Clasificación, acceso y procedencia: los tres controles de datos que los agentes vuelven obligatorios

Las políticas de clasificación de información existen en casi todas las organizaciones medianas. Suelen estar escritas, suelen definir tres o cuatro niveles, y suelen aplicarse de forma desigual: bien en los sistemas críticos, de manera irregular en el resto, y prácticamente nada en los documentos que la gente crea todos los días.

Esa aplicación desigual fue tolerable durante años porque el riesgo estaba acotado por la fricción humana. Un permiso demasiado amplio significaba que alguien podía acceder a algo que no le correspondía, si se le ocurría buscarlo, si sabía dónde estaba y si tenía motivo para hacerlo. Tres condiciones que raramente se daban juntas.

Los agentes eliminan las tres condiciones. Un agente busca todo lo que puede buscar, encuentra lo que está indexado y no necesita motivo. Un permiso demasiado amplio deja de ser un riesgo latente y pasa a ser una fuga probable.

Los tres controles

Clasificación. Qué nivel de sensibilidad tiene cada conjunto de información, aplicado de forma consistente y legible por sistemas. No basta con una política escrita: la clasificación tiene que estar en los metadatos, donde un sistema pueda leerla y actuar en consecuencia.

Control de acceso. Quién puede consultar qué, incluidos los agentes como sujetos de derecho propio. Un agente que actúa en nombre de una persona debería tener, como máximo, los permisos de esa persona. Un agente que actúa por su cuenta necesita sus propios permisos, definidos explícitamente y no heredados por conveniencia.

Procedencia. De dónde salió cada dato y por qué transformaciones pasó. Cuando una respuesta contiene información sensible, la pregunta inmediata es de dónde la sacó. Sin procedencia, no hay respuesta.

El problema del permiso heredado

Hay un patrón que merece atención específica porque es común y silencioso.

Cuando un agente se conecta a los sistemas de una organización, alguien tiene que darle credenciales. La ruta rápida es usar una cuenta de servicio existente que ya tiene los accesos necesarios. Esa cuenta, casi siempre, tiene bastante más de lo necesario, porque se creó para otro propósito y sus permisos crecieron con el tiempo.

El resultado es un agente con acceso a información que nadie decidió darle. Y como el acceso es técnico y no pasa por ninguna interfaz humana, no hay ningún momento en que alguien note la desproporción.

La corrección requiere invertir el orden. En vez de preguntar qué credencial disponible sirve, preguntar qué necesita exactamente este agente y crear una identidad con eso y nada más. Es más trabajo la primera vez y menos trabajo todas las siguientes, porque establece el patrón.

Retención y privacidad

Hay dos dimensiones adicionales que las políticas tradicionales cubren mal en un contexto con agentes.

Retención. Las conversaciones con agentes contienen información de la organización, y esas conversaciones se almacenan. La pregunta de cuánto tiempo se conservan, dónde y bajo qué protección casi nunca se responde antes del despliegue. Y cuando se responde después, con frecuencia hay meses de historial acumulado bajo condiciones que nadie definió.

Privacidad. Los datos personales que entran en una consulta a un agente son tratamiento de datos personales, con todo lo que eso implica según la regulación aplicable. Esto incluye datos de empleados, de clientes y de terceros mencionados en documentos que el agente consulta.

Ninguna de las dos es una consideración futura. Son decisiones que ya se están tomando por defecto, en cada organización que tiene un agente en operación, simplemente sin que nadie las haya tomado.

Lo que la regulación agrega

Para organizaciones con exposición europea, la aplicación general del Reglamento de Inteligencia Artificial de la Unión Europea llega el 2 de agosto de 2026, con excepciones y períodos de transición específicos.

Independientemente del alcance exacto que aplique a cada organización, la dirección es inequívoca: trazabilidad, transparencia, supervisión humana y gestión de riesgos dejaron de ser buenas prácticas voluntarias. Y los tres controles de este artículo son precisamente la base sobre la que se construye la trazabilidad.

Una organización que no puede decir qué datos consultó un sistema, con qué autorización y de dónde venían, no puede demostrar cumplimiento de nada. No porque incumpla necesariamente, sino porque no tiene evidencia.

El problema de los permisos en la recuperación de contexto

Hay un escenario técnico que produce fugas silenciosas y que muchas organizaciones no anticipan al desplegar un asistente sobre documentos internos.

El patrón habitual consiste en indexar un conjunto de documentos para que el sistema pueda recuperar fragmentos relevantes ante una consulta. La pregunta que suele resolverse tarde es qué pasa con los permisos de esos documentos una vez indexados.

Si el índice no conserva el permiso de origen, ocurre lo predecible: cualquier persona con acceso al asistente puede recibir, dentro de una respuesta, un fragmento de un documento al que no tiene acceso. No lo abrió, no lo buscó, no violó ningún control. El sistema se lo entregó.

Hay tres formas de resolverlo y conviene elegir conscientemente.

Filtrar en la recuperación. El índice conserva el permiso de cada fragmento y la consulta se filtra según la identidad de quien pregunta. Es la solución correcta y la que más trabajo de integración requiere, porque exige que el sistema de permisos y el índice se mantengan sincronizados.

Segmentar los índices. Un índice por nivel de acceso, y cada usuario consulta el que le corresponde. Más simple de implementar y menos granular; funciona bien cuando los niveles de acceso son pocos y estables.

Indexar solo lo abierto. El índice contiene únicamente documentos accesibles para toda la audiencia del asistente. Es la opción más segura y la que menos valor entrega, porque deja fuera precisamente el conocimiento más específico.

La tercera es un punto de partida razonable mientras se construye la primera, y es mucho mejor que la opción por defecto, que es indexar todo y no filtrar nada.

Hay un caso adicional que conviene revisar: los permisos que cambian después de indexar. Alguien pierde acceso a un área, pero el índice se construyó cuando lo tenía. Si el filtrado ocurre en la recuperación con la identidad actual, no hay problema. Si el índice se segmentó por permisos históricos, la revocación no tiene efecto hasta la siguiente reindexación.

Esa desincronización entre permisos vigentes y permisos indexados es exactamente el tipo de brecha que ninguna auditoría de accesos detecta, porque el sistema de identidades muestra la configuración correcta.

Una revisión de dos horas

Hay un ejercicio acotado que produce un diagnóstico honesto.

Toma el agente o asistente que hoy tiene más uso en tu organización. Responde cinco preguntas por escrito:

1. ¿Con qué identidad accede a los datos y quién es su dueño?
2. ¿Qué conjuntos de información puede consultar, enumerados?
3. ¿Alguno de esos conjuntos contiene información clasificada como restringida o datos personales?
4. ¿Dónde se almacenan las conversaciones y por cuánto tiempo?
5. Si alguien pregunta de dónde salió una respuesta específica, ¿se puede reconstruir?

La experiencia de hacer este ejercicio es bastante consistente: las dos primeras preguntas se responden con esfuerzo, la tercera produce una sorpresa, y las dos últimas revelan que nadie las había pensado.

Ese es un buen resultado. Un diagnóstico incómodo y concreto vale más que una política de veinte páginas que describe cómo debería ser todo.