Consentimento e direito a ser esquecido

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

Imagem gerada com IA

Traduzido com IA. Ainda não revisto pela comunidade. Ler em inglês

Módulo 5 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: As leis de privacidade moldam o design · Próximo: Proteger, reter e provar

A pergunta que este módulo responde: Como projetar para o consentimento, e para apagar uma pessoa?

A Steve Trucking tem o telefone de um Destinatário. Pergunta simples: podemos enviar-lhe uma mensagem? Talvez. Sobre a entrega de hoje? A de amanhã? Podemos usar o número para uma promoção? E se ele disse não às mensagens, ou sim às atualizações de entrega mas não ao marketing, e depois mudou de ideias?

Agora a outra direção. O Destinatário diz: apaguem a minha informação pessoal. Onde está? No Salesforce, provavelmente, mas aprendemos que essa não é a resposta inteira. Veio de um Parceiro retalhista. Pode estar numa plataforma de dados de clientes (customer data platform), no histórico de campos, num arquivo, numa nota de entrega, numa exportação, num log de integração, na conversa de um agente. Consentimento e eliminação soam a perguntas de política, mas, a dada altura, o sistema tem de lhes responder. Isso é arquitetura.

O consentimento é um dado

O primeiro princípio: o consentimento é um dado. Não o reduza a Has_Opted_In__c = true. A pergunta real nunca é só «ele consentiu?» É consentiu com quê, por que canal, em que endereço ou número, para que finalidade, quando, isso mudou, e conseguimos prová-lo? Se o negócio toma decisões com base nessas respostas, têm de ser armazenadas como dados estruturados. Um parágrafo numa política de privacidade não basta, e uma caixa de verificação num formulário web também não: a caixa regista um evento; a arquitetura tem de guardar o que o evento significa.

Use o modelo que a Salesforce já construiu

A minha posição: use o modelo de consentimento pronto sempre que puder, em vez de reconstruir a mesma coisa em campos personalizados. O modelo de dados de consentimento da Salesforce gere o consentimento em quatro níveis, cada um uma pergunta mais específica (Understand the Salesforce Consent Data Model (opens in a new tab), em inglês):

• Consentimento global, no Indivíduo (Individual): quem é esta pessoa, e disse não a tudo?
• Consentimento por tipo de ponto de contacto (Contact Point Type Consent): podemos usar este tipo de canal, como SMS ou e-mail?
• Consentimento por ponto de contacto: e este número de telefone ou endereço de e-mail específico?
• Finalidade de uso dos dados (Data Use Purpose): por que motivo: notificações de entrega, atendimento, marketing?

Juntando tudo, a arquitetura consegue responder a «podemos usar a informação desta pessoa, através deste ponto de contacto, para esta finalidade?», o que é muito mais útil do que «consentimento = sim». Qualquer registo que se relacione com um indivíduo pode participar: leads, contactos, contas pessoais, utilizadores.

Click to enlarge

Quatro perguntas, cada uma mais estreita do que a anterior. Um único indicador de opt-in não responde bem a nenhuma delas.

A finalidade importa

Um Parceiro retalhista envia à Steve Trucking o telefone de um Destinatário para que a equipa possa coordenar a entrega. Isso não transforma o Destinatário num lead de marketing. Os mesmos dados podem ter usos permitidos diferentes: coordenação da entrega, acompanhamento do atendimento, marketing, personalização por IA. Se a política ou a lei os trata de forma diferente, o modelo tem de os distinguir. A pergunta não é temos o número de telefone? É o que podemos fazer com ele?

E o consentimento nem sempre é a base legal. Alguns usos apoiam-se noutras bases que a lei prevê, e isso é determinação do Jurídico. Não construa uma arquitetura que presume que todas as decisões de privacidade são uma caixa de opt-in. Sustente o que a política disser: se um uso depende de consentimento, modele e aplique o consentimento; se se aplica outra base, guarde mesmo assim o necessário para decidir se o uso é permitido.

O consentimento tem um ciclo de vida e uma autoridade

As pessoas dão consentimento, retiram-no, mudam preferências, mudam de número. O negócio acrescenta novas finalidades; as leis mudam. Por isso, projete o ciclo de vida: o que foi escolhido, quando, como, para que finalidade, e o que acontece na retirada. E é aqui que fica interessante: quando um Destinatário retira o consentimento, o Salesforce sabe. A plataforma de mensagens sabe? A análise? O agente? Um consentimento que vive num sistema enquanto outros agem com uma permissão desatualizada não é bem um controlo.

