Glosario de gobierno de datos

"Los datos son un activo" es la frase más repetida del sector y normalmente la más vacía. Solo significa algo cuando cambia una decisión, y la prueba es la misma que aplicarías a un edificio o a una flota: un activo tiene un dueño, un valor registrado, un coste de mantenimiento y un ciclo de vida que termina. Una tabla que no es de nadie, que nadie sabe valorar y que nadie va a borrar nunca no es un activo. Es almacenamiento. El DMBOK define el gobierno como autoridad sobre la gestión de los activos de datos, así que la palabra hace trabajo real en esa definición.

En la práctica. Empieza por los diez conjuntos de datos que alimentan el reporting de dirección y responde cuatro preguntas para cada uno: de quién es, cuánto vale, cuánto nos cuesta cuando está mal y cuándo desaparece. Registra las respuestas en el inventario o el catálogo. La medida útil es el porcentaje de activos que tienen a la vez dueño y definición aprobada, y cómo evoluciona.

Dónde se rompe. Un rastreador llena el catálogo con todas las tablas del patrimonio, y todo lo que encontró pasa a llamarse activo. Nadie sabe qué porcentaje tiene dueño. Mientras tanto no se retira nada, porque borrar da miedo y conservar no tiene un coste visible. Un registro de activos que solo crece es un inventario de pasivos.

Un comité existe para que el gobierno tenga de dónde sacar autoridad. Los dueños de datos pueden acordar qué es un cliente y quién aprueba el acceso, pero no pueden aprobar un presupuesto, asumir un riesgo regulatorio en nombre de la compañía ni decirle a otro directivo que su proyecto se retrasa porque sus datos no están listos. Por eso la sala es más amplia que el equipo de datos: el patrocinador de nivel C que responde por la cuenta de resultados, el delegado de protección de datos, el director de ciberseguridad y, normalmente, legal, auditoría interna y los dueños de los dominios que están en la agenda.

En la práctica. Se reúne trimestralmente, no cada mes, porque decide cosas más grandes y menos numerosas que un consejo: el cuerpo de políticas, la financiación, el apetito de riesgo, los dominios prioritarios y las escaladas que el consejo no pudo cerrar. Cada punto llega con una recomendación y sale con un nombre asignado. El DPO y el responsable de seguridad son miembros, no revisores: eso es lo que evita que una objeción de privacidad aparezca tres semanas después de una decisión ya tomada.

Dónde se rompe. Solo asiste gente de datos. Un comité formado por el CDO, dos analistas y un consultor puede recomendar cualquier cosa y financiar ninguna, y en dos reuniones se convierte en un seguimiento de proyecto con título ejecutivo. El fallo contrario es igual de común: treinta invitados, cincuenta diapositivas y un registro de decisiones vacío desde el kickoff.

El Data Management Body of Knowledge es lo más parecido a un libro de texto compartido que tiene la profesión. Define once áreas de conocimiento —gobierno, arquitectura, modelado, almacenamiento y operaciones, seguridad, integración e interoperabilidad, documentos y contenido, datos maestros y de referencia, data warehousing e inteligencia de negocio, metadatos y calidad de datos— y las dibuja como una rueda con el gobierno en el centro. Es un marco de referencia de verdad, y muy completo. La crítica habitual es que resulta muy teórico: te dice qué existe y para qué sirve cada parte, pero no es nada obvio cómo aplicarlo en tu propia empresa, y la secuencia queda en tus manos.

En la práctica. Su función más útil es como mapa de brechas. Contrasta un programa con las once áreas y las dos o tres que nadie posee se vuelven visibles de inmediato, lo cual suele ser más informativo que cualquier puntuación de madurez. También zanja discusiones sobre palabras, y por eso la certificación CDMP se construye sobre él.

Dónde se rompe. Los equipos toman la rueda como si fuera un plan e intentan levantar once capacidades a la vez. La rueda es un mapa del territorio, no una ruta por él. Un primer año que hace bien gobierno, metadatos y calidad en un solo dominio vale más que un primer año que abre once frentes y no cierra ninguno.

Si una política dice "los datos de contacto del cliente deben ser utilizables", el estándar dice qué significa utilizable: el correo cumple un formato válido, el código de país es ISO 3166-1 alfa-2, el teléfono se almacena en E.164, la dirección se valida contra el fichero postal de referencia. Un estándar se escribe para que lo compruebe una máquina. Ahí está la diferencia con una política: una política es un compromiso, un estándar es una especificación.

En la práctica. Los estándares son el punto donde el gobierno deja de ser abstracto, porque cada uno puede convertirse en una regla de calidad con un umbral y un panel. La secuencia útil es corta: nombra el elemento de datos crítico, escribe su estándar, impleméntalo como regla, informa de la tasa de incumplimiento.

Dónde se rompe. Se escriben estándares para todo en lugar de para lo que importa, lo que produce un documento que nadie puede implementar y un backlog que nadie va a financiar. Veinte estándares que cubren los campos que aparecen en el reporting regulatorio y en los paneles de dirección valen más que doscientos que cubren cada columna del almacén.

La gestión de datos es el trabajo de ejecución: modelar, integrar, almacenar, proteger, mover, archivar y finalmente eliminar datos. Es lo que hacen los ingenieros de datos, los DBA, los arquitectos y los analistas. El gobierno decide las reglas; la gestión construye y opera dentro de ellas. El DAMA-DMBOK coloca el gobierno como el eje central de once disciplinas de gestión precisamente para evitar que se confundan.

En la práctica. La diferencia se ve mejor en una sola petición. "El correo del cliente nunca debe estar vacío" es una decisión de gobierno: alguien con autoridad sobre el dominio de cliente la declaró. Añadir la restricción NOT NULL, corregir las 40.000 filas que la incumplen y vigilar los nuevos incumplimientos es gestión de datos.

Dónde se rompe. Las organizaciones contratan gestión de datos y la llaman gobierno. La plataforma se construye, los pipelines corren, y nadie ha decidido qué significan los números, así que el mismo campo se carga de tres formas para tres consumidores que creían cada uno que la suya era la definición. El fallo inverso es más silencioso e igual de frecuente: una función de gobierno que produce políticas que ningún equipo de ingeniería tuvo nunca presupuesto para implementar.

El gobierno de datos es el ejercicio de autoridad y control sobre la gestión de los datos. No gestiona los datos: decide quién los gestiona, qué está autorizado a decidir, qué reglas debe seguir y quién responde cuando algo sale mal. Todo lo demás que la gente llama gobierno —un catálogo, un panel de calidad, un foro de stewards— es o un instrumento para tomar esas decisiones o la evidencia de que se tomaron.

En la práctica. Se parece a una lista corta de personas con nombre y apellido, cada una con decisiones concretas asociadas. Quién aprueba un cambio en la definición de "cliente activo". Quién autoriza que un dataset salga del dominio de finanzas. A quién se llama cuando un informe y un sistema no coinciden. Cuando un programa de gobierno funciona, esa lista está escrita, está al día y la conocen las personas a las que obliga.

Dónde se rompe. El gobierno se compra como herramienta y se dota como comité, y ninguna de las dos cosas crea un derecho de decisión. Un catálogo sin dueño registrado junto a cada término es un directorio; un consejo sin autoridad es una reunión. Si nadie puede señalar una decisión que el programa haya tomado de verdad en el último trimestre, todavía no hay gobierno: solo su documentación.

Un marco es la lista de piezas del gobierno de datos. Casi todos se reducen a cuatro componentes: roles y responsabilidades (dueños, stewards, custodios), políticas y estándares, órganos de decisión como un consejo, y una supervisión que mide si algo de todo eso está ocurriendo. Los marcos de referencia como DAMA-DMBOK y DCAM describen cómo es hacerlo bien en toda la disciplina. El tuyo es la versión de esa estructura que has decidido construir. No es el modelo operativo, que dice quién ocupa cada pieza en tu organización y cómo circulan de verdad las decisiones.

En la práctica. Toma prestado el vocabulario pronto y el alcance tarde. Usar las palabras estándar para dueño, steward y elemento de datos crítico no cuesta nada y zanja toda una categoría de discusiones. Secuenciar es otra cosa: un marco presenta sus áreas como iguales, y el orden en que las construyes debería salir de dónde vienen tus escalados, no del orden de los capítulos.

Dónde se rompe. El diagrama del marco se convierte en el entregable. Recibe una diapositiva, un acta de constitución y un lanzamiento, y cada caja está ocupada por un rol que no tiene nadie. Un marco dice qué contiene un programa completo. Mientras las cajas no tengan nombres dentro, no se ha gobernado nada.

Una política de datos enuncia un requisito y nombra a quién le corresponde cumplirlo. "Los datos personales no se conservan más tiempo del que exige la finalidad para la que se recogieron." "Todo elemento de datos crítico tiene un dueño con nombre." Las políticas son deliberadamente pocas, deliberadamente cortas y deliberadamente aburridas: son la capa que no cambia cuando cambia la herramienta. El detalle de cómo cumplirlas va en un estándar o en un procedimiento por debajo.

En la práctica. Un conjunto de políticas viable para una organización mediana ocupa entre cinco y diez páginas en total, con cada política en una sola página, con dueño, fecha de aprobación y fecha de revisión. Si no se puede leer en una tarde por alguien a quien aplica, no se va a leer.

Dónde se rompe. Dos formas de fallar, ambas mortales. La primera es la política de cuarenta páginas escrita para satisfacer a un auditor, que nadie lee y que por tanto no gobierna nada. La segunda es una política aprobada por el equipo de datos y no por el área de negocio a la que obliga: en el momento en que le cuesta un plazo a alguien, se descubre que nunca tuvo autoridad detrás.

Un programa es la forma en que el gobierno de datos llega a una organización: un patrocinador ejecutivo, un alcance, personas con nombre y tiempo acordado, y un plan para los próximos dos trimestres. El primero es más pequeño de lo que casi todo el mundo espera. Se apoya en seis cimientos: tratar los datos como un activo de una manera que cambie decisiones, dividir el patrimonio en dominios, nombrar dueños y stewards, escribir un conjunto de políticas lo bastante corto como para leerlo, mantener un inventario sencillo y arreglar un poco de calidad de datos donde la gente lo vea. Nada de eso exige una plataforma.

En la práctica. Dos dominios, dueños y stewards con nombre, cinco políticas, una hoja de cálculo, tres atributos medidos. Eso es un primer trimestre completo, y el orden importa: dominios antes que roles, roles antes que políticas, políticas antes que catálogo, catálogo antes que medición. Consigue que el jefe de cada steward acepte el tiempo por escrito, porque un trabajo diario con plazos gana siempre a un gobierno sin ellos.

Dónde se rompe. El programa se gestiona como un proyecto con fecha de fin. Hay un acta de constitución, una ráfaga de actividad y un informe de cierre, y el problema original sigue intacto: once políticas aprobadas y dos departamentos que siguen llevando cifras de ingresos distintas a la misma reunión. El gobierno se comporta como una operación. El programa lo arranca; después del lanzamiento, algo permanente tiene que sostenerlo.

Un consejo existe para el conflicto entre dominios. Dos áreas quieren definiciones incompatibles de la misma entidad; una política le costaría a un departamento el roadmap del trimestre; un dominio quiere exponer datos sobre los que otro dominio está regulado. Eso no se resuelve dentro de un dominio, y escalar cada caso a un comité ejecutivo no escala. El consejo es el lugar permanente donde se resuelven, por las personas responsables de los dominios implicados.

En la práctica. Un consejo que funciona es pequeño —los dueños de datos, presidido por alguien con peso ejecutivo—, se reúne mensualmente y trabaja sobre una cola de decisiones concretas con una respuesta propuesta adjunta. El acta registra qué se decidió y quién lo decidió, y eso es lo que lo convierte en autoridad y no en conversación.

Dónde se rompe. El consejo se convierte en una reunión de seguimiento. Veinte asistentes, una presentación, una ronda de novedades, ninguna decisión, y en dos trimestres los dueños mandan delegados en lugar de asistir. La prueba fiable: si el orden del día no contiene la palabra "aprobar", cancela la reunión y escribe un correo.

Un steward es la mitad operativa de la propiedad. Escribe y mantiene las definiciones del glosario de negocio, traduce la política en reglas, clasifica las incidencias de calidad y es la primera llamada cuando un número parece equivocado. Se elige por conocimiento, no por jerarquía: normalmente es la persona a la que el resto del equipo ya preguntaba, de manera informal, antes de que existiera el rol. Los mejores stewards ya hacían casi todo el trabajo sin cobrarlo y sin documentarlo.

En la práctica. El stewardship es un porcentaje declarado de un puesto real, no un título añadido a una carga de trabajo completa. Entre un diez y un veinte por ciento, protegido y con el respaldo del dueño, es la diferencia entre una red de stewards que funciona y una que deja de reunirse sin ruido a los cuatro meses.

Dónde se rompe. Se nombran stewards en bloque, se les da una plantilla y ningún tiempo, y se les pide documentar todo. No se documenta nada, y el programa concluye que el negocio no está comprometido. La capacidad de stewardship es lo que con más frecuencia queda sin recursos en un programa de gobierno, y lo más fácil de corregir.

Los derechos de decisión son la sustancia del gobierno. No "el consejo gobierna los datos de cliente", sino: quién aprueba un atributo nuevo de cliente, quién aprueba un cambio en una definición existente, quién concede acceso fuera del dominio, quién acepta una tolerancia de calidad, quién declara una incidencia. Cada una es una decisión distinta con un decisor distinto, y escribirlas suele ser la semana de mayor valor que invierte un programa de gobierno.

En la práctica. Basta con una tabla de una página: la decisión en las filas, el rol en las columnas, una sola A por fila. La restricción que la hace útil es que cada fila tenga exactamente un responsable. Dos A en una fila es una discusión sin resolver escrita como si fuera un diseño.

Dónde se rompe. Los derechos de decisión se documentan como un RACI sobre actividades y no sobre decisiones, lo que produce una matriz donde todos son consultados sobre todo y nada va más rápido. El otro fallo es publicar la tabla sin avisar a nadie de que su nombre está en ella.

Un dueño de datos tiene suficiente peso para que sus decisiones se sostengan. Aprueba definiciones, autoriza accesos, acepta o rechaza tolerancias de calidad y asume la consecuencia cuando los datos de su dominio fallan a alguien más abajo. La propiedad es responsabilidad, no custodia: el dueño rara vez toca los datos y casi nunca los arregla en persona. Lo que distingue a un dueño real de uno nominal es que puede decir no a una petición de otra área y que se le respete.

En la práctica. La propiedad recae en el líder de negocio cuyos objetivos dependen más del dominio: comercial para cliente, operaciones para producto, RRHH para empleado. Es una persona con nombre, nunca un equipo y nunca un comité, y aparece en sus objetivos y no en una diapositiva.

Dónde se rompe. La propiedad se asigna a TI, que tiene la custodia pero no la autoridad sobre el significado, o se reparte en un "grupo de trabajo", lo que significa que la próxima definición en disputa no tiene quién la resuelva. El síntoma más claro es una petición de cambio de definición que circula durante seis semanas: eso no es un proceso lento, es un dueño ausente.

El stewardship es el mecanismo que convierte la autoridad en efecto. Un consejo puede decidir que "ingresos" tiene una sola definición; el stewardship es lo que encuentra los cuatro sistemas donde se calcula de forma distinta, consigue cambiar tres y documenta el cuarto como excepción conocida. Como disciplina es poco lucida: mantener un glosario, perseguir una incidencia entre dos equipos, explicar la misma definición a un analista nuevo por quinta vez.

En la práctica. Un modelo de stewardship nombra, por dominio, quién es el dueño, quiénes son los stewards, cómo se propone y aprueba un cambio de definición y dónde se registran las incidencias. Escrito, eso son dos páginas, y esas dos páginas son el modelo operativo que a la mayoría de los programas les falta.

Dónde se rompe. El stewardship se trata como trabajo de documentación y se mide por número de términos en el glosario. El número de términos es una métrica de vanidad: un glosario de 900 términos que nadie consulta vale menos que 40 términos que el equipo de reporting usa de verdad. Mide uso y resolución, no volumen.

Un catálogo es un buscador de tus propios datos. Responde a las dos preguntas que de otro modo consumen el tiempo de los analistas —¿ya existe un conjunto de datos para esto? y ¿puedo confiar en él?— poniendo la estructura técnica, las definiciones de negocio y la propiedad en un mismo sitio. La mayoría de catálogos puede recolectar la estructura automáticamente de almacenes, herramientas de BI y pipelines; ninguno puede aportar el significado, y por eso un catálogo es un proyecto de gobierno disfrazado de presupuesto de herramienta.

En la práctica. La adopción de un catálogo se sigue con un solo número: el porcentaje de los activos que la gente busca de verdad que tienen dueño y definición. Poblar bien los 200 activos principales vale más que poblar 20.000 en vacío, y es la versión que se usa dos veces.

Dónde se rompe. El catálogo se compra antes de que existan las definiciones y se despliega como el entregable del programa. Seis meses después contiene todas las columnas del parque, el 3 % tiene descripción y la organización concluye que los catálogos no funcionan. La herramienta funcionaba bien; no había nada que meter dentro.

La certificación es una promesa ligada a un activo concreto. Alguien responsable ha revisado la definición, el origen y la calidad, y pone su nombre. La insignia en el catálogo o en la herramienta de BI es lo que hace utilizable esa promesa. Permite decidir si confiar en un segundo en lugar de en una hora, y es lo que separa la cifra de margen gobernada de las cuatro versiones improvisadas que tiene al lado. Algunas organizaciones usan niveles, como oro para los datos aptos para decidir, en lugar de un simple sí o no.

En la práctica. Certifica pocas cosas que importen y publica los criterios: dueño, definición aprobada, calidad dentro de la tolerancia, consumidores conocidos. Trata la retirada también como una decisión, que toma el dueño de la métrica tras consultar a los consumidores registrados y con el uso reciente como evidencia. Mide si los activos certificados se reutilizan en lugar de reconstruirse, y si la gente sigue usándolos pasados los primeros 90 días.

Dónde se rompe. La certificación se concede una vez y nunca se revisa, así que la insignia sobrevive al dueño, a la definición y a los controles de calidad que la sostenían. El fallo contrario es pedir a la gente que prefiera los datos certificados antes de que exista ninguno. En ambos casos la insignia deja de significar algo y la gente vuelve a sus propias hojas de cálculo.

Los datos maestros son los que aparecen en todos los sistemas: el cliente que existe en el CRM, en facturación, en soporte y en el almacén, en cuatro versiones ligeramente distintas. El MDM es la práctica de resolverlas en un único registro con un identificador conocido, y de decidir qué sistema puede modificar qué atributo. Es trabajo técnico con un requisito previo de gobierno, porque las reglas de coincidencia y de supervivencia son decisiones de negocio disfrazadas de configuración.

En la práctica. Los proyectos de MDM funcionan cuando parten de un dolor concreto —clientes duplicados que inflan la tasa de churn, un proveedor pagado dos veces— y cubren una sola entidad. Fracasan cuando parten de la ambición de una vista única de cliente para toda la empresa.

Dónde se rompe. El umbral de coincidencia lo fija el equipo de implantación. Alguien tiene que decidir si fusionar dos registros con un 92 % de similitud es aceptable, y la consecuencia de una fusión errónea es un cliente viendo los datos de otro cliente. Esa es una decisión del dueño, y delegarla en una pantalla de configuración es como el MDM se convierte en un incidente de privacidad.

Un glosario de negocio responde a "qué significa esta palabra aquí". No en general, ni en el sector: aquí, en esta empresa, a efectos de reporting. Cada entrada tiene una definición, un dueño que la aprobó, el cálculo si es una métrica y, en el mejor caso, los sistemas e informes donde está implementada. El glosario es donde un programa de gobierno se vuelve visible por primera vez para quien está fuera de él, lo que hace que su calidad importe de forma desproporcionada.

En la práctica. Un glosario se gana su existencia la primera vez que zanja una discusión. Empieza por los veinte términos que aparecen en el reporting de dirección y que se sabe que están en disputa —churn, cliente activo, ingresos, plantilla, entrega a tiempo— y lleva cada uno a una única definición aprobada.

Dónde se rompe. El glosario se construye como ejercicio de exhaustividad, en una herramienta que nadie tiene en su flujo de trabajo diario, así que las definiciones se escriben una vez y nunca se consultan. Un glosario al que no se llega desde donde la gente trabaja —la herramienta de BI, el buscador de la intranet, el catálogo— es un documento, no un control.

La mayoría de los catálogos se diseñaron para ser rastreados: un escaneo corre el domingo por la noche y el miércoles el catálogo describe un almacén que ya no existe. La ingesta activa invierte eso. Cada ejecución de un pipeline, cada cambio de esquema, cada permiso concedido, cada prueba fallida y cada consulta a una tabla emiten un evento, y la plataforma de metadatos escucha en lugar de preguntar. Lo valioso no es tener documentación más fresca: es que un metadato que llega en segundos se puede accionar automáticamente, algo que el metadato pasivo nunca permitió.

En la práctica. Los conectores se suscriben a lo que la plataforma ya emite: logs de consultas, eventos del orquestador, flujos de CDC, ejecuciones de CI, cambios de IAM. El linaje se recalcula en cada ejecución en vez de deducirse del SQL una vez por trimestre, el uso y el coste salen del consumo real, y el bucle se cierra del lado operativo: una regla de calidad que falla abre un ticket al dueño con nombre, un cambio de esquema incompatible rompe la build del productor, una tabla sin uso aparece en su lista de baja y una columna nueva con pinta de dato personal se marca antes de que alguien la consulte.

Dónde se rompe. Se construye el flujo y no el bucle. Millones de eventos entran en un catálogo que nadie abre y la única diferencia con el escaneo semanal es la factura. La prueba es sencilla: ¿algún evento de metadatos cambia algo fuera del catálogo —una alerta, una revisión de accesos, un despliegue bloqueado? Si no, esto es un proyecto de documentación muy caro.

El linaje responde a dos preguntas que de otro modo son caras. Hacia arriba: este número parece incorrecto, ¿de dónde viene y qué lo ha tocado? Hacia abajo: vamos a cambiar este campo, ¿qué se rompe? La segunda es el análisis de impacto y, en organizaciones con algo de complejidad en sus pipelines, es la que paga todo el ejercicio: la alternativa es una congelación de cambios o un descubrimiento en producción.

En la práctica. El linaje merece capturarse con la granularidad sobre la que vas a actuar. El linaje tabla a tabla en los pipelines que sostienen los informes regulatorios suele bastar para responder a ambas preguntas; el linaje a nivel de columna en todo el parque es un proyecto de investigación.

Dónde se rompe. El linaje se dibuja a mano en una herramienta de diagramas. Es exacto el día en que se dibuja y está equivocado antes de acabar el sprint, y como parece autoritativo la gente se apoya en él después de que deje de ser cierto. Un linaje que no se deriva de los propios pipelines tiene una caducidad de semanas.

Los metadatos suelen dividirse en tres. Los metadatos de negocio son significado: la definición de "cliente activo", el dueño, la clasificación de sensibilidad. Los metadatos técnicos son estructura: tabla, columna, tipo, nulabilidad, el proceso que la carga. Los metadatos operativos son comportamiento: cuándo se ejecutó la última carga, cuántas filas llegaron, cuántas fallaron la validación. Un programa de gobierno necesita los tres, pero solo tiene presupuesto para empezar por uno.

En la práctica. Empieza por los metadatos de negocio de los datos que ya aparecen en decisiones, porque ahí es donde duele su ausencia: un analista que no puede distinguir cuál de dos columnas de ingresos es la que se publica pierde una hora a la semana en algo que una frase resolvería.

Dónde se rompe. Se recolectan metadatos en masa porque una herramienta puede hacerlo automáticamente, y el resultado es un catálogo con 40.000 entradas técnicas sin significado asociado. La recolección automática es la mitad barata. La mitad cara es que una persona decida qué significa cada cosa, y ninguna herramienta ha hecho nunca esa parte.

Un campo roto es un síntoma. La causa casi siempre está aguas arriba de la base de datos: un formulario que acepta texto libre, un traspaso entre equipos que nadie tiene asignado, una integración que trunca en silencio, un objetivo que premia rellenar cualquier cosa para cerrar el ticket. El análisis de causa raíz es la disciplina de preguntar por qué hasta llegar a algo que una persona o un cambio de proceso pueda corregir. Los 5 porqués son la herramienta habitual y el linaje es el mapa que se sigue. Es el paso Analizar de DMAIC, y el que convierte una limpieza en una mejora.

En la práctica. Empieza por los escalados, no por un marco. Saca un año de incidentes, tickets y hallazgos de auditoría y clasifícalos por causa; la mayoría de las organizaciones descubre que cuatro o cinco causas explican la mayor parte, y que al menos una se repite desde hace años sin dueño. Cada causa confirmada debería acabar en dos cosas: una corrección donde nace el defecto y una regla de calidad de datos que detecte la siguiente vez.

Dónde se rompe. El análisis se detiene en la primera respuesta técnica —"falló el proceso de ETL"—, que es donde la culpa es más fácil de colocar y menos útil. O dura un trimestre, produce un diagrama de causa y efecto precioso y no cambia ningún sistema. Un análisis que no cambia un proceso solo ha documentado el problema con más detalle.

No existe una calidad de datos absoluta. Una dirección de cliente que basta para enviar un correo de marketing no basta para entregar un palé, y el mismo registro puede ser a la vez aceptable e inservible según quién lo tome. Por eso "mejorar nuestra calidad de datos" no es accionable y "nuestros datos de dirección deben ser suficientes para entregar y hoy el 12 % no lo es" sí lo es.

En la práctica. El trabajo de calidad funciona en bucle: elige un uso que importe, define la regla que ese uso exige, mide la tasa de incumplimiento, corrige el proceso que la genera y sigue midiendo. El cuarto paso es el que cambia algo: limpiar sin arreglar el origen es una suscripción, no un proyecto.

Dónde se rompe. La calidad se mide contra todas las dimensiones para todos los campos y se comunica como una única puntuación. Un porcentaje compuesto no le dice a nadie qué hacer el lunes. Informa por regla y por dueño, nombra el proceso que produjo el incumplimiento, y la conversación pasa a ser resoluble.

El coste aparece en sitios que nadie etiqueta como datos: facturas rehechas, envíos no entregables, analistas conciliando dos informes a mano, gasto de marketing contra contactos duplicados, una redeclaración regulatoria. Cada uno es pequeño y cada uno tiene un responsable que ha dejado de verlo, y por eso el total es invisible hasta que alguien lo suma. Sumarlo suele ser lo más persuasivo que hace un programa de gobierno.

En la práctica. Cuantifica tres fallos concretos en lugar de estimar una cifra global. Horas × coste cargado × frecuencia, más el gasto directo. Tres números creíbles y defendibles de procesos que el negocio reconoce harán más por un caso de negocio que un porcentaje de referencia sobre los ingresos.

Dónde se rompe. La cifra se toma de un estudio de un proveedor —"los datos malos cuestan a las empresas entre el 15 % y el 25 % de sus ingresos"— y se presenta como el número de esta empresa. Un director financiero lo descarta en una frase, y la credibilidad no vuelve. Tus tres ejemplos propios, por modestos que sean, sobreviven a la pregunta "¿de dónde sale eso?".

El mismo cliente aparece tres veces con grafías ligeramente distintas, dos direcciones y un solo correo entre todas. La deduplicación encuentra esos registros, decide cuáles van juntos y los fusiona o los vincula para que el negocio cuente un cliente en lugar de tres. Lo difícil no es el algoritmo de coincidencia; es acordar qué hace que dos registros sean la misma entidad y qué versión de cada atributo sobrevive.

En la práctica. Perfila la tasa de duplicados sobre la clave natural de tu conjunto de datos más usado antes de elegir herramienta: el número defiende el caso por sí solo. Acuerda con el dueño de los datos las reglas de coincidencia y de supervivencia, ejecuta la deduplicación como rutina recurrente y no como limpieza puntual, y declara el registro resultante como fuente de la verdad. Es una de las victorias tempranas más fiables de un programa de gobierno porque es visible y medible.

Dónde se rompe. Un proyecto de limpieza deduplica la base de clientes, todos lo celebran y los sistemas de origen siguen creando duplicados al mismo ritmo. Seis meses después la cifra ha vuelto. La deduplicación solo se mantiene gracias a la decisión de gobierno que la sigue: una fuente autorizada y un proceso en el punto de entrada que compruebe antes de crear.

Las dimensiones existen para que "los datos están mal" pase a ser un diagnóstico. La completitud es si el valor está. La validez es si cumple su formato. La exactitud es si coincide con la realidad, la única dimensión que normalmente necesita una persona o una referencia externa para comprobarse. La consistencia es si el mismo hecho concuerda entre sistemas. La oportunidad es si llegó a tiempo para ser útil. La unicidad es si la entidad aparece una sola vez.

En la práctica. La mayoría de los problemas reales son de validez, completitud y consistencia, en ese orden, porque son las tres que un sistema puede generar en silencio. Nombrar la dimensión te dice dónde va el arreglo: la validez suele ser un control de entrada, la consistencia suele ser una integración, la oportunidad suele ser una planificación.

Dónde se rompe. La exactitud se mide con una regla, y no puede medirse así. Un código postal que pasa la validación de formato y pertenece a otra ciudad es válido y equivocado. Comprobar la exactitud implica comparar contra algo autoritativo y, si no existe esa fuente, dilo en lugar de informar de un 98 %.

El trabajo de calidad de datos falla de una forma muy predecible: alguien hace una limpieza, el tablero se pone verde y seis meses después el mismo campo está roto otra vez porque nada cambió aguas arriba. DMAIC es la disciplina que lo evita. Viene de la manufactura, encaja en datos casi sin adaptarlo y todo su valor está en la última letra: Controlar es el paso que separa una mejora de una limpieza.

En la práctica. Definir elige un elemento de datos crítico y el dolor de negocio asociado, en dinero o en horas. Medir perfila el estado actual para tener una línea base y no una opinión. Analizar rastrea el defecto hasta su origen, que casi siempre es un proceso o un formulario, no una base de datos. Mejorar lo corrige donde nace: un campo obligatorio, una validación, un traspaso rediseñado, un equipo reentrenado. Controlar deja una regla de calidad, un monitor, un umbral y un dueño con nombre que recibe la alerta. Un ciclo por elemento, de seis a diez semanas, una página de evidencia en cada paso.

Dónde se rompe. Los equipos paran después de Mejorar, porque ahí está la victoria visible y ahí aplaude el patrocinador. La otra versión es un proyecto que se pasa un trimestre entre Medir y Analizar, produce una presentación preciosa de causa raíz y no cambia ningún sistema.

La criticidad es un mecanismo de triaje. Ninguna organización puede gobernar todos los campos, así que la lista de CDE es la respuesta honesta a "cuáles importan de verdad". Un campo es crítico si alimenta una declaración regulatoria, un estado financiero, un pago, una decisión de seguridad o una métrica de dirección. Eso suele estar entre 50 y 300 campos en una empresa mediana, de entre decenas de miles.

En la práctica. Deriva la lista hacia atrás desde la consecuencia. Toma los informes regulatorios, el informe de dirección y los tres procesos operativos principales, y traza de qué campos dependen. Ese trazado es tu lista de CDE, y viene con su propia justificación incorporada, que es lo que la hace financiable.

Dónde se rompe. La criticidad se decide preguntando a cada departamento cuáles de sus datos son críticos. Todos responden "todos", porque a nadie se le premia por declarar que sus datos no importan. La criticidad hay que derivarla del uso, no recogerla como opinión.

Todas las organizaciones las tienen: la exportación que finanzas vuelve a teclear cada mes, el libro regional con su propia definición de "cliente activo", el fichero en el que el analista confía más que en el panel. Cada una nació como un apaño razonable para un problema real: un acceso lento, un número equivocado, un informe que no respondía a la pregunta. Juntas son el lugar donde viven los números reales de la organización, fuera de cualquier control, linaje o auditoría.

En la práctica. Trata las hojas paralelas como evidencia, no como mala conducta. Pregunta qué arregla cada una y tendrás una lista priorizada de puntos de dolor: definiciones que faltan, accesos que tardan tres semanas, calidad que nadie escala. Contarlas es una aproximación razonable a la brecha de confianza. Retíralas arreglando el motivo por el que existen y dando a los consumidores una vía para reportar discrepancias a un steward, y luego mide cuántas desaparecen.

Dónde se rompe. El gobierno prohíbe las hojas de cálculo o bloquea las exportaciones sin arreglar lo que empujó a la gente hacia ellas. El trabajo se mueve a un sitio menos visible, el riesgo se traslada en lugar de reducirse y la siguiente auditoría encuentra los mismos números en una unidad personal. Una hoja de cálculo que ya nadie necesita desaparece sola.

Un pipeline que se cae lanza una alerta. Los fallos caros son los que no: una tabla que carga la mitad de sus filas habituales, una fuente que deja de actualizarse, una columna de origen que cambia de tipo sin aviso. La observabilidad vigila esas señales de forma continua — recuento de filas, frescura frente al calendario, deriva de esquema, valores que se salen de su rango habitual — y avisa a alguien cuando los datos se comportan distinto de sí mismos.

En la práctica. Monitoriza primero las tablas detrás de las decisiones que importan y dirige cada alerta a un steward con nombre, no a un canal compartido. Combínala con el linaje, para que una alerta en una tabla de origen muestre de inmediato qué paneles y modelos dependen de ella. La observabilidad es buena diciendo que algo cambió; decidir si el cambio es un problema sigue siendo trabajo de alguien que conoce el negocio.

Dónde se rompe. Se activa una herramienta sobre todo el almacén, aprende miles de líneas base y salta con cada pico de cierre de mes y cada bajón de festivo. El equipo la silencia en semanas. El otro fallo es tratar la observabilidad como sustituta de la validación: detecta los datos malos después de que han llegado, lo cual es útil, pero no impide que entren.

El perfilado es cómo descubres que el campo de país contiene 47 formas distintas de escribir "Reino Unido", que el 8 % de las fechas de nacimiento es 01/01/1900 y que una columna documentada como obligatoria está vacía en un tercio de las filas. Es el diagnóstico más barato del trabajo con datos y el que más se salta, porque produce hechos incómodos antes de que un proyecto haya acordado su alcance.

En la práctica. Perfila antes de prometer. Medio día de perfilado sobre las tablas que sostienen un panel propuesto te dirá si ese panel es un trabajo de dos semanas o de dos trimestres, y eso es lo más útil que puedes saber al principio.

Dónde se rompe. El resultado del perfilado se presenta en crudo. Nadie fuera del equipo de datos tiene una opinión sobre un informe de cardinalidad. Tradúcelo: "la tabla de clientes tiene 14.000 registros duplicados, y por eso la tasa de churn del informe de dirección está sobrestimada en unos cuatro puntos". El mismo hallazgo, otra consecuencia.

Una regla tiene cuatro partes: los datos a los que aplica, la condición que afirma, el umbral a partir del cual el resultado cuenta como fallo y la persona que hace algo al respecto. Sin el umbral, cada regla está siempre en verde o siempre en rojo. Sin responsable, una regla que falla es una notificación que nadie ha aceptado recibir, lo que en un mes es una carpeta de correo filtrada.

En la práctica. Las reglas que merece la pena escribir vienen de incidentes. Algo salió mal, alguien investigó, la causa fue una condición de los datos: codifica esa condición como regla para que la próxima vez se detecte antes de la consecuencia. Un backlog de reglas derivadas de incidentes reales tiene una credibilidad que un conjunto generado nunca tiene.

Dónde se rompe. Las reglas se generan automáticamente a partir del profiling y se activan en bloque. El resultado son miles de alertas, la mayoría describiendo condiciones perfectamente normales en ese negocio, y el equipo deja de leer todas. La fatiga de alertas no es un problema de ajuste, es una decisión de diseño tomada demasiado pronto.

Un SLA de calidad de datos convierte "los datos deberían estar bien" en números que alguien firma: la tabla de clientes llega antes de las 06:00, los campos obligatorios están informados al menos en un 99,5 %, la precisión de facturación se mantiene por encima de una línea acordada. Se sitúa entre el equipo que produce los datos y los equipos que construyen sobre ellos, y nombra a un responsable del lado productor. Sin ese nombre es un deseo con decimales.

En la práctica. Empieza con tres dimensiones, normalmente frescura, completitud y precisión, sobre el puñado de conjuntos de datos que alimentan decisiones por las que la gente realmente discute. Cada compromiso necesita una medición que se ejecute sola y un tiempo de respuesta ante incumplimientos, no solo un objetivo. El SLA útil es el que un dueño de dominio puede ver en un panel junto a si se cumplió el mes pasado.

Dónde se rompe. El SLA lo redacta el lado consumidor, promete lo que le gustaría y no lo que el productor puede entregar, y se incumple desde la primera semana. Nadie lo renegocia, todos dejan de mirarlo y el documento sobrevive como prueba de que alguna vez se habló de calidad. Un SLA que nunca se incumple suele estar demasiado bajo; uno que se incumple siempre no es un acuerdo.

Un umbral es el número que convierte una medición en una decisión. Una completitud del 97 % no significa nada por sí sola; una completitud por debajo del 98 % en la dirección de facturación, que bloquea la emisión de facturas, significa que el steward recibe un ticket. Lo fija el dueño de los datos, porque solo el negocio sabe cuánto error puede absorber un proceso antes de costar dinero. Ingeniería lo aplica y el steward gestiona lo que queda por debajo.

En la práctica. Fija umbrales por uso, no por campo en abstracto, y parte de la consecuencia: qué se rompe aguas abajo y a partir de qué tasa empieza a doler. Pon el umbral donde ya ocurre el trabajo — en la definición de "terminado" de un pipeline, en los criterios de lanzamiento — para que se compruebe cada vez y no se revise una vez al trimestre. Deja escrito por qué se eligió cada número; el motivo es lo que permite cambiarlo después sin pelea.

Dónde se rompe. Los umbrales se copian del valor por defecto de un proveedor o se fijan en el 100 % porque cualquier cosa menor suena a aceptar datos malos. Un umbral del 100 % salta constantemente, se silencia y no protege nada. El fallo contrario es un umbral tan holgado que nunca salta, lo que en el panel parece buena calidad y no lo es.

La validación es la puerta. En la ingesta aplica el esquema, rechaza importes de transacción negativos y correos mal formados, y comprueba que las claves obligatorias estén informadas. Durante la transformación comprueba que una devolución tenga su compra correspondiente y que los totales cuadren entre origen y destino. Los registros que fallan se rechazan o se ponen en cuarentena en lugar de seguir adelante, porque el sitio más barato para corregir datos malos es antes de que se haya construido nada encima.

En la práctica. Pon los primeros controles donde hoy entran datos sin validar: la ingesta por API y las cargas manuales de ficheros son los sospechosos habituales. Empieza ligero — esquema, completitud, unos pocos controles de rango en las tablas prioritarias — y añade validación de reglas de negocio donde los incidentes demuestren que hace falta. Un control que falla debería detener la carga o enviar los registros a una tabla de cuarentena, y alguien debería ser dueño de lo que cae ahí.

Dónde se rompe. Los controles registran los fallos y dejan pasar todo, así que la validación se convierte en un informe de lo que salió mal ayer. O la tabla de cuarentena existe y nadie la mira, que es solo una forma más lenta de perder registros. Validar sin decidir qué pasa cuando algo falla es monitorización con pasos extra.

La alfabetización de datos no es estadística. Es la capacidad práctica de mirar un gráfico y saber a qué pregunta responde, de notar que el denominador ha cambiado, de preguntar de dónde viene un número antes de repetirlo y de decir "esto no sostiene esa conclusión" en una reunión. Es sobre todo escepticismo y vocabulario más que técnica, y por eso puede enseñarse a un equipo comercial en semanas y por eso el despliegue de una herramienta nunca la produce.

En la práctica. La alfabetización se construye con los datos propios de la organización, en el contexto de decisiones que la gente ya toma. Una sesión de una hora que recorra con un equipo de ventas su propio informe de pipeline —qué significa cada campo, dónde se rompe, qué comparaciones no son válidas— supera con mucho a un curso genérico.

Dónde se rompe. La alfabetización se compra como una licencia de una plataforma de e-learning y se comunica como tasa de finalización. La finalización mide asistencia, no capacidad. La medida que importa es si las preguntas que se hacen en las reuniones de revisión mejoran, y eso es observable en un trimestre si alguien está mirando.

La analítica en autoservicio sustituye la cola de tickets por infraestructura: un catálogo buscable para encontrar los datos, accesos concedidos por rol y no por hilo de correo, conjuntos de datos certificados sobre los que construir y herramientas de BI que la gente de negocio pueda usar de verdad. Lo que se busca es velocidad para la pregunta rutinaria —el gerente de tienda que mira su stock, la analista de marketing que desglosa la campaña del mes pasado— mientras el equipo central deja de ser el cuello de botella de cada cambio en un informe y pasa a mantener aquello sobre lo que todos construyen.

En la práctica. Funciona encima del gobierno, no en su lugar. El mínimo es un pequeño conjunto de datos certificados con un dueño con nombre, definiciones acordadas para las métricas que la gente va a calcular y niveles de acceso que dejen entrar a la mayoría en los datos operativos agregados sin una aprobación cada vez. Después, formación con los datos propios de los usuarios, porque una herramienta que nadie sabe interpretar solo produce números equivocados con más seguridad y más rápido.

Dónde se rompe. La herramienta se despliega antes que todo eso. Cada departamento crea sus propios cuadros de mando con su propia fórmula para la misma métrica, los informes se multiplican y en un año el comité de dirección tiene tres cifras de ingresos y no se fía de ninguna. No es un fracaso del autoservicio. Es autoservicio sin glosario.

La cultura se observa en comportamientos pequeños. Si una reunión empieza por el número o por la opinión. Si un analista puede decir que los datos no sostienen el plan sin pagarlo con su carrera. Si un informe que muestra un fracaso se distribuye o se revisa. Si la gente busca datos existentes antes de encargar nuevos. Nada de eso sale de un cartel; todo sale de lo que se ve hacer a los directivos cuando los datos son incómodos.

En la práctica. La cultura se mueve cuando se mueven los incentivos. La intervención individual más eficaz es que un líder cambie públicamente una decisión por la evidencia y diga que ese es el motivo. Eso vale más que un año de comunicación interna.

Dónde se rompe. La cultura se trata como el componente blando y no medible del programa y se entrega a comunicación. No es blanda ni imposible de medir: mide con qué frecuencia se conciliaron previamente los números de un documento de decisión, cuántas decisiones citan una fuente, cuánto se tarda en responder "¿de dónde viene esto?". Esas cosas se mueven y se pueden seguir.

Lo contrario de la tiranía de datos, esa situación en la que una pregunta rutinaria necesita un ticket, una semana y un permiso por escrito de TI. La democratización cambia el punto de partida de "cerrado salvo aprobación" a "disponible salvo riesgo", con la propiedad repartida entre los dominios de negocio y una función central que fija los estándares de seguridad, mantiene el glosario y cuida la coherencia de la arquitectura. No es barra libre sin gobierno. Bien hecha, exige más gobierno que el bloqueo, solo que de otro tipo.

En la práctica. Clasifica los datos por niveles. Los datos muy restringidos —datos personales, libros contables, secretos comerciales— mantienen aprobaciones estrictas, enmascaramiento y registro de auditoría. Los datos operativos de negocio se abren a los usuarios autenticados a través de modelos certificados. Los datos exploratorios en bruto viven en sandboxes. Añade un catálogo para que la gente encuentre las cosas, accesos basados en roles para que no dependan de la bandeja de entrada de alguien y alfabetización para que el acceso se convierta en decisiones.

Dónde se rompe. Se anuncia como un valor y se entrega como una licencia: todo el mundo recibe la herramienta de BI y nadie recibe definiciones ni datos certificados. O las restricciones se quedan, la gente las rodea y la organización acaba con un mercado negro de datos hecho de hojas de cálculo exportadas: democratización, técnicamente, sin ninguno de los controles.

La gestión del cambio es la parte del gobierno de datos que trata con personas y no con datos. El gobierno redistribuye autoridad, añade rutinas y pide a la gente que deje de hacer cosas que localmente le funcionan, como exportar ficheros en bruto a sus propias hojas de cálculo. La resistencia es normal y suele tener causas corrientes: no se entiende qué cambia, se teme perder el control de los propios números o se ve fricción sin ningún beneficio propio. El DMBOK le dedica su último capítulo, que es más o menos donde la dejan también casi todos los programas.

En la práctica. Empieza por una historia de negocio, no por una política: la previsión que salió mal, la campaña que llegó tarde. Busca aliados dentro de los dominios, stewards y responsables de equipo a los que el resto ya escucha, porque los pares convencen donde un equipo central no puede. Traduce la jerga a frases llanas, haz visibles las primeras victorias y mide la adopción: cuánta gente usa cada semana los datos certificados y cuántas hojas de cálculo en la sombra se han retirado.

Dónde se rompe. Se trata como comunicación: un correo de lanzamiento, un PDF con la política, una diapositiva en la reunión general. Todo el mundo queda informado y nadie se comporta de otra manera. Contar políticas publicadas mide cuánto se ha escrito, no si alguien ha cambiado lo que hace.

La prueba no es si los datos aparecen en el documento de decisión. Es si los datos podrían haber producido una decisión distinta. Una organización que reúne la evidencia después de haber elegido no está basada en datos, está decorada con datos, y todos los implicados notan la diferencia. Estar realmente basado en datos también exige aceptar que algunas decisiones tienen evidencia insuficiente y decirlo, en lugar de disfrazar un juicio de análisis.

En la práctica. Escribe, antes del análisis, qué resultado te haría cambiar de opinión. Ese único hábito convierte un ejercicio de confirmación en una decisión, y es gratis.

Dónde se rompe. La expresión se usa para decir "tenemos paneles". Los paneles son oferta. Una cultura de decisión es demanda, y ambas son independientes: hay muchas organizaciones con un reporting excelente del que nunca ha dependido ninguna decisión. Un trabajo de gobierno que solo mejora la oferta no moverá esto en absoluto.

DCAM lo publica el EDM Council (Enterprise Data Management Council), una asociación del sector con raíces profundas en los servicios financieros, y se nota: está pensado para organizaciones que algún día tendrán que demostrar a un auditor o a un regulador cómo gestionan sus datos. Agrupa la gestión de datos en ocho áreas de capacidad —estrategia y caso de negocio, programa y financiación, arquitectura de negocio y técnica, calidad de datos, gobierno, entorno de control y analítica— y puntúa cada una en seis niveles de realización, de no iniciado a mejorado. Donde DAMA-DMBOK describe qué abarca la gestión de datos, DCAM está diseñado para medir cuánto has avanzado.

En la práctica. Su fuerza es la evidencia. Una puntuación DCAM debe apoyarse en artefactos —la política aprobada, el rol con presupuesto, el control que se ejecuta de verdad—, lo que lo hace adecuado cuando el resultado tiene que sobrevivir a una auditoría o compararse entre unidades de negocio. También es detallado, y su uso completo suele pasar por la membresía y la formación del Council. La mayoría de los programas pequeños toman prestada su estructura en lugar de aplicarlo de principio a fin.

Dónde se rompe. Se elige DCAM porque suena riguroso y luego se ejecuta como una hoja de cálculo autoevaluada por el propio equipo evaluado. El detalle que lo hace creíble se convierte en la razón por la que nunca se termina. Si nadie fuera de la oficina de datos va a mirar las puntuaciones, un modelo más ligero y tres acciones con nombre harán más.

El modelo es la regla; la evaluación es el acto de medir con ella. Eliges un marco, reúnes evidencia en cada una de sus dimensiones —calidad, stewardship, metadatos, seguridad, arquitectura— y asignas un nivel a cada una, de modo que el resultado dice "nivel 1 en calidad, nivel 3 en seguridad" y no una nota única. La versión útil tiene cuatro pasos: acotar el alcance, reunir evidencia, mapear los niveles y convertir las brechas en un plan con responsables y fechas. Es una línea base que se repite, no un diploma para enmarcar.

En la práctica. La evidencia gana a los cuestionarios. Pide ver el glosario, los últimos tickets de incidencias, el rastro de aprobación de accesos, y puntúa lo que te enseñan, no lo que te cuentan. Limita el alcance a las preguntas sobre las que vas a actuar: una lectura rápida para encontrar tu dimensión más débil es útil, una línea base de cuarenta puntos sobre todas las áreas de conocimiento es un proyecto en sí misma. Y no hace falta una para encontrar el dolor: las entrevistas y un año de escalados lo sacan a la luz antes.

Dónde se rompe. La evaluación se convierte en los primeros seis meses del programa y en su único entregable. O el objetivo se escribe como un nivel, "llegar al nivel 3", que nadie fuera del equipo de datos puede valorar y ninguna revisión de presupuesto financiará. Traduce cada brecha a un resultado de negocio antes de que entre en la hoja de ruta.

Gobierno proactivo significa que los controles están donde se fabrica el dato, no donde se consume. Las definiciones se acuerdan antes de construir la tabla. Las reglas de calidad corren dentro del pipeline, así que una carga defectuosa se detiene en lugar de llegar. Las interfaces llevan un contrato, así que un cambio incompatible rompe la build del productor y no el informe del lunes de otra persona. Los accesos se revisan por calendario y no cuando pregunta un auditor. La clasificación ocurre al crear el dato, cuando la persona que sabe qué contiene el campo todavía está en la sala.

En la práctica. Cambia lo que reportas. Un programa reactivo cuenta incidentes cerrados; uno proactivo cuenta cosas que no pasaron: cargas bloqueadas antes de publicarse, cambios incompatibles detenidos en CI, accesos retirados el mismo día en que alguien cambió de puesto, datasets nuevos que nacieron ya con dueño y clasificación. Son indicadores adelantados, son aburridos y son la única evidencia de que la prevención funciona.

Dónde se rompe. La prevención degenera en aduana. Cada dataset nuevo necesita tres aprobaciones y dos semanas de espera, así que la gente hace lo que siempre hace cuando la puerta principal es lenta: construye la cosa en una hoja de cálculo, una cuenta de nube personal o un almacén en la sombra, y la función de gobierno pierde de vista precisamente los datos que quería proteger. Si un control no se puede automatizar, necesita un acuerdo de nivel de servicio; y si no tiene ninguno de los dos, es una cola, no un control.

Se reconoce por el calendario. El trabajo llega en forma de incidentes: el regulador pregunta, finanzas encuentra dos cifras de ingresos, un cliente recibe el extracto de otro, un modelo aparece entrenado con datos que nunca debió ver. El equipo responde bien —a veces heroicamente— y luego vuelve a lo que estaba haciendo hasta el siguiente. El gobierno reactivo no es un defecto de carácter: es el aspecto que tiene el gobierno antes de que alguien financie la prevención, y casi todos los programas empiezan aquí.

En la práctica. La salida consiste en aprovechar los incidentes, no solo en sobrevivirlos. Registra cada uno con lo que costó, qué datos estaban implicados y qué control lo habría detectado. Doce registros forman un patrón, y un patrón construye el caso de negocio que ninguna diapositiva de madurez consigue: los mismos tres dominios, el mismo dueño ausente, la misma regla de calidad que no existe. Ese es también el momento de convertir un incidente en un control permanente en lugar de en una limpieza.

Dónde se rompe. Quedarse aquí. Un equipo famoso por arreglar cosas se convierte en la brigada de limpieza —valorada, ocupada, nunca financiada para prevenir— y la reputación se endurece: gobierno son los que llamas después del daño. La señal de que está pasando es simple: nadie recuerda una decisión que la función de gobierno tomara antes de que un incidente la forzara.

La madurez es una afirmación sobre repetibilidad, no sobre herramientas. Una organización donde el informe mensual sale bien porque un analista concreto sabe qué tres columnas ignorar es inmadura por mucho presupuesto tecnológico que tenga. Una donde el mismo informe lo produce correctamente quien esté de turno, con las excepciones documentadas, es madura. La diferencia está en si el conocimiento vive en las personas o en el proceso.

En la práctica. La madurez merece evaluarse por capacidad, no como un número único. Puedes ser genuinamente fuerte en metadatos y débil en calidad, y la media de las dos no te dice nada accionable. Evalúa las capacidades, elige las dos que bloquean el resultado de negocio más cercano y deja el resto.

Dónde se rompe. La madurez se convierte en el objetivo. A nadie le han dado presupuesto por pasar de 2,1 a 2,6; se lo dan por cerrar un hallazgo regulatorio o desbloquear un lanzamiento, y la madurez mejora como subproducto. Presenta la evaluación como diagnóstico, nunca como objetivo.

TDWI, la organización de investigación y formación en datos y analítica, describe la madurez analítica en cinco etapas que casi todas las organizaciones reconocen en sí mismas a la primera lectura. Naciente: el uso de datos es puntual e individual y el reporting es manual. Emergente: la dirección empieza a pedir evidencia y las definiciones son inconsistentes y todo el mundo lo sabe. En desarrollo: la formación se formaliza y los datos se consultan de forma rutinaria en las decisiones operativas. Madura: la fluidez va mucho más allá de los equipos técnicos y las definiciones estandarizadas son lo normal. Líder: se espera evidencia y la analítica es una ventaja competitiva, no una función de soporte. Mira la analítica en conjunto —organización, infraestructura, gestión de datos, analítica y gobierno— y no solo el gobierno de datos.

En la práctica. Úsalo para la conversación sobre cómo se toman las decisiones, donde un modelo solo de gobierno se quedaría corto; encaja de forma natural con el trabajo de alfabetización y cultura. Las descripciones de las etapas son lo bastante breves para leerlas en voz alta en un comité de dirección, y la gente se sitúa enseguida, normalmente con más generosidad de la que la evidencia permite.

Dónde se rompe. La etiqueta de la etapa se convierte en el objetivo. "Pasar de En desarrollo a Madura" no es un resultado de negocio y no sobrevivirá a una revisión de presupuesto. "Reducir de cuatro a una las definiciones de ingresos en uso" es el mismo progreso en una forma que alguien financiará. La etapa es un diagnóstico, no un destino.

La mayoría de los modelos comparten una forma de cinco niveles: no pasa nada deliberado, algunas personas lo hacen bien, está documentado y es repetible, se mide, se mejora a propósito. El valor no está en la puntuación sino en el vocabulario: un modelo da al equipo directivo una forma compartida de decir "estamos en nivel 1 en calidad y en nivel 3 en control de accesos", que es una conversación mucho más productiva que intercambiar anécdotas.

En la práctica. Usa el modelo como guía de entrevista, no como cuestionario. La evidencia que determina un nivel es lo que alguien te enseña: el glosario real, los tres últimos registros de incidencias, el rastro de aprobación de un cambio de definición. La autoevaluación se infla en torno a un nivel en todas las organizaciones.

Dónde se rompe. El resultado es un diagrama de araña, y el diagrama de araña es el entregable. Una evaluación de madurez que no acaba con tres acciones concretas, un responsable para cada una y una fecha ha producido un diagnóstico sobre el que nadie puede actuar. El gráfico es el principio de la conversación, no su conclusión.

Un modelo operativo tiene cuatro partes: los dominios y sus dueños, los roles y cuánto tiempo lleva cada uno, los foros y qué decide cada uno, y las rutas: cómo se cambia una definición, cómo se escala una incidencia, cómo se aprueba una excepción. También declara una forma: centralizado, federado o un núcleo con equipos de dominio. Federado es la respuesta más común y la que menos se especifica, y por eso tan a menudo significa nadie.

En la práctica. Ajusta el modelo a la organización que tienes de verdad. Una empresa que lo decide todo a través de los responsables funcionales no sostendrá un modelo por dominios, por correcto que sea el mapa de dominios. El gobierno que pelea contra la estructura de decisión existente pierde.

Dónde se rompe. El modelo se diseña para el estado final y se lanza de golpe: todos los dominios, todos los roles, todos los foros, en la misma fecha. La capacidad no existe, los foros no se llenan y dieciocho meses después el modelo es un documento que describe algo que nunca ocurrió. Dos dominios bien hechos valen más que doce anunciados.

Todos los modelos de madurez toman prestada la misma escalera de CMMI, aunque llamen distinto a los escalones. El nivel 1 es ad hoc: funciona porque una persona concreta sigue trabajando aquí. El nivel 2 es repetible: lo mismo ocurre dos veces por la misma razón, normalmente dentro de un solo equipo. El nivel 3 es definido: está escrito, tiene dueño y es igual en todos los dominios. El nivel 4 es gestionado: se mide, y la medición se usa para decidir. El nivel 5 es optimizado: mejora a propósito y con cadencia, sin que un programa empuje. Fíjate en que ninguna de esas frases menciona una herramienta.

En la práctica. Puntúa cada capacidad por separado —metadatos, calidad, privacidad, alfabetización, arquitectura— y espera un perfil desigual. Nivel 3 en clasificación y nivel 1 en calidad no es una contradicción: es tu hoja de ruta, y te dice qué deberían comprar los próximos doce meses. La conversación útil nunca es "en qué nivel estamos", sino "qué tendría que ser verdad para que esta capacidad fuera un 3, y merece la pena hacerlo este año".

Dónde se rompe. El nivel pasa de descripción a objetivo. Alguien se compromete a "nivel 4 en diciembre", el diagnóstico se convierte discretamente en un examen autocorregido y el programa empieza a optimizar la nota en lugar del negocio. Nivel 5 en todo también es la ambición equivocada: la mayoría de las organizaciones deberían quedarse deliberadamente en nivel 2 allí donde no hay casi nada en juego.

Un esquema de clasificación es un conjunto pequeño de etiquetas —público, interno, confidencial y restringido son las cuatro habituales— cada una asociada a reglas de manejo concretas: quién puede acceder, si puede salir del país, si puede usarse para entrenar un modelo, cuánto se conserva y cómo debe destruirse. La etiqueta solo merece la pena por las reglas que hay detrás; una etiqueta sin consecuencia es decoración.

En la práctica. Cuatro niveles es el máximo práctico. Cada nivel adicional genera discusiones sobre casos límite y etiquetado inconsistente, y la diferencia entre "confidencial" y "muy confidencial" casi nunca se operativiza de forma distinta.

Dónde se rompe. La clasificación se aplica pidiendo a los dueños de datos que etiqueten todo, lo que produce un parque entero marcado como confidencial: la respuesta segura para quien etiqueta e inútil para todos los demás. Ancla el esquema en ejemplos, pon "interno" por defecto y exige una justificación para el nivel más alto.

RBAC es una idea de gobierno antes que una técnica. Los permisos se asocian a un rol —tramitador de siniestros, analista de riesgos, analista de marketing—, el dueño de los datos aprueba qué puede ver ese rol, y una persona obtiene el acceso al entrar en él. La ganancia no son menos clics: es que la pregunta cambia de "¿por qué Marta tiene esto?" a "¿debería un analista de riesgos ver esto?", que es una pregunta que alguien puede responder de verdad, y responder una sola vez para todos.

En la práctica. Los roles se nombran por el puesto, nunca por la persona ni por el proyecto. El dueño de los datos aprueba su alcance, y el acceso se engancha al ciclo de vida de RR. HH.: quien entra hereda su rol, quien se mueve pierde el anterior el mismo día, y quien sale se corta automáticamente. Las columnas sensibles siguen detrás de una política de enmascaramiento incluso dentro de un rol aprobado, y cada rol se recertifica con una periodicidad fija por el dueño que lo concedió — la recertificación es la parte por la que todo el mundo compra la herramienta y que nadie ejecuta.

Dónde se rompe. La explosión de roles. Cada excepción crea un rol nuevo y, dos años después, hay más roles que empleados y nadie sabe qué significa ninguno, que es lo mismo que no tener modelo. El segundo fallo son los movimientos internos: las altas y las bajas se gestionan, pero quien ha cambiado de puesto tres veces conserva la suma de todo lo que necesitó alguna vez. Cuando los roles ya no alcanzan a expresar la regla, la respuesta suele ser añadir atributos —región, propósito, clasificación— encima, no otros cien roles.

Confidencial es el nivel donde quien corre el riesgo es la compañía. Si se filtra, un competidor fija precios contra ti, una negociación se cae, una valoración se mueve o tu propia gente descubre cuánto gana el resto. Es un daño real y merece controles reales, pero es un daño comercial, y por eso circula por una vía distinta a la de los datos personales sensibles, donde el expuesto es una persona.

En la práctica. La etiqueta por sí sola no vale nada; lo que la hace útil son las reglas de manejo grapadas a ella. Quién aprueba el acceso y por cuánto tiempo. Dónde puede vivir el dato: qué plataforma, qué región, qué tenant. Si puede salir de la empresa y bajo qué acuerdo. Cuánto se conserva y qué pasa al final. Y si se puede pegar en una herramienta de IA externa, que es la pregunta que hoy recibe más veces esta clasificación. Un nivel sin reglas asociadas es decoración.

Dónde se rompe. Todo acaba siendo confidencial. Un criterio de "por si acaso, restríngelo" produce un almacén donde el 90 % de las tablas llevan la etiqueta más alta, así que la gente esquiva los controles para poder trabajar y la etiqueta deja de informar. Una clasificación que funciona es deliberadamente desigual: la mayoría del dato es interno, una porción es confidencial, un conjunto pequeño es restringido, y alguien con peso está dispuesto a defender dónde se trazan las líneas.

La distinción que importa es quién sale herido. Los datos sensibles son la categoría en la que el daño recae sobre un ser humano: un diagnóstico, una plantilla biométrica, una afiliación política o religiosa, la pertenencia a un sindicato, la orientación sexual, el origen étnico, un antecedente penal, una dirección que alguien mantiene oculta. El RGPD los llama categorías especiales, la LGPD brasileña los llama dados sensíveis y ambas los tratan como una clase aparte con una base legal más estricta, porque la consecuencia de una filtración no es un bochorno ni una multa: es discriminación, exclusión o riesgo físico para alguien que nunca eligió estar en tu base de datos.

