A privacidade é o que resta depois de o sistema aprender a esquecer.

O direito ao apagamento não é um botão rotulado «eliminar». Nos sistemas modernos, é uma questão disciplinada sobre cópias, dados derivados, provas,...

A privacidade é o que resta depois de o sistema aprender a esquecer.

Esquecer não é o oposto de recordar

Um processo em papel tem uma vida visivelmente tranquilizadora. Chega, é colocado em algum sítio, é copiado se alguém tiver uma fotocopiadora e acaba por ir para um triturador ou para um arquivo. A parte difícil pode ser decidir se deve ser destruído, mas o objeto em si é obedientemente finito. Um registo digital é menos educado. Pode ser armazenado como uma linha, um anexo, um índice de pesquisa, uma pré-visualização de mensagem, um bloco de cópia de segurança, uma entrada de auditoria, uma caraterística numa entrada de modelo, um vetor num armazenamento de embeddings, uma resposta em cache ou um valor que viajou para o sistema de outra organização. Não basta perguntar onde vive o original. A pergunta mais útil é o que foi feito a partir dele, o que ainda permite identificar uma pessoa e que propósito serve cada vestígio restante.

É essa a dignidade prática do direito ao apagamento. É frequentemente chamado direito a ser esquecido, uma expressão vívida mas imperfeita. O esquecimento humano é acidental, parcial e cheio de regressos embaraçosos. Um processo de apagamento legal deve ser deliberado. Deve ser capaz de distinguir um registo que tem de ser removido de um registo que tem de ser conservado porque a lei o exige, de uma alegação contestada que tem de permanecer disponível para uma defesa legal e de um resíduo técnico que pode ser isolado até ao seu prazo de expiração. Deve também resistir a um instinto corporativo útil: tratar o apagamento como um estado de ecrã e não como uma propriedade dos sistemas.

O Regulamento Geral sobre a Proteção de Dados não promete que todos os elementos ligados a uma pessoa desaparecerão a pedido. O artigo 17.º estabelece os fundamentos pelos quais um responsável pelo tratamento deve apagar dados pessoais sem demora injustificada, incluindo quando os dados deixam de ser necessários para a finalidade para a qual foram recolhidos ou tratados, quando o consentimento é retirado e não existe outro fundamento jurídico e quando o tratamento foi ilícito. O mesmo artigo estabelece limites. O apagamento não se aplica quando o tratamento for necessário, por exemplo, para o exercício da liberdade de expressão e de informação, para o cumprimento de uma obrigação legal, para tarefas de interesse público em algumas circunstâncias, por motivos de saúde pública, para fins de arquivo, de investigação ou estatísticos sujeitos a salvaguardas, ou para efeitos de ações judiciais. Isso não é uma lacuna numa promessa. É a forma real do direito.

Portanto, a pergunta para quem gere um sistema não é: «Conseguimos apagar dados?» Quase qualquer sistema consegue apagar alguma coisa. A pergunta é se a organização consegue explicar, para um pedido específico e para uma finalidade de tratamento específica, que dados detém, o que aconteceu a esses dados, o que é obrigada ou tem direito a conservar, que destinatários a jusante precisam de ser informados e como pode ser verificada a ação concluída. A diferença parece processual. Na prática, é arquitetural. Um produto que só sabe adicionar informação descobrirá que o apagamento é uma funcionalidade muito mais cara.

Isto é especialmente acentuado nos sistemas de IA, mas não se limita à IA. A pesquisa, a análise, o apoio ao cliente, a identidade, a monitorização de segurança e a gestão de documentos produzem todos derivados. Um modelo apenas dá novos nomes ao problema: tokens, gradientes, embeddings, índices de recuperação, prompts e resultados. Nenhum desses rótulos dissolve a questão subjacente de saber se uma pessoa singular continua identificável. Nem um termo técnico responde silenciosamente à questão jurídica. Um embedding não é automaticamente anónimo porque é difícil de ler. Um registo não é automaticamente necessário porque é útil. Uma cópia de segurança não está automaticamente isenta porque é inconveniente.

A privacidade depois do esquecimento não é, portanto, uma página em branco. É o estado residual que permanece depois de uma organização ter tomado uma decisão legal, proporcionada e verificável sobre o que já não deve ser tratado. A qualidade desse estado residual diz às pessoas muito mais sobre um sistema do que a presença de um botão de eliminar jamais dirá.

O direito tem condições, e isso torna-o mais forte

A lei europeia de proteção de dados é por vezes descrita como se oferecesse ao indivíduo um botão vermelho universal. Essa imagem serve para um diapositivo, mas é suficientemente errada para causar problemas. O artigo 17.º está ligado à finalidade, à base jurídica e às circunstâncias do tratamento. Contém um direito, obrigações para os responsáveis pelo tratamento e exceções que protegem outros direitos e interesses públicos. Uma resposta responsável começa por determinar a identidade do requerente, quando tal seja necessário, compreender os dados e a finalidade do tratamento em causa e decidir se se aplicam um fundamento do artigo 17.º e uma exceção. A resposta pode ser o apagamento. Pode ser uma recusa fundamentada, no todo ou em parte. Pode ser a limitação do tratamento enquanto um litígio é resolvido. Pode também ser um pedido que aponte para um sistema que a organização não controla.

