Cómo prevenir el envenenamiento de datos en RAG: procedencia de fuentes, cuarentena y pruebas de reindexación

Un chatbot web puede ofrecer una respuesta educada, lingüísticamente convincente y técnicamente bien generada, pero operar sobre una base de conocimiento envenenada. En el envenenamiento de datos RAG no se manipula principalmente la formulación de una consulta individual. En su lugar, contenidos falsos, manipulados o insuficientemente verificados ingresan en la cadena de datos persistente: fuente, analizador sintáctico (parser), fragmento (chunk), metadatos, embedding y, finalmente, el índice de recuperación de producción. De este modo, el error se mantiene a lo largo de muchas sesiones y puede afectar incluso a preguntas normales.

Por lo tanto, una protección eficaz comienza mucho antes del prompt. Los equipos deben ser capaces de responder a lo siguiente para cada bloque de conocimiento: ¿de dónde procede, quién es el responsable, qué versión se procesó, qué transformaciones tuvieron lugar y mediante qué validación se aprobó para la búsqueda? La procedencia de la fuente proporciona este rastro. Una cuarentena técnicamente separada puede evitar que los cambios no verificados pasen a estar disponibles de inmediato. A continuación, las pruebas de reindexación dirigidas comprueban si el contenido corregido ha sustituido realmente a los fragmentos antiguos.

Qué es y qué no es el envenenamiento de datos RAG

La clasificación OWASP LLM04:2025 sobre envenenamiento de datos y modelos describe las manipulaciones en los datos de preentrenamiento, ajuste fino (fine-tuning) o embedding como un riesgo para la integridad. Para un chatbot web, la última variante es especialmente concreta: un documento se ingiere y se divide en secciones; estos fragmentos se embeben y se almacenan como vectores en el índice de recuperación. Si este documento se altera de forma deliberada o accidental, puede aparecer como una base aparentemente relevante ante las preguntas correspondientes.

Es necesario distinguir los riesgos, aunque pueden solaparse: Prompt Injection intenta inyectar instrucciones o datos en tiempo de ejecución para alterar el comportamiento previsto del sistema; la inyección indirecta de prompts también puede ingresar al contexto a través de los documentos recuperados. El envenenamiento de datos, por el contrario, altera el conjunto de conocimientos duradero o sus derivados. Los derechos de acceso también resuelven un problema diferente: determinan qué persona puede ver un documento. La procedencia y la aprobación determinan si este documento debe ingresar al índice como una fuente de conocimiento confiable. En una arquitectura sólida, los tres riesgos requieren sus propios controles y transiciones coordinadas.

La superficie de ataque abarca toda la cadena de datos

Un índice RAG rara vez se crea a partir de una única colección verificada manualmente. Los crawlers leen sitios web, los conectores sincronizan carpetas en la nube, los usuarios suben archivos y las interfaces importan datos de productos. A esto se suman el parsing, OCR, la limpieza de lenguaje, el fragmentado (chunking) y el enriquecimiento de metadatos. Cada etapa puede incorporar contenido incorrecto o descontextualizar una afirmación originalmente correcta.

Causas típicas son un sistema de origen comprometido, un documento espejo vinculado recientemente, un archivo de borrador publicado accidentalmente, un inquilino (tenant) asignado incorrectamente o una actualización del analizador que asigna valores de tablas a encabezados equivocados. La comparación de un hash criptográfico del contenido con un valor de referencia confiable puede detectar desviaciones; un hash coincidente no demuestra la veracidad, la actualidad ni la aprobación del contenido.

La procedencia como un registro de datos auditable

Cada documento y cada fragmento derivado de él debe incluir un registro de datos de procedencia. En la práctica, es útil contar con al menos un ID de fuente estable, la URL de origen canónica, el propietario responsable, la fecha/hora de recuperación, la versión del documento, el hash del contenido, el estado de aprobación, la clase de confianza, la versión del parser, la versión de chunking, el modelo de embedding y la generación del índice. En el caso de las cargas manuales, se añaden el rol de la persona que sube el archivo y la licencia verificada. En los sistemas sincronizados, también es importante saber a través de qué conector autenticado llegó el archivo.

El Perfil de IA Generativa NIST AI 600-1 aborda la procedencia del contenido, la documentación trazable, así como las pruebas y evaluaciones como componentes esenciales de la gestión de riesgos en la IA generativa. Trasladado a los sistemas RAG, esto significa: no solo importa el índice actual. La relación trazable entre la revisión de la fuente, el proceso de ejecución y la generación del índice publicado también forma parte de la documentación operativa.

La cuarentena separa la ingesta de la publicación

