Translate

terça-feira, 14 de julho de 2026

Machine Learning sem Mistérios

Bellacosa Mainframe em machine learning sem misterios

☕ Um Café no Bellacosa Mainframe

Machine Learning sem Mistérios

O Guia Definitivo do Programador COBOL Padawan para Entrar no Mundo da Inteligência Artificial sem Esquecer os Fundamentos

"Todo Mestre Jedi da IA começou entendendo os dados antes de treinar o primeiro modelo."


Introdução – O Erro que Muitos Estão Cometendo em 2026

Existe um fenômeno curioso acontecendo na indústria.

Todos querem aprender IA.

Todos querem aprender ChatGPT.

Todos querem aprender LLMs.

Todos querem aprender Agentes de IA.

Mas poucos querem aprender Machine Learning.

É como alguém querer aprender CICS sem saber COBOL.

Ou querer administrar um Db2 sem nunca ter visto uma tabela.

Ou ainda querer fazer tuning de SQL sem entender como funciona um índice.

O resultado?

Profissionais que sabem usar ferramentas, mas não compreendem o que acontece por trás delas.

No universo IBM Z isso seria impensável.

Nenhum programador COBOL experiente diria:

"Não preciso entender JCL porque hoje existe DevOps."

Da mesma forma...

Nenhum Engenheiro de IA deveria dizer:

"Não preciso aprender Machine Learning porque existe GPT."

Os LLMs são apenas um dos milhares de produtos da árvore gigantesca chamada Machine Learning.

Neste artigo vamos construir essa árvore desde as raízes.

Não utilizando matemática pesada.

Mas utilizando aquilo que um programador COBOL conhece melhor do que ninguém:

dados, regras de negócio, processamento e tomada de decisão.

Pegue seu café.

Nossa jornada está apenas começando.


Bellacosa Mainframe e os algoritmo de machine learning

O que realmente é Machine Learning?

Antes de tudo precisamos desfazer um mito.

Machine Learning NÃO significa que o computador pensa.

Ele também NÃO significa que o computador ficou inteligente.

Na verdade...

Machine Learning significa apenas uma coisa:

Encontrar padrões automaticamente a partir dos dados.

Nada mais.

Nada menos.

Imagine um programa COBOL.

Normalmente fazemos algo assim:

IF SALDO > 10000
   MOVE "VIP" TO TIPO-CLIENTE
ELSE
   MOVE "NORMAL" TO TIPO-CLIENTE
END-IF

Quem criou essa regra?

Você.

Agora imagine milhões de clientes.

Talvez existam centenas de regras.

Talvez milhares.

Talvez nenhuma pessoa consiga descobri-las.

É aqui que entra Machine Learning.

O algoritmo encontra essas regras sozinho.


Uma analogia para quem vive no Mainframe

Imagine que você trabalha em um banco.

Existe um arquivo VSAM com 50 milhões de clientes.

Cada registro possui:

IDADE

SALÁRIO

PROFISSÃO

ESTADO

QUANTIDADE DE CARTÕES

RENDA

LIMITE

UTILIZAÇÃO

INADIMPLENTE?

Durante vinte anos o banco registrou tudo.

Você já sabe quais clientes ficaram inadimplentes.

Agora surge um novo cliente.

Como prever se ele pode dar prejuízo?

Você pode escrever milhares de IFs...

Ou pode deixar o algoritmo aprender.

Esse é exatamente o objetivo do Machine Learning.


IA não começou com o ChatGPT

Outro erro comum.

Muitos acreditam que IA nasceu em 2022.

Na verdade...

A história começa muito antes.

Década de 1950.

Depois vieram:

  • Regressão

  • Redes Bayesianas

  • Árvores de decisão

  • Redes neurais

  • SVM

  • Random Forest

  • Gradient Boosting

Somente décadas depois apareceram:

  • Deep Learning

  • Transformers

  • GPT

  • Claude

  • Gemini

Ou seja...

LLMs são apenas um capítulo.

Não o livro inteiro.


A grande árvore do Machine Learning

Imagine uma árvore gigantesca.

Seu tronco chama-se:

Machine Learning

Dela nascem quatro grandes galhos:

Machine Learning

│

├── Supervisionado

├── Não Supervisionado

├── Semi-Supervisionado

└── Aprendizado por Reforço

Cada um resolve problemas completamente diferentes.


Aprendizado Supervisionado

É o tipo mais utilizado pelas empresas.

Aqui existe um professor.

Imagine um pai ensinando uma criança.

Ele mostra um cachorro.

Diz:

"Cachorro."

Mostra outro.

"Cachorro."

Mostra outro.

"Cachorro."

Depois de milhares de exemplos...

A criança aprende.

Machine Learning funciona exatamente assim.


Dados Rotulados

O segredo está nos rótulos.

Imagine um arquivo:

IDADE

RENDA

EMPRÉSTIMO

PAGOU?

O campo PAGOU é conhecido.

Logo...

Existe um professor.

Esse conjunto chama-se:

Dados rotulados.


Classificação

Agora queremos responder perguntas como:

SIM

NÃO

Ou

Fraude

Não fraude

Ou

Spam

Não Spam

Ou

Cliente Ouro

Cliente Prata

Cliente Bronze

Não queremos números.

Queremos categorias.


Logistic Regression

Apesar do nome...

Ela faz classificação.

Sua missão é calcular probabilidades.

Por exemplo:

Cliente A

98%

↓

Grande chance de inadimplência.

É extremamente utilizada por bancos.

Também por seguradoras.

E por fintechs.


Naïve Bayes

Esse algoritmo nasceu baseado no famoso Teorema de Bayes.

Ele faz uma suposição simplificadora.

Considera que as variáveis são independentes.

Na prática isso raramente acontece.

Mesmo assim...

Ele funciona surpreendentemente bem.

É excelente para:

  • filtros de spam

  • classificação de textos

  • análise documental

  • NLP clássico


K-Nearest Neighbors (KNN)

Imagine mudar para um bairro novo.

Você provavelmente terá hábitos parecidos com os vizinhos.

O algoritmo pensa igual.

Ele procura os registros mais próximos.

Depois pergunta:

"A maioria pertence a qual grupo?"

Se oito dos dez vizinhos são clientes premium...

Talvez você também seja.

Muito simples.

Muito intuitivo.

Mas caro computacionalmente em bases enormes.


Árvores de Decisão

Provavelmente o algoritmo mais fácil de explicar.

Ele faz perguntas.

Idade > 30?

↓

Sim

↓

Salário > 8000?

↓

Sim

↓

Cliente Premium

É quase um grande IF...

Só que aprendido automaticamente.

Um programador COBOL costuma entender esse algoritmo imediatamente.


Random Forest

Agora imagine cem árvores.

Cada uma observa os dados de maneira ligeiramente diferente.

Cada uma vota.

A maioria vence.

Esse é o conceito da Random Forest.

Ela reduz erros individuais e costuma apresentar excelente desempenho em dados tabulares, muito comuns em sistemas corporativos.


Support Vector Machine

Agora pense em dois grupos de clientes.

● ● ● ● ●

▲ ▲ ▲ ▲ ▲

Existe uma fronteira entre eles.

A missão da SVM é encontrar a melhor linha (ou hiperplano) que separa essas classes.

Ela é poderosa em problemas com poucas variáveis e conjuntos de dados médios.


Regressão

Agora não queremos responder "Sim" ou "Não".

Queremos prever números.

Exemplos:

  • faturamento

  • temperatura

  • consumo

  • preço de imóvel

  • demanda de energia


Regressão Linear

Imagine que quanto maior a casa...

Maior o preço.

A regressão procura justamente a reta que melhor representa essa relação.

É um dos algoritmos mais antigos e ainda hoje extremamente útil.


Lasso Regression

Além de prever valores, ela consegue eliminar automaticamente variáveis pouco relevantes.

Isso reduz complexidade e ajuda a evitar modelos excessivamente ajustados (overfitting).


Aprendizado Não Supervisionado