Isto não é motivo para transformar um pedido do titular dos dados num pequeno percurso de obstáculos. O RGPD exige que os responsáveis pelo tratamento facilitem o exercício dos direitos. O artigo 12.º exige que as informações e comunicações sobre as medidas tomadas relativamente a um pedido sejam concisas, transparentes, inteligíveis e de fácil acesso. Exige, em geral, que a informação sobre as medidas tomadas seja fornecida sem demora injustificada e, em qualquer caso, no prazo de um mês a contar da receção do pedido. Esse prazo pode ser prorrogado por mais dois meses, quando necessário, tendo em conta a complexidade e o número de pedidos, mas o responsável deve informar a pessoa sobre a prorrogação e os respetivos motivos no prazo de um mês. Um sistema que só ao fim de três meses consegue identificar os seus próprios fluxos de dados não encontrou uma defesa processual. Encontrou um problema de governação.

As orientações do Comité Europeu para a Proteção de Dados para pequenas e médias empresas expõem claramente o ponto operacional: as pessoas podem pedir o apagamento em circunstâncias específicas, e as organizações devem ter procedimentos para responder aos pedidos de direitos. Um procedimento não é um parecer jurídico guardado numa pasta partilhada. É um percurso de trabalho do pedido à decisão e à execução. Inclui as funções autorizadas a decidir, os mapas de dados que lhes permitem ver o tratamento relevante, os fornecedores e destinatários que podem precisar de uma notificação, os calendários de conservação que explicam uma exceção e as provas que permitem a um revisor posterior compreender o que foi feito.

O Tribunal de Justiça ajudou a tornar visível outra distinção. Os seus acórdãos sobre a desreferenciação dizem respeito à apresentação de ligações pelos motores de busca, não a uma instrução para apagar a publicação subjacente do sítio Web de origem. No acórdão Google Spain, o Tribunal considerou que o operador de um motor de busca pode ser responsável pelo tratamento de dados pessoais que aparecem em páginas Web publicadas por terceiros e que o titular dos dados pode, em certas circunstâncias, pedir a remoção de ligações de uma lista de resultados apresentada na sequência de uma pesquisa pelo nome da pessoa. Em acórdãos posteriores, o Tribunal abordou questões como os dados sensíveis, o âmbito territorial da desreferenciação e as informações inexatas. Esses acórdãos não transformam todos os factos indesejados num pedido de apagamento. Mostram por que motivo um sistema tem de identificar a camada em causa: publicação de origem, índice, lista de resultados, cache, extrato ou outra cópia.

Essa disciplina de camadas também é importante dentro das organizações. Um trabalhador pode pedir a um responsável que apague um registo de contacto que já não é necessário para uma finalidade de recrutamento. O responsável pode ter de avaliar uma obrigação de conservação separada para efeitos de remuneração ou de prova de igualdade de tratamento. Uma entidade pública pode tratar um registo no âmbito de uma atribuição legal e ter de avaliar a legislação aplicável em vez de repetir uma resposta do setor privado. Um editor pode ter de ponderar a liberdade de expressão e de informação. O resultado não pode ser decidido apenas pelo vocabulário da base de dados.

É tentador ressentir as condições porque impedem uma promessa simples. Mas são elas que tornam a promessa significativa. Um direito que ignora deveres legais, outros direitos fundamentais e a distinção prática entre sistemas colapsaria num ritual. A abordagem europeia exige uma decisão responsável, não uma decisão teatral. Isso exige mais trabalho. Também torna uma recusa contestável e um apagamento credível.

O apagamento começa por localizar as superfícies de processamento. O diagrama é um mapa de sistemas, não uma afirmação de que todas as superfícies têm o mesmo tratamento legal.

Um registo pode desaparecer do ecrã e permanecer no sistema

A falha de eliminação mais fácil é familiar a quem já construiu uma aplicação: remover um item da interface do produto, deixar os dados subjacentes num armazenamento e assumir que o trabalho está feito porque os utilizadores comuns já não o veem. Por vezes, uma eliminação suave é exatamente o desenho operacional certo. Pode preservar um curto período de anulação, tornar a replicação segura ou evitar quebrar uma relação que tem de ser resolvida. Mas a eliminação suave não é apagamento apenas porque a interface ficou mais silenciosa. A sua utilização tem de estar ligada a uma finalidade definida, a um período de retenção, a controlos de acesso e a uma ação posterior que altere efetivamente o estado dos dados.

