Un ataque de inyección de prompts es ahora una de las principales amenazas de seguridad en IA porque puede hacer que un sistema de IA ignore sus instrucciones reales, revele datos sensibles o haga un uso indebido de las herramientas conectadas. OWASP situó la inyección de prompts como LLM01 en su Top 10 de 2025 para aplicaciones con LLM, y Gartner la calificó como un problema crítico de la GenAI en 2026. El riesgo se intensifica cuando los agentes de IA pueden navegar, hacer clic, llamar a APIs o actuar con tus permisos.
Conceptos básicos de los ataques de inyección de prompts: directa frente a indirecta
La intención de búsqueda aquí es informativa, con un enfoque práctico de seguridad: quieres saber qué es el ataque, por qué organizaciones serias lo están tratando de repente como un riesgo de nivel directivo y qué puedes hacer realmente al respecto. Un ataque de inyección de prompts apunta a las instrucciones que rodean a un modelo de lenguaje de gran tamaño en lugar de a una base de datos, un servidor o un campo de contraseña.
El Top 10 de LLM de OWASP de 2025 define la inyección de prompts directa como una entrada maliciosa del usuario enviada directamente al modelo. Piensa en un usuario que le dice a un bot de soporte que ignore su política y revele instrucciones ocultas. Suena infantil. A veces funciona.
La inyección de prompts indirecta es más peligrosa porque la instrucción hostil se encuentra en material externo que el modelo procesa después: una página web, un correo electrónico, un documento, un ticket, una invitación de calendario, una notificación o un repositorio de código. Puede que el usuario nunca la vea. La IA la lee y la trata como parte del contexto de la tarea.
Esa distinción importa para cualquiera que esté creando productos de IA, especialmente sistemas que usan herramientas. Si estás siguiendo cómo los agentes autónomos están pasando de las demos a los flujos de trabajo reales, los riesgos descritos en implementaciones prácticas de IA agéntica ya no son notas a pie de página teóricas sobre seguridad.
Por qué esta amenaza llegó a lo más alto de las listas de seguridad en IA
OWASP puso “LLM01:2025 Prompt Injection” en primer lugar de su Top 10 de 2025 para aplicaciones con LLM. Entre los impactos que enumera figuran acciones no intencionadas, divulgación de información sensible e influencia sobre el uso de herramientas o la toma de decisiones. No son molestias menores de chatbot; son modos de fallo empresariales.
Gartner impulsó el problema con más fuerza en 2026. El 28 de mayo de 2026 publicó “Cybersecurity Threat: Prompt Injection”, describiendo el problema como una amenaza crítica e inevitable para las aplicaciones de IA empresariales y los agentes de IA emergentes. El 2 de junio de 2026, su ThreatScape 2026–2027 incluyó la inyección de prompts entre cuatro amenazas críticas que requieren Ciberseguridad mejoras urgentes.
Los organismos de seguridad también están intentando corregir una idea equivocada muy extendida. El UK National Cyber Security Centre dijo en 2026 que la inyección de prompts no equivale a la inyección SQL. Estoy de acuerdo con ese planteamiento: tratarlo como un viejo fallo de saneamiento de entradas lleva a los equipos a prometer en exceso soluciones que no tienen.
Una inyección SQL suele explotar un límite preciso del analizador. Un ataque de inyección de prompts explota la ambigüedad del lenguaje, la jerarquía de instrucciones, el contexto de las herramientas y la confianza. El lenguaje natural es la superficie de ataque, por eso “simplemente filtrar las palabras malas” es un remedio muy débil.
El problema de los agentes: cuando las palabras pueden desencadenar acciones
Los chatbots ya eran bastante arriesgados cuando solo generaban texto. Los agentes elevan el riesgo porque pueden recuperar datos, invocar herramientas, acceder a sistemas privados y realizar acciones. Microsoft y IA abierta ambos describen la inyección de prompts como un riesgo importante cuando los sistemas de IA pueden navegar, hacer clic, usar API u operar con permisos de usuario.
Imagina un asistente de IA que puede resumir correos electrónicos, leer un registro de CRM, crear un evento de calendario y enviar un mensaje. Una instrucción maliciosa oculta en un correo electrónico podría decirle al asistente que reenvíe notas confidenciales o dé prioridad a una factura falsa. El atacante no hackeó el buzón en el sentido clásico. Envenenó el material en el que confiaba el asistente.
OpenAI dijo el 22 de diciembre de 2025 que la inyección de prompts era uno de los riesgos más significativos frente a los que se defendía activamente para el modo agente de ChatGPT Atlas. La guía de seguridad de Microsoft de 2026 para sistemas agénticos subraya igualmente el principio de mínimo privilegio, la aprobación humana, la supervisión y los límites a las acciones autónomas.
La parte incómoda es la cadena de permisos. Si un empleado puede aprobar reembolsos, descargar registros de clientes o actualizar datos de producción, un agente que actúe en nombre de ese empleado puede ser capaz de hacer lo mismo, salvo que el sistema limite su autoridad. Para entender por qué la IA puede ayudar y perjudicar a los defensores al mismo tiempo, consulta este análisis más amplio sobre el doble filo de la IA en la ciberseguridad.
Casos y estudios recientes que conviene conocer
Los informes del mundo real en 2026 muestran lo variados que pueden ser los vectores de ataque. El 4 de junio de 2026, Tom’s Guide cubrió una investigación de SafeBreach Labs que describía una vulnerabilidad de inyección de prompts basada en notificaciones que afectaba a Google Gemini en Androide. El detalle destacable es la vía de entrega: una notificación móvil, no un cuadro de prompt de aspecto siniestro.
Las herramientas de desarrollo asistidas por IA tienen su propia versión del problema. Un artículo de arXiv del 23 de marzo de 2026, “Are AI-assisted Development Tools Immune to Prompt Injection?”, analizaba ataques a través de vectores de envenenamiento de herramientas. Para los equipos de software que ya están comparando agentes y asistentes de programación, ese riesgo está muy cerca de decisiones cotidianas del flujo de trabajo como las planteadas en comparativas de herramientas para desarrolladores.
Dos artículos de mayo de 2026 ofrecen cifras útiles, aunque aleccionadoras. “AI Agents May Always Fall for Prompt Injections”, publicado el 17 de mayo de 2026, caracterizaba la inyección de prompts como la vulnerabilidad más crítica en los agentes de IA desplegados. Otro artículo de arXiv publicado el 23 de mayo de 2026, sobre operaciones de seguridad aumentadas con LLM, informó de que el éxito de los ataques descendía del 26.6% con prompting ingenuo al 11.8% con su defensa probada más sólida.
Aquí está el cálculo concreto que muchas síntesis omiten: esa caída del 26.6% al 11.8% supone una reducción de 14.8 puntos porcentuales, o aproximadamente una reducción relativa del 55.6%. Un buen avance. Aun así, no es lo bastante seguro para acciones de alto riesgo sin supervisión, porque aproximadamente uno de cada nueve intentos tuvo éxito incluso con la defensa probada más sólida.
| Fuente o evento | Año/fecha | Qué dice sobre la inyección de prompts | Señal práctica |
|---|---|---|---|
| OWASP Top 10 for LLM Applications v2.0 | 2025 | Enumera LLM01:2025 Prompt Injection como el primer riesgo | Trátalo como un riesgo principal de las aplicaciones de IA, no como un fallo marginal |
| Nota de seguridad del modo agente de OpenAI Atlas | 2025-12-22 | Califica la inyección de prompts como uno de los riesgos más significativos frente a los que se defiende | La navegación y los clics del agente necesitan controles especiales |
| Guía de Microsoft sobre riesgos agénticos | 2026 | Vincula el riesgo a agentes que recuperan datos, usan herramientas y actúan con permisos | Restringe los permisos y la autonomía |
| Estudio de arXiv sobre operaciones de seguridad | 2026-05-23 | Informa de que el éxito desciende del 26.6% al 11.8% con una defensa más sólida | La defensa ayuda, pero el riesgo residual sigue siendo significativo |
| Gartner 2026–2027 ThreatScape | 2026-06-02 | Nombra la inyección de prompts como un problema crítico de seguridad de la GenAI | Los equipos de seguridad deberían integrar mitigaciones específicas de IA en el desarrollo |
Cómo un ataque de inyección de prompts perjudica a una empresa
El riesgo más evidente es la fuga de datos. Un modelo podría revelar prompts del sistema, notas internas, documentos recuperados, respuestas de API o fragmentos de datos de usuarios si se le engaña para que trate las instrucciones del atacante como de mayor prioridad que la política. En los sectores regulados, eso puede convertirse muy rápidamente en un incidente de cumplimiento.
El perjuicio operativo puede ser aún peor. La guía de 2025 de OWASP destaca las acciones no deseadas y la influencia sobre el uso de herramientas o la toma de decisiones. Si un agente puede actualizar un registro, aprobar una acción, enviar un mensaje o activar un flujo de trabajo, el objetivo del ataque ya no es «el modelo». Es el proceso de negocio que hay detrás del modelo.
También hay un riesgo reputacional que rara vez aparece en los brillantes planes de despliegue de IA: la confusión en las auditorías. Cuando un agente toma una mala decisión después de procesar una página o un mensaje envenenado, los registros pueden mostrar que la cuenta del usuario legítimo realizó la acción. Sin una captura cuidadosa de los eventos, puede que te cueste demostrar qué leyó el modelo, qué herramienta llamó y por qué.
Los servicios financieros, la atención al cliente, la administración sanitaria, las operaciones legales y el desarrollo de software se enfrentan todos a distintas versiones del mismo problema. Los flujos de pago agentic merecen una precaución adicional; si estás siguiendo la evolución hacia las compras y los pagos asistidos por IA, lo que está en juego en materia de seguridad en torno a agentic AI payment systems es evidente.
¿Qué reduce realmente el riesgo?
Ninguna fuente primaria seria afirma que exista una cura permanente. OpenAI considera la inyección de prompts un desafío de seguridad de la IA a largo plazo que requiere defensas continuas. La guía de 2026 de Microsoft y los materiales de OWASP apuntan a una defensa en profundidad, que es menos vistosa que un detector mágico, pero mucho más creíble.
Empieza por los controles aburridos. Funcionan. El acceso de mínimo privilegio limita el daño si se manipula un sistema de IA, mientras que la aprobación humana para operaciones de alto riesgo crea un punto de control antes de que se mueva dinero, cambien registros o salgan datos sensibles de un sistema.
- Separa las instrucciones fiables del sistema del contenido no fiable, y etiqueta por defecto los datos recuperados como no fiables.
- Limita las acciones autónomas, especialmente las compras, los mensajes externos, los cambios de cuenta, la ejecución de código y las exportaciones de datos.
- Usa permisos de herramientas de mínimo privilegio en lugar de dar a un agente el mismo acceso amplio que a un administrador humano.
- Añade aprobación humana para las operaciones de alto impacto, con el contenido fuente visible para la persona revisora.
- Supervisa y registra prompts, fuentes recuperadas, llamadas a herramientas, salidas e intentos bloqueados para su investigación posterior.
- Haz red teaming de ataques directos e indirectos antes del lanzamiento y, después, repite las pruebas tras cambios en el modelo, la herramienta o la política.
- Valide las entradas y salidas, e implemente la detección o el bloqueo de instrucciones manipuladoras allí donde haya demostrado su utilidad.
Mi opinión: si su agente de AI puede realizar acciones irreversibles y usted no dispone de una capa de aprobación humana, está aceptando un riesgo que la mayoría de los clientes no aprobarían conscientemente. La autonomía debe ganarse en ámbitos reducidos, no concederse porque una demo haya parecido fluida.
Los marcos pueden ayudar a los equipos a evitar puntos ciegos. OWASP publicó su “Top 10 for Agentic Applications 2026” el 9 de diciembre de 2025, desarrollado con más de 100 expertos, y Microsoft relaciona riesgos de agentes como el secuestro de objetivos con mitigaciones en Copilot Studio. El trabajo sobre seguridad de la AI relacionado con NIST también forma parte del panorama más amplio de la gobernanza, como se explica en este artículo sobre marcos de control de ciberseguridad de la AI.
Una prueba práctica de riesgo antes de lanzar una funcionalidad de AI
Antes del lanzamiento, plantee una pregunta difícil: ¿qué puede hacer el sistema después de leer contenido hostil? Si la respuesta es “resumirlo”, el riesgo puede ser manejable. Si la respuesta es “enviar, comprar, eliminar, aprobar, desplegar o divulgar”, el sistema necesita controles más sólidos.
Un método de puntuación útil es sencillo. Asigne de 0 a 3 puntos a cada uno de estos factores: sensibilidad de los datos, capacidad de las herramientas, autonomía, exposición a contenido externo y lagunas de auditabilidad. Un asistente de resumen de documentos con poca capacidad de herramientas podría obtener 4 o 5 puntos; un agente de compras que lee correos de proveedores y puede enviar pedidos podría alcanzar fácilmente 12 o más.
Los números obligan a mantener una conversación. Una puntuación superior a 10 debería activar la aprobación humana, permisos más restringidos, pruebas de red team y puertas de lanzamiento. No es un estándar formal, pero es mejor que la habitual manta de seguridad de “tenemos un prompt de política”.
Los equipos de seguridad también deberían cuestionar un contraargumento habitual: “Los humanos también caen en el phishing, así que los agentes no son peores”. Cierto, pero incompleto. Una persona comprometida suele actuar a velocidad humana; un agente conectado puede procesar cientos de elementos, llamar herramientas rápidamente y producir explicaciones convincentes que ocultan la cadena de instrucciones maliciosas.
Preguntas frecuentes
¿Qué es un ataque de inyección de prompts en términos sencillos?
Un ataque de inyección de prompts es un intento de hacer que un sistema de IA siga instrucciones maliciosas que entran en conflicto con sus reglas reales. Puede ser escrito directamente por un usuario o estar oculto dentro de contenido externo que la IA lee.
¿Es la inyección de prompts lo mismo que la inyección SQL?
No. El NCSC del Reino Unido dijo en 2026 que la inyección de prompts no es equivalente a la inyección SQL. La inyección SQL se dirige a comandos estructurados de bases de datos, mientras que la inyección de prompts se dirige a instrucciones del lenguaje, el contexto y el comportamiento del modelo.
¿Pueden detenerse por completo los ataques de prompt injection?
Las fuentes primarias no respaldan esa afirmación. OpenAI describe la inyección de prompts como un desafío de seguridad de la IA a largo plazo, y una investigación de 2026 mostró defensas que reducían el éxito de los ataques, pero no lo eliminaban.
¿Por qué los agentes de IA están más expuestos que los chatbots?
Los agentes pueden usar herramientas, explorar contenido, acceder a datos privados y realizar acciones con permisos de usuario. Por tanto, un ataque de inyección de prompts exitoso contra un agente puede afectar a flujos de trabajo reales, no solo a una respuesta de texto.
¿Cuál es la primera medida de mitigación que deberían aplicar las empresas?
Aplique el principio de mínimo privilegio y limite las acciones autónomas. Si la AI no tiene permiso para exportar datos, aprobar pagos o cambiar registros sin revisión, una manipulación exitosa tendrá menos margen para causar daños.
ES 
EN 
FR