¿Tu agente de IA sabe lo que no debe hacer?
Darle a un agente de IA acceso a código, nube o datos con una instrucción en el prompt no es controlarlo. Cuatro límites que permiten automatizar en serio con menos chance de que un error escale a incidente.
La pregunta que nadie escribe
Cuando un equipo conecta un agente de IA a algo que importa —un repositorio, una cuenta de nube, una base de datos, el sistema de tickets— suele escribir con cuidado qué tiene que hacer. Lo que muchas veces no escribe es qué no tiene que hacer. Y cuando lo escribe, lo escribe en el prompt: "no borres nada", "no toques producción", "pedí confirmación antes de desplegar".
Eso es una instrucción. No es un control.
La diferencia importa porque un modelo de lenguaje no obedece instrucciones como un programa ejecuta código: las interpreta. La mayoría de las veces las interpreta bien. El problema es la vez que no, y que ese día el agente tenía permiso para hacer lo que le pediste que no hiciera.
Por qué muchos equipos no se animan
La reacción razonable frente a ese riesgo es no automatizar nada que importe. El agente propone, una persona copia, pega y ejecuta. Es seguro, y es lento: se pagó la herramienta y se sigue trabajando a mano.
Y no pasa solo acá. Gartner pronostica que más del 40 % de los proyectos de agentes de IA se van a cancelar para fines de 2027, y entre las causas menciona controles de riesgo insuficientes. En el estudio de Deloitte de 2026, con más de 3.000 líderes de negocio y tecnología encuestados en 24 países, solo el 21 % dice tener un modelo de gobierno maduro para sus agentes. Y en el informe DORA 2025, el 90 % de los profesionales de tecnología encuestados usa IA en su trabajo, pero apenas el 24 % confía "mucho" o "muchísimo" en la calidad de lo que genera, y un 30 % confía poco o nada.
Conviene leer esas cifras con la cautela que merecen: las tres vienen de organizaciones que venden consultoría o plataformas de IA, y ninguna mide específicamente a la Argentina. Pero apuntan en la misma dirección: que el agente funcione no alcanza; también hay que poder confiar en dejarlo trabajar.
Cuatro límites que sí son controles
Ninguno de estos límites es nuevo. Son los mismos principios con los que se gobierna a cualquier persona con acceso a producción, aplicados a un actor que no se cansa y no pregunta si no se lo obliga.
1. Leer es libre; escribir, solo dentro de lo acordado. El agente puede consultar todo lo que necesite para entender el problema. Lo que cambia algo —un archivo, un recurso, un registro— y no está explícitamente permitido espera un "sí", y ese "sí" dice qué cubre. Lo que ya se decidió que es seguro, el agente lo hace solo. "Sí" a reiniciar un servicio no es "sí" a reiniciar todos.
2. El que propone no tiene la herramienta que ejecuta. Si el agente no debe borrar, no alcanza con decirle que no borre: no tiene que tener la capacidad de borrar. Los permisos se recortan en la credencial, no en el prompt. Una prohibición que el agente puede ignorar es una sugerencia.
3. Todo queda registrado: qué propuso, quién lo aprobó, qué pasó. No para auditar personas, sino para que cuando algo salga mal la pregunta sea "qué del sistema permitió esto" y tenga respuesta en minutos, no en una reunión.
4. Cada error se cierra con un cambio, no con una promesa. Cuando el agente hace algo inesperado, el cierre no es "vamos a tener más cuidado". Es una regla escrita, un permiso recortado o una barrera técnica, según cuánto podría costar que se repita. Saber cuándo alcanza con una regla y cuándo hace falta una barrera es buena parte del trabajo.
Esto no es burocracia
La objeción previsible es que todo esto frena. No necesariamente: bien diseñados, estos límites aceleran. Un equipo que no sabe qué puede hacer su agente termina aprobando todo a mano, que es la forma más lenta de usar una herramienta rápida. Un equipo con límites claros puede dejar que el agente haga solo todo lo que es seguro hacer solo, y concentrar la atención humana en las pocas decisiones que la necesitan.
El objetivo no es tener más aprobaciones. Es tener cambios rápidos, con límites que no dependen de que el modelo interprete bien una instrucción.
Tres preguntas para hacerte hoy
Si en tu organización ya hay un agente o un asistente de IA conectado a algo que importa, probá contestar esto sin mirar la configuración:
- ¿Qué puede hacer hoy ese agente sin que nadie lo apruebe?
- ¿Quién le dio ese permiso, y con qué criterio?
- La última vez que hizo algo que no esperaban, ¿qué cambió después: una regla, una barrera, o nada?
Si alguna respuesta fue "no sé", no es un problema de la herramienta. Es un dato sobre cómo está gobernada, y se puede corregir antes de que lo corrija un incidente.