Crie agentes de IA escaláveis: uma arquitetura de referência orientada a sistemas para startups

Cada geração de desenvolvedores enfrenta uma mudança no nível de abstração. A linguagem de montagem deu lugar às linguagens de alto nível. Os sistemas monolíticos evoluíram para sistemas distribuídos. A infraestrutura on-premises deu lugar às plataformas nativas da nuvem. Agora, o próprio software está se tornando nativo da IA, moldado por modelos, contexto, agentes e fluxos de trabalho adaptativos. 

Na re:Invent 2025, Werner Vogels definiu claramente esse momento: os desenvolvedores que obtêm sucesso pensam em termos de sistemas e criam com precisão. As empresas que se destacam não são aquelas que adotaram a IA mais cedo ou escolheram o modelo mais avançado. São aquelas que pensam em sistemas completos, que compreendem que cada decisão arquitetônica tem repercussões nas camadas acima e abaixo dela. 

A pilha de IA moderna é frequentemente tratada como uma lista de verificação: escolher um modelo, integrar a recuperação de dados, adicionar orquestração e realizar a implantação. Os produtos baseados em IA fracassam quando seus componentes parecem impressionantes isoladamente. Eles são bem-sucedidos quando o sistema se comporta de maneira previsível sob cargas reais, equilibrando velocidade, confiabilidade, governança e custo. 

Peter DeSantis apresentou esse argumento sob a perspectiva da infraestrutura na re:Invent 2025. Os cinco princípios fundamentais pelos quais a AWS tem se dedicado há vinte anos — segurança, disponibilidade, elasticidade, agilidade e custo — são ainda mais importantes agora, e não menos. As workloads de IA agravam todas as fraquezas arquitetônicas. Um sistema que funciona com 100 usuários pode apresentar falhas estruturais ao atingir 10.000. Um modelo de custos que parece razoável na fase de protótipo pode se tornar insustentável em volume de produção. E uma abordagem de governança baseada em boas intenções não consegue passar por uma auditoria de segurança corporativa. 

Este artigo apresenta uma arquitetura de referência orientada a sistemas para criadores de modelos e equipes de SaaS nativas de IA que estão passando da fase de protótipo para a produção, composta por cinco camadas que revelam todo o seu valor quando atuam em conjunto.

Pense em termos de sistemas, não apenas de serviços 

Um erro comum no projeto de IA generativa é otimizar cada camada de forma independente. Uma equipe escolhe o “melhor” modelo. Outra escolhe o “melhor” armazenamento de vetores. Uma terceira opta por um framework de orquestração com base na familiaridade. Cada decisão pode parecer racional isoladamente, mas os usuários percebem o comportamento do sistema como um todo: velocidade de recuperação, qualidade da resposta, robustez do fluxo de trabalho, aplicação de políticas, isolamento de locatários e custo por serviço. 

Em softwares nativos de IA, esses resultados surgem das interações entre as camadas: como a identidade e as permissões influenciam a recuperação de dados e o acesso às ferramentas; como a atualidade do contexto determina a qualidade dos resultados; como a orquestração lida com novas tentativas, estado e etapas de longa duração; como a observabilidade abrange chamadas de modelos, fluxos de trabalho e lógica de aplicações; como os custos se acumulam entre armazenamento, inferência e execução de fluxos de trabalho. 

A melhor pilha de IA não é aquela cujos componentes, considerados individualmente, sejam os mais impressionantes. É aquela cujos ciclos de feedback geram um comportamento confiável e previsível do sistema. Sob essa perspectiva, apresentamos aqui uma arquitetura de referência prática para startups modernas nativas de IA na AWS. 

Camada 1: Base de dados e contexto

Todo produto de IA é construído sobre uma base de dados. Essa camada determina se o produto é capaz de fundamentar o comportamento da IA em um contexto duradouro e bem gerenciado. Em sistemas de produção, o contexto influencia a qualidade da recuperação de dados, o comportamento do modelo, a personalização e a confiança. Se essa camada for frágil, desatualizada ou mal gerenciada, a instabilidade se propaga para as camadas superiores. 

