El human-in-the-loop no se ha vuelto obsoleto: se ha vuelto un placebo

El loop que nos vendieron como cinturón de seguridad

Hay una frase que se repite en demos, decks de inversores y políticas internas con la misma cara de pena:

“Tranquilos. Hay un humano en el loop.”

Suena a control. Suena a madurez. Suena a que alguien con dos neuronas vivas se ha leído el Reglamento Europeo de IA y ha puesto un adulto en la sala. En la práctica, muchas veces es otra cosa: un sello de goma al final de un flujo que ya ha decidido por ti.

No voy a hacer el numerito fácil de “fuera humanos, viva la autonomía”. Eso es de gurú con calendario de keynotes. Tampoco voy a decir que el human-in-the-loop está muerto en todos los contextos, porque no lo está. Lo que se está agotando es el modelo mental del HITL clásico: la IA propone, un humano valida cada caso, y con eso ya dormimos tranquilos.

Ese modelo no aguanta volumen. No aguanta fatiga. Y, lo más jodido, no aguanta la psicología de confiar en un sistema que acierta casi siempre. Cuando el modelo parece fiable, el revisor deja de revisar de verdad. OpenWebinars lo llama, con bastante precisión, sesgo de automatización: cuanto más creíble parece la máquina, menos se cuestiona, y la supervisión se vuelve mecánica si no hay tiempo, formación y criterios claros.

Eso no es un detalle de UX. Es el núcleo del problema.

No hay un solo “humano en el loop”: hay un mapa y casi nadie lo usa

Antes de pelearnos con el eslogan, hay que bajar al diccionario. datos.gob.es ordena los mecanismos de supervisión de forma bastante limpia, y conviene tenerlos en la cabeza porque “HITL” se usa para todo y al final no significa nada.

Human in the Loop (HITL): intervención humana directa en cada decisión. La IA sugiere; una persona valida o corrige antes de ejecutar. Es el modelo más conservador. Tiene sentido cuando las consecuencias importan de verdad y el volumen lo permite.

Human on the Loop (HOTL): el sistema actúa de forma autónoma; un humano monitoriza en tiempo real y puede intervenir si detecta mierda. Encaja en alto volumen, donde revisar caso a caso es una fantasía de PowerPoint.

Human in Command (HIC): los humanos definen propósito, límites, criterios de calidad y riesgo aceptable; auditan resultados y pueden suspender el sistema. Aquí el mando no está en el clic de “aprobar”, está en el diseño del terreno de juego.

Human out of the Loop (HOOTL): sin intervención humana directa. Solo para contextos muy acotados, bajo riesgo y con salvaguardas robustas. Si alguien te lo vende para crédito al consumo o triage médico, sal corriendo.

La primera hostia conceptual es esta: mucha gente dice HITL cuando en realidad quiere HOTL o HIC, o cuando lo que tiene montado es un HOOTL con un becario mirando un dashboard de vez en cuando. El eslogan tapa la arquitectura. Y cuando el eslogan tapa la arquitectura, la gobernanza se vuelve teatro.

Tres fuentes, una tensión, y la tesis que sale al cruzarlas

El material de este artículo no sale de una sola campana. Sale de tres lecturas que se pisan y a la vez se tiran de los pelos.

OpenWebinars (marzo de 2026) pone el foco en la competencia crítica del supervisor. El riesgo del human-in-the-loop, dice, no es tanto perder el control técnico como perder la capacidad de dudar. La validación automática genera falsa seguridad. La supervisión efectiva exige aprendizaje continuo: si no, el humano se convierte en un aprobador pasivo. Ahí aparecen dos conceptos que deberían estar en la pared de cualquier equipo de producto con IA: obsolescencia cognitiva (dejas de ejercitar habilidades porque el entorno ya no las exige) y fatiga decisional (validar demasiadas decisiones en poco tiempo te empuja a delegar implícitamente en el sistema).

datos.gob.es (mayo de 2026) aporta el mapa institucional y la paradoja de fondo: a medida que los sistemas mejoran, sube la presión para reducir la intervención humana. Un 99% de precisión puede esconder errores difíciles de detectar o con costes inaceptables. Y recuerda que el Reglamento Europeo de IA dedica su Artículo 14 a la supervisión humana en sistemas de alto riesgo: las personas tienen que poder monitorizarlos de forma efectiva. No dice “pon un humano a clicar Aprobar 8 horas”. Dice que la supervisión tiene que ser real.

