Consentimento e direito ao esquecimento

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

Imagem gerada com IA

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

Módulo 5 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: 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 mandar mensagem para ele? 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 ideia?

Agora a outra direção. O Destinatário diz: apaguem minhas informações pessoais. Onde elas estão? No Salesforce, provavelmente, mas aprendemos que essa não é a resposta inteira. Vieram de um Parceiro varejista. Podem estar numa plataforma de dados do cliente (customer data platform), no histórico de campos, num arquivo, numa observação de entrega, numa exportação, num log de integração, na conversa de um agente. Consentimento e exclusão soam como perguntas de política, mas em algum momento o sistema precisa respondê-las. Isso é arquitetura.

Consentimento é dado

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

Use o modelo que a Salesforce já construiu

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 gerencia 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 ela disse não a tudo?
• Consentimento por canal de engajamento (Contact Point Type Consent): podemos usar este tipo de canal, como SMS ou e-mail?
• Consentimento por ponto de contato: e este número de telefone ou endereço de e-mail específico?
• Finalidade de uso dos dados (Data Use Purpose): por qual motivo: notificações de entrega, atendimento, marketing?

Juntando tudo, a arquitetura consegue responder “podemos usar as informações desta pessoa, por este ponto de contato, para esta finalidade?”, o que é muito mais útil do que “consentimento = sim”. Qualquer registro que se relacione a um indivíduo pode participar: leads, contatos, contas pessoais, usuários.

Click to enlarge

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

A finalidade importa

Um Parceiro varejista manda à Steve Trucking o telefone de um Destinatário para que a equipe 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 precisa distingui-los. A pergunta não é temos o número de telefone? É o que temos permissão para fazer com ele?

E o consentimento nem sempre é a base legal. Alguns usos se apoiam em outras bases que a lei prevê, e isso é determinação do Jurídico. Não construa uma arquitetura que presume que toda decisão de privacidade é uma caixa de opt-in. Sustente o que a política disser: se um uso depende de consentimento, modele e aplique o consentimento; se outra base se aplica, ainda assim armazene 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. Então projete o ciclo de vida: o que foi escolhido, quando, como, para qual 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 controle.

Isso significa perguntar qual sistema tem autoridade sobre o consentimento. O Salesforce, uma plataforma de preferências, outro lugar? 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 quaisquer dados governados precisam: um dono, um registro com autoridade, uma forma de sincronizar, e aplicação.

Agora a pessoa diz: me esqueçam

O primeiro instinto é excluir o contato e dar por encerrado. Mas os dados da pessoa podem estar num contato, numa entrega, numa observação de entrega, num caso, numa foto, no histórico de campos, no Snowflake, num arquivo, num log de integração, num índice de busca ou no histórico de conversas de um agente. É por isso que minha posição sobre a exclusão começa antes: a exclusão é rara e difícil na prática, então controle primeiro para onde vão os dados pessoais. Projete para que eles caiam no menor número possível de lugares. Depois, quando chegar um pedido, ofusque ou desvincule 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 busca e conversas de agentes.

Não comece a caçada quando o pedido chegar. 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. Você já sabe quais campos guardam dados pessoais e para onde foram as cópias.

Click to enlarge

Um pedido de “me esqueçam” é uma decisão para cada cópia.

O relógio está correndo

Esses pedidos vêm com prazos. Pelo GDPR, a organização precisa atender ao pedido de uma pessoa sem demora injustificada e dentro de um mês a partir do recebimento; para pedidos complexos ou numerosos, o prazo pode ser prorrogado por mais dois meses, mas a pessoa precisa ser informada dentro do primeiro mês, com os motivos (artigo 12.º, n.º 3, Regulamento (UE) 2016/679 (opens in a new tab)). Outras leis definem os próprios prazos; o Jurídico vai dizer quais se aplicam. De um jeito ou de outro, um mês não é tempo suficiente para descobrir o panorama. Esse é o prazo que o mapa de cópias precisa vencer.

Excluir, desidentificar ou reter?

Um pedido não significa necessariamente que tudo, em todo lugar, desaparece. Alguns registros devem ou podem ser mantidos; alguns registros 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 por local: excluir, desidentificar, ou manter sob um requisito aprovado (e então quem pode ver, por quanto tempo, por quê?).

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

Você não consegue excluir o que não consegue encontrar

Antes de apagar alguém, você precisa encontrá-lo. O pedido vem de um endereço de e-mail. Um Parceiro varejista mandou “Joana Silva”, outro “J. Silva”, e o telefone mudou. O Destinatário nem é um contato; os dados dele ficam em cada entrega. A mesma pessoa recebeu entregas de dois parceiros diferentes. Um sistema a conhece pelo e-mail, outro por um ID externo. A exclusão depende da identidade, e você não quer excluir os dados de outra pessoa porque sua correspondência foi agressiva demais. A arquitetura de identidade faz parte da arquitetura de privacidade.

A Steve Trucking torna isso ainda mais difícil. Um Parceiro varejista nunca pode ver as entregas ou os Destinatários de outro. Se a mesma pessoa recebeu entregas de dois parceiros, as operações precisam manter esses relacionamentos separados, enquanto a privacidade ainda pode precisar 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 precisa fazer as duas coisas.

Fotos e texto livre também são dados

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

E texto livre é perigoso. Você remove o nome, o telefone e o endereço, e depois encontra esta observação de entrega: “Ligar para a Joana no 602-555-0198. Código do portão 4821. Cachorro no quintal.” Lá está. Classificar as observações 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 detalhes pessoais desnecessários caiam ali. 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 esses processos. Suas políticas de direito ao esquecimento são montadas por objeto, para capturar tudo o que você quer remover, e rodam contra um registro de cliente específico (Delete Data with Right to Be Forgotten Policies (opens in a new tab), em inglês). Isso é útil. Mas “compramos o Privacy Center, então acabou” 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, busca, arquivos de mídia, conversas de agentes. A empresa ainda precisa de uma resposta corporativa, e você precisa verificar o que cada ferramenta realmente cobre 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 exclusão pergunta onde estão os dados desta pessoa, para agirmos sobre eles? A portabilidade pergunta onde estão, para os fornecermos? As duas se apoiam em identidade, classificação, linhagem, inventário de sistemas e propriedade.

E depois: como você prova que fez? Pedido recebido, identidade verificada, sistemas pesquisados, ações tomadas, exceções registradas, dados retidos justificados, conclusão registrada. Há uma tensão real aqui: você está removendo os dados pessoais de alguém enquanto guarda evidências suficientes para mostrar que tratou o pedido direito. É 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 precisam permanecer; a arquitetura as guarda 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 o embasamento (grounding) de um agente, a personalização ou o treinamento; a Finalidade de uso dos dados é o lugar natural para distinguir essas coisas. E dados pessoais podem sobreviver em prompts, contexto de embasamento, conversas, resumos, índices de busca e vetoriais, e logs. “Excluímos o registro 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 quem, qual canal, qual ponto de contato e que finalidade.
• Qual sistema tem autoridade sobre o consentimento, e como as retiradas chegam a cada sistema que age com base nele.
• Por onde os dados pessoais podem se espalhar: campos, texto livre, arquivos, histórico, análise, arquivamento, integrações, busca e IA.
• Como um pedido encontra a pessoa certa e conduz a exclusã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 exclusão parecem opostos (podemos usar estes dados? conseguimos parar e removê-los?), mas se apoiam 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 exclusão antes que chegue o primeiro pedido. Quando alguém perguntar “vocês conseguem me esquecer?”, 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 (GDPR, ou RGPD) (opens in a new tab), artigo 12.º, n.º 3, o prazo para atender 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.