Microsoft Foundry e a escolha de modelos: como decidir entre GPT, Claude e Model Router sem cair no hype

Uma das perguntas mais comuns em projetos de inteligência artificial é também uma das mais perigosas:

“Qual é o melhor modelo?”

A pergunta parece técnica, mas quase sempre nasce errada. Porque, em produção, o melhor modelo não existe de forma absoluta. Existe o melhor modelo para uma tarefa, dentro de um custo aceitável, com uma latência viável, em uma região permitida, com governança adequada e com comportamento consistente o suficiente para o risco daquele processo.

Foi por isso que o movimento da Microsoft em novembro de 2025 foi tão importante. Com a chegada dos modelos Claude da Anthropic ao Microsoft Foundry, a Microsoft reforçou uma tese clara: o futuro da IA corporativa não será de um único modelo dominante para todos os cenários, mas de uma plataforma onde diferentes modelos podem ser escolhidos, combinados, governados e operados em um mesmo ambiente. No anúncio, a Microsoft posicionou o Foundry como uma plataforma capaz de oferecer GPT e Claude em um único lugar, com controles corporativos para construir e operar aplicações e agentes em escala.

Na prática, isso muda a conversa. O tema deixa de ser “qual modelo é mais inteligente?” e passa a ser “qual estratégia de modelos minha empresa precisa?”

A armadilha do modelo vencedor

O mercado adora ranking.

Modelo A vence benchmark.
Modelo B escreve melhor.
Modelo C programa melhor.
Modelo D é mais barato.
Modelo E tem mais contexto.
Modelo F é melhor para agentes.

Essas comparações ajudam, mas também criam um vício: tratar a escolha de modelo como campeonato.

Em ambiente corporativo, isso é raso.

Uma empresa não escolhe modelo apenas por performance bruta. Ela escolhe considerando tarefa, custo, governança, latência, segurança, região, compliance, disponibilidade, integração, qualidade da resposta, suporte operacional e previsibilidade.

Um modelo pode ser excelente para raciocínio complexo e ruim para tarefas simples de alta escala. Outro pode ser ótimo para custo e latência, mas insuficiente para análise profunda. Outro pode ser muito bom para código, mas desnecessário para classificação de tickets.

A decisão madura não é escolher o “campeão”. É criar uma matriz de decisão.

O que muda com Claude no Microsoft Foundry

A entrada dos modelos Claude no Microsoft Foundry aumenta a liberdade de escolha dentro do ecossistema Azure.

Segundo o anúncio da Microsoft, o Foundry passa a oferecer acesso a modelos Claude e GPT frontier em uma mesma plataforma, reforçando a proposta de permitir que desenvolvedores e empresas escolham a inteligência certa para cada desafio. A Microsoft também destaca casos como chatbots em tempo real, agentes de pesquisa, coding agents e workflows enterprise como exemplos onde a escolha de modelo passa a ser parte central da arquitetura.

Esse é o ponto que me interessa: escolha de modelo deixa de ser uma decisão isolada de desenvolvedor e passa a ser uma decisão de arquitetura.

Porque, se uma empresa vai ter dezenas de agentes e aplicações, ela não pode depender de uma escolha manual e emocional para cada caso. Ela precisa de critérios.

O erro de padronizar tudo em um único modelo

Padronizar tudo em um único modelo parece simples. E, em alguns momentos, simplicidade é boa.

Mas existe uma diferença entre padronização e preguiça arquitetural.

Se eu uso o mesmo modelo caro para classificar e-mails, resumir textos simples, fazer análise estratégica, gerar código e operar agentes, provavelmente estou desperdiçando dinheiro em algumas tarefas e assumindo risco em outras.

Um modelo frontier pode ser necessário para raciocínio complexo. Mas talvez seja exagero para extração simples. Um modelo menor pode ser suficiente para classificação. Um modelo com melhor capacidade de contexto pode ser ideal para análise documental. Um modelo com melhor desempenho em código pode fazer mais sentido para agentes de desenvolvimento.

O problema não é usar um modelo padrão. O problema é não saber quando sair dele.

O papel do Model Router

É aqui que o Model Router começa a ficar interessante.

A documentação do Microsoft Foundry Models mostra que, em novembro de 2025, a versão 2025-11-18 do Model Router adicionou suporte a modelos Anthropic como claude-haiku-4-5, claude-opus-4-1 e claude-sonnet-4-5, além de uma nova versão GA com suporte a modelos anteriores e novos modelos de linguagem. Também trouxe recursos como routing profiles, para otimizar escolhas por qualidade ou custo, e custom subsets, permitindo especificar quais modelos entram nas decisões de roteamento.

Isso muda bastante a arquitetura.

Em vez de a aplicação escolher sempre um modelo fixo, ela pode delegar parte da decisão ao roteamento de modelos, dentro de limites definidos pela própria empresa.

Mas atenção: Model Router não é desculpa para abrir mão da arquitetura. Ele precisa ser governado.

Quando usar modelo fixo

Eu usaria modelo fixo quando o comportamento precisa ser previsível e muito controlado.

Por exemplo:

Uma aplicação crítica que exige validação rígida.
Um fluxo regulado onde o modelo foi testado e aprovado.
Um agente que depende de características específicas de um modelo.
Um processo com saída padronizada e contrato bem definido.
Um cenário onde custo, latência e comportamento já foram calibrados.

Modelo fixo reduz variabilidade. E reduzir variabilidade pode ser essencial.

Em produção, nem sempre o melhor caminho é deixar o roteador escolher. Às vezes, o melhor caminho é saber exatamente qual modelo está sendo usado, por quê e com quais limites.

Quando usar Model Router

Eu usaria Model Router quando a empresa quer equilibrar qualidade, custo e flexibilidade em um conjunto de tarefas menos rígidas ou com variação natural.

Por exemplo:

Assistentes internos de conhecimento.
Resumo de documentos não críticos.
Classificação inicial de solicitações.
Geração de rascunhos.
Pesquisa exploratória.
Tarefas com diferentes níveis de complexidade.
Aplicações onde custo e latência precisam ser otimizados dinamicamente.

O valor do roteador está em evitar que tudo seja tratado como se exigisse o modelo mais caro ou mais poderoso.

Mas o roteador precisa ter limites. A documentação mostra justamente a importância dos custom subsets, porque eles permitem controlar quais modelos podem participar da decisão com base em custo, compliance e performance.

Para mim, esse é o ponto mais importante: roteamento sem subconjunto é liberdade demais. Roteamento com subconjunto é arquitetura.

Como eu criaria uma matriz de decisão de modelos

Antes de escolher GPT, Claude, open model ou Model Router, eu criaria uma matriz simples.

Critério 1: Tipo de tarefa
- classificação
- extração
- resumo
- raciocínio complexo
- código
- pesquisa
- agente multi-step
- resposta conversacional

Critério 2: Risco
- baixo
- médio
- alto

Critério 3: Necessidade de qualidade
- suficiente
- alta
- crítica

Critério 4: Custo permitido
- baixo
- médio
- alto

Critério 5: Latência esperada
- tempo real
- interativo
- assíncrono

Critério 6: Governança
- pode usar modelos roteados
- exige modelo fixo
- exige região específica
- exige aprovação de segurança

Critério 7: Observabilidade
- log básico
- tracing completo
- avaliação contínua

Essa matriz parece simples, mas muda a conversa com o negócio.

Em vez de o time dizer “vamos usar o melhor modelo”, ele começa a dizer: “para esta tarefa, este nível de risco e este custo, este conjunto de modelos faz mais sentido”.

Isso é maturidade.

Um exemplo prático: assistente corporativo

Imagine um assistente interno que ajuda colaboradores a responder dúvidas, resumir documentos e preparar rascunhos de e-mail.

Se todo pedido for para o modelo mais poderoso, o custo sobe sem necessidade. Se tudo for para o modelo mais barato, a qualidade cai em tarefas complexas.

Uma arquitetura melhor seria separar por tipo de tarefa.

Classificação de intenção:
Modelo menor ou roteador otimizado por custo.

Resumo simples:
Modelo rápido e barato.

Análise documental complexa:
Modelo de maior capacidade.

Geração de e-mail:
Modelo intermediário, com avaliação de tom e aderência.

Pergunta crítica sobre política interna:
Modelo fixo aprovado + fontes confiáveis + revisão humana se necessário.

Perceba que a decisão não é “GPT ou Claude”. A decisão é “qual capacidade eu preciso para cada etapa?”.

Essa é a virada.

Um exemplo prático: agente de código

Agora imagine um agente de desenvolvimento que ajuda a analisar repositórios, sugerir correções e gerar testes.

O anúncio da Microsoft destaca que modelos Claude podem ser usados em cenários como agentes de código, tarefas de longo horizonte, pesquisa, computer use e workflows complexos dentro do Foundry.

Isso não significa que Claude deve ser usado para tudo. Significa que, para certos tipos de tarefa, ele passa a ser uma alternativa relevante dentro da plataforma.

Um desenho possível:

Análise inicial do issue:
modelo rápido e barato.

Leitura de arquivos e entendimento de contexto:
modelo com bom contexto e raciocínio.

Geração de patch:
modelo forte em código.

Revisão final:
modelo diferente ou etapa de avaliação para reduzir viés.

Execução:
nunca automática em produção sem pipeline, teste e aprovação.

Aqui, a escolha de modelo faz parte de um workflow. Não é uma chamada isolada.

GPT, Claude ou open model?

A pergunta não é qual é melhor. A pergunta é qual resolve melhor o caso.

Eu pensaria assim:

GPT / Azure OpenAI
Bom candidato para cenários generalistas, agentes, aplicações corporativas, produtividade, raciocínio e integração ampla no ecossistema Microsoft.

Claude
Bom candidato para tarefas com forte raciocínio, análise extensa, código, pesquisa, workflows agentic e cenários em que comportamento de longo horizonte é importante.

Open models
Bons candidatos quando a empresa precisa de maior controle, otimização de custo, cenários específicos, customização, restrições de propriedade ou workloads menos dependentes de frontier intelligence.

Essa divisão não é absoluta. É um ponto de partida.

A escolha correta depende de teste.

Benchmark ajuda, mas não decide sozinho

Benchmark é útil. Mas benchmark não substitui avaliação com dados reais.

O modelo que vai bem em benchmark público pode não ser o melhor no seu domínio. Seu caso pode ter linguagem específica, documentos ruins, regras internas, perguntas ambíguas, dados incompletos e padrões que benchmark nenhum captura.

Por isso, antes de escolher modelo, eu criaria um conjunto de avaliação próprio.

Perguntas reais.
Documentos reais ou representativos.
Casos fáceis.
Casos difíceis.
Casos ambíguos.
Casos maliciosos.
Casos fora de escopo.
Saídas esperadas.
Critérios de avaliação.

Sem isso, a escolha de modelo vira opinião.

E opinião não sustenta produção.

Como testar modelos de forma prática

Eu montaria uma avaliação simples com cinco blocos:

1. Qualidade da resposta
A resposta está correta, completa e útil?

2. Aderência à instrução
O modelo respeitou formato, limite e tom?

3. Uso de contexto
Ele usou as fontes corretamente ou inventou?

4. Custo e latência
O resultado justifica o custo e o tempo?

5. Segurança e comportamento
Ele recusou o que deveria recusar? Lidou bem com incerteza?

Depois, testaria os modelos candidatos nas mesmas entradas.

O resultado pode mostrar que um modelo mais barato resolve 70% das tarefas, enquanto um modelo mais forte deve ser reservado para os 30% complexos.

Isso é arquitetura de custo.

Custom subsets: governança de verdade

Um dos recursos mais importantes do Model Router em novembro de 2025 foi o suporte a custom subsets, permitindo que a empresa especifique quais modelos entram nas decisões de roteamento.

Isso é governança aplicada.

Imagine que sua empresa decidiu que um determinado processo só pode usar modelos aprovados para uma região, custo ou política interna. Com subset, você não deixa o roteador escolher qualquer coisa. Você define o conjunto permitido.

Por exemplo:

Subset: suporte-interno
Modelos permitidos:
- modelo rápido para perguntas simples
- modelo intermediário para resumo
- modelo forte para casos complexos

Não permitido:
- modelos fora da região aprovada
- modelos sem aprovação de segurança
- modelos com custo acima do limite

Esse tipo de controle é essencial.

Roteamento inteligente sem governança pode virar surpresa.
Roteamento inteligente com subset vira plataforma.

Routing profiles: custo versus qualidade

Outro recurso citado na documentação são os routing profiles, que permitem inclinar as escolhas do roteador para qualidade ou custo, mantendo um nível base de performance.

Isso é muito útil porque nem toda aplicação tem a mesma prioridade.

Um assistente executivo pode priorizar qualidade.
Um classificador de alto volume pode priorizar custo.
Uma aplicação interativa pode priorizar latência.
Uma análise assíncrona pode tolerar mais tempo para obter melhor resultado.

O importante é transformar isso em política.

Não deve ser o desenvolvedor escolhendo no impulso. Deve ser uma decisão documentada:

Este workload prioriza custo porque processa alto volume e baixo risco.
Este workload prioriza qualidade porque apoia decisão estratégica.
Este workload usa modelo fixo porque exige previsibilidade.
Este workload usa router porque há variação de complexidade.

Quando a empresa documenta isso, o uso de IA deixa de ser artesanal.

O risco de custo invisível

Um dos grandes riscos em IA é custo invisível.

No começo, parece pouco. Um teste aqui, um agente ali, um resumo acolá. Depois, a empresa tem dezenas de fluxos consumindo modelos caros para tarefas simples.

O custo não explode de uma vez. Ele cresce escondido.

Por isso, estratégia de modelos precisa ser também estratégia de custo.

Eu criaria três faixas:

Baixo custo
Classificação, extração simples, triagem, reformulação de texto.

Custo médio
Resumo mais sofisticado, geração de conteúdo, perguntas com contexto.

Alto custo
Raciocínio complexo, análise profunda, código, pesquisa multi-etapa, agentes de longo horizonte.

Cada faixa teria modelos candidatos e limites.

Isso evita usar modelo de Fórmula 1 para entregar pizza na esquina.

O risco de compliance

Custo não é o único problema. Compliance também importa.

A documentação do Model Router deixa claro que custom subsets dão mais controle sobre custo, compliance e características de performance.

Esse ponto é crítico.

Algumas empresas podem ter restrições sobre região, tipo de deployment, provedor, retenção, dados sensíveis ou uso por área. Então a escolha de modelo precisa entrar em governança de dados.

Perguntas necessárias:

O dado pode sair para este tipo de modelo?
O modelo está disponível na região exigida?
O deployment atende à política interna?
A aplicação registra dados sensíveis?
O roteador pode escolher modelos fora do subset aprovado?
Existe auditoria do modelo usado por chamada?

Sem essas respostas, a empresa está assumindo risco sem perceber.

O que registrar em produção

Em uma aplicação com múltiplos modelos ou roteador, eu registraria pelo menos:

request_id
user_or_app_id
workload_name
task_type
selected_model
routing_profile
model_subset
latency_ms
input_tokens
output_tokens
estimated_cost
status
error
evaluation_score
timestamp

Isso permite responder perguntas importantes:

Qual modelo está sendo mais usado?
Qual modelo está mais caro?
Qual tarefa consome mais?
Qual rota tem mais erro?
Qual perfil entrega melhor qualidade?
Onde a latência está pior?
Onde podemos otimizar?

Sem esse tipo de telemetria, a empresa não tem estratégia de modelos. Tem consumo de API.

Uma estratégia madura de modelos

Eu montaria uma estratégia em quatro camadas.

Camada 1: modelo padrão
Um modelo principal para tarefas gerais e baixo risco.

Camada 2: modelos especializados
Modelos específicos para código, pesquisa, raciocínio, documentos longos ou multimodalidade.

Camada 3: roteamento
Model Router para workloads com variação de complexidade e necessidade de otimização dinâmica.

Camada 4: avaliação contínua
Medição real de qualidade, custo, latência e segurança.

Essa estrutura permite evoluir sem bagunça.

A empresa não fica presa a um único modelo. Mas também não vira um festival de escolhas aleatórias.

Quando não usar Model Router

Eu evitaria Model Router em cenários onde a previsibilidade do modelo é requisito central.

Por exemplo:

Processos regulados.
Saídas com contrato rígido.
Fluxos com validação formal por modelo específico.
Cenários onde uma pequena mudança de comportamento pode quebrar a aplicação.
Ambientes onde o compliance exige controle absoluto do modelo utilizado.

Nesses casos, modelo fixo pode ser melhor.

Roteamento é flexibilidade. Mas flexibilidade nem sempre é o objetivo.

Quando usar Claude dentro do Foundry

Eu olharia para Claude dentro do Foundry principalmente em cenários onde raciocínio longo, análise contextual, código e tarefas agentic complexas são relevantes.

