Construindo uma Plataforma de IA Agêntica Empresarial com Amazon Bedrock AgentCore

O verdadeiro gargalo não é o modelo — é tudo ao redor dele

Quem já tentou colocar um agente de Inteligência Artificial (IA) em produção sabe que o modelo em si raramente é o problema. O que trava o avanço é a infraestrutura ao redor: como garantir que múltiplas equipes trabalhem em um ambiente seguro, quem é responsável por cada modelo e ferramenta, como manter o controle de custos entre contas e como lidar com erros sem quebrar as fronteiras de cada time.

Para endereçar exatamente esse cenário, a AWS publicou uma arquitetura de referência detalhada para a construção de uma plataforma de IA agêntica empresarial usando o Amazon Bedrock e o Amazon Bedrock AgentCore. O post original descreve o modelo operacional multi-conta, o plano de controle da plataforma, um padrão de implantação repetível por equipe, gateways separados para inferência e ferramentas, e um pipeline de avaliação que controla a promoção de cada agente para produção.

O que é o Amazon Bedrock AgentCore

O Amazon Bedrock AgentCore oferece serviços modulares para construir, implantar e operar agentes em escala. Isso inclui runtime, gateway, identidade, memória, políticas, registro e avaliações. Por cima dessa base, o Enterprise Agentic AI Platform Blueprint adiciona os contratos empresariais como infraestrutura implantável: limites de conta, entrega de software, observabilidade, governança de custos e ciclo de vida completo dos agentes.

Princípios arquiteturais: cinco desafios comuns

A AWS identificou cinco categorias de desafios que aparecem repetidamente em clientes que tentam estabelecer uma plataforma de agentes:

• Acesso governado a modelos: toda requisição de inferência não confiável deve passar por um gateway aprovado. Esse gateway aplica as guardrails da organização (como o Amazon Bedrock Guardrails), restringe quais modelos e regiões cada equipe pode usar, e impõe limites de taxa, cotas de tokens e orçamentos por equipe.
• Acesso governado a ferramentas: os agentes devem descobrir e invocar apenas ferramentas aprovadas por meio de um gateway autenticado usando o Protocolo de Contexto de Modelo (MCP — Model Context Protocol), com funções de execução de menor privilégio e rastreabilidade.
• Entrega delegada: as equipes de produto precisam implantar e reverter mudanças de forma independente, dentro de limites pré-aprovados, sem depender da equipe de plataforma para cada deploy.
• Operações de frota e custos: diferentes perfis precisam de visibilidade entre contas sem ter acesso de escrita. Engenheiros de operações precisam de logs, métricas e traces. Donos de fluxos precisam ver custo por agente. Times de Operações Financeiras (FinOps) precisam de estorno por equipe via AWS Cost Explorer e pelo Relatório de Custo e Uso da AWS (CUR).
• Evidências e ciclo de vida: cada versão de agente precisa de comprovação em cada fronteira que toca — acesso a modelos, acesso a ferramentas, identidade, capacidade de reversão e desativação completa sem deixar resíduos.

Modelos operacionais: centralizado, descentralizado ou federado

A AWS descreve três modelos que as empresas costumam adotar para IA agêntica. No modelo centralizado, uma única equipe de IA e Aprendizado de Máquina (IA/AM) constrói e opera todos os agentes — a governança é consistente, mas essa equipe rapidamente vira um gargalo. No modelo descentralizado, cada unidade de negócio cuida dos seus próprios agentes, o que garante agilidade, mas gera drift nos controles, duplicação de esforço e perda de visibilidade de custos.

O blueprint implementa o modelo federado: uma equipe central de plataforma fornece serviços compartilhados e governados, enquanto as equipes de domínio mantêm a propriedade de seus agentes, ferramentas e dados. Para saber mais sobre como escolher o modelo adequado, a AWS disponibiliza a página de Modelos de Governança no AWS Prescriptive Guidance.

Os dois planos principais da arquitetura

Plano de controle da plataforma

A conta de plataforma publica templates versionados e interfaces, opera o Registro de Agentes da AWS e os Gateways de Inferência compartilhados, admite modelos e guardrails, orquestra releases revisados e agrega sinais de toda a frota. As equipes consomem essas capacidades por meio de código, descritores e pipelines — não por sessões de administrador ou tickets de deploy.

Célula de Workstream repetível

Cada produto ou domínio recebe uma fronteira isolada com um repositório de código próprio, um pipeline de carga de trabalho e três capacidades do Amazon Bedrock AgentCore: Runtime, Memória com escopo por ator e um Gateway que usa autorização AWS_IAM e expõe apenas os alvos de ferramentas aprovados. A célula também inclui chaves do Serviço de Gerenciamento de Chaves da AWS (AWS KMS — AWS Key Management Service) gerenciadas pelo cliente, tags, alarmes, orçamentos e um link de origem do Gerenciador de Acesso de Observabilidade (OAM — Observability Access Manager) do Amazon CloudWatch.

O ponto central dessa arquitetura é que uma célula pode ser implantada, falhar, ser revertida ou desativada sem coordenar com outra equipe. A unidade de escala é a célula de Workstream, não um agente configurado manualmente ou uma conta de carga de trabalho compartilhada.

Topologia de contas e camadas da solução

O blueprint define funções lógicas de conta que separam a governança empresarial, os serviços compartilhados de plataforma e a execução por equipe:

• Fundação de gerenciamento: AWS Organizations, AWS IAM Identity Center, políticas preventivas, auditoria, retenção e políticas de custo.
• Segurança e arquivo de logs: AWS CloudTrail, AWS Config, AWS Security Hub, Amazon GuardDuty e dados de auditoria retidos.
• Observabilidade: sink do CloudWatch OAM com logs, métricas, traces e visões de custo centralizados.
• Camada de plataforma de IA agêntica: caminhos dourados, catálogo de governança, guardrails, Gateways de Inferência compartilhados, aliases exatos de ferramentas, pipelines e interfaces operacionais comuns.
• Frota de Workstreams: cada produto, domínio ou fronteira regulada recebe uma ou mais células de não-produção e produção.

Essa topologia se integra a uma landing zone existente, onde os rótulos de Gerenciamento, Plataforma e Workstream descrevem responsabilidades, não uma estrutura fixa de três contas.

Políticas de controle de serviço e separação de responsabilidades

As Políticas de Controle de Serviço (SCPs — Service Control Policies) restringem as permissões máximas disponíveis para as contas de plataforma e Workstream. Elas complementam — mas não substituem — o Gerenciamento de Identidade e Acesso (IAM), as autorizações de gateway, as guardrails, as políticas de recursos e os controles de rede.

Alguns pontos-chave das SCPs no blueprint:

• Admissão de modelos e regiões: políticas da organização e funções de execução do gateway restringem a inferência a modelos aprovados e à região suportada.
• Aplicação de guardrails: os agentes não chamam provedores de modelos diretamente — toda inferência passa pelo gateway governado.
• Mutação exclusiva via pipeline: implantações diretas de desenvolvedores em contas de Workstream estão fora do modelo suportado.
• Governança de registro e gateway: a síntese do Gateway de Workstream falha quando um registro subscrito está ausente, alterado ou não aprovado.

Pipeline de Integração e Entrega Contínua (CI/CD) com portões de avaliação

O blueprint usa pipelines revisados de plataforma e de carga de trabalho para impor a seguinte sequência de promoção:

• Fonte e revisão: um pull request estabelece a revisão de fonte imutável.
• Build e síntese: o pipeline compila código, executa testes, cria o manifesto do agente, escaneia imagens, valida políticas e inspeciona a saída do AWS CloudFormation.
• Funções estáveis e transferência de permissões: o pipeline de carga de trabalho cria funções estáveis de Workstream e pausa. O pipeline de plataforma concede aliases exatos de ferramentas à função de Gateway correta — e só então o pipeline de carga de trabalho continua.
• Deploy em não-produção: o pipeline implanta Runtime, Memória, Gateway de Ferramentas, observabilidade, alarmes, orçamentos, tags e recursos de aplicação na fronteira de não-produção da célula.
• Avaliação do agente implantado: o portão invoca o Runtime real e mede regressão, qualidade, sucesso de ferramentas, comportamento de recusa, latência do primeiro token e custo. Cada chamada autorizada é pareada com um teste adversarial: o portão chama um modelo aprovado e confirma sucesso, depois chama um modelo não aprovado e confirma a negação. Se uma negação esperada estiver ausente, o portão reprova o build.
• Aprovação humana: um revisor examina as evidências implantadas, limitações conhecidas e riscos residuais.
• Promoção, observação e reversão: a promoção para produção usa a revisão aprovada e verificações de continuidade. O pipeline prova tanto o caminho de avanço quanto o de recuperação.

A desativação segue uma ordem estrita de dependências: as concessões de alias de plataforma são revogadas primeiro, depois o Gateway e as funções de ferramentas do Workstream, e por fim o Runtime, a Memória e os recursos de aplicação. Cada etapa é verificada antes de prosseguir, e um inventário final confirma que nenhum recurso residual permanece.

Segurança e governança em profundidade

O blueprint implementa defesa em profundidade por meio de controles de identidade, políticas, entrega, dados e evidências:

• Identidade e fronteiras de confiança: o AgentCore Identity e o Amazon Cognito fornecem credenciais de inferência de curta duração. AWS_IAM e SigV4 autenticam o tráfego de ferramentas.
• Segurança e admissão de modelos: a inferência flui pelo gateway governado, aplicando guardrails e listas de modelos permitidos antes de cada chamada.
• Autorização de ferramentas: o Gateway de Ferramentas invoca apenas aliases aprovados pelo registro. Políticas Cedar fornecem autorização, com um wrapper AWS Lambda para defesa em profundidade.
• Proteção de dados por tenant: as contas de Workstream isolam o estado da aplicação. A memória do AgentCore usa namespaces com escopo por ator e chaves KMS gerenciadas pelo cliente.
• Cadeia de suprimentos de software e release: fonte revisada, hashing de manifesto, builds reproduzíveis, escaneamento de imagem, validação de políticas, avaliação de runtime implantado, aprovação humana, reversão e teardown ordenado por dependência formam um único contrato de release.
• Auditoria, observabilidade e governança de custos: o CloudTrail e os dados de plano de controle retidos corroboram as evidências do pipeline. O OAM compartilha logs, métricas e traces com operadores centrais. Tags de alocação padrão, orçamentos, cotas e reconciliação do Relatório de Custo e Uso atribuem propriedade sem dar ao agente permissão de reescrever sua própria atribuição.

Frameworks suportados e experiência do desenvolvedor

Na escala empresarial, o plano de experiência do desenvolvedor é um catálogo de templates de agentes versionados e aprovados pela organização. O blueprint inclui templates de referência para Strands, LangGraph e CrewAI — mas qualquer framework pode ser usado, desde que o template preserve os contratos de gateway de inferência, gateway de ferramentas, identidade, política, avaliação e entrega.

As equipes de aplicação são donas dos prompts, da lógica dos agentes, das ferramentas e dos casos de avaliação. A equipe de plataforma é dona dos controles comuns e dos requisitos de release.

Como começar

A recomendação da AWS é clara: implante uma célula de Workstream representativa a partir do repositório do blueprint, prove seu ciclo de vida completo — onboarding, promoção para produção, reversão, observabilidade centralizada e desativação sem resíduos — e depois automatize células adicionais a partir da mesma base versionada.

O deployment e os recursos disponíveis são baseados na região eu-west-1 (Irlanda). Qualquer componente substituído, outra região ou um rollout organizacional mais amplo requer suas próprias evidências de disponibilidade, segurança, carga, reversão, observabilidade e teardown.

Recursos relacionados

• Enterprise Agentic AI Platform Blueprint no GitHub
• Arquitetura multi-conta para IA agêntica em produção na AWS (Prescriptive Guidance)
• Workshop: Construindo uma Plataforma de IA Agêntica Empresarial no Amazon Bedrock AgentCore
• Documentação do Amazon Bedrock AgentCore

Fonte

Building an Agentic AI Platform on Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/building-an-agentic-ai-platform-on-amazon-bedrock-agentcore/)