Sistema de IA agêntica multilocatário

Last reviewed 2026-06-18 UTC

Este documento fornece uma arquitetura de referência para ajudar você a projetar e implantar um sistema de IA agêntica multitenant no Google Cloud. À medida que sua organização aumenta as implantações de IA generativa, diferentes unidades de negócios exigem agentes de IA especializados que acessam ferramentas exclusivas, seguem regras operacionais específicas e processam dados sensíveis. As unidades de negócios podem desenvolver silos de aplicativos fragmentados em uma organização, o que pode causar uma alta sobrecarga operacional, graves lacunas de governança e risco de exposição de dados. Esta arquitetura mostra como criar um sistema centralizado que permite capacitar equipes descentralizadas com recursos autônomos de IA, mantendo a segurança e a conformidade unificadas.

O público-alvo deste documento inclui arquitetos, desenvolvedores e administradores que criam e gerenciam sistemas multiagentes de nível empresarial na nuvem. Este documento pressupõe que você tenha uma compreensão básica dos conceitos de IA, ML e LLM, além de IA agêntica.

A seção Implantação deste documento fornece uma estratégia de implementação para ajudar você a criar e implantar um sistema de IA generativa multiusuário.

Arquitetura

O diagrama a seguir mostra uma arquitetura para um sistema de IA generativa multiusuário que segue um modelo hub-and-spoke. Um modelo hub e spoke é um design de rede em que um ambiente central, conhecido como hub, se conecta a vários ambientes isolados, conhecidos como spokes.

Uma arquitetura que mostra um sistema de IA agêntico multitenant.

A arquitetura consiste nos seguintes componentes:

Componente Descrição
VPC Service Controls A arquitetura usa o VPC Service Controls para configurar um perímetro de serviço no nível da organização. Esse perímetro de serviço oferece um limite de segurança estrito e impede a exfiltração de dados.
Hub de roteamento

O hub de roteamento atua como o ponto de entrada central da arquitetura e inclui os seguintes componentes:

  • Balanceador de carga de aplicativo externo: atua como o ponto de entrada central para usuários externos ou internos. O balanceador de carga garante que apenas o tráfego autenticado e seguro chegue ao portal de front-end.
  • Google Cloud Armor e Model Armor: o balanceador de carga integra o Cloud Armor e o Model Armor para inspecionar e remover solicitações maliciosas na borda da rede. O hub de roteamento usa Service Extensions no balanceador de carga de aplicativo externo para integrar o Model Armor diretamente ao fluxo de solicitações.
  • Identity-Aware Proxy (IAP): impõe um modelo de confiança zero para verificar a identidade e o contexto do usuário antes que qualquer solicitação chegue ao aplicativo.
  • Portal de front-end: um aplicativo do Cloud Run sem servidor que funciona como um mecanismo de roteamento para encaminhar solicitações ao projeto de locatário isolado apropriado.
Hub central de governança e segurança

A Central de governança e segurança é um projeto Google Cloud dedicado que oferece Identity and Access Management (IAM), registros, monitoramento e segurança centralizados para toda a plataforma. Esse hub inclui os seguintes componentes:

  • Security Command Center: um serviço que monitora todo o sistema de IA agêntica multilocatário em busca de riscos de segurança.
  • IAM: uma estrutura de controle de acesso que gerencia identidades e permissões nos hubs compartilhados e nos projetos do locatário. Esse componente oferece governança centralizada para todas as identidades humanas e de máquinas.
  • Cloud Logging: um sistema que agrega registros dos hubs compartilhados e dos projetos isolados do locatário no hub central de governança e segurança.
Projetos de locatário

Cada projeto de locatário é um projeto Google Cloud dedicado para cada unidade de negócios. Os projetos de locatário individuais são ambientes isolados que incluem os seguintes componentes:

Fluxo com agentes

O exemplo de sistema multitenant na arquitetura anterior tem o seguinte fluxo:

  1. A solicitação de um usuário é encaminhada por um balanceador de carga de aplicativo externo. No hub de roteamento, essas verificações são concluídas para garantir que apenas o tráfego autenticado e seguro chegue ao portal de front-end:
    1. O Cloud Armor aplica políticas de segurança para absorver ataques iniciais de negação de serviço distribuída (DDoS) baseados em protocolo de rede da camada 4. O Cloud Armor inspeciona a solicitação e filtra o tráfego malicioso, como injeção de SQL (SQLi), scripting em vários locais (XSS) e assinaturas de bots conhecidos.
    2. O Model Armor intercepta o payload para detectar e rejeitar ataques de injeção de comandos ou intenções maliciosas.
    3. Se alguma dessas camadas detectar uma ameaça ou acesso não autorizado, o balanceador de carga vai descartar a solicitação na borda da rede.
    4. Se as camadas de segurança não detectarem nenhuma ameaça e validarem o acesso do usuário, o balanceador de carga vai rotear o tráfego para o serviço de back-end.
  2. Se a solicitação passar em todas as verificações, o balanceador de carga a encaminhará para a plataforma de front-end, que vai realizar as seguintes ações:
    1. Extrai a identidade do usuário, como a unidade de negócios ou o ID do locatário.
    2. Usa o IAP para verificar a identidade corporativa do usuário e a integridade do dispositivo.
    3. Usa um registro mantido dinamicamente para identificar o locatário de destino correto.
  3. O portal de front-end encaminha a solicitação ao locatário. Para garantir que o agente não possa acessar outros projetos do locatário ou serviços Google Cloud não autorizados, o Agent Runtime usa uma política de PAB para limitar os recursos que o agente pode acessar.
  4. O Model Armor usa a Proteção de Dados Sensíveis para inspecionar e mascarar dinamicamente qualquer informação de identificação pessoal (PII) ou conteúdo restrito. O Model Armor realiza uma verificação adicional de injeções de comandos maliciosas na solicitação para garantir que o agente processe apenas dados seguros.

  5. O Gemini realiza as seguintes tarefas para gerar uma resposta:

    1. Realiza uma passagem de raciocínio inicial para entender a intenção do usuário.
    2. Se o Gemini determinar que não tem fatos específicos, ele vai gerar um plano para chamar as ferramentas de dados específicas do locatário:
      1. Para verificar se um usuário tem permissão para acessar os recursos de dados, o agente verifica a identidade do usuário e as vinculações de função do IAM.
      2. Para recuperar o contexto, o agente executa uma chamada de ferramenta pelo servidor MCP para o repositório de dados do locatário.
      3. O agente cria uma resposta embasada combinando a lógica interna com os fatos específicos do locatário recém-recuperados.

    Se o Gemini não precisar de mais informações, ele vai gerar uma resposta e enviá-la para o Model Armor.

  6. O Model Armor inspeciona e mascara dinamicamente qualquer PII ou conteúdo restrito e envia a resposta higienizada para o agente do locatário. Essa inspeção final ajuda a garantir que nenhum dado sensível vaze na saída.

  7. A resposta é encaminhada de volta ao usuário, do agente do locatário pela plataforma de front-end e pelo balanceador de carga.

Produtos usados

Esta arquitetura de referência usa os seguintes produtos e ferramentas de código aberto e do Google Cloud , escolhidos pela natureza sem servidor, escalonabilidade e recursos de segurança:

Caso de uso

Os sistemas de IA agêntica multilocatários são adequados para organizações empresariais que querem dimensionar as implantações de IA generativa além de um único aplicativo. Para identificar casos de uso adequados a essa arquitetura, analise os processos de negócios e identifique diferentes equipes que precisam de agentes de IA especializados próprios que acessam ferramentas exclusivas e dados sensíveis. Essa abordagem ajuda você a capacitar equipes descentralizadas com recursos autônomos de IA, mantendo a segurança unificada e a conformidade corporativa.

Confira a seguir um exemplo de caso de uso para um sistema de IA agêntica com vários locatários.

Atendimento ao cliente em toda a empresa

É possível adaptar essa arquitetura de referência para oferecer atendimento ao cliente com tecnologia de IA em diferentes divisões de negócios. Por exemplo, para oferecer suporte a uma divisão de eletrônicos e uma de produtos para casa, implante um agente de eletrônicos e um agente de produtos para casa como dois agentes separados em projetos de locatários separados. Esses agentes de IA especializados atuam como assistentes inteligentes que lidam com consultas de suporte específicas da divisão acessando especificações técnicas, garantias ou políticas de devolução exclusivas. Com essa automação, as equipes de suporte humano podem se concentrar em encaminhamentos mais complexos dos clientes.

Para esse caso de uso, a arquitetura oferece os seguintes benefícios:

  • Isolamento estrito de dados: o design multilocatário garante que o conhecimento de suporte de cada divisão seja estritamente isolado. A política de PAB fornece mecanismos de proteção que ajudam a garantir que uma identidade de agente em um locatário não possa acessar dados em outro locatário.
  • Conhecimento especializado do agente: como cada agente reside em um projeto de locatário isolado, ele só recupera o contexto do datastore específico da divisão. Essa recuperação direcionada garante alta acurácia e evita que o agente confunda as políticas de diferentes unidades de negócios.
  • Redução do risco entre domínios: a arquitetura ajuda a eliminar o risco de exposição de dados entre unidades de negócios. Mesmo que uma identidade de agente seja comprometida, o agente não poderá acessar recursos Google Cloud não autorizados.

Essa arquitetura é ideal para grandes organizações e empresas de varejo que gerenciam várias marcas ou unidades de negócios distintas e exigem soberania de dados estrita.

Alternativas de design

Esta seção apresenta abordagens de design alternativas que você pode considerar para sua implantação de IA agêntica multitenant no Google Cloud.

Implantação de acesso privado

Na arquitetura descrita neste documento, os usuários acessam o sistema de IA agêntica multilocatário pela internet pública usando um balanceador de carga de aplicativo externo exposto centralmente. Se sua organização exigir um sistema que permaneça inacessível da Internet pública, adapte a arquitetura para usar uma das seguintes estratégias de acesso privado.

Bloquear o tráfego com políticas de segurança de borda

Para permitir o tráfego apenas dos endereços IP corporativos verificados da sua organização, configure as políticas de segurança do Cloud Armor para negar qualquer outro tráfego. Essa regra de segurança de alta prioridade bloqueia todas as solicitações não autorizadas na borda da rede. Para uma camada extra de segurança, use o IAP para exigir uma sessão de identidade corporativa válida e configure as permissões do IAM para todos os usuários.

Essa abordagem permite aproveitar as políticas de segurança de borda do Cloud Armor para descarregar a mitigação de DDoS e a filtragem de WAF, como SQLi e XSS, e oferece uma experiência de confiança zero. No entanto, o endereço IP de front-end do balanceador de carga de aplicativo externo permanece público e pode não atender aos requisitos de compliance de algumas organizações.

Direcionar o tráfego por um balanceador de carga de aplicativo interno

A arquitetura neste documento usa um balanceador de carga de aplicativo externo, que oferece políticas robustas do Cloud Armor, recursos de segurança mais avançados e menor complexidade operacional em comparação com os balanceadores de carga internos. No entanto, o uso de um balanceador de carga externo significa que o tráfego atravessa a Internet pública.

Para manter o tráfego totalmente dentro da rede privada do Google, use um balanceador de carga de aplicativo interno. O uso de um balanceador de carga de aplicativo interno oferece suporte ao IAP para confirmação de identidade. Um balanceador de carga de aplicativo externo global avalia as políticas da IAP na camada de borda. Por outro lado, um balanceador de carga de aplicativo interno avalia as políticas na camada de rede interna. Como o tráfego nunca passa pela Internet pública, o uso de um balanceador de carga de aplicativo interno ajuda você a atender aos requisitos rigorosos de soberania de dados e de endereço IP público zero.

Para manter a baixa latência e obedecer aos requisitos regionais de residência de dados, implante um balanceador de carga de aplicativo interno regional em cada região principal. Com um balanceador de carga de aplicativo interno regional, você roteia o tráfego de ambientes locais pela Cloud Interconnect ou pela Cloud VPN diretamente para o endereço IP interno do balanceador de carga. Um balanceador de carga de aplicativo interno regional é compatível com o Cloud Armor regional para proteção interna de WAF. No entanto, em comparação com um balanceador de carga de aplicativo externo, os balanceadores de carga de aplicativo internos regionais oferecem suporte a um conjunto limitado de políticas de segurança do Cloud Armor, não têm recursos avançados de segurança e aumentam a complexidade operacional.

Para minimizar ainda mais a latência e ajudar a garantir a alta disponibilidade para atender aos seus requisitos de recuperação de desastres, implante um balanceador de carga de aplicativo interno entre regiões. Com um balanceador de carga de aplicativo interno entre regiões, você usa o Cloud DNS com políticas de roteamento de geolocalização para resolver o URL interno do aplicativo no balanceador de carga de aplicativo interno entre regiões naGoogle Cloud região mais próxima do usuário. No entanto, uma configuração entre regiões não é compatível com nenhuma integração do Cloud Armor.

Infraestrutura de computação

Para priorizar uma abordagem sem servidor que facilite o gerenciamento e reduza a sobrecarga operacional, a arquitetura neste documento usa o Cloud Run na infraestrutura de computação. Também é possível executar aplicativos conteinerizados em clusters do GKE. O Google Kubernetes Engine (GKE) é um mecanismo de orquestração de contêineres que automatiza a implantação, o escalonamento e o gerenciamento de aplicativos em contêineres. O GKE oferece suporte total aos balanceadores de carga de aplicativos internos e externos. Para informações sobre como escolher um serviço de computação para suas cargas de trabalho no Google Cloud, consulte Hospedagem de aplicativos noGoogle Cloud.

Servidores do Protocolo de Contexto de Modelo (MCP, na sigla em inglês)

Para permitir que os componentes do sistema de agentes interajam, é necessário estabelecer protocolos de comunicação claros. O MCP é um protocolo aberto que fornece uma interface padronizada para que os agentes acessem e usem as ferramentas, os dados e outros serviços necessários.

Para conectar os agentes do locatário ao seu repositório de dados, considere os requisitos do aplicativo para escolher entre as seguintes opções de implantação do servidor MCP. Ao escolher entre implantações locais e compartilhadas do MCP, considere as compensações entre isolamento de dados e eficiência operacional.

  • Servidor MCP local: um servidor MCP local ou específico do locatário é um servidor MCP implantado em cada projeto de locatário e que fornece aos agentes acesso a repositórios de dados e ferramentas específicos dessa unidade de negócios.

    Confira abaixo os principais recursos e considerações sobre os servidores MCP locais:

    • Rede: um perímetro do VPC Service Controls no nível do projeto e uma política de PAB oferecem segurança e isolamento inerentes, o que ajuda a garantir que não haja acesso entre locatários.
    • Gerenciamento: equipes individuais de desenvolvedores e operações gerenciam projetos de locatário de forma independente. Esse isolamento oferece autonomia para cada unidade de negócios.
    • Segurança: os limites fixos do IAM do projeto de locatário ajudam a minimizar as superfícies de risco lateral e não exigem mapeamentos de identidade complexos.

    Os servidores MCP locais oferecem isolamento máximo e podem processar acesso aos dados altamente sensíveis ou regulamentados. No entanto, se você implantar vários servidores MCP locais, vai aumentar sua carga operacional. Recomendamos servidores MCP locais para aplicativos que exigem acesso restrito a armazenamentos de dados que podem conter informações sensíveis.

  • Servidor MCP compartilhado: um servidor MCP compartilhado ou global é um servidor MCP que você implanta em um projeto de serviços compartilhados. Os servidores MCP compartilhados dão acesso a ferramentas e sistemas comuns a vários locatários.

    Confira abaixo os principais recursos e considerações sobre os servidores MCP compartilhados:

    • Rede: para garantir que o tráfego não atravesse a Internet pública, os servidores MCP compartilhados exigem conectividade privada, como Private Service Connect ou peering de rede VPC.
    • Gerenciamento: uma equipe de operações centralizada gerencia a implementação de todo o sistema. Esse gerenciamento consolidado otimiza a eficiência operacional e elimina a necessidade de duplicar implementações locais em vários locatários.
    • Segurança: você propaga com segurança a identidade do usuário final do agente no projeto de locatário para o servidor MCP compartilhado. Para garantir que os usuários só possam acessar ou modificar dados a que têm permissão, o servidor MCP compartilhado usa a identidade do usuário propagada para aplicar o controle de acesso refinado no sistema de back-end.

    Os servidores MCP compartilhados centralizam o gerenciamento de ferramentas comuns, o que reduz a duplicação e otimiza a eficiência operacional. Embora os servidores MCP compartilhados reduzam a sobrecarga de gerenciamento, eles exigem uma propagação de identidade e uma lógica de autorização robustas para manter o acesso seguro. Recomendamos servidores MCP compartilhados para interações com sistemas e ferramentas corporativas comuns, como ferramentas de relatórios de despesas, sistemas de recursos humanos (RH), bases de conhecimento em toda a empresa ou gerentes de presença.

Nessa arquitetura, você usa servidores MCP para padronizar a conexão entre os agentes do locatário e os repositórios de dados. Dependendo dos requisitos da sua carga de trabalho, você pode usar outros tipos de ferramentas de agente para conectar seus agentes a APIs e sistemas externos específicos. Para mais informações sobre interações com ferramentas do agente, consulte Ferramentas do agente.

Considerações sobre o design

As seções a seguir descrevem fatores de design, práticas recomendadas e recomendações a serem consideradas ao usar essa arquitetura de referência para desenvolver uma topologia que atenda aos seus requisitos específicos de segurança, confiabilidade, custo e desempenho. As orientações desta seção não são completas. Dependendo dos requisitos da sua carga de trabalho e dos produtos e recursos que você usa, pode haver outros fatores de design e compensações que você precisa considerar.

segurança, privacidade e conformidade

Nesta seção, descrevemos considerações e recomendações de design para criar uma topologia no Google Cloud que atenda aos requisitos de segurança, privacidade e conformidade da sua carga de trabalho.

Componente Considerações e recomendações de design
Nuvem privada virtual (VPC) Isolamento de locatário: nessa arquitetura, você implanta cada locatário em um projeto Google Cloud dedicado. Para criar um limite de segurança estrito, combine o isolamento no nível do projeto do locatário com a política de PAB e o VPC Service Controls no nível da organização.
IAM Controle de acesso: para implementar o princípio de privilégio mínimo, use um modelo de acesso baseado em persona. Por exemplo, é possível definir papéis personalizados do IAM para garantir que um desenvolvedor que cria um agente em um locatário não possa acessar dados em outro.
Cloud Armor

Proteção de WAF interna e de borda: o Cloud Armor oferece segurança e proteção de WAF para defender o portal de front-end contra ataques DDoS e vulnerabilidades da Web. Um balanceador de carga de aplicativo externo global oferece suporte ao conjunto completo de recursos avançados de borda, como gerenciamento de bots e proteção adaptativa do Google Cloud Armor.

Se você implantar um balanceador de carga de aplicativo interno regional, o Cloud Armor vai operar com um conjunto restrito de políticas padrão do WAF. O conjunto restrito de políticas é adaptado para limites de rede interna e inclui políticas como proteção contra SQLi e XSS. Para mais informações, consulte Como integrar o Cloud Armor a outros produtos do Google.
Agent Platform

Endpoints de modelo compartilhados: para evitar abusos e garantir o uso justo dos endpoints de modelo compartilhados, implemente uma das seguintes estratégias:

  • Limitação de taxa no nível do locatário: aplique cotas no portal de front-end para cada locatário antes que as solicitações cheguem ao endpoint compartilhado. Para aplicar as cotas, faça o seguinte:
    1. Extraia a identidade do locatário do contexto da IAP.
    2. Acompanhe o uso em relação aos limites predefinidos para cada locatário usando um armazenamento externo, como o Memorystore para Redis.
    3. Rejeite solicitações de locatários que excedam os limites.
  • API Gateway: para aplicar cotas por locatário usando chaves de API e planos de uso, implemente o API Gateway antes do endpoint compartilhado.
Cloud Run

Renderização de conteúdo: para melhorar a postura de segurança do portal de front-end, priorize a renderização do lado do servidor (SSR) em vez da renderização do lado do cliente (CSR). Em comparação com a CSR, a SSR oferece estes benefícios:

  • Executa a lógica do aplicativo e gerencia secrets em um ambiente Google Cloud controlado.
  • Reduz a superfície de ataque do lado do cliente e evita vazamentos de dados sensíveis para o navegador não confiável do usuário.
  • Limita a exposição de dados enviando apenas o HTML necessário ao cliente.
  • Fornece codificação de saída centralizada para proteção contra ataques de scripting em vários locais (XSS).
Security Command Center Monitoramento de segurança centralizado: para monitorar ameaças e aplicar políticas de segurança, como autenticação multifator (MFA) e criptografia de dados, use as ferramentas no Security Command Center.

Mais recomendações de segurança

Confiabilidade

Nesta seção, descrevemos considerações e recomendações de design para criar e operar uma infraestrutura confiável para sua implantação no Google Cloud.

Componente Considerações e recomendações de design
Cloud Load Balancing Roteamento global: um balanceador de carga de aplicativo externo global fornece um único endereço IP Anycast que encaminha automaticamente o tráfego do usuário para a borda geográfica do Google mais próxima. Essa configuração reduz a latência com a terminação Secure Sockets Layer (SSL) de borda. Ele também garante alta disponibilidade se uma região sofrer uma interrupção, porque redireciona de maneira inteligente o tráfego para back-ends regionais íntegros.
Locatário Tolerância a falhas: para tolerar ou lidar com falhas no nível do agente, implante agentes em projetos de locatários isolados. Esse isolamento ajuda a garantir que problemas operacionais ou incidentes de segurança permaneçam em uma única unidade de negócios e não afetem outros recursos ou unidades.
Agent Platform Planejamento de capacidade: se o número de solicitações ao modelo exceder a capacidade alocada, o modelo vai retornar o código de erro 429. Para cargas de trabalho essenciais para os negócios e que exigem capacidade de processamento consistentemente alta, é possível reservar capacidade de processamento usando a capacidade de processamento provisionada.
Agent Runtime

Escalonabilidade sem servidor: os agentes implantados no Agent Runtime são escalonados de forma independente com base na demanda. Um pico repentino de uso em um locatário não esgota os recursos de computação nem afeta a disponibilidade de um agente em outro projeto de locatário.

Tratamento de erros: para lidar com erros transitórios, como limites de taxa do código de erro 429, a lógica de orquestração do agente usa a espera exponencial. Se um prazo de contexto for excedido, o agente vai realizar um encerramento completo e informar o progresso parcial ao usuário. Por exemplo, um prazo de contexto pode ser excedido devido a chamadas de ferramentas lentas, latência de API de terceiros, processamento de conjuntos de dados massivos ou processamento com uso intenso de computação.

Para princípios e recomendações de confiabilidade específicos para cargas de trabalho de IA e ML, consulte Perspectiva de IA e ML: confiabilidade no Framework bem arquitetado.

Eficiência operacional

Nesta seção, descrevemos os fatores que você precisa considerar ao usar essa arquitetura de referência para projetar uma topologia Google Cloud que possa ser operada de maneira eficiente.

Componente Considerações e recomendações de design
Google Cloud Observability Monitoramento centralizado: o Logging e o Monitoring permitem monitorar a integridade e o desempenho de toda a plataforma. É possível configurar alertas para detectar e resolver problemas de forma proativa sem permitir o acesso a dados sensíveis.
Todos os produtos na arquitetura Implantações padronizadas: usar a Agent Platform em um padrão de arquitetura de locatário padronizado permite estabelecer uma referência consistente ao integrar novos locatários. Para reduzir a carga operacional, automatize o processo de implantação usando ferramentas de infraestrutura como código (IaC), como o Terraform. Para conferir o código do Terraform que pode ser usado para criar e implantar um sistema de IA agêntica multitenant, consulte a seção Implantação deste documento.

Para princípios e recomendações de excelência operacional específicos para cargas de trabalho de IA e ML, consulte Perspectiva de IA e ML: excelência operacional no framework bem arquitetado.

Otimização de custos

Nesta seção, você encontra orientações para otimizar o custo de configuração e operação de uma topologia Google Cloud criada usando essa arquitetura de referência.

Componente Considerações e recomendações de design
Agent Platform

Consumo de tokens: para gerenciar custos e evitar que o modelo de IA exceda as janelas de contexto, use as seguintes estratégias:

  • Resumo do contexto: em vez de salvar uma conversa inteira de uma sessão como contexto, use um modelo de IA para resumir conversas mais antigas e informações menos importantes.
  • Remover saídas: identifique e remova partes menos relevantes ou detalhadas das saídas da ferramenta ou do contexto recuperado. Por exemplo, se você só precisar dos nomes das colunas dos seus dados, remova o excesso de metadados de uma busca de esquema de banco de dados. Essa estratégia exige uma lógica personalizada que usa heurísticas, filtragem ou um modelo de linguagem pequeno (SLM, na sigla em inglês) para extrair as informações mais importantes.
  • Limite máximo de tokens: para evitar loops infinitos e controlar custos, aplique um limite máximo de tokens por sessão.

Endpoints de modelo: para gerenciar cotas de API e utilização de recursos, é possível implantar endpoints da Agent Platform em uma configuração dedicada ou compartilhada:

  • Endpoints dedicados: ao implantar endpoints em cada projeto de locatário, você fornece isolamento de cota inerente. O uso de cada locatário é contabilizado nas cotas do próprio projeto, o que evita o impacto entre locatários. Em comparação com os endpoints compartilhados, os dedicados oferecem um gerenciamento de cota mais simples. No entanto, os endpoints dedicados impedem que você aproveite a possível economia de custos de um endpoint compartilhado.
  • Endpoints compartilhados: para otimizar os custos, hospede um endpoint compartilhado no hub central de governança e segurança. Como todos os locatários compartilham o mesmo pool de cotas, para evitar ataques maliciosos, é necessário implementar estratégias de mitigação, como limitação de taxa no nível do locatário ou aplicação de cotas com o API Gateway. Em comparação com endpoints dedicados, os compartilhados são mais econômicos. No entanto, os endpoints compartilhados exigem mais esforço de engenharia e podem introduzir latência e sobrecarga de gerenciamento.

Para informações sobre custos na Agent Platform, consulte Custo de criação e implantação de modelos de IA na Agent Platform.
Cloud Run Instrumentação: permite monitorar o desempenho, solucionar problemas e rastrear o uso de recursos de cada locatário. Para identificar o locatário de cada solicitação, extraia a identidade do usuário do contexto fornecido pelo IAP. Para informações sobre como instrumentar seu aplicativo, consulte Escolher uma abordagem de instrumentação.
Model Armor Filtragem centralizada de comandos: para aplicar uma governança estrita e uma postura de confiança zero, essa arquitetura implanta o Model Armor em duas camadas: no hub de roteamento e em cada projeto de locatário. Embora essa abordagem de duas camadas ajude a garantir a soberania de dados, ela aumenta a latência e os custos operacionais. Para reduzir custos e a complexidade do sistema, filtre todos os comandos e respostas implantando o Model Armor exclusivamente no hub de roteamento.
Todos os produtos na arquitetura

Infraestrutura compartilhada: componentes principais compartilhados, como o portal de front-end, o hub central de governança e segurança e a Agent Platform, podem reduzir custos em comparação com a criação de uma pilha personalizada separada para cada agente.

Sobrecarga da plataforma: para distribuir os custos compartilhados do hub central de governança e segurança, use um modelo de alocação que se ajuste aos seus recursos de rastreamento e padrões de uso. Recomendamos que você use um dos seguintes modelos de alocação de custos:

  • Alocação de divisão uniforme: um modelo de divisão uniforme aloca custos compartilhados igualmente entre todos os locatários. Use esse modelo quando a plataforma for um utilitário básico ou quando a sobrecarga do rastreamento granular superar os benefícios de custo.
  • Alocação proporcional: um modelo proporcional, ou processo de chargeback, aloca custos compartilhados com base na proporção de custos diretos que cada locatário incorre. Use esse modelo quando o consumo do locatário variar muito e você tiver uma telemetria robusta, como rótulos do Resource Manager e análise de registros, para atribuir custos com precisão.
  • Alocação fixa: um modelo fixo ou em níveis aloca custos compartilhados com base em coeficientes definidos pela empresa. Use esse modelo quando os locatários exigirem contratos de nível de serviço (SLAs) diferentes. Com uma alocação fixa de modelo, você pode cobrar taxas fixas por recursos premium dedicados em vez de recursos compartilhados padrão.

Para mais informações sobre como alocar custos de serviços compartilhados, consulte Cloud FinOps: alocação de custos de serviços compartilhados.

Gerenciamento centralizado de custos: para acompanhar com precisão o custo total de propriedade (TCO) do seu sistema de IA generativa e atribuir custos a unidades de negócios individuais, use rótulos e dados de exportação do Cloud Billing. Para mais informações sobre como usar rótulos para aumentar a conscientização sobre custos, consulte Promover uma cultura de conscientização sobre custos.

Para estimar o custo dos seus recursos do Google Cloud , use a calculadora de preços doGoogle Cloud .

Para princípios e recomendações de otimização de custos específicos para cargas de trabalho de IA e ML, consulte Perspectiva de IA e ML: otimização de custos no Well-Architected Framework.

Implantação

Para implantar essa arquitetura de referência, use o exemplo multi-tenant IA agêntica Terraform disponível no GitHub.

A seguir

Colaboradores

Autores:

  • Shivank Awasthi | Arquiteto de soluções de campo
  • Utkarsh Bhardwaj | Consultor de soluções técnicas, IA agêntica, apps, plataformas e infraestrutura de nuvem

Outros colaboradores: