Gobierno del dato: de los pilares a la prueba

Lo esencial

• El gobierno del dato es el modelo operativo que fija quién decide, con arreglo a qué reglas, mediante qué procesos y sobre qué tecnología. En este punto coinciden todas las guías disponibles.
• Lo que ha cambiado es el resultado exigible. En cuanto entran sistemas de IA en el perímetro, el gobierno del dato debe producir pruebas documentales y no solo decisiones.
• El artículo 10 del Reglamento de IA impone ocho requisitos expresos a los conjuntos de datos de entrenamiento, validación y prueba.
• DAMA-DMBOK, DCAM, DGI y COBIT son anteriores a la regulación de los datos de entrenamiento. Siguen sirviendo de armazón, pero ninguno indica qué hay que archivar.
• Una sola comprobación resulta decisiva: ¿puede su organización presentar, para cualquier modelo en producción, una ficha del conjunto de datos, un registro de trazabilidad y un informe de examen de sesgos?

Qué es realmente el gobierno del dato

El gobierno del dato es el modelo operativo que determina cómo una organización recoge, conserva, protege y utiliza su información. Se articula en cuatro componentes recurrentes: políticas y estándares que fijan las reglas, funciones y responsabilidades que sostienen la rendición de cuentas, procesos que convierten las reglas en rutina y tecnología que deja constancia de lo ocurrido. En el mercado hispanohablante conviven dos denominaciones para lo mismo, gobierno del dato y gobernanza de datos, y el contenido no varía.

Ese consenso es correcto pero incompleto, porque describe una estructura de decisión y apenas dice nada sobre lo que esa estructura debe producir. Durante veinte años la omisión tuvo escaso alcance, ya que el destinatario del modelo era la propia organización: un cuadro de mando de calidad, un comité de dirección y un catálogo pensado para los analistas.

Esa etapa ha terminado. Cuando los datos alimentan un sistema de IA, el destinatario de su gobierno del dato puede ser un organismo notificado, una autoridad de vigilancia del mercado o un cliente corporativo que ejecuta su diligencia debida sobre proveedores. Esos lectores no aceptan un modelo operativo como respuesta: piden documentos. Un dispositivo incapaz de aportarlos constituye un relato de cumplimiento, que es cosa distinta. El asunto se inscribe en la cuestión más amplia de la gobernanza de la IA entendida como disciplina operativa.

Gobierno del dato y gestión de datos

La distinción es más sencilla de lo que sugieren la mayoría de las guías. La gestión de datos corresponde a la ejecución: flujos, almacenamiento, reglas de calidad, datos maestros, integración. El gobierno del dato constituye la capa de autoridad situada por encima: quién está facultado para decidir, cuál es el estándar aplicable y cómo demuestra la organización que dicho estándar se ha cumplido.

Una fórmula útil para retener la diferencia consiste en decir que la gestión responde al cómo, mientras que el gobierno responde a quién lo dispuso y dónde consta la prueba. Quien solo produce documentación de procesos ha descrito gestión y la ha llamado gobierno.

Los cuatro modelos de referencia y su propósito original

Todas las publicaciones sobre la materia citan la misma lista. No son modelos rivales: fueron concebidos para cometidos distintos.

Modelo	Origen	Propósito	Uso recomendado
DAMA-DMBOK	DAMA International	Definir la práctica de gestión de datos en once áreas de conocimiento	Como referencia de práctica y vocabulario
DCAM	EDM Council	Medir la madurez de las capacidades frente a un patrón	Como instrumento de evaluación
Marco DGI	Data Governance Institute	Diseñar derechos de decisión y cadenas de responsabilidad	Como capa organizativa
COBIT	ISACA	Gobernar el sistema de información y el riesgo tecnológico	Como vocabulario de auditoría y control

La combinación más extendida en 2026 consiste en emparejarlos: DAMA-DMBOK define la buena práctica y DCAM mide la distancia que separa de ella. La versión 3.0 del DMBOK, en elaboración, amplía su alcance a la gestión de datos para aprendizaje automático, lo que señala con claridad la dirección del sector.

Por qué ninguno se escribió para sistemas de IA

Los cuatro fueron concebidos para gobernar el dato como activo de la organización. Ninguno fue concebido para gobernarlo como componente de un producto regulado. El desplazamiento no es cosmético.

En la lógica del activo, la pregunta dirigida a un conjunto de datos versa sobre su exactitud, su localización, su seguridad y su titularidad. En la lógica del producto la pregunta cambia: ¿fue ese conjunto de entrenamiento concreto pertinente y suficientemente representativo respecto de la finalidad para la que el modelo se introdujo en el mercado, y puede usted acreditarlo? Un gobierno del dato construido sobre la lógica del activo responderá sin dificultad a la primera pregunta y de ningún modo a la segunda.

Qué cambia cuando la IA entra en el patrimonio de información

Se producen tres cambios simultáneos.

En primer lugar, los datos de entrenamiento, validación y prueba pasan a ser un objeto regulado con criterios de calidad fijados por ley. Dejan de ser meras entradas analíticas para convertirse en el fundamento probatorio de una afirmación de conformidad sobre un producto.

En segundo lugar, cada conjunto adquiere un responsable que debe responder de la representatividad y no solo de la exactitud. Son propiedades distintas: un conjunto puede ser impecablemente exacto respecto de la población equivocada.

En tercer lugar, el inventario sobre el que descansa su gobierno del dato deja de ser fiable. El modelo presupone que se sabe qué sistemas consumen qué datos, y las herramientas no declaradas quiebran ese presupuesto en silencio: por eso la shadow AI es antes un problema de datos que un problema de seguridad. Si un equipo vuelca fichas de clientes en un asistente no autorizado, ningún registro anota ese flujo y ninguna política ha llegado a aplicarse.

Artículo 10 del Reglamento de IA: las obligaciones que hay que satisfacer

El artículo 10 es la disposición que convierte el gobierno del dato de buena práctica en obligación jurídica para los sistemas de IA de alto riesgo. Conforme al artículo 10, apartado 1, los sistemas de alto riesgo desarrollados mediante técnicas de entrenamiento deben basarse en conjuntos de datos de entrenamiento, validación y prueba que cumplan los criterios de calidad enunciados en el precepto.

El apartado 2 exige que dichos conjuntos se sometan a prácticas de gobernanza y gestión adecuadas a la finalidad prevista y enumera ocho extremos que deben cubrirse. Leídos como pliego de condiciones, obligan a documentar:

1. Las decisiones de diseño, formalizadas en lugar de presupuestas.
2. Los procesos de recogida y el origen de los datos y, en el caso de datos personales, la finalidad original de la recogida.
3. Las operaciones de preparación: anotación, etiquetado, depuración, actualización, enriquecimiento y agregación.
4. Las hipótesis sobre lo que los datos deben medir y representar.
5. La evaluación de disponibilidad, cantidad e idoneidad de los conjuntos necesarios.
6. El examen de sesgos que puedan afectar a la salud, la seguridad o los derechos fundamentales, incluidos los efectos discriminatorios.
7. Las medidas adecuadas de detección, prevención y mitigación de esos sesgos.
8. La identificación de lagunas o deficiencias que impidan el cumplimiento y el modo de subsanarlas.

El apartado 3 fija el listón de calidad: los conjuntos deben ser pertinentes, suficientemente representativos y, en la medida de lo posible, carecer de errores y estar completos en atención a la finalidad prevista, con propiedades estadísticas adecuadas a las poblaciones afectadas. El apartado 4 obliga a tener en cuenta las características propias del entorno geográfico, contextual, conductual o funcional de uso. Un modelo de selección de personal validado en un mercado laboral nacional no arrastra esa validación al cruzar una frontera.

El apartado 5 contiene una autorización estrecha y con frecuencia mal leída: el proveedor puede tratar excepcionalmente categorías especiales de datos personales cuando ello sea estrictamente necesario para detectar y corregir sesgos, con sujeción a garantías adecuadas y solo cuando otros datos no permitan cumplir esa finalidad. Se trata de una excepción acotada y no de una licencia para recoger atributos sensibles de forma rutinaria, en línea con el principio de minimización que la AEPD ha venido recordando de manera constante. El apartado 6 cierra el cuadro para los sistemas que no aprenden de datos, respecto de los cuales solo rigen los conjuntos de prueba. La arquitectura completa de estas obligaciones se detalla en nuestra guía operativa del Reglamento de IA.

El anexo IV y el deber de ficha descriptiva

El artículo 10 dice cómo deben ser los datos. El anexo IV dice qué debe constar por escrito. El punto 2, letra d), del anexo IV exige que la documentación técnica incluya, cuando proceda, fichas que describan las metodologías y técnicas de entrenamiento y los conjuntos de datos utilizados: descripción general, procedencia, alcance y características principales, forma de obtención y selección de los datos, procedimientos de etiquetado y metodologías de depuración. El punto 2, letra g), extiende la misma disciplina a los datos de validación y prueba y a las métricas de exactitud y solidez.

Es esta frase la que altera la naturaleza del trabajo exigido. La trazabilidad deja de ser una comodidad para los analistas y pasa a ser un entregable documental con formato prescrito. La referencia académica subyacente es el trabajo de Gebru y colegas, Datasheets for Datasets, que proponía exactamente esa forma: motivación, composición, proceso de recogida, preprocesamiento, usos, distribución y mantenimiento. Nuestra guía sobre documentación de sistemas de IA cubre el resto del expediente.

Qué debe el responsable del despliegue conforme al artículo 26, apartado 4

La literatura sobre la materia se dirige casi siempre al titular de los datos. El Reglamento vincula también a la organización que se limita a adquirir el sistema. Conforme al artículo 26, apartado 4, el responsable del despliegue que ejerza control sobre los datos de entrada debe velar por que esos datos sean pertinentes y suficientemente representativos en atención a la finalidad prevista del sistema de alto riesgo. El apartado 6 impone conservar los registros generados automáticamente durante seis meses como mínimo.

De modo que, si explota bajo licencia un modelo de scoring y lo alimenta con sus propios expedientes, su gobierno del dato soporta una obligación legal sobre esos expedientes. Comprar el modelo no externaliza el deber sobre el dato.

Alinear los pilares con la ISO 42001 y el NIST AI RMF

La maniobra útil no consiste en sustituir el dispositivo existente, sino en redefinir lo que cada pilar debe entregar. La tabla siguiente ofrece la versión condensada.

Pilar clásico	ISO/IEC 42001 anexo A	NIST AI RMF	Documento a producir
Políticas y estándares	A.7.2 datos para el desarrollo, A.7.4 calidad de los datos	MAP 2.3	Criterios de calidad escritos por finalidad
Funciones y responsabilidades	A.7.3 adquisición de datos	MAP 4.1, MAP 4.2	Responsable nombrado y revisión de datos de terceros
Procesos	A.7.6 preparación de datos	MAP 2.3	Protocolo de etiquetado e informe de sesgos
Tecnología	A.7.5 procedencia de los datos	MEASURE 2.2	Trazabilidad del origen a la entrada del modelo

La norma ISO/IEC 42001 reúne sus requisitos sobre datos en el control A.7 del anexo A, dedicado a los datos para sistemas de IA y desglosado en A.7.2 datos para el desarrollo y la mejora, A.7.3 adquisición de datos, A.7.4 calidad de los datos, A.7.5 procedencia de los datos y A.7.6 preparación de datos. Quien aspire a certificarse trabajará contra esa lista, que engrana con el artículo 10 sin duplicarlo. Hemos explicado en otro lugar por qué la ISO 42001 por sí sola no produce conformidad con el Reglamento.

El NIST AI RMF aporta en cambio un vocabulario de riesgo y no una meta de certificación. La subcategoría MAP 2.3 aborda la integridad científica y las actividades de prueba, evaluación, verificación y validación, e incluye expresamente el diseño experimental y la recogida y selección de datos. Las subcategorías MAP 4.1 y 4.2 se refieren al riesgo derivado de datos de terceros y al deber de revisar el material obtenido del exterior desde la perspectiva del sesgo, la privacidad y la seguridad antes de autorizarlo. Este último punto gana peso cada año, dado que la mayoría de las organizaciones entrena ya sobre datos que no ha recogido. El cruce completo entre marcos figura en nuestra comparación de NIST AI RMF, ISO 42001, Reglamento de IA y principios de la OCDE.

La lista de documentos que hay que producir

Esta es la traducción operativa. Un gobierno del dato que cubra sistemas de IA debe poder aportar, a requerimiento y por sistema, los nueve documentos siguientes.

