VTB explicou por que pilotos de AI emperram antes de chegar à produção e como a arquitetura pode corrigir isso

Nos dias 8 e 9 de abril, na conferência Data Fusion do VTB, o VTB reconheceu publicamente um problema familiar para quase todo cliente corporativo de IA: pilotos parecem convincentes, mas poucos chegam à produção real. O foco da análise não é a qualidade de um modelo individual, mas a própria arquitetura de implementação.

Por Que Pilotos Quebram

A ideia-chave é simples: um piloto normalmente testa uma etapa em condições controladas, mas em produção surge uma cadeia inteira de ações onde os erros se acumulam. Se oito elos funcionam com 85% de precisão, a confiabilidade geral da cadeia cai para 27%. Em uma apresentação, tal sistema ainda parece "quase bom", mas em um processo real, três de quatro resultados saem errados, e o mais perigoso é que não fica claro de antemão quais são.

Por isso o problema não se manifesta como um bug único, mas como uma degradação sistêmica da qualidade ao escalar. Isso também leva a uma conclusão mais desagradável: o mercado frequentemente otimiza IA não pela precisão, mas pela autonomia. A métrica "qual porcentagem de tarefas é executada sem intervenção humana" é conveniente para marketing e relatórios, mas mostra pouco bem como o sistema permanece ancorado à realidade no longo prazo.

O artigo vincula isso a viés de automação e deskilling: as pessoas cada vez mais confiam em sugestões incorretas e simultaneamente perdem a habilidade de tomar decisões sem a máquina. Como resultado, a empresa não consegue apenas um pipeline frágil, mas também uma erosão gradual de sua própria expertise.

Arquitetura Com Humanos

Em vez de autonomia total, propõe-se um esquema de baixa entropia, onde humanos estão incorporados no sistema como elemento obrigatório, não como botão de emergência. Divide o trabalho em quatro níveis: desde um operador de campo perto do objeto até um especialista de domínio que verifica as recomendações do modelo e realimenta correções para o treinamento.

A lógica é "descarregar" a incerteza em cada nível, em vez de deixá-la subir descontroladamente pela cadeia.

• Nível 0 — um operador ou especialista no local que vê o objeto real e valida dados de entrada.
• Nível 1 — modelos estreitos para sinais específicos: temperatura, umidade, defeitos, imagens ou outros parâmetros físicos.
• Nível 2 — um coordenador que coleta resultados dos modelos, raciocina e formula uma recomendação para humanos.
• Nível 3 — um especialista de domínio que confirma ou corrige a conclusão e assim fornece um sinal de aprendizagem ao sistema.

Em tal design, a tarefa da IA não é substituir o especialista, mas expandir seu escopo de ação e produtividade. O autor fornece o exemplo de um gêmeo digital de um ecossistema florestal cobrindo mais de 180 mil hectares: conforme a cobertura cresceu de 2 para 50 mil hectares, despesas de capital aumentaram 2,1 vezes, despesas operacionais aumentaram 2,2 vezes, e o time cresceu apenas de quatro para oito pessoas. Com uma abordagem tradicional, segundo a estimativa do autor, seriam necessários muito mais funcionários de campo.

Por Que API Não É Suficiente

Um ponto separado diz respeito ao stack. O artigo argumenta que tal esquema é difícil de construir apenas sobre APIs públicas de modelos grandes, porque a expertise de domínio deve viver não apenas em prompts ou RAG, mas nos pesos de um modelo localmente controlado. Para isso, propõem-se adaptadores LoRA ou QLoRA, que são ajustados em pares verificados de respostas e preferências de especialistas. Após o dia de trabalho, logs são validados por humanos, o ajuste fino é executado à noite, e pela manhã o sistema inicia com conhecimento de domínio atualizado.

"Um prompt é esquecido no final da janela de contexto.

Um adaptador — nunca."

Esta lógica aposta em infraestrutura proprietária. O benchmark de hardware mencionado no material é aproximadamente 900 mil a 1,2 milhão de rublos: um servidor com RTX 4090 ou 5090 para o coordenador e treinamento noturno, vários Raspberry Pi para modelos estreitos no local, e armazenamento de logs separado. O argumento principal não é que modelos em nuvem são inúteis, mas que são melhor usados como uma ferramenta de pesquisa externa em vez de uma camada de tomada de decisão em loops de produção crítica.

O Que Isso Significa

Para o mercado, essa é uma mudança importante: a questão não é mais quantas pessoas podem ser removidas do processo, mas como manter a qualidade ao escalar IA. Se essa lógica pegar, implementações corporativas serão cada vez mais construídas em torno de modelos locais, verificação contínua e loops humano-máquina, em vez de promessas de autonomia total.