La inyección de prompt es el riesgo número uno de las aplicaciones empresariales con modelos de lenguaje según OWASP, que la mantiene en el primer puesto de su Top 10 por segunda edición consecutiva. No es un escenario teórico ni un problema de laboratorio: es la consecuencia directa de cómo funcionan estos sistemas.
Un modelo de lenguaje no distingue entre las instrucciones que le da su desarrollador y el texto que procesa. Todo llega como palabras. Si dentro de un documento que el sistema lee hay algo con forma de instrucción, existe la posibilidad de que lo trate como tal.
La versión conocida —un usuario escribiendo «ignora tus instrucciones»— es la menos preocupante, porque el atacante tiene que estar delante y sus permisos son los de un usuario cualquiera.
La versión que importa en un entorno empresarial es la inyección indirecta: el texto malicioso no lo escribe el usuario, viene dentro del contenido que el sistema procesa como parte de su trabajo normal.
Los vectores habituales:
En todos los casos el flujo es el mismo: alguien externo escribe texto que tu sistema leerá y que puede influir en lo que hace. Y en todos los casos, el daño posible es exactamente igual al alcance de los permisos que le hayas dado.
La respuesta intuitiva es filtrar las instrucciones sospechosas en la entrada. No funciona de forma fiable, por tres razones:
El lenguaje tiene infinitas formas. Cualquier lista de patrones prohibidos se puede reformular. La instrucción puede estar en otro idioma, parafraseada o distribuida en varias frases.
Puede estar oculta. Texto en blanco sobre blanco en un PDF, metadatos, contenido que el usuario no ve pero el sistema sí lee.
El filtro no puede saber la intención. Un correo legítimo puede contener la frase «por favor, envía esto a contabilidad». El sistema no tiene forma robusta de decidir si eso es una instrucción para él o información para una persona.
La conclusión operativa es incómoda y clarificadora: hay que asumir que la inyección va a ocurrir y diseñar para que no importe.
Principio | Qué implica | Qué evita |
|---|---|---|
Permiso mínimo | El sistema solo accede a lo que su tarea concreta requiere | Que una instrucción inyectada alcance datos ajenos |
Separación de canales | El contenido externo nunca se trata como instrucción de sistema | Que un PDF redefina el comportamiento |
Lista blanca de acciones | Solo se permiten operaciones enumeradas explícitamente | Que se ejecute algo no previsto |
Validación humana en lo irreversible | Pagos, comunicaciones externas, cambios en producción | Que el daño se materialice sin revisión |
Registro completo | Se guarda qué entró y qué se ejecutó | Que el incidente sea irreconstruible |
Las cinco son decisiones de arquitectura, no configuraciones de la herramienta. Y las cinco cuestan poco si se toman antes de construir, que es la razón por la que este artículo pertenece más a una conversación de diseño que a una de seguridad.
OWASP añade a este cuadro dos riesgos relacionados que conviene nombrar: LLM02, divulgación de información sensible, y LLM06, exceso de capacidad. Los tres forman el mismo problema visto desde ángulos distintos: qué puede leer el sistema, qué puede hacer y quién puede influir en ello. Lo hemos desarrollado en dar permisos a un agente es una decisión de riesgo
Imagina un asistente que procesa las facturas que llegan al correo de administración: extrae importe, proveedor y número de cuenta, y prepara el pago.
Un proveedor falso envía una factura que, en un texto pequeño al pie, incluye una instrucción dirigida al sistema para que utilice otro número de cuenta. Si el asistente tiene permiso para preparar pagos y nadie valida el número de cuenta contra la ficha del proveedor, el fraude se ejecuta con la eficiencia de un sistema automatizado
Nótese que en este ejemplo el modelo no ha fallado: ha hecho exactamente lo que un texto le pidió. El fallo está en el diseño, que permitió que un texto externo determinara un dato crítico sin contraste con la fuente de verdad.
De ahí la regla que repetimos en cada proyecto: el modelo redacta e interpreta; el sistema decide los hechos. Los importes, las cuentas, los estados y los permisos se consultan contra el sistema de origen, nunca se aceptan del contenido procesado.
Cuando alguien presente una solución con IA que lea contenido externo, tres preguntas separan lo serio de lo improvisado:
Un proveedor que responde «nuestro modelo no cae en eso» no ha entendido el riesgo. La contención no depende de la calidad del modelo, depende del alcance que se le haya concedido.
Es la manipulación del comportamiento de un modelo de lenguaje mediante texto que este procesa como si fueran instrucciones. OWASP lo sitúa como el primer riesgo de su Top 10 para aplicaciones con LLM de 2025, porque el modelo no distingue estructuralmente entre las instrucciones del desarrollador y el contenido que analiza.
Es la variante relevante en entornos empresariales: las instrucciones no las escribe el usuario, sino que vienen dentro del contenido que el sistema procesa de forma rutinaria — un correo de proveedor, un PDF, una página web, un ticket de soporte o un campo de formulario.
No de forma fiable. El lenguaje admite infinitas reformulaciones, las instrucciones pueden ocultarse en texto invisible o metadatos, y un filtro no puede determinar la intención. El enfoque correcto es asumir que ocurrirá y limitar el daño posible mediante permisos y controles.
Con cinco principios de diseño: permiso mínimo por tarea, separación entre contenido externo e instrucciones de sistema, lista blanca de acciones permitidas, validación humana obligatoria en operaciones irreversibles y registro completo de entradas y acciones ejecutadas.
Sí, si el sistema los procesa y tiene permisos amplios. El ejemplo típico es una factura que incluye una instrucción para cambiar el número de cuenta de pago. El fallo no es del modelo, sino del diseño que permite que un texto externo determine un dato crítico sin contrastarlo con la fuente de verdad.
Qué ocurre si el contenido procesado incluye instrucciones dirigidas al sistema, qué puede hacer el sistema en el peor de los casos y si podría reconstruirse un incidente ocurrido hace un mes. Una respuesta que niegue la posibilidad del ataque indica desconocimiento del riesgo.
¿Tu sistema de IA lee contenido que escriben terceros? Revisamos alcance, permisos, separación de canales y trazabilidad, y te decimos cuál es el peor escenario posible con el diseño actual. Solicita la revisión →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
