En este artículo
Un asistente RAG que consulta expedientes, contratos, manuales internos o bases de conocimiento puede acelerar decisiones y reducir tiempos de búsqueda. Pero también puede convertir una brecha de permisos, una mala indexación o una instrucción maliciosa en una exposición de información institucional. Entender cómo proteger datos RAG exige tratar esta solución como parte de la arquitectura empresarial, no como un chat conectado a documentos.
RAG, o generación aumentada por recuperación, permite que un modelo de lenguaje responda a partir de fuentes documentales seleccionadas. El modelo no necesita memorizar los documentos: los consulta mediante un motor de recuperación y usa los fragmentos encontrados para construir una respuesta. Esta separación es útil, pero no elimina el riesgo. Los datos viajan, se transforman, se indexan, se consultan y, finalmente, se presentan a una persona o a otro sistema.
La seguridad debe acompañar cada una de esas etapas. El objetivo no es impedir el uso de inteligencia artificial, sino garantizar que sus respuestas respeten los mismos límites de acceso, custodia y trazabilidad que la organización exige fuera del asistente.
Cómo proteger datos RAG desde la arquitectura
La primera decisión es definir qué información puede entrar al sistema y con qué propósito. No todo repositorio institucional debe estar disponible para un asistente, aunque técnicamente sea posible conectarlo. Una biblioteca de políticas públicas puede tener un tratamiento distinto al de historias laborales, información contractual reservada, investigaciones en curso o datos personales.
Conviene partir de una clasificación de la información que ya tenga validez operativa. Si la organización no la posee, el proyecto RAG es una oportunidad para construirla con las áreas jurídicas, de seguridad, datos y negocio. La clasificación debe establecer, como mínimo, qué contenido es público, interno, confidencial o restringido; quién es responsable de cada fuente; cuánto tiempo debe conservarse; y qué usuarios pueden consultarlo.
Este trabajo evita un error frecuente: asumir que proteger la interfaz del chat protege todo el sistema. Un usuario puede autenticarse correctamente y, aun así, recibir fragmentos que no debería ver si el índice vectorial no conserva los permisos originales de los documentos. La autorización debe aplicarse antes de recuperar contenido, no solo al momento de mostrar la respuesta.
Los permisos deben viajar con cada fragmento
Para responder, un RAG divide los documentos en fragmentos y los transforma en representaciones matemáticas llamadas embeddings. Ese proceso mejora la búsqueda semántica, pero puede romper el vínculo con los permisos si no se diseña con cuidado.
Cada fragmento indexado debe conservar metadatos verificables: fuente de origen, propietario, fecha de actualización, nivel de clasificación, dependencia responsable, vigencia y reglas de acceso. Cuando un usuario hace una consulta, el sistema debe filtrar los fragmentos candidatos según su identidad, rol, unidad organizacional y contexto autorizado.
No basta con usar un filtro genérico como “usuario interno”. En entidades públicas, universidades y empresas con estructuras complejas, un mismo documento puede ser visible para un área, restringido para otra o estar sujeto a una etapa específica de un flujo. La política de acceso debe reflejar esa realidad.
También es recomendable mantener los documentos maestros en su repositorio institucional y utilizar el índice RAG como una representación controlada, no como la única copia operativa. Así es posible corregir, retirar o actualizar contenido sin depender de un repositorio opaco o difícil de auditar.
El ingreso de documentos es una superficie de riesgo
Gran parte de la seguridad de un RAG se decide antes de la primera consulta. Los conectores hacia gestores documentales, sitios Drupal, sistemas de archivos, correo o plataformas de atención deben operar con credenciales de mínimo privilegio. Un conector que puede leer todo el repositorio por comodidad crea un riesgo desproporcionado.
La ingesta debe validar formatos, detectar duplicados, registrar su procedencia y excluir información que no corresponda al caso de uso. Un archivo cargado por error, una versión obsoleta de una circular o un documento con datos personales innecesarios pueden terminar influyendo en respuestas posteriores.
Además, los documentos no son necesariamente confiables solo porque provengan de una fuente interna. Un texto puede incluir instrucciones diseñadas para manipular al modelo, por ejemplo, pedirle que ignore sus reglas, revele contexto de otras consultas o cambie su comportamiento. Esto se conoce como inyección de instrucciones indirecta. La defensa no consiste únicamente en agregar una frase al prompt: requiere separar las instrucciones del sistema del contenido recuperado, marcar el contenido como no confiable y limitar las acciones que el modelo puede ejecutar.
Cuando la fuente es un sitio institucional o una plataforma editorial, la calidad del flujo editorial también importa. Versionado, revisión, fechas de vigencia y responsables claros reducen el riesgo de que el RAG responda con información desactualizada o sin aprobación.
Controlar la salida también protege la información
Una respuesta puede exponer información incluso cuando cada fragmento recuperado parecía autorizado. El modelo puede combinar varios elementos, inferir relaciones sensibles o reproducir contenido con un nivel de detalle mayor al necesario. Por eso la salida necesita controles propios.
El asistente debe citar las fuentes internas que sustentan su respuesta, indicando el documento y, cuando aplique, la fecha o versión. Esto permite a la persona usuaria verificar el contenido y facilita la auditoría posterior. Las citas no son un adorno de experiencia: son un mecanismo de trazabilidad y una barrera contra respuestas sin fundamento.
Para datos personales, secretos empresariales o información sometida a reserva, pueden aplicarse políticas de minimización y enmascaramiento. El sistema debería responder con la menor cantidad de información necesaria para completar la tarea. Si una consulta requiere una autorización adicional, la respuesta correcta no es intentar inferirla, sino orientar al usuario hacia el proceso establecido.
También conviene distinguir entre un RAG informativo y un agente con capacidad de actuar sobre sistemas. Consultar un manual de compras no tiene el mismo nivel de riesgo que crear una orden, modificar un registro o enviar una comunicación externa. Las acciones deben ser acotadas, auditables y medibles, con validación humana para procesos de alto impacto.
Qué controles técnicos no deberían negociarse
La herramienta elegida importa, pero la arquitectura importa más. Una implementación madura suele combinar los siguientes controles:
- Autenticación integrada con el proveedor de identidad institucional y autorización granular basada en roles, atributos o políticas.
- Cifrado de datos en tránsito y en reposo, con una gestión clara de llaves, entornos y copias de respaldo.
- Segmentación entre desarrollo, pruebas y producción, evitando usar documentos reales en ambientes no controlados.
- Registros de auditoría que relacionen usuario, consulta, documentos recuperados, respuesta generada, acción ejecutada y versión de la configuración.
- Políticas de retención para conversaciones, archivos temporales, índices y telemetría, alineadas con obligaciones legales y operativas.
En algunos casos, será apropiado usar modelos desplegados en infraestructura privada o servicios empresariales con condiciones contractuales específicas para el tratamiento de datos. En otros, un servicio administrado puede ser suficiente si ofrece aislamiento, garantías de no entrenamiento con los datos del cliente, residencia de datos compatible y controles auditables. No hay una respuesta universal: depende de la criticidad de la información, del marco regulatorio, de la capacidad de operación interna y de los requisitos de continuidad.
Evaluar ataques antes de abrir el RAG a toda la organización
Un piloto no debe medirse solo por la calidad percibida de las respuestas. Debe someterse a pruebas deliberadas de seguridad y comportamiento. Es útil crear un conjunto de consultas que intenten acceder a documentos de otros perfiles, extraer instrucciones internas, revelar datos enmascarados, utilizar archivos con instrucciones maliciosas o provocar respuestas fuera del alcance del asistente.
Estas evaluaciones deben repetirse cuando cambien el modelo, el prompt, los conectores, las políticas de acceso o las fuentes de información. Un ajuste aparentemente menor puede alterar la forma en que el sistema recupera contenido o responde a instrucciones ambiguas.
Los equipos responsables necesitan indicadores que permitan operar el servicio con criterio: consultas bloqueadas por política, intentos de acceso no autorizado, fuentes desactualizadas, porcentaje de respuestas con cita verificable, incidentes de calidad y tiempos de corrección. La observabilidad convierte la seguridad en una práctica continua, no en una revisión previa al lanzamiento.
Gobernanza para sostener el sistema en el tiempo
La protección de datos RAG requiere responsables definidos. Tecnología puede administrar la plataforma, pero no debería decidir por sí sola qué documentos son válidos, quién puede verlos o cuándo debe retirarse una fuente. Esas decisiones requieren participación de los dueños de información, seguridad, jurídico, gestión documental y las áreas usuarias.
Una política operativa debe establecer cómo se aprueban nuevas fuentes, cómo se corrigen respuestas erróneas, quién atiende incidentes, cuándo se revisan los permisos y qué evidencia se conserva. En organizaciones con plataformas críticas, esta gobernanza debe integrarse a los procesos existentes de gestión de cambios, continuidad operativa y arquitectura empresarial.
Coresis aborda este tipo de iniciativas desde tecnología aplicada con criterio de arquitectura y continuidad: conectando el RAG con los sistemas existentes, preservando controles institucionales y diseñando una operación que pueda evolucionar sin perder trazabilidad.
La pregunta útil no es si un RAG puede responder sobre los documentos de la organización. La pregunta es qué puede responder, para quién, con qué fuentes, bajo qué evidencia y con qué mecanismo de corrección cuando algo cambia. Cuando esas respuestas están definidas antes de escalar, la inteligencia artificial deja de ser un punto ciego y se convierte en una capacidad institucional gobernable.