Agentes de IA para bancos: atendimento, risco e controles

Agentes de IA para bancos são papéis de software que executam tarefas definidas de atendimento e operações, como responder dúvidas sobre conta, preparar dossiês de casos e encaminhar exceções, dentro de permissões e regras de aprovação definidas pelo próprio banco. A versão que vale construir parte do controle: o agente lê apenas o que o seu papel exige, age apenas dentro de limites declarados e deixa um registro que um revisor consegue acompanhar. A capacidade importa, mas em uma instituição regulada são os limites que tornam essa capacidade utilizável.

Principais pontos

• Comece por um único papel, como a abertura de contestações ou a cobrança de documentos, e não por um assistente geral para o banco inteiro.
• Separe o que o agente pode ler, o que pode redigir e o que pode executar. Cada nível precisa de permissão e responsável próprios.
• Coloque os limites de aprovação no próprio sistema, e não apenas em um documento de política que o agente é instruído a seguir.
• Registre cada consulta, chamada de ferramenta e passagem de bastão, para que um revisor reconstrua o caso sem pedir ao agente que se explique.
• Trate o agente como um serviço operado, com monitoramento, avaliações e revisões de permissão, e não como um projeto pontual.

O que os agentes de IA para bancos fazem na prática?

Na prática, um agente bancário é um profissional com descrição de cargo estreita. Ele tem identidade própria, acesso a um conjunto específico de sistemas, memória do contexto que pode guardar e um caminho definido para entregar o trabalho a uma pessoa. A palavra superinteligente só faz sentido em um aspecto: o agente consegue manter mais contexto relevante do que um humano em determinado momento, como os casos abertos de um cliente, as regras do produto aplicáveis e as últimas notas internas. Isso não significa que o agente tenha autoridade.

O trabalho que se encaixa costuma ser repetitivo, baseado em documentos e limitado por regras que já existem. Alguns exemplos:

• Ler uma mensagem recebida de um cliente, identificar o tipo de solicitação e reunir o que falta antes de uma pessoa assumir.
• Preparar o resumo de um caso de contestação, reclamação ou alteração cadastral, com as fontes anexadas.
• Conferir um conjunto de documentos enviados com uma lista de verificação e apontar as lacunas.
• Redigir uma resposta no tom aprovado pelo banco para uma pessoa revisar e enviar.
• Acompanhar filas e sinalizar à equipe certa os itens próximos do prazo de atendimento.

O trabalho que não se encaixa, pelo menos no início, é qualquer um em que o resultado do agente movimente dinheiro, altere uma decisão de crédito ou mude a posição jurídica do cliente sem uma pessoa no circuito.

Por que o controle vem antes da capacidade?

Um banco não é reprovado em auditoria porque o agente não era inteligente o bastante. Ele é reprovado porque ninguém consegue mostrar quem ou o que fez algo, com base em quê e quem autorizou que isso acontecesse. Projetar primeiro para responder a essa pergunta muda a arquitetura.

O NIST AI Risk Management Framework organiza esse raciocínio em torno de governar, mapear, medir e gerenciar riscos. Para uma equipe de banco, isso se traduz em perguntas concretas: quem é o responsável por este agente, para que ele serve, como sabemos que está se comportando bem e o que fazemos quando não está. Se essas respostas existem antes do lançamento, as escolhas técnicas ficam mais fáceis, porque cada uma precisa servir a uma resposta.

Há também ameaças específicas de sistemas baseados em modelos de linguagem. O OWASP Top 10 for LLM Applications lista problemas como injeção de prompt, agência excessiva e divulgação de informações sensíveis. Um e-mail de cliente com instruções dirigidas ao agente não é hipótese em uma caixa de atendimento. A defesa é principalmente estrutural: o agente não deve ter ferramentas de que não precisa, o conteúdo vindo de fora do banco deve ser tratado como dado e nunca como instrução, e toda ação relevante deve exigir uma verificação que não dependa do julgamento do modelo.

O guia da Anthropic sobre como construir agentes eficazes faz um ponto parecido pelo lado da engenharia: comece pelo fluxo mais simples que resolva o problema e acrescente autonomia apenas onde ela se justifica. Em um banco, esse conselho pesa mais, porque cada grau a mais de autonomia precisa ser supervisionado, testado e explicado.

Por onde um banco deve começar?

Escolha o primeiro papel com um critério de decisão, e não por entusiasmo. Uma boa primeira tarefa atende à maior parte dos pontos abaixo.

• O trabalho chega em um padrão reconhecível, como um formulário, um tipo de mensagem ou uma fila.
• Já existe um procedimento escrito, e a equipe o segue na maior parte das vezes.
• Os erros são visíveis e reversíveis, por exemplo um rascunho errado que o revisor identifica antes do envio.
• Os dados necessários estão em poucos sistemas, que conseguem oferecer acesso restrito.
• Uma pessoa identificada responde pelo resultado e sabe dizer o que é um bom resultado.
• O sucesso pode ser observado, como menos casos parados por falta de documento ou primeira resposta mais rápida sem aumento de correções.

