Prompt injection: el agujero que nadie en tu equipo audita

La inyección de prompts es la vulnerabilidad que aparece cuando un modelo de lenguaje, un LLM, no puede distinguir entre las instrucciones que le dio quien lo construyó y el texto que le llega desde fuera. Las dos cosas entran por el mismo sitio. El modelo lee un único flujo, no distingue el origen de cada tramo y decide sobre el conjunto como si todo viniera de la misma mano. No hay frontera.

Eso, dicho así, suena a problema de laboratorio. Deja de sonar así en cuanto ese modelo tiene permiso para leer un correo, consultar una base de datos o llamar a una herramienta interna. Entonces el texto de fuera puede pedirle cosas, y el modelo no tiene forma nativa de saber que no debería obedecer, porque para él la petición legítima de su dueño y la instrucción colada por un tercero en mitad de un documento tienen exactamente la misma forma, el mismo peso y la misma apariencia de orden razonable.

Hay una pregunta que se hace poco y ordena bastante el asunto. No es qué es la inyección de prompts, que está explicado en cien sitios. Es quién, dentro de tu organización, sabría auditar si el agente que acabáis de conectar a producción resiste una.

Qué es un ataque de prompt injection

Un sistema construido sobre un modelo de lenguaje funciona con dos capas de texto. Una son las instrucciones de la casa, lo que se suele llamar system prompt: el tono, los límites, lo que el asistente puede y no puede hacer. La otra es lo que llega en tiempo de ejecución, y ahí caben tanto lo que escribe el usuario en la conversación como todo lo que el sistema recupera por su cuenta mientras trabaja: el fragmento de documentación que ha ido a buscar, el correo que abre para resumirlo o la respuesta de una herramienta externa que alguien más controla.

En software tradicional esas dos capas están separadas por diseño. El código es código y los datos son datos, y hay décadas de ingeniería, de convenciones de lenguaje y de herramientas de análisis dedicadas a que esa frontera no se cruce por accidente. Un modelo de lenguaje no tiene nada de eso. Recibe una secuencia de texto y la interpreta entera como algo a lo que responder.

La definición que mantiene OWASP lo formula sin adornos: hay inyección cuando alguien construye una entrada que modifica la intención original del conjunto de instrucciones. No hace falta desbordar un buffer. Tampoco encontrar un fallo en una librería. Basta con escribir.

La distinción operativa que importa es entre directa e indirecta. En la directa, el atacante teclea en la conversación. Es la versión visible y también la menos preocupante en un entorno empresarial, porque para intentarla el atacante necesita antes una cuenta, una sesión abierta o un canal de acceso que alguien le haya concedido, y a esas alturas del problema ya tienes una brecha mayor de la que ocuparte. En la indirecta, el texto malicioso está esperando dentro de una página web, un PDF, un ticket de soporte o un correo, y el agente lo lee porque su trabajo es leerlo. Nadie ha hablado con el sistema. Fue él a buscarlo.

Esa segunda variante es la que convierte una arquitectura de recuperación de información en una superficie de ataque. Si montas un RAG sobre documentación interna y alguien consigue meter texto en esa documentación, ya sea un proveedor con acceso de edición, un becario que pega un fragmento copiado de una web o un atacante que ha encontrado el formulario que alimenta el índice, esa persona ha escrito instrucciones que tu modelo va a leer con la misma atención reverente que dedica a las tuyas. Lo mismo aplica a cualquier agente que consulte herramientas externas a través de protocolos como MCP.

En qué se diferencia de un jailbreak

Los dos términos circulan juntos. No son lo mismo.

Un jailbreak busca que el modelo se salte sus propias normas de comportamiento: que diga lo que tiene prohibido decir, que explique lo que no debe explicar. El objetivo es el modelo. Una inyección de prompts busca que la aplicación construida encima del modelo haga algo que su dueño no autorizó: filtrar datos de otro usuario, llamar a una herramienta con parámetros que no tocaban, devolver el contenido del system prompt.

La diferencia práctica está en dónde vive el riesgo. Un jailbreak es un problema del proveedor del modelo. Una inyección es un problema tuyo, porque el fallo no está en el modelo sino en los permisos que le concediste al montarlo, en la confianza implícita que depositaste en el texto que iba a procesar y en la ausencia de cualquier control que se interponga entre lo que el agente decide hacer y lo que efectivamente ejecuta contra tus sistemas.

OpenAI publicó en noviembre de 2025 un análisis del problema donde lo encuadra como un desafío de seguridad de frontera, no como un bug con parche pendiente. Esa es la parte incómoda. No hay versión que lo arregle, ni parche que cerrar, ni proveedor al que escalarlo, porque la causa está en cómo funciona la tecnología y no en cómo está implementada. Se mitiga por arquitectura.

Por qué un test de inyección puede pasar mientras el ataque funciona

Aquí llega la sorpresa.

Lo habitual, cuando alguien del equipo decide por fin tomarse esto en serio, es montar una batería de pruebas siguiendo el procedimiento razonable de cualquier otra disciplina de seguridad: se reúne una lista de cargas maliciosas conocidas, se lanzan una a una contra el agente en un entorno controlado y se comprueba que ninguna consigue lo que pedía. Todas fallan. El test pasa. Se cierra el ticket.

El problema es qué se está comprobando exactamente. Un test así verifica que el modelo no obedeció a un puñado de frases concretas en un contexto concreto. No verifica que el sistema resista una instrucción equivalente escrita de otra manera, ni que aguante la misma frase cuando llega escondida en un adjunto en vez de en el chat, ni que el fallo deje de producirse dos pasos más adelante en una cadena de herramientas donde la salida de un agente se convierte, sin que nadie lo revise, en la entrada del siguiente.

Y hay una trampa peor. Si la prueba consiste en preguntarle al propio modelo si fue manipulado, la respuesta la produce el mismo sistema que acaba de ser manipulado. Un atacante que controla la entrada también controla, en parte, lo que el sistema va a informar sobre sí mismo. El test puede salir en verde precisamente porque el ataque funcionó.

Lo que separa a alguien que sabe de esto de alguien que ha leído sobre esto es justo ese matiz. No es conocer la lista de cargas. Es entender por qué la lista no basta, y diseñar la verificación desde fuera del sistema que se está verificando. Es el mismo razonamiento que sostiene el red teaming aplicado a la IA: comprobar por ataque, no por declaración.

Quién está defendiendo esto hoy en las empresas españolas

Este es el dato que no aparece en ninguna de las guías que ocupan la primera página cuando buscas el término.

Según el análisis de mercado de Shakers, sobre 23.581 ofertas de tecnología activas en España entre el 14 de junio y el 25 de agosto de 2026, hay 61 que mencionan explícitamente prompt injection. Es un nicho pequeño. Lo interesante no es cuántas son, sino de qué tipo de puesto hablan.

De esas 61, veintiocho corresponden a roles nuevos de la era de la IA, diecisiete a ingeniería de software convencional y ocho a perfiles de cloud y DevOps. Las cuatro restantes se reparten entre producto, datos y machine learning. Ninguna categoría de seguridad pura domina el conjunto.

Léelo otra vez con calma, porque tiene consecuencias. La responsabilidad de defender un agente contra inyecciones no está recayendo sobre el equipo de seguridad. Está recayendo sobre quien construye el agente. Y quien construye el agente, en la mayoría de los casos, aprendió a hacerlo hace dieciocho meses, con documentación que cambiaba cada trimestre y sin nadie por encima que hubiera pasado antes por ahí.

Esa es la brecha real, y encaja con lo que BCG midió en enero de 2025: tres de cada cuatro empresas habían probado IA y solo una de cada cuatro veía resultados relevantes. La distancia entre probar y sostener no está en el modelo. Está en quién se encarga de las partes que no salen en la demo.

Qué skills acompañan a esa competencia en las ofertas reales

El perfil que se dibuja al mirar qué más pide cada una de esas 61 ofertas es bastante nítido, y no es el que cabría esperar de un puesto descrito como de seguridad.

Python aparece en 37. Azure en 33, AWS en 24. Después vienen OpenAI con 22, integración continua con 21, LangChain con 19, Docker y Kubernetes con 18 cada uno, Anthropic con 16 y Google Cloud con 14.

Es un repertorio de desarrollo y plataforma. No hay herramientas de pentesting. Ni certificaciones ofensivas. Ni nada que recuerde al equipamiento clásico de un auditor. Lo que se está buscando, leído entre líneas de esas descripciones de puesto, es a alguien capaz de construir el sistema entero y que además, mientras lo construye, mantenga en la cabeza el modelo mental de cómo se rompe y qué haría un tercero con acceso al texto que ese sistema va a leer.

Conviene señalar la otra cara del dato: solo 10 ofertas del mismo conjunto mencionan seguridad de modelos de lenguaje como tal. La muestra es pequeña y no aguanta conclusiones fuertes, pero apunta en la misma dirección. La disciplina se está pidiendo por sus componentes, todavía no por su nombre.

Cómo evaluar si alguien sabe defender un agente

Si el mercado le está encargando esto a perfiles de desarrollo, la pregunta operativa es cómo distinguir a quien lo sabe hacer. Cuatro preguntas separan bastante bien.

Qué haría con un agente que lee correos de clientes. Una respuesta que empieza por filtrar la entrada es una respuesta incompleta. La buena empieza por los permisos: qué puede hacer ese agente después de leer, y por qué necesita poder hacerlo. El filtrado ayuda. Es la segunda línea, no la primera.

Cómo comprobaría que la mitigación funciona. Aquí se ve enseguida quién ha estado en producción. Si la verificación depende de preguntarle al modelo, no hay verificación. La respuesta sólida describe controles fuera del modelo: qué llamadas se registran, qué se bloquea antes de ejecutarse, qué se revisa a mano.

Dónde pondría el límite de confianza. Todo el problema, por debajo de la jerga y de las listas de mitigaciones que circulan, se reduce a una única decisión de diseño: qué texto se va a tratar como dato inerte que el sistema procesa y qué texto se va a tratar como instrucción legítima que el sistema obedece. Quien sabe de esto contesta con una frontera concreta. Quien no, con buenas intenciones.

Qué haría si el ataque llega dentro de un documento legítimo. Es el caso indirecto. El que de verdad ocurre. Si la respuesta asume que el atacante escribe en el chat, esa persona ha entendido la mitad del problema.

Ninguna se responde bien de memoria. Todas se responden bien con oficio, que es exactamente lo que hay que verificar antes de poner a alguien a montar un sistema con acceso a datos de clientes.

Las mitigaciones que sí resisten

No hay solución completa. Desconfía de quien te venda una. Lo que hay es un conjunto de decisiones de arquitectura que reducen mucho la superficie.

La primera y la que más rinde es limitar permisos. Un agente que solo puede leer no saca nada por escritura. Un agente que necesita aprobación humana para ejecutar cualquier acción irreversible convierte lo que habría sido un incidente con post mortem, comunicación a clientes y semanas de desconfianza interna en una notificación que alguien descarta en diez segundos desde el móvil. La mayor parte del daño potencial se elimina en una conversación de media hora, antes de conectar nada, en la que alguien pregunta en voz alta qué es lo peor que ese sistema podría llegar a hacer si obedeciera la instrucción equivocada, y el equipo descubre que la respuesta honesta incluye acciones que nadie había pensado autorizar.

La segunda es separar canales. El contenido recuperado se trata como dato no confiable, siempre, y no viaja en el mismo plano que las instrucciones. Cuesta más que un filtro de palabras. Aguanta muchísimo mejor.

La tercera es monitorizar la salida y las llamadas a herramientas, no solo la entrada. Como el ataque puede venir por dentro, el punto de control útil está en lo que el sistema intenta hacer, no en lo que le llega. Se vigila la acción, no la frase.

Y la cuarta, que se olvida siempre, es tratar el propio corpus como un activo con integridad. Si tu agente lee de una base documental, quien pueda escribir en esa base escribe en tu modelo. Es la misma lección que dejó el slopsquatting en el terreno de las dependencias, y la que hace que la preparación del dato deje de ser un asunto de calidad para pasar a ser uno de seguridad.

Preguntas frecuentes sobre prompt injection

¿Está resuelto el problema de la inyección de prompts?

No, y no hay indicios de que vaya a resolverse con una actualización de modelo. La causa está en que los LLM procesan instrucciones y datos en el mismo canal, que es una propiedad de cómo funcionan y no un defecto de implementación. Lo que existe son mitigaciones de arquitectura que reducen el impacto: permisos mínimos, separación de canales y control de las acciones ejecutadas.

¿En qué se diferencia de un jailbreak?

Un jailbreak intenta que el modelo incumpla sus propias normas de comportamiento, y es un problema del proveedor del modelo. Una inyección de prompts intenta que la aplicación construida sobre el modelo haga algo que su dueño no autorizó, como filtrar datos o llamar a una herramienta indebida. Comparten técnica, pero el riesgo y la responsabilidad recaen en sitios distintos.

¿Cómo se detecta una inyección indirecta?

No se detecta de forma fiable leyendo la entrada, porque el texto malicioso llega escondido en contenido legítimo. El control práctico está en la salida y en las llamadas a herramientas, es decir en registrar qué intenta hacer el agente antes de que lo haga, bloquear las acciones irreversibles sin aprobación humana y comparar el comportamiento observado con el que ese flujo debería producir en condiciones normales. La verificación tiene que vivir fuera del modelo.

¿Qué perfil se está encargando de esto en España?

Mayoritariamente perfiles de desarrollo, no de seguridad. De las 61 ofertas activas que mencionan prompt injection entre junio y agosto de 2026, veintiocho son roles nuevos de la era de la IA y diecisiete de ingeniería de software, frente a ocho de cloud y DevOps. Las tecnologías que las acompañan son Python, Azure, AWS, LangChain y Kubernetes.

¿Basta con una batería de tests de inyección?

No. Una batería comprueba que el sistema resistió unas cargas concretas en un contexto concreto, no que resista variantes equivalentes ni ataques que lleguen por otro canal. Si además la comprobación consiste en preguntarle al modelo si fue manipulado, el resultado lo produce el mismo sistema comprometido. La verificación debe diseñarse desde fuera.