La IA clínica tiene un punto ciego, y está en la consulta

Andrea Lopez SalcedoOtorrinolaringología | Salud digital | Aplicaciones médicas

4 min de lectura

Hay una escena que se repite en startups de salud digital de todo el mundo. Un equipo con talento técnico impecable construye un producto clínico durante meses. Lo prueba con datos, obtiene métricas prometedoras, diseña una interfaz limpia. Y cuando llega al hospital real, se estrella.

La tecnología funciona. Todo lo demás falla.

Se estrella porque el formulario que diseñaron no recoge lo que el médico necesita saber. Porque el flujo que imaginaron no encaja en una consulta de seis minutos con interrupciones. Porque la variable clave para el diagnóstico no estaba en el dataset, estaba en cómo el paciente fruncía el ceño al describir su mareo. El patrón se repite demasiado para ser anecdótico. Y tiene una causa clara: los productos de IA clínica se diseñan, mayoritariamente, desde fuera del hospital.

Cómo decide un médico (de verdad)

Hay una fantasía persistente en el mundo healthtech: que el razonamiento clínico es un árbol de decisión. El médico recibe datos, los procesa, emite un diagnóstico. Si le das mejores datos o más rápido, todo mejora. La realidad es más desordenada. Un médico en consulta trabaja con información incompleta, ambigua, y a menudo contradictoria. El paciente que dice "me mareo" puede tener una hipotensión, una crisis de ansiedad, o un tumor del nervio acústico. Las mismas palabras, tres diagnósticos que no se parecen en nada. La diferencia está en preguntas que ningún formulario hace, en observaciones que no se codifican, y en un contexto clínico que se construye en tiempo real durante la conversación.

La otoneurología, la especialidad que se ocupa del vértigo y los trastornos del equilibrio, es probablemente el ejemplo más extremo de esto. El diagnóstico depende casi enteramente de la narrativa del paciente y de la capacidad del médico para interpretarla. No hay una analítica que diga "esto es un vértigo posicional." Se diagnostica escuchando, preguntando bien, y reconociendo patrones en respuestas ambiguas. Si un producto de IA funciona aquí, probablemente funciona en cualquier especialidad. Si falla aquí, lo que falla probablemente afecta a toda la IA clínica.

Cuando las métricas dicen que sí y la clínica dice que no

Un modelo de machine learning entrenado para predecir el nivel de triaje en urgencias puede tener un AUC excelente y ser clínicamente inútil. Pasa más de lo que parece. El modelo aprende correlaciones estadísticas en datos históricos. Algunas de esas correlaciones reflejan realidad clínica. Otras reflejan sesgos del sistema: qué tipo de pacientes llegan a qué hora, cómo documenta cada turno, qué variables faltan porque nadie las registra. Un data scientist ve rendimiento. Un clínico ve riesgos.

La conclusión es sencilla: hace falta criterio clínico real dentro del equipo que construye. Alguien que entienda los datos desde el otro lado, integrado en el proceso, no un asesor decorativo que revisa el producto una vez al trimestre.

La regulación como brújula temprana

Cuando se diseña una herramienta que estructura anamnesis vestibulares con IA, hay una decisión de diseño temprana que lo cambia todo: ¿la herramienta interpreta o solo documenta? Si interpreta, es Software as a Medical Device (SaMD). Regulación europea, proceso de certificación, meses de validación adicional. Si documenta y estructura información sin emitir juicio diagnóstico, no lo es. Muchos founders descubren esta distinción demasiado tarde, cuando ya han invertido meses desarrollando en una dirección que les obliga a un proceso regulatorio que no habían contemplado. Entender el marco regulatorio (MDR, AI Act, GDPR sanitario) desde la fase de concepto no ralentiza el proyecto. Lo protege. Y obliga a pensar mejor qué problema resuelve realmente el producto.

El punto ciego y cómo cubrirlo

El punto ciego de la IA clínica es de perspectiva. Los equipos que construyen productos de salud digital rara vez incluyen a alguien que haya pasado consulta esa misma mañana, que conozca el peso real de un diagnóstico ambiguo, y que además entienda qué hay dentro del modelo que están entrenando.

Esa intersección existe, aunque sea pequeña. Y las lecciones que salen de ahí son transferibles a cualquier equipo que construya tecnología para entornos clínicos.

Lecciones concretas, extraídas del cruce entre la consulta y el código, usando una de las especialidades más difíciles de digitalizar como campo de pruebas. Para founders, para equipos de producto, para inversores, y para cualquier médico que se pregunte qué viene.