A eliminação definitiva tem os seus próprios limites. Eliminar uma linha pode deixar um índice de pesquisa até ao próximo ciclo de indexação. Um armazenamento de objetos pode ter versionamento. Uma cache de entrega de conteúdos pode manter uma resposta até expirar ou ser invalidada. Uma fila de mensagens pode conter um evento ainda não processado. Um armazém de dados pode ter ingerido uma imagem instantânea. Um serviço pode ter transferido os dados para um processador, um subprocessador ou um destinatário. A lição prática não é que a eliminação seja impossível. É que uma organização precisa de um inventário com fidelidade suficiente para distinguir estas superfícies e de uma política que indique o que acontece em cada uma.

Há ainda uma distinção entre conteúdo e prova. Um bilhete de apoio ao cliente pode conter a mensagem de uma pessoa. O sistema pode precisar de um registo de que o bilhete existiu, foi resolvido e foi eliminado ao abrigo de uma regra aprovada. Manter a mensagem inteira para sempre para provar que foi eliminada é uma pequena obra-prima burocrática, mas não é um controlo de privacidade. Um desenho melhor retém apenas a prova mínima necessária para a responsabilização, separada do conteúdo que já não tem finalidade. Essa prova pode ser um identificador de pedido, o tipo de decisão, o momento de conclusão, a categoria de retenção aplicável e os sistemas alcançados. O desenho depende da organização. O princípio não depende: a prova não deve recriar os dados pessoais desnecessários.

As cópias de segurança merecem a mesma linguagem simples. Uma cópia de segurança pode ser necessária para disponibilidade, segurança ou recuperação de desastres. Continua a ser processamento. A questão prática é se a cópia de segurança é acessível separadamente, durante quanto tempo permanece recuperável, quem a pode restaurar, se está incluída no fluxo normal de apagamento e como se evita que um ambiente restaurado reintroduza silenciosamente dados que entretanto foram removidos do sistema ativo. Uma política razoável pode depender do período de rotação definido da cópia de segurança, em vez de modificar individualmente cada bloco histórico. Mas uma política tem de o dizer, proteger o acesso entretanto e garantir que a restauração segue o estado atual dos dados sempre que possível. «Está na cópia de segurança» descreve um problema. Não é uma resposta para ele.

Os registos são semelhantes. Os registos de segurança e operacionais podem ser essenciais. Podem constituir o único relato de um acesso, de uma tentativa de autenticação falhada ou de uma alteração de produção. Podem também reter identificadores, endereços, corpos de pedidos ou fragmentos de conteúdo que nunca foram necessários para o diagnóstico. Um bom design de registos minimiza a recolha, anonimiza ou pseudonimiza quando adequado, separa os dados sensíveis dos metadados de eventos, limita o acesso e aplica políticas de retenção. Tentar descobrir todos os campos sensíveis durante um pedido de apagamento é possível, mas é um substituto pobre para decidir, na fase de design, o que o registo nunca deveria ter contido.

Um responsável técnico não precisa de prometer um apagamento imediato e uniforme em todos os dispositivos para agir de forma responsável. Precisa de conseguir indicar o ciclo de vida: o que fica indisponível imediatamente, o que é removido na próxima execução de processamento, o que persiste ao abrigo de uma política de retenção documentada, o que permanece protegido até expirar e o que acontecerá se ocorrer uma operação de recuperação. Esse relato dá a uma pessoa, a um regulador e a um operador algo concreto para examinar. Uma notificação verde dá-lhes muito pouco.

Os dados derivados não são uma via de escape

Os sistemas modernos transformam frequentemente dados pessoais antes de os utilizarem. Extraem uma data de um documento, classificam uma mensagem, calculam uma pontuação, inferem um idioma, criam um índice de pesquisa, produzem um resumo, associam duas contas ou convertem texto e imagens em vetores utilizados para pesquisa por semelhança. Essas transformações podem ser úteis. Podem também fazer com que uma organização sinta que ultrapassou os dados pessoais. Não é necessariamente o caso.

O RGPD é tecnologicamente neutro. Os seus considerandos explicam que os dados pseudonimizados que possam ser atribuídos a uma pessoa singular mediante informações adicionais devem ser considerados informações sobre uma pessoa singular identificável. Explicam também que a identificabilidade deve ter em conta todos os meios razoavelmente suscetíveis de serem utilizados, pelo responsável pelo tratamento ou por outra pessoa, considerando fatores como o custo, o tempo, a tecnologia disponível e a evolução tecnológica. A questão não é se uma representação se parece com um nome numa folha de cálculo. É se se refere a uma pessoa identificada ou identificável no contexto real.

Um embedding torna este ponto utilmente desconfortável. Num sistema de recuperação, um documento pode ser dividido em segmentos e representado como vetores numéricos para que uma consulta encontre material semanticamente semelhante. O vetor não é um parágrafo legível. Pode, no entanto, estar ligado a um documento de origem, a um inquilino, a um utilizador, a um controlo de acesso, a um campo de metadados ou a uma chave de recuperação. Pode permitir que o sistema selecione material pessoal em resposta a uma consulta. A organização não pode considerá-lo anónimo apenas porque um ser humano não consegue reconstruir uma frase olhando para uma lista de coordenadas. Tem de avaliar a representação, os dados associados, os meios de associação e a finalidade do tratamento.

O mesmo se aplica a uma pontuação derivada. Uma pontuação de risco, uma categoria de preferência ou um indicador de elegibilidade pode conter menos detalhe bruto do que os dados de origem e ainda assim ter efeitos graves para a pessoa. Pode ser um dado pessoal se se referir a uma pessoa identificada ou identificável. Eliminar a origem mantendo uma pontuação que continua a influenciar uma decisão não é uma resposta limpa. Pode simplesmente mover a pessoa para uma forma mais opaca. O sistema precisa de uma regra para os derivados: quais são eliminados com a origem, quais são recalculados, quais deixam de poder ser utilizados, quais devem ser conservados ao abrigo de uma obrigação separada e quem decide.

Não existe um teste técnico universal que resolva todos os derivados. Algumas estatísticas agregadas podem ser anónimas. Algumas podem continuar vulneráveis a individualização ou associação. Alguns parâmetros de modelos podem não ser razoavelmente atribuíveis a um indivíduo num determinado contexto. Outros podem estar associados a dados de treino, a um modelo de âmbito restrito ou a uma superfície de ataque que altera a avaliação. O conceito de informação anónima do RGPD não é um rótulo decorativo para dados que se tornaram inconvenientes de interpretar. O responsável pelo tratamento deve fazer uma avaliação fundamentada nos meios e no contexto de identificação.

Essa incerteza não é motivo para descrever todos os derivados como permanentemente tóxicos. É motivo para manter a linhagem. Uma equipa deve saber quais as coleções de entrada utilizadas para um feature store, um índice, uma execução de treino ou uma tabela de relatórios; quais as versões de um derivado produzidas; quais os sistemas que as consomem; e que resposta uma alteração na fonte deve desencadear. A linhagem transforma uma pergunta desconfortável numa tarefa de engenharia delimitada. Sem ela, cada pedido de direitos torna-se uma expedição arqueológica através de nomes de tarefas, buckets de armazenamento e a memória de alguém sobre uma migração feita há dois invernos.

A aprendizagem automática acrescenta uma pergunta difícil, não uma isenção mágica

A aprendizagem automática dificulta o apagamento porque o treino não é uma operação de arquivo. Um exemplo de treino pode afetar parâmetros através de uma longa sequência de atualizações, juntamente com muitos outros exemplos. Um modelo implementado pode ter sido copiado para vários ambientes. Um modelo posterior pode ter sido afinado a partir de um anterior. Uma equipa pode usar dados de avaliação, prompts, corpora de recuperação e registos de feedback que seguem ciclos de vida diferentes. Se os dados de uma pessoa entraram num desses sistemas, uma organização não pode responder responsavelmente com um encolher de ombros sobre a matemática. Também não pode prometer honestamente que a eliminação de uma base de dados remove toda a influência possível de todos os parâmetros.

O primeiro passo é separar os sistemas. Um corpus de recuperação não é um modelo treinado. Se um documento é usado como fonte para recuperação, o apagamento pode envolver remover ou desativar o documento, os seus fragmentos, metadados e entradas de índice, e depois verificar se a recuperação já não o alcança. Um registo de prompts não é um armazenamento de embeddings. Um conjunto de dados de afinação não é uma trilha de auditoria de segurança. Um checkpoint de modelo não é um registo de fonte atual. A resposta correta pode ser diferente para cada superfície, mas uma resposta não pode ser concebida até que as superfícies sejam nomeadas.

Para dados de treino, a análise legal e técnica pode exigir uma decisão sobre se o retreino, a substituição, a restrição, a retenção ou outra medida é apropriada. A investigação sobre machine unlearning é relevante porque explora métodos para reduzir a influência de dados específicos sem retreinar um modelo do zero. Não é um certificado geral de que um sistema esqueceu. Os métodos têm pressupostos, classes de modelos, condições de dados e limites de verificação. Uma organização não deve comercializar uma técnica experimental como uma implementação universal do Artigo 17. Também não deve esperar por uma técnica perfeita antes de conceber melhores controlos de dados.

Melhores controlos começam a montante. Minimize os dados recolhidos. Separe os dados pessoais do material de treino quando a finalidade pretendida o permitir. Defina um período de retenção antes de a acumulação tornar a pergunta emocionalmente cara. Mantenha registos com versões de conjuntos de dados e execuções de treino. Torne explícitas as condições de opt-in ou outras condições legais quando forem a base relevante. Evite que um arquivo de prompts de produção se torne silenciosamente um corpus de desenvolvimento de modelos. Mantenha o material de avaliação e suporte distinguível dos dados de treino. Quanto menos um sistema depender de proveniência desconhecida, mais precisamente poderá responder a uma pergunta de eliminação.

Há também um limite para a palavra «influência». Uma pessoa pode estar preocupada por um texto ter feito parte de um conjunto de treino. Uma equipa técnica pode conseguir determinar que o registo de origem foi removido de um corpus atual, mas não provar, num sentido filosófico amplo, que não resta nenhum fragmento de influência em qualquer parâmetro de um modelo histórico. A lei da privacidade não se torna mais fácil quando uma organização substitui uma descrição concreta por metafísica. A obrigação é avaliar o tratamento, os fundamentos e as medidas nos termos da lei. A organização deve explicar o âmbito da sua conclusão, os sistemas que abrange e a limitação remanescente. A precisão é mais gentil do que uma promessa extravagante.

Para os responsáveis pela implementação de IA, o ónus prático recai muitas vezes tanto sobre o aprovisionamento como sobre a engenharia. Um fornecedor deve ser capaz de explicar o que faz com os pedidos, os ficheiros carregados, a telemetria e o feedback opcional; quais desses são utilizados para treino ou melhoria do serviço; que controlos de retenção existem; como um cliente pode obter as informações necessárias para responder a pedidos de direitos; e o que acontece num ambiente partilhado versus dedicado. Um contrato que apenas diga «conforme com o RGPD» não forneceu as informações necessárias para operar um processo de apagamento. Forneceu um adjetivo.

Os motores de busca ensinam uma lição útil sobre camadas

A jurisprudência do Tribunal de Justiça sobre a desreferenciação é útil aqui precisamente por ser mais restrita do que a expressão popular «direito a ser esquecido». Os processos dizem respeito a saber se, e em que condições, um motor de busca deve remover ligações de resultados baseados no nome. Não criam um simples poder de alterar a história na sua origem. Essa distinção mostra que as questões de privacidade dizem muitas vezes respeito à forma como a informação é disponibilizada, ligada e amplificada, e não apenas se um registo existiu alguma vez.

No processo Google Spain, o Tribunal considerou ligações na lista de resultados de um motor de busca para páginas publicadas por terceiros. A decisão deixou claro que a atividade de um motor de busca pode constituir tratamento de dados pessoais e que, em condições específicas, o operador pode ser obrigado a remover ligações dos resultados apresentados após uma pesquisa sobre o nome de uma pessoa. A decisão não foi uma ordem dirigida ao jornal que publicou os avisos originais. O proprietário de um sistema que analisa uma base de conhecimento interna pode aprender com isto: os índices de pesquisa, as pré-visualizações e a classificação de resultados são camadas de tratamento com consequências próprias.

O processo GC e Outros examinou pedidos de remoção de ligações para páginas web que continham dados pessoais sensíveis. O Tribunal abordou a ponderação envolvida e os deveres que podem surgir para um operador de motor de busca. O processo Google v CNIL abordou o âmbito territorial e decidiu, nas circunstâncias desse caso, que o direito da UE não exigia a desreferenciação em todas as versões de um motor de busca a nível mundial, exigindo simultaneamente medidas eficazes para impedir ou desencorajar seriamente o acesso, a partir dos Estados-Membros, a ligações removidas das versões da UE. O processo TU e RE dizia respeito a um pedido relativo a informações alegadamente inexatas e clarificou elementos do ónus da prova e o tratamento de imagens de pré-visualização. Estes acórdãos são decisões jurídicas específicas dos factos, não uma lista de verificação para implementação. Em conjunto, fazem um ponto de vista sistémico: a ligação, a lista de resultados, a pré-visualização da imagem e a página original não têm automaticamente o mesmo remédio.

Esse ponto aplica-se bem. Um portal empresarial pode conservar legalmente um registo de origem para um fim limitado, enquanto o acesso através de uma superfície de pesquisa ampla é excessivo. Um sistema de apoio técnico pode precisar de uma entrada de auditoria protegida, enquanto a sua pré-visualização de autocompletar não deve expor os dados de um antigo cliente a um grande grupo. Um documento pode ser removido de um corpus de recuperação enquanto um resumo gerado por modelo permanece num armazenamento diferente. A resposta correta não é declarar todas as camadas idênticas. É compreender como a camada altera a exposição, a finalidade e o risco.

O documento alerta também para um atalho popular: assumir que a visibilidade é a única questão de privacidade. Um registo pode estar tecnicamente oculto e ainda assim ser processado, consultado, utilizado para traçar perfis, transferido ou restaurado. Inversamente, uma organização pode precisar de um registo cuidadosamente limitado para provar que respondeu adequadamente, proteger uma pretensão legal ou cumprir um dever estatutário. A privacidade não é uma competição para produzir a menor quantidade de dados em todas as circunstâncias imagináveis. É uma disciplina de finalidade, necessidade, proporcionalidade e controlo.

É por isso que um inventário de eliminação deve incluir os caminhos de recuperação e apresentação. Pergunte quais os índices que contêm o registo, quais as caches que o servem, quais as exportações que o incluem, quais as APIs que o devolvem, quais os campos derivados utilizados para classificar ou recomendar e quais os caminhos de restauro de cópias de segurança que o podem tornar novamente ativo. A lista não será elegante. Será mais útil do que a elegância.

Demonstração é diferente de afirmação

Quando um sistema afirma que consegue apagar dados, há duas questões separadas. A primeira é se o design tem uma via legítima e documentada para o fazer. A segunda é se uma organização consegue demonstrar que essa via foi seguida para um pedido específico sem preservar mais material pessoal do que o necessário para a demonstração. A primeira é uma capacidade do produto. A segunda é responsabilização.

Um registo de eliminação útil é deliberadamente modesto. Não precisa de reproduzir o pedido completo de uma pessoa, documentos ou histórico de conta numa nova base de dados de conformidade. Pode registar uma referência do pedido, o resultado da verificação de identidade quando adequado, a categoria do pedido, os sistemas aplicáveis, a decisão e a fundamentação legal a um nível apropriado, as datas das ações, as exceções ou motivos de retenção, as notificações aos destinatários quando exigidas e o estado da eliminação assíncrona ou da expiração das cópias de segurança. Os campos exatos dependem do responsável pelo tratamento e do contexto. O que importa é que um revisor posterior consiga ver o caminho sem reconstruir o conteúdo sensível a partir de fragmentos.

A verificação deve corresponder à superfície dos dados. Um registo de uma aplicação em funcionamento pode ser verificado confirmando que uma consulta autorizada já não o devolve. Um sistema de recuperação pode ser testado com o identificador original e padrões de consulta relevantes, evitando tentativas amplas de recriar conteúdo pessoal. Um índice pode comunicar o seu estado de eliminação. Uma fila pode mostrar a conclusão. Um processo de cópias de segurança pode mostrar que uma imagem de recuperação está protegida pela sua regra de retenção e que o restauro aplica um registo de eliminação atual ou controlo equivalente. A verificação não precisa de provar uma negativa metafísica. Precisa de fornecer provas proporcionais à afirmação feita.

Há aqui uma armadilha modesta. Uma equipa pode criar um painel impressionante com todas as luzes verdes acesas e sem relação estável com o trabalho. Um painel significativo identifica a superfície de dados, a ação, o estado, o responsável, as provas e a próxima revisão. Permite distinguir entre «pedido aceite», «registo ativo eliminado», «notificação ao destinatário pendente», «cópia de segurança a aguardar expiração» e «retido por obrigação legal». Esses estados têm significados diferentes. Colapsá-los em «eliminado» transforma a incerteza em design de interface de utilizador.

A eliminação demonstrável depende também da gestão de mudanças. Um sistema de origem pode ser substituído, um processador adicionado, um formato de índice alterado, um novo destino analítico introduzido ou a política de retenção de um fornecedor de IA revista. Se o procedimento de eliminação não for atualizado com essas mudanças, o procedimento passa gradualmente a descrever um sistema que já não existe. O resultado é familiar em qualquer disciplina operacional: um manual bonito e um serviço real a moverem-se em direções opostas. Testar regularmente uma pequena amostra do caminho, incluindo o sistema problemático, é geralmente mais revelador do que encomendar um grande documento de garantia que ninguém consegue executar.

Para uma autoridade pública ou uma empresa regulada, esta não é uma questão restrita ao gabinete de privacidade. O encarregado da proteção de dados pode orientar a interpretação, mas a engenharia é responsável pelas interfaces e pelos mecanismos de eliminação, o produto é responsável pela finalidade e pelo percurso do utilizador, as compras são responsáveis pelas obrigações de informação impostas aos fornecedores, a segurança é responsável pelos controlos de acesso e de restauro, e as operações são responsáveis pela execução sob pressão. Um único responsável não consegue inspecionar todas as camadas sozinho. Uma camada sem responsável não fica segura por ser difícil de discutir.

Um processo defensável regista a sua decisão e execução sem criar uma segunda biografia desnecessária da pessoa.

A conservação é a outra metade da eliminação

Muitos problemas de eliminação começam muito antes de um pedido. Começam quando um sistema não tem qualquer decisão de conservação. Os dados chegam porque podem vir a ser úteis. Os registos tornam-se permanentes porque o armazenamento é barato. As exportações são mantidas porque uma auditoria futura pode pedi-las. Os dados de treino são acumulados porque um modelo posterior pode beneficiar deles. Cada decisão parece inofensiva isoladamente. Em conjunto, transformam a organização em proprietária de um arquivo grande e mal compreendido e tornam cada pedido de eliminação mais caro, incerto e litigioso.

O princípio da limitação da conservação do RGPD estabelece que os dados pessoais devem ser conservados de uma forma que permita a identificação dos titulares dos dados apenas durante o período necessário para as finalidades para as quais são tratados, sujeito a conservação mais longa para fins de arquivo de interesse público, de investigação científica ou histórica ou de fins estatísticos, quando se aplicarem garantias. O princípio não prescreve um calendário único para todas as organizações. Exige um juízo ligado à finalidade. Um calendário de conservação deve, portanto, indicar as categorias de dados, a finalidade, a base jurídica, o período normal, o evento desencadeador, a exceção, a ação de eliminação, o responsável e o ponto de revisão. «Durante o tempo necessário» é um princípio. Torna-se uma regra operacional apenas quando alguém pode dizer necessário para quê, até quando e decidido por quem.

Essa estrutura é útil para a IA porque impede que um rótulo amplo, como dados de treino, esconda várias coisas diferentes. Uma contribuição em bruto, um conjunto de dados limpo, um conjunto de características, uma versão de modelo, um histórico de instruções, um conjunto de avaliação e um registo de monitorização podem ter finalidades e considerações de conservação diferentes. Combiná-los num único balde indefinido prejudica tanto a inovação como a responsabilização. Separar não garante uma resposta jurídica, mas torna uma possível.

As decisões de conservação beneficiam também de uma condição de recusa. O que nos faria parar de conservar isto? Um contrato concluído, um litígio resolvido, o fim de um prazo legal, uma investigação de segurança concluída, uma versão de modelo substituída, o fim de uma janela de restauro ou uma decisão de não prosseguir uma finalidade de investigação podem ser todos eventos desencadeadores reais. A questão não é automatizar um relógio de eliminação para tudo. É evitar um sistema em que a única condição para manter dados é que ninguém tenha ainda sido obrigado a explicá-los.

Há um pequeno instinto neerlandês que vale a pena conservar aqui: um armário não está organizado porque tem uma porta. Está organizado porque se consegue encontrar a coisa relevante, saber porque lá está e removê-la sem mudar de casa. Um património de dados merece, pelo menos, esse padrão. Um calendário de conservação que não sobrevive a uma conversa com as pessoas que operam o sistema não é um calendário. É uma previsão meteorológica escrita em prosa jurídica.

Isto não significa que todas as organizações tenham de centralizar todas as decisões de eliminação. As equipas locais compreendem frequentemente melhor os seus processos. Significa que as regras locais precisam de conceitos comuns, de responsabilidade visível e de um caminho para escalar. Caso contrário, o arquivo de uma equipa é a violação de outra, e o pedido de uma pessoa é encaminhado por um labirinto de serviços com nomes educados.

O que um fornecedor honesto de IA pode dizer

Um fornecedor honesto de IA não afirma que todos os dados dos clientes desaparecem quando chega um pedido. Também não se esconde atrás da dificuldade dos modelos. Descreve o limite do serviço. O que é processado para inferência. O que é retido para administração de conta, segurança, suporte, faturação ou prevenção de abusos. Se os pedidos e as respostas são armazenados. Se são utilizados para formação, avaliação ou melhoria do serviço. Que processadores e regiões estão envolvidos. Como os clientes podem configurar a retenção. Que documentação existe para pedidos de titulares de dados. Que ações são imediatas, quais são assíncronas e quais dependem de uma avaliação jurídica separada.

Para os compradores, as questões de aquisição são práticas. Conseguimos obter um mapa claro do fluxo de dados? Conseguimos identificar os papéis de responsável e subcontratante pelo tratamento relevante? Conseguimos exportar ou eliminar material de forma utilizável? Os índices de recuperação e os armazenamentos derivados estão incluídos no ciclo de vida documentado? O que acontece às cópias de segurança? Como são comunicadas as alterações de subcontratantes? Pode o fornecedor ajudar-nos a responder a um pedido dentro do prazo aplicável? Os usos para formação e melhoria do serviço são opt-in, opt-out, contratados ou descritos apenas numa página que pode mudar após a compra? Que registos técnicos estão disponíveis para comprovar a ação?

As respostas variam. Um grande serviço partilhado nem sempre pode oferecer o mesmo controlo que um ambiente dedicado. Um registo de segurança nem sempre pode ser eliminado no mesmo momento que um perfil de conta. Um arquivo estatutário não pode ser tratado como uma preferência de consumidor. Essas diferenças não são necessariamente falhas. O silêncio sobre elas é. A resposta certa do comprador é alinhar o comportamento documentado do serviço com o propósito, as obrigações e o risco da organização. Um produto pode ser inadequado para uma tarefa altamente sensível mesmo quando é totalmente adequado para uma ferramenta de rascunho de baixo risco.

Na Dweve, o nosso Centro de Confiança adota a mesma visão restrita de evidência. Uma página pública pode descrever controlos e limites de documentação, mas não pode certificar cada implementação de cliente nem decidir a base legal para o tratamento de um cliente. Esse limite importa. Uma plataforma pode suportar controlos de retenção, registos e fluxos de trabalho auditáveis. A organização que a utiliza continua a ser dona do seu propósito, das suas escolhas de dados e da decisão de responder a uma pessoa específica. Um bom texto de produto deve tornar essa responsabilidade mais clara, não herdá-la silenciosamente.

A declaração mais valiosa de um fornecedor é muitas vezes uma limitação. «Este registo permanecerá em cópias de segurança protegidas até ao fim do período de rotação indicado.» «Este serviço não utiliza o conteúdo especificado do cliente para formação nos termos destas condições.» «Este índice é removido de forma assíncrona e o estado pode ser verificado aqui.» «Não podemos fazer esta afirmação para uma integração de terceiros.» Estas frases podem parecer menos mágicas do que uma promessa universal de privacidade. Permitem que um comprador desenhe um processo real.

Perguntas que valem a pena fazer antes de o pedido chegar

Uma organização não precisa de inventar uma violação, um indivíduo em sofrimento ou um incidente heroico a altas horas da noite para testar o seu design de apagamento. Pode usar um pedido hipotético claramente identificado durante o horário de trabalho normal. Suponha que uma pessoa pede a eliminação de material guardado num sistema virado para o cliente. Que equipa recebe o pedido? Como é verificada a identidade sem recolher informação nova em excesso? Que finalidades são relevantes? Que sistemas contêm dados de origem, derivados, índices, registos, caches, exportações e cópias de recuperação? Que subcontratantes precisam de uma instrução ou notificação? Que exceção ou dever de conservação, se existir, se aplica? Quem pode decidir? Quem pode executar? Como explicará a organização o resultado?

Depois, faça as perguntas técnicas difíceis. Consegue um operador encontrar o inventário de dados atual sem um antigo engenheiro? Pode um índice de pesquisa ser verificado independentemente da sua tabela de origem? Um identificador eliminado reaparece depois de um restauro? Os trabalhos em lote usam instantâneos antigos? Pode um armazenamento de embeddings ser ligado aos seus documentos e ao seu cliente? Um pipeline de monitorização captura o conteúdo dos pedidos por predefinição? Os ficheiros de exportação são regidos pelas mesmas regras de conservação que a sua origem? O registo de prova cria uma nova pilha de conteúdo sensível? Estes não são casos extremos adicionados para fazer uma política parecer séria. São consequências normais de sistemas que fazem cópias para funcionar.

Por fim, faça a pergunta de governação: o que levaria a organização a mudar a sua resposta? Uma nova obrigação legal, uma identidade contestada, um processo judicial em curso, uma alteração no acordo com um fornecedor, uma verificação de eliminação falhada, uma cópia de segurança restaurada, um novo pipeline de modelo ou uma decisão de um regulador podem ser relevantes. Um processo sem gatilho de revisão é simplesmente uma suposição inicial promovida a política.

Nada disto substitui o aconselhamento jurídico num caso concreto. Os requisitos do RGPD, o direito nacional, os deveres setoriais, os contratos e os factos do tratamento são todos relevantes. Mas as organizações não precisam de uma disputa legal para começar a criar as condições para uma resposta inteligível. Precisam de conhecer os seus sistemas suficientemente bem para deixarem de oferecer uma promessa simples para uma realidade complicada.

A privacidade é a qualidade do resíduo

A ambição por detrás do apagamento não é tornar o passado irreal. É dar às pessoas um controlo significativo quando os dados já não precisam de ser tratados, quando o consentimento foi retirado, quando o tratamento é ilícito ou quando se aplica outro fundamento do artigo 17.º. Pede aos responsáveis pelo tratamento que tratem os dados pessoais como algo guardado para uma finalidade, e não como matéria-prima com uma ocupação indefinida. Pede-lhes que expliquem as exceções em vez de as usarem como uma máquina de fumo. Pede aos sistemas que carreguem linhagem suficiente para que o esquecimento possa ser deliberado.

Para os serviços digitais, o teste silencioso é o que resta. Depois de um registo ser removido de um ecrã de produto, o que continua ativo? Depois de um documento sair de um corpus de recuperação, que representação derivada ainda o seleciona? Depois de uma conta ser eliminada, que registo é conservado, para que finalidade e durante quanto tempo? Depois de uma cópia de segurança ser restaurada, o que impede um registo reformado de voltar? Depois de um modelo mudar, que histórico de dados pode ser inspecionado? Depois de um pedido ser encerrado, consegue a organização mostrar o seu trabalho sem construir outro perfil oculto?

Um sistema raramente responderá a todas estas perguntas com uma ação e um carimbo de tempo. Isso é normal. O que não é normal é fingir que as perguntas desaparecem porque os dados são difíceis, distribuídos ou lucrativos. A privacidade não é o momento em que um serviço aprende um comando de eliminação. É o que resta depois de o sistema aprender a esquecer com uma finalidade, um limite e um registo da sua própria contenção.

Fontes