Como a Alelo transformou seu atendimento com IA generativa com o Amazon Bedrock na AWS

Todos os meses, 746 mil pessoas acessam a FAQ da Alelo, e ainda assim continuam ligando para o call center. Isso sinaliza uma lacuna clara entre o conteúdo de autoatendimento e a resolução efetiva da dúvida do usuário. Foi exatamente isso que nos levou a repensar completamente o atendimento digital da Alelo. Nesta postagem você vai entender como a Alelo conseguiu melhorar o atendimento aos seus clientes utilizando IA.

Quando analisamos 2,3 milhões de registros da Central de Atendimento ao Usuário (CAU) da Alelo entre maio e setembro de 2025, um padrão saltou aos olhos. Ao longo desses cinco meses, 2,3 milhões de usuários distintos acessaram o serviço pela central telefônica. Desse universo, isolamos 1,6 milhão que também possuíam acesso ao aplicativo Meu Alelo, a base real para qualquer hipótese de migração de canal. Cruzamos os motivos de contato com a capacidade de resolução digital e identificamos, entre 221 tópicos, os cinco que concentravam quase 30% de todas as ligações e que poderiam ser resolvidos via assistente virtual: informações sobre produto ou aplicativo (~382 mil ligações), rastreio de cartões (~83 mil), cancelamento por perda (~32 mil), consulta de saldo (~16 mil) e informação sobre a próxima carga do benefício (~7 mil). Mais revelador ainda, sete dos dez temas mais frequentes no chat eram questões que não exigiam um atendente humano. A informação já existia na FAQ; os clientes simplesmente não conseguiam encontrá-la de forma eficiente.

De chatbot a assistente: por que decidiram mudar

O chatbot anterior operava com regras pré-programadas e menus fixos, um modelo que atende bem a fluxos previsíveis, mas que limita a experiência quando a demanda do usuário foge das opções disponíveis. Não havia compreensão de linguagem natural, não havia memória de contexto entre interações, era uma árvore de decisão vestida de chat.

Em parceria com a CI&T e a AWS, foi desenhado um assistente virtual baseado em IA generativa. A abordagem muda o paradigma de interação: em vez de navegar por menus numéricos e selecionar opções pré-definidas, o usuário descreve o que precisa com suas próprias palavras, como se estivesse conversando com uma pessoa do suporte. O assistente utiliza primeiro Processamento de Linguagem Natural (PLN) para entender a intenção. Em seguida, busca a resposta no conteúdo da FAQ. Por fim, responde de forma contextualizada ao usuário.

Escolhendo o modelo certo no Amazon Bedrock

Foram avaliados quatro modelos de linguagem disponíveis no Amazon Bedrock, considerando assertividade, completude, latência e custo por requisição. Nos testes iniciais, o Amazon Nova Pro mostrou bom equilíbrio entre custo e qualidade em cenários genéricos.

Quando colocamos os modelos contra o conteúdo real da nossa FAQ com as perguntas que os usuários realmente fazem no dia a dia, o Claude Haiku 4.5 se destacou na etapa de homologação. Enquanto os modelos Nova e Nova Pro perdiam consistência após algum tempo de conversa, confundindo contextos quando o usuário misturava tópicos, o Claude mantinha assertividade mesmo em diálogos longos com múltiplos assuntos da FAQ. Essa robustez em conversas multi-tópico foi o fator decisivo para a escolha de produção.

Após avaliação técnica, selecionamos o Claude Haiku 4.5 como modelo de produção.

Como ficou a arquitetura

A restrição mais forte do projeto era o prazo: quatro semanas até a produção. Isso eliminou qualquer abordagem que exigisse infraestrutura dedicada ou ciclos longos de configuração. Optamos por uma arquitetura 100% serverless na AWS, onde cada componente é gerenciado e escala automaticamente. Para a camada de busca semântica, avaliamos duas abordagens: montar um pipeline RAG customizado (com embedding manual, banco vetorial dedicado e lógica de chunking própria) ou utilizar o Amazon Bedrock Knowledge Bases, que encapsula todo esse fluxo. Escolhemos o Knowledge Bases pela velocidade de entrega (bastou apontar para o bucket do Amazon S3 com os documentos da FAQ), pela manutenção simplificada (reindexação automática quando a equipe atualiza a FAQ) e pela integração nativa com Bedrock. A alternativa de RAG customizado daria mais controle sobre a estratégia de retrieval, mas adicionaria semanas de desenvolvimento. Para o escopo da FAQ (documentos curtos e bem estruturados), o Knowledge Bases atendeu sem personalização avançada. Na camada de orquestração, escolhemos AWS Lambda em vez de containers porque o padrão de tráfego é request-response com picos previsíveis e sem processamento de longa duração.