Azirgo (julio de 2026) va más a saco y con olor a producción: el human-in-the-loop se agotó porque no escala. Revisar 50 tickets es manejable. Revisar 5.000 no. El humano se vuelve cuello de botella: caro, lento y poco confiable por fatiga. Su propuesta no es “fuera gente”, es mover la validación al diseño del sistema con guardrails (validación de esquema, allowlist de acciones, umbral de confianza, restricción de fuentes, límites de longitud y tono) y dejar al humano en las excepciones, en torno al 5-10% de casos, no en el 100%.

Seamos justos: el HITL clásico no es un capricho de consultor. Nace de una intuición sensata (que alguien con criterio supervise lo que una máquina no entiende) y ha funcionado durante décadas en contextos de bajo volumen y alto impacto, como la aviación o la medicina. El problema no es el concepto original, sino la fe de que se puede copiar y pegar a cualquier pipeline sin rediseñar la arquitectura de supervisión.

¿Dónde coinciden? En que el ritual de “todo pasa por un humano” es frágil. En que la fiabilidad aparente del modelo baja la vigilancia. En que la supervisión sin criterio es decorado.

¿Dónde discrepan? OpenWebinars insiste en formar y mantener despierta la capacidad crítica del revisor. Azirgo insiste en que meter más revisores al final del tubo es una trampa de escala y que el valor del humano está antes de la ejecución: políticas, límites, umbrales, rutas de escalamiento, criterios de rechazo. datos.gob.es se queda en el marco: hay grados de intervención y la ley exige efectividad, no postureo.

La tesis de Domina IA, al cruzar las tres, es esta:

El HITL clásico se agota como estrategia por defecto. No porque el humano sobre, sino porque lo hemos puesto en el sitio equivocado: al final del proceso, a sello por minuto, sin mando real sobre el diseño. El humano no se elimina del circuito; se saca del cuello de botella y se sube al mando, a los límites y a las excepciones. Si no, el “loop” es un placebo regulatorio y operativo.

Eso no es matar la supervisión. Es dejar de confundir supervisión con rezar al final del pipeline.

El riesgo real no es que la IA se escape: es que tú te duermas

OpenWebinars lo deja negro sobre blanco: el peligro no es solo técnico. Es cognitivo. Si tu trabajo consiste en validar salidas que en el 98% de los casos “se ven bien”, tu cerebro hace lo que siempre ha hecho con las alarmas que no saltan: las ignora.

Eso tiene nombre de manual: sesgo de automatización. Y tiene una hermana peor: la obsolescencia cognitiva. Dejas de practicar el juicio porque el sistema ya te lo sirve empaquetado. Al cabo de meses, no es que el modelo sea mejor revisor que tú. Es que tú ya no eres revisor. Eres un sello.

La Comisión Europea, según recoge la misma pieza de OpenWebinars en el contexto del Reglamento Europeo de IA, advierte precisamente de esto: la supervisión humana puede volverse formal sin comprensión real del sistema. Traducción de barra de bar: puedes cumplir el checklist y seguir sin enterarte de una mierda de lo que estás firmando.

Y aquí va el matiz que mucha gente se traga mal. La fatiga decisional no afecta igual a todos los sectores ni a todas las tareas. No es lo mismo priorizar tickets de soporte de baja gravedad que autorizar operaciones con impacto legal o sanitario. No inventamos una ley universal de agotamiento humano. Lo que sí consta es la relación que marca OpenWebinars: cuando delegas en exceso y metes demasiadas validaciones en poco tiempo, el criterio se atrofia y la delegación se vuelve implícita. El sistema no te ha “quitado” el control. Tú se lo has entregado a plazos, con sonrisa de cumplimiento.

En organizaciones que emplean IA para priorización o riesgo, los errores más graves (de nuevo según OpenWebinars) no suelen ser el fallo cinematográfico de un día. Son pequeñas desviaciones acumuladas que nadie cuestionó a tiempo. Eso es lo que el HITL de marketing no detecta: el revisor cansado que aprueba el 37.º caso de la mañana con el mismo gesto con el que acepta las cookies de una web.

Por qué no escala (y por qué decirlo no es insultar al revisor)

Azirgo va al hueso operativo. Revisar 50 casos a conciencia es trabajo humano de verdad. Revisar 5.000 es otra industria: colas, SLAs, turnos, rotación y una curva de atención que se va al carajo. El humano se convierte en cuello de botella. Lento. Caro. Y, por fatiga, poco confiable.

