Sistema de IA agêntica multilocatário

Last reviewed 2026-10-16 UTC

Este documento apresenta uma arquitetura de referência para ajudar você a projetar e implantar um sistema de IA agêntica multilocatário no Google Cloud. À medida que sua organização escala 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 alta sobrecarga operacional, graves lacunas de governança e risco de exposição de dados. Essa arquitetura mostra como criar um sistema centralizado que permite capacitar equipes descentralizadas com recursos de IA autônomos, 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 de implantação deste documento fornece uma estratégia de implementação para ajudar você a criar e implantar um sistema de IA agêntica multilocatário.

Arquitetura

O diagrama a seguir mostra uma arquitetura para um sistema de IA agêntica multilocatá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êntica multilocatário.

A arquitetura consiste nos seguintes componentes:

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 fornece um limite de segurança estrito e ajuda a evitar 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 ajuda a garantir 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 limpar comandos maliciosos na borda da rede. O hub de roteamento usa extensões de serviço no balanceador de carga de aplicativo externo para integrar o Model Armor diretamente ao fluxo de solicitações.
  • Identity-Aware Proxy (IAP): aplica 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 atua como um mecanismo de roteamento para encaminhar solicitações ao projeto de locatário isolado apropriado.
Hub central de governança e segurança

O hub central de governança e segurança é um projeto dedicado do Google Cloud que fornece Identity and Access Management (IAM), geração de 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: um framework de controle de acesso que gerencia identidades e permissões nos hubs compartilhados e nos projetos de locatário. Esse componente oferece governança centralizada para todas as identidades humanas e de máquina.
  • Cloud Logging: um sistema que agrega registros dos hubs compartilhados e dos projetos de locatário isolados no hub central de governança e segurança.
Projetos de locatário

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

Fluxo agêntico

O sistema multilocatário de exemplo na arquitetura anterior tem o seguinte fluxo:

  1. A solicitação de um usuário é roteada 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 qualquer ataque distribuído de negação de serviço (DDoS) inicial baseado 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 bot conhecidas.
    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 ameaças e validarem o acesso do usuário, o balanceador de carga vai encaminhar 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 executará 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 para o locatário. Para garantir que o agente não possa acessar outros projetos de locatário ou serviços não autorizados do Google Cloud, 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 maliciosos 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 análise 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 papel 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 recém-recuperados específicos do locatário.

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

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

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

Produtos usados

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

  • VPC Service Controls: uma funcionalidade de rede gerenciada que minimiza os riscos de exfiltração de dados para seus recursos do Google Cloud .
  • Cloud Load Balancing: um portfólio de balanceadores de carga globais, regionais, escalonáveis, globais e de alto desempenho.
  • Google Cloud Armor: um serviço de segurança de rede que oferece regras de firewall de aplicativos da Web (WAF) e ajuda a proteger contra ataques DDoS e de aplicativos.
  • Model Armor: um serviço que protege seus recursos de IA generativa e agêntica contra injeção de comandos, vazamentos de dados sensíveis e conteúdo prejudicial.
  • Identity-Aware Proxy (IAP): um serviço que permite um modelo de acesso de confiança zero para seus aplicativos e máquinas virtuais.
  • Identity and Access Management (IAM): um sistema que permite criar e gerenciar permissões para recursos do Google Cloud .
  • Cloud Run: uma plataforma de computação sem servidor que permite executar contêineres diretamente na infraestrutura escalonável do Google.
  • Gemini Enterprise Agent Platform: uma plataforma abrangente que permite criar, escalonar, governar e otimizar agentes de IA de nível empresarial.
  • Gemini: uma família de modelos de IA multimodal desenvolvida pelo Google.
  • Protocolo de Contexto de Modelo (MCP): um padrão de código aberto para conectar aplicativos de IA a sistemas externos.
  • Cloud Logging: um sistema de gerenciamento de registros em tempo real com armazenamento, pesquisa, análise e alertas.

Caso de uso

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

Veja a seguir um exemplo de caso de uso para um sistema de IA agêntica multilocatário.

Atendimento ao cliente em toda a empresa

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

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

  • Isolamento rigoroso de dados: o design multilocatário ajuda a garantir que o conhecimento de suporte de cada divisão seja estritamente isolado. A política de PAB oferece proteções 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 repositório de dados específico da divisão. Essa recuperação direcionada ajuda a melhorar a precisão e evita que o agente confunda as políticas de diferentes unidades de negócios.
  • Risco reduzido 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 do Google Cloud não autorizados.

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

Alternativas de design

Nesta seção, apresentamos abordagens de design alternativas que você pode considerar para sua implantação de IA agêntica multilocatária 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 de forma centralizada. Se a organização exigir um sistema que permaneça inacessível pela Internet pública, será possível adaptar a arquitetura para usar uma das seguintes estratégias de acesso particular.

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 que você aproveite 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.

Rotear 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 balanceadores de carga internos. No entanto, o uso de um balanceador de carga externo significa que o tráfego passa pela 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 é compatível com o IAP para confirmação de identidade. Um balanceador de carga de aplicativo externo global avalia as políticas do 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 atravessa a Internet pública, o uso de um balanceador de carga de aplicativo interno ajuda 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ê encaminha o tráfego de ambientes locais pelo Cloud Interconnect ou pelo 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 de WAF interna. No entanto, em comparação com um balanceador de carga de aplicativo externo, os balanceadores de carga de aplicativo internos regionais dão suporte a um conjunto limitado de políticas de segurança do Cloud Armor, não têm recursos de segurança avançados e aumentam a complexidade operacional.

Para minimizar ainda mais a latência e ajudar a garantir alta disponibilidade para atender aos 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 para o balanceador de carga de aplicativo interno entre regiões na Google 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 que prioriza o uso de tecnologia sem servidor, que facilita o gerenciamento e reduz a sobrecarga operacional, a arquitetura neste documento usa o Cloud Run para a 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 é totalmente compatível com balanceadores de carga de aplicativo internos e externos. Para saber como escolher um serviço de computação para suas cargas de trabalho no Google Cloud, consulte Como hospedar aplicativos no Google Cloud.

Servidores MCP locais e compartilhados

Para permitir que os componentes do seu sistema de agentes interajam, é necessário estabelecer protocolos de comunicação claros. O MCP é um protocolo aberto que oferece 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 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 vantagens e desvantagens entre o isolamento de dados e a eficiência operacional.

  • Servidor MCP local: um servidor MCP local ou específico do locatário é um servidor MCP que você implanta 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 a seguir 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: as equipes de desenvolvedores e de operações gerenciam os 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 lidar com acesso a 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 restritivo a repositórios de dados que podem conter informações sensíveis.

  • Servidor MCP compartilhado: um servidor MCP compartilhado ou global é um servidor MCP implantado em um projeto de serviços compartilhados. Os servidores MCP compartilhados fornecem acesso a ferramentas e sistemas comuns a vários locatários.

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

    • Rede: para garantir que o tráfego não passe pela Internet pública, os servidores MCP compartilhados exigem conectividade privada, como o Private Service Connect ou o peering de rede VPC.
    • Gerenciamento: uma equipe de operações centralizada gerencia a implementação para 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 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 lógica robusta de propagação de identidade e autorização 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 corporativas ou gerentes de presença.

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

Considerações de segurança para agentes

Os agentes de IA apresentam riscos de segurança específicos e críticos que as práticas de segurança convencionais e determinísticas talvez não consigam mitigar adequadamente. O Google recomenda uma abordagem para agentes de IA seguros que combina os pontos fortes dos controles de segurança determinísticos com defesas dinâmicas baseadas em raciocínio. Essa abordagem se baseia em três princípios fundamentais: supervisão humana, autonomia do agente cuidadosamente definida e observabilidade. Veja a seguir recomendações específicas que estão alinhadas com esses princípios básicos:

  • Supervisão humana: um sistema de IA agêntica pode falhar ou não funcionar como esperado. Por exemplo, o modelo pode gerar conteúdo impreciso ou um agente pode selecionar ferramentas inadequadas. Em sistemas de IA agêntica essenciais para os negócios, incorpore um fluxo human-in-the-loop para permitir que supervisores humanos monitorem, substituam e pausem agentes. Por exemplo, usuários humanos podem revisar a saída dos agentes, aprovar ou rejeitar as saídas e fornecer mais orientações para corrigir erros ou tomar decisões estratégicas. Essa abordagem combina a eficiência dos sistemas de IA agêntica com o pensamento crítico e a experiência de domínio dos usuários humanos.
  • Identidade do agente e acesso com privilégio mínimo:

  • Governança de tráfego de entrada e saída: roteie o tráfego do agente pelo Gateway de Agente para aplicar políticas de segurança de ambiente de execução nos limites de entrada e saída. Para informações sobre as plataformas de Agent Runtime compatíveis com o Gateway de Agente, consulte Agent Runtime compatíveis.

    • Cliente para agente (entrada): implante o Gateway de Agente na frente do Agent Runtime. O gateway ajuda a autenticar os autores de chamadas e inspecionar os comandos de entrada em tempo real usando o Model Armor.

    • Do agente para qualquer lugar (saída):

      • Encaminhar solicitações de saída de agente para agente (A2A) e de agente para ferramenta (MCP) pelo Gateway de Agente no modo de saída.
      • Aplique políticas de acesso de negação padrão usando políticas de acesso do IAM e o IAP.
      • Verifique se os agentes e as ferramentas de destino estão registrados no Agent Registry.
      • Inspecione as invocações e respostas de ferramentas de saída com o Model Armor para ajudar a evitar a exfiltração de dados, a injeção indireta de comandos e o uso indevido de ferramentas.

  • Monitoramento: monitore o comportamento do agente usando recursos abrangentes de rastreamento que oferecem visibilidade sobre todas as ações de um agente, incluindo o processo de raciocínio, a seleção de ferramentas e os caminhos de execução. Para mais informações, consulte Como fazer login de um agente no Agent Runtime e Como fazer login no ADK.

Para mais informações sobre como proteger agentes de IA, consulte Segurança para agentes de IA.

Considerações de segurança da nuvem privada virtual (VPC)

Nessa arquitetura, você implanta cada locatário em um projeto dedicado doGoogle Cloud . Para criar um limite de segurança rígido, combine o isolamento no nível do projeto de locatário com a política de PAB e o VPC Service Controls no nível da organização.

Considerações de segurança do IAM

Para implementar o princípio de privilégio mínimo, use um modelo de acesso baseado em personas. 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 locatário.

Considerações de segurança do Cloud Armor

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 é compatível com o conjunto completo de recursos de borda avançados, 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 de WAF padrão. O conjunto restrito de políticas é adaptado para limites de rede internos 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.

Considerações de segurança da Agent Platform

Para garantir que as configurações e o uso da Plataforma de Agentes atendam aos seus requisitos de segurança, considere as seguintes recomendações:

  • Responsabilidade compartilhada: a segurança é uma responsabilidade compartilhada. A Agent Platform protege a infraestrutura subjacente e oferece ferramentas e controles de segurança para ajudar você a proteger seus dados, códigos e modelos. Você é responsável por configurar corretamente seus serviços, gerenciar controles de acesso e proteger seus aplicativos. Para mais informações, consulte Responsabilidade compartilhada da plataforma de agentes.
  • Controles de segurança: a plataforma de agentes oferece suporte a Google Cloud controles de segurança que podem ser usados para atender aos requisitos de residência de dados, chaves de criptografia gerenciadas pelo cliente (CMEK), segurança de rede usando o VPC Service Controls e Transparência no acesso. Para mais informações, consulte a seguinte documentação:
  • Segurança: os modelos de IA podem produzir respostas nocivas, às vezes em resposta a comandos maliciosos.
    • Para aumentar a segurança e reduzir o possível uso indevido do sistema de IA agêntica, configure filtros de conteúdo para que atuem como barreiras contra entradas e respostas nocivas. Para mais informações, consulte Filtros de segurança e conteúdo.
    • Para inspecionar e higienizar solicitações de inferência, comandos de agentes, chamadas de ferramentas e respostas para ameaças como injeção de comandos e conteúdo nocivo, use o Model Armor para chamadas de API de modelo diretas e para solicitações roteadas pelo Gateway de Agente. O Model Armor ajuda a evitar entradas maliciosas, verificar a segurança do conteúdo, proteger dados sensíveis, manter a conformidade e aplicar políticas de segurança de maneira consistente.
  • Acesso ao modelo: é possível configurar políticas da organização para limitar o tipo e as versões de modelos de IA que podem ser usados em um projeto do Google Cloud . Para mais informações, consulte Controlar o acesso aos modelos do Model Garden.
  • Proteção de dados: para descobrir e desidentificar dados sensíveis nos comandos, nas respostas e nos dados de registro, use a API Cloud Data Loss Prevention. Para mais informações, assista este vídeo: Como proteger dados sensíveis em apps de IA.

  • Endpoints de modelo compartilhados: para evitar abusos e garantir o uso justo de 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. Aplique as cotas fazendo o seguinte:

      1. Extraia a identidade do locatário do contexto do 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. Rejeitar solicitações de locatários que excedem os limites.

    • Gateway de API: para aplicar cotas por locatário usando chaves de API e planos de uso, implemente o gateway de API antes do endpoint compartilhado.

Considerações de segurança do MCP

Para garantir que sua implementação do MCP atenda aos requisitos de segurança, considere as seguintes recomendações:

  • Registro e descoberta de ferramentas: registre servidores e ferramentas MCP no Agent Registry para que os agentes se conectem apenas a endpoints MCP inventariados e aprovados pelo administrador.
  • Controle de acesso e inspeção de tráfego: roteie o tráfego do agente para o MCP pelo Gateway de Agente no modo Agente para qualquer lugar (saída) e proteja os servidores MCP (como os servidores MCP hospedados no Cloud Run) usando IAP e políticas de acesso do IAM. Configure o Model Armor ou as políticas de governança semântica no Gateway de Agente para inspecionar as entradas e saídas da ferramenta MCP em busca de exposição de dados sensíveis e injeção indireta de comandos.
  • Segurança geral do MCP: ao configurar seus agentes para usar o MCP, verifique se o acesso a dados e ferramentas externos está autorizado, implemente controles de privacidade, como criptografia, aplique filtros para proteger dados sensíveis e monitore as interações dos agentes. Para mais informações, consulte MCP e segurança.

Considerações de segurança do Cloud Run

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 controlado do Google Cloud .
  • Reduz a superfície de ataque do lado do cliente e ajuda a evitar 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.
  • Oferece codificação de saída centralizada para proteção contra ataques de scripting em vários locais (XSS).

Considerações de segurança do Security Command Center

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 as considerações e recomendações de design para criar e operar uma infraestrutura confiável para sua implantação no Google Cloud.

Considerações sobre a confiabilidade do Cloud Load Balancing

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 do Google mais próxima geograficamente. Essa configuração reduz a latência por meio da terminação de Secure Sockets Layer (SSL) de borda. Ele também ajuda a garantir alta disponibilidade se uma região sofrer uma interrupção, porque redireciona o tráfego de maneira inteligente para back-ends regionais íntegros.

Considerações sobre a confiabilidade do locatário

Para tolerar ou lidar com falhas no nível do agente, implante agentes em projetos de locatário 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 de negócios.

Considerações sobre a confiabilidade da Agent Platform

Se o número de solicitações ao modelo exceder a capacidade alocada, o modelo retornará o código do erro 429. Para cargas de trabalho essenciais aos negócios e que exigem uma capacidade de processamento consistentemente alta, é possível reservar capacidade de processamento usando a Capacidade de Processamento Provisionada.

Considerações sobre a confiabilidade do Agent Runtime

Para garantir que as configurações e o uso do Agent Runtime atendam aos seus requisitos de confiabilidade, considere as seguintes recomendações:

  • 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 temporá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 APIs de terceiros, processamento de conjuntos de dados massivos ou processamento intensivo 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 Well-Architected Framework.

Eficiência operacional

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

Considerações sobre o Google Cloud Observability

O Logging e o Cloud 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.

Considerações sobre eficiência operacional para todos os produtos da arquitetura

O uso da 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 ver o código do Terraform que pode ser usado para criar e implantar um sistema de IA agêntica multilocatário, 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 Well-Architected Framework.

Otimização de custos

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

Considerações sobre custos da Agent Platform

Para garantir que as configurações e o uso da Agent Platform atendam aos seus requisitos de custo, considere as seguintes recomendações:

  • Consumo de tokens: para gerenciar custos e evitar que o modelo de IA exceda as janelas de contexto, use as seguintes estratégias para gerenciar o contexto do modelo de IA:
    • Resumo de contexto: em vez de salvar uma conversa de sessão inteira como contexto, use um modelo de IA para resumir conversas mais antigas e informações menos críticas.
    • Remover saídas: identifique e remova partes menos relevantes ou detalhadas das saídas de ferramentas ou do contexto recuperado. Por exemplo, se você só precisa dos nomes das colunas dos seus dados, pode remover os metadados excessivos de uma busca de esquema de banco de dados. Essa estratégia requer uma lógica personalizada que usa heurística, 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 Plataforma de Agentes 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 próprias cotas do projeto, o que evita o impacto entre locatários. Em comparação com os endpoints compartilhados, os endpoints dedicados oferecem um gerenciamento de cotas 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, é possível hospedar um endpoint compartilhado no hub central de governança e segurança. Como todos os locatários compartilham o mesmo pool de cotas, para ajudar a 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 gateway de API. Em comparação com os endpoints dedicados, os endpoints 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.

Considerações de custo do Cloud Run

A instrumentação permite monitorar o desempenho, solucionar problemas e acompanhar 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 saber como instrumentar seu aplicativo, consulte Escolher uma abordagem de instrumentação.

Considerações de custo do Model Armor

Para aplicar uma governança rigorosa 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 os custos e a complexidade do sistema, filtre todos os comandos e respostas implantando o Model Armor exclusivamente no hub de roteamento.

Considerações de custo para todos os produtos da arquitetura

Para garantir que sua arquitetura atenda aos requisitos de custo, considere as seguintes recomendações gerais:

  • Infraestrutura compartilhada: os componentes de infraestrutura principal compartilhados, como o portal de front-end, o hub central de governança e segurança e a Agent Platform, podem reduzir os 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 de referência ou quando a sobrecarga do rastreamento granular superar os benefícios de custo.
    • Alocação proporcional: um modelo proporcional ou processo de estorno aloca custos compartilhados com base na proporção de custos diretos que cada locatário gera. Use esse modelo quando o consumo do locatário variar drasticamente 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. Uma alocação de modelo fixo permite cobrar taxas fixas por recursos dedicados premium em comparação com 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 monitorar com precisão o custo total de propriedade (TCO) do seu sistema de IA agêntica 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 conscientização de custos, consulte Promover uma cultura de conscientização de custos.

Para estimar o custo dos 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 do Terraform de IA agêntica multilocatária 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 de nuvem e infraestrutura

Outros colaboradores: