As leis de privacidade moldam o design
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)
Módulo 4 de 6 do capítulo Qualidade e governação de dados, capítulo 5 do curso Data Architect. Cada módulo sustenta-se sozinho. Anterior: Conheça os seus dados · Próximo: Consentimento e direito a ser esquecido
A pergunta que este módulo responde: O que pedem a um design Salesforce as regulações de privacidade e setoriais?
Quando trabalhei na Austrália, conheci muitos aspirantes a arquiteto que nunca tinham ouvido falar do RGPD. Os europeus muitas vezes não ouviram falar da lei de privacidade da Califórnia, nem da do Canadá, nem da do Brasil. É natural: conhece-se as regras de onde se trabalha. Mas estas 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.
Não precisa de se tornar advogado. Precisa de ver que uma regulação pode mudar onde os dados são armazenados, o que recolhe, quem os vê, porque os pode usar, durante quanto tempo os guarda, para onde os envia, se os consegue eliminar, que histórico mantém, e o que consegue provar depois. Estas 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 equipas jurídica e de conformidade decidem que leis se aplicam e o que 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, por isso o RGPD não se aplica». Talvez sim, talvez não. O âmbito territorial do RGPD (o Regulamento Geral sobre a Proteção de Dados, GDPR em inglês) alcança organizações fora da UE que oferecem bens ou serviços a pessoas na UE, ou que controlam o seu comportamento ali (artigo 3.º, Regulamento (UE) 2016/679 (opens in a new tab)). Por isso o sítio onde fica a sede da sua empresa não encerra a pergunta. Onde estão os seus clientes, os seus colaboradores, as pessoas cujos dados guarda, os seus sistemas, os seus subcontratantes? Para onde viajam os dados? É outra vez o panorama do capítulo 4. Não consegue tomar boas decisões de privacidade sem saber para onde vão os dados.
As regulações que deve reconhecer
Seção intitulada “As regulações que 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, logo aplica-se o requisito X». Essa decisão é do Jurídico. O seu trabalho é saber o suficiente 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 |
|---|---|---|
| RGPD (GDPR) (opens in a new tab) | União Europeia | Dados pessoais, tratamento lícito, direitos dos titulares, retenção, transferências, proteção de dados desde a conceção |
| CCPA, alterada pela CPRA (opens in a new tab) | Califórnia | Direitos dos consumidores sobre a informação pessoal que as empresas recolhem sobre eles |
| PIPEDA (opens in a new tab) | Canadá | Como as organizações do setor privado tratam informação pessoal |
| 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ção pessoal, segundo os Australian Privacy Principles |
| HIPAA (opens in a new tab) | Saúde nos EUA | Informação de saúde protegida, nos contextos abrangidos |
| 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 cotadas nos EUA | Controlos e evidências por trás dos relatórios financeiros |
| COPPA (opens in a new tab) | EUA, crianças online | Informação pessoal recolhida online de crianças |
A lista cresce (mais estados americanos têm as suas próprias leis), e as leis mudam. É por isso que não quero que decore uma tabela e ache que aprendeu arquitetura de privacidade. Aprenda os nomes, depois aprenda as perguntas que lhes sobrevivem.
O que as leis têm em comum
Seção intitulada “O que as leis têm em comum ”Os pormenores variam, mas as grandes leis de privacidade voltam sempre às mesmas poucas coisas, e cada uma delas acaba por cair na arquitetura.
Direitos. As pessoas podem pedir para ver os seus dados, retificá-los, apagá-los e levá-los consigo; ao abrigo das leis da Califórnia e do Brasil, também se podem opor à venda deles. Cada um desses pedidos significa encontrar os dados da pessoa, todos eles.
Transferências. O RGPD e a LGPD controlam a saída de dados pessoais da sua jurisdição e exigem um nível de proteção adequado no destino; a PIPEDA espera o mesmo nível de proteção quando um terceiro trata os dados, onde quer que esteja. É outra vez o panorama: que setas atravessam uma fronteira?
Notificação de violações de dados. Quando há uma violação de dados pessoais, as leis esperam que a notifique às autoridades e, por vezes, às pessoas afetadas, dentro de um prazo que varia conforme a lei. Não consegue notificar dados que não sabia que tinha, nem dizer o que foi exposto se não consegue encontrar as cópias.
Responsabilidade. Tem de conseguir demonstrar a conformidade: registos do que trata e porquê, avaliações de impacto para os tratamentos de alto risco e, ao abrigo do RGPD e da LGPD, um encarregado da proteção de dados (EPD, ou DPO). A arquitetura tem de produzir os registos.
Comece pelo que é pessoal
Seção intitulada “Comece pelo que é pessoal ”Antes de proteger informação pessoal, encontre-a. Alguma é óbvia: nome, morada de casa, telefone, e-mail. Outra não: localização, identificadores de dispositivo, endereços IP, imagens, dados de comportamento, qualquer coisa que possa ser associada a uma pessoa. E o contexto importa. Uma entrega da Steve Trucking leva o nome, a morada, o telefone, as notas de entrega e as fotografias do Destinatário. Uma fotografia pode mostrar uma caixa num alpendre, 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 guarda.
Onde vivem?
Seção intitulada “Onde vivem? ”«No Salesforce.» Provavelmente não só no Salesforce. Vieram de um Parceiro retalhista? Foram copiados para o Snowflake, ingeridos pelo Data 360, gravados num log de integração, exportados por um utilizador, deixados no histórico de campos, arquivados, copiados para uma sandbox, passados a um parceiro, usados na conversa de um agente? Os dados pessoais espalham-se. Por isso, quando o Jurídico pergunta «onde guardamos a informação desta pessoa?», «sabemos onde está o valor atual» não é resposta. Quero o panorama e a linhagem: para onde foram as cópias.
Um telefone, muitas cópias. A privacidade também se aplica às cópias.
Porque é que os pode usar?
Seção intitulada “Porque é que os pode usar? ”Ter dados e ter permissão para os usar não é a mesma coisa. A Steve Trucking tem o telefone de um Destinatário para coordenar a entrega de hoje. Isso transforma-o 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 tem de carregar a resposta: porque foi recolhido, que uso foi autorizado, se o consentimento era necessário, se foi dado, se foi retirado, e para que canal, endereço e finalidade. A permissão para usar os dados tem de 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 modela-a.
Recolher menos é uma decisão de arquitetura
Seção intitulada “Recolher menos é uma decisão de arquitetura ”Um dos controlos de privacidade mais fortes é não recolher os dados, ou não os copiar para onde não são precisos. O Snowflake precisa do telefone do Destinatário? A análise precisa da morada completa? A sandbox precisa de fotografias reais das entregas? Um agente precisa dos dados pessoais do Destinatário para responder a esta pergunta? Se não, o controlo mais forte pode ser não os pôr lá. Cada cópia que não faz é uma que não precisa de proteger, reter, eliminar, acompanhar quanto a consentimento, auditar ou reportar numa violação de dados. O dado sensível mais barato de governar é aquele que nunca copiou.
A retenção faz parte do modelo
Seção intitulada “A retenção faz parte do modelo ”«Vamos guardar tudo por agora» é uma política de retenção. Só que má. Para dados importantes, quero saber logo no design durante quanto tempo precisamos deles e porquê; se uma regulação define um mínimo ou outra define um máximo; quando começa a contar o prazo; e o que acontece no fim: eliminar, arquivar, desidentificar, e onde estão as cópias? Os registos financeiros podem ter de ficar durante um período definido. O código do portão de um Destinatário não tem propósito anos depois da entrega. Estas decisões não esperam que a base de dados fique grande.
Anonimizado, pseudonimizado, encriptado, mascarado
Seção intitulada “Anonimizado, pseudonimizado, encriptado, 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 voltar a ser associados usando informação guardada separadamente, e, segundo o RGPD, os dados pseudonimizados continuam a ser dados pessoais (artigo 4.º, n.º 5). A anonimização vai mais longe: os dados já não podem ser razoavelmente associados à pessoa (considerando 26). Por isso, quando alguém disser «não precisamos de eliminar, vamos só tirar o nome», cuidado. Se a pessoa ainda pode ser razoavelmente identificada, não atravessou 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 voltar a associar, que chaves restam, onde estão os mapeamentos?
Use as palavras com precisão, porque resolvem problemas diferentes. A encriptação protege os dados contra divulgação não autorizada; um utilizador autorizado continua a conseguir desencriptá-los. O mascaramento muda o que determinados utilizadores 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 torna-se requisitos
Seção intitulada “A regulação torna-se requisitos ”O Jurídico não precisa de me dizer para criar um conjunto de permissões; esse é o meu lado da linha. O Jurídico pode dizer «só colaboradores com necessidade legítima de negócio podem aceder a esta categoria de informação pessoal». Depois eu traduzo: quem são, como identificamos a categoria, como é concedido o acesso, o que acontece quando alguém muda de função, uma integração pode lê-la, um agente pode, pode ser exportada, e como provamos quem a viu? Os donos definem a política; os arquitetos aplicam-na. 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 põe-na a funcionar e torna-a comprovável.
E a conformidade não é um produto. Não se compra «conformidade: ligada». A encriptação pode apoiar um requisito, as funcionalidades de auditoria fornecem evidências, as ferramentas de retenção executam a política, os dados de consentimento sustentam o uso permitido, mas licenciar uma funcionalidade não torna uma arquitetura conforme. A conformidade vem do design inteiro: pessoas, política, processo, dados, controlos e evidências. O Salesforce é parte disso, não tudo. E, se uma política importa o suficiente para ser aplicada, pergunte se importa o suficiente para ser provada: quem acedeu a este registo a 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 equipas precisam de parte deles, só nas suas próprias paragens, só no dia; o Snowflake quer análise de entregas; as finanças precisam do suficiente para faturar, mas não do que a equipa vê. E um Parceiro retalhista 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 equipas veem só as suas paragens, a retenção a jusante difere da retenção operacional. O requisito de privacidade não fica ao lado do diagrama de panorama. Muda-o.
Perguntas que sobrevivem às regulações
Seção intitulada “Perguntas que sobrevivem às regulações ”As regulações mudam, por isso leve consigo um conjunto duradouro 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.
- Porque os podemos usar? Que finalidade e que base legal se aplicam? Há consentimento envolvido?
- Quem pode usá-los? Pessoas, sistemas, parceiros, integrações, agentes.
- Durante quanto tempo os guardamos, e o que acontece no fim?
- A pessoa consegue exercer os seus direitos sobre eles? Acesso, retificação, apagamento, portabilidade, oposição, conforme a lei prevê.
- Conseguimos provar o que aconteceu? Acesso, alterações, exportações, consentimento, eliminação, retenção.
A governação da IA está a tornar-se lei
Seção intitulada “A governação da IA está a tornar-se lei ”A IA acrescenta mais um consumidor de dados governados. Um sistema de IA pode usar estes dados, para que finalidade, como fundamentação (grounding), combinados com quê, repetidos na sua saída, registados onde, durante quanto tempo? A governação da IA está a passar 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 exige depende do sistema e do uso. A direção para os arquitetos é clara: a IA não fica fora da governação; é 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 se torna 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, eliminação, anonimização, pseudonimização, proteção e evidências moldam o ciclo de vida dos dados.
- Que evidências têm de existir para mostrar que os controlos importantes funcionaram de facto.
As regulações não se tornam arquitetura quando pomos o seu nome num diapositivo. Tornam-se arquitetura quando mudam a forma como os dados são recolhidos, classificados, movidos, protegidos, retidos, eliminados e comprovados.
Para saber mais
Seção intitulada “Para saber mais ”- As fontes oficiais das regulações estão nas ligações da tabela acima, consultadas em 2026-10-14.
- Regulamento (UE) 2016/679 (RGPD, ou GDPR) (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.