Roles y responsabilidades de un equipo de Data Governance: la estructura mínima para cumplir el AI Act

Por qué los data governance roles son críticos para el AI Act

El AI Act no regula solo los sistemas de IA. Regula los procesos, la documentación y las personas responsables de esos sistemas. El artículo 10 exige gobernanza de datos sobre los datasets de entrenamiento. El artículo 11 exige documentación técnica mantenida por alguien. El artículo 14 exige supervisión humana efectiva y verificable. El artículo 9 exige un sistema de gestión de riesgos con responsables asignados.

Cada uno de esos artículos presupone que hay una persona o un equipo con mandato claro para ejecutar esas responsabilidades. Si en tu organización no existe esa persona —o existe en el papel pero sin tiempo ni autoridad real— el cumplimiento del Reglamento es una declaración de intenciones, no una realidad auditable. Y AESIA y la AEPD inspeccionan realidades, no intenciones.

Para entender el contexto regulatorio completo, consulta el artículo AI Act key dates: qué debe hacer tu empresa en cada hito regulatorio.

El Data Governance Lead: el rol que lo hace posible todo

El Data Governance Lead —también llamado Chief Data Officer en organizaciones grandes, o Head of Data Governance en entornos más operativos— es el rol que convierte la gobernanza de datos de un proyecto en una capacidad organizativa. Sin este perfil con mandato ejecutivo real, los demás roles existen en el vacío.

Responsabilidades del Data Governance Lead

• Definir y mantener la estrategia de data governance alineada con los objetivos de negocio y los requisitos regulatorios.
• Presidir el Data Governance Committee y garantizar que las decisiones sobre el dato tienen seguimiento real.
• Asignar y gestionar los Data Owners por dominio, con responsabilidades formales documentadas.
• Ser el interlocutor principal ante la dirección, el área legal y, en caso de inspección, ante AESIA o la AEPD.
• Priorizar los dominios críticos de datos, los proyectos de calidad y las iniciativas de catálogo y linaje.
• Gestionar el presupuesto y los recursos del equipo de gobernanza.

Qué perfil necesita

No es un perfil puramente técnico ni puramente de negocio. Es un perfil híbrido que entiende cómo funcionan los datos técnicamente, cómo los usa el negocio y qué implica el marco regulatorio. En la práctica, los mejores perfiles vienen de roles como Data Architect, Business Intelligence Manager o Data Product Manager con exposición a proyectos de cumplimiento normativo. La capacidad de comunicar hacia arriba —a dirección y consejo— y hacia abajo —a equipos técnicos— es tan importante como el conocimiento técnico.

En entornos con múltiples unidades de negocio, como los grupos con varias filiales, este rol se replica en dos niveles: un Data Governance Lead corporativo que define los estándares y un Data Governance Lead local por entidad que los implementa. Sin esa estructura federada, el framework corporativo se convierte en algo que "existe en el papel pero no en la práctica".

El Data Owner: el responsable de negocio del dato

El data owner role es el más malentendido en la práctica. No es el técnico que gestiona la tabla en la base de datos. Es el responsable de negocio que responde por la calidad, el uso correcto y la protección del dato dentro de su dominio. En muchas organizaciones este rol existe implícitamente —alguien "sabe" de qué datos es responsable— pero sin formalización ni autoridad real, lo que lo convierte en un rol decorativo.

Data governance responsibilities del Data Owner

• Aprobar y revocar accesos a los datos de su dominio, con criterio de negocio.
• Validar y aprobar las definiciones de negocio de las entidades y métricas de su dominio.
• Asumir la responsabilidad formal sobre la calidad del dato: si un informe ejecutivo tiene un dato incorrecto, el Data Owner responde.
• Aprobar el uso de datos de su dominio en proyectos de IA, analítica avanzada o compartición con terceros.
• Participar en el Data Governance Committee con voto en decisiones que afecten a su dominio.
• Firmar las fichas de dataset para sistemas de IA de alto riesgo que usen datos de su dominio (art. 10 AI Act).

El error más frecuente con este rol

Nombrar Data Owners sin decírselo, sin darles tiempo asignado y sin darles autoridad real sobre las decisiones de acceso. El resultado es un RACI bonito en una presentación y un dominio de datos sin gobernanza real. El Data Owner necesita saber que es Data Owner, entender qué significa eso y tener capacidad real de decir que no cuando alguien solicita un acceso que no corresponde.

El Data Steward: el operador de la gobernanza en el día a día

Si el Data Owner es el responsable de negocio, el Data Steward es el ejecutor operativo. Las data steward responsibilities cubren todo lo que ocurre en el espacio entre la política (definida por el Lead y el Committee) y la implementación técnica (ejecutada por Data Engineering). Es el rol que mantiene viva la gobernanza en el día a día.

Responsabilidades del Data Steward

• Mantener el glosario de negocio: definiciones de entidades, métricas, jerarquías y relaciones entre dominios.
• Definir, documentar y supervisar las reglas de calidad del dato para su dominio.
• Gestionar las solicitudes de acceso de primer nivel: verificar que la solicitud es coherente con el rol de negocio del solicitante antes de elevarla al Data Owner.
• Documentar el linaje de negocio en el catálogo: qué transformación de negocio representa cada campo, qué reglas se aplicaron y quién las aprobó.
• Coordinar con Data Engineering la implementación técnica de las reglas de calidad y los controles de acceso.
• Actuar como punto de contacto para cualquier equipo que tenga dudas sobre la definición, el origen o el uso correcto de los datos de su dominio.
• Mantener actualizadas las fichas de dataset para sistemas de IA que usen datos de su dominio.

Cuántos Data Stewards necesita una organización

La respuesta depende del número de dominios críticos y del volumen de actividad de gobernanza en cada uno. En la práctica, un Data Steward puede gestionar entre uno y tres dominios si la carga es razonable. Por debajo de eso, el rol es superficial. Por encima, el Steward no puede hacer bien su trabajo y acaba priorizando solo los incendios.

En entornos multi-entidad, el modelo que mejor funciona es tener Stewards locales por entidad —que conocen el negocio y los datos locales— coordinados por un Steward corporativo por dominio que mantiene la coherencia de las definiciones maestras.

El Data Custodian: el guardián técnico del dato

El Data Custodian es el perfil técnico responsable del almacenamiento, la seguridad física y el acceso a nivel de infraestructura. En muchas organizaciones este rol lo ejerce el equipo de Data Engineering o el equipo de plataforma de datos, sin que nadie lo llame formalmente Data Custodian. El nombre importa menos que la claridad de las responsabilidades.

Responsabilidades del Data Custodian

• Implementar y mantener los controles de acceso técnicos: RBAC en Snowflake, permisos en el data lake, RLS en la capa semántica.
• Gestionar el ciclo de vida técnico del dato: retención, archivado, borrado conforme a políticas de privacidad y regulación.
• Asegurar la disponibilidad y la integridad de los datos: backups, recuperación ante fallos, monitorización de pipelines.
• Implementar las reglas de calidad definidas por el Data Steward en los pipelines de datos.
• Mantener los logs de acceso y auditoría que el AI Act (art. 12) y el RGPD exigen para sistemas regulados.
• Ejecutar los cambios técnicos derivados de revisiones de acceso: revocar permisos, ajustar roles, documentar cambios.

Roles técnicos especializados: RBAC, linaje, calidad y auditoría

En organizaciones con mayor madurez o mayor volumen de datos, los roles técnicos de gobernanza se especializan. Estos no son roles independientes en todos los casos; en equipos pequeños, un único perfil de Data Engineering cubre varios. Lo importante es que cada responsabilidad tenga un propietario claro.

Especialista en Access Governance (RBAC)

Diseña y mantiene el modelo de control de acceso basado en roles: qué rol tiene acceso a qué dato, en qué plataforma y bajo qué condiciones. En entornos con Snowflake y Power BI, este perfil gestiona la sincronización entre los roles de negocio definidos por los Data Owners y la implementación técnica en las plataformas. También diseña y mantiene los workflows de solicitud y aprobación de acceso, y ejecuta las revisiones trimestrales con evidencia documentada.

