LGPD e IA: o que garantir antes de subir um agente

A LGPD não tem um capítulo sobre inteligência artificial, e é justamente por isso que a dúvida aparece. As obrigações são as mesmas de sempre, só que um agente de IA as encontra todas ao mesmo tempo: ele trata dado pessoal, envia esse dado a um terceiro, produz decisão automatizada e guarda histórico.

Este texto organiza o que precisa estar resolvido antes de subir um agente em produção, na ordem em que a conversa costuma acontecer dentro da empresa. Ele descreve prática, não parecer: a leitura final de risco é de quem responde juridicamente por dados pessoais aí, e a função deste guia é fazer você chegar nessa conversa com as perguntas certas.

O que muda quando é IA

Nada muda na lei, e três coisas mudam na prática. A primeira é que o dado sai do ambiente da empresa. Ao usar um serviço de terceiro, o conteúdo enviado passa a ser tratado por outra organização, com outra política de retenção e, às vezes, outra jurisdição.

A segunda é a opacidade. Quando alguém pergunta por que a resposta foi aquela, um sistema tradicional exibe a regra, e o modelo não exibe nada equivalente. Isso torna mais difícil cumprir o dever de explicar, que a lei cobra.

A terceira é a escala. Um agente processa em um dia o que uma equipe processaria em um mês, e um erro de configuração não afeta um caso, afeta a base inteira. As três combinadas explicam por que o mesmo tratamento que era rotina passa a exigir revisão quando o executor é um modelo.

A base legal vem antes da ferramenta

A primeira pergunta não é qual ferramenta usar, é com que fundamento a empresa trata aquele dado. Se o tratamento já acontece hoje de forma manual e tem base definida, usar IA para executá-lo não cria uma base nova, mas pode mudar a finalidade, e finalidade nova exige fundamento próprio.

O exemplo que mais aparece é o histórico de atendimento. Registrar a conversa para prestar o serviço é uma coisa. Usar o mesmo histórico para treinar um modelo que vai pontuar propensão de compra é outra finalidade, com outro fundamento, e às vezes com necessidade de consentimento específico.

Vale escrever a resposta em uma linha por uso, antes de qualquer piloto: qual dado, para qual finalidade, com qual fundamento e por quanto tempo. Sem isso, o projeto avança e a pergunta reaparece na véspera de entrar em produção, quando mudar custa caro.

Minimização: o que não enviar

O princípio da minimização diz para tratar apenas o dado necessário à finalidade, e ele é a ferramenta prática mais útil aqui, porque reduz risco sem reduzir resultado.

• Remova identificador direto quando ele não for necessário. Muita análise funciona igual com um código no lugar do nome e do CPF.
• Não envie o registro inteiro quando o trecho basta. Mandar o contrato completo para extrair a data de vencimento é excesso.
• Separe o dado sensível antes. Saúde, biometria, origem racial, opinião política e filiação sindical têm regime próprio e não devem entrar em piloto por descuido.
• Prefira consulta a cópia. Arquitetura que lê sob demanda deixa menos rastro que a que duplica a base para um ambiente novo.

Boa parte dessa separação sai do trabalho descrito em governança de dados, e é ele que torna a decisão rápida em vez de caso a caso.

O fornecedor é operador, e isso tem consequência

Quando a empresa contrata um serviço que trata dado pessoal em seu nome, esse fornecedor atua como operador, e a empresa continua respondendo como controladora perante o titular. O contrato precisa refletir isso, e três cláusulas costumam faltar.

A primeira é a vedação de uso do conteúdo para treinamento do modelo do fornecedor. A segunda é a obrigação de informar incidente em prazo definido, porque o dever de comunicar recai sobre a empresa. A terceira é a transparência sobre subcontratação, já que muitos serviços rodam sobre modelo de um terceiro, e a cadeia precisa estar explícita para poder ser avaliada.

