IA conversacional para bancos: o que funciona e o que falha

O que a IA conversacional realmente significa no setor bancário

Tirando o marketing, a IA conversacional é só isto: um cliente digita ou fala o que quer da mesma forma que diria a um caixa, e o software entende a intenção e responde ou executa a tarefa. Sem árvore de atendimento telefônico, sem "digite 2 para saldos".

O CFPB apresenta isso como uma escada de sofisticação, e os degraus importam:

• Chatbots baseados em regras funcionam com "decision tree logic or a database of keywords", de modo que o usuário fica "limited to predefined possible inputs". Pense em um menu de botões. Se você já leu nossa comparação entre agente de IA e chatbot baseado em regras, este é o degrau mais baixo.
• Chatbots NLU usam compreensão de linguagem natural para reconhecer a intenção por trás do texto livre, não apenas palavras-chave. O NatWest descreve seu assistente Cora como algo que trata consultas "through natural language processing and machine learning".
• Agentes baseados em LLM são o novo degrau superior. O CFPB observa que os bancos estão "moving from simple, rule-based chatbots towards more sophisticated technologies such as large language models".

O degrau que torna os LLMs seguros para o setor bancário é a geração aumentada por recuperação, ou fundamentação (grounding): o modelo responde a partir da própria base de conhecimento do banco em vez de seus pesos de treinamento. O DBS descreve o DBS Joy como algo que integra "large language models with the bank's proprietary knowledge base", permitindo "move beyond pre-programmed static answers to dynamic responses". O Wells Fargo vai além e projeta seu assistente para que nenhum dado pessoal chegue ao LLM.

Esta é a forma de um fluxo bem construído, e por isso a verificação de confiança no meio não é negociável:

O CFPB também é direto sobre o teto: os chatbots "may be useful for resolving basic inquiries, but their effectiveness wanes as problems become more complex". Isso não é uma crítica à tecnologia, é o objetivo de design. As ferramentas que as pessoas realmente gostam são as que conhecem seus próprios limites e recorrem a uma pessoa. Nosso guia sobre IA no atendimento ao cliente cobre esse limite em termos gerais; o setor bancário só eleva a aposta.

Onde já está funcionando: as implementações dos grandes bancos

A prova não está em uma apresentação de fornecedor, está nos próprios números dos bancos. Estas são as implementações principais, todas obtidas de salas de imprensa primárias:

Algumas coisas chamam a atenção. Primeiro, os casos de uso se concentram em consultas de alto volume e baixo risco: a Erica sinaliza tendências de saldo "in the next 7 days", enquanto o Eno alerta proativamente sobre "a double charge, an abnormally large tip amount, or potential fraud" e gera números de cartão virtuais específicos por comerciante. Segundo, as implementações inteligentes tratam a IA como uma porta de entrada, não como um muro. O Cora+ do NatWest encaminha com um resumo para que "the human agent can quickly understand what support the customer needs".

Terceiro, o alcance multilíngue é um verdadeiro diferencial, não uma nota de rodapé. Mais de 3 milhões de clientes do Wells Fargo de língua espanhola já usaram o Fargo mais de 160 milhões de vezes. Esse é o tipo de cobertura que é brutalmente cara de manter com pessoal humano e barata de adicionar com um agente treinado em histórico multilíngue.

A economia explica a corrida. A Juniper Research projetou que os chatbots bancários economizariam US$ 7,3 bilhões globalmente até 2023, ante US$ 209 milhões em 2019, o equivalente a 862 milhões de horas de trabalho, com os aplicativos móveis respondendo por 79% das interações. O CFPB coloca o valor unitário em US$ 0,70 economizados por interação. Se você quiser conferir esses números para sua própria equipe, nosso artigo sobre IA versus suporte humano ao cliente percorre a comparação.

O que os clientes realmente pensam

Esta é a parte que as páginas dos fornecedores pulam. Se você ler onde clientes bancários reais falam, a voz da frustração é mais alta, mais afiada e mais específica do que a do elogio, e vale a pena ouvi-la, porque ela diz exatamente o que evitar.

A reclamação mais raivosa é o loop que não escala, mesmo quando há dinheiro em jogo:

