Há algumas semanas, durante uma reunião de planejamento de produto em uma fintech de médio porte, ouvi do head de engenharia: “Nosso modelo de IA para análise de crédito está performando muito bem, mas começamos a detectar padrões estranhos nos dados de entrada — parece que alguém está tentando envenenar o dataset.” Essa frase, que até pouco tempo atrás soaria como roteiro de ficção científica, é hoje o tipo de alerta que ecoa em departamentos de segurança do mundo inteiro. O setor financeiro, historicamente na vanguarda da adoção tecnológica, está colhendo os frutos da inteligência artificial — e também enfrentando uma nova classe de ameaças que não existia há cinco anos.
A Shield Security, conforme noticiado recentemente, escolheu o palco do FEBRABAN TECH 2026 para acender um sinal de alerta sobre essa nova superfície de ataques mediados por IA. Não se trata de mais um aviso genérico sobre riscos cibernéticos. Estamos falando de vetores de ataque que exploram exatamente aquilo que torna a IA poderosa: sua capacidade de aprender, generalizar e operar com base em dados — e que, quando manipulada, se volta contra os próprios sistemas que deveria proteger.
Por que a IA cria uma superfície de ataque genuinamente nova?
Toda tecnologia introduz riscos, mas a IA generativa e os modelos de aprendizado profundo trazem algo inédito: a possibilidade de ataques que não são contra o software, e sim contra as camadas de percepção e decisão. No setor financeiro, onde identidades, transações e dados sigilosos são o core do negócio, isso se traduz em três frentes principais: fraudes sintéticas de identidade, ataques adversariais a modelos de scoring e engenharia social assistida por deepfake.
Eu mesmo, em projetos de automação de processos para bancos digitais, já vi casos em que um modelo de prevenção a fraudes foi enganado por um ataque adversarial sutil: uma pequena alteração em pixels de um documento digitalizado, imperceptível ao olho humano, mas suficiente para fazer o classificador interpretar um RG falso como legítimo. Esse tipo de exploração não é teórico — está documentado na literatura acadêmica e já aparece em incidentes reais. A diferença é que, até pouco tempo, o custo computacional para realizar tais ataques em escala era proibitivo. Com a popularização de modelos de código aberto e GPUs acessíveis, essa barreira caiu.
No FEBRABAN TECH 2026, o tema central — “Protegendo identidades, dados e transações” — acerta ao colocar o foco na tríade que sustenta a confiança digital. Mas creio que a indústria ainda subestima a velocidade com que os atacantes estão assimilando essas novas ferramentas. Enquanto as equipes de segurança debatem políticas de uso aceitável de IA, há grupos explorando LLMs para gerar e-mails de phishing com gramática perfeita e contexto adaptado ao histórico do alvo, ou sintetizando vozes de executivos para autorizar transferências.
Deepfakes em tempo real e a erosão da confiança biométrica
Um dos pontos mais delicados que a Shield Security provavelmente endereçou em sua palestra é a fragilidade dos sistemas de verificação de identidade baseados exclusivamente em biometria facial ou vocal. Há dois anos, participar de uma chamada de vídeo para confirmar a identidade de um cliente ainda era considerado um padrão ouro de segurança. Hoje, com modelos de face-swapping e clonagem de voz disponíveis em plataformas de código aberto, esse método se tornou vulnerável a ataques em tempo real.
Participei de uma prova de conceito em que um colega gravou três minutos de áudio de um diretor, alimentou um modelo de síntese neural e, em menos de dez minutos, conseguiu gerar uma frase inteira — “Autorizo a transferência de R$ 50 mil para a conta de liquidante” — com entonação e pausas convincentes. O sistema de autenticação por voz do banco, que usava apenas um modelo de verificação de locutor, não detectou a fraude. O que impediu o ataque foi uma política secundária: um segundo fator via token físico. Mas quantos produtos financeiros hoje implementam esse tipo de defesa em cascata?
Isso me leva a uma reflexão prática para quem trabalha com produto: a adoção de IA nos fluxos de onboarding e autenticação precisa vir acompanhada de uma camada de detecção de ataques adversariais. Não basta treinar um modelo com dados limpos e colocá-lo em produção. É necessário monitorar continuamente a distribuição das features de entrada, implementar verificações de liveness que exijam interação (piscar, virar o rosto, repetir uma frase aleatória) e, acima de tudo, nunca confiar em um único modal biométrico.
Os vetores de ataque que o setor financeiro precisa mapear hoje
Quando falamos em “superfície de ataques IA”, é tentador imaginar um cenário futurista com robôs invadindo servidores. A realidade é mais prosaica e igualmente perigosa. Na minha experiência, os vetores mais críticos para o setor financeiro se dividem em três categorias — e a maioria das instituições ainda não tem visibilidade sobre nenhuma delas:
- Envenenamento de dados de treinamento (data poisoning): Um atacante que consegue injetar dados maliciosos no dataset usado para treinar modelos de crédito ou fraude pode fazer o modelo aprender a aprovar transações fraudulentas ou negar crédito a clientes legítimos. O efeito é silencioso e de longo prazo, difícil de detectar pós-implantação.
- Ataques adversariais em inferência: Pequenas perturbações nos dados de entrada — como alterar um dígito em um CPF ou adicionar ruído a uma foto — fazem o modelo produzir saídas incorretas. Para um sistema de autenticação facial, isso pode significar liberar acesso a um impostor.
- Engenharia social amplificada por IA generativa: Phishing personalizado, criação de documentos falsos com qualidade indistinguível de originais e clonagem de voz para autorizações. É o vetor mais imediato e o que mais tem evoluído nos últimos meses.
Durante o desenvolvimento de um produto de crédito para pequenas empresas, minha equipe se deparou com um caso clássico de data poisoning: um concorrente, usando contas de testes, submetia propositalmente propostas de crédito com dados inconsistentes — renda superestimada, documentos adulterados — para que o modelo aprendesse a rejeitar perfis semelhantes, mesmo quando legítimos. O ataque só foi descoberto porque o time de dados começou a investigar um aumento súbito de falsos positivos. Se não houvesse um pipeline de monitoramento, o modelo teria degradado lentamente sem que ninguém notasse.
Privacidade em produto: o elo perdido na corrida pela IA
A categoria deste artigo é “Privacidade em produto”, e isso não é coincidência. Acredito que a maior vulnerabilidade que a IA introduz no setor financeiro não está nos algoritmos, mas na forma como os dados são coletados, armazenados e utilizados para treinar modelos. A pressão por inovação — onboarding digital em segundos, crédito pré-aprovado, chatbots com linguagem natural — tem levado equipes de produto a coletar volumes cada vez maiores de dados pessoais sem as salvaguardas proporcionais.
Em uma consultoria que prestei para um banco digital, o time de produto queria implementar análise de sentimentos por voz nas ligações de cobrança para detectar clientes insatisfeitos. A ideia era boa, mas ninguém havia pensado em como garantir que o modelo não armazenasse trechos de áudio com dados sensíveis, ou como obter consentimento adequado nos termos de uso. A corrida pela IA esquece que privacidade não é um atributo opcional — é a base da confiança que sustenta qualquer transação financeira.
E aqui reside o paradoxo: quanto mais IA uma instituição financeira adota, maior a superfície de ataque e maior a responsabilidade sobre a privacidade dos dados. Um modelo de recomendação de produtos que consome o histórico de transações pode, se mal projetado, vazar indiretamente informações sobre a saúde financeira de um cliente. Um sistema de detecção de fraudes que usa dados biométricos pode, se comprometido, expor características físicas imutáveis que não podem ser trocadas como uma senha.
O que equipes de produto podem fazer — e o que devem evitar
A partir das discussões que tenho tido com CTOs e heads de segurança, algumas práticas emergem como essenciais para quem está construindo produtos financeiros com IA:
- Adotar uma estratégia de defesa em profundidade para modelos: Não confiar em um único modelo para decisões críticas. Implementar ensembles, modelos de detecção de outliers e validação cruzada com regras determinísticas.
- Monitorar a deriva de distribuição dos dados de entrada: Se as features que o modelo recebe em produção começam a se desviar estatisticamente do treinamento, pode ser sinal de ataque adversarial ou envenenamento.
- Exigir explicabilidade: Modelos de caixa-preta são difíceis de auditar. Sempre que possível, usar técnicas de LIME ou SHAP para entender por que uma decisão foi tomada — especialmente quando uma transação é bloqueada ou um crédito negado.
- Separar dados de treinamento de dados de produção com controles de acesso rigorosos: O envenenamento só é possível se o atacante conseguir injetar dados no pipeline de treinamento. Isolar esses ambientes é uma medida barata e eficaz.
- Nunca usar biometria como único fator de autenticação: Deepfakes e ataques de apresentação estão evoluindo rápido. Autenticação multifatorial com fatores posse (token) e conhecimento (senha) ainda é o padrão ouro — e deve ser combinada com detecção de liveness robusta.
Por outro lado, há práticas que vejo sendo adotadas e que considero arriscadas. Uma delas é o uso de modelos de IA para análise comportamental contínua sem transparência para o cliente. Monitorar cada clique, cada movimento do mouse, cada pausa na digitação pode gerar insights de segurança, mas também cria um perfil comportamental que, se vazado, expõe o usuário a fraudes muito mais sofisticadas. O equilíbrio entre segurança e privacidade é delicado, e a balança não pode pender apenas para o lado da vigilância.
A dimensão humana que a tecnologia não resolve
Sei que parece contraditório um especialista em automação e IA defender limites para a tecnologia, mas minha experiência mostra que o maior fator de risco em produtos financeiros continua sendo o fator humano — e não estou falando de funcionários mal-intencionados, mas de decisões de produto tomadas sem considerar as implicações de segurança. A pressão por métricas de curto prazo — taxas de aprovação, tempo de onboarding, engajamento — frequentemente atropela a construção de defesas contra ataques que ainda não aconteceram, mas que são previsíveis.
No caso da Shield Security, o alerta sobre a nova superfície de ataques IA não deve ser lido como um chamado para parar de usar IA, mas sim como um lembrete de que a adoção precisa ser responsável. O FEBRABAN TECH 2026 acertou ao colocar o tema em pauta, mas o debate precisa sair dos palcos e chegar aos boards de produto, aos repositórios de código e aos comitês de privacidade. Não há modelo de IA que substitua a governança de dados bem-feita e a cultura de segurança incorporada ao ciclo de desenvolvimento.
Minha recomendação editorial para quem está lendo este artigo é: se você trabalha com produto financeiro, sente com seu time de segurança e dados e faça um exercício de “red teaming” para identificar quais dos seus modelos de IA são vulneráveis aos três vetores que descrevi. Depois, olhe para seus processos de consentimento e transparência — eles estão preparados para explicar a um regulador ou a um cliente como os dados estão sendo usados para treinar modelos? Se a resposta for não, a superfície de ataque não está apenas na tecnologia, está na confiança. E essa, uma vez perdida, nenhum algoritmo recupera.