Uma tarefa que falha em vários desses pontos é um mau começo, por mais atraente que seja. São exemplos as conversas abertas de aconselhamento, qualquer coisa que envolva decisão de crédito ou trabalhos espalhados por sistemas aos quais ninguém consegue dar acesso restrito.

Outros negócios regulados e baseados em documentos passaram pelo mesmo exercício de seleção. O artigo sobre IA para corretores de crédito imobiliário mostra como a cobrança de documentos e as atualizações de status formam um primeiro papel bem delimitado, e a mesma lógica vale dentro das áreas de crédito de um banco. Para equipes que lidam com grande volume de contatos, a IA em operações de call center cobre revisão de qualidade e roteiros, que se aplicam bem aos canais de atendimento.

Como funcionam os limites de aprovação?

Um limite de aprovação é uma regra sobre quais ações o agente pode tomar sozinho, quais ele só pode propor e em quais ele não pode encostar. A forma útil de definir esses limites é pela consequência, e não pelo assunto. Uma única conversa com um cliente pode conter ações de todos os níveis.

Um modelo viável tem quatro níveis:

• Ler: o agente consulta informações a que tem direito para este caso e este cliente. Nada muda.
• Redigir: o agente prepara uma resposta, uma nota de caso ou um lançamento em formulário. Uma pessoa revisa antes de sair ou de ser salvo como definitivo.
• Agir com aviso: o agente executa uma ação de baixa consequência e reversível, como marcar um caso ou enviar uma confirmação padronizada, e registra para amostragem posterior.
• Agir com aprovação: o agente prepara uma ação relevante e espera um aprovador identificado. Ele não consegue concluí-la sozinho.

Algumas ações ficam fora dos quatro níveis e simplesmente não estão disponíveis para o agente: liberar recursos, alterar condições de crédito, isentar uma tarifa acima de um limite ou encerrar uma conta. Deixar essas ferramentas de fora é mais forte do que pedir ao agente que não as use.

O guia de autorização da OWASP é uma boa referência para aplicar isso. Use o princípio do menor privilégio, verifique as permissões a cada requisição e não apenas no login, e negue por padrão. Para um agente, isso significa que cada chamada de ferramenta é autorizada de acordo com o papel do agente e com o caso específico, e a verificação acontece no sistema que guarda os dados, e não dentro do prompt.

Dois detalhes práticos pesam mais do que parece. Primeiro, os aprovadores precisam de contexto suficiente para aprovar de verdade, então o agente deve apresentar as evidências que usou, e não apenas a conclusão. Segundo, as aprovações devem expirar ou ficar atreladas a um caso específico, para que uma aprovação permanente não vire, sem alarde, uma permissão ampla.

O que deve constar na trilha de auditoria?

Uma trilha de auditoria útil responde às perguntas do revisor sem depender da memória de ninguém. Ela deve ser gerada pelo sistema ao redor do agente, e não escrita pelo agente sobre si mesmo, porque o relato do modelo sobre o próprio raciocínio não é evidência.

Para cada caso, o registro deve conter:

• O gatilho: qual mensagem, evento ou agendamento iniciou o trabalho.
• A identidade e o papel sob os quais o agente operou, e a versão de suas instruções e ferramentas naquele momento.
• Cada fonte consultada, com a permissão que a autorizou.
• Cada chamada de ferramenta, com entradas, saídas e qualquer recusa por verificação de permissão.
• Os rascunhos produzidos, as edições feitas pela pessoa e a versão final enviada ou salva.
• Os pedidos de aprovação, o aprovador, a decisão e o horário.
• As passagens de bastão e escalonamentos, com o motivo.

As práticas de observabilidade ajudam aqui. Os conceitos de traces e spans do OpenTelemetry permitem acompanhar um caso por vários passos e sistemas, de modo que o revisor veja o caminho da mensagem recebida até a ação final como uma sequência conectada. Seja qual for a ferramenta usada pelo banco, o princípio é o mesmo: um caso, um caminho rastreável.

A trilha de auditoria também serve à operação, e não só ao compliance. Quando um cliente contesta o que lhe foi dito, quando um regulador pergunta como uma decisão foi sustentada ou quando uma equipe interna quer amostrar o trabalho, o mesmo registro responde. As equipes de auditoria interna podem usá-lo diretamente, tratando evidências e amostras do mesmo modo quando o trabalho envolve um agente.

Como é um caso de atendimento de ponta a ponta?

Este é um cenário ilustrativo, e não um caso real. Um cliente pessoa física escreve ao banco dizendo que um pagamento no cartão foi cobrado duas vezes e pede o estorno.

O agente primeiro identifica a solicitação como uma contestação de cartão e confirma a identidade do cliente pela etapa de verificação que o banco já tem, a qual ele não consegue contornar. Em seguida, lê o histórico de transações apenas daquele cliente, encontra duas cobranças parecidas no mesmo dia e busca o procedimento de contestação do banco e as condições do cartão aplicáveis. Ele observa que uma das duas cobranças ainda está pendente, o que altera o procedimento.

O agente redige uma resposta que explica o que encontrou e o que acontece a seguir, e monta um dossiê do caso: as duas transações, o procedimento aplicado, as informações que faltam e uma sugestão de categoria. Ele não consegue estornar nada. Coloca o caso na fila da equipe de contestações com o dossiê anexado e o marca como pronto para revisão.

Um analista de contestações abre o caso, vê as evidências em um só lugar, edita uma frase do rascunho, aprova a resposta e decide o caminho da contestação. O sistema registra cada passo: o que o agente leu, o que redigiu, o que o analista alterou e quando a decisão foi tomada. Se o cliente perguntar depois por que lhe informaram determinado prazo, a resposta está no registro.

O agente não decidiu nada com consequência financeira. Ele tirou o trabalho de coleta e preparação, manteve o contexto reunido e tornou a decisão humana mais rápida de tomar e mais fácil de defender.

Como uma operação gerenciada mantém isso sob controle?

Um agente orientado a controle precisa de operação contínua, porque as permissões se desviam, os procedimentos mudam e os sistemas são atualizados. Um plano sensato de implantação e operação é este:

• Defina um papel com um responsável de negócio identificado, um escopo escrito e um critério de sucesso observável.
• Mapeie os sistemas de que o papel precisa e conceda o acesso mais restrito que funcione, com credenciais separadas para o agente.
• Escreva os limites de aprovação por consequência e implemente-os nas ferramentas, e não apenas nas instruções.
• Monte um conjunto de avaliação com casos reais anonimizados do passado e rode-o antes de qualquer uso diante do cliente. O artigo da Anthropic sobre como desmistificar avaliações (evals) de agentes de IA é uma boa referência para estruturar isso.
• Rode o agente no modo somente rascunho, com a equipe revisando cada resultado, até que os revisores confiem no padrão das respostas.
• Amplie a autonomia uma ação por vez, apenas onde a amostragem mostrar qualidade consistente, e registre cada mudança.
• Revise permissões, registros e resultados de avaliação em intervalos regulares e depois de qualquer mudança nos sistemas ou nas políticas.

A Be Human projeta, implementa e opera esse tipo de infraestrutura para empresas. Um primeiro trabalho define um papel útil, a memória e as ferramentas de que ele precisa, os limites de aprovação e um critério de sucesso observável. A operação gerenciada pode então incluir monitoramento, avaliações recorrentes, manutenção de integrações, revisão de permissões, resposta a incidentes e melhorias controladas, com as pessoas da empresa mantendo o controle sobre o que o agente pode fazer. O serviço é remoto e disponível em inglês e português.

Para encontrar a primeira tarefa que vale entregar a um agente, faça o diagnóstico gratuito de IA da Be Human.

Perguntas frequentes

Um agente de IA pode aprovar um empréstimo ou movimentar dinheiro sozinho? Não em um projeto orientado a controle. O agente pode reunir documentos, conferi-los com uma lista de verificação e preparar uma recomendação, mas as decisões com consequência financeira ou jurídica ficam com pessoas identificadas. As ferramentas que liberariam recursos ou alterariam condições de crédito simplesmente não são dadas ao agente.

Como manter os dados dos clientes separados entre os casos? O acesso é restrito ao caso e ao cliente no momento da requisição e é imposto pelos sistemas que guardam os dados. O agente não leva os dados de um cliente para outra conversa, a menos que uma regra de memória definida permita. As verificações de permissão e as consultas ficam registradas para que um revisor confirme o que foi acessado.

Como testar um agente antes de ele falar com clientes? Monte um conjunto de avaliação com casos passados, sem os detalhes sensíveis, e meça se o agente segue o procedimento, cita as fontes certas e para onde deve parar. Depois rode no modo somente rascunho, com a equipe revisando cada resultado. A autonomia é ampliada aos poucos, e as avaliações continuam rodando depois do lançamento.

O banco precisa treinar um modelo próprio para isso? Em geral, não como ponto de partida. A maior parte do valor vem de dar a um modelo capaz o contexto, as ferramentas e os limites certos: consulta aos procedimentos vigentes, acesso restrito aos sistemas e caminhos claros de escalonamento. Treinar um modelo próprio pode ser considerado mais tarde, se as avaliações mostrarem uma lacuna específica que contexto e ferramentas não resolvem.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.