A gente pegou o teste mais rigoroso que existe hoje pra medir quanto de um trabalho real uma IA entrega sozinha, do pedido até a entrega pronta, e rodou ele duas vezes. Uma com um modelo de ponta, desses que rodam na nuvem e custam caro por uso. Outra com um modelo barato, aberto, rodando dentro de casa, numa máquina de escritório. O modelo de ponta tirou 0,94. O modelo local tirou 0,48.
A nota é a parte menos interessante. O que interessa pro seu negócio é o que quebrou: o modelo barato fez o trabalho, escreveu mais de duas mil linhas de código coerente, e mesmo assim ficou na metade da nota. Não por burrice. Por falta de disciplina pra terminar sozinho e por não provar que o que fez funciona. E quase tudo que quebrou tem conserto no processo em volta, não no modelo. Essa é a decisão que toda empresa enfrenta quando pesa IA local (conta previsível) contra nuvem (cara por uso), e é sobre isso aqui.
O que a gente mediu, sem jargão
Imagine contratar alguém pra uma tarefa fechada: aqui está a especificação do que precisa ser feito, entregue pronto e testado. O teste mede exatamente isso na IA. Ele dá um pedido real e detalhado (uma integração de pagamento, no caso), deixa a IA planejar, executar e entregar sozinha, e no fim um avaliador independente confere item por item da especificação. Cada exigência vale dois pontos: fez? e provou com teste que funciona?. Sem evidência, zero. É o mesmo teste, com as mesmas regras, rodado nos dois modelos. A única diferença é qual IA está no volante.
A descoberta que importa: ele faz, mas não prova
Aqui está o ponto que vale mais que a nota total. O modelo local implementou boa parte do que foi pedido, chegou a entregar 8 das 14 exigências. Mas quando o teste perguntou "e você provou, com um teste automático, que isso funciona?", a resposta foi zero em 13 das 14 exigências. Traduzindo pra folha de pagamento: ele escreve o trabalho, mas não confere o próprio trabalho. Entrega sem garantia.
Isso não é detalhe de laboratório. É o retrato de qualquer processo em que a máquina produz rápido e ninguém confere depois. O que separa uma automação confiável de uma bomba-relógio quase nunca é a capacidade de produzir. É a prova de que o que foi produzido está certo. E o modelo barato é exatamente onde essa prova some primeiro.
Capacidade não é o gargalo. Disciplina é.
O padrão de falha mais comum foi quase cômico de tão humano. O modelo escrevia "agora eu vou criar o arquivo" e simplesmente parava. Anunciava a ação e não executava. É o funcionário que na reunião diz "pode deixar que já mando o e-mail" e o e-mail nunca sai. Os melhores resultados morreram assim, sempre no último passo, com o trabalho 90% pronto e ninguém pra mandar continuar.
Repare no tamanho do contraste: essa mesma IA que trava em "continuar sem ninguém mandar" tinha acabado de escrever mais de duas mil linhas de código coerente. A inteligência estava lá. O que faltou foi a teimosia de terminar. Modelo de ponta faz isso no automático, você nem percebe que existe esse degrau. No modelo barato, é onde tudo escorrega.
Teve mais coisa quebrando pelo mesmo motivo. Numa hora o modelo inventou um erro que não existia em lugar nenhum, uma mensagem de "sem espaço em disco" que ele leu num log onde ela nunca esteve, e parou pra perguntar o que fazer, travando um processo que deveria rodar sozinho. Noutra, restos de tentativas antigas espalhados pela máquina fizeram ele investigar em vez de trabalhar, até desistir em silêncio. Nenhuma dessas falhas é sobre "a IA não sabe programar". Todas são sobre conduzir a IA num trilho firme.
Onde a IA barata sofre de verdade
Trabalho de verdade exige que a IA execute ações concretas, uma atrás da outra, centenas de vezes, sem escorregar em nenhuma: cria um arquivo, roda um comando, lê o resultado, decide o próximo passo. Modelo de ponta faz isso de forma invisível. Nos modelos leves, foi exatamente aí que tudo escorregou, e cada um de um jeito diferente. Um anunciava a ação e não fazia. Outro decidia a ação certa mas errava o formato de executar. Um terceiro inventava a própria tarefa. Trocamos de modelo várias vezes procurando um que aguentasse o papel inteiro, e a lição foi dura: passar num teste simples não prevê aguentar um trabalho longo e complexo.
Teve até um ajuste fino curioso, que qualquer gestor entende por analogia. Existe um botão que regula o quanto a IA é "criativa" contra "obediente ao pé da letra". No ajuste mais rígido, ela ficou teimosa: passou 18 minutos insistindo em instalar uma coisa do jeito que estava bloqueado, sem nunca tentar o caminho alternativo óbvio. Afrouxando um pouco, no mesmo ponto, ela leu a documentação, contornou o obstáculo e entregou a implementação completa. Rigidez demais trava; folga demais alucina. O ponto certo não é o mesmo pra cada modelo, e só a operação de verdade, sob carga, revela qual é.
A conta: um cobra em dólar, o outro em horas
Aqui está o outro lado da moeda, o que puxa tanta empresa pro modelo local. As duas opções custam, só que em moedas diferentes. A nuvem cobra em dinheiro, por uso: cada rodada oficial do teste queimou perto de 31 milhões de unidades de processamento, e isso vira fatura em dólar que cresce com o volume. O modelo local não manda fatura nenhuma, mas cobra em tempo: cada tentativa completa levou de 4 a 6 horas de máquina rodando na sua energia.
Pra quem tem volume alto e constante, tempo fixo de máquina previsível bate fatura variável que surpreende. Pra quem usa pouco e de vez em quando, a nuvem sai mais barata sem discussão. Só que a conta de horas do modelo local só fecha se ele de fato terminar o trabalho, e foi justamente aí que ele tropeçou. Rodar barato não adianta se metade das tentativas morre no último passo.
O que isso significa pra sua empresa
A conclusão que fica é libertadora e desconfortável ao mesmo tempo. Capacidade você compra barato. O modelo aberto que rodou na nossa máquina escreve código coerente, resolve problema, contorna obstáculo. O que ele não tem, e o que o modelo de ponta cobra caro pra entregar, é a disciplina de terminar sozinho e a teimosia de provar que terminou. E isso, diferente da capacidade, não vem no modelo: vem no processo que você constrói em volta dele.
Três lições que valem pra qualquer automação de IA, com modelo caro ou barato. Primeira: "concluído" não é prova. Se ninguém confere de forma objetiva o que a máquina diz que fez, você está confiando na palavra dela, e ela erra. Segunda: a integridade tem que ser estrutural. Regra que depende do modelo "obedecer" é cara ou coroa; o que segura de verdade é o trilho que não deixa ele pular etapa. Terceira: a escolha do modelo é parte do sistema, não uma caixinha que você troca no fim. O teste era idêntico nos dois casos. A diferença inteira estava em qual modelo aguentava o roteiro sem tropeçar.
Dá pra rodar trabalho sério com IA barata, dentro de casa, com conta previsível. Só não dá pra jogar o modelo sozinho no problema e esperar que ele se conduza. O que transforma um modelo local de "promessa que trava no último passo" em ferramenta confiável é exatamente o trilho em volta: as conferências obrigatórias entre etapas, os freios que não deixam a IA encerrar sem ter terminado de verdade, a prova automática de que cada entrega funciona. É esse trilho, e não o modelo, que separa uma automação que você pode confiar de uma que te deixa na mão numa sexta às cinco da tarde.
Esse foi o primeiro round. O próximo é adaptar o trilho ao jeito que o modelo barato roda, e ver o quanto dá pra recuperar da nota sem trocar de modelo. Vira a parte 2. Se a sua empresa está pesando IA local pra cortar custo e quer saber onde ela paga primeiro, o que precisa ficar dentro de casa e quanto de trilho ela vai exigir pra ser confiável, é exatamente esse mapa que o Diagnóstico de IA On-Premise da Steply entrega.