Antes de tudo: eu não sou advogado. O que segue é o que aprendi implementando e vendendo software com IA para empresas brasileiras, e cada ponto aqui foi validado — ou corrigido — por alguém que é. Se você for usar isso pra decidir algo sério, faça o mesmo.
Dito isso: a parte de LGPD que mais atrapalha venda de IA não é jurídica. É de engenharia.
A pergunta que derruba a proposta
Já vi mais de um projeto travar em uma pergunta só, feita pelo encarregado do cliente:
"Se a gente encerrar o contrato, como vocês apagam nosso dado?"
Parece simples. Aí você lembra que aquele dado entrou num índice vetorial compartilhado, virou embedding, apareceu em log de prompt, foi parar num cache, e possivelmente está numa avaliação que alguém salvou pra comparar modelos.
A resposta honesta seria "não sei ao certo". Essa resposta perde o contrato — e deveria mesmo.
O direito de eliminação está lá no artigo 18 e não é novo. O que a IA fez foi multiplicar os lugares onde o dado se espalha, sem que ninguém tenha atualizado o mapa. Você não pode apagar o que não sabe onde está.
Controlador e operador: descubra qual você é
Isso decide o resto do contrato e é onde vi mais gente errar.
No arranjo típico de SaaS B2B, o cliente é o controlador — ele decide por que e como tratar o dado — e você é o operador, tratando em nome dele. Isso significa que a base legal não é sua escolha: é dele. Seu papel é executar dentro do que ele determinou e conseguir provar que foi só isso.
Onde isso vira problema: no minuto em que você usa o dado do cliente pra melhorar seu produto — treinar, avaliar, ajustar — você pode estar tratando para finalidade própria. Aí a conversa mudou de figura. Não é proibido, mas exige base legal, transparência e, muito provavelmente, uma cláusula específica que a maioria dos contratos padrão não tem.
A regra prática que adotei: dado de cliente não vira melhoria de produto sem cláusula explícita. Se quiser usar, negocia. Se não negociou, não usa. Isso encerra uma classe inteira de discussão desagradável meses depois.
Subprocessador é o nome do seu provedor de modelo
Toda API de modelo que você chama é um subprocessador. Toda. E o cliente tem direito de saber quem são e de ser avisado quando a lista muda.
Isso tem duas consequências chatas e uma boa:
Chata um: trocar de provedor de modelo não é decisão só técnica. Se o contrato lista subprocessadores e exige aviso prévio, sua migração de fornecedor tem prazo contratual.
Chata dois: transferência internacional tem regra própria. Se o modelo roda fora do Brasil — e quase sempre roda —, isso é transferência internacional de dados pessoais. A ANPD aprovou cláusulas-padrão contratuais justamente pra dar um caminho previsível aqui, e a maioria dos contratos de fornecedor grande já vem com equivalente. Vale conferir se o seu vem, em vez de supor.
A boa: essa lista, uma vez montada, é o ativo comercial mais subestimado que você pode ter. Chegar na call de segurança com a tabela pronta — provedor, finalidade, país, base de transferência, retenção — muda o tom da reunião inteira. Já vi isso encurtar due diligence de semanas pra dias.
Decisão automatizada: o artigo que quase ninguém lê
O artigo 20 dá ao titular o direito de solicitar revisão de decisões tomadas unicamente com base em tratamento automatizado que afetem seus interesses.
Se o seu agente aprova, reprova, pontua ou prioriza pessoas, isso te alcança. Duas coisas que passei a exigir dos nossos sistemas por causa disso:
Registro do porquê. Não basta guardar a saída. Precisa dar pra reconstruir com que informação a decisão foi tomada. Foi uma das razões que me levaram a construir o Credence — o rastro de origem que serve pra depurar agente é o mesmo que serve pra responder pedido de revisão.
Humano no lugar certo. "Revisão humana" não é botão de aprovar em lote. É alguém com informação suficiente pra discordar. Se o revisor só vê a nota final, o processo é decorativo.
O que a arquitetura resolve e o que ela não resolve
Escrevi sobre modelo por demanda por cliente e a conexão com LGPD é direta, mas quero ser preciso sobre o limite.
Resolve: isolamento demonstrável, porque nenhum processo carrega dado de dois clientes; eliminação verificável, porque a configuração e o armazenamento são por cliente; e retenção com prazo real, porque o ambiente é efêmero por construção.
Não resolve: base legal, finalidade, informação ao titular, contrato, e o inventário de tratamento. Isso é trabalho de papel, e não tem arquitetura que substitua.
O erro comum — que eu cometi — é achar que uma boa engenharia de isolamento cobre conformidade. Ela cobre a parte demonstrável. A parte declaratória continua sendo escrita por gente.
O kit mínimo que eu levo pra call
Depois de repetir isso muitas vezes, virou uma pasta que abro na tela:
- Mapa de fluxo de dados: o que entra, onde processa, o que persiste, por quanto tempo.
- Lista de subprocessadores com país e base de transferência.
- Política de retenção por tipo de dado, com o número real, não "conforme necessidade".
- Procedimento de eliminação, incluindo índices, caches e logs — testado, não escrito.
- Plano de incidente: quem avisa, em quanto tempo, por qual canal. Comunicação de incidente à autoridade e aos titulares está prevista na lei e tem expectativa de prazo razoável; não é hora de improvisar.
- Relatório de impacto quando o tratamento for de risco maior — perfilamento, decisão automatizada, dado sensível.
Nada disso é sofisticado. É só feito antes em vez de depois.
Sobre o marco legal de IA
Existe projeto em tramitação no Congresso para regular IA de forma específica, com obrigações graduadas por risco. Não vou apostar em texto final nem em prazo — a essa altura qualquer previsão minha envelhece rápido.
O que dá pra dizer com alguma segurança: as exigências que aparecem em toda proposta séria são as mesmas que você já deveria ter. Saber o que o sistema faz, registrar como decide, conseguir explicar, conseguir apagar.
Quem construiu isso porque o cliente pediu vai achar a regulação chata. Quem não construiu vai achar cara.