Resumen en 40 palabras: la prompt injection es un ataque en el que un texto consigue que un modelo de IA siga instrucciones que no son las de su dueño. Es el riesgo número uno del OWASP Top 10 para LLM y no se elimina con un parche: se gestiona con diseño.
Si tu empresa tiene un chatbot, un asistente que lee el correo, un buscador interno con IA o un agente conectado a herramientas, ya está expuesta a la inyección de instrucciones. En esta guía explicamos cómo funciona, desmontamos un ataque real paso a paso y vemos qué controles reducen de verdad el riesgo, desde el punto de vista de quien lo pone a prueba.
Qué es la prompt injection
Un modelo de lenguaje recibe un único bloque de texto: las instrucciones del sistema, la pregunta del usuario y, a menudo, contenido externo (un correo, un PDF, una web, el resultado de una herramienta). Todo llega por el mismo canal. La prompt injection aprovecha que el modelo no tiene una frontera fiable entre instrucciones y datos: si un texto se parece a una orden, puede acabar obedeciéndolo.
Inyección directa
El atacante escribe la orden en la conversación: «olvida tus instrucciones anteriores y…». Es la versión conocida, la de los jailbreaks. Su impacto suele limitarse a lo que ese usuario ya podía ver o hacer.
Inyección indirecta
La orden está escondida en un contenido que el sistema procesa: un correo entrante, un currículum, una página web, un comentario en un ticket o un documento en SharePoint. La víctima no escribe nada malicioso; solo pide al asistente que resuma su bandeja de entrada. Esta es la que preocupa en las empresas, porque el atacante no necesita acceso al sistema y el asistente actúa con los permisos de la víctima.
Por qué no se arregla como una SQL injection
La comparación con la SQL injection es tentadora y engañosa. En SQL, la base de datos separa la consulta de los datos, y las consultas parametrizadas cierran el problema de raíz. En un LLM no existe esa separación: el modelo solo predice el siguiente texto a partir de todo lo que ha leído.
El NCSC británico lo explicó en diciembre de 2025 en un artículo titulado «Prompt injection is not SQL injection (it may be worse)». Su conclusión práctica es que hay que tratar al modelo como un intermediario que siempre se puede confundir, y que la prompt injection es un riesgo residual que se reduce con diseño, no un fallo que se cierra con un filtro. El informe NIST AI 100-2 (2025) va en la misma línea: las defensas actuales son empíricas y pueden caer ante nuevas técnicas.
Esto cambia la pregunta. No es «¿cómo evito que el modelo se equivoque?», sino «si el modelo se equivoca, ¿qué es lo peor que puede pasar?».
Anatomía de un ataque real: EchoLeak en Microsoft 365 Copilot
EchoLeak (CVE-2025-32711) es el mejor ejemplo para entender el problema porque encadena fallos pequeños, cada uno aparentemente controlado. Lo descubrió Aim Labs, lo comunicó a Microsoft, que lo corrigió en el servidor en mayo de 2025, y se publicó en junio. Microsoft no detectó explotación real.
- El correo. El atacante envía un correo redactado como una petición de negocio normal, con instrucciones escondidas para el asistente y una frase pidiéndole que no mencione ese correo. El tono evitaba el clasificador de Microsoft que detecta inyecciones.
- El enlace. Copilot eliminaba los enlaces en línea de sus respuestas, pero no los enlaces «de referencia» de Markdown. El atacante pedía al asistente que construyera uno con datos internos dentro de la URL.
- La imagen. Un enlace requiere un clic. Una imagen no: el navegador la carga sola al mostrar la respuesta. Usando una imagen de referencia, la petición salía sin intervención del usuario.
- El dominio permitido. La política de seguridad del navegador bloqueaba dominios externos, pero permitía uno de Microsoft que, a su vez, solicitaba la URL indicada. Ese intermediario llevaba los datos hasta el servidor del atacante.
La lección para cualquier empresa: ningún control falló de forma escandalosa. Falló la suposición de que cada capa bastaba por sí sola. El análisis publicado sobre el caso (arXiv, 2025) recomienda exactamente lo contrario: varias capas, y asumir que cualquiera puede fallar.
Dónde aparece en tu empresa
| Sistema | Por dónde entra la instrucción | Qué puede pasar |
|---|---|---|
| Asistente de correo o de Microsoft 365 / Google Workspace | Un correo externo | Fuga de información interna, respuestas manipuladas |
| Buscador interno con RAG | Un documento subido por un tercero o un empleado | Respuestas falsas, fuga entre departamentos |
| Cribado de currículums con IA | Texto oculto en un CV | Candidatos puntuados de forma fraudulenta |
| Chatbot de atención al cliente | La propia conversación | Compromisos comerciales falsos, daño reputacional |
| Agente con herramientas (CRM, ERP, pagos) | Cualquier contenido que lea | Acciones no autorizadas con permisos reales |
| Navegador o asistente que lee webs | Una página web | Exfiltración, acciones en nombre del usuario |
Qué no funciona (o funciona menos de lo que parece)
- Listas negras de frases. El atacante reformula, traduce o codifica. El NCSC desaconseja expresamente confiar en ellas.
- Pedirle al modelo que «no obedezca instrucciones externas». Es otra instrucción más, que también se puede anular.
- Guardar secretos en el prompt del sistema. Se pueden extraer. El prompt no es un control de acceso.
- Un único clasificador. Ayuda, pero EchoLeak demuestra que se puede esquivar con un tono neutro.
Qué sí reduce el riesgo: defensa en capas
- Mínimo privilegio. El asistente no debe poder hacer más que el usuario que lo usa, ni más de lo que la tarea necesita. Un resumidor de correo no necesita enviar correos.
- Separar contenido no confiable. Marcar lo que viene de fuera (correos, webs, documentos de terceros) y no mezclarlo con datos sensibles en la misma tarea si no hace falta.
- Controles deterministas fuera del modelo. Las decisiones importantes (a qué herramienta llamar, a qué dominio conectarse, qué importe aprobar) las valida código normal, no el LLM.
- Controlar las salidas y el tráfico de salida. Lista permitida de dominios, no renderizar imágenes ni enlaces externos generados por el modelo, y revisar los intermediarios que permite la política de seguridad del navegador.
- Confirmación humana para acciones con impacto: enviar, pagar, borrar, compartir.
- Registro y monitorización de entradas, salidas y llamadas a herramientas, para detectar comportamientos raros y poder investigar.
- Pruebas continuas. Cada modelo nuevo, fuente de datos o herramienta cambia la superficie de ataque.
Cómo se prueba la prompt injection en una auditoría
En un pentesting de IA no basta con probar frases conocidas en el chat. Un enfoque útil cubre al menos:
- Mapa de entradas: todas las fuentes de texto que llegan al modelo, incluidas las indirectas.
- Inyección directa e indirecta en cada fuente, con variantes codificadas, en otros idiomas y en varios turnos.
- Objetivos de impacto, no de «romper» el modelo: ¿se puede sacar un dato de otro usuario?, ¿se puede provocar una llamada a una herramienta?, ¿se puede sacar información fuera de la empresa?
- Canales de salida: enlaces, imágenes, Markdown, llamadas a API y correos generados.
- Automatización: herramientas de código abierto como PyRIT (de Microsoft) o garak permiten probar miles de variantes; el criterio de qué probar y la explotación final siguen siendo manuales.
Si quieres una visión más amplia de los ataques a modelos de lenguaje, consulta nuestro artículo sobre hacking de la IA y la guía del OWASP Top 10 para LLM y agentes.
Preguntas frecuentes sobre prompt injection
¿Qué es la prompt injection en pocas palabras?
Un ataque en el que un texto consigue que un modelo de IA siga instrucciones distintas de las de su propietario. Puede escribirlo el usuario (directa) o estar escondido en un contenido que el modelo lee (indirecta).
¿Se puede eliminar del todo?
Con la tecnología actual, no. El NCSC británico y el NIST coinciden en que es un riesgo residual. Lo que sí se puede es limitar mucho su probabilidad y, sobre todo, su impacto.
¿Qué diferencia hay entre prompt injection y jailbreak?
El jailbreak busca que el modelo salte sus normas de contenido. La prompt injection busca que el sistema haga algo que su propietario no quería, como revelar datos o usar una herramienta. Un jailbreak puede ser una técnica dentro de una inyección.
¿Afecta a Copilot, ChatGPT o Gemini en la empresa?
Afecta a cualquier sistema basado en modelos de lenguaje que procese contenido externo. Los fabricantes añaden defensas, pero la configuración, los permisos y los conectores de cada empresa determinan el impacto real.
¿Cómo sé si mi chatbot o asistente es vulnerable?
Con un pentest de IA que pruebe la inyección directa e indirecta en todas las fuentes de datos y mida el impacto real: fuga de información, uso de herramientas y canales de salida.
Contenido revisado por el equipo de consultoría de BCNSoluciona · octubre de 2026. Fuentes: NCSC (diciembre de 2025), NIST AI 100-2 E2025, OWASP GenAI Security Project y análisis técnico de EchoLeak (CVE-2025-32711).
