gobierno del dato ia gobernanza rgpd seguridad

El gobierno del dato para agentes de IA consiste en decidir, antes de conectar nada, qué información puede ver cada agente, con qué clasificación, cuánto tiempo la conserva, de dónde procede cada respuesta y quién responde si algo sale mal. No es un ejercicio documental: es el prerrequisito técnico que separa un despliegue que crece de uno que se para en el primer comité de seguridad.

La razón es sencilla. Un agente con acceso a los sistemas de la empresa multiplica el alcance de cualquier error de permisos: donde un empleado con acceso indebido a una carpeta habría abierto tres documentos, un agente indexa cuatro mil y los devuelve a quien pregunte con la frase correcta. La capacidad que hace útil a un agente —leer mucho y sintetizar rápido— es exactamente la que hace peligrosa una mala clasificación. Este artículo recorre las cinco piezas del gobierno del dato aplicadas a agentes: clasificación, permisos, retención, linaje y auditoría.

¿Por qué el gobierno del dato bloquea tantos proyectos de IA?

Porque el problema aparece tarde, cuando el piloto funciona y toca conectarlo a los datos reales. La demostración se hizo con veinte documentos elegidos; la producción exige apuntar a la unidad de red, al gestor documental o al correo, y ahí es donde alguien pregunta quién puede ver qué. Si la respuesta no existe, el proyecto se detiene.

Y no se detiene por burocracia: se detiene porque la mayoría de empresas descubre en ese momento que sus permisos reales no se parecen a los que creía tener. Carpetas compartidas con toda la organización «temporalmente» hace cuatro años, exportaciones de nóminas en un directorio de finanzas, contratos con datos personales en el histórico de un correo comercial. El agente no crea ese problema, lo hace visible y lo convierte en consultable.

La lectura optimista es que este trabajo se paga solo aunque el proyecto de IA se cancelara: ordenar la clasificación y los permisos mejora la seguridad, el cumplimiento y la vida diaria de la gente. La lectura realista es que hay que presupuestarlo como parte del proyecto, no como un requisito previo que aparecerá gratis.

¿Cómo se clasifica la información antes de conectar un agente?

Con cuatro niveles, no con veinte. Cualquier esquema más fino se abandona en tres meses porque nadie sabe en qué cajón va cada cosa. La regla es que cada nivel tenga una consecuencia clara sobre lo que un agente puede hacer con esa información.

Nivel	Ejemplos	Qué puede hacer el agente
Público	Catálogo, web, notas de prensa, documentación abierta	Leer, indexar y citar sin restricciones
Interno	Procedimientos, políticas, plantillas, actas ordinarias	Leer e indexar; responder solo a personal identificado
Confidencial	Contratos, precios por cliente, márgenes, expedientes	Acceso limitado por rol; respuesta con cita obligatoria y registro
Restringido	Datos de salud, nóminas, datos de menores, negociaciones abiertas	Fuera del alcance del agente salvo caso de uso aprobado y aislado

El nivel restringido merece una regla propia: por defecto, fuera. No porque sea imposible tratarlo, sino porque el coste de gobernarlo bien —base legal, minimización, evaluación de impacto, controles reforzados— rara vez compensa en los primeros casos de uso. Empezar excluyéndolo permite avanzar rápido en el 90% del valor.

¿Quién decide qué ve cada agente?

Tres roles, y ninguno de ellos es el proveedor tecnológico. Cuando esta pregunta se responde con «lo configuró la consultora», el gobierno del dato no existe.

• El propietario del dato. El responsable del área que genera esa información —finanzas para márgenes, RRHH para expedientes, comercial para precios— decide en qué nivel está y quién puede consultarla. No es un rol técnico.
• El responsable del agente. La persona que responde de lo que hace ese agente concreto: qué fuentes consume, qué puede escribir, a quién sirve y qué escala. Cada agente necesita un nombre propio detrás.
• Protección de datos. El delegado de protección de datos o quien haga esa función revisa base legal, minimización, plazos y derechos de los interesados antes de que el agente toque nada con datos personales.

Sobre esos tres roles se apoya la regla operativa que aplicamos siempre: un agente, un propósito, un conjunto de permisos. Nada de un asistente corporativo omnisciente con acceso a todo «porque es más cómodo». Varios agentes especializados son más seguros, más fáciles de auditar y, en la práctica, también más precisos. El detalle de cómo se estructuran esos permisos está en gobernanza de agentes de IA y permisos.

¿Cuánto tiempo conserva un agente lo que ve?

Más de lo que la gente supone, y en más sitios de los que imagina. Un despliegue típico guarda la misma información en cuatro lugares distintos: el historial de conversaciones, el índice de búsqueda (los embeddings), los registros técnicos y las copias de seguridad de todo lo anterior. Una política de retención que solo contemple el primero no es una política.

El punto que más problemas causa es el índice vectorial. Cuando borras un documento del origen, sus fragmentos siguen dentro del índice hasta que se reconstruye, y el agente puede seguir citando su contenido. Si ese documento contenía datos personales y alguien ejerce su derecho de supresión, el borrado en el origen no es suficiente: hay que tener un procedimiento que reindexe o elimine los fragmentos afectados, y hay que poder demostrarlo.

Nuestra recomendación práctica es fijar tres plazos por escrito desde el primer día: conversaciones (por ejemplo 90 días, salvo las que se conviertan en incidencia), registros técnicos (6-12 meses, por seguridad y auditoría) e índice (reconstrucción periódica más un procedimiento de supresión bajo demanda con plazo comprometido). Cifras que puedas cumplir de verdad, no las que quedan bien en un documento.

Linaje: ¿de dónde salió esta respuesta?

El linaje es la capacidad de reconstruir, para cualquier respuesta del agente, qué fuentes concretas usó, en qué versión y con qué fecha. Sin eso, no puedes auditar, no puedes corregir un error de raíz y no puedes defender una decisión ante un cliente, un auditor o un juzgado.

En la práctica se traduce en tres exigencias de diseño: cada fragmento indexado guarda su origen, versión y fecha; cada respuesta cita las fuentes que la sustentan; y cada cita es navegable hasta el documento real. Un agente que responde bien pero sin citar es un agente que no podrás gobernar, y esa carencia se descubre siempre en el peor momento.

El linaje también resuelve un problema cotidiano menos dramático: las políticas contradictorias. Cuando el agente cita la fuente, alguien detecta que hay dos versiones del procedimiento de devoluciones circulando desde 2024, y eso se arregla. Sin cita, el agente elige una de las dos en silencio y nadie se entera. Esta disciplina es el corazón de un sistema de recuperación bien montado, cuyo coste desglosamos en cuánto cuesta un RAG corporativo.

¿Qué hay que registrar para poder auditar?

1. Quién preguntó y qué preguntó, con identidad verificada, no con un usuario genérico compartido.
2. Qué consultó el agente: sistemas, consultas ejecutadas y documentos recuperados.
3. Qué respondió y con qué fuentes citadas.
4. Qué escribió o ejecutó, si tiene permisos de escritura: registro completo de la acción, incluido el estado anterior.
5. Qué escaló y a quién, con el motivo. Los escalados son la mejor fuente de mejora del sistema.

Estos registros deben ser inmutables para el propio agente —no puede borrar su rastro— y estar retenidos según la política acordada. Un detalle que ahorra disgustos: guarda también las decisiones de no responder. Saber cuántas veces el agente se negó y por qué es tan informativo como saber qué contestó.

¿Qué marco normativo se aplica en Europa?

Tres capas que conviene no mezclar. El RGPD sigue siendo la base para todo lo que sean datos personales: base legal, minimización, plazos, derechos de los interesados y, cuando el tratamiento es de riesgo, evaluación de impacto previa. Esta capa se aplica desde siempre y no ha cambiado con la IA.