Eso no significa que el HITL clásico sea basura en un hospital, en un proceso judicial o en una decisión de alto impacto con bajo volumen. Significa que no puedes copiar el mismo patrón a un agente que procesa miles de acciones al día y pretender que el control sigue siendo el mismo. El control ha cambiado de forma. Si no rediseñas, solo has escalado el teatro.

El patrón de madurez que describe Azirgo es casi un chiste cruel de la industria, porque lo has visto en tres clientes y en dos startups:

1. Automatizas.
2. Te asustas con los errores.
3. Metes revisión humana de todo.
4. Descubres que no escala.
5. Mueves la validación al diseño y dejas al humano en excepciones.

La pregunta no es si ese arco es bonito. La pregunta es en qué punto del arco estás tú fingiendo que el paso 3 es un estado final. Porque el paso 3 es un torniquete. No es una arquitectura.

Y ojo con la trampa opuesta: no vamos a afirmar que los guardrails eliminan por completo la necesidad de supervisión humana. No consta, y además sería una gilipollez. Un allowlist mal pensado es solo un error con mejor marketing. Un umbral de confianza del 0.92 sin muestreo humano es una superstición con decimales. Los guardrails cambian dónde interviene el humano y cuánto interviene por unidad de salida. No convierten el sistema en moralmente adulto.

Mover al humano antes del botón: diseño, no penitencia

Si el valor del humano no está en releer el 100% de las salidas, ¿dónde está?

Azirgo lo sitúa antes de la ejecución: definir políticas, límites, umbrales, rutas de escalamiento y criterios de rechazo. Eso se parece bastante al Human in Command de datos.gob.es: propósito, límites, calidad, riesgo aceptable, auditoría y capacidad de suspender. Dos vocabularios, misma intuición: el mando no es el clic final; el mando es el marco.

En la práctica, eso se traduce en cosas que suenan aburridas y salvan el culo:

• Validación de esquema: si la salida no cumple la forma, no sale. Punto. Azirgo menciona la documentación de Pydantic como ejemplo de validación estructurada en Python; no es magia, es higiene.
• Allowlist de acciones: el agente no “puede intentar lo que sea”; puede hacer A, B y C. El resto es excepción o rechazo.
• Umbral de confianza con ruta de escalado: por debajo del umbral, humano. Por encima, no significa “verdad divina”; significa “pasa el filtro, y aún así muestreo”.
• Restricción de fuentes y de alcance: de dónde puede leer, a dónde puede escribir, qué herramientas toca.
• Límites de longitud, tono y tipo de decisión: no todo es un prompt bonito; a veces es una política de negocio codificada.

Esto conecta con un problema que ya hemos visto en agentes que “obedecen demasiado bien”: el fallo no siempre es del modelo, es de permisos, de superficie de acción y de ausencia de frenos. Si te suena el olor, es el mismo barrio que cuando el agente obedece demasiado bien: el desastre no necesita malicia, le basta un circuito sin límites claros.

Y también encaja con el trabajo bien hecho en validación humana cuando el usuario no es ingeniero: no se trata de mirar el output como un cura mira un milagro, sino de tener método, arquitectura y criterios. Eso es lo que, en otro terreno, se defiende en validación humana para no programadores con Claude Code: el humano aporta juicio cuando hay un marco, no cuando hay fe.

La diferencia entre un HITL serio y un HITL de cartel es brutal:

• En el de cartel, el humano revisa todo y no entrena criterio.
• En el serio, el humano diseña qué puede pasar, qué no, qué se escala, qué se audita y qué se apaga.

Uno produce tickets. El otro produce gobernanza.

La paradoja del 99% y la regulación que pide efectividad, no teatro

datos.gob.es formula la paradoja sin drama inútil: cuanto mejores son los sistemas, más presión hay para quitar humanos del medio. Un 99% de precisión puede esconder errores caros o difíciles de pillar. Ese 1% no se reparte de forma amable. A veces se concentra justo en los casos raros, sensibles o adversariales: justo donde el revisor dormido es más peligroso.

Aquí entra el Artículo 14 del AI Act, que datos.gob.es sitúa en la exigencia de supervisión humana efectiva para sistemas de alto riesgo. Importante lo que no vamos a afirmar: no vamos a decir que el Reglamento exige HITL clásico en todos los sistemas de alto riesgo, ni a inventar el detalle completo del artículo cuando no está en el material. Lo que sí consta es la dirección: las personas tienen que poder monitorizar de forma efectiva. “Efectiva” es la palabra que tumba el teatro.

