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

🌐 También en 28 idiomas

English · 日本語 · 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 · Español (México) · Français (Canada) · Deutsch (Schweiz)

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

Capítulo 5 de Data Architect, Parte 1: Convertirse en Data Architect. Anterior: Entender los datos de la empresa.

Di “gobierno de datos” y la gente se imagina reuniones: comités, políticas, un documento que nadie lee. Yo hago siempre otra pregunta: ¿dónde se hace cumplir la política?

Si la política dice que solo Finanzas puede cambiar el nombre legal del cliente, ¿qué impide que lo haga otra persona? 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 cierto? Si dice que esto se conserva siete años, ¿qué lo elimina pasados los siete? Una política sin un punto de cumplimiento es casi solo un deseo. Mi posición es sencilla: los dueños fijan la política; los arquitectos la hacen cumplir. El dueño de los datos decide. El sistema que diseña el arquitecto lo hace mecánicamente cierto.

Y no esperes terminar. El gobierno de datos nunca termina. Va en flujos y reflujos, manteniendo fuera lo peor de los datos malos. Es sencillo cuando Salesforce está solo, y más difícil, y más necesario, cuando Salesforce es un nodo del panorama que dibujamos en el capítulo 4. Por eso ese capítulo vino primero: el panorama te dice hasta dónde tiene que llegar el gobierno.

Imagen generada con IA.

Las posiciones de este capítulo

• Gestiona el programa como funciona la empresa: centralizado, federado o híbrido; el arquitecto necesita saber quién aprueba una política.
• El propietario del registro no es el dueño de los datos. El campo Propietario determina la asignación y el acceso; la responsabilidad sobre los datos vive en el negocio.
• Que la creación sea abierta o cerrada depende del gobierno que rodea a los datos. Abierta está bien para la mayoría de las organizaciones pequeñas y medianas; ciérrala cuando las cuentas se mantienen como datos maestros en un ERP o se sincronizan con él; el camino intermedio es un tipo de registro provisional con una conversión controlada al tipo gobernado.
• Si el ERP gestiona un campo como maestro, no lo estás cambiando, estás pidiendo que lo cambien. El golden record es un híbrido: los campos maestros del ERP entran, los campos propios de Salesforce nunca vuelven, y los flujos bidireccionales necesitan una regla de colisión.
• Clasifica los campos sensibles, no todos los campos. Documenta ampliamente; clasifica con intención; conserva tanto los metadatos de negocio como los técnicos.
• Enseña las regulaciones. Muchos arquitectos nunca han oído hablar de las leyes de fuera de su región, y estas leyes dan forma al diseño de los sistemas.
• Usa el modelo de consentimiento estándar siempre que puedas, en lugar de reconstruirlo.
• Para el derecho al olvido, controla primero adónde van los datos personales. El borrado es poco frecuente y difícil; diseña para que los datos personales lleguen a pocos lugares y luego persigue cada copia: el historial de campos, los archivos, las copias de analítica, los índices de búsqueda y las conversaciones de los agentes, antes de que se acabe el plazo.
• Shield es la respuesta para requisitos regulatorios clave como el cifrado en reposo, con compensaciones para las que hay que diseñar.
• Field Audit Trail cuando hay regulación. El historial de campos estándar es lo predeterminado.
• Configura Event Monitoring antes de necesitarlo, y envía los eventos a un repositorio como Splunk. No quieres toparte con un problema y descubrir entonces que no los estabas capturando.

El ciclo de vida gobernado de los datos

Click to enlarge

Siete preguntas a lo largo de la vida de los datos. Las herramientas apoyan la política; no la definen.

El recorrido de este capítulo

Seis módulos, cada uno se sostiene por sí solo.

1. El gobierno de datos se diseña dentro de la organización. Dueños, responsables y custodios; centralizado, federado o híbrido; propietario del registro frente a dueño de los datos; convertir cada política en un punto de cumplimiento.
2. Mantener fuera los datos malos. “Suficientemente bueno” como definición del negocio; creación abierta frente a cerrada, el registro provisional y un tipo de registro para cada flujo; el golden record híbrido y las bidireccionales; una decisión de calidad en cada frontera de datos.
3. Conoce tus datos: diccionario, linaje y clasificación. Metadatos de negocio y técnicos; qué significan, de dónde vienen, cómo hay que tratarlos, y por qué la clasificación sin cumplimiento es decoración.
4. Las leyes de privacidad dan forma al diseño. Las leyes que hay que reconocer, lo que tienen en común (derechos, transferencias, notificación de brechas, responsabilidad proactiva) y las preguntas que las sobreviven; anonimizado frente a seudonimizado; el cumplimiento no es un producto.
5. El consentimiento y el derecho al olvido. El consentimiento como datos, el modelo de consentimiento estándar, el plazo de cada solicitud y diseñar el borrado antes de que llegue la primera.
6. Proteger, conservar y demostrar. Las compensaciones del cifrado, los sandboxes, la retención, el historial de campos y Field Audit Trail, y Event Monitoring configurado antes de necesitarlo.

Cuando termines, ponte a prueba con la guía de estudio del capítulo: una lista de verificación para el examen, los hábitos que van más allá, las palabras que conviene conocer y algunas preguntas.

Lo que decide aquí un arquitecto

• Quién es dueño de cada dominio de datos importante, y qué hace cumplir la política de cada dueño.
• Qué datos malos se mantienen fuera, y qué se detecta, se pone en cuarentena y se arregla después.
• Qué campos son sensibles, y qué cambia esa clasificación.
• Adónde van los datos personales, para qué pueden usarse y cómo se eliminan de cada copia.
• Cuánto tiempo se conservan los datos y su historial, y qué evidencia existe para demostrar lo que pasó.

Este capítulo es orientación de arquitectura, no asesoramiento legal. Los equipos legales y de cumplimiento deciden qué leyes aplican y qué exigen; el arquitecto convierte esos requisitos en diseño.

Más allá del examen: el gobierno de datos tiene un nuevo consumidor, el agente. La clasificación decide qué puede recuperar, el consentimiento decide para qué puede usar los datos, y el linaje y la auditoría tienen que llegar hasta lo que dijo e hizo. Cada módulo termina con lo que la IA cambia en su parte del ciclo de vida.

Explora

• Ayuda de Salesforce, Data Classification Metadata Fields (opens in a new tab) (en inglés), consultado el 2026-10-14.
• Ayuda de Salesforce, Understand the Salesforce Consent Data Model (opens in a new tab) (en inglés), consultado el 2026-10-14.
• Reglamento (UE) 2016/679 (RGPD/GDPR) (opens in a new tab), EUR-Lex, consultado el 2026-10-14.

Siguiente: Datos maestros e identidad