Ir al contenido

Calidad y gobierno de datos

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)

An open sketchbook on a drafting table at dawn, a building sketched on one page and a data model on the other, with a pencil, an eraser, a cup and a lamp.
Imagen generada con IA

Guía de estudio del capítulo 5 del curso Data Architect. Lee primero los seis módulos; esta página te ayuda a comprobar lo que te quedó.

Sobre esta guía de estudio. Está construida solo con el contenido de este curso y con la lista de objetivos publicada en la guía del examen de Salesforce. Nunca se basa en preguntas reales del examen, y no pretende saber qué hay en el examen. Si ya hiciste el examen, por favor no me envíes preguntas: el acuerdo de certificación prohíbe compartirlas, y memorizar respuestas es, de todos modos, la forma equivocada de convertirse en arquitecto.

Este capítulo lleva la sección Data Governance del examen (10 %) y partes de Data Modeling (metadatos) y de Salesforce Data Management (consistencia). También es donde la ley de privacidad se encuentra con el modelo de datos. Es arquitectura, no asesoramiento legal: el área legal decide qué aplica, y el arquitecto lo hace cumplible. Los números de la plataforma cambian, así que comprueba los actuales antes de confiar en ellos.

Márcalos a medida que avanzas. Cada uno enlaza con el lugar donde se enseña.

GOV-2: diseñar un programa de gobierno de datos

  • Sé que el propietario del registro (un mecanismo de la plataforma para el acceso) no es el dueño de los datos (que responde por los datos como activo del negocio), y que cada campo puede registrar un Data Owner. (El propietario del registro no es el dueño de los datos)
  • Puedo distinguir al dueño de los datos (fija la política), al responsable de los datos (los mantiene funcionando) y al custodio (opera el sistema). (Dueño, responsable, custodio)
  • Conocimiento para el examen: conozco 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. (Cómo funciona el programa)
  • Puedo usar una matriz RACI para responder dónde se crean, se editan y se referencian los datos. (Haz que la matriz RACI se gane su lugar)
  • Puedo nombrar un punto de cumplimiento para una política de gobierno (permisos, validación, campos solo de integración, historial de campos), no solo la formación. (El gobierno de datos tiene que volverse mecánico)
  • Sé que las señales de calidad que vale la pena medir son aquellas sobre las que alguien va a actuar. (Mide aquello sobre lo que alguien va a actuar)

SDM-2 y MDM-4: mantener fuera los datos malos

DM-3: metadatos de negocio y técnicos

  • Conocimiento para el examen: distingo los metadatos de negocio (significado, definiciones, dueño, reglas, sensibilidad) de los metadatos técnicos (objetos, campos, tipos, nombres de API, esquemas, asignaciones, linaje). (Dos tipos de metadatos)
  • Sé la diferencia entre un diccionario de negocio (qué significa), el linaje (de dónde vino) y la clasificación (cómo hay que tratarlo). (Conoce tus datos)
  • Conozco los campos de clasificación de Salesforce: Data Owner, Field Usage, Data Sensitivity Level, Compliance Categorization, en campos estándar y personalizados. (La clasificación responde otra pregunta)
  • Sé que hay que clasificar los campos sensibles, no todos los campos, y que la clasificación sin cumplimiento es decoración. (La clasificación sin cumplimiento es decoración)

