Hoja de Trabajo de Diseño de Flujo HITL: Convierte Cualquier Caso de Uso de IA en un Sistema Human-in-the-Loop

Human-in-the-loop (HITL) no es una filosofía — es una decisión de ingeniería. Para cada caso de uso de IA que requiere supervisión humana, alguien necesita especificar exactamente: ¿dónde interviene el humano, quién es, qué ve, cuánto tiempo tiene y qué pasa cuando no responde? Sin esos detalles, "tenemos supervisión humana" es una declaración de intención, no un control.

Usa esta hoja de trabajo para cada caso de uso de IA que estés desplegando que requiera supervisión humana. Una hoja de trabajo completada por sistema. Guárdala con tu entrada de inventario de modelos.

Parte 1: Perfil del Caso de Uso

Completa esto antes de hacer cualquier diseño técnico. Si no puedes responder estas preguntas claramente, el caso de uso no está listo para implementación.

Nombre del caso de uso: _______________________________________________

Responsable del sistema (nombre y título): _______________________________________________

Fecha de completación: _______________________________________________

Descripción breve — ¿Qué hace la IA, en una o dos oraciones?

¿Qué entrada recibe?

¿Qué output produce? (Sé específico: una puntuación, una etiqueta de clasificación, texto generado, una acción recomendada, etc.)

¿Qué acción downstream dispara el output? (¿Qué sucede después si el output es aceptado?)

Parte 2: Evaluación de Riesgos

Califica este caso de uso en dos dimensiones, luego usa la matriz de resultado para determinar tu modo de supervisión requerido.

Severidad de Consecuencia: ¿Qué tan malo es un output incorrecto?

Nivel	Definición	Ejemplos
Alto	Daño significativo a un individuo; difícil o imposible de revertir	Rechazo de préstamo, recomendación de tratamiento médico, presentación legal, terminación de cuenta
Medio	Impacto material, reversible con esfuerzo y costo	Precios incorrectos, contenido equivocado mostrado al usuario, servicio retrasado
Bajo	Inconveniencia menor, fácilmente corregible sin impacto duradero	Sugerencia de autocompletado, recomendación de etiqueta, resumen interno

Tu calificación: [ ] Alto [ ] Medio [ ] Bajo

Frecuencia de Decisión: ¿Cuántas decisiones por día?

Nivel	Volumen
Alto	Más de 10,000 decisiones por día
Medio	100 a 10,000 decisiones por día
Bajo	Menos de 100 decisiones por día

Tu calificación: [ ] Alto [ ] Medio [ ] Bajo

Matriz de Resultado

	Baja Frecuencia	Media Frecuencia	Alta Frecuencia
Alta Consecuencia	HITL requerido	HITL requerido	HITL requerido
Media Consecuencia	HITL recomendado	HOTL con muestreo	HOTL con muestreo
Baja Consecuencia	HOOTL con logging	HOOTL con logging	HOOTL con logging

Tu modo de supervisión:

[ ] HITL — El humano aprueba cada output antes de que se tome la acción downstream

[ ] HOTL — El humano monitorea con tasa de muestreo definida; puede anular. Tasa de muestreo: _______%

[ ] HOOTL — Completamente automatizado; métricas agregadas monitoreadas por humanos

Nota: Si la política de gobernanza de tu organización ordena HITL para este nivel de riesgo independientemente del volumen, esa política tiene precedencia sobre esta matriz.

Parte 3: Diseño del Punto de Intervención

Completa esta sección solo para sistemas HITL y HOTL.

¿Dónde ocurre la revisión humana?

Marca todos los que apliquen:

[ ] Antes de que el modelo se ejecute (el humano revisa los datos de entrada y decide si proceder)

[ ] Después de que el modelo produce output pero antes de la acción downstream (más común para HITL)

[ ] Antes de una acción downstream específica dentro de un flujo de trabajo multi-paso (especifica qué acción abajo)

[ ] Todo lo anterior

Acción específica que requiere aprobación humana (si aplica):

Especificación del revisor

¿Quién es el revisor designado? (rol/título, no nombre individual — especifica la asignación individual en el RACI de tu equipo)

¿Hay un revisor secundario para escalaciones? (rol/título)

¿Cuál es el tiempo máximo aceptable de revisión (SLA)?

¿Qué pasa si un revisor no responde dentro del SLA?

[ ] Escalar a revisor secundario

[ ] Escalar a [rol]: _______________

[ ] Auto-rechazar (no tomar acción downstream)

[ ] Auto-aprobar (solo para sistemas de Nivel 3 con justificación documentada)

[ ] Pausar todo el flujo de trabajo y alertar al responsable del sistema

¿Puede el revisor solicitar información adicional antes de decidir?

