Microsoft Foundry em GA: como migrar do clássico sem transformar IA em dívida técnica

Toda plataforma que cresce rápido passa por uma fase de reorganização.

No começo, o foco é dar velocidade. O produto precisa permitir teste, exploração, protótipo, adoção e experimentação. Depois, quando o uso amadurece, a conversa muda. A pergunta deixa de ser “como eu testo isso?” e passa a ser “como eu opero isso em produção, com governança, segurança, observabilidade e escala?”

Foi exatamente essa mudança que ficou clara com a disponibilidade geral do novo Microsoft Foundry portal em março de 2026.

A Microsoft posicionou a GA do novo Foundry como uma virada de uso piloto para uso corporativo em produção, com foco em construir, implantar e operar sistemas de IA em escala, trazendo governança, segurança e controles operacionais ao longo do ciclo de vida. A documentação deixa claro que a nova experiência organiza a jornada em Discover, Build e Operate, e que recursos como RBAC, audit logs, controles de compliance, monitoramento, alertas e integração com rede virtual fazem parte da proposta enterprise.

Para mim, esse momento não deve ser lido como “mudou a tela do portal”. Isso seria raso.

A leitura correta é: a Microsoft está consolidando o Foundry como plataforma operacional de IA.

E, quando uma plataforma muda de fase, a arquitetura também precisa mudar.

O problema da transição

Toda migração de plataforma tem um risco: o time achar que é só trocar de tela.

No caso do Foundry, esse risco é grande, porque a história da plataforma teve várias mudanças de nome e arquitetura. A própria documentação explica a evolução de Azure AI Studio → Azure AI Foundry → Microsoft Foundry, e também mostra a evolução do portfólio de serviços, de Azure Cognitive Services para Azure AI Services e depois para Foundry Tools. Apesar da evolução de nomes, o tipo de recurso Azure continua sendo Microsoft.CognitiveServices/accounts.

Essa informação é importante porque mostra duas coisas ao mesmo tempo.

Primeiro, existe continuidade técnica.
Segundo, existe mudança de modelo operacional.

E é exatamente aí que muita empresa erra.

Ela olha para o recurso antigo, vê que ainda funciona, e conclui que não precisa mexer em nada. Ou, no extremo oposto, tenta migrar tudo de uma vez sem entender o que ainda depende do clássico.

Os dois caminhos são ruins.

GA não significa que tudo do clássico desapareceu

A disponibilidade geral do novo portal não quer dizer que todo recurso antigo foi absorvido com paridade total.

A documentação é clara ao dizer que existe um escopo definido para a GA dos Foundry projects, enquanto capacidades fora do escopo continuam no Foundry classic. Também mostra que alguns itens são novos ou aprimorados no portal atual, enquanto outros ainda exigem classic ou migração específica.

Esse ponto precisa ser entendido antes de qualquer plano de migração.

A pergunta correta não é: “posso abandonar o clássico hoje?”

A pergunta correta é: “quais workloads já fazem sentido no novo portal, quais ainda dependem do clássico e quais precisam de migração planejada?”

Esse inventário separa arquitetura de ansiedade.

O que mudou na navegação

O clássico usava uma navegação mais concentrada em um painel lateral. O novo portal separa a experiência em áreas mais claras.

Home para visão do projeto e ações rápidas.
Discover para catálogo de modelos e benchmarks.
Build para modelos, agentes, playgrounds, avaliações e fine-tuning.
Operate para administração, quota, compliance, tracing e saúde operacional.
Docs para documentação.

Essa mudança pode parecer visual, mas não é só visual.

Ela revela a nova mentalidade da plataforma.

Discover é sobre escolher e entender capacidades.
Build é sobre construir aplicações, agentes e experiências.
Operate é sobre governar, monitorar e administrar.

Essa divisão é muito mais alinhada com produção do que uma experiência voltada apenas para experimentação.

Para um time de tecnologia, isso importa porque ajuda a separar responsabilidades.

Quem explora modelos não é necessariamente quem opera quota.
Quem constrói agente não é necessariamente quem aprova compliance.
Quem faz avaliação não é necessariamente quem gerencia permissões.

A plataforma começa a refletir uma organização mais madura de times.

O que eu avaliaria antes de migrar

Antes de qualquer migração, eu faria um diagnóstico simples.

1. Quais projetos existem hoje?
2. Eles são Foundry projects ou hub-based projects?
3. Quais agentes estão em uso?
4. Quais APIs esses agentes usam?
5. Existe dependência de Assistants API?
6. Existe dependência de SDK antigo?
7. Quais modelos estão em produção?
8. Quais ferramentas estão conectadas?
9. Quais integrações usam API key?
10. Quais workloads dependem de preview?
11. Quais recursos são classic-only?
12. Quais projetos têm impacto em cliente ou operação?

Sem esse inventário, migração vira chute.

A documentação de migração reforça justamente a necessidade de revisar mudanças de terminologia, comparar funcionalidades, atualizar SDKs, migrar agentes para Responses API e validar se a região do recurso Foundry suporta Responses API e Agent Service.

Isso é arquitetura básica: antes de mover, entenda o que existe.

Hub-based projects: o ponto que pode confundir

Um dos pontos mais importantes é a diferença entre projetos hub-based e Foundry projects.

A documentação de migração de hub-based para Foundry projects explica que o Microsoft Foundry está em transição para uma plataforma unificada como serviço, substituindo o modelo anterior que exigia gerenciar múltiplos serviços Azure. Os novos Foundry projects simplificam setup, governança e workflows que cruzam modelos, agentes, ferramentas, observabilidade, segurança e trust.

Mas existe um detalhe: hub-based projects não aparecem da mesma forma no portal atual. A documentação do novo portal indica que projetos hub-based são classic-only e exigem alternar para o classic ou migrar para Foundry projects.

Esse é um ponto crítico.

Se sua empresa tem projetos hub-based, você não deve simplesmente abrir o novo portal e assumir que tudo sumiu ou que tudo foi migrado automaticamente. É preciso identificar o tipo de projeto e decidir se ele deve continuar temporariamente no clássico ou ser migrado.

Responses API: a migração que não dá para ignorar

Outro ponto central é a transição para Responses API.

A documentação de navegação do clássico para o atual mostra que o protocolo antigo da Assistants API passa a ser substituído pela Responses API. Também registra uma data importante: 26 de agosto de 2026 como sunset da Assistants API, recomendando o uso do Microsoft Foundry Agents Service em GA e a migração dos workloads.

Isso muda a prioridade.

Se sua empresa tem agentes antigos baseados em Assistants API, isso não é apenas uma melhoria opcional. É uma dívida com data.

O time precisa planejar migração antes que a urgência vire incidente.

Eu trataria isso como projeto formal:

Inventário de agentes usando Assistants API
Mapeamento de funcionalidades usadas
Reescrita para Responses API
Validação de região
Teste de comportamento
Teste de regressão
Observabilidade
Deploy controlado
Desativação do fluxo antigo

A pior coisa é esperar o prazo chegar para descobrir que o agente crítico ainda depende de API que vai sair.

SDKs: dívida técnica silenciosa

Outro ponto que passa despercebido é SDK.

A documentação informa que o pacote azure-ai-inference tem aposentadoria prevista para 30 de maio de 2026, recomendando migração para o pacote openai. Também aponta requisitos de SDK, como Python 3.9+ ou .NET 8+ com azure-ai-projects 2.x e pacote openai.

Isso é importante porque muita aplicação de IA começa como script.

Um script vira ferramenta interna.
A ferramenta interna vira processo.
O processo vira dependência.
A dependência fica em SDK antigo.
Ninguém lembra até quebrar.

Por isso, migração de Foundry não é só portal. É também dependência de código.

Se eu estivesse revisando um ambiente real, eu pediria ao time para procurar:

azure-ai-inference
azure-ai-projects em versões antigas
Assistants API
api-version datado em chamadas críticas
clientes customizados sem padrão
scripts locais que viraram produção

Isso evita que a empresa modernize a interface e mantenha o código antigo por baixo.

RBAC e API keys

Outro ponto importante da GA é o modelo de acesso.

A documentação de GA orienta que, para workloads sensíveis à governança, a recomendação é usar Microsoft Entra ID com RBAC, porque API key não oferece a mesma granularidade de permissões baseada em função. API keys ainda existem em parte da experiência, mas não devem ser o padrão para tudo em produção.

Esse ponto é essencial.

Muita empresa começa com API key porque é mais rápido. O problema é quando a mesma lógica vai para produção. Chave compartilhada facilita o começo, mas complica rastreabilidade, rotação, permissão mínima e governança.

Minha regra seria simples:

