Inter usa Amazon Bedrock para transformar extratos bancários em assistente financeiro agêntico

O Inter, banco digital com mais de 45 milhões de clientes, colocou em produção um assistente financeiro conversacional construído sobre o Amazon Bedrock. Segundo post publicado no blog da AWS Brasil, assinado por Lucas Thaislo (AWS), Guilherme Mota, Liliane Nunes e Matheus Neves (Inter) e Nathalia Santiago (ACT Digital), a solução evoluiu de uma prova de conceito para um sistema agêntico com 13 domínios funcionais, medido entre fevereiro e julho de 2026. O material é um bom estudo de caso de arquitetura para quem desenha sistemas de IA generativa em produção com controle de permissão e multi-tenant real.

O problema

O ponto de partida não é técnico, é de produto: segundo a pesquisa Acrobacia Financeira do Inter (2025), 92% da população brasileira usa mobile banking, mas 74% sofre de ansiedade financeira, com picos de estresse de 8,6 em 10 em momentos de crise. O cliente tinha extrato, mas não tinha interpretação.

Para o time de engenharia, isso virou quatro requisitos concretos:

• Dados sem inteligência acionável: transações brutas, sem camada de recomendação.
• Escalabilidade do atendimento: qualquer solução baseada em crescimento de headcount para dar suporte personalizado a milhões de clientes é economicamente inviável.
• Diversidade de segmentos: pessoa física, pessoa jurídica, conta global e cliente residente no exterior precisavam de controles de acesso diferentes, idealmente sem implantações separadas por segmento.
• Latência e disponibilidade: resposta abaixo de 15 segundos, 24 horas por dia, incluindo madrugada e fim de semana.

Esse último ponto se confirmou no uso real: mais de 93 mil das 600 mil interações (15,5%) aconteceram entre meia-noite e seis horas da manhã, fora de qualquer janela de atendimento humano.

A arquitetura

O fluxo descrito no post, do cliente ao dado, segue este caminho:

1. O cliente abre o chat dentro do Super App do Inter e descreve o que quer em linguagem natural (um saldo, uma meta de gasto, uma antecipação de recebíveis).
2. Um orquestrador de IA generativa, chamado internamente de Seven, decide para qual agente especializado a conversa vai: Conta Digital, FAQ, Pagamentos ou outro domínio.
3. O agente de Conta Digital monta dinamicamente o conjunto de ferramentas disponíveis para aquela conversa, filtrando por permissão do produto que o cliente efetivamente contratou.
4. A chamada ao modelo de linguagem passa pelo LiteLLM, camada de abstração que aponta para o Amazon Bedrock.
5. Se o modelo precisa de dado real, ele aciona uma das mais de 13 ferramentas: consulta de transações no Amazon OpenSearch, consulta de categorias no Amazon DynamoDB, entre outras.
6. O resultado da ferramenta volta ao LLM, que compõe a resposta final em linguagem natural.
7. O DynamoDB persiste histórico de chat, metas financeiras e contexto de conversa, para a próxima interação não começar do zero.
8. A resposta chega ao cliente com latência média de 13,4 segundos e p95 abaixo de 18 segundos.

O desenho interessante aqui, para quem arquiteta sistemas assim, é que a permissão não fica só na borda (API Gateway, IAM, camada de autorização clássica). Ela entra na própria montagem do prompt: se o cliente não tem conta global, a ferramenta de consulta de extrato internacional simplesmente não existe na lista que o modelo enxerga.

Os serviços envolvidos

A pilha descrita no post combina serviços AWS com uma camada de orquestração própria do Inter:

• Amazon Bedrock: inferência do LLM, acessado via LiteLLM para permitir troca de modelo sem reescrever a camada de agente.
• Amazon DynamoDB: memória de longo prazo da conversa (histórico de chat, metas financeiras, contexto do LLM).
• Amazon OpenSearch: busca de transações, usado como uma das ferramentas acionáveis pelo agente.
• Seven: orquestrador proprietário do Inter que roteia a conversa entre agentes especializados por domínio.
• Mais de 13 ferramentas permission-gated: cada uma mapeada a um produto (extrato, cartão, boleto, antecipação de recebíveis, sala VIP, aprovação PJ, entre outros).
• Job de testes semânticos: roda cenários conversacionais contra o agente em produção e publica resultado no Slack.

Nenhum desses componentes é exótico isoladamente. O que diferencia a arquitetura é a combinação: Bedrock para raciocínio, DynamoDB para estado, OpenSearch para busca e um catálogo de ferramentas tratado como superfície de autorização, não só como função exposta ao modelo.

Trade-offs

