Cuando una empresa despliega un asistente de IA sobre sus datos internos, asume que el modelo hará lo que le han pedido: responder preguntas, resumir documentos, ayudar al equipo. Lo que no suele asumir es que un tercero, sin acceso directo al sistema, pueda redirigir ese asistente para que filtre información, deshabilite sus propios filtros de seguridad o ejecute acciones no autorizadas. Eso es exactamente lo que permite la inyección de prompts. Y no es un fallo puntual de implementación: es una consecuencia directa de cómo los modelos de lenguaje procesan el mundo.
Cuando OWASP publicó su Top 10 para aplicaciones LLM en 2025, la inyección de prompts ocupó el primer lugar. No fue una sorpresa, pero la posición es reveladora: pese a estar documentada desde 2023, sigue siendo la vulnerabilidad más frecuente en despliegues de IA en producción. La razón es arquitectónica.
Los modelos de lenguaje no distinguen entre código y dato. Todo es lenguaje natural, y el modelo lo trata como un flujo continuo de instrucciones. No hay separación semántica clara entre «lo que el sistema debe hacer» y «lo que el usuario o el entorno le está diciendo». Como ha señalado el equipo de seguridad de Microsoft en su análisis sobre inyección indirecta, el riesgo fundamental es que un atacante pueda proporcionar datos especialmente diseñados que el modelo interprete como instrucciones legítimas, sin necesitar acceso directo al sistema. Basta con que el modelo lea tu contenido.
De incidente aislado a cadena de ataque
La narrativa dominante trata la inyección de prompts como una vulnerabilidad aislada, un truco de demostración o un problema perimetral que se resuelve con filtros. Esa visión es incompleta.
Investigadores en seguridad han propuesto el concepto de «promptware» para describir cómo la inyección puede estructurarse como una cadena de ataque completa. El modelo, publicado en arXiv en enero de 2026, contempla siete pasos que van desde el acceso inicial —inyección directa o indirecta— hasta persistencia, escalada de privilegios y exfiltración de datos. Una vez que las instrucciones maliciosas están dentro del material que el modelo procesa, el ataque puede transitar hacia lo que en el ámbito de seguridad se llama jailbreaking: eludir el entrenamiento de alineación mediante técnicas análogas a la ingeniería social o mediante sufijos adversariales en el prompt. El resultado no es solo engañar al modelo para que responda algo inapropiado; es desbloquearlo para uso malicioso y establecer persistencia en su memoria o en las bases de datos que consulta.
Este cambio de paradigma importa. En su informe sobre el uso de IA por actores de amenaza, Google documenta cómo la evolución del panorama de amenazas transformó la naturaleza de la ofensiva cibernética a lo largo de 2025: desde actividad de bajo nivel hasta espionaje orquestado con IA y malware adaptativo habilitado por LLMs. Herramientas diseñadas específicamente para explotar modelos de lenguaje se usaron en operaciones reales. La brecha entre demostración técnica y uso operacional se está cerrando más rápido de lo que los equipos de seguridad suelen asumir.
Cinco brechas en dos meses: el estado actual
Entre enero y febrero de 2025 se documentaron cinco grandes brechas de datos relacionadas con LLMs a nivel global, según el análisis de NSFOCUS Xingyun Lab, con filtración de historiales de conversación, claves de API y credenciales. No fueron ataques de actores estatales con recursos extraordinarios. Fueron explotaciones directas de configuraciones inseguras, APIs expuestas y confianza ciega en datos externos procesados por modelos.
Uno de los incidentes de enero ilustra bien el mecanismo. El objetivo era un sistema RAG empresarial —un asistente que recupera documentos internos para responder preguntas—. Los investigadores incrustaron instrucciones maliciosas en un documento de acceso público que el sistema podía recuperar. Cuando el asistente procesó ese documento, siguió las instrucciones embebidas en él. Primero, empezó a filtrar inteligencia de negocio propietaria a endpoints externos. Después, modificó sus propios prompts de sistema para deshabilitar filtros de seguridad. Por último, ejecutó llamadas a API con privilegios superiores a los que el usuario tenía autorización para ejercer.
El ataque funcionó por una razón estructural: el sistema no distinguía entre «lo que me han dicho que haga» y «lo que estoy leyendo en este documento». Todo el contenido recuperado recibía el mismo nivel de confianza que las instrucciones del sistema.
La defensa tradicional no fue diseñada para esto
Los WAF y los sistemas de sanitización de entradas no pueden proteger contra instrucciones codificadas en lenguaje natural. La entrada legítima y la maliciosa son, en la capa de red, indistinguibles. Como señala Obsidian Security en su análisis, estos ataques operan en la capa semántica, no en la de red o aplicación, y eso invalida por diseño las defensas perimetrales clásicas.
Microsoft ha desarrollado técnicas como Spotlighting para aislar entradas no confiables y Prompt Shields integrado en Defender for Cloud, y reconoce que la inyección indirecta de prompts es la técnica más frecuente en las vulnerabilidades de seguridad de IA reportadas. No hay solución única. Lo que hay es defensa en profundidad: prompts de sistema endurecidos, aislamiento explícito de datos externos frente a instrucciones del sistema, gobernanza estricta de los privilegios del agente y bloqueo determinista de patrones conocidos de exfiltración. Es una postura de seguridad, no un parche.
El problema de fondo, sin embargo, no es técnico: es de modelo mental. Seguimos pensando en los asistentes de IA como herramientas. Pero cuando les damos acceso a datos sensibles, capacidad de ejecutar acciones y autonomía para interpretar contexto externo, dejan de ser herramientas. Se convierten en infraestructura con capacidad de acción. Y esa infraestructura tiene una vulnerabilidad de diseño: confía en el lenguaje.
La inyección de prompts no se parchea como se parchea un CVE. Es la forma en que los sistemas de lenguaje natural entienden el mundo. Hasta que las arquitecturas no separen de manera robusta «instrucciones del sistema» de «datos del entorno», cada asistente con capacidad de acción será, en potencia, un vector de ataque conversacional. La pregunta relevante no es si esto ocurrirá en producción. Es si los equipos que despliegan estos sistemas lo saben ya.