En entornos como IAG, con miles de usuarios distribuidos entre múltiples aerolíneas y sistemas, este rol es crítico: un modelo de RBAC mal diseñado genera tanto sobreprivilegio —acceso a datos que no corresponden— como fricción operativa —usuarios que no pueden acceder a lo que necesitan para hacer su trabajo.

Especialista en Data Lineage

Mantiene la trazabilidad end-to-end del dato: desde la fuente transaccional hasta el dashboard o el modelo de IA. En stacks modernos con dbt y OpenMetadata, parte de este trabajo se automatiza. Pero el linaje de negocio —qué transformación de negocio representa cada campo, qué reglas se aplicaron y quién las aprobó— requiere un perfil que entienda tanto el dato técnico como el contexto de negocio. Este es el perfil que garantiza que el artículo 10 del AI Act tiene sustancia real, no solo existencia formal.

Especialista en Data Quality

Define, implementa y monitoriza las reglas de calidad en los pipelines de datos. Trabaja con dbt tests, Great Expectations o Soda para traducir los umbrales de calidad acordados con los Data Stewards en controles automáticos. Mantiene los dashboards de calidad visibles para los Data Owners y gestiona el proceso de remediación cuando se detectan anomalías. En entornos con datos de entrenamiento para modelos de IA, este perfil es además responsable de documentar las métricas de calidad que el art. 10 del AI Act exige.

Especialista en Auditoría y Reporting de Gobernanza

Mantiene los dashboards de auditoría que hacen visible el estado de la gobernanza para la dirección, el área legal y los auditores externos. Accesos activos por rol, fechas de última revisión, incidencias de calidad abiertas, cobertura del catálogo por dominio, estado de la documentación de sistemas de IA. Este perfil convierte la gobernanza en algo medible y, por tanto, defendible ante el regulador.

Señales de que tu empresa necesita estructurar estos roles ya

Estos son los síntomas más claros de que la estructura de data governance roles es insuficiente y que el riesgo —operativo y regulatorio— está creciendo:

• Nadie sabe quién es el responsable de un dato cuando algo falla. La pregunta "¿de quién es este dato?" genera silencio o una cadena de correos sin respuesta clara.
• Los accesos se aprueban por email o por Slack. Sin workflow formal, sin trazabilidad y sin revisión periódica. En una inspección de la AEPD o AESIA, esto es indefendible.
• El mismo KPI tiene definiciones distintas según el equipo. Señal directa de ausencia de Data Stewards con autoridad sobre las definiciones de negocio.
• La documentación técnica de los sistemas de IA no existe o no está actualizada. Si el art. 11 del AI Act requiere documentación previa al despliegue y esa documentación no existe, el riesgo es inmediato.
• El catálogo de datos lleva meses sin actualizarse. Sin un Data Steward con tiempo asignado, el catálogo muere en semanas. Si está muerto, la gobernanza es nominal.
• No hay nadie con mandato para decir que no. Si cualquier solicitud de acceso o uso de datos se aprueba porque "nadie tiene autoridad para negarla", la gobernanza no existe.
• La empresa va a desplegar o ya despliega un sistema de IA de alto riesgo sin tener asignado quién gestiona los datasets, quién mantiene la documentación técnica y quién responde ante el regulador.

Lo que he visto en entornos complejos

Caso 1 — RBAC sin propietario en un grupo multi-aerolínea

En un entorno con múltiples aerolíneas bajo una misma holding, los roles de acceso en Snowflake habían sido configurados en el año uno del proyecto por el equipo de ingeniería. Tres años después, nadie había revisado qué usuarios seguían activos, qué roles habían crecido más allá de su scope original y qué accesos habían quedado huérfanos por bajas o cambios de rol. El problema no era técnico: era que no existía un Data Custodian con mandato explícito para mantener ese modelo de acceso vivo.

La solución no fue técnica en primer lugar: fue asignar formalmente ese mandato, establecer un proceso de revisión trimestral con evidencia documentada y construir un dashboard de auditoría en Power BI que hacía visible el estado de los accesos para los Data Owners de cada dominio. La herramienta es la misma; lo que cambió fue quién era responsable de mantenerla.

Caso 2 — Data Stewards sin tiempo en proyectos de BI comercial

En proyectos de BI para equipos comerciales, el patrón más frecuente es que el rol de Data Steward recae implícitamente en el analista más senior del equipo, que lo ejerce entre sus otras responsabilidades sin tiempo asignado ni reconocimiento formal. El resultado es un glosario de negocio que nadie actualiza, definiciones que varían entre informes y un equipo que dedica el 30% de su tiempo a resolver dudas sobre datos en lugar de analizarlos.

Formalizar el rol —con tiempo asignado, criterios claros de responsabilidad y visibilidad en el catálogo— transforma ese coste oculto en un activo visible. Los nuevos analistas se incorporan más rápido, las reuniones de validación de datos desaparecen y la confianza en los informes aumenta de forma medible.

Caso 3 — AI Governance sin propietario en entornos regulados

En entornos con sistemas analíticos que apoyan decisiones operativas —optimización de rutas, pricing dinámico, predicción de demanda— la pregunta de quién es responsable del modelo de IA suele recaer en el equipo que lo construyó, que no tiene mandato de gobernanza y que no mantiene la documentación técnica más allá de los comentarios en el código. Cuando ese equipo cambia o el sistema evoluciona, la documentación queda obsoleta.

La solución que funciona es extender el mandato del Data Governance Lead para cubrir explícitamente los sistemas de IA: clasificación de riesgo, asignación de Data Owners para los datasets de entrenamiento, revisión periódica de la documentación técnica y proceso de aprobación antes de cualquier nuevo despliegue en producción. No es un nuevo equipo; es una extensión del framework existente con responsabilidades explícitas.

Errores frecuentes en la definición de data governance roles

• Crear roles sin asignar tiempo real. El Data Steward "a tiempo parcial" que dedica el 10% de su jornada a gobernanza entre otras diez responsabilidades no puede hacer su trabajo. La gobernanza efectiva requiere tiempo dedicado, no tiempo residual.
• Confundir Data Owner con el administrador técnico de la base de datos. El Data Owner es un rol de negocio. Asignarlo al DBA o al Data Engineer genera confusión de responsabilidades y decisiones técnicas donde debería haber decisiones de negocio.
• Un único perfil para todo. Poner a una sola persona como Data Governance Lead, Data Steward, Data Custodian y especialista de calidad a la vez garantiza que nada se hace bien. El equipo mínimo viable es pequeño, pero debe tener responsabilidades separadas.
• Roles definidos pero sin Data Governance Committee. Sin un foro de decisión formal donde los Data Owners, el Lead y el área legal se reúnan periódicamente, los conflictos sobre el dato —y los habrá— no tienen cauce de resolución. Se resuelven por jerarquía o por quien grita más fuerte, que es la forma más ineficiente de gobernar datos.
• No documentar las responsabilidades formalmente. Un RACI en una presentación que nadie vuelve a abrir no cuenta. Las responsabilidades deben estar documentadas en un documento accesible, revisado periódicamente y conocido por todos los implicados.
• Ignorar los AI Act governance roles como algo separado. Las obligaciones del AI Act sobre documentación, datasets y supervisión humana no son responsabilidades flotantes: deben estar asignadas a personas concretas. Si no hay un propietario explícito para el artículo 10, el artículo 10 no se cumple.

Conclusión: sin roles, el framework es papel mojado

Un data governance team structure efectivo no se mide por el número de personas ni por los títulos del organigrama. Se mide por si cada responsabilidad crítica —calidad, acceso, linaje, documentación, auditoría— tiene un propietario con tiempo, mandato y autoridad real para ejercerla. Sin eso, el mejor framework del mundo es una presentación bonita que no protege a nadie ni genera valor para nada.

Con el AI Act en aplicación plena, la ausencia de roles formalizados no es solo un problema operativo: es un riesgo regulatorio concreto. Las organizaciones que tienen asignadas las data governance responsibilities correctamente son las que pueden responder en minutos ante una inspección. Las que no las tienen son las que improvisan bajo presión y generan evidencia de incumplimiento en el proceso.

