 |
| Bellacosa Mainframe e o prenda-me se for capaz ia e ibm z17 contra fraudes |
☕ Um Café no Bellacosa Mainframe
Prenda-me se For Capaz — Quando o IBM z17 Colocou uma IA na Alfândega da Transação e Mandou a Fraude Mostrar o Passaporte
Ou: Frank Abagnale entrou no banco vestido de piloto, o programa COBOL consultou o histórico, o Telum II calculou um score em menos de um milissegundo — e o Spyre ficou no andar de cima investigando por que o cheque tinha sido emitido por uma companhia aérea que não existia
Há uma cena clássica em qualquer bom filme de vigaristas.
O sujeito entra pela porta principal usando um uniforme impecável. Caminha como se conhecesse o prédio, cumprimenta o segurança pelo nome, segura uma pasta de couro e parece tão legítimo que ninguém se lembra de fazer a pergunta fundamental:
— Quem é você?
Frank Abagnale Jr., personagem central de Catch Me If You Can, construiu sua carreira cinematográfica exatamente nesse intervalo entre parecer legítimo e alguém conferir os dados.
Ele não precisava derrubar o sistema bancário. Não precisava explodir o datacenter, quebrar a criptografia ou fazer engenharia reversa no CICS.
Precisava apenas parecer verdadeiro durante tempo suficiente.
Fraude funciona assim.
Ela raramente entra pela janela usando máscara preta e carregando um saco com cifrão. Normalmente chega pela porta da frente com:
nome aparentemente correto;
cartão válido;
senha correta;
documento convincente;
dispositivo conhecido;
comportamento quase normal;
história razoavelmente plausível.
O problema da segurança moderna não é encontrar aquilo que parece completamente falso. Isso costuma ser fácil.
O problema é identificar aquilo que possui 97% de verdade e esconde a fraude nos 3% restantes.
E o banco precisa perceber isso antes que a autorização seja concluída.
Não amanhã.
Não depois do fechamento do movimento.
Não quando o cliente ligar informando que nunca comprou vinte televisores em Vladivostok.
A decisão precisa acontecer enquanto a transação ainda está atravessando o corredor.
É nesse ponto que entra o IBM z17, seu processador Telum II, o acelerador Spyre e uma ideia aparentemente simples, mas arquiteturalmente poderosa:
Em vez de mandar os dados até a inteligência artificial, colocamos a inteligência artificial perto dos dados.
Puxe uma cadeira, abra o ISPF e peça mais um café. Hoje acompanharemos uma transação bancária como se ela fosse Frank Abagnale tentando atravessar a alfândega vestido de piloto.
1. A fraude não começa com um crime: começa com uma história
Imagine que um cliente normalmente faça compras assim:
supermercados em Itatiba;
combustível duas vezes por mês;
serviços digitais recorrentes;
pequenas compras durante o dia;
um restaurante aos sábados;
nenhuma transação internacional recente.
Subitamente aparece uma tentativa de compra:
três notebooks;
às 3h17 da madrugada;
em outro país;
utilizando um dispositivo nunca visto;
depois de quatro tentativas recusadas;
com endereço de entrega diferente;
poucos minutos depois de uma alteração cadastral.
Nenhuma dessas características, sozinha, prova uma fraude.
Pessoas viajam.
Pessoas compram notebooks.
Pessoas trocam de celular.
Pessoas esquecem senhas.
Pessoas compram presentes de madrugada porque a insônia também participa da economia mundial.
Entretanto, quando combinamos todos os sinais, surge uma história estranha.
É exatamente esse tipo de relação que um modelo de machine learning procura aprender.
Ele não está buscando apenas uma regra rígida como:
SE VALOR > 10000
ENTÃO RECUSAREle tenta responder uma pergunta mais sofisticada:
Considerando dezenas ou centenas de características, o quanto esta transação se parece com as fraudes que observamos anteriormente?
A resposta geralmente não é “sim” ou “não”.
É um score.
Por exemplo:
RISCO-DE-FRAUDE = 0,91Isso significa que o modelo encontrou uma combinação fortemente associada a comportamento fraudulento. Não significa que ele tenha presenciado o crime, interrogado o suspeito e recuperado o dinheiro numa mala escondida no aeroporto.
A IA não produz uma sentença judicial.
Ela produz evidência probabilística para ajudar o sistema a tomar uma decisão.
Esse será nosso primeiro ensinamento para o programador COBOL iniciante:
Machine learning não elimina a lógica de negócio. Ele acrescenta uma nova informação à lógica de negócio.
2. Treinamento e inferência: a escola e a prova oral
Antes de entender o Telum II, precisamos separar duas fases frequentemente misturadas.
Treinamento
Durante o treinamento, apresentamos ao modelo dados históricos:
compras legítimas;
fraudes confirmadas;
contestações;
chargebacks;
dispositivos comprometidos;
contas invadidas;
identidades roubadas;
comportamentos considerados normais;
comportamentos considerados suspeitos.
O modelo tenta encontrar relações matemáticas entre as características e os resultados conhecidos.
É como mostrar milhares de cheques a um investigador e dizer:
— Estes eram legítimos. Estes eram falsificados. Descubra os padrões.
O treinamento pode ser computacionalmente pesado. Pode utilizar GPUs, plataformas de ciência de dados, clusters, ambientes cloud ou infraestrutura especializada.
Esse trabalho não precisa acontecer dentro da transação bancária.
Nenhum cliente aceitará esperar três semanas diante da maquininha enquanto o modelo reaprende a história do sistema financeiro.
Inferência
Depois de treinado, o modelo pode receber uma nova transação e aplicar aquilo que aprendeu.
Essa aplicação é chamada de inferência.
O modelo recebe informações como:
VALOR
HORARIO
LOCALIZACAO
TIPO-DE-ESTABELECIMENTO
IDADE-DA-CONTA
DISPOSITIVO
QUANTIDADE-DE-TENTATIVAS
MEDIA-DE-GASTOS
DISTANCIA-DA-ULTIMA-COMPRAE devolve algo como:
SCORE-DE-RISCO = 0,8734Treinamento é a escola de investigadores.
Inferência é o momento em que o inspetor olha para o passaporte, compara os sinais e decide se chamará o supervisor.
O IBM z17 é especialmente interessante nessa segunda fase: executar a inferência rapidamente, em grande escala e suficientemente perto da aplicação transacional para que o resultado ainda possa influenciar a autorização.
3. O que acontece quando o cartão encosta na maquininha?
Vamos acompanhar nossa transação passo a passo.
A implementação real varia entre instituições, bandeiras, adquirentes e sistemas, mas o fluxo conceitual pode ser representado assim:
MAQUININHA
↓
ADQUIRENTE
↓
REDE OU BANDEIRA
↓
BANCO EMISSOR
↓
SISTEMA DE AUTORIZAÇÃO
↓
ANÁLISE DE RISCO
↓
APROVAR, NEGAR OU DESAFIARDentro do banco, o sistema pode consultar:
situação do cartão;
senha ou credencial;
saldo;
limite;
bloqueios;
restrições geográficas;
quantidade de operações recentes;
perfil do cliente;
regras antifraude;
resultado de modelos de IA.
Em um ambiente mainframe, partes desse processamento podem envolver:
CICS;
IMS;
Db2;
VSAM;
IBM MQ;
programas COBOL;
serviços Java;
APIs;
z/OS Connect;
componentes Linux executando no IBM Z;
rotinas de segurança;
mecanismos de criptografia;
serviços de inferência.
O programa COBOL não precisa “virar uma IA”.
Ele pode continuar fazendo aquilo que sempre fez muito bem: orquestrar regras de negócio, validar campos, controlar estados, registrar decisões e preservar a integridade da transação.
A diferença é que agora ele pode receber um score calculado por um modelo.
Conceitualmente, nossa lógica poderia se parecer com isto:
EVALUATE TRUE
WHEN CARTAO-BLOQUEADO
MOVE '05' TO CODIGO-RESPOSTA
WHEN SCORE-FRAUDE > 900
MOVE 'N' TO AUTORIZAR
MOVE 'FRAUDE ALTA' TO MOTIVO-DECISAO
WHEN SCORE-FRAUDE > 650
MOVE 'S' TO EXIGIR-AUTENTICACAO
MOVE 'VALIDACAO ADICIONAL'
TO MOTIVO-DECISAO
WHEN LIMITE-DISPONIVEL < VALOR-COMPRA
MOVE 'N' TO AUTORIZAR
MOVE 'LIMITE INSUFICIENTE'
TO MOTIVO-DECISAO
WHEN OTHER
MOVE 'S' TO AUTORIZAR
MOVE 'APROVADA' TO MOTIVO-DECISAO
END-EVALUATE.Naturalmente, um sistema bancário real será muito mais sofisticado. A ordem das verificações, os limites, as exceções e as regras serão governados por políticas específicas.
Mas o princípio é este:
IA calcula o risco.
A aplicação toma a decisão.Essa separação é saudável.
O modelo não deve possuir autoridade ilimitada simplesmente porque tem “inteligência artificial” no nome.
4. O orçamento de tempo da transação
Quando alguém lê que o z17 pode executar inferências com tempo de resposta inferior a 1 milissegundo, pode imaginar que toda a compra será concluída nesse intervalo.
Não é isso.
Um milissegundo é:
[
1\text{ ms} = 0{,}001\text{ segundo}
]
O número divulgado refere-se ao processamento da inferência no cenário medido, não ao tempo total da transação desde a maquininha até a resposta final.
A operação completa ainda pode incluir:
transmissão pelas redes;
validação criptográfica;
leitura de bancos de dados;
execução de regras;
verificação de limite;
gravação de logs;
atualização de saldos;
journaling;
construção da resposta;
retorno à maquininha.
Pense na transação como um filme de duas horas e na inferência como uma cena importante dentro dele.
O Telum II não precisa filmar o longa-metragem inteiro em um milissegundo. Ele precisa executar sua cena sem estourar o cronograma da produção.
Isso é fundamental porque toda aplicação crítica possui um orçamento de latência.
Se a autorização inteira precisa responder em determinado intervalo, não podemos entregar quase todo esse orçamento a um modelo remoto.
Uma chamada externa pode exigir:
montar uma requisição;
serializar os dados;
criptografar;
atravessar a rede;
autenticar no serviço;
entrar numa fila;
executar a inferência;
montar a resposta;
retornar pela rede;
tratar timeouts e erros.
Mesmo que a média seja boa, há uma pergunta mais importante:
O comportamento continuará previsível durante os picos?
Em ambiente crítico, não basta dizer que a resposta média foi de 5 ms.
Precisamos conhecer:
percentil 95;
percentil 99;
percentil 99,9;
comportamento em saturação;
impacto sobre outros workloads;
tempo máximo aceitável;
estratégia de fallback;
resultado quando o serviço não responder.
Uma média bonita pode esconder um pequeno grupo de respostas terrivelmente lentas.
E o sistema bancário não pode dizer ao comerciante:
— Tivemos um excelente tempo médio hoje. Infelizmente, sua venda caiu no percentil azarado.
5. Telum II: o investigador sentado dentro do banco
O Telum II é o processador que equipa o IBM z17 e inclui a segunda geração do acelerador integrado de IA.
A palavra mais importante é “integrado”.
A inferência pode acontecer muito perto da carga transacional, sem depender de um acelerador remoto pendurado do outro lado de uma rede.
Segundo a IBM, o acelerador do Telum II oferece quatro vezes a capacidade computacional da geração anterior, chegando a 24 TOPS, além de suporte a INT8 e melhorias destinadas a ampliar a variedade de modelos executáveis. O processador também trabalha com caches maiores, melhorias de roteamento e uma DPU destinada a auxiliar operações de entrada e saída. IBM Telum II.
O que são TOPS?
TOPS significa trillions of operations per second, ou trilhões de operações por segundo.
É uma medida da capacidade computacional do acelerador.
Entretanto, TOPS não contam toda a história.
Dois aceleradores com números semelhantes podem produzir resultados diferentes devido a:
arquitetura;
precisão numérica;
eficiência do compilador;
movimentação de dados;
memória;
cache;
tipo do modelo;
tamanho do lote;
utilização dos núcleos;
integração com a aplicação.
É como comparar dois restaurantes apenas pelo número de fogões. O resultado também depende da cozinha, dos ingredientes, dos garçons e de alguém lembrar que o cliente pediu o bife sem cebola.
Por que INT8 importa?
Modelos de IA podem trabalhar com diferentes precisões numéricas.
INT8 utiliza números inteiros de oito bits. Em muitos cenários de inferência, isso permite:
representar os parâmetros com menos espaço;
movimentar menos dados;
executar mais operações;
consumir menos energia;
aumentar o throughput.
Essa redução de precisão precisa ser validada para garantir que o modelo continue suficientemente acurado.
Não adianta tornar a inferência quatro vezes mais rápida se ela passar a confundir Frank Abagnale com o gerente da agência.
6. Spyre: a equipe de inteligência no andar de cima
Se o Telum II é o agente posicionado diretamente no balcão de imigração, o Spyre é uma equipe adicional de inteligência.
O IBM Spyre Accelerator é fornecido em placas PCIe e possui 32 núcleos de aceleração por chip. Várias placas podem ser combinadas para atender cargas maiores. O produto tornou-se disponível para IBM z17 e LinuxONE 5 em outubro de 2025. Anúncio oficial do Spyre.
Ele foi pensado para complementar o acelerador do Telum II em cenários como:
modelos maiores;
vários modelos trabalhando conjuntamente;
IA generativa;
modelos de linguagem;
aplicações multimodais;
assistentes;
agentes de IA;
análise de dados estruturados e textuais.
Imagine uma transação suspeita.
O Telum II pode executar rapidamente o modelo preditivo principal:
Risco calculado: 78%.
Uma arquitetura mais sofisticada pode combinar outros modelos:
um modelo para o comportamento do dispositivo;
outro para identidade;
outro para lavagem de dinheiro;
um encoder examinando descrições textuais;
um modelo avaliando relações entre contas;
um sistema generativo produzindo um resumo para o analista.
Isso é chamado de abordagem multimodelo ou, em certos contextos, ensemble.
O benchmark dos 450 bilhões de inferências antifraude não deve ser apresentado como resultado obrigatório da soma Telum II mais Spyre.
A alegação foi originalmente associada ao acelerador integrado do Telum II. O Spyre amplia a capacidade e o repertório do sistema, principalmente para modelos mais complexos e novas cargas de IA.
Em resumo:
TELUM II
Inferência transacional rápida, integrada e previsível.
SPYRE
Capacidade complementar para modelos maiores, múltiplos e generativos.Os dois podem trabalhar dentro da mesma estratégia, mas não são peças idênticas.
7. Cinco milhões por segundo não são 450 bilhões por dia
Agora chegamos ao Easter egg matemático escondido no roteiro.
Originalmente diziamos que o z17 podia processar até 5 milhões de inferências por segundo, equivalentes a mais de 450 bilhões por dia.
Vamos convocar o programa COBOL da contabilidade:
[
5.000.000 \times 86.400 = 432.000.000.000
]
Um dia possui 86.400 segundos.
Portanto, cinco milhões de inferências por segundo equivalem a 432 bilhões por dia.
Para chegar a 450 bilhões, precisaríamos de aproximadamente:
[
450.000.000.000 \div 86.400
= 5.208.333
]
Ou cerca de 5,21 milhões de inferências por segundo.
Isso não significa necessariamente que a IBM tenha cometido um erro.
A IBM apresenta números arredondados e indicadores derivados de cenários específicos:
até 5 milhões de inferências por segundo;
até 450 bilhões de inferências por dia;
resposta de aproximadamente 1 ms ou inferior, dependendo da declaração.
O erro aparece quando alguém liga as duas frases com “ou seja”, transformando indicadores de benchmark em uma conversão matemática exata.
Uma formulação mais segura seria:
O IBM z17 pode alcançar até 5 milhões de inferências por segundo em determinado cenário e, segundo outro indicador divulgado pela IBM, até 450 bilhões de inferências por dia.
Curiosidade para o programador iniciante: sempre desconfie de expressões como:
“ou seja”;
“equivale a”;
“portanto”;
“isso representa”.
Elas parecem conectores inocentes, mas frequentemente escondem o exato lugar onde marketing, arredondamento e matemática decidiram falsificar um cheque juntos.
8. O que o benchmark realmente mediu?
O número de 450 bilhões por dia não caiu do céu diretamente na capa de uma revista.
Segundo a metodologia publicada pela IBM, o resultado foi extrapolado de testes internos com:
hardware IBM tipo 9175;
modelo LSTM sintético para detecção de fraude em cartões;
batch size de 160;
ambientes Red Hat Enterprise Linux e z/OS;
z/OS Container Extensions;
configuração específica de CPUs, IFLs, zIIPs e memória.
A IBM também informa claramente que os resultados podem variar. Metodologia do benchmark do z17.
O que é LSTM?
LSTM significa Long Short-Term Memory.
É um tipo de rede neural recorrente desenvolvido para trabalhar com sequências e dependências temporais.
Em fraude, isso pode ser útil porque o significado de uma transação depende frequentemente daquilo que aconteceu antes.
Exemplo:
10:01 — compra de R$ 25 em Itatiba
10:04 — compra de R$ 19 em Itatiba
10:07 — compra de R$ 12.000 em TóquioA última transação não é suspeita apenas pelo valor. Ela é suspeita pela relação temporal e geográfica com as anteriores.
Modelos atuais podem empregar outras arquiteturas, mas a LSTM continua sendo uma referência útil para determinados problemas sequenciais.
O que é batch size?
Batch size é a quantidade de amostras processadas conjuntamente.
No teste divulgado, o lote era de 160 inferências.
Isso ajuda o acelerador a utilizar melhor seus recursos, assim como uma transportadora consegue mover caixas com mais eficiência quando carrega um caminhão inteiro em vez de enviar um veículo para cada pacote.
Entretanto, batching cria uma consideração importante:
throughput mede quanto trabalho total é concluído;
latência mede quanto tempo cada solicitação espera e leva para ser respondida.
Grandes lotes podem aumentar o throughput, mas, dependendo da implementação, também podem fazer uma solicitação aguardar o lote ser formado.
Por isso, nunca analise apenas um número.
Pergunte:
Qual era o modelo?
Qual era o tamanho do lote?
Quantas threads foram usadas?
Qual era a configuração?
A latência apresentada é média ou percentil?
O resultado foi medido ou extrapolado?
Havia carga transacional concorrente?
O modelo era real ou sintético?
Essa é uma dica de ouro para qualquer benchmark, não apenas de mainframe.
9. Inferência não é sinônimo de transação
Outra armadilha está na palavra “operação”.
Quando ouvimos “450 bilhões de operações de inferência”, é tentador imaginar 450 bilhões de compras analisadas.
Mas uma transação pode executar vários modelos:
MODELO 1 — fraude do cartão
MODELO 2 — risco do dispositivo
MODELO 3 — identidade comprometida
MODELO 4 — localização anômala
MODELO 5 — lavagem de dinheiro
MODELO 6 — conta-laranjaUma única compra poderia gerar seis inferências.
Logo:
1 transação ≠ obrigatoriamente 1 inferênciaTambém é possível processar inferências em lotes ou utilizar modelos diferentes conforme o tipo de operação.
O número demonstra capacidade de execução de modelos. Não deve ser convertido automaticamente em quantidade de cartões, clientes ou compras.
É como olhar o contador de instruções executadas pelo processador e concluir que cada instrução representa um cliente atendido.
O COBOLzeiro olha para isso, toma um gole de café e pergunta:
— Onde está o copybook com a definição dessa unidade?
Pergunta correta.
10. “Levar a IA até os dados” não significa eliminar toda movimentação
Uma das frases mais fortes da apresentação do z17 é a ideia de executar IA onde os dados residem.
Mas precisamos interpretá-la corretamente.
Não significa que nenhum byte jamais se mova.
Dentro do sistema ainda haverá:
leitura de registros;
acesso a memória;
comunicação entre componentes;
preparação das variáveis;
busca de características;
passagem de parâmetros;
gravação do resultado.
O que pode ser evitado é a necessidade de enviar a transação para um serviço remoto de inferência, fora do ambiente em que a aplicação crítica está sendo executada.
Isso reduz:
dependência da rede;
latência externa;
serialização;
pontos adicionais de falha;
exposição de dados sensíveis;
fronteiras operacionais;
complexidade de auditoria.
Compare os dois caminhos.
Inferência remota
COBOL/CICS
↓
API
↓
GATEWAY
↓
REDE
↓
SERVIÇO EXTERNO
↓
MODELO
↓
REDE
↓
RESPOSTA
↓
DECISÃOInferência local
COBOL/CICS
↓
SERVIÇO DE INFERÊNCIA NO AMBIENTE IBM Z
↓
TELUM II
↓
SCORE
↓
DECISÃOO segundo caminho não é magicamente gratuito, mas reduz fronteiras.
E cada fronteira removida significa menos um lugar para:
perder tempo;
falhar;
expirar;
autenticar;
converter dados;
abrir uma porta de ataque;
explicar para a auditoria.
11. O cloud não é o vilão do filme
Seria confortável transformar esta história num duelo:
MAINFRAME = HERÓI
CLOUD = VIGARISTAMas arquitetura séria não funciona como desenho animado.
Cloud pode ser excelente para:
treinamento de modelos;
experimentação;
notebooks;
ciência de dados;
armazenamento histórico;
elasticidade;
processamento assíncrono;
comparação de versões;
grandes modelos;
investigação posterior.
O IBM Z pode ser particularmente apropriado para:
inferência na transação;
dados regulados;
baixa latência previsível;
enorme volume;
integração com sistemas existentes;
disponibilidade;
segurança e auditoria;
continuidade operacional.
Uma arquitetura híbrida madura pode funcionar assim:
PLATAFORMA DE DADOS OU CLOUD
↓
TREINAMENTO
↓
VALIDAÇÃO
↓
APROVAÇÃO DO MODELO
↓
EMPACOTAMENTO
↓
IMPLANTAÇÃO NO IBM Z
↓
INFERÊNCIA TRANSACIONAL
↓
MONITORAMENTO E FEEDBACKO modelo aprende em um ambiente e trabalha em outro.
Isso também cria responsabilidades importantes:
versionar o modelo;
registrar quem o aprovou;
controlar sua implantação;
medir drift;
comparar versões;
permitir rollback;
manter explicabilidade;
preservar evidências.
O modelo é um componente de produção. Deve receber disciplina semelhante à de qualquer outro artefato crítico.
Se você jamais colocaria um load module não testado diretamente em produção, também não deveria instalar um modelo treinado na sexta-feira por alguém que escreveu no change:
“Melhorias diversas. Baixo risco.”
12. Falso positivo: quando o FBI prende o piloto verdadeiro
Um sistema antifraude pode errar de duas maneiras principais.
Falso negativo
A transação era fraudulenta, mas foi considerada legítima.
Consequências possíveis:
perda financeira;
chargeback;
investigação;
desgaste com o cliente;
impacto regulatório.
Falso positivo
A transação era legítima, mas foi considerada fraudulenta.
Consequências:
compra recusada;
cliente constrangido;
perda da venda;
chamada ao atendimento;
cancelamento do cartão;
deterioração da confiança.
Imagine o cliente viajando pela Europa depois de meses comprando apenas em São Paulo.
O comportamento mudou bruscamente, mas existe uma explicação legítima.
Um modelo ruim pode confundir “fora do padrão” com “fraude”.
Essa é uma distinção essencial:
Anomalia não é prova de crime. É motivo para investigar ou aplicar controles proporcionais.
Por isso, uma instituição pode criar diferentes respostas:
risco baixo: aprovar;
risco moderado: solicitar biometria;
risco alto: enviar notificação;
risco muito alto: bloquear;
caso complexo: análise humana.
Quanto mais rápido o score estiver disponível, mais opções o banco terá.
Em vez de escolher apenas entre aprovar e negar, pode inserir autenticação adaptativa sem destruir a experiência do cliente.
13. Segurança local não é segurança automática
Colocar a IA no mainframe não elimina:
credenciais roubadas;
engenharia social;
fraude interna;
dados de treinamento contaminados;
modelos enviesados;
configuração incorreta;
permissões excessivas;
falhas de aplicação;
ataques adversariais;
decisões de negócio ruins.
O ambiente local pode ajudar a proteger:
confidencialidade dos dados;
propriedade intelectual do modelo;
tráfego sensível;
disponibilidade;
cadeia de auditoria;
previsibilidade operacional.
Mas o sistema ainda precisa de:
RACF bem administrado;
princípio do menor privilégio;
criptografia;
segregação de funções;
logging;
monitoramento;
revisão de modelos;
gestão de vulnerabilidades;
resposta a incidentes;
governança de IA.
A IA é apenas uma camada.
A arquitetura completa se parece mais com isto:
IDENTIDADE
+
DADOS CONFIÁVEIS
+
MODELO VALIDADO
+
APLICAÇÃO CORRETA
+
REGRAS DE NEGÓCIO
+
AUDITORIA
+
RESPOSTA OPERACIONALSe qualquer camada estiver comprometida, o vigarista poderá atravessar o sistema usando um belo uniforme e um crachá perfeitamente impresso.
14. Passo a passo para o COBOLzeiro entender uma integração com IA
Você não precisa se transformar imediatamente em cientista de dados. Comece fazendo as perguntas corretas.
Passo 1 — Entenda o evento de negócio
Defina exatamente o que será avaliado:
compra?
PIX?
abertura de conta?
alteração cadastral?
saque?
pedido de empréstimo?
Passo 2 — Identifique as entradas
Descubra quais informações alimentam o modelo:
VALOR
HORARIO
PAIS
DISPOSITIVO
HISTORICO
TENTATIVAS
IDADE-DA-CONTA
TIPO-DE-CANALPasso 3 — Conheça o contrato
O serviço deve possuir um contrato claro:
ENTRADA:
DADOS-DA-TRANSACAO
SAIDA:
SCORE-DE-RISCO
VERSAO-DO-MODELO
CODIGO-DE-STATUS
MOTIVO
TEMPO-DE-INFERENCIAA versão do modelo é fundamental para auditoria.
Passo 4 — Defina o timeout
O que acontecerá se a inferência não responder?
negar tudo;
aprovar tudo;
usar regras tradicionais;
chamar um modelo alternativo;
encaminhar para validação adicional?
Não responder também é um resultado operacional, e precisa de regra.
Passo 5 — Separe score de decisão
Evite permitir que o modelo controle diretamente a transação.
MODELO → SCORE
REGRA → DECISÃOPasso 6 — Registre evidências
Grave pelo menos:
identificador da transação;
horário;
score;
versão do modelo;
decisão;
regra aplicada;
resultado posterior conhecido.
Isso permite reconstruir a história.
Passo 7 — Monitore desempenho e qualidade
Observe:
latência;
throughput;
erros;
timeouts;
falsos positivos;
falsos negativos;
mudança no perfil dos dados;
queda de acurácia.
Passo 8 — Prepare rollback
Se o novo modelo começar a bloquear metade da população de Itatiba, você precisa retornar rapidamente à versão anterior.
MLOps sem rollback é apenas aventura.
15. Easter eggs recuperados do cheque falsificado
Easter egg número 1 — O mainframe já fazia “IA” antes da moda
Bancos utilizam modelos estatísticos, regras, scores e análise de risco há décadas.
O que mudou não foi a descoberta repentina de que padrões podem indicar fraude. Mudaram:
escala;
variedade dos modelos;
integração;
velocidade;
capacidade de processar mais sinais;
uso de aceleradores especializados.
A inteligência transacional não nasceu ontem. Ela ganhou músculos novos.
Easter egg número 2 — O COBOL não perdeu o emprego para a IA
A IA pode calcular a probabilidade de fraude, mas alguém ainda precisa:
validar a mensagem;
aplicar o limite;
controlar a conta;
atualizar o saldo;
produzir o registro;
garantir atomicidade;
tratar exceções;
responder ao canal.
O modelo pode dizer que o cheque parece suspeito.
O COBOL continua sendo o funcionário que decide se o cheque entra no movimento e garante que o livro-caixa feche no final do dia.
Easter egg número 3 — Frank Abagnale trabalhou para o FBI
A melhor ironia da história é que o fraudador pode ensinar o sistema a identificar fraudes.
Na segurança, o conhecimento ofensivo frequentemente fortalece a defesa.
Da mesma forma, fraudes confirmadas tornam-se exemplos de treinamento. O atacante, involuntariamente, deixa material para melhorar o próximo modelo.
É quase um programa de estágio não remunerado do Red Team.
Easter egg número 4 — A velocidade pode reduzir fraude sem aumentar bloqueios
Com mais capacidade de inferência, o banco pode executar vários modelos em vez de depender de uma única regra agressiva.
Isso permite distinguir melhor:
comportamento incomum;
comportamento realmente malicioso;
cliente viajando;
conta comprometida;
compra legítima de alto valor;
fraude coordenada.
Mais inteligência pode significar não apenas bloquear mais, mas bloquear melhor.
Easter egg número 5 — O mainframe não precisa aparecer na manchete
Quando uma transação é aprovada corretamente, ninguém comemora:
— Fantástico! O sistema consultou o limite, avaliou o risco, atualizou os registros e respondeu dentro do SLA!
O cliente apenas guarda o cartão.
O sucesso do sistema crítico é frequentemente invisível.
Ele só vira notícia quando para.
16. O verdadeiro “Catch Me If You Can” da fraude moderna
Frank Abagnale precisava manter sua história por alguns minutos.
A fraude digital precisa parecer legítima por milissegundos.
Ela corre entre:
a captura dos dados;
a autenticação;
a análise;
a autorização;
a liquidação.
O IBM z17 procura fechar esse intervalo colocando capacidade de inferência dentro do núcleo transacional.
Não é uma solução mágica.
Não elimina a necessidade de investigadores, regras, autenticação, governança, criptografia ou analistas.
O que ele faz é permitir que a aplicação pergunte, no momento decisivo:
Esta operação se parece com aquilo que afirma ser?
E receba uma resposta antes que o suspeito chegue ao portão de embarque.
A grande inovação não está apenas em fazer cinco milhões de cálculos por segundo. Está em realizar a análise cedo o bastante para mudar o destino da transação.
Antes, muitos sistemas descobriam a fraude depois:
a operação era aprovada;
o dinheiro seguia seu caminho;
o cliente reclamava;
começava a investigação;
alguém tentava recuperar o prejuízo.
Era perícia.
Com a inferência transacional, a inteligência pode participar do processo antes da conclusão:
a operação chega;
os dados são avaliados;
o modelo produz o score;
as regras interpretam o risco;
o sistema aprova, bloqueia ou desafia;
a decisão é registrada.
É a diferença entre encontrar a falsificação no arquivo morto e pará-la no balcão.
Epílogo — O cheque, o COBOL e o homem de uniforme
No final do filme, o vigarista não é derrotado porque alguém construiu uma parede infinitamente alta.
Ele é alcançado porque o investigador aprende a reconhecer seus padrões.
O papel usado.
A forma de imprimir.
As cidades escolhidas.
O modo como ele conta a história.
Fraude é repetição disfarçada de improviso.
A inteligência artificial encontra valor justamente nessa repetição: relações pequenas demais, rápidas demais ou numerosas demais para depender exclusivamente da observação humana.
O Telum II aproxima essa análise do lugar onde a decisão acontece.
O Spyre amplia o repertório para modelos maiores e abordagens mais complexas.
O z17 fornece o ambiente para executar isso com a velocidade, a escala, o isolamento e a previsibilidade exigidos por sistemas críticos.
E o COBOL?
O COBOL continua no balcão.
Recebe a mensagem.
Valida o cartão.
Consulta o limite.
Interpreta o score.
Executa a regra.
Grava a decisão.
Libera ou recusa a transação.
Talvez ele não apareça no trailer. Talvez ninguém compre uma camiseta escrito PERFORM UNTIL FRAUD-DETECTED. Mas, quando Frank Abagnale chegar usando o uniforme de piloto, será o velho programa transacional que olhará o score calculado em menos de um milissegundo e dirá:
IF IDENTIDADE-PARECE-PERFEITA
AND HISTORIA-NAO-FECHA
MOVE 'N' TO AUTORIZAR
MOVE 'PRENDA-ME-SE-FOR-CAPAZ'
TO MOTIVO-RECUSA
END-IF.No andar de cima, o Spyre cruza os dossiês.
Dentro do processador, o Telum II examina o próximo passageiro.
No CICS, outra tarefa começa.
E em algum lugar do datacenter, um COBOL escrito quando Leonardo DiCaprio ainda era criança continua protegendo uma transação que jamais saberá seu nome.
Para ir mais longe
https://eljefemidnightlunch.blogspot.com/2026/08/spy-vs-spy-no-tribunal-as-trapacas.html
https://eljefemidnightlunch.blogspot.com/2026/08/red-team-e-os-doze-trabalhos-de-asterix.html
