Criar apps corporativos ficou fácil. O Copilot Managed Runtime cuida da parte difícil.

A frase mais honesta dos anúncios da Microsoft em setembro nem era sobre IA. Estava no post que apresenta o Copilot Managed Runtime: “Código funcionando é só o primeiro passo.”

Em seguida, a Microsoft lista o que vem depois: provisionar e proteger recursos de nuvem, configurar identidade e segurança, respeitar as políticas da organização, estabelecer processos de implantação e operar o app durante todo o ciclo de vida. Quem já tentou levar um protótipo interno de IA para produção reconhece essa lista. É nela que a maioria trava.

O que a Microsoft anunciou

O Copilot Managed Runtime entrou em public preview em 25 de setembro. A Microsoft o descreve como uma plataforma corporativa para rodar código dentro dos limites do tenant do Microsoft 365, governada pela TI. Segundo a empresa, ele já sustenta os apps criados no Copilot Cowork, no Copilot Code e no Copilot Studio, e está sendo aberto a ferramentas de terceiros e a desenvolvedores profissionais por meio de um SDK e de uma CLI.

Os apps publicados no runtime podem usar, nos termos da Microsoft:

• Identidade e compartilhamento via Microsoft Entra.
• Ambientes de execução hospedados pela Microsoft.
• Políticas da organização para conectores, acesso a dados, endpoints aprovados e auditoria.
• Controles de implantação, versionamento e ciclo de vida, com controle de código via Git.
• Inventário central, monitoramento, visibilidade de uso e controle da TI no centro de administração do Microsoft 365.

O anúncio não traz preço, licenciamento nem disponibilidade por região. Para empresas no Brasil, isso precisa ser confirmado com o time de conta da Microsoft antes de qualquer planejamento.

O problema real: volume de apps, não qualidade

As empresas brasileiras já passaram por isso. Bancos de dados em Access, planilhas cheias de macros e, mais recentemente, apps de Power Apps seguiram o mesmo padrão: fáceis de criar, difíceis de encontrar, mais difíceis ainda de desativar. Quem montou um Centro de Excelência de Power Platform conhece bem o desafio. A IA barateia ainda mais a criação: a Microsoft agora descreve pequenos apps sob medida como uma nova unidade do trabalho, ao lado de documentos e planilhas.

Quando criar é quase de graça, o gargalo passa a ser operar. Todo app precisa de hospedagem, modelo de identidade, política de acesso a dados, trilha de auditoria e um dono. Se cada área tiver de montar essa base sozinha, duas coisas acontecem: a maioria dos apps úteis nunca chega a ser publicada, e os que chegam seguem cada um um modelo de governança diferente.

É esse o argumento a favor de um runtime gerenciado. A Microsoft chama de “separação entre construir livremente e operar de forma gerenciada”: cada pessoa constrói na ferramenta que faz sentido para ela, mas tudo roda sobre uma camada única e governada.

1. Criado no Copilot Cowork, Code, Studio ou em ferramentas de terceiros
2. Identidade Entra, políticas e versionamento
3. Centro de administração: inventário, uso e saúde
4. Dono do app: lógica, uso de dados e desativação

• Construção livre: Criado no Copilot Cowork, Code, Studio ou em ferramentas de terceiros
• Operação gerenciada (preview): Identidade Entra, políticas e versionamento · Centro de administração: inventário, uso e saúde
• Continua com o negócio: Dono do app: lógica, uso de dados e desativação

Padronizado pelo runtime gerenciadoDecisões que continuam com o negócio

O que um runtime não decide

Uma plataforma governada elimina uma classe grande de risco: apps sem autenticação, credenciais no código, conectores que ninguém aprovou, apps que ninguém sabe que existem. Mas não elimina as perguntas que são do negócio:

A lógica está certa? Um app pode estar perfeitamente hospedado e ainda calcular o número errado. Código gerado por IA precisa de revisão proporcional ao que o app decide.

O uso dos dados é adequado? Acesso governado significa que o app só alcança o que a política permite. Não significa que todo uso permitido seja uma boa ideia. Um conector aprovado para relatórios pode não ser adequado para um app que envia e-mails a clientes, e, quando há dados pessoais, a finalidade do uso precisa estar clara, como pede a LGPD.

Quem é o dono? Um inventário central mostra o que existe. Não torna ninguém responsável por um app quando quem o criou muda de área.

A IA dentro dele é boa o suficiente? Se o app chama um modelo, o comportamento continua precisando de avaliação e de uma forma de ser verificado depois de mudanças.

Quando ele é desativado? Versionamento torna a mudança segura. Desativar é uma decisão que alguém precisa tomar.

Para empresas padronizadas em Microsoft 365, Entra e Power Platform

Para organizações que já rodam sobre Microsoft 365 e Entra, o runtime permite um modelo operacional diferente: a TI governa como os apps rodam, e não quem pode construí-los. Isso só funciona com algumas regras claras:

1. Critérios de promoção. Quando um app pessoal vira compartilhado, e qual revisão isso dispara?
2. Dono obrigatório. Nenhum app compartilhado sem uma área de negócio responsável e uma data de revisão.
3. Políticas padrão que reflitam o risco. Revise as políticas padrão de conectores e endpoints antes de liberar o runtime em larga escala, e não depois.
4. Um caminho para a engenharia. A Microsoft destaca que desenvolvedores podem baixar o código e continuar evoluindo o app. Defina quando um app é importante o bastante para passar a um time que o mantenha.

Em resumo

O Copilot Managed Runtime mira a camada onde os apps internos de IA mais morrem: hospedagem, identidade, políticas e ciclo de vida. Padronizar essa camada é o movimento certo, e ele ainda está em preview. As decisões sobre dono, correção e uso adequado não vêm junto. Elas são a diferença entre ter uma plataforma governada e ter um portfólio governado.

Para ver como isso se encaixa no stack completo, leia o nosso guia de 2026.