Un asistente interno que responde sobre normativa, contratos o documentación técnica puede ahorrar horas por semana. También puede convertirse en el mayor agujero de seguridad de la empresa si responde con un documento que el usuario no tenía permiso de leer.
El riesgo no está en el modelo. Está en la arquitectura que decide qué información entra en el contexto.
El problema no es el prompt
En un RAG básico, el flujo es siempre el mismo: el usuario pregunta, el sistema busca fragmentos parecidos en una base vectorial, los mete en el prompt y el modelo redacta una respuesta. Si la búsqueda no distingue entre el contrato de un cliente y el de otro, el modelo responderá con la información que le des.
Decirle al modelo “no reveles datos confidenciales” no es un control de acceso. Es una instrucción que puede ignorar, que puede ser manipulada y que no sabe qué documentos debería haber visto el usuario. La seguridad tiene que estar en el sistema, no en la buena voluntad del modelo.
Tres capas de control
1. Permisos en el documento
Cada documento indexado necesita metadatos de acceso: empresa, departamento, proyecto, nivel de confidencialidad y lista de usuarios o grupos autorizados. Esos metadatos se guardan junto al fragmento y se consultan en el momento de la recuperación.
Si el sistema no sabe quién puede ver un documento, no debería indexarlo.
2. Filtro antes de la búsqueda vectorial
El filtro tiene que aplicarse antes de recuperar, no después. La consulta a la base vectorial debe incluir las condiciones de acceso del usuario:
- mismo tenant o empresa;
- mismos grupos o roles;
- mismo proyecto, si aplica;
- nivel de confidencialidad permitido.
Recuperar diez fragmentos y luego descartar siete es una mala práctica: los tres sensibles ya estuvieron en memoria y pueden filtrarse en logs, en la respuesta o en una siguiente iteración.
3. Respuesta con citas verificables
Cada respuesta debería incluir la fuente y el fragmento exacto que la sostiene. Eso permite al usuario comprobar la información y al equipo auditar por qué el asistente dijo lo que dijo. Si una respuesta no puede citarse, es una señal de que el modelo está completando huecos con conocimiento general.
Las citas no son solo una función de producto. Son una herramienta de seguridad y de calidad.
Qué registrar para poder investigar
Un incidente sin trazas es un incidente que no se puede cerrar. El registro mínimo debería incluir:
- identificador del usuario y sus grupos;
- consulta original;
- filtros aplicados;
- documentos recuperados y su nivel de acceso;
- respuesta generada;
- modelo y versión del prompt;
- latencia y coste.
Con esos datos puedes responder preguntas concretas: ¿qué documentos vio este usuario?, ¿por qué apareció este fragmento?, ¿el filtro falló o el documento estaba mal etiquetado?
Errores frecuentes
Indexar todo y confiar en el prompt. Es el error más caro. La base vectorial se convierte en una copia de documentos sensibles sin control.
Permisos solo en la interfaz. Ocultar un botón no impide que la API devuelva el documento. Cualquiera con la sesión abierta puede llamar al endpoint.
Metadatos incompletos. Un documento sin departamento o sin tenant acaba apareciendo donde no debe. La validación de metadatos debería bloquear la indexación, no generar una advertencia.
Reintentos sin control. Si el asistente vuelve a preguntar al modelo cuando la respuesta no le gusta, multiplicas las posibilidades de filtrar contexto. Los reintentos deben tener un límite y una política clara.
Sin evaluación de calidad. Un RAG puede ser seguro y, aun así, responder mal. Necesitas un conjunto de preguntas de prueba con respuestas esperadas y revisar periódicamente la precisión.
Cómo empezar sin un proyecto de seis meses
- Elige un caso de uso acotado y un grupo pequeño de usuarios.
- Define qué documentos entran y con qué metadatos.
- Implementa el filtro de permisos antes de la recuperación.
- Añade citas y un registro de auditoría desde el primer día.
- Mide precisión, latencia y coste antes de ampliar.
Un asistente interno útil no es el que responde a todo. Es el que responde con la información correcta a la persona correcta, y deja rastro de por qué lo hizo.
En Coderwebs construimos este tipo de asistentes dentro de asistentes IA con RAG, con permisos, citas y evaluación. Si el asistente además tiene que ejecutar acciones, conviene revisar también el diseño de agentes de IA y sus límites.
Conclusión
La seguridad de un RAG se decide en la recuperación. Si el documento equivocado entra en el contexto, ya es tarde. Permisos por documento, filtros previos y auditoría no son extras: son la base para que el asistente pueda usarse en una empresa real.