distribuição do Microsoft Foundry em toda a minha organização

Um plano de distribuição estruturado ajuda você a evitar lacunas de segurança, sobrecargas de custos e expansão de acesso ao adotar Microsoft Foundry em escala. Este guia descreve as principais decisões para implantar o Foundry, incluindo configuração de ambiente, isolamento de dados, integração com outros serviços Azure, gerenciamento de capacidade e monitoramento. Use este guia como ponto de partida e adapte-o às suas necessidades. Para obter detalhes sobre a implementação, consulte os artigos vinculados.

Pré-requisitos

Antes de começar o planejamento de distribuição, confirme se você tem:

  • Uma estratégia de assinatura do Azure e de grupo de recursos para ambientes de desenvolvimento, teste e produção.
  • Microsoft Entra ID grupos (ou grupos de identidade equivalentes) definidos para administradores, gerentes de projeto e usuários do projeto.
  • Um plano de região inicial com base no modelo e na disponibilidade de funcionalidades. Para obter detalhes, consulte a disponibilidade de recursos entre regiões de nuvem.
  • Acordo sobre os requisitos de segurança para rede, criptografia e isolamento de dados em sua organização.

Lista de verificação para implementação da linha de base

Use esta lista antes da sua primeira implementação em produção:

  1. Defina limites de ambiente entre desenvolvimento, teste e produção.
  2. Atribua a propriedade para cada recurso do Foundry e escopo do projeto.
  3. Determine os recursos da Foundry que você planeja usar. Nem todas as APIs de recursos estão disponíveis no contexto do projeto. Se você planeja atribuir permissões no escopo mais baixo do projeto para isolamento de casos de uso, talvez não haja suporte para APIs clássicas de IA Azure, como o Tradutor. Isso exige que todos os usuários tenham permissões no nível de recurso do Foundry principal. Para esses casos, a segregação pelo recurso do Foundry é recomendada.
  4. Defina atribuições de RBAC para administradores, gerentes de projeto e usuários do projeto.
  5. Defina a abordagem de rede para cada ambiente (acesso público, ponto de extremidade privado ou híbrido).
  6. Decida se as chaves gerenciadas pelo cliente são exigidas pela política.
  7. Defina o custo e a responsabilidade de monitoramento para cada grupo empresarial.
  8. Identificar conexões compartilhadas necessárias e conexões com escopo de projeto.

Exemplo de organização

A Contoso é uma empresa global que explora a adoção do GenAI em cinco grupos de negócios, cada um com necessidades distintas e maturidade técnica.

Para acelerar a adoção e manter a supervisão, a Contoso Enterprise IT tem como objetivo habilitar um modelo com recursos compartilhados comuns, incluindo rede e gerenciamento centralizado de dados, ao mesmo tempo em que permite o acesso de autoatendimento ao Foundry para cada equipe em um ambiente seguro e controlado para gerenciar seus casos de uso.

Considerações sobre implementação

O recurso Foundry define o escopo para configurar, proteger e monitorar o ambiente de sua equipe. Ele está disponível no portal do Foundry e por meio de APIs de Azure. Projetos são como pastas para organizar seu trabalho nesse contexto de recurso. Os projetos também controlam o acesso e as permissões às APIs e ferramentas do desenvolvedor do Foundry.

Importante

Os projetos fornecem um ambiente de área restrita pré-configurado otimizado para criação de agente e recursos nativos do Foundry. No entanto, como o Foundry é baseado em uma série de Serviços de IA do Azure clássicos, nem todas as API clássicas estão disponíveis no contexto do projeto. Identifique os recursos que suas equipes planejam usar e verifique se eles dão suporte ao acesso no nível do projeto. Para serviços como tradução que exigem permissões no nível de recurso pai do Foundry, considere o uso de recursos separados do Foundry para isolamento de custos e controle de acesso.

Captura de tela de um diagrama mostrando o recurso Foundry.

Para garantir a consistência, a escalabilidade e a governança entre as equipes, considere as seguintes práticas de configuração de ambiente ao implantar o Foundry:

  • Estabeleça ambientes distintos para desenvolvimento, teste e produção. Use grupos de recursos ou assinaturas separados e recursos do Foundry para isolar fluxos de trabalho, gerenciar o acesso e dar suporte à experimentação com versões controladas.

  • Crie um recurso de Foundry separado para cada grupo de negócios. Alinhe as implantações com limites lógicos, como domínios de dados ou funções de negócios, para garantir a autonomia, a governança e o acompanhamento de custos. Considere também recursos do Foundry separados quando as equipes precisarem de APIs de IA clássicas de Azure que não dão suporte ao acesso no escopo do projeto.

  • Associe projetos a casos de uso. Os projetos Foundry representam casos de uso específicos e fornecem contêineres para organizar componentes como agentes ou arquivos para um aplicativo. Embora herdem as configurações de segurança de seu recurso pai, eles também podem implementar seus próprios controles de acesso, integração de dados e outros controles de governança. Antes de atribuir permissões no escopo do projeto, verifique se as APIs que sua equipe planeja usar dão suporte ao acesso no nível do projeto.

Protegendo o ambiente de Fundição

A foundry é criada na plataforma Azure, para que você possa personalizar os controles de segurança para atender às necessidades da sua organização.

Identidade

Use Microsoft Entra ID para gerenciar o acesso de usuário e serviço. A Foundry dá suporte a identidades gerenciadas para permitir a autenticação segura e sem senha para outros serviços de Azure. Você pode atribuir identidades gerenciadas no nível de recurso do Foundry e, opcionalmente, no nível do projeto para controle refinado. Para obter detalhes, consulte o controle de acesso baseado em função no Foundry.

Rede

Implante o Foundry em um Rede Virtual para isolar o tráfego e controlar o acesso usando NSGs (Grupos de Segurança de Rede). Para cenários de conectividade privada, use pontos de extremidade privados e valide o DNS e o status de aprovação do ponto de extremidade. Para obter detalhes e limitações de implementação, consulte Como configurar um link privado para o Foundry.

Importante

Alguns recursos, como agentes e avaliações, exigem configuração de rede adicional para isolamento de ponta a ponta. Para obter detalhes de implementação e limitações atuais, consulte Como configurar o isolamento de rede para o Foundry.

Chaves gerenciadas pelo cliente

Azure dá suporte a CMK (chaves gerenciadas pelo cliente) para criptografar dados em repouso. A Foundry dá suporte ao CMK opcionalmente para clientes com necessidades de conformidade estritas. Para obter detalhes, consulte chaves gerenciadas pelo cliente na Foundry.

Autenticação e autorização

A Foundry dá suporte ao acesso baseado em chave API para integração simples e Azure RBAC para controle refinado. As chaves de API podem simplificar a configuração, mas não fornecem a mesma granularidade baseada em função que Microsoft Entra ID com RBAC. Azure impõe uma separação clara entre o plano control (operações de gerenciamento de recursos, como criar ou configurar recursos) e o plano data (operações de runtime como modelos de chamada e acesso a dados). Comece com funções internas e defina funções personalizadas conforme necessário. Para obter detalhes, consulte o controle de acesso baseado em função no Foundry.

Modelos

Use modelos do ARM ou Bicep para automatizar implantações seguras. Explore os modelos de infraestrutura de exemplo.

Armazenamento

Você pode optar por usar recursos de armazenamento internos no Foundry ou usar seus próprios recursos de armazenamento. Para o Serviço de Agente, threads e mensagens podem ser armazenados opcionalmente em recursos gerenciados por você.

Exemplo: abordagem de segurança da Contoso

A Contoso protege suas implantações do Foundry usando a rede privada com a TI Corporativa gerenciando uma rede de hub central. Cada grupo de negócios se conecta por meio de uma rede virtual spoke. Eles usam o controle de acesso baseado em função (RBAC) integrado para separar o acesso:

  • Os administradores gerenciam implantações, conexões e recursos compartilhados
  • Project Managers supervisionam projetos específicos
  • Os usuários interagem com as ferramentas do GenAI

Para a maioria dos casos de uso, a Contoso depende da criptografia gerenciada pela Microsoft por padrão e não usa chaves gerenciadas pelo cliente.

Planejar o acesso do usuário

O gerenciamento de acesso efetivo é fundamental para uma configuração segura e escalonável do Foundry.

Definir funções e responsabilidades de acesso

Identifique quais grupos de usuários exigem acesso a vários aspectos do ambiente do Foundry. Atribua funções internas ou personalizadas do Azure RBAC com base em responsabilidades como:

  • Proprietário da conta: gerencie configurações de nível superior, como segurança e conexões de recursos compartilhados.
  • Gerentes de projeto: Criam e gerenciam Projetos Foundry e seus colaboradores.
  • Usuários do projeto: contribuam para projetos existentes.

Use este mapeamento inicial de função para escopo no planejamento de implementação:

Persona Função inicial Escopo recomendado
Administradores Proprietário ou dono da conta de IA do Azure Assinatura ou recurso do Foundry
Gerentes de Projeto Gerente de Projeto de IA do Azure Recurso do Foundry
Usuários do Project Usuário do Azure AI Projeto de fundimento

Ajuste as atribuições com base em requisitos de privilégio mínimo e políticas empresariais.

Determinar o escopo de acesso

Escolha o escopo apropriado para atribuições de acesso:

  • Nível de assinatura: acesso mais amplo, normalmente adequado para equipes centrais de TI ou plataforma ou organizações menores.
  • Nível do grupo de recursos: útil para agrupar recursos relacionados com políticas de acesso compartilhado. Por exemplo, uma Azure Function que segue o mesmo ciclo de vida da aplicação que seu ambiente Foundry.
  • Nível de projeto ou recurso: ideal para controle refinado, especialmente ao lidar com dados confidenciais ou habilitar o autoatendimento.

Alinhar estratégia de identidade

Para fontes de dados e ferramentas integradas ao Foundry, determine se os usuários devem se autenticar usando:

  • Identidades gerenciadas ou chave de API: adequado para serviços automatizados e acesso compartilhado entre usuários.
  • Identidades de usuário: preferencialmente quando a responsabilidade ou a auditoria no nível do usuário são necessárias.

Use Microsoft Entra ID grupos para simplificar o gerenciamento de acesso e garantir a consistência entre ambientes.

Para integração com privilégios mínimos, comece com a função Azure Usuário de IA para desenvolvedores e identidades gerenciadas por projeto e adicione funções elevadas somente quando necessário. Para obter detalhes, consulte o controle de acesso baseado em função no Foundry.

Estabelecer conectividade com outros serviços de Azure

A Foundry dá suporte a connections, que são configurações reutilizáveis que permitem o acesso aos componentes do aplicativo em serviços Azure e não Azure. Essas conexões também atuam como agentes de identidade, permitindo que o Foundry se autentique em sistemas externos usando identidades gerenciadas ou entidades de serviço em nome dos usuários do projeto.

Crie conexões no nível de recurso Foundry para serviços compartilhados como Armazenamento do Azure ou Key Vault. Conexões de escopo para um projeto específico para integrações confidenciais ou específicas do projeto. Essa flexibilidade permite que as equipes balanceiem a reutilização e o isolamento com base em suas necessidades. Saiba mais sobre conexões no Foundry.

Configure a autenticação de conexão para usar tokens de acesso compartilhado, como identidades gerenciadas do Microsoft Entra ID ou chaves de API, para gerenciamento simplificado e integração, ou tokens de usuário por meio do Entra ID passthrough, que oferecem maior controle ao acessar fontes de dados sensíveis.

Screenshot de um diagrama mostrando a conectividade e a integração do projeto foundry com outros serviços Azure.

Exemplo: a estratégia de conectividade da Contoso

  • A Contoso cria um recurso do Foundry para cada grupo de negócios, garantindo que projetos com dados semelhantes precisem compartilhar os mesmos recursos conectados.
  • Por padrão, os recursos conectados usam tokens de autenticação compartilhada e são compartilhados em todos os projetos.
  • Projetos que utilizam workloads de dados confidenciais se conectam a fontes de dados por meio de conexões com escopo de projeto e autenticação de passagem do Microsoft Entra ID.

Governança

A governança efetiva no Foundry garante operações seguras, compatíveis e econômicas entre grupos de negócios.

  • Model Controle de Acesso com Azure Policy Azure Policy impõe regras entre Azure recursos. No Foundry, use políticas para restringir quais modelos ou famílias de modelos grupos de negócios específicos podem acessar. Exemplo: o grupo Finance &Risk da Contoso é impedido de usar modelos de versão prévia ou não compatíveis aplicando uma política no nível de assinatura do grupo de negócios.
  • Gerenciamento de Custos por Grupo Empresarial Ao implantar o Foundry por grupo de negócios, a Contoso pode acompanhar e gerenciar custos de forma independente. Use a calculadora de preços Azure para estimativas de pré-implantação e Gerenciamento de Custos da Microsoft para uso real contínuo e acompanhamento de tendências. Trate os custos do Foundry como uma parte do custo total da solução.
  • Usage Tracking com Azure Monitor Azure Monitor fornece métricas e dashboards para acompanhar padrões de uso, desempenho e integridade dos recursos do Foundry.
  • O registro em log detalhado com o Azure Log Analytics do Azure Log Analytics permite uma inspeção profunda de logs para Insights Operacionais. Por exemplo, registro de solicitação, uso de token e latência para dar suporte à auditoria e à otimização.

Validar decisões de implementação

Depois de definir seu plano de distribuição, valide os seguintes resultados:

  • Identidade e acesso: as atribuições de funções correspondem a personas e escopos aprovados.
  • Rede: o caminho de conectividade e o modelo de isolamento são documentados para cada ambiente.
  • Verificação de rede: o status da conexão do ponto de extremidade é Aprovado e o DNS resolve os pontos de extremidade Foundry para endereços IP privados a partir do interior da rede virtual.
  • Proteção de dados: a abordagem de criptografia (chaves gerenciadas por Microsoft ou chaves gerenciadas pelo cliente) está documentada e aprovada.
  • Operações: os responsáveis por custos e monitoramento são atribuídos por grupo empresarial.
  • Verificação de operações: os painéis e exibições de custo são definidos em Gerenciamento de Custos da Microsoft e o monitoramento está conectado ao Application Insights para cada projeto de produção.
  • Operações de modelo: a estratégia de implantação (padrão ou provisionada) é documentada por caso de uso.
  • Preparação da região: os modelos e serviços necessários são confirmados em regiões de destino antes da distribuição.

Configurar e otimizar implantações de modelo

Ao implantar modelos no Foundry, as equipes podem escolher entre tipos de implantação padrão e provisionados. As implantações padrão são ideais para desenvolvimento e experimentação, oferecendo flexibilidade e facilidade de instalação. Implantações provisionadas são recomendadas para cenários de produção em que o desempenho previsível, o controle de custo e a fixação de versão do modelo são necessários.

Para dar suporte a cenários inter-regionais e permitir que você acesse implantações de modelo existentes, o Foundry permite conexões a implantações de modelo hospedadas em outras instâncias do Foundry ou Azure OpenAI. Usando conexões, as equipes podem centralizar implantações para experimentação e, ao mesmo tempo, habilitar o acesso de projetos distribuídos. Para workloads de produção, considere ter casos de uso gerenciando suas próprias implantações para garantir um controle mais rígido sobre o ciclo de vida do modelo, o controle de versão e as estratégias de reversão.

Para evitar o uso excessivo e garantir uma alocação justa de recursos, você pode aplicar limites de TPM (Tokens por Minuto) no nível de implantação. Os limites do TPM ajudam a controlar o consumo, proteger contra picos acidentais e alinhar o uso com orçamentos ou cotas de projeto. Considere a definição de limites conservadores para implantações compartilhadas e limites mais altos para serviços críticos de produção.

Saiba Mais

Próxima etapa