GUÍA TÉCNICA
Human-in-the-loop: cómo supervisar un agente de IA
Un agente puede buscar información, utilizar herramientas y avanzar por un proceso sin que una persona decida cada paso. Esa capacidad es precisamente lo que obliga a diseñar dónde termina su autoridad.
La respuesta fácil es poner a una persona delante de cada acción sensible y pedirle que pulse «Aprobar». Pero si el revisor recibe demasiadas solicitudes, no entiende qué va a ocurrir o no puede detener realmente la acción, la presencia humana se convierte en un trámite.
RESPUESTA RÁPIDA
Human-in-the-loop (HITL) es un patrón en el que una persona interviene directamente en una decisión o acción del sistema. En un agente puede utilizarse para aprobar una herramienta, corregir una propuesta, aportar información, resolver una excepción o recuperar el control cuando se alcanza un límite. No todas las acciones necesitan esa intervención: la arquitectura debe decidir qué puede ejecutarse dentro de límites, qué requiere aprobación y qué debe escalarse o bloquearse.
La pregunta útil no es cuánta autonomía conceder en abstracto, sino qué puede hacer el agente sin pedir permiso, qué debe validar una persona y qué debería quedar bloqueado por diseño.
Qué significa human-in-the-loop en un agente de IA
En su forma más sencilla, HITL introduce a una persona dentro del ciclo de ejecución.
El agente trabaja hasta llegar a un punto donde no debería continuar por sí solo. Entonces el sistema puede detenerse, mostrar qué pretende hacer y esperar una decisión humana antes de seguir.
Ese patrón puede verse así:
Agente propone → ejecución se pausa → persona revisa → aprueba o rechaza → sistema continúa
OpenAI implementa este comportamiento en su Agents SDK mediante interrupciones de ejecución para llamadas a herramientas que necesitan aprobación. La ejecución puede convertirse en un estado persistible, esperar una decisión y continuar después desde el punto en que quedó pausada.
Microsoft documenta un patrón equivalente en Agent Framework: cuando una herramienta requiere aprobación, el workflow puede emitir una solicitud, esperar una respuesta externa y reanudar la ejecución posteriormente.
Pero HITL es más amplio que aprobar herramientas.
Una persona puede intervenir porque:
- la acción tiene consecuencias relevantes;
- falta información que el sistema no puede obtener;
- aparece una excepción;
- el agente ha superado un número razonable de intentos;
- la tarea queda fuera de su mandato;
- existe una contradicción entre políticas;
- alguien debe asumir una decisión reservada expresamente a una persona.
Por eso, al diseñar supervisión conviene separar varios mecanismos que suelen agruparse bajo la misma etiqueta.
Supervisar no es lo mismo que aprobar
Aprobación, escalado, corrección, interrupción y monitorización no resuelven el mismo problema.
Aprobación
El agente ya sabe qué acción quiere ejecutar, pero necesita autorización.
Por ejemplo, preparar un reembolso puede ser automático, pero emitirlo cuando el caso supera los límites definidos puede exigir aprobación. La persona decide si esa acción concreta puede producirse.
Handoff o escalado
El agente no debería seguir resolviendo el caso.
Puede ocurrir porque falta información, el proceso ha salido de su alcance, ha alcanzado un límite de reintentos o la decisión pertenece a una persona. Aquí no preguntamos simplemente «¿puedo hacer esto?». El sistema devuelve el trabajo.
Corrección
La persona no acepta ni rechaza sin más. Modifica la propuesta. Puede cambiar un destinatario, ajustar un importe, eliminar una frase o seleccionar una alternativa antes de continuar.
No todas las plataformas implementan este patrón de la misma manera, pero desde el punto de vista de diseño es distinto de un sí/no.
Interrupción
Una persona detiene una ejecución que ya está en curso porque observa que está desviándose, ha cambiado el contexto o aparece un riesgo.
Monitorización
El sistema opera sin solicitar una decisión en cada caso, pero una persona observa su comportamiento y puede intervenir.
El error consiste en llamar «supervisión humana» a cualquier presencia de una persona. Lo que importa es qué autoridad tiene esa persona y en qué momento puede ejercerla.
El punto de control debe estar antes del efecto
Si queremos impedir una acción, revisar después de que haya ocurrido llega tarde.
Para una operación sensible, el patrón debería ser:
Proponer → pausar → revisar → aprobar o rechazar → ejecutar → registrar
No:
Ejecutar → avisar → revisar
La segunda arquitectura puede servir para auditoría, monitorización o aprendizaje posterior, pero ya no evita el efecto inicial.
La diferencia se entiende mejor al separar preparación y ejecución. Un agente puede redactar un correo sin enviarlo, preparar una modificación sin aplicarla, calcular un reembolso sin emitirlo o proponer cancelar un pedido sin cancelarlo.
Eso permite mover la aprobación hasta el último punto razonable antes del efecto real.
El control debe existir antes del efecto.
El gate debe aparecer antes del efecto
La revisión preventiva puede detener una acción; la revisión posterior solo puede explicar o corregir algo que ya ocurrió.
Equivalente textual del diagrama
Patrón preventivo: proponer, pausar, revisar, aprobar o rechazar, ejecutar y registrar.
Patrón posterior: ejecutar, avisar y revisar. Este segundo patrón sirve para monitorización o auditoría, pero no evita el efecto inicial.
Esta separación también mejora la experiencia del revisor. En lugar de interrumpir a una persona durante cada paso, el sistema puede trabajar, reunir evidencia, preparar una propuesta y pedir juicio humano justo antes de la acción que cambia algo fuera del propio agente.
No todas las acciones deberían pedir permiso
Exigir aprobación para cada llamada a una herramienta parece prudente, pero puede convertirse en una arquitectura peor.
Una forma más útil es clasificar las acciones por su efecto.
Lectura y preparación
Consultar una fuente autorizada, leer el estado de un pedido, calcular una cifra o preparar un borrador suele tener un impacto distinto de modificar un sistema.
Eso no significa que toda lectura sea inocua: puede existir información sensible. Pero, una vez establecidos los permisos, no siempre aporta valor pedir una aprobación manual para cada consulta.
Acciones acotadas y reversibles
Algunas modificaciones pueden ejecutarse automáticamente si están muy limitadas y existe una forma clara de revertirlas. Actualizar una etiqueta interna o crear un borrador dentro de una carpeta determinada puede tener un perfil de riesgo muy diferente de enviar una comunicación externa.
Acciones sensibles
Cuando una decisión afecta dinero, personas, datos relevantes, obligaciones o relaciones externas, la necesidad de aprobación aumenta.
OpenAI recomienda especialmente intervención humana ante acciones sensibles, irreversibles o de alto impacto. Microsoft utiliza un criterio parecido para acciones difíciles de revertir o que afectan a personas, dinero o cumplimiento.
Acciones fuera de mandato
Hay tareas que el agente no debería poder ejecutar ni siquiera con una interpretación creativa de su objetivo.
En esos casos, la respuesta no es «pedir aprobación». Puede ser bloquear la capacidad o escalar el caso.
Una política razonable podría producir cuatro resultados:
Permitir → permitir con límites → requerir aprobación → bloquear o escalar
No es una escala universal. Es una forma de pensar qué autoridad necesita cada acción.
Cómo decidir dónde colocar un approval gate
No existe una lista única de herramientas que siempre deban requerir aprobación. El mismo tipo de acción puede tener consecuencias muy distintas según el contexto.
Impacto
¿Qué ocurre si la acción es incorrecta? Una mala etiqueta interna y una transferencia bancaria no pertenecen a la misma categoría.
Reversibilidad
¿Podemos deshacerla de forma fiable? Cuanto más irreversible sea una acción, más fuerte debería ser el control previo.
Alcance
¿Afecta a un elemento o a miles? Una acción de bajo riesgo repetida en un lote enorme puede producir un efecto agregado relevante.
Efecto externo
¿La acción permanece dentro del sistema o alcanza a clientes, proveedores, empleados u otras organizaciones? Enviar, publicar, cancelar, pagar o borrar suelen tener un significado distinto de preparar o recomendar.
Sensibilidad
¿Intervienen datos personales, información confidencial, dinero o decisiones con consecuencias sobre personas?
Ambigüedad
¿El caso es habitual o presenta una excepción poco conocida? La novedad puede ser una buena razón para escalar incluso cuando la operación habitual se automatiza.
Capacidad de limitar técnicamente
¿Podemos reducir el riesgo mediante permisos, límites de importe, alcance de herramientas, entornos aislados o validaciones?
La decisión de poner una persona en el bucle no debería tomarse aislada del resto de controles.
Ejemplo orientativo — no es un caso de cliente.
Imaginemos un agente que ayuda a gestionar incidencias de clientes. Puede leer el ticket y consultar el estado del pedido automáticamente porque solo utiliza accesos de lectura ya autorizados. Puede preparar un diagnóstico y un borrador de respuesta. Si la política permite una acción pequeña, reversible y perfectamente acotada, la empresa podría decidir automatizarla dentro de límites. Si el agente propone una acción con impacto mayor, el workflow puede pausarse para aprobación. Y si encuentra una excepción que ninguna política cubre, en lugar de pedir «sí/no» puede transferir el caso a una persona.
La arquitectura no se decide por la etiqueta «agente». Se decide por acción, riesgo, autoridad y control. Si quieres profundizar en cómo repartir esas funciones entre reglas y comportamiento agéntico, puedes ver agente de IA vs automatización.
La autoridad se diseña según el efecto
Impacto, reversibilidad, alcance y sensibilidad ayudan a decidir si una acción puede ejecutarse, necesita límites, requiere aprobación o debe escalarse.
Equivalente textual del diagrama
- PERMITIR: Lectura o acción muy acotada.
- LIMITAR: Ejecución dentro de permisos y umbrales.
- APROBAR: Efecto sensible o difícil de revertir.
- ESCALAR / BLOQUEAR: Fuera de mandato o riesgo no aceptable.
Qué debe ver una persona antes de aprobar
Un buen gate no pregunta simplemente:
¿Aprobar?
La persona necesita comprender qué se está autorizando.
Dependiendo del caso, la interfaz debería mostrar suficiente información sobre:
- la acción propuesta;
- el objeto, cuenta, cliente o sistema afectado;
- los parámetros exactos;
- la razón por la que el agente la propone;
- la evidencia utilizada;
- el efecto esperado;
- si la acción puede revertirse;
- las alternativas disponibles;
- qué ocurrirá si se aprueba;
- qué ocurrirá si se rechaza;
- cuándo caduca la solicitud si el contexto puede cambiar.
No todos los campos son necesarios para todas las decisiones. La idea es otra: el humano necesita un paquete de decisión, no un botón aislado.
Microsoft recomienda proporcionar suficiente contexto para que quien revisa pueda decidir con rapidez sin convertir el proceso en un cuello de botella.
También conviene distinguir explicación de evidencia. Que el agente diga «recomiendo aprobar porque es correcto» aporta poco. Es más útil mostrar qué política aplicó, qué datos observó, qué condición activó la revisión y qué parámetros se enviarán realmente a la herramienta.
La persona debe poder verificar la decisión sin reconstruir manualmente todo el proceso.
Una aprobación sin contexto es solo otro clic.
Qué ocurre después de aprobar o rechazar
La decisión humana no debería ser el final de la arquitectura.
Si se aprueba
El sistema puede necesitar revalidar que el contexto sigue siendo válido antes de ejecutar. Esto es importante si la aprobación tarda minutos u horas: el estado del pedido, la disponibilidad o los permisos podrían haber cambiado.
Aprobar → revalidar → ejecutar → registrar → continuar
Si se rechaza
La herramienta sensible no se ejecuta. El agente puede recibir la decisión y, según el diseño, terminar, pedir más información, proponer una alternativa, replanificar dentro de límites o escalar definitivamente.
OpenAI permite devolver un mensaje específico al agente cuando una llamada es rechazada, de manera que la ejecución pueda continuar sabiendo que esa acción no fue autorizada.
Si la persona modifica la propuesta
Cuando la interfaz y el proceso lo permiten, la aprobación puede transformarse en corrección: el humano ajusta parámetros y la nueva acción vuelve a validarse antes de ejecutarse.
Si nadie responde
Este caso debe diseñarse explícitamente. Una aprobación sensible no debería convertirse en autorización automática simplemente porque ha pasado tiempo, salvo que exista una política consciente que lo permita.
El sistema puede mantener la tarea pausada, caducar la solicitud, cancelarla o escalarla a otro responsable.
Pausar y reanudar
Una aprobación tampoco tiene que ser inmediata. OpenAI documenta estados de ejecución serializables para conservar una tarea interrumpida y reanudarla más tarde. Microsoft Agent Framework también contempla workflows que esperan una respuesta externa antes de continuar.
Eso permite crear colas de revisión o procesos duraderos en lugar de obligar al agente y al humano a permanecer conectados simultáneamente.
El problema de approval fatigue
Pedir permiso parece un control barato. A gran escala deja de serlo.
Anthropic publicó en 2026 que los usuarios de Claude Code aprobaban aproximadamente el 93 % de las solicitudes de permiso observadas en ese producto. La compañía detectó además que, a medida que aumentaba el número de aprobaciones, la atención dedicada a cada una disminuía.
Ese porcentaje pertenece a Claude Code y a su población de usuarios. No puede extrapolarse como una tasa universal para agentes empresariales.
Lo que sí demuestra es un problema de diseño real: la supervisión puede degradarse cuando interrumpe demasiado.
Si una persona ve cincuenta veces al día el mismo mensaje «¿Permitir esta acción?», la interacción puede terminar pareciéndose más a un hábito que a una revisión consciente.
El objetivo no debería ser maximizar la cantidad de gates. Debería ser concentrar la atención humana donde cambia la decisión.
Algunas estrategias son:
- no pedir aprobación para operaciones puramente informativas ya autorizadas;
- aplicar reglas condicionales según parámetros;
- limitar técnicamente la herramienta;
- utilizar entornos aislados;
- permitir automáticamente operaciones claramente acotadas;
- elevar solo excepciones o acciones de mayor impacto.
Anthropic describe precisamente cómo combinó permisos con sandboxing para reducir solicitudes triviales en Claude Code.
Un control que el usuario deja de leer deja de controlar bien.
Human-in-the-loop no sustituye permisos y guardrails
Este es uno de los errores más peligrosos del diseño superficial de agentes:
«Como hay una persona aprobando, podemos darle al agente acceso amplio.»
No.
Una persona puede equivocarse, aprobar por rutina o no comprender una acción técnica. HITL debería formar parte de una defensa por capas, no reemplazarla.
Una arquitectura puede combinar:
- Permisos mínimos. El agente solo puede acceder a los sistemas y operaciones que necesita.
- Límites técnicos. Importes, rutas, dominios, volumen, tipos de archivo o entornos acotados.
- Validaciones automáticas. Comprobaciones antes de la ejecución.
- Aprobación humana. Solo cuando aporta juicio real.
- Registro y monitorización. Qué se propuso, quién aprobó y qué terminó ejecutándose.
Anthropic distingue de forma explícita la supervisión mediante human-in-the-loop del containment: limitar técnicamente aquello que el agente puede hacer incluso si su comportamiento falla.
Las dos capas resuelven problemas diferentes.
Por ejemplo, aunque una persona apruebe enviar un correo, la herramienta utilizada por el agente no necesita por ello acceso a todos los buzones de la organización ni a toda la base de clientes.
Aprobar una acción no debería ampliar los permisos del sistema más allá de lo necesario para ejecutarla.
La persona no es la única barrera
La supervisión humana funciona mejor como una capa dentro de una arquitectura con permisos, límites, validaciones y trazabilidad.
Equivalente textual del diagrama
- PERMISOS: Acceso mínimo necesario.
- LÍMITES Y VALIDACIONES: Alcance, volumen, parámetros y reglas.
- HITL: Juicio humano donde aporta control.
- EJECUCIÓN: Acción acotada y verificable.
- REGISTRO: Qué ocurrió y quién autorizó.
Approval y handoff resuelven problemas distintos
Approval
El agente dispone de una acción válida y necesita autorización antes de ejecutarla.
La pregunta es: «¿Puedo hacer esto?»
Handoff
El agente ha llegado a un punto en el que no debería continuar resolviendo el caso.
La pregunta pasa a ser: «¿Quién debe hacerse cargo ahora?»
OpenAI recomienda intervención humana tanto para acciones de alto riesgo como cuando el agente supera umbrales de fallo, por ejemplo después de varios intentos sin resolver correctamente la intención del usuario.
Un buen sistema debe poder reconocer que detenerse también puede ser una salida correcta.
Algunas condiciones de handoff pueden ser:
- información insuficiente;
- excepción no cubierta;
- ambigüedad persistente;
- conflicto entre políticas;
- demasiados intentos;
- acción fuera de alcance;
- decisión expresamente reservada a una persona.
El objetivo de la supervisión no es conseguir que el agente termine siempre la tarea. Es conseguir que sepa cuándo no debe terminarla solo.
HITL, HOTL y Human in Command
No toda intervención humana ocurre en el mismo punto del sistema.
datos.gob.es utiliza tres conceptos útiles para situar diferentes formas de supervisión.
Human in the Loop (HITL)
La persona interviene directamente en una decisión concreta antes de que el sistema continúe. Es el patrón típico de aprobación, corrección o validación.
Human on the Loop (HOTL)
El sistema puede operar de forma más autónoma mientras una persona monitoriza el proceso y mantiene capacidad de intervenir. Puede ser útil cuando revisar cada operación individual sería impracticable, pero necesitamos vigilancia y capacidad de parada.
Human in Command (HIC)
La intervención se sitúa en un nivel de gobernanza. Las personas determinan para qué puede utilizarse el sistema, qué límites tiene, qué nivel de riesgo es aceptable, qué métricas se revisan y cuándo debe modificarse o detenerse.
No son tres niveles de madurez ni una progresión obligatoria. Pueden coexistir.
Un agente puede tener un mandato definido mediante Human in Command, operar habitualmente bajo monitorización y detenerse para HITL ante ciertas acciones.
Qué significa supervisión humana efectiva
Existe una diferencia entre tener una persona en el proceso y diseñar una supervisión que realmente pueda modificar el resultado.
El Reglamento de IA de la Unión Europea ofrece un marco útil para entender esa diferencia en los sistemas clasificados como de alto riesgo. Su artículo 14 exige que la supervisión humana sea efectiva y proporcional al riesgo, al nivel de autonomía y al contexto de uso.
Entre las capacidades que contempla para las personas encargadas de supervisar se encuentran, cuando corresponda:
- comprender capacidades y limitaciones del sistema;
- detectar anomalías;
- ser conscientes del riesgo de sesgo de automatización o automation bias;
- interpretar adecuadamente la salida;
- ignorarla, revocarla o revertirla;
- intervenir;
- detener el sistema de forma segura.
Esto no significa que todo agente empresarial esté sujeto a ese régimen ni que toda implementación deba utilizar los mismos controles. La clasificación jurídica depende del sistema y de su uso concreto.
Pero el principio de diseño es útil mucho más allá de la norma:
Una persona nominalmente presente no constituye supervisión efectiva si no puede comprender, cuestionar o detener lo que está ocurriendo.
Este artículo describe arquitectura técnica y operativa; la aplicación concreta del Reglamento de IA debe analizarse para cada sistema y no constituye asesoramiento jurídico.
Un framework para diseñar la supervisión antes de desplegar
Antes de construir pantallas de aprobación, conviene mapear el proceso y responder estas preguntas.
¿Qué acciones solo leen información?
Separa consultas, búsquedas y operaciones que no producen un efecto externo de aquellas que modifican sistemas o afectan a terceros.
¿Qué acciones modifican sistemas?
Distingue preparar de ejecutar. Una propuesta puede automatizarse aunque la modificación final necesite otra autoridad.
¿Qué acciones afectan a terceros?
Mensajes, pagos, cancelaciones, publicaciones y cambios que afectan a personas merecen un análisis específico.
¿Qué puede revertirse?
Define qué significa reversible en la práctica y durante cuánto tiempo puede deshacerse una operación.
¿Qué límite reduce el impacto potencial?
Permisos, volumen, importe, alcance, entorno, dominios o tipos de operación pueden acotar una capacidad.
¿Qué requiere aprobación?
La regla debe depender del efecto y del contexto, no únicamente del nombre de la herramienta.
¿Quién tiene autoridad para aprobar?
No todo usuario debería poder autorizar cualquier acción. La identidad del revisor forma parte del control.
¿Qué información necesita esa persona?
Diseña el paquete de decisión antes de diseñar el botón de aprobar.
¿Qué ocurre si rechaza o no responde?
La tarea debe poder pausar, caducar, cancelar o escalarse sin convertir el silencio en aprobación accidental.
¿Cómo reanuda el agente?
La ejecución debe conservar suficiente estado para continuar sin repetir acciones ni perder el contexto relevante.
¿Qué quedará registrado?
Debe poder reconstruirse qué se propuso, qué se aprobó o rechazó, quién decidió y qué se ejecutó finalmente.
¿Cuántas aprobaciones esperamos generar?
Un sistema que produce cientos de interrupciones puede estar desplazando el trabajo en lugar de diseñar bien la autonomía.
¿Qué señal indicará que el gate está mal diseñado?
Aprobación casi automática, solicitudes caducadas, búsqueda manual de contexto o frecuentes correcciones posteriores son señales útiles.
La supervisión debería evaluarse como parte del sistema, no instalarse una vez y olvidarse. En cómo evaluar un agente de IA antes y después de producción explicamos cómo convertir approvals, handoffs, acciones prohibidas y outcomes en criterios verificables.
Si además necesitas decidir qué partes de un proceso deben seguir siendo deterministas y cuáles justifican comportamiento agéntico, el artículo agente de IA vs automatización desarrolla esa decisión. Para entender el sistema completo, puedes volver a qué es un agente de IA y cómo funciona.
Preguntas frecuentes
¿Qué significa human-in-the-loop?
Es un patrón en el que una persona interviene directamente en una decisión o acción del sistema. En agentes de IA suele utilizarse para aprobar o rechazar acciones, aportar información, corregir una propuesta o recuperar control cuando el agente alcanza un límite.
¿Todos los agentes necesitan aprobación humana?
No. Algunos agentes realizan tareas de bajo impacto, solo lectura o completamente reversibles dentro de permisos muy acotados. La necesidad de aprobación depende de las acciones, el riesgo, la reversibilidad, el contexto y los controles existentes.
¿Qué diferencia hay entre HITL y human-on-the-loop?
En HITL la persona participa directamente en una decisión concreta antes de continuar. En Human on the Loop el sistema puede operar sin aprobación caso por caso, mientras una persona supervisa y mantiene capacidad de intervenir.
¿Qué acciones debería aprobar una persona?
No existe una lista universal. Las acciones difíciles de revertir, sensibles o con consecuencias relevantes sobre personas, dinero, datos o sistemas suelen justificar más control. También importan el alcance, el volumen y los límites técnicos.
¿Un agente sigue siendo autónomo si necesita aprobaciones?
Sí. La autonomía no es binaria. Un agente puede decidir muchos pasos por sí mismo y detenerse únicamente en determinadas fronteras de autoridad. Diseñar esas fronteras es parte del sistema.
¿Qué ocurre si nadie responde a una aprobación?
Debe definirse por diseño. La tarea puede permanecer pausada, caducar, cancelarse o escalarse. Para acciones sensibles, un tiempo de espera no debería convertirse accidentalmente en aprobación automática.
¿HITL sustituye guardrails y permisos?
No. La aprobación humana es una capa adicional. Permisos mínimos, validaciones automáticas, aislamiento, límites y registros siguen siendo importantes porque el revisor también puede equivocarse o aprobar por rutina.
¿Puede una persona detener un agente que ya está ejecutándose?
Puede hacerlo si la arquitectura ofrece una capacidad de interrupción o parada. Ese patrón es distinto de la aprobación previa, pero forma parte de una supervisión bien diseñada cuando las ejecuciones pueden durar o producir múltiples acciones.
Fuentes y lecturas recomendadas
Las fuentes siguientes sostienen los patrones de aprobación, pausa y reanudación, la diferencia entre supervisión y límites técnicos, el problema de la fatiga de aprobaciones y el contexto europeo de supervisión efectiva.
- 01OpenAI — A practical guide to building agents (enlace externo)openai.com
Trata la intervención humana ante umbrales de fallo y acciones sensibles, irreversibles o de alto impacto.
- 02OpenAI Agents SDK — Human-in-the-loop (enlace externo)openai.github.io
Documenta aprobación de herramientas, interrupciones, rechazo, persistencia de estado y reanudación de ejecuciones.
- 03Microsoft Agent Framework — Human-in-the-loop workflows (enlace externo)learn.microsoft.com
Documenta pausa, solicitud de input externo, aprobación de herramientas y reanudación de workflows.
- 04Microsoft — Apply responsible AI (enlace externo)learn.microsoft.com
Recomienda aprobación humana para acciones difíciles de revertir o que afectan a personas, dinero o cumplimiento, además de suficiente contexto para el revisor.
- 05Anthropic — How we contain Claude across products (enlace externo)anthropic.com
Distingue supervisión humana de containment y analiza el problema de approval fatigue en Claude Code.
- 06Anthropic — Measuring AI agent autonomy in practice (enlace externo)anthropic.com
Analiza cómo cambia la supervisión en uso real y subraya la capacidad efectiva de monitorizar e intervenir.
- 07datos.gob.es — Human in the Loop, Human on the Loop y Human in Command (enlace externo)datos.gob.es
Explica diferentes mecanismos de supervisión humana y su función dentro de sistemas de IA.
- 08Reglamento (UE) 2024/1689 — artículo 14 (enlace externo)eur-lex.europa.eu
Define requisitos de supervisión humana para sistemas de IA de alto riesgo y capacidades de las personas responsables de esa supervisión.
Sobre el autor
Elvis Mendoza, fundador de Agentes Como Servicio. Trabaja en el diseño de producto, la arquitectura de soluciones, el diseño de agentes y flujos de trabajo y la construcción de software asistida por IA para conectar procesos, datos, herramientas y supervisión humana alrededor de necesidades empresariales concretas.
¿Qué decisiones debería poder tomar tu agente sin pedir permiso?
Antes de automatizar una acción real conviene definir qué puede hacer el sistema por sí solo, qué debe aprobar una persona y qué debería quedar bloqueado por diseño.
En Agentes Como Servicio diseñamos estas fronteras alrededor del proceso real: herramientas acotadas, permisos, validaciones, puntos de aprobación y escalado allí donde el efecto de una decisión lo justifica.
Solicitar acceso