“Has contratado a un ayudante brillante que se cree todo lo que lee, y le has dado las llaves.”
La frontera que desaparece
En una aplicación normal, el código es código y los datos son datos. Una consulta SQL es un conjunto de instrucciones; el nombre del usuario es un dato. Décadas de práctica en seguridad (validación de entradas, consultas parametrizadas, escapado) existen para mantener esa línea nítida. Toda la disciplina de defensa contra la inyección consiste en no dejar que los datos se conviertan en instrucciones.
Un modelo de lenguaje borra esa línea. El prompt es un único flujo de texto que contiene tus instrucciones, la entrada del usuario y cualquier documento recuperado, y el modelo lo lee todo como instrucciones que podría seguir. No existe una sintaxis que diga «esta parte es un dato, no le obedezcas». El modelo decide qué trata como una orden, y decide mal bajo presión.
Las fronteras de confianza, redibujadas
La seguridad empieza con una pregunta: ¿en qué confías, y dónde se encuentra lo fiable con lo no fiable? Con un LLM, la respuesta honesta es incómoda. Todo lo que el modelo lee (mensajes del usuario, documentos recuperados, salidas de herramientas, el contenido de una página web que ha navegado) es no fiable y podría llevar instrucciones. Y todo lo que el modelo puede hacer (llamar a herramientas, devolver datos, desencadenar acciones) es una capacidad que un atacante puede intentar tomar prestada.
Por qué ya no basta con la estrategia de siempre
La seguridad de aplicaciones tradicional sigue aplicándose: la autenticación, la autorización, el cifrado y lo demás siguen siendo necesarios. Pero se diseñó para sistemas deterministas con gramáticas de entrada claras. Un LLM no tiene gramática de entrada; una «entrada válida» es cualquier texto en cualquier idioma, incluido texto diseñado para manipular el modelo. No puedes escribir una expresión regular para la malicia expresada en un castellano fluido.
Así que la seguridad de la IA es aditiva, no un reemplazo. Conservas todo lo que ya haces y añades una capa para los modos de fallo propios del modelo: seguir instrucciones procedentes de contenido no fiable, filtrar lo que se le ha confiado, ser convencido de saltarse sus salvaguardas y actuar más allá de lo que tenías previsto. Los cinco próximos capítulos tratan de esos modos de fallo; el último, de cómo gobernar el conjunto.
Un mapa de lo que puede salir mal
La comunidad ha convergido en una taxonomía aproximada: el OWASP Top 10 para aplicaciones LLM es la versión más citada, y vale la pena leerla entera. Los riesgos principales se agrupan en unas pocas familias:
- Inyección de prompt: contenido no fiable secuestra las instrucciones del modelo (capítulo 2).
- Divulgación de información sensible: el modelo filtra datos que se le dieron o con los que se entrenó (capítulo 3).
- Jailbreaks y abuso: se guía al modelo más allá de sus salvaguardas de seguridad (capítulo 4).
- Riesgos de la cadena de suministro: datos envenenados, modelos con puertas traseras, paquetes y herramientas maliciosos (capítulo 5).
- Agencia excesiva: se permite al modelo hacer más de lo que sería seguro (tema transversal).
Ninguno de estos riesgos es exótico. Son las consecuencias previsibles de un sistema que sigue instrucciones en lenguaje natural y que has conectado a capacidades reales. Entenderlos constituye la mayor parte de la defensa.
Una línea por cada uno
- Los LLM borran la frontera instrucciones/datos sobre la que se apoya la seguridad clásica: todo lo que está en el prompt se lee como instrucciones potenciales.
- Trata cada token que el modelo lee como no fiable, y cada acción que puede ejecutar como potencialmente abusada.
- La seguridad de la IA es aditiva: conserva toda la seguridad de aplicaciones tradicional y añade una capa para los modos de fallo propios del modelo.
- Las taxonomías estándar (OWASP LLM Top 10, MITRE ATLAS) son un mapa útil, no una defensa. Orientan tu modelado de amenazas, no lo reemplazan.
Adónde ir ahora