En los últimos meses, el auge de los agentes de inteligencia artificial ha transformado la forma en que las empresas automatizan procesos, gestionan clientes y toman decisiones. Sin embargo, un incidente reciente —en el que un agente cargó 4.000 euros a la cuenta de facturación equivocada sin que nadie lo advirtiera hasta días después— ha puesto sobre la mesa una verdad incómoda: los guardarraíles de prompt, por sí solos, no son suficientes para garantizar la seguridad en entornos productivos. El error no fue un fallo del modelo; el agente actuó exactamente como fue diseñado, con credenciales amplias, sin límites de alcance y sin una auditoría que registrara la acción. El problema fue de plataforma, no de prompt.
Cuando hablamos de agentes de IA, tendemos a centrarnos en la calidad de las instrucciones y en la capacidad del modelo para entender contextos. Pero la experiencia demuestra que incluso el mejor prompt falla si la infraestructura que lo sostiene carece de barreras de identidad, permisos granulares y trazabilidad. En Q2BSTUDIO, empresa de desarrollo de software y tecnología, llevamos años aplicando estos principios en proyectos de aplicaciones a medida, donde la seguridad no es una capa adicional, sino un pilar arquitectónico desde el diseño.
Para entender por qué los guardarraíles de prompt son insuficientes, primero hay que distinguir entre dos niveles de control. El primero es el nivel semántico: las instrucciones que damos al modelo para que no realice acciones no deseadas. El segundo es el nivel sistémico: las reglas y mecanismos que la plataforma impone antes, durante y después de la ejecución del agente. Un prompt bien escrito puede evitar que el modelo mencione datos sensibles, pero no puede evitar que el agente use una API con credenciales demasiado permisivas para escribir en una base de datos equivocada.
La seguridad en plataforma para agentes implica, como mínimo, tres capas. La primera es la identidad y autenticación: cada agente debe tener una identidad única, con permisos específicos para cada recurso (bases de datos, APIs, sistemas de archivos). La segunda es la delimitación de alcance: el agente solo debe poder interactuar con los sistemas y datos que necesita para su tarea, y nada más. La tercera es la auditoría completa: cada acción del agente debe ser registrada, con timestamp, identidad del agente, datos de entrada y salida, y resultado. Sin estas capas, cualquier error de prompt —o incluso un comportamiento perfectamente razonable pero contextualmente erróneo— puede tener consecuencias graves.
En el caso del agente que facturó a la cuenta equivocada, el problema no fue que el modelo interpretara mal la instrucción. El problema fue que el agente tenía acceso a la API de facturación completa, sin restricciones sobre qué cuentas podía modificar. Un sistema de plataforma bien diseñado habría exigido que el agente presentara un token de autorización para cada cuenta específica, o que operara dentro de un 'sandbox' de facturación limitado a las cuentas asignadas a ese agente. Nada de eso existía.
Este tipo de arquitectura de seguridad no es nueva. En el mundo de las aplicaciones empresariales, se aplican principios de mínimo privilegio, separación de responsabilidades y registro de auditoría desde hace décadas. La novedad es que ahora debemos aplicarlos también a los agentes de IA, que son software autónomo con capacidades de decisión. Y aquí es donde muchas empresas cometen el error de tratar la IA como un componente mágico que no necesita las mismas protecciones que una aplicación tradicional. Nada más lejos de la realidad.
Desde Q2BSTUDIO, recomendamos integrar estos controles en la plataforma de despliegue de agentes, no en el prompt. Esto significa usar sistemas de identidad federada (como OAuth o SAML) para cada agente, establecer políticas de acceso basadas en roles (RBAC) que limiten el alcance de las APIs, y desplegar un ciclo de auditoría continuo que alimente dashboards de IA y Business Intelligence. De hecho, la combinación de agentes con Plataformas de BI como Power BI permite visualizar en tiempo real las acciones de los agentes, detectar anomalías y reaccionar antes de que un error se convierta en una crisis.
Otro aspecto crucial es la ciberseguridad. Los agentes de IA son vectores de ataque potenciales: si un atacante logra alterar el prompt o interceptar las credenciales de un agente, puede conseguir acceso a sistemas críticos. Por eso, en Q2BSTUDIO aplicamos las mismas prácticas de seguridad que en cualquier otro proyecto de ciberseguridad: pentesting específico sobre agentes, revisión de permisos, cifrado de comunicaciones y monitorización continua. No podemos confiar únicamente en que el prompt sea correcto; debemos asumir que el agente puede ser comprometido y diseñar la plataforma para contener el daño.
La nube también juega un papel fundamental. Tanto AWS como Azure ofrecen servicios de identidad y control de acceso que pueden aplicarse directamente a los agentes. Por ejemplo, AWS IAM permite definir roles para cada agente con políticas muy detalladas, mientras que Azure Managed Identities proporciona una identidad automática y segura. En Q2BSTUDIO ayudamos a nuestros clientes a diseñar arquitecturas cloud (AWS/Azure) que integren agentes de IA con estos mecanismos de seguridad desde el primer día. No se trata de añadir un firewall después, sino de construir la plataforma con esos límites incorporados.
Volviendo al incidente inicial, la lección es clara: los guardarraíles de prompt son una herramienta útil, pero no son una muralla. La verdadera seguridad para agentes de IA reside en la plataforma que los ejecuta. Si una empresa despliega agentes sin identidad granular, sin límites de alcance y sin auditoría, está asumiendo un riesgo innecesario. En Q2BSTUDIO sabemos que la excelencia técnica no está solo en el modelo, sino en la infraestructura que lo sostiene. Por eso trabajamos con nuestros clientes en proyectos de automatización de procesos y BI/Power BI para garantizar que cada agente actúe dentro de unos límites seguros, trazables y controlables.
En definitiva, la próxima vez que un equipo se plantee añadir más instrucciones al prompt para evitar errores, debería preguntarse primero: ¿mi plataforma permite que el agente haga algo que no debería, aunque el prompt sea perfecto? Si la respuesta es sí, entonces el problema no es de prompt, es de plataforma. Y ahí es donde realmente debemos poner el foco.
