A maioria dos projetos de agentes de IA em instituições financeiras não morre na demo. A demo funciona. O sponsor de negócio está convencido, o orçamento existe e o fornecedor já mostrou uma conversa de voz que soa humana. O projeto morre mais tarde, na décima reunião, quando chega à mesa de Riscos e alguém faz a primeira pergunta que ninguém preparou: onde ficam os registros de cada conversa e quem pode lê-los.
Este artigo explica o que acontece nessa reunião, o que as equipes de Riscos, Compliance e Segurança da Informação pedem para ver antes de aprovar um agente conversacional, e como chegar com as respostas prontas. No final há um checklist com as doze perguntas que um CISO faz, para que a due diligence seja a segunda reunião do projeto, e não a décima.
O que está acontecendo com os projetos de IA nos bancos da LatAm
Bancos, fintechs e seguradoras da região testam agentes conversacionais para cobrança, atendimento, originação e onboarding há dois anos. A maioria desses testes fica no piloto. As razões que aparecem nas conversas com equipes de operação se repetem: o projeto passou por Inovação e por Negócio, mas nunca foi desenhado para passar por Riscos.
A equipe de Riscos não é contra a IA. O trabalho dela é aprovar o que pode auditar e frear o que não pode. Quando um agente de IA chega a essa revisão sem registros reconstruíveis, sem uma resposta clara sobre o que acontece com os dados pessoais e sem um mecanismo para desfazer uma mudança em produção, a resposta é a única possível: o projeto fica congelado até segunda ordem. E “segunda ordem” costuma significar seis meses.
Os quatro bloqueios que congelam um projeto
Nas instituições reguladas da LatAm, os projetos de agentes de IA travam quase sempre por uma destas quatro razões. Cada uma tem uma pergunta concreta por trás.
1. Auditoria: ninguém consegue reconstruir o que o agente disse
Um regulador ou um auditor interno pode pedir, meses depois, o que exatamente o agente disse a um cliente, em qual canal, com qual versão do prompt e por que tomou aquela decisão. Se o fornecedor só entrega uma transcrição sem versão, sem rastreabilidade das ferramentas invocadas e sem registro de quem acessou aquela conversa, a resposta para Riscos é incompleta.
O que se pede para ver: registro por conversa com identificador, versão do agente que atendeu, ferramentas que consultou, acesso por perfil e retenção definida em contrato.
2. PII: os dados pessoais viajam para onde não deveriam
Em uma conversa de cobrança ou de originação, o cliente diz o CPF, o número da conta e o saldo. Se esses dados chegam sem tratamento a um modelo de linguagem de terceiros ou ficam escritos em logs, a instituição tem um problema de LGPD, além de um problema reputacional.
O que se pede para ver: onde a PII é detectada e bloqueada (idealmente na borda, antes de tocar o modelo), se fica tokenizada nos registros e quais fornecedores de modelo recebem quais informações.
3. Alucinação: o agente pode dizer algo que não deve
Em crédito, em seguros ou em saúde, uma resposta inventada não é um erro de produto: é uma consequência regulatória. Se o único controle sobre o que o agente diz é uma instrução dentro do prompt (“não mencione taxas que não estejam contratadas”), Riscos não consegue auditar, porque um prompt pode ser contornado com uma injeção.
O que se pede para ver: guardrails que rodam em código, antes e depois do modelo, com filtros obrigatórios que não podem ser desativados (injeção de prompt, exfiltração de dados, sinais de crise) e um catálogo fechado de ações que o agente pode executar. Também um foco temático: o que o agente faz quando perguntam algo fora do seu domínio.
4. Rede privada: “não pode sair da nossa rede”
Muitas políticas de segurança em bancos estabelecem que os dados de clientes não saem do perímetro da instituição, ou que só podem viver em infraestrutura dedicada. A maioria das plataformas de agentes conversacionais opera em nuvem compartilhada, e aí a conversa termina.
O que se pede para ver: opções reais de implantação (nuvem compartilhada com isolamento por organização, nuvem dedicada em conta própria, rede privada ou modelo híbrido para voz) e a arquitetura de criptografia documentada para a revisão do CISO.
Como é um projeto que passa por Riscos
Os projetos que chegam a produção em 1 a 3 semanas têm algo em comum: a revisão de segurança aconteceu no início, com o pacote técnico sobre a mesa, e não no final como uma surpresa. Na prática, isso significa três decisões tomadas antes do piloto.
A segunda reunião é com Riscos. Depois da reunião de negócio (volume, taxas atuais, custo por contato, KPI do piloto), a próxima conversa inclui o CISO ou a equipe de Compliance, com a arquitetura, o modelo de implantação e a lista de controles. Quanto antes a objeção aparece, mais barato é resolvê-la.
Os controles estão na plataforma, não no prompt. Versionamento de cada agente com histórico e comparação entre versões, implantação gradual (canary) para mudanças sensíveis, rollback imediato, QA de regressão por agente e guardrails determinísticos. Tudo isso pode ser mostrado na tela e auditado linha por linha.
Um só motor, aprovado uma vez. Quando a plataforma que opera a cobrança é a mesma que depois vai operar a originação ou o atendimento, a aprovação de Riscos é herdada. O segundo caso de uso não volta a começar do zero. Na Coru, essa lógica é a base dos Agentes ADI: originação, onboarding, transações, cobrança e atendimento sobre uma mesma plataforma, com uma única due diligence.
Que números levar para essa conversa
Riscos não se interessa por promessas de recuperação. Interessa-se pelos dados da plataforma que consegue verificar. Os que a Coru sustenta hoje, medidos em produção com clientes financeiros da LatAm:
- Resposta de voz em menos de 800 ms, do trunk SIP ao primeiro áudio.
- Primeiro agente em produção em 1 a 3 semanas; voz sobre trunk próprio em 2 a 5 dias.
- 70 % dos contatos resolvidos sem intervenção humana, com transferência a operador sob demanda.
- 53 % de redução de OpEx em operações de cobrança.
As certificações ISO 27001 e PCI DSS estão em processo; o desenho da plataforma toma seus requisitos como referência e a documentação de arquitetura e criptografia é compartilhada na due diligence. Dizer “em processo” com clareza faz parte da conversa com Riscos, e não é um obstáculo.
O checklist: as doze perguntas que um CISO faz antes de aprovar um agente de IA
Estas são as perguntas que aparecem, em uma ordem ou outra, em quase todas as revisões de segurança de um agente conversacional na região. Servem para preparar a reunião, avaliar um fornecedor ou revisar um projeto que já está congelado.
Auditoria e dados
- Onde fica o registro de cada conversa e quem pode lê-lo?
- O que acontece com um CPF, um CURP ou um número de conta quando o agente o ouve?
- Os dados pessoais viajam para um modelo de terceiros? Ficam em logs?
- Cada interação pode ser reconstruída: o que o agente disse, com qual versão e por quê?
Controle do comportamento
- O que impede o agente de dizer algo indevido? Está no prompt ou em código?
- Como se bloqueia uma injeção de prompt?
- O agente pode executar ações fora de um catálogo fechado?
- O que ele faz diante de um pedido fora do seu domínio: inventa, encaminha ou para?
Produção e implantação
- Como se testa uma mudança antes de ela chegar a 100 % do tráfego?
- Se o agente erra em produção, em quanto tempo se volta à versão anterior?
- Pode ser implantado em nuvem dedicada ou dentro da rede da instituição, se a política exigir?
- Quem acessa o quê: perfis, permissões e registro de cada ação administrativa?
Se não houver resposta para três dessas perguntas, o projeto não vai sair da revisão. Se as doze tiverem resposta documentada, a due diligence deixa de ser a etapa onde os projetos morrem e passa a ser a mais curta.
Baixar o checklist de due diligence para agentes de IA em instituições reguladas (PDF, com a resposta que um CISO espera em cada ponto).
Perguntas frequentes
Por que os projetos de agentes de IA travam na área de Riscos de um banco?
Porque chegam sem o que Riscos precisa para aprovar: registros reconstruíveis de cada conversa, tratamento documentado dos dados pessoais, controles sobre o comportamento do agente que estejam fora do prompt e um modelo de implantação compatível com a política de segurança da instituição.
Qual é a diferença entre um guardrail no prompt e um guardrail em código?
Um guardrail no prompt é uma instrução que o modelo pode ignorar ou que uma injeção pode contornar. Um guardrail em código é um filtro determinístico que roda antes e depois do modelo, não depende da interpretação do modelo e pode ser auditado.
Um agente de IA pode operar sem que os dados saiam da rede do banco?
Sim, se a plataforma oferece implantação em nuvem dedicada na conta do cliente, em rede privada ou em um modelo híbrido em que a voz é operada dentro do perímetro. Nem todas as plataformas oferecem; é uma das primeiras perguntas a fazer.
Quanto tempo um agente de IA leva para chegar a produção em uma instituição financeira?
Com a revisão de segurança feita no início e a plataforma já aprovada, entre 1 e 3 semanas. Com voz sobre um trunk SIP próprio, a conexão leva de 2 a 5 dias.
O que acontece se o agente erra em produção?
Em uma plataforma com versionamento e implantação gradual, a mudança é liberada primeiro para uma fração do tráfego, as métricas são monitoradas e, se algo degrada, volta-se à versão anterior imediatamente. Essa capacidade de rollback é um dos controles que Riscos pede para ver.
A Coru® opera agentes de IA para bancos, fintechs, seguradoras e BPOs na LatAm. Agentes ADI por etapa do ciclo de crédito e ADI Platform para operá-los em voz, WhatsApp e web, com guardrails em código, PII protegida e implantação onde a política exigir. Veja o Agente de Cobrança e Segurança e guardrails.