Por qué la ciberseguridad tradicional no protege los sistemas de AI

Cada segunda empresa que ha desplegado un agente de AI o un modelo de lenguaje lo protege exactamente como un microservicio ordinario — con firewall, scanner de dependencias y políticas de acceso. Parece razonable, pero en la práctica es como poner una puerta de metal en una casa a la que le falta una pared entera. Boris Matsakov, ingeniero de Data Science de Cloud.ru, formuló precisamente el problema que la industria hasta ahora prefiere no notar en su análisis en Habr: DevSecOps clásico y seguridad de AI son dos circuitos diferentes, y uno no reemplaza al otro.

La divergencia es simple y al mismo tiempo fundamental. DevSecOps se construyó durante décadas alrededor de un modelo de amenaza comprensible: hay un perímetro, hay dependencias, hay infraestructura y derechos de acceso. Protege cada una de estas capas — y el sistema está seguro.

Pero los modelos de AI se atacan de formas completamente diferentes. La inyección de prompts permite a un atacante secuestrar el comportamiento del modelo a través de texto especialmente construido. El envenenamiento de datos de entrenamiento distorsiona la lógica misma de la toma de decisiones mucho antes de que el modelo llegue a producción.

La manipulación de contexto obliga a un agente de AI a ejecutar acciones que sus creadores no anticiparon. Ninguno de estos ataques toca la infraestructura en el sentido tradicional — atacan aquello que hace que la AI sea inteligencia artificial: los datos y la capacidad del modelo para interpretarlos.

El problema es especialmente agudo con sistemas agentic — agentes de AI autónomos que no solo generan texto, sino que toman decisiones, llaman APIs externas, trabajan con bases de datos y ejecutan cadenas de acciones. Si un modelo de lenguaje ordinario se puede comparar vagamente con un consultor que da consejos, entonces un agente de AI es un empleado con acceso a los sistemas corporativos. Comprometer tal empleado a través de inyección de prompts significa obtener no solo una respuesta incorrecta, sino un impacto real en los procesos empresariales.

Y aquí la protección de infraestructura es impotente por definición: desde la perspectiva del firewall, el agente está haciendo exactamente lo que se le permite — enviando solicitudes y recibiendo respuestas.

La buena noticia es que la industria no se queda quieta. En los últimos dieciocho meses, se han desarrollado varios documentos marco serios que permiten construir un sistema de defensa práctico. OWASP lanzó dos listas separadas del Top 10 de vulnerabilidades — para aplicaciones LLM y para sistemas agentic.

Google presentó SAIF — el Secure AI Framework con un mapa de riesgos que ayuda a las empresas a evaluar sistemáticamente las amenazas. MITRE amplió su legendaria base de datos ATT&CK al proyecto ATLAS, que cataloga técnicas de ataque específicas para sistemas de aprendizaje automático. Cada una de estas herramientas llena su propio nicho: OWASP proporciona una lista de verificación de vulnerabilidades específicas, SAIF proporciona una metodología de evaluación de riesgos, ATLAS proporciona un lenguaje para describir ataques y construir modelos de amenaza.

La mala noticia es que un estándar unificado aún no existe. No hay ni un "GOST" ni una ISO, ni un marco obligatorio que prescriba un conjunto específico de medidas para las empresas. Cada equipo interpreta a su manera qué significa un "sistema de AI seguro", y a menudo esta interpretación se reduce a lo que los ingenieros de DevSecOps internos ya saben hacer. Esto crea una ilusión peligrosa de protección: formalmente se siguen todos los procedimientos, los scanners están en verde, el acceso está controlado — pero el modelo es vulnerable a ataques que el equipo de seguridad puede ni siquiera sospechar.

La conclusión práctica para el negocio se ve así: la seguridad de AI debe considerarse como un circuito separado que se superpone al DevSecOps existente en lugar de estar incorporado en él. Esto significa competencias separadas en el equipo, un conjunto separado de herramientas para pruebas — red teaming de modelos, verificación de inyección de prompts, auditoría de datos de entrenamiento — y un modelo de amenaza separado construido considerando las especificidades del aprendizaje automático. Los marcos OWASP, SAIF y ATLAS proporcionan una base suficiente para que no tengas que reinventar la rueda.

La industria de seguridad de AI está actualmente aproximadamente en el mismo lugar donde estaba la ciberseguridad clásica a principios de los años 2000: las amenazas son reales, las herramientas están emergiendo, pero aún no existen estándares maduros. Las empresas que comiencen a construir este circuito ahora obtendrán no solo una ventaja técnica sino también una competitiva — porque en dos o tres años los reguladores inevitablemente vendrán con requisitos, y será más fácil adaptarse para quienes estén preparados.