Por qué la mayoría de asistentes de IA empresarial pueden filtrar lo que no deberían
Hay una escena que se repite en casi todas las demos de asistentes de IA para empresas: alguien escribe una pregunta, el sistema busca entre los documentos internos y responde en segundos con una precisión que impresiona. La demo convence, el proyecto arranca. Y unos meses después, alguien de soporte hace una pregunta rutinaria y recibe, junto a la respuesta, un dato de nómina que jamás debería haber visto.
No es un fallo exótico, y no hace falta un atacante sofisticado para provocarlo. Es la consecuencia directa de cómo funciona la búsqueda semántica cuando nadie ha pensado en los permisos desde el primer día. Merece la pena entender el mecanismo, sin jerga, porque si estás evaluando un asistente de IA para tu empresa esto es lo primero que deberías mirar.
Qué les pasa a tus documentos cuando entran en un buscador semántico
Para que una IA responda preguntas sobre tus documentos, primero hay que convertirlos en algo que se pueda buscar por significado, no solo por palabras exactas. Ese proceso trocea cada documento en fragmentos y transforma cada fragmento en un vector: una larga lista de números que representa de qué habla ese texto. Cuando alguien pregunta algo, su pregunta se convierte también en números, y el sistema recupera los fragmentos que más se le parecen. Esta arquitectura se llama RAG (generación aumentada por recuperación) y es la base de prácticamente todos los asistentes de conocimiento corporativo del mercado.
El problema nace en un detalle fácil de pasar por alto. El documento original vivía en una carpeta con permisos: solo lo veía RRHH, o solo dirección. Pero el fragmento vectorizado es otra cosa. Vive en otro sitio —un almacén de vectores— y, si nadie lo diseña a propósito, no arrastra consigo la información de quién podía ver el original. A partir de ahí, el buscador hace su trabajo: encontrar lo más relevante para la pregunta. Que no es lo mismo que lo que esa persona tiene permiso de ver. Son dos criterios distintos, y el segundo no viene de serie.
El parche habitual: filtrar después de buscar
La mayoría de implementaciones intentan resolver esto en la capa de aplicación: primero recuperan los fragmentos más relevantes y luego, con los resultados ya en la mano, descartan los que el usuario no debería ver. Recuperar primero y filtrar después es un patrón de fallo documentado y recurrente en la industria; no es la anécdota de una implementación descuidada.
¿Por qué falla? Porque ese filtro es código de aplicación, y el código de aplicación tiene bugs, casos límite y metadatos que alguien olvidó rellenar. Basta un conector que indexa una carpeta de más, un documento con contenido mezclado de dos departamentos o una condición mal escrita para que un fragmento restringido llegue hasta el modelo, y de ahí a la respuesta. Y hay algo peor: aunque el filtro funcione, el contenido restringido ya ha viajado desde la base de datos hasta la aplicación. La puerta estaba abierta; solo confiabas en que el último guardia mirase bien.
Un ejemplo hipotético (pero perfectamente plausible)
Imagina que alguien de operaciones pregunta: «¿Cómo se calcula el plus de los turnos de fin de semana?». En el almacén de vectores hay un fragmento de la tabla salarial completa del departamento, porque en su día alguien subió el Excel a la carpeta compartida equivocada, o porque el conector indexó más de la cuenta. Semánticamente, ese fragmento es lo más relevante que existe para esa pregunta. Si el permiso no se comprobó al buscar, la respuesta llega con nombres y cifras que esa persona nunca debería haber visto. Nadie ha hackeado nada: el sistema ha hecho exactamente aquello para lo que fue construido.
¿Cómo de extendido está este problema? Voy a ser honesto: las cifras concretas que circulan proceden de fuentes sueltas, no de estudios independientes auditados, así que no voy a darte un porcentaje como si fuera un hecho verificado. Lo que sí se puede afirmar es que los análisis del sector apuntan de forma consistente en la misma dirección: las fugas entre departamentos o entre clientes en sistemas RAG son un problema extendido, no marginal. Lo bastante extendido como para que sea la primera pregunta que le hagas a cualquier proveedor.
Cómo se hace bien
La alternativa no tiene misterio conceptual, aunque exija bastante más trabajo de ingeniería. Consiste en tres decisiones que hay que tomar al principio del diseño, no al final:
- El permiso se comprueba al recuperar, no después. El filtro de acceso forma parte de la consulta misma, reforzado a nivel de base de datos. No es un «if» en el código de la aplicación: es la base de datos negándose a devolver lo que no corresponde.
- El aislamiento se refuerza en capas independientes. Base de datos y almacén de vectores aplican cada uno su propia separación, de modo que un fallo en una capa no compromete la otra. Y se verifica con pruebas automáticas, no con confianza.
- Los datos verdaderamente sensibles ni siquiera entran en el juego. Nóminas y datos personales de empleados no se vectorizan ni pasan por el buscador semántico: cada acceso a ellos se comprueba de forma explícita en el servidor, consulta a consulta.
Así está construido Savia desde el primer día: cada departamento tiene su espacio de conocimiento aislado a nivel de base de datos, el aislamiento entre empresas se verifica en dos capas independientes con pruebas automáticas, y los datos sensibles de empleados viven fuera del pipeline de búsqueda semántica por completo. No por ser más listos que nadie, sino por haber empezado por la pregunta de los permisos en lugar de dejarla para el final.
Si estás evaluando asistentes de IA, no preguntes «¿tiene permisos?»: todos te dirán que sí. Pregunta dónde se aplican. La respuesta separa los sistemas diseñados para una empresa de las demos que solo aspiran a impresionar en una reunión.