Intro

RAG aparece en casi cualquier conversación seria sobre asistentes con IA. Y suele explicarse de forma demasiado simple: como si fuera apenas una manera elegante de darle más contexto a un modelo antes de responder.

La idea base no está mal, pero queda corta. Un sistema RAG no es solo un LLM con mejor memoria aparente. Es una arquitectura que decide qué información busca, de dónde la trae, con qué permisos la obtiene y cómo se la entrega al modelo.

Ahí es donde ciberseguridad empieza a importar de verdad. Porque en cuanto conectás un modelo con documentación interna, wikis, tickets, runbooks o bases de conocimiento, ya no estás evaluando solo al modelo. Estás evaluando todo el sistema alrededor.

Qué significa realmente RAG

RAG viene de retrieval-augmented generation.

Traducido a algo útil: antes de que el modelo responda, el sistema busca información relevante en una o varias fuentes, recupera fragmentos y los inyecta como contexto para generar la respuesta.

Eso cambia bastante el juego.

En vez de depender solo de lo que el modelo aprendió durante entrenamiento, el sistema puede apoyarse en documentación más actual, específica o interna. Por eso RAG se volvió tan atractivo para asistentes corporativos, buscadores semánticos, copilotos de soporte y herramientas internas.

Cómo funciona un pipeline típico

Aunque cada implementación varía, un flujo RAG suele tener piezas bastante reconocibles:

  • documentos o fuentes de conocimiento;
  • fragmentación del contenido en chunks;
  • embeddings para representar esos fragmentos;
  • una base vectorial o mecanismo de búsqueda;
  • recuperación de pasajes relevantes;
  • armado del prompt final con ese contexto;
  • respuesta generada por el LLM.

La parte importante no es memorizar la lista. La parte importante es entender que hay varias capas donde algo puede salir mal.

Si el chunking es pobre, la recuperación puede traer contexto inútil. Si el índice está contaminado, el modelo va a razonar sobre material contaminado. Si los permisos están mal resueltos, el sistema puede devolver información que el usuario nunca debió ver.

Qué valor aporta de verdad

RAG sí resuelve problemas reales. Y ese punto conviene defenderlo sin humo.

Por ejemplo, puede servir para:

  • responder sobre documentación interna sin reentrenar un modelo;
  • consultar procedimientos, políticas o runbooks;
  • acelerar el trabajo de soporte o de un SOC con material ya existente;
  • usar información más actual que la que el modelo traía de fábrica;
  • reducir parte de las respuestas inventadas cuando la fuente recuperada es buena.

Imaginá un analista que necesita recordar el procedimiento interno para aislar un endpoint o verificar a qué equipo se escala cierto incidente. Un asistente con RAG puede encontrar ese material en segundos y devolver una respuesta bastante más útil que un LLM solo, que probablemente completaría con generalidades.

Lo que no resuelve por sí solo

Acá aparece una de las confusiones más comunes.

RAG no garantiza verdad. No elimina alucinaciones. No corrige permisos mal diseñados. No vuelve seguro a un asistente por el solo hecho de agregarle búsqueda.

Como mucho, cambia la base sobre la que el modelo responde.

Eso significa que un sistema RAG puede seguir fallando por varias razones:

  • recupera contexto equivocado;
  • trae fragmentos incompletos o desactualizados;
  • mezcla documentos de calidad desigual;
  • responde con exceso de confianza a partir de material ambiguo;
  • expone información que no correspondía.

Decir que RAG arregla las alucinaciones es vender una simplificación peligrosa. Lo más correcto es decir que puede reducir parte del problema cuando la recuperación, la calidad documental y el ensamblado del contexto están bien resueltos.

Por qué cambia la discusión de ciberseguridad

Un modelo base responde según su entrenamiento, su prompt y el contexto inmediato que recibe.

Un sistema RAG responde según todo eso, más:

  • qué fuentes puede consultar;
  • qué datos entraron al índice;
  • cómo se segmentan los documentos;
  • qué filtros existen antes del prompt final;
  • qué permisos y controles tiene la capa de retrieval.

O sea, el riesgo ya no vive solo en el modelo. Vive en la arquitectura completa.

Por eso una pregunta útil deja de ser "¿qué sabe el modelo?" y pasa a ser otra:

¿qué puede recuperar, desde dónde, con qué permisos y bajo qué controles?

Riesgo 1: prompt injection vía documentos

Este es uno de los riesgos más discutidos, y con razón.

Si el sistema indexa contenido que incluye instrucciones maliciosas, manipuladoras o simplemente hostiles, el modelo puede tomar ese material como parte del contexto y verse influido por él.

Eso puede pasar si se indexan sin demasiado criterio:

  • wikis abiertas;
  • tickets cargados por muchos usuarios;
  • contenido externo;
  • documentación de terceros;
  • archivos generados automáticamente sin saneo.

El punto clave es que la prompt injection no necesita entrar siempre por la interfaz del chat. También puede entrar por los documentos que el propio sistema decide recuperar.

