Agentes de IA: quem controla o acesso a dados pessoais?

O que muda quando a IA deixa de responder e passa a agir

Muitas empresas já se acostumaram com assistentes de IA que geram textos, resumem documentos ou ajudam em pesquisas internas. Esse uso, por si só, já exige cuidado com dados pessoais. Mas existe uma mudança importante acontecendo: a IA está saindo do papel de “chat” e entrando no papel de agente.

Um agente de IA não apenas responde uma pergunta. Ele pode planejar etapas, consultar sistemas, buscar registros, chamar APIs, comparar informações, preencher formulários, criar tarefas, redigir e-mails e, em alguns casos, executar ações quase sem intervenção humana.

Na prática, isso significa que a empresa pode estar dando à IA acesso a sistemas como:

• CRM;
• e-mail corporativo;
• calendário;
• banco de dados;
• ferramentas de atendimento;
• plataformas de marketing;
• sistemas financeiros;
• repositórios de documentos;
• Slack, Teams ou outras ferramentas internas;
• integrações por API ou servidores MCP.

O risco, portanto, não está apenas em “usar IA”. O ponto crítico é: quais dados pessoais esse agente consegue acessar, com qual finalidade, em nome de quem e com qual limite?

É aqui que a LGPD precisa entrar de forma prática. Não como um bloqueio à inovação, mas como uma camada de governança para permitir que a empresa use IA com mais segurança.

Por que agentes de IA aumentam o risco de acesso indevido

Um colaborador humano normalmente tem um cargo, uma área, uma senha, um gestor e permissões vinculadas ao seu trabalho. Mesmo quando a governança de acesso não é perfeita, a empresa costuma ter alguma noção de quem acessou o quê.

Com agentes de IA, essa lógica pode ficar confusa rapidamente.

Um agente pode ser criado para “ajudar o time comercial”. Mas, para isso, alguém conecta o agente ao CRM inteiro. Depois, ele também ganha acesso ao e-mail de vendas. Em seguida, passa a consultar documentos internos e gerar respostas automáticas. Quando a empresa percebe, a IA já consegue visualizar dados de leads, clientes, históricos de negociação, anexos, reclamações, informações contratuais e até dados que não deveriam estar no fluxo.

O problema fica ainda maior quando o agente usa credenciais genéricas, tokens amplos ou permissões de administrador.

Nesses casos, se houver uma consulta indevida, um vazamento, uma resposta com informação errada ou um envio para destinatário incorreto, a empresa pode ter dificuldade para responder perguntas básicas:

• Quem acionou o agente?
• O agente agiu em nome de qual usuário?
• Quais dados foram acessados?
• Qual ferramenta foi usada?
• A ação foi apenas uma sugestão ou foi executada automaticamente?
• Houve revisão humana?
• O dado ficou salvo em logs, memória ou base vetorial?

Essas perguntas não são apenas técnicas. Elas estão diretamente ligadas à responsabilidade, segurança, prestação de contas e governança de dados pessoais.

CRM, e-mail e banco de dados: onde os dados pessoais aparecem

CRM: mais do que nome, e-mail e telefone

O CRM costuma parecer um sistema simples: nome, empresa, telefone, e-mail e etapa comercial. Mas, na realidade, ele pode concentrar muito mais informação.

Dependendo do uso, o CRM pode conter:

• histórico de contato;
• preferências do cliente;
• observações de vendedores;
• dados financeiros;
• documentos enviados durante a negociação;
• reclamações;
• registros de suporte;
• dados de representantes legais;
• informações sobre colaboradores do cliente;
• anotações sensíveis inseridas de forma indevida.

Um agente de IA que consulta o CRM para sugerir próximos passos comerciais não necessariamente precisa enxergar toda a base, todos os campos e todos os clientes. Em muitos casos, ele precisa apenas de um recorte: dados do lead relacionado ao usuário, campos comerciais essenciais e histórico limitado.

A lógica deve ser: qual é o mínimo de informação necessário para aquele caso de uso funcionar?

E-mail: o risco mais subestimado

Dar acesso ao e-mail corporativo pode parecer conveniente. O agente lê mensagens, resume conversas, prepara respostas e ajuda o time a ganhar produtividade.

Mas e-mail é um dos ambientes mais sensíveis da empresa. Uma caixa postal pode conter contratos, anexos, dados de terceiros, informações trabalhistas, dados financeiros, propostas, documentos pessoais, negociações confidenciais e mensagens internas.

Por isso, o acesso ao e-mail deve ser tratado com muito cuidado. Em muitos cenários, o agente deve poder rascunhar uma resposta, mas não enviá-la automaticamente. Também pode ser recomendável limitar o acesso por pasta, remetente, assunto, período ou contexto.

Quando o agente tiver permissão para enviar mensagens externas, a empresa deve definir regras claras: quando há aprovação humana, que tipo de anexo é permitido, como evitar destinatário errado e como registrar a ação.

Banco de dados: o agente não deve ter SQL livre sobre dados pessoais

Outro risco comum é conectar agentes diretamente a bancos de dados para responder perguntas internas. A intenção pode ser boa: facilitar análise, relatórios e produtividade.

Mas permitir que um agente gere consultas livres sobre tabelas com dados pessoais pode criar exposição excessiva.

Uma alternativa mais segura é usar:

• views aprovadas;
• campos limitados;
• filtros por área, carteira ou unidade;
• mascaramento de dados;
• limites de linhas;
• bloqueio de exportação em massa;
• registro de consultas;
• revisão humana para ações sensíveis.

O agente não precisa “ver tudo” para ser útil. Em muitos casos, a inteligência está justamente em desenhar um fluxo controlado, com dados suficientes para o objetivo e restrições adequadas para reduzir risco.

Identidade do agente: quem fez a ação?

Uma pergunta simples deve orientar a governança: quando o agente age, quem aparece no log?

Se todas as ações ficam registradas como “admin”, “integração”, “API user” ou “bot genérico”, a empresa perde rastreabilidade.

O ideal é que cada agente tenha:

• identidade própria;
• dono interno responsável;
• finalidade documentada;
• sistemas autorizados;
• escopos de acesso;
• ambiente de execução conhecido;
• trilha de auditoria.

Também é importante diferenciar dois cenários:

1. Agente agindo em nome de um usuário: por exemplo, um vendedor pede ao agente para resumir o histórico de um lead que já está em sua carteira.
2. Agente agindo como serviço corporativo: por exemplo, um agente que roda automaticamente todos os dias para identificar tickets pendentes ou riscos operacionais.

Essa distinção muda permissões, logs e responsabilidades. Um agente não deve herdar acesso amplo apenas porque um usuário específico tem acesso amplo. E um agente corporativo não deve operar como se fosse uma pessoa sem regras próprias.

Autorização: permissões por tarefa, não por conveniência

A regra de menor privilégio, muito conhecida em segurança da informação, também vale para agentes de IA: o agente deve acessar apenas o que precisa para cumprir sua função.

Na prática, isso significa separar permissões como:

• leitura;
• escrita;
• envio externo;
• exclusão;
• exportação;
• consulta a dados sensíveis;
• acesso a anexos;
• acesso a dados de todos os clientes ou apenas de uma carteira;
• acesso temporário ou contínuo.

Um agente de suporte, por exemplo, pode precisar visualizar histórico de atendimento e status do cliente. Isso não significa que precise acessar dados financeiros, documentos pessoais ou toda a base de clientes.

Um agente comercial pode ajudar a preparar follow-ups. Isso não significa que deva enviar e-mails sem revisão, alterar cadastro do cliente ou exportar listas inteiras.

A governança deve começar pelo caso de uso. Antes de conceder acesso, a empresa deve responder:

• Qual problema o agente resolve?
• Quais sistemas ele precisa acessar?
• Quais dados pessoais entram no fluxo?
• O acesso é indispensável ou apenas conveniente?
• O agente apenas lê ou também executa ações?
• Há risco para titulares se o agente errar?
• Quem aprova mudanças de permissão?

Minimização de dados antes do prompt

A LGPD trabalha com princípios como finalidade, necessidade, segurança e responsabilização. Para agentes de IA, esses princípios precisam ser traduzidos para decisões de arquitetura.

Uma medida prática é minimizar dados antes de enviá-los ao modelo.

Em vez de enviar um histórico completo de cliente, a empresa pode enviar apenas os campos relevantes para a tarefa. Em vez de incluir CPF, endereço completo e dados financeiros, pode mascarar ou remover o que não for necessário. Em vez de indexar documentos inteiros em uma base vetorial, pode separar materiais por finalidade, área e nível de acesso.

Também é preciso olhar para a chamada “memória” do agente. Se o agente guarda informações para melhorar interações futuras, essa memória pode virar um novo repositório de dados pessoais. Ela precisa de finalidade, retenção, controle de acesso e processo de exclusão.

O mesmo vale para bases RAG e bancos vetoriais. Se documentos com dados pessoais são indexados, a empresa precisa entender onde estão, quem consulta, por quanto tempo ficam armazenados e como atender direitos dos titulares quando aplicável.

Logs e auditoria: não basta dizer que “a IA decidiu”

O NIST, em discussões recentes sobre ecossistemas de IA agentiva, destaca a importância de rastreabilidade: reconstruir a cadeia de decisões, o uso de ferramentas e as evidências que sustentaram uma ação do agente.

Para empresas, isso significa que logs devem ser úteis, mas não excessivos.

Um bom registro pode indicar:

• usuário que acionou o agente;
• identidade do agente;
• ferramenta consultada;
• tipo de dado acessado;
• horário da ação;
• decisão tomada;
• aprovação humana, quando houver;
• resultado gerado;
• erro ou exceção relevante.

Ao mesmo tempo, a empresa deve evitar transformar logs em um novo vazamento esperando acontecer. Copiar dados pessoais em excesso para logs, prompts, históricos ou ferramentas de observabilidade pode aumentar o risco.

A pergunta correta é: qual evidência precisamos para auditar e corrigir o sistema sem armazenar mais dados do que o necessário?

O papel do DPO na governança de agentes de IA

O DPO, ou encarregado, não precisa ser a pessoa que aprova tecnicamente cada integração. Mas ele deve participar da governança dos casos de uso que envolvem dados pessoais, principalmente quando há automação, alto volume, dados sensíveis, decisões relevantes ou fornecedores externos.

Na prática, o DPO pode apoiar a empresa em pontos como:

• mapear agentes e conectores que tratam dados pessoais;
• revisar finalidade e base legal por caso de uso;
• orientar minimização de dados;
• avaliar necessidade de análise de risco ou RIPD quando aplicável;
• revisar cláusulas com fornecedores de IA;
• verificar transferência internacional e suboperadores;
• apoiar política interna de uso de agentes;
• definir regras de aprovação humana;
• orientar resposta a incidentes envolvendo IA;
• treinar áreas de negócio para não conectar sistemas sem governança.

Esse é um bom exemplo de como DPO as a Service pode gerar valor contínuo. A empresa não precisa esperar um problema acontecer para envolver privacidade. Ela pode criar um processo leve de triagem, aprovação e revisão periódica dos agentes em uso.

Checklist antes de conectar um agente de IA aos sistemas internos

Antes de liberar um agente para operar com dados reais, a empresa deveria responder pelo menos estas perguntas:

1. Qual é a finalidade do agente?
2. Quais sistemas ele acessa?
3. Quais categorias de dados pessoais entram no fluxo?
4. O agente precisa mesmo de todos esses dados?
5. O acesso é de leitura, escrita, envio, exclusão ou exportação?
6. O agente tem identidade própria?
7. Quem é o dono interno do agente?
8. As permissões são temporárias ou permanentes?
9. O agente pode acessar anexos?
10. O agente pode enviar e-mails ou mensagens externas?
11. Quando há aprovação humana?
12. Os dados enviados ao modelo são minimizados ou mascarados?
13. Existe memória persistente? Por quanto tempo?
14. Há base vetorial ou RAG com dados pessoais?
15. Os logs registram ações sem armazenar dados em excesso?
16. O fornecedor usa dados para treinar modelos?
17. Há transferência internacional de dados?
18. O contrato prevê exclusão, segurança e suboperadores?
19. Como a empresa responderá a pedidos de titulares?
20. Qual é o plano em caso de erro, exposição indevida ou incidente?

Conclusão: agentes de IA precisam de governança antes da escala

Agentes de IA podem aumentar produtividade, melhorar atendimento e acelerar rotinas internas. Mas, quando conectados a CRM, e-mail, bancos de dados e ferramentas corporativas, eles passam a fazer parte do ecossistema de tratamento de dados pessoais da empresa.

O caminho mais seguro não é proibir o uso. É organizar.

Empresas que querem usar agentes de IA com responsabilidade devem criar um inventário de casos de uso, definir permissões, limitar dados, revisar fornecedores, manter logs proporcionais e envolver privacidade desde o desenho da solução.

A TOGETHER apoia empresas nessa jornada com DPO as a Service, governança de IA, revisão de fornecedores, políticas internas e estruturação de processos práticos para que inovação e proteção de dados caminhem juntas.

Referências

• NIST — AI Agent Standards Initiative: https://www.nist.gov/artificial-intelligence/ai-agent-standards-initiative
• NIST — Building Measurement Probes into Agentic AI Ecosystems: https://www.nist.gov/news-events/events/2026/04/nist-information-technology-laboratory-ai-webinar-series-building
• LGPD — Lei nº 13.709/2018: https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm
• ANPD — Guia sobre atuação do Encarregado: https://www.gov.br/anpd/pt-br/assuntos/noticias/anpd-lanca-guia-sobre-atuacao-do-encarregado