GOV-1: datos personales y sensibles

  • Reconozco las principales leyes (RGPD, CCPA/CPRA, PIPEDA, LGPD, la Privacy Act de Australia, HIPAA, PCI DSS, SOX, COPPA), sé que el RGPD puede alcanzar a organizaciones de fuera de la UE, y sé lo que las leyes tienen en común: derechos, transferencias, notificación de brechas y responsabilidad proactiva. (Las regulaciones que deberías reconocer, Las leyes no se detienen en la frontera)
  • Sé la diferencia entre cifrado, enmascaramiento, seudonimización y anonimización, y que los datos seudonimizados siguen siendo datos personales. (Anonimizado, seudonimizado, cifrado, enmascarado)
  • Sé que recopilar menos es un control de privacidad, y que la retención se diseña desde el principio. (Recopilar menos es una decisión de arquitectura, La retención es parte del modelo)
  • Conozco el modelo de datos de consentimiento: el consentimiento global en el objeto Individual, el consentimiento por canal de interacción, el consentimiento por punto de contacto y el propósito de uso de los datos. (Usa el modelo que Salesforce ya construyó)
  • Sé que las solicitudes tienen plazos (RGPD: un mes, ampliable otros dos), así que el mapa de copias tiene que existir antes. (El reloj está corriendo)
  • Sé que el derecho al olvido significa encontrar cada copia (historial, archivos, analítica, logs, archivos adjuntos, texto libre), y que las políticas de Privacy Center se ejecutan por objeto sobre un registro de cliente. (Ahora la persona dice: olvídame, Privacy Center es una herramienta)
  • Conozco las compensaciones de Shield Platform Encryption: los campos probabilísticos no se pueden filtrar, agrupar ni ordenar en SOQL; el cifrado determinista permite filtrar; los campos cifrados no pueden determinar el uso compartido basado en criterios. (El cifrado es un control, no el cumplimiento)
  • Sé que no hay que copiar los datos sensibles de producción a los sandboxes, y que Data Mask se está reemplazando por Data Mask & Seed. (No copies el riesgo de producción al sandbox)
  • Conozco el seguimiento del historial de campos (hasta 20 campos por objeto; 18 meses, 24 solo a través de la API; en texto largo solo registra la edición) frente a Field Audit Trail (hasta 200 campos, conservados hasta que los eliminas). (El historial también son datos)
  • Conozco la retención de los registros de Event Monitoring (1 día sin el complemento para algunos eventos, 30 días de forma predeterminada con él, hasta 365 ampliada), y que hay que exportar los eventos a un SIEM antes de necesitarlos: los registros de pago no se pueden recuperar de antes del inicio del contrato. (Auditar y monitorear no son lo mismo)

El examen es el piso, no el techo. Estos son los hábitos de este capítulo que necesita un arquitecto, los pregunte o no el examen.

  • Una política sin un punto de cumplimiento es casi solo un deseo.
  • Los dueños fijan la política; los arquitectos la hacen cumplir. No te inventes la política, y no hagas de abogado.
  • El gobierno de datos nunca termina. Va en flujos y reflujos; diseña la retroalimentación.
  • No confíes en el buen comportamiento. Construye el control: las personas, las integraciones y los agentes cometen errores.
  • Gobierna lo suficiente, no todo.
  • Evita primero los errores costosos. Un duplicado con dos años de historial es un problema grande.
  • Distingue lo que leen las personas de aquello con lo que deciden las máquinas.
  • Documenta en amplitud; clasifica de forma deliberada.
  • Los datos sensibles más baratos de gobernar son los que nunca copiaste.
  • El consentimiento son datos, y el permiso para usar los datos tiene que poder representarse como datos.
  • Controla primero adónde van los datos personales, porque la eliminación es rara y difícil.
  • El cumplimiento no es un producto.
  • Capturar → Clasificar → Proteger → Usar → Conservar → Eliminar → Auditar.
  • Captura la evidencia antes de que nadie la pida.
TérminoEn una línea
Gobierno de datosLas políticas sobre los datos, y la arquitectura que las hace ciertas
Dueño de los datosLa persona o la función que responde por un tipo de datos
Responsable de los datos (data steward)La persona que mantiene sanos los datos día a día
CustodioEl equipo que opera los sistemas que guardan los datos
RACIResponsable, Aprobador (quien responde), Consultado, Informado
Registro provisionalUn registro creado antes de que el sistema con la autoridad lo haya aceptado
Diccionario de negocioDefiniciones acordadas de los términos importantes del negocio
LinajeDe dónde vino un valor y qué le pasó por el camino
Clasificación de datosEtiquetar los datos por confidencialidad y categoría de cumplimiento para que reciban los controles adecuados
TaxonomíaEl conjunto de etiquetas que usa una organización para clasificar los datos
Datos personalesInformación que identifica a una persona, o que puede vincularse con una
SeudonimizaciónReemplazar los identificadores mientras sigue existiendo un camino de vuelta; siguen siendo datos personales
AnonimizaciónEliminar la capacidad razonable de identificar a la persona
Modelo de datos de consentimientoLos objetos de Salesforce para el consentimiento por persona, canal, punto de contacto y propósito
Derecho al olvidoEl derecho de una persona, donde la ley lo otorga, a que se borren sus datos personales
Golden record híbridoUn registro con los campos del sistema maestro y los campos propios de Salesforce, cada uno con un único origen
Metadatos de negocio / técnicosQué significan los datos y quién es su dueño / cómo se construyen y se mueven
Field Audit TrailHistorial de campos más largo: hasta 200 campos por objeto, conservado hasta que se elimina
Event MonitoringRegistros de inicios de sesión, exportaciones, llamadas a la API y visualizaciones, conservados por un tiempo limitado
SIEMUn repositorio de seguridad donde se guardan y se analizan los registros de eventos

