Os donos definem a política, os arquitetos a aplicam

🌐 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)

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

Capítulo 5 de Data Architect, Parte 1: Tornando-se arquiteto de dados. Anterior: Entendendo os dados corporativos.

Diga “governança de dados” e as pessoas imaginam reuniões: comitês, políticas, um documento que ninguém lê. Eu faço uma pergunta diferente toda vez: onde a política é aplicada?

Se a política diz que só o Financeiro pode alterar a razão social do cliente, o que impede os outros? Se diz que as equipes veem o endereço de um Destinatário só nas suas próprias paradas, só no dia, o que torna isso verdade? Se diz guarde isto por sete anos, o que o remove depois de sete? Uma política sem ponto de aplicação é, em boa parte, um desejo. Minha posição é simples: os donos definem a política; os arquitetos a aplicam. O proprietário dos dados decide. O sistema que o arquiteto projeta torna isso mecanicamente verdadeiro.

E não espere terminar. A governança nunca termina. Ela vai e vem, mantendo do lado de fora o pior dos dados ruins. É simples quando o Salesforce está sozinho, e mais difícil, e mais necessária, quando o Salesforce é um nó do panorama que desenhamos no capítulo 4. Foi por isso que aquele capítulo veio primeiro: o panorama diz até onde a governança precisa chegar.

Imagem gerada com IA.

As posições deste capítulo

• Conduza o programa do jeito que a empresa funciona: centralizado, federado ou híbrido; o arquiteto precisa saber quem aprova uma política.
• O proprietário do registro não é o proprietário dos dados. O campo Proprietário determina atribuição e acesso; a responsabilidade pelos dados é do negócio.
• Criação aberta ou travada depende da governança em torno dos dados. Aberta serve para a maioria das orgs pequenas e médias; trave quando as contas são mestres num ERP ou sincronizadas com ele; o caminho do meio é um tipo de registro provisório com conversão controlada para o governado.
• Se o ERP é o mestre de um campo, você não está alterando o campo, está pedindo para alterá-lo. O golden record é híbrido: os campos mestres do ERP entram, os campos próprios do Salesforce nunca voltam, e os fluxos bidirecionais precisam de uma regra para colisões.
• Classifique os campos sensíveis, não todos os campos. Documente de forma ampla; classifique de forma deliberada; mantenha tanto os metadados de negócio quanto os técnicos.
• Ensine as regulações. Muitos arquitetos nunca ouviram falar das leis de fora da sua própria região, e essas leis moldam o design de sistemas.
• Use o modelo de consentimento pronto sempre que puder, em vez de reconstruí-lo.
• Para o direito ao esquecimento, controle primeiro para onde vão os dados pessoais. A exclusão é rara e difícil; projete para que os dados pessoais caiam em poucos lugares, e então vá atrás de cada cópia: histórico de campos, arquivos, as cópias de análise, índices de busca e conversas de agentes, antes que o prazo acabe.
• O Shield é a resposta para requisitos regulatórios-chave como criptografia em repouso, com trade-offs para os quais você projeta.
• Field Audit Trail quando houver regulação. O histórico de campos padrão é o default.
• Configure o Event Monitoring antes de precisar dele, e envie os eventos para um repositório como o Splunk. Você não quer dar de cara com um problema e então descobrir que não estava capturando os eventos.

O ciclo de vida dos dados governados

Click to enlarge

Sete perguntas ao longo da vida dos dados. As ferramentas apoiam a política; não a definem.

O caminho por este capítulo

Seis módulos, cada um se sustentando sozinho.

1. A governança é projetada dentro da org. Proprietários, data stewards e custodiantes; centralizado, federado ou híbrido; proprietário do registro versus proprietário dos dados; transformar cada política num ponto de aplicação.
2. Mantendo dados ruins do lado de fora. “Bom o bastante” como definição de negócio; criação aberta versus travada, o registro provisório e um tipo de registro para cada fluxo; o golden record híbrido e os bidirecionais; uma decisão de qualidade em cada fronteira de dados.
3. Conheça seus dados: dicionário, linhagem e classificação. Metadados de negócio e técnicos; o que significam, de onde vieram, como devem ser tratados, e por que classificação sem aplicação é decoração.
4. Leis de privacidade moldam o design. As leis que é preciso reconhecer, o que elas têm em comum (direitos, transferências, notificação de incidentes, responsabilização), e as perguntas que sobrevivem a elas; anonimizado versus pseudonimizado; conformidade não é um produto.
5. Consentimento e direito ao esquecimento. Consentimento como dado, o modelo de consentimento padrão, o prazo de cada pedido, e projetar a exclusão antes que chegue o primeiro.
6. Proteger, reter e provar. Os trade-offs da criptografia, sandboxes, retenção, histórico de campos e Field Audit Trail, e o Event Monitoring configurado antes da necessidade.

Quando terminar, teste-se com o guia de estudo do capítulo: uma lista para o exame, os hábitos que vão além dele, as palavras para conhecer e algumas perguntas.

O que um arquiteto decide aqui

• Quem é dono de cada domínio de dados importante, e o que aplica a política de cada dono.
• Que dados ruins são mantidos do lado de fora, e o que é pego, colocado em quarentena e corrigido depois.
• Quais campos são sensíveis, e o que essa classificação muda.
• Para onde vão os dados pessoais, para que podem ser usados, e como são removidos de cada cópia.
• Por quanto tempo os dados e o histórico deles são guardados, e que evidências existem para provar o que aconteceu.

Este capítulo é orientação de arquitetura, não aconselhamento jurídico. As equipes jurídica e de conformidade decidem quais leis se aplicam e o que elas exigem; o arquiteto transforma esses requisitos em design.

Além do exame: a governança tem um novo consumidor, o agente. A classificação decide o que ele pode recuperar, o consentimento decide para que ele pode usar os dados, e a linhagem e a auditoria precisam chegar até o que ele disse e fez. Cada módulo termina com o que a IA muda na sua parte do ciclo de vida.

Para saber mais

• Salesforce Help, Data Classification Metadata Fields (opens in a new tab) (em inglês), consultado em 2026-10-14.
• Salesforce Help, Understand the Salesforce Consent Data Model (opens in a new tab) (em inglês), consultado em 2026-10-14.
• Regulamento (UE) 2016/679 (GDPR, ou RGPD) (opens in a new tab), EUR-Lex, consultado em 2026-10-14.

Próximo: Dados mestres e identidade