Por qué la ciberseguridad clásica no protege los sistemas de IA

La mitad de las empresas que han desplegado un agente de IA o un modelo de lenguaje lo protege exactamente igual que un microservicio corriente: con un cortafuegos, un escáner de dependencias y una política de accesos. Suena razonable, pero en la práctica es como poner una puerta blindada en una casa a la que le falta una pared. Boris Matsakov, ingeniero de Data Science en Cloud.ru, formuló con precisión en su análisis en Habr un problema que el sector prefiere seguir ignorando: el DevSecOps clásico y la seguridad de la IA son dos perímetros distintos, y uno no sustituye al otro.

La raíz de la divergencia es sencilla y a la vez fundamental. El DevSecOps se construyó durante décadas en torno a un modelo de amenazas bien entendido: hay un perímetro, hay dependencias, hay infraestructura y derechos de acceso. Protege cada una de estas capas y el sistema estará a salvo.

Pero los modelos de IA se atacan de una forma completamente distinta. La prompt injection permite a un atacante tomar el control del comportamiento del modelo mediante un texto especialmente diseñado. El envenenamiento de los datos de entrenamiento distorsiona la propia lógica de decisión mucho antes de que el modelo llegue a producción.

La manipulación del contexto hace que un agente de IA ejecute acciones que sus creadores no habían previsto. Ninguno de estos ataques toca la infraestructura en el sentido tradicional: golpean lo que hace de la IA una inteligencia artificial, es decir, los datos y la capacidad del modelo para interpretarlos.

El problema se agudiza con los sistemas agénticos: agentes de IA autónomos que no se limitan a generar texto, sino que toman decisiones, llaman a API externas, trabajan con bases de datos y ejecutan cadenas de acciones. Si un modelo de lenguaje corriente puede compararse, a grandes rasgos, con un consultor que da consejos, un agente de IA es un empleado con acceso a los sistemas corporativos. Comprometer a ese empleado mediante prompt injection supone obtener no solo una respuesta errónea, sino un impacto real en los procesos de negocio.

Y aquí la protección de infraestructura es impotente por definición: desde el punto de vista del cortafuegos, el agente hace exactamente lo que se le permite, enviar solicitudes y recibir respuestas.

La buena noticia es que el sector no se queda quieto. En el último año y medio han surgido varios marcos de referencia serios que permiten construir un sistema de protección práctico. OWASP ha publicado dos listas Top 10 de vulnerabilidades independientes: una para aplicaciones LLM y otra para sistemas agénticos.

Google presentó SAIF, el Secure AI Framework, con un mapa de riesgos que ayuda a las empresas a evaluar las amenazas de forma sistemática. MITRE amplió su célebre base ATT&CK hasta el proyecto ATLAS, que cataloga técnicas de ataque específicas contra sistemas de aprendizaje automático. Cada herramienta cubre su propio nicho: OWASP ofrece una lista de comprobación de vulnerabilidades concretas, SAIF una metodología de evaluación de riesgos y ATLAS un lenguaje para describir ataques y construir modelos de amenazas.

La mala noticia es que sigue sin existir un estándar único. No hay un «GOST», ni una norma ISO, ni un marco obligatorio que prescriba a las empresas un conjunto concreto de medidas. Cada equipo interpreta a su manera qué es un «sistema de IA seguro», y esa interpretación suele reducirse a lo que ya saben hacer los ingenieros de DevSecOps de la plantilla. Eso crea una peligrosa ilusión de protección: formalmente se cumplen todos los procedimientos, los escáneres están en verde, los accesos están segregados, pero el modelo sigue siendo vulnerable a ataques que el equipo de seguridad puede ni sospechar.

La conclusión práctica para las empresas es la siguiente: la seguridad de la IA debe tratarse como un perímetro aparte que se superpone al DevSecOps existente, y no como algo integrado en él. Eso implica competencias específicas en el equipo, un conjunto propio de herramientas de prueba (red teaming de modelos, comprobación de prompt injection, auditoría de los datos de entrenamiento) y un modelo de amenazas propio, construido teniendo en cuenta las particularidades del aprendizaje automático. Los marcos OWASP, SAIF y ATLAS ofrecen una base suficiente para no reinventar la rueda.

El sector de la seguridad de la IA se encuentra hoy más o menos donde estaba la ciberseguridad clásica a principios de los 2000: las amenazas son reales y las herramientas van apareciendo, pero aún no hay estándares maduros. Las empresas que empiecen a construir este perímetro ahora obtendrán no solo una ventaja técnica, sino también competitiva, porque dentro de dos o tres años los reguladores llegarán inevitablemente con exigencias, y adaptarse será más fácil para quienes ya estén preparados.