En la práctica. Es una etiqueta a nivel de columna, aplicada al crear el dato y heredada por todo lo que va detrás, con enmascaramiento activado por defecto y acceso concedido para un propósito declarado y no para un cargo. La retención es más corta, compartirlos con un tercero exige una base legal con nombre y los modelos entrenados con ellos heredan todas esas restricciones. El primer paso honesto suele ser más pequeño que una política: averiguar qué tablas los contienen de verdad, porque el inventario casi siempre está mal.

Dónde se rompe. Se confunden con los datos confidenciales y se gobiernan como si fueran lo mismo. Los salarios y los precios son confidenciales: la expuesta es la empresa. Una historia clínica es sensible: el expuesto es el individuo. Mezclarlos lleva a proteger datos comerciales como si hubiera vidas en juego, o a proteger la salud de las personas con el cuidado que se le da a una lista de precios. Segundo fallo: la etiqueta vive en la columna de origen y la copia en la hoja de cálculo de alguien no hereda nada.

Dos personas ejecutan la misma consulta contra la misma tabla y obtienen respuestas distintas, a propósito. El agente de soporte ve una tarjeta que termina en 4471 y el resto en asteriscos; el analista de fraude la ve completa; el científico de datos ve un hash consistente que sigue permitiendo el cruce pero no identifica a nadie. Nada se copió y nada se destruyó: la política se evalúa mientras corre la consulta. Ahí está la diferencia con el enmascaramiento estático, que produce una copia aparte, permanentemente alterada, para los entornos inferiores.

En la práctica. La regla se engancha a la clasificación, no al equipo: una columna etiquetada como personal o sensible hereda una política de enmascaramiento, y los roles reciben el derecho de ver a través de ella. Snowflake, BigQuery, Databricks y SQL Server lo soportan de forma nativa, lo que significa que escribes la política una vez en lugar de mantener una vista a mano por audiencia — y las vistas hechas a mano son la razón por la que una columna sin enmascarar acaba en un tablero que nadie recuerda haber creado.

Dónde se rompe. Se trata el enmascaramiento como si fuera todo el control. Un identificador enmascarado junto a una fecha de nacimiento, un código postal y un importe sin enmascarar reidentifica a las personas sin esfuerzo, así que enmascarar sin pensar en lo que revelan las columnas restantes es teatro. El clásico complementario: producción está bien enmascarada y el entorno de pruebas guarda una copia sin enmascarar de hace dos años que puede leer media compañía.

El gobierno de la IA pregunta con qué se entrenó un modelo, si esos datos estaban permitidos para ese propósito, quién aprobó el despliegue, qué se monitoriza del modelo y quién puede apagarlo. Cuatro de esas cinco preguntas se responden con linaje, clasificación, registros de consentimiento y propiedad de los datos. Por eso una organización sin gobierno de datos no puede tener gobierno de la IA: no hay nada debajo a lo que apelar.

En la práctica. La vía más rápida a un gobierno de IA defendible es extender lo que ya existe. Añade "aprobado para entrenamiento de modelos" al esquema de clasificación, exige linaje para los conjuntos de entrenamiento, lleva la aprobación de modelos al orden del día del consejo existente y registra la decisión. Eso son semanas de trabajo, no un programa nuevo.

Dónde se rompe. El gobierno de la IA se construye como una estructura paralela con su propio comité, su cuerpo de políticas y su vocabulario. En un año tiene otro dueño y otra respuesta para el mismo conjunto de datos, y la primera pregunta regulatoria expone la brecha. Un único conjunto de derechos de decisión sobre los datos, extendido a los modelos, es la disposición que aguanta.

La PII es más amplia de lo que suponen la mayoría de los inventarios, porque la identificabilidad es contextual. Un código postal no identifica; un código postal más una fecha de nacimiento más un puesto de trabajo con frecuencia sí. Bajo el RGPD el concepto relevante es dato personal, que cubre cualquier cosa relativa a una persona identificable, incluidos los datos que solo la identifican al cruzarlos con algo más que ya tienes. Por eso "hemos quitado los nombres" no es, por sí solo, anonimización.

En la práctica. Encuentra los datos personales trazando la finalidad, no escaneando columnas. Pregunta qué procesos implican a una persona, qué se recogió, qué se le dijo en aquel momento y en qué base se está apoyando la organización. Los escáneres de patrones encuentran direcciones de correo; no encuentran el cruce que vuelve reidentificable un conjunto de datos.

Dónde se rompe. Los datos pseudonimizados se tratan como anónimos y se mueven fuera de sus controles originales: a un entorno de analítica, a un sistema de pruebas, a un conjunto de entrenamiento. Los datos pseudonimizados siguen siendo datos personales, porque la clave que los revierte existe. Anónimo significa irreversiblemente anónimo, y muy pocos datos de un parque operativo cumplen ese umbral.

La privacidad trata de la persona que está en los datos, no de la organización que los guarda. La seguridad pregunta si los datos están protegidos de quien no debería verlos. La privacidad pregunta si quien puede verlos debería usarlos para esto. Normas como el RGPD, la LGPD o la CCPA convierten esa pregunta en obligaciones: una base legal, una finalidad declarada, minimización, límites de retención y derechos que la persona puede ejercer.

En la práctica. La privacidad se conecta con la clasificación y el acceso. Los campos personales se etiquetan donde se crean, se enmascaran por defecto y se liberan para una finalidad declarada, no para un puesto. El etiquetado por finalidad hace la mayor parte del trabajo: un conjunto de datos recogido para facturación no queda disponible automáticamente para un modelo de abandono, y un conjunto de entrenamiento hereda los límites de consentimiento y finalidad de cada fuente que lo alimentó.

Dónde se rompe. La privacidad se gestiona como un documento legal en lugar de como un conjunto de controles. La política dice que los datos solo se usan para fines declarados; nada en el catálogo registra cuáles eran esos fines. Luego un modelo llega a producción y nadie sabe decir si los clientes que contiene consintieron este uso. La política nunca estuvo equivocada. Simplemente no tenía nada debajo.

Los datos se crean, se usan, se quedan obsoletos y en algún momento deberían archivarse o borrarse. La retención es la decisión sobre cuándo. Una regla de retención utilizable tiene tres partes: la clase de datos que cubre, un plazo y un disparador, el evento que pone en marcha el reloj, como el fin de un contrato o el cierre de una cuenta. Un plazo sin disparador es un número que nadie puede aplicar.

En la práctica. Fijar la regla es gobierno: el dueño, con legal y privacidad, decide cuánto tiempo se conservan los registros de clientes y qué cuenta como fin de la relación. Implementarla es gestión: el proceso de retención que archiva los registros según el calendario legal y los borra a tiempo, más la evidencia de que se ejecutó. La retención también fluye aguas abajo. Las copias, extracciones y conjuntos de entrenamiento heredan la regla de su origen, o la regla significa muy poco.

Dónde se rompe. La retención es la decisión de gobierno que la mayoría de los programas aplaza indefinidamente, porque conservarlo todo parece seguro y borrar cualquier cosa parece arriesgado. Así es como una organización acaba guardando datos personales durante una década sin una base defendible, y lo descubre en una auditoría o una brecha en lugar de en una revisión.

La arquitectura de datos es el plano del patrimonio de datos: los modelos, los patrones de integración, las plataformas y los caminos que recorren los datos entre ellas. En el DMBOK es una de las áreas de conocimiento alrededor del núcleo del gobierno, y el reparto es limpio. El gobierno aporta los límites de los dominios, la fuente autoritativa de cada entidad y los estándares. La arquitectura convierte esas decisiones en modelos y diseño de plataforma. Es trabajo de gestión de datos, no de gobierno, pero es donde las decisiones de gobierno se vuelven físicas.

En la práctica. Las preguntas de arquitectura que más importan al gobierno rara vez son tecnológicas. ¿Qué sistema es la fuente autoritativa para cliente? ¿Dónde termina un dominio? ¿Qué estándar tiene que cumplir un pipeline nuevo antes de salir a producción? Si esas respuestas existen y están escritas, los arquitectos eligen bien y rápido. Si no, toman ellos las decisiones de gobierno, de forma implícita, una integración cada vez.

Dónde se rompe. Años de decisiones locales razonables producen un patrimonio fragmentado: mainframes heredados, un lakehouse en la nube y una docena de herramientas SaaS, cada una con su propia definición solapada de la misma entidad. Nadie diseñó el desorden. Cada pieza tenía sentido cuando se añadió, y ninguna decisión cubrió nunca cómo encajaban. Una migración de plataforma no lo arregla, porque las definiciones viajan con los datos.

La mayoría de los incidentes de datos no son corrupción: son sorpresa. Un ingeniero renombra una columna, endurece un tipo, cambia lo que significa "cancelado" o pasa una carga nocturna a horaria —todos cambios razonables— y once tableros y dos modelos aguas abajo se rompen o, peor, siguen funcionando y reportan silenciosamente otra cosa. Un contrato de datos hace explícita la promesa para que el cambio sea una negociación y no una caída: este es el esquema, esto significa cada campo, esta es la frescura, estos son los umbrales de calidad, este es el dueño y este es el aviso que recibirás antes de que algo de esto cambie.

En la práctica. El contrato vive con el código del productor, en control de versiones, y se prueba. Un cambio incompatible rompe el pipeline del productor antes de desplegarse, que es justamente el objetivo: el coste del cambio recae en el equipo que lo hace y no en quien lo descubra primero. Quien consume se registra contra el contrato, así que el productor ve a quién rompería y una deprecación pasa a ser una fecha y una ruta de migración en lugar de un anuncio. En una ficha de marketplace, el contrato es lo que convierte una tabla en algo sobre lo que otro equipo puede construir.

Dónde se rompe. El contrato es una página en la wiki. Nada lo comprueba, se desvía en un mes y acaba documentando cómo se comportaba el dato antes. El otro fallo es prometer de más: frescura o completitud que el productor no puede garantizar, así que el contrato se incumple constantemente y todo el mundo deja de leer las alertas.

Un data lake admite casi cualquier cosa: exportaciones de aplicaciones, logs, datos de IoT, extracciones de herramientas SaaS, ficheros que nadie recuerda haber pedido. A diferencia de un data warehouse, no exige un esquema por adelantado, lo que lo hace barato de llenar y flexible de usar. Un lakehouse añade tablas y controles de estilo warehouse sobre el mismo almacenamiento. En ambos casos, el lake resuelve un problema de almacenamiento. Por sí solo no resuelve ningún problema de significado, propiedad o confianza.

