Leis de privacidade moldam o design
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)
Módulo 4 de 6 do capítulo Qualidade e governança de dados, capítulo 5 do curso Data Architect. Cada módulo se sustenta sozinho. Anterior: Conheça seus dados · Próximo: Consentimento e direito ao esquecimento
A pergunta que este módulo responde: O que as regulações de privacidade e de setor pedem de um design Salesforce?
Quando trabalhei na Austrália, conheci muitos aspirantes a arquiteto que nunca tinham ouvido falar do GDPR. Os europeus muitas vezes não ouviram falar da lei de privacidade da Califórnia, nem da do Canadá, nem da do Brasil. É natural: você conhece as regras de onde trabalha. Mas essas leis atravessam fronteiras, e moldam o design de sistemas mesmo que nenhuma delas trate de Salesforce. Por isso pertencem a um curso de arquitetura de dados.
Você não precisa virar advogado. Precisa enxergar que uma regulação pode mudar onde os dados são armazenados, o que você coleta, quem os vê, por que você pode usá-los, por quanto tempo os guarda, para onde os envia, se consegue excluí-los, que histórico mantém, e o que consegue provar depois. Essas não são só perguntas jurídicas. São perguntas de arquitetura de dados.
Este módulo é 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 aplicável.
As leis não param na fronteira
Seção intitulada “As leis não param na fronteira ”Primeiro, o maior equívoco: “não estamos na Europa, então o GDPR não se aplica”. Talvez sim, talvez não. O âmbito territorial do GDPR (o Regulamento Geral sobre a Proteção de Dados, ou RGPD) alcança organizações fora da UE que oferecem bens ou serviços a pessoas na UE, ou que monitoram o comportamento delas ali (artigo 3.º, Regulamento (UE) 2016/679 (opens in a new tab)). Então onde fica a sede da sua empresa não encerra a pergunta. Onde estão seus clientes, seus funcionários, as pessoas cujos dados você guarda, seus sistemas, seus operadores? Para onde os dados viajam? É o panorama do capítulo 4 de novo. Você não consegue tomar boas decisões de privacidade sem saber para onde os dados vão.
As regulações que você deve reconhecer
Seção intitulada “As regulações que você deve reconhecer ”Eis os nomes que um arquiteto deve conhecer, com o que cada um cobre. É uma tabela de reconhecimento, não uma matriz de aplicabilidade: não a leia para decidir “temos clientes na Califórnia, então o requisito X se aplica”. Essa decisão é do Jurídico. Seu trabalho é saber o bastante para fazer a pergunta antes de o sistema ser construído.
| Lei ou norma | Onde ou o quê | Por que um arquiteto deve reconhecê-la |
|---|---|---|
| GDPR (opens in a new tab) | União Europeia | Dados pessoais, tratamento lícito, direitos dos titulares, retenção, transferências, privacidade desde a concepção |
| CCPA, alterada pela CPRA (opens in a new tab) | Califórnia | Direitos dos consumidores sobre as informações pessoais que as empresas coletam sobre eles |
| PIPEDA (opens in a new tab) | Canadá | Como organizações do setor privado tratam informações pessoais |
| LGPD (opens in a new tab) | Brasil | A Lei Geral de Proteção de Dados Pessoais do Brasil |
| Privacy Act 1988 (opens in a new tab) | Austrália | Como as organizações tratam informações pessoais, segundo os Australian Privacy Principles |
| HIPAA (opens in a new tab) | Saúde nos EUA | Informações de saúde protegidas, nos contextos cobertos |
| PCI DSS (opens in a new tab) | Cartões de pagamento | Proteção dos dados de contas de cartões de pagamento |
| Sarbanes-Oxley (SOX) (opens in a new tab) | Empresas de capital aberto nos EUA | Controles e evidências por trás dos relatórios financeiros |
| COPPA (opens in a new tab) | EUA, crianças on-line | Informações pessoais coletadas on-line de crianças |
A lista cresce (mais estados americanos têm suas próprias leis), e as leis mudam. É por isso que não quero que você decore uma tabela e ache que aprendeu arquitetura de privacidade. Aprenda os nomes, depois aprenda as perguntas que sobrevivem a eles.
O que as leis têm em comum
Seção intitulada “O que as leis têm em comum ”Os detalhes variam, mas as grandes leis de privacidade sempre voltam às mesmas poucas coisas, e cada uma delas cai na arquitetura.
Direitos. As pessoas podem pedir para ver seus dados, corrigi-los, excluí-los e levá-los consigo; pelas leis da Califórnia e do Brasil, também podem se opor à venda deles. Cada um desses pedidos significa encontrar os dados da pessoa, todos eles.
Transferências. O GDPR e a LGPD controlam a saída de dados pessoais da sua jurisdição e pedem proteção adequada no destino; a PIPEDA espera o mesmo nível de proteção quando um terceiro trata os dados, onde quer que esteja. É o panorama de novo: quais setas cruzam uma fronteira?
Notificação de incidentes. Quando dados pessoais são expostos, as leis esperam que você avise as autoridades, e às vezes as pessoas afetadas, dentro de um prazo que varia conforme a lei. Você não consegue notificar sobre dados que não sabia que tinha, nem dizer o que foi exposto se não consegue encontrar as cópias.
Responsabilização. Você precisa conseguir demonstrar a conformidade: registros do que você trata e por quê, avaliações de impacto para tratamentos de alto risco e, pelo GDPR e pela LGPD, um encarregado de proteção de dados (DPO). A arquitetura precisa produzir os registros.
Comece pelo que é pessoal
Seção intitulada “Comece pelo que é pessoal ”Antes de proteger informações pessoais, encontre-as. Algumas são óbvias: nome, endereço residencial, telefone, e-mail. Outras não: localização, identificadores de dispositivo, endereços IP, imagens, dados de comportamento, qualquer coisa que possa ser ligada de volta a uma pessoa. E o contexto importa. Uma entrega da Steve Trucking leva o nome, o endereço, o telefone, as observações de entrega e as fotos do Destinatário. Uma foto pode mostrar uma caixa numa varanda, ou uma pessoa, ou o interior de uma casa. A entrega é um dado operacional, mas alguns dos seus atributos são pessoais. É por isso que o módulo 3 classificou campos: a privacidade começa por saber o que você guarda.
Onde eles vivem?
Seção intitulada “Onde eles vivem? ”“No Salesforce.” Provavelmente não só no Salesforce. Vieram de um Parceiro varejista? Foram copiados para o Snowflake, ingeridos pelo Data 360, gravados num log de integração, exportados por um usuário, deixados no histórico de campos, arquivados, copiados para um sandbox, passados a um parceiro, usados na conversa de um agente? Dados pessoais se espalham. Então, quando o Jurídico pergunta “onde guardamos as informações desta pessoa?”, “sabemos onde está o valor atual” não é resposta. Quero o panorama e a linhagem: para onde as cópias foram.
Um telefone, muitas cópias. A privacidade também se aplica às cópias.
Por que você tem permissão para usá-los?
Seção intitulada “Por que você tem permissão para usá-los? ”Ter dados e ter permissão para usá-los não são a mesma coisa. A Steve Trucking tem o telefone de um Destinatário para coordenar a entrega de hoje. Isso o transforma numa lista de marketing? Não. A base legal depende da jurisdição e da situação, e o Jurídico orienta isso, mas a arquitetura precisa carregar a resposta: por que foi coletado, que uso foi autorizado, se o consentimento era necessário, se foi dado, se foi retirado, e para qual canal, endereço e finalidade. A permissão para usar os dados precisa poder ser representada como dado, porque um documento de política não consegue tomar uma decisão em tempo de execução. O próximo módulo a modela.
Coletar menos é uma decisão de arquitetura
Seção intitulada “Coletar menos é uma decisão de arquitetura ”Um dos controles de privacidade mais fortes é não coletar os dados, ou não copiá-los para onde não são necessários. O Snowflake precisa do telefone do Destinatário? A análise precisa do endereço completo? O sandbox precisa de fotos reais das entregas? Um agente precisa dos dados pessoais do Destinatário para responder a esta pergunta? Se não, o controle mais forte pode ser não colocá-los ali. Cada cópia que você não faz é uma que você não precisa proteger, reter, excluir, acompanhar consentimento, auditar ou relatar num vazamento. O dado sensível mais barato de governar é aquele que você nunca copiou.
A retenção faz parte do modelo
Seção intitulada “A retenção faz parte do modelo ”“Vamos guardar tudo por enquanto” é uma política de retenção. Só que ruim. Para dados importantes, quero saber já no design por quanto tempo precisamos deles e por quê; se uma regulação define um mínimo ou outra define um máximo; quando o relógio começa; e o que acontece no fim: excluir, arquivar, desidentificar, e onde estão as cópias? Registros financeiros podem precisar ficar por um período definido. O código do portão de um Destinatário não tem propósito anos depois da entrega. Essas decisões não esperam o banco de dados ficar grande.
Anonimizado, pseudonimizado, criptografado, mascarado
Seção intitulada “Anonimizado, pseudonimizado, criptografado, mascarado ”Troque “Joana Silva” por 7F92A1. A Joana foi anonimizada? Não, se outra tabela ainda diz 7F92A1 = Joana Silva. Isso é pseudonimização: o identificador direto é substituído, mas os dados podem ser religados usando informação guardada separadamente, e, segundo o GDPR, dados pseudonimizados continuam sendo dados pessoais (artigo 4.º, n.º 5). A anonimização vai além: os dados não podem mais ser razoavelmente ligados à pessoa (considerando 26). Então, quando alguém disser “não precisamos excluir, vamos só tirar o nome”, cuidado. Se a pessoa ainda pode ser razoavelmente identificada, você não cruzou essa linha. Se um resultado satisfaz a lei, quem decide é o Jurídico; o trabalho do arquiteto é dizer exatamente o que o sistema faz: dá para religar, que chaves restam, onde estão os mapeamentos?
Use as palavras com precisão, porque elas resolvem problemas diferentes. A criptografia protege os dados contra divulgação não autorizada; um usuário autorizado ainda consegue descriptografá-los. O mascaramento muda o que determinados usuários ou ambientes veem. A pseudonimização separa a identidade direta mantendo um caminho de volta. A anonimização remove a capacidade razoável de identificar a pessoa. Só a última tira os dados da categoria “pessoal”.
A regulação vira requisitos
Seção intitulada “A regulação vira requisitos ”O Jurídico não precisa me dizer para criar um conjunto de permissões; esse é o meu lado da linha. O Jurídico pode dizer “só funcionários com necessidade legítima de negócio podem acessar esta categoria de informação pessoal”. Aí eu traduzo: quem são eles, como identificamos a categoria, como o acesso é concedido, o que acontece quando alguém muda de função, uma integração pode lê-la, um agente pode, ela pode ser exportada, e como provamos quem a viu? Os donos definem a política; os arquitetos a aplicam. O Jurídico e a conformidade estabelecem a obrigação, os proprietários dos dados definem a política de negócio, e o arquiteto projeta a aplicação.
Da regulação à evidência: o Jurídico interpreta, o proprietário define a política, o arquiteto faz funcionar e torna comprovável.
E conformidade não é um produto. Você não compra “conformidade: ligada”. A criptografia pode apoiar um requisito, os recursos de auditoria fornecem evidências, as ferramentas de retenção executam a política, os dados de consentimento sustentam o uso permitido, mas licenciar um recurso não torna uma arquitetura conforme. A conformidade vem do design inteiro: pessoas, política, processo, dados, controles e evidências. O Salesforce é parte disso, não tudo. E, se uma política importa o bastante para ser aplicada, pergunte se importa o bastante para ser provada: quem acessou este registro em 17 de março, quem alterou este campo, o que continha aquela exportação? O módulo 6 trata das evidências.
A privacidade muda o panorama
Seção intitulada “A privacidade muda o panorama ”Na Steve Trucking, os dados pessoais do Destinatário chegam por três integrações de parceiros. O Salesforce precisa deles para executar as entregas; as equipes precisam de parte deles, só nas suas próprias paradas, só no dia; o Snowflake quer análise de entregas; o financeiro precisa do bastante para faturar, mas não do que a equipe vê. E um Parceiro varejista nunca pode ver os Destinatários de outro. A privacidade muda as setas: certos campos não vão para o Snowflake, a análise recebe uma versão menos identificável, as equipes veem só as suas paradas, a retenção mais adiante difere da retenção operacional. O requisito de privacidade não fica ao lado do diagrama de panorama. Ele o muda.
Perguntas que sobrevivem às regulações
Seção intitulada “Perguntas que sobrevivem às regulações ”As regulações mudam, então leve consigo um conjunto durável de perguntas para quaisquer dados sensíveis ou regulados:
- O que são? Pessoais, sensíveis, financeiros, de saúde, de pagamento, de crianças ou regulados de outra forma?
- Onde vivem? Cada cópia: integrações, histórico, análise, arquivos, sandboxes, logs, uso por IA.
- Por que podemos usá-los? Que finalidade e que base legal se aplicam? Há consentimento envolvido?
- Quem pode usá-los? Pessoas, sistemas, parceiros, integrações, agentes.
- Por quanto tempo os guardamos, e o que acontece no fim?
- A pessoa consegue exercer seus direitos sobre eles? Acesso, correção, exclusão, portabilidade, oposição, conforme a lei prevê.
- Conseguimos provar o que aconteceu? Acesso, alterações, exportações, consentimento, exclusão, retenção.
A governança da IA está virando lei
Seção intitulada “A governança da IA está virando lei ”A IA acrescenta mais um consumidor de dados governados. Um sistema de IA pode usar estes dados, para que finalidade, como embasamento (grounding), combinados com o quê, repetidos na sua saída, registrados onde, por quanto tempo? A governança da IA está passando de política da empresa para lei: o Regulamento da IA da União Europeia (Regulamento (UE) 2024/1689 (opens in a new tab)) é o primeiro grande exemplo. O que ele exige depende do sistema e do uso. A direção para os arquitetos é clara: a IA não fica fora da governança; ela é mais um consumidor de dados governados.
O que um arquiteto decide aqui
Seção intitulada “O que um arquiteto decide aqui ”- Onde os dados regulados ou sensíveis entram, vivem, se movem e são copiados ao longo do panorama.
- Como a política jurídica e de conformidade vira requisitos aplicáveis, sem que o arquiteto interprete a lei.
- Se cada sistema que recebe dados sensíveis precisa deles, ou se uma versão menos identificável bastaria.
- Como retenção, exclusão, anonimização, pseudonimização, proteção e evidências moldam o ciclo de vida dos dados.
- Que evidências precisam existir para mostrar que os controles importantes de fato funcionaram.
As regulações não viram arquitetura quando colocamos o nome delas num slide. Viram arquitetura quando mudam como os dados são coletados, classificados, movidos, protegidos, retidos, excluídos e comprovados.
Para saber mais
Seção intitulada “Para saber mais ”- As fontes oficiais das regulações estão nos links da tabela acima, consultadas em 2026-10-14.
- Regulamento (UE) 2016/679 (GDPR, ou RGPD) (opens in a new tab): artigo 3.º (âmbito territorial), artigo 4.º, n.º 5 (pseudonimização), considerando 26 (informação anônima).
- Regulamento (UE) 2024/1689 (o Regulamento da IA) (opens in a new tab), EUR-Lex.