Na prática, são comuns quatro tipos de falhas: 

• Os dados de referência devem perdurar além de qualquer modelo ou estratégia de recuperação específica. Equipes que vinculam sua arquitetura de dados de forma excessivamente rígida a um modelo de incorporação específico muitas vezes precisam reconstruir toda a base sempre que o modelo ou o padrão de acesso muda. 
• O contexto deve ser organizado de forma a permitir um acesso rápido e relevante. A latência na recuperação de dados é um problema de qualidade do produto que se agrava em todas as camadas superiores. 
• O mesmo contexto que aumenta a precisão pode representar um risco se estiver desatualizado, for compartilhado em excesso ou não estiver devidamente isolado entre locatários. Limites bem definidos são essenciais para a precisão e a confiança, e não apenas para a conformidade.
• Dados não estruturados de longa duração, representações vetoriais e o estado operacional têm finalidades diferentes e devem permanecer arquitetonicamente distintos, mesmo quando coexistem em estreita proximidade.

O Amazon Simple Storage Service (Amazon S3) continua sendo o sistema oficial de registro de documentos, transcrições, artefatos e logs O S3 Vectors ampla essa base para o armazenamento nativo de vetores em escala de bilhões de vetores, preservando o modelo de elasticidade, durabilidade e disponibilidade do S3. Para um ISV que esteja desenvolvendo um produto de alto teor de conhecimento, o conteúdo regulatório, o histórico de interações com o cliente e as representações vetoriais que tornam ambos pesquisáveis podem ser armazenados nos mesmos buckets, sob as mesmas políticas de acesso, sem a necessidade de provisionar, escalar e proteger um banco de dados de vetores separado.

Uma equipe que antes gerenciava um banco de dados de vetores separado teria de lidar com o provisionamento, monitorar a integridade do índice e planejar eventos de escalonamento de forma independente do restante da infraestrutura. O S3 Vectors elimina completamente essa necessidade. Ele herda as mesmas políticas de acesso que já regem o armazenamento de documentos; portanto, não há estratégia de escalonamento separada, nem gerenciamento adicional de credenciais, nem novos pontos de falha a serem monitorados.

Os armazenamentos de vetores especializados ainda têm o seu lugar. O OpenSearch é a melhor opção quando a aplicação precisa combinar a correspondência exata de palavras-chave com a relevância semântica, ou quando a performance da recuperação precisa ser otimizada com menor latência. O Amazon Nova Multimodal Embeddings se torna importante quando os dados não são puramente textuais. Uma plataforma de inteligência contratual que processa PDFs digitalizados juntamente com registros estruturados, ou uma plataforma de mídia que indexa vídeos com transcrições, se beneficia de um espaço vetorial compartilhado em vez de fluxos de trabalho fragmentados.

Principais serviços: Amazon S3, Amazon S3 Vectors, Amazon OpenSearch Service (acelerado por GPU), Amazon Nova Multimodal Embeddings, Amazon Bedrock Knowledge Bases. 

Ponto de partida: Armazene os documentos de origem no S3 com isolamento de locatários baseado em prefixos desde o início e, em seguida, configure uma Base de Conhecimento Bedrock com base nesse bucket antes de criar qualquer lógica de recuperação personalizada.

Camada 2: modelo e serviço

Essa camada determina como o sistema gera inteligência e qual é o custo envolvido. A decisão não é qual modelo é o mais capaz, mas qual estratégia de modelo oferece o equilíbrio certo entre precisão, latência, custo e controle para cada tipo de workload. 

Um construtor específico para um determinado domínio (tecnologia jurídica, assistente de programação ou classificador de documentos financeiros) requer um nível de precisão exclusivo que um modelo de ponta genérico não consegue oferecer de forma consistente nem sustentar economicamente. Um fornecedor independente de software (ISV) moderno precisa de latência e custos previsíveis em volumes de consultas. E um usuário de inferência deve evitar pagar os preços de um modelo de ponta por tarefas rotineiras como roteamento, resumo ou extração de entidades, nas quais um modelo menor e otimizado apresenta performance equivalente por uma fração do custo. 

Para a maioria das equipes, o Amazon Bedrock é o ponto de partida ideal: uma paleta gerenciada com mais de 18 modelos de peso aberto, além dos modelos de ponta da Anthropic, com o Nova 2 na faixa de melhor performance, sem a carga operacional de manter uma infraestrutura de inferência. À medida que o produto amadurece, a pergunta certa muda de “qual modelo é o melhor?” para “quanto da nossa vantagem competitiva vem do comportamento do modelo proprietário em comparação com os fluxos de trabalho do produto proprietário?”. O Bedrock Reinforcement Fine-Tuning (RFT) pode melhorar a precisão em relação aos modelos base em tarefas específicas do domínio, tornando variantes menores, mais rápidas e mais econômicas viáveis em volume de produção. 

Para equipes que precisam de mais controle, o Amazon SageMaker AI AI é o nível gerenciado, mas controlado, destinado a desenvolvedores que precisam se aprofundar no ajuste fino, na avaliação, no MLOps e na implantação personalizada. É também a opção mais adequada quando o comportamento de modelos proprietários faz parte do próprio produto. Equipes que precisam de padrões de runtime que uma interface totalmente gerenciada não oferece, como streaming bidirecional para experiências nativas de voz, considerarão o SageMaker a opção mais prática. O streaming de áudio de entrada e transcrições parciais de saída tornam a interação fluida, em vez de limitada pela latência. 

Para equipes que estão desenvolvendo modelos de base do zero, o EC2 Trn3 (Trainium3) oferece um custo de treinamento 40% menor e uma produção de tokens 5 vezes maior por megawatt, com integração nativa ao PyTorch para que as equipes possam treinar e realizar a implantação sem alterar o código do modelo. O Amazon Elastic Kubernetes Service (EKS) é a opção ideal para equipes que precisam de controle total do runtime ou de pilhas de serviço especializadas. 

As decisões relativas ao nível do modelo definem o custo mínimo do sistema. Se todas as solicitações forem direcionadas por padrão a um modelo de ponta, os custos aumentam rapidamente à medida que são adicionados recursos de recuperação, agentes e fluxos de trabalho com várias etapas. Uma estratégia disciplinada de modelos mantém a capacidade alinhada aos requisitos da tarefa e evita que o custo do modelo acabe, sem que se perceba, prejudicando a rentabilidade do produto.

A página de preços do Bedrock oferece uma comparação atualizada de custos, modelo a modelo, entre tokens de entrada e saída. Fazer esses cálculos com base no volume de solicitações previsto é uma medida recomendável antes de finalizar sua arquitetura.

Principais serviços: Amazon Bedrock (inferência sem servidor, níveis de serviço), família Amazon Nova 2, Bedrock RFT, SageMaker AI, EC2 Trn3 (Trainium3).

Ponto de partida: Identifique quais das suas workloads exigem um modelo de ponta e quais poderiam ser gerenciadas por uma alternativa menor ou mais econômica, já que a diferença de custo aumenta rapidamente em grande escala. 

Camada 3: Inferência e runtime agêntico 

A inferência é o ponto em que a intenção arquitetônica se transforma em comportamento visível para o usuário. Essa camada controla a latência, o throughput, a concorrência, o estado da sessão, os padrões de interação com ferramentas, a qualidade sob picos de demanda e o custo por interação com o cliente. O desafio não está na capacidade, mas na confiabilidade, no isolamento e na consistência de custos em condições reais: múltiplos usuários, picos de demanda, chamadas de ferramentas que podem falhar e fluxos de trabalho que se estendem por minutos, em vez de milissegundos. 

Essa é a camada que determina se um ISV moderno pode vender para grandes empresas ou apenas para os primeiros usuários. Uma aplicação agêntica com excelente performance de modelo, mas sem isolamento de locatários, sem durabilidade do fluxo de trabalho e sem histórico auditável de chamadas de ferramentas, será reprovada em uma análise de aquisição, não porque seja tecnicamente incorreto, mas porque não é confiável no nível do sistema. 

O Projeto Mantle, o mecanismo de inferência subjacente ao Bedrock, aborda a confiabilidade e o isolamento no nível da infraestrutura. O roteamento por camadas de serviço permite que uma plataforma de inteligência contratual encaminhe a extração de cláusulas voltada para o usuário para uma via prioritária e a verificação regulatória em segundo plano para uma via flexível, otimizando custos sem prejudicar a experiência do usuário. O isolamento de filas por cliente significa que um pico nos uploads de documentos de um locatário não afeta a sessão de revisão ativa de outro locatário. O Journal, uma inovação fundamental do Mantle, verifica continuamente o estado da inferência para que um fluxo de trabalho de due diligence de longa duração que falhe aos 12 minutos seja retomado na marca dos 12 minutos, e não do zero.

O Amazon Bedrock AgentCore oferece o runtime de produção que, de outra forma, a maioria das equipes levaria meses para desenvolver: implantação de agentes em contêineres em qualquer framework (LangGraph, CrewAI, Strands Agents, OpenAI Agents SDK), memória episódica entre sessões, acesso a ferramentas baseado em MCP com aplicação de políticas via Cedar e avaliação contínua da qualidade por avaliadores em tempo real. Uma equipe jurídica de SaaS que opera sua própria infraestrutura de agentes normalmente precisa de vários engenheiros para gerenciar a containerização, o gerenciamento de sessões e a segurança das ferramentas. O AgentCore consolida essas responsabilidades em uma camada gerenciada, liberando essa capacidade de engenharia para a biblioteca de cláusulas, a taxonomia de riscos e as regras de políticas específicas para cada cliente que garantem a fechamento de negócios.

O princípio que determina o sucesso ou o fracasso desta etapa nos ciclos de vendas corporativas é a distinção entre mecanismos e boas intenções: 

Principais serviços: Amazon Bedrock (Project Mantle: níveis de serviço, isolamento de filas, Journal), AgentCore (Runtime, Memory, Gateway, Evaluations, Identity), Strands Agents, AWS Step Functions, Amazon Simple Queue Service (SQS). 

Ponto de partida: Enumere os requisitos empresariais que seu agente precisa cumprir e associe cada um deles a um mecanismo concreto, em vez de uma estratégia de prompt.

Camada 4: Orquestração e computação 

Esta é a camada em que a IA deixa de ser uma simples chamada de modelo e se torna um software. A maioria dos produtos de IA em produção consiste em sistemas de várias etapas que recuperam o contexto, invocam modelos, chamam ferramentas, validam resultados, ativam gatilhos para ações posteriores, armazenam os resultados e reentram nos fluxos de trabalho de forma assíncrona. A orquestração faz parte da arquitetura central da aplicação, não é um detalhe de implementação. 

Considere uma plataforma SaaS de serviços financeiros que realiza análises de contratos. Uma única solicitação pode envolver a importação de documentos, a divisão em blocos, a geração de incorporações, a comparação com acordos anteriores, o raciocínio em várias etapas sobre as cláusulas, o encaminhamento a um revisor humano e o gatilho de um fluxo de trabalho de conformidade posterior. Trata-se de um fluxo de trabalho de aplicação robusto, com lógica de ramificação, novas tentativas, transições de estado e etapas assíncronas que podem durar minutos ou horas, e não de uma simples chamada de inferência. 

Essa visão estrutural reflete o que tornou a computação sem servidor tão revolucionária: o objetivo não é simplesmente facilitar o gerenciamento da infraestrutura, mas eliminar categorias inteiras de gerenciamento de infraestrutura. O Lambda Managed Instances aplica esse princípio a uma lacuna comum. Algumas workloads exigem características computacionais específicas — como grande capacidade de memória para geração de embeddings, pipelines de pré-processamento de documentos ou inferência de modelos com uso intensivo de CPU — que são pesadas demais para simples funções sem servidor, mas não justificam o gerenciamento direto de uma frota. Uma startup que processa milhares de documentos jurídicos diariamente pode executar essas funções em perfis de instância específicos enquanto o Lambda gerencia do provisionamento, escalabilidade e aplicação de patches, mantendo uma arquitetura sem servidores sem assumir as operações da frota do EC2. 

Para equipes que precisam de um controle mais aprofundado do runtime, o EKS oferece a consistência e o controle necessários para desenvolvedores de modelos que utilizam servidores de inferência personalizados ou para equipes de plataforma que adotam o Kubernetes como padrão. 

O Amazon DynamoDB se encaixa naturalmente como o plano de controle transacional para o estado do fluxo de trabalho, metadados da sessão, configuração do locatário, chaves de idempotência, resultados de ferramentas e referências de auditoria. É a espinha dorsal operacional que mantém o aplicativo coerente à medida que o trabalho se move entre os serviços e as etapas do fluxo de trabalho. Isso é diferente da camada de memória semântica usada para recuperação.

O ambiente de desenvolvimento baseado em IA Kiro se encaixa nessa camada como um acelerador de entrega de software. Seu perfil é ajudar as equipes a transformar requisitos expressos em linguagem natural em projetos estruturados, especificações e tarefas de implementação, permitindo que as equipes avancem mais rapidamente, mantendo a coerência da arquitetura do sistema. 

Principais serviços: Lambda Managed Instances, Lambda Durable Functions, Amazon DynamoDB, Amazon EC2 M9g (Graviton5), AWS Step Functions, Amazon ECS no Graviton5, Amazon EventBridge, Amazon SQS. 

Ponto de partida: mapeie seu fluxo de trabalho no papel, identificando cada etapa que possa falhar, se ramificar ou ser executada de forma assíncrona, antes de escolher qualquer ferramenta de orquestração.

Camada 5: Governança, observabilidade e confiança 

É nesse ponto que muitas pilhas de IA ainda falham. As equipes tratam a governança como algo que pode ser acrescentado posteriormente. Agentes com amplo acesso a ferramentas, rigor de avaliação limitado e restrições vagas baseadas em prompts minam a confiança e criam barreiras à adoção. Qual é o princípio mais adequado? Mecanismos, não intenções. 

Os compradores corporativos fazem duas perguntas recorrentes antes de adotar um sistema de IA: vocês podem comprovar que nossos dados nunca ultrapassam os limites de cada instância? E podem provar que sua IA opera dentro dos limites que afirmam, com mecanismos que garantam o cumprimento desses limites e logs que mostrem o que aconteceu? 

Para um ISV do setor de saúde, isso significa um agente com escopo de conformidade com a HIPAA que não pode acessar registros fora do contexto autorizado pelo paciente. Para um provedor de SaaS de serviços financeiros, significa um assistente de pesquisa de investimentos cujas chamadas de ferramentas são limitadas por acordos de acesso a dados específicos do cliente. Esses são requisitos necessários para implantações corporativas regulamentadas, e não casos excepcionais. 

O Bedrock Confidential Computing aborda a questão do isolamento de dados no plano de inferência, protegendo os dados durante a execução e oferecendo um limite de runtime com maior garantia de segurança. Serviços como Bedrock, AgentCore, Lambda e S3 podem operar dentro de um modelo de identidade unificado, permitindo que a governança de acesso seja aplicada de forma consistente aos dados, à invocação de modelos e ao uso de ferramentas de agente, sem a necessidade de criar um sistema de autorização separado para cada camada. As mesmas políticas que regem o acesso aos dados também regem as chamadas de modelos e as permissões das ferramentas. Os logs de chamadas de ferramentas tornam-se, então, registros auditáveis do comportamento do sistema. 

A governança nesta camada também inclui controles de dados específicos para cada locatário, versionamento de modelos e prompts, rastreabilidade entre chamadas de ferramentas e fluxos de trabalho, visibilidade de custos por ambiente ou cliente e observabilidade de ponta a ponta nas camadas de aplicações, fluxos de trabalho e modelos. Não se trata de luxos arquitetônicos. São esses recursos que permitem às equipes analisar o comportamento do sistema, investigar incidentes na camada correta e comprovar a conformidade sem precisar reconstruir eventos a partir de logs brutos.

Para equipes que atuam na região EMEA, o contexto regulatório influencia várias dessas decisões arquitetônicas. Os requisitos do RGPD relativos à residência de dados significam que o isolamento de locatários não é apenas uma exigência comercial para as empresas, mas também uma exigência legal. O isolamento baseado em prefixos do S3 e a criptografia por locatário são os mecanismos práticos que atendem a essa exigência. A Lei de IA da UE introduz novas obrigações em relação à transparência e à supervisão humana para aplicações de IA de alto risco, o que se traduz diretamente em registros de auditoria e rastreabilidade de chamadas de ferramentas.

Observe que a disponibilidade do modelo do Bedrock, do S3 Vectors e do AgentCore não é uniforme em todas as regiões da AWS na EMEA. As equipes devem verificar a disponibilidade na região de destino antes de se comprometerem com uma arquitetura específica.

As equipes de startups também devem ter em conta que alguns dos serviços mencionados acima, incluindo o S3 Vectors e o AgentCore, são relativamente novos em ambientes de produção. Verifique se eles estão maduros para o seu caso de uso específico e para a sua região antes de adotá-los como infraestrutura principal.

Principais serviços: Amazon Bedrock (computação confidencial), AWS Identity and Access Management (IAM), Amazon CloudWatch, AgentCore Policy (Cedar), AgentCore Evaluations, AWS Security Hub. 

Ponto de partida: Decida o que seu log de auditoria precisa comprovar aos compradores ou aos responsáveis pela conformidade. Em seguida, trabalhe de forma retroativa a partir disso para definir as políticas e as ferramentas necessárias.

Como o sistema completo é integrado

Uma solicitação do usuário chega à aplicação. O runtime autentica a solicitação e determina o contexto do locatário. O conhecimento relevante sobre a memória e o produto é recuperado da camada de contexto. A camada de orquestração determina se a tarefa é uma simples interação com o modelo ou um fluxo de trabalho de várias etapas. A camada de inferência gera ou raciocina sobre a próxima etapa. As políticas restringem quais ferramentas podem ser invocadas. Etapas de longa duração verificam o estado e se recuperam de forma limpa em caso de falha. O sistema emite telemetria em cada estágio. Avaliações e ciclos de feedback medem a qualidade ao longo do tempo. As equipes de produto usam esses sinais para refinar prompts, atualizar políticas, melhorar a recuperação ou decidir quando uma personalização mais profunda do modelo é necessária. 

Isso é o pensamento sistêmico na prática. A arquitetura vencedora é aquela que integra dados, contexto, inferência, fluxo de trabalho, governança e operações em um sistema coerente que se comporta bem à medida que a empresa aumenta sua escalabilidade.

Para a maioria das equipes de startups, o ponto de partida é a Camada 1. Certifique-se de que sua base de dados e o isolamento de locatários estejam em ordem antes de lidar com agentes ou orquestração. A confiabilidade das camadas seguintes depende inteiramente da solidez da base subjacente.

Construa. Possua.

Uma pilha de IA bem projetada melhora o tempo de lançamento no mercado, a confiabilidade, a confiança e o controle de custos, não por causa de um único serviço, mas porque as camadas funcionam juntas como um sistema coerente. Quando a pilha é orientada a sistemas, as equipes podem desenvolver sua arquitetura à medida que a empresa cresce, sem precisar reconstruí-la do zero sempre que surge uma nova funcionalidade.