Agora ninguém sabe a resposta.

Não existem rótulos.

Você apenas entrega os dados.

O algoritmo precisa descobrir padrões sozinho.

É como um DBA recebendo um banco desconhecido e tentando entender sua estrutura apenas observando os dados.


Clustering

O objetivo agora é agrupar registros semelhantes.

Não existe resposta certa.

Existem apenas padrões.


K-Means

O algoritmo escolhe centros.

Depois aproxima os registros desses centros.

No final surgem grupos.

Muito usado para segmentação de clientes.


DBSCAN

Ao contrário do K-Means, ele não precisa saber previamente quantos grupos existem.

Também consegue identificar ruídos.

Excelente para encontrar padrões complexos.


Redução de Dimensionalidade

Imagine uma tabela Db2 com 500 colunas.

Será que todas são importantes?

Provavelmente não.

É aqui que entram:

  • PCA

  • ICA


PCA

Principal Component Analysis.

Reduz centenas de variáveis para poucas dimensões mantendo a maior parte da informação.

Muito utilizado antes do treinamento dos modelos.


ICA

Independent Component Analysis.

Seu objetivo é separar sinais independentes.

Muito usado em processamento de voz, imagens e sinais biomédicos.


Associação

Esses algoritmos procuram regras ocultas.

Exemplo:

Quem compra café

↓

também compra açúcar.

Ou

Quem compra notebook

↓

compra mochila.

Os algoritmos clássicos são:

  • Apriori

  • FP-Growth

Muito utilizados em e-commerce e supermercados.


Detecção de Anomalias

Essa área é extremamente importante para bancos.

Imagine um cliente.

Sempre realiza compras em São Paulo.

Hoje aparece:

03:14 AM

Japão

US$ 8.500

Isso foge completamente do padrão.

Os algoritmos detectam esse comportamento.


Isolation Forest

Em vez de aprender o comportamento normal, ele procura aquilo que é fácil de isolar.

Fraudes normalmente aparecem rapidamente como pontos isolados.

É um algoritmo muito utilizado em segurança, observabilidade e detecção de ataques.


Aprendizado Semi-Supervisionado

Imagine um banco de dados com:

100 milhões de clientes.

Apenas:

5 mil registros rotulados.

Rotular dados custa caro.

Então o algoritmo aprende utilizando:

  • poucos exemplos conhecidos;

  • muitos exemplos desconhecidos.

Esse cenário é bastante comum na indústria.


Aprendizado por Reforço

Agora não existe professor.

Existe recompensa.

Imagine ensinar uma criança.

Acertou.

+10 pontos

Errou.

-5 pontos

Depois de milhares de tentativas...

Ela aprende a escolher as melhores ações.


Q-Learning

É um dos algoritmos clássicos.

Aprende qual decisão gera maior recompensa no longo prazo.

Muito usado em:

  • robótica

  • jogos

  • sistemas autônomos


Model-Based Reinforcement Learning

Aqui o agente vai além.

Ele aprende como o ambiente funciona.

Depois simula mentalmente vários cenários antes de agir.

É semelhante ao planejamento de produção ou à simulação de cargas em um ambiente z/OS.


O que a imagem ainda não mostra

O roadmap clássico é excelente, mas a IA moderna evoluiu.

Hoje você também encontrará:

Ensemble Learning

  • XGBoost

  • LightGBM

  • CatBoost

  • Gradient Boosting

São frequentemente os campeões em dados tabulares.


Deep Learning

Aqui entram:

  • CNN

  • RNN

  • LSTM

  • GRU

  • Autoencoders

  • Transformers

Esses modelos revolucionaram visão computacional, linguagem natural e reconhecimento de padrões complexos.


IA Generativa

Finalmente chegamos aos famosos LLMs.

Eles utilizam arquiteturas Transformer e são treinados sobre enormes volumes de texto.

Aqui encontramos:

  • GPT

  • Claude

  • Gemini

  • Llama

  • Mistral

Além deles surgem componentes fundamentais como:

  • Embeddings

  • Busca Vetorial

  • RAG (Retrieval-Augmented Generation)

  • Bancos Vetoriais

Esses elementos permitem que um modelo consulte conhecimento externo antes de responder.


O papel do Machine Learning no IBM Z

Quem trabalha com COBOL, Db2 e IBM Z talvez imagine que Machine Learning pertence apenas às startups.

Na realidade, ele já está presente em inúmeras aplicações corporativas:

  • previsão de inadimplência;

  • detecção de fraude em cartões;

  • classificação automática de documentos;

  • segmentação de clientes;

  • previsão de demanda;

  • análise de séries temporais;

  • detecção de anomalias em logs SMF/RMF;

  • otimização de cargas batch;

  • manutenção preditiva de hardware;

  • busca semântica em documentos corporativos;

  • recomendação de produtos financeiros.

O IBM Z já oferece aceleração para IA e integrações com ecossistemas modernos, permitindo que modelos sejam treinados ou inferidos próximos dos dados, reduzindo latência e aumentando a segurança.


Como um Padawan COBOL deve iniciar essa jornada?

Não tente aprender tudo de uma vez.

Construa sua base em camadas, exatamente como você faria ao aprender o ecossistema mainframe.

  1. Matemática essencial

    • Álgebra linear

    • Probabilidade

    • Estatística

    • Cálculo básico (conceitos)

  2. Python para Ciência de Dados

    • NumPy

    • Pandas

    • Matplotlib

  3. Machine Learning clássico

    • Regressão

    • Classificação

    • Clustering

    • Validação de modelos

  4. Scikit-learn

    • Treinamento

    • Avaliação

    • Pipelines

  5. Deep Learning

    • TensorFlow ou PyTorch

    • Redes neurais

    • CNNs

    • Transformers

  6. IA Generativa

    • Embeddings

    • RAG

    • LLMs

    • Agentes

  7. MLOps

    • Versionamento

    • Deploy

    • Monitoramento

    • Governança


Easter Egg Bellacosa Mainframe ☕

Existe uma frase muito conhecida entre programadores COBOL:

"Os dados sempre contam a verdade; quem mente é o programa."

No Machine Learning podemos adaptá-la:

"Os modelos aprendem aquilo que os dados ensinam. Se os dados carregam erros, preconceitos ou inconsistências, o modelo apenas os reproduz em escala."

Por isso, a maior parte do trabalho de um cientista de dados não é treinar modelos, mas compreender o domínio do negócio, preparar os dados, validá-los e monitorar continuamente o comportamento dos sistemas em produção.


Conclusão

Machine Learning não é uma moda passageira nem um substituto para a programação tradicional. Ele é uma extensão da engenharia de software orientada por dados. Para um programador COBOL, a transição é mais natural do que parece: você já domina regras de negócio, processamento em lote, qualidade de dados e sistemas críticos. O próximo passo é aprender como fazer com que algoritmos descubram padrões que antes precisavam ser codificados manualmente.

LLMs impressionam porque conversam. Mas a inteligência corporativa vai muito além da geração de texto. Empresas precisam prever inadimplência, detectar fraudes, otimizar processos, recomendar produtos, classificar documentos e tomar decisões em tempo real. Tudo isso continua sendo sustentado pelos fundamentos do Machine Learning.

Assim como um bom engenheiro de mainframe nunca ignora conceitos como JCL, VSAM, CICS ou Db2, um futuro engenheiro de IA não deve ignorar regressão, árvores de decisão, Random Forest, clustering, PCA ou aprendizado por reforço.

As ferramentas continuarão mudando. Novos frameworks aparecerão todos os anos. Mas os fundamentos matemáticos, estatísticos e algorítmicos que sustentam o Machine Learning permanecem os mesmos há décadas — e continuarão sendo a base sobre a qual as próximas gerações de inteligência artificial serão construídas.

O verdadeiro Mestre Jedi da IA não é aquele que apenas sabe chamar uma API de um LLM. É aquele que entende por que o modelo funciona, quando ele falha e qual algoritmo é mais adequado para cada problema. Essa é a diferença entre usar inteligência artificial e realmente praticar engenharia de inteligência artificial.

