Qualidade e governança de dados

🌐 Também em 28 idiomas

English · Español · 日本語 · 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)

Imagem gerada com IA

Traduzido por IA. Ainda não revisado pela comunidade. Ler em inglês

Guia de estudo do capítulo 5 do curso Data Architect. Leia primeiro os seis módulos; esta página ajuda você a verificar o que ficou.

Sobre este guia de estudo. Ele foi construído apenas a partir do conteúdo deste curso e da lista de objetivos publicada no guia do exame da Salesforce. Ele nunca se baseia em questões reais do exame e não afirma saber o que cai na prova. Se você já fez o exame, por favor não me envie as questões: o contrato de certificação proíbe compartilhá-las, e decorar respostas é, de qualquer forma, o jeito errado de se tornar arquiteto.

Este capítulo carrega a seção de Governança de Dados do exame (10%) e partes de Modelagem de Dados (metadados) e de Gerenciamento de Dados Salesforce (consistência). É também onde a lei de privacidade encontra o modelo de dados. Isto é arquitetura, não aconselhamento jurídico: o Jurídico decide o que se aplica, e o arquiteto torna isso aplicável. Os números da plataforma mudam, então confira os atuais antes de contar com eles.

Para o exame

Marque conforme avança. Cada item tem um link para onde é ensinado.

GOV-2: projetar um programa de governança

• Sei que o proprietário do registro (um mecanismo da plataforma para acesso) não é o proprietário dos dados (responsável pelos dados como ativo do negócio), e que cada campo pode registrar um Data Owner. (O proprietário do registro não é o proprietário dos dados)
• Consigo distinguir o proprietário dos dados (define a política), o data steward (mantém tudo funcionando) e o custodiante (opera o sistema). (Proprietário, data steward, custodiante)
• Conhecimento para o exame: conheço as três formas de conduzir um programa de governança, centralizada, federada (descentralizada) e híbrida, e o que cada uma significa para quem define a política e onde ficam as definições compartilhadas. (Como o programa funciona)
• Consigo usar uma RACI para responder onde os dados são criados, editados e referenciados. (Faça a matriz RACI merecer seu lugar)
• Consigo nomear um ponto de aplicação para uma política de governança (permissões, validação, campos só da integração, histórico de campos), não só treinamento. (A governança precisa virar mecânica)
• Sei que os sinais de qualidade que vale medir são aqueles sobre os quais alguém vai agir. (Meça aquilo sobre o que alguém vai agir)

SDM-2 e MDM-4: manter os dados ruins do lado de fora

• Consigo decidir se a criação de contas deve ser aberta ou travada, e conheço o caminho do tipo de registro provisório para contas que são mestres num ERP. (Aberta ou travada?, O caminho do meio)
• Consigo proteger atributos governados (um ID do ERP, uma razão social) e ainda deixar editáveis os campos próprios do Salesforce: um golden record híbrido. E sei que um campo somente leitura numa página do Dynamic Forms não é aplicação; a segurança em nível de campo ou uma regra de validação é. (Proteja o registro governado, Um tipo de registro para cada fluxo)
• Sei que os fluxos bidirecionais são os mais difíceis: se o ERP é o mestre de um campo, o Salesforce está pedindo para alterá-lo, e uma colisão precisa de uma regra (o ERP vence, rejeitar se mudou, ou uma pessoa resolve). (Proteja o registro governado)
• Sei que campos obrigatórios podem criar dados falsos (N/A, 999999), e conheço as alternativas. (Não deixe campos obrigatórios criarem dados falsos)
• Consigo decidir o que acontece com os dados de entrada que reprovam nas verificações: aceitar, rejeitar ou colocar em quarentena, e quem é dono da exceção. (Toda fronteira de dados precisa de uma decisão de qualidade)
• Sei que dados de referência também precisam de metadados: definições, um dono, uma origem e mapeamentos entre sistemas. (Dados de referência também precisam de metadados)

DM-3: metadados de negócio e técnicos

• Conhecimento para o exame: sei distinguir metadados de negócio (significado, definições, proprietário, regras, sensibilidade) de metadados técnicos (objetos, campos, tipos, nomes de API, esquemas, mapeamentos, linhagem). (Dois tipos de metadados)
• Sei a diferença entre um dicionário de negócio (o que significa), a linhagem (de onde veio) e a classificação (como precisa ser tratado). (Conheça seus dados)
• Conheço os campos de classificação do Salesforce: Data Owner, Field Usage, Data Sensitivity Level, Compliance Categorization, em campos padrão e personalizados. (A classificação responde a outra pergunta)
• Sei que devo classificar os campos sensíveis, não todos os campos, e que classificação sem aplicação é decoração. (Classificação sem aplicação é decoração)

GOV-1: dados pessoais e sensíveis

• Reconheço as principais leis (GDPR, CCPA/CPRA, PIPEDA, LGPD, a Privacy Act da Austrália, HIPAA, PCI DSS, SOX, COPPA), sei que o GDPR pode alcançar organizações fora da UE, e sei o que as leis têm em comum: direitos, transferências, notificação de incidentes e responsabilização. (As regulações que você deve reconhecer, As leis não param na fronteira)
• Sei a diferença entre criptografia, mascaramento, pseudonimização e anonimização, e que dados pseudonimizados continuam sendo dados pessoais. (Anonimizado, pseudonimizado, criptografado, mascarado)
• Sei que coletar menos é um controle de privacidade, e que a retenção é projetada desde o início. (Coletar menos é uma decisão de arquitetura, A retenção faz parte do modelo)
• Conheço o modelo de dados de consentimento: consentimento global no Indivíduo, consentimento por canal de engajamento, consentimento por ponto de contato, e finalidade de uso dos dados. (Use o modelo que a Salesforce já construiu)
• Sei que os pedidos têm prazos (GDPR: um mês, prorrogável por mais dois), então o mapa de cópias precisa existir antes. (O relógio está correndo)
• Sei que o direito ao esquecimento significa encontrar cada cópia (histórico, arquivos, análise, logs, arquivos anexos, texto livre), e que as políticas do Privacy Center rodam por objeto a partir de um registro de cliente. (Agora a pessoa diz: me esqueçam, O Privacy Center é uma ferramenta, não a arquitetura inteira)
• Conheço os trade-offs do Shield Platform Encryption: campos probabilísticos não podem ser filtrados, agrupados nem ordenados em SOQL; a criptografia determinística permite filtrar; campos criptografados não podem guiar compartilhamento baseado em critérios. (Criptografia é um controle, não conformidade)
• Sei que não devo copiar os dados sensíveis da produção para os sandboxes, e que o Data Mask está sendo substituído pelo Data Mask & Seed. (Não copie o risco da produção para o sandbox)
• Conheço o histórico de campos (até 20 campos por objeto; 18 meses, 24 só pela API; em texto longo, registra só a edição) versus o Field Audit Trail (até 200 campos, guardado até você excluí-lo). (O histórico também é dado)
• Conheço a retenção dos logs do Event Monitoring (1 dia sem o complemento para alguns eventos, 30 dias por padrão com ele, até 365 estendidos), e que é preciso exportar os eventos para um SIEM antes de precisar deles: os logs pagos não podem ser recuperados de antes do início do contrato. (Auditar e monitorar não são a mesma coisa)

Além do exame

O exame é o piso, não o teto. Estes são os hábitos deste capítulo de que um arquiteto precisa, quer alguma pergunta trate deles ou não.

• Uma política sem ponto de aplicação é, em boa parte, um desejo.
• Os donos definem a política; os arquitetos a aplicam. Não invente a política, e não brinque de advogado.
• A governança nunca termina. Ela vai e vem; projete o retorno.
• Não conte com o bom comportamento. Construa o controle: pessoas, integrações e agentes, todos erram.
• Governe o bastante, não tudo.
• Evite primeiro os erros caros. Uma duplicata com dois anos de histórico é um problema grande.
• Distinga o que as pessoas leem daquilo com base em que as máquinas decidem.
• Documente amplamente; classifique de forma deliberada.
• O dado sensível mais barato de governar é aquele que você nunca copiou.
• Consentimento é dado, e a permissão para usar dados precisa poder ser representada como dado.
• Controle primeiro para onde vão os dados pessoais, porque a exclusão é rara e difícil.
• Conformidade não é um produto.
• Capturar → Classificar → Proteger → Usar → Reter → Excluir → Auditar.
• Capture as evidências antes que alguém as peça.

Palavras para conhecer

Termo	Em uma linha
Governança de dados	As políticas para os dados, e a arquitetura que as torna verdadeiras
Proprietário dos dados	A pessoa ou função responsável por um tipo de dado
Data steward	A pessoa que mantém os dados saudáveis no dia a dia
Custodiante	A equipe que opera os sistemas que guardam os dados
RACI	Responsável, Aprovador (Accountable), Consultado, Informado
Registro provisório	Um registro criado antes de o sistema com autoridade aceitá-lo
Dicionário de negócio	Definições acordadas dos termos importantes do negócio
Linhagem	De onde um valor veio e o que aconteceu com ele no caminho
Classificação de dados	Rotular os dados por sensibilidade e categoria de conformidade para que recebam os controles certos
Taxonomia	O conjunto de rótulos que uma organização usa para classificar dados
Dados pessoais	Informação que identifica uma pessoa, ou que pode ser ligada de volta a uma
Pseudonimização	Substituir identificadores enquanto ainda existe um caminho de volta; continuam sendo dados pessoais
Anonimização	Remover a capacidade razoável de identificar a pessoa
Modelo de dados de consentimento	Os objetos da Salesforce para o consentimento por pessoa, canal, ponto de contato e finalidade
Direito ao esquecimento	O direito de uma pessoa, onde a lei o concede, de ter seus dados pessoais apagados
Golden record híbrido	Um registro com os campos do sistema mestre e os campos próprios do Salesforce, cada um com uma única origem
Metadados de negócio / técnicos	O que os dados significam e quem é dono deles / como são construídos e se movem
Field Audit Trail	Histórico de campos mais longo: até 200 campos por objeto, guardado até ser excluído
Event Monitoring	Logs de logins, exportações, chamadas de API e visualizações, guardados por tempo limitado
SIEM	Um repositório de segurança onde os logs de eventos são guardados e analisados

