RAG no es magia: la bomba de seguridad y compliance que nadie te contó

El cuñado que enchufó sus PDFs y se creyó el más listo

El Cuñado dice: "Tío, ya tengo IA en mi empresa. Subí todos los contratos a un RAG, le pregunto lo que quiero y me lo encuentra en segundos. Esto es el futuro."

La realidad es: Has construido un sistema que puede alucinar en el retrieval, que abre vectores de ataque que tu firewall ni conoce, que probablemente incumple el GDPR si tienes datos personales en esos PDFs, y que corre sobre GPUs con una vulnerabilidad de Rowhammer documentada en 2025 por la Universidad de Toronto.

Por qué importa saberlo: Porque cuando esto explota (y explota) no te va a doler el proyecto. Te va a doler la multa, el auditor y el titular de prensa.

Qué es RAG de verdad, sin el barniz de marketing

RAG son las siglas de Retrieval-Augmented Generation. La idea es simple: en vez de pedirle a un LLM que recuerde cosas de su entrenamiento (que puede ser de hace meses y que puede inventarse), le das acceso a una base de documentos propia. El modelo busca los fragmentos relevantes y los usa como contexto para responder.

El pipeline básico tiene tres fases:

Ingesta: troceas tus documentos en fragmentos (chunks) de entre 256 y 512 tokens, los conviertes en vectores matemáticos (embeddings) y los guardas en una base de datos vectorial como pgvector o Pinecone.
Retrieval: cuando llega una pregunta, la conviertes también en embedding y buscas los fragmentos más parecidos usando algoritmos como HNSW (Hierarchical Navigable Small World). Es una búsqueda por similitud semántica, no por palabras exactas.
Generation: los fragmentos recuperados se meten al LLM junto con la pregunta, y el modelo genera la respuesta.

Hasta aquí suena razonable. El problema es que cada una de esas tres fases tiene sus propios vectores de ataque y sus propios requisitos de cumplimiento. Y la mayoría de implementaciones ignoran ambos.

El problema de seguridad que tu arquitecto no mencionó

Inyección indirecta de prompts

El ataque más conocido y menos mitigado. El escenario: alguien consigue meter un documento en tu base de conocimiento (o en una fuente externa que tu RAG indexa) con instrucciones ocultas para el LLM. Cuando el sistema recupera ese fragmento y lo mete en el contexto, el modelo obedece las instrucciones del atacante, no las tuyas.

No necesitas acceso al sistema. Solo necesitas que tu RAG indexe contenido que controles, aunque sea parcialmente. Un PDF enviado por email, una página web indexada, un ticket de soporte. El vector de entrada es enorme.

Envenenamiento de la base vectorial

Los embeddings no son texto legible. Son vectores de números flotantes en un espacio de alta dimensión. Eso tiene una consecuencia práctica: si alguien consigue modificar los vectores almacenados (o inyectar fragmentos diseñados para aparecer siempre en los resultados de búsqueda) puede controlar qué información recibe el LLM sin que nadie lo vea venir.

La defensa obvia es controlar quién escribe en tu base vectorial. La realidad es que en muchas implementaciones el pipeline de ingesta tiene permisos demasiado amplios y no hay auditoría de qué entra.

EchoLeak y la filtración por contexto

EchoLeak es una clase de ataque donde el contexto recuperado por el RAG incluye información de otras sesiones o usuarios. Si tu sistema no aísla correctamente los embeddings por usuario o por sesión, un atacante puede formular preguntas que hagan que el retrieval devuelva fragmentos que pertenecen al contexto de otro usuario.

No es un ataque teórico. Es una consecuencia directa de implementar RAG multiusuario sin separación de namespaces en la base vectorial.

GPUBreach: cuando el hardware también falla

Aquí viene la parte que menos se discute en las charlas de RAG.

Investigadores de la Universidad de Toronto demostraron en 2025 un ataque llamado GPUBreach: un Rowhammer aplicado a memoria GDDR6 de GPUs Nvidia. El ataque corrompe tablas de páginas y consigue acceso root. No requiere acceso físico al hardware, pero sí ejecución de código en la GPU objetivo.