API key pode existir em laboratório.
Produção deve preferir Entra ID e RBAC.
Ambientes críticos devem ter identidade, função e escopo bem definidos.

Em IA, identidade importa tanto quanto modelo.

Como eu organizaria ambientes

Para uma empresa usando Foundry em produção, eu separaria ambientes claramente.

Sandbox
- exploração
- preview features permitidas
- dados fictícios ou mascarados
- baixa criticidade

Development
- desenvolvimento de agentes e apps
- integração inicial
- testes controlados

Staging
- testes com comportamento próximo de produção
- avaliações
- validação de segurança
- revisão de custo

Production
- apenas recursos aprovados
- GA sempre que possível
- RBAC
- observabilidade
- governança
- preview bloqueado salvo exceção formal

A documentação de GA recomenda que organizações definam política para uso apenas de capacidades GA em produção e também políticas para restringir acesso a preview em ambientes produtivos.

Esse é um detalhe que muita empresa ignora.

Preview é ótimo para inovação. Mas preview em produção sem critério é risco mascarado de velocidade.

Como decidir o que migra primeiro

Eu não migraria tudo de uma vez.

Começaria com workloads de baixo risco e alto aprendizado.

Primeiro:
- projetos de laboratório
- agentes internos simples
- aplicações sem impacto em cliente
- workloads sem dependência classic-only

Depois:
- agentes com ferramentas
- aplicações internas relevantes
- integrações com dados corporativos

Por último:
- workloads críticos
- agentes com ação operacional
- fluxos com cliente final
- processos regulados

Esse caminho reduz risco.

A migração precisa gerar aprendizado antes de tocar o que é crítico.

Um plano de migração prático

Eu organizaria em seis etapas.

1. Inventário

Mapear projetos, agentes, modelos, integrações, SDKs, APIs, regiões e dependências.

2. Classificação

Separar em: pronto para novo Foundry, dependente do clássico, precisa de migração técnica, precisa de redesign.

3. Padronização

Definir RBAC, ambientes, naming convention, padrão de SDK, política de preview e padrão de observabilidade.

4. Migração piloto

Escolher um projeto simples e migrar de ponta a ponta.

5. Validação

Testar comportamento, latência, custo, permissões, tracing, avaliações e fallback.

6. Escala

Criar playbook e repetir para outros projetos.

A parte mais importante é a validação. Migrar e não testar comportamento é irresponsável.

Migração de agente não é copiar configuração

Quando falamos de agentes, migração exige mais cuidado.

Um agente não é apenas uma configuração. Ele tem comportamento.

Mesmo que instruções, ferramentas e modelos pareçam equivalentes, a mudança de API, SDK, runtime ou fluxo pode alterar respostas.

Por isso, antes de migrar um agente, eu criaria uma base de testes.

Perguntas frequentes
Perguntas difíceis
Perguntas ambíguas
Tentativas de prompt injection
Solicitações fora de escopo
Chamadas de ferramenta
Erros simulados
Casos que exigem humano
Casos com dados sensíveis

Depois compararia antes e depois.

A pergunta não é só “funcionou?”.
A pergunta é “continua se comportando como deveria?”.

O novo portal e a disciplina de operação

A seção Operate do novo portal é uma das partes mais importantes da mudança.

A documentação mostra que tarefas antes espalhadas pelo Management Center e navegação clássica agora ficam em Operate: quota, admin, compliance, tracing, guardrails, controles e recursos conectados.

Isso reforça uma ideia: IA precisa ser operada.

Não basta criar agente.
Não basta escolher modelo.
Não basta publicar endpoint.

É preciso ver quota, custo, compliance, tracing, health, permissões, uso e comportamento.

Sem operação, IA vira uma caixa-preta com orçamento.

O que eu colocaria em um checklist de produção

Antes de chamar um workload de IA de “produção” no novo Microsoft Foundry, eu exigiria:

Foundry project definido
Ambiente correto
Modelo aprovado
Região validada
RBAC configurado
Preview policy definida
API key evitada ou justificada
SDK atualizado
Responses API quando aplicável
Tracing habilitado
Avaliações mínimas criadas
Ferramentas revisadas
Dados classificados
Fallback definido
Human-in-the-loop para risco alto
Owner técnico definido
Owner de negócio definido
Plano de rollback

Isso pode parecer rigoroso, mas é o mínimo para não transformar IA em dívida técnica.

O que eu não faria

