flowchart LR
A[IA prepara propuesta] --> B[Humano revisa]
B --> C{¿Aprueba?}
C -- Sí --> D[Enviar al proveedor]
C -- No --> E[Corregir / detener]
Human-in-the-loop
Cómo diseñar revisión, aprobación, escalamiento y manejo de excepciones para que la intervención humana sea un control efectivo y no una formalidad.
En la página anterior distinguimos workflows humanos, asistidos por IA y parcialmente automatizados.
Esa clasificación nos mostró que no existe una única respuesta a la pregunta:
¿Cuánto trabajo debe ejecutar automáticamente el sistema?
Pero al introducir automatización aparece inmediatamente otra pregunta:
¿Dónde debe intervenir una persona?
Una respuesta habitual es decir:
“No hay problema: tendremos human-in-the-loop.”
La frase parece suficiente hasta que intentamos convertirla en un proceso real.
¿La persona interviene antes de ejecutar una acción o después?
¿Revisa todas las salidas o sólo algunas?
¿Debe aprobar?
¿Puede detener el proceso?
¿Recibe la evidencia necesaria?
¿Qué ocurre si discrepa?
¿Quién resuelve una excepción?
¿Queda registro de su decisión?
Si no podemos contestar esas preguntas, todavía no hemos diseñado control humano. Sólo hemos declarado que existe una persona en alguna parte del sistema.
Idea central
Human-in-the-loop no significa simplemente “hay un humano”.
Significa diseñar puntos concretos en los que una persona puede revisar, aprobar, escalar o resolver excepciones con información y autoridad suficientes para afectar realmente el resultado.
El humano como parte de la arquitectura del proceso
En un workflow simple podemos tener:
IA analiza
↓
humano revisa
↓
sistema continúaPero esa representación todavía es demasiado general.
Necesitamos saber qué función cumple la intervención humana.
No es lo mismo:
revisar si la extracción es correctaque:
aprobar una excepción contractualTampoco es lo mismo:
revisar una muestra de tareas una semana despuésque:
detener una acción antes de que llegue al proveedorEl material del curso distingue tres modelos temporales especialmente útiles:
| Modelo | Cuándo interviene la persona | Ejemplo |
|---|---|---|
| Aprobación previa | antes de ejecutar una acción | enviar propuesta al proveedor |
| Supervisión por umbral | cuando se supera una condición de riesgo | excepción de responsabilidad, datos sensibles |
| Revisión posterior | después de la ejecución, por muestreo o auditoría | tareas rutinarias de baja criticidad |
Esta clasificación no reemplaza las cuatro funciones centrales del nodo —revisión, aprobación, escalamiento y excepciones—. Nos ayuda a entender en qué momento puede aparecer cada una.
1. Revisión: comprobar la calidad de un resultado
La revisión responde principalmente:
¿El trabajo producido es suficientemente correcto, completo y verificable para continuar?
Supongamos que una aplicación de IA prepara esta matriz:
| Cláusula | Hallazgo | Riesgo | Evidencia |
|---|---|---|---|
| 8.2 | uso amplio de datos | alto | extracto contractual |
| 12.1 | suspensión unilateral | medio | extracto contractual |
| 15.4 | limitación de responsabilidad | medio | extracto contractual |
Una revisión humana puede comprobar:
- que las cláusulas existen;
- que el texto citado corresponde al documento correcto;
- que no se omitió una excepción relevante;
- que la clasificación tiene fundamento;
- que no se mezcló información contextual con evidencia contractual;
- que existen antecedentes suficientes para continuar.
La revisión no adopta necesariamente la decisión final.
Su función puede ser simplemente validar el producto de una etapa.
Revisar no es rehacer todo el trabajo
Un diseño ineficiente sería:
IA revisa contrato durante 30 minutos
↓
abogado vuelve a revisar desde cero durante 30 minutosEn ese caso, la automatización puede haber agregado muy poco.
Una revisión bien diseñada intenta concentrar la atención humana allí donde agrega valor.
Por ejemplo, el sistema puede mostrar:
texto original
+
hallazgo
+
criterio aplicado
+
clasificación
+
incertidumbreLa persona no necesita reconstruir todo el proceso para verificar cada punto.
Eso exige que la salida sea revisable por diseño.
La evidencia condiciona la calidad de la revisión
Comparemos dos interfaces.
Primera:
RIESGO ALTO
La cláusula de datos es problemática.
[ Aprobar ]Segunda:
HALLAZGO
El proveedor puede utilizar información derivada del servicio para mejorar sus productos.
EVIDENCIA
Cláusula 8.2: [fragmento]
CRITERIO INTERNO
Uso secundario de datos debe estar delimitado.
EVALUACIÓN
La redacción no aclara suficientemente qué información puede reutilizarse.
INCERTIDUMBRE
Falta confirmar definición de “Usage Data”.
[ Confirmar hallazgo ] [ Corregir ] [ Solicitar información ]La segunda configuración hace posible una intervención humana mucho más sustantiva.
La persona puede ver qué está validando.
Revisión completa y revisión por muestreo
No todas las tareas necesitan revisión individual.
Podemos distinguir:
Revisión completa
Cada resultado pasa por una persona.
Útil cuando:
- la criticidad es alta;
- la tarea es nueva;
- el sistema todavía no está suficientemente evaluado;
- el error es difícil de revertir;
- la decisión tiene consecuencias materiales.
Revisión por muestreo
Sólo una proporción de los resultados se revisa posteriormente.
Puede ser razonable para tareas estables y de menor impacto.
Por ejemplo:
extracción automática de metadatos
↓
95 % se procesa directamente
↓
5 % se audita aleatoriamenteEl porcentaje concreto dependerá del caso. La idea importante es que human-in-the-loop no exige necesariamente revisar manualmente cada ejecución.
2. Aprobación: autorizar que el proceso avance
La aprobación responde una pregunta distinta:
¿Está autorizado el siguiente paso?
Supongamos que la revisión ya terminó correctamente.
Tenemos:
hallazgos validados
+
documentación completa
+
excepciones identificadasTodavía puede faltar una decisión:
¿puede enviarse esta posición al proveedor?O:
¿puede aceptarse esta excepción?O:
¿puede firmarse el contrato?La aprobación no es simplemente otra revisión de calidad.
Es un acto de autorización dentro del proceso.
Revisión y aprobación no son equivalentes
Podemos expresarlo así:
REVISIÓN
¿el análisis está suficientemente bien hecho?
APROBACIÓN
¿está permitido avanzar con esta decisión o acción?Una persona puede tener capacidad para revisar y no autoridad para aprobar.
Por ejemplo:
- un analista jurídico puede verificar la matriz;
- un abogado senior puede validar una posición;
- un gerente o comité puede tener autoridad para aceptar una excepción económica relevante.
El workflow debe representar esas diferencias.
Aprobación previa
Cuando una acción es significativa o difícil de revertir, puede ser razonable exigir aprobación antes de ejecutarla.
Por ejemplo:
La posición del control es esencial.
Si el sistema primero envía y después pide aprobación, la persona ya no está autorizando la acción. Está auditando algo que ocurrió.
La irreversibilidad como criterio de diseño
No todas las acciones tienen el mismo costo de corrección.
Comparemos:
crear borrador internocon:
enviar aceptación contractualO:
proponer un cambio en una planillacon:
eliminar un registroCuanto más irreversible, externo o jurídicamente significativo sea el efecto, más fuerte es la razón para colocar el control antes de la acción.
No es una regla absoluta. Es un criterio de diseño.
3. Escalamiento: trasladar un asunto fuera de la ruta ordinaria
Un proceso bien diseñado necesita saber qué ocurre cuando un caso excede la autoridad o los criterios de la ruta normal.
Ahí aparece el escalamiento.
Escalar significa transferir el asunto a una persona, rol o instancia con capacidad para resolver una situación que el nivel ordinario no debe cerrar por sí solo.
Por ejemplo:
desviación dentro de estándar
→ continuar
fallback autorizado
→ continuar con registro
excepción fuera de estándar
→ escalarEl escalamiento evita dos extremos.
Escalar todo
Si cada diferencia menor llega al socio, gerente o comité, el proceso se vuelve lento y costoso.
No escalar nada
Si quien ejecuta el workflow puede resolver cualquier desviación, puede terminar aceptando riesgos fuera de su autoridad.
El playbook posterior ayudará a definir mejor esas fronteras.
Por ahora necesitamos entender el escalamiento como un control de autoridad.
Un escalamiento necesita información suficiente
Este mensaje es un mal escalamiento:
Tenemos un problema con el contrato.
¿Qué hacemos?Una estructura mejor podría contener:
ASUNTO
Cláusula de responsabilidad.
POSICIÓN PREFERIDA
Cap equivalente a 12 meses de fees.
POSICIÓN DEL PROVEEDOR
Cap equivalente a 3 meses.
FALLBACK AUTORIZADO
6 meses.
RESULTADO DE NEGOCIACIÓN
Proveedor rechaza el fallback.
IMPACTO
Servicio crítico con acceso a datos de clientes.
DECISIÓN SOLICITADA
Aceptar 3 meses / continuar negociando / rechazar.El decisor recibe el contexto necesario.
El escalamiento se convierte en una tarea bien formada, no en una transferencia de incertidumbre.
El escalamiento también necesita una ruta de regreso
Supongamos que un comité aprueba la excepción.
¿Qué ocurre después?
El workflow debería saber:
ESCALADO
↓
excepción aprobada
↓
volver a NEGOCIACIÓN o APROBACIÓN
↓
registrar decisiónSi no existe ruta de regreso, el escalamiento puede convertirse en un “agujero negro” operacional.
4. Excepciones: cuando el proceso ordinario no puede continuar
Una excepción aparece cuando el caso no puede seguir la ruta prevista de manera normal.
Puede tener muchos orígenes.
Excepción documental
falta el DPAExcepción técnica
no se pudo acceder al repositorioExcepción jurídica
el proveedor rechaza una cláusula obligatoriaExcepción organizacional
la persona con facultad de aprobación no está disponibleExcepción de clasificación
el servicio no encaja en ninguna categoría previstaLa excepción no es necesariamente un “error del sistema”.
Es una situación en la que la ruta normal ya no proporciona una respuesta suficiente.
Excepción y error no son lo mismo
Un error puede ser:
el sistema falló al abrir el PDFUna excepción puede ser:
el contrato contiene una estructura que el procedimiento ordinario no contemplaAmbos requieren tratamiento, pero no necesariamente el mismo.
Una arquitectura madura distingue:
FALLO TÉCNICO
reintentar / usar alternativa / soporte
INFORMACIÓN FALTANTE
solicitar / esperar
EXCEPCIÓN DE NEGOCIO
escalar / decidirSi todo se representa como ERROR, perdemos información sobre qué hacer.
La capacidad de detenerse también es una capacidad
Una de las propiedades más importantes de un proceso controlado es poder decir:
NO PUEDO CONTINUAR CON BASE SUFICIENTEPor ejemplo:
No se encontró el DPA requerido.
Estado: PENDIENTE_DE_DOCUMENTACIÓN.
No se solicitará aprobación hasta recibirlo.Éste es un comportamiento mejor que producir una respuesta completa inventando silenciosamente la información faltante.
La abstención y el escalamiento son mecanismos de control.
Tres modelos temporales de intervención humana
Ahora podemos combinar las funciones anteriores con el momento de intervención.
Modelo A: aprobación previa
La persona interviene antes de una acción.
Por ejemplo:
preparar correo al proveedor
↓
aprobación humana
↓
enviarAdecuado cuando la acción es externa, significativa o difícil de revertir.
Modelo B: supervisión por umbral
El sistema funciona normalmente sin revisión individual, pero solicita intervención cuando se cumple una condición.
Por ejemplo:
riesgo bajo o medio
→ continuar
riesgo alto
→ escalarO:
proveedor sin datos sensibles
→ ruta ordinaria
proveedor crítico con datos personales
→ revisión humana reforzadaLa calidad de este modelo depende de la calidad del umbral.
Si el criterio que dispara revisión es malo, el control también lo será.
Modelo C: revisión posterior
La acción ocurre y después se revisa mediante auditoría, muestreo o análisis periódico.
Por ejemplo:
extracción automática de fechas
↓
registro
↓
auditoría mensual de muestraPuede resultar adecuado cuando:
- el impacto individual es bajo;
- el error es reversible;
- existe buena observabilidad;
- la supervisión ex ante costaría más que el riesgo controlado.
No resulta equivalente para una acción contractual irreversible.
Antes, durante y después
Podemos resumir la arquitectura temporal:
flowchart LR
A[Antes] --> B[Durante]
B --> C[Después]
A --- D[Aprobación previa]
B --- E[Umbral / excepción / escalamiento]
C --- F[Muestreo / auditoría / revisión posterior]
Un mismo workflow puede utilizar los tres modelos en distintos puntos.
Por ejemplo:
extracción de metadatos
→ revisión posterior
clasificación de alto riesgo
→ supervisión por umbral
envío de posición contractual
→ aprobación previaNo necesitamos escoger una sola filosofía para todo el proceso.
Qué hace que la intervención humana sea efectiva
El material del curso entrega una regla muy importante: HITL no debe ser decorativo.
Podemos descomponer esa idea en cinco requisitos.
1. Información suficiente
La persona necesita ver aquello que permite evaluar la decisión.
No sólo:
“riesgo alto”Sino, según corresponda:
- evidencia;
- criterio;
- contexto;
- información faltante;
- acción propuesta.
2. Poder real de detener o modificar
Si la persona sólo puede hacer clic en:
ACEPTARpero no puede rechazar, corregir o escalar, la intervención es limitada.
3. Autoridad adecuada
No basta que haya una persona.
Debe ser la persona o rol apropiado para esa decisión.
4. Tiempo y carga razonables
Una persona que recibe cientos de aprobaciones triviales puede desarrollar fatiga y confirmar automáticamente.
El diseño del control debe considerar también volumen y ergonomía.
5. Registro
Debe quedar constancia, cuando sea relevante, de:
quién intervino
qué decisión adoptó
cuándo
sobre qué versión
con qué condicionesSin registro, la intervención puede existir y seguir siendo difícil de auditar.
Prueba práctica de control humano
Antes de llamar “human-in-the-loop” a un diseño, pregunta:
¿Qué ve la persona?
¿Qué puede hacer?
¿Qué ocurre si rechaza?
¿Tiene autoridad suficiente?
¿Queda evidencia de la decisión?
Si no podemos responder, probablemente el control todavía no está bien diseñado.
El riesgo del rubber stamping
Existe un problema conocido en muchos sistemas de apoyo a decisiones: la persona puede terminar confirmando la recomendación del sistema sin analizarla sustantivamente.
Imaginemos una interfaz:
La IA recomienda APROBAR.
Confianza: 96 %.
[ Aprobar ]Si el usuario no puede inspeccionar la evidencia, el número puede producir una apariencia de certeza.
La revisión humana corre el riesgo de transformarse en un rubber stamp: una confirmación formal sin control material.
Una mejor interfaz puede mostrar:
RECOMENDACIÓN PROPUESTA
Aprobar con condiciones.
EVIDENCIA
3 documentos utilizados.
PUNTOS ABIERTOS
1 excepción contractual.
INFORMACIÓN FALTANTE
ninguna.
ACCIÓN
Revisar excepción antes de decidir.La interfaz no garantiza una decisión correcta.
Pero hace más visible aquello que debe ser considerado.
La confianza del modelo no debe reemplazar la autoridad del proceso
Una aplicación puede producir una puntuación:
confidence = 0.94Eso no significa:
autorización = concedidaDebemos evitar mezclar:
- confianza estadística o heurística;
- suficiencia de evidencia;
- nivel de riesgo;
- autoridad organizacional.
Son dimensiones diferentes.
Human-in-the-loop en trabajo jurídico
La relevancia profesional es especialmente clara en tareas donde un output puede afectar:
- derechos de un cliente;
- posición negociadora;
- comunicaciones a terceros;
- presentación ante tribunales;
- tratamiento de información confidencial;
- aceptación de riesgos;
- obligaciones contractuales.
La ABA Formal Opinion 512 insiste en que los abogados deben comprender razonablemente las capacidades y limitaciones de las herramientas de IA generativa y aplicar un grado apropiado de revisión o verificación según la tarea. La guía del CCBE desarrolla una preocupación equivalente respecto de competencia profesional, confidencialidad, independencia y uso responsable.
No necesitamos convertir esta página en una discusión exhaustiva de deberes profesionales.
La consecuencia arquitectónica es suficiente:
la tecnología puede preparar o ejecutar parte del trabajo, pero la organización debe decidir dónde necesita juicio, autorización y responsabilidad humana.
Caso conductor: diseñar los controles de una contratación
Retomemos el workflow del proveedor de IA.
Etapa 1: clasificación
El sistema propone:
criticidad = altaControl:
humano revisa si la clasificación activa correctamente las revisiones exigidasEtapa 2: análisis
La IA prepara una matriz.
Control:
abogado revisa hallazgos y evidenciaEtapa 3: negociación
El sistema prepara una redacción alternativa.
Control:
aprobación previa antes de enviar al proveedorEtapa 4: excepción
El proveedor rechaza el fallback autorizado.
Control:
escalamiento a responsable con autoridad superiorEtapa 5: registro
Una vez aprobada la excepción:
sistema registra automáticamente
+
conserva quién aprobó y bajo qué condicionesAquí no existe un único “humano en el loop”.
Existen distintos puntos humanos con funciones distintas.
Una matriz de control
Podemos representarlo así:
| Situación | Función humana | Momento | Resultado |
|---|---|---|---|
| IA extrae cláusulas | revisión | después de generar | hallazgos validados |
| enviar propuesta | aprobación | antes de actuar | autorizado / rechazado |
| riesgo supera umbral | escalamiento | durante el proceso | decisión superior |
| falta documento | excepción | cuando se detecta | detener / solicitar |
| tarea rutinaria | auditoría | después | control por muestreo |
Esta tabla ayuda a evitar una categoría demasiado genérica de “supervisión humana”.
Qué puede salir mal
Colocar el control después de una acción irreversible
La revisión posterior no reemplaza una aprobación que debía ocurrir antes.
Exigir aprobación para todo
Un proceso lleno de clics humanos puede producir fatiga y perder capacidad de distinguir lo importante.
Escalar sin criterios
Si nadie sabe qué merece escalamiento, el proceso será inconsistente.
Crear umbrales sin evidencia
“Riesgo alto” sólo funciona como disparador si la clasificación tiene una base suficientemente clara.
No definir qué pasa con una excepción
Un expediente puede quedar indefinidamente “pendiente” sin dueño ni próximo paso.
Dar al revisor una conclusión sin evidencia
La persona puede estar formalmente presente y materialmente ciega.
Confundir revisión con responsabilidad
Una persona puede revisar un output sin asumir la autoridad para aceptar el riesgo que contiene.
Qué debes recordar
Human-in-the-loop es una arquitectura de control, no una etiqueta tranquilizadora.
En este sitio distinguiremos:
Revisión
Comprobar calidad, completitud y evidencia.
Aprobación
Autorizar el siguiente paso o una acción.
Escalamiento
Transferir el asunto cuando excede la ruta o autoridad ordinaria.
Excepción
Tratar una situación en la que el proceso normal no puede continuar.
Y esas funciones pueden ubicarse:
ANTES
aprobación previa
DURANTE
supervisión por umbral / excepción / escalamiento
DESPUÉS
muestreo / auditoríaLa presencia humana sólo aporta control real cuando existe información suficiente, poder de intervención, autoridad adecuada y registro de la decisión.
El problema que todavía queda abierto
Con workflow y human-in-the-loop ya podemos ordenar tareas y colocar controles.
Pero todavía queda una dificultad típicamente jurídica.
Los casos no sólo difieren en su estado.
También difieren en qué criterio debemos aplicar y qué estrategia corresponde cuando aparece una variante.
Un checklist puede recordarnos revisar responsabilidad, datos, SLA o terminación.
Un procedimiento puede indicar en qué orden hacerlo.
Pero ninguno de esos elementos explica necesariamente:
“Si el proveedor rechaza nuestra posición preferida, ¿qué alternativa está autorizada?”
O:
“Si el servicio es crítico y trata datos personales, ¿qué ruta adicional debemos activar?”
El siguiente nodo estudia el paso del checklist al playbook.