Solução · AI Operations
O modelo que escolheste vai desaparecer. A pergunta é se dás por isso antes ou depois do teu cliente.
Escolher modelo não é uma decisão que se toma uma vez: os fornecedores retiram versões com pré-aviso, atualizam-nas por baixo e mexem nos preços — e o teu sistema continua em produção durante tudo isso. Montamos a função que transforma mudar de modelo numa operação aborrecida: banco de ensaio teu, comparação a sério e regresso atrás, em vez de um salto de fé.
O problema
O teu fornecedor de modelo é um fornecedor. Tratas-lo como se fosse uma constante.
- O modelo que usam foi escolhido numa tarde, há ano e meio, porque era o bom naquele momento. Ninguém voltou a rever a decisão e ninguém sabe se ainda é a certa.
- Chegou um email de retirada com uma data. Ninguém sabe quantos sistemas vossos dependem daquela versão em concreto, por isso também não sabe quanto trabalho está por trás dessa data.
- Alguém experimentou um modelo novo com cinco exemplos escritos à mão, achou-o melhor e pô-lo em produção. A comparação foi uma impressão, não uma medida.
- Numa manhã a qualidade mudou sem ninguém mexer em nada. Discutiu-se se era o modelo, o prompt ou o dado, decidiu-se por sensação e seguiu-se em frente.
- O mesmo modelo caro trata a tarefa que exige critério e a que só arruma um email em três gavetas, porque decidir o que vai para onde nunca foi o trabalho de ninguém.
- Se o fornecedor cai meia hora, caem meia hora. Não há segundo caminho e ninguém alguma vez testou se poderia haver.
- Mudar de modelo parece um projeto de seis semanas, por isso não se faz — e a decisão de há ano e meio fica congelada por medo, não por critério.
O custo de continuar igual
Tens um fornecedor crítico cujo produto muda debaixo dos teus pés e nenhuma forma de medir o efeito. Isso paga-se de três maneiras. A primeira é a surpresa: chega uma data de retirada e a migração faz-se a correr, sem banco de ensaio, com o risco distribuído pelos clientes. A segunda é o desvio silencioso, que é pior: o sistema não dá erro, apenas começa a responder um pouco diferente — mais longo, noutro formato, a recusar coisas que antes aceitava — e como ninguém mede, descobre-se por uma queixa. E a terceira é o custo de oportunidade: como mudar mete medo, não mudas, e continuas a pagar modelo caro para tarefas baratas e a aguentar um modelo pior do que o que já está disponível.
A solução
Transformamos a mudança de modelo numa operação medida, reversível e aborrecida
- 1Primeiro o inventário, que quase ninguém tem: que sistemas vossos chamam que modelo e em que versão exata, que tarefa faz cada chamada e o que se partiria se essa versão desaparecesse amanhã. Sem isso, qualquer aviso de retirada é uma emergência em vez de uma tarefa planeada.
- 2Construímos o teu banco de casos de ouro: um conjunto congelado de casos reais da tua operação — os normais, os estranhos e os que correram mal — com o resultado que consideras correto. É o ativo que faz a comparação de modelos passar de impressão a medida, e é teu mesmo que amanhã nos despeças.
- 3Definimos o encaminhamento por tarefa: que chamadas precisam mesmo do modelo bom e quais se resolvem com um mais barato ou mais rápido sem piorar o resultado. A decisão toma-se com o banco à frente, não com a intuição de quem fala mais alto.
- 4Montamos o processo de migração: candidato contra o banco, comparação lado a lado sobre o vosso trabalho real, lançamento gradual a uma parte do tráfego, comparação de saídas em direto e só depois a mudança completa. Com o regresso atrás preparado e ensaiado antes de começar, não improvisado no dia mau.
- 5Instalamos a deteção de desvio. Os fornecedores também atualizam sem mudar o nome da versão, e isso não dá erro: muda o formato, muda o comprimento, a aderência ao JSON afrouxa e a linha onde o modelo diz que não desloca-se. O banco corre periodicamente para que esse desvio seja apanhado por um alerta e não por um cliente.
- 6E deixamo-lo em calendário. As datas de retirada dos teus fornecedores entram como avisos com folga — não como um email que alguém arquivou — e a decisão de modelo passa a rever-se com uma cadência acordada, com o custo por tarefa e a qualidade medida em cima da mesa.
O que muda
O que deixas de perder
A Anthropic compromete-se a um pré-aviso mínimo de 60 dias para retirar modelos públicos e a OpenAI a um mínimo de seis meses para os modelos em disponibilidade geral. Esse pré-aviso só serve se alguém souber que sistemas vossos dependem da versão afetada: o inventário transforma uma data num plano.
Políticas públicas de descontinuação dos fornecedores (Anthropic, OpenAI), consultadas 2026-08
Mudar de modelo deixa de ser um salto de fé: o candidato mede-se contra os teus próprios casos, com o teu critério de correto, antes de tocar num único cliente.
Mecanismo
O desvio silencioso deixa de se descobrir por uma queixa. Quando o fornecedor atualiza por baixo, as saídas mudam sem dar erro — formato, comprimento, aderência ao JSON, onde recusa — e o banco periódico transforma isso num alerta.
Mecanismo
O custo baixa por desenho e não por corte: quando cada tarefa vai para o modelo de que precisa, a poupança vem de deixar de pagar critério onde só era preciso arrumar — não de usar pior IA.
Mecanismo
O que medimos: sistemas com versão de modelo inventariada, qualidade do candidato contra o banco de casos de ouro, desvios detetados pela execução periódica, custo por tarefa antes e depois do encaminhamento, tempo de regresso atrás ensaiado e dias de folga sobre cada data de retirada anunciada.
O que medimos
Ficha técnica
- Trabalho que elimina
- que a decisão de que modelo usa a tua empresa congele por medo e que cada retirada, atualização ou mudança de preço do fornecedor se resolva a correr, sem medir e com os clientes pelo meio
- Implementação habitual
- 4–8 semanas
- Entrada
- os teus sistemas de IA em produção, as versões de modelo que chamam hoje e casos reais da tua operação — incluindo os que correram mal
- Saída
- um inventário vivo do que depende de que versão, um banco de casos de ouro teu, encaminhamento por tarefa, um procedimento de migração com regresso atrás ensaiado e alertas de desvio e de datas de retirada
- Compatível com
- OpenAIAnthropicGoogle Vertex AIAzure OpenAIAmazon BedrockMistralLangSmithLangfuseBraintrust
- Pode ligar-se a
- Os teus registos de produção, de onde vêm os casos do bancoA tua camada de avaliação e a gestão de prompts, se já existiremO teu gateway ou encaminhador de modelos, para que mudar seja configuraçãoO teu painel de custos por modelo e por tarefaO teu processo de alterações e o calendário de piquete
- O que medimos
- % de sistemas com versão de modelo inventariada e responsável atribuídoqualidade do candidato contra o banco de casos de ourodesvios de comportamento detetados pela execução periódicacusto por tarefa antes e depois do encaminhamentotempo de regresso atrás ensaiado em simulacrodias de folga sobre cada data de retirada anunciada
- Adequado para
- empresas com IA já em produção e dependência real de um ou vários fornecedores de modelo — CIO, CTO ou responsável de IA — que precisam que a decisão de modelo seja revisível, mensurável e reversível em vez de um compromisso às cegas
- Não adequado para
- quem ainda está em piloto e não tem tráfego real — aí não há banco para construir, é preciso chegar primeiro a produção —, nem quem quer que lhe digamos qual é o melhor modelo do mercado: isso depende do teu trabalho, e é precisamente por isso que se mede em vez de se opinar
Perguntas frequentes
E continuamos a dizê-lo: mudar de modelo porque algo não rende é quase sempre mudar o problema de sítio, porque o estrangulamento costuma ser um processo mal definido ou dado sujo. Isto é o contrário daquilo. Aqui não se muda de modelo para arranjar nada: muda-se porque o fornecedor retira a versão que usas, porque a atualizou por baixo, porque saiu uma opção que faz o mesmo por uma fração do custo, ou porque a decisão que tomaste há ano e meio já não é a que tomarias hoje. São mudanças que vão acontecer quer queiras quer não. O que montamos é a capacidade de as absorver sem drama e com evidência — e, já agora, aquilo que te diz quando o modelo não é o problema, que é precisamente o caso em que convém não lhe tocar.
É um conjunto congelado de casos reais da tua operação com o resultado que tu consideras correto: os normais, os estranhos, os ambíguos e sobretudo os que na altura correram mal. Costumam bastar dezenas ou poucas centenas bem escolhidos, não são precisos milhares. É o que importa porque é a única coisa que transforma «este modelo parece melhor» num número comparável: passas o candidato pelo mesmo conjunto que o modelo atual e vês exatamente onde melhora e onde piora, no teu trabalho e não num exame genérico. E é a coisa mais valiosa que levas do projeto, porque não depende de nenhum fornecedor: serve igual para o ano com modelos que hoje não existem. Por isso o construímos contigo e fica em tua casa.
Porque medem outra coisa. Um benchmark público diz-te como se comporta um modelo num exame padronizado que não se parece nada com a tua operação: nem os teus documentos, nem o teu vocabulário, nem os teus casos-limite, nem a tua definição de correto. É informação útil para descartar candidatos claramente piores e para perceber por onde vai o mercado, e usamo-los para isso. Mas a decisão não a pode tomar um ranking: um modelo pode pontuar melhor em aberto e render pior numa tarefa concreta com documentos concretos, e o inverso também acontece. O fornecedor, ainda por cima, tem um interesse evidente na comparação. O teu banco de casos não tem.
Executando o banco periodicamente contra o mesmo endpoint e comparando com a linha de base. Esse é o único método fiável, porque uma atualização silenciosa não produz um erro: produz um desvio. O formato das chamadas a ferramentas muda um pouco, a aderência ao JSON afrouxa, as respostas alongam-se ou encurtam, e a fronteira do que o modelo recusa desloca-se. Nada disso parte a integração, por isso a monitorização clássica — disponibilidade, latência, taxa de erro — dá tudo verde enquanto a qualidade escorrega. Com a execução periódica do banco, esse desvio sai como um alerta com casos concretos à frente, e então a conversa é «isto mudou na terça e são estes os casos» em vez de «acho que ultimamente responde estranho».
Menos do que qualquer alternativa, e é fácil de comprovar: os entregáveis são teus e não dependem de nós. O inventário de versões, o banco de casos de ouro, as regras de encaminhamento, o procedimento de migração e o calendário de retiradas ficam documentados e nos teus sistemas. Montamos sobre o teu stack e sobre as ferramentas de avaliação que já tenhas; se não tens nenhuma, escolhemos convosco e explicamos porquê, sem camada proprietária de que depois haja que sair. A forma normal de acabar é a tua equipa operá-lo — isso é formar a equipa, que é um serviço diferente — ou operarmo-lo nós enquanto essa capacidade amadurece. As duas saídas estão escritas desde o início.
Montamos no teu negócio?
Localizaste o problema. Nós entregamos a solução e deixamo-la medida.