Quando um usuário digita uma pergunta no aplicativo Meu Alelo, a sequência é direta: o aplicativo envia a mensagem via Amazon API Gateway para uma função Lambda que atua como orquestradora. Essa Lambda invoca o Amazon Bedrock Knowledge Bases, que converte a pergunta em embedding e busca os trechos mais relevantes da FAQ armazenada no S3. Com os trechos recuperados como contexto, a Lambda chama o Claude Haiku 4.5 no Amazon Bedrock para gerar uma resposta contextualizada. A resposta é retornada ao aplicativo. Quando o usuário avalia a resposta (like/dislike), essa informação é gravada no Amazon DynamoDB, permitindo curadoria contínua e identificação de gaps na FAQ.

Na segunda fase, que está em implementação, o Amazon Bedrock AgentCore foi adicionado. São múltiplos agentes especializados: um supervisor, um agente de serviços e um generalista, conectados às APIs internas da Alelo via Amazon API Gateway e funções Lambda. Isso permite consultas transacionais como saldo, extrato, promoções e status de cartão. O AgentCore Memory mantém o contexto entre sessões, e o AgentCore Observability confere rastreabilidade completa.

Quatro semanas até a produção

A implementação da primeira fase seguiu um ritmo agressivo: quatro semanas do kickoff ao usuário real conversando com o assistente.

Na primeira semana, definimos escopo, objetivos e critérios de sucesso. Em paralelo, fizemos uma revisão criteriosa da base de dados da FAQ (avaliando qualidade, relevância e cobertura dos conteúdos) e convertemos todo o material em arquivos Markdown, formato mais adequado para que o modelo de linguagem interprete as informações com precisão. Também configuramos o ambiente de infraestrutura na AWS, estabelecendo a base técnica da aplicação.

Com a infraestrutura pronta, a segunda semana foi dedicada ao desenvolvimento do chat em interface web. A decisão de construir via Webview (em vez de desenvolver nativamente para cada plataforma mobile) foi estratégica: a mesma interface funcionaria tanto no aplicativo Android quanto no iOS, reduzindo esforço de desenvolvimento e acelerando o prazo de entrega.

Na terceira semana, integramos o Webview ao aplicativo e entramos na fase de testes. Duas frentes foram prioritárias: a primeira garantiu que o assistente respondesse apenas dentro do contexto para o qual foi treinado, evitando respostas fora do escopo. A segunda focou em segurança, com testes para identificar e bloquear tentativas de injeção de prompt, técnica em que usuários mal-intencionados tentam manipular o modelo para que ignore suas instruções originais.

A liberação na quarta semana foi controlada, com rollout gradual. Selecionamos um grupo reduzido de usuários, priorizando os mais ativos e concentrando o lançamento na base Android, plataforma que representa o maior volume de usuários do aplicativo. Essa abordagem nos permitiu monitorar o comportamento da solução em ambiente real com menor risco, antes de expandir o acesso para toda a base.

Resultados do primeiro mês

Colocamos o assistente em produção completa em 14 de abril de 2026. Os números do primeiro mês deram confiança de que a Alelo estava no caminho certo:

• 17,5 mil acessos diários em média.
• Taxa de aprovação de 74% (6.901 positivas vs. 2.423 negativas em 9.324 conversas avaliadas), medida diretamente por avaliações dos usuários no formato like/dislike ao final de cada interação.

Analisando os feedbacks negativos, um padrão claro foi encontrado: a maior parte da insatisfação acontece quando o usuário pede algo que o assistente ainda não faz, como emitir segunda via de cartão, abrindo oportunidades para melhoria e evolução do chatbot.

O que não esperávamos

Um aprendizado que nos obrigou a recalibrar as projeções: descobrimos que 63% dos usuários que ligam para a CAU já usam o aplicativo ativamente. Isso significa que a migração de volume do telefone para o assistente não vai acontecer automaticamente. Parte dos usuários que hoje interagem com o assistente já consumia a FAQ antes, e não necessariamente ligava para a central.

