GDPR para agentes de IA: minimize dados pessoais em memória, ferramentas e logs
Um agente não processa dados pessoais apenas quando envia um prompt ao modelo. Montagem do contexto, busca, memória persistente, chamadas de ferramentas, retries, traces, exportações e telemetria do fornecedor podem criar cópias e finalidades adicionais. Minimizar dados significa estruturar o sistema inteiro em torno do que uma tarefa específica realmente precisa, e depois fazer retenção e solicitações de titulares funcionarem em todos os armazenamentos.
Publicado em 28 de setembro de 202616 min de leituraEngenharia de privacidade
O GDPR não depende da tecnologia. Seus princípios se aplicam a dados pessoais em CRM, índice vetorial, transcrição de agente, resultado de ferramenta, plataforma de observabilidade ou endpoint de fornecedor de modelo. O Artigo 5 exige dados adequados, pertinentes e limitados ao necessário para cada finalidade, além de limitar por quanto tempo podem permanecer identificáveis. O resumo de 2026 do European Data Protection Board sobre proteção desde o desenho e por padrão reforça que esses princípios precisam ser operacionalizados ao longo do ciclo de tratamento. Para engenharia, isso vira um problema concreto de inventário e controles, não de escrever prompts mais bonitos.
Este é um guia de engenharia, não uma orientação jurídica. O controlador precisa determinar finalidades, base legal, transparência, papéis e direitos aplicáveis ao caso concreto. Uma biblioteca de agentes ou uma configuração de privacidade não resolve essas decisões pela organização.
Mapeie todos os lugares por onde os dados podem passar
Caminho de uma solicitação ao agente e as cópias que escapam do armazenamento principal da conversa
Origem e identidadeEntrada do usuário, contexto da conta, arquivos, ID de sessão e finalidade.
Montagem do contextoPrompt de sistema, registros recuperados, resumos, histórico e schemas de ferramentas.
Modelo e ferramentasSolicitação ao fornecedor, conteúdo gerado, ações em APIs, retries e callbacks.
Persistência e telemetriaMemória, chunks vetoriais, traces, logs, filas, backups, exports e diagnósticos.
Desenhe setas nos dois sentidos: consultas e resultados de ferramentas trazem dados pessoais de volta ao contexto, onde podem ser copiados novamente.
Faça o mapa por finalidade e categoria de dado. Inclua buffers transitórios e dados derivados, não apenas tabelas de banco. Um resumo em texto livre ainda pode identificar alguém; um embedding não é automaticamente anônimo; um ID pseudonimizado continua sendo dado pessoal se puder ser associado a uma pessoa. O parecer do EDPB sobre modelos de IA trata anonimato como avaliação caso a caso, inclusive considerando se alguém pode ser identificado ou se dados pessoais podem ser extraídos por consultas.
Reduza o contexto antes de enviá-lo ao modelo
Comece pelo contrato da tarefa. Um agente de suporte que precisa explicar um atraso de entrega pode precisar do status e da previsão do pedido, mas não do cadastro completo, chamados sem relação, credenciais de pagamento ou anos de conversas. Recupere campos por allowlist, filtre finalidade e autorização antes do ranking e retorne ao modelo apenas o menor registro útil. Quando possível, faça a ferramenta de backend executar uma operação estreita e devolver um código de resultado, sem expor os dados pessoais que estavam por trás dela.
Uma janela de contexto maior não é autorização para enviar mais dados. Inclua regras explícitas de idade máxima, origem, finalidade e sensibilidade na recuperação. Redija ou transforme identificadores somente quando a tarefa continuar funcionando e a transformação for apropriada; aplicar hash a um e-mail estável não o torna anônimo quando os registros continuam correlacionáveis. Não use conversas pessoais para treinar modelos nem para memória entre usuários por padrão. Uma finalidade diferente exige avaliação, transparência e controles próprios.
Faça a memória ter escopo, ser inspecionável e expirar
Separe estado transitório da conversa, preferências solicitadas pelo usuário, registros operacionais e parâmetros aprendidos do modelo. Cada tipo tem finalidade, acesso, retenção e comportamento de eliminação diferentes. Mantenha estado de tarefa de curta duração em armazenamento com TTL; persista uma preferência apenas quando houver necessidade clara e expectativa visível; preserve registros empresariais exigidos no sistema de origem, em vez de promovê-los silenciosamente à memória do agente.
Entradas de memória deveriam carregar proveniência, finalidade, categoria de dado, registro de origem, data de criação, expiração e referência de titular ou tenant quando apropriado. Aplique os limites de usuário e tenant no filtro de metadados e também na autorização do armazenamento. Teste vazamento entre sessões, fatos antigos reaparecendo e uma solicitação apagar a linha original enquanto os chunks continuam pesquisáveis.
A retenção precisa cobrir retries, traces e fornecedores
01 · ColetarFinalidade e escopoDocumente categorias, responsável pela base legal, origens e campos necessários.
02 · ProcessarMinimizar por padrãoFiltre consultas, redacte, limite ferramentas e evite histórico de prompt desnecessário.
03 · PersistirClassificar e expirarDefina TTL por armazenamento, acesso, backups e comportamento de eliminação.
04 · ObservarRedigir telemetriaMantenha IDs e eventos operacionais úteis; exclua conteúdo de prompt e ferramentas por padrão.
05 · ReconciliarDireitos e evidênciasLocalize cópias, execute ações delimitadas, registre exceções e verifique a conclusão.
Registrar cada prompt é tentador durante um protótipo e perigoso como padrão permanente. Prefira eventos estruturados como tipo da tarefa, versão do modelo, nome da ferramenta, latência, status e token de correlação que não seja um identificador reutilizável da conta. Se capturar conteúdo for necessário para uma finalidade específica de depuração, controle o acesso, reduza dados, estabeleça prazo curto e registre a justificativa da exceção. Revise termos dos operadores, região, subprocessadores, retenção e caminhos de acesso de suporte de cada fornecedor de modelo ou observabilidade.
Transforme solicitações de titulares em um fluxo distribuído
Direitos não podem ser implementados como “apague a linha da conversa”. Uma solicitação pode exigir busca em registros ligados à conta, memória do agente, índices vetoriais, caches, event stores e serviços de fornecedores. Acesso e portabilidade também exigem uma forma significativa de reunir registros relevantes. Eliminação tem condições e exceções jurídicas; alguns registros empresariais podem precisar ser mantidos, e cabe ao controlador avaliar o pedido em vez de prometer remoção incondicional em qualquer sistema.
Desenhe um fluxo orquestrado com chave de titular verificada, busca delimitada, adaptadores por armazenamento, ações idempotentes, fila de revisão para correspondências ambíguas e relatório de conclusão auditável. Propague tombstones de eliminação para consumidores assíncronos para impedir que um evento antigo recrie um embedding apagado. Para backups, defina expiração e controles de restauração: o processo de recuperação deve reaplicar os registros de exclusão antes de disponibilizar os dados restaurados.
Separe decisões automatizadas e escalonamento humano
Nem toda ação apoiada por IA é uma decisão do Artigo 22. Esse artigo trata de decisões baseadas unicamente em tratamento automatizado, inclusive definição de perfis, com efeitos jurídicos ou similarmente significativos, sujeito às condições e salvaguardas do GDPR. Mesmo assim, fluxos consequentes merecem um inventário de decisões: o que o agente recomenda, o que pode executar, se uma pessoa faz revisão significativa e como a pessoa afetada pode contestar ou corrigir o resultado.
Use ferramentas de menor privilégio, schemas de ações estreitos, confirmação de transações e verificações de política fora do modelo. Uma afirmação em linguagem natural de que o usuário consentiu não é um registro confiável de autorização. Impessa que o modelo amplie o próprio escopo e trate resultados de ferramentas e documentos recuperados como dados não confiáveis, não instruções.
Controles de engenharia para colocar no quadro
Orçamento de contexto por finalidadeDefina categorias permitidas, idade máxima e número máximo de registros por tarefa. Rejeite resultados sem justificativa campo a campo.
Inventário de armazenamentos e fornecedoresMapeie cópias, responsáveis, operadores, regiões, retenção, perfis de acesso, adaptadores de eliminação e backups.
Observabilidade atenta à privacidadeMeça sucesso, latência, segurança e custo sem gravar prompts pessoais brutos nem payloads completos por padrão.
Testes de solicitações de titularesPlante identidades de teste em origem, memória, vetores, logs e filas; simule acesso ou exclusão e verifique os resultados esperados.
Memória vinculada à finalidadeSepare preferências do usuário de estado transitório; mostre o que é lembrado e forneça correção ou remoção quando aplicável.
Fronteira com o fornecedorDocumente o que sai do seu ambiente, retenção e reutilização, subprocessadores e efeito do encerramento do serviço.
Artefato do agente
Controle de minimização
Risco de retenção e direitos
Teste
Contexto do prompt
Allowlist por tarefa e filtros de recuperação.
O fornecedor do modelo pode receber dados pessoais.
Verificar que campos excluídos nunca entram no payload.
Resumo da conversa
Manter apenas fatos necessários à finalidade ativa.
Pode perpetuar dados sensíveis ou desatualizados.
Inspecionar após correção e expiração.
Memória vetorial
Índice isolado por tenant, referência de origem e TTL.
Eliminação precisa cobrir chunks e índices derivados.
Pesquisar após exclusão e restauração de backup.
Argumentos e resultados de ferramentas
Schemas restritos e autorização no servidor.
Retries, filas e auditoria criam cópias extras.
Rastrear retries e remover payload dos logs rotineiros.
Dataset de avaliação
Dados sintéticos ou controlados adequadamente.
Fixtures podem virar depósitos duradouros de dados pessoais.
Verificar fixtures, exports e permissões.
O que eu construiria
Eu adicionaria ao agente uma ficha de fluxo de dados: cada tarefa declara finalidade, campos permitidos, origens, ferramentas, armazenamentos, operadores e retenção. Uma camada de políticas valida a ficha antes da montagem do contexto; um filtro de privacidade redige saídas; hooks de eventos associam metadados de retenção e titular aos artefatos persistidos; e um orquestrador de direitos distribui solicitações pelos adaptadores registrados. Testes em CI inspecionam payloads enviados a fornecedores e percorrem cenários de exclusão, correção e restauração com dados sintéticos.
Faça o inventário responder a perguntas operacionais, não virar documentação cerimonial: para onde essa tarefa pode enviar dados, quais artefatos podem ser recuperados, o que expira automaticamente e quem responde quando um adaptador de exclusão falha? Um painel deve mostrar cobertura e exceções, não declarar “em conformidade com GDPR” porque todos os quadrados estão verdes.
Em resumo
Para agentes de IA, minimização é uma propriedade do caminho inteiro: o que entra no contexto, quais ferramentas veem os dados, o que fica na memória, o que a telemetria registra, quais fornecedores recebem informações e se as cópias podem ser localizadas depois. Delimite cada tarefa, faça a memória expirar, mantenha a observabilidade leve em conteúdo e crie fluxos de direitos entre armazenamentos. Muitas vezes, o controle de privacidade mais forte é uma decisão de arquitetura de não criar uma cópia desnecessária.
Nota editorial: Este artigo traduz princípios do GDPR e materiais do EDPB em controles de engenharia. Não determina a base legal, as obrigações do controlador nem a resposta a uma solicitação específica; envolva profissionais qualificados de privacidade e direito nessas decisões.