Si tu supervisión consiste en un humano sin formación, sin tiempo y sin criterios, mirando una cola infinita, no estás cumpliendo el espíritu de “monitorización efectiva”. Estás externalizando la ansiedad legal a un interino.

Y sí, el desfase entre lo que la ley nombra y lo que los sistemas ya hacen en producción es un problema de fondo de toda la industria; lo hemos tratado en el desfase regulatorio de la IA. El Artículo 14 no te regala la arquitectura. Te exige que la supervisión no sea un PDF. El resto es ingeniería y criterio.

OpenWebinars y datos.gob.es se dan la mano en este punto aunque no usen las mismas palabras: sin comprensión real del sistema, la supervisión se vuelve formal. Azirgo añade la consecuencia de fábrica: si además intentas que esa supervisión formal cubra el 100% del volumen, se rompe. Tres caminos al mismo muro.

Lo que se atrofia cuando el revisor se convierte en sellador

Hablemos claro de la obsolescencia cognitiva, porque es el coste que casi nadie pone en el Excel.

Cuando el entorno no exige juicio, el juicio se oxida. No de golpe. A plazos. Primero dejas de contrastar fuentes. Luego dejas de pedir el porqué de una clasificación rara. Luego firmas porque “el modelo suele acertar”. Al final, el día que el sistema se desvía en una racha de casos parecidos, no tienes músculo para pillarlo. Tienes hábito de aprobar.

OpenWebinars enlaza esto con el aprendizaje continuo como condición de la supervisión. No es un curso de mindfulness corporativo. Es una exigencia operativa: si tu gente no entiende límites del modelo, modos de fallo, datos de entrada y criterios de rechazo, no tienes human-in-the-loop. Tienes human-in-the-way: un obstáculo burocrático que además se cree control.

La fatiga decisional empuja en la misma dirección. Validar mucho en poco tiempo no te hace más responsable; te hace más propenso a delegar sin decirlo. El sistema gana por agotamiento. Y las organizaciones con IA de priorización o riesgo pagan eso en forma de desviaciones pequeñas que se apilan hasta hacerse caras. No hace falta un apocalipsis. Basta una racha de microerrores no cuestionados.

Eso es lo que el eslogan “hay un humano” oculta con elegancia de consultora: el humano puede estar presente y, aun así, no estar ejerciendo.

Entonces, ¿se acabó el humano en el circuito?

No. Se acabó el autoengaño de que el circuito se controla con un revisor al final y un checkbox de cumplimiento.

Recapitulando sin moraleja de LinkedIn:

• El HITL clásico sigue teniendo sentido en decisiones de alto impacto y volumen manejable. Nadie serio lo entierra en bloque.
• El HITL clásico se agota como patrón por defecto cuando el volumen sube, la fatiga entra y el modelo parece “casi perfecto”.
• El sesgo de automatización y la obsolescencia cognitiva convierten al revisor en sellador si no hay formación, tiempo y criterios.
• El mapa de datos.gob.es (HITL, HOTL, HIC, HOOTL) obliga a elegir con honestidad qué nivel de intervención tienes de verdad, no el que pone el slide.
• Azirgo acierta al empujar la validación al diseño y al reservar al humano para excepciones; se equivocaría quien lea eso como “los guardrails sobran al humano”.
• El AI Act, vía Artículo 14 según datos.gob.es, empuja a supervisión efectiva en alto riesgo. Efectiva no es sinónimo de “un humano mira todo”.

La posición con huevos es esta: deja de emplear el human-in-the-loop como indulgencia. No es un amuleto. Es un diseño. O el humano manda de verdad (límites, auditoría, excepciones, capacidad de apagar) o el loop es un placebo que te cobra en tiempo, en dinero y en criterio oxidado.

Si tu sistema solo es “seguro” porque alguien pulsa Aprobar 400 veces al día, no tienes un sistema seguro. Tienes un sistema que ha convertido a una persona en la última capa de un stack mal pensado. Y las capas humanas mal pensadas no escalan: se rompen, se callan o se acostumbran a mentir con un clic.

El futuro no es un humano fuera del circuito por dogma. Es un humano menos en la cola y más en el mando. Menos penitencia de revisión masiva. Más ingeniería de límites. Más muestreo honesto. Más competencia crítica que no se oxide.

Porque el día que el 99% te haya dormido del todo, el 1% no te va a pedir permiso.