El gobierno de datos se diseña dentro de la organización

🌐 También en 28 idiomas

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Français (Canada) · Deutsch (Schweiz)

Imagen generada con IA

Traducido con IA. Aún no revisado por la comunidad. Leer en inglés

Módulo 1 de 6 del capítulo Calidad y gobierno de datos, capítulo 5 del curso Data Architect. Cada módulo se sostiene por sí solo. Siguiente: Mantener fuera los datos malos

La pregunta que responde este módulo: ¿Qué significa el gobierno de datos para un arquitecto, y quién hace qué?

Cuando la gente oye gobierno de datos, piensa en reuniones: comités, políticas, estándares, un documento que explica quién debe hacer qué con los datos. Todo eso puede formar parte de un programa de gobierno. Como arquitecto, me interesa otra pregunta: ¿dónde se hace cumplir la política?

Si la política dice que solo Finanzas puede cambiar un campo, ¿qué lo hace cumplir? Si dice que el ERP es dueño del registro legal del cliente, ¿qué impide que alguien en Salesforce lo cambie? Si dice que los equipos ven la dirección de un destinatario solo para sus propias paradas, solo ese día, ¿qué hace que eso sea realmente cierto? Si dice que esto se conserva siete años, ¿qué lo archiva o lo elimina pasados los siete? Una política sin un punto de cumplimiento es casi solo un deseo. El gobierno de datos se convierte en arquitectura cuando esas decisiones se construyen dentro del sistema.

El gobierno de datos nunca termina

Déjame aclararlo pronto: el gobierno de datos no se termina. Lo he visto ir en flujos y reflujos. Una empresa pone atención de verdad en la calidad de los datos, y las cosas mejoran. La atención se va a otra parte, y la calidad baja. Entra en funcionamiento una integración nueva, una unidad de negocio cambia su proceso, alguien importa un archivo, la empresa adquiere otra, un agente empieza a escribir registros, y el problema vuelve a cambiar. El objetivo no es un estado mítico en el que cada registro es perfecto para siempre. Es mantener los datos lo bastante confiables para el negocio y mantener fuera lo peor de los datos malos. Es un trabajo continuo.

Cuando Salesforce está prácticamente solo, gobernar significa limpiar los datos en un solo lugar. Cuando es un nodo del panorama del capítulo 4, se vuelve más difícil, y más necesario. Ahora el cliente vive en Salesforce, el ERP, el almacén de datos, los sistemas de los socios, Data 360. ¿Quién es su dueño? ¿Quién puede cambiarlo? ¿Qué copia es la referencia, qué atributos pueden moverse, cuánto tiempo se conservan y quién responde cuando están mal? No son preguntas de configuración. Son preguntas de gobierno que se convierten en configuración.

El propietario del registro no es el dueño de los datos

Empieza por la palabra propietario, porque Salesforce la vuelve confusa. Abre una cuenta y ves un Propietario: un representante de ventas, por ejemplo. ¿Es el representante dueño de los datos del cliente? No necesariamente. En Salesforce, un registro de un objeto con propietario pertenece a un usuario o a una cola; el propietario tiene acceso total, y el propietario determina la asignación y el uso compartido a través de la jerarquía de funciones y las reglas de uso compartido (Sharing and Record Access Features (opens in a new tab), en inglés). Eso es la propiedad del registro: un mecanismo de la plataforma.

El dueño de los datos es otra cosa: la persona o la función que responde por los datos como activo del negocio. Finanzas puede ser dueña de la información legal del cliente, Operaciones del estado de las entregas, Recursos Humanos de los datos de los empleados. Salesforce incluso te da un lugar donde registrarlo: el campo de clasificación Data Owner (dueño de los datos) en cada campo (Data Classification Metadata Fields (opens in a new tab), en inglés).

En Steve Trucking, la cuenta de un socio minorista puede ser propiedad del ejecutivo de ventas que gestiona a ese socio. Pero la identidad legal del socio la gobierna Finanzas y se mantiene como dato maestro en el ERP de finanzas. Ventas, servicio, operaciones y el portal de socios necesitan la cuenta; nada de eso significa que el ejecutivo de ventas deba cambiar la identidad legal del socio una vez que Finanzas la ha establecido. He visto equipos mirar el campo Propietario y suponer que resolvieron la propiedad de los datos. No es así. La asignación de registros no es la responsabilidad del negocio.

Dueño, responsable, custodio

Tres roles de gobierno, tres trabajos distintos.

El dueño de los datos fija la política. Responde qué significan los datos, quién puede crearlos y cambiarlos, qué tan exactos tienen que ser, cuánto tiempo se conservan, quién puede verlos, qué sistema es la referencia y qué pasa cuando están mal. El arquitecto no debería inventarse esas respuestas. Es una de mis posiciones más firmes: los dueños fijan la política; los arquitectos la hacen cumplir. Si Finanzas dice que el nombre legal solo puede cambiar a través del proceso del ERP una vez que el cliente está activo, esa es una decisión de gobierno. Hacerla mecánicamente cierta es mi trabajo.

El responsable de los datos (data steward) los mantiene funcionando. El responsable está cerca de la salud diaria de los datos: vigila las señales de calidad, investiga los duplicados, resuelve las excepciones, coordina los arreglos, mantiene las definiciones, detecta el proceso que no deja de producir datos malos. Hay dos tareas más que recaen en el responsable. Cuando dos equipos no están de acuerdo sobre lo que significa un campo, quién es su dueño o quién puede verlo, el responsable lleva la disputa al dueño y se asegura de que la decisión se cumpla. Y el responsable construye la alfabetización en datos (data literacy): ayuda a las personas que introducen y usan los datos a entender qué significan y por qué existen las reglas. Un responsable necesita más que un nombre en un organigrama. Necesita tiempo, visibilidad, un proceso y la autoridad para que se arreglen los problemas. Si no, “responsable de datos” se convierte en la octava responsabilidad de alguien, que se mira una vez por trimestre.

El custodio opera el sistema. Administradores, equipos de plataforma, equipos de seguridad: quien opera la tecnología que guarda y procesa los datos. El dueño dice que solo estos roles pueden verlos; el custodio opera los controles que lo hacen así. Los nombres importan menos que dejar clara cada responsabilidad, y en una organización pequeña una persona puede llevar dos sombreros.

Cómo funciona el programa

Los programas de gobierno de datos suelen tener una de tres formas. Centralizado: un equipo escribe las políticas y los estándares para todos los dominios. Es coherente, y puede convertirse en un cuello de botella, lejos de las personas que hacen el trabajo. Federado (descentralizado): cada dominio, como finanzas, ventas u operaciones, gobierna sus propios datos dentro de unas pocas reglas compartidas. Está cerca del trabajo, y las definiciones se van separando entre dominios. Híbrido: un equipo central pequeño es dueño de los estándares y de las definiciones compartidas, y los dueños y responsables de cada dominio gestionan sus propios datos. La mayoría de las empresas que he visto terminan en algún punto del híbrido. Para el arquitecto, la forma responde una pregunta práctica: ¿quién aprueba una política antes de que yo la haga cumplir, y dónde viven las definiciones compartidas?

Conocimiento para el examen. Conoce las tres formas de gestionar un programa de gobierno de datos, centralizado, federado (descentralizado) e híbrido, y lo que significa cada una para quién fija la política y dónde viven las definiciones compartidas.

Haz que la matriz RACI se gane su lugar

Una matriz RACI (quién es Responsable de hacerlo, quién Aprueba y responde por ello, a quién se Consulta y a quién se Informa) ayuda, pero no una hoja de cálculo gigante hecha porque el gobierno “la exige”. Quiero que responda preguntas de arquitectura, empezando por las tres del capítulo 4 (Las cuatro preguntas detrás de las categorías): ¿dónde se crean los datos, dónde se editan y dónde se referencian? A menudo son sistemas distintos. Toma un producto: el ERP lo crea, Salesforce lo referencia, el portal lo muestra, el almacén de datos lo analiza. Ahora el negocio cambia lo que significa “producto activo”. ¿Dónde empieza el cambio, quién lo aprueba, cómo se propaga y qué copias son de solo lectura? Si no puedes responder, todavía no tienes gobierno. Tienes copias. Una buena matriz RACI deja al descubierto exactamente esa ambigüedad.

El gobierno de datos tiene que volverse mecánico

El negocio dice que solo Finanzas puede cambiar el nombre legal del cliente. No quiero que la respuesta de arquitectura sea “lo cubriremos en la formación”. La formación ayuda; no es cumplimiento. Quizá sea el acceso a nivel de campo, una regla de validación, un campo que solo escribe la integración o un proceso controlado en lugar de ediciones directas. El mecanismo depende del requisito, pero tiene que haber uno:

