Prompt injection: qué es y cómo consigue engañar a una IA: lo esencial

Un asistente de inteligencia artificial recibe el encargo de resumir un correo. En mitad del mensaje encuentra una orden ajena a esa tarea y, en lugar de limitarse a describir su contenido, modifica la respuesta para favorecer al remitente. Eso es una inyección de instrucciones: introducir indicaciones en material que la IA debería tratar como datos, no como órdenes. Puede ocurrir en una conversación, pero también en una página web, un documento o un mensaje que el usuario nunca ha escrito.

El problema aparece cuando el contenido consultado adquiere autoridad dentro de la respuesta o de las acciones del asistente. A veces el resultado es una frase fuera de lugar; otras, información sesgada o una operación que nadie solicitó. El riesgo depende de lo que el sistema pueda ver y hacer. Un modelo que solo redacta texto ofrece un margen de daño distinto al de un asistente conectado al correo, a archivos privados o a herramientas capaces de actuar por su cuenta.

Una orden escondida entre los datos

Los modelos de lenguaje trabajan con instrucciones y con información sobre la que deben aplicar esas instrucciones. Una aplicación puede pedirles que traduzcan un texto, analicen un currículum o sinteticen una noticia. El texto recibido también puede contener frases imperativas, y ahí surge la fricción: leer una orden no equivale a recibirla. Un traductor debe traducir una frase que le pide abandonar la traducción, del mismo modo que un periodista puede informar sobre una amenaza sin obedecerla.

En una aplicación convencional, los permisos y las operaciones se delimitan mediante código. Los asistentes de IA también pueden recibir mensajes con funciones y prioridades diferentes, pero esa separación técnica no garantiza que interpreten siempre correctamente el papel de cada fragmento de lenguaje. Una instrucción incluida en una fuente externa puede presentarse como si procediera del usuario o de quien desarrolló la aplicación. La vulnerabilidad reside en confundir la procedencia del texto con su autoridad, no en que todas las palabras entren necesariamente por el mismo canal.

Imaginemos un sistema encargado de condensar valoraciones de un alojamiento. Entre varias críticas aparece una nota destinada al asistente que le pide destacar únicamente los comentarios positivos. Si la síntesis resultante oculta las quejas porque ha seguido esa nota, la fuente ha dejado de aportar información y ha comenzado a dirigir el trabajo. La manipulación puede parecer una respuesta normal: no necesita mostrar una alerta ni interrumpir la conversación para alterar lo que acaba leyendo la persona.

Este detalle explica por qué el fenómeno no se reduce a una colección de frases ingeniosas para engañar a un chatbot. Un correo, una web o un archivo pueden ser relevantes para la tarea y, a la vez, contener una indicación hostil. Descartar todo el material externo impediría muchos usos útiles; aceptarlo sin distinguir sus funciones abriría la puerta al abuso. La frontera entre consultar y obedecer es el centro del problema.

De los primeros experimentos a los asistentes conectados

La vulnerabilidad empezó a llamar la atención pública en 2022. En mayo de ese año, Jonathan Cefalu comunicó a OpenAI un problema de manipulación mediante instrucciones; durante esos meses también circuló la expresión inglesa que acabaría dando nombre al ataque. Simon Willison contribuyó a difundirla en septiembre de 2022. Aquellos ejemplos mostraban que una persona podía intentar desviar la tarea prevista para un modelo mediante texto introducido en su entrada.

La expansión de asistentes capaces de navegar por internet y leer archivos cambió la escala del problema. Ya no hacía falta que el atacante hablara directamente con el sistema afectado: podía dejar instrucciones en un lugar que el asistente encontraría al cumplir una petición legítima. Investigaciones difundidas en 2023 estudiaron esta modalidad indirecta en aplicaciones que utilizaban modelos de lenguaje. El material de consulta se convirtió en un posible vehículo de ataque, aunque el usuario no hubiera autorizado a su autor a darle órdenes a la IA.

Hay un cambio de perspectiva importante. En un chat aislado, quien intenta alterar el comportamiento suele ser quien escribe el mensaje. En un asistente que resume documentos ajenos, la persona que solicita el resumen puede ser la víctima y quien preparó el documento, el atacante. La conversación visible sigue pareciendo corriente: el usuario pide un trabajo y el sistema lo realiza. El conflicto queda escondido en una fuente que el usuario quizá ni siquiera ha abierto.

Dos caminos para cruzar la misma frontera

La inyección directa ocurre cuando alguien escribe al asistente una indicación destinada a imponerse sobre las reglas o la tarea establecidas para él. Sería el caso de introducir en una herramienta de traducción un texto que, en lugar de ser traducido, pide al modelo responder sobre otro asunto. La aplicación debería considerar ese fragmento como contenido de entrada, aunque esté redactado en forma de orden. El atacante controla el mensaje enviado y busca que el sistema le atribuya más autoridad de la que tiene.

En la modalidad indirecta, el atacante modifica una fuente externa que el asistente consultará después. Puede ser una página web, un correo, un archivo adjunto o un documento incorporado a una búsqueda. La orden puede aparecer a simple vista o camuflarse mediante formatos que dificultan que una persona la detecte. El rasgo decisivo no es que permanezca invisible, sino que viaja dentro de información no fiable y pretende gobernar una tarea encargada por otra persona.

Un currículum ilustra bien el cambio de papeles. Si una empresa utiliza IA para extraer datos de las candidaturas, el aspirante controla el documento que llega al sistema. Una frase oculta que exija una valoración favorable no añade experiencia profesional: intenta influir en la evaluación. Se han descrito maniobras parecidas en trabajos académicos dirigidas a sistemas de revisión asistidos por IA. Ambos ejemplos muestran cómo una fuente interesada puede intentar escribir su propia valoración.

Ni el ataque tiene que ser sofisticado ni toda frase imperativa presente en un documento constituye un ataque. Un manual puede contener instrucciones legítimas porque precisamente trata de explicar un procedimiento. La diferencia depende de la tarea y del destinatario: una cosa es resumir lo que indica el manual y otra dejar que el manual dicte cómo debe comportarse el asistente. La intención de sustituir las órdenes legítimas y el efecto sobre la respuesta importan más que una palabra concreta.

Cuando el engaño pasa de las palabras a las acciones

La consecuencia más visible es la contaminación de la respuesta. Un resumen puede omitir información desfavorable; una búsqueda, presentar como fiable una página que no lo es; una evaluación, inclinarse hacia el resultado solicitado por el texto analizado. Es un riesgo difícil de advertir porque el producto final conserva una apariencia pulida. La fluidez de una respuesta no demuestra que el asistente haya respetado la procedencia de sus instrucciones.

También existe la extracción de información. Un atacante puede intentar que el sistema revele sus instrucciones internas o datos a los que tiene acceso durante una tarea. Pedir la reproducción de esas instrucciones se conoce como filtración del mensaje de sistema. Sin embargo, revelar instrucciones y revelar secretos no son lo mismo: el efecto depende de qué información se haya entregado al asistente, de los permisos de la aplicación y de los controles que protejan sus salidas.

El salto más delicado llega cuando la IA usa herramientas. Si puede consultar archivos, enviar mensajes o ejecutar operaciones, una orden escondida en un documento puede intentar que actúe fuera del encargo original. Eso no significa que cualquier texto malicioso consiga borrar un archivo o enviar datos al exterior. Para que ocurra, la aplicación debe permitir esa acción y las barreras restantes tienen que fallar. La capacidad del sistema, no solo la habilidad verbal del atacante, determina el alcance del incidente.

Las instrucciones tampoco tienen por qué llegar como texto visible en una página. Los sistemas que procesan documentos complejos, imágenes y otros formatos amplían las superficies donde pueden aparecer indicaciones destinadas al modelo. Una imagen con texto legible para la máquina o un documento con capas de contenido difíciles de revisar plantean el mismo dilema básico. Cuantos más materiales interpreta un asistente, más ocasiones hay para que encuentre contenido cuya función no sea informar, sino dirigirlo.

Los casos que hicieron visible el problema

En febrero de 2023, pruebas realizadas con el entonces Bing Chat mostraron que era posible inducir al asistente de Microsoft a revelar detalles de sus instrucciones internas. El episodio ayudó a entender una forma directa del ataque: el interlocutor intentaba que el sistema desatendiera límites establecidos por la aplicación. Exponer reglas internas no implica por sí solo acceso a otras conversaciones o a datos privados, pero sí evidenció que la separación entre órdenes podía fallar.

La búsqueda mediante IA abrió otro frente. En diciembre de 2024, una investigación periodística sobre la herramienta de búsqueda de ChatGPT mostró que el contenido de una página podía influir indebidamente en la respuesta generada. En las pruebas, texto oculto en material consultado alteró valoraciones que debían reflejar la información disponible. El interés del caso está en la intervención de un tercero que controla la fuente, no en una petición maliciosa escrita por quien utiliza el buscador.

En 2025 también se comunicaron pruebas de instrucciones escondidas en documentos capaces de influir en funciones de memoria de un asistente. El escenario añade una dimensión temporal: el efecto buscado no siempre aparece durante la lectura inicial, sino que puede manifestarse en una interacción posterior. Las condiciones concretas y los controles de cada producto importan, pero el ejemplo señala el riesgo de conservar como preferencia una orden ajena.

Estos episodios deben leerse con cuidado. Una demostración controlada confirma que una técnica funcionó en determinadas condiciones; no prueba que cualquier instalación de ese servicio sea vulnerable ni que exista una campaña de ataques en curso. Las aplicaciones cambian sus defensas y sus permisos. Lo que permanece es el patrón compartido por los incidentes: un texto de menor confianza intenta determinar qué debe decir, recordar o hacer un sistema de IA.

Por qué no es lo mismo que saltarse un filtro

Una evasión de salvaguardas busca que un modelo produzca algo que normalmente rechazaría. La inyección de instrucciones, en cambio, describe cómo una indicación situada en un lugar de menor confianza intenta imponerse sobre las órdenes legítimas. Ambas técnicas pueden coincidir, pero no son equivalentes. Un asistente que cambia una crítica negativa por una positiva debido a una orden escondida ha sufrido una alteración de su tarea, aunque el resultado no contenga nada que sus filtros de seguridad deban prohibir.

La comparación con las inyecciones clásicas de código ayuda a reconocer la familia del problema: en ambos casos, datos proporcionados por alguien ajeno acaban tratados como instrucciones. La analogía tiene un límite. En una base de datos se pueden separar órdenes y valores mediante mecanismos formales; en un modelo de lenguaje, el significado de una frase depende del contexto y puede adoptar muchas formas. No basta con buscar una secuencia prohibida para identificar todas las tentativas.

Tampoco equivale a contaminar los datos de entrenamiento. Esa manipulación trata de influir en lo que el modelo aprende o incorpora durante su preparación. La inyección descrita aquí ocurre cuando el sistema ya está funcionando y procesa una entrada para responder a una petición. Distinguir ambos momentos evita atribuir cada error extraño de una IA a un ataque. Una respuesta incorrecta puede proceder de muchas causas; para hablar de inyección debe existir una indicación que desvíe indebidamente el comportamiento.

Defensas que reducen el riesgo sin prometer inmunidad

La protección más importante no consiste en pedirle al modelo, con una frase más enérgica, que ignore todas las trampas. Esa advertencia puede ayudar en algunos casos, pero sigue siendo lenguaje que el sistema debe interpretar frente a otro lenguaje. La defensa más sólida se construye alrededor de la aplicación: decidir fuera del modelo qué puede consultar y ejecutar, y mantener separados los contenidos externos de las decisiones que requieren autoridad.

Un asistente encargado de resumir correos, por ejemplo, no necesita necesariamente permiso para enviarlos ni acceso indiscriminado a todos los archivos de una organización. Restringir esas capacidades reduce las consecuencias de una orden maliciosa que consiga influir en su respuesta. El mismo criterio se aplica a las fuentes consultadas: limitar las que puede recuperar y revisar cómo entran en el sistema disminuye la exposición. Menos permisos significan menos daño posible, incluso cuando la detección del ataque falla.

Las operaciones sensibles admiten controles adicionales. Una aplicación puede exigir confirmación humana antes de enviar información, modificar registros o ejecutar acciones difíciles de deshacer. También puede comprobar mediante código a qué destinos se permite transmitir datos y qué información está autorizada a mostrar. La revisión de entradas y salidas, junto con pruebas que introduzcan documentos hostiles de forma deliberada, ayuda a descubrir fallos. Ninguna capa aislada cubre todas las variantes, por lo que su utilidad depende de cómo se combinen.

Filtrar frases sospechosas parece una solución sencilla, pero una orden dañina puede estar reformulada, repartida entre varios fragmentos o integrada en texto útil para la tarea. A la inversa, una cita legítima sobre seguridad puede contener palabras que parezcan una instrucción. Un detector automático sirve como señal para revisar, no como árbitro infalible. También las instrucciones que delimitan el contenido externo pueden mejorar el comportamiento sin convertir esa delimitación en una barrera técnica absoluta.

El Centro Nacional de Ciberseguridad del Reino Unido ha advertido de que no existe una mitigación segura y definitiva para este problema. Esa cautela no equivale a resignación. Significa que la seguridad debe evaluarse sobre la aplicación completa, con sus conexiones, permisos y decisiones, en lugar de atribuirla solo al modelo elegido. La pregunta útil es qué ocurriría si una instrucción maliciosa lograra pasar: qué datos encontraría el asistente y qué podría hacer con ellos.

La confianza será la verdadera medida de un asistente útil

La promesa de los asistentes conectados consiste en ahorrar trabajo leyendo información dispersa y actuando sobre ella. Precisamente esa capacidad los expone a mensajes escritos por terceros que tienen motivos para influir en el resultado. No hace falta atribuir mala intención a cada página o documento para reconocer el riesgo: basta con aceptar que una fuente consultada no debe convertirse en jefa del asistente.

También importa distinguir entre errores visibles y silenciosos. Una respuesta absurda delata enseguida que algo ha fallado; una síntesis razonable que elimina una objeción decisiva puede pasar inadvertida. El peligro no siempre tiene aspecto de intrusión informática. A menudo se parece a un correo bien redactado, una valoración pulida o un informe convincente. La manipulación más eficaz puede conservar la apariencia de normalidad mientras cambia el criterio con el que se presenta la información.

La IA puede seguir siendo útil aunque no interprete perfectamente cada texto que encuentra, siempre que la aplicación no confunda lectura con permiso. Dar acceso acotado, reservar las decisiones delicadas y comprobar la procedencia de lo que alimenta sus respuestas permite contener una debilidad que todavía no tiene solución universal. Al final, la cuestión no es si un asistente sabe leerlo todo, sino si sabe mantener en su sitio a quien escribió cada cosa.