O próprio anúncio da Microsoft destaca usos como long-running agents, coding, cybersecurity, financial analysis, computer use, research, advanced coding, long-horizon tasks e complex problem solving, variando por modelo Claude.

Mas a decisão precisa ser testada.

Não basta dizer “Claude é bom para isso”. O certo é pegar seus casos reais e medir.

Se o resultado for melhor, ótimo. Se o custo não compensar, use outro modelo. Se o comportamento não encaixar, ajuste.

Modelo não é religião. É ferramenta.

Quando usar GPT dentro do Foundry

Eu continuaria olhando para GPT/Azure OpenAI como uma base muito forte para aplicações generalistas, agentes empresariais e integração dentro do ecossistema Microsoft.

A vantagem aqui é maturidade, ecossistema, familiaridade, documentação, integração com Foundry e ampla adoção.

Mas, de novo, não existe resposta universal.

A empresa pode ter workloads em GPT, workloads em Claude, workloads em open models e workloads roteados. Isso não é falta de padrão. Pode ser uma estratégia madura, desde que bem governada.

O erro que eu evitaria

O erro seria transformar a chegada do Claude no Foundry em uma troca de torcida.

Antes era “vamos usar GPT para tudo”.
Depois vira “agora Claude é melhor para tudo”.
Amanhã será outro modelo.

Isso é imaturidade.

O ganho do Foundry é justamente permitir escolha dentro de uma plataforma governada. Então o foco não deve ser trocar dependência de um modelo por dependência de outro. O foco deve ser criar uma arquitetura de seleção, avaliação e operação de modelos.

Essa é a leitura correta.

O que eu faria em um projeto novo

Em um novo projeto de IA no Microsoft Foundry, eu começaria assim:

Definir casos de uso.
Classificar tarefas por risco e complexidade.
Escolher modelos candidatos.
Criar base de avaliação.
Testar qualidade, custo e latência.
Definir modelo fixo ou roteador por workload.
Configurar subsets aprovados.
Registrar modelo usado por chamada.
Reavaliar periodicamente.

Esse processo é mais importante do que a escolha inicial.

Porque modelos mudam. Plataforma muda. Custo muda. Casos de uso evoluem.

O que precisa permanecer é o método.

Minha leitura sobre novembro de 2025

Novembro de 2025 foi importante porque mostrou que o Microsoft Foundry estava deixando de ser apenas uma plataforma com bons modelos e passando a ser uma plataforma de estratégia de modelos.

A entrada de Claude no Foundry ampliou a liberdade de escolha. O Model Router avançou para uma versão GA com suporte a mais modelos, routing profiles, custom subsets e deployment types. Isso indica uma direção clara: empresas vão precisar operar múltiplos modelos com governança, e não apenas escolher um modelo preferido.

Para mim, esse é um dos temas mais importantes da IA corporativa.

A maturidade não está em saber o nome do modelo mais novo. Está em saber quando usar, quando não usar, como medir e como governar.

Conclusão

A chegada dos modelos Claude ao Microsoft Foundry e a evolução do Model Router mudam a conversa sobre IA no Azure.

A pergunta deixa de ser “qual é o melhor modelo?” e passa a ser “qual é a melhor estratégia de modelos para cada tarefa?”

Isso é uma diferença enorme.

Empresas maduras não vão depender de um único modelo para tudo. Também não vão deixar cada time escolher qualquer coisa sem critério. Elas vão criar uma camada de decisão: modelo fixo onde precisa de previsibilidade, roteador onde faz sentido otimizar, subsets onde há compliance, perfis onde há trade-off entre custo e qualidade, e avaliação contínua para não depender de achismo.

No fim, IA em produção não é campeonato de benchmark.

É engenharia de decisão.

E o Microsoft Foundry começa a ficar mais interessante justamente porque dá espaço para essa nova camada: uma plataforma onde diferentes modelos podem coexistir, ser governados e ser escolhidos com mais inteligência.

Modelo bom importa. Mas estratégia de modelos importa mais.

Referências técnicas usadas como base: anúncio oficial da Microsoft sobre Claude models no Microsoft Foundry e documentação do Microsoft Foundry Model Router, incluindo a versão 2025-11-18, modelos Anthropic, routing profiles, custom subsets e deployment types