Redação de dados pessoais em logs de agentes de IA sem vazamentos

Para redigir dados pessoais nos logs de agentes, aplique a redação no ponto em que os eventos são gravados, e não em uma limpeza feita depois da exportação. Substitua valores pessoais por marcadores tipados que preservem o significado, como telefone_cliente ou responsavel_pedido, para que cada evento ainda mostre o que aconteceu. Guarde qualquer mapa de volta aos valores originais em um repositório separado e restrito, e teste o pipeline inteiro com dados pessoais fictícios plantados em lugares realistas.

Principais pontos

• Redija no momento da gravação, antes que os dados cheguem a traces, filas, caches, armazenamentos de depuração de fornecedores ou backups.
• Substitua valores por marcadores tipados para que os eventos continuem legíveis para revisores que nunca veem o dado bruto.
• Armazene qualquer mapa de reidentificação separadamente, com regras de acesso próprias e registro próprio.
• Teste a redação com identificadores sintéticos plantados em todos os caminhos de gravação, e repita o teste após cada mudança.
• Defina retenção e acesso aos logs do agente antes do primeiro incidente, e não durante ele.

Por que redigir exportações depois do fato deixa lacunas

Uma primeira tentativa comum é um script que apaga nomes, e-mails e telefones de uma exportação de logs todas as noites. Parece razoável, mas cobre apenas o arquivo que alguém exportou. Sistemas com agentes gravam em muitos lugares: o prompt e a resposta do modelo, os argumentos de ferramentas, os resultados das ferramentas, os documentos recuperados, as entradas de memória, as mensagens de erro, as filas de tarefas e os sistemas de rastreamento. Dados pessoais podem estar em todos esses pontos ao mesmo tempo, e algumas dessas cópias nunca são exportadas.

Os argumentos de ferramentas são uma fonte frequente de vazamento. Quando o agente consulta um cliente, a chamada costuma conter o nome completo ou o telefone, e o registro devolvido costuma trazer um endereço. Os tratadores de erro acrescentam outro risco, porque rastreamentos de pilha e mensagens de validação frequentemente repetem o dado que causou a falha. Uma exportação limpa não limpa o coletor de traces que guardou o mesmo erro uma hora antes.

Ferramentas de observabilidade ajudam a organizar esse raciocínio. O projeto OpenTelemetry trata traces, logs e métricas como sinais separados, cada um com seus próprios atributos e cada um exigindo tratamento próprio. Aplique a mesma lógica aos logs de agentes: liste cada sinal que o agente emite e decida o que cada um pode conter antes de qualquer valor ser gravado.

O que uma auditoria ou revisão de incidente realmente precisa

Antes de escolher os marcadores, defina as perguntas que o log precisa responder. A maioria das auditorias e revisões de incidentes faz alguma versão das mesmas perguntas: qual agente agiu, em qual versão e configuração, qual ferramenta ele chamou, sobre qual identificador de registro, em que horário, com qual resultado, e se uma pessoa aprovou a etapa quando a aprovação era exigida.

A maioria das revisões não precisa do texto completo da mensagem de um cliente, de um identificador de pagamento, de um dado de saúde ou de um endereço completo. Um revisor normalmente precisa saber que um registro de cliente foi lido, que um reagendamento foi proposto e que um integrante da equipe aprovou. O conteúdo do registro raramente faz parte da pergunta. Escrever isso cedo também facilita justificar as regras de redação para quem, depois, perguntar por que um detalhe está ausente.

Mantenha o registro de aprovação como um evento próprio. Se o agente parou para pedir aprovação, o log deve mostrar o pedido, o papel ou identificador de quem aprovou, a decisão e o horário. Essa cadeia única costuma ser exatamente o que uma revisão de incidente mais precisa.

Um plano de redação passo a passo

Use esta sequência ao incluir redação em um agente existente ou ao desenhá-la para um novo:

• Etapa 1: Inventarie cada caminho de gravação, incluindo prompts, saídas do modelo, chamadas de ferramentas, resultados de ferramentas, gravações de memória, tratadores de erro, filas, traces e qualquer armazenamento de depuração ou avaliação do fornecedor.
• Etapa 2: Classifique os dados de cada caminho em identificadores diretos, identificadores indiretos, categorias sensíveis e texto livre. O texto livre exige o tratamento mais rigoroso, porque as pessoas escrevem coisas inesperadas nele.
• Etapa 3: Defina um marcador por tipo de dado, como nome_cliente, telefone_cliente ou referencia_conta, e mantenha-os consistentes dentro de uma sessão para que os eventos continuem ligáveis entre si.
• Etapa 4: Aplique a redação dentro da camada de log, antes da serialização. Redigir em um painel deixa o valor bruto armazenado.
• Etapa 5: Decida se alguma reidentificação é necessária. Se for, crie um mapa de tokens com tokens baseados em chave, criptografe-o, restrinja o acesso e registre cada consulta.
• Etapa 6: Redija erros e rastreamentos de pilha, que costumam repetir valores de entrada.
• Etapa 7: Teste com identificadores sintéticos plantados em todos os caminhos, incluindo entradas desenhadas para fazer o agente repetir dados pessoais.
• Etapa 8: Nomeie um responsável pelas regras de log e marque uma data de revisão, porque ferramentas, prompts e integrações mudam.

Onde dados pessoais se escondem nos logs de agentes

Use esta checklist durante o desenho e de novo após qualquer mudança de integração:

• Argumentos de ferramentas que carregam nomes, telefones, e-mails ou identificadores de registro
• Resultados de ferramentas que devolvem registros completos quando o agente precisava de um único campo
• Documentos recuperados e entradas de memória que incluem dados de clientes
• Saídas do modelo que repetem por completo a mensagem de um cliente
• Mensagens de erro e rastreamentos de pilha que repetem valores de entrada
• Nomes de arquivos e metadados de anexos, que frequentemente contêm nomes de pessoas
• Logs de depuração de fornecedores, conjuntos de dados de avaliação e cópias para suporte
• Backups, snapshots e exportações feitos para solucionar problemas

A checklist é mais útil quando alguém que não construiu o agente a revisa. Quem construiu tende a enxergar os campos que esperava, enquanto um revisor enxerga o que o sistema realmente grava.

Cenário ilustrativo: uma consulta de reagendamento

O cenário a seguir é ilustrativo e não descreve um cliente real. Uma pequena empresa de serviços em campo usa um agente para ajudar clientes a reagendar visitas. Um cliente escreve com um número de telefone e um pedido para mudar um horário. O agente chama uma ferramenta de consulta com o telefone, recebe um registro com nome e endereço, propõe um novo horário e pede que um integrante da equipe aprove.

Na primeira versão dos logs, o telefone aparecia no argumento da ferramenta, o endereço aparecia no resultado e um erro de validação incluía o nome completo. Depois que as regras de redação passaram a ser aplicadas no momento da gravação, o mesmo evento passou a mostrar uma consulta usando o marcador telefone_cliente, uma referência de registro que é um token com chave, um status de resultado encontrado, uma mudança proposta com uma janela de horário e um evento de aprovação indicando o papel de quem aprovou. A revisão ainda consegue responder o que o agente fez, quando, sob qual aprovação e o que mudou. Os dados de contato brutos nunca foram gravados no log, e o mapa de tokens fica em um repositório restrito.

Manter o rastro sem manter o segredo

Uma questão prática é se devemos usar hash ou tokenização nos identificadores. Um hash simples de um número de telefone oferece proteção fraca, porque o universo de números possíveis é pequeno o bastante para que alguém teste candidatos. Tokens gerados com uma chave secreta guardada separadamente são muito mais difíceis de reverter. O mesmo cliente deve receber o mesmo token dentro de um escopo definido, para que os eventos continuem ligáveis, mas a chave e qualquer tabela de mapeamento exigem controle rigoroso.

Defina quem pode resolver um token, em que circunstâncias e como esse acesso é registrado. Em muitas empresas, a resposta é um pequeno grupo de pessoas responsáveis por conformidade ou resposta a incidentes, com uma justificativa documentada para cada consulta. Registre por escrito o prazo de guarda dos logs e do mapa de tokens, porque um mapa mantido por mais tempo do que os logs que ele sustenta cria exposição própria. O artigo sobre prazos de guarda de logs de agentes de IA mostra como equilibrar esses prazos com as necessidades de auditoria.

A mesma disciplina vale para a memória do próprio agente. Se ele guarda fatos sobre clientes para uso posterior, decida o que pode manter e torne a exclusão possível. O guia sobre exclusão de dados de cliente em agentes de IA descreve como encontrar, remover e verificar essa exclusão.

Como a Be Human trata isso e como testar pontos cegos

Nos projetos da Be Human, o escopo de logs é definido com a empresa no primeiro papel útil, junto com a memória, as ferramentas, os limites de aprovação e o critério de sucesso desse papel. Os tipos de marcador, as regras de token e os prazos de retenção são registrados no contexto operacional, e a redação é implementada na camada de log do agente, e não em uma ferramenta de relatórios. Na operação gerenciada, testes de cobertura de logs fazem parte das avaliações recorrentes, e as revisões de permissão verificam quem pode resolver tokens. Quando ocorre um incidente, as regras de log escritas dizem à equipe de resposta quais evidências existem e o que foi mantido fora delas.

Os testes são o que transforma um desenho de redação em algo confiável. Plante identificadores sintéticos nas entradas de teste, execute o agente com pedidos normais e incomuns e depois procure esses identificadores em todos os caminhos de gravação. Inclua entradas que tentem fazer o agente repetir dados, porque instruções injetadas podem levar o modelo a copiar texto sensível para um campo que ninguém filtrou. Revise uma amostra de eventos reais todo mês e repita o teste com identificadores plantados após cada mudança em ferramenta, prompt ou integração. Trate qualquer falha como defeito na camada de log e registre a correção.

Se você não tem certeza de quais fluxos de agentes hoje gravam dados pessoais nos logs, o diagnóstico gratuito de IA da Be Human pode ajudar a encontrar a primeira tarefa que vale entregar a um agente, com as regras de log definidas desde o início.

Perguntas frequentes

Devemos manter os dados pessoais originais nos logs? Normalmente não, pelo menos não no log operacional. Mantenha no log os eventos, decisões e aprovações, e guarde valores originais somente onde houver necessidade comercial ou legal documentada, em um sistema separado e restrito, com prazo de retenção próprio. Muitas revisões se satisfazem apenas com marcadores e tokens estáveis.

Redigir os logs de agentes basta para cumprir a lei de proteção de dados? A redação reduz a exposição, mas não resolve sozinha as suas obrigações legais. As regras dependem do seu setor, das finalidades do tratamento e da legislação aplicável, então revise-as com um advogado qualificado. O artigo sobre LGPD e agentes de IA nas empresas é um bom ponto de partida para operações no Brasil.

Como saber se a redação está funcionando? Teste com identificadores sintéticos plantados em todos os caminhos de gravação, incluindo entradas desenhadas para fazer o agente repetir dados pessoais. Depois, faça amostragens de eventos reais em uma agenda recorrente e procure padrões que nunca deveriam aparecer. Um teste aprovado em um caminho não prova que os outros estão cobertos, então mantenha a lista de testes atualizada conforme ferramentas e integrações mudam.

Quem deve poder resolver um token e voltar ao valor original? Limite essa permissão a um grupo pequeno, com motivo definido, como revisão de conformidade ou resposta a incidente, e exija uma justificativa registrada para cada consulta. Revise essa lista periodicamente e remova o acesso quando alguém mudar de função. Registrar cada resolução é tão importante quanto restringi-la, porque isso permite ver como o mapeamento foi usado.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.