Bancos brasileiros investem R$ 50,4 bilhões em tecnologia em 2026, mas o compliance ainda depende da fila de TI para mudar uma regra de risco. Veja o que trava a autonomia dos times e como recuperá-la sem construir motor do zero.
Os bancos brasileiros nunca tiveram tanto orçamento de tecnologia. Ainda assim, quando o compliance precisa mudar uma regra de risco, na maioria das instituições ele não muda sozinho: descreve a alteração, abre um chamado e espera a fila da engenharia.
Esses dois fatos convivem no mesmo balanço. A Pesquisa Febraban de Tecnologia Bancária 2026, conduzida pela Deloitte com bancos que representam cerca de 85% dos ativos do setor, registra um orçamento de R$ 46,8 bilhões em 2025, um crescimento de 58% desde 2021, e projeta R$ 50,4 bilhões para 2026. Prioridade declarada também existe de sobra: 80% dos bancos classificam IA como prioridade média ou alta de investimento. A maturidade é que fica para trás, com apenas 40% das instituições em maturidade média ou alta de IA.
Ou seja: orçamento deixou de ser o gargalo faz tempo. O que trava a resposta a risco na maioria das instituições não é dinheiro, é autonomia. E a decisão que mais influencia essa autonomia costuma ser tomada cedo, quase por inércia: construir o motor de risco internamente ou contratar uma plataforma.
Quando uma instituição decide entre construir e contratar, a discussão quase sempre gira em torno de custo de desenvolvimento contra custo de licença. É uma conta que ignora a variável que mais importa.
A variável que decide é o tempo que a sua régua leva para acompanhar um risco novo e o quanto passa por ela enquanto essa mudança não entra no ar. Chame de exposição acumulada. Ela tem duas forças agindo juntas: cada dia que a regra espera na fila é mais um dia de janela aberta, e cada dia de janela aberta deixa passar um volume que só cresce. Duas instituições podem gastar o mesmo em tecnologia e ter exposições completamente diferentes, dependendo de quanto tempo cada uma leva para colocar uma regra nova em produção.
A Febraban perguntou aos bancos quais são os principais desafios para adotar IA em segurança da informação, um recorte vizinho do compliance e do PLD. As três respostas mais citadas explicam por que construir internamente costuma perder fôlego justamente na operação.
68% dos bancos apontam preocupações com privacidade, governança de dados e uso ético da IA. Para um time de compliance, a tradução é direta: se o Banco Central questionar uma decisão em inspeção, ou se uma comunicação ao COAF exigir a reconstrução da análise, "o modelo decidiu" não é resposta aceitável. Um motor construído às pressas, sem trilha de decisão, não sobrevive a uma auditoria. A régua precisa entregar o que o regulador cobra de você: critérios documentados (Circular BCB nº 3.978/2020, art. 40, §1º) e trilhas de auditoria verificáveis (art. 61), à disposição do BCB quando solicitado.
40% dos bancos citam a falta de profissionais com conhecimento em IA aplicada. É aqui que a decisão de construir internamente costuma morrer em silêncio: Construir internamente depende de um time que o mercado inteiro está disputando. A própria pesquisa mostra que 42% dos bancos pretendem ampliar o quadro de TI em 2026. Todos estão contratando as mesmas pessoas. A alternativa que os times de compliance têm adotado é tirar a dependência de TI da equação: em plataformas no-code, o próprio analista ajusta regra, faixa de risco e fluxo de exceção.
32% apontam a dificuldade de integrar novas tecnologias à infraestrutura existente. Cada bureau contratado é uma API diferente, um contrato diferente, um formato de resposta diferente. Multiplique por cinco ou dez fornecedores de dados e a automação vira um projeto de integração permanente. A pergunta certa deixa de ser "como integro mais um fornecedor" e passa a ser "como paro de integrar fornecedores um a um". Um orquestrador único inverte o custo: mantém as fontes de dados já conectadas atrás de uma só integração, consultadas conforme a regra que o seu time define.
Antes de decidir entre construir e contratar, vale ver o comparativo temporal completo dos dois modelos, com os prazos regulatórios em jogo.
O eixo da decisão não é quem tem os melhores engenheiros. É quem coloca uma regra nova em produção antes de o volume de operações não detectadas se acumular.
|
Critério |
Construir internamente |
Plataforma no-code |
|---|---|---|
|
Quem muda a regra |
Engenharia, via chamado |
O próprio analista de compliance |
|
Tempo até a regra entrar em produção |
De semanas a meses |
Minutos |
|
Manutenção e evolução |
Recorrente e crescente, sob a instituição |
Embutida e previsível |
|
Integração de dados |
Cada bureau, uma integração a sustentar |
Fontes já conectadas atrás de uma integração |
|
Trilha de auditoria |
A construir e manter |
Nativa, cada decisão rastreável |
|
Exposição enquanto a regra não sobe |
Operações passam sem alerta; o volume cresce a cada dia |
Cobertura da base no mesmo turno |
Entre as operações que saíram da fila da engenharia e passaram a responder ao risco no próprio ritmo, três decisões se repetem.
Trocaram regras de score confusas por uma régua auditável. Matriz de risco com faixas explícitas, em que cada decisão e cada derivação à mesa carrega justificativa rastreável e documentada. É isso que sustenta a operação diante do regulador.
Colocaram a regra na mão do compliance. Com workflows no-code, o time ajusta a política sem abrir chamado para a TI, e a mudança de regra deixa de depender de um ciclo de desenvolvimento.
Pararam de integrar fornecedores um a um. Em vez de somar APIs, orquestraram as fontes de dados atrás de uma única camada, consultadas em cascata conforme a régua define, sem pagar duas vezes pela mesma consulta.
Para ser justo, existem casos em que o build interno é a rota certa. Eles são raros e costumam exigir três condições ao mesmo tempo: uma funcionalidade tão específica que nenhuma ferramenta do mercado atende, uma exigência de ambiente inteiramente on-premises por política interna (não por regulação, que já admite computação em nuvem com controles adequados) e capacidade de construir e manter a solução de forma contínua e indefinida. Mesmo aí, permanece uma dependência que não some: o acesso a listas de sanções, PEP e dados de vínculos quase sempre precisa ser adquirido de fornecedores. Para a maioria das instituições, as três condições não coexistem, e a conta da exposição acumulada pende de forma decisiva para a plataforma.
Depende de três condições que raramente coexistem: funcionalidade crítica inexistente no mercado, exigência de ambiente totalmente on-premises por política interna e capacidade de manter a solução de forma contínua e indefinida. Fora esses casos, a variável que decide é o tempo de resposta: quanto sua régua demora para acompanhar um risco novo e quanto passa por ela até lá. Nesse critério, a plataforma responde em minutos e o build, em semanas a meses.
Porque, num motor construído internamente, a regra de negócio vive no código. Toda mudança de régua, ajuste de cenário ou nova tipologia vira requisito, chamado e sprint, disputando prioridade com o roadmap de produto. O compliance, que entende do risco, perde autonomia sobre a própria régua. Plataformas no-code devolvem essa autonomia, permitindo que o analista configure e publique a regra sem depender de desenvolvimento.
É uma plataforma em que o próprio time de compliance cria, calibra e publica regras e cenários de risco por uma interface visual, sem escrever código. Ela reúne motor de decisão, orquestração de fontes de dados, gestão de casos e trilha de auditoria, de modo que a resposta a um padrão novo deixa de depender da fila da engenharia.
Sim, desde que cada decisão seja rastreável e demonstrável. A Circular BCB nº 3.978/2020 exige política de PLD/FT com critérios documentados (art. 40, §1º), registros conservados pelos prazos regulamentares (arts. 66 e 67) e trilhas de auditoria verificáveis (art. 61), tudo à disposição do BCB. A LGPD (art. 20) ainda garante ao cliente o direito de solicitar a revisão de decisões automatizadas, o que reforça a necessidade de registrar a justificativa de cada decisão. A VAAS armazena essa justificativa em trilha de auditoria e possui certificação SOC, que atesta seus controles de segurança da informação. Vale a ressalva de que o monitoramento de operações suspeitas e a comunicação ao COAF são etapa distinta: cada análise deve ser formalizada em dossiê (art. 43, §2º) e não pode ser terceirizada (art. 44). A plataforma dá suporte a essa etapa com trilha e dossiê, mas a decisão de comunicar e a comunicação ao COAF permanecem responsabilidade da instituição.
Raramente, quando se conta o ciclo completo. A proposta mostra o custo de construir, mas o que quebra o orçamento é o de manter: infraestrutura, integrações, evolução de regras, segurança e conformidade, tudo recorrente e crescente. Some o custo de dado, que o build não reduz, e o custo de oportunidade da engenharia alocada em risco em vez de produto. Numa plataforma, boa parte disso já vem embutida em um custo previsível.
Se você chegou até aqui, é provável que a sua operação esteja no ponto em que a automação já se provou em algum piloto, mas a régua de risco ainda depende da fila da engenharia para mudar. O guia "Construir ou contratar o motor de risco" traz o comparativo temporal dos dois modelos, a tabela de custos que o build esconde e os prazos regulatórios que pesam na balança, para você levar a decisão embasada à próxima reunião.
Fonte dos dados de mercado: Pesquisa Febraban de Tecnologia Bancária 2026 (34ª edição), Deloitte/Febraban, versão executiva, jun/2026. A série histórica de orçamento é reapurada a cada edição; o crescimento de 58% refere-se ao período 2021–2025.