Definición en una frase
Diseño que reserva a una persona una revisión, decisión o autorización dentro de un proceso automatizado.
Definición: una intervención humana en un punto definido
Humano en el circuito, o *human-in-the-loop* (HITL), es un patrón de diseño en el que una persona participa en una etapa definida del funcionamiento de un sistema automatizado. Puede revisar información, clasificar un caso, corregir una salida, autorizar una acción o aportar feedback. El término describe la participación humana en el proceso, pero no determina por sí mismo qué tarea realiza la persona ni cuánta autoridad conserva.
Por eso, decir que un sistema es HITL no significa necesariamente que una persona examine cada entrada y cada resultado. La intervención puede limitarse a casos dudosos, ocurrir antes de una acción concreta o aportar información para una etapa posterior. Para entender el diseño hay que especificar el punto de intervención, las opciones disponibles para la persona y qué sucede con su decisión.
Las definiciones introductorias consultadas describen HITL como participación humana en el ciclo de vida del aprendizaje automático o en el funcionamiento, la supervisión y la toma de decisiones de un proceso. Son formulaciones generales, no una especificación técnica única ni una garantía de calidad.
Dónde puede intervenir una persona
La intervención puede situarse en distintas fases. En una revisión de entradas, la persona comprueba o completa datos antes de que el sistema los procese. En la revisión de salidas, evalúa una recomendación o clasificación antes de que se use. En una autorización previa, decide si se ejecuta una acción. Durante la operación, puede vigilar el proceso y actuar cuando surge una excepción. Después, su feedback puede servir para revisar reglas o preparar futuras mejoras.
Estas funciones no son intercambiables. Revisar una respuesta no equivale a tener autoridad para bloquearla; aprobar una transacción no equivale a comprobar cómo se extrajeron sus datos; y recibir una notificación no equivale a tener tiempo y capacidad para intervenir. Un diseño claro separa la tarea de la persona de la tarea automatizada y especifica qué resultado produce cada una.
También debe definirse qué pasa cuando la persona no está disponible, no responde o discrepa del sistema. Si la operación continúa automáticamente tras un plazo, esa regla forma parte del diseño. Si se detiene, debe quedar claro quién resuelve el bloqueo. Sin esas condiciones, la expresión HITL deja sin responder una parte práctica importante.
Mapa de decisiones posibles
| Punto de intervención | Qué puede hacer la persona | Qué conviene precisar |
|---|---|---|
| Antes del procesamiento | Revisar o completar una entrada | Qué datos ve y qué cambios puede guardar |
| Antes de usar una salida | Corregir, aceptar o rechazar una recomendación | Si el sistema espera la decisión o continúa |
| Antes de ejecutar una acción | Autorizar, denegar o pedir una revisión adicional | Qué autoridad tiene y cómo se registra la decisión |
| Durante una excepción | Investigar, detener o escalar un caso | Qué señales activan la intervención y quién responde |
| Después del resultado | Aportar feedback sobre el caso | Si el feedback cambia una regla, un proceso o un modelo |
Cómo funciona el ciclo de intervención
Un ciclo HITL debe poder describirse de principio a fin. Primero, el sistema identifica el caso que requiere participación humana, o presenta todos los casos si esa es la política elegida. Después, muestra a la persona la información necesaria para evaluar la situación. La persona dispone de una o varias acciones concretas. Por último, el sistema aplica, registra o deriva la decisión según unas reglas previamente definidas.
La interfaz y el contexto importan tanto como la existencia de una etapa de revisión. Si se muestra solo una puntuación sin sus límites, si faltan datos relevantes o si no se distingue con claridad una recomendación de una decisión ya tomada, la persona puede no estar en condiciones de evaluar el caso. El diseño debería permitir entender qué se propone, qué está pendiente y qué consecuencias tendrá aceptar o rechazar.
Una implementación técnica puede pausar una ejecución hasta recibir una decisión humana. Por ejemplo, la documentación de LangChain describe un mecanismo que puede detener llamadas a herramientas y esperar una decisión. Ese mecanismo ilustra una forma concreta de incorporar una pausa; no establece una definición universal de HITL ni demuestra por sí solo que la revisión sea adecuada para cualquier proceso.
Proceso que conviene documentar
- 01Definir qué evento activa la intervención: todos los casos, una excepción o un umbral establecido.
- 02Indicar qué información recibe la persona y qué elementos pueden faltar o ser inciertos.
- 03Enumerar las acciones permitidas: aceptar, corregir, rechazar, escalar, detener o revertir.
- 04Explicar qué hace el sistema después de cada acción y qué ocurre si no hay respuesta.
- 05Registrar quién tomó la decisión, cuándo la tomó y qué información tenía disponible.
Tres ejemplos aplicados
Los siguientes escenarios son ejemplos de diseño, no afirmaciones sobre el funcionamiento de un servicio concreto. En cada uno se separa la labor automatizada de la decisión que conserva una persona. Esa separación permite comprobar si la intervención es sustantiva o si solo existe una posibilidad formal de escalar un caso.
blocks
Conceptos próximos que conviene distinguir
HITL se usa como etiqueta amplia para la participación humana en un proceso. No conviene tratarla como sinónimo automático de supervisión humana en sentido regulatorio. La supervisión puede tener requisitos específicos según el contexto y el marco aplicable; las fuentes aquí consideradas no bastan para describir obligaciones legales concretas. Por tanto, esta ficha explica un patrón de diseño, no determina cumplimiento normativo.
También se usan expresiones como *human-on-the-loop* para describir una persona que observa el funcionamiento y puede intervenir, y *human-out-of-the-loop* para un proceso que opera sin una intervención humana individual en esa fase. Estas etiquetas son útiles como contraste general, pero su uso no es uniforme: en una implementación real, es más preciso describir acciones, autoridad y momento que confiar solo en el nombre del patrón.
La intervención en producción debe separarse del feedback empleado para desarrollar o ajustar un modelo. En RLHF —aprendizaje por refuerzo a partir de feedback humano— la participación humana se utiliza durante un proceso de entrenamiento o ajuste. Que personas hayan proporcionado feedback en esa etapa no implica que una persona revise cada decisión del sistema cuando está en uso. A la inversa, una persona puede intervenir en producción sin que su decisión se use para entrenar un modelo.
El aprendizaje activo también es distinto: designa, en términos generales, una estrategia para seleccionar ejemplos que podrían beneficiarse de etiquetado o revisión. Esa selección puede incluir a personas, pero no determina por sí sola quién tiene autoridad sobre una acción operativa. Las fuentes verificadas para esta ficha no ofrecen una comparación técnica detallada de aprendizaje activo y RLHF; estas distinciones deben leerse como orientación conceptual, no como taxonomía completa.
No confundir la presencia humana con la función humana
| Concepto | Pregunta que responde | Lo que no permite concluir por sí solo |
|---|---|---|
| HITL | ¿En qué punto participa una persona? | Que revise cada caso o tenga autoridad suficiente |
| Supervisión humana | ¿Cómo se supervisa un sistema y bajo qué condiciones? | Que exista un único modelo aplicable a todos los contextos |
| RLHF | ¿Se usa feedback humano en una fase de entrenamiento o ajuste? | Que haya revisión humana de cada salida en producción |
| Aprendizaje activo | ¿Qué ejemplos se seleccionan para revisión o etiquetado? | Que la persona autorice acciones del sistema |
Límites y errores frecuentes
Una etapa humana no garantiza por sí misma que el sistema sea seguro, preciso, eficaz o conforme a una norma. Para detectar un problema, una persona necesita información pertinente, tiempo, conocimientos adecuados y autoridad para actuar. Si falta alguno de esos elementos, la intervención puede existir en el diagrama del proceso sin funcionar como una comprobación efectiva.
Un riesgo de diseño es asumir que la persona detectará cualquier error porque puede revisar una recomendación. Puede faltarle contexto, estar atendiendo demasiados casos o no disponer de una opción clara para rechazarla. También puede existir presión para aceptar la salida automatizada o una ruta de escalado que no conduce a una resolución. Estos son límites posibles que deben evaluarse en cada entorno; las fuentes consultadas no aportan una medición de su frecuencia ni permiten cuantificar su efecto.
Otro error es usar la revisión como etiqueta general sin indicar su alcance. «Hay una persona en el circuito» no aclara si ve todos los casos, solo excepciones o una muestra; si revisa antes o después de actuar; ni quién responde por una decisión. Tampoco aclara cómo se corrige una salida equivocada o si una acción puede revertirse.
Por último, debe evitarse confundir supervisión con aprobación. Una persona que puede observar una pantalla, pero no detener una acción, tiene una función distinta de quien debe autorizarla. Del mismo modo, una persona disponible para recibir una escalada no equivale a una persona asignada, informada y con capacidad para resolverla.
Criterios prácticos para describir un diseño HITL
Para evaluar o documentar un sistema, describa el punto exacto en el que interviene la persona y qué acontecimiento activa esa intervención. Indique si la participación es obligatoria, selectiva o posterior a la acción. Si solo se revisan excepciones, explique cómo se identifican y qué casos pueden quedar fuera de la revisión.
Especifique qué información ve la persona, qué opciones puede ejercer y qué autoridad respalda esas opciones. Una recomendación que puede aceptarse, corregirse o rechazarse requiere controles distintos de una alerta que solo puede reconocerse. También conviene señalar quién puede detener el proceso, pedir una segunda revisión o revertir una acción.
Describa qué ocurre si la persona no responde, no está disponible o discrepa del sistema. Defina los tiempos de respuesta pertinentes al proceso, sin asumir que un plazo único sirve para cualquier contexto. Registre decisiones y cambios de forma que puedan reconstruirse: quién intervino, sobre qué información y con qué resultado.
En conjunto, una descripción útil responde a seis preguntas: dónde interviene la persona; qué ve; qué decide; qué puede cambiar; qué sucede ante una excepción o falta de respuesta; y cómo se revisa si el mecanismo funciona como se esperaba. Estas preguntas hacen explícitas las responsabilidades que la etiqueta por sí sola deja abiertas.
Lista breve de evaluación
- 01Punto: ¿en qué fase del proceso se produce la intervención?
- 02Contexto: ¿qué información y limitaciones se muestran a quien revisa?
- 03Autoridad: ¿puede corregir, rechazar, autorizar, detener o revertir?
- 04Excepciones: ¿qué sucede ante una discrepancia o una falta de respuesta?
- 05Trazabilidad: ¿queda constancia de la decisión y de su resultado?
- 06Evaluación: ¿qué evidencia permitiría comprobar si la revisión cumple su objetivo?
Alcance de las fuentes
Las fuentes verificadas para esta ficha incluyen explicaciones generales de HITL, una publicación institucional sobre mecanismos de intervención y documentación técnica de un mecanismo concreto que pausa llamadas a herramientas a la espera de una decisión humana. Sus alcances son distintos: una definición introductoria no equivale a una norma, y la documentación de un producto no establece cómo deben diseñarse todos los sistemas.
No se ha aportado una fuente regulatoria que permita resumir obligaciones legales específicas, ni evidencia que mida la eficacia de los ejemplos hipotéticos o la incidencia de los riesgos descritos. Por eso, la ficha no afirma que un diseño HITL satisfaga requisitos regulatorios ni que la participación humana produzca por sí sola mejores resultados. Las categorías y ejemplos sirven para formular preguntas de diseño que deben resolverse con evidencia adecuada al contexto.