Teste-se

Cenários curtos no estilo do curso. Decida sua resposta antes de abrir.

1. A política diz que só o Financeiro pode alterar a razão social de um cliente. A equipe planeja cobrir isso no treinamento. O que falta?

Um ponto de aplicação. Treinamento não é controle: use acesso no nível do campo, um campo que só a integração grava, uma regra de validação ou um processo controlado. Os donos definem a política; o arquiteto a torna mecanicamente verdadeira. Releia A governança precisa virar mecânica.

2. Os clientes são mestres no ERP. Os vendedores precisam começar a vender para novos prospects na hora. Como permitir isso sem dois sistemas criando o registro mestre?

Deixe os vendedores criarem a conta como um tipo de registro provisório, e depois a converta por um processo controlado: o Financeiro aprova, ou a integração a submete ao ERP, que casa ou cria o cliente e devolve o ID com autoridade. Releia O caminho do meio.

3. Um novo campo obrigatório se enche de “N/A” e “999999”. O que aconteceu, e o que você faria no lugar?

Os usuários foram obrigados a responder antes de saber. Exija mais adiante no processo, deixe outro sistema fornecer, use um estado provisório, ou permita um Desconhecido explícito quando essa for uma resposta real. Releia Não deixe campos obrigatórios criarem dados falsos.

4. A equipe trocou os nomes por tokens e diz que os dados estão anonimizados, então o pedido de exclusão está resolvido. Está?

Não, se os tokens podem ser ligados de volta à pessoa: isso é pseudonimização, e os dados continuam pessoais. Diga exatamente o que o sistema faz, onde fica o mapeamento, e deixe o Jurídico decidir se isso atende ao requisito. Releia Anonimizado, pseudonimizado, criptografado, mascarado.

5. Um Destinatário aceita mensagens sobre a entrega, mas não marketing. Como o modelo deve guardar isso?

Com o modelo de dados de consentimento, não com uma caixa de seleção: a pessoa, o canal (SMS), o número específico e a finalidade de uso dos dados (notificações de entrega, não marketing). E decida qual sistema tem autoridade sobre o consentimento, para que uma retirada chegue a cada sistema que age com base nele. Releia Use o modelo que a Salesforce já construiu.

6. A conformidade precisa filtrar relatórios por um campo criptografado de número do Seguro Social. O campo usa o esquema de criptografia padrão. Qual é o problema?

A criptografia probabilística não permite filtrar em cláusulas WHERE de SOQL nem em filtros de gerenciamento de dados. A criptografia determinística permite filtrar, com um pequeno custo em força. A criptografia é uma decisão de design com trade-offs, não uma caixa de seleção no fim. Releia Criptografia é um controle, não conformidade.

7. Seis meses depois de um incidente, alguém pergunta quem exportou um conjunto de registros. Ninguém configurou o armazenamento do Event Monitoring. O que você pode dizer?

Provavelmente nada: os logs de eventos são guardados por tempo limitado (no máximo um ano, mesmo estendido), então o que for mais antigo sumiu, a menos que tenha sido exportado. Configure o Event Monitoring e envie os eventos para um SIEM antes de precisar deles. Releia Auditar e monitorar não são a mesma coisa.

8. Um vendedor pede ao Salesforce para alterar a razão social de um cliente, que tem o ERP como mestre. Nos mesmos minutos, alguém a altera no ERP. O que o design deve dizer?

Que o Salesforce estava pedindo, não alterando: o ERP é o mestre do campo. Decida de antemão a regra para colisões (o ERP vence, rejeitar se o valor mudou, ou uma pessoa resolve) e se campos relacionados viajam juntos. Releia Proteja o registro governado.

9. Chega um pedido de exclusão de uma pessoa. A equipe planeja começar a mapear onde estão os dados dela. Qual é o problema?

O relógio já está correndo: pelo GDPR, um mês, prorrogável por mais dois para pedidos complexos. O mapa de cópias precisa existir antes que o pedido chegue. Releia O relógio está correndo.

Para saber mais

• Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (em inglês, consultado em 2026-09-25): a lista oficial de objetivos e seus pesos. Sempre confira a versão atual antes de agendar o exame.
• A seção Para saber mais de cada módulo lista a documentação da Salesforce e as leis por trás dos seus fatos, com a data de consulta.