Un componente arquitectónico central es la separación estricta: los contenidos nuevos o modificados no pasan a ser buscables directamente. Primero llegan a una zona de ingesta. Allí, el pipeline valida el origen, el tipo de archivo, el tamaño, la firma o el hash esperado, el inquilino permitido, la integridad de los metadatos y el alcance de la modificación. Solo después se generan el texto y los fragmentos en una generación de índice no productiva.

Las reglas deben basarse en el riesgo. Un cambio en una página de preguntas frecuentes interna y autenticada puede aprobarse tras pruebas automáticas. En cambio, un nuevo dominio, una modificación de texto inusualmente extensa, un propietario de archivo desconocido o una fuente sin persona responsable activan la cuarentena y la revisión humana. Si falta una información obligatoria, se aplica el principio "fail closed": la generación anterior confirmada permanece activa; la nueva versión no se publica silenciosamente.

Aprobación como una generación de índice inmutable

Tras la verificación, no se sobrescribe gradualmente un índice productivo. Es preferible una nueva generación versionada con un manifiesto: documentos esperados, fragmentos esperados, hashes de origen, versiones de transformación y marcas de tiempo. Solo cuando las pruebas resultan favorables, un alias o una configuración de enrutamiento conmuta de forma atómica a esta generación. La generación anterior permanece disponible para una reversión (rollback) durante un periodo limitado y definido.

El procedimiento se asemeja a una migración controlada. Nuestro artículo sobre la transición de un modelo de embedding RAG muestra por qué las generaciones de índices paralelas y las pruebas comparativas son útiles también durante los cambios técnicos. En caso de sospecha de envenenamiento, se añade la cuestión de seguridad: ¿qué revisión de la fuente y qué fragmentos derivados deben bloquearse?

Escenario de ejemplo ficticio: un plazo de devolución incorrecto llega al bot de soporte

Supongamos que un comercio opera un chatbot para consultas de productos y servicios. La base de conocimiento sincroniza cada noche el centro de ayuda oficial y algunos portales de fabricantes autorizados. Tras un cambio de enlace, un conector sigue una redirección hacia una página espejo no autorizada. Allí, un PDF de aspecto plausible indica un plazo de devolución de 90 días en lugar de 30. El archivo se divide en fragmentos; varias secciones terminan en el índice con una alta similitud semántica.

A la mañana siguiente, el bot promete el plazo equivocado ante las preguntas de devolución. El modelo de lenguaje no fue reprogramado y los usuarios no introdujeron ninguna instrucción maliciosa. La recuperación simplemente proporcionó una base errónea. La monitorización emite una alarma porque aparece un nuevo dominio por primera vez como fuente de respuesta y una prueba de Golden Set para el plazo de devolución difiere de la evidencia esperada.

Cuarentena y recuperación controladas

1. El equipo detiene únicamente la fuente de ingesta afectada y congela la generación de índice actual frente a nuevos cambios.
2. El ID del documento sospechoso, todos los ID de fragmentos derivados y sus coincidencias de respuesta se registran en el incidente.
3. El dominio espejo se bloquea y sus fragmentos se mueven a cuarentena. Para preguntas sobre el plazo de devolución, el bot ofrece temporalmente un aviso seguro remitiendo al soporte humano o a la página de políticas confirmada.
4. El alias se restablece a la última generación de índice comprobadamente limpia. De este modo, otras áreas de conocimiento no afectadas permanecen disponibles.
5. El conector se limita a la fuente canónica. A continuación, el pipeline construye una nueva generación a partir del manifiesto confirmado.
6. Esta generación pasa a producción únicamente tras las pruebas de reindexación y la aprobación especializada.

Este orden limita los daños sin desactivar prematuramente todo el chatbot. La clave reside en la vinculación entre los datos de origen y sus derivados: sin la asignación de documento a fragmentos, no estaría claro qué vectores deben eliminarse.

Las pruebas de reindexación deben demostrar más que la ejecución exitosa de un pipeline

Un estado de tarea exitoso solo demuestra que el proceso finalizó técnicamente. No prueba que los fragmentos antiguos hayan desaparecido ni que las fuentes correctas prevalezcan ante preguntas reales. Por tanto, un paquete de pruebas sólido evalúa el inventario, la recuperación y el comportamiento de las respuestas.

1. Verificación de manifiesto y borrado

Compare la nueva generación con el manifiesto aprobado. Cada versión de documento esperada debe estar presente; los ID de documentos y fragmentos bloqueados no deben aparecer. Los "tombstones" para contenidos eliminados o reemplazados son especialmente importantes. De lo contrario, limitarse a añadir nuevos embeddings permite que los resultados antiguos envenenados permanezcan en el índice.