Política de gobierno	Decide el dueño	Posible punto de cumplimiento
El ERP es dueño de la identidad legal del cliente	Finanzas	Campos solo de integración, permisos, validación
Solo las personas que lo necesitan ven los datos personales	Privacidad, seguridad	Uso compartido, permisos, acceso a campos
Los identificadores de cliente son únicos	Dueño del negocio	ID externo único, reglas de duplicados
Los registros gobernados no se crean a mano	Dueño de los datos	Permisos, automatización, integración
Los datos sensibles tienen un período de retención fijado	Privacidad, legal	Un proceso de retención o de eliminación
Los cambios importantes tienen que poder demostrarse	Cumplimiento	Historial de campos, pista de auditoría
El origen de los datos sigue siendo identificable	Dueño de los datos	Un campo de origen, metadatos de linaje

Digo posible punto de cumplimiento a propósito. No es una tabla para elegir funciones. Es el orden del pensamiento: ¿cuál es la política, quién es su dueño y qué hace que sea cierta en la arquitectura?

Click to enlarge

Los dueños fijan la política; los arquitectos la hacen cumplir.

No confíes en el buen comportamiento

“Nunca cambies el ID de cliente del ERP”. Todos lo saben, hasta que alguien lo hace: por accidente, mediante una carga de datos, mediante la automatización, mediante una integración, mediante un agente. Si cambiarlo dañaría los datos de la empresa, “por favor, no lo hagas” no es el control. Construye el control. Confía, pero verifica. Las personas, las integraciones, la automatización y la IA cometen errores, así que la arquitectura debería suponer que, tarde o temprano, algo intentará lo que la política prohíbe. ¿Qué pasa entonces?

El gobierno de datos cruza las fronteras entre sistemas

Vuelve al panorama. El ERP es dueño del cliente; Salesforce, el almacén de datos y una plataforma de datos de clientes guardan copias; un socio recibe una parte. ¿A qué sistema se aplica la política? A todos. Salesforce puede bloquear correctamente un cambio del nombre legal mientras una integración deja que un sistema posterior lo sobrescriba. Salesforce puede eliminar datos personales que el almacén de datos sigue guardando. Un campo clasificado como sensible en Salesforce puede acabar en un campo de texto sin clasificar en otro lugar. El gobierno no puede detenerse en el borde de la organización, porque los datos no se detienen ahí. Por eso el capítulo 4 vino primero: el panorama te dice hasta dónde tiene que llegar el gobierno.

Gobierna lo suficiente, no todo

El fallo contrario es igual de real. Descubrimos que el gobierno importa, así que lo bloqueamos todo: nadie puede crear nada, cada cambio necesita aprobación. Los datos están gobernados, y nadie puede hacer su trabajo. Gobernar significa el control adecuado para los datos: estricto para unos, ligero para otros. Algunos registros se pueden crear libremente, otros necesitan aprobación; algunos campos los puede editar casi cualquiera, otros solo la integración. El próximo módulo se pone práctico justo con eso.

Y como el gobierno nunca termina, el cumplimiento necesita retroalimentación. ¿Están aumentando los duplicados? ¿Los campos obligatorios se llenan de basura? ¿Fallan las integraciones, los usuarios encuentran atajos, crecen las excepciones, los responsables pasan todo el día con un solo problema? Esas señales te dicen si el diseño funciona y, a veces, que el control, o la política, tiene que cambiar.

Más allá del examen: lo que cambia la IA. El gobierno de datos tiene un nuevo consumidor: el agente. El dueño de los datos sigue decidiendo qué puede usarse y para qué; el arquitecto sigue haciéndolo cumplible. Lo que cambia es la velocidad y la escala. Un agente lee, combina y actúa sobre datos gobernados mucho más rápido que una persona, así que una política que existe solo en un documento protege todavía menos.

Lo que decide aquí un arquitecto

• Quién responde por cada dominio de datos importante, y en qué se diferencia eso de la propiedad del registro.
• Quién es el responsable de los datos y quién los opera como custodio.
• Dónde se crean, se editan, se referencian y se mantienen como datos maestros los datos importantes en todo el panorama.
• Qué punto de cumplimiento hace mecánicamente cierta cada política importante.
• Cómo muestra la arquitectura si el gobierno funciona, o si empieza a deslizarse.

Cuando oigo un requisito de gobierno, lo traduzco. “El ERP es dueño de esto”. “Solo estas personas pueden ver esto”. “Necesitamos demostrar quién cambió esto”. “Conserva esto siete años”. Cada vez: muéstrame el punto de cumplimiento. El arquitecto no decide la política. Diseñamos el sistema que la hace cumplir. Ahí es donde el gobierno deja de ser un documento y se convierte en arquitectura.

Explora

• Ayuda de Salesforce, Sharing and Record Access Features (opens in a new tab) (en inglés), consultado el 2026-10-14.
• Ayuda de Salesforce, Data Classification Metadata Fields (opens in a new tab) (en inglés), consultado el 2026-10-14.