Qué pasó
La sepsis es una emergencia en la que cada hora cuenta: detectarla temprano cambia el desenlace. Por eso un modelo predictivo que avise antes que el ojo humano es, en teoría, una de las mejores ideas que la inteligencia artificial puede aportar a un hospital. Epic Systems, la compañía del expediente clínico electrónico que usan miles de centros, incorporó uno: el Epic Sepsis Model.
Investigadores lo validaron con datos propios en Michigan Medicine. El resultado, publicado en la literatura médica revisada por pares, fue este: el modelo no detectó a 1.709 de 2.552 pacientes con sepsis, es decir, el 67%. Al mismo tiempo, generó alertas sobre el 18% de todos los pacientes hospitalizados.
Las dos cifras juntas describen el problema completo. El sistema dejaba pasar a dos de cada tres pacientes que sí tenían la condición y, a la vez, señalaba a casi uno de cada cinco ingresados. Fallaba en las dos direcciones a la vez.
Por qué pasó
Un modelo predictivo aprende de una población: sus pacientes, sus criterios de registro, sus prácticas de documentación, sus tiempos. Ese aprendizaje es lo que lo hace útil, y también lo que lo ata al lugar donde se entrenó. Trasladarlo a otro hospital no es instalar un programa: es aplicar a una población distinta un patrón aprendido en otra.
El desempeño que reporta un proveedor es una medición legítima en su contexto. No es una promesa transferible. El fallo de proceso está en tratarlo como si lo fuera: activar el modelo en un centro nuevo sin repetir la medición con datos locales, porque la cifra "ya está validada".
La segunda parte es la carga de alertas. Un aviso sobre el 18% de los hospitalizados no funciona como una señal, funciona como ruido de fondo. El personal aprende, con toda razón, a descontarlo. Cuando eso ocurre, el modelo puede seguir marcando correctamente algunos casos y ya no cambiar ninguna decisión: la alerta perdió su capacidad de interrumpir a alguien. Ese umbral —cuántas alertas por día tolera un equipo antes de dejar de mirarlas— casi nunca se define antes de encender el sistema.
La tercera es la ausencia de un mecanismo de vigilancia continua. Sin una medición periódica de cuántos casos reales se detectaron y cuántos avisos fueron falsos, la única señal disponible es la impresión del equipo. Y la impresión llega tarde.
Dónde te puede pasar a ti
Ninguna de estas dinámicas es exclusiva de un hospital. Se repiten en cualquier organización que enciende un modelo comprado:
- Un puntaje de riesgo crediticio entrenado con clientes de otro país aplicado a tu cartera.
- Un detector de fraude que marca tantas transacciones legítimas que el equipo lo empieza a ignorar.
- Un clasificador de leads que ordena tus prospectos según el comportamiento de los prospectos de otra empresa.
- Un modelo de rotación de personal validado en una industria distinta a la tuya.
La pregunta que ordena todo es una: ¿alguien midió este sistema con tus datos, tu población y tu operación, antes de dejar que influya en una decisión?
Cómo se evita
- Validación local obligatoria antes de encender. Se corre el modelo en silencio sobre casos históricos propios y se compara su salida contra lo que efectivamente ocurrió. Si no se puede hacer esa comparación, no se enciende.
- Presupuesto de alertas definido de antemano. Antes de activar el sistema se acuerda cuántos avisos por día es capaz de atender el equipo. El umbral del modelo se ajusta a ese número, no al revés.
- Las dos caras del error, siempre juntas. Ningún reporte muestra solo aciertos: se publican en el mismo tablero los casos que el modelo dejó pasar y los avisos que resultaron falsos.
- Revisión periódica con fecha. El desempeño se vuelve a medir en un calendario fijo, porque la población cambia aunque el modelo no.
Un buen modelo mal validado localmente produce el mismo daño que un mal modelo. La diferencia no está en el algoritmo: está en si alguien lo probó donde se iba a usar.
Cómo lo hacemos en Catalizadora
Todo modelo que entra a un sistema que construimos corre primero en modo silencioso contra datos históricos del cliente, y su salida se compara con el resultado real antes de que llegue a un usuario. Fijamos con el cliente cuántas alertas diarias tolera su operación y calibramos el umbral a esa capacidad. Los tableros muestran siempre las dos caras: lo que el sistema marcó y lo que se le pasó. Un modelo que no se puede medir con datos del cliente no se activa.