"Los investigadores lograron previamente con GPUHammer degradar la precisión de modelos de redes neuronales profundas mediante bit flips en GPUs."

Eso significa dos cosas concretas para sistemas RAG:

Primera: en entornos cloud compartidos (que es donde corre la mayoría de RAG en producción), si un atacante consigue ejecutar código en la misma GPU física que tu sistema, el aislamiento puede romperse. GPUBreach fue reportado a Nvidia en noviembre de 2025 y notificado a Microsoft, AWS y Google. Google pagó una recompensa de 600 dólares por el hallazgo, lo que da una idea de cómo de en serio se tomó inicialmente.

Segunda: la mitigación estándar es memoria ECC (Error-Correcting Code), que puede corregir flips de un solo bit. Pero si el ataque induce más de dos flips, la ECC no es suficiente y puede producirse corrupción silenciosa. No es una protección completa.

Importante matizar: GPUBreach requiere ejecución de código en la GPU, no es un ataque remoto arbitrario. Y a fecha de este artículo, no hay evidencia pública de que haya sido explotado fuera de laboratorio. Pero el vector existe, está documentado, y las GPUs de inferencia en cloud son exactamente el tipo de entorno compartido que el ataque necesita.

El infierno de compliance que nadie dibuja en la pizarra

El problema del derecho al olvido con embeddings

El GDPR tiene un artículo que todo el mundo conoce pero pocos implementan bien: el derecho de supresión. Un usuario te pide que borres sus datos. En una base de datos relacional, ejecutas un DELETE. Problema resuelto.

En un sistema RAG, ese dato está troceado en chunks de 256-512 tokens, convertido en vectores flotantes, y almacenado en una base vectorial. El documento original puede estar en S3 o en otro almacén. Las referencias cruzadas pueden estar en metadatos. Y el propio embedding, aunque no sea texto legible, puede considerarse dato personal derivado si permite reidentificación.

¿Cómo borras eso de forma auditable? No hay un botón. Necesitas un pipeline de borrado que rastree cada chunk de cada documento por origen, que actualice la base vectorial, que invalide caché si la tienes, y que genere un registro de auditoría que demuestre que el borrado fue completo.

La mayoría de implementaciones RAG no tienen nada de esto. Y la base de datos CMS GDPR Enforcement Tracker registró hasta febrero de 2026 un total de 2.394 multas por valor de aproximadamente 5.650 millones de euros. El regulador no está mirando para otro lado.

Los números que hacen que el compliance deje de ser una conversación de RR.HH.

El Ponemon Institute lleva años midiendo el coste del cumplimiento frente al incumplimiento. Los datos más recientes disponibles son de 2017 (estudio conjunto con Globalscape): el coste promedio de cumplimiento era de 5,47 millones de dólares anuales. El de incumplimiento: 14,82 millones. Una ratio de 2,71 veces.

En 2011, la ratio era de 2,65 veces con un coste de cumplimiento de 3,5 millones. La tendencia es consistente: cumplir cuesta, pero incumplir cuesta casi tres veces más.

Estos son datos históricos y genéricos, no específicos de sistemas de IA o RAG. Pero la lógica es la misma: el coste de poner las cosas bien desde el principio es sistemáticamente menor que el coste de arreglarlo después de una multa, una brecha o una auditoría fallida.

Y en 2017, solo el 14,3% de los presupuestos de TI se destinaba a cumplimiento. Un leve aumento desde el 11,8% de 2011. Infrainversión crónica con datos.

El caso de TD Bank es ilustrativo aunque no tenga relación directa con IA: recibió una multa de 3.000 millones de dólares de las autoridades estadounidenses por fallos sistémicos en su programa anti-lavado de dinero. Fitch revisó su perspectiva a negativa en mayo de 2024. Los fallos sistémicos en compliance no son un problema de tecnología; son un problema de prioridades. Y las consecuencias son proporcionales al descuido.

