O fornecedor mudou o modelo e partiu-se: como a tua automação sobrevive a uma versão nova

O que se parte a sério quando o modelo muda (e o que não se parte)

A primeira coisa é tirar do caminho a palavra «partiu-se», porque manda-te procurar no sítio errado. Quando o fornecedor muda o modelo, a tua automação não falha: muda de ideias. A ligação fica intacta e a avaria, se aparecer, aparece três passos abaixo e disfarçada de outra coisa.

• A forma da saída. O JSON traz um campo a mais, o mesmo campo chega como texto em vez de número, ou a resposta vem embrulhada num bloco de código que antes não vinha. O nó que fazia o parsing deixa de o fazer e, no pior caso, nem rebenta: devolve vazio e segue.
• O tom e o comprimento. O rascunho de email que cabia em três linhas abre agora com duas frases de cortesia. Ninguém dá por isso numa semana. Dá-se por isso quando alguém do comercial diz que «os emails automáticos soam estranhos há um mês».
• Onde o modelo diz que não. Uma versão nova pode recusar casos que a anterior processava —dados pessoais dentro de um documento, a linguagem de uma reclamação agressiva— e essa recusa chega em prosa, não como erro. O teu fluxo arruma-a satisfeito no campo «resumo».
• O que NÃO se parte: a ligação. Mesmo endpoint, mesma chave, resposta 200. É por isso que o nó fica verde e é por isso que não salta nenhum alerta. É o ponto mais importante disto tudo.

E a mudança chega de três maneiras, que convém distinguir porque se defendem de forma diferente. Retirada anunciada: o fornecedor comunica que uma versão concreta desaparece numa data; há pré-aviso, há tempo e há culpado se ninguém o leu. Alias flutuante: a tua configuração aponta para algo do género «a última» e a última já é outra; subscreveste a mudança sem saber. Atualização por baixo: o nome da versão não muda mas o comportamento muda. Esta última é a má, porque não gera nenhum evento a que te possas agarrar.

Porque é que a deriva não dispara nenhum alerta técnico

A monitorização que tens montada —a que vem de série no n8n, no Make ou no Zapier— responde a uma pergunta: a execução terminou? Não responde à única que interessa aqui: terminou bem? E como o modelo devolve sempre algo plausível, a resposta à primeira é sim, mesmo quando a saída não presta.

• O monitor mede conclusão, não qualidade. Zero execuções falhadas convive lindamente com um mês inteiro de resumos maus. Neste caso concreto, o painel verde é informação falsa.
• Quando o parsing falha mesmo, avisa tarde e enviesado. Só apanhas a deriva que também parte a estrutura. A que mantém a estrutura e desloca o critério —classificar na categoria ao lado, extrair o valor do rodapé em vez do total— passa inteira.
• A fila de revisão humana é o teu detetor barato. Se tens um passo com humano no ciclo, um salto brusco no que chega a revisão sem que o volume de entrada tenha subido é o sinal mais fiável e gratuito que vais ter.
• O detetor caro é a queixa do cliente. É o que quase toda a gente usa, e é por isso que o problema aparece semanas depois e com plateia.

Convém pôr isto no sítio certo: a mudança de modelo é uma das frentes da manutenção contínua de qualquer automação com IA, a par das APIs que mudam e dos dados que se sujam. Aqui abrimos só essa frente, porque é a única das três em que a avaria não é provocada por ninguém do teu lado.

A bateria de casos teus: a rede de segurança antes de aceitares uma versão nova

A única defesa que funciona é ter uma opinião escrita sobre o que é uma saída correta para ti. Não um benchmark público, não a nota que o modelo tira num exame genérico: vinte ou trinta casos reais da tua operação, com o resultado que dás por bom. Isso é a bateria, e constrói-se uma vez.

• Sai do teu histórico, não da tua imaginação. Agarra execuções reais dos últimos meses: os casos normais, os estranhos e sobretudo os que correram mal e alguém corrigiu à mão. Esses últimos são os que mais valem.
• Cada caso guarda três coisas. A entrada exata, a saída que consideras correta e uma linha a explicar porque é correta. Sem a terceira, daqui a seis meses ninguém saberá se uma alteração é uma regressão ou uma melhoria.
• Não se compara letra a letra. O modelo quase nunca escreve o mesmo duas vezes, e ainda bem. Verificam-se propriedades: estrutura, valores-chave, decisão tomada, comprimento dentro de um intervalo.
• Vive fora da plataforma. Um ficheiro versionado no teu repositório ou na drive partilhada, não um cenário dentro da ferramenta. Se amanhã mudares de ferramenta, a bateria vai contigo.

Um reparo que evita o erro contrário: ter bateria não significa que a resposta a cada problema seja mudar de modelo. Se os teus casos correm mal com a versão nova e com a antiga, o modelo nunca foi o estrangulamento —esse argumento está todo em porque é que mudar de modelo não arranja um processo mal desenhado, que fala da mudança que escolhes por otimismo—. Este guia trata do caso oposto: a mudança que te chega imposta e contra a qual só te podes preparar.

Isolar a chamada ao modelo para o trocares sem mexer no resto do fluxo

A pergunta que decide se uma mudança de modelo te custa uma tarde ou duas semanas é de canalização, não de estratégia: em quantos sítios está escrito o nome do modelo? Se a resposta for «em catorze nós espalhados por seis cenários», cada aviso de retirada vira uma escavação arqueológica. O trabalho de isolar faz-se uma vez e paga-se sozinho no primeiro susto.

• Um único sítio onde vivem o nome e a versão. Uma variável de ambiente no n8n, uma linha numa folha de configuração, uma constante no teu script. Mudar de modelo tem de ser editar um valor, nunca abrir fluxos um a um.
• Um só subfluxo que faz a chamada. Os restantes cenários invocam-no e recebem a resposta já validada. No Make é um cenário atrás de um webhook interno; no n8n, um workflow chamado com Execute Workflow; num script, uma função.
• O prompt fora do nó. Guardado e versionado à parte, não incrustado no corpo de um pedido HTTP. Muitas vezes, adaptar-se a um modelo novo é mexer no prompt, e queres poder ver o que mexeste.
• Um contrato de saída explícito. O subfluxo valida a resposta contra um esquema antes de a devolver. Se não cumprir, tenta uma vez e, se voltar a falhar, manda o caso para revisão humana. Assim uma deriva de formato torna-se um aviso barulhento em vez de um dado lixo a circular no teu ERP.
• Fixa a versão, não o alias. Apontar para «a última» é cómodo até ao dia em que a última é outra e ninguém deu por ela. Fixar quer dizer que és tu a decidir quando mudas, e é disso que se trata.

Este isolamento é também o que torna possível testar qualquer alteração sem partir a automação: com a chamada num único ponto, experimentar uma versão nova é apontar o subfluxo para outro valor num ambiente de testes, não clonar meio sistema. E com o prompt versionado à parte, documentar o que a tua automação faz deixa de ser um exercício de memória.

O dia da troca: de uma versão para a outra sem desligar nada

Com a bateria montada e a chamada isolada, migrar de versão deixa de ser um salto de fé e passa a ser uma sequência aborrecida. A ordem não é negociável, porque cada passo só faz sentido se o anterior correu bem.

• A seco. Passas a bateria contra a versão candidata sem tocar na produção. O que se parte aqui arranja-se aqui, e é quase sempre o prompt e o esquema de saída, não a lógica do fluxo.
• Em sombra. Uns dias a chamar as duas versões com o mesmo caso real e a guardar as duas saídas, entregando ainda a antiga. É aí que aparecem as diferenças que nenhum caso de teste tinha previsto.
• Por troços. Primeiro o tipo de caso com menos impacto, ou uma percentagem do tráfego. O processo que mexe em dinheiro ou que fala diretamente com um cliente vai em último, nunca em primeiro.
• Com o caminho de volta preparado antes de começar. Se voltar à versão anterior for editar um valor e gravar, a migração é reversível. Se implicar um deploy e um telefonema, não é.
• Com a data no calendário. Os grandes fornecedores —OpenAI, Anthropic, Google— publicam políticas de retirada com pré-aviso e notas de versão onde anunciam as mudanças. Mas o pré-aviso chega por email e o email acaba arquivado. Uma data vale alguma coisa quando está no calendário da equipa com um lembrete, não numa caixa de entrada.

A parte incómoda: a versão antiga desliga-se, não se apaga. Deixa-a configurada e desativada durante a sobreposição. Uma mudança de modelo que corre mal às onze da noite arranja-se em dois minutos se o caminho de volta ainda lá estiver, e em duas horas se tiver de ser reconstruído de memória.

Não depender de um só fornecedor: o que isso quer dizer à tua escala

É aqui que a maioria dos artigos fica grandiloquente e recomenda uma arquitetura multi-fornecedor com comutação automática. Para uma equipa que opera meia dúzia de automações isso é sobre-engenharia cara: dá-te um sistema mais difícil de manter em troca de um risco que quase nunca se materializa assim. O que compensa a sério é muito mais modesto.

• Ter um segundo modelo testado uma vez. Não a quente: testado. Passar a bateria contra um candidato de outro fornecedor e arquivar o resultado. No dia em que precisares de mexer, já sabes o que se parte e quanto custa.
• Que a chamada não fale o dialeto de ninguém. Se o teu subfluxo usa uma camada fina de tradução ou um SDK compatível entre fornecedores, mudar é configuração. Se usa parâmetros exclusivos de um, mudar é reescrever.
• Que o prompt não dependa de uma manha. Instruções claras e um formato de saída pedido explicitamente viajam bem entre modelos. Os truques afinados para uma versão concreta não viajam: são dívida.
• O que NÃO é preciso à tua escala. Encaminhamento automático por custo, dois fornecedores quentes em paralelo ou uma camada de abstração tua. Isso resolve um problema de tamanho empresa, não o teu.

E uma fronteira honesta para fechar. Tudo o que está acima foi escrito para o operador que tem meia dúzia de fluxos e quer dormir descansado. Quando por baixo estão dezenas de sistemas, várias equipas e um inventário que ninguém tem, o problema deixa de ser um fluxo e passa a ser uma função de empresa: que sistema chama que versão, que tarefa merece que modelo e quem vigia as datas de retirada. Isso é escolher e mudar de modelo de IA em produção, e é o passo seguinte quando queres que to operem em vez de o operares tu. Se o que queres é a chamada ao modelo isolada, a bateria montada e o procedimento de mudança escrito sobre a tua stack atual, isso é infraestrutura de IA empresarial: a canalização que faz da próxima versão uma tarde de trabalho e não uma semana má.