VTB explica por que pilotos de IA travam antes da produção e como resolver isso com arquitetura

Nos dias 8 e 9 de abril, durante a conferência Data Fusion, o VTB admitiu publicamente um problema que quase todo cliente corporativo de IA conhece: os pilotos parecem convincentes, mas poucos chegam de fato à produção. O foco da análise não é a qualidade de um modelo isolado, e sim a própria arquitetura de implementação.

Por que os pilotos quebram

A ideia central é simples. Um piloto costuma testar uma única etapa em condições controladas. Na produção, surge uma cadeia inteira de ações, e os erros se acumulam ao longo dela. Se oito elos operam com 85% de precisão, a confiabilidade final da cadeia cai para 27%. Numa apresentação, esse sistema ainda parece "quase bom". No processo real, porém, três de cada quatro resultados saem errados, e o mais perigoso é que não dá para saber de antemão quais. Por isso, o problema não aparece como um bug pontual, mas como uma degradação sistêmica da qualidade à medida que o sistema escala.

Disso decorre uma conclusão ainda mais incômoda: o mercado muitas vezes otimiza a IA não para a precisão, mas para a autonomia. A métrica "qual porcentagem das tarefas foi concluída sem um humano" é conveniente para marketing e relatórios, mas mostra mal o quanto o sistema continua conectado à realidade no longo prazo. O artigo relaciona isso ao automation bias e ao deskilling: as pessoas passam a confiar cada vez mais em sugestões erradas e, ao mesmo tempo, perdem a habilidade de decidir sem a máquina. No fim, a empresa fica não só com um pipeline frágil, mas também com uma erosão gradual da própria expertise.

Arquitetura com humano

Em vez da autonomia total, a proposta é um esquema de baixa entropia, em que o humano faz parte do sistema como elemento obrigatório, e não como botão de emergência. O trabalho é dividido em quatro níveis: do operador de campo, que fica junto ao objeto, ao especialista de domínio, que revisa as recomendações do modelo e devolve as correções para o treinamento. A lógica é "zerar" a incerteza em cada nível, em vez de deixá-la subir sem controle pela cadeia.

• Nível 0 — operador ou especialista no local, que vê o objeto real e valida os dados de entrada.
• Nível 1 — modelos especializados em sinais específicos: temperatura, umidade, defeitos, imagens ou outros parâmetros físicos.
• Nível 2 — coordenador, que reúne os resultados dos modelos, raciocina sobre eles e formula uma recomendação para o humano.
• Nível 3 — especialista de domínio, que confirma ou corrige a conclusão e, com isso, fornece ao sistema um sinal de treinamento.

Nesse arranjo, o papel da IA não é substituir o especialista, mas ampliar seu raio de ação e sua produtividade. O autor cita o exemplo de um gêmeo digital de um ecossistema florestal com mais de 180 mil hectares. Quando a cobertura passou de 2 para 50 mil hectares, os gastos de capital cresceram 2,1 vezes, os operacionais 2,2 vezes, e a equipe aumentou apenas de quatro para oito pessoas. Na abordagem tradicional, segundo a estimativa do autor, seriam necessários muitas vezes mais funcionários de campo.

Por que API não basta

Um ponto à parte trata do stack. O artigo afirma que é difícil construir esse esquema apenas sobre APIs públicas de grandes modelos, porque a expertise de domínio deve residir não nos prompts, nem só no RAG, mas nos pesos de um modelo controlado localmente. Para isso, a proposta são adaptadores LoRA ou QLoRA, retreinados com pares verificados de respostas e preferências dos especialistas. Depois do expediente, os logs passam por validação humana; à noite, roda o retreinamento; e de manhã o sistema já opera com o conhecimento de domínio atualizado.

"O prompt é esquecido no fim da janela de contexto.

O adaptador, nunca."

Essa lógica aposta em infraestrutura própria. A referência de hardware no material fica em torno de 900 mil a 1,2 milhão de rublos: um servidor com RTX 4090 ou 5090 para o coordenador e o treinamento noturno, alguns Raspberry Pi para os modelos especializados no local e um armazenamento separado para os logs. O argumento principal não é que os modelos em nuvem sejam inúteis, mas que é melhor usá-los como ferramenta externa de pesquisa, e não como camada de tomada de decisão em um circuito de produção crítico.

O que isso significa

Para o mercado, é uma virada importante: a questão deixa de ser quantas pessoas dá para tirar do processo e passa a ser como manter a qualidade ao escalar a IA. Se essa lógica pegar, as implementações corporativas tendem a girar cada vez mais em torno de modelos locais, verificação constante e circuitos humano-máquina, e não de promessas de autonomia total.