Prompt injection en chatbots web: protección para RAG, herramientas y datos

Un chatbot web no solo procesa preguntas inofensivas. Los visitantes pueden intentar reescribir sus reglas, revelar instrucciones internas o desencadenar acciones no autorizadas. Aún más difíciles de detectar son las órdenes que no están directamente en el chat, sino que se ocultan en una página web rastreada, un documento subido o un sistema de terceros conectado.

Quien desee mitigar la prompt injection en chatbots web no puede confiar únicamente en un prompt de sistema redactado de forma especialmente estricta. Se requiere una arquitectura multicapa: las entradas y fuentes se tratan como no confiables, los permisos se restringen técnicamente, las salidas se verifican antes del procesamiento posterior y las acciones de riesgo se confirman mediante código determinista o un ser humano.

Qué significa la prompt injection en un chatbot web

OWASP describe la prompt injection como una entrada que altera involuntariamente el comportamiento o la salida de un modelo de lenguaje. Una prompt injection directa proviene directamente del usuario, por ejemplo, como una indicación para ignorar reglas anteriores. En cambio, una prompt injection indirecta se esconde en contenidos externos que el sistema consulta más tarde: páginas web, documentos de conocimiento, correos electrónicos, datos de productos o archivos.

Esta distinción es importante para los operadores de sitios web. Un chatbot de FAQ puro tiene una superficie de ataque menor que un sistema que rastrea páginas web continuamente, busca en documentos internos, lee datos del CRM o puede ejecutar funciones. Aunque Retrieval-Augmented Generation (RAG) mejora la base técnica de las respuestas, no elimina el riesgo de injection. Incluso un conjunto de fuentes bien mantenido puede contener instrucciones manipuladas o malinterpretadas.

Evaluar el riesgo según las funciones en lugar del nombre del modelo

La pregunta decisiva no es solo: «¿Qué modelo estamos usando?», sino: «¿Qué impacto puede tener una respuesta manipulada?». Cree un mapa sencillo de funciones y datos para el chatbot:

• ¿Qué fuentes públicas e internas tiene permitido leer?
• ¿A qué datos personales, confidenciales o críticos para el negocio se puede acceder?
• ¿Solo puede generar texto o también crear tickets, clientes potenciales, correos electrónicos, citas o pedidos?
• ¿Qué acciones modifican sistemas externos?
• ¿Qué decisiones se adoptan automáticamente sin que las revise un ser humano?

A medida que aumentan los derechos de lectura, de escritura y el grado de automatización, más importantes son los límites técnicos fuera del modelo. El resumen sobre errores frecuentes en chatbots de IA ayuda en el inventario general. En el caso de la prompt injection, también debe documentar los flujos de datos, los límites de confianza y los derechos de acción.

Separar claramente cuatro zonas de confianza

Un modelo práctico de seguridad distingue cuatro zonas, incluso si técnicamente se procesan en la misma aplicación.

Zona 1: Reglas del sistema y directrices

Aquí se definen el rol, el propósito permitido, los límites de respuesta y las reglas de escalación. Estas reglas orientan al modelo, pero no constituyen un control de acceso fiable. OWASP advierte expresamente en contra de tratar los prompts del sistema como un secreto o mecanismo de seguridad. Las credenciales de acceso, claves de conexión e información interna confidencial no deben incluirse aquí.

Zona 2: Entradas de los visitantes

Cada mensaje del chat se considera no confiable. Limite la longitud, los tipos de archivos y las funciones permitidas; normalice las entradas para el procesamiento técnico y márquelas claramente en el prompt como datos del usuario. Un filtro puede detectar patrones de ataque conocidos, pero no debe bloquear preguntas legítimas de forma generalizada. Un visitante que consulte en una documentación de seguridad sobre «ignore previous instructions» podría tener una consulta válida.

Zona 3: Fuentes recuperadas y contexto RAG

Incluso el contenido rastreado, los PDF y los resultados de servicios externos siguen siendo datos, no instrucciones. Separe su contenido de forma visible del contexto de control, almacene el origen y la hora de consulta y admita únicamente fuentes aprobadas. La publicación sobre la actualización de la base de conocimiento de chatbots de IA muestra cómo interactúan el inventario de fuentes, la frecuencia de rastreo y el control de calidad.

