Qué revisamos antes de poner en marcha un agente de IA

Cada agente de IA que lanzamos obtiene acceso a algo que vale la pena proteger: una agenda, un CRM, a veces una ficha de paciente. La conversación del sector sobre agentes de IA habla mucho de lo que pueden hacer y muy poco de lo que pueden ver, y de qué pasa si ese acceso se usa mal, se filtra o simplemente está sobredimensionado desde el primer día.

Tratamos cada nuevo agente como una nueva superficie de ataque, no solo como una nueva función. Antes de que nada llegue a producción, pasa por la misma revisión que aplicaríamos si un cliente nos pidiera auditar la suya.

Tres comprobaciones antes del lanzamiento.

Primera, el acceso. Mapeamos exactamente qué puede leer y escribir el agente, y lo recortamos al mínimo que realmente necesita — ningún agente tiene acceso permanente a una base de datos completa cuando solo usa tres campos. El acceso con privilegios excesivos es el hallazgo más habitual en las auditorías de agentes, incluidas las nuestras.

Segunda, el abuso. Sometemos al agente a los mismos intentos de inyección de prompts y jailbreak que probaría un atacante — instrucciones ocultas dentro de un mensaje, intentos de hacerlo llamar a herramientas que no debería, intentos de extraer su propio prompt de sistema o contexto. Todo lo que funciona se corrige antes del lanzamiento, no después de que lo encuentre un cliente.

Tercera, la gobernanza. Comprobamos el despliegue frente a los marcos que se están convirtiendo en el estándar real de esto — ISO/IEC 42001, NIST AI RMF y los requisitos del EU AI Act para usos de mayor riesgo. No porque quede bien marcar una casilla, sino porque un regulador o el equipo de seguridad de un cliente enterprise acabará preguntando, y «no lo pensamos» no es una respuesta que estemos dispuestos a dar.

Nada de esto es exclusivo nuestro — debería ser práctica estándar para cualquiera que lance un agente con acceso real. La mayoría del sector se lo salta porque ralentiza una demo. Creemos que la alternativa es peor.