Todo desenho de agente em produção financeira esbarra em pelo menos quatro tensões do Well-Architected.

Segurança. Fazer o controle de acesso na camada de montagem de ferramentas, e não só na API, reduz a chance de o modelo "alucinar" um dado que o cliente não deveria ver. O custo é operacional: cada novo produto do banco exige mapear explicitamente quais ferramentas ele libera, e qualquer erro nesse mapeamento vira incidente de exposição de dado, não só bug funcional.

Confiabilidade. Atender pessoa física, pessoa jurídica, conta global e residente no exterior com um único agente, em vez de implantações separadas, simplifica operação e deploy. Em compensação, aumenta o blast radius: uma regressão no agente único afeta todos os segmentos ao mesmo tempo, não um pedaço isolado da base.

Eficiência de desempenho. Com 13 ferramentas disponíveis e um orquestrador decidindo qual agente chamar, cada resposta pode envolver múltiplas idas e voltas ao LLM antes da resposta final. A latência média de 13,4 segundos é aceitável para um chat assíncrono, mas está longe do tempo de resposta de uma API REST tradicional, e qualquer novo domínio adicionado tende a empurrar esse número para cima, não para baixo.

Excelência operacional. Separar prompts e guardrails do ciclo de deploy do código permite iterar o comportamento do agente sem gerar uma nova implantação. Isso acelera o time de produto, mas descola a configuração do controle de versão de código, o que exige disciplina extra de auditoria e um processo de rollback de prompt tão maduro quanto o de rollback de release.

O agente de Conta Digital transforma a forma como nossos clientes interagem com sua vida financeira, de ler extratos passivamente a gerenciar seu dinheiro ativamente por meio de conversas naturais, 24 horas por dia.

Guilherme Ximenes, CIO Global no Inter

Custo estimado

O post da AWS não publica a fatura de infraestrutura do Inter, só o resultado de negócio: cerca de R$ 1 milhão (perto de US$ 180 mil) em economia estimada de deflexão de atendimento, em cinco meses e meio, com base em dados internos do banco.

Para quem vai orçar algo parecido, os drivers de custo ficam claros no próprio desenho da arquitetura, mesmo sem número fechado:

• Inferência no Bedrock é cobrada por token de entrada e saída, e varia por modelo escolhido na conta; um fluxo com orquestrador mais roteamento mais agente especializado tende a gerar mais de uma chamada de LLM por turno de conversa, o que multiplica o consumo de token em relação a um chatbot de resposta única.
• DynamoDB em modo on-demand se encaixa bem num tráfego irregular como o do Inter, com 15,5% das interações concentradas na madrugada: não há necessidade de provisionar capacidade para o pico de horário comercial o tempo todo.
• OpenSearch como ferramenta de busca de transação soma um componente de cluster que precisa ser dimensionado à parte da conta de inferência, com seu próprio custo de storage e de nó.

Um caminho razoável para controlar a conta, que o post não detalha mas que é prática comum em arquiteturas desse tipo, é reservar o modelo mais caro do Bedrock para o raciocínio do agente especializado e usar um modelo menor e mais barato só para a etapa de roteamento do orquestrador, que não precisa do mesmo nível de capacidade.

Como adaptar

O padrão do Inter serve de referência para qualquer time de arquitetura que precise expor dados sensíveis a um agente de IA sem abrir mão de controle de acesso granular. Alguns pontos valem ser copiados literalmente:

1. Monte a lista de ferramentas por permissão em tempo de execução, não em tempo de build. O modelo nunca deve receber a definição de uma função que ele não tem autorização para chamar.
2. Separe memória de raciocínio: use um banco de baixa latência como o DynamoDB para o estado da conversa, deixando o LLM livre para focar em decidir qual ferramenta chamar, não em lembrar o que já foi dito.
3. Trate prompt e guardrail como configuração, não como código, mas só se você também tiver testes automatizados rodando contra produção, como o job que o Inter publica no Slack. Sem isso, desacoplar prompt do deploy vira risco, não agilidade.
4. Faça rollout progressivo por público interno antes do cliente final: o Inter lançou primeiro para os próprios colaboradores ("Sangue Laranja"), depois para os segmentos premium WIN e PRIME, e só então para a base completa.

A lista de próximos passos do Inter, com motor de insights proativos, integração a WhatsApp, Siri e Amazon Alexa, Open Finance e portabilidade salarial via conversa, dá uma pista de até onde esse tipo de arquitetura escala quando o orquestrador e o catálogo de ferramentas são tratados como plataforma, e não como feature isolada.

Fonte: AWS Brasil — Blog oficial (pt-BR)