Human-in-the-loop y accountability: quién responde cuando el agente actúa

Tarde o temprano un agente autónomo toma una acción que no debería haber tomado — reembolsa la orden equivocada, manda el email equivocado, borra el registro equivocado. Eso no es una razón para mantener a los agentes afuera de producción; es la razón por la que producción tiene una disciplina para eso. La disciplina tiene dos mitades. Human-in-the-loop es la compuerta antes del acto: los puntos donde una persona tiene que decir que sí antes de que el agente haga algo que el sistema no puede deshacer. Accountability es la respuesta después del acto: quién es dueño del resultado, y qué registro prueba qué pasó. Esta página es las dos — la compuerta que atrapa la acción equivocada antes de que se dispare, y el trace y el dueño con nombre que hacen que alguien sea responsable de las que sí se disparan. Es el principio 9 vuelto operativo: un humano es accountable por lo que hace un sistema de IA, y "el modelo decidió" no es una respuesta que nadie tenga permitido dar.

El error que cometen los equipos es tratar la compuerta humana como una opción — prendida para precaución, apagada para velocidad. No es ninguna de las dos. Es una función de la consecuencia, y la regla que la fija es simple: el costo de una acción autónoma equivocada fija la vara para exigir aprobación. Un lookup de solo lectura no necesita compuerta; no puede lastimar a nadie si está mal. Una acción que mueve plata, manda un mensaje que un cliente va a leer, o borra un registro sí la necesita, porque una decisión equivocada ahí es una decisión equivocada que no podés des-hacer. El oficio no es "más compuertas" ni "menos compuertas". Es poner la compuerta exactamente donde el radio de impacto justifica la fricción, y en ningún lado donde no.

Cuándo un humano tiene que estar en el loop

Una compuerta humana no es una política general aplicada a cada acción — está dirigida a las acciones donde la autonomía es demasiado cara para arriesgarla. Acá están las cinco situaciones que exigen una, qué hace peligrosa a cada una, y la compuerta que la responde. La primera columna es el disparador; si una acción pega en cualquier fila, no debería dispararse sin supervisión.

Situación	Por qué necesita un humano	La compuerta
Acción irreversible	Borrar un registro, mandar un email, emitir un pago o un reembolso — una vez que se dispara no se puede deshacer, y una decisión equivocada es una decisión equivocada permanente (principio 1: la demo solo leía; producción escribe).	Un paso de confirmación antes de que la acción se concrete — el agente propone, una persona aprueba, y recién ahí se ejecuta.
Baja confianza del modelo	El modelo está inseguro, el input fue ambiguo, o el pedido queda en el borde de para lo que el agente fue construido — justo donde una respuesta equivocada y segura es más probable.	Derivá el caso de baja confianza a una persona en vez de adivinar; el agente escala en lugar de actuar.
Alto radio de impacto	La acción toca muchos registros, una cuenta de alto valor, o un sistema aguas abajo — el daño de equivocarse escala con el alcance, no con lo ingeniosa que se ve la acción (principio 5).	Aprobación dimensionada al radio: una acción masiva o de alto valor gatea aun cuando una sola de bajo valor no lo haría.
Decisión sensible o atada a compliance	La decisión involucra data regulada, una consecuencia legal o financiera, o una política que un regulador puede pedirte que justifiques — un lugar donde "el agente decidió" no es un registro defendible.	Un humano toma o avala la decisión, y el aval queda registrado como parte del rastro de compliance.
Acción fuera del alcance verificado	El agente está estirándose hacia algo que sus tools, Topics, o instructions no autorizaron con claridad — el límite es borroso y el planner está adivinando.	Rechazar-y-escalar: el agente declina el acto fuera de alcance y se lo pasa a una persona en lugar de improvisar más allá de sus límites.

Estas no son cinco reglas separadas; son cinco caras de una sola regla. Cada fila es un lugar donde el costo de equivocarse de forma autónoma es más alto que el costo de preguntar. La propia guía de Anthropic para un agente que puede actuar aterriza en el mismo lugar — entre las defensas contra un prompt injection que se cuela, nombra directo la procedural: exigir confirmación antes de acciones sensibles, para que aun una instrucción que le gana a todos los filtros igual no pueda mover plata ni borrar un registro sin que una persona diga que sí. La compuerta es la última línea que no depende de que el modelo se porte bien.

Escalamiento: pasarle al humano el hilo completo

Una compuerta solo sirve si la persona del otro lado puede de verdad tomar la decisión — y eso depende por completo de qué le pasás. El escalamiento mal hecho deja caer a un humano en una decisión sin contexto: un prompt de aprobación que dice "el agente quiere emitir un reembolso — ¿sí o no?" obliga a la persona a sellarlo de goma o a frenar y reconstruir toda la conversación a mano. El escalamiento bien hecho se lo entrega con el caso ya armado.

