En salud, human-in-the-loop (HITL) se usa mucho… y se entiende poco. A veces se reduce a “que lo valide un médico” y listo. En la práctica, HITL es otra cosa: es el diseño operativo que define cuándo y cómo interviene una persona, con responsabilidades claras, evidencia trazable y mecanismos para evitar riesgos típicos como la sobreconfianza en la automatización.
Si estás evaluando IA para un hospital, una red de atención primaria (APS) o un programa de tamizaje (por ejemplo, retinopatía diabética), este artículo te deja un marco simple para separar marketing de implementación real.
Qué es human-in-the-loop (y qué NO es)
HITL significa que el sistema está diseñado para que decisiones críticas no queden “cerradas” por la IA, sino que pasen por un circuito humano definido: captura, verificación, priorización, revisión, informe y seguimiento.
No es HITL cuando: - El humano solo “firma” sin ver evidencia. - No hay criterios de escalamiento (todo va o nada va). - No se registra quién decidió, con qué información y bajo qué versión del modelo. - La IA se integra de forma que empuja a aceptar por defecto (riesgo de automation bias).
La literatura describe automation bias como la tendencia a sobreconfiar en recomendaciones automáticas, incluso cuando están equivocadas, especialmente bajo carga de trabajo o presión de tiempo (revisión sistemática disponible en PubMed Central).
Los 3 “loops” que importan en IA clínica
En implementación real, HITL no es un único paso: son tres bucles complementarios.
1) Loop de operación (el de todos los días)
Define qué pasa con cada caso: - Quién captura el estudio (técnico, enfermería, etc.). - Qué valida la IA (por ejemplo, calidad de imagen o triage). - Quién decide el siguiente paso (derivar, informar, repetir captura, etc.). - Qué tiempos se esperan (SLA internos).
En programas de retina, este loop es clave porque el cuello de botella suele ser oftalmología: HITL bien hecho protege horas médicas sin degradar seguridad clínica.
2) Loop de seguridad y riesgo (antes y después del go-live)
Incluye: - análisis de riesgos (qué puede fallar y cómo se controla), - pruebas planificadas, - validación clínica, - planes de contingencia.
Organismos y marcos regulatorios insisten en pensar la IA en el ciclo de vida completo (no solo en el piloto). Como referencia práctica, podés revisar:
- Principios de Good Machine Learning Practice (GMLP) para dispositivos médicos basados en IA/ML (FDA): https://www.fda.gov/medical-devices/software-medical-device-samd/good-machine-learning-practice-medical-device-development-guiding-principles
- Documento de principios GMLP (PDF): https://www.fda.gov/media/153486/download
- Guía ética y de gobernanza en IA para salud (OMS/WHO): https://www.who.int/publications/i/item/9789240029200
- Evaluación clínica de SaMD (IMDRF): https://www.imdrf.org/sites/default/files/docs/imdrf/final/technical/imdrf-tech-170921-samd-n41-clinical-evaluation_1.pdf
3) Loop de mejora continua (monitoreo en producción)
La IA cambia en su performance por múltiples razones: cambios de población, cámaras nuevas, protocolos distintos, etc. HITL maduro exige: - métricas de performance y de proceso, - revisión de errores (incluyendo falsos negativos), - monitoreo de deriva, - y gobierno de cambios (qué se actualiza, cuándo, cómo se comunica).
Para gestión de riesgos de IA más allá de salud, el NIST AI Risk Management Framework es un buen marco transversal: https://www.nist.gov/itl/ai-risk-management-framework
Patrones de diseño HITL que funcionan (con ejemplos concretos)
Patrón A: “IA filtra, humano confirma”
Útil cuando el costo del error es alto. - La IA prioriza o sugiere. - Un profesional confirma los casos relevantes. - Se documenta el razonamiento mínimo (no “aprobado” sin evidencia).
Ejemplo en retina: IA para identificar casos de riesgo y derivar a revisión oftalmológica, mientras los casos sin hallazgos claros se gestionan con reglas clínicas definidas (siempre con política de escalamiento ante incertidumbre).
Patrón B: “IA asiste captura + control de calidad”
Muchas fallas no son “de diagnóstico”: son de calidad de dato. - La IA guía al operador para capturar mejor. - Si la imagen no es útil, se repite en el momento. - Se reduce la tasa de “estudios no gradables”.
Este patrón se apoya en procesos de usabilidad y seguridad de uso: la FDA tiene una guía clásica sobre human factors aplicados a dispositivos médicos (muy aplicable a software clínico): https://www.fda.gov/regulatory-information/search-fda-guidance-documents/applying-human-factors-and-usability-engineering-medical-devices
Patrón C: “Doble escalamiento: incertidumbre + contexto”
No todo se decide por un score. - Si la IA está insegura → escala. - Si hay factores de contexto (síntomas, comorbilidades, antecedente) → escala, aunque el score sea bajo. - Si hay discordancia humano vs IA → segunda lectura o auditoría.
Checklist operativo: qué pedir en una demo para saber si es HITL real
Usá estas preguntas en compras / evaluación:
1) Roles y permisos: ¿quién puede capturar, revisar, informar, auditar?
2) Umbrales y escalamiento: ¿qué dispara revisión humana (incertidumbre, calidad, hallazgo)? ¿Es configurable?
3) Evidencia y trazabilidad: ¿queda registro de quién decidió, cuándo, con qué versión del modelo y qué datos?
4) Manejo de errores: ¿cómo se reporta un caso mal priorizado? ¿hay circuito de mejora?
5) Integración al flujo: ¿reduce trabajo o lo aumenta? (ojo con alertas excesivas y fatiga)
6) Validación clínica: ¿qué evidencia pública muestran? ¿en poblaciones comparables a LATAM?
7) Monitoreo en producción: ¿tienen tablero de métricas? ¿cómo detectan deriva?
Cómo se aplica HITL en Retinar (teleoftalmología para retina)
Retinar fue diseñado desde el inicio con un enfoque HITL “operable” en campo, pensado para Argentina y Latinoamérica, donde hay alta demanda, recursos especializados limitados y heterogeneidad de equipamiento.
En términos prácticos:
- Captura descentralizada + asistencia: el estudio puede capturarse en APS o campañas, con un flujo que busca minimizar recapturas y asegurar calidad.
- Prediagnóstico por IA para priorización: la IA ayuda a identificar casos de riesgo y acelerar derivación, pero el circuito está pensado para que el especialista concentre su tiempo donde agrega valor.
- Revisión profesional y trazabilidad: los casos que requieren confirmación pasan a informe remoto, con registro del flujo (quién revisó y qué se decidió).
- Compatibilidad multi-cámara: en programas reales, HITL también implica adaptarse al parque instalado sin romper el proceso.
Si tu objetivo es implementar tamizaje de retinopatía diabética y/o riesgo de glaucoma sin saturar oftalmología, este enfoque permite operar con seguridad clínica y previsibilidad operativa, evitando el “piloto eterno”.
Cierre: HITL no es una feature, es un sistema de trabajo
Cuando HITL está bien implementado: - baja la fricción operativa, - sube la confianza clínica, - mejora la calidad del dato, - y vuelve escalable un programa (especialmente en tamizaje).
Cuando está mal implementado: - aumenta el riesgo de sobreconfianza, - crea cuellos de botella nuevos, - o genera “aprobaciones automáticas” sin evidencia.
CTA: llevemos esto a un piloto real
¿Querés ver un ejemplo concreto de HITL aplicado a teleoftalmología en terreno (APS, campañas o redes privadas) y con métricas operativas claras?
Contactanos y coordinamos una demo de Retinar para evaluar tu flujo, tu equipamiento y un plan de implementación por etapas:
- Formulario de contacto en la web
- O escribinos para armar un piloto en tu institución