Para construir el framework que sustenta estos roles, consulta el artículo Cómo implementar un Data Governance Framework efectivo en la era del AI Act.

Checklist: estructura de data governance roles operativa

• Data Governance Lead designado con mandato ejecutivo y tiempo asignado.
• Data Owners formalizados por dominio crítico, con RACI documentado y responsabilidades comunicadas.
• Data Stewards asignados por dominio con tiempo dedicado y capacidad de decisión operativa.
• Data Custodian o equipo técnico con mandato explícito sobre accesos, retención y logs.
• Data Governance Committee activo con reuniones periódicas y actas documentadas.
• Especialista o responsable de RBAC con revisión trimestral de accesos y evidencia.
• Especialista o responsable de calidad del dato con reglas definidas y alertas activas.
• Responsable de linaje con cobertura end-to-end documentada en el catálogo.
• Responsable de auditoría y reporting con dashboard de gobernanza activo.
• AI Governance Officer o mandato extendido del Lead para cubrir clasificación de riesgo, documentación técnica (art. 11) y gestión de datasets de IA (art. 10).
• Todas las responsabilidades documentadas en un documento formal accesible y revisado.
• Proceso de onboarding para nuevos responsables de roles de gobernanza.

Preguntas frecuentes sobre data governance roles

¿Cuáles son los data governance roles imprescindibles en una organización?

La estructura mínima viable incluye un Data Governance Lead con mandato ejecutivo, Data Owners por dominio de negocio, Data Stewards con capacidad de decisión operativa y al menos un perfil técnico que gestione accesos, calidad y linaje. En entornos regulados por el AI Act, se añade un AI Governance Officer o se extiende el mandato del DPO para cubrir las obligaciones del Reglamento.

¿Qué diferencia hay entre un Data Owner y un Data Steward?

El Data Owner es el responsable de negocio del dato: decide sobre su uso, aprueba accesos y asume la responsabilidad formal sobre su calidad. El Data Steward es el ejecutor operativo: mantiene las definiciones, aplica las reglas de calidad y actúa como punto de contacto para cuestiones del dato en el día a día. El Owner decide; el Steward opera. Confundir ambos roles —o asignarlos a la misma persona sin tiempo suficiente— es uno de los errores más frecuentes en la práctica.

¿Qué responsabilidades tiene un Data Steward?

Las data steward responsibilities principales son: mantener el glosario de negocio actualizado, definir y supervisar las reglas de calidad del dato, gestionar las solicitudes de acceso de primer nivel, documentar el linaje de negocio en el catálogo y coordinar con los Data Owners las decisiones sobre uso y clasificación del dato. En entornos con sistemas de IA, también mantiene las fichas de dataset que exige el artículo 10 del AI Act.

¿Cómo afecta el AI Act a la estructura de roles de Data Governance?

El AI Act añade responsabilidades específicas que deben estar asignadas formalmente: clasificación de riesgo de sistemas de IA, mantenimiento de la documentación técnica del artículo 11, gestión de los datasets de entrenamiento conforme al artículo 10, supervisión de los logs de auditoría y coordinación con AESIA y la AEPD en caso de inspección. Estas responsabilidades pueden recaer en roles existentes ampliados o en un AI Governance Officer dedicado, dependiendo del tamaño y la complejidad de los sistemas de IA de la organización.

¿Cuántas personas necesita un equipo de Data Governance para ser efectivo?

No hay una cifra universal, pero la estructura mínima para una organización mediana con datos en cloud es: un Data Governance Lead a tiempo completo o parcial con mandato ejecutivo, un Data Steward por dominio crítico (entre dos y cinco según la organización) y al menos un perfil técnico de Data Engineering. El error más frecuente es intentar hacer todo con un solo perfil que acaba sin tiempo ni autoridad para nada. Más que el número de personas, lo que determina la efectividad es la claridad de las responsabilidades y la autoridad real de cada rol.