Del impulso al impacto: las tres decisiones para escalar la IA en salud

El 71 % de las organizaciones de salud que reportan valor medible de la IA no está ampliando esas iniciativas al ritmo esperado, según una encuesta de Carta Healthcare de abril de 2026. La barrera más mencionada es, como en la clínica del caso, encajar la IA en los sistemas existentes: la integración con la historia clínica electrónica (44 %).¹ Y el problema no es exclusivo de la salud. Robert Cooper, en IEEE Engineering Management Review, retoma el término “parálisis del piloto” para describir ese estancamiento; según su análisis, la mayoría de los fracasos de los proyectos de IA nace de malas prácticas de gestión, no de la tecnología.²

En Argentina y la región se ve la otra cara del mismo fenómeno. Ocho de cada diez profesionales ya usan IA generativa, la mayoría con cuentas personales gratuitas; pero solo tres de cada diez directivos afirman que su organización tiene una estrategia formal de transformación digital, y otros cuatro de cada diez la están desarrollando, según la Encuesta de Salud Digital 2025 de Consenso Salud y Develop Consulting.³

La IA entró en las instituciones antes de que las instituciones la organizaran. Impulso hay de sobra; lo que falta es convertirlo en impacto.

Convertir ese impulso en impacto pide más que buenos resultados en un piloto: la solución tiene que encajar en los sistemas, las reglas y los procesos de una institución de salud. Para pasar de una prueba exitosa a una implementación a escala hay que tomar tres decisiones, y cada una atiende a una de las trabas de la clínica: sobre qué datos va a correr la IA y qué se resuelve una sola vez, quién responde por ella y quién puede detenerla, y cómo se demuestra que mejora el trabajo real. Una condición atraviesa a las tres: los equipos que van a usarla y gobernarla.

Lo ideal es tomarlas antes del piloto; si el piloto ya ocurrió, todavía se pueden tomar antes de escalar. Las recorremos en orden y, al final, volvemos a la clínica.

Un modelo de IA vale lo que valen los datos que recibe en producción. Y en una institución de salud esos datos vienen de sistemas que nacieron por separado (la historia clínica, el laboratorio, las imágenes, la farmacia, la facturación y, cada vez más, los prestadores externos), cada uno con su estructura, sus códigos locales y su forma de identificar a un paciente. Reemplazar esos sistemas rara vez es viable, y conectar cada modelo nuevo con cada sistema, punto a punto, multiplica el trabajo con cada proyecto.

La decisión de arquitectura con más impacto es definir qué se resuelve de forma compartida y qué queda en cada modelo. Hay cuatro capacidades que conviene resolver una sola vez, en una capa compartida de datos, para que cada modelo nuevo no vuelva a enfrentar los mismos problemas:

• Estructura: un formato común para representar a un paciente, un análisis o una receta, basado en un estándar abierto como HL7® FHIR®, que la industria adoptó en los últimos años para intercambiar información clínica. Así el modelo consume un solo formato en vez de uno por sistema, y la integración construida para el primer caso sirve para el siguiente.
• Terminologías: un vocabulario común al que se traducen los códigos locales, como LOINC para los análisis de laboratorio o SNOMED CT para diagnósticos y hallazgos clínicos. Si no, un mismo análisis llega con códigos distintos según la fuente, el modelo deja de reconocerlo y se degrada en silencio al cambiar de sede.
• Calidad y permisos: reglas comunes que definen qué dato es aceptable (un valor en un rango posible, un documento con la cantidad correcta de dígitos) y qué datos puede usar cada modelo, tanto en el entrenamiento como en producción, incluida la información que se carga en una herramienta de IA generativa. Quién responde por la base legal y la finalidad de ese uso se define en la Decisión 2.
• Identidad: reconocer que registros de distintos sistemas corresponden a la misma persona, aunque cada sistema use su propio número de paciente y el DNI falte o esté mal cargado en alguno. Sin esto, el modelo ve a un mismo paciente como varios y repite las alertas.

Adoptar un estándar resuelve la primera de las cuatro. Para las otras tres, FHIR® ofrece herramientas (perfiles, mapeos de códigos, vinculación de registros), pero alguien tiene que definirlas y mantenerlas. Dos sistemas que usan FHIR® pueden seguir mandando códigos distintos, valores imposibles y el mismo paciente dos veces. Con las cuatro resueltas en la capa compartida, a cada modelo le queda solo lo propio: la lógica de su caso de uso y el subconjunto de datos que necesita.