Escenarios cortos al estilo del curso. Decide tu respuesta antes de abrirla.

1. La política dice que solo Finanzas puede cambiar el nombre legal de un cliente. El equipo planea cubrirlo en la formación. ¿Qué falta?

Un punto de cumplimiento. La formación no es un control: usa el acceso a nivel de campo, un campo que solo escribe la integración, una regla de validación o un proceso controlado. Los dueños fijan la política; el arquitecto la hace mecánicamente cierta. Vuelve a leer El gobierno de datos tiene que volverse mecánico.

2. Los clientes se mantienen como datos maestros en el ERP. Los representantes de ventas necesitan empezar a vender a los nuevos prospectos de inmediato. ¿Cómo se lo permites sin que dos sistemas creen el registro maestro?

Deja que los representantes creen la cuenta con un tipo de registro provisional, y luego conviértela mediante un proceso controlado: Finanzas la aprueba, o la integración la envía al ERP, que empareja o crea el cliente y devuelve el ID de referencia. Vuelve a leer El camino intermedio.

3. Un campo obligatorio nuevo se llena de "N/A" y "999999". ¿Qué pasó, y qué harías en su lugar?

Se obligó a los usuarios a responder antes de saber la respuesta. Exígelo más adelante en el proceso, deja que lo aporte otro sistema, usa un estado provisional o permite un Desconocido explícito cuando esa es una respuesta real. Vuelve a leer No dejes que los campos obligatorios creen datos falsos.

4. El equipo reemplazó los nombres por tokens y dice que los datos están anonimizados, así que la solicitud de eliminación está resuelta. ¿Lo está?

No si los tokens pueden vincularse de nuevo con la persona: eso es seudonimización, y los datos siguen siendo personales. Di exactamente qué hace el sistema, dónde vive el mapeo, y deja que el área legal decida si cumple el requisito. Vuelve a leer Anonimizado, seudonimizado, cifrado, enmascarado.

5. Un destinatario acepta mensajes de texto sobre la entrega pero no de marketing. ¿Cómo debería guardarlo el modelo?

Con el modelo de datos de consentimiento, no con una sola casilla: la persona, el canal (SMS), el número concreto y el propósito de uso de los datos (avisos de entrega, no marketing). Y decide qué sistema es la referencia para el consentimiento, para que una retirada llegue a cada sistema que actúa sobre él. Vuelve a leer Usa el modelo que Salesforce ya construyó.

6. Cumplimiento necesita filtrar informes por un campo cifrado de número de Seguro Social. El campo usa el esquema de cifrado predeterminado. ¿Cuál es el problema?

El cifrado probabilístico no permite filtrar en las cláusulas WHERE de SOQL ni en los filtros de gestión de datos. El cifrado determinista permite filtrar con un pequeño costo en solidez. El cifrado es una decisión de diseño con compensaciones, no una casilla al final. Vuelve a leer El cifrado es un control, no el cumplimiento.

7. Seis meses después de un incidente, alguien pregunta quién exportó un conjunto de registros. Nadie configuró el almacenamiento de Event Monitoring. ¿Qué puedes decirle?

Probablemente nada: los registros de eventos se conservan un tiempo limitado (como mucho un año, incluso ampliado), así que todo lo anterior ha desaparecido a menos que se exportara. Configura Event Monitoring y envía los eventos a un SIEM antes de necesitarlos. Vuelve a leer Auditar y monitorear no son lo mismo.

8. Un representante pide a Salesforce cambiar el nombre legal de un cliente, que el ERP gestiona como maestro. En esos mismos minutos, alguien lo cambia en el ERP. ¿Qué debería decir el diseño?

Que Salesforce estaba pidiendo, no cambiando: el ERP gestiona el campo como maestro. Decide la regla de colisión de antemano (gana el ERP, se rechaza si el valor cambió, o lo resuelve una persona) y si los campos relacionados viajan juntos. Vuelve a leer Protege el registro gobernado.

9. Llega la solicitud de borrado de una persona. El equipo planea empezar a mapear dónde viven sus datos. ¿Cuál es el problema?

El reloj ya está corriendo: con el RGPD, un mes, ampliable otros dos para solicitudes complejas. El mapa de copias tiene que existir antes de que llegue la solicitud. Vuelve a leer El reloj está corriendo.