O risco sistêmico da IA que ninguém está monitorando em produção

Quando o código vence o regulador

Em junho de 2026, Christine Lagarde, presidente do Banco Central Europeu, subiu ao palco em Veneza para dizer o que muitos engenheiros de sistemas financeiros já sentem na pele há pelo menos três anos: a inteligência artificial, em seu estado atual de adoção, representa um risco concreto para a estabilidade financeira global. A declaração não é sobre o potencial futurista da tecnologia, mas sobre a volatilidade e as incertezas geradas por uma inovação disruptiva que já está embarcada em milhares de pipelines de decisão — da concessão de crédito ao trading de alta frequência.

Como profissional que passou os últimos anos desenhando infraestruturas de inferência para clientes do setor financeiro, posso afirmar: o problema não é a IA em si, mas a forma como a estamos colocando em produção. A ausência de padrões de engenharia para modelos sistêmicos, a dependência excessiva de provedores de nuvem concentrados e a falta de observabilidade sobre o comportamento de agentes autônomos são os verdadeiros catalisadores do risco. E, ao contrário do que muitos CTOs acreditam, isso não se resolve com mais compliance — resolve-se com arquitetura.

O gargalo invisível da inferência em larga escala

Grande parte dos sistemas financeiros que usam IA hoje opera com modelos que foram treinados em cenários históricos e depois congelados. O problema é que esses modelos são colocados em produção em loops de decisão com latência de milissegundos, sem qualquer mecanismo de detecção de deriva de comportamento (drift). Um modelo de precificação de ativos que começa a apresentar viés porque o mercado mudou — e não porque o modelo foi retreinado — pode gerar sinais falsos para milhares de algoritmos downstream. Cada sinal falso não é um erro isolado; é um micro-choque que pode se propagar em cascata.

Em 2024, um incidente em uma das principais bolsas de criptoativos foi causado por um modelo de detecção de anomalias que começou a marcar transações legítimas como fraudulentas devido a uma mudança na distribuição de tamanho de blocos após um halving. O modelo não foi atualizado, o drift não foi monitorado, e o sistema de clearing travou por 45 minutos. Lagarde tem razão: o risco não está no modelo, mas na falta de engenharia de produção para IA.

A falsa segurança da nuvem concentrada

Outro ponto que o discurso de Lagarde toca indiretamente é a concentração de infraestrutura. Hoje, a maior parte dos sistemas de IA para finanças roda em três provedores de nuvem — AWS, Azure e GCP. Dentro desses provedores, os modelos frequentemente compartilham clusters de GPU e até mesmo instâncias de inferência multiinquilino. Um pico de requisições em um modelo de recomendação de varejo pode, em teoria, roubar capacidade de inferência de um modelo de risco de crédito que roda no mesmo cluster. Não é um cenário teórico: já vi, em um cliente do setor bancário, o time de fraude ter que esperar fila de GPU porque o time de marketing estava executando campanhas sazonais.

A dependência de APIs de IA como serviço (AIaaS) agrava ainda mais o quadro. Quando um banco usa a API de um modelo de linguagem para classificar e-mails de compliance ou extrair dados de contratos, ele está terceirizando não apenas o processamento, mas a segurança da decisão. Se o provedor da API muda o comportamento do modelo — o que acontece com frequência em versões não documentadas — o sistema bancário pode começar a classificar documentos errados sem nenhum aviso. Não existe SLA para comportamento semântico de modelo; existe apenas disponibilidade.

A caixa-preta que já é sistêmica

O ponto mais delicado, e que merece atenção de qualquer engenheiro de software trabalhando com IA financeira, é o fenômeno dos agentes autônomos interagindo entre si sem supervisão humana em tempo real. Imagine dois fundos de hedge que usam modelos diferentes, mas correlacionados, para tomar decisões de compra e venda sobre o mesmo ativo. Se um modelo detecta um padrão que o outro não vê, e ambos começam a agir simultaneamente com base em sinais derivados de dados públicos, o que se forma é um loop de reforço que pode amplificar movimentos de mercado sem nenhum fundamento econômico. Isso não é ficção: o flash crash de 2010 foi causado por algoritmos relativamente simples. Hoje, esses algoritmos são substituídos por redes neurais que ninguém consegue auditar completamente.

Durante um projeto de arquitetura para um sistema de market making, precisei convencer o time de que era necessário implementar um circuit breaker não apenas no nível de execução de ordens, mas no nível do modelo. Se a incerteza da predição ultrapassasse um limite calibrado dinamicamente, o sistema deveria pausar e delegar a decisão a um humano. A resistência foi enorme: "isso vai reduzir nossa vantagem competitiva em latência". A engenharia de IA financeira não pode tratar o modelo como um oráculo, mas como um componente sujeito a falhas que precisam ser contidas.

Por que o alerta de Lagarde importa para engenheiros de software

