O agente que atendia bem até vazar o dado errado
Numa fintech brasileira, um agente de IA respondia dúvida de fatura pelo WhatsApp. Funcionou bem por meses. Numa sexta à tarde, respondeu a pergunta certa com o dado errado: colou o CPF e o histórico de compras de outro cliente na conversa. O time de segurança só viu no fim de semana, revogou o acesso do agente na segunda e levou seis semanas para reativar, agora com escopo de dado reescrito do zero.
Esse tipo de episódio já aparece em número, não só em conversa de corredor. A Sinch entrevistou 2.527 executivos seniores de dez países, Brasil incluído, entre janeiro e fevereiro deste ano, para o relatório "The AI Production Paradox". A cobertura brasileira do estudo saiu nas duas últimas semanas: 76% das empresas do país já têm agente de IA rodando em produção, acima da média global de 62% e dos 67% dos Estados Unidos. O Brasil sai na frente na corrida de colocar agente pra atender gente de verdade.
Só que 80% das organizações brasileiras já precisaram interromper ou reverter alguma implementação de IA, também acima da média global, que é 74%. E em 39% desses recuos o motivo foi vazamento de dado pessoal ou informação sensível. Não foi o modelo que respondeu errado. Foi o agente enxergando dado que não devia enxergar.
| Métrica | Brasil | Média global |
|---|---|---|
| Agentes de IA em produção | 76% | 62% |
| Já interrompeu ou reverteu implementação | 80% | 74% |
| Rollback causado por vazamento de dado | 39% | não informado por país |
As duas leituras não se cancelam
Dá pra ler o dado de duas formas. A primeira: o Brasil é mais ousado, testa em produção antes dos EUA e da Europa, aprende mais rápido. A segunda: o Brasil está pulando a etapa que impede o agente de sair rodando com acesso a tudo. Provavelmente as duas são verdadeiras ao mesmo tempo, e é exatamente isso que o estudo chama de paradoxo. Velocidade de deploy virou métrica de vaidade em reunião de board. Velocidade de rollback virou custo escondido que ninguém mede.
A gente vê o padrão de perto em diagnóstico de cliente: o agente nasce com acesso amplo porque é mais rápido de configurar assim, e ninguém volta depois para apertar o escopo. Funciona no piloto, com dez conversas por dia e um analista acompanhando cada uma. Escala para mil conversas por dia e o mesmo escopo amplo vira uma superfície de erro que ninguém está olhando em tempo real.
Por que o culpado quase nunca é o modelo
Quando um agente vaza dado de um cliente para outro, o instinto é culpar o modelo por alucinar. Na prática, o problema costuma estar uma camada abaixo: o agente tem acesso de leitura a uma base inteira quando devia ter acesso só ao registro daquela conversa. A pergunta certa não é se o modelo é confiável. É o que esse agente consegue ler, e por quanto tempo.
Um exemplo simples do que muda o resultado: em vez de dar ao agente uma chave de API com escopo total do CRM, o acesso é gerado por sessão, vale só para o ID do cliente daquela conversa e expira quando ela termina.
POST /v1/session-token
{
"customer_id": "cli_48213",
"scope": ["read:invoice", "read:ticket"],
"ttl_seconds": 900
}
Esse token não abre a base inteira. Abre uma fatia, por um tempo curto, e expira sozinho. É trabalho de arquitetura, não de prompt. Nenhum ajuste de instrução no agente resolve permissão mal desenhada.
Tem um motivo pelo qual essa etapa fica pra depois. Escopo estreito dá mais trabalho de configurar e trava caminho que parecia funcionar no teste manual. O time sob prazo escolhe o caminho que funciona amanhã, não o que aguenta o próximo trimestre. E o custo dessa escolha não aparece na sexta em que o agente entra no ar. Aparece semanas depois, quando o volume de conversas já é dez vezes maior e ninguém está olhando log um por um.
O que dá pra fazer na segunda de manhã
Antes de perguntar se o agente está pronto para mais volume, vale perguntar o que ele consegue ler hoje que não devia. Três checagens rápidas: se o acesso a dado é por sessão ou permanente, se existe log de qual registro cada conversa tocou, e se alguém revisa esse log toda semana ou só depois que algo já vazou.
A Overflow trata essa etapa como parte da implementação, não como extra: na fase de produção do processo de IA-first, agente entra no ar com controle de acesso e guardrail definidos antes, não ajustados depois do primeiro incidente. Detalhe de <a href="https://overflow.codes/ia-first">como isso funciona na prática</a>. Não é sobre desacelerar o Brasil na corrida de colocar agente em produção. É sobre chegar na frente sem deixar a porta destrancada atrás.