Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Exibição no momento:Versão do portal Foundry (clássico) - Alternar para a versão do novo portal Foundry
Nota
Os links neste artigo podem abrir conteúdo na nova documentação do Microsoft Foundry em vez da documentação do Foundry (clássico) que você está exibindo agora.
O Microsoft Foundry organiza as cargas de trabalho de IA por meio de uma arquitetura em camadas: um recurso Foundry de nível superior para governança, projetos para isolamento de desenvolvimento e serviços conectados do Azure para armazenamento, pesquisa e gestão de segredos.
Este artigo fornece às equipes de segurança e operações de TI detalhes sobre o recurso foundry e a arquitetura de serviço subjacente do Azure, seus componentes e sua relação com outros tipos de recursos do Azure. Use essas informações para orientar como personalizar sua implantação do Foundry de acordo com os requisitos da sua organização. Para obter mais informações sobre como distribuir o Foundry em sua organização, consulte o Lançamento do Foundry.
Quando usar essa arquitetura
Considere o modelo de recurso do Foundry quando o cenário envolver:
- Configuração inicial: você está iniciando um novo projeto de IA e deseja um único recurso que agrupe o acesso ao modelo, a hospedagem do agente e as ferramentas de avaliação.
- Acesso de várias equipes: várias equipes precisam de projetos isolados com implantações de modelo compartilhado e governança centralizada.
- Design controlado por conformidade: sua organização requer rede privada, criptografia gerenciada pelo cliente ou escopo do RBAC do Azure nos níveis de recursos e projetos.
- Migração do Azure OpenAI: você está migrando de um recurso autônomo do Azure OpenAI e deseja manter as políticas existentes e o RBAC ao adicionar recursos de agente e avaliação.
Para exploração de desenvolvedor único, um recurso foundry com um projeto é o padrão recomendado. Se sua carga de trabalho exigir apenas conclusões do Azure OpenAI sem a hospedagem ou avaliação do agente, um recurso autônomo do Azure OpenAI poderá ser suficiente.
Tipos e provedores de recursos de IA do Azure
Na família de produtos de IA do Azure, você pode usar esses provedores de recursos do Azure que dão suporte às necessidades do usuário em diferentes camadas na pilha.
| Provedor de recursos | Propósito | Serviços com suporte |
|---|---|---|
| Microsoft.CognitiveServices | Dá suporte ao desenvolvimento de aplicativos Agentic e GenAI compondo e personalizando modelos predefinidos. | Foundry; OpenAI do Azure; Fala do Azure no Foundry Tools; Linguagem do Azure no Foundry Tools; Visão do Azure no Foundry Tools |
| Microsoft.Search | Dá suporte à recuperação de conhecimento sobre seus dados | Pesquisa de IA do Azure |
Para a maioria dos cenários de desenvolvimento de IA, incluindo criação de agente, implantação de modelo e fluxos de trabalho de avaliação, o recurso Foundry é o ponto de partida recomendado. Os recursos de fundação compartilham o namespace do provedor Microsoft.CognitiveServices com serviços como Azure OpenAI, Fala, Visão e Linguagem. Esse namespace de provedor compartilhado ajuda a alinhar APIs de gerenciamento, padrões de controle de acesso, rede e comportamento de política entre os recursos de IA relacionados.
Use a tabela a seguir para identificar qual tipo de recurso corresponde à carga de trabalho. O texto mostra os tipos de recursos e as capacidades específicas no provedor Microsoft.CognitiveServices:
| Tipo de recurso | Tipo e provedor de recursos | Variante | Capacidades com suporte |
|---|---|---|---|
| Microsoft Foundry | Microsoft.CognitiveServices/accounts |
AIServices |
Agentes, Avaliações, Azure OpenAI, Fala, Visão, Linguagem e Compreensão de Conteúdo |
| Projeto de fundimento | Microsoft.CognitiveServices/accounts/projects |
AIServices |
Sub-recurso do item acima |
| Azure Speech nas Ferramentas de Foundry | Microsoft.CognitiveServices/accounts |
Speech |
Fala |
| Linguagem do Azure nas Ferramentas Foundry | Microsoft.CognitiveServices/accounts |
Language |
Linguagem |
| Azure Vision nas Ferramentas de Fundição | Microsoft.CognitiveServices/accounts |
Vision |
Visão |
Os tipos de recursos nos mesmos namespaces de provedor compartilham as mesmas APIs de gerenciamento e usam ações, configurações de rede e aliases semelhantes do controle de acesso baseado em função do Azure (Azure RBAC) para a configuração do Azure Policy. Se você estiver atualizando do Azure OpenAI para o Foundry, as políticas personalizadas do Azure e as ações do RBAC do Azure existentes continuarão a ser aplicadas.
Hierarquia de recursos de fundição
O diagrama a seguir mostra um recurso foundry com implantações de modelo, configurações de segurança, conexões e dois projetos. Serviços conectados do Azure, como Armazenamento, Key Vault e Pesquisa de IA do Azure , são recursos separados do Azure sob seus próprios limites de governança:
Importante
Recursos conectados como Armazenamento, Key Vault e Pesquisa de IA do Azure são recursos independentes do Azure com seus próprios limites de governança. Você gerencia as configurações de rede, políticas de acesso e conformidade para esses recursos separadamente do recurso Foundry.
Use esse modelo ao planejar a arquitetura e os limites de acesso:
- Recurso do Foundry: recurso de nível superior do Azure onde você gerencia configurações de governança, como rede, segurança e implantações de modelos.
- Projeto: limite de desenvolvimento dentro do recurso Foundry em que as equipes criam e avaliam casos de uso. Os projetos permitem que as equipes façam protótipos em um ambiente pré-configurado, reutilizando implantações e conexões de modelo existentes sem a configuração de TI repetida.
- Ativos do projeto: arquivos, agentes, avaliações e artefatos relacionados no escopo de um projeto.
- Recursos conectados: serviços do Azure como Armazenamento, Key Vault e Pesquisa de IA do Azure que o recurso Foundry faz referência por meio de conexões. Esses recursos têm limites de governança separados, portanto, você gerencia suas políticas de rede e acesso de forma independente.
Essa separação permite que as equipes de TI apliquem controles centralizados no nível do recurso enquanto as equipes de desenvolvimento trabalham dentro dos limites do nível do projeto.
Nota
A maioria das novas APIs está disponível no escopo do projeto. No entanto, alguns recursos originalmente suportados no nível da conta por meio dos serviços Azure OpenAI, de Fala, de Visão e de Linguagem estão disponíveis apenas no nível do recurso Foundry, não no âmbito do projeto. Por exemplo, a API de Tradutor está disponível apenas no nível de recurso do Foundry. Planeje sua estrutura de implantação com base em quais escopos de API suas cargas de trabalho exigem.
Separação de responsabilidades impulsionada pela segurança
A Foundry impõe uma separação clara entre operações de gerenciamento e desenvolvimento para garantir cargas de trabalho de IA seguras e escalonáveis.
Governança de recursos de nível superior
Os recursos Foundry de nível hierárquico superior abrangem operações de gestão, como configurar a segurança, estabelecer a conectividade com outros serviços do Azure e administrar implantações. Os contêineres de projeto dedicados isolam as atividades de desenvolvimento e fornecem limites para controle de acesso, arquivos, agentes e avaliações.
Controle de acesso baseado em função
As ações do RBAC do Azure refletem essa separação de preocupações. As ações do plano de controle, como a criação de implantações e projetos, são distintas das ações do plano de dados, como criar agentes, executar avaliações e carregar arquivos. Você pode definir o escopo de atribuições RBAC tanto no nível de recurso de nível superior quanto no nível de projeto individual. Atribua identidades gerenciadas em qualquer escopo para dar suporte à automação segura e ao acesso ao serviço. Para obter mais informações, consulte o controle de acesso baseado em função para o Microsoft Foundry.
As tarefas iniciais mais comuns para a integração com o princípio do privilégio mínimo incluem:
Usuário do Foundry para cada entidade de usuário desenvolvedor no escopo de recursos do Foundry.
Importante
As funções RBAC do Foundry foram renomeadas recentemente. Foundry User, Foundry Owner, Foundry Account Owner e Foundry Project Manager eram anteriormente chamados de Usuário do Azure AI, Proprietário do Azure AI, Proprietário da conta do Azure AI e Gerente de Projeto do Azure AI. Você ainda pode ver os nomes anteriores em alguns lugares enquanto essa mudança de nome está sendo implementada. Os IDs das funções e as permissões principais não são alterados com a mudança de nome.
Usuário do Foundry para cada identidade gerenciada do projeto no escopo de recurso do Foundry.
Para obter definições de função e diretrizes de planejamento de escopo, consulte o controle de acesso baseado em função para o Microsoft Foundry.
Monitoramento e observabilidade
O Azure Monitor segmenta as métricas por escopo. Você pode exibir as métricas de gerenciamento e uso no recurso de nível superior, enquanto as métricas específicas do projeto, como desempenho de avaliação ou atividade de agente, têm como escopo os contêineres de projeto individuais.
Os principais recursos de monitoramento incluem:
- Métricas em nível de recurso: consumo de token, latência do modelo, contagens de solicitações e taxas de erro em todos os projetos.
- Métricas no nível do projeto: resultados das execuções de avaliação, contagens de invocação de agente e atividade de operação de arquivo.
- Log de diagnósticos: habilite as configurações de diagnóstico para rotear logs para Log Analytics, Armazenamento ou Hubs de Eventos para análise e retenção.
Para obter mais informações, consulte a visão geral do Azure Monitor.
Infraestrutura de computação
A Foundry gerencia a infraestrutura de computação para hospedagem de modelo, execução de agente e processamento em lote.
Tipos de implantação de modelo
A implantação padrão em recursos do Foundry fornece arquitetura de hospedagem de modelos.
Computação gerenciada para agentes e avaliações
Os agentes, avaliações e trabalhos em lote são executados como computação de contêiner gerenciada, totalmente gerenciados pela Microsoft. As avaliações invocam pontos de extremidade de modelo e comparam saídas com critérios de classificação. A Foundry armazena resultados dentro do escopo do projeto, acessíveis por meio do portal ou do SDK.
Integração de rede virtual
Quando seus agentes se conectam a sistemas externos, você pode isolar o tráfego de rede usando a injeção de contêiner, em que a plataforma injeta uma sub-rede em sua rede virtual, permitindo a comunicação local com seus recursos do Azure na mesma rede virtual.
A Foundry dá suporte a dois modelos de rede para isolamento de saída:
| Modelo | Como funciona | Compromisso |
|---|---|---|
| VNet gerenciada pelo cliente (BYO) | Você fornece a VNet e uma sub-rede dedicada designada a Microsoft.App/environments. A plataforma integra-se à sua sub-rede, permitindo a comunicação local com seus recursos privados do Azure. |
Controle total sobre a configuração de rede; requer seu próprio gerenciamento de rede. |
| VNet gerenciada (versão preliminar) | A Foundry gerencia a VNet em seu nome. | Configuração mais simples; limita as opções de personalização. Para obter detalhes, consulte Configurar rede virtual gerenciada. |
Nota
Alguns cenários isolados de rede exigem o SDK ou a CLI em vez do portal. Por exemplo, implantações com pontos de extremidade privados que bloqueiam todo o acesso público não podem ser configuradas através da interface do usuário do portal. Para obter detalhes, consulte Como configurar um link privado para o Foundry.
Isolamento de locatário
A computação gerenciada pela Microsoft executa cargas de trabalho em ambientes logicamente isolados por projeto. O código do cliente não compartilha contêineres de runtime com outros locatários.
Segurança de conteúdo e barreiras de proteção
A Foundry integra os controles de segurança de conteúdo ao pipeline de inferência do modelo e do agente. Guardrails definem riscos para detectar, pontos de intervenção para verificação (entrada do usuário, saída, chamadas de ferramenta (versão prévia) e respostas de ferramenta (versão prévia)) e ações de resposta quando um risco é detectado. Os filtros de conteúdo são executados em linha com as solicitações de modelo e podem ser configurados para cada implantação. Para obter mais informações, consulte a Visão Geral de Guardrails e Controles e Níveis de Severidade de Filtragem de Conteúdo.
Escalonamento
A computação gerenciada para agentes e avaliações é dimensionada automaticamente com base na demanda de carga de trabalho. O modelo de hospedagem é dimensionado com base na configuração da implantação.
Disponibilidade regional
Os recursos de computação variam de acordo com a região do Azure. A disponibilidade do modelo, as opções de tipo de implantação e o suporte a recursos, como Agentes ou avaliações, podem ser diferentes entre regiões. Confirme se sua região de destino dá suporte aos recursos necessários antes do provisionamento. Para obter a disponibilidade atual, consulte a disponibilidade de recursos entre regiões de nuvem.
Armazenamento de dados
A Foundry fornece opções flexíveis e seguras de armazenamento de dados para dar suporte a uma ampla gama de cargas de trabalho de IA.
Armazenamento gerenciado para upload de arquivo
Na configuração padrão, o Foundry usa contas de armazenamento gerenciadas pela Microsoft que são logicamente separadas e dão suporte a uploads de arquivos diretos para casos de uso selecionados, como modelos OpenAI e Agentes, sem a necessidade de uma conta de armazenamento fornecida pelo cliente.
Traga seu próprio armazenamento
Opcionalmente, você pode conectar suas próprias contas de Armazenamento do Azure. Foundry Tools, como avaliações e processamento em lote, podem ler entradas e gravar saídas nessas contas. Para obter detalhes sobre cenários com suporte, consulte Leve seus próprios recursos com o serviço Agente.
Armazenamento de estado do agente
- Com a configuração básica do agente, o serviço Agent armazena threads, mensagens e arquivos no armazenamento multilocatário gerenciado pela Microsoft, com separação lógica.
- Com a configuração do agente padrão, você traz seus próprios recursos do Azure para todos os dados do cliente, incluindo arquivos, conversas e repositórios de vetores. Nessa configuração, os dados são isolados pelo projeto em suas contas de armazenamento.
Criptografia de chave gerenciada pelo cliente
Por padrão, os serviços do Azure criptografam dados em repouso e em trânsito usando chaves gerenciadas pela Microsoft com criptografia AES compatível com FIPS 140-2 de 256 bits. Nenhuma alteração de código é necessária.
Para usar suas próprias chaves, verifique se os seguintes pré-requisitos estão atendidos antes de habilitar as chaves gerenciadas pelo cliente para o Foundry:
- O Key Vault é implantado na mesma região do Azure que o recurso Foundry.
- A exclusão suave e a proteção contra limpeza estão habilitadas no Key Vault.
- As identidades gerenciadas têm permissões de chave necessárias, como a função De usuário de criptografia do Key Vault ao usar o RBAC do Azure.
Traga seu próprio Cofre de Chaves
Por padrão, o Foundry armazena todos os segredos de conexão baseados em chave de API em um Azure Key Vault gerenciado. Se você preferir gerenciar segredos por conta própria, conecte o cofre de chaves ao recurso Foundry. Uma conexão do Azure Key Vault gerencia todos os segredos de conexão no nível do projeto e do recurso. Para obter mais informações, veja como configurar uma conexão do Azure Key Vault com o Foundry.
Para saber mais sobre criptografia de dados, consulte as chaves gerenciadas pelo cliente para criptografia com o Foundry.
Residência e conformidade de dados
A Foundry armazena todos os dados em repouso na região designada do Azure. Os dados de inferência (prompts e conclusões) são processados de acordo com o tipo de implantação: as implantações globais podem ser roteadas para qualquer região do Azure, as implantações em zonas de dados permanecem dentro da zona dos EUA ou da UE, e as implantações padrão ou regionais são processadas na região de implantação. Para obter detalhes, consulte Os tipos de implantação. A Foundry não dá suporte ao failover automático entre regiões. Se sua organização exigir disponibilidade de várias regiões, implante recursos do Foundry separados em cada região de destino e gerencie a sincronização e o roteamento de dados na camada do aplicativo. Para obter detalhes de certificação de conformidade, consulte a documentação de conformidade do Azure.
Validar decisões de arquitetura
Antes da distribuição, valide o seguinte para seu ambiente de destino:
- Verifique se os modelos e recursos necessários estão disponíveis em suas regiões de implantação. Para obter detalhes, consulte a disponibilidade de recursos entre regiões de nuvem.
- Verifique se as atribuições de funções estão corretamente definidas tanto no recurso Foundry quanto nos níveis do projeto. Para obter detalhes, consulte o controle de acesso baseado em função para o Microsoft Foundry.
- Valide os requisitos de isolamento de rede e os caminhos de acesso privado. Para obter detalhes, consulte Como configurar um link privado para o Foundry.
- Confirme os requisitos de criptografia e gerenciamento de segredo, incluindo chaves gerenciadas pelo cliente e integração do Azure Key Vault. Para obter detalhes, consulte chaves gerenciadas pelo cliente para criptografia com o Foundry e como configurar uma conexão do Azure Key Vault com o Foundry.
- Verifique as cotas e os limites dos seus recursos de destino, incluindo os limites de implantação de modelos e os limites de taxa. Para obter detalhes, consulte cotas e limites do Azure OpenAI elimites, cotas e regiões do Serviço de Agente.
Conteúdo relacionado
- Implementação do Foundry em toda a minha organização
- Controle de acesso baseado em função para o Microsoft Foundry
- Chaves gerenciadas pelo cliente para criptografia com a Foundry
- Como configurar um link privado para o Foundry
- Traga seus próprios recursos com o serviço Agent
- Visão geral do Azure Monitor
- Cotas e limites do Azure OpenAI
- Tipos de implantação para modelos Foundry
- Visão geral de guardrails e controles
- Disponibilidade de recursos entre regiões de nuvem