Quién responde cuando responde un agente

La pregunta que decide si un agente llega a producción no es técnica. Es de quién es el resultado cuando sale mal.

Carlos Andrés Ramírez · 2026-08-20

Casi todas las conversaciones sobre agentes empiezan por la capacidad. Qué puede hacer el modelo, hasta dónde llega, qué tan bueno es. Y se atascan en un sitio completamente distinto: qué pasa el día que hace algo que nadie quería.

El patrón se repite con la suficiente frecuencia como para dejar de tratarlo como una coincidencia. Un equipo construye un agente que funciona. Lo demuestra. Todo el mundo asiente. Y entonces el proyecto entra en una fase que nadie planificó, que puede durar meses, en la que el agente ya no se mejora: se discute.

Lo que se discute nunca es la precisión. Es una pregunta mucho más simple, y mucho más incómoda: si este agente aprueba un descuento que no tocaba, ¿de quién es el error?

Aquí conviene separar dos preguntas que se mezclan sin querer. Quién responde legalmente cuando un agente causa un daño lo resuelve un tribunal o un contrato, caso por caso, y ya hay despachos especializados en eso. Quién responde dentro de la empresa, todos los días, antes de que pase nada, es una pregunta distinta, y nadie se la delegó al despacho ni al proveedor de la plataforma. Comprar un agente con panel de auditoría tampoco la resuelve: el panel registra qué decidió el agente, pero nunca dice quién decidió que pudiera decidir eso solo.

El síntoma

La responsabilidad no se delega hacia arriba.

Cuando una organización no ha decidido de quién es el resultado, la respuesta por defecto es escalarlo. El agente propone y una persona confirma. Sobre el papel suena prudente. En la práctica es la forma más cara de no automatizar nada: se ha construido un sistema que hace el trabajo dos veces, una el agente y otra quien lo revisa, y se ha añadido una espera en medio.

• El agente propone, pero nadie tiene autoridad para dejar de revisarlo.
• La revisión no se mide, así que no se sabe cuántas veces corrige algo de verdad.
• Cada excepción sube un nivel, y el nivel de arriba no tiene contexto para decidirla.
• El equipo que construyó el agente no es el que responde por sus decisiones.
• No hay un umbral escrito a partir del cual el agente decide solo.

El problema detrás

Un agente no es una herramienta. Ocupa un puesto.

Una herramienta la usa alguien, y ese alguien responde por el resultado. Un agente actúa en nombre de la organización dentro de un proceso, y eso lo acerca mucho más a un puesto de trabajo que a un software. Los puestos tienen un ámbito de decisión, un jefe, un umbral a partir del cual consultan y una medida de si lo están haciendo bien. Los agentes que llegan a producción tienen esas cuatro cosas. Los que se quedan en piloto, ninguna.

Si no puedes nombrar a la persona que responde por lo que decide el agente, no tienes un agente en producción: tienes una demo con turno de guardia.

BECOME

Qué cambia

Cuatro decisiones, antes de la primera línea de código.

Ámbito

Qué decisiones entran dentro del agente y cuáles no. Escrito como una lista cerrada, no como un principio general.

Dueño

Una persona nombrada que responde por el resultado agregado. No el equipo de IA: quien responde hoy por ese proceso.

Umbral

El punto exacto por encima del cual el agente consulta: un importe, un nivel de riesgo, un nivel de confianza. Un número, no un criterio.

Medida

Qué se mira para saber si funciona, y cada cuánto. Incluye cuántas veces la revisión humana cambió algo de verdad.

Ninguna de las cuatro es técnica, y las cuatro son bloqueantes. Por eso el trabajo de diseño va antes que el de construcción: un agente construido sin ellas funciona igual de bien en la demostración y no llega nunca a operar.

Coge el agente que tengas parado ahora mismo y responde las cuatro preguntas por escrito, en una página. Si alguna no tiene respuesta, ahí está el motivo por el que no ha escalado. Y no era el modelo.

Revisemos tu agente parado