Si vienes del mundo de las bases de datos, conoces la inyección SQL y sabes que se resolvió: consultas parametrizadas, y el problema desapareció. La pregunta natural es por qué no se ha hecho lo mismo con los modelos de lenguaje.
La respuesta es que no se puede, al menos no todavía.
Por qué es estructural
El Top 10 de OWASP para aplicaciones LLM de 2026 mantiene la inyección de prompts en el puesto número uno. Su razonamiento es el que importa: el modelo procesa instrucciones y contenido no confiable dentro de la misma ventana de contexto, y no existe un equivalente a la consulta parametrizada que los separe.
En SQL puedes decirle al motor “esto es código, esto es dato” y él respeta la frontera. En un LLM, todo es texto. El documento que estás resumiendo puede contener una frase que el modelo interprete como instrucción, y no hay una capa que distinga estructuralmente una cosa de la otra.
OWASP añade un detalle interesante: la inyección conserva el primer puesto pese a un historial de incidentes públicos delgado, algo que atribuye a un efecto de defensa — se invierte tanto en contenerla que los ataques exitosos no acaban en bases de datos públicas.
Lo que ha cambiado en 2026
La agencia excesiva subió del sexto puesto en 2025 al tercero en 2026. No es casualidad que coincida con el año de los agentes.
El motivo es directo: la inyección de prompts pasa de ser un problema de contenido a ser un problema de acción. Un modelo que sólo redacta texto y se equivoca produce un texto malo. Un agente con credenciales, memoria persistente y acceso a herramientas que se equivoca ejecuta algo.
Los despliegues actuales dan a estos sistemas acceso a ficheros, bases de datos, código, mensajería y procesos de negocio. La superficie ya no es la conversación: es todo lo que el agente puede tocar.
Cómo se contiene
No se elimina. Se contiene, y el planteamiento correcto es el de siempre en seguridad: asumir el compromiso y limitar el radio.
- Mínimo privilegio, de verdad. El agente accede a lo que necesita para esa tarea, no a lo que su cuenta de servicio permite. Credenciales por tarea, no por sistema.
- Separar lectura de escritura. Leer contenido no confiable y escribir en sistemas críticos no deben convivir en el mismo contexto sin una aprobación humana entre medias.
- Confirmación humana en lo irreversible. Enviar, pagar, borrar, publicar, modificar permisos. Todo lo que no se puede deshacer pasa por una persona.
- Filtrado de salida, no sólo de entrada. Vigila lo que sale: fuga de datos del contexto, llamadas a herramientas inesperadas, URLs con parámetros raros.
- Registro por paso y alertas. Si no puedes reconstruir qué hizo el agente y por qué, tampoco podrás responder a un incidente.
- Tratar todo contenido externo como hostil. Correo, PDF, página web, ticket de cliente, resultado de búsqueda. Todo.
La pregunta para tu proveedor
Si estás evaluando una herramienta de IA con acceso a tus sistemas, hay una pregunta que separa a los que se lo han pensado de los que no:
“¿Qué pasa si el documento que procesa vuestro agente contiene instrucciones dirigidas a él?”
Si la respuesta es “el modelo es lo bastante bueno para ignorarlas”, busca otro proveedor. Si la respuesta habla de aislamiento, privilegios acotados y aprobaciones, estás hablando con alguien que entiende el problema.