Quando a IA erra com convicção: o novo desafio da segurança bancária

“Quando a IA erra, ela erra com convicção.”

Saí da Febraban Tech 2026, realizada entre 24 e 26 de agosto de 2026,, com essa frase na cabeça. Passei os últimos dias pensando no que ela cobra de quem opera segurança em um banco. Ainda estou formulando uma visão mais completa. Mas tenho uma convicção: o maior risco de um agente de IA não é simplesmente produzir uma resposta errada. É tomar uma decisão ou executar uma ação autorizada com base nesse erro, sem hesitar, sem demonstrar dúvida e, muitas vezes, sem disparar um alerta.
Por isso, a segurança da IA agêntica não pode começar no dia do lançamento. Ela precisa ser construída antes da primeira interação com o cliente e continuar operando enquanto o agente muda, acessa ferramentas e executa ações.

Uma nova camada de confiança

No palco da Febraban Tech, os agentes de IA apareceram como uma possível terceira camada de confiança do sistema financeiro.
O Pix consolidou a confiança na transação. O Open Finance desenvolveu mecanismos de confiança para o compartilhamento de informações. Agora, os agentes exigem que o cliente confie simultaneamente no banco, no humano e no software que interpreta o contexto e age em seu nome. Essa nova camada é diferente porque o agente não apenas consulta uma informação. Dependendo da arquitetura e das permissões recebidas, ele pode:

• Acessar dados pessoais e financeiros.
• Consultar sistemas internos.
• Recomendar produtos.
• Iniciar ou apoiar transações.
• Acionar APIs e outras ferramentas.
• Compartilhar informações com outros agentes.
• Tomar decisões dentro de fluxos automatizados.

Quanto maior sua autonomia, maior precisa ser a capacidade do banco de identificar, limitar, observar e interromper seu comportamento.

Três perguntas essenciais

As discussões do evento podem ser organizadas em três perguntas que deveriam anteceder qualquer agente colocado em produção.

O que o agente pode fazer?

A autenticação confirma quem está tentando acessar o ambiente. Ela não responde, sozinha, quais ações deveriam ser permitidas em cada contexto. O agente precisa ter identidade própria, permissões mínimas, escopo de atuação definido e limites proporcionais ao risco. Em uma arquitetura segura, ferramentas e funções ficam restritas ao necessário, permissões de leitura e escrita são separadas e operações sensíveis exigem autorização explícita.
Em um banco, “ter acesso” e “poder executar” não podem significar a mesma coisa.

A ação é adequada?

Um agente pode estar autenticado, ter permissão técnica e, ainda assim, tentar realizar uma ação inadequada para aquele cliente ou contexto.
Esse é um problema de suitability aplicado a um software que interpreta situações e toma decisões. O controle não pode analisar apenas a identidade: precisa considerar perfil do cliente, finalidade, momento, valor envolvido, risco da ação e regras do negócio.
A pergunta deixa de ser apenas “o agente tem permissão?” e passa a ser: o que este agente pode fazer por este cliente, neste momento e sob quais condições?
Essa decisão precisa resultar de políticas verificáveis, e não somente da interpretação probabilística do modelo.

O que acontece quando ele erra?

Controles preventivos são necessários, mas não eliminam todos os erros. Modelos podem alucinar, perder contexto, interpretar incorretamente uma instrução ou ser manipulados por dados externos.
O problema é que um erro convincente pode passar pela revisão humana justamente porque parece correto. Se o agente executa ações, a organização precisa registrar decisões, chamadas de ferramentas, autorizações e resultados, além de detectar comportamentos anômalos e manter trilhas de auditoria.
Também precisa existir uma resposta operacional: bloquear a ação, reduzir privilégios, isolar o agente, solicitar aprovação humana ou reverter o fluxo quando isso for tecnicamente possível. Essa capacidade pode ser apoiada por SOAR, com automação, orquestração e resposta, desde que os limites e critérios de aprovação estejam claramente definidos.

O agente muda em produção

Um agente de IA não deve ser tratado como um software estático.
Quando o modelo é substituído, o comportamento pode mudar. Quando alguém altera o prompt, uma nova regra é criada. Quando uma ferramenta entra no fluxo, a superfície de ataque aumenta. Quando a memória é atualizada, o contexto utilizado nas próximas decisões também pode ser afetado.
Cada uma dessas alterações funciona, na prática, como uma nova release em produção. A validação dessas mudanças exige engenharia, testes e automação, capacidades que podem ser estruturadas com apoio de Professional Services especializados em cibersegurança.

Por isso, cada alteração deveria gerar:

• Registro da mudança.
• Avaliação de risco.
• Testes de segurança.
• Validação das permissões.
• Testes de comportamento esperado e inesperado.
• Revisão dos casos de uso afetados.
• Plano de reversão.
• Monitoramento reforçado após a mudança.

Segurança de agentes, portanto, não é um teste executado uma vez. É uma capacidade contínua de governança, validação e resposta, integrada a uma estratégia mais ampla de resiliência cibernética na era da IA.

Antes de expor ao cliente

Um dos relatos apresentados no evento chamou minha atenção: um banco S1 trabalhou durante 20 meses na construção de sua plataforma de segurança de IA antes de expor qualquer recurso ao cliente. O processo incluiu Red Team procurando alucinações e falhas de contexto.
A mensagem mais importante não é que toda instituição precise repetir exatamente esse prazo. É que segurança e governança devem acompanhar o agente desde a concepção, em vez de aparecerem como uma etapa de homologação no fim do projeto.
Os controles também precisam ser proporcionais ao risco. Um assistente interno que resume documentos não exige necessariamente o mesmo nível de supervisão de um agente autorizado a iniciar um pagamento, recomendar um investimento ou alterar dados cadastrais.
Segurança durante a execução.

Em fevereiro de 2026, o Gartner publicou o primeiro Market Guide for Guardian Agents. A categoria reúne agentes voltados a supervisionar outros agentes, verificando se suas ações permanecem alinhadas aos objetivos e limites definidos pela organização.
A existência dessa categoria reforça uma mudança importante: proteger apenas o modelo, a aplicação ou a API não basta. É preciso observar o comportamento do agente durante a execução.
Na prática, essa camada precisa fazer parte de uma operação contínua de SecOps, conectando detecção, resposta, hunting e contexto de negócio. Ela deve ser capaz de:

• Identificar o agente e a versão em execução.
• Conhecer as permissões e ferramentas disponíveis.
• Registrar decisões e chamadas realizadas.
• Confrontar ações com políticas de segurança e negócio.
• Detectar desvios de comportamento.
• Interromper ações de alto risco.
• Encaminhar exceções para revisão humana.
• Preservar evidências para auditoria e investigação.

Não se trata de substituir controles existentes por outro agente. Trata-se de adicionar visibilidade e aplicação de políticas ao ponto em que a decisão acontece.

O desafio operacional

Os bancos brasileiros preveem investir R$ 50,4 bilhões em tecnologia em 2026, crescimento de 8% sobre o ano anterior. A Pesquisa Febraban de Tecnologia Bancária também posiciona cibersegurança, cloud, inteligência artificial e IA generativa entre as prioridades estratégicas do setor.
A previsão específica para IA, Analytics e Big Data chega a aproximadamente R$ 3 bilhões. Ao mesmo tempo, 92% das instituições identificam ganho de velocidade em tarefas rotineiras como benefício da IA, enquanto 48% apontam avanços na detecção e prevenção de fraudes.
A velocidade, porém, amplia tanto o valor quanto o impacto potencial do erro.
Quanto mais rapidamente um agente consulta, decide e executa, menor é a janela disponível para identificar uma ação inadequada. Isso faz com que observabilidade, identidade, políticas, automação de resposta e contexto de negócio precisem operar no mesmo ritmo.

Do log ao contexto

Para quem opera segurança, o desafio não será apenas coletar mais logs. Será entender o que cada ação representa para o negócio.
Um acesso autorizado pode ser tecnicamente legítimo, mas incompatível com o perfil daquele cliente. Uma chamada de API pode estar dentro da permissão concedida, mas produzir um efeito financeiro fora do comportamento esperado. Uma recomendação pode parecer correta isoladamente, mas ser inadequada quando confrontada com contexto, política ou risco.
É aqui que a integração entre dados de infraestrutura, aplicações e negócio ganha relevância. O BSOC da DataRunk conecta detecção de ameaças, inteligência transacional e visão de negócio em uma operação única, construída para monitorar riscos no fluxo do dinheiro.
Em um ambiente de agentes, essa convergência permite que a operação não pergunte somente “houve uma violação técnica?”, mas também:

• A ação fazia sentido para aquele cliente?
• O comportamento era esperado para aquele agente?
• O agente utilizou uma ferramenta fora de seu fluxo habitual?
• A decisão respeitou as políticas vigentes?
• O efeito financeiro foi compatível com o contexto?
• É necessário bloquear, investigar ou solicitar validação humana?

Sem contexto de negócio, a operação enxerga atividade. Com contexto, ela enxerga risco.
Essa convergência é parte da evolução do SOC para um Cyber Fusion Center no setor financeiro: uma estrutura capaz de correlacionar sinais técnicos, comportamentais e transacionais antes que uma ameaça se transforme em perda financeira ou incidente regulatório.

Por onde começar

Se eu estivesse estruturando essa camada hoje, começaria por seis frentes:

1. Inventário: identificar agentes, modelos, responsáveis, ferramentas, dados acessados e ambientes em que operam.
   Identidade e privilégio mínimo: atribuir uma identidade a cada agente e conceder somente as permissões necessárias para sua finalidade.
2. Políticas de adequação: transformar regras de segurança, negócio e suitability em condições verificáveis antes da execução.
3. Testes adversariais: testar prompt injection, perda de contexto, abuso de ferramentas, escalada de privilégios, vazamento de dados e comportamentos inesperados.
4. Observabilidade durante a execução: registrar decisões, chamadas, autorizações, versões, resultados e desvios de comportamento.
5. Resposta: definir quando bloquear, reduzir autonomia, exigir aprovação humana, isolar o agente ou acionar a gestão de incidentes.

O objetivo não é impedir a adoção da IA. É criar condições para que a autonomia cresça sem ultrapassar a capacidade de controle da instituição.

A camada ainda está nascendo

Não tenho a resposta inteira para o que acontece quando um agente erra com convicção. Sei que ela não está no dia do lançamento. Está na arquitetura, na identidade, nos limites, nos testes, na observabilidade e na capacidade de resposta construída antes e operada depois.
Também sei que o Brasil costuma escrever esse tipo de infraestrutura antes de existir uma ferramenta completamente pronta. Foi assim no Pix e no Open Finance.
Agora, o setor financeiro começa a construir sua terceira camada de confiança: aquela que permitirá que agentes atuem sem transformar a autonomia em falta de controle.
Se você está montando essa camada agora, converse com a DataRunk. Podemos apoiar o diagnóstico, a arquitetura, a automação e a operação contínua dessa nova camada de segurança.