Riesgo 2: data leakage

Acá suele estar el riesgo más serio para empresas.

Si el sistema no respeta bien permisos o segmentación, una consulta aparentemente inocente puede terminar devolviendo fragmentos sensibles: arquitectura interna, procedimientos delicados, información de clientes, inventarios o secretos mal documentados.

En ese caso el problema no es solo el modelo. El problema es la combinación entre retrieval, controles de acceso y ensamblado del prompt.

Un RAG con acceso demasiado amplio puede convertirse en una interfaz muy cómoda para explorar información interna que antes estaba dispersa y, por eso mismo, era menos trivial de exfiltrar.

Riesgo 3: poisoning del índice

Si alguien logra insertar contenido falso, sesgado o malicioso en las fuentes indexadas, el sistema puede empezar a responder con base en esa contaminación.

Eso no requiere ciencia ficción. Alcanza con que una fuente confiable en apariencia permita contenido incorrecto, desactualizado o manipulado, y que ese material gane peso en la recuperación.

En seguridad esto es especialmente delicado cuando el asistente se usa para:

  • consultar procedimientos;
  • sugerir pasos operativos;
  • resumir documentación interna;
  • asistir decisiones en incidentes.

Si el índice está envenenado, el modelo puede entregar una respuesta prolija, pero operacionalmente mala.

Riesgo 4: contexto irrelevante o mal recuperado

No todos los problemas vienen de un atacante. A veces basta con una mala implementación.

Un sistema que trae contexto irrelevante, ambiguo o incompleto puede empujar al modelo hacia respuestas convincentes, pero equivocadas. Y como la respuesta llega con apariencia de haber consultado la base interna, el usuario tiende a confiar más de la cuenta.

Ese detalle importa mucho. En RAG, una respuesta incorrecta puede volverse más persuasiva justamente porque parece respaldada por documentación real.

Riesgo 5: exceso de permisos

Muchas implementaciones caen en la tentación de indexar todo "para que el asistente sea más útil".

Eso suele terminar mal.

Cuantas más fuentes internas pueda leer el sistema, mayor es el valor potencial que entrega, sí, pero también mayor es la concentración de riesgo. Un asistente con acceso a demasiados repositorios, wikis, tickets, runbooks y documentos sensibles puede convertirse en un punto único de exposición.

En seguridad, la comodidad sin segmentación suele ser deuda disfrazada de productividad.

Dónde sí puede aportar mucho a ciberseguridad

Dicho todo eso, un RAG bien diseñado puede ser muy útil para defensa.

Algunos casos sensatos:

  • asistentes para SOC con runbooks y playbooks;
  • consulta de procedimientos internos durante incidentes;
  • búsqueda rápida sobre arquitectura, responsables o inventario documentado;
  • ayuda para onboarding técnico de equipos con documentación extensa;
  • apoyo a soporte interno cuando la información está repartida en muchas fuentes.

El beneficio real no es que el modelo "se vuelva experto". El beneficio real es que reduce fricción para encontrar y usar conocimiento confiable que la organización ya tenía, pero mal accesible.

Qué controles mínimos debería tener una empresa

Antes de desplegar un sistema RAG sobre datos internos, hay una checklist bastante básica que conviene cumplir:

  • segmentar fuentes según permisos reales;
  • no indexar todo por defecto;
  • registrar consultas y documentos recuperados;
  • separar fuentes confiables de fuentes abiertas o editables;
  • filtrar o sanear contenido antes de indexarlo;
  • validar mejor el retrieval en acciones sensibles;
  • limitar acceso del asistente a secretos y datos de alto impacto;
  • hacer pruebas específicas de prompt injection, leakage y poisoning.

Si una organización no puede explicar con claridad qué entra al índice, quién puede consultarlo y cómo se audita lo recuperado, todavía no está gobernando bien su RAG.

RAG no es una feature suelta, es un sistema

Esta es probablemente la idea más importante de todo el tema.

Cuando una empresa conecta un LLM a bases de conocimiento internas, no está activando una simple mejora de UX. Está desplegando una arquitectura nueva de acceso, recuperación, decisión y exposición de información.

Por eso evaluar RAG solo por la calidad aparente de las respuestas es un error. También hay que mirar permisos, fuentes, trazabilidad, sanitización, monitoreo y diseño del flujo completo.

Conclusión

RAG puede volver mucho más útiles a los asistentes basados en LLMs. Pero también puede volver mucho más delicada la superficie de datos, permisos y seguridad de una organización.

La lectura madura no es "RAG arregla al modelo" ni tampoco "RAG es inseguro por definición". La lectura madura es otra: RAG mejora capacidad cuando el sistema está bien gobernado, y amplifica problemas cuando se conecta de forma torpe a información sensible.

Si lo pensás como arquitectura y no como magia, aparecen las preguntas correctas. Y en ciberseguridad, esas preguntas son las que realmente importan.