lgpd · privacidade

O dado do seu cliente está indo para dentro do prompt

Versão técnica. Se você é dono de empresa e quer saber o que checar, leia A IA da sua empresa está vendo dado que não deveria (4 min).

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.

lgpd.py · redator de dado pessoal brasileiro✓ testado
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
saída real da execução✓ 12/12 casos
# 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:

  1. 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.
  2. Recorte o RAG por permissão antes da busca, não depois — o mesmo princípio da etapa 2 da blindagem.
  3. Limite o histórico. Reenviar 40 turnos anteriores multiplica exposição e custo. Resuma o que passou e mande o resumo.
  4. 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.

próximo passo

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.