Isso significa perguntar que sistema tem autoridade sobre o consentimento. O Salesforce, uma plataforma de preferências, outro sítio? Seja qual for a resposta, não deixe cinco sistemas decidirem de forma independente se a mesma pessoa concordou com o mesmo uso. O consentimento precisa do que precisam quaisquer dados governados: um dono, um registo com autoridade, uma forma de sincronizar, e aplicação.

Agora a pessoa diz: esqueçam-me

O primeiro instinto é eliminar o contacto e dar o assunto por encerrado. Mas os dados da pessoa podem estar num contacto, numa entrega, numa nota de entrega, num caso, numa fotografia, no histórico de campos, no Snowflake, num arquivo, num log de integração, num índice de pesquisa ou no histórico de conversas de um agente. É por isso que a minha posição sobre a eliminação começa antes: a eliminação é rara e difícil na prática, por isso controle primeiro para onde vão os dados pessoais. Projete para que fiquem no menor número possível de sítios. Depois, quando chegar um pedido, ofusque ou desassocie onde isso satisfizer a política, e vá atrás de cada cópia: histórico de campos, arquivos, Data 360 e, agora, índices de pesquisa e conversas de agentes.

Não comece a caçada quando chegar o pedido. Aí já é tarde demais para começar a entender o panorama. O dicionário, a linhagem e a classificação do módulo 3 não eram papelada; são o que torna isto possível. Já sabe que campos guardam dados pessoais e para onde foram as cópias.

Click to enlarge

Um pedido de «esqueçam-me» é uma decisão para cada cópia.

O relógio está a contar

Estes pedidos vêm com prazos. Ao abrigo do RGPD, a organização tem de dar seguimento ao pedido de uma pessoa sem demora injustificada e no prazo de um mês a contar da data de receção do pedido; para pedidos complexos ou numerosos, esse prazo pode ser prorrogado por mais dois meses, mas a pessoa tem de ser informada no prazo de um mês, com os motivos (artigo 12.º, n.º 3, Regulamento (UE) 2016/679 (opens in a new tab)). Outras leis definem os seus próprios prazos; o Jurídico dir-lhe-á quais se aplicam. Seja como for, um mês não é tempo suficiente para descobrir o panorama. É esse o prazo que o mapa de cópias tem de vencer.

Eliminar, desidentificar ou reter?

Um pedido não significa necessariamente que tudo, em todo o lado, desaparece. Alguns registos devem ou podem ser mantidos; alguns registos operacionais podem ficar mas deixar de identificar a pessoa; alguns dados podem ser desidentificados. A política e a lei aplicáveis decidem; a arquitetura sustenta cada resultado, local a local: eliminar, desidentificar, ou manter sob um requisito aprovado (e então quem pode ver, durante quanto tempo, porquê?).

Lembre-se da distinção do módulo 4. Desassociar só conta como esquecer quando a pessoa já não pode ser razoavelmente reidentificada. Os dados pseudonimizados continuam a ser dados pessoais. Não use a ofuscação como atalho para contornar um requisito legal.

Não consegue eliminar o que não consegue encontrar

Antes de apagar alguém, tem de o encontrar. O pedido vem de um endereço de e-mail. Um Parceiro retalhista enviou «Joana Silva», outro «J. Silva», e o telefone mudou. O Destinatário nem é um contacto; os seus dados ficam em cada entrega. A mesma pessoa recebeu entregas de dois parceiros diferentes. Um sistema conhece-a pelo e-mail, outro por um ID externo. A eliminação depende da identidade, e não quer eliminar os dados de outra pessoa porque a sua correspondência foi demasiado agressiva. A arquitetura de identidade faz parte da arquitetura de privacidade.

A Steve Trucking torna isto ainda mais difícil. Um Parceiro retalhista nunca pode ver as entregas ou os Destinatários de outro. Se a mesma pessoa recebeu entregas de dois parceiros, as operações têm de manter essas relações separadas, enquanto a privacidade pode ainda precisar de encontrar a pessoa nos dois. Não resolva a privacidade quebrando a fronteira de segurança, e não proteja a fronteira tornando os pedidos de privacidade impossíveis. A arquitetura tem de fazer as duas coisas.

As fotografias e o texto livre também são dados

