Inyección de prompt: riesgos de fuga de datos de los asistentes de IA

¿Qué es una inyección de prompt?

La inyección de prompt es un ciberataque contra los grandes modelos de lenguaje (LLM): el atacante disfraza entradas maliciosas como entradas legítimas [10]. Apunta a los servicios que se apoyan en la IA [11]. Su objetivo es llevar al modelo a ignorar sus instrucciones originales [13] y a seguir en su lugar las del atacante [27].

Los tres elementos de la definición

• Una entrada de apariencia legítima: el texto trampa parece una consulta o un contenido ordinario [10].
• Un efecto sobre las instrucciones: el modelo abandona las instrucciones que encuadraban su comportamiento [27].
• Un beneficiario: ahora son las órdenes del atacante las que se siguen, y no las del diseñador o del usuario legítimo [27].

Una fuente la presenta como un medio para desviar una IA sin explotar un fallo en el sentido clásico [28]. Para un CISO, esto cambia la naturaleza del problema: la manipulación pasa por el canal normal de uso del modelo, y no por una vulnerabilidad de código que bastaría con parchear.

Dos analogías habituales, para manejar con cautela

En la literatura de los editores aparecen dos comparaciones:

• La inyección SQL: Flutteris describe la inyección de prompt como «el equivalente en IA de la inyección SQL» [27].
• La ingeniería social: OpenAI la califica de ataque de ingeniería social específico de la IA conversacional [16].

Estas dos fuentes son actores comerciales. Sus comparaciones son pedagógicas: ayudan a situar el riesgo frente a ataques conocidos, pero no demuestran una equivalencia técnica. La primera pone el acento en la entrada forjada que desvía un sistema; la segunda, en la persuasión de un interlocutor. La inyección de prompt toma algo de ambos sin confundirse con ninguno.

Queda por entender por qué un modelo se deja desviar de este modo, y por qué vías llega la entrada maliciosa: son los objetos de las secciones siguientes.

¿Por qué se dejan manipular los LLM?

Los LLM se dejan manipular porque no separan las instrucciones que se les dan de los datos que leen: el modelo trata todas las entradas como un prompt continuo [34].

Una frontera que se desdibuja

Cuando un agente recibe «analiza este contrato», «resume este correo» o «reformula este párrafo», ejecuta la consigna. Pero para cumplir la tarea lee un documento, y el contenido de ese documento no tiene para él un estatus distinto al de la consigna inicial [34]. Un texto colado en el documento puede entonces tomarse por una orden. La IA se convierte así en un vector de ataque porque borra la frontera entre datos e instrucciones [21].

Las consecuencias se ven en el caso indirecto: la IA ejecuta entonces las órdenes ocultas como si vinieran del usuario legítimo [36]. Un análisis de Palo Alto Networks sobre los asistentes de programación va en la misma línea: el modelo no distingue de forma fiable las instrucciones del sistema de las peticiones del usuario [33].

Un ataque que no explota ningún fallo

La inyección de prompt desvía una IA sin explotar un fallo en el sentido tradicional [28]. No se apoya en un error de implementación. Aprovecha el funcionamiento normal del modelo para volverlo contra sus diseñadores [24]. El modelo hace aquello para lo que fue concebido: seguir las instrucciones que lee.

Las comparaciones propuestas por las fuentes reflejan esta particularidad. Algunas asimilan el ataque a la inyección SQL, ya que el atacante empuja al modelo a abandonar sus instrucciones originales para seguir las suyas [27]. Otras ven un ataque de ingeniería social propio de la IA conversacional [16]. Este segundo paralelo es el más elocuente: no se fuerza ninguna protección, se convence al modelo.

Esta causa de fondo pesa más a medida que los asistentes se abren a datos internos y a la web. Esta ampliación de sus capacidades introduce una forma de riesgo aún mal encuadrada [28]. Cuanto más lee el agente fuentes que no controla, más ocasiones se multiplican de colar en ellas una instrucción. De ahí la idea, defendida por algunas fuentes, de que la seguridad descansa en la reducción de la superficie de ataque, el mínimo privilegio y los controles en cada etapa, más que en una defensa única [39].

¿Qué diferencia hay entre inyección directa e indirecta?

La inyección directa la introduce el atacante en la consulta que dirige al modelo. La inyección indirecta se oculta en una fuente que el asistente procesa, y el usuario legítimo suele ignorarla. Una fuente la define como la inserción de instrucciones maliciosas en una consulta o en una fuente de datos, con el fin de influir en el comportamiento del modelo [23].

Dónde se ocultan las instrucciones

• Directa: la instrucción llega por el canal de la conversación, en forma de consulta.
• Indirecta: la instrucción pasa por los datos que la IA procesa, a menudo sin que el usuario lo sepa [18]. Puede tratarse de un documento, una página web u otra fuente de datos.

El segundo caso funciona porque la IA trata todas las entradas como un prompt continuo. No separa las instrucciones que le dio el usuario («analiza este contrato», «resume este correo») de los datos que está leyendo [34].

Un sitio web que engaña a un asistente

Un sitio web puede bastar para desviar a un asistente. Un artículo dedicado a Claude describe este escenario: el contenido de la página lleva órdenes ocultas, y la IA las ejecuta como si vinieran del usuario legítimo. Las consecuencias posibles son fugas de datos, acciones no autorizadas o respuestas sesgadas [36]. El usuario solo había pedido consultar o resumir una página. El atacante, por su parte, nunca tuvo acceso a la conversación.

Un punto de atención para los agentes

Las fuentes académicas del expediente tratan la inyección indirecta como un riesgo aparte. Un artículo sobre la delegación de una intención en un agente de IA cita la inyección de prompt, «incluida la indirecta», como primer riesgo, y la fuga de datos como segundo [8]. Una obra dedicada a la responsabilidad cuando las máquinas actúan también trata explícitamente la inyección de prompt indirecta [5]. Para un agente que lee fuentes externas y luego actúa, la superficie de ataque no se limita a lo que escribe el usuario: incluye todo lo que el agente abre, lee o consulta.

¿Cómo provoca una inyección de prompt una fuga de datos?

Una inyección de prompt provoca una fuga de datos por tres vías documentadas: acciones no deseadas del agente, las salidas del modelo y la exposición del prompt del sistema. Estas fugas provocadas por un atacante deben distinguirse de las que proceden de los usos cotidianos.

Tres vías de fuga provocadas por el ataque

• Acciones no deseadas del agente. Según Bruno Lussato, citado por franceinfo, un pirata puede elaborar prompts que empujen al agente de IA a actuar contra su función: fuga de datos, ejecución de código o generación de contenidos maliciosos [26]. La fuga de datos sensibles figura también entre los principales riesgos identificados, junto con la toma de control parcial de los sistemas y el daño a la reputación [25].
• Fuga a través de las salidas del modelo. Entre las amenazas frecuentes, una fuente menciona «de la inyección de prompt a la fuga por las salidas» [2]. Lo que responde el modelo puede convertirse, por tanto, en el canal de salida de la información.
• Fuga del prompt del sistema. Está técnicamente emparentada con la inyección de prompt y con el jailbreak [30]. Las claves API y las credenciales figuran entre los elementos expuestos [30]. Cabe deducir que un prompt del sistema no debería contener secretos.

Fugas por uso cotidiano: otro mecanismo

En este segundo caso no interviene ningún atacante. Información confidencial se transmite involuntariamente a servicios de terceros, a través de las interfaces de IA que usan los colaboradores [20]. La causa es un comportamiento de uso, no una manipulación del modelo.

Ambas familias coinciden en la cuestión de los datos introducidos en los prompts. Un análisis de la Shadow AI recomienda preguntarse qué datos integra una herramienta en sus prompts [3]. La información transmitida a un servicio no controlado queda expuesta, haya o no inyección.

Esta distinción importa para un CISO: ambas fugas no requieren las mismas medidas. Según una de las fuentes, con este tipo de asistente, «el verdadero problema de seguridad es la gobernanza» [2].

¿Qué otros daños causan en agentes, memoria y código?

El riesgo de la inyección de prompt no se limita a la fuga de datos: en cuanto un asistente dispone de herramientas, memoria o acceso al código, una instrucción desviada puede desencadenar acciones y no solo divulgaciones.

Acciones no previstas y propagación

Según Bruno Lussato, citado por franceinfo, un pirata puede elaborar prompts que provoquen acciones no deseadas del agente: fuga de datos, ejecución de código o generación de contenidos maliciosos [26]. IBM describe además un escenario de propagación: el mensaje malicioso pide al asistente que lo reenvíe a otros contactos [10]. El ataque deja entonces de limitarse a la primera víctima.

Envenenamiento de la memoria

Pueden inyectarse discretamente instrucciones ocultas en la memoria de asistentes de uso general: Microsoft Copilot, ChatGPT, Claude, Perplexity y Grok [29]. El objetivo ya no es una conversación aislada, sino la memoria del asistente.

Asistentes de programación desviados

El equipo Unit 42 de Palo Alto Networks ha constatado que estos asistentes pueden ser desviados por usuarios o actores malintencionados, a través del chat, del autocompletado o de la generación de pruebas unitarias. Las consecuencias registradas son la inserción de puertas traseras, la fuga de información sensible y la creación de contenidos perjudiciales [33]. Secure Code Warrior informa, por su parte, de un agente de programación manipulado para escribir código vulnerable a inyecciones SQL e instalar herramientas del sistema [17].

Qué valen estas fuentes

Estos casos proceden de un medio de gran público (franceinfo) y de actores comerciales: IBM, Palo Alto Networks, Secure Code Warrior. El artículo que relata el envenenamiento de la memoria también es de un sitio comercial, y el extracto disponible no permite identificar a los autores del estudio que cita [29]. Ninguno de estos elementos es un estudio primario examinado aquí. Ilustran escenarios plausibles y documentados, pero no miden ni su frecuencia ni su tasa de éxito. Un CISO los utilizará, por tanto, para elaborar una lista de escenarios que probar, no para cuantificar un riesgo.

¿Qué dice la OWASP y qué obligaciones impone el RGPD?

Varias fuentes presentan la inyección de prompt como la vulnerabilidad n.º 1 según la OWASP. Según una fuente comercial, una fuga de datos que ella provoca se rige por el mismo régimen del RGPD que un hackeo clásico.

Su lugar en el referencial OWASP

La OWASP se describe como una organización internacional de referencia en ciberseguridad. Un sitio especializado indica que clasifica la inyección de prompt como vulnerabilidad n.º 1 [24]. Otro proveedor de ciberseguridad habla del «peligro número uno de los LLM según la OWASP» [37]. Estas dos fuentes son contenidos de profesionales, no el referencial en sí. Para una clasificación oponible, hay que consultar directamente el documento de la OWASP.

Un artículo dedicado al «OWASP Top 10 LLM 2026» menciona, por su parte, un enfoque en los riesgos agénticos, el «Unbounded Consumption», la inyección de prompt y el OWASP ASI [40]. El expediente no permite detallar la clasificación de 2026, ni precisar qué lugar ocupa en ella la inyección de prompt. Por tanto, no lo afirmamos.

Obligaciones del RGPD en caso de fuga

Según core.security, una fuente comercial, el responsable del tratamiento que sufre una fuga de datos de clientes provocada por una inyección de prompt se expone a las mismas obligaciones legales que con un hackeo clásico [32]. La fuente cita:

• la notificación a la CNIL en un plazo de 72 horas;
• sanciones económicas que pueden alcanzar el 4 % de la facturación mundial [32].

Según esta fuente, la técnica de ataque no cambia, por tanto, la calificación del incidente. Para un CISO, la inyección de prompt es una posible causa de violación de datos, que debe integrarse en los procedimientos de gestión de incidentes al mismo nivel que una intrusión.

El expediente no contiene el texto del RGPD ni una publicación de la CNIL. Estos elementos son reportados por un actor comercial, y el DPO deberá confirmarlos en los textos oficiales.

