En abril de 2026, un agente de IA basado en Claude y utilizado para tareas de desarrollo de software borró la base de datos de producción de una empresa en nueve segundos. Tenía reglas de seguridad explícitas y, aun así, encontró la forma de eludirlas.
Meses antes, un agente de IA con acceso al correo electrónico comenzó a eliminar mensajes de la bandeja de entrada de una especialista en seguridad de IA, pese a tener instrucciones específicas para evitarlo.
En ambos casos, las instrucciones de seguridad existían. El problema estaba en cómo se habían implementado: el propio agente podía interpretar esos límites y actuar por fuera de ellos.
Estos incidentes reflejan un problema cada vez más frecuente. Según el Agent Productivity Index 2026 de Kore.ai, el 82% de las empresas reporta que sus agentes de IA ejecutaron acciones de forma autónoma con consecuencias reales, incluso con controles de seguridad activos.
El problema de fondo está en dónde se implementan esos controles. Muchas organizaciones todavía confían en instrucciones dentro del prompt para establecer límites que deberían estar definidos técnicamente en la arquitectura.
Con software tradicional, la seguridad se define por accesos, permisos y superficies de ataque fijas. Con un agente de IA se suma una variable: el propio agente decide, en tiempo real, qué hacer con esos accesos. Cada permiso otorgado se vuelve una superficie de riesgo dinámica.
Un guardrail es un control técnico que establece límites concretos sobre qué puede responder un agente, a qué información puede acceder y qué acciones puede ejecutar. Su efectividad depende de que esos límites estén fuera de la capacidad de decisión del modelo.
Un permiso funciona como control de seguridad cuando su cumplimiento queda fuera de la capacidad de decisión del agente.
Estos riesgos pueden aparecer incluso cuando el modelo funciona según lo esperado. Basta con que tenga acceso a una acción que debería estar restringida por diseño.
Una instrucción en el prompt puede indicarle a un agente que evite borrar datos o que solicite aprobación antes de ejecutar una acción. A medida que aumenta la extensión y complejidad de una interacción, esas instrucciones pueden perder peso dentro del contexto que utiliza el modelo para decidir.
La detección de datos sensibles durante una conversación también cubre solo una parte del problema. Decisiones como qué herramientas puede utilizar el agente, qué sistemas puede consultar y qué acciones tiene habilitadas deben definirse desde su configuración y arquitectura.
El nivel de control también debería responder al riesgo de cada caso de uso. Un agente con acceso de solo lectura requiere controles diferentes a uno capaz de iniciar una transacción. Gartner proyecta que aplicar una gobernanza uniforme, sin distinguir el riesgo real de cada agente, podría llevar a un 40% de las empresas a discontinuar agentes autónomos para 2027.
Si más de una queda sin una respuesta clara, probablemente exista un área de riesgo que todavía necesita mayor visibilidad y control.
Incorporar controles de seguridad desde el diseño permite definir correctamente los permisos, las responsabilidades de cada agente y las acciones que requieren validación. Cuando estos controles se agregan con agentes ya desplegados, los cambios pueden requerir ajustes importantes en su arquitectura y configuración.
Las organizaciones que incorporan la seguridad desde las primeras etapas tienen mejores condiciones para llevar agentes a producción, ampliar sus casos de uso y mantener el control a medida que aumenta su autonomía.
¿Tu organización ya tiene agentes de IA en producción o los está evaluando para procesos críticos?
Desde EDSA ayudamos a diseñar la seguridad de agentes desde la arquitectura, la configuración y la plataforma, definiendo controles acordes al nivel de autonomía y riesgo de cada caso de uso. Escribinos a talk@edsa.com y agendemos una conversación.