1. Un registro de conjuntos de datos vinculado al inventario de sistemas de IA, de modo que todo modelo pueda referirse a los datos que consumió.
2. Una ficha descriptiva por cada conjunto de entrenamiento, validación y prueba, con el formato del anexo IV.
3. Un registro de trazabilidad desde el sistema de origen hasta la entrada del modelo, transformaciones incluidas.
4. Un informe de examen de sesgos que precise las características protegidas examinadas y el método empleado.
5. Un registro de decisiones de mitigación, incluidas las decisiones de aceptar un sesgo residual y quién las adoptó.
6. Un registro de lagunas y deficiencias con responsables y plazos, que da cuerpo a la letra h) del apartado 2.
7. Un protocolo de anotación, con medida de concordancia entre anotadores cuando las etiquetas admitan juicio.
8. Un registro de conservación y base jurídica, enlazado con la evaluación de impacto en protección de datos cuando haya datos personales.
9. Una aprobación nominativa por versión del conjunto, ya que un documento sin firma es una afirmación y no un control.

Los puntos cuatro y cinco son los más débiles en la mayoría de los programas y los primeros que un auditor reclama. Nuestra guía sobre sesgo de la IA detalla los métodos de examen.

El registro de elementos de dato críticos, extendido a la IA

Las entidades reguladas ya mantienen un registro de elementos de dato críticos. No necesita usted un segundo registro, sino una clave ajena.

Añada una relación entre cada elemento crítico y los sistemas de IA que lo consumen y el registro dejará de ser un artefacto de calidad para responder a preguntas de cumplimiento: qué modelos se ven afectados si ese elemento se degrada, qué conjuntos heredaron sus defectos conocidos y a qué responsables de modelo hay que avisar cuando su definición cambia. Esa única unión convierte trabajo ya realizado en prueba regulatoria a coste marginal, y es la modificación de mayor rendimiento sobre un dispositivo existente.

Un despliegue en noventa días

Una secuencia realista para una organización que ya cuenta con gobierno del dato y debe extenderlo a la IA.

1. Semanas 1 y 2, alcance y desencadenante jurídico. Determine qué sistemas son de alto riesgo, cuáles son modelos de uso general que usted solo despliega y cuáles quedan fuera. Las obligaciones difieren de forma acusada y los errores de calificación se pagan después.
2. Semanas 3 y 4, inventario. Relacione los sistemas de IA y los conjuntos que cada uno consume. Cuente con una lista incompleta en la primera pasada y programe un barrido de herramientas no declaradas.
3. Semana 5, clasificación. Etiquete cada conjunto por sensibilidad, base jurídica, origen (interno, de terceros, sintético, extraído de la web) y carácter de entrenamiento, validación o prueba.
4. Semana 6, responsabilidades. Asigne un responsable nombrado por conjunto. Una persona, no un equipo: una responsabilidad compartida es una responsabilidad ausente.
5. Semanas 7 a 9, documentación. Redacte las fichas con el formato del anexo IV y empiece por el sistema más expuesto, porque ahí es donde el formato se somete a prueba real.
6. Semanas 10 y 11, prueba de representatividad. Compare las propiedades estadísticas de los conjuntos con la población destinataria y el entorno de despliegue. Deje constancia de las desviaciones halladas en lugar de corregirlas en silencio.
7. Semana 12, aprobación y cadencia. Obtenga la aprobación nominativa y fije el disparador de revisión, vinculándolo a los reentrenamientos y no al calendario.

Es precisamente en la cadencia donde más programas fallan. Si su marco de gobernanza de la IA revisa los datos una vez al año mientras los modelos se reentrenan cada semana, la documentación describe un sistema que ya no existe.

Los cinco fallos recurrentes

La madurez de fachada. El programa se autoevalúa frente a un modelo de capacidades y comunica avances sin prueba alguna detrás de la puntuación. La declaración de la dirección no constituye evidencia.

La herramienta antes que la regla. Se adquiere un catálogo antes de haber escrito la política que debería aplicar. La herramienta acaba codificando las convenciones de quien la configuró.

La ausencia de responsable de los datos de entrenamiento. Los sistemas de origen tienen titular. El conjunto derivado, compuesto a partir de cuatro de ellos, filtrado, reetiquetado y congelado para una versión del modelo, no suele tener ninguno.

Registros nunca unidos. El catálogo de datos y el inventario de sistemas de IA residen en herramientas distintas mantenidas por equipos distintos, de manera que ninguna consulta puede establecer qué modelo usó qué datos. Es la causa más frecuente de que una auditoría no encuentre nada aprovechable.