2. Pruebas de recuperación con fuentes esperadas

Para preguntas críticas, no basta con un texto de respuesta esperado. Defina además ID de fuentes permitidas y prohibidas, un número mínimo de coincidencias y condiciones de exclusión. Por ejemplo, la política de devoluciones debe proceder del documento canónico; el dominio espejo puesto en cuarentena no debe aparecer en los resultados principales ni en el contexto del modelo. La estructura de estos conjuntos de prueba se explica en el artículo sobre la calidad de las respuestas con Golden Set y pruebas RAG.

3. Pruebas negativas y de manipulación

En un entorno de prueba aislado, los equipos pueden ingresar una fuente de prueba no autorizada y claramente marcada. El pipeline debe mantenerla en cuarentena; la búsqueda de tipo producción no debe recuperarla. Además, se prueban cambios inusuales de dominio, falta de propietarios, diferencias extremas de contenido y fechas contradictorias. El Informe NIST AI 100-2 sobre Aprendizaje Automático Adversarial clasifica el envenenamiento como una categoría de ataque en su taxonomía y subraya que las contramedidas y sus límites deben analizarse sistemáticamente.

4. Comparación antes y después del cambio

Ejecute las mismas preguntas contra la última generación limpia y la nueva. Compare las fuentes de origen, la jerarquía de relevancia, las evidencias de respuesta, la tasa de no respuesta y la evaluación especializada. Una pequeña proporción de despliegue canary puede aportar señales de producción adicionales, siempre que los usuarios no accedan a fuentes no verificadas. El cambio productivo solo se efectúa cuando se cumplen los límites de seguridad y calidad establecidos.

Monitorización: detección temprana de anomalías

Supervise no solo las valoraciones de las respuestas. Los datos significativos incluyen dominios de origen nuevos o poco frecuentes, la proporción de fuentes no verificadas en el flujo de ingesta, tamaños de archivo inusuales, marcadas diferencias de hash o texto, un volumen elevado de fragmentos nuevos de un solo propietario, cambios en las fuentes principales del Golden Set y respuestas sin evidencia confirmada. Las métricas deben hacer referencia a los ID de procedencia, no a preguntas completas de usuarios almacenadas innecesariamente.

La vigencia del contenido también sigue siendo relevante. Una política antigua, reemplazada hace tiempo, no está envenenada intencionadamente, pero puede causar el mismo efecto. El artículo sobre la actualización de bases de conocimiento y control de calidad en crawlers complementa los controles de seguridad abarcando la cadencia, las responsabilidades y las rutas de eliminación.

Lista de cotejo para ingestas RAG seguras

• ¿Cuenta cada fuente con un ID estable, origen canónico, persona responsable y clase de confianza?
• ¿Se registran conjuntamente el hash, la versión del documento, el parser, el chunking y el modelo de embedding?
• ¿Permanecen fuera de la búsqueda productiva las fuentes nuevas o con cambios sustanciales hasta su verificación?
• ¿Los nuevos dominios, las firmas faltantes o los cambios de contenido inverosímiles derivan en una cuarentena?
• ¿Se publican los índices aprobados como generaciones versionadas con alias con posibilidad de rollback?
• ¿La reindexación elimina de forma comprobable los fragmentos reemplazados en lugar de solo añadir nuevos datos?
• ¿Evalúa un Golden Set tanto las respuestas como las fuentes esperadas y prohibidas?
• ¿Existe una alternativa segura (fallback) para los temas cuyas fuentes están bloqueadas durante un incidente?
• ¿Se han definido roles separados para la ingesta, la aprobación especializada, la respuesta a incidentes y la republicación?
• ¿Se documenta tras cada incidente qué control falló y qué prueba de regresión se añadió?

Conclusión

El envenenamiento de datos en RAG no se puede solucionar con una sola regla de prompt. La protección surge de una cadena de suministro de conocimiento auditable: documentar el origen, evaluar las modificaciones en cuarentena, versionar los índices, eliminar de forma segura los derivados antiguos y probar la recuperación con las fuentes esperadas. Comience con las clases de documentos de mayor riesgo y un Golden Set reducido. Esta combinación permite visibilizar qué fuente respalda una respuesta y habilita una vía de reversión dirigida antes de que un estado de conocimiento erróneo se convierta en la norma permanente.

Fuentes

• Proyecto de Seguridad GenAI de OWASP: LLM04:2025 Envenenamiento de Datos y Modelos
• NIST AI 600-1: Marco de Gestión de Riesgos de Inteligencia Artificial – Perfil de Inteligencia Artificial Generativa
• NIST AI 100-2: Aprendizaje Automático Adversarial – Taxonomía y Terminología de Ataques y Mitigaciones