Poder, Tecnología y Sociedad

Cuando la IA entra al hospital, el algoritmo deja de ser el problema: la gobernanza se convierte en el verdadero desafío

Por el Dr. Adrián Guzmán

Hay una frase que deberíamos repetir cada vez que hablamos de Inteligencia Artificial en medicina:

Una IA puede equivocarse. Lo verdaderamente peligroso es construir una institución incapaz de reconocer que se equivocó.

El reciente caso que involucra a Mayo Clinic y a una exdirectora de operaciones de investigación, Traci Tamiko Eto, debería ser leído con enorme cuidado. No porque las acusaciones hayan sido probadas —no lo han sido—, sino porque plantea preguntas que van mucho más allá de Mayo Clinic: ¿quién valida una IA médica?, ¿quién decide cuándo un proyecto necesita supervisión ética?, ¿qué ocurre cuando los resultados son peores de lo esperado?, ¿quién protege al investigador o especialista que levanta la mano y dice “esto no está funcionando”?

Y, sobre todo:

¿Qué sucede cuando la velocidad de innovación comienza a competir con la responsabilidad clínica?

El documento analiza precisamente estas tensiones: presunta supresión de resultados desfavorables, posibles problemas de consentimiento e IRB, utilización de software no autorizado, gobernanza de datos sensibles y posibles represalias contra quienes plantearon preocupaciones. Es fundamental insistir en que se trata de alegaciones y que Mayo Clinic las niega.

Pero independientemente del desenlace judicial, el caso nos obliga a mirar el problema estructural.

Mi experiencia en Nueva York me enseñó algo fundamental

Durante mi etapa profesional como Senior Cloud Implementation Architect en Memorial Sloan Kettering Cancer Center (MSKCC), en Nueva York, entre 2018 y 2020, tuve la oportunidad de trabajar dentro de uno de los ecosistemas hospitalarios y oncológicos más sofisticados del mundo.

Mi trabajo estuvo relacionado con la validación de tecnologías empresariales en entornos sanitarios regulados, modernización de infraestructura, arquitectura cloud, gestión de información clínica y marcos de gobierno tecnológico, incluyendo iniciativas relacionadas con Azure, continuidad operativa, recuperación ante desastres y arquitecturas de información clínica.

Y también tuve experiencia trabajando con Paige.AI en el ecosistema de MSKCC, algo que para mí fue especialmente relevante porque representaba precisamente el tipo de frontera tecnológica donde la Inteligencia Artificial deja de ser una demostración experimental y comienza a interactuar con problemas reales de medicina.

Ahí comprendí algo que hoy considero todavía más importante:

En medicina, una arquitectura técnicamente brillante no es suficiente.

Necesitamos una arquitectura que sea:

segura + explicable + auditable + validable + gobernable + clínicamente responsable.

Cuando una tecnología trabaja con información médica, imágenes, datos clínicos o procesos relacionados con pacientes, el concepto de “move fast and break things” simplemente no puede trasladarse sin modificaciones al ámbito sanitario.

Porque aquí no estamos hablando solamente de una aplicación que falla.

Estamos hablando potencialmente de una persona.

El problema no es que una IA tenga errores

Uno de los elementos más llamativos del caso Mayo es la discusión alrededor de resultados presuntamente desfavorables de una herramienta de IA.

Pero quiero hacer una distinción fundamental.

Que una IA tenga una tasa elevada de error durante una fase experimental no constituye, por sí mismo, un escándalo.

Los modelos fallan.

Los modelos tienen sesgos.

Los modelos presentan falsos positivos y falsos negativos.

Los modelos pueden funcionar extraordinariamente bien en un dataset y mucho peor en otro.

Una herramienta puede tener resultados impresionantes en laboratorio y comportarse de manera completamente diferente cuando se enfrenta a la diversidad del mundo real.

Eso es ciencia.

Eso es ingeniería.

Eso es investigación.

El verdadero problema comienza cuando una organización deja de tratar el error como información y empieza a tratarlo como una amenaza reputacional.

