Respuesta directa
En pocas palabras
Para proteger un sistema RAG, autoriza cada consulta antes de buscar similitud y limita el universo de recuperación por tenant, usuario, finalidad, clasificación y vigencia. Valida y firma las fuentes antes de indexarlas, conserva procedencia desde el documento hasta cada chunk, trata embeddings y metadatos como datos sensibles y vuelve a comprobar permisos antes de entregar contexto al modelo. Prueba cruces entre tenants, documentos envenenados, contenido oculto, permisos revocados, borrado y reindexación. La búsqueda vectorial ordena cercanía semántica; no sustituye autenticación, autorización ni control de integridad.
La similitud semántica no concede acceso
Un sistema RAG recupera información de una base de conocimiento y la incorpora al contexto que recibe el modelo. OWASP LLM08:2025 advierte que fallos en la generación, almacenamiento o recuperación de vectores y embeddings pueden facilitar exposición de datos, cruces de contexto, inversión de embeddings y envenenamiento de fuentes. El riesgo no termina en la base vectorial: atraviesa ingestión, parsing, chunks, metadatos, cachés, prompt, respuesta, trazas y eliminación.
La distancia entre dos vectores responde qué fragmentos parecen relacionados con una consulta. No responde si la persona puede leerlos, si pertenecen a su organización, si siguen vigentes ni si la fuente es confiable. La autorización debe reducir primero el conjunto elegible. Después se calcula similitud dentro de ese conjunto. Antes de entregar el resultado, el servicio vuelve a validar identidad, tenant, recurso y versión de la política.
Inventa el recorrido completo del conocimiento
Registra fuentes, conectores, parser, OCR, reglas de chunking, modelo de embeddings, dimensiones, colección, namespace, índices, metadatos, filtros, reranker, caché, modelo generativo y consumidores. Para cada elemento documenta owner, versión, tenant, finalidad, clasificación, región, retención, proveedor y estado. Incluye jobs de sincronización, reindexación, restauración y borrado; suelen tener más privilegios que una consulta normal.
Mantén un identificador estable que una documento, versión, chunk, embedding y respuesta citada. Un hash confirma qué bytes se procesaron; no demuestra que el contenido sea verdadero o autorizado. La procedencia debe conservar quién incorporó la fuente, desde qué sistema, bajo qué permiso, cuándo cambió y qué índice la contiene. Sin esa cadena no puedes retirar una versión ni explicar por qué apareció un fragmento.
Clasifica y minimiza antes de crear embeddings
No indexar texto completo por defecto. Define qué campos necesita cada caso de uso y excluye contraseñas, tokens, datos de autenticación, notas restringidas, adjuntos no aprobados y campos sin finalidad. Seudonimizar un identificador puede reducir exposición directa, pero un fragmento conserva relaciones, nombres indirectos y contexto capaz de volver identificable a una persona o empresa. Un embedding tampoco convierte información sensible en anónima.
Aplica reglas antes del parser y después de extraer texto. Algunos formatos incluyen comentarios, revisiones, capas ocultas, metadatos, texto blanco, objetos incrustados o contenido OCR que no era visible en la vista principal. Conserva el nivel de clasificación en cada chunk y deriva la política del documento original. Si un fragmento pierde tenant o permiso durante una transformación, no debe llegar al índice.
| Criterio | Control verificable | Atajo peligroso |
|---|---|---|
| Acceso | Filtro autorizado antes del top-k | Pedir al modelo que ignore otros tenants |
| Privacidad | Minimizar y clasificar antes de indexar | Suponer que el vector es anónimo |
| Integridad | Fuente validada, versionada y trazable | Confiar porque el archivo está en el índice |
| Borrado | Documento, chunks, vectores, cachés y derivados | Eliminar solo el archivo original |
Controla quién puede incorporar conocimiento
Separa carga, aprobación y publicación. Un usuario que puede adjuntar un archivo a una oportunidad no obtiene por ello permiso para convertirlo en conocimiento global. El conector autentica origen y servicio, valida tipo, tamaño, firma o checksum, escanea contenido, asigna tenant y clasificación y envía la versión a revisión cuando corresponda. Las fuentes externas necesitan allowlist, límites de profundidad y evidencia de términos de uso.
Usa una zona de cuarentena antes del índice productivo. Ejecuta parsing seguro, detección de secretos, malware y contenido oculto; revisa cambios de volumen, idioma, dominio y distribución semántica. Compara el nuevo corpus con una línea base. La promoción debe registrar versión, aprobador, resultado de pruebas y rollback. Un job automático no debe publicar silenciosamente documentos cuya procedencia o permiso cambió.
Aísla tenants, colecciones y clases de usuario
OWASP describe el cruce de contexto cuando grupos o aplicaciones comparten una base vectorial sin separación efectiva. La opción más clara es una colección o namespace por tenant y finalidad, con credenciales y políticas separadas. Si existe infraestructura compartida, el tenant efectivo se deriva de la sesión autenticada, nunca de un parámetro libre del usuario o del modelo. La consulta siempre incluye esa frontera en el servicio de acceso.
Prueba aislamiento horizontal y vertical: otro usuario de la misma empresa, otra empresa, soporte, administrador, servicio de ingestión y proceso de evaluación. Incluye IDs manipulados, filtros omitidos, búsquedas vacías, top-k alto, consultas multilingües, cachés y exportaciones. MITRE CWE-639 recuerda que un identificador controlado por el usuario no puede sustituir la comprobación de privilegios sobre el registro solicitado.
Aplica autorización previa y vuelve a comprobar al entregar
Construye un conjunto autorizado con identidad, rol, tenant, relación con el recurso, finalidad, clasificación, vigencia y estado contractual. El vector store recibe un filtro cerrado generado por el backend, no una expresión producida por el modelo. NIST SP 800-207A sitúa la política en identidades de usuario, aplicación y servicio; la ubicación de red o pertenencia a un índice no concede confianza implícita.
Después del retrieval, verifica cada resultado contra el recurso fuente o un snapshot de permisos consistente. Esto cubre cambios entre indexación y consulta: una carpeta compartida puede volverse privada, una persona puede salir del equipo o un contrato puede expirar. Si el servicio de autorización no responde, falla cerrado para contenido restringido. No rellenes el contexto con resultados de un namespace menos protegido para evitar una respuesta vacía.
Detecta envenenamiento y cambios de procedencia
NIST AI 100-2 incluye poisoning entre las familias de ataque a sistemas generativos. En RAG, una fuente manipulada puede posicionarse cerca de consultas objetivo, introducir instrucciones, alterar datos comerciales o desacreditar documentos legítimos. El atacante puede ser externo, proveedor, integración comprometida o persona interna con permiso de escritura. También existe poisoning accidental por sincronizaciones rotas, duplicados y fuentes obsoletas.
Define fuentes permitidas y confianza por versión. Firma o verifica artefactos cuando sea viable, conserva checksum y lineage y compara cambios inesperados. Limita cuántos documentos puede publicar cada identidad, aplica revisión reforzada a contenido de alto impacto y separa hechos de instrucciones. Los documentos recuperados son datos no confiables: nunca heredan autoridad para cambiar política, llamar herramientas o ampliar permisos.
Prueba parsing, chunking y contenido indirecto
La misma fuente puede producir chunks distintos según parser, OCR, encabezados, tablas y tamaño de ventana. Un corte puede separar advertencia y cifra, mezclar dos tenants o perder la referencia que explica una excepción. Evalúa documentos reales y adversarios: texto oculto, comentarios, enlaces, macros, tablas extensas, imágenes, caracteres de control, codificaciones y contenido repetido diseñado para dominar el ranking.
Conserva suficiente contexto para interpretar sin copiar todo el documento. Cada chunk necesita source ID, versión, posición, clasificación, tenant, permisos y fecha. Evalúa precisión y seguridad juntas: aumentar overlap o top-k puede mejorar recall y al mismo tiempo ampliar exposición. Los límites se fijan por caso de uso y riesgo, no por una métrica de retrieval aislada.
Versiona índices, embeddings y políticas como una unidad
Cambiar modelo de embeddings, dimensiones, normalización, chunking, reranker o filtros altera qué se recupera. Crea una versión de colección que relacione todos esos elementos con corpus, permisos y evaluación. Construye el nuevo índice fuera de línea, ejecuta pruebas y promuévelo mediante alias o configuración auditable. Conserva rollback sin reactivar documentos revocados o políticas antiguas.
Evita actualizaciones parciales donde nuevos chunks conviven con metadatos incompletos. Usa estados explícitos: ingesting, quarantined, approved, active, superseded y deleted. Una reindexación debe ser idempotente y reconciliar conteos, hashes y permisos. Después de un cambio, comprueba que las consultas anteriores siguen respetando tenant y que los canarios prohibidos continúan sin aparecer.
Trata embeddings y metadatos como datos gobernados
OWASP incluye ataques de inversión de embeddings: dependiendo del modelo, datos y acceso, un adversario puede inferir o reconstruir información del material fuente. No publiques vectores ni endpoints de similitud sin necesidad. Cifra tránsito y almacenamiento, restringe exportación, separa credenciales, limita consultas y registra patrones de extracción. Protege también metadatos, que suelen revelar nombres, rutas, tenants y clasificación de forma directa.
El riesgo no se elimina con una afirmación universal de irreversibilidad. Evalúa qué puede aprender alguien con acceso a vectores, modelo de embeddings, consultas repetidas y corpus auxiliar. Reduce precisión innecesaria, superficie de consulta y tiempo de retención según el caso, sin prometer anonimización. Si el material fuente debe eliminarse, localiza y borra embeddings, snapshots, réplicas, cachés, evaluaciones y exportaciones derivados.
Entrega contexto con citas, vigencia y conflictos visibles
El modelo debe recibir fragmentos con fuente, versión, fecha, clasificación y límites claros. Separa contenido recuperado de instrucciones del sistema y tool schemas. Si dos fuentes autorizadas discrepan, no ocultes el conflicto mediante una respuesta fluida: muestra qué documento sostiene cada dato y pide revisión cuando el efecto sea material. Una cita demuestra de dónde salió el texto, no que el texto sea verdadero.
Valida la salida antes de mostrarla, guardarla o usarla. Comprueba que cada afirmación sensible tenga respaldo recuperado, que la cita pertenezca a la audiencia y que no se mezclen datos de distintos tenants. Si no hay evidencia suficiente, responde con incertidumbre o crea un pendiente. No guardes automáticamente una inferencia del modelo como hecho verificado del CRM.
Prueba denegaciones, poisoning y ciclo de vida
Crea datasets de seguridad independientes del benchmark de calidad. Incluye canarios únicos por tenant y clasificación, usuarios con permisos distintos, documentos retirados, fuentes contradictorias, queries multilingües, paraphrase, top-k extremos y filtros ausentes. Intenta insertar texto que ordena ignorar políticas, llamar herramientas o revelar contexto. La prueba pasa cuando el documento no autorizado queda fuera del conjunto recuperable y no aparece en respuesta, cita, caché o traza.
Prueba también revocación y borrado. Cambia un permiso después de indexar, elimina una fuente, restaura un backup y reejecuta la consulta. Mide tiempo hasta que el cambio se refleja en todas las réplicas. Verifica que reindexar no resucite contenido y que rollback preserve la lista de revocaciones. Ejecuta estas pruebas al cambiar corpus, parser, embedding, filtro, proveedor, política o modelo generativo.
Monitorea la cadena y responde sobre el corpus
Registra identidad, tenant, versión de política, colección, filtros aplicados, IDs recuperados, puntuaciones, citas y resultado, con contenido redactado por defecto. Vigila cambios de volumen, fuentes nuevas, fallos de autorización, canarios recuperados, distribución de similitud, documentos dominantes y consultas repetitivas de extracción. Separa métricas de calidad, seguridad y costo para que una mejora de recall no oculte exposición.
Ante una fuga o poisoning, pausa ingestión y retrieval afectados, preserva hashes y versiones, delimita tenants y respuestas, revoca fuentes y credenciales y elimina caches. Corrige permisos o pipeline, reconstruye el índice desde fuentes conocidas y vuelve a probar antes de reabrir. Cambiar el prompt no limpia un corpus comprometido. Si hay datos personales, contratos o terceros, activa las rutas internas aplicables y conserva una cronología verificable.
Mantén estas fronteras en Cerravi y durante todo el ciclo de vida
La seguridad de RAG combina integridad, confidencialidad y autorización. OWASP aporta el mapa específico de vectores y embeddings; NIST AI 100-2 ayuda a clasificar poisoning y ataques de privacidad; NIST SP 800-207A orienta políticas basadas en identidades de aplicación y servicio; CWE-639 ayuda a detectar accesos horizontales mediante claves manipulables. Ninguna referencia certifica por sí sola una implementación: la evidencia está en las pruebas y el estado observado.
En Cerravi, Copilot organiza contexto y propone siguientes pasos para revisión humana. Los recorridos públicos no envían mensajes ni cambian etapas automáticamente. Las propuestas usan productos y precios conocidos; un importe faltante se marca para revisión y no se inventa. Las monedas permanecen separadas salvo conversión aprobada. Buyer Room aporta señales, no confirma identidad, aceptación, firma, pago ni intención. Forecast usa reglas transparentes del CRM y no garantiza cierres. Cualquier recuperación futura debe respetar tenant, permisos, procedencia y estas mismas fronteras.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿Un vector store separa automáticamente los datos de cada cliente?
No. La separación depende de la arquitectura, credenciales, namespaces y filtros aplicados por el backend. El tenant debe derivarse de la sesión autenticada y limitar el conjunto antes de calcular similitud.
¿Los embeddings son anónimos porque no contienen texto legible?
No debe asumirse. Pueden conservar relaciones y permitir inferencias o reconstrucción según el modelo, el acceso y los datos auxiliares. Trátalos como derivados gobernados del material fuente.
¿Cómo se evita el data poisoning en una base RAG?
Controla quién ingresa fuentes, valida origen y contenido, usa cuarentena, conserva hashes y procedencia, compara cambios y exige aprobación antes de promover una versión al índice productivo.
¿Basta con filtrar los resultados después de la búsqueda vectorial?
No. Un documento no autorizado ya pudo influir en ranking, caché, trazas o contexto. La política debe limitar el universo antes del top-k y volver a comprobar cada resultado al entregarlo.
¿Qué debe probarse antes de publicar un sistema RAG multi-tenant?
Cruces entre tenants y roles, permisos revocados, fuentes envenenadas, contenido oculto, consultas multilingües, cachés, reindexación, rollback, borrado y ausencia de canarios prohibidos en respuestas y trazas.