Human in the Loop
Intervención humana deliberada
Human in the Loop — HITL — es el patrón de introducir intervención humana deliberada en puntos seleccionados de un proceso habilitado por AI. La intervención puede revisar, decidir, aprobar, corregir, clasificar, resolver una excepción o aportar información. Su función y sus consecuencias deben formar parte del proceso; no alcanza con que exista una persona en algún lugar de la organización.
Una aplicación puede detener una propuesta antes de ejecutarla, solicitar una elección entre alternativas o escalar un caso que no puede resolver con la información disponible. También puede incorporar revisión posterior para corregir un resultado ya producido. Esos diseños no ofrecen las mismas garantías ni tienen el mismo costo operativo.
El patrón conecta una necesidad concreta de juicio o autoridad con una intervención útil. No presupone que la persona sea infalible ni que deba participar en cada paso. Tampoco exige un agente autónomo: un workflow fijo que deriva excepciones a un operador puede implementar HITL.
HITL y Human-Agent Collaboration
Human-Agent Collaboration describe una relación amplia de trabajo entre personas y agentes: construir una interpretación del problema, compartir información, ajustar objetivos y evaluar avances. HITL describe una intervención situada dentro de un proceso. La colaboración puede contener esas intervenciones sin reducirse a ellas.
Una persona puede colaborar continuamente en una tarea sin existir un checkpoint formal de aprobación. Un workflow también puede solicitar una clasificación humana aislada sin establecer una relación de colaboración extensa. Confundir ambas cosas dificulta determinar qué decisión necesita realmente el proceso y quién tiene responsabilidad sobre ella.
El documento de colaboración mantiene su alcance de desarrollo asistido. Aquí se estudia el patrón general, aplicable a una propuesta de respuesta, una excepción operativa o una selección de alternativas. No se crea una nueva identidad para cada profesión que interviene ni se redefine el trabajo humano como una herramienta más sin autoridad propia.
Approval y Human Review
Approval es una decisión específica de autorización. Puede ser un mecanismo de HITL, pero una intervención también puede corregir un dato, aportar contexto, elegir una categoría o rechazar una premisa sin autorizar ninguna acción. Una persona que explica una ambigüedad no necesariamente concede permiso para ejecutar lo que sigue.
Agent Permissions and Approval Boundaries conserva la distinción entre autoridad, capacidad y alcance. La aplicación debe vincular una aprobación con la acción concreta y sus condiciones. Si la propuesta cambia de forma relevante, no corresponde asumir que la decisión anterior cubre automáticamente el nuevo efecto.
Human Review es una forma de intervención orientada a examinar un resultado o proceso. HITL incluye revisión, pero también otras decisiones. Una revisión puede detectar un problema sin tener autoridad para autorizar la corrección; una aprobación puede aceptar una acción sin revisar exhaustivamente todos sus aspectos técnicos.
La pregunta de revisión debe ser concreta. Comprobar identidad del destinatario, pertinencia de una respuesta y exactitud de un cálculo son trabajos distintos. Pedir «revisá que esté bien» sin delimitar expectativas puede producir una confirmación cuyo alcance nadie entiende de la misma manera. El proceso debe conservar qué se pidió comprobar y qué decisión tomó efectivamente la persona.
Estos límites deberían ser comprensibles para quien interviene. Un botón ambiguo de continuar puede mezclar reconocimiento de lectura, aceptación de contenido y autorización operativa. La aplicación necesita expresar qué decisión se solicita y qué ocurrirá después, sin trasladar al usuario la obligación de deducir efectos ocultos.
Dónde puede intervenir la persona
Antes de actuar, una persona puede revisar una propuesta o aportar un dato faltante. Durante la ejecución puede resolver una excepción o elegir una alternativa. Después de la generación puede corregir un resultado. En un checkpoint puede decidir si se continúa, cambia el objetivo o se detiene el proceso.
La intervención posterior no previene retroactivamente los efectos anteriores. Si una publicación ya ocurrió, una revisión puede detectar el error y orientar su reparación, pero no debe presentarse como aprobación previa. Elegir el momento requiere relacionar riesgo, reversibilidad y qué información estará disponible para decidir.
Tampoco es obligatorio detener todo el workflow. Puede quedar pendiente una acción mientras otras tareas independientes continúan, si el contrato lo permite. La aplicación debe conservar qué parte espera una decisión y evitar que una continuación lateral ejecute indirectamente el mismo efecto que estaba bloqueado.
Si la persona modifica la propuesta, el proceso necesita utilizar la versión corregida y mantener los controles aplicables. Registrar una edición no demuestra que el sistema la haya incorporado. La continuidad requiere relacionar intervención, estado actual y resultado efectivo de la ejecución.
Cuándo solicitar intervención
Los disparadores pueden ser sistemáticos, basados en riesgo, política, excepción, incertidumbre o solicitud humana. También puede utilizarse muestreo para observar resultados que de otro modo no se revisarían. Cada estrategia responde preguntas diferentes; no existe una política universal de frecuencia o umbral.
Una estimación de confianza puede contribuir a la decisión, pero no equivale por sí sola a riesgo ni a corrección. Un sistema puede estar seguro y equivocado, o ser incierto sobre una acción de bajo impacto. Los criterios deben relacionarse con consecuencias y evidencia, no solo con un número generado por el mismo proceso que se pretende supervisar.
La intervención sistemática puede ser adecuada para ciertos efectos y generar un cuello de botella en otros. La basada solo en excepciones depende de que el sistema pueda reconocerlas. El muestreo aporta información sobre casos observados, sin garantizar que cada caso no revisado sea correcto.
Una solicitud explícita del usuario también puede cambiar el recorrido. No debería ser necesario que el modelo declare incertidumbre para permitir corrección o escalamiento. El diseño debe reconocer que las personas pueden detectar problemas que los disparadores automáticos no identifican.
Información para decidir
Una intervención útil necesita objetivo, propuesta, evidencia pertinente, incertidumbre y consecuencias. Una pantalla que muestra solo una conclusión puede inducir aceptación sin permitir verificar sus premisas. Mostrar todo el historial tampoco garantiza comprensión: el material decisivo puede quedar oculto entre detalles irrelevantes.
Context Management puede preparar una transferencia informativa adecuada. Debe distinguir hechos comprobados, supuestos y puntos pendientes. El resumen facilita continuidad, pero puede perder excepciones; las evidencias importantes deberían ser recuperables cuando la decisión las necesite.
La persona también necesita saber qué puede cambiar. Corregir contenido, devolver el caso, pedir más información o rechazar una acción son respuestas diferentes. Si la interfaz solo permite aceptar, puede convertir una falta de alternativas en una aprobación aparente y dificultar el tratamiento de excepciones reales.
Conviene evitar explicaciones que aparenten más evidencia de la disponible. Una justificación fluida no demuestra que se consultó la fuente correcta. La revisión debe poder distinguir un resultado observado de una explicación generada sobre él. No es necesario exponer razonamiento privado para aportar hechos, referencias y límites relevantes.
Estado, espera y reanudación
El proceso debe conservar qué está pendiente, quién puede decidir y sobre qué versión. La respuesta humana puede llegar cuando los datos ya cambiaron. Antes de continuar puede ser necesario refrescar estado o comprobar que la acción sigue siendo aplicable; aprobar una propuesta antigua no actualiza sus premisas.
La falta de respuesta necesita un comportamiento definido para el caso. Puede mantenerse la espera, expirar una propuesta o escalarse por otro canal disponible. No corresponde interpretar el silencio como aprobación salvo que exista un contrato explícito y apropiado que lo establezca. El patrón no impone una regla única de timeout.
También debe evitarse ejecutar dos veces por respuestas repetidas o reanudaciones. Idempotency conserva la propiedad general relevante para efectos repetidos. Recibir una decisión humana dos veces no significa que existan dos autorizaciones para producir dos efectos equivalentes.
Agent Checkpoints and Recovery puede aportar mecanismos de continuidad en agentes. HITL no exige ese tipo de runtime, pero comparte la necesidad de distinguir estado registrado, decisión recibida y acción completada. Una marca de aprobado no constituye evidencia de ejecución exitosa.
Límites de la revisión humana
La presencia humana no garantiza corrección, seguridad, cumplimiento ni verificación suficiente. Puede haber sesgo de automatización, aceptación rutinaria, falta de tiempo, contexto insuficiente o criterios inconsistentes. Una persona puede compartir con el modelo el mismo supuesto erróneo y confirmar una conclusión equivocada.
Solicitar demasiadas intervenciones puede producir fatiga y convertir una frontera importante en un trámite. Solicitar muy pocas puede dejar consecuencias relevantes sin juicio apropiado. El diseño debe observar si las intervenciones aportan decisiones informadas, no limitarse a contar cuántos clics de aceptación ocurrieron.
Las Guidelines for Human-AI Interaction de Microsoft Research ofrecen principios de interacción para capacidades, errores y adaptación de sistemas AI. Sirven como referencia para diseñar la experiencia de intervención; no prueban que insertar una revisión humana elimine fallos.
La competencia y autoridad del participante también importan. Estar disponible no equivale a disponer de la información o atribución necesaria. Un proceso que escala sin identificar una vía real de resolución puede quedar detenido o derivar decisiones a personas que no pueden asumirlas.
HITL, Guardrails y verificación
Los controles automatizados pueden detectar una condición y solicitar intervención humana. La persona puede resolver una excepción o rechazar una acción que pasó controles automáticos. Esa composición no vuelve HITL equivalente a Guardrails: uno introduce participación humana; los otros aplican o comprueban condiciones de comportamiento y política.
Una persona tampoco reemplaza automáticamente un control técnico que debe ejecutarse en la frontera de una operación. Si se requiere impedir un efecto no autorizado, la implementación debe respetar la autoridad efectiva. Una revisión previa de texto no garantiza que la ejecución posterior conserve el mismo alcance. AI Guardrails se materializará en XIII.
La verificación pregunta qué evidencia demuestra requisitos del resultado. Puede incluir participación humana, comprobaciones automáticas o ambas. HITL determina un punto de intervención, pero no define por sí solo la suficiencia de la evidencia. Generated Code Verification desarrolla esa responsabilidad para software.
Ejemplo y trade-offs
Un sistema prepara una respuesta a una solicitud excepcional. Primero reúne condiciones y propone una alternativa. Una persona revisa si la interpretación del caso es correcta, corrige un dato y elige entre las opciones. Esa intervención es HITL aunque todavía no autorice ejecutar una modificación externa.
Si después se necesita una acción con permiso específico, debe respetarse esa frontera adicional. La aplicación presenta la propuesta actual y sus efectos a quien tenga autoridad. Si el estado del caso cambió durante la espera, la decisión debe revisarse bajo las condiciones actuales antes de continuar.
El proceso puede ganar juicio situado y capacidad para manejar excepciones, a cambio de latencia, disponibilidad humana y coordinación. Automatizar la preparación reduce trabajo mecánico, pero una propuesta demasiado convincente puede fomentar revisión superficial. Diseñar HITL requiere facilitar desacuerdo, corrección y comprensión de límites.
La implementación más simple puede ser una única intervención bien definida en un workflow convencional. Un sistema general de escalamiento, colas y roles solo se justifica cuando las necesidades reales lo requieren. Agregar personas al diagrama no resuelve una decisión mal formulada ni una responsabilidad ambigua.
Fuentes y alcance
Referencia primaria consultada el 2026-10-30: Microsoft Research, Guidelines for Human-AI Interaction, trabajo presentado en 2019. La definición del patrón y las fronteras con colaboración, autorización y verificación son síntesis del Atlas. No se prescribe una política universal de aprobación ni se materializan evaluación humana general, regulación o Guardrails.