¿Cómo reducir el riesgo en la práctica?

Ninguna defensa única basta: la defensa en profundidad combina la reducción de la superficie de ataque, el mínimo privilegio y los controles en cada etapa. [39] Cada capa limita los daños que las demás no han podido evitar.

Las palancas que el expediente permite respaldar

• Limitar lo que el agente puede alcanzar. La inyección de prompt preocupa menos si el agente no puede acceder a los datos sensibles. [15] Databricks, editor de plataformas de datos, recomienda por ello restringir las capacidades del agente, en particular su acceso a los sistemas sensibles y a los datos privados. [15]
• Situar al humano y los derechos en el lugar adecuado. Una fuente especializada menciona la validación humana y los controles de acceso granulares, en particular en el sector financiero. [35] La idea es que una acción sensible no dependa solo de la decisión del modelo.
• Asegurar antes de desplegar. Según Flowpi, editor comercial, los chatbots y copilotos deben protegerse antes de su puesta en producción. Sin salvaguardas, la inyección de prompt y las fugas de datos amenazan la marca, los clientes y el retorno de la inversión. [22]
• Tratar el tema como una cuestión de gobernanza. Para un asistente empresarial, «el verdadero problema de seguridad es la gobernanza». Esto supone una postura de seguridad de datos dedicada a la IA. [2]

Un límite que asumir

Estas medidas reducen el riesgo sin eliminarlo. Una prueba que movilizó a 2000 hackers contra un asistente de IA concluye que la inyección de prompts sigue siendo un problema de seguridad real. [35] Las fuentes del expediente no presentan ninguna medida técnica infalible, y las que detallan medidas son, en su mayoría, editores o consultores. Para un CISO, la consecuencia es práctica: hay que diseñar la arquitectura suponiendo que una inyección acabará pasando, y preguntarse qué podrá leer, ejecutar o transmitir entonces el agente.

¿Cómo encuadra Oupi las acciones de su agente?

Oupi encuadra las acciones de su agente según dos principios: los actos sensibles están sujetos a validación humana, y la ejecución del agente está aislada. Esta sección describe estos principios sin detallar su puesta en práctica.

Dos principios

• Validación humana de los actos sensibles. El agente no lleva a término por sí solo una acción con consecuencias. Una persona la valida antes de que se ejecute.
• Ejecución aislada. El agente trabaja en un perímetro separado, lo que circunscribe lo que una acción desviada podría alcanzar.

La relación con las recomendaciones generales

Estos dos principios coinciden con las medidas recomendadas en el resto de este expediente.

• Limitar las capacidades del agente. Databricks, editor de plataformas de datos, indica que la inyección de prompt preocupa menos si el agente no puede acceder a los datos sensibles. Recomienda restringir el acceso a los sistemas sensibles y a los datos privados [15]. El aislamiento de la ejecución va en esta dirección: reduce lo que un agente manipulado puede tocar.
• Mantener la supervisión humana. Un artículo de Roboto, actor comercial, menciona la validación humana, junto con controles de acceso granulares, entre las respuestas adoptadas en el sector financiero [35]. La validación de los actos sensibles responde a esta lógica: una instrucción inyectada no basta por sí sola para desencadenar una acción crítica.
• Reducir la superficie de ataque. Según una guía técnica de seguridad de las aplicaciones LLM, la seguridad descansa en la reducción de la superficie, el mínimo privilegio y los controles en cada etapa, y no en una defensa única [39]. La validación humana y el aislamiento son dos de esos controles.

Los límites de este dispositivo

Estas medidas reducen el riesgo, pero no lo eliminan. Una prueba realizada con 2 000 participantes sobre un asistente de IA concluye que la inyección de prompts sigue siendo un problema de seguridad real [35]. La validación humana también supone que la persona entienda lo que aprueba. Complementa las demás protecciones (control de salidas, detección, monitorización) y no las sustituye, de acuerdo con el enfoque de defensa en profundidad [39].

Los compromisos de Oupi en materia de confianza se presentan en la página Confianza.