Vale acrescentar a pergunta de onde o processamento ocorre. Transferência internacional é permitida, mas tem requisitos próprios, e descobrir a rota depois do contrato assinado costuma custar renegociação.

Decisão automatizada e o direito à revisão

Este é o ponto que mais afeta desenho de produto. A lei assegura ao titular pedir revisão de decisão tomada unicamente com base em tratamento automatizado que afete seus interesses, incluindo decisões de perfil.

Na prática, isso significa duas exigências. Precisa existir um caminho para pedir revisão, visível para quem foi afetado e não escondido em rodapé. E precisa existir alguém capaz de revisar de fato, com acesso ao caso e autonomia para mudar o resultado, o que exclui a revisão que apenas repete a saída do sistema.

O desenho que evita o problema é manter a decisão final com uma pessoa nos casos que afetam alguém, usando o modelo para preparar, ordenar e sugerir. Vale para crédito, seleção, priorização de atendimento e qualquer pontuação que mude o que a pessoa recebe. Em atendimento, a fronteira prática está descrita em agente de IA para atendimento e vendas.

O que contar ao titular

A transparência exigida é menor do que o receio sugere, e maior do que a prática comum. O titular precisa saber que existe tratamento automatizado, qual a finalidade, e como pedir revisão. Não é preciso publicar detalhe técnico de modelo.

Em atendimento, a boa prática é declarar no início da interação que se trata de um assistente, e oferecer caminho para uma pessoa. Isso não é apenas conformidade: reduz frustração e melhora o resultado, porque a expectativa fica calibrada desde o começo.

Retenção, log e exclusão

Três prazos precisam estar definidos, e costumam ser esquecidos porque ficam em camadas diferentes do sistema. O primeiro é quanto tempo a empresa guarda a conversa ou o documento processado. O segundo é quanto tempo o fornecedor retém o conteúdo enviado, que é informação dele e precisa estar no contrato.

O terceiro é o log de uso, aquele registro de quem perguntou o quê e o que o sistema respondeu. Ele é necessário para auditoria e para atender pedido de revisão, e é também um novo depósito de dado pessoal, que precisa de prazo e de controle de acesso como qualquer outro.

O pedido de exclusão precisa alcançar as três camadas. Sistema que apaga da base própria e deixa cópia no histórico do fornecedor não cumpriu o pedido, e essa é a falha mais comum quando o assunto é auditado.

O que checar antes de subir

1. A finalidade está escrita, com fundamento definido para cada uso.
2. O dado enviado foi reduzido ao necessário, sem identificador dispensável.
3. O contrato com o fornecedor veda treinamento, prevê comunicação de incidente e explicita subcontratação.
4. Existe caminho visível para pedir revisão, e alguém com autonomia para revisar.
5. Os três prazos de retenção estão definidos, incluindo o do log.
6. O aviso de que há tratamento automatizado está onde o titular vê.
7. Quem responde por dados pessoais na empresa leu e concordou com o desenho.

Sete itens resolvem a maior parte dos casos de uso interno e de atendimento. Aplicação que envolva dado sensível ou decisão de crédito pede análise dedicada, e nesses casos o custo do parecer é pequeno perto do custo de refazer.

Por onde seguir

A regra de o que pode ser enviado a cada ferramenta cabe na política descrita em governança de IA, que é onde estas exigências viram rotina. A separação do que é sensível vem de governança de dados, e o preparo da base antes do projeto está em como preparar os dados da empresa antes de qualquer IA. Para escolher onde aplicar com menor exposição, o recorte é IA para empresas, e os limites por tipo de aplicação estão em agentes de IA e em o que é chatbot. Quando a conformidade entra no orçamento do projeto, as linhas que ela ocupa estão em quanto custa criar uma IA. E se o requisito legal mudar o desenho do que vai ser construído, a conversa é de escopo, tratada em definir o escopo de um produto digital.

Perguntas frequentes