Validate Health es una firma de analítica en salud con sede en Chicago. Ayuda a prestadores y organizaciones de atención responsable (ACOs) a gestionar su riesgo financiero y mejorar los resultados de sus pacientes en la transición hacia la atención basada en valor. En 2025 fue adquirida por Oliver Wyman, de Marsh McLennan, para integrarse a su práctica de consultoría actuarial.

Para una empresa así, los modelos son el producto, y uno de los más importantes es saber cuánto va a costar cada paciente. Por eso trabajamos con su equipo en todo el ciclo de data science sobre datos de salud en Databricks: el análisis exploratorio, la definición de modelos de predicción de costo por paciente, la arquitectura para evaluarlos y mejorarlos, y el despliegue a producción con MLOps. El resultado: pasamos de un modelo base con 50% de confiabilidad a un modelo en producción con 87,8%.

En analítica de salud, un modelo no es útil solo porque "funciona en el notebook". Tiene que ser preciso, explicable y estable, porque sus resultados alimentan decisiones financieras y clínicas importantes. El reto tenía varias capas:

• Datos complejos y sensibles: información de salud de gran volumen, con muchas variables, valores faltantes y casos extremos, que exige un manejo cuidadoso de la privacidad.
• Elegir bien qué modelar: definir qué modelos y arquitecturas tienen sentido antes de invertir en entrenarlos.
• Medir lo que importa: saber si una nueva versión del modelo es realmente mejor que la anterior, y no solo distinta.
• Llegar a producción: pasar de la experimentación a modelos desplegados, versionados y monitoreados.

1. Análisis exploratorio de datos

Antes de construir cualquier modelo, entendimos los datos. Con un análisis exploratorio (EDA) en Databricks revisamos distribuciones, calidad, valores atípicos y relaciones entre variables, y detectamos los patrones y los riesgos que el modelo debía tener en cuenta. Esa base evita construir sobre supuestos equivocados.

2. Definición de modelos y arquitectura de despliegue

Con lo aprendido definimos los modelos de predicción de costo por paciente y cómo se iban a desplegar: qué problema resuelve cada uno, con qué datos se entrena, cada cuánto se actualiza y cómo llegan sus resultados a quienes los usan.

3. Arquitectura de evaluación: modelo base, evaluador, pruebas y métricas

El corazón del proyecto fue una arquitectura que permite mejorar los modelos con evidencia:

• Modelo base: un modelo de referencia, simple y bien entendido, que fija el punto de partida. El nuestro arrancó con 50% de confiabilidad, y cada nueva versión tenía que superarlo para ganarse su lugar.
• Evaluador: un proceso automático que compara cada modelo candidato contra el modelo base con las mismas reglas y los mismos datos.
• Pruebas: validación con datos que el modelo nunca vio y con periodos históricos distintos, para confirmar que el desempeño se sostiene en el tiempo y en distintos segmentos.
• Métricas: indicadores técnicos y de negocio que dicen, sin ambigüedad, si una versión es mejor.

4. Despliegue a producción con MLOps

Los modelos que superan al evaluador se llevan a producción con MLOps en Databricks:

• MLflow: cada experimento queda registrado con sus datos, parámetros y métricas, de modo que cualquier resultado se puede reproducir y comparar.
• Unity Catalog: registro central de modelos, con versiones controladas, trazabilidad y permisos de acceso gobernados, clave cuando se trabaja con datos de salud.
• Model Serving: el modelo en producción se consume vía API, para que las aplicaciones y los analistas de Validate Health obtengan la predicción de costo de cada paciente cuando la necesitan.
• Monitoreo: seguimiento del desempeño para detectar cuándo el modelo empieza a degradarse y necesita reentrenarse.

Un modelo aprende minimizando una función de pérdida: la regla que le dice qué tan grave es cada error. Elegirla es una decisión de negocio, no solo técnica:

• No todos los errores cuestan lo mismo: al predecir el costo por paciente, subestimar el de un paciente complejo puede ser mucho más grave que sobreestimarlo. La función de pérdida le enseña al modelo qué errores evitar con más fuerza.
• Los casos extremos importan, pero no deben dominar: unos pocos pacientes pueden concentrar una gran parte del costo. Elegimos funciones de pérdida que los tengan en cuenta sin que distorsionen las predicciones para el resto.
• El modelo optimiza lo que le pides: si la pérdida no refleja la prioridad del negocio, el modelo será técnicamente bueno y comercialmente inútil.

En pocas palabras, la función de pérdida es la forma de traducir "qué nos duele más" al idioma del modelo.

Medir bien es lo que convierte un experimento en un activo. Evaluamos cada modelo en tres niveles:

1. Precisión: qué tan lejos están las predicciones de la realidad, en promedio y en los casos más costosos.
2. Estabilidad: si el modelo se comporta igual en distintos periodos y segmentos de pacientes, o solo funciona en algunos.
3. Impacto en el negocio: si las mejoras técnicas se traducen en mejores decisiones de riesgo y de costo.

Así pasamos del 50% de confiabilidad del modelo base al 87,8% del modelo en producción, una mejora de 37,8 puntos medida con las mismas reglas en cada paso. Con esas métricas, cada ciclo de mejora tiene un resultado claro: la nueva versión reemplaza al modelo en producción o se descarta, y siempre se sabe por qué.

1. Datos de salud sensibles: trabajar con información de pacientes bajo estrictos cuidados de privacidad y acceso.
2. Datos heterogéneos y con casos extremos: preparar variables útiles sin perder la señal de los casos más relevantes.
3. Comparaciones justas: garantizar que cada versión se evaluara con las mismas reglas que el modelo base.
4. Del experimento a producción: llevar los modelos a un entorno productivo, versionado y monitoreado.

• Un entendimiento profundo de los datos gracias al análisis exploratorio, antes de invertir en modelos.
• Modelos de predicción de costo por paciente con su arquitectura de despliegue definida.
• De 50% a 87,8% de confiabilidad: una mejora de 37,8 puntos frente al modelo base, medida con una arquitectura de evaluación con evaluador, pruebas y métricas.
• Modelos en producción con MLflow, Unity Catalog y Model Serving, versionados, gobernados y consumidos vía API.

La experiencia con Validate Health resume nuestro método:

1. Entender los datos primero: el análisis exploratorio define qué es posible y qué no.
2. Fijar un modelo base: sin un punto de referencia no hay forma de saber si mejoras.
3. Elegir la función de pérdida según el negocio: el modelo debe evitar los errores que más cuestan.
4. Evaluar con métricas técnicas y de negocio: una mejora solo cuenta si se nota en las decisiones.
5. Desplegar con MLOps: registrar con MLflow, gobernar con Unity Catalog, servir vía API y monitorear para que el modelo siga siendo confiable.

• MLOps / LLMOps: llevar modelos y agentes a producción y mantenerlos confiables, medibles y eficientes en costo.
• Auditoría y Evaluación de Agentes: la misma disciplina de modelo base, evaluador y métricas, aplicada a sistemas de IA generativa.
• Datos para IA: plataformas de datos en Databricks, Snowflake o BigQuery listas para analítica y machine learning.
• Consultoría y ROI de IA: definir qué modelar y cómo medir su impacto antes de invertir.

¿Tienes modelos que no salen del notebook o que nadie sabe si están mejorando? Hablemos.