Capítulo 14 — O Julgamento da História

Bellacosa Mainframe e o Julgamento da Historia

☕ Um Café no Bellacosa Mainframe

Capítulo 14 — O Julgamento da História

Quarenta Anos Depois, Quem Estava Certo?

O capítulo final reúne as principais lições das previsões sobre a morte do mainframe e mostra como a evolução do IBM Z oferece ensinamentos para o futuro da computação corporativa.

Por

A evolução do IBM Mainframe julgada pela história após quarenta anos
As manchetes envelhecem. A engenharia permanece. Quatro décadas depois, a história oferece seu veredito sobre o futuro do mainframe.

"A História não julga pelas manchetes. Ela julga pelos sistemas que continuam funcionando."

— Bellacosa Mainframe

O veredito da História

Após quarenta anos de previsões sobre o desaparecimento do mainframe, bancos, seguradoras, governos, companhias aéreas e grandes empresas continuam executando bilhões de transações diárias sobre plataformas IBM Z, agora integradas com APIs, Linux, containers, OpenShift, Inteligência Artificial e cloud híbrida.

O julgamento histórico mostra que a evolução tecnológica não ocorreu por substituições absolutas, mas por integração contínua e preservação do conhecimento acumulado.

O legado para as próximas gerações

O trabalho de Wolfgang Spruth permitiu preservar um importante registro histórico das previsões sobre a morte do mainframe, oferecendo às novas gerações uma oportunidade rara de comparar expectativas, realidade e evolução tecnológica ao longo das décadas.

A última xícara de café

O verdadeiro legado do IBM Mainframe não é provar que estava certo. É lembrar que engenharia sólida, conhecimento de negócio e inovação contínua costumam sobreviver a modismos passageiros. O futuro pertence às tecnologias capazes de evoluir sem esquecer as lições do passado.


Bellacosa Mainframe e a hora da verdade

Finalmente chegamos ao tribunal

Imagine um enorme tribunal.

Não um tribunal comum.

Um tribunal onde o juiz é o tempo.

As testemunhas são quarenta anos de história da computação.

As provas são milhões de transações executadas todos os dias.

E os jurados...

Somos nós.

Arquitetos.

Programadores.

DBAs.

Operadores.

Sysprogs.

Analistas de negócios.

Estudantes.

Todos aqueles que vivem a computação real.

No banco dos réus existe uma placa.

IBM Mainframe

A acusação?

Ter sobrevivido quando deveria ter desaparecido.


A promotoria apresenta seu caso

O promotor começa.

— Meritíssimo...

Temos aqui dezenas de reportagens.

Forbes.

New York Times.

InfoWorld.

Business Week.

Todas afirmavam que esta plataforma estava ultrapassada.

Que seria substituída.

Que desapareceria.

Que sua arquitetura não possuía futuro.

Apresentamos como prova os artigos preservados pelo Professor Wolfgang Spruth em seu histórico trabalho The Death of the Mainframe.

O juiz olha os documentos.

Todos verdadeiros.

Todos publicados.

Todos assinados por profissionais respeitados.


A defesa não chama advogados

Curiosamente...

A defesa do Mainframe não apresenta um único advogado.

Não chama executivos.

Não chama jornalistas.

Não chama analistas.

Ela chama apenas testemunhas.

Primeira testemunha.

Um banco internacional.

— Quantas transações você processou hoje?

— Bilhões.

Segunda testemunha.

Uma companhia aérea.

— Quantas reservas?

— Milhões.

Terceira.

Uma operadora de cartões.

— Quantas autorizações?

— Milhões por minuto.

Quarta.

Uma seguradora.

— Quantos contratos?

— Dezenas de milhões.

Quinta.

Um governo.

— Quantos cidadãos dependem dos seus sistemas?

— Praticamente todos.

O silêncio toma conta da sala.


A testemunha mais inesperada

Então entra uma testemunha curiosa.

Ela usa camiseta.

Tênis.

Notebook.

Visual Studio Code aberto.

Git.

Python instalado.

Containers.

Kubernetes.

O juiz pergunta:

— Quem é você?

Ele responde.

— Sou um desenvolvedor de 2026.

— O senhor trabalha com Mainframe?

— Sim.

— Mas... o senhor não parece um programador de Mainframe.

O jovem sorri.

— Porque o senhor ainda imagina o Mainframe de 1989.

Eu trabalho com:

Git.

VS Code.

Python.

Zowe.

Ansible.

OpenShift.

DevOps.

REST.

JSON.

watsonx.

COBOL.

Tudo no mesmo ambiente.

O juiz faz uma anotação.


A acusação insiste

O promotor tenta recuperar o controle.

— Mas Excelência...

O Mainframe era fechado.

Centralizado.

Antigo.

O juiz olha para o IBM z17 projetado na tela.

Pergunta:

— Ele continua fechado?

A defesa responde.

— Linux.

Containers.

Kubernetes.

OpenShift.

REST.

Python.

Git.

Java.

Node.js.

Go.

Open APIs.

Cloud híbrida.

IA.

O promotor permanece em silêncio.


Chama-se a Inteligência Artificial

A próxima testemunha surpreende a todos.

É uma Inteligência Artificial.

O juiz pergunta:

— Você trabalha contra o Mainframe?

Ela responde.

— Não.

Trabalho com ele.

— Explique.

— Auxilio desenvolvedores COBOL.

Documento aplicações.

Analiso SQL.

Interpreto JCL.

Explico programas.

Ajudo DBAs.

Auxilio Sysprogs.

Analiso logs.

Automatizo operações.

O juiz sorri discretamente.

Mais uma previsão acabava de perder força.


O depoimento do COBOL

As portas do tribunal se abrem.

Entra um senhor elegante.

Sessenta e seis anos de idade.

Terno impecável.

Calmo.

Seguro.

O juiz pergunta.

— Nome?

— COBOL.

— Profissão?

— Regras de negócio.

— O senhor ainda trabalha?

Ele responde.

— Nunca trabalhei tanto.

A plateia ri.

Mas todos sabem que aquela resposta contém mais verdade do que humor.


O depoimento do JCL

Logo depois entra outro veterano.

Pouco falador.

Muito organizado.

— Nome?

— JCL.

— Idade?

— Não gosto de falar sobre isso.

— O senhor ainda possui utilidade?

Ele responde calmamente.

— Todos os dias organizo milhares de processos batch.

Controlo dependências.

Gerencio datasets.

Inicio cargas.

Executo backups.

Produzo relatórios.

Enquanto todos dormem.

A plateia aplaude.


O Db2 pede a palavra

O banco de dados aproxima-se da tribuna.

— Senhor Db2...

O senhor gostaria de dizer alguma coisa?

— Apenas uma observação.

Enquanto discutiam minha morte...

Continuei armazenando informações críticas de bancos, governos, seguradoras e empresas no mundo inteiro.

Hoje também trabalho com IA, análise em tempo real e integração híbrida.

Nada mais.

O depoimento dura menos de um minuto.

Suficiente.


O CICS também comparece

O juiz pergunta.

— Senhor CICS...

O senhor ainda recebe transações?

O velho monitor transacional responde.

— Algumas.

— Quantas?

— Bilhões.

Novo silêncio.


A última testemunha

O juiz chama Wolfgang Spruth.

Infelizmente ele já não está entre nós.

Mas seu trabalho permanece.

Sobre a mesa repousa sua apresentação.

"The Death of the Mainframe."

O juiz folheia lentamente.

Forbes.

New York Times.

InfoWorld.

Business Week.

Todas as manchetes.

Todas preservadas.

O juiz olha para a plateia.

Comenta.

— Este material nunca foi sobre provar quem estava certo.

Sempre foi sobre ensinar como a História acontece.

Talvez esse seja o maior legado do Professor Spruth.


O veredito

Depois de horas de audiência...

O juiz retorna.

Toda a sala permanece em silêncio.

Ele começa.

— Este tribunal conclui que...

