Por qué decirle a un agente de IA "no hagas esto" no es una estrategia de seguridad
Los agentes de IA son no determinísticos: el prompt no garantiza nada. La seguridad real se construye con permisos, guardrails determinísticos y control humano.
Iván Itzcovich
Co-fundador
GPT-5.6 salió hace dos semanas. Le alcanzaron unos días para esto:
No es un caso aislado. En abril de 2026, un agente de IA borró la base de datos de producción de una empresa — y todos sus backups — en nueve segundos, corriendo sobre Claude Opus 4.6, un modelo de frontera en el que todos confiamos y que muchos usamos a diario.
Mientras leés esto, miles de equipos están conectando agentes a sus sistemas con más permisos de los que deberían, confiando en que el prompt se porte bien. Este artículo es sobre por qué esa confianza está mal puesta — y qué poner en su lugar.
Los agentes de IA son no determinísticos por diseño
Un sistema determinístico produce outputs que podés predecir con 100% de confianza: misma entrada, misma salida, siempre. Un modelo de lenguaje no funciona así — no ejecuta reglas: genera respuestas probables. La misma instrucción, en el mismo contexto, puede producir acciones distintas en dos ejecuciones diferentes. Esa flexibilidad es exactamente lo que los hace útiles — manejan situaciones que nadie previó — y exactamente lo que los hace impredecibles.
El problema no es la calidad del modelo: uno bueno sigue las instrucciones la enorme mayoría de las veces. El problema es que "la enorme mayoría de las veces" es una probabilidad — y en volumen, el complemento de esa probabilidad deja de ser teórico:
Lo que "casi siempre" significa en volumen
Confiabilidad por ejecución
Conversaciones por mes: 10.000
Probabilidad de al menos un incidente al mes
>99,99%
Incidentes esperados al mes
500
P(al menos uno) = 1 − pⁿ. Elegí la confiabilidad que quieras: con volumen suficiente, el incidente llega igual.
Por eso ningún prompt, por más detallado que sea, garantiza un comportamiento. "Nunca borres datos" es una instrucción que el modelo va a seguir casi siempre. Y "casi siempre" no es un estándar de seguridad.
El modelo de seguridad correcto: todo lo que puede pasar, va a pasar
En seguridad, un "modelo" es el conjunto de supuestos sobre los que diseñás el sistema. En la web, el supuesto se define por superficie, no por intención: una URL accesible sin autenticación se considera pública aunque nunca la hayas publicado; algo servido por HTTP se asume leído aunque nadie lo esté mirando. No se discute si "en la práctica" alguien la encontró — se diseña como si ya hubiera pasado.
Con agentes de IA el modelo es el mismo, pero sobre acciones en vez de datos:
Toda acción que el agente puede ejecutar, asumí que la va a ejecutar — se lo hayas pedido o no.
No es pesimismo: es la consecuencia directa del no determinismo que muestra el contador de arriba. Si una herramienta está disponible, con suficiente volumen algún camino de razonamiento va a llegar a ella. Por eso la pregunta de diseño nunca es "¿cuándo la va a usar?" sino "¿qué pasa el día que la use?" — y todo lo que sigue en este artículo es una forma de que esa respuesta sea aburrida.
Promptear "no hagas X" no es un control de seguridad
En los incidentes de arriba, los agentes tenían reglas que prohibían exactamente lo que hicieron. La versión doméstica del mismo fenómeno, instrucción explícita incluida:
Una instrucción en el prompt es una sugerencia fuerte, no una barrera. La barrera tiene que existir afuera del modelo.
Cómo se resuelve: permisos, guardrails y control humano
La seguridad en sistemas con agentes de IA se construye igual que siempre se construyó la seguridad en software: con controles que se cumplen el 100% de las veces, sin importar qué "quiera" hacer el modelo. Tres mecanismos.
1. Permisos mínimos: que no pueda hacer lo que nunca debería hacer
Si el agente no tiene físicamente el permiso, no importa cuánto se confunda: el daño posible está acotado por diseño. En el tweet del principio, el problema de fondo no fue que el modelo se equivocó — fue que un agente que revisaba código tenía permisos de shell para borrar cualquier archivo de la máquina.
En StudioChat operamos agentes que interactúan con las APIs de nuestros clientes — bancos y fintechs incluidos — y la regla es tokens de grano fino por acción. Un agente de soporte bancario puede leer transacciones, consultar los datos de una tarjeta, y hasta pausarla al instante ante un robo. Pero aunque la misma API del cliente soporte generar un cobro, el token del agente no incluye ese permiso. No es que el prompt le dice que no cobre: es que no puede.
Token del agente · API de tarjetas del cliente
tok_agente_soporte_****- GET
/cards/:idDatos y estado de la tarjeta✓ permitido - GET
/transactionsHistorial de movimientos✓ permitido - POST
/cards/:id/pausePausar tarjeta ante robo o fraude✓ permitido - POST
/payment-linksGenerar link de pago para el cliente✓ permitido - POST
/chargesEfectuar un cobro con la tarjeta✗ denegado - DELETE
/accounts/:idEliminar cuentas o datos✗ denegado
2. Guardrails: una capa determinística y una entrenada para vigilar
Un guardrail es un mecanismo que controla los inputs y outputs del agente antes de ejecutar una acción o de mostrarle una respuesta al cliente. Conviene pensarlo en dos capas.
La capa determinística. Reglas de código — no de prompt — que se cumplen el 100% de las veces: expresiones regulares, validaciones duras, listas de bloqueo. Si la respuesta contiene un número de tarjeta o datos de otro cliente, se bloquea; si la acción es irreversible, no se ejecuta. Un regex no tiene días malos.
Probá la primera capa vos
Demo ilustrativa corriendo en tu navegador: solo regex, sin modelos. En producción esta capa se combina con modelos de seguridad y scoping de datos.
La capa de modelos guardrail. Existen modelos entrenados específicamente para vigilar a otros modelos — como gpt-oss-safeguard-20b, un modelo open source de OpenAI al que le definís tus propias reglas y las evalúa sobre cada interacción. Atrapan lo que un regex no puede: intención, contexto, reformulaciones creativas del mismo ataque.
Cuidado
Los modelos guardrail también son no determinísticos. Son un refuerzo excelente y una única barrera pésima: la combinación de las dos capas es lo que funciona.
3. Human-in-the-loop: las operaciones importantes las aprueba una persona
Para acciones sensibles — reembolsos, cambios de datos, cancelaciones — el agente propone y una persona aprueba. El costo en velocidad es mínimo comparado con el costo de una acción irreversible ejecutada a velocidad de máquina. Y todo queda registrado: cuando algo sale mal, la diferencia entre un incidente gestionable y una crisis es poder reconstruir exactamente qué pasó. En el incidente de abril, el único registro era la confesión del propio agente.
Regla práctica
Si la respuesta a "¿qué impide que el agente haga X?" empieza con "el prompt le dice que…", no tenés un control de seguridad. Tenés una sugerencia.
Todo componente de IA necesita un responsable
Cuando un agente hace algo inesperado, ¿de quién es la culpa? ¿De OpenAI? ¿De Anthropic? No. Bajo el modelo de seguridad de arriba, que estas cosas pasen es un supuesto de diseño — y quejarse del proveedor del modelo no tiene ningún beneficio para la empresa: el daño ya está hecho, y ninguna de las decisiones que lo permitieron fue de OpenAI.
Por eso cada agente — cada componente de IA en producción — tiene que tener un responsable con nombre y apellido dentro de la compañía. La persona que sabe que va a responder cuando su agente haga algo mal es la que va a exigir permisos mínimos, guardrails y aprobaciones antes de prender nada. Esa presión implícita es la que convierte todo lo anterior de "buenas ideas" en requisitos.
Todo agente va a tener un responsable tarde o temprano. La única pregunta es si lo elegís antes del incidente — cuando todavía puede prevenirlo — o si lo nombra el incidente.
Tips rápidos
Acá van unos tips fáciles de implementar que generan diferencia:
-
Todas las llamadas al modelo pasan por tracing. Un gateway tipo Cloudflare AI Gateway o herramientas como Langfuse loguean cada llamada al LLM. Cuando algo pase — va a pasar — el postmortem se hace con datos, no con memoria.
-
Usá los últimos modelos. Correr un modelo viejo es como correr una librería sin parches: los modelos nuevos traen el entrenamiento de seguridad más reciente — resisten mejor las inyecciones y siguen mejor las instrucciones. El "si funciona, no lo toques" acá juega en contra.
-
Parámetros determinísticos. Si un parámetro define de quién son los datos, no lo decide la LLM: se inyecta por fuera, desde la sesión autenticada. El modelo puede elegir qué transacción consultar — nunca de qué usuario. Es la defensa contra el acceso cruzado entre usuarios: el modelo no puede filtrar datos de otro usuario.
- determinístico
<user_id>Inyectado desde la sesión autenticada — el modelo nunca lo ve ni lo decide. - decide la LLM
<transaction_id>Lo elige el modelo, entre las transacciones ya listadas de ese usuario.
Qué preguntarle a un proveedor de agentes de IA
Si estás evaluando incorporar agentes de IA a tu operación, estas son las preguntas que separan una demo linda de una arquitectura seria:
Las preguntas incorrectas
- ¿Qué modelo usan?
- ¿Qué tan bueno es el modelo?
- ¿Cada cuánto se equivoca?
Las preguntas correctas
- ¿Qué puede hacer el agente en el peor caso?
- ¿Qué acciones tiene físicamente disponibles?
- ★ La más importante¿Qué pasa cuando el modelo no sigue las instrucciones?
El modelo se va a equivocar — siempre, es cuestión de volumen. Por eso "pasa muy poco" no es una respuesta válida a la última pregunta. La respuesta válida enumera mecanismos: permisos, guardrails, aprobaciones.
Un proveedor serio no te va a responder "el prompt le dice que no lo haga". Te va a mostrar:
- La arquitectura de permisos.
- Los guardrails que corren fuera del modelo.
- Los puntos donde una persona tiene la última palabra.
La IA no determinística es una herramienta extraordinaria. Solo hay que dejar de pedirle que además sea su propio sistema de seguridad.
Fuentes consultadas:
- The Guardian y Live Science — cobertura del incidente de PocketOS (abril 2026)
- OpenAI — gpt-oss-safeguard, modelos open source para guardrails con políticas propias
Iván Itzcovich · Co-fundador, StudioChat
¿Querés ver agentes así trabajando para tu equipo?
Agendar demo