Porque entonces aparece el fenómeno más peligroso de todos:

la desaparición institucional de las malas noticias.

Un error documentado puede corregirse.

Un error oculto puede convertirse en una catástrofe.

El documento plantea precisamente esta preocupación: si se confirmara que resultados desfavorables fueron ocultados o distorsionados, el problema ya no sería solamente técnico, sino de integridad institucional.

En medicina, los datos no son simplemente “datos”

Otra cuestión que me preocupa especialmente es la gobernanza de información clínica y genómica.

En el mundo tecnológico hemos aprendido a hablar de:

data lakes, data warehouses, APIs, modelos fundacionales, embeddings, pipelines, data lineage y synthetic data.

Pero existe una realidad que ningún arquitecto debería olvidar:

detrás de cada registro médico existe una persona.

Y en el caso de los datos genómicos, incluso hay más personas involucradas.

Una secuencia genética puede revelar información sobre familiares, predisposiciones y características que trascienden al individuo que originalmente proporcionó la muestra.

Por eso, hablar simplemente de “anonimización” puede resultar insuficiente en la era de la IA.

La combinación de datasets puede permitir inferencias que no eran posibles cuando cada dataset era analizado de forma independiente.

Y aquí aparece un concepto que considero esencial:

Data lineage no es un lujo. Es una obligación.

Debemos saber:

¿De dónde vino el dato?

¿Quién lo transformó?

¿Quién lo utilizó?

¿En qué modelo terminó?

¿Quién tuvo acceso?

¿A qué proveedor fue transferido?

¿En qué país terminó almacenado?

¿Se utilizó para entrenamiento?

¿Puede eliminarse posteriormente?

Y quizá la pregunta más difícil:

¿Puede realmente deshacerse el uso de un dato una vez que ha sido incorporado a un sistema de IA?

La IA médica no puede ser una caja negra institucional

Una de las lecciones que aprendí trabajando en arquitectura tecnológica dentro de un entorno médico complejo es que la seguridad no puede depender de la confianza.

Debe depender de controles verificables.

No basta con decir:

“Este modelo fue aprobado.”

Tenemos que preguntar:

¿Qué versión?

¿Con qué población fue validado?

¿Con qué dataset?

¿Con qué métricas?

¿Quién lo validó?

¿Quién autorizó el cambio?

¿Qué ocurre cuando cambia el modelo?

¿Qué ocurre cuando cambia el prompt?

¿Qué ocurre cuando cambia una dependencia de software?

¿Qué ocurre cuando cambia la fuente de datos?

¿Qué ocurre cuando el proveedor actualiza el algoritmo?

Porque una IA no es un producto estático.

Una modificación aparentemente pequeña puede cambiar su comportamiento.

Por eso, en mi opinión, la gobernanza de IA médica debe adoptar un principio muy sencillo:

Every material change is potentially a safety change.

Cada cambio material debe poder activar una nueva evaluación.

¿Quién puede detener una IA?

Esta es quizá la pregunta más importante.

Supongamos que tenemos un sistema de IA utilizado en un hospital.

El sistema comienza a presentar resultados anómalos.

Un ingeniero lo detecta.

Un médico lo confirma.

Un especialista en privacidad encuentra una vulnerabilidad.

Un investigador descubre que la población utilizada para validarlo no representa adecuadamente a los pacientes reales.

¿Quién tiene autoridad para decir:

“Detengan el sistema.”

Si la respuesta es:

“Hay que esperar autorización del director.”

tenemos un problema.

Si la respuesta es:

“Pero el proyecto ya recibió millones de dólares.”

tenemos un problema mayor.

Si la respuesta es:

“No podemos detenerlo porque somos líderes en IA.”

entonces ya no estamos hablando de tecnología.

Estamos hablando de cultura organizacional.

Una organización verdaderamente madura debe permitir que una persona responsable de seguridad, ética, privacidad o investigación pueda activar una pausa sin temor a represalias.

El whistleblower es parte de la arquitectura

Esta es una idea que considero fundamental:

Un whistleblower no es necesariamente un problema para una organización.

En sistemas complejos, puede ser un sensor.

En arquitectura cloud tenemos monitoring.

Tenemos logs.

Tenemos alertas.

Tenemos observabilidad.

Tenemos incident response.

Entonces, ¿por qué no tenemos el equivalente humano?

Un investigador que dice:

“Los resultados no coinciden.”

Un médico que dice:

“Este modelo está fallando con mis pacientes.”

Un especialista en privacidad que dice:

“Este dataset puede ser reidentificable.”

Un ingeniero que dice:

“Esta actualización cambió el comportamiento.”

Todos ellos están haciendo exactamente lo que debería hacer un buen sistema de seguridad:

detectar anomalías.

El documento señala que una cultura de represalias puede producir un efecto escalofriante: los empleados dejan de documentar, escalar o cuestionar problemas.

Eso convierte el miedo en una vulnerabilidad tecnológica.

Mayo no es el único problema

Sería un error convertir este caso en una discusión sobre una sola institución.

El problema es mucho más grande.

Está ocurriendo en hospitales.

En universidades.

En startups.

En farmacéuticas.

En empresas de tecnología.

En gobiernos.

Y en cualquier organización que esté intentando implementar IA más rápido que sus propios mecanismos de gobernanza.

La tentación es enorme:

“Si nosotros no lo hacemos primero, alguien más lo hará.”

Pero en medicina existe una diferencia fundamental.

No estamos compitiendo únicamente por velocidad.

Estamos compitiendo por confianza.

Y la confianza tarda años en construirse y puede desaparecer en un solo incidente.

Mi conclusión: necesitamos AI Governance by Design

La respuesta no es detener la Inteligencia Artificial.

Todo lo contrario.

Necesitamos utilizarla.

Necesitamos acelerar su adopción.

Necesitamos invertir en ella.

Necesitamos utilizarla para descubrir enfermedades, analizar imágenes, acelerar investigación, personalizar tratamientos y ampliar el acceso al conocimiento médico.

Pero debemos hacerlo bajo una nueva arquitectura:

AI Governance by Design.

No como una auditoría al final.

No como un documento de compliance.

No como un comité que aparece cuando algo sale mal.

Sino como parte de la arquitectura desde el primer día.

Cada sistema debería tener:

propietario responsable

inventario de IA

trazabilidad de datos

versionamiento de modelos

validación independiente

evaluación de sesgos

monitoreo continuo

gestión de incidentes

controles de ciberseguridad

protección de privacidad

supervisión humana

mecanismo de rollback

mecanismo de apagado

protección para quienes reportan riesgos

Porque al final existe una diferencia enorme entre:

una organización que utiliza Inteligencia Artificial

y

una organización que sabe gobernar Inteligencia Artificial.

Mi conclusión personal

Después de haber trabajado en arquitectura tecnológica dentro del ecosistema sanitario de Nueva York y de haber vivido de cerca la complejidad de integrar tecnología, cloud, información clínica e innovación en entornos altamente regulados —incluyendo mi experiencia con Paige.AI en MSKCC—, tengo una convicción cada vez más fuerte:

El futuro de la IA médica no dependerá solamente de quién tenga el mejor modelo.

Dependerá de quién sea capaz de construir la mejor arquitectura de confianza alrededor del modelo.

Porque un algoritmo puede equivocarse.

Un sistema puede fallar.

Un modelo puede necesitar ser retirado.

Eso forma parte de la innovación.

Lo que no podemos permitir es que una institución pierda la capacidad de escuchar cuando alguien dice:

“Tenemos un problema.”

La verdadera madurez de la Inteligencia Artificial no se demuestra cuando una organización presume que su modelo nunca falla.

Se demuestra cuando puede decir:

“Nuestro modelo falló. Lo detectamos. Lo documentamos. Lo investigamos. Lo corregimos. Y aprendimos.”

Esa es la diferencia entre implementar IA y gobernar IA.

Y en medicina, esa diferencia puede ser literalmente la diferencia entre innovación y riesgo.