Gobernar un agente de IA no es lo mismo que gobernar un chatbot

La pregunta que casi nadie se hace todavía

La mayoría de las políticas de IA que existen hoy en las empresas se escribieron pensando en sistemas que responden: un chatbot de atención al cliente, un generador de texto, un clasificador. Todos esperan una entrada humana y producen una salida — y ahí termina su ciclo de vida en cada interacción.

Un agente de IA rompe ese modelo. No espera una pregunta para actuar: planifica una secuencia de pasos, llama a herramientas y sistemas externos, y a veces toma decisiones intermedias sin que nadie las revise una por una. La pregunta que las políticas actuales casi nunca responden es: ¿qué pasa cuando el sistema no solo genera contenido, sino que ejecuta acciones con consecuencias reales?

Cinco piezas que un agente necesita, y un chatbot no

1. Un inventario que detecte deriva de permisos

Un chatbot tiene los mismos permisos el día que se despliega que un año después. Un agente, no: a menudo se le van añadiendo integraciones y accesos según se necesitan — un conector nuevo aquí, una API más allá — hasta que nadie recuerda ya la lista completa de lo que puede tocar. El inventario de un agente no es una foto fija, es un registro que hay que revisar porque el propio sistema cambia solo con el tiempo.

2. Límites de autorización explícitos, no implícitos

"El agente puede gestionar el calendario" no es un límite — es una intención. Un límite real dice: puede crear y mover eventos sin aprobación, pero cancelar uno con más de 5 asistentes requiere confirmación humana. La diferencia entre las dos frases es la diferencia entre una política que funciona y una que se descubre rota cuando ya ha pasado algo.

3. Un rastro de auditoría diseñado para reconstruir decisiones, no solo registrar texto

Guardar el prompt y la respuesta de un chatbot basta para auditarlo. Un agente que ejecuta 6 pasos para completar una tarea necesita que cada paso quede registrado — qué herramienta llamó, con qué datos, y por qué decidió ese camino y no otro. Sin eso, cuando algo sale mal, no hay forma de saber en qué paso empezó a torcerse.

4. Responsabilidad clara cuando varios agentes interactúan entre sí

Un agente casi nunca actúa solo — orquesta a otros, o recibe resultados de otro que a su vez llamó a un tercero. Cuando el error aparece al final de esa cadena, "¿de quién fue la culpa?" deja de tener una respuesta obvia si no se definió de antemano quién es responsable de cada eslabón.

5. Un procedimiento de escalado humano, no una promesa genérica de "supervisión"

Decir "hay supervisión humana" no es un procedimiento. Un procedimiento real define disparadores concretos — qué situación obliga al agente a parar y esperar a una persona — y qué pasa si esa persona no responde a tiempo. Sin esos dos detalles, la supervisión humana existe en el papel, pero no en la práctica.

El error más común: tratarlo como un chatbot con más pasos

La tentación es coger la política de uso aceptable que ya tienes para chatbots y añadirle una cláusula sobre agentes. El problema es que las 5 piezas de arriba no son variaciones de una política de chatbot — son documentos distintos, porque responden a una pregunta distinta: no "¿qué puede decir el sistema?", sino "¿qué puede hacer el sistema, y quién se entera si lo hace mal?".

Por dónde empezar, en orden

1. Inventario y clasificación de riesgo — igual que con cualquier sistema de IA, pero revisando la deriva de permisos.
2. Límites de autorización — qué puede hacer sin preguntar, qué necesita aprobación, qué está prohibido siempre.
3. Rastro de auditoría — antes de desplegar a producción, no después de un incidente.
4. RACI multiagente — si hay más de un agente interactuando, definir responsabilidad antes de que haga falta.
5. Procedimiento de escalado — disparadores concretos, no una promesa genérica.