Una de las revisiones sistemáticas más citadas sobre herramientas de IA para clínicos señala que su adopción ha sido más lenta de lo esperado, en buena parte porque los marcos de evaluación disponibles privilegian métricas técnicas como la exactitud y la validación, y pasan por alto el impacto clínico, la integración en el flujo de trabajo y la sostenibilidad económica (Jacob et al., 2025). El diagnóstico se extiende a cualquier tecnología sanitaria: un sistema puede ser técnicamente impecable y aun así llegar a producción sin dueño clínico, sin adopción y sin que nadie mida si hace más bien que daño.
Este artículo no vuelve sobre la tesis de que la transformación digital es un cambio de modelo. Parte de ahí y baja a la ejecución: cómo se conduce un proyecto concreto —un portal, un módulo de agenda, una herramienta de IA desde la idea hasta la decisión de escalarlo o retirarlo, con las puertas de decisión, los responsables y la evidencia que cada paso debería exigir.
Por qué los proyectos clínicos fallan después de la compra
El patrón se repite en instituciones de todos los tamaños. La decisión de compra la toma un comité administrativo; la configuración, el área de sistemas; la capacitación, el proveedor, durante dos o tres sesiones. Nadie del servicio clínico firmó una hipótesis de valor, nadie definió qué resultado haría fracasar el proyecto y nadie quedó encargado de vigilar los efectos adversos después del arranque. La tecnología funciona, la adopción es parcial, y a los seis meses coexisten el sistema nuevo y la planilla anterior.
La Organización Mundial de la Salud lo aborda desde la gobernanza. Su documento de discusión de junio de 2026 sobre IA en políticas de salud basadas en evidencia recomienda, antes de desplegar herramientas, evaluaciones de impacto algorítmico y revisiones de preparación tecnológica; una vez en uso, flujos de verificación humana, puntos de decisión con intervención humana y paneles de supervisión multidisciplinarios que combinen experiencia en el dominio, métodos y ética. El principio que los une es que la IA debe aumentar la capacidad humana y no automatizarla (OMS, 2026). Aunque el texto se refiere a la IA, su lógica se traslada con pocos ajustes a cualquier tecnología que afecte decisiones o procesos clínicos.
Puerta 0: un caso de uso con hipótesis de valor y de daño
Todo proyecto debería abrirse con una página, no con una cotización. Debe responder cinco preguntas: qué problema concreto resuelve, para qué servicio y qué población, quién es el dueño clínico que responderá por el resultado, qué indicador cambiaría si funciona y qué indicador empeoraría si funciona mal. La segunda mitad es la que casi siempre falta. Una hipótesis de valor sin hipótesis de daño produce proyectos que miden el beneficio esperado y no vigilan el riesgo.
Un ejemplo ilustrativo en imagenología: un portal de resultados con liberación automática. La hipótesis de valor puede ser reducir las llamadas administrativas para obtener resultados; la de daño, un aumento de consultas ansiosas por hallazgos mal comprendidos o accesos indebidos. Con ambas escritas, el piloto sabe qué medir desde el primer día.
Puerta 1: comité clínico y mapa del flujo actual
La literatura sobre gobernanza de IA en organizaciones de salud converge en la necesidad de equipos multidisciplinarios. El marco de personas, procesos, tecnología y operaciones (PPTO), publicado en npj Digital Medicine en 2026 y construido a partir de la experiencia de sistemas como Duke Health, insiste en incluir clínicos que atienden pacientes, especialistas en ética, expertos regulatorios y líderes operativos (npj Digital Medicine, 2026a). Una IPS mediana no necesita cuatro comités: necesita una mesa pequeña con un clínico responsable, un representante de calidad, un responsable de datos y protección de información, una persona de operaciones y alguien de TI, con reuniones cortas y actas.
Esa mesa recibe, antes de cualquier configuración, el mapa del flujo actual: quién hace qué, cuánto tarda, dónde se pierde información y cómo se ve hoy el indicador de valor. Sin línea base no hay forma de saber, seis meses después, si el cambio ayudó.
Puerta 2: evaluación previa de riesgo, equidad y preparación
La evaluación previa no tiene que ser un expediente de cien páginas, pero sí debe documentar al menos cuatro cosas: qué datos usa el sistema y de dónde provienen, a quiénes puede perjudicar o dejar fuera, qué decisiones humanas conserva el profesional y qué infraestructura necesita para operar bien. Para herramientas con componente de IA, esa evaluación incluye el desempeño por subgrupos de población y la forma en que el modelo se comporta ante datos distintos a los de su entrenamiento, un punto que los marcos recientes de monitoreo continuo asocian con la deriva de los modelos tras el despliegue (npj Digital Medicine, 2025).
La escala debe ser proporcional. Una revisión sistemática de 35 marcos de implementación de IA en salud publicados entre 2019 y 2024 identificó siete dominios críticos de gobernanza y advirtió que muchos marcos asumen recursos amplios, lo que deja en desventaja a organizaciones pequeñas; a partir de esa revisión se propuso un modelo de madurez de cinco niveles que ajusta las exigencias a los recursos disponibles (npj Digital Medicine, 2026b). Para una IPS colombiana, eso significa empezar por el nivel que puede sostener, con un inventario de las herramientas automatizadas en uso y su nivel de riesgo, antes que adoptar un esquema que nunca se aplicará.
Puerta 3: piloto con criterios de salida definidos antes de empezar
El piloto es un experimento y no una versión suave del lanzamiento. Debe tener un alcance acotado (un servicio, una sede o un turno), una duración definida, un grupo de usuarios entrenados y, sobre todo, criterios de salida escritos antes de empezar: qué resultado autoriza el escalamiento, cuál obliga a corregir y cuál detiene el proyecto. Cuando esos criterios se redactan después, los datos se interpretan a favor de lo que ya se decidió.
Durante el piloto, tres prácticas separan los proyectos que aprenden de los que solo acumulan tiempo: registrar incidentes y cuasi incidentes con un canal simple de reporte, sostener una revisión semanal corta con el dueño clínico y comparar los indicadores contra la línea base de la puerta 1. La capacitación se evalúa por comportamiento observado —si el equipo usa la herramienta como se diseñó y si encuentra atajos riesgosos—, no por asistencia a sesiones.
Puerta 4: escalar con una condición, o retirar sin culpa
La mayoría de los marcos describen cómo adoptar; muy pocos describen cómo retirar. Sin embargo, el retiro es una decisión legítima de gobernanza: una herramienta que no cumple los criterios de salida debe ajustarse, pausarse o retirarse, y esa decisión no es un fracaso personal del equipo sino el resultado esperado de un piloto bien diseñado. Escalar, por su parte, debería depender de que el piloto cumpla los criterios, de que exista un plan de monitoreo posdespliegue con responsables y de que el soporte, la capacitación y la gestión de cambios estén dimensionados para el nuevo volumen.
La siguiente tabla resume las puertas como herramienta de trabajo para la mesa clínica.
| Puerta | Pregunta central | Evidencia mínima | Decide |
|---|---|---|---|
| 0. Caso de uso | ¿Qué problema resuelve y qué daño podría causar? | Hoja de caso con hipótesis de valor y de daño, y dueño clínico | Dirección médica |
| 1. Preparación | ¿Conocemos el flujo actual y quién responde? | Mapa del flujo, línea base e integrantes de la mesa clínica | Mesa clínica |
| 2. Evaluación previa | ¿A quién podría perjudicar o dejar fuera, y estamos listos? | Evaluación de riesgo y equidad; revisión de datos y de integraciones | Mesa clínica y protección de datos |
| 3. Piloto | ¿Funciona en nuestro entorno, con nuestros pacientes? | Indicadores contra línea base, incidentes y observación de uso | Dueño clínico |
| 4. Escalar o retirar | ¿Se cumplen los criterios de salida? | Informe del piloto y plan de monitoreo posdespliegue | Gerencia y dirección médica |
Infraestructura de gestión: portafolio, cambios, observabilidad e integraciones
Un proyecto aislado se puede manejar con una hoja de cálculo; cinco proyectos simultáneos, no. Una IPS que digitaliza en varios frentes necesita un portafolio visible que muestre en qué puerta está cada iniciativa, un proceso de gestión de cambios que evite modificar configuraciones críticas sin aviso a los servicios afectados y un catálogo de integraciones que documente qué sistema habla con cuál, con qué estándar y quién es el responsable. En imagenología, ese catálogo incluye el RIS, el PACS, el portal, la facturación y la historia clínica. La observabilidad —alertas y tableros que muestren fallos de integración, colas detenidas o mensajes rechazados— permite detectar problemas antes de que el usuario los reporte.
Marco regulatorio colombiano: datos y interoperabilidad desde el diseño
En Colombia, cualquier proyecto clínico que trate datos de salud debe considerar desde la puerta 0 la Ley 1581 de 2012 y sus normas reglamentarias, que obligan a definir finalidades, responsables y encargados, y las reglas de la historia clínica electrónica interoperable, incluido el Resumen Digital de Atención. Esto cambia el orden de las preguntas: antes de elegir una herramienta hay que saber qué datos tocará, dónde se almacenarán, qué proveedor actuará como encargado del tratamiento y cómo se integrará con la historia clínica. Dejar estas preguntas para la etapa de implementación es la forma más frecuente de descubrir que el proyecto no puede entrar en producción sin rehacerlo.
Lo que debería ver una gerencia antes de aprobar el siguiente proyecto
Tres documentos de una página cada uno bastan para ordenar la conversación: la hoja de caso de uso con sus hipótesis de valor y de daño, los criterios de salida del piloto y el plan de monitoreo posdespliegue con un responsable nombrado. Si el proveedor o el área solicitante no pueden completarlos, el proyecto aún no está listo para comprarse. La pregunta que más protege a una institución no es cuánto cuesta la licencia, sino bajo qué evidencia se dejaría de usar.
Conozca las soluciones de Medilab Sistemas
Medilab Sistemas acompaña la adopción de sus plataformas con un enfoque de implementación por etapas: definición del caso de uso con el servicio clínico, línea base de indicadores, piloto acotado y seguimiento posterior. Si su institución quiere estructurar la mesa clínica y los criterios de salida antes de implementar un nuevo módulo, el equipo de Medilab puede acompañar ese diseño. Siga en contacto con nosotros y con gusto le contamos sobre nuestras soluciones.
