Quando uma empresa liga um atendimento com IA, o caminho do dado costuma ser este: a mensagem do cliente chega, o sistema anexa o histórico dele, junta um trecho do cadastro para dar contexto, e manda tudo para o modelo.
Funciona bem. E, nesse mesmo movimento, CPF, telefone, endereço e às vezes dado de saúde saem da sua infraestrutura — muitas vezes para um servidor em outro país. Isso não é um detalhe de implementação: é tratamento de dado pessoal, com regra própria.
Este artigo é de engenharia, não é parecer jurídico. Ele descreve controles técnicos que sustentam o cumprimento da LGPD; a avaliação da base legal de cada tratamento é do seu jurídico ou do encarregado de dados.
1. O que a lei trata como problema aqui
Quatro pontos da LGPD tocam diretamente um agente de IA:
- Necessidade (art. 6º, III). O tratamento deve se limitar ao mínimo necessário para a finalidade. Mandar o cadastro inteiro porque "é mais fácil" é o oposto disso.
- Dado sensível (art. 11). Saúde, biometria, origem racial e outros têm regime mais restrito que dado comum. Uma clínica que joga a queixa do paciente no prompt está tratando dado sensível, mesmo que só queira marcar uma consulta.
- Transferência internacional (art. 33). Se o modelo roda fora do Brasil, houve transferência internacional — e ela exige fundamento próprio. Esse é o ponto mais ignorado, porque não aparece em lugar nenhum da interface.
- Papéis (art. 5º). Você é o controlador. O fornecedor do modelo é operador. Responsabilidade perante o titular não terceiriza junto com a API.
2. O controle que resolve a maior parte: não mandar
A defesa mais eficaz não é contratual, é arquitetural: o dado pessoal não precisa chegar ao modelo. O modelo precisa entender a intenção e redigir a resposta — quase nunca precisa do CPF real para isso.
O padrão é redigir na entrada e reidratar na saída: substitui-se cada dado por um rótulo antes do envio, e o valor real volta depois, já no seu servidor, quando a resposta for montada.
import re
CPF = re.compile(r"\b\d{3}\.?\d{3}\.?\d{3}-?\d{2}\b")
# \b nao casa antes de "(", entao o parentese de abertura ficaria orfao.
# O lookbehind tambem impede casar no meio de um numero longo.
TELEFONE = re.compile(r"(?<![\w])(?:\+55\s?)?\(?\d{2}\)?\s?9?\d{4}[-\s]?\d{4}(?!\d)")
def cpf_valido(valor: str) -> bool:
"""Confere os dígitos verificadores. Sem isso, qualquer sequência de 11
números vira falso positivo — protocolo, matrícula, código de imóvel."""
n = re.sub(r"\D", "", valor)
if len(n) != 11 or n == n[0] * 11:
return False
for corte in (9, 10):
soma = sum(int(n[i]) * (corte + 1 - i) for i in range(corte))
if (soma * 10) % 11 % 10 != int(n[corte]):
return False
return True
# entrada Oi, sou a Ana, CPF 529.982.247-25. Contato: ana.silva@exemplo.com.br ou (17) 99123-4567. Imóvel no CEP 15010-100, protocolo 12345678901, empresa 12.345.678/0001-95. # o que sai da sua rede Oi, sou a Ana, CPF [CPF]. Contato: [EMAIL] ou [TELEFONE]. Imóvel no CEP [CEP], protocolo 12345678901, empresa [CNPJ]. # casos que separam um redator util de um quebrado 111.111.111-11 -> preservado (repetido, nao e CPF) 529.982.247-24 -> preservado (digito verificador errado) 12345678901 -> preservado (protocolo, nao CPF)
Repare no que não foi mascarado. Um redator que apaga toda sequência de 11 dígitos destrói número de protocolo, matrícula e código de imóvel — e o agente perde justamente a informação de que precisa para trabalhar. Por isso a validação de dígito verificador não é preciosismo: é o que separa mascarar dado pessoal de mutilar o contexto.
Regex sozinha não cobre tudo. Nome próprio, endereço escrito por extenso e número de carteirinha não têm formato fixo — para esses, a saída é não colocá-los no prompt em primeiro lugar (buscar por identificador interno) ou usar um classificador dedicado. Trate o redator como a última linha de defesa, não como a única.
3. Minimizar antes de redigir
Redigir é a rede de segurança. O ganho maior vem antes, no que você decide anexar:
- Envie identificador, não o registro. O agente trabalha com
cliente_id; quem resolve o nome real é o seu servidor, na hora de montar a resposta final. - Recorte o RAG por permissão antes da busca, não depois — o mesmo princípio da etapa 2 da blindagem.
- Limite o histórico. Reenviar 40 turnos anteriores multiplica exposição e custo. Resuma o que passou e mande o resumo.
- Separe o que é sensível. Numa clínica, "quero remarcar" não precisa carregar o motivo da consulta anterior.
4. O que exigir do fornecedor do modelo
- Retenção zero ou contratada. Saber por quanto tempo o conteúdo fica guardado, e se é usado para treino. Isso é cláusula, não configuração.
- Região de processamento. Se houver opção no Brasil, ela elimina a discussão do art. 33 de uma vez.
- Registro de tratamento. Você precisa conseguir responder, para um titular, o que foi tratado a respeito dele — o que exige a trilha de auditoria, não só o log da aplicação.
- Eliminação. Pedido de exclusão precisa alcançar também o que ficou em índice vetorial e em cache — e essa é a parte que costuma ser esquecida na implementação.
5. O resumo
O jeito mais barato de cumprir a lei num agente de IA é reduzir o que sai da sua rede. Minimize o que é anexado, redija o que ainda assim passar, reidrate no seu servidor e guarde trilha do que foi tratado. Contrato com o fornecedor cobre o resto — mas não substitui nenhuma dessas quatro coisas.
Quer saber que dado seu sai da rede hoje?
Diagnóstico sem custo: mapeamos o que o seu agente envia ao modelo, apontamos o que é desnecessário e o que é sensível, e devolvemos o recorte mínimo.