La separación entre instrucción y dato que los LLM nunca tuvieron
En diciembre de 2025, OpenAI publicó algo inusual: una admisión explícita de que el prompt injection en navegadores agénticos es poco probable que se resuelva de forma completa, de la misma manera que no se resuelven las estafas o la ingeniería social en la web. No es un comunicado sobre un parche futuro ni un roadmap de mitigaciones. Es el reconocimiento de que sistemas como ChatGPT Atlas operan sobre una fragilidad estructural que no tiene solución técnica definitiva.
La declaración llegó semanas después de que investigadores demostraran que unas pocas palabras ocultas en un documento o en el portapapeles eran suficientes para manipular el comportamiento del agente. OpenAI respondió con actualizaciones de seguridad, red-teaming automatizado y monitores de detección en tiempo real. Pero el núcleo del problema permanece: los modelos no tienen capacidad para distinguir de manera confiable entre instrucciones y datos. Y eso no es un defecto de implementación. Es una propiedad arquitectónica de los LLM.
Aun así, la industria entera está construyendo infraestructura crítica sobre ella.
La trifecta que hace inevitable el compromiso
Simon Willison identificó en 2025 lo que llamó la trifecta letal: cuando un agente tiene acceso a datos privados, procesa contenido no confiable y puede comunicarse externamente, es explotable por diseño. No es un caso límite. Es la descripción exacta de la mayoría de agentes desplegados en producción, porque precisamente eso es lo que los hace útiles.
La cadena de ataque documentada por el propio OpenAI ilustra la mecánica: un atacante insertó un email malicioso en la bandeja de entrada de un usuario; cuando el agente escaneó el correo más tarde, siguió las instrucciones ocultas y envió un mensaje de renuncia. Después de las actualizaciones, el sistema logró detectar y señalar el intento. Pero eso sigue siendo defensa probabilística contra un vector de ataque semántico que no tiene firma binaria ni patrón de red identificable.
Los números reflejan que esto no es un problema emergente. Según el Top 10 de OWASP 2025 para aplicaciones LLM, el prompt injection ocupa el primer lugar entre las vulnerabilidades críticas desde que se publicó la lista, y lo hace porque explota el diseño del sistema en lugar de un fallo que pueda corregirse con un parche. JBFuzz, un framework basado en fuzzing presentado en marzo de 2025, logró tasas de éxito medias del 99% contra modelos como GPT-4o, Gemini 2.0 o DeepSeek-V3. No es investigación académica distante: son exploits prácticos contra sistemas en producción.
La primera consecuencia práctica es que el costo de lanzar un ataque de este tipo ha caído radicalmente. La segunda, más relevante, es que el perfil del atacante ha dejado de importar: no hace falta entender la arquitectura del modelo para explotarla.
Por qué parchear no resuelve el problema
Microsoft, en su estrategia pública de defensa en profundidad, lo formula con claridad inhabitual: el prompt injection indirecto es un riesgo inherente que surge de la modelización probabilística del lenguaje, la generación estocástica y la flexibilidad lingüística de los LLM modernos. Traducción: no hay solución determinista. Solo capas de controles probabilísticos apiladas sobre un sistema que no distingue formalmente entre lo que debe ejecutar y lo que debe procesar.
La respuesta de OpenAI a esta asimetría es entrenar atacantes automáticos mediante reinforcement learning para descubrir nuevos vectores antes de que aparezcan en la naturaleza. Es una carrera armamentista donde el adversario y el defensor son versiones del mismo tipo de modelo, entrenadas para superarse mutuamente. El espacio de posibles inyecciones semánticas es combinatorialmente vasto, y la superficie de ataque crece con cada nueva capacidad que se le otorga al agente.
El UK National Cyber Security Centre advirtió en diciembre que los ataques de prompt injection contra aplicaciones de IA generativa pueden nunca ser totalmente mitigados de la misma manera que lo fueron los ataques de SQL injection. OpenAI lo admite de forma análoga. Lo que ambas instituciones describen no es un problema técnico pendiente de resolver, sino una propiedad emergente de cómo están construidos estos sistemas.
El problema más profundo: el lenguaje no distingue
Hay una manera de enmarcar todo esto que va más allá de la vulnerabilidad técnica concreta. Los LLM no tienen, y no pueden tener en su arquitectura actual, una separación formal entre instrucción y dato. Ambos llegan como texto. Ambos se procesan de la misma manera. La distinción que existe en sistemas convencionales —código versus datos, instrucción versus contenido— simplemente no está incorporada en cómo funciona un modelo de lenguaje.
Cuando se construye un agente sobre esa base y se le otorgan capacidades de acción —leer correo, ejecutar búsquedas, llamar APIs, tomar decisiones—, se está delegando autoridad en un sistema que no tiene manera de verificar de quién viene cada instrucción. El vector de ataque no es técnico en el sentido clásico: es semántico. No hay una firma que detectar, no hay un patrón de red que bloquear. Hay texto que se parece a una instrucción legítima porque, desde la perspectiva del modelo, lo es.
Eso es lo que hace estructuralmente diferente el prompt injection de otras vulnerabilidades. Un buffer overflow explota un error de implementación. El prompt injection explota el diseño fundamental del sistema que lo hace útil.
¿Infraestructura crítica sobre incertidumbre estructural?
El State of AI Security 2026 de Cisco encontró que solo el 29% de las organizaciones que planean desplegar IA agéntica reportan estar preparadas para asegurar esos despliegues. La brecha no es de conocimiento: en este punto, la evidencia es pública y está bien documentada. La brecha es de otro tipo.
Se sigue adelante porque la utilidad percibida justifica el riesgo estructural, o porque la presión competitiva no permite esperar a que exista una arquitectura formalmente más segura. Ambas razones son comprensibles. Ninguna resuelve el problema subyacente.
La pregunta ya no es técnica. Es si estamos dispuestos a tratar la incertidumbre fundamental como condición permanente de operación, y qué significa eso para los sistemas que construimos sobre ella.