Alcance detenido en el dato personal. Los programas de protección de datos cubren bien lo personal. El artículo 10 abarca la totalidad de los datos de entrenamiento, incluidos los operativos, los de sensores y los sintéticos sin componente personal alguno.

Preguntas frecuentes

¿Cuáles son los cuatro pilares del gobierno del dato?

Políticas y estándares, funciones y responsabilidades, procesos y tecnología. Algunos proveedores los desglosan en cinco, siete o diez componentes, pero las adiciones son subdivisiones y no categorías nuevas: calidad, gestión de metadatos y trazabilidad se sitúan dentro de procesos y tecnología. Cuando intervienen sistemas de IA conviene tratar como obligatorio un quinto elemento que rara vez se enumera: las pruebas producidas, es decir, las fichas, los registros de trazabilidad y los informes de sesgo que una autoridad pueda leer efectivamente.

¿Cuáles son los principios clave?

Rendición de cuentas con responsable nombrado por conjunto, transparencia sobre origen y transformaciones, calidad definida frente a una finalidad declarada y no en abstracto, protección proporcionada a la sensibilidad y a la base jurídica, y trazabilidad del origen al consumo. Bajo el Reglamento de IA, la calidad y la trazabilidad pesan más, ya que el artículo 10, apartado 3, plantea un criterio referido a la finalidad y no una exigencia general.

¿Qué diferencia hay entre gobierno del dato y gobernanza de la IA?

El primero gobierna el dato. La segunda gobierna los sistemas construidos sobre él, junto con los modelos, las decisiones de despliegue, la supervisión humana y la gestión de incidentes. Se solapan en un solo punto, los datos de entrenamiento, y es exactamente ahí donde el Reglamento sitúa sus obligaciones documentales más pesadas. En la práctica ambos deben compartir inventario y taxonomía de riesgo, conservando responsables y cadencias de revisión separados.

¿Qué modelo adoptar: DAMA-DMBOK, DCAM o DGI?

Rara vez hace falta elegir en exclusiva. DAMA-DMBOK aporta definición de práctica y vocabulario, DCAM la medida de madurez y DGI el diseño de los derechos de decisión. El patrón habitual combina el primero para la práctica y el segundo para medir el avance. Si hay sistemas de IA en alcance, ninguno de los tres basta por sí solo, puesto que ninguno especifica los documentos exigidos por el anexo IV: procede superponer el anexo A.7 de la ISO/IEC 42001.

¿Exige el Reglamento de IA un gobierno del dato?

Para los sistemas de alto riesgo, en la práctica sí. El artículo 10, apartado 2, exige que los conjuntos de entrenamiento, validación y prueba se sometan a prácticas adecuadas de gobernanza y gestión, y enumera después ocho extremos que deben cubrirse. El texto no designa marco alguno ni impone un modelo concreto, de modo que un dispositivo existente y adaptado puede bastar. Lo que sí impone es el resultado documental, por la vía del anexo IV.

¿A quién corresponde la titularidad?

Suele corresponder al director de datos o a una figura equivalente, con un órgano de dirección para las decisiones transversales. Más que el título importan dos condiciones: que la responsabilidad sobre cada conjunto sea personal y que quien la ostenta pueda bloquear una puesta en producción. Cuando hay sistemas de IA implicados, el responsable del gobierno del dato y el de la gobernanza de la IA han de decidir conjuntamente sobre los datos de entrenamiento, porque ninguno de los dos puede aprobar en solitario.

Conclusión

Las publicaciones disponibles le dirán que el gobierno del dato descansa sobre cuatro pilares y que conviene escoger un marco. Es cierto, y ahí se detiene la mayor parte del consejo. La pregunta difícil es otra: qué entrega usted cuando alguien ajeno a su organización pregunta cómo se compuso el conjunto de entrenamiento de un modelo, si representaba a las personas sobre las que iba a aplicarse y quién lo aprobó.

Si hoy la respuesta honesta se limita a una política y a una captura del catálogo, la debilidad no está en los pilares, sino en los documentos que nunca se les pidió producir. Empiece por el registro de conjuntos vinculado al inventario de sistemas de IA: el resto de la cadena probatoria encontrará dónde anclarse.

Descubra cómo AI Sigil convierte las obligaciones de gobierno del dato en pruebas oponibles.