Muitos desenvolvedores veem o debate regulatório sobre IA como algo distante, que diz respeito a advogados e economistas. Essa percepção está errada. As decisões que tomamos hoje — como arquitetar um pipeline de inferência, como versionar modelos, como testar comportamento em condições extremas — determinam se o sistema será resiliente ou quebrará discretamente. O alerta do BCE não é um convite para parar de usar IA; é um chamado à profissionalização da engenharia de IA em produção.

Algumas práticas que precisam se tornar mandatórias em qualquer projeto financeiro:

• Observabilidade de modelo em tempo real: não basta monitorar latência e throughput. É preciso monitorar distribuição de predições, incerteza calibrada, e detecção de drift com thresholds dinâmicos.
• Isolamento de infraestrutura crítica: modelos que afetam liquidez, risco de crédito ou execução de ordens não devem dividir clusters com modelos não críticos. O custo extra de isolamento é o prêmio do seguro.
• Circuit breakers comportamentais: implementar limites de desvio de comportamento do modelo com fallback para regras determinísticas ou intervenção humana. Não se trata de "frear a inovação", mas de evitar que um bug derrube o sistema.
• Auditabilidade de versões e decisões: cada decisão de modelo deve ser rastreável até a versão exata do artefato, os hiperparâmetros e os dados de treinamento. Sem isso, é impossível fazer análise post-mortem em uma crise.

Riscos que não estão no radar regulatório — ainda

A discussão sobre risco sistêmico da IA no setor financeiro costuma focar em concentração de mercado, viés algorítmico e falta de explicabilidade. Esses são problemas reais, mas existe uma camada técnica anterior que o regulador ainda não enxergou com clareza: a fragilidade das cadeias de dependência de software. Um modelo de IA não é uma entidade isolada; ele depende de bibliotecas, frameworks, kernels de GPU, serviços de orquestração e camadas de rede. Uma vulnerabilidade em uma biblioteca de serialização usada por 70% dos modelos de classificação financeira pode, se explorada, comprometer sistemas de dezenas de bancos simultaneamente. Não é um ataque à IA, é um ataque à infraestrutura que a IA usa — e que é compartilhada entre concorrentes.

Durante um pentest em um ambiente de inferência financeira, descobri que todos os modelos de um cliente usavam a mesma versão de uma biblioteca de pré-processamento que tinha uma falha conhecida de desserialização insegura. O atacante poderia, com um payload malicioso em um campo de entrada, executar código arbitrário no servidor de inferência e, a partir dali, acessar os modelos de todos os clientes que rodavam no mesmo cluster. A correção foi trivial; a descoberta, assustadora. Esse tipo de risco não aparece nos relatórios de estabilidade financeira — mas pode derrubar um sistema de pagamentos em minutos.

O que engenheiros podem fazer hoje

Se você trabalha com IA aplicada a finanças, aqui estão três ações práticas que podem reduzir significativamente o risco sistêmico do seu sistema:

1. Implemente shadow mode e rollout gradual. Nunca coloque um modelo novo em produção direto. Comece executando em shadow, comparando suas decisões com o modelo em produção ou com regras determinísticas. Só promova após validação estatística em dados reais.
2. Adicione telemetria de intenção. Além de métricas de performance, registre por que o modelo tomou cada decisão (atribuição de features, valores de features, incerteza). Isso permite depuração em cenários de crise sem precisar reproduzir o ambiente exato.
3. Diversifique provedores de IA. Se você depende de APIs de terceiros para funções críticas (classificação de risco, extração de dados), tenha um fallback com outro provedor ou com um modelo próprio mais simples. A dependência única é um risco de continuidade de negócios.

A responsabilidade técnica que não pode ser delegada

O alerta de Christine Lagarde não é uma profecia apocalíptica, mas um diagnóstico preciso de um momento em que a adoção da IA corre mais rápido que a capacidade de gerenciar seus efeitos colaterais. Para engenheiros de software, essa é uma oportunidade — e uma responsabilidade. Não podemos esperar que reguladores entendam de isolamento de clusters, monitoramento de drift ou cadeias de dependência de bibliotecas para agir. Cabe a nós, que construímos esses sistemas, incorporar os princípios de resiliência, auditabilidade e contenção de falhas no cerne da arquitetura.

No fim das contas, a estabilidade financeira não depende apenas de bancos centrais e tratados internacionais. Depende também de commits em repositórios de código, de pull requests que revisam não apenas a lógica de negócio, mas o comportamento do modelo, e de decisões de arquitetura que consideram o pior caso — aquele em que o modelo erra, o cluster cai, e o sistema precisa continuar funcionando com dignidade. A IA aplicada a finanças não pode ser tratada como um projeto de inovação; precisa ser tratada como engenharia crítica, com padrão de segurança de usina nuclear.