"I've had fraud happening on my card this week and I've never had such an excruciating experience with a bank... I had to threaten to reach out to KiFid [the Dutch financial ombudsman] for them to allow me to speak to a human. Also the AI will occasionally pretend to be a person too. It's all horrible."

Bitterboule80 on r/bunq

Esse é exatamente o "doom loop" contra o qual o CFPB alertava, acontecendo em um caso de fraude. O tema seguinte é igualmente constante: as pessoas querem um humano visível, e a confiança despenca no momento em que as coisas deixam de ser simples. Como disse um operador de fintech observando seus próprios clientes:

"i've seen customers be fine with bots for simple stuff but get wary as soon as money or disputes are involved."

thepillowco on r/fintech

Existe até um tipo de reclamação claramente bancário: o bot como um downgrade de um recurso que as pessoas já tinham. O desabafo de um cliente do Bank of America sobre ser empurrado para "ask Erica" em vez de simplesmente filtrar seus próprios extratos é um lembrete útil de que a IA conversacional não é automaticamente um upgrade em relação a uma boa caixa de busca.

Nada disso diz "não faça". Diz que a régua é a confiança, e que o modo de falha é específico e evitável. Os profissionais que já lançaram isso concordam com a solução. Do mesmo tópico do r/fintech:

"The key though is avoiding generic bots and keeping it rules-based, built for a specific domain/process/problem (especially in regulated areas like disputes), integrating with back-office data, and making handover to humans seamless."

Essa é a receita, nas próprias palavras de um cliente. Acertar o encaminhamento é o que separa as implementações que as pessoas toleram das que as fazem sair furiosas.

O que automatizar e o que entregar a um humano

Então, onde está a linha? Depois de ver muitas dessas implementações ao vivo, minha regra é simples: automatize a consulta, escale a decisão. Se responder à pergunta puder movimentar dinheiro, negar um produto ou invocar um direito legal, um humano fica responsável. Tudo o mais é território justo para o agente.

A coluna da esquerda é onde estão o volume e a economia, e é exatamente o trabalho de nível 1 que consome o dia de uma equipe de suporte. Ela se encaixa perfeitamente no que um bom agente de IA para helpdesk já faz bem: desviar o que é repetitivo, manter as respostas consistentes, registrar tudo. A coluna da direita é onde uma resposta errada vira um problema regulatório, então esses fluxos devem captar a intenção e depois encaminhar, nunca adivinhar.

O erro que mais vejo é equipes tentando empurrar a linha para a direita rápido demais, deixando o bot tentar lidar com contestações ou perguntas de empréstimo porque uma demo o fez parecer capaz. É assim que se acaba nos tópicos do r/bunq mencionados acima. Comece estreito, prove na coluna da esquerda, e expanda só quando sua taxa de desvio e a qualidade do seu escalonamento se mantiverem firmes.

A superfície de conformidade que o setor bancário acrescenta

É isso que torna o setor bancário diferente do suporte genérico. Uma resposta errada aqui não é apenas um cliente irritado, é uma instituição regulada potencialmente violando a lei federal. O CFPB disse isso claramente: um "poorly deployed chatbot can lead to customer frustration, reduced trust, and even violations of the law."

Então um bot bancário carrega uma superfície de conformidade que um bot de suporte genérico não tem:

Percorrendo a pilha:

• Tratamento de dados pessoais e de cartão. O Gramm-Leach-Bliley Act e a FTC Safeguards Rule exigem a criptografia das informações do cliente em trânsito e em repouso, além de um dever de notificação de violação em 30 dias. Se o fluxo puder tocar em números de cartão, a PCI DSS exige que o número da conta seja mascarado e tornado ilegível. Por isso, a ocultação em transcrições e registros não é opcional.
• Revisão humana de decisões automatizadas. Para clientes da UE, o artigo 22 do RGPD concede o direito de "not to be subject to a decision based solely on automated processing" que tenha efeitos legais ou significativos, ter um empréstimo negado é o exemplo clássico, além do direito à intervenção humana.
• A linha de alto risco da Lei de IA da UE. Segundo o Anexo III, a IA usada "to evaluate the creditworthiness of natural persons or establish their credit score" é classificada como de alto risco, acionando obrigações de supervisão humana e registro. Vale a pena ser preciso aqui: um bot de suporte que responde "qual é o meu saldo" não é automaticamente de alto risco, esse gatilho é o caso de uso de pontuação de crédito. Mas no momento em que um fluxo influencia uma decisão de crédito, ele cruza a linha.
• O padrão exigido dos fornecedores. Os bancos que compram uma ferramenta vão esperar um relatório SOC 2 Tipo II, que testa se os controles realmente funcionaram ao longo do tempo, não apenas se existem no papel.