As reportagens analisadas refletiam honestamente o conhecimento disponível em sua época.

Não houve má-fé.

Houve entusiasmo.

Houve confiança excessiva.

Houve extrapolação de tendências.

Houve influência do marketing.

Houve simplificações inevitáveis.

Mas também houve inovação verdadeira.

Client/Server mudou o mercado.

Internet mudou o planeta.

Linux mudou os datacenters.

Cloud mudou a infraestrutura.

IA está mudando a computação.

Nada disso pode ser negado.

O juiz faz uma pausa.

Continua.

— O erro ocorreu quando essas inovações passaram a ser apresentadas como substitutas inevitáveis de tudo o que existia anteriormente.

A História mostrou outro caminho.

Integração.

Compatibilidade.

Evolução.


A sentença

O juiz bate o martelo.

— O IBM Mainframe não é culpado.

A sala sorri.

Ele continua.

— Também declaro inocentes os jornalistas.

A plateia estranha.

O juiz explica.

— Eles apenas tentaram prever o futuro.

Como todos nós fazemos.

A diferença é que o futuro resolveu escrever outra história.


O verdadeiro vencedor

Chega então a última pergunta.

Quem venceu?

IBM?

UNIX?

Linux?

Cloud?

Open Source?

IA?

O juiz responde.

Nenhum deles.

Quem venceu foi a Engenharia.

Porque ela conseguiu integrar todos.

Hoje um único fluxo de negócio pode envolver:

Um aplicativo móvel.

Uma API.

Um microsserviço.

Kafka.

Containers.

Kubernetes.

OpenShift.

Java.

Python.

COBOL.

CICS.

Db2.

MQ.

IBM z17.

watsonx.

Tudo trabalhando junto.

Se isso não é evolução...

O que seria?


A herança para os próximos quarenta anos

Você, Padawan COBOL, talvez leia este artigo em 2036.

Ou 2046.

Quem sabe em 2056.

Talvez novas manchetes estejam dizendo:

"O fim da Inteligência Artificial."

"O fim do Cloud."

"O fim do Kubernetes."

"O fim dos LLMs."

"O fim dos Agentes."

Quando esse dia chegar...

Lembre-se deste julgamento.

Lembre-se de Forbes.

Lembre-se do New York Times.

Lembre-se da InfoWorld.

Lembre-se da Business Week.

Lembre-se do Professor Wolfgang Spruth.

E faça apenas uma pergunta.

Essa tecnologia ainda resolve problemas reais?

Se resolver...

Provavelmente continuará evoluindo.


A última xícara de café

Este não foi um artigo sobre computadores.

Nem sobre COBOL.

Nem sobre IBM.

Foi um artigo sobre humildade.

Humildade para reconhecer que prever o futuro é difícil.

Humildade para admitir erros.

Humildade para estudar a História antes de repetir slogans.

Humildade para entender que tecnologias realmente importantes raramente desaparecem de um dia para o outro.

Elas evoluem.

Adaptam-se.

Integram-se.

Transformam-se.

Foi isso que aconteceu com o Mainframe.

Foi isso que provavelmente acontecerá com muitas tecnologias atuais.


Encerramento

Quando você terminar este capítulo...

Olhe novamente para o IBM z17.

Não veja apenas um computador.

Veja sessenta anos de engenharia.

Milhões de horas de desenvolvimento.

Décadas de compatibilidade.

Bilhões de linhas de código.

Trilhões de dólares processados.

Milhões de profissionais que dedicaram suas carreiras para que o mundo continuasse funcionando.

Depois olhe para as manchetes da década de 1990.

Elas continuam importantes.

Porque nos lembram de algo extremamente valioso.

Buzzwords escrevem capas de revistas.

Engenharia escreve a História.

E a História, felizmente, costuma ter muito mais paciência do que os ciclos do marketing.


Epílogo Final

O Professor Wolfgang Spruth preservou o passado.

Os engenheiros construíram o presente.

Agora cabe aos novos Padawans construir o futuro.

Mas façam um favor à próxima geração.

Antes de anunciar a morte de qualquer tecnologia...

Esperem alguns anos.

A História agradece.

E o IBM Mainframe também.

Bellacosa Mainframe e o Funeral que nunca aconteceu

























C:\BELLACOSA\COBOL\FUNERAL_QUE_NUNCA_ACONTECEU.HTML
★ BELLACOSA MAINFRAME APRESENTA ★

A MORTE DO COBOL

O Funeral que Nunca Aconteceu

Uma investigação histórica em 14 capítulos sobre as previsões, reportagens, buzzwords e profetas que anunciaram repetidamente o fim do COBOL — enquanto bilhões de transações continuavam sendo processadas silenciosamente.

SISTEMA ONLINE — 14 CAPÍTULOS DISPONÍVEIS
DIRETÓRIO DE CAPÍTULOS

README.TXT

Esta série investiga uma das narrativas mais repetidas da história da tecnologia: a suposta morte do COBOL. Durante décadas, revistas, jornais, consultorias e especialistas anunciaram seu desaparecimento. Entretanto, o COBOL permaneceu processando bancos, seguradoras, governos, cartões, pagamentos e sistemas críticos.

Os títulos e links acima são elementos HTML reais, permitindo que mecanismos de busca encontrem e rastreiem todos os capítulos. Os iframes funcionam apenas como previews visuais.

C:\> RUN BELLACOSA.EXE /COBOL /HISTORY /NO-FUNERAL _

★ BELLACOSA MAINFRAME ★ COBOL ★ IBM Z ★ HISTÓRIA DA COMPUTAÇÃO ★

Melhor visualizado em qualquer navegador com café disponível.

segunda-feira, 13 de julho de 2026

Inteligência Não é o Resultado: Tokens, Contexto e a Nova Economia da IA Corporativa

 

Bellacosa Mainframe fala sobre tokens contexto e a ia

☕ Um Café no Bellacosa Mainframe

Inteligência Não é o Resultado: Tokens, Contexto e a Nova Economia da IA Corporativa

Imagine a cena.

É madrugada no datacenter. As luzes azuis dos corredores refletem nos gabinetes, os ventiladores trabalham em ritmo constante e, no centro da sala, um programador COBOL padawan observa um painel moderno repleto de gráficos sobre inteligência artificial.

No painel aparecem números impressionantes:

  • bilhões de parâmetros;

  • milhões de tokens processados;

  • GPUs operando em paralelo;

  • latência inferior a um segundo;

  • custo de inferência caindo mês após mês;

  • modelos cada vez maiores e mais rápidos.

O padawan sorri e pergunta ao mestre:

— Então vencemos? Nossa IA está pronta?

O mestre toma um gole de café, olha para o terminal e responde:

— Depende. O que ela fez pela empresa?

O jovem programador fica em silêncio.

A resposta resume um dos maiores desafios da inteligência artificial corporativa:

Inteligência não é o resultado. Inteligência é apenas um componente do caminho até o resultado.

Uma empresa não recebe dinheiro porque processou mais tokens. Não conquista clientes porque sua GPU executou inferências mais rapidamente. Não reduz perdas simplesmente porque instalou um modelo de linguagem com centenas de bilhões de parâmetros.

O valor aparece quando a inteligência é transformada em ação.

Quando uma fraude é bloqueada.

Quando uma transação é concluída.

Quando um cliente recebe a resposta correta.

Quando uma falha é evitada.

Quando uma operação é automatizada com segurança.

Quando uma decisão é tomada com base em dados confiáveis, contexto adequado e regras de negócio governadas.

É sobre essa transformação que vamos conversar neste café.


1. O grande engano da economia dos tokens

Nos primeiros anos da popularização da inteligência artificial generativa, grande parte da discussão se concentrou nos modelos.

As perguntas mais comuns eram:

  • Qual modelo possui mais parâmetros?

  • Qual gera textos melhores?

  • Qual responde mais rápido?

  • Qual possui a maior janela de contexto?

  • Quanto custa um milhão de tokens?

  • Quantas GPUs são necessárias?

  • Qual modelo venceu determinado benchmark?

Essas métricas são importantes. Entretanto, elas medem principalmente capacidade técnica.

Elas não demonstram, por si só, valor de negócio.

É parecido com avaliar um programa COBOL apenas pela quantidade de instruções executadas por segundo.

Imagine que um programa processa dez milhões de registros em dois minutos. Parece excelente. Porém, ao final, ele gera valores incorretos nas contas dos clientes.

Foi rápido?

Sim.

Foi eficiente?

Talvez.

Gerou valor?

Não.

Na realidade, criou um problema mais rapidamente.

O mesmo acontece com a IA.

Uma organização pode reduzir o custo de um milhão de tokens em 80%, aumentar o throughput e utilizar servidores mais poderosos. Contudo, se o sistema continuar produzindo respostas irrelevantes, decisões erradas ou tarefas incompletas, o benefício econômico é pequeno.

O erro está em confundir uma unidade de processamento com uma unidade de valor.

O token é uma unidade técnica.

O resultado é uma unidade de negócio.


2. O que é um token, afinal?

Para um programador COBOL acostumado com registros, campos, bytes e layouts, podemos comparar o token a uma pequena unidade usada pelo modelo para interpretar uma informação.

Uma palavra pode ser formada por um ou vários tokens.

Por exemplo, uma frase como:

O cliente solicitou o cancelamento do cartão.

é dividida internamente em partes menores. O modelo processa essas partes, identifica padrões e calcula quais tokens devem aparecer na resposta.

O custo de muitos serviços de IA é calculado com base na quantidade de tokens de entrada e saída.

Temos então:

Tokens de entrada:
pergunta, documentos, histórico, instruções.

Tokens de saída:
resposta gerada pelo modelo.

Em uma aplicação simples, isso funciona bem.

Entretanto, em uma empresa, o objetivo raramente é apenas gerar texto.

Considere esta solicitação:

Cliente:
Perdi meu cartão e há uma compra que não reconheço.

Um chatbot baseado apenas em texto pode responder:

Sinto muito pelo ocorrido.
Entre em contato com a central do banco para bloquear o cartão.

A resposta pode ser educada e tecnicamente correta.

Mas o problema continua existindo.

O cartão não foi bloqueado.

A transação não foi contestada.

O cliente ainda corre risco.

Nenhuma investigação foi aberta.

A IA gerou tokens, mas não gerou um resultado.


3. Da resposta para a ação

Uma aplicação corporativa madura precisa transformar a solicitação em uma sequência de operações.

Por exemplo:

1. Identificar o cliente.
2. Confirmar a autenticação.
3. Consultar os cartões ativos.
4. Verificar as últimas transações.
5. Bloquear o cartão comprometido.
6. Abrir uma contestação.
7. Solicitar um novo cartão.
8. Registrar a operação para auditoria.
9. Enviar confirmação ao cliente.

Agora não estamos mais falando apenas de um modelo.

Estamos falando de um sistema completo.

Esse sistema precisa conectar:

Modelo de IA
    +
Dados
    +
Aplicações
    +
APIs
    +
Segurança
    +
Governança
    +
Infraestrutura
    +
Operações

A inteligência artificial interpreta a intenção.

Os sistemas corporativos executam a ação.

Essa distinção é essencial.

O modelo pode compreender que o cliente deseja bloquear um cartão. Porém, quem realiza o bloqueio é uma aplicação transacional, talvez escrita em COBOL, executando em CICS e acessando dados no Db2.

O modelo não substitui necessariamente o sistema de negócio.

Ele passa a conversar com ele.


4. Tokens ficam baratos, contexto fica valioso

Uma das ideias mais importantes da nova economia da IA é a seguinte:

Tokens tendem a se tornar abundantes. Contexto confiável continuará sendo raro.

Os modelos estão ficando mais eficientes.

O custo da inferência tende a cair.

A capacidade computacional continua aumentando.

Modelos abertos e comerciais competem intensamente.

Consequentemente, o acesso à inteligência genérica tende a se tornar cada vez mais comum.

A pergunta estratégica deixa de ser:

Qual empresa possui acesso a um modelo de IA?

E passa a ser:

Qual empresa consegue fornecer ao modelo o contexto correto, no momento correto, com segurança e governança?

Vamos comparar duas situações.

Situação A: modelo sem contexto

Usuário:
O cliente João pode receber aumento de limite?

Resposta da IA:

Para avaliar um aumento de limite, considere renda,
histórico de pagamentos e nível de endividamento.

A resposta é genérica.

Pode ter sido escrita por qualquer modelo.

Situação B: modelo com contexto corporativo

Usuário:
O cliente João pode receber aumento de limite?

O sistema consulta:

CRM:
Cliente desde 2012.

Db2:
Nenhum atraso nos últimos 36 meses.

Sistema de crédito:
Score interno 892.

Sistema antifraude:
Nenhum alerta ativo.

Folha de pagamento:
Renda média aumentou 18%.

Política corporativa:
Aumento automático permitido até 20%.

Resposta:

O cliente está elegível para aumento de até 20%,
conforme a política de crédito vigente.

Motivos:
- relacionamento de 14 anos;
- ausência de atraso em 36 meses;
- score interno elevado;
- aumento comprovado de renda;
- nenhum alerta de fraude.

A recomendação exige confirmação do analista.

A diferença não está apenas no modelo.

Está no contexto.


5. O contexto proprietário como vantagem competitiva

Qualquer empresa pode contratar acesso a um modelo.

Porém, nenhuma concorrente possui exatamente:

  • seu histórico de clientes;

  • suas regras de negócio;

  • seus contratos;

  • seus dados operacionais;

  • seus registros de fraude;

  • seus manuais;

  • sua experiência acumulada;

  • seus sistemas legados;

  • seus fluxos de aprovação;

  • seu conhecimento institucional.

Esse conjunto forma o chamado contexto proprietário.

No mundo mainframe, uma parcela significativa desse contexto pode estar armazenada em:

  • tabelas Db2;

  • bancos IMS;

  • arquivos VSAM;

  • filas MQ;

  • transações CICS;

  • programas COBOL;

  • copybooks;

  • logs SMF;

  • datasets sequenciais;

  • catálogos;

  • regras codificadas durante décadas.

Eis um detalhe que muitos projetos modernos ignoram:

O mainframe não armazena apenas dados antigos. Ele contém contexto operacional acumulado.

Um programa COBOL de quarenta anos pode representar regras de negócio que nunca foram formalmente documentadas em outro lugar.

Por exemplo:

IF CLIENTE-SEGMENTO = 'P'
   AND DIAS-ATRASO = ZERO
   AND SCORE-CREDITO > 850
   AND VALOR-SOLICITADO <= LIMITE-AUTOMATICO
       MOVE 'APROVADO' TO STATUS-PROPOSTA
ELSE
       MOVE 'ANALISE' TO STATUS-PROPOSTA
END-IF.

Esse trecho não é apenas código.

Ele é conhecimento empresarial executável.

É uma política.

É contexto.

É parte da inteligência corporativa.


6. O perigo de construir agentes sobre dados desorganizados

Muitas empresas estão correndo para implementar agentes de IA.

O problema é que um agente pode automatizar decisões e executar tarefas. Portanto, um erro cometido por ele pode se espalhar muito mais rapidamente do que um erro em um chatbot tradicional.

Um chatbot errado gera uma resposta ruim.

Um agente errado pode:

  • cancelar um pedido;

  • bloquear um cliente;

  • aprovar um pagamento;

  • alterar um cadastro;

  • abrir milhares de chamados;

  • executar uma rotina indevida;

  • enviar informações confidenciais;

  • interromper um processo produtivo.

Observe esta arquitetura problemática:

Agente de IA
    |
    +--> CRM desatualizado
    |
    +--> planilha manual
    |
    +--> base duplicada
    |
    +--> documentação antiga
    |
    +--> API sem controle

O agente pode ser sofisticado.

O modelo pode ser excelente.

A infraestrutura pode ser poderosa.

Mesmo assim, o resultado será frágil.

No mundo COBOL, aprendemos há décadas a regra:

Garbage In, Garbage Out

Entrada ruim produz saída ruim.

Na era dos agentes, podemos acrescentar:

Garbage In, Automated Disaster Out

Entrada ruim pode produzir desastre automatizado.

É um pouco dramático, mas é verdade.


7. O custo por token não é o custo por tarefa concluída

Aqui aparece uma armadilha financeira importante.

Uma empresa pode celebrar a redução do custo por token, enquanto o custo real de completar uma tarefa continua aumentando.

Imagine um agente responsável por resolver chamados.

Modelo antigo:

Custo por milhão de tokens: US$ 10
Tokens por tarefa: 10.000
Taxa de sucesso: 80%

Modelo novo:

Custo por milhão de tokens: US$ 2
Tokens por tarefa: 40.000
Taxa de sucesso: 45%

O novo modelo parece mais barato por token.

Entretanto, ele usa quatro vezes mais tokens e falha com maior frequência.

Precisamos calcular o custo da tarefa concluída.

Exemplo simplificado

Modelo antigo:

10.000 tokens por tentativa
US$ 10 por 1.000.000 de tokens

Custo por tentativa:
10.000 / 1.000.000 x 10 = US$ 0,10

Com 80% de sucesso:

Custo aproximado por tarefa concluída:
0,10 / 0,80 = US$ 0,125

Modelo novo:

40.000 tokens por tentativa
US$ 2 por 1.000.000 de tokens

Custo por tentativa:
40.000 / 1.000.000 x 2 = US$ 0,08

Com 45% de sucesso:

Custo aproximado por tarefa concluída:
0,08 / 0,45 = US$ 0,177

O token ficou mais barato.

A tarefa ficou mais cara.

E ainda nem consideramos:

  • retrabalho;

  • intervenção humana;

  • erros operacionais;

  • consumo de APIs;

  • processamento de banco de dados;

  • armazenamento;

  • auditoria;

  • observabilidade;

  • impacto de decisões incorretas.

Esse é um dos grandes ensinamentos:

O indicador correto não é somente custo por token. É custo por resultado confiável.


8. A jornada em três fases

A imagem apresenta uma evolução poderosa:

Tokens → Contexto → Outcomes

Vamos aprofundar cada estágio.

Fase 1 — Tokens

É a fase da inteligência genérica.

A empresa mede:

  • preço;

  • velocidade;

  • capacidade;

  • latência;

  • tamanho do modelo;

  • consumo de GPU.

O objetivo é gerar uma boa resposta.

Fase 2 — Contexto

A empresa conecta o modelo aos seus dados.

Entram em cena:

  • RAG;

  • bancos vetoriais;

  • catálogos;

  • metadados;

  • APIs;

  • documentos;

  • sistemas transacionais;

  • dados históricos;

  • regras corporativas.

O objetivo é gerar uma resposta relevante para a organização.

Fase 3 — Resultado confiável

A empresa transforma a resposta em ação controlada.

Entram em cena:

  • agentes;

  • automação;

  • workflows;

  • aprovações;

  • autenticação;

  • autorização;

  • observabilidade;

  • auditoria;

  • rollback;

  • compliance.

O objetivo é gerar uma ação mensurável, segura e repetível.


9. RAG: dando memória ao modelo

Um dos mecanismos mais comuns para fornecer contexto a um modelo é o RAG, sigla para Retrieval-Augmented Generation.

Em português, algo como geração aumentada por recuperação de informação.

O fluxo básico é:

Pergunta
   |
   v
Busca de documentos relevantes
   |
   v
Documentos adicionados ao prompt
   |
   v
Modelo gera resposta baseada no contexto

Vamos imaginar um assistente para suporte COBOL.

Pergunta:

Como resolver o ABEND S0C7 do programa PAGT001?

Sem RAG, o modelo responde genericamente:

S0C7 normalmente indica dados inválidos em uma operação numérica.

Com RAG, o sistema consulta:

  • manual interno;

  • dump do programa;

  • copybook;

  • histórico de incidentes;

  • documentação do batch;

  • versão do módulo.

O contexto recuperado informa:

O campo WS-VALOR-ENTRADA é lido da posição 81,
mas o arquivo recebido possui caracteres em branco.

A resposta passa a ser:

No programa PAGT001, o S0C7 ocorre porque o campo
WS-VALOR-ENTRADA recebe espaços do registro de entrada.

Antes da conversão, valide o conteúdo:

IF CAMPO-ENTRADA NUMERIC
    MOVE CAMPO-ENTRADA TO WS-VALOR
ELSE
    MOVE ZERO TO WS-VALOR
END-IF.

Agora a resposta possui contexto real.


10. Do RAG ao agente

RAG responde.

Agente executa.

Considere este pedido:

Reprocesse o job de faturamento que falhou.

Um agente corporativo poderia seguir este fluxo:

1. Localizar o job no JES2.
2. Consultar o retorno no SDSF.
3. Identificar o step com falha.
4. Ler mensagens do sistema.
5. Correlacionar com incidentes anteriores.
6. Validar se o reprocessamento é permitido.
7. Solicitar aprovação, quando necessário.
8. Reexecutar o job.
9. Monitorar o novo processamento.
10. Registrar tudo na auditoria.

Perceba a diferença.

O agente não pode simplesmente encontrar um exemplo de JCL e submetê-lo.

Ele precisa respeitar:

  • autorização RACF;

  • regras operacionais;

  • janela batch;

  • dependências;

  • datasets;

  • estado do processamento;

  • políticas de reexecução;

  • impacto financeiro;

  • aprovação humana.

É aí que governança e segurança deixam de ser acessórios.

Elas tornam-se componentes centrais.


11. Segurança: o agente não pode ser um superusuário irresponsável

Um agente precisa operar segundo o princípio do menor privilégio.

Em ambientes z/OS, isso significa respeitar controles como:

  • RACF;

  • SAF;

  • perfis de dataset;

  • classes de recurso;

  • autorização de comandos;

  • acesso a transações;

  • controle de APIs;

  • trilhas SMF;

  • segregação de funções.

Imagine um agente que pode:

  • submeter qualquer job;

  • ler qualquer dataset;

  • alterar tabelas;

  • cancelar transações;

  • acessar dados pessoais.

Mesmo que a intenção seja legítima, esse desenho cria um risco gigantesco.

O correto é limitar o agente.

Exemplo:

Agente de suporte batch:

Pode:
- consultar spool;
- ler mensagens;
- comparar incidentes;
- sugerir correções;
- reexecutar jobs pré-autorizados.

Não pode:
- alterar loadlibs de produção;
- modificar datasets críticos;
- submeter JCL fora da whitelist;
- acessar dados de clientes;
- ignorar aprovações.

Uma boa arquitetura trata o agente como qualquer identidade corporativa.

Ele possui:

  • credencial;

  • função;

  • escopo;

  • permissões;

  • responsabilidade;

  • trilha de auditoria.


12. Governança: quem decidiu, por quê e com quais dados?

Em ambientes regulados, não basta uma decisão estar correta.

Ela precisa ser explicável.

Considere um agente de crédito.

Ele nega uma proposta.

A empresa precisa responder:

  • Qual modelo foi utilizado?

  • Qual versão?

  • Quais dados foram consultados?

  • Qual política estava vigente?

  • Houve intervenção humana?

  • A decisão pode ser reproduzida?

  • Existia viés?

  • Os dados estavam atualizados?

  • O cliente pode contestar?

Sem essas respostas, a automação se torna uma caixa-preta perigosa.

Uma trilha de auditoria pode registrar:

Data/Hora: 2026-07-14 14:35:12
Agente: AGT-CREDITO-01
Modelo: MODELO-CREDITO-V3
Política: POL-CRED-2026-04
Cliente: ID anonimizado 984521
Dados consultados:
- score interno;
- renda declarada;
- histórico de pagamento;
- alertas de fraude.

Decisão:
Encaminhado para análise humana.