La segunda capa es el Reglamento Europeo de IA. Desde el 2 de agosto de 2026 se aplican las obligaciones de transparencia del artículo 50 —informar a las personas de que interactúan con un sistema de IA y etiquetar contenido sintético—, junto con las obligaciones de alfabetización en IA. Los sistemas de alto riesgo del Anexo III tienen un calendario propio que, tras la revisión del paquete ómnibus digital, apunta a diciembre de 2027 (situación a agosto de 2026; conviene confirmar el texto consolidado antes de planificar cumplimiento).

La tercera es voluntaria pero cada vez más pedida en concursos y por clientes grandes: la norma ISO/IEC 42001 de sistemas de gestión de IA, que da una estructura reconocible a todo lo anterior. Si tu empresa ya tiene ISO 27001, el salto es razonable; si no, empieza por el gobierno del dato y deja la certificación para cuando haya algo que certificar. Y si la conclusión del análisis es que ciertos datos no deben salir de tu infraestructura, esa decisión tiene consecuencias de arquitectura que repasamos en IA en local frente a nube y privacidad.

Cómo implantarlo sin parar el proyecto

1. Semana 1-2: inventario del caso de uso. No de toda la empresa. Qué fuentes necesita ese agente concreto, quién es su propietario y qué contienen realmente.
2. Semana 3-4: clasificación y limpieza. Cuatro niveles, aplicados solo a esas fuentes. Excluye lo restringido y corrige los permisos rotos que aparezcan.
3. Semana 5-6: permisos del agente. Usuario de servicio propio, privilegio mínimo, escritura solo donde sea imprescindible.
4. Semana 7-8: retención, linaje y registro. Plazos por escrito, citas obligatorias en las respuestas y auditoría activada antes de abrir a usuarios.
5. Semana 9-12: piloto supervisado con un grupo reducido, revisión semanal de registros y ampliación por fases.

Esa secuencia encaja dentro del arranque de 90 días que usamos en cualquier despliegue serio, descrito en el checklist de 90 días para una empresa AI-First. La clave es que el gobierno del dato avanza con el proyecto y acotado al caso de uso; el intento de gobernar todo el dato de la empresa antes de conectar el primer agente es la forma más elegante de no desplegar nunca.

Preguntas frecuentes

¿Puedo empezar un piloto sin tener esto resuelto?

Sí, si el piloto usa un conjunto de datos cerrado, sin datos personales y con usuarios identificados. Lo que no debes hacer es apuntar el piloto a la unidad de red completa «para ver qué tal». Un piloto acotado te enseña lo mismo y no crea un problema de seguridad que después hay que explicar.

¿El agente puede ver solo lo que ve el usuario que pregunta?

Es el modelo más seguro y el que recomendamos cuando la plataforma lo permite: el agente actúa en nombre del usuario y hereda sus permisos, de modo que nadie obtiene por el chat lo que no obtendría por el sistema. Tiene un coste —el índice debe respetar permisos por documento, lo que complica la arquitectura— pero elimina la clase de incidente más común.

¿Qué pasa con los datos que enviamos al proveedor del modelo?

Depende del contrato y del plan: los acuerdos empresariales de los principales proveedores excluyen el uso de los datos del cliente para entrenamiento y fijan plazos de retención cortos, pero eso hay que verificarlo en el contrato concreto y no darlo por supuesto. Es información que tu delegado de protección de datos necesita por escrito antes del despliegue, no después.

¿Cómo gestiono el derecho de supresión con un índice vectorial?

Con un procedimiento documentado que localice los fragmentos derivados de ese origen y los elimine o reindexe en un plazo comprometido. Técnicamente exige guardar la relación fragmento-origen desde el principio; si no la guardaste, la única vía es reconstruir el índice completo. Es una de esas decisiones de diseño baratas al principio y muy caras después.

¿Cuánto añade esto al coste del proyecto?

En un despliegue acotado, el trabajo de clasificación, permisos y retención suele suponer entre el 15% y el 30% del esfuerzo total la primera vez, y bastante menos en los siguientes agentes porque el marco ya existe. Presupuestarlo desde el principio evita la conversación incómoda de mitad de proyecto en la que alguien descubre que el piloto no puede pasar a producción.