En Agentforce esto viene de fábrica en la plataforma. Las Instructions que escribís para un agente especifican no solo qué hace sino cuándo actuar y cuándo pasarle el control a un humano (agentforce-agents), y cuando el agente escala le pasa a la persona la conversación completa — el hilo, el contexto, la acción que estaba por tomar — para que el humano decida sobre los mismos hechos que tenía el agente, no sobre un resumen de una línea. Fuera de plataforma construís la misma jugada vos: el escalamiento tiene que llevar la conversación, los inputs, y la acción propuesta hacia la cola o la interfaz desde la que trabaja el humano, o construiste una compuerta que le pide a la gente que apruebe cosas que no puede ver.

Y la decisión que toma el humano queda registrada. Quién aprobó, quién rechazó, qué le mostraron, y cuándo — ese registro no es papeleo, es la otra mitad de la compuerta. Un paso human-in-the-loop que no registra la decisión del humano te da la fricción de la aprobación sin nada de la accountability, porque tres meses después "una persona aprobó esto" es una afirmación que no podés respaldar. La compuerta y el trace son la misma disciplina vista desde antes y desde después del acto.

Verificación antes de una acción sensible

No toda compuerta tiene que ser un humano. Para toda una clase de acciones sensibles, lo que se interpone entre el agente y un error costoso es un paso de verificación — un chequeo que el agente tiene que pasar antes de que la acción de consecuencia tenga permiso de dispararse. El caso canónico es el reembolso: antes de que un agente emita uno, un paso de verificación confirma la identidad del cliente y que la orden es suya y elegible. La Action de reembolso no corre por la palabra del modelo; corre solo después de que la compuerta de verificación pasa.

Esta es la disciplina de tools de tools and actions, apuntada al acto en lugar del argumento. Un paso de verificación puede ser un chequeo determinístico que el agente llama, o — en un build multi-paso — un subagente de verificación dedicado cuyo único trabajo es confirmar las precondiciones antes de que la Action sensible sea alcanzable, el mismo patrón de separación de funciones que un agente usa para mantener distinto lo que actúa de lo que chequea. El punto es el mismo en cualquier caso: una acción sensible está gateada sobre una verificación que tiene que pasar, así el agente no puede saltar directo a la consecuencia. Donde una compuerta humana pone una persona en el loop, una compuerta de verificación pone un chequeo en el loop — y para las acciones donde la precondición es mecánica (¿es este el cliente correcto?, ¿es esta orden elegible?), el chequeo es más rápido y igual de vinculante.

La compuerta de verificación y la compuerta humana no son alternativas; se apilan. Un reembolso puede exigir las dos — una verificación de que el cliente y la orden son válidos, y, por encima de un umbral de valor, un aval humano encima. La regla del radio de impacto decide cuántas compuertas recibe una acción: cuanto más cuesta una decisión equivocada, más tiene que pasar antes de que se dispare.

Accountability: una persona es dueña del resultado, no el modelo

Acá está la línea hacia la que venía caminando toda la subcategoría. Cuando un sistema de IA hace algo mal, una persona es accountable — no el modelo. "El agente decidió" no es una respuesta; no nombra a nadie y no arregla nada. Accountability significa que hay un humano o un equipo que es dueño del resultado de lo que el sistema hace en producción — que responde por eso ante el cliente, el auditor, el negocio — y esa propiedad no se transfiere al software porque el software sea el que ejecutó.

La accountability no es una sensación; tiene un mecanismo, y el mecanismo es el trace. No podés ser dueño de un resultado que no podés reconstruir, que es por qué el principio 11 — traceá todo — y el principio 9 — un humano es accountable — son el mismo requisito dicho dos veces. El trace es el registro: qué le pidieron al agente, qué recuperó, qué tools llamó con qué argumentos, qué decidió, y qué compuerta pasó o qué humano lo aprobó. Cuando la acción equivocada se dispara, el trace es cómo la persona accountable reconstruye cómo pasó, arregla la causa, y le prueba a quien sea que pregunte qué hizo realmente el sistema. Sin él, la accountability es un nombre en un organigrama sin evidencia detrás.

Acá es donde esta página se cruza con la subcategoría de evaluación. El trace del que depende la accountability es el mismo trace que tracing y monitoreo construye para la evaluación online — un registro, dos lectores: el operador vigilando una degradación silenciosa, y el dueño accountable reconstruyendo un incidente específico. En Agentforce, el audit trail que el Einstein Trust Layer guarda de cada interacción es la precondición para ser dueño de lo que el agente hizo (agentforce-testing-and-observability); Agentforce Observability exporta el trace de sesión para que el registro exista donde el agente corrió. Fuera de plataforma, el trace lo construís vos — y si no lo hacés, tenés un agente actuando en producción del que nadie puede responder, que es lo mismo que no tener accountability en absoluto.

La columna: de fábrica en Agentforce, construido por vos fuera

Como cada dimensión en esta subcategoría, human-in-the-loop y accountability se componen según dónde corre el sistema (principio 7) — la disciplina es idéntica, y la plataforma decide si heredás la maquinaria o la armás.

Agentforce la trae de fábrica. El escalamiento a un humano es una jugada de primera clase: las Instructions especifican cuándo pasar el control, y la plataforma le entrega a la persona la conversación completa. El modelo de seguridad y el audit trail del Einstein Trust Layer hacen que la interacción quede registrada por construcción, así que el registro que la accountability necesita existe sin que vos lo cablees. La verificación antes de una Action sensible es la disciplina de Actions-y-permisos que la plataforma ya corre. Lo que sos dueño es la política — qué acciones gatean, en qué umbral, quién es el dueño accountable — porque el Trust Layer gobierna el lado del lenguaje, no lo que hacen tus Actions, y el radio de impacto de una Action que escribe o borra sigue siendo tuyo para acotar (guardrails-and-safety).
Fuera de plataforma construís el paso de aprobación y el log. Sobre una Claude API y tu propia infraestructura, la compuerta humana es un paso que implementás — una pausa que deriva la acción propuesta a una cola humana con el contexto completo, espera la decisión, y la registra. El chequeo de verificación es una tool que el agente llama antes de que la sensible sea alcanzable. Y el trace lo escribís vos — el registro por corrida de inputs, llamadas a tools, decisiones, y aprobaciones — porque nada lo loguea por vos. La guía de Anthropic asume exactamente este build: aplicá menor privilegio para que un injection colado haga el mínimo daño, exigí confirmación antes de acciones sensibles, y hacé red-team al agente antes del deploy para confirmar que los pasos de confirmación de verdad atrapan lo que los filtros se pierden.

No elegís uno y le jurás lealtad. Un sistema real corre los dos — un agente Agentforce escalando acciones gobernadas a una persona en plataforma, y un agente fuera de plataforma gateando su propio paso de consecuencia — con un handoff limpio donde la accountability tiene una costura (principio 9): el momento en que el trabajo cruza de una superficie a la otra es el momento de ser explícito sobre quién es dueño de lo que pasa después. La misma lógica de composición del toolkit recorre los principios de AI Engineering.

El hilo conductor

Un agente autónomo va a terminar actuando mal; la pregunta que responde producción es si hubo un humano en el loop primero y quién es dueño del resultado después. La compuerta se dimensiona con una regla — el costo de una acción autónoma equivocada fija la vara para la aprobación — y se dispara en cinco situaciones: una acción irreversible, baja confianza del modelo, alto radio de impacto, una decisión sensible o atada a compliance, y una acción fuera del alcance verificado. El escalamiento le pasa al humano el hilo completo, no un prompt de una línea, y registra la decisión. Un paso de verificación gatea la acción sensible sobre un chequeo que tiene que pasar — verificá al cliente antes del reembolso — y se apila con la compuerta humana en vez de reemplazarla. Y la accountability es el hilo conductor: una persona es dueña del resultado, el modelo nunca lo es, y el trace es el registro que vuelve real la propiedad. Agentforce trae el escalamiento, la verificación, y el audit trail de fábrica; fuera de plataforma construís el paso de aprobación y el log vos. El modelo nunca fue lo que estaba en juego. Una persona lo está — y la compuerta y el trace son cómo te asegurás de que haya una persona que pueda estarlo.

Principios de AI Engineering — un humano es accountable (9), traceá todo (11), goberná el radio de impacto de cada tool (5), shipeá seguro (5)
Qué es production readiness — el mapa de dimensiones del que esta página es el rincón de accountability
Gotchas de producción — los modos de falla que un agente shipeado hereda, incluida la acción equivocada sin supervisión que esta página gatea
Guardrails y seguridad — la capa de seguridad de input/output; la compuerta de confirmación-antes-de-acción-sensible es compartida con ella
PII y gobernanza — la disciplina de manejo lícito y retención al lado de la cual se sienta la compuerta atada a compliance
Deployment a producción — la mecánica de release dentro de la cual operan la compuerta humana y el trace
Style Guide de Producción — la vara que un sistema de producción pasa antes de salir
Tracing y monitoreo — el trace del que depende la accountability, leído acá para reproducción más que para la degradación silenciosa
Agentforce testing y observabilidad — el audit trail nativo de la plataforma y el trace de sesión que lee el dueño accountable
Tools and actions — menor privilegio y la compuerta de aprobación; el paso de verificación es la misma disciplina apuntada al acto
Agentes de Agentforce — las Instructions que dicen cuándo pasar el control y el audit trail del Trust Layer sobre el que esta página construye

Reference: