A maioria dos projetos de IA em bancos não falha pela tecnologia: falha antes, em como o problema foi enquadrado. Três pesquisas (RAND, McKinsey e o BIS) convergem em que o gargalo é organizacional, não técnico. As três falhas mais comuns: comprar «uma IA» em vez de um resultado de negócio mensurável, não ter um dono do projeto do lado do negócio, e desenhar o piloto para impressionar na demo em vez de sobreviver à produção (core legado, dados reais, risco e compliance). O antídoto é um checklist de quatro perguntas antes de aprovar o piloto: resultado mensurável, dono do negócio, dados e sistemas reais, e caminho até a produção no plano desde o dia um.
A IA generativa é uma realidade atual no setor financeiro. Os casos de uso estão claros, a tecnologia está disponível, e as equipes que antes hesitavam agora estão em modo de implementação. A pergunta já não é «deveríamos explorar a IA?», mas «como fazemos para que o projeto chegue à produção e gere valor real?». Essa pergunta tem resposta e, paradoxalmente, tem pouco a ver com a tecnologia. Por que alguns projetos chegam e outros não? Há um padrão que se repete na indústria e que três pesquisas distintas documentaram por caminhos distintos: os projetos de IA em bancos que não escalam geralmente não falham pelo modelo — falham antes, em como o projeto foi definido. A RAND Corporation , que entrevistou engenheiros com mais de cinco anos de experiência em projetos de IA em produção, identificou cinco causas raiz de fracasso. Apenas uma é técnica; as outras quatro são de enquadramento, liderança e organização. A McKinsey descreve um «purgatório de pilotos» onde os projetos impressionam na demo e não avançam. O BIS , ao definir diretrizes de governança de IA para o setor financeiro (2025), coloca o foco não na capacidade do modelo, mas na governança, nos controles de risco e na clareza do propósito como os fatores que determinam uma adoção bem-sucedida. O padrão converge no mesmo lugar: a diferença entre os projetos que geram valor real e os que não está em como o problema foi enquadrado, não em qual modelo foi escolhido. E isso, na verdade, é uma boa notícia. A boa notícia: o gargalo está sob o seu controle Se a causa principal não é a tecnologia, também não depende de esperar a próxima geração de modelos nem de trocar de fornecedor. Depende de decisões organizacionais que o banco pode tomar hoje, antes de aprovar um piloto. A vantagem competitiva não está em acessar uma tecnologia que ninguém mais tem: está em saber como enquadrar o problema para que o projeto sobreviva ao salto da demo para o mundo real. É isso que separa as equipes que escalam das que ficam no purgatório de pilotos. As três falhas que travam os projetos (e como evitá-las) 1. Compra-se «uma IA», não um resultado de negócio O pedido chega como «precisamos de um chatbot» ou «queremos IA no atendimento ao cliente». Não chega como «queremos reduzir em 20% o tempo de resolução de reclamações de cartões sem aumentar a taxa de fraude». Sem um resultado mensurável e um dono responsável por esse número, o piloto é avaliado pelo que impressiona na demo, não pelo que move o negócio. E em produção, onde os dados são reais e os comitês de risco fazem perguntas difíceis, a demo já não basta. A correção é direta: antes de falar de tecnologia, o projeto precisa de um resultado escrito em uma frase. «Melhorar a experiência do cliente» não é um resultado. «Reduzir o tempo médio de resolução de consultas de 8 para 4 minutos no canal WhatsApp», sim. 2. Ninguém do negócio é dono do projeto A iniciativa acaba órfã em Inovação ou em TI. Quando é preciso brigar por orçamento, por acesso a dados ou por integração com o core, não há um líder do negócio com algo real em jogo que defenda o projeto. Segundo a RAND, os mal-entendidos sobre o propósito do projeto são a causa raiz número um que os próprios engenheiros apontam. Não a falta de dados nem o modelo, mas a falta de clareza sobre para que o projeto existe e quem responde por isso. A correção é identificar, antes do piloto, uma pessoa da área impactada —não de TI nem de Inovação— que responda por um resultado concreto de negócio: receita, custos, ou um indicador próprio da área. 3. O piloto é desenhado para impressionar, não para sobreviver à produção A produção roda sobre um core bancário de décadas, dados fragmentados, latência real e compliance regulatório que não consta em nenhum documento da avaliação inicial. O salto da POC para a produção é onde se concentra a maior parte do risco. Os projetos que o superam são os que incluíram a integração, a governança e os controles de risco no plano desde o primeiro dia, não como uma «fase 2» que ninguém termina de financiar. O checklist antes de aprovar o piloto Quatro perguntas que, se tiverem resposta antes de assinar algo, aumentam significativamente as chances de o projeto chegar à produção: Qual é o resultado de negócio mensurável? Um número, uma linha de base atual e uma meta. Se não puder ser escrito em uma frase, o projeto não está pronto. Quem do negócio é responsável por esse resultado? Uma pessoa da área impactada que responda pelo número, não pela tecnologia. O piloto roda sobre dados e sistemas reais? Se não, você não está testando o projeto: está testando uma demo. O caminho até a produção está no plano desde o dia um? Integração, governança, controles de risco e compliance regulatório como parte do desenho inicial, não como etapa futura. A ter em conta: se o projeto só pode ser explicado em termos de tecnologia («vamos implementar IA generativa»), está mal enquadrado. Se é explicado em termos de negócio («vamos recuperar X horas de gestão / reduzir Y custo de atendimento / aumentar Z taxa de contenção»), tem chances reais. Um esclarecimento necessário A tecnologia importa sim: há casos em que o modelo é o limite real —problemas que a IA ainda não resolve bem, ou onde a qualidade dos dados é tão baixa que nenhum enquadramento compensa—. A própria RAND reconhece isso como uma das cinco causas de fracasso. O ponto não é que a tecnologia seja irrelevante, mas que na distribuição observada é o fator minoritário. Apostar primeiro em «melhor tecnologia» quando o problema é de enquadramento é otimizar a variável errada. Dois esclarecimentos de rigor: a evidência da RAND e do MIT é cross-industry, não exclusiva de bancos, embora a lógica se reforçe no setor financeiro pelas camadas adicionais de regulação e integração legada. E os dados do MIT (Project NANDA, 2025) são recentes e ainda sem a validação longitudinal de estudos mais consolidados: usamos como sinal potente, não como lei estabelecida. Como encaramos isso na Delto O padrão que as pesquisas descrevem é o mesmo que vemos em projetos reais: o piloto impressiona e depois se choca com o core legado, os dados reais, o comitê de risco e as perguntas de compliance que ninguém antecipou na avaliação inicial. Por isso, na Delto começamos com duas perguntas: qual resultado de negócio precisa se mover e quem, do lado do negócio, é dono desse número. A tecnologia vem depois, quando essas duas perguntas têm resposta, como instrumento para melhorar o negócio. Não é uma promessa de resultados garantidos, mas a ordem que —segundo a evidência disponível e o que vemos em campo— separa os projetos que chegam à produção dos que ficam no purgatório de pilotos. Se você tem um projeto em andamento ou uma prova de conceito que não terminou de escalar, vamos conversar sobre como enquadrá-lo para que chegue à produção. Fontes Gartner, “Gartner Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept By End of 2025” (julho 2024). Ver fonte RAND Corporation, Ryseff, De Bruhl e Newberry, “The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed” (2024). Ver fonte MIT, Project NANDA, “The GenAI Divide: State of AI in Business 2025” (julho 2025). Cobertura McKinsey & Company, “The State of AI in 2025” (QuantumBlack). Ver fonte Bank for International Settlements, “Governance of AI adoption in central banks” (janeiro 2025). Ver fonte Nota: os números vêm das publicações primárias citadas. A evidência de causas raiz (RAND, MIT) é cross-industry, não exclusiva de bancos. A hierarquia causa-raiz/consequências é interpretação analítica da Delto, não uma conclusão literal das fontes.
Por que os projetos de IA em bancos fracassam? Segundo a RAND, de cinco causas raiz de fracasso apenas uma é técnica; as outras quatro são de enquadramento, liderança e organização. A maioria não falha pelo modelo, mas por como o projeto foi definido.
O que é o «purgatório de pilotos»? É o termo que a McKinsey usa para os projetos de IA que impressionam na demo mas nunca avançam para produção nem geram valor real.
Como se enquadra bem um projeto de IA em bancos? Começando por um resultado de negócio mensurável (um número, uma linha de base e uma meta), com um dono do negócio responsável por esse número, testando sobre dados e sistemas reais, e com o caminho até a produção (integração, governança, risco, compliance) no plano desde o dia um.
Então a tecnologia não importa? Importa sim: às vezes o modelo ou a qualidade dos dados é o limite real, e a RAND reconhece isso. Mas na distribuição observada é o fator minoritário; apostar em «melhor tecnologia» quando o problema é de enquadramento é otimizar a variável errada.