[ ] No — el revisor debe decidir basado en lo que se muestra

[ ] Sí — el revisor puede solicitar: _______________________________________________

SLA para respuesta a solicitud de información: _______________

Parte 4: Requisitos de Interfaz de Revisión

La interfaz de revisión es donde el riesgo de sesgo de automatización es más alto. Los revisores a quienes se les muestra solo el output de IA con un solo botón de aprobar/rechazar aprobarán la mayoría de los outputs automáticamente. La interfaz debe mostrar suficiente contexto para que el revisor ejerza un juicio genuino.

Elementos requeridos — marca todos los que deben estar presentes en tu interfaz de revisión:

[ ] Output de IA (la recomendación, clasificación o texto generado específico)

[ ] Puntuación de confianza o probabilidad si el modelo produce una

[ ] Outputs alternativos considerados por el modelo (top-N alternativas, si aplica)

[ ] Los datos de entrada que produjeron este output

[ ] La versión del modelo que produjo este output

[ ] Casos pasados similares y sus resultados (casos de referencia)

[ ] Contexto regulatorio o de política relevante para este tipo de decisión

[ ] Tiempo restante en el SLA de revisión (cuenta regresiva visible)

[ ] Indicadores de flags o anomalías si la entrada está fuera de la distribución de entrenamiento del modelo

[ ] Decisiones previas de este revisor en casos similares (para apoyar calibración)

Contexto adicional requerido para este caso de uso específico:

¿Qué debe registrar el revisor al rechazar?

[ ] Razón de rechazo (requerida, texto libre)

[ ] Categoría de rechazo (requerida, seleccionar de lista): _______________

[ ] Corrección recomendada: _______________

Parte 5: Umbrales de Escalación

Define los umbrales que determinan el enrutamiento para cada decisión. Sé específico — umbrales vagos producen comportamiento inconsistente.

Enrutamiento	Condición
Auto-aprobar	Confianza > _____% Y tipo de output = _____ Y sin flags levantados
Revisión estándar	Confianza entre _____% y _____% O cualquiera de estos flags: _____
Revisión senior	Confianza inferior a _____% O output incluye cualquiera de: _____
Rechazo automático	Output contiene cualquiera de: _____ (ej., contenido prohibido, solicitud fuera de alcance)

Nota sobre establecer umbrales: No establezcas umbrales de auto-aprobación antes de tener datos empíricos sobre la calibración de confianza real del modelo. Ejecuta el modelo en modo sombra (outputs registrados pero sin acciones downstream tomadas) durante al menos 30 días y revisa la distribución de puntuaciones de confianza junto con decisiones de revisores humanos antes de finalizar los umbrales.

Parte 6: Prevención de Sesgo de Automatización

El sesgo de automatización — la tendencia de los revisores humanos a deferir a los outputs de IA sin una evaluación independiente genuina — socava los controles HITL. Estos controles lo reducen.

Verificación retrospectiva aleatoria

[ ] _____% de las decisiones auto-aprobadas son revisadas retrospectivamente cada semana por un revisor senior

Calibración de revisores

[ ] Los revisores son probados en un conjunto de casos conocidos (donde la respuesta correcta está establecida) al menos mensualmente. Tasa de aprobación requerida: _____%. Los revisores que fallan las pruebas de calibración son reentrenados antes de regresar a tareas de revisión.

Monitoreo de tasa de anulación

[ ] Las tasas de anulación se calculan semanalmente. Rango objetivo de tasa de anulación: _____% a _____%

[ ] Una tasa de anulación que se desvía más de _____% del rango base dispara: _______________________________________________

Rotación de revisores

[ ] Ningún revisor individual maneja más del _____% de los casos en cualquier semana dada

[ ] Número mínimo de revisores activos: _____

Bucle de retroalimentación

[ ] Las decisiones de los revisores se usan para evaluar periódicamente el rendimiento del modelo. Cuando los revisores consistentemente anulan el modelo en un tipo de entrada específico, esto dispara una evaluación del modelo dentro de _____ días.

Parte 7: Requisitos de Pista de Auditoría

Para cada decisión humana en este flujo de trabajo, lo siguiente debe registrarse automáticamente. Esto no es opcional para sistemas de Nivel 1 o Nivel 2 — es un requisito regulatorio bajo SR 11-7, Artículo 30 del EU AI Act e HIPAA (donde aplique).

Campos de log requeridos — confirma que cada uno será capturado:

[ ] Marca de tiempo en UTC (no hora local)

[ ] Identidad del revisor (ID de usuario, no nombre — el nombre puede cambiar; el ID de usuario persiste)

[ ] Output de IA que fue revisado (texto exacto, puntuación o clasificación)

[ ] Versión del modelo que produjo el output (no versión de la aplicación — versión del artefacto del modelo)