La prioridad la marca el primer caso de uso con valor demostrable: integrar las fuentes que ese caso exige, pero sobre la capa compartida, para que cada modelo nuevo arranque con parte del camino recorrido. Conectar solo lo que pide un piloto, directo al modelo y sin capa compartida, obliga a rehacer el trabajo en el siguiente.

En Argentina y la región, donde el costo de implementación es la barrera más citada para la transformación digital (52 %),³ rehacer integraciones es un gasto que pocas instituciones pueden absorber. La investigación respalda este enfoque: RAND, tras entrevistar a 65 científicos de datos e ingenieros de la industria y la academia, identifica la falta de infraestructura para gestionar los datos y desplegar los modelos como una de las cinco causas raíz del fracaso de los proyectos de IA, y recomienda invertir de antemano en esa infraestructura.⁴ Eso no significa conectar de entrada todas las fuentes, que solo demora los resultados: la capa se construye una vez y las fuentes se suman a medida que los casos de uso las piden.

Gobernar una solución de IA en salud implica responder en cuatro planos: los datos, la validez clínica, el modelo en el tiempo y las decisiones. Cada uno necesita un responsable asignado.

Hoy, uno de cada cuatro directivos encuestados por Carta Healthcare reporta que su organización no tiene un responsable claro de la estrategia de IA.¹ Quién asume cada rol depende de la organización y del riesgo, pero ninguno puede quedar vacante.

Y la gobernanza no empieza con el primer modelo propio. Si ocho de cada diez encuestados ya usan IA generativa, la mayoría con cuentas personales gratuitas, como muestra la encuesta de Consenso Salud, la pregunta de qué datos de pacientes salen de la institución, y bajo qué reglas, ya está abierta.³

Hay un indicador simple de gobernanza madura: para cada solución en producción, la organización sabe quién puede detenerla y bajo qué condiciones. Definirlo antes de que la solución se use con pacientes es una forma concreta de cumplir el primer principio que la Organización Mundial de la Salud propone para la IA en salud: proteger la autonomía humana, es decir, que las personas mantengan el control de los sistemas de salud y de las decisiones médicas.⁵

Que un modelo acierte no es suficiente: lo que importa es cuánto cambió el resultado. Cuando Carta Healthcare preguntó a los directivos qué aceleraría la adopción de IA en sus organizaciones, la respuesta más elegida fue una solución que funcione dentro de la historia clínica electrónica (48 %).¹

Integrarse es lo primero que se pide, pero no demuestra por sí solo que la solución sea eficaz, segura y sostenible.

Antes de extenderla, conviene evaluar cinco aspectos:

• Cómo se integra al flujo de trabajo. Se usa desde la herramienta donde ya ocurre la tarea, clínica o administrativa, sin pasos ni carga de datos adicionales.
• Qué pasa con las excepciones. Cuando la información está incompleta o el resultado es incierto, el caso se deriva a una persona con el contexto necesario para decidir.
• Cómo está diseñada la revisión humana. Está definido qué se revisa, quién lo hace y con qué profundidad, en proporción al riesgo: una recomendación clínica exige más control que la clasificación de un documento administrativo.
• Cómo se mide su efecto. Con métricas clínicas, como las reinternaciones, y operativas, como los tiempos de proceso o los reprocesos, comparadas con una línea de base definida antes del piloto y traducidas a los términos de quien aprueba el presupuesto: horas recuperadas, costo por caso.
• Con qué condiciones sale del piloto. Están definidos de antemano los resultados que habilitan la extensión y los límites de riesgo que obligan a frenarla.

Estos criterios se construyen con los equipos que van a usar la solución, que es justamente la condición que atraviesa a las tres decisiones.

La condición para que las tres decisiones se puedan tomar descansa en la capacitación de los equipos. Quienes usan la solución detectan sus excepciones; quienes la gobiernan necesitan entender qué aprueban; y la capa compartida de datos rinde cuando la institución sabe qué información circula por ella.

En la región, la capacitación continua es el habilitador más mencionado de la transformación digital (71 %), aunque buena parte de los profesionales asistenciales todavía no recibió preparación específica en estas tecnologías.³

En la práctica, eso pide un canal para reportar lo que se ve en el uso diario, formación también para quienes aprueban y supervisan, y reglas claras sobre qué información puede cargarse en herramientas de IA generativa.

Con esas tres decisiones tomadas antes del piloto, la historia de la clínica habría sido otra. Una capa compartida de datos habría traducido los códigos del laboratorio de la segunda sede y vinculado los tres identificadores de cada paciente, y las alertas no se habrían repetido. Un responsable con autoridad para pausar el modelo habría actuado apenas empezaron los desvíos, avisado por los médicos que los vieron primero. Y una línea de base con condiciones de salida le habría permitido a la dirección saber si convenía seguir.

Después del piloto esas decisiones cuestan más, y una línea de base definida a posteriori ya no es igual de confiable. Pero estancado no es lo mismo que terminado. Antes de llegar a la tercera sede, la clínica todavía puede tomarlas: asignar quién puede pausar el modelo y con qué criterios, resolver los códigos y la identidad de los pacientes en la capa compartida, y definir contra qué va a medir, por ejemplo contra la tercera sede, que todavía no lo usa, en el mismo período.

Un piloto demuestra que una solución puede funcionar en determinadas condiciones. Escalarla exige demostrar que puede integrarse, operar bajo controles definidos y sostener sus resultados en el contexto real de la institución. Esa es la distancia entre el impulso y el impacto.

Ayudar a recorrerla es lo que guía cómo construimos en UMA: tecnología pensada para interoperar desde el origen, integrarse con los sistemas que las instituciones ya usan y operar con controles acordados para cada solución, de modo que adoptarla cambie lo menos posible el trabajo diario de los equipos.

¹ Carta Healthcare, Healthcare AI Works. So Why Isn't It Scaling? (relevamiento de abril de 2026). Encuesta a directivos de salud realizada por una empresa estadounidense de datos clínicos; el informe no publica tamaño de muestra, país de los encuestados ni metodología. El 71 % de las organizaciones que reportan valor medible de la IA no está ampliando esas iniciativas al ritmo esperado. Barreras de adopción más citadas: dificultad de integración con la historia clínica electrónica (44 %), falta de respaldo de la dirección o de presupuesto (37 %) y prioridades organizacionales en competencia (33 %); la confianza de los profesionales, el costo recurrente y las preocupaciones regulatorias empatan en 26 %. Responsable de la estrategia de IA: conducción médica y asistencial (41 %), sin responsable claro (26 %), dirección ejecutiva (19 %) y área de sistemas (15 %). Lo que más aceleraría la adopción: una solución que funcione dentro de la historia clínica (48 %) y casos de otras instituciones con resultados medibles (36 %).

² Robert G. Cooper, “Why AI Projects Fail: Lessons From New Product Development”, IEEE Engineering Management Review, vol. 52, n.º 4 (2024), pp. 15–21, DOI 10.1109/EMR.2024.3419268. Identifica siete causas principales del fracaso de los proyectos de IA en las empresas, atribuibles sobre todo a malas prácticas de gestión, similares a las ya estudiadas en el desarrollo de nuevos productos, y propone adaptar las estrategias de esa disciplina.

³ Consenso Salud y Develop Consulting, Encuesta de Salud Digital en Argentina y América Latina (julio de 2025). Más de 200 profesionales del sector, el 85 % residentes en Argentina y más del 60 % en roles de dirección o gerencia. El 31 % de los encuestados de dirección media y alta afirma tener una estrategia formal de transformación digital y el 37,9 % está en proceso de desarrollarla (base reducida de respuestas); el 81,6 % usa IA generativa y el 57,3 % accede mediante versiones gratuitas individuales. Barreras más citadas: costo de implementación (52,2 %) y falta de capacitación (44,6 %); habilitador más mencionado: capacitación continua (70,7 %). El 56,3 % de los profesionales asistenciales encuestados (“profesionales clínicos” en el informe) no tiene formación formal en salud digital.

⁴ James Ryseff, Brandon F. De Bruhl y Sydne J. Newberry, The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed: Avoiding the Anti-Patterns of AI, RAND Corporation (agosto de 2024). Entrevistas semiestructuradas a 65 científicos de datos e ingenieros con al menos cinco años de experiencia (50 de la industria, incluida salud, y 15 de la academia), realizadas entre agosto y diciembre de 2023. Las cinco causas raíz identificadas en la industria: malentendidos sobre el problema a resolver o la métrica a optimizar; falta de datos adecuados; foco en la tecnología y no en el problema; infraestructura insuficiente para gestionar datos y desplegar modelos; y problemas demasiado difíciles para la IA actual. Entre sus recomendaciones: invertir de antemano en infraestructura de gobernanza de datos y despliegue de modelos.

⁵ Organización Mundial de la Salud, Ethics and governance of artificial intelligence for health: WHO guidance (2021). El primero de sus seis principios es proteger la autonomía humana: las personas deben mantener el control de los sistemas de salud y de las decisiones médicas.