En la práctica. Un lake gobernado es aburrido. Cada zona o conjunto de datos tiene un dueño con nombre, una clasificación y una entrada en el catálogo. Los datos en bruto recién aterrizados se separan de los datos curados sobre los que se permite informar, y la diferencia es visible para quien navega. Las columnas sensibles se enmascaran por defecto, no después de la primera queja.

Dónde se rompe. La ingesta funciona sin gestión y todo entra, porque es fácil. En un par de años el lake contiene registros duplicados, tres versiones de la tabla de clientes y una factura de almacenamiento que nadie sabe explicar, y los analistas vuelven sin ruido a sus hojas de cálculo. Eso es el pantano de datos, y es un resultado de gobierno, no de tecnología: nadie decidió qué debía estar ahí ni quién respondía por ello.

Un dominio es la forma de partir el gobierno en trozos lo bastante pequeños para tener dueño. Cliente, producto, proveedor, empleado, finanzas, contrato: cada uno es un cuerpo de datos con sus propias definiciones, sus propios sistemas de registro, su propia exposición regulatoria y su propio dueño natural en algún lugar del negocio. Los dominios son la unidad sobre la que se construye casi todo modelo operativo, porque "quién es dueño de los datos" es una pregunta sin respuesta y "quién es dueño de los datos de cliente" no lo es.

En la práctica. Los buenos dominios siguen al negocio, no al organigrama ni a la base de datos. Son pocos —entre ocho y quince a escala empresarial— y cada uno tiene exactamente un dueño responsable, un sistema de registro y una lista de elementos de datos críticos. La prueba de un límite es si un campo en disputa tiene un hogar evidente.

Dónde se rompe. Los dominios se dibujan alrededor de los sistemas, así que "datos de Salesforce" se convierte en dominio y el registro de cliente que también vive en facturación y en soporte tiene tres dueños y ninguno. También se dibujan demasiado pequeños: cuarenta dominios significan cuarenta dueños, lo que significa que nadie responde de verdad y que el consejo no cabe en una sala.

Bien entendido, esto no es un sistema que contenga todos los datos. Es una decisión por atributo: el sistema de RRHH es autoritativo para la situación laboral, el CRM para las preferencias de contacto, el ERP para el importe facturado. En cualquier otro sitio puede haber una copia, pero en ningún otro sitio puede discrepar y ganar. Escrito atributo por atributo, esto es uno de los artefactos más valiosos que produce un programa de gobierno.

En la práctica. Declara la fuente autoritativa de los veinte atributos que aparecen en los informes en disputa y exige que los sistemas de abajo se concilien contra ellos. Es una decisión de gobierno con una consecuencia técnica, en ese orden.

Dónde se rompe. La expresión se convierte en la justificación para consolidar todo en una única plataforma, que es un programa de varios años con un historial pobre. No necesitas un sistema; necesitas una respuesta por atributo. Son presupuestos muy distintos, y solo el segundo resuelve de verdad la discusión de la reunión.

Dos direcciones, un mismo conjunto de preguntas de gobierno. Hacia dentro, compras: datos demográficos, firmográficos, scoring de crédito, geoespaciales, meteorología, series de mercado, sea a través de un bróker o de un exchange como Snowflake Marketplace o AWS Data Exchange. Hacia fuera, publicas: compartes con socios o vendes un agregado que solo tu compañía puede producir. En ambos casos el dato cruza la frontera donde acaban tus controles y empieza un contrato.

En la práctica. El dato que entra recibe el mismo trato que el interno más una licencia: un dueño interno con nombre, una procedencia documentada, controles de calidad a la llegada y condiciones explícitas sobre lo que puedes hacer con él — si puede entrenar un modelo, si puede redistribuirse a un cliente, qué pasa con los datos derivados cuando termina la suscripción. Lo que sale no sale sin el DPO y legal por escrito: qué base legal cubre la cesión, qué agregación o anonimización se aplica y quién responde si un socio lo usa más allá del acuerdo.

Dónde se rompe. Un fichero comprado con tarjeta de crédito se cruza en producción y, dieciocho meses después, nadie sabe su origen, su licencia ni si el contrato sigue vivo — pero tres informes regulatorios dependen de él. En el sentido contrario, el acuerdo se cierra en lo comercial y la revisión de privacidad llega después de la primera entrega, que es el orden más caro posible.

Un catálogo te dice que el dato existe. Un marketplace te lo entrega. La diferencia es la caja: una ficha que puedes solicitar, una aprobación que llega a la persona responsable y un acceso que aparece en horas y no después de un trimestre de correos. Importa porque la alternativa no es "la gente espera": es que un analista que no consigue el dataset certificado en un plazo razonable lo reconstruye mal desde un extracto de origen, y ahora la compañía tiene dos versiones de los ingresos.

En la práctica. Cada ficha es un producto de datos, no una tabla: tiene dueño, una descripción en lenguaje de negocio, un contrato que cubre esquema y frescura, una puntuación de calidad visible, cifras de uso y de coste, y un flujo de solicitud que termina en un rol concedido y no en un ticket. Quien consume puede ver quién más lo usa y qué cambió el mes pasado. La medida de si funciona es el tiempo medio entre la solicitud y el acceso, y si ese número está en los objetivos de alguien.

Dónde se rompe. El marketplace se lanza volcando dentro el almacén completo —diez mil tablas, sin dueños, sin contratos— y se convierte en un buscador más lento. O el escaparate es real pero la solicitud cae en una cola sin nivel de servicio, lo que enseña a todo el mundo que el atajo es más rápido. Un marketplace con cincuenta productos de verdad gobernados vale más que uno con todo y nadie detrás.

Un pipeline es la fontanería entre un sistema de origen y un informe, un modelo u otro sistema: ingerir, validar, transformar, cargar y repetir según un calendario. Construir y operar pipelines es trabajo de gestión de datos. El gobierno de datos no los escribe, pero decide lo que deben respetar: qué fuente es la autoritativa, qué campos están clasificados, qué tolerancia de calidad aplica y a quién hay que avisar cuando algo cambia aguas arriba.

En la práctica. El fallo peligroso casi nunca es la caída. Un pipeline que se detiene lanza una alerta y alguien lo arregla antes de comer. El que sigue funcionando con un nulo donde no toca o un código de moneda equivocado convierte en silencio un registro malo en un agregado malo y después en una decisión mala. Los controles van en cada etapa crítica, no solo al final, y un control fallido sobre datos críticos debería detener la ejecución o mandar los registros a cuarentena, no dejarlos pasar con un aviso.

Dónde se rompe. Cada equipo construye su propio pipeline desde la misma fuente, cada uno con una lógica ligeramente distinta, y nadie es dueño de las diferencias. Luego cambia un esquema aguas arriba sin previo aviso, la mitad de los pipelines se rompen sin ruido y la discrepancia la descubre un auditor. Arreglar el pipeline es gestión. Decidir a quién hay que avisar antes de cambiar el esquema es gobierno.

Tratar los datos como un producto significa que alguien responde de que sus consumidores estén satisfechos, no solo de que el pipeline se ejecute. Eso implica documentación, una interfaz estable, una frecuencia de actualización declarada, garantías de calidad, una vía para notificar problemas y un plan para cambiarlo sin romper a quien está más abajo. Es la misma disciplina que un equipo de software aplica a una API, aplicada a una tabla.

En la práctica. Un producto de datos solo es un producto si tiene consumidores con nombre. Dos equipos que dependen de él, con una actualización acordada y una vía para quejarse, es suficiente. Sin consumidores tienes un conjunto de datos con papeleo extra.

Dónde se rompe. Todas las tablas existentes se reetiquetan como productos de datos sin ningún cambio en propiedad, documentación o compromiso. Renombrar no crea responsabilidad. La prueba es simple e implacable: si la carga falla un domingo, ¿hay alguien que no sea el equipo de plataforma que lo sepa, le importe y tenga una obligación declarada de responder?

Un silo se forma cuando, en algún momento, conseguir la información compartida de forma central era más difícil que reconstruirla en local. Ventas tiene su lista de clientes, finanzas otra, logística una tercera. Nadie se propuso crear un silo; cada uno fue un atajo razonable. El coste visible es el esfuerzo duplicado. El coste caro es que las copias divergen, tres cuadros de mando dan tres respuestas a la misma pregunta y nadie sabe decir cuál es la buena.

En la práctica. La respuesta del gobierno de datos no es "consolidarlo todo": eso es un programa de plataforma de varios años, no un acto de gobierno. Es nombrar la fuente autoritativa de cada entidad compartida, declarar derivadas las demás copias y publicar esa decisión en un sitio donde la gente la encuentre de verdad. Un catálogo de datos ayuda. La decisión importa más que la herramienta.

Dónde se rompe. Los silos se tratan como un problema tecnológico y se responden con una migración. Los datos se mudan a una sola plataforma, las definiciones se mudan con ellos sin cambios y la organización tiene ahora los mismos silos en un único sitio más caro. Un silo se acaba con una decisión sobre autoridad, no con un cambio de dirección.

Un dominio es donde vive la responsabilidad; un subdominio es donde el trabajo cabe de verdad en la cabeza de alguien. Cliente es un dominio, y es demasiado grande para un solo glosario: prospectos, consentimiento y preferencias, reclamaciones, situación crediticia y fidelización tienen definiciones distintas de "activo", reglas distintas, sistemas distintos y personas distintas a las que les importa. Partir Cliente en subdominios permite gobernar bien cada una de esas piezas sin inventar cinco dominios nuevos y cinco dueños nuevos en el organigrama.

En la práctica. Sabes que necesitas uno cuando un único steward no puede responder preguntas de todo el dominio, o cuando la misma palabra necesita dos definiciones dentro de él. Un subdominio tiene un steward con nombre, sus propias entradas en el glosario de negocio, sus propios elementos críticos y reglas de calidad, y suele ser la unidad desde la que realmente se construyen y publican los productos de datos. El dueño del dominio sigue respondiendo por el conjunto; el steward del subdominio opera una parte.

Dónde se rompe. Subdividir hasta que el catálogo es una copia de la estructura de reporte. Cincuenta subdominios son cincuenta glosarios medio mantenidos, y la reorganización del año que viene los invalida todos. Divide cuando una definición o un dueño te obliguen, no para que el diagrama parezca completo.