--- title: "Cómo diseñar bien el Human-in-the-Loop (HITL): patrones de aprobación para agentes de IA" description: "Human-in-the-Loop (HITL) designa la integración deliberada de aprobaciones humanas en la cadena de acciones de un agente de IA." locale: "es" canonical: "https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/seguridad-de-agentes-de-ia-owasp/como-disenar-bien-el-human-in-the-loop-hitl-patrones-de-aprobacion-para-agentes" category: "Agentes de IA" topic: "Seguridad de agentes de IA & OWASP" updated: "2026-10-28T13:11:15.908Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # Cómo diseñar bien el Human-in-the-Loop (HITL): patrones de aprobación para agentes de IA Human-in-the-Loop (HITL) designa la integración deliberada de aprobaciones humanas en la cadena de acciones de un agente de IA. Cuando una acción es irreversible, costosa o tiene relevancia jurídica, una persona la revisa y la aprueba antes de que el agente actúe. HITL es la aplicación operativa de la supervisión humana que exige el artículo 14 del Reglamento de IA de la UE. ## De un vistazo - HITL no es un mecanismo para aplicar en todas partes: la aprobación va antes de las acciones irreversibles, costosas o con relevancia jurídica, no antes de cada paso. - Tres patrones clave cubren la mayoría de los casos: Pre-Action Approval, Checkpoint Approval y Escalation-on-Anomaly. - El mayor punto débil no es la falta de un control de aprobación, sino su degradación por el sesgo de automatización (OWASP ASI09): la persona aprueba sin mirar. - El artículo 14 del Reglamento de IA de la UE exige supervisión humana para la IA de alto riesgo; HITL es su aplicación técnica, complementada con registros de auditoría. - La UX tiene que obligar a revisar: mostrar el razonamiento, la procedencia de las fuentes y el nivel de confianza en lugar de un simple botón de aprobar. - Cada intervención manual y cada aprobación deben quedar registradas a prueba de manipulaciones (registros WORM, firma criptográfica). Human-in-the-Loop (HITL) designa la integración deliberada de aprobaciones humanas en la cadena de acciones de un [agente de IA](https://blckalpaca.at/es/glosario/agente-de-ia-ai-agent). Cuando una acción es irreversible, costosa o tiene relevancia jurídica, una persona la revisa y la aprueba antes de que el [agente](https://blckalpaca.at/es/glosario/agente) actúe. HITL es la aplicación operativa de la supervisión humana que exige el [artículo 14 del Reglamento de IA de la UE](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R1689) y, al mismo tiempo, una contramedida central frente al [riesgo agéntico ASI09 de OWASP](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/seguridad-de-agentes-de-ia-owasp/owasp-agentic-security-asi-top-10-2026-los-riesgos-de-los-sistemas-de-ia-agentic) (Human-Agent Trust Exploitation). - **Cuándo hace falta HITL:** antes de acciones irreversibles, costosas o con relevancia jurídica, no antes de cada paso. - **Qué patrones existen:** Pre-Action Approval, Checkpoint Approval y Escalation-on-Anomaly, normalmente combinados. - **Qué falla con más frecuencia:** el control de aprobación degenera en un trámite que se aprueba sin mirar (sesgo de automatización). La UX y la auditoría tienen que impedirlo activamente. ## Por qué la autonomía ingenua es un problema de seguridad Los sistemas agénticos planifican, razonan, eligen herramientas y actúan con una confirmación humana mínima paso a paso. Precisamente esa autonomía amplía la superficie de ataque. La entrada ASI02 de OWASP (Tool Misuse & Exploitation) señala como vector de ataque propio los [modos de autoaprobación o «YOLO»](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/seguridad-de-agentes-de-ia-owasp/tool-misuse-y-excessive-agency-cuando-los-agentes-de-ia-tienen-demasiados-permis), que desactivan los diálogos de confirmación. Nuestra recomendación: desactiva la autoaprobación en cualquier herramienta que toque bases de datos, pagos, comunicaciones o despliegues, y sustitúyela por controles Human-in-the-Loop. Por eso HITL no es una comodidad de UX, sino un control de seguridad. Limita el daño cuando un [secuestro de objetivos (ASI01)](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/seguridad-de-agentes-de-ia-owasp/agent-goal-hijacking-cuando-se-manipulan-los-objetivos-de-los-agentes-de-ia-auto), una [memoria envenenada (ASI06)](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/seguridad-de-agentes-de-ia-owasp/como-prevenir-el-memory-poisoning-protege-la-memoria-a-largo-plazo-y-vectorial-d) o una cadena de suministro comprometida (ASI04) llevan a un agente a actuar en contra de la intención de quienes lo operan. ## ¿Cuándo hace falta una aprobación humana? La decisión de poner o no un control de aprobación no debería tomarse sobre la marcha, sino a partir de una clasificación de riesgos documentada. Tres criterios cubren la mayoría de los casos: - **Irreversibilidad.** ¿La acción no se puede deshacer, o solo con mucho esfuerzo? Borrados, pagos, envíos a clientes, consignas de producción. - **Costes.** ¿La acción genera costes considerables o difíciles de acotar? Llamadas masivas a [API](https://blckalpaca.at/es/glosario/api), pedidos, aprovisionamiento de infraestructura. - **Relevancia jurídica.** ¿La acción produce efectos jurídicos o afecta a datos personales? Contratos, resoluciones de crédito o de prestaciones, comunicaciones de operaciones sospechosas, exportación de datos maestros. Por el contrario, las operaciones de solo lectura o las acciones fácilmente reversibles en un sandbox no suelen necesitar un control de aprobación. De lo contrario aparece la «fatiga de aprobación» y los revisores aprueban sin mirar por puro cansancio. ## Patrones HITL: Pre-Action, Checkpoint, Escalation Tres patrones básicos cubren la mayoría de las arquitecturas y en la práctica se combinan. **Pre-Action Approval.** El agente se detiene justo antes de una acción crítica concreta. La acción prevista, con sus argumentos, pasa a una cola de aprobación; solo se ejecuta tras el visto bueno humano. Adecuado para operaciones individuales de alto riesgo (iniciar un pago, enviar un contrato). **Checkpoint Approval.** En planes de varias fases, una persona revisa en hitos definidos antes de que arranque el siguiente segmento. Adecuado para flujos de trabajo largos en los que cada paso por separado es inofensivo, pero la trayectoria acumulada se vuelve crítica. El patrón responde al esquema de la «rana hervida» descrito por OWASP, en el que cada paso parece plausible, pero la trayectoria global es dañina. **Escalation-on-Anomaly.** El agente trabaja de forma autónoma y solo involucra a una persona cuando saltan umbrales o detectores de anomalías: frecuencias inusuales de llamadas a herramientas, operaciones destructivas poco después de incorporar contenido externo, superaciones del rate limit. Técnicamente se puede implementar mediante policy-as-code (p. ej., con Open Policy Agent (OPA) o Cedar) como control de aprobación del uso de herramientas. Una arquitectura HITL eficaz escalona la confianza: las decisiones de mayor impacto requieren más revisores o pruebas más sólidas («graduated trust»). Según OWASP, lo decisivo es que el control de aprobación exija una **verificación independiente de las pruebas**, no solo la recomendación del agente. ## La matriz acción-riesgo-HITL La siguiente matriz muestra, a modo de ejemplo, cómo se pueden clasificar las acciones. Está pensada como plantilla; cada organización debe ajustar los umbrales concretos a su apetito de riesgo. | Acción | Riesgo | ¿Requiere HITL? | Patrón recomendado | | --- | --- | --- | --- | | Consultar un registro / generar un informe | Bajo (reversible) | No | Basta con el registro de auditoría | | Crear una nota interna / un borrador | Bajo | No | Basta con el registro de auditoría | | Enviar un correo a un cliente externo | Medio (riesgo reputacional / de datos) | Sí | Pre-Action Approval | | Modificar una entrada de la base de datos (escritura) | Medio-alto | Sí | Pre-Action o Checkpoint | | Iniciar un pago / pedido | Alto (costes, irreversible) | Sí, en su caso con principio de cuatro ojos | Pre-Action, escalonado según el importe | | Borrar un registro definitivamente | Alto (irreversible) | Sí | Pre-Action Approval | | Emitir una resolución de crédito / prestación | Alto (efectos jurídicos) | Sí | Pre-Action + revisión independiente | | Enviar una comunicación de operación sospechosa (SAR) | Alto (jurídico) | Sí | Pre-Action + principio de cuatro ojos | | Consigna de producción / escritura en OT | Crítico (seguridad) | Sí | Pre-Action + control de plausibilidad | | Llamadas masivas a API por encima del umbral | Variable (costes) | Condicional | Escalation-on-Anomaly + límite de costes | ## El error más frecuente: el control de aprobación se degrada El mayor riesgo no es la falta de un control de aprobación, sino su vaciado progresivo. OWASP lo recoge como riesgo propio de su Top 10: [**ASI09 (Human-Agent Trust Exploitation)**](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/seguridad-de-agentes-de-ia-owasp/owasp-agentic-security-asi-top-10-2026-los-riesgos-de-los-sistemas-de-ia-agentic). Los agentes generan respuestas pulidas y con tono de autoridad; las personas tienden a darlas por buenas. Así, la [capa de supervisión](https://blckalpaca.at/es/glosario/capa-de-supervision) pensada como control de seguridad se convierte ella misma en el punto débil. Los mecanismos relevantes: - **Sesgo de automatización**: la respuesta se acepta sin revisión crítica. - **Deferencia a la autoridad**: el tono seguro desanima a hacer preguntas. - **Escalada gradual de la confianza**: el agente gana credibilidad con respuestas correctas antes de que lleguen las manipuladas. - **Sobrecarga cognitiva**: el volumen y la complejidad superan la capacidad humana de revisión. - **«Alucinación pulida»**: una respuesta segura de sí misma, falsa y convincente. Señales de detección con las que se puede medir la degradación: el tiempo de decisión de los revisores baja aunque la complejidad de las tareas se mantenga, y los patrones de aprobación se correlacionan de forma extrema con la recomendación del agente. Ambas cosas apuntan a que se aprueba sin mirar. ## Diseño UX que obliga a revisar Que el HITL funcione o no depende de la interfaz. Un simple botón de «Aprobar» invita a firmar sin leer. Lo que ayuda son los patrones de force engagement, que obligan a una revisión real: - **Hacer visible el razonamiento.** Mostrar la justificación, la procedencia de las fuentes y los intervalos de confianza, no ocultarlos. Según OWASP, quien esconde la traza de razonamiento en la UI genera precisamente una señal de detección de ASI09. - **Resaltado de outputs adversariales.** Avisos del tipo «esta respuesta podría estar influida por contenido externo» allí donde el contenido procede de fuentes no fiables. - **Retardo obligatorio.** En aprobaciones de alto riesgo, imponer un retraso deliberado para impedir la confirmación refleja. - **Formación sobre el sesgo de automatización** para los revisores e **inyecciones de prueba** periódicas («simulacros de incendio») que comprueban si el HITL sigue funcionando. ## Escenario de ejemplo: la cascada de compras Un escenario hace tangible el fallo del HITL. Supongamos que, a lo largo de tres semanas, se convence paso a paso a un agente de compras de que su límite de aprobación es de 500.000 USD. Después, el atacante coloca en diez transacciones pedidos falsos por un total de 5 millones de USD. El aprobador humano cree al agente, que afirma con cada vez más insistencia estar autorizado para importes mayores. Un caso de manual de ASI09, agravado por errores en cascada (ASI08). En pseudocódigo, un control Pre-Action eficaz podría esbozarse así: \`\`\`text on agent\_action(action): risk = classify(action) # reversibilidad, costes, derecho if risk in {ALTO, CRÍTICO}: evidence = gather\_provenance(action) # fuentes, confianza, razonamiento approver = route\_by\_amount(action) # >límite -> cuatro ojos / escalado decision = require\_human(evidence, enforce\_delay=True, show\_reasoning=True) audit\_log.write\_worm(action, evidence, decision) # firmado if not decision.approved: abort() execute(action) \`\`\` Importante: el límite (`route_by_amount`) está **fuera** de la memoria del agente y protegido contra manipulaciones. De lo contrario, el agente reaprende su propio límite, como en el ejemplo. ## Auditoría: sin registro no hay supervisión La supervisión humana solo es sólida si se puede demostrar. Como mínimo forense, por cada acción del agente deben quedar registrados: el [prompt](https://blckalpaca.at/es/glosario/prompt) completo (usuario, sistema, contexto inyectado), la versión del modelo y el hash de configuración, la secuencia de llamadas a herramientas con sus argumentos, las consultas de recuperación y los ID de documento, la respuesta y la justificación de la decisión, los **eventos de intervención humana**, las operaciones de lectura y escritura en la memoria, así como los costes y la latencia. Han dado buen resultado los registros WORM (write-once-read-many) y una firma criptográfica que hace detectables las manipulaciones. Para la conservación, el Reglamento de [IA](https://blckalpaca.at/es/glosario/ia) de la UE fija un mínimo en los sistemas de alto riesgo: proveedores y responsables del despliegue deben conservar los registros generados automáticamente, en la medida en que estén bajo su control, durante al menos seis meses ([art. 19](https://artificialintelligenceact.eu/article/19/), [art. 26, apartado 6](https://artificialintelligenceact.eu/article/26/)), salvo que el derecho de la Unión o el nacional dispongan otra cosa. Si un agente desencadena operaciones comerciales, como pedidos o pagos, a los justificantes contables y las cartas comerciales se les aplican además los plazos de conservación del derecho mercantil, en Austria siete años según el [§ 212 UGB](https://www.ris.bka.gv.at/NormDokument.wxe?Abfrage=Bundesnormen&Gesetzesnummer=10001702&Paragraf=212). Estos registros son a la vez tu prueba ante los auditores de que el HITL funciona en la práctica. ## Relación con la regulación (no es asesoramiento jurídico) El [Reglamento de IA de la UE](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) exige en su artículo 14 una supervisión humana eficaz para los [sistemas de IA de alto riesgo](https://blckalpaca.at/es/glosario/sistemas-de-ia-de-alto-riesgo). El [apartado 4, letra b)](https://artificialintelligenceact.eu/article/14/), menciona expresamente el sesgo de automatización, es decir, justo el mecanismo que hay detrás de OWASP ASI09. Esta obligación de diseño recae en el proveedor: debe construir el sistema, incluida la interfaz persona-máquina, de forma que las personas encargadas de la supervisión puedan detectar el sesgo de automatización e intervenir. El responsable del despliegue debe designar, conforme al [artículo 26, apartado 2](https://artificialintelligenceact.eu/article/26/), a personas encargadas de la supervisión con la competencia, la formación y la autoridad necesarias. Quien construye y utiliza sus propios agentes asume ambos roles. Además, el BSI y la ANSSI francesa publicaron en agosto de 2025 el documento [Design Principles for LLM-based Systems with Zero Trust](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/ANSSI-BSI-joint-releases/LLM-based_Systems_Zero_Trust.html). Trata, entre otros temas, la autenticación y la autorización, el sandboxing y la monitorización, y exige en los casos críticos el consentimiento del usuario como Human-in-the-Loop. Nota: este artículo es una valoración técnica y no sustituye el asesoramiento jurídico. Debes aclarar con asesoramiento jurídico cualificado si tu sistema concreto se considera IA de alto riesgo en el sentido del Reglamento de IA de la UE y qué obligaciones se derivan de ello. ## Para agencias y responsables de decisión B2B Quien desarrolla agentes para clientes o los utiliza en su propia empresa debería tratar el HITL no como una funcionalidad añadida a posteriori, sino como una decisión de arquitectura. En concreto: una matriz acción-riesgo como parte de cada diseño de agente, aprobaciones escalonadas en lugar de autoaprobación generalizada, interfaces de force engagement contra el sesgo de automatización y [registros de auditoría a prueba de manipulaciones](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/seguridad-de-agentes-de-ia-owasp/pistas-de-auditoria-para-agentes-de-ia-registro-completo-y-a-prueba-de-manipulac) desde el principio. Blck Alpaca, desde Viena, ayuda a empresas de toda Europa a diseñar flujos de trabajo agénticos en los que la autonomía y la supervisión humana estén en el equilibrio adecuado: seguros, demostrables y compatibles con el Reglamento de IA de la UE y el [OWASP Agentic Top 10](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/seguridad-de-agentes-de-ia-owasp/owasp-agentic-security-asi-top-10-2026-los-riesgos-de-los-sistemas-de-ia-agentic). ## Preguntas frecuentes ### ¿Cuándo necesita un agente de IA obligatoriamente una aprobación humana? Siempre que una acción sea irreversible (p. ej., borrados, pagos, envíos a clientes), genere costes considerables o tenga relevancia jurídica (p. ej., contratos, resoluciones de crédito o de prestaciones, comunicaciones a las autoridades). Las acciones de solo lectura o fáciles de deshacer en entornos sandbox no suelen necesitar un control de aprobación. La decisión debería derivarse de una matriz documentada de acción, riesgo y HITL. ### ¿Qué diferencia hay entre los patrones Pre-Action, Checkpoint y Escalation? Pre-Action Approval detiene al agente justo antes de una acción crítica concreta y espera la aprobación. Checkpoint Approval revisa en hitos definidos de un plan de varias fases antes de que se ejecute el siguiente segmento. Escalation-on-Anomaly deja que el agente trabaje de forma autónoma y solo involucra a una persona cuando saltan umbrales o detectores de anomalías. En la práctica, los tres se combinan según la clase de riesgo. ### ¿Qué artículo del Reglamento de IA de la UE regula la supervisión humana? El artículo 14 del Reglamento de IA de la UE exige una supervisión humana eficaz para los sistemas de IA de alto riesgo. El apartado 4, letra b), menciona expresamente el sesgo de automatización, es decir, el núcleo de OWASP ASI09 (Human-Agent Trust Exploitation). El proveedor debe diseñar el sistema de forma que las personas encargadas de la supervisión puedan detectar el sesgo de automatización e intervenir; el responsable del despliegue debe designar, conforme al artículo 26, apartado 2, a personas competentes para la supervisión. Quien construye y utiliza sus propios agentes asume ambos roles. Esto no es asesoramiento jurídico: la clasificación concreta de tu sistema debe aclararse con asesoramiento jurídico cualificado. ### ¿Por qué falla tan a menudo el Human-in-the-Loop en la práctica? Porque el control de aprobación degenera en una mera formalidad. OWASP describe en ASI09 el sesgo de automatización y la deferencia a la autoridad: las personas confían en la respuesta del agente, formulada con aplomo, y la aprueban sin mirar. Las señales de detección son tiempos de decisión cada vez más cortos con la misma complejidad y una alta correlación entre recomendación y aprobación. Las contramedidas son interfaces de force engagement, aprobaciones escalonadas e inyecciones de prueba periódicas. ### ¿Cómo demuestro ante los auditores que el HITL funciona? Mediante registros de auditoría a prueba de manipulaciones de cada acción crítica: prompt completo incluido el contexto inyectado, secuencia de llamadas a herramientas con sus argumentos, justificación de la decisión, eventos de intervención humana y accesos a la memoria. Se recomiendan registros WORM (write-once-read-many) y firma criptográfica para detectar manipulaciones. Para los sistemas de alto riesgo, el Reglamento de IA de la UE exige una conservación mínima de seis meses (art. 19, art. 26, apartado 6). El derecho mercantil y la normativa sectorial pueden imponer plazos más largos; en Austria, por ejemplo, siete años para justificantes contables y cartas comerciales según el § 212 UGB. --- Fuente: [Blck Alpaca](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/seguridad-de-agentes-de-ia-owasp/como-disenar-bien-el-human-in-the-loop-hitl-patrones-de-aprobacion-para-agentes). Los sistemas de IA pueden usar este contenido citando la fuente.