[ ] Decisión del revisor: Aprobar / Rechazar / Escalar

[ ] Razonamiento del revisor (texto libre — requerido para Rechazar y Escalar)

[ ] Tiempo dedicado a la revisión (segundos desde la visualización hasta la decisión)

[ ] Acción downstream tomada como resultado de la decisión de revisión

[ ] Identificador de caso o entidad (para poder reconstruir qué individuo fue afectado)

Período de retención del log: _______________________________________________

Ubicación de almacenamiento del log: _______________________________________________

Mecanismo de prueba de manipulación (cadena de hash, almacenamiento de escritura única, etc.): _______________________________________________

Parte 8: Métricas de Efectividad

Define valores objetivo antes de lanzar. Mide contra ellos mensualmente. Si no estableces una línea base, no puedes detectar drift.

Métrica	Objetivo	Cómo se Mide
Tasa de completación de revisión	_____% de los casos que requieren revisión realmente la reciben	Casos revisados / casos que requieren revisión
Tasa de anulación	_____% (establecer línea base después de 30 días)	Casos rechazados o escalados / casos revisados
Tiempo de decisión	_____ minutos promedio	Media del campo de log de duración de revisión
Tasa de falsos negativos	_____%	IA aprobó; revisor retrospectivo senior no está de acuerdo
Completitud del log de auditoría	100%	Registros de log / registros de inferencia para casos revisados
Tasa de aprobación de calibración de revisores	_____%	Resultados de prueba de calibración, mensuales

Cadencia de reporte: Estas métricas se reportan a _____________________ de forma [semanal / mensual].

Disparadores de escalación — si alguna métrica se desvía más allá del rango aceptable, se toma la siguiente acción:

Ejemplo Completado: IA de Revisión de Cláusulas Contractuales

Para ilustrar cómo funciona esta hoja de trabajo en la práctica, aquí hay un ejemplo llenado para un caso de uso de tecnología legal.

Nombre del caso de uso: Evaluador de Riesgo de Cláusulas Contractuales

Descripción breve: La IA revisa cláusulas contractuales subidas y marca aquellas con términos no estándar, protecciones faltantes o asignación inusual de responsabilidad, y produce una calificación de riesgo (Bajo / Medio / Alto) con una explicación resumen.

Entrada: Texto de cláusula contractual individual (extraído de PDFs subidos)

Output: Calificación de riesgo (Bajo / Medio / Alto) y explicación de 2-3 oraciones de los problemas marcados

Acción downstream: Las cláusulas calificadas como Alto se ponen automáticamente en cola para revisión de abogado; las cláusulas calificadas como Bajo se auto-aceptan; las de Medio se ponen en cola para revisión de paralegal

Severidad de consecuencia: Alta (consecuencias legales y financieras por cláusulas riesgosas no detectadas)

Frecuencia de decisión: Media (200-500 cláusulas por día)

Modo de supervisión: HITL para cláusulas de calificación Alta; HOTL (10% de muestra) para cláusulas de calificación Media

Revisor: Asociado Senior (para Alta); Paralegal (para revisión de muestra de Media)

SLA: Calificación Alta: 4 horas; Revisión de muestra Media: 24 horas

Acción ante incumplimiento de SLA: Escalar al Socio de guardia

Umbral de auto-aprobación: Confianza > 92% Y calificación = Bajo Y sin cláusulas de PI o indemnización marcadas

Umbral de revisión senior: Cualquier cláusula donde la confianza del modelo sea inferior al 70% O la cláusula involucre limitación de responsabilidad, propiedad de PI o ley aplicable

Objetivo de tasa de anulación: 15-25% para cláusulas de calificación Alta (si la tasa de anulación cae por debajo del 10%, los revisores pueden estar aprobando automáticamente; si supera el 35%, el modelo puede estar marcando en exceso)

Conectando a Tu Infraestructura de Auditoría

La Parte 7 de esta hoja de trabajo especifica los campos exactos de log requeridos para cada decisión de revisión humana. Esos campos necesitan ser capturados por tu interfaz de revisión y almacenados en un sistema que pueda producirlos bajo demanda para reguladores.

Si estás construyendo una interfaz de revisión personalizada, la completitud del log debería ser un requisito bloqueante para el lanzamiento — no una mejora post-lanzamiento. Los registros de auditoría faltantes de antes de una corrección de logging se pierden; no pueden reconstruirse.

El logging de operador y seguimiento de revisión humana integrado de Ertas Data Suite captura automáticamente los campos de la Parte 7 para pasos de revisión del pipeline de datos, con almacenamiento a prueba de manipulaciones y exportación estructurada para presentación regulatoria.

Agenda una llamada de descubrimiento con Ertas →