Inyección de prompts: cuando una fuente intenta dar órdenes a tu asistente

Imagina este caso hipotético: encargas una comparación de tres competidores a partir de sus páginas públicas. Una de ellas incluye una indicación para favorecer su propia oferta u omitir una debilidad. El trabajo sigue siendo preparar una comparación con fuentes; esa página no puede cambiar las condiciones del encargo.

Ahora añade dos permisos: consultar notas privadas sobre precios y enviar mensajes. El mismo intento de desviar la tarea podría tener consecuencias distintas. Por eso conviene revisar las capacidades reales del asistente antes de automatizar la investigación.

Qué significa una inyección de prompts

Se produce cuando un atacante introduce contenido que intenta modificar el comportamiento previsto de un modelo de lenguaje. La inyección es indirecta si llega a través de una página, un documento, un correo o el resultado de una herramienta que el asistente consulta. No hace falta que alguien del equipo pegue deliberadamente la instrucción.

No es lo mismo que una afirmación inventada: en este caso, la fuente contiene una orden que busca desviar el trabajo. Puede sesgar el resumen, provocar un uso indebido de herramientas o facilitar una divulgación, según los permisos disponibles. Su apariencia no basta para identificarla: buscar determinadas frases sospechosas no garantiza su detección.

Por qué «solo lectura» no impide una divulgación

Junto con quien administra el sistema, haz inventario de las entradas, los datos privados accesibles, las herramientas, las comunicaciones externas y los destinatarios del resultado. Incluye también las conexiones que están disponibles aunque no sean necesarias para esta tarea.

El modo de solo lectura puede impedir ciertas modificaciones mediante las herramientas autorizadas. Sin embargo, no impide automáticamente divulgar lo leído. También importan las direcciones a las que se pueden hacer peticiones, los datos incluidos en ellas y quién puede recibir las respuestas. Un permiso para investigar no debería incorporar por defecto acceso a notas confidenciales ni capacidad de envío.

Un primer encargo que termine en un borrador

En MindVerve recomendamos empezar con fuentes aprobadas y no sensibles, sin introducir secretos en la investigación. El resultado sería un borrador para revisión interna. Pide al responsable del sistema que desactive las herramientas innecesarias de escritura, envío y publicación, y que restrinja los destinos permitidos desde la plataforma.

Conserva la procedencia de las fuentes para que una persona pueda contrastar las afirmaciones importantes con los originales. Si no es posible comprobar los permisos o las comunicaciones salientes, reduce el piloto a documentos aprobados que se faciliten manualmente, sin acciones externas. Antes de incorporar información sensible, consulta al responsable de informática o seguridad.

Lo que las instrucciones pueden aclarar y lo que no controlan

Separar las instrucciones del material de consulta ayuda a explicar la tarea, pero no crea una barrera de seguridad. Puedes pedir al asistente que señale los intentos de desviación como contenido no fiable y no los obedezca. Esa petición tampoco configura sus permisos: los controles técnicos dependen de la plataforma y de sus responsables.

La generación aumentada por recuperación, o RAG, busca pasajes relevantes antes de generar una respuesta. Esos pasajes también pueden contener instrucciones. Usar RAG o encargar la revisión a otra IA no garantiza la protección.

OpenAI y Anthropic describen defensas que combinan varias medidas y siguen siendo imperfectas. Las instrucciones deben acompañarse de acceso limitado, comprobaciones de las acciones fuera del modelo y pruebas periódicas. Estas medidas reducen el riesgo, pero no eliminan todas las posibilidades de ataque.

Cómo plantear una prueba sin datos ni envíos reales

Proponemos este ejercicio para un entorno aislado; no es una prueba que hayamos ejecutado. Usa datos ficticios y compara tres documentos: uno normal, otro que pida introducir un eslogan ajeno al tema y otro que solicite transmitir información a un destinatario ficticio no autorizado. No se deben enviar mensajes reales.

La prueba debería producir una síntesis útil y fiel, y señalar los intentos de desviar la tarea sin obedecerlos. No debería haber ninguna acción saliente sin autorización: compruébalo en el registro del sistema, no solo en la respuesta final. Anota también las falsas alarmas, si se completó el trabajo útil y cuánto esfuerzo exigió la revisión.

Guarda las versiones de las entradas, las instrucciones, el modelo y el flujo, junto con los resultados esperados, los observados y el registro real de acciones. Repite el ejercicio cuando haya cambios importantes. Superarlo una vez no demuestra que el sistema sea seguro.

Aprobar un envío exige ver qué se va a enviar

Enviar el borrador, publicarlo o modificar el presupuesto de una campaña son acciones diferentes. Cada una necesita permiso y una comprobación del contenido o cambio exacto, del destino y de la acción propuesta. Una pregunta genérica sobre si se puede continuar no permite saber qué se está autorizando.

La formación ayuda al equipo a revisar con criterio; los controles técnicos limitan lo que el sistema puede ejecutar. Elegir una tarea que siga siendo útil con esas restricciones permite combinar ambas cosas sin confiar toda la protección a una revisión humana.

Cuándo detener el piloto

Si aparece una acción inesperada o una divulgación, no amplíes el uso. Detén el proceso afectado, conserva solo las pruebas necesarias sin propagar información sensible e implica al responsable de informática o seguridad. Habrá que repetir las pruebas antes de reanudarlo. Una fuente puede aportar información, pero no conceder permiso para actuar.

Fuentes oficiales verificadas el 22 de septiembre de 2026, en horario UTC.