Plataforma de evals e endpoint MCP desligam em 30 de novembro. Sua suíte precisa sobreviver a cada fornecedor
OpenAI Evals, um modelo do Copilot Studio e um endpoint MCP do Databricks se aposentam em seis semanas. Aposentadorias são rotina. Perder o instrumento que as verifica, não.
Ouça este artigo · 5 min
Narração completa do artigo, gerada por IA.
Aqui está um calendário de seis semanas para um ambiente de Enterprise AI bastante comum.
Seis semanas de datas de ciclo de vida de fornecedores
15 de outubro30 de novembro
- 15 outCopilot Studio aposenta GPT-5.3 Chat e GPT-5.4 Reasoning, prorrogação de até 30 dias
- 31 outCopilot Studio aposenta GPT-5.5 Chat, sem prorrogação; OpenAI Evals passam a ser somente leitura
- 12 novCopilot Studio aposenta GPT-4.1, GPT-4.1 Mini, GPT-5 Chat e GPT-5 Auto
- 30 novdashboard e API do OpenAI Evals desligam; o endpoint beta do Genie One MCP do Databricks termina
Nada disso é uma crise. A Microsoft indica um substituto para cada modelo do Copilot Studio que está sendo aposentado, o GPT Chat Latest, um default que acompanha os snapshots de chat suportados. A Databricks mudou o prazo do endpoint beta do Genie One MCP de 31 de outubro para 30 de novembro e aponta para um substituto em disponibilidade geral (GA) no Unity Gateway. A OpenAI anunciou o fim da plataforma Evals em 3 de junho e publicou um caminho de migração para o Promptfoo. Os fornecedores estão fazendo o que devem: avisando com antecedência.
O que merece atenção é uma linha desse calendário, porque ela é diferente em natureza.
O instrumento também se aposenta
Uma aposentadoria de modelo muda aquilo que você está testando. Uma aposentadoria de endpoint muda como se chega até a coisa. Uma aposentadoria de plataforma de avaliação remove o instrumento que você usa para saber se qualquer uma das outras duas mudanças quebrou alguma coisa.
Pense em um time que construiu sua suíte de regressão no OpenAI Evals: datasets de casos reais, graders que pontuam respostas, thresholds que liberam ou barram um release. Desde 31 de outubro, esses evals são somente leitura. Depois de 30 de novembro, o dashboard e a API têm parada programada. Se esse mesmo time também opera um agente no Copilot Studio cujo modelo GPT-5.5 Chat foi substituído em 31 de outubro sem prorrogação, ele teve que validar uma troca forçada de modelo nas mesmas semanas em que estava perdendo a ferramenta com que valida. A OpenAI observa que os graders documentados para workflows de eval fazem parte da transição.
Defendemos desde setembro que a avaliação é a superfície de controle dos sistemas de IA, e em outubro que aposentadorias de modelos pertencem ao calendário de mudanças. Este calendário acrescenta um refinamento: a suíte de avaliação é ela mesma uma dependência, e é a que menos pode se dar ao luxo de ser alugada.
O que “ter a suíte de evals” significa na prática
Ter não significa construir sua própria plataforma de avaliação. Significa que os ativos sobrevivem a qualquer plataforma.
Datasets em um formato neutro. Casos de teste, resultados esperados e a procedência de cada caso (de onde veio, quem aprovou) ficam no seu repositório ou na sua plataforma de dados, como arquivos ou tabelas, não apenas dentro do dashboard de um fornecedor.
Graders como código ou como rubricas escritas. Um grader é a definição de “correto”. Mantenha-o como código que você consegue rodar em qualquer lugar, ou como uma rubrica precisa o bastante para ser reconstruída. Um juiz LLM também precisa do seu modelo e do seu prompt versionados, já que um juiz em um snapshot que está sendo aposentado também vai deslocar as notas.
Thresholds e histórico. A taxa de aprovação que liberou o último release, e os resultados por trás dela, são a linha de base do próximo. Perder o histórico significa que toda comparação começa do zero.
Um segundo runner. Conseguir rodar a mesma suíte em duas ferramentas, mesmo ocasionalmente, é o teste de que a suíte é portátil. Uma migração forçada por um prazo é o pior momento para descobrir o que vivia só na ferramenta antiga.
O ponto mais amplo
A IA em produção depende de peças que mudam no calendário dos outros: snapshots de modelos, defaults do harness, conectores, endpoints de protocolo e serviços de avaliação. Isso é normal, e a resposta não é evitar fornecedores. É saber quais peças são intercambiáveis e quais carregam o julgamento da organização.
Os modelos são cada vez mais intercambiáveis. A definição do que é uma boa resposta não é. Foram especialistas de negócio que a escreveram, ela codifica o que o negócio aceita, e é o que permite trocar todo o resto com segurança. Ela pertence à lista curta de coisas que uma empresa deve manter depois de qualquer handoff de fornecedor, ao lado da identidade e das definições de negócio.
Se 30 de novembro está no seu calendário por causa de uma migração, use a data para mais uma tarefa: verifique se cada ativo de avaliação do qual você depende existe em algum lugar que você controla, e se você consegue rodá-lo sem o fornecedor que está indo embora.