Human-in-the-Loop: diseñar una supervisión que pueda intervenir
La aprobación necesita contexto, autoridad y una acción delimitada. Cómo diseñar la intervención humana antes, durante y después de una tarea de IA.
Human-in-the-Loop (HITL) describe la participación de personas en el desarrollo o funcionamiento de un sistema de IA. Aquí me centro en su intervención sobre propuestas y acciones durante el trabajo.
Una pantalla muestra una propuesta generada por inteligencia artificial y ofrece dos botones: «Aprobar» y «Rechazar». Hay una persona en el proceso, pero todavía no sabemos si dispone de lo necesario para supervisarlo.
Para decidir, necesita entender qué se propone, sobre qué información se basa y qué consecuencias tendrá su decisión. Necesita también tiempo, competencia y autoridad para rechazar la propuesta. Si esas condiciones faltan, la aprobación puede convertirse en un trámite.
Aprobar el texto y aprobar la acción
Pensemos en un sistema que recibe una reclamación por un cobro, consulta los datos disponibles y prepara una respuesta junto con una propuesta de devolución. La persona responsable puede considerar adecuada la redacción y, sin embargo, carecer de información para confirmar el importe o la operación afectada.
La interfaz debería mostrar los datos relevantes, la información que falta y la acción exacta que se pretende ejecutar. Una aprobación para enviar un correo no debe convertirse implícitamente en autorización para efectuar una devolución. Separar ambas decisiones permite que cada una se revise con el contexto adecuado.
El punto de control depende de las consecuencias
La intervención humana puede producirse antes de empezar, mientras el sistema trabaja, antes de una acción o después de ejecutar una tarea. Esos momentos cumplen funciones distintas. Una revisión posterior puede descubrir que se ha modificado un dato incorrecto, pero no impide que el cambio ya haya ocurrido.
Para un borrador sin efectos externos puede ser suficiente revisar el resultado. Una acción que cambia permisos, mueve dinero o afecta a una persona puede requerir autorización previa. La elección depende del impacto, de la posibilidad de revertir el cambio y de los controles disponibles, no de una única regla para todos los procesos.
La confianza declarada no es un detector de errores
Un sistema puede pedir ayuda cuando identifica incertidumbre, pero también puede presentar una respuesta incorrecta con aparente seguridad. Quizá ha omitido un documento o ha aplicado una regla que no corresponde. Por eso la supervisión no debería depender únicamente de la confianza expresada por el modelo.
Es útil combinarla con condiciones externas: el tipo de operación, los datos ausentes, los permisos, la existencia de contradicciones y los límites de importe o alcance definidos por la organización. Al derivar un caso, el sistema debe indicar qué intentaba hacer y qué necesita, en lugar de mostrar solo un error genérico.
Vincular la aprobación con la versión revisada
Entre revisar una propuesta y ejecutarla puede cambiar la información. Si una persona aprueba una modificación de matrícula y, antes de aplicarla, el expediente cambia, la autorización original puede haber dejado de ser válida. El proceso necesita asociar la aprobación con la acción y los datos que se mostraron. Un cambio material debe provocar una nueva comprobación o devolver el caso a revisión.
La aprobación tampoco debería caducar de forma ambigua. Conviene definir durante cuánto tiempo es válida, quién puede utilizarla y qué ocurre si la ejecución falla. Reintentar una acción cuyo resultado se desconoce puede duplicar sus efectos; antes de repetirla, hay que consultar el estado real. Son decisiones de la aplicación y de sus integraciones, además de instrucciones para el agente.
Una persona también puede fallar
Revisar cientos de propuestas parecidas puede generar cansancio o aceptación por inercia. Si comprobar cada caso exige buscar en varias aplicaciones y reconstruir la información, la revisión será más difícil y consumirá más tiempo.
La solución necesita diseñar el trabajo de revisión: mostrar la evidencia, facilitar correcciones, ofrecer una vía de escalado y ajustar el volumen a la capacidad disponible. Al utilizar varios agentes, el control del trabajo por lotes permite limitar la producción que espera una decisión. Las personas también cometen errores; su participación reduce determinados riesgos cuando está bien organizada, pero no garantiza por sí sola un resultado correcto.
Corregir no significa entrenar
Una persona puede editar una respuesta y resolver el caso sin que cambie el modelo. Las correcciones registradas pueden utilizarse después para evaluar resultados o mejorar instrucciones, fuentes y reglas. Emplearlas para entrenar un modelo exige un proceso específico; no ocurre automáticamente por pulsar «Aprobar».
La supervisión efectiva se reconoce por lo que permite hacer a quien revisa: comprender, modificar, rechazar o detener una acción. Esas capacidades deben formar parte del diseño del proceso desde el principio.
En educación, la evaluación con rúbricas y retroalimentación exige además comprobar qué evidencia sostiene cada juicio y cómo puede revisarse una decisión académica. Es un caso específico donde la supervisión debe diseñarse alrededor de la consecuencia para el estudiante.
Más de 22 años construyendo y evolucionando plataformas de aprendizaje en producción.
Sobre Alberto Lara y su trayectoria profesional →Seguir leyendo
- Cómo reanudar una automatización de cursos sin repetir lo que ya terminó
Un caso de recuperación para distinguir el progreso guardado de los cambios que realmente existen en la plataforma.
- Agentes de IA en paralelo: cómo controlar el trabajo por lotes
Límites de concurrencia, colas de revisión y estados por elemento para convertir la producción paralela en resultados utilizables.
- AI-first: diseñar el proceso antes que el asistente
Cómo repartir interpretación, reglas, herramientas y decisiones humanas al diseñar una solución con inteligencia artificial.