É fácil pensar na privacidade como campos: nome, e-mail, telefone, morada. Mas a Steve Trucking tira milhões de fotografias de entrega por ano, e algumas mostram pessoas ou o interior de uma casa. Uma política de retenção ou eliminação que só olha para campos estruturados está incompleta; também está uma que ignora ficheiros, documentos, transcrições, logs, e prompts e respostas de IA.

E o texto livre é perigoso. Remove o nome, o telefone e a morada, e depois encontra esta nota de entrega: «Ligar à Joana para o 602-555-0198. Código do portão 4821. Cão no quintal.» Ali está. Classificar as notas de entrega como sensíveis diz que pode haver um problema; não encontra nem remove os dados pessoais dentro do texto. Às vezes a melhor resposta é impedir que pormenores pessoais desnecessários lá caiam. Controle primeiro para onde vão os dados pessoais.

O Privacy Center é uma ferramenta, não a arquitetura inteira

O Privacy Center da Salesforce ajuda a executar estes processos. As suas políticas de direito a ser esquecido são montadas por objeto, para apanhar tudo o que quer remover, e correm contra um registo de cliente específico (Delete Data with Right to Be Forgotten Policies (opens in a new tab), em inglês). Isso é útil. Mas «comprámos o Privacy Center, por isso está resolvido» não é uma arquitetura. Os dados da pessoa podem viver fora do alcance de qualquer ferramenta: Data 360, o data warehouse, sistemas de parceiros, arquivos, logs, pesquisa, ficheiros multimédia, conversas de agentes. A empresa continua a precisar de uma resposta empresarial, e precisa de verificar o que cada ferramenta cobre realmente antes de contar com ela.

Portabilidade e prova

Algumas leis também dão às pessoas o direito de receber uma cópia dos seus dados. Repare que é o mesmo problema de descoberta: a eliminação pergunta onde estão os dados desta pessoa, para agirmos sobre eles? A portabilidade pergunta onde estão, para os fornecermos? As duas apoiam-se em identidade, classificação, linhagem, inventário de sistemas e propriedade.

E depois: como prova que o fez? Pedido recebido, identidade verificada, sistemas pesquisados, ações tomadas, exceções registadas, dados retidos justificados, conclusão registada. Há uma tensão real aqui: está a remover os dados pessoais de alguém enquanto guarda evidências suficientes para mostrar que tratou bem o pedido. É exatamente por isso que os arquitetos não devem inventar regras de retenção por conta própria. O Jurídico e a conformidade decidem que evidências têm de permanecer; a arquitetura guarda-as sem guardar os dados que deveria remover.

Além do exame: o que a IA muda. A IA cria novas finalidades e novas cópias. A permissão para usar dados para prestar um serviço não cobre automaticamente a fundamentação (grounding) de um agente, a personalização ou o treino; a Finalidade de uso dos dados é o sítio natural para distinguir estas coisas. E os dados pessoais podem sobreviver em prompts, contexto de fundamentação, conversas, resumos, índices de pesquisa e vetoriais, e logs. «Eliminámos o registo de origem» não é uma resposta completa se a camada de IA ainda se lembra.

O que um arquiteto decide aqui

• Como o consentimento e o uso permitido são modelados, para que os sistemas consigam responder a quem, que canal, que ponto de contacto e que finalidade.
• Que sistema tem autoridade sobre o consentimento, e como as retiradas chegam a cada sistema que age com base nele.
• Por onde se podem espalhar os dados pessoais: campos, texto livre, ficheiros, histórico, análise, arquivo, integrações, pesquisa e IA.
• Como um pedido encontra a pessoa certa e conduz a eliminação, a desidentificação ou a retenção aprovada em cada local.
• Que evidências permanecem para provar que o consentimento e os pedidos de privacidade foram tratados.

Consentimento e eliminação parecem opostos (podemos usar estes dados? conseguimos parar e removê-los?), mas apoiam-se nas mesmas bases: identidade, finalidade, classificação, linhagem, propriedade, aplicação e evidência. Use o modelo de consentimento padrão, controle para onde vão os dados pessoais, saiba onde estão as cópias, e projete o processo de eliminação antes de chegar o primeiro pedido. Quando alguém perguntar «conseguem esquecer-me?», a arquitetura precisa de uma resposta melhor do que «achamos que sim».

Para saber mais

• 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), artigo 12.º, n.º 3, o prazo para dar seguimento a um pedido, consultado em 2026-10-14.
• Salesforce Help, Delete Data with Right to Be Forgotten Policies (opens in a new tab) (Privacy Center; em inglês), consultado em 2026-10-14.