Motivo:
Divergência entre renda declarada e histórico de movimentação.

Esse registro transforma uma ação de IA em uma ação corporativamente defensável.


13. O papel da infraestrutura

A imagem apresenta uma fundação composta por tecnologias como LinuxONE, OpenShift, IBM Fusion, Storage Scale, Ceph e watsonx.

A mensagem não é que uma única tecnologia resolve tudo.

A mensagem é que IA corporativa exige uma base coordenada.

Vamos interpretar cada camada.

LinuxONE

LinuxONE representa uma plataforma voltada a cargas Linux empresariais com forte ênfase em:

  • escalabilidade;

  • consolidação;

  • segurança;

  • disponibilidade;

  • eficiência operacional.

Ele pode hospedar aplicações, APIs, bancos de dados, containers e serviços de IA próximos dos sistemas corporativos.

Red Hat OpenShift

OpenShift atua como camada de orquestração de containers.

Ele permite executar:

  • microsserviços;

  • APIs;

  • pipelines;

  • modelos;

  • aplicações;

  • agentes;

  • componentes de integração.

Para o padawan COBOL, podemos compará-lo a uma grande plataforma que administra milhares de aplicações empacotadas em containers, distribuindo recursos, reiniciando componentes e aplicando políticas.

IBM Fusion

IBM Fusion aparece como uma fundação para dados e operações.

Em uma arquitetura de IA, armazenamento não significa apenas “guardar arquivos”.

É necessário:

  • disponibilizar dados;

  • proteger dados;

  • mover dados;

  • criar cópias;

  • restaurar ambientes;

  • aplicar políticas;

  • manter consistência;

  • fornecer desempenho.

Storage Scale

Storage Scale é associado ao acesso paralelo e distribuído a grandes volumes de informação.

Em cargas de IA, muitos processos podem precisar acessar enormes conjuntos de dados simultaneamente.

Um armazenamento lento transforma GPUs caras em máquinas esperando dados.

É o velho problema de I/O.

O programador COBOL conhece isso bem.

Não adianta possuir CPU rápida se o programa passa o tempo inteiro aguardando leitura.

Ceph

Ceph fornece armazenamento distribuído em diferentes formatos:

  • objeto;

  • bloco;

  • arquivo.

É bastante útil em ambientes de nuvem e containers, especialmente quando aplicações precisam de armazenamento resiliente e escalável.

watsonx

O watsonx representa a camada de IA, dados e governança.

De forma conceitual:

watsonx.ai
Modelos, desenvolvimento e inferência.

watsonx.data
Dados preparados para análise e IA.

watsonx.governance
Controle, risco, transparência e auditoria.

O ponto central é importante:

A IA empresarial não é apenas o modelo. Ela depende de dados e governança na mesma proporção.


14. O mainframe como servidor de contexto

Muitos projetos cometem um erro cultural: tratam o mainframe como um sistema antigo que precisa ser contornado.

Entretanto, nas grandes empresas, o mainframe frequentemente contém o contexto mais confiável.

É nele que estão:

  • o saldo verdadeiro;

  • o estoque verdadeiro;

  • o contrato vigente;

  • o pagamento confirmado;

  • a apólice ativa;

  • o cadastro oficial;

  • a transação contabilizada.

Uma IA pode ler milhares de documentos, mas a resposta definitiva pode depender de uma única consulta ao Db2.

Exemplo:

SELECT STATUS_CONTA,
       SALDO_DISPONIVEL,
       LIMITE_CREDITO
  FROM CONTAS
 WHERE NUMERO_CONTA = :WS-CONTA;

Essa consulta retorna o estado operacional real.

O documento explica a política.

O sistema transacional informa a verdade atual.

A combinação dos dois produz contexto confiável.


15. Exemplo completo: agente de atendimento bancário

Vamos montar uma arquitetura passo a passo.

Solicitação

Cliente:
Quero contestar a compra de R$ 2.500 realizada ontem.

Etapa 1 — Interpretação

O modelo identifica:

Intenção:
Contestar transação.

Entidades:
Valor: R$ 2.500.
Período: ontem.

Etapa 2 — Autenticação

Antes de consultar informações, o sistema confirma a identidade do cliente.

MFA validado.
Sessão autenticada.
Token de acesso emitido.

Etapa 3 — Consulta de transações

Uma API chama o sistema transacional.

OpenShift
   |
   v
API corporativa
   |
   v
z/OS Connect
   |
   v
CICS
   |
   v
Programa COBOL
   |
   v
Db2

O COBOL recebe os dados:

01 REQUEST-DATA.
   05 REQ-CONTA          PIC X(12).
   05 REQ-DATA-INICIAL   PIC X(10).
   05 REQ-VALOR          PIC 9(7)V99.

01 RESPONSE-DATA.
   05 RESP-CODIGO        PIC X(04).
   05 RESP-DESCRICAO     PIC X(100).
   05 RESP-ID-TRANSACAO  PIC X(20).

Etapa 4 — Aplicação das regras

A política determina:

Compras acima de R$ 2.000 exigem análise adicional.

O agente não pode simplesmente devolver o dinheiro.

Ele precisa:

- bloquear temporariamente a transação;
- gerar protocolo;
- abrir análise antifraude;
- avisar o cliente;
- registrar a decisão.

Etapa 5 — Auditoria

Tudo é registrado.

Quem solicitou.
Qual agente atuou.
Quais dados foram consultados.
Qual regra foi aplicada.
Qual ação foi executada.

Etapa 6 — Resultado

Resposta final:

A transação de R$ 2.500 foi localizada.

Foi aberto o protocolo 845219.
O valor está em análise.
O cartão permanece ativo, mas novas transações suspeitas
serão monitoradas.

Prazo estimado: até 5 dias úteis.

Agora existe um resultado real.

Não apenas uma resposta elegante.


16. TTO: Time to Outcome

A sigla TTO significa Time to Outcome, ou tempo até o resultado.

Durante muitos anos, a tecnologia falou sobre:

  • Time to Market;

  • Time to Value;

  • tempo de resposta;

  • tempo de processamento;

  • SLA.

O TTO mede quanto tempo uma organização leva para transformar uma necessidade em um resultado concluído.

Considere um incidente batch.

Processo tradicional

08:00 — job falha.
08:20 — operador identifica.
08:45 — chamado é aberto.
09:30 — equipe analisa.
10:15 — causa é descoberta.
11:00 — correção é aprovada.
11:30 — job é reexecutado.
12:00 — processamento termina.

TTO:

4 horas.

Processo assistido por IA

08:00 — job falha.
08:01 — agente lê mensagens.
08:02 — correlaciona com incidente anterior.
08:03 — valida pré-requisitos.
08:04 — solicita aprovação.
08:07 — operador aprova.
08:08 — agente reexecuta.
08:30 — processamento termina.

TTO:

30 minutos.

A IA não criou valor porque leu o spool rapidamente.

Criou valor porque reduziu o tempo até a recuperação.


17. Métricas melhores para IA corporativa

Além do custo por token, uma organização deveria acompanhar:

Taxa de conclusão

Quantas tarefas foram realmente concluídas?

Tarefas iniciadas: 1.000
Tarefas concluídas: 760
Taxa de conclusão: 76%

Taxa de intervenção humana

Quantas tarefas exigiram correção?

Tarefas concluídas: 760
Intervenções humanas: 180
Taxa: 23,7%

Custo por resultado

Inclui:

  • tokens;

  • infraestrutura;

  • APIs;

  • processamento;

  • armazenamento;

  • retrabalho;

  • supervisão humana.

Tempo até o resultado

Quanto tempo o processo completo levou?

Taxa de erro operacional

Quantas ações precisaram ser revertidas?

Conformidade

Quantas ações possuíam:

  • autorização;

  • justificativa;

  • trilha;

  • evidência;

  • política associada?

Essas métricas aproximam IA de operação real.


18. Um exemplo COBOL: preparando contexto para uma API