Eu não faria migração no impulso.

Não migraria workload crítico sem teste.
Não colocaria preview em produção sem política.
Não manteria API key compartilhada por conveniência.
Não ignoraria Assistants API sunset.
Não deixaria hub-based project sem plano.
Não assumiria que feature do clássico existe igual no novo portal.
Não misturaria sandbox e produção no mesmo projeto.
Não deixaria SDK antigo escondido em script.

A maior parte dos problemas de migração não vem da tecnologia. Vem da falta de inventário.

O papel do arquiteto nessa transição

O arquiteto precisa traduzir a mudança de plataforma em plano de adoção.

Não é só mandar o time “usar o novo Foundry”.

É definir:

quais padrões serão adotados;
quais recursos estão liberados;
quais recursos ficam em sandbox;
como será migração de agentes;
como serão tratados SDKs antigos;
como será observabilidade;
como será governança de modelo;
como será gestão de acesso;
como será a política de preview;
como será a documentação interna.

Sem isso, cada time cria sua própria versão do Foundry.

E quando cada time cria seu próprio padrão, a empresa não tem plataforma. Tem ilhas.

O papel do desenvolvedor

O desenvolvedor precisa olhar para essa transição como oportunidade de limpar a base.

Atualizar SDKs.
Remover dependência de api-version datado quando possível.
Migrar para Responses API.
Padronizar autenticação.
Criar abstrações internas.
Adicionar logs.
Melhorar testes.
Evitar código descartável em produção.

A GA do portal novo é um bom momento para parar e perguntar:

“Esse código que nasceu como POC deveria continuar assim?”

Na maioria das vezes, a resposta é não.

O papel do gestor

Para liderança, a mensagem é outra: IA está entrando em fase de operação.

Isso significa orçamento, governança, papéis e responsabilidade.

Quem aprova modelos?
Quem aprova uso de preview?
Quem responde por incidentes?
Quem mede custo?
Quem revisa dados?
Quem decide quando um agente pode agir?
Quem acompanha métricas?

IA corporativa não pode ser apenas iniciativa de inovação. Precisa virar capacidade operacional.

E o novo Foundry em GA sinaliza exatamente essa maturidade.

Um exemplo aplicado

Imagine uma empresa que criou três agentes no clássico:

Um agente interno de suporte técnico.
Um agente de FAQ comercial.
Um agente de análise de documentos.

O caminho ruim seria migrar os três de uma vez.

O caminho melhor:

Suporte técnico
Baixo risco, interno, ótimo candidato para piloto.

FAQ comercial
Médio risco, precisa validar fontes e respostas oficiais.

Análise de documentos
Risco maior se envolve dados sensíveis; migrar depois de revisar segurança, RBAC, região e logs.

Cada workload tem um plano.

Migração madura não é por ordem de vontade. É por ordem de risco.

Minha leitura sobre março de 2026

Março de 2026 foi um marco porque o Microsoft Foundry deixou mais claro seu papel como plataforma enterprise de IA.

A GA do novo portal reforça produção, governança, segurança e ciclo de vida. A documentação de migração mostra a reorganização de terminologia, navegação, SDKs, APIs e projetos. A transição de Assistants API para Responses API e o sunset já anunciado criam uma direção objetiva para workloads de agentes.

Minha leitura é simples: acabou a fase em que IA podia viver apenas como experimento isolado.

Agora, quem quer usar Foundry de verdade precisa pensar como plataforma.

Conclusão

A disponibilidade geral do novo Microsoft Foundry portal não é apenas uma mudança visual.

Ela representa uma mudança de fase: de exploração para operação, de playground para plataforma, de demo para produção.

Mas essa transição só gera valor se for feita com método.

Antes de migrar, inventarie.
Antes de modernizar, entenda dependências.
Antes de publicar, configure governança.
Antes de escalar, observe.
Antes de confiar, avalie.

O novo Foundry oferece uma base mais madura para criar, operar e governar aplicações e agentes de IA. Mas base madura não compensa arquitetura imatura.

No fim, a pergunta não é “já posso usar o novo portal?”

A pergunta correta é: “minha organização está pronta para tratar IA como plataforma operacional?”

Porque é isso que a GA do Microsoft Foundry representa.

Não é só uma nova experiência.
É um convite para sair do improviso.

E, em IA corporativa, sair do improviso é a diferença entre inovação sustentável e dívida técnica com interface bonita.