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

🌐 Também em 28 idiomas

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · 繁體中文 · 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 com IA. Ainda não revisto pela comunidade. Ler em inglês

Capítulo 5 de Data Architect, Parte 1: Tornar-se arquiteto de dados. Anterior: Entender os dados empresariais.

Diga «governação de dados» e as pessoas imaginam reuniões: comités, políticas, um documento que ninguém lê. Eu faço sempre uma pergunta diferente: onde é aplicada a política?

Se a política diz que só as Finanças podem alterar a denominação social do cliente, o que impede os outros? Se diz que as equipas veem a morada de um Destinatário só nas suas próprias paragens, só no dia, o que torna isso verdade? Se diz guarde isto durante sete anos, o que o remove passados os sete? Uma política sem ponto de aplicação é, em boa parte, um desejo. A minha posição é simples: os donos definem a política; os arquitetos aplicam-na. O proprietário dos dados decide. O sistema que o arquiteto projeta torna isso mecanicamente verdadeiro.

E não espere terminar. A governação nunca termina. Vai e vem, mantendo lá fora o pior dos dados maus. É simples quando o Salesforce está sozinho, e mais difícil, e mais necessária, quando o Salesforce é um nó do panorama que desenhámos no capítulo 4. Foi por isso que esse capítulo veio primeiro: o panorama diz até onde a governação tem de chegar.

Imagem gerada com IA.

As posições deste capítulo

• Conduza o programa da forma como a empresa funciona: centralizado, federado ou híbrido; o arquiteto precisa de saber quem aprova uma política.
• O proprietário do registo 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 trancada depende da governação à volta dos dados. Aberta serve para a maioria das orgs pequenas e médias; tranque quando as contas são mestres num ERP ou sincronizadas com ele; o caminho do meio é um tipo de registo provisório com conversão controlada para o governado.
• Se o ERP é o mestre de um campo, não está a alterar o campo, está a pedir para o alterar. 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 como 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 a ser esquecido, controle primeiro para onde vão os dados pessoais. A eliminação é rara e difícil; projete para que os dados pessoais fiquem em poucos sítios, e depois vá atrás de cada cópia: histórico de campos, arquivos, as cópias de análise, índices de pesquisa e conversas de agentes, antes que o prazo acabe.
• O Shield é a resposta para requisitos regulatórios-chave como encriptação em repouso, com trade-offs para os quais se projeta.
• Field Audit Trail quando houver regulação. O histórico de campos padrão é o ponto de partida.
• Configure o Event Monitoring antes de precisar dele, e envie os eventos para um repositório como o Splunk. Não quer dar de caras com um problema e só então descobrir que não estava a capturar 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 percurso deste capítulo

Seis módulos, cada um a sustentar-se sozinho.

1. A governação é projetada dentro da org. Proprietários, data stewards e custodiantes; centralizado, federado ou híbrido; proprietário do registo versus proprietário dos dados; transformar cada política num ponto de aplicação.
2. Manter os dados maus lá fora. «Suficientemente bom» como definição de negócio; criação aberta versus trancada, o registo provisório e um tipo de registo para cada fluxo; o golden record híbrido e os bidirecionais; uma decisão de qualidade em cada fronteira de dados.
3. Conheça os 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 porque é que a classificação sem aplicação é decoração.
4. As leis de privacidade moldam o design. As leis que é preciso reconhecer, o que têm em comum (direitos, transferências, notificação de violações de dados, responsabilidade), e as perguntas que lhes sobrevivem; anonimizado versus pseudonimizado; a conformidade não é um produto.
5. Consentimento e direito a ser esquecido. O consentimento como dado, o modelo de consentimento padrão, o prazo de cada pedido, e projetar a eliminação antes de chegar o primeiro pedido.
6. Proteger, reter e provar. Os trade-offs da encriptação, 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 a 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 maus são mantidos lá fora, e o que é apanhado, posto em quarentena e corrigido depois.
• Que 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.
• Durante quanto tempo são guardados os dados e o seu histórico, e que evidências existem para provar o que aconteceu.

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

Além do exame: a governação tem um novo consumidor, o agente. A classificação decide o que pode recuperar, o consentimento decide para que pode usar os dados, e a linhagem e a auditoria têm de chegar até ao que 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 (RGPD, ou GDPR) (opens in a new tab), EUR-Lex, consultado em 2026-10-14.

Próximo: Dados mestres e identidade