El Cyber Resilience Act: el reloj que ya está corriendo

La Unión Europea aprobó el Reglamento de Ciberresiliencia (CRA). Las fechas que importan:

11 de septiembre de 2026: los productos digitales deben tener procesos de reporte de vulnerabilidades e incidentes. Eso incluye notificación en 24 horas de vulnerabilidades explotadas activamente y reporte completo en 72 horas.
Diciembre de 2027: aplicación plena. El CRA amplía el marcado CE a software, firmware, servicios backend y dispositivos en red. Obliga a diseño seguro por defecto, actualizaciones durante al menos cinco años, y una declaración de conformidad que debe conservarse diez años.

¿Aplica a tu sistema RAG? Depende de si lo comercializas como producto digital en la UE. No es automático, y la categorización de sistemas RAG dentro del CRA (si entran como "productos importantes" con mayor escrutinio) no está explicitada en el reglamento. Pero si vendes un producto con componentes de IA en Europa, la pregunta no es si te afecta sino cuánto.

Y el estado del arte en la industria no es tranquilizador: una encuesta de Cloudsmith reveló que solo el 25% de las organizaciones genera SBOMs (Software Bill of Materials) de forma automática. Más de la mitad necesitaría un esfuerzo significativo para un reporte completo de su cadena de suministro de software. Menos de un tercio confía en superar una auditoría de cadena de suministro.

El CRA no exige que los SBOMs sean públicos, pero sí que estén disponibles para las autoridades de vigilancia del mercado. Si no tienes ni idea de qué librerías de terceros corren en tu pipeline de embeddings, tienes un problema que llegará antes de lo que crees.

Lo que un RAG seguro y compliant necesita, sin romanticismos

No existe el RAG "seguro por defecto". La arquitectura base no incluye ninguna de estas cosas. Tienes que construirlas:

En seguridad:

Validación y sanitización de todo el contenido antes de la ingesta. No indexas lo que no controlas.
Separación de namespaces por usuario o tenant en la base vectorial. EchoLeak no es un bug; es una consecuencia de no separar.
Auditoría de escritura en la base vectorial. Quién mete qué y cuándo.
Monitorización de outputs para detectar patrones de inyección. No es infalible, pero es lo mínimo.

En compliance:

Trazabilidad chunk-documento-origen desde el primer día. Si no sabes de dónde viene cada vector, no puedes borrar nada de forma auditable.
Pipeline de borrado que cubra almacén de documentos, base vectorial, metadatos y caché.
Clasificación de datos antes de la ingesta. No todo lo que está en un PDF puede entrar en un sistema RAG sin análisis previo.
Si comercializas el sistema en la UE, empieza ahora con el inventario de componentes de software. Septiembre de 2026 está más cerca de lo que parece.

El retrieval que falla y el que te hunde

Hay un dato que circula en la literatura técnica: el retrieval en sistemas RAG falla en torno al 80% de los casos cuando se evalúa con criterios estrictos de relevancia. No es que el LLM alucine; es que el retrieval le da basura y el LLM hace lo que puede con ella.

Eso es un problema de calidad. Pero combinado con los vectores de ataque descritos arriba, se convierte en algo más grave: un sistema que ya de por sí recupera información irrelevante con frecuencia es mucho más difícil de monitorizar. El ruido de fondo oculta el ataque.

Un RAG que funciona bien en retrieval es más seguro, no solo más útil. La calidad técnica y la seguridad no son dimensiones separadas en este contexto.

El remate

RAG es una arquitectura válida y útil. Pero la narrativa de "conecta tus documentos y listo" es exactamente el tipo de simplificación que luego te cuesta tres veces más de lo que costaba hacerlo bien desde el principio.

Los datos están ahí: incumplir cuesta 2,71 veces más que cumplir. Las vulnerabilidades están documentadas. El regulador europeo tiene un calendario publicado.

La pregunta no es si tu RAG tiene estos problemas. La pregunta es cuándo vas a revisarlo.