# Agentic RAG na AWS: Comparativo de Arquiteturas para Ambientes Financeiros

Agentic RAG deixou de ser experimento de laboratório e passou a ser requisito de plataforma em ambientes financeiros que exigem rastreabilidade, controle de custo e latência previsível. Neste artigo, comparo quatro abordagens arquiteturais concretas na AWS, com trade-offs reais, números plausíveis e uma recomendação sem rodeios.

- URL: https://fernando.moretes.com/blog/agentic-rag-confiavel-para-plataformas-enterprise

- Markdown: https://fernando.moretes.com/blog/agentic-rag-confiavel-para-plataformas-enterprise/article.md?lang=pt

- Published: 2026-06-13T12:00:00.000Z

- Category: IA & Agentes

- Tags: agentic-rag, bedrock, opensearch, eks, step-functions, financial-grade, governance, aws

- Reading time: 8 min

- Source: [Agentic RAG](https://research.google/blog/)

---

Quando o Google Research publicou sua análise sobre Agentic RAG confiável para plataformas enterprise, o sinal que captei não foi sobre modelos — foi sobre orquestração, governança e onde a responsabilidade de controle deve residir na pilha. Em ambientes financeiros onde cada chamada de LLM precisa ser auditável, cada falha de recuperação precisa ser rastreável e cada dólar de inferência precisa ser justificável, a escolha da arquitetura de orquestração de agentes não é detalhe de implementação: é decisão arquitetural de primeira classe. Tenho quatro candidatos sérios na AWS e vou colocá-los frente a frente.

## O Problema Real: Por Que RAG Simples Não Basta em Finanças

RAG clássico — embed, retrieve, generate — resolve o problema de conhecimento estático, mas quebra em três dimensões críticas para ambientes financeiros. Primeiro, **raciocínio multi-hop**: uma consulta como "qual é a exposição consolidada de crédito do cliente X considerando derivativos e posições em aberto de T-2?" exige múltiplos passos de recuperação com dependências entre eles, não uma única busca vetorial. Segundo, **uso de ferramentas**: calcular VaR, consultar um sistema de limites de crédito ou acionar uma API de preços em tempo real são ações, não documentos — e RAG simples não tem mecanismo de ação. Terceiro, **rastreabilidade regulatória**: em BACEN, CVM ou SEC, a cadeia de raciocínio que levou a uma recomendação ou decisão automatizada precisa ser reconstituível, não apenas o output final.

Agentic RAG resolve esses três problemas introduzindo um loop de planejamento-execução-observação (ReAct, MRKL ou variantes) onde o agente decide dinamicamente quais ferramentas invocar, em que ordem, e quando a resposta é suficientemente boa para encerrar. O custo dessa capacidade é complexidade operacional: loops de agente introduzem não-determinismo, latência variável, risco de loops infinitos e superfície de ataque expandida. A escolha arquitetural central é **onde esse loop vive** e **quem o controla** — e é exatamente aí que as quatro abordagens divergem de forma material.

## Os Quatro Candidatos: Identidade Arquitetural de Cada Um

**Opção A — Bedrock Agents nativo**: O agente vive completamente dentro do Bedrock. A AWS gerencia o loop ReAct, o roteamento de ferramentas (Action Groups via Lambda), a memória de sessão e a integração com Knowledge Bases (OpenSearch Serverless como backend vetorial). O operador define o prompt de instrução, as definições de ferramentas em OpenAPI schema e as guardrails. Latência de orquestração fica em torno de 800ms–1.5s por step de raciocínio para Claude 3 Sonnet, com cobrança por token de entrada/saída mais overhead de orquestração.

**Opção B — LangGraph + EKS**: O loop de agente roda em Python dentro de pods EKS, usando LangGraph para definir o grafo de estados. O time tem controle total sobre cada nó do grafo, transições, checkpointing de estado em DynamoDB e integração com qualquer backend de recuperação — OpenSearch Service (provisionado), pgvector no Aurora, ou Kendra. Latência de orquestração é determinística e controlável, mas a responsabilidade operacional é integral.

**Opção C — Step Functions orquestrado**: O loop de agente é externalizado para uma Step Functions Express Workflow. Cada step de raciocínio é um estado da máquina — invoke model, evaluate, branch, retrieve, tool call. O não-determinismo do LLM é contido dentro de estados individuais; a orquestração em si é determinística, auditável no X-Ray e replayável. Lambda executa as ferramentas; Bedrock ou SageMaker serve o modelo.

**Opção D — Híbrido Bedrock + Step Functions**: Bedrock Agents lida com o loop ReAct interno enquanto Step Functions orquestra o fluxo de negócio externo — validação de entrada, enriquecimento de contexto, chamada ao agente, pós-processamento, logging de auditoria. O agente é uma caixa preta controlada, não o orquestrador principal.

## Mapa Comparativo: Quatro Arquiteturas de Agentic RAG na AWS

Cada coluna representa uma arquitetura. As arestas mostram o fluxo de orquestração e recuperação. A linha de controle indica onde o loop de agente reside.

### 🟧 Option A — Bedrock Agents Native

- Bedrock Agent ReAct loop (managed) (ai)
- Knowledge Base OpenSearch Serverless (storage)
- Action Groups Lambda (OpenAPI) (compute)
- Guardrails + Session Memory (security)

### 🟦 Option B — LangGraph + EKS

- LangGraph Pod EKS (Fargate/EC2) (compute)
- OpenSearch Service Provisioned + kNN (storage)
- DynamoDB State checkpoint (data)
- Bedrock / SageMaker Model endpoint (ai)

### 🟩 Option C — Step Functions Orchestrated

- Step Functions Express Workflow (compute)
- Lambda Tool executor (compute)
- Bedrock InvokeModel per-step call (ai)
- X-Ray + CloudWatch Full trace per step (security)

### 🟨 Option D — Hybrid Bedrock + Step Functions

- Step Functions Outer orchestrator (compute)
- Bedrock Agent Inner ReAct loop (ai)
- S3 + CloudWatch Audit log sink (storage)

### Fluxos

- user -> ba_agent: A: invoke
- ba_agent -> ba_kb: retrieve
- ba_agent -> ba_tools: tool call
- ba_agent -> ba_guard: guardrail check
- user -> lg_pod: B: invoke
- lg_pod -> lg_os: vector search
- lg_pod -> lg_ddb: checkpoint state
- lg_pod -> lg_model: generate
- user -> sf_wf: C: invoke
- sf_wf -> sf_model: invoke per step
- sf_wf -> sf_lmb: tool dispatch
- sf_wf -> sf_xray: trace emit
- user -> hy_sf: D: invoke
- hy_sf -> hy_ba: delegate inner loop
- hy_sf -> hy_audit: audit log

## Dimensões Críticas: Onde Cada Arquitetura Ganha e Onde Sangra

**Auditabilidade regulatória** é onde Step Functions (Opção C) tem vantagem estrutural. Cada estado da máquina gera um evento no EventBridge e uma entrada no X-Ray com o payload completo — input, output, duração, erros. Em uma auditoria do BACEN, posso reconstruir exatamente o que o sistema decidiu em cada step de raciocínio para qualquer sessão histórica. Bedrock Agents (Opção A) fornece CloudTrail para chamadas de API e logs de invocação no CloudWatch, mas o loop interno de raciocínio é opaco — você vê o input e o output final, não os passos intermediários de pensamento, a menos que habilite trace explicitamente via `enableTrace: true` na chamada `InvokeAgent`.

**Custo de inferência** é o segundo diferenciador. Em Bedrock Agents, cada step de raciocínio consome tokens do prompt de sistema + histórico de conversa + contexto recuperado + resposta. Para Claude 3 Sonnet (us-east-1), isso significa aproximadamente $3/1M tokens de entrada e $15/1M de saída. Um agente com 5 steps de raciocínio e contexto médio de 4k tokens por step custa ~$0.08 por sessão. Em Step Functions Express, o custo de orquestração é $1/1M de transições de estado — praticamente zero — mas você ainda paga pelos tokens Bedrock. A diferença real é que Step Functions permite **interromper o loop mais cedo** com lógica determinística de avaliação, reduzindo steps desnecessários.

**Latência P99** é onde LangGraph+EKS (Opção B) pode surpreender negativamente. Cold starts de pods, overhead de serialização de estado no DynamoDB e latência de rede para OpenSearch Service provisionado podem empurrar P99 para 8–12 segundos em cargas de trabalho complexas. Bedrock Agents, por ser serverless gerenciado, tem P99 mais consistente em torno de 4–7 segundos para 5 steps, mas sem controle de tunning.

## Comparativo Técnico: Quatro Arquiteturas de Agentic RAG
| Critério | Dimensão | A — Bedrock Agents | B — LangGraph + EKS | C — Step Functions | D — Híbrido |
| --- | --- | --- | --- | --- | --- |
| Controle do loop de agente | AWS gerencia (caixa cinza) | Total (código Python) | Total (estados declarativos) | Parcial (outer controlado) | — |
| Auditabilidade regulatória | Média (trace habilitável) | Alta (custom logging) | Muito alta (X-Ray nativo) | Alta (SF trace + CT) | — |
| Latência P50 (5 steps) | ~3–5s | ~2–4s (warm pods) | ~3–6s | ~4–7s | — |
| Latência P99 (5 steps) | ~5–8s | ~8–14s (cold start) | ~6–10s | ~7–12s | — |
| Custo de orquestração (excl. tokens) | Incluído no Bedrock | EKS node hours (~$0.10–0.20/h) | ~$0.000001/transição | SF + Bedrock overhead | — |
| Guardrails e segurança | Nativo (Bedrock Guardrails) | Custom (código + WAF) | Custom (Lambda + WAF) | Bedrock + SF validation | — |
| Complexidade operacional | Baixa | Alta | Média | Média-alta | — |
| Portabilidade (multi-cloud / on-prem) | Baixa (lock-in Bedrock) | Alta (framework agnóstico) | Baixa (lock-in AWS) | Baixa (lock-in AWS) | — |
| Suporte a retrieval híbrido (sparse+dense) | Limitado (KB gerenciado) | Total (custom pipeline) | Total (via Lambda) | Parcial (KB + Lambda) | — |
| Time-to-production (equipe média) | 2–4 semanas | 8–16 semanas | 4–8 semanas | 5–10 semanas | — |

## Segurança e Governança: O Que o Comparativo Não Captura Completamente

Em ambientes financeiros regulados, a superfície de ataque de um agente RAG é qualitativamente diferente de uma API REST. O agente pode ser induzido via **prompt injection** a exfiltrar dados de contexto, invocar ferramentas não autorizadas ou bypassar guardrails. Cada arquitetura tem um perfil de risco distinto.

No **Bedrock Agents**, o Guardrails nativo oferece filtros de conteúdo configuráveis com categorias de harm (HATE, INSULTS, SEXUAL, VIOLENCE, MISCONDUCT, PROMPT_ATTACK) e word filters com listas customizadas — configuráveis via `CreateGuardrail` API com `contentPolicyConfig` e `wordPolicyConfig`. O problema é que Guardrails avalia o output, não o raciocínio intermediário. Uma injection que manipula o step de planejamento pode passar despercebida se o output final parecer benigno.

No **LangGraph+EKS**, a responsabilidade de segurança é total do time. Isso significa implementar: (1) input sanitization antes de qualquer chamada de modelo, (2) IAM roles com least-privilege por nó do grafo — um nó de retrieval não deve ter permissão de invocar APIs de pagamento, (3) KMS CMK para criptografia de estado no DynamoDB com `aws:kms` encryption type e chave por tenant em ambientes multi-tenant, (4) VPC endpoints para OpenSearch e Bedrock eliminando tráfego pela internet pública.

No **Step Functions**, a separação de estados cria uma oportunidade natural de inserir validação determinística entre steps — um estado `ValidateToolOutput` que verifica schema, range e permissões antes de passar o resultado para o próximo step de raciocínio. Isso é difícil de fazer de forma confiável em Bedrock Agents sem customização extensiva de Action Groups. Para ambientes com requisitos de LGPD/GDPR, Step Functions também facilita a implementação de **data residency controls** via condições de IAM `aws:RequestedRegion` em cada invocação de serviço.

## Matriz de Decisão: Qual Arquitetura para Qual Contexto

### A — Bedrock Agents Nativo

**Pros**
- Menor time-to-production (2–4 semanas)
- Guardrails e memória de sessão gerenciados
- Integração nativa com Knowledge Bases e OpenSearch Serverless
- Sem overhead operacional de infraestrutura de agente

**Cons**
- Loop de raciocínio opaco — auditabilidade limitada sem trace explícito
- Retrieval híbrido (BM25 + dense) não disponível nativamente no KB
- Lock-in forte em Bedrock; migração custosa
- Controle limitado sobre política de retry e backoff por tool

**Verdict:** Ideal para MVPs e times sem expertise em orquestração distribuída. Não recomendado para ambientes com auditoria regulatória de nível 1.

### B — LangGraph + EKS

**Pros**
- Controle total sobre o grafo de estados — testável unitariamente
- Suporte a retrieval híbrido customizado e re-ranking
- Portabilidade: pode rodar em qualquer cloud ou on-prem
- Checkpointing de estado persistente para sessões longas

**Cons**
- Alta complexidade operacional: EKS, HPA, cold starts, dependency management
- Time-to-production 3–4x maior que Bedrock Agents
- Segurança e guardrails são responsabilidade total do time
- P99 degradado por cold starts sem warm pool configurado

**Verdict:** Certo para plataformas de AI com equipes de ML engineering maduras que precisam de portabilidade e controle granular. Overkill para a maioria dos casos financeiros.

### C — Step Functions Orquestrado

**Pros**
- Auditabilidade máxima: cada step rastreado no X-Ray com payload completo
- Orquestração determinística com não-determinismo LLM contido
- Custo de orquestração virtualmente zero ($1/1M transições)
- Retry nativo com jitter, timeout por estado e compensação transacional

**Cons**
- Verbosidade do ASL para loops complexos — manutenção não trivial
- Limite de 25k caracteres por payload de estado (mitigável com S3 reference pattern)
- Não há memória de sessão nativa — precisa ser implementada externamente
- Loop de agente dinâmico requer Map state ou recursão — complexo de modelar

**Verdict:** Melhor escolha para fluxos de agente com número máximo de steps conhecido e requisitos regulatórios de auditoria de nível 1. Minha recomendação principal para bancos e corretoras.

### D — Híbrido Bedrock + Step Functions

**Pros**
- Combina velocidade de desenvolvimento do Bedrock com controle de fluxo do SF
- Auditoria de fluxo de negócio no SF; raciocínio interno no Bedrock trace
- Fácil de adicionar pré/pós-processamento determinístico ao redor do agente

**Cons**
- Dois sistemas de orquestração para operar e debugar
- Loop interno do Bedrock Agent ainda é parcialmente opaco
- Custo acumulado: Bedrock overhead + SF transitions

**Verdict:** Bom compromisso para times que já usam Bedrock Agents e precisam adicionar governança sem reescrever tudo. Não é a escolha ideal de greenfield.

## Observabilidade e SLOs: O Que Monitorar em Cada Arquitetura

Agentic RAG quebra os SLOs tradicionais de API porque a latência é uma função do número de steps de raciocínio, que é não-determinístico. Definir um SLO de P99 < 5s para um agente com até 8 steps é matematicamente impossível sem controle explícito de terminação.

Para **Bedrock Agents**, os sinais de observabilidade primários são: `InvokeAgent` duration no CloudWatch (métrica `InvocationLatency`), número de steps via trace parsing (campo `orchestrationTrace.rationale`), e taxa de `THROTTLING_EXCEPTION` que indica pressão no limite de TPS da conta (padrão: 10 TPS por modelo por região, aumentável via Service Quotas). Um SLO realista é P95 < 8s com budget de erro de 0.5% para throttling.

Para **Step Functions**, cada estado emite métricas nativas: `ExecutionTime`, `ExecutionsFailed`, `ExecutionsTimedOut`. Com OpenTelemetry, posso instrumentar o Lambda de cada tool com spans que propagam o `traceId` do Step Functions, criando uma árvore de trace end-to-end no X-Ray ou Datadog. O SLO mais útil aqui é **steps por sessão** — se P95 > 6 steps, há um sinal de que o prompt de sistema ou os documentos recuperados são de baixa qualidade, não que o sistema está lento.

Para **LangGraph+EKS**, o padrão que funciona é OpenTelemetry SDK com auto-instrumentation do LangChain, exportando para ADOT Collector no EKS e depois para CloudWatch EMF ou Datadog. Métricas críticas: `llm.token.usage` por nó do grafo (para controle de custo por step), `retrieval.hit_rate` (documentos relevantes / total recuperados) e `tool.error_rate` por tool name. Um `retrieval.hit_rate` < 0.6 em produção é alarme de degradação do índice vetorial — provavelmente drift de embeddings ou índice desatualizado.

> **O Paradoxo da Flexibilidade em Agentes Financeiros:** A arquitetura que dá mais flexibilidade ao agente (LangGraph com grafo aberto) é precisamente a que mais dificulta a auditoria regulatória. Em finanças, o objetivo não é maximizar a autonomia do agente — é maximizar a **previsibilidade do comportamento** dentro de um envelope de ações autorizadas. Isso inverte a intuição de quem vem do mundo de AI research: você quer o agente mais restrito que ainda resolve o problema, não o mais capaz. Step Functions força essa restrição de forma estrutural.

## Referências de Custo e Performance (Estimativas de Produção)

- **$0.06–0.12** — Custo por sessão (5 steps, Claude 3 Sonnet, 4k tokens/step). Válido para Opções A, C e D. Opção B adiciona ~$0.002/sessão de EKS amortizado
- **10 TPS** — Limite padrão de invocação Bedrock por modelo por região. Throttling é o principal limitante de escala para Opções A e D em picos. Solicite aumento via Service Quotas com justificativa de caso de uso.
- **25 KB** — Limite de payload por estado no Step Functions. Use o padrão S3 reference: armazene o contexto RAG no S3 e passe apenas o S3 URI entre estados para evitar o limite.

## Anti-Padrões Críticos em Agentic RAG Financeiro

- **Sem limite de steps**: Agentes sem `maxIterations` configurado podem entrar em loops infinitos consumindo tokens indefinidamente. Sempre configure um teto — 8 steps é razoável para a maioria dos casos financeiros.
- **Tool permissions excessivas**: Action Groups ou Lambda tools com IAM policies de `*` em recursos. Cada tool deve ter uma IAM role dedicada com permissões mínimas e `aws:ResourceTag` conditions para isolamento por tenant.
- **Contexto RAG sem filtragem de metadados**: Recuperar documentos sem filtrar por `tenantId`, `classification_level` ou `effective_date` no OpenSearch query. Em ambientes multi-tenant, isso é um vetor de vazamento de dados entre clientes.
- **Logging de prompts com PII**: Habilitar trace completo no Bedrock ou logar payloads de LangGraph sem mascaramento de CPF, conta bancária e dados de posição. Isso viola LGPD e cria risco de auditoria.
- **Embeddings estáticos em produção**: Indexar documentos uma vez e nunca reindexar. Drift de embeddings ao trocar de modelo de embedding invalida silenciosamente a qualidade do retrieval — monitore `retrieval.hit_rate` e reindexe ao trocar modelos.

> **Nota do Arquiteto: O Que Eu Faria de Fato:** Em qualquer ambiente financeiro regulado que eu arquitetei, a Opção C — Step Functions com Bedrock InvokeModel por estado — é o ponto de partida correto, não porque seja a mais elegante, mas porque é a mais auditável e a mais fácil de explicar para um time de compliance que nunca viu um agente de AI. A lição dura que aprendi é que a batalha de adoção de AI em finanças não é técnica — é de confiança institucional. Um fluxo Step Functions com estados nomeados (`EvaluateCreditQuery`, `RetrieveRegulatoryDocs`, `ValidateToolOutput`) que um auditor consegue ler no console da AWS vale mais do que um loop LangGraph perfeitamente otimizado que só o time de ML entende. Quando o negócio e a governança estiverem confortáveis, aí você evolui para o híbrido ou para LangGraph — mas comece pelo que você consegue defender numa reunião de risco.

## Veredicto: Step Functions Orquestrado é a Escolha Financeiramente Responsável

Para plataformas financeiras com requisitos regulatórios sérios — BACEN, CVM, SEC, LGPD — a **Opção C (Step Functions orquestrado)** é a recomendação principal. Ela entrega auditabilidade estrutural que nenhuma das outras opções oferece nativamente, custo de orquestração desprezível, retry e timeout determinísticos por step, e um modelo mental que times de compliance e engenharia conseguem compartilhar. O payload limit de 25KB é o único obstáculo real — resolvido com o padrão S3 reference em menos de um sprint.

**Bedrock Agents nativo (Opção A)** é a escolha certa para MVPs, provas de conceito e casos de uso internos onde auditabilidade de nível 1 não é requisito. Não a descarte — ela tem o melhor time-to-production e o menor overhead operacional.

**LangGraph+EKS (Opção B)** faz sentido apenas se você tem uma plataforma de AI com equipe de ML engineering dedicada, precisa de portabilidade real (multi-cloud ou on-prem) e está disposto a investir 3–4x mais tempo de engenharia. Para a maioria dos bancos e corretoras brasileiras, esse investimento não se justifica.

**O híbrido (Opção D)** é o caminho de migração — se você já está em Bedrock Agents e precisa adicionar governança sem 

**Rating:** Step Functions-Orchestrated (Option C) f

## Referências e Leitura Complementar

- [AWS Bedrock Agents — Developer Guide](https://docs.aws.amazon.com/bedrock/latest/userguide/agents.html)
- [AWS Bedrock Guardrails — Configuration Reference](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html)
- [AWS Step Functions — Express Workflows](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-standard-vs-express.html)
- [Amazon OpenSearch Service — k-NN Plugin](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/knn.html)
- [AWS Well-Architected Framework — Machine Learning Lens](https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/welcome.html)
- [LangGraph — State Graph Documentation](https://langchain-ai.github.io/langgraph/)
- [ReAct: Synergizing Reasoning and Acting in Language Models (Yao et al., 2022)](https://arxiv.org/abs/2210.03629)
- [Google Research Blog — Agentic RAG](https://research.google/blog/)