Um agente de RH que responde dúvidas sobre férias já está lidando com dado pessoal, mesmo que ninguém tenha pensado nisso no momento de configurar o SharePoint como fonte de conhecimento. Um agente de atendimento no WhatsApp coleta o número de telefone do cliente na primeira mensagem, antes mesmo de a conversa começar de verdade. Um agente de vendas que consulta o CRM está processando nome, e-mail, histórico de compra — tudo dado pessoal, na definição exata da lei. A maior parte das empresas que implementa agentes de IA não percebe que está lidando com a LGPD desde o primeiro dia, porque o foco natural vai para “o agente funciona bem?” e a pergunta “que dado ele está tocando, e com que base legal?” fica para depois — quando já é tarde para corrigir com facilidade. Este artigo cobre os cuidados que precisam entrar na conversa antes do lançamento de qualquer agente que toque dado pessoal, com a ressalva necessária: o que segue é orientação prática e técnica, não parecer jurídico. Para decisões formais de conformidade, o encarregado de dados ou um advogado precisa validar o caso específico da sua empresa. Para o panorama mais amplo de como estruturar o controle de agentes de IA, veja o artigo sobre governança de agentes de IA, e para o contexto geral de agentes corporativos, o artigo sobre agentes de IA para empresas.
Riscos: onde a LGPD entra sem que ninguém tenha planejado
Fonte de conhecimento conectada sem revisão do que contém
O caminho mais comum para um problema de LGPD em um agente de IA começa de forma inofensiva: alguém conecta um site inteiro do SharePoint como fonte de conhecimento porque é mais rápido do que selecionar bibliotecas específicas. Se esse site contém, em algum lugar, uma planilha com dados de colaboradores, um contrato com informação de terceiro, ou um documento de avaliação de desempenho, o agente passa a ter acesso a dado pessoal que ninguém pretendia expor — e pode, eventualmente, incluir esse conteúdo em uma resposta para um usuário que não deveria ter acesso a ele.
Coleta de dado além do necessário
É comum um agente ser configurado para coletar mais informação do que a tarefa realmente exige — “para o caso de precisar depois”. Um agente de suporte técnico que pede CPF sem necessidade real, um agente de vendas que armazena detalhes pessoais de uma conversa sem finalidade clara para isso. Cada dado coletado sem necessidade imediata é uma responsabilidade extra que a empresa assume: guardar com segurança, justificar por que está ali, e eventualmente apagar quando alguém pedir.
Ausência de transparência com o titular
Um usuário que conversa com um agente sem saber que está falando com um sistema automatizado — ou sem entender que aquela conversa está sendo processada e possivelmente armazenada — não teve a informação básica que a LGPD exige que ele tenha. Isso vale tanto para colaboradores internos quanto, com ainda mais peso, para clientes em canais externos como WhatsApp ou site.
Retenção indefinida de conversas
Logs de conversa com um agente costumam ficar armazenados por padrão, sem que ninguém tenha decidido conscientemente por quanto tempo isso faz sentido. Guardar indefinidamente é o tipo de decisão que parece inofensiva até o dia em que alguém pede a exclusão dos próprios dados, ou até uma auditoria perguntar por que a empresa ainda tem conversas de três anos atrás sem justificativa para isso.
Combinação de dados que não deveria acontecer
Um agente com acesso a mais de uma fonte de dados pode, em uma única resposta, juntar fragmentos que isoladamente pareciam inofensivos, mas que combinados formam um perfil mais completo sobre uma pessoa do que qualquer sistema individual permitiria. Ninguém configurou essa combinação de propósito. Ela aconteceu porque nada no desenho do agente impedia.
Decisão automatizada sem revisão humana em caso sensível
A LGPD trata com atenção especial situações em que uma decisão que afeta uma pessoa é tomada de forma automatizada, sem intervenção humana — especialmente quando envolve avaliação de comportamento, perfil ou características pessoais. Um agente que, por exemplo, aprova ou nega automaticamente uma solicitação com base em dado pessoal, sem qualquer revisão humana disponível para o titular contestar, entra numa zona que exige cuidado redobrado e, quase sempre, orientação jurídica específica antes de ser implementado dessa forma.
Boas práticas: o que reduz esse risco na prática
Definir a base legal antes de escrever qualquer tópico do agente
A LGPD prevê dez bases legais diferentes para o tratamento de dado pessoal, e consentimento é apenas uma delas — provavelmente a mais mal aplicada em contexto corporativo, porque exige uma manifestação livre e específica que é difícil de obter (e de provar) em uma conversa automatizada. Para a maioria dos agentes internos, a base costuma ser execução de contrato de trabalho ou legítimo interesse da empresa para fins de gestão. Para agentes que atendem clientes, frequentemente é execução de contrato comercial. Qual base se aplica depende da finalidade concreta — e essa definição deveria acontecer antes da primeira linha de configuração do agente, não depois que ele já está em produção.
Minimizar por padrão, não por exceção
A pergunta que deveria orientar cada campo de coleta de dado no agente é simples: isso é estritamente necessário para resolver o que o usuário está pedindo agora? Se a resposta for “pode ser útil depois”, a resposta correta é não coletar. Minimização não é apenas um princípio abstrato da lei — é a prática que reduz, na origem, boa parte do risco de vazamento, retenção indevida e exposição desnecessária.
Ser claro com quem está do outro lado da conversa
A primeira mensagem de qualquer agente que processa dado pessoal deveria deixar claro que se trata de um sistema automatizado, e, quando fizer sentido, indicar brevemente que a conversa é processada e como o usuário pode acessar mais informação ou falar com um humano. Isso não precisa ser um parágrafo jurídico completo dentro do chat — pode (e deveria) apontar para a política de privacidade completa, mas a transparência mínima no momento do primeiro contato não é opcional.
Definir e documentar prazo de retenção
Cada tipo de dado que passa pelo agente deveria ter um prazo de retenção definido conscientemente, não herdado do padrão da plataforma. Conversas de suporte técnico simples podem ter retenção curta. Registros que sustentam uma obrigação fiscal ou trabalhista seguem prazos legais específicos, geralmente mais longos. A diferença entre esses casos precisa estar documentada, com justificativa, para que a empresa consiga responder com segurança se algum dia for questionada sobre por que guarda o que guarda.
Configurar DLP para impedir combinação e exposição indevida
As políticas de prevenção de perda de dados do Copilot Studio, configuradas no Power Platform Admin Center, controlam quais conectores e fontes de dados podem ser combinados dentro de um mesmo agente. É o controle técnico mais direto para impedir o cenário descrito na seção de riscos, em que fragmentos de fontes diferentes se juntam numa resposta que nenhuma delas, isoladamente, geraria. Vale revisar essas políticas antes do lançamento de qualquer agente com acesso a mais de uma fonte de dado pessoal, não depois.
Manter revisão humana nos pontos que realmente importam
Nem toda interação do agente precisa de revisão humana antes de acontecer — isso inviabilizaria o próprio propósito de ter um agente. Mas decisões que afetam uma pessoa de forma concreta (aprovar, negar, classificar, priorizar) deveriam ter um ponto de checagem humana disponível, especialmente quando o titular tem o direito de contestar aquela decisão. O agente pode preparar, sugerir, estruturar — a decisão final em casos sensíveis continua sendo de uma pessoa.
Envolver o encarregado de dados desde o desenho, não na revisão final
Se a empresa tem um DPO (encarregado de dados) formalmente nomeado, ele deveria estar na conversa desde a definição do caso de uso do agente, não apenas assinando uma aprovação no fim do projeto. Trazer essa avaliação cedo custa muito menos do que redesenhar um agente já em produção porque uma prática de coleta de dado precisou ser revista depois de um questionamento externo.
Exemplos: como isso aparece em casos de uso reais
Agente de RH respondendo dúvida sobre férias
O agente responde com base na política geral de férias — informação que não é dado pessoal de ninguém especificamente. O problema aparece se o colaborador perguntar “quantos dias de férias eu ainda tenho”, porque essa resposta exigiria consultar um dado individual em um sistema de folha de pagamento. A prática mais segura, nesse caso, é o agente explicar o processo geral e direcionar a consulta de saldo individual para o canal ou sistema já autorizado a lidar com esse dado especificamente, em vez de tentar responder ele mesmo com base em uma integração ad hoc.
Agente de atendimento no WhatsApp
Já na primeira mensagem, o número de telefone do cliente é um dado pessoal sendo processado — e, como detalhamos no artigo sobre Copilot Studio e WhatsApp, o conteúdo dessa conversa é compartilhado com a própria plataforma WhatsApp, fora do perímetro direto de controle da empresa. Isso reforça, nesse canal especificamente, a importância de coletar o mínimo possível e deixar claro logo de início que é um atendimento automatizado.
Agente de suporte técnico interno
Ao abrir um chamado, o agente coleta nome, e-mail e descrição do problema — dados pessoais do colaborador, ainda que em contexto interno. A base legal aqui costuma ser direta (execução do contrato de trabalho, para fins de suporte operacional), mas mesmo assim vale manter esse fluxo dentro do escopo declarado: se o agente começar a usar essas informações para qualquer finalidade além de resolver o chamado, isso já é uma nova finalidade que precisaria de avaliação própria.
Checklist antes de conectar um agente a dado pessoal
Base legal e finalidade
- ☐ A base legal para o tratamento de dado pessoal foi definida e documentada antes do lançamento?
- ☐ A finalidade do agente está descrita de forma específica, não genérica?
- ☐ O jurídico ou o encarregado de dados revisou esse desenho antes de ir ao ar?
Minimização e fontes de dado
- ☐ O agente coleta apenas o dado estritamente necessário para a finalidade declarada?
- ☐ As fontes de conhecimento conectadas foram revisadas quanto à presença de dado pessoal não previsto?
- ☐ Existe risco de combinação indevida entre múltiplas fontes conectadas ao mesmo agente?
Transparência
- ☐ A primeira interação informa claramente que se trata de um atendimento automatizado?
- ☐ Há um caminho acessível para o usuário entender como seus dados são tratados?
- ☐ Existe forma simples de o usuário falar com um humano quando quiser?
Retenção e controles técnicos
- ☐ Existe prazo de retenção definido e documentado para os dados processados pelo agente?
- ☐ As políticas de DLP no Power Platform Admin Center estão configuradas para esse agente?
- ☐ O agente usa autenticação adequada ao nível de sensibilidade do dado que acessa?
Revisão humana
- ☐ Decisões automatizadas que afetam uma pessoa têm ponto de revisão humana disponível?
- ☐ Existe processo para o titular contestar uma resposta ou decisão do agente?
- ☐ Há revisão periódica programada, não apenas no lançamento?
Este checklist funciona melhor como ponto de partida para uma conversa com o jurídico da empresa, não como substituto dela. Para o desenho de controle mais amplo de quem responde por cada agente, vale complementar com o modelo descrito no artigo sobre governança de agentes de IA.
Um aviso direto sobre este conteúdo
Tudo que foi descrito aqui é orientação prática e técnica, pensada para ajudar times de TI, produto e negócio a chegarem numa conversa com o jurídico já com as perguntas certas em mãos — não para substituir essa conversa. A LGPD tem nuances que dependem do caso concreto: o setor da empresa, o tipo específico de dado, se há dado sensível envolvido (saúde, origem racial, orientação sexual, entre outras categorias com proteção reforçada), e o histórico de tratamento já existente na empresa mudam a análise de forma relevante. Antes de lançar qualquer agente que processe dado pessoal em escala, vale uma avaliação formal com um advogado especializado ou com o encarregado de dados da empresa. A Autoridade Nacional de Proteção de Dados (ANPD) também publica orientações e materiais de referência que ajudam a entender como a lei está sendo interpretada e aplicada.
Para fechar
A boa notícia é que nada disso exige escolher entre ter um agente de IA útil e respeitar a LGPD. As duas coisas convivem bem quando a base legal é definida cedo, o agente coleta só o necessário, o usuário sabe com quem está falando, os dados têm prazo para deixar de existir, e alguém revisa periodicamente se tudo isso ainda está funcionando como planejado. O que não convive bem é tratar privacidade como uma etapa de revisão no fim do projeto — nesse ponto, ajustar já custa tempo, retrabalho e, em alguns casos, risco regulatório que poderia ter sido evitado com uma conversa de trinta minutos no início.
A InfoB, como parceira certificada Microsoft, apoia empresas na configuração técnica de agentes com os controles de segurança e privacidade adequados — DLP, permissões, retenção — trabalhando lado a lado com o jurídico ou o encarregado de dados de cada empresa, que segue sendo quem valida a adequação legal do tratamento.
Perguntas frequentes
Um agente de IA precisa de consentimento para processar dados pessoais?
Depende da base legal aplicável ao caso. Consentimento é só uma das dez bases previstas na LGPD — em bastante caso corporativo, execução de contrato ou legítimo interesse acabam sendo mais adequados, porque consentimento exige uma manifestação livre e específica que é difícil de obter numa conversa automatizada. Qual base vale para o seu agente depende da finalidade concreta dele.
O agente pode usar dados de clientes para melhorar suas próprias respostas com o tempo?
Isso é uma finalidade diferente de simplesmente responder à conversa daquele momento, e precisa de base legal e transparência próprias. Não é algo que deveria acontecer por padrão só porque a plataforma permite.
Por quanto tempo os dados de conversa com o agente devem ficar guardados?
Pelo tempo que a finalidade declarada exigir, nem mais. Não existe um número mágico válido para todo caso — varia com o tipo de dado e eventual obrigação legal de guarda. O prazo precisa ser definido conscientemente, não deixado no padrão da plataforma.
Este artigo substitui uma análise jurídica sobre LGPD?
Não. O conteúdo é informativo e cobre cuidados técnicos e operacionais relevantes. Decisão sobre base legal e adequação de tratamento de dado pessoal precisa ser validada com um advogado ou com o encarregado de dados da empresa, olhando o caso concreto.