Tem um padrão que se repete em projeto de IA que falha em produção: o agente foi calibrado com dataset genérico, com "dados de mercado", com corpus público — qualquer coisa menos os casos reais do cliente. Resultado previsível: na primeira semana de produção, falso positivo vira norma. Time perde confiança. Agente vai pra prateleira em 60 dias.
E na pós-mortem, a conversa quase nunca aponta a causa raiz. O time discute hiperparâmetros, troca de modelo base, ajuste de threshold. O problema raramente é o modelo. É o que entrou nele.
Por que dataset genérico parece atraente#
Calibrar com dataset genérico é tentador por três motivos legítimos:
- Velocidade — você pode começar amanhã. Não precisa coordenar com o time do cliente pra exportar histórico, anonimizar, validar amostra.
- Volume — dataset genérico costuma ter milhões de exemplos. Dataset próprio do cliente costuma ter centenas a milhares. O instinto técnico fala "mais é melhor".
- Disponibilidade — Hugging Face, Kaggle, datasets públicos. Tudo a um
pip installde distância. Sem fricção contratual.
Tudo isso é verdade. E é exatamente por isso que vai dar errado em produção.
O que dataset genérico não captura#
Operação tem três camadas de especificidade que dataset genérico nunca vai ter:
Vocabulário do negócio. Cada empresa tem uma forma de chamar as coisas que não aparece em corpus público. A fintech chama de "transação suspeita" o que o regulador chama de "operação atípica". A indústria chama de "peça fora de tolerância" o que o livro chama de "rejeito". O agente treinado em corpus público classifica corretamente o conceito abstrato e erra sistematicamente o termo concreto que o cliente usa.
Edge cases reais. Os casos difíceis de uma operação são, por definição, raros — e por isso ausentes em qualquer dataset suficientemente "limpo" pra ser publicado. O caso em que dois clientes diferentes têm CPF parecido. O caso em que um defeito visual é normal pra esse fornecedor específico. O caso em que uma reclamação que parece queixa é, naquela operação específica, um pedido de upsell disfarçado. Esses casos só existem no histórico do cliente.
Distribuição de classes. Dataset genérico costuma ser balanceado pra didática (50% de cada classe, ou amostras estratificadas). Operação real é desbalanceada — 99% das transações são normais, 1% suspeitas. Modelo treinado no dataset balanceado vai produzir muito mais falso positivo na operação desbalanceada do que esperado pela métrica de avaliação.
O caso fintech: 30 dias, falso positivo zero#
Na implantação de compliance automatizado pra uma fintech Série A (caso publicado: /casos/investig — processo semelhante aplicado em compliance bancário), seguimos o roteiro contrário ao dataset genérico:
- Semana 1-2 — Coleta. O time de risco do cliente exportou 90 dias de transações classificadas (transação X, decisão Y, justificativa Z). ~270 mil registros. Anonimização preservando estrutura.
- Semana 3 — Análise estatística. Distribuição real: 98.7% normais, 1.1% revisão, 0.2% reprovadas. Confirmamos que vocabulário interno tem 14 termos específicos que não aparecem em corpus de compliance público. Mapeamos.
- Semana 4 — Tuning supervisionado. Agente roda sobre os 90 dias históricos. Saída comparada com a classificação humana original. Toda divergência analisada por analista sênior — quem estava certo? Cada acerto/erro reforça o modelo via prompt-tuning + exemplos.
Resultado documentado: falso positivo caiu de ~12% (linha de base com prompt genérico) para 0% (após 30 dias com dados próprios). Esse "zero" não é fluke estatístico — significa que, na janela de validação supervisionada de 30 dias seguintes, nenhuma transação aprovada pelo agente foi reprovada pelo revisor humano por amostragem.
Isso não foi sorte. Foi consequência de calibrar o modelo com os casos que ele iria operar.
O custo real da calibragem com dados próprios#
A objeção comum: "calibrar com nossos dados leva tempo." Verdade. No caso da fintech, esse custo foi:
- 2 semanas pra exportação + anonimização (time do cliente)
- 1 semana pra análise estatística (Titan Lab)
- 1 semana de tuning supervisionado (analista sênior do cliente revisando)
Total: 4 semanas. Comparado com o que? Comparado com 60-90 dias de POC com dataset genérico que precisa ser jogada fora porque o agente não converge na operação real. Calibragem própria não é o caminho lento — é o caminho que termina.
O checklist técnico#
Se você está prestes a iniciar projeto com agente de IA, esses são os critérios mínimos pra calibragem ter chance:
| Critério | Mínimo viável | Ideal |
|---|---|---|
| Volume de exemplos | 500 casos rotulados | 5.000+ |
| Janela temporal | Últimos 30 dias | Últimos 90 dias (captura sazonalidade) |
| Distribuição | Refletindo proporção real | Refletindo + edge cases catalogados separadamente |
| Vocabulário | Glossário interno mapeado | Glossário + sinônimos + contraexemplos |
| Revisor sênior | 1 pessoa disponível 50% do tempo | 1 pessoa dedicada por 4 semanas |
| Critério de fim | Falso positivo < X% | Falso positivo < X% medido por amostragem por 2 semanas consecutivas |
Sem esse mínimo, o projeto não vai sair da POC — não por limitação do modelo, mas por limitação dos dados que entraram nele.
O ponto que importa#
Modelo de IA hoje é, em alta medida, commodity. Claude, GPT, Gemini — todos chegam num teto técnico similar pra a maioria das tarefas de operação. O que decide se o projeto vai funcionar em produção é a qualidade do dado que calibra o modelo na sua realidade específica.
Por isso a primeira pergunta que vale fazer ao iniciar projeto com agente de IA não é "qual modelo vamos usar". É: qual é a janela histórica de dados rotulados que temos? quem é o revisor sênior que vai validar a calibragem? Se as respostas existem, o projeto tem chance. Se não, o trabalho que precisa acontecer antes do código é a coleta — não o tuning.