Tempo de leitura estimado: 11 minutos
Escalar agentes de Inteligência Artificial em serviços financeiros virou uma decisão que começa na arquitetura e se sustenta na governança e na operação. Quando um agente passa a consultar dados sensíveis, acionar APIs, resumir eventos ou apoiar decisões em atendimento, fraude, crédito e compliance, ele passa a compor uma camada crítica da operação.
A conversa muda de tom: o que importa é previsibilidade em produção, com trilha de auditoria, controle de acesso, custo visível e integração confiável com o ambiente que a empresa já precisa manter em operação.
A Gartner projeta que 40% das iniciativas agênticas serão canceladas até 2027 por falha de controle e ROI indefinido. É o mesmo hiato que o AI Index 2026 da Stanford mede em 88% de adoção de IA contra menos de 10% de uso escalado de agentes: todo mundo adotou, poucos sustentam em produção.
Os riscos que crescem com a escala
Essa escala não amplia só capacidade de processamento. Amplia, na mesma proporção, riscos específicos:
- Exposição regulatória: quando uma decisão do agente não tem trilha auditável;
- Risco de modelo: quando ele responde com dado desatualizado, lineage incompleto ou permissão além do necessário;
- Risco de terceiro: quando integrador, gateway ou modelo externo vira dependência opaca;
- Risco de custo: quando a conta cresce mais rápido que a governança sobre ela.
Um caso fora do setor financeiro dá a medida do problema em outra escala. Em uma apresentação no Databricks Data and AI Summit, Vikas Ranjan, da T-Mobile, descreveu uma operação que processa cerca de 700 TB de dados brutos por dia, com picos de 2 milhões de registros por segundo.
Em serviços financeiros, agentes não operam sobre dados neutros. Eles tocam jornadas com consequência material: atendimento, onboarding, prevenção a fraude, análise documental, suporte a times internos, observabilidade operacional e acesso a conhecimento regulatório. Cada uma dessas frentes depende de contexto confiável e de limites claros sobre o que o agente pode consultar, inferir e acionar.
Arquitetura de agentes precisa nascer com governança
Nem toda tarefa de um agente exige raciocínio aberto. Em bancos, três padrões de execução cobrem a maioria dos casos, e cada um responde a um perfil de risco diferente.
- Workflow determinístico: sem decisão do modelo no meio do caminho, aplicado a sanitização de texto, extração estruturada e formatação de saída. Risco baixo, repetição alta: o que sustenta o padrão é a previsibilidade.
- Orquestração sequencial: uma etapa depende da anterior, com um ponto de revisão humana antes da ação crítica. Um agente reúne contexto, outro estrutura a resposta, um terceiro aplica política de compliance antes de liberar. É o padrão certo quando o custo de errar é alto e a etapa final não pode ficar só com a máquina.
- Execução concorrente: tarefas independentes rodando ao mesmo tempo sobre o mesmo caso, por exemplo validação documental, checagem de política interna, consolidação de contexto operacional e classificação de prioridade de atendimento. Reduz o tempo total sem abrir mão de estrutura.
A escolha entre os três depende do risco da tarefa, não da novidade da tecnologia. Os três precisam operar dentro da infraestrutura corporativa, herdando identidade, auditoria e observabilidade do ambiente, em vez de reconstruir essas camadas para o agente.
Anthropic documenta o mesmo critério para arquitetura de agentes: soma-se complexidade só quando ela melhora o resultado de forma comprovável, porque autonomia plena troca previsibilidade por latência, custo e risco de erro em cadeia. Em banco, essa troca exige decisão explícita de arquitetura.
Boas práticas para colocar agentes em produção com menos atrito
Uma das recomendações mais fortes do caso T-Mobile é projetar para escala desde o dia 1. Esse princípio ganha ainda mais relevância em serviços financeiros, onde mudanças estruturais depois do crescimento aumentam custo, complexidade e exposição a risco.
Colocar agentes em produção, portanto, exige decisões que vão além da escolha do modelo. É preciso definir onde o uso de LLM realmente agrega valor, como os agentes acessam dados, quais controles valem durante a execução e como todo o sistema será observado e operado.
Um caminho pragmático inclui:
- Definir onde usar LLM: separar fluxos determinísticos daqueles que realmente exigem interpretação ou geração pelo modelo.
- Escolher a estratégia de orquestração: usar execução sequencial quando uma etapa depende da anterior e concorrente quando tarefas independentes podem acontecer em paralelo.
- Conectar agentes a dados governados: centralizar catálogo, linhagem e controle de acesso para definir quais informações cada agente pode recuperar.
- Criar observabilidade desde o início: instrumentar logs, alertas, monitoramento e runbooks antes da entrada em produção.
- Tratar custo como requisito de arquitetura: considerar consumo de modelo, recuperação, armazenamento e processamento durante o desenho da solução, e não apenas depois do aumento de uso.
- Distribuir conhecimento operacional: reservar tempo de sprint para documentação, base de conhecimento e transferência de ownership.
Esse último ponto é especialmente importante para escala. Equipes que operam agentes precisam reduzir a dependência de especialistas isolados e permitir que novos engenheiros entendam rapidamente a arquitetura, os fluxos críticos e os procedimentos de operação.
RAG como camada de conhecimento
Quando o agente precisa trabalhar com conhecimento corporativo, Retrieval-Augmented Generation (RAG) é uma das estratégias para fornecer informações atualizadas ao large language model (LLM) no momento da consulta.
Em vez de incorporar todo o conhecimento aos parâmetros do modelo, a arquitetura recupera informações relevantes de uma base e adiciona esse contexto ao prompt usado para gerar a resposta.
O fluxo se divide em três etapas:
- Ingestão e indexação: documentos, bases de conhecimento e dados operacionais são divididos em blocos, ou chunks. Cada trecho é convertido em uma representação vetorial por modelos de embeddings e armazenado em um índice de busca.
- Recuperação e reordenamento: a consulta combina busca vetorial semântica com busca léxica, como BM25. Modelos de reordenamento, como cross-encoders, priorizam os trechos mais relevantes antes de enviá-los ao LLM.
- Geração fundamentada: o LLM recebe os conteúdos recuperados como contexto para gerar a resposta e cita as fontes ou os trechos usados como referência.
RAG ou fine-tuning para conhecimento corporativo
Avaliamos fine-tuning como alternativa para incorporar conhecimento corporativo em ambientes bancários, mas descartamos essa abordagem na maioria dos cenários analisados.
| Critério | RAG | Fine-tuning |
| Atualização de conhecimento | Atualiza direto na base, sem retreinar o modelo | Exige novo ciclo de treinamento a cada mudança |
| Rastreabilidade da resposta | Cita a fonte usada na recuperação | Não referencia o documento de origem |
| Controle de permissão | Aplicado no momento da recuperação | Não existe nesse nível; fica só nos pesos do modelo |
| Custo operacional | Latência adicional de retrieval | Custo recorrente de retreinamento |
Essa escolha também tem trade-offs. A etapa de recuperação adiciona latência e amplia a arquitetura que precisa ser operada. Índices, pipelines de atualização, permissões, estratégias de recuperação, avaliação e monitoramento passam a fazer parte do produto.
Onde a arquitetura costuma perder qualidade
Chunking sem considerar o contexto
Dividir documentos apenas por quantidade fixa de caracteres ou tokens separa informações que deveriam permanecer juntas. Quando isso acontece, a recuperação perde contexto e a qualidade da resposta cai.
Estratégias como semantic chunking ou estruturas parent-child preservam relações entre os trechos e melhoram a qualidade do material enviado ao modelo.
Controle de acesso apenas na aplicação
Proteger somente a interface deixa uma lacuna na arquitetura. As regras de autorização também precisam valer na camada de recuperação.
Role-Based Access Control (RBAC) e Access Control Lists (ACLs) aplicados durante a busca restringem os documentos recuperados de acordo com as permissões de quem faz a consulta.
Em um banco, por exemplo, uma pessoa com acesso a relatórios operacionais não deveria recuperar trechos de documentos restritos à diretoria.
Conteúdo sem autorização não deve entrar no contexto enviado ao LLM.
Índice vetorial desatualizado
A qualidade das respostas também depende da atualização da base consultada. Quando um documento muda e o índice mantém uma versão anterior, o agente trabalha com informação defasada.
Reindexar toda a base a cada alteração aumenta custo e processamento. Uma estratégia de sincronização incremental com o Lakehouse atualiza apenas os dados alterados e reduz a necessidade de reprocessar todo o conjunto.
Operação na stack Databricks
Na stack Databricks, essas responsabilidades se distribuem entre diferentes componentes:
- Mosaic AI Vector Search: busca e recuperação sobre o índice vetorial
- Unity Catalog: governança, permissões e linhagem dos dados
- MLflow: avaliação de fidelidade e relevância das respostas
- Lakehouse Monitoring: acompanhamento de drift e qualidade ao longo do tempo
Agentes e RAG funcionam como sistemas de produção, não como uma chamada de LLM conectada a um prompt.
A qualidade final depende de toda a cadeia: dados, permissões, recuperação, orquestração, geração, avaliação, observabilidade e operação.
Projetar essas camadas desde o início reduz retrabalho quando o volume cresce e transforma um experimento com LLM em uma arquitetura capaz de operar em escala.
Maturidade antes de autonomia
Segundo o estudo Unlocking Enterprise AI, da Economist Impact com a Databricks (2024), 85% das empresas globais já usam IA generativa e a projeção chega a 99% até 2027. No mesmo estudo, 22% consideram sua infraestrutura pronta para IA e 37% avaliam que seus modelos estão preparados para produção. A adoção correu na frente da capacidade de sustentar.
A TreeID desenvolveu uma autoavaliação de maturidade para adoção de agentes de IA em produção. O questionário identifica lacunas de governança, dependências técnicas e pontos de risco operacional nas quatro camadas: dados, integrações, aplicações e observabilidade. Com o resultado, a organização define o que priorizar antes de ampliar a autonomia dos agentes.
Perguntas frequentes
Maturidade para produção depende de arquitetura, governança, controle de acesso, observabilidade, custo monitorado e integração com sistemas já existentes. Sem essa base, o agente continua sendo experimento.
Quando a tarefa é repetitiva, estruturada e de baixo risco, como sanitização, classificação simples ou formatação de saída. Nesses casos, previsibilidade vale mais do que flexibilidade.
Depende da dependência entre etapas. Fluxos sequenciais funcionam melhor quando há revisão humana ou aplicação de política antes da próxima ação. Fluxos concorrentes funcionam melhor quando tarefas independentes podem rodar em paralelo para reduzir o tempo total.
O risco está em quem acessa o dado, mas também em quem publicou a instrução, qual fonte foi usada, qual política estava ativa e qual ação foi executada. Sem controle central, auditoria e rastreabilidade ficam frágeis.
Custo precisa entrar no desenho desde o início. Isso inclui escolha de modelo, frequência de execução, concorrência, chamadas a APIs, retenção de contexto, reprocessamento e políticas de infraestrutura.
Mapear a maturidade atual de dados, integração, governança e operação. Sem esse diagnóstico, a empresa acelera a camada visível do agente, mas mantém fragilidades na fundação.
Conclusão
Escalar agentes de IA começa antes da escolha do agente. A autonomia só se sustenta quando dados, integrações, aplicações e observabilidade oferecem governança, rastreabilidade e mecanismos claros de intervenção.
Quanto maior a autonomia, maior precisa ser a capacidade de controlar o que o agente acessa, acompanhar como ele opera e intervir quando necessário. Em produção, escala depende menos de modelos mais capazes e mais de uma arquitetura preparada para operar com segurança, previsibilidade de custo e controle..
Fontes
- Stanford HAI. “The 2026 AI Index Report”. Universidade Stanford, 2026.
- Gartner. “Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027”. Junho de 2025.
- Anthropic. “Building Effective AI Agents”. Dezembro de 2024.
- Economist Impact e Databricks. “Unlocking Enterprise AI”. Novembro de 2024.
- Vikas Ranjan (T-Mobile). “Managing Databricks at Scale”. Databricks Data and AI Summit, 2025.