Essa descoberta nos levou a revisar as projeções de economia com mais conservadorismo. Consideramos apenas os usuários com uso efetivo do aplicativo, e portanto com maior probabilidade de adotar o assistente como canal primário. O cálculo partiu do volume total de 520 mil ligações anuais nos cinco tópicos prioritários, aplicando o coeficiente de 63% (proporção de usuários que também usam o aplicativo) e o custo médio de R$ 2,18 por ligação. Com essa base (520.000 × 63% = 327.600 ligações elegíveis × R$ 2,18), projetamos uma economia anual de R$ 714 mil distribuída entre cinco funcionalidades prioritárias:

• Notificação proativa de status do cartão (~382 mil ligações/ano): R$ 474 mil.
• Rastreamento proativo de cartões (~83 mil ligações/ano): R$ 141 mil.
• Cancelamento por perda (~32,5 mil ligações/ano): R$ 56 mil.
• Consulta de saldos com sugestão de promoções (~16,7 mil ligações/ano): R$ 29 mil.
• Notificação de depósito de benefícios (~7 mil ligações/ano): R$ 12 mil.

O que vem pela frente

Organizamos o roadmap em quatro horizontes. O primeiro, já em produção, cobre o atendimento consultivo com os temas mais frequentes. Em seguida, vamos conectar o assistente ao resumo de gastos para apoiar o planejamento financeiro dos usuários. Depois, entram sugestões personalizadas de estabelecimentos e ofertas baseadas em localização e comportamento. O horizonte mais ambicioso prevê integração com Open Finance, posicionando o assistente como um conselheiro financeira que vai além dos benefícios Alelo.

Conclusão

Para a Alelo, este projeto não é apenas uma melhoria no atendimento. É uma mudança de modelo. Estamos migrando de um paradigma reativo, onde o cliente liga quando tem um problema, para um paradigma proativo, onde o assistente antecipa necessidades e oferece caminhos antes que o cliente precise pedir.

O primeiro mês confirmou a viabilidade técnica e a aceitação dos usuários. Do ponto de vista técnico, a arquitetura serverless absorveu 17,5 mil requisições diárias sem intervenção operacional e a um custo de US$ 0,0076 por requisição: o equivalente a aproximadamente US$ 4.000/mês para atender toda a base ativa. Do ponto de vista do usuário, a taxa de aprovação de 74% em mais de 9 mil conversas avaliadas indica que o assistente já resolve a maioria das dúvidas consultivas. Agora, nosso trabalho é expandir o escopo para que a conversa resolva cada vez mais.

Se você está pensando em substituir um chatbot baseado em regras por IA generativa, nossa recomendação é: comece pequeno, meça obsessivamente e deixe os dados dos usuários guiarem a expansão. O Amazon Bedrock oferece a flexibilidade de testar múltiplos modelos sem compromisso. Já o Amazon Bedrock Knowledge Bases simplifica enormemente a integração com sua base de conteúdo existente.

Sobre os autores

	Rodolfo D’Alessio é Customer Solutions Manager na AWS, atuando como parceiro estratégico de clientes do segmento financeiro no Brasil. Desde 2018 na Amazon, ajuda clientes a acelerar resultados por meio de jornadas estruturadas em FinOps, Segurança, Modernização e AI/GenAI. Engenheiro eletricista com MBA em Gestão de Projetos (USP/Esalq) e certificações AWS Solutions Architect e AI Practitioner.
	Leonardo Azize Martins é Arquiteto de Soluções para o segmento financeiro. Tendo trabalhado com desenvolvimento e infraestrutura de aplicações web em multinacionais. Quando não está trabalhando, Leonardo gosta de passar o tempo com a família e brincar com a filha.
	Esteffany Menezes é Customer Solutions Manager na AWS, baseada no Brasil, ajudando clientes do setor de Serviços Financeiros a acelerar suas jornadas na nuvem. Formada em Engenharia Elétrica pela Unicamp e com quase 10 anos de experiência em Inteligência Artificial, é apaixonada por transformar desafios técnicos complexos em valor real de negócio em escala.
	Bruno Montanha é Technical Account Manager na Amazon Web Services. Ele trabalha em parceria com clientes enterprise do setor de serviços financeiros, focado em tornar as operações em nuvem simples e eficientes por meio de orientação proativa em confiabilidade, segurança e otimização de custos.