Log de IA: o dado mais sensível e menos protegido

A ironia que a LGPD deixou no colo dos gestores

Existe uma contradição embutida em quase todo projeto de IA corporativa no Brasil, e poucos gestores a enxergam antes de ela virar incidente.

A LGPD, no Art. 46, obriga agentes de tratamento a adotar medidas de segurança para proteger dados pessoais de acessos não autorizados e de situações acidentais ou ilícitas. Para demonstrar essa diligência — e para sobreviver a uma eventual investigação da ANPD —, a resposta técnica é sempre a mesma: logs, trilhas de auditoria, rastreabilidade. Registre tudo. De onde veio cada dado, quem perguntou o quê, o que o modelo respondeu.

O problema é que esse mesmo registro, feito para provar conformidade, tende a se tornar o repositório menos protegido de dados sensíveis da empresa.

Esta é a tese deste artigo: em projetos de IA, a governança que você monta para se defender pode ser exatamente onde você fica exposto. E isso acontece porque logs de IA não são tratados como o que são — ativos críticos de dados pessoais.

Por que o log de IA é diferente de qualquer log que você já teve

Um log de aplicação tradicional registra eventos: usuário X logou às 14h, transação Y foi aprovada. É estruturado, previsível, pobre em conteúdo pessoal.

Um log de IA generativa é o oposto. Ele armazena o prompt inteiro e a resposta inteira. Se um colaborador do jurídico cola trechos de um contrato para o modelo resumir, ou se um agente de atendimento puxa o histórico de um cliente para responder, esse conteúdo — CPF, e-mail, endereço, dados de saúde, cláusulas confidenciais — fica gravado no log em texto livre.

Material especializado em governança de agentes de IA no contexto da LGPD é direto sobre isso: logs de prompts, respostas e eventos de agentes frequentemente armazenam trechos de dados pessoais ou sensíveis se não houver filtragem prévia. E aqui está o paradoxo: quanto mais detalhado o log — o que a auditoria exige —, mais atraente e perigoso ele se torna como alvo.

Na prática, muitas empresas terminam com um banco de dados sombra, cheio de dados sensíveis, mantido fora do perímetro dos sistemas core, com controle de acesso frouxo, porque "é só o log". Ninguém aplica ao log de IA o mesmo rigor que aplica ao prontuário ou à base de crédito. E, no entanto, o log contém pedaços de ambos.

O que fazer com os logs — sem abrir mão da auditoria

A solução não é registrar menos. É registrar com disciplina. As mesmas fontes que apontam o risco também descrevem o remédio, e ele cabe em três movimentos concretos:

Pseudonimizar o log sempre que a identificação direta não for necessária. Mascare CPF, e-mail, telefone e endereço antes de o dado chegar ao registro. Você preserva a capacidade de auditar o fluxo sem preservar a identidade da pessoa no lugar mais vulnerável.
Aplicar o princípio do menor privilégio ao acesso aos logs — e tornar esse acesso auditável. Quem consulta o log de IA precisa ser um conjunto restrito e rastreável. Log que qualquer analista de TI abre não é controle, é exposição.
Definir prazo de retenção e política de descarte específicos para logs com dados pessoais. Manter tudo para sempre "por segurança" é o oposto de segurança. É acúmulo de passivo.

Nada disso é sobre o modelo de IA. É sobre a engenharia ao redor dele — a parte que não aparece na demo e decide se o projeto sobrevive a uma fiscalização.

O segundo elo fraco: a permissão que a IA não respeita

Se o log é o risco de saída, a permissão propagada errado é o risco de entrada.

Sistemas legados costumam ter controles de acesso maduros: cada usuário vê o que tem direito de ver. Mas quando você pluga um modelo ou um agente sobre esses sistemas, ele pode simplesmente ignorar essas restrições — lendo tudo o que a integração alcança e respondendo a qualquer usuário com base nisso. O chatbot interno responde ao estagiário de vendas com um dado que só a diretoria financeira poderia consultar. Ninguém autorizou. Ninguém percebeu.

A governança madura exige que o controle de acesso seja propagado para a camada de IA: a IA responde a cada usuário somente com aquilo que ele já poderia consultar nos sistemas de origem. Não é uma configuração opcional. É a diferença entre um copiloto e um vazamento com interface de chat.

Como os grandes fornecedores transformaram isso em argumento de venda

Não é coincidência que as big techs de nuvem tenham feito da governança o centro do discurso. A AWS afirma, em sua documentação, que dados de clientes enviados a serviços como o Amazon Bedrock e o SageMaker não são usados para treinar modelos fundacionais, a menos que o cliente opte explicitamente por isso — o que reduz o risco de compartilhamento não autorizado e ajuda na base legal sob a LGPD. A Google Cloud, por sua vez, estrutura sua oferta em torno de RBAC, criptografia em repouso e em trânsito, logs de auditoria de todas as chamadas de API e opções de residência de dados.

O recado para o gestor é claro: isolamento de dados, controle de acesso baseado em papéis e logging detalhado deixaram de ser diferencial técnico e viraram pré-requisito comercial. Quem vende IA corporativa vende, na verdade, governança embrulhada em modelo.

O mesmo movimento explica a migração corporativa das interfaces gratuitas de IA generativa para contratos enterprise e uso via API dedicada. A recomendação prática é bloquear as versões de consumidor e exigir, em contrato, que os inputs dos usuários não sejam usados para treinar modelos públicos. Quando um colaborador cola dado de cliente numa ferramenta gratuita sem salvaguarda, a orientação já pressupõe o pior: acionar o comitê de incidentes e o DPO, pedir ao provedor a exclusão dos logs e avaliar o impacto de conformidade. É gestão de crise, não de projeto.

Governança antes da automação, não depois

O erro estrutural da maioria das empresas é inverter a ordem. Primeiro liberam o agente, depois pensam em conformidade. As fontes de governança de agentes defendem o contrário, e com razão: defina antes a finalidade, o escopo, quais sistemas serão acessados, o nível de autonomia e os riscos. Classifique se haverá tratamento de dados pessoais, dados sensíveis e decisões automatizadas com efeitos significativos. Formalize o DPA com cada fornecedor de LLM e de nuvem, com cláusula de proibição de retreinamento, medidas de segurança e prazos de retenção. Só então ligue as integrações.

A LGPD não perdoa a intenção. Usar IA para tratar dados pessoais sem estrutura de governança configura tratamento em desconformidade — e a lei prevê multa de até 2% do faturamento no Brasil, limitada a R$ 50 milhões por infração. O passivo reputacional, com clientes e com a ANPD, costuma custar mais.

O que isso significa para empresas brasileiras

A conversa sobre LGPD e IA no Brasil ficou presa em duas caixas: "a IA vê dados demais" e "vamos anonimizar antes de mandar pro modelo". Ambas são corretas e ambas são insuficientes.

O recorte que separa quem está protegido de quem está exposto é mais silencioso. É a política de retenção dos logs de prompt. É quem tem acesso a esses registros. É se o controle de permissão dos sistemas legados chega até a camada de IA — ou se para na porta.

Para o gestor brasileiro, a agenda prática é curta e desconfortável: trate o log de IA com o mesmo rigor da sua base de dados mais sensível, propague as permissões dos sistemas de origem para a camada de IA e monte a governança antes de ligar o agente, não depois do incidente. Nenhum desses três itens aparece numa demonstração de produto. Todos os três aparecem numa fiscalização.

A IA que você adota para ganhar velocidade só vira vantagem competitiva quando a engenharia de governança ao redor dela é invisível — e sólida. O resto é passivo esperando data para vencer.

O log da sua IA é o dado mais sensível da empresa — e o menos protegido