El motor de alerta de sepsis de Epic falló en una validación de 2021 en Michigan Medicine, pasando por alto a dos tercios de los pacientes que posteriormente desarrollaron sepsis, mientras activaba una alarma en el 18 % de todos los ingresos. El error se remonta a un fallo clásico de fuga de datos (data leakage): el modelo contaba la orden de antibióticos de un médico —que ya es un signo de sospecha de infección— como un predictor, reflejando esencialmente una decisión que el clínico ya había tomado.

Por qué falló el modelo

El equipo de Michigan examinó 38.455 estancias hospitalarias, el tamaño típico de un proyecto de mejora de la calidad de varios años. Los puntos de referencia internos de Epic prometían una alta precisión, pero la prueba independiente mostró lo contrario. Las alertas de "alto riesgo" del modelo se activaron en casi una quinta parte de los pacientes, pero dos tercios de los casos reales de sepsis pasaron desapercibidos. En la práctica, el sistema gritaba "¡cuidado!" con demasiada frecuencia mientras ignoraba los mismos eventos que debía detectar.

La causa raíz no fue un fallo en el algoritmo de aprendizaje automático en sí, sino en los datos que se le suministraron. Al utilizar la presencia de una orden de antibióticos como entrada, el modelo aprendió a predecir una elección que el clínico ya había realizado. Cuando el algoritmo señalaba a un paciente, a menudo lo hacía porque el médico ya había ordenado antibióticos, no porque la fisiología del paciente indicara una sepsis inminente.

Un problema más amplio en la IA hospitalaria

El modelo de sepsis de Epic se ha implementado en cientos de hospitales durante años, pero el error de fuga permaneció oculto hasta que un esfuerzo de validación específico lo sacó a la luz. El episodio ilustra una debilidad sistémica: la mayoría de los proyectos de IA en los sistemas de salud carecen de los controles operativos necesarios para detectar tales problemas de forma temprana.

  • Sin pruebas externas – Los hospitales no realizaron pruebas externas.
  • Sin monitoreo continuo – No contaban con monitoreo.
  • Sin una responsabilidad clara – Sin un equipo designado responsable de la calidad de los datos y del rendimiento del modelo, los problemas pasan desapercibidos.

Estas brechas mantienen muchas iniciativas de IA atrapadas en el "purgatorio de los pilotos", sin llegar nunca más allá de una etapa de prueba de concepto.

El coste oculto de los datos fragmentados

El caso de la sepsis también muestra cómo los ecosistemas de TI de salud fragmentados sabotean la IA. Los obstáculos comunes incluyen:

  • Registros de pacientes bloqueados en módulos de EHR heredados que no intercambian datos automáticamente.
  • Sistemas de imagen y laboratorio que no pueden comunicarse entre sí, lo que obliga a realizar transferencias manuales de archivos.
  • Identificadores de pacientes duplicados que dividen los datos de una misma persona en múltiples historias clínicas.
  • Notas clínicas y signos vitales almacenados en silos separados, que nunca se fusionan para el entrenamiento del modelo.

Cuando un modelo se entrena con un conjunto de datos limpio y curado, pero luego se alimenta con datos reales y desordenados, el rendimiento se degrada silenciosamente. Los clínicos pierden la confianza rápidamente; una enfermera que tiene que perseguir alertas a través de múltiples pantallas las ignorará, incluso si el algoritmo subyacente es técnicamente sólido.

Cuatro fundamentos "aburridos" para una IA fiable

Un despliegue funcional de IA se basa en cuatro capacidades prácticas que rara vez ocupan los titulares:

  1. Interoperabilidad – Los datos deben fluir entre los EHR, laboratorios, plataformas de imagen y herramientas de apoyo a la decisión sin pasos manuales de exportación e importación.
  2. Gobernanza – Una persona o equipo responsable debe ser dueño de la calidad de los datos y monitorear los resultados del modelo a lo largo del tiempo.
  3. Integración en el flujo de trabajo – Las alertas deben aparecer dentro de la cola de trabajo existente del clínico; los clics o pantallas adicionales frenan la adopción.
  4. Operaciones escalables – El monitoreo automatizado, el análisis de la fatiga por alertas y los procesos de reentrenamiento periódico son esenciales antes de que el modelo llegue a producción.

Omitir cualquiera de estos pasos deja un proyecto vulnerable al tipo de fallo silencioso observado en el modelo de sepsis de Epic.

Preguntas que debe hacer antes de comprar una solución de IA

Los hospitales pueden evitar errores costosos exigiendo respuestas concretas:

  • ¿Puede rastrear los datos de un solo paciente a través de cada sistema que utilizará el modelo?
  • ¿Quién, por nombre, es responsable de mantener la calidad de los datos y supervisar el rendimiento del modelo?
  • ¿Se han probado las alertas con clínicos durante un turno real, y no solo en un entorno de pruebas (sandbox)?
  • ¿Existe un plan de monitoreo documentado que especifique cómo se identificarán y abordarán las derivas del rendimiento (performance drift)?

Si el proveedor no puede señalar a una persona, un proceso o un panel de monitoreo, la organización debería detenerse y reevaluar.

Conclusión

El modelo de sepsis de Epic no falló porque el aprendizaje automático sea inadecuado para los hospitales; falló porque carecía del flujo de datos y de las estructuras de gobernanza necesarios. Un modelo que predice la propia decisión de un médico advierte que es la capa de ingeniería de datos, y no el algoritmo, la que requiere mejoras. Construir una IA confiable en la atención sanitaria exige la misma infraestructura «aburrida» que mantiene en funcionamiento cualquier sistema de TI crítico: datos limpios y conectados, una rendición de cuentas clara, alertas integradas en el flujo de trabajo y un monitoreo proactivo. Sin ellas, incluso el modelo más sofisticado acabará lanzando las advertencias equivocadas a las personas equivocadas.