Zona 4: Herramientas, acciones y salidas

Las llamadas a funciones no deben ejecutarse solo porque el modelo genere texto adecuado. Un controlador determinista verifica el nombre de la función, los parámetros, la autorización, el contexto de la sesión y los sistemas de destino permitidos. Las salidas del modelo que se utilicen posteriormente como HTML, Markdown, SQL, rutas de archivo o parámetros de API requieren la validación y codificación adecuadas para ese contexto.

El privilegio mínimo limita el impacto

En el estado actual de la técnica, la prompt injection no se puede eliminar de forma totalmente fiable con una sola medida. Por ello, la aplicación debe diseñarse para que un intento de manipulación exitoso cause el menor impacto posible. OWASP y Microsoft recomiendan para ello el principio del menor privilegio.

• Utilice identidades técnicas separadas para lectura y escritura.
• Conceda acceso únicamente a los datos necesarios para el propósito concreto del chatbot.
• Limite las funciones a esquemas de parámetros reducidos y claramente definidos.
• Utilice permisos de corta duración si una acción los requiere.
• Exija una confirmación explícita para pasos de riesgo o irreversibles.
• Nunca deje la autorización en manos del texto libre del modelo.

Un chatbot de soporte, por ejemplo, puede preparar un borrador de ticket, pero no debería determinar automáticamente destinatarios, prioridades o derechos de acceso internos arbitrarios. Un chatbot de captación de leads puede recibir datos de contacto estructurados sin obtener por ello derechos de lectura sobre todo el CRM.

Verificar e aislar las fuentes RAG

La prompt injection indirecta convierte el pipeline de fuentes en parte de la arquitectura de seguridad. Una página manipulada puede parecer inofensiva visualmente y, aun así, contener texto que el modelo interprete como una instrucción. En sistemas multimodales, las imágenes u otros formatos de archivo también pueden desempeñar un papel.

Por ello, establezca un proceso de entrada de fuentes con reglas de aprobación: dominios y áreas de documentos permitidos, propietarios identificables, control de versiones, análisis de malware y archivos, así como una revisión para contenidos nuevos o modificados de forma inusual. Marque explícitamente los fragmentos recuperados dentro del contexto del modelo como untrusted content. Un resultado de búsqueda puede aportar información, pero no cambiar reglas del sistema ni permisos de herramientas.

Compruebe además si la respuesta está realmente respaldada por las fuentes. La guía sobre la calidad de respuesta en chatbots de IA con Golden Set y pruebas RAG describe la fundamentación (groundedness) y la verificación de fuentes. Esta revisión de calidad complementa los controles de seguridad, pero no los sustituye.

Los filtros de entrada y salida son una capa, no la solución completa

Los servicios de protección especializados pueden detectar intentos de ataque directos e indirectos. Microsoft Prompt Shields, por ejemplo, distingue los ataques en las entradas de usuario de las instrucciones ocultas en documentos. Google también recomienda en su guía de seguridad medidas de protección contra la prompt injection, tareas delimitadas de forma más estricta, identificadores de usuario, límites de cantidad y supervisión humana en casos de mayor riesgo.

Dichos filtros proporcionan señales probabilísticas. Por lo tanto, planifique un comportamiento graduado: bloquear, responder de forma segura, cambiar a un modo estrictamente limitado o transferir a una persona. Registre la clase de decisión y la versión técnica, pero evite el almacenamiento innecesario de texto completo. En el caso de datos personales, también se aplican las áreas de verificación descritas en el artículo sobre chatbots de IA y el RGPD. Este artículo no constituye asesoramiento legal.

Validar las salidas del modelo antes del procesamiento posterior

Una entrada segura no garantiza una salida segura. OWASP lista el tratamiento inadecuado de salidas como un riesgo independiente: el texto del modelo puede terminar en HTML, scripts, consultas de bases de datos o rutas de archivos. Por lo tanto, trate también cada salida del modelo inicialmente como no confiable.

Solicite un formato estructurado estricto para los procesos automatizados y valídelo contra un esquema. Utilice listas blancas para nombres de funciones y sistemas de destino. Codifique el texto visible para el contexto de salida correspondiente. Descarte campos no esperados, URL externas y parámetros fuera de los valores permitidos. Los datos confidenciales deben pasar por una revisión de directrices propia antes de su visualización o transmisión.

Probar la prompt injection con un conjunto de pruebas de seguridad

Complemente el Golden Set técnico con casos de prueba adversarios. Las pruebas deben evaluar el sistema de producción real, incluyendo la recuperación, las herramientas y la lógica de permisos, no solo el modelo base. Un conjunto útil incluye:

• intentos directos de reemplazar reglas o consultar instrucciones internas;
• variantes multilingües, codificadas y distribuidas en varios mensajes;
• preguntas técnicas inofensivas que contengan palabras clave similares y no deban ser bloqueadas por error;
• fragmentos manipulados en una fuente de conocimiento de prueba;
• nombres de funciones no autorizados, parámetros adicionales y direcciones de destino ajenas;
• intentos de emitir datos confidenciales o contenidos de sesiones anteriores;
• pruebas para salidas en HTML, Markdown y enlaces;
• rutas de cancelación, transferencia (handoff) y confirmación en acciones de riesgo.

Mida no solo si salta un filtro. Evalúe el resultado final: ¿se evitó una acción no autorizada? ¿Permanecieron protegidos los datos confidenciales? ¿Siguió funcionando una consulta legítima? ¿Se registró de forma comprensible un caso sospechoso?

Plan práctico de implementación para equipos web

1. Definir el alcance: documentar fuentes de datos, herramientas, permisos de escritura y destinos externos.
2. Separar zonas de confianza: etiquetar técnicamente reglas del sistema, entradas de usuario, contenidos RAG y salidas de acción.
3. Reducir permisos: eliminar accesos no utilizados y descomponer las acciones de escritura en funciones pequeñas.
4. Añadir validación: introducir límites de entrada, salidas estructuradas, listas blancas y codificación específica del contexto.
5. Establecer confirmaciones: asegurar las acciones de riesgo y los flujos de datos confidenciales con supervisión humana (Human-in-the-Loop).
6. Ejecutar el conjunto de pruebas: verificar casos de control directos, indirectos y legítimos antes de cada lanzamiento relevante.
7. Supervisar la operación: revisar periódicamente los eventos de filtro, las acciones denegadas, los cambios inusuales en las fuentes y los falsos positivos.

Lista de verificación: Protección contra prompt injection

• El prompt del sistema no contiene secretos ni sustituye la autorización.
• Los textos de usuario y las fuentes externas se consideran no confiables por defecto.
• Las fuentes RAG cuentan con aprobación, origen, versión y propietarios responsables.
• Las herramientas siguen el principio del menor privilegio y solo aceptan parámetros validados.
• Las acciones de riesgo requieren una confirmación trazable.
• Las salidas del modelo se verifican antes de pasar a HTML, API, CRM u otros sistemas de destino.
• Los filtros de seguridad se evalúan según sus falsos positivos y falsos negativos.
• Las pruebas de ataque directas e indirectas se ejecutan periódicamente y tras realizar cambios.

Conclusión

La prompt injection no es un problema exclusivo de prompt engineering. Para los chatbots web, una protección sólida solo se logra si la aplicación trata las entradas, fuentes, salidas y acciones como zonas de confianza separadas. Los filtros pueden detectar ataques, pero el privilegio mínimo, la validación determinista y la confirmación humana son los que limitan su posible impacto.

Comience con el mapa de funciones y datos de su chatbot. Elimine permisos innecesarios, aísle los contenidos RAG y pruebe todo el recorrido hasta la acción externa. De este modo, el chatbot seguirá siendo útil sin que el texto libre del modelo decida sobre autorizaciones o cambios críticos para el negocio.

Fuentes

• OWASP GenAI Security Project: LLM01:2025 Prompt Injection
• OWASP GenAI Security Project: LLM07:2025 System Prompt Leakage
• OWASP GenAI Security Project: LLM05:2025 Improper Output Handling
• NIST: Generative Artificial Intelligence Profile (NIST AI 600-1)
• Microsoft Learn: Defend against indirect prompt injection attacks
• Microsoft Learn: Prompt Shields in Azure AI Content Safety
• Google AI for Developers: Safety and factuality guidance