IA no WhatsApp e LGPD: como atender clientes sem vazar dados sigilosos

O problema real: a conversa do cliente não é sua para entregar

• a conversa inteira, com tudo o que o cliente contou, passa a existir nos servidores de outra empresa;

• ela pode ficar guardada em logs, em históricos de requisições, em sistemas de monitoramento, por um prazo que você não define;

• e, dependendo do contrato, pode ser usada para treinar o modelo de outra pessoa.

O que a LGPD diz sobre isso

• Finalidade e necessidade (art. 6º). O dado foi entregue para o atendimento. Usá-lo para outra coisa, como o treino do modelo de um fornecedor, ou expor mais do que o necessário, fere os princípios da lei.

• Transparência (art. 9º). O titular tem direito de saber com quem seus dados são compartilhados e para quê. Uma IA que manda a conversa para um terceiro sem isso estar claro na política de privacidade é um compartilhamento escondido.

• Segurança desde a concepção (art. 46). A empresa precisa adotar medidas técnicas e administrativas para proteger os dados contra acessos não autorizados, e a lei pede isso desde a concepção do produto, não depois do incidente.

• Transferência internacional (art. 33). Processar dados pessoais fora do país só é permitido em hipóteses específicas, com garantias, e a maior parte da infraestrutura de IA está fora dele.

• Responsabilidade (arts. 42 e 44). O tratamento que não oferece a segurança esperada é irregular, e quem trata o dado responde pelo dano que ele causar.

• Incidentes e sanções (arts. 48 e 52). Um vazamento relevante precisa ser comunicado à ANPD e aos titulares, e as multas chegam a 2% do faturamento, limitadas a R$ 50 milhões por infração, sem contar o dano à reputação.

A pergunta que muda o desenho

O que ficou para trás

• A API de um LLM comercial. A melhor qualidade de resposta com o menor esforço. Mas a conversa chega em claro num serviço que não controlamos, e a única proteção é o contrato. Foi a primeira versão do desenho, e foi substituída antes de ir para produção.

• Mascarar os dados pessoais antes de enviar. Parece elegante: trocar nome, telefone e endereço por marcadores e mandar o resto. Na prática, nenhum algoritmo reconhece com segurança qualquer dado pessoal num texto livre. Um "moro em frente à padaria do Seu João" passa por qualquer filtro. Uma proteção que falha em silêncio é pior que nenhuma, porque dá a sensação de que o problema está resolvido.

As três decisões

1. Um modelo aberto, rodando num ambiente nosso

2. Criptografia de envelope, com a chave sempre do nosso lado

• cada resposta usa uma chave de dados própria, que não abre nenhuma outra;

• essa chave é protegida por uma chave mestra que fica na nossa conta e nunca sai dela;

• o processo que gera a resposta só decifra o pedido em memória, durante a geração, e devolve a resposta já cifrada.

3. Nada da conversa num log, e isso é testado

• Os logs registram só identificadores, tempos e códigos de erro. Nunca o texto, nunca a mensagem da exceção, que costuma carregar pedaços da entrada.

• Há um teste que confere isso: nenhuma linha de log pode conter o texto de entrada ou de saída. Uma regra de privacidade que não está num teste é uma intenção, não uma garantia.

O jurídico entrou antes do código

• a política de privacidade da MSI passou a dizer que as respostas podem ser geradas por IA, quem processa o texto, para quê, onde, e como ele é protegido;

• o fornecedor da infraestrutura de GPU entrou na política como suboperador, e dele são exigidos o contrato de tratamento de dados e o relatório de auditoria de segurança.

O que isso não protege (e por que dizer)

• O WhatsApp está no caminho por definição. A criptografia descrita aqui protege o trecho entre o nosso ambiente e a IA.

• O banco do sistema guarda as conversas, porque o atendimento precisa delas. Ele fica do lado de dentro, protegido por controle de acesso.

• Quem administra a máquina da GPU, durante a geração, poderia em tese ler a memória. Nenhuma criptografia resolve isso sem hardware de computação confidencial. É por isso que o contrato e a auditoria do fornecedor são exigidos, e não opcionais.

A stack

• Backend: TypeScript e Node.js 22, em módulos separados por responsabilidade (chat, canal e agente), conversando por filas e contratos;

• Painel de atendimento: React com React Router;

• Banco: PostgreSQL;

• Geração das respostas: Python, com um modelo de pesos abertos;

• Organização: monorepo com pnpm, infraestrutura como código e testes com Jest e pytest, escritos antes do código.

O preço dessa escolha

• Partida a frio: para não pagar GPU parada, a primeira resposta depois de um tempo sem uso demora mais, enquanto a máquina sobe; quente, a resposta sai em segundos.

• Qualidade: um modelo aberto de porte acessível não é o melhor modelo comercial. A escolha é por medição, não por fama.

• Mais peças: geração assíncrona, novas tentativas com espera crescente, circuit breaker para quando o provedor cai e uma varredura periódica para o retorno que não chega.

• Dois lados do contrato: quem cifra e quem decifra são escritos em linguagens diferentes, e os dois são testados contra os mesmos exemplos fixos, para concordar byte a byte.

O que eu levo para o próximo projeto

• O dado do cliente não é seu para entregar. A empresa recebe a conversa para atender, e é só para isso que ela pode ser usada.

• A LGPD é requisito de arquitetura. Neste caso, ela decidiu o modelo, o formato das mensagens e até o que pode aparecer num log.

• Desenhe para não precisar confiar. Contrato e auditoria continuam necessários, mas "o que o terceiro consegue ver?" vale mais que "o que o terceiro promete?".

• Diga o limite em voz alta. "Só existe em claro na memória durante a geração" é uma frase verificável. "Ponta a ponta" quase nunca é.