O fio condutor de tudo isso é o mesmo padrão de design que os clientes estavam implorando: fundamentação, registro e uma saída para um humano. Três estruturas legais separadas exigem, cada uma de forma independente, o caminho de escalonamento. Se você está avaliando ferramentas, nossa nota sobre gestão do conhecimento com IA para equipes de suporte cobre como manter essa camada de conhecimento aprovado limpa, que é onde a precisão começa.

Como implantá-la sem enfurecer seus clientes

Juntando a voz do cliente e a superfície de conformidade, o roteiro fica claro. É isto que eu faria, em ordem.

Fundamente tudo, depois prove antes de ir ao ar. Restringir o agente à sua central de ajuda e aos documentos de política aprovados é o que o impede de inventar uma resposta, e é a mitigação que o CFPB pede implicitamente quando diz que bots genéricos são "ill-suited for tasks that require logic, specialized knowledge, or current data". Já vi isso falhar do jeito mais difícil: o bot de um cliente pagante fabricou uma alegação de produto e a enviou para clientes reais porque a busca não encontrou nada e o modelo preencheu a lacuna com dados de treinamento. A solução não é um modelo mais inteligente, é simular o agente primeiro contra milhares de tickets reais anteriores, para ver onde ele teria alucinado antes que um cliente visse.

Filtre por confiança e mantenha o humano visível. Defina um limite: abaixo dele, o agente rascunha para um humano ou encaminha em vez de responder ao vivo. Limite tentativas repetidas para nunca construir um doom loop. O recurso mais citado nas avaliações de bots bancários é o escalonamento contínuo, e é justamente o que foi negado aos clientes do r/bunq.

Mantenha os dados sensíveis onde devem estar. Quando integramos equipes de finanças e saúde, o filtro mais difícil é sempre o tratamento de dados. Um comprador precisava da garantia de que os dados de tickets com números de cartão e senhas permaneceriam em seu próprio ambiente; a resposta é que o agente raciocina sobre o tipo de pergunta e o estilo de resposta, com retenção personalizada e ocultação de dados pessoais, e nenhum dado de cliente é usado para treinar modelos. Essas são as perguntas que sua revisão de segurança deveria fazer a qualquer fornecedor.

Comece pelo nível 1, expanda com evidências. O escopo realista, repetido continuamente por operadores, é o desvio de nível 1: deixe o agente cuidar das perguntas de "quais são as taxas" e "como faço para sacar" que consomem o tempo de suporte, e encaminhe o complicado para uma pessoa. Expanda só quando sua resolução no primeiro contato se mantiver firme. Se você está montando uma equipe em torno disso, nosso guia de escalonamento para startups é um bom companheiro.

Experimente a eesel para suporte bancário e fintech

Se você é um banco, um credor ou uma fintech avaliando isso, a eesel é construída exatamente para o padrão acima. Ela se conecta ao helpdesk que você já usa, aprende com seus tickets anteriores e documentos de ajuda, e responde apenas a partir desse conhecimento aprovado, então desvia as consultas de nível 1 sem sair do roteiro. A parte que mais importa para uma equipe regulada: você pode simular o agente contra milhares dos seus tickets históricos reais antes que ele responda a um único cliente ao vivo, e depois ativar a autonomia gradualmente com roteamento baseado em confiança e um encaminhamento limpo a um humano.

Ela já opera em escala bancária: nosso agente lida com mais de 100 mil tickets em alemão por mês para uma plataforma de comparação de empréstimos, com controles SOC 2, RGPD e residência de dados na UE, e ocultação de dados pessoais no lado de segurança. O preço é baseado no uso, cerca de US$ 0,40 por ticket resolvido, sem taxas por assento, então você não paga por uma plataforma que ainda está testando.

Você pode experimentar a eesel gratuitamente, ou agendar uma demo se quiser passar pela configuração de conformidade e simulação com alguém primeiro.