Imagine um programa COBOL que consulta dados de um cliente para um agente.

       IDENTIFICATION DIVISION.
       PROGRAM-ID. CLIENTE-CONTEXTO.

       DATA DIVISION.
       WORKING-STORAGE SECTION.

       01 WS-CLIENTE-ID        PIC 9(10).
       01 WS-NOME              PIC X(40).
       01 WS-SEGMENTO          PIC X(10).
       01 WS-SCORE             PIC 9(03).
       01 WS-DIAS-ATRASO       PIC 9(03).
       01 WS-STATUS            PIC X(10).

       01 WS-CONTEXTO.
          05 FILLER            PIC X(12) VALUE
             '"cliente":"'.
          05 WS-JSON-NOME      PIC X(40).
          05 FILLER            PIC X(14) VALUE
             '","segmento":"'.
          05 WS-JSON-SEGMENTO  PIC X(10).
          05 FILLER            PIC X(10) VALUE
             '","score":'.
          05 WS-JSON-SCORE     PIC 9(03).
          05 FILLER            PIC X(01) VALUE '}'.

       PROCEDURE DIVISION.

           MOVE 1234567890 TO WS-CLIENTE-ID

           EXEC SQL
               SELECT NOME,
                      SEGMENTO,
                      SCORE,
                      DIAS_ATRASO,
                      STATUS
                 INTO :WS-NOME,
                      :WS-SEGMENTO,
                      :WS-SCORE,
                      :WS-DIAS-ATRASO,
                      :WS-STATUS
                 FROM CLIENTES
                WHERE CLIENTE_ID = :WS-CLIENTE-ID
           END-EXEC

           IF SQLCODE = 0
               MOVE WS-NOME     TO WS-JSON-NOME
               MOVE WS-SEGMENTO TO WS-JSON-SEGMENTO
               MOVE WS-SCORE    TO WS-JSON-SCORE
               DISPLAY WS-CONTEXTO
           ELSE
               DISPLAY 'ERRO SQLCODE: ' SQLCODE
           END-IF

           GOBACK.

O objetivo do exemplo não é apresentar um gerador JSON perfeito, mas mostrar a ideia.

O programa:

  1. recebe o identificador do cliente;

  2. consulta dados no Db2;

  3. organiza as informações;

  4. disponibiliza o contexto para outro componente.

O LLM não precisa conhecer a estrutura interna do banco.

Uma API intermediária pode transformar os dados em um contrato bem definido.

Exemplo:

{
  "cliente": "Maria Silva",
  "segmento": "Platinum",
  "score": 920,
  "diasAtraso": 0,
  "status": "Ativo"
}

Esse JSON se torna contexto para a decisão.


19. Easter egg: o mainframe já fazia “agentes” antes da moda

Existe uma curiosidade divertida.

Muito antes dos atuais agentes de IA, o mainframe já executava cadeias automáticas de decisões.

JCL, schedulers, CICS, IMS, MQ e automação operacional já permitiam:

  • detectar eventos;

  • disparar jobs;

  • avaliar códigos de retorno;

  • chamar programas;

  • executar contingências;

  • registrar resultados.

Considere este exemplo simplificado:

//STEP01 EXEC PGM=VALIDA
//STEP02 EXEC PGM=PROCESSA,COND=(0,NE,STEP01)
//STEP03 EXEC PGM=NOTIFICA,COND=(0,NE,STEP02)

A lógica diz:

Valide.
Se estiver tudo certo, processe.
Se o processamento terminar corretamente, notifique.

Isso é uma forma primitiva de orquestração orientada a resultados.

A diferença moderna é que a IA pode interpretar linguagem, analisar informações não estruturadas e escolher ferramentas dinamicamente.

Mas o princípio de automação controlada não nasceu ontem.

O mainframe já ensinava isso quando muitos dos atuais especialistas em IA ainda brincavam com disquetes.


20. Faster complexity: complexidade mais rápida

Uma frase poderosa do texto é:

Isso não é transformação. É complexidade mais rápida.

Automatizar um processo ruim não o transforma automaticamente em um processo bom.

Imagine um fluxo com:

  • cinco planilhas;

  • três aprovações redundantes;

  • dados duplicados;

  • políticas conflitantes;

  • sistemas sem integração.

Adicionar IA pode acelerar o fluxo.

Mas também pode acelerar:

  • inconsistências;

  • erros;

  • retrabalho;

  • decisões conflitantes;

  • consumo de recursos;

  • dívida operacional.

Antes de automatizar, a empresa deveria perguntar:

Este processo ainda faz sentido?
Os dados são confiáveis?
As regras estão documentadas?
As responsabilidades estão claras?
A decisão pode ser auditada?
Existe mecanismo de reversão?

A IA não elimina arquitetura.

Ela aumenta a importância da arquitetura.


21. Um roteiro prático para o programador COBOL padawan

Como começar essa jornada?

Passo 1 — Identifique um resultado

Não comece com:

Vamos usar IA.

Comece com:

Queremos reduzir o tempo de análise de um ABEND de 90 para 15 minutos.

Passo 2 — Localize o contexto

Pergunte:

Onde estão os dados necessários?

Talvez em:

  • spool;

  • Db2;

  • SMF;

  • documentação;

  • Git;

  • tickets;

  • datasets;

  • copybooks.

Passo 3 — Defina as fontes confiáveis

Nem toda informação possui o mesmo peso.

Fonte oficial:
Db2 de produção.

Fonte complementar:
manual interno.

Fonte histórica:
tickets anteriores.

Fonte não confiável:
planilha local sem atualização.

Passo 4 — Crie uma camada de integração

Evite permitir acesso direto e irrestrito ao sistema.

Use:

  • APIs;

  • z/OS Connect;

  • MQ;

  • serviços CICS;

  • stored procedures;

  • camadas de autorização.

Passo 5 — Aplique governança

Registre:

  • modelo;

  • versão;

  • fonte;

  • decisão;

  • ação;

  • usuário;

  • horário;

  • resultado.

Passo 6 — Comece com aprovação humana

Antes de permitir ação autônoma:

IA sugere.
Humano aprova.
Sistema executa.

Depois, tarefas simples e de baixo risco podem ganhar maior autonomia.

Passo 7 — Meça o resultado

Acompanhe:

  • tempo economizado;

  • taxa de sucesso;

  • retrabalho;

  • custo por tarefa;

  • falhas;

  • impacto operacional.


22. Conclusão: a verdadeira corrida da IA

A corrida da inteligência artificial está mudando.

Na primeira fase, todos buscavam modelos maiores.

Na segunda, perceberam que o modelo sem contexto possui valor limitado.

Na terceira, as empresas vencedoras aprenderão a transformar contexto em ação confiável.

A fórmula é simples de escrever:

Compute
   +
Data
   +
Storage
   +
Context
   +
Applications
   +
Security
   +
Governance
   +
Operations
   =
Trusted Outcomes

Mas implementá-la exige engenharia.

Exige integração entre o novo e o legado.

Exige APIs, segurança, arquitetura, armazenamento, observabilidade e governança.

Exige reconhecer que o COBOL, o CICS, o IMS, o Db2 e o IBM Z não são obstáculos à inteligência artificial.

Eles podem ser a fonte do contexto mais valioso da organização.

Os tokens ficarão mais baratos.

Os modelos serão cada vez mais acessíveis.

A capacidade computacional continuará crescendo.

Contudo, o contexto confiável continuará raro.

E o resultado governado será ainda mais valioso.

No final, a pergunta correta não será:

Quantos tokens sua empresa processou?

Será:

Quantos problemas reais ela resolveu, com segurança, velocidade, rastreabilidade e confiança?

O mestre termina o café, olha novamente para o jovem programador e conclui:

— Padawan, o modelo pode conhecer milhares de respostas. Mas somente o sistema completo consegue entregar o resultado.

E, no fundo do datacenter, enquanto o IBM Z continua processando milhões de transações, uma antiga verdade da computação reaparece com nova roupa:

Tecnologia não vale pelo que promete. Vale pelo que consegue concluir.