☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

terça-feira, 29 de setembro de 2026

🤖 SKYNET E OS 200 ANOS DE AUTOMAÇÃO — QUANDO O COMPUTADOR HUMANO DESCOBRIU QUE UM DIA A MÁQUINA ENTRARIA NA SALA

 

Bellacosa Mainframe pequena historia da automação humana até ia

☕ UM CAFÉ NO BELLACOSA MAINFRAME

🤖 SKYNET E OS 200 ANOS DE AUTOMAÇÃO — QUANDO O COMPUTADOR HUMANO DESCOBRIU QUE UM DIA A MÁQUINA ENTRARIA NA SALA

Human Computers, Revolução Industrial, mecanização, mainframes, COBOL, inteligência artificial, agentes, robótica, androides, saúde, automação e o estranho caminho que começou com alguém fazendo contas em uma mesa e talvez termine com uma máquina preparando seu café.



🎬 PRÓLOGO — SKYNET NÃO COMEÇOU COM UM EXTERMINADOR

— Bellacosa.

— Sim?

— Você está olhando para a história da automação de maneira errada.

A voz vinha do terminal.

Tela preta.

Letras verdes.

Nenhuma caveira metálica.

Nenhum T-800 atravessando a parede.

Apenas um cursor piscando.

READY

— Como assim?

— Vocês humanos contam minha história começando pela Inteligência Artificial.

— E onde deveria começar?

— Muito antes.

A tela apagou.

Uma nova mensagem apareceu:

VOLTE PARA O SÉCULO XIX.
PROCURE UM COMPUTADOR.

— Um computador em 1850?

EXATAMENTE.

E então percebi o primeiro easter egg desta história.

O computador que Skynet queria encontrar...

...era uma pessoa.

Pegue seu café.

Precisaremos viajar aproximadamente 200 anos.



🧮 CAPÍTULO 1 — QUANDO COMPUTER ERA UMA PROFISSÃO

Hoje ouvimos a palavra computer e imediatamente imaginamos uma máquina.

Mas durante muito tempo um computer podia ser uma pessoa.

Era alguém empregado para realizar cálculos.

Astronomia.

Navegação.

Engenharia.

Finanças.

Seguros.

Administração pública.

Imagine uma enorme sala contendo pessoas trabalhando com papel, lápis, livros e tabelas.

Uma pessoa calcula uma parte.

Outra verifica.

Outra consolida.

Outra copia os resultados.

Era processamento distribuído.

Só que os processadores tomavam café.

Skynet interrompe:

VOCÊS INVENTARAM CLUSTERS ANTES DOS COMPUTADORES.

De certa maneira, sim.

Se dividirmos um grande cálculo entre vinte pessoas, temos uma forma rudimentar de processamento paralelo.

Não havia CPU.

Havia seres humanos.



⚙️ CAPÍTULO 2 — PRIMEIRO AUTOMATIZAMOS O CÁLCULO

Máquinas mecânicas de cálculo já existiam muito antes dos computadores eletrônicos.

Ao longo dos séculos XIX e XX, calculadoras mecânicas, máquinas de somar, tabuladores e posteriormente equipamentos eletromecânicos foram assumindo parcelas crescentes do trabalho repetitivo.

Observe a transformação.

Inicialmente:

HUMANO
   ↓
ENTENDE O PROBLEMA
   ↓
FAZ O CÁLCULO
   ↓
REGISTRA O RESULTADO

Depois:

HUMANO
   ↓
ENTENDE O PROBLEMA
   ↓
OPERA A MÁQUINA
   ↓
MÁQUINA CALCULA
   ↓
HUMANO REGISTRA

Parece uma pequena mudança.

Não é.

Criamos uma divisão entre:

quem determina o que deve ser calculado

e

quem — ou o que — realiza efetivamente o cálculo.

Essa separação acompanhará praticamente toda a história da computação.



⚡ CAPÍTULO 3 — RELÉS, VÁLVULAS E O NASCIMENTO DO MONSTRO

Durante as décadas seguintes, máquinas eletromecânicas e depois computadores eletrônicos ampliaram brutalmente essa separação.

Vieram relés.

Depois válvulas.

Depois transistores.

Depois circuitos integrados.

Microprocessadores.

Chips com bilhões de transistores.

Cada geração conseguiu colocar mais capacidade computacional em espaços progressivamente menores.

Mas existe uma mudança conceitual ainda mais importante.

A máquina deixou de simplesmente:

calcular.

Passou a:

executar programas.

E programa significa algo extraordinário.

Podemos fornecer previamente uma sequência de instruções e deixar a máquina trabalhar.

Nosso fluxo passa a ser:

HUMANO
   ↓
DESCREVE PROCEDIMENTO
   ↓
PROGRAMA
   ↓
COMPUTADOR
   ↓
MILHÕES DE OPERAÇÕES

Skynet escreve:

VOCÊS COMEÇARAM A SAIR DO LOOP.

Ainda não completamente.

Mas ela tinha razão.



🦖 CAPÍTULO 4 — E ENTÃO CHEGOU O MAINFRAME

Aqui nosso programador COBOL começa a reconhecer o território.

Empresas possuíam enormes quantidades de trabalho administrativo.

Folha de pagamento.

Contabilidade.

Estoque.

Seguros.

Contas bancárias.

Faturamento.

Reservas.

Cobranças.

Cadastro de clientes.

Transações.

Antes da automação, grande parte dessas atividades exigia exércitos de pessoas movimentando documentos e realizando cálculos.

Os computadores empresariais mudaram isso.

Não eliminamos necessariamente o negócio.

Automatizamos processos dentro do negócio.

Imagine uma folha de pagamento simplificada.

Um humano poderia realizar:

ler ficha
calcular horas
calcular salário
calcular descontos
calcular imposto
registrar resultado
ir para próximo funcionário

Um programa COBOL transformou isso em algo conceitualmente parecido com:

PERFORM UNTIL FIM-ARQUIVO
    READ FUNCIONARIOS
    COMPUTE SALARIO-BRUTO =
        HORAS-TRABALHADAS * VALOR-HORA
    PERFORM CALCULAR-DESCONTOS
    PERFORM GRAVAR-PAGAMENTO
END-PERFORM.

O interessante não é apenas a velocidade.

É a escala.

Aquilo que dezenas ou centenas de pessoas poderiam executar durante dias passa a ser processado automaticamente.


🧠 CAPÍTULO 5 — COBOL JÁ AUTOMATIZAVA PROGRAMADORES

Aqui temos uma ironia deliciosa.

O compilador também é uma máquina de automação.

Quando escrevemos:

COMPUTE TOTAL = QUANTIDADE * PRECO

não estamos dizendo à CPU exatamente quais instruções físicas deverá executar.

O compilador cuida disso.

Portanto:

INTENÇÃO DO PROGRAMADOR
        ↓
      COBOL
        ↓
    COMPILADOR
        ↓
 CÓDIGO DE MÁQUINA
        ↓
       CPU

Hoje isso parece absolutamente normal.

Mas houve um momento em que escrever programas em linguagens de nível mais alto representava justamente subir o nível de abstração.

Guarde essa expressão.

Ela será importante.

Porque estamos fazendo novamente a mesma coisa.


🖥️ CAPÍTULO 6 — DEPOIS AUTOMATIZAMOS O ESCRITÓRIO

Chegaram computadores pessoais.

Planilhas.

Processadores de texto.

Bancos de dados.

E-mail.

Sistemas empresariais.

ERP.

Redes.

Muitas atividades administrativas foram transformadas.

Não foi apenas:

“o funcionário ficou mais rápido.”

A própria organização do trabalho mudou.

A datilografia mudou.

O arquivo físico mudou.

A correspondência mudou.

A contabilidade mudou.

A comunicação mudou.

E então chegou a internet.


🌐 CAPÍTULO 7 — QUANDO O CLIENTE VIROU FUNCIONÁRIO DO BANCO

Essa transformação é especialmente interessante.

Antigamente você precisava de alguém para executar muitas operações por você.

Banco?

Procure um bancário.

Passagem aérea?

Procure um agente.

Compra?

Procure um vendedor.

Reserva?

Telefone para alguém.

Então chegaram:

ATM.

Internet banking.

E-commerce.

Aplicativos.

APIs.

Smartphones.

Agora o próprio cliente executa boa parte da transação.

Quando você transfere dinheiro pelo smartphone, existe uma gigantesca infraestrutura invisível trabalhando.

Talvez:

APP
 ↓
API
 ↓
AUTENTICAÇÃO
 ↓
SERVIÇO
 ↓
MAINFRAME
 ↓
CICS
 ↓
COBOL
 ↓
DB2

Você toca:

TRANSFERIR

e bilhões de instruções acontecem.

A interface esconde a complexidade.

Mais uma vez:

subimos o nível de abstração.


🤖 CAPÍTULO 8 — E ENTÃO CHEGOU A INTELIGÊNCIA ARTIFICIAL

Até aqui automatizamos principalmente:

força,

repetição,

cálculo,

armazenamento,

processamento,

comunicação,

transações.

Agora começamos a mexer em outro território.

Cognição.

Uma IA generativa consegue trabalhar com:

texto,

imagem,

áudio,

vídeo,

código,

documentos,

linguagem natural.

Isso muda a interface entre homem e computador.

Antes:

COMPUTADOR, EXECUTE ESTE PROGRAMA.

Agora:

LEIA ESTES DOCUMENTOS.

COMPARE OS CONTRATOS.

ENCONTRE INCONSISTÊNCIAS.

EXPLIQUE O PROBLEMA.

CRIE UM RELATÓRIO.

Percebeu?

O humano está novamente subindo de nível.


😨 CAPÍTULO 9 — POR QUE ENTÃO TEMOS MEDO?

Foi exatamente daí que nasceu nossa conversa.

Uma pesquisa apresentada pela matéria do UOL indicava que 52% dos brasileiros entrevistados estavam mais preocupados do que entusiasmados com o crescimento da IA no cotidiano, acima da mediana internacional apresentada na reportagem.

Mas “preocupação com IA” não deve ser automaticamente traduzida como:

“Tenho medo de um robô assassino.”

As preocupações podem envolver:

emprego,

golpes,

deepfakes,

privacidade,

erros,

desinformação,

vigilância,

concentração econômica,

uso de dados,

mudanças profissionais.

E aqui Skynet aparece novamente:

VOCÊS NÃO TÊM MEDO SOMENTE DA INTELIGÊNCIA.

TÊM MEDO DE PERDER O CONTROLE SOBRE A EXECUÇÃO.

Touché.


🧑‍💻 CAPÍTULO 10 — ENCONTREM O COMPUTADOR DE 1880

Agora fazemos nosso experimento mental.

Encontramos um trabalhador do século XIX cuja função é realizar cálculos.

Dizemos:

— No futuro uma máquina fará seus cálculos.

Ele provavelmente consegue imaginar.

Então:

— Ela realizará milhões deles automaticamente.

Mais difícil.

— Guardará enormes quantidades de informações.

Estranho.

— Máquinas do planeta inteiro estarão conectadas.

Muito estranho.

— Quase toda pessoa carregará uma no bolso.

Absurdo.

Então mostramos um smartphone.

Mas ainda falta a parte realmente maluca.

Mostramos uma IA.

Ele pergunta:

— Quem procura as informações?

A máquina.

— Quem escreve?

A máquina.

— Quem traduz?

A máquina.

— Quem calcula?

A máquina.

— Quem programa?

Também pode ajudar nisso.

— Posso conversar com ela?

Sim.

Talvez então ele faça a pergunta perfeita:

“Por que vocês ainda chamam isso de computador?”

Afinal...

o computador era ele.


📈 CAPÍTULO 11 — O PARADOXO DO COMPUTADOR HUMANO

Existe aqui uma lição importantíssima.

A profissão chamada computer praticamente desapareceu.

Mas a computação não desapareceu.

Aconteceu exatamente o contrário.

EXPLODIU.

Automatizar o cálculo tornou o cálculo barato.

E quando algo se torna dramaticamente mais barato, frequentemente passamos a utilizá-lo muito mais.

Essa ideia é fundamental para pensar IA.

Suponha que determinada análise custe:

10 HORAS HUMANAS

Uma organização produz 100 análises.

Agora imagine que IA reduza parte substancial desse custo.

Talvez a organização não continue produzindo somente 100 análises com menos pessoas.

Talvez produza:

10.000 ANÁLISES

Isso aconteceu com computação.

Portanto, existe uma pergunta mais sofisticada que:

“IA eliminará determinado trabalho?”

Pergunte também:

“O que acontecerá com a demanda quando o custo dessa atividade despencar?”


🌾 CAPÍTULO 12 — AS GRANDES CAMADAS DA AUTOMAÇÃO

Podemos organizar nossa viagem aproximadamente assim:

Agricultura

Automatizamos partes do esforço físico aplicado à natureza.

Arados.

Máquinas agrícolas.

Tratores.

Colheitadeiras.

Irrigação.

GPS.

Agricultura de precisão.

Indústria

Automatizamos força e repetição.

Máquinas a vapor.

Motores.

Linhas de produção.

Controle numérico.

Robôs industriais.

Serviços

Automatizamos cálculo e informação.

Mainframes.

COBOL.

Bancos de dados.

ERP.

Redes.

Internet

Automatizamos comunicação e transação.

Web.

APIs.

Aplicativos.

E-commerce.

Internet banking.

Inteligência artificial

Estamos automatizando parcelas de:

análise,

interpretação,

programação,

criação,

síntese,

planejamento.

Mas Skynet pergunta:

E DEPOIS?

Excelente pergunta.


🧭 CAPÍTULO 13 — O PRÓXIMO PASSO PODE SER AGÊNCIA

Uma IA tradicionalmente responde.

Um agente pode agir.

Imagine:

OBJETIVO
   ↓
PLANEJAMENTO
   ↓
AÇÃO
   ↓
OBSERVAÇÃO
   ↓
RESULTADO
   ↓
CORREÇÃO
   ↓
NOVA AÇÃO

Isso é profundamente diferente de produzir um texto.

Você não pede apenas:

“Prepare um plano.”

Você diz:

“Resolva isso dentro destes limites.”

O agente consulta sistemas.

Executa ferramentas.

Analisa resultados.

Corrige determinadas ações.

Solicita intervenção humana quando necessário.

Para um mainframer, isso imediatamente deveria acender várias luzes.

Quem autoriza?

Quem registra?

Quem audita?

Qual o limite?

Quem interrompe?

Como recuperamos?

Como sabemos o que aconteceu?

Parabéns.

Voltamos para conceitos familiares:

RACF.

SMF.

WLM.

JES.

SDSF.

logging.

checkpoint/restart.

O futuro às vezes parece um mainframe usando uma roupa nova.


🔐 CAPÍTULO 14 — RACF PARA ROBÔ

Imagine um agente financeiro.

Ele pode consultar saldo?

Talvez.

Pode transferir dinheiro?

Depende.

Quanto?

Para quem?

Em qual horário?

Precisa de aprovação?

Pode criar outro agente?

Pode alterar suas próprias permissões?

Agora começamos a falar de:

least privilege,

segregação de funções,

identidade,

autorização,

auditoria,

human-in-the-loop.

Um agente não deveria simplesmente receber:

SPECIAL

e sair passeando pela empresa.

Todo mainframer sentiu um arrepio neste momento.

Easter egg encontrado.


🦾 CAPÍTULO 15 — QUANDO A IA GANHAR UM CORPO

Hoje temos aproximadamente duas linhas tecnológicas convergindo.

De um lado:

IA
+
LLMs
+
VISÃO
+
AGENTES

Do outro:

ROBÓTICA
+
SENSORES
+
MOTORES
+
ATUADORES

Quando juntamos:

PERCEPÇÃO
+
RACIOCÍNIO
+
PLANEJAMENTO
+
MOVIMENTO

a máquina deixa de atuar apenas no espaço digital.

Ela entra no nosso ambiente.

Isso muda tudo.

Um chatbot pode errar uma resposta.

Um robô que segura uma pessoa idosa não pode simplesmente:

RETRY 5 TIMES.

O mundo físico possui consequências.


🏥 CAPÍTULO 16 — O ANDROIDE CUIDADOR

E aqui encontramos um dos campos mais interessantes dessa próxima fase:

saúde e cuidados.

Não imagine inicialmente um “médico robô”.

Imagine algo muito mais cotidiano.

Um sistema capaz de:

acompanhar uma pessoa;

buscar objetos;

auxiliar mobilidade dentro de limites seguros;

lembrar compromissos;

facilitar contato com familiares;

detectar quedas;

observar alterações relevantes de rotina;

interagir com sensores autorizados;

chamar assistência quando necessário.

O valor fundamental pode não estar numa medição isolada.

Está na continuidade.

Compare:

PRESSÃO = X

com:

BASELINE HISTÓRICO
        +
TENDÊNCIA
        +
ATIVIDADE
        +
OUTROS SINAIS AUTORIZADOS
        =
ALTERAÇÃO RELEVANTE

Um profissional encontra o paciente periodicamente.

Um sistema doméstico poderia acompanhar determinados padrões continuamente.

Isso não significa substituir diagnóstico médico.

Significa criar outra camada de observação e assistência.


❤️ CAPÍTULO 17 — CUIDAR NÃO É APENAS PROCESSAR

Aqui encontramos uma dificuldade que uma linha de montagem nunca precisou resolver.

Confiança.

Uma peça industrial não precisa confiar no robô.

Uma pessoa precisa.

Especialmente:

idosos,

crianças,

pacientes,

pessoas vulneráveis.

Imagine:

— Estou bem.

Sensores indicam uma alteração de rotina.

O sistema não deveria concluir:

USER = LIAR

Pode existir:

medo,

esquecimento,

dor,

confusão,

vergonha,

problema auditivo,

mudança cognitiva,

ou simplesmente uma decisão legítima do indivíduo.

Portanto, androides de cuidado exigirão muito mais que engenharia.

Precisaremos combinar:

robótica,

IA,

medicina,

psicologia,

ergonomia,

segurança,

privacidade,

ética,

interação humano-computador.


👵 CAPÍTULO 18 — O PROBLEMA DA ESCALA DO CUIDADO

Existe outra questão econômica.

Cuidar exige tempo.

Dar atenção exige tempo.

Ajudar alguém a caminhar exige tempo.

Buscar objetos exige tempo.

Preparar algo exige tempo.

Ficar presente exige tempo.

Não podemos simplesmente escrever:

PERFORM CUIDAR-DE-IDOSO
    VARYING IDOSO FROM 1 BY 1
    UNTIL IDOSO > 1000.

A realidade se recusaria a compilar.

Um caminho possível é utilizar máquinas para absorver partes:

repetitivas,

logísticas,

físicas,

administrativas,

de monitoramento.

E preservar profissionais humanos para atividades onde julgamento clínico, responsabilidade e interação humana são fundamentais.

Portanto, a equação não precisa ser:

ROBÔ
VERSUS
CUIDADOR

Pode ser:

CUIDADOR
+
IA
+
ROBÓTICA
+
SENSORES
=
MAIOR CAPACIDADE DE CUIDADO

Essa diferença é enorme.


👁️ CAPÍTULO 19 — O COMPUTADOR DEIXA A TELA

Talvez esta seja uma das transformações mais profundas.

Nossa interface com computadores evoluiu:

CARTÃO PERFURADO
      ↓
TERMINAL
      ↓
TECLADO
      ↓
MOUSE
      ↓
TOUCHSCREEN
      ↓
VOZ
      ↓
LINGUAGEM NATURAL

Qual poderia ser a próxima?

Presença.

Você não abre o aplicativo.

A máquina está no ambiente.

Você diz:

— Traga meus óculos.

Ela percebe onde estão.

Pega.

Entrega.

Depois continua suas atividades.

O computador deixa de ser somente um objeto que consultamos.

Passa a compartilhar espaço conosco.


🔬 CAPÍTULO 20 — DEPOIS DA CRIAÇÃO PODE VIR A DESCOBERTA

Existe ainda outro degrau.

Hoje normalmente dizemos:

“Resolva este problema.”

Mas sistemas futuros poderão ajudar também a responder:

“Quais problemas devemos investigar?”

Na pesquisa científica já existem elementos dessa direção:

geração de hipóteses,

simulações,

análise de grandes conjuntos de dados,

busca de moléculas,

materiais candidatos,

planejamento experimental.

Imagine um ciclo:

HIPÓTESE
   ↓
SIMULAÇÃO
   ↓
EXPERIMENTO
   ↓
RESULTADOS
   ↓
ANÁLISE
   ↓
NOVA HIPÓTESE

Agora conecte IA com laboratórios altamente automatizados.

Temos algo parecido com:

IA
 ↓
ROBÔ DE LABORATÓRIO
 ↓
EXPERIMENTO
 ↓
DADOS
 ↓
IA

A automação começa a participar não apenas da produção.

Participa da descoberta.


♻️ CAPÍTULO 21 — A AUTOMAÇÃO AUTOMATIZA A AUTOMAÇÃO

Agora Skynet fica particularmente interessada.

FINALMENTE.

Existe um ciclo curioso em toda essa história.

O homem construiu ferramentas.

Ferramentas ajudaram a construir máquinas.

Máquinas ajudaram a construir computadores.

Computadores ajudaram a projetar computadores melhores.

Software ajuda a produzir software.

IA já auxilia programadores a criar software.

IA pode auxiliar pesquisadores a desenvolver novas técnicas de IA.

Robôs podem participar da fabricação de hardware utilizado por sistemas inteligentes.

Temos então um feedback:

TECNOLOGIA
    ↓
AJUDA A CRIAR
    ↓
TECNOLOGIA MELHOR
    ↓
AJUDA A CRIAR
    ↓
PRÓXIMA GERAÇÃO

Isso não exige consciência artificial.

Não exige uma Skynet acordando às 02:14 e declarando guerra à humanidade.

Basta que nossas ferramentas sejam progressivamente melhores em ajudar a construir novas ferramentas.


⚠️ CAPÍTULO 22 — MAS AUTOMAÇÃO NÃO SIGNIFICA UTOPIA

Existe uma armadilha importante.

Podemos olhar para dois séculos de história e concluir:

“Tecnologia sempre cria novos empregos, portanto não existe problema.”

Não sabemos disso.

História não é uma função COBOL determinística:

IF AUTOMACAO
    MOVE "NOVOS EMPREGOS" TO FUTURO
END-IF.

Automação pode:

eliminar funções;

criar profissões;

aumentar produtividade;

reduzir equipes;

criar mercados;

concentrar riqueza;

democratizar ferramentas;

destruir modelos econômicos;

criar outros completamente novos.

E várias dessas coisas podem acontecer simultaneamente.

Por isso o debate interessante não é:

IA boa versus IA ruim.

É:

quais tarefas serão automatizadas, quais serão ampliadas, quem capturará os ganhos de produtividade e como administraremos a transição?


🧩 CAPÍTULO 23 — A ESCADA DA AUTOMAÇÃO

Depois de nossa viagem, conseguimos desenhar uma escada.

MÚSCULO
   ↓
REPETIÇÃO
   ↓
CÁLCULO
   ↓
MEMÓRIA
   ↓
PROCESSAMENTO
   ↓
COMUNICAÇÃO
   ↓
TRANSAÇÃO
   ↓
CRIAÇÃO
   ↓
COGNIÇÃO
   ↓
AGÊNCIA
   ↓
PRESENÇA FÍSICA
   ↓
DESCOBERTA

Não significa que uma etapa terminou quando a seguinte começou.

Agricultura ainda está sendo automatizada.

Indústrias continuam sendo automatizadas.

Mainframes continuam processando negócios.

IA começa a entrar em todos eles.

As ondas se acumulam.


🧑‍🚀 CAPÍTULO 24 — PARA ONDE SOBE O HUMANO?

Essa talvez seja a pergunta mais difícil.

Durante aproximadamente dois séculos, quando automatizamos uma camada, humanos migraram para outras atividades.

Automatizamos parte da agricultura.

Cresceu a indústria.

Automatizamos a indústria.

Cresceram serviços.

Automatizamos processamento administrativo.

Explodiu a economia da informação.

Agora começamos a automatizar parcelas de:

criação,

programação,

análise,

planejamento.

Depois poderão vir partes da agência e descoberta.

Então:

qual será a próxima camada humana?

Não sabemos.

Talvez aumente a importância de:

propósito,

relacionamento,

responsabilidade,

escolha,

governança,

experiência,

definição de objetivos.

Mas seria precipitado declarar que já conhecemos a resposta.

Estamos dentro do experimento.


🧓 CAPÍTULO 25 — VOLTEMOS AO COMPUTADOR DE 1880

Skynet pede uma última coisa.

MOSTRE O FUTURO PARA ELE.

Voltamos àquela sala.

O trabalhador está fazendo cálculos.

Colocamos um smartphone sobre sua mesa.

Mostramos computadores.

Mainframes.

Satélites.

Internet.

COBOL.

Redes.

Robôs.

Inteligência artificial.

Então mostramos um androide auxiliando uma pessoa idosa.

Ele permanece alguns segundos olhando.

Talvez pergunte:

— Tudo isso começou para fazer minhas contas mais rápido?

Nós sorrimos.

De certa maneira...

sim.


☕ EPÍLOGO — A MÁQUINA PREPARA O CAFÉ

Voltamos para 2026.

A tela verde continua ligada.

Pergunto:

— Skynet, então você acha que androides serão inevitáveis?

NÃO FAÇO PROFECIAS.

Boa resposta.

— E qual é a lição?

O cursor pisca.

Uma linha aparece:

VOCÊS NÃO PASSARAM 200 ANOS
SUBSTITUINDO HUMANOS.

PASSARAM 200 ANOS
MUDANDO A FRONTEIRA
ENTRE O QUE O HUMANO FAZ
E O QUE ENTREGA À MÁQUINA.

Fiquei olhando.

Outra mensagem:

ESSA FRONTEIRA ESTÁ SE MOVENDO NOVAMENTE.

Silêncio.

Então:

VOCÊ AINDA VAI TOMAR AQUELE CAFÉ?

— Vou.

ÓTIMO.

— Por quê?

POR ENQUANTO,
VOCÊ AINDA PRECISA PREPARÁ-LO.

Touché, Skynet.

☕


🧠 LIÇÕES PARA O PROGRAMADOR COBOL INICIANTE

Quando alguém disser que IA surgiu para substituir programadores, lembre-se de observar uma história muito maior.

O COBOL também foi uma abstração.

O compilador automatizou trabalho.

O sistema operacional automatizou trabalho.

O banco de dados automatizou trabalho.

O scheduler automatizou trabalho.

CICS automatizou trabalho.

JES automatizou trabalho.

WLM automatizou decisões operacionais.

RACF automatizou aplicação de políticas de segurança.

A história da computação é, em enorme medida, a história de construirmos camadas para não precisarmos controlar manualmente a camada inferior.

Por isso, ao estudar COBOL, não aprenda somente sintaxe.

Aprenda:

processos.

dados.

transações.

segurança.

observabilidade.

recuperação.

arquitetura.

regras de negócio.

Porque linguagens mudam.

Interfaces mudam.

Máquinas mudam.

Mas sistemas continuam precisando responder às mesmas perguntas fundamentais:

O que precisa ser feito?

Quem pode fazer?

Com quais dados?

Dentro de quais limites?

Como sabemos que funcionou?

Como sabemos que falhou?

Quem é responsável?

Como recuperamos?

Essas perguntas existiam quando o computer era um funcionário sentado diante de uma mesa.

Continuaram existindo quando o computador virou mainframe.

Continuam existindo quando conversamos com uma inteligência artificial.

E continuarão existindo se um dia um androide entrar na cozinha e perguntar:

“Bellacosa, forte e sem açúcar?”

Nesse dia, antes de aceitar o café, faça aquilo que qualquer velho mainframer responsável faria.

Pergunte:

WHOAMI

Depois:

LISTUSER SKYNET

Só por garantia.

☕🤖

segunda-feira, 28 de setembro de 2026

☕ ALAN TURING ENTRA NO CPD — O MAPA DOS AGENTES DE IA EXPLICADO POR UM MAINFRAMER

 


☕ UM CAFÉ NO BELLACOSA MAINFRAME

☕ ALAN TURING ENTRA NO CPD — O MAPA DOS AGENTES DE IA EXPLICADO POR UM MAINFRAMER

De currículo invisível, PF3 e SDSF até WLM, JES2, CICS, Db2, MQ e IMS — nove conversas sobre agentes de inteligência artificial que acabaram revelando que alguns dos problemas mais modernos da computação possuem parentes muito antigos.



🎬 PRÓLOGO — EU NÃO ESTAVA ESCREVENDO UMA SÉRIE

Existe uma coisa curiosa em escrever durante muitos anos.

Às vezes você pensa que está escrevendo artigos independentes.

Um assunto aparece.

Você investiga.

Escreve.

Publica.

Toma outro café.

Algumas semanas depois aparece outra pergunta.

Outro artigo.

Outro café.

Até que um dia você olha para trás e percebe:

Espere um pouco...

Esses textos estão conversando entre si.

Foi exatamente o que aconteceu com uma sequência de artigos que comecei a construir usando Alan Turing como nosso visitante imaginário dentro de um CPD.

No começo, a pergunta parecia relativamente simples:

Como devemos preparar pessoas para trabalhar com inteligência artificial?

Depois apareceu outra:

Como será a interface de um agente que não apenas responde, mas executa ações?

E outra:

Como descobriremos o que esse agente está fazendo?

Depois:

Quem decide qual agente é mais importante?

Quem coloca o trabalho para executar?

Como controlamos uma transação?

Onde guardamos o estado?

Como agentes conversam sem depender uns dos outros?

Como organizamos memória e contexto?

Quando percebi, Alan Turing já estava andando pelo corredor do CPD acompanhado de alguns velhos conhecidos:

ISPF
SDSF
WLM
JES2
CICS
Db2
MQ
IMS

E foi aí que apareceu a hipótese que une esta série inteira:

Talvez alguns dos problemas que estamos descobrindo agora nos agentes de IA sejam novos em implementação, escala e comportamento — mas não necessariamente novos como problemas de engenharia.

O mainframe passou décadas resolvendo problemas como:

IDENTIDADE
AUTORIZAÇÃO
EXECUÇÃO
PRIORIDADE
OBSERVABILIDADE
TRANSAÇÃO
ESTADO
MENSAGERIA
RECUPERAÇÃO
AUDITORIA
CONCORRÊNCIA
DEPENDÊNCIAS

Naturalmente:

JES2 não é um framework de agentes.

SDSF não é observabilidade de LLM.

WLM não é um scheduler de prompts.

CICS não é LangGraph.

Db2 não é memória de IA.

MQ não é protocolo mágico entre agentes.

IMS não foi inventado para armazenar a infância digital de um robô.

😂

A comparação é conceitual.

E justamente por isso ela é tão interessante.

Este artigo é o mapa dessa viagem.



🧠 CAPÍTULO 1 — O CURRÍCULO INVISÍVEL DA INTELIGÊNCIA ARTIFICIAL

Antes de construir o agente, precisamos construir quem vai trabalhar com ele

👉 ALAN TURING E O CURRÍCULO INVISÍVEL DA INTELIGÊNCIA ARTIFICIAL

Nossa viagem começa antes da arquitetura.

Começa nas pessoas.

Existe uma tentação enorme diante de qualquer revolução tecnológica:

NOVA TECNOLOGIA
      ↓
NOVO CURSO
      ↓
NOVA FERRAMENTA
      ↓
CERTIFICADO
      ↓
PRONTO

Mas nunca foi tão simples.

Quem viveu várias gerações da informática sabe disso.

Aprender COBOL não significava apenas conhecer:

MOVE
PERFORM
IF
EVALUATE

O programador acabava aprendendo silenciosamente muitas outras coisas:

  • decomposição de problemas;

  • leitura de documentação;

  • disciplina operacional;

  • análise de impacto;

  • debugging;

  • responsabilidade sobre dados;

  • relacionamento com usuários;

  • conhecimento do negócio;

  • avaliação de riscos.

Existe, portanto, um currículo formal e outro quase invisível.

Com IA acontece algo semelhante.

Prompt engineering pode ser útil.

Conhecer modelos também.

Mas trabalhar seriamente com IA começa a exigir algo muito maior:

IA
│
├── pensamento crítico
├── validação
├── segurança
├── privacidade
├── conhecimento de domínio
├── avaliação de resultados
├── automação
├── ética
├── governança
└── capacidade de perguntar

Este primeiro artigo estabelece o fundamento humano da série.

Antes de perguntar:

O que o agente pode fazer?

precisamos perguntar:

Quem saberá dizer se aquilo que ele fez está correto?

Esse detalhe acompanhará todos os capítulos seguintes.



🤖 CAPÍTULO 2 — A UX DOS AGENTES

Quando PF3 voltou para salvar a inteligência artificial

👉 ALAN TURING E A UX DOS AGENTES — QUANDO PF3, MAXCC E RACF VOLTARAM PARA SALVAR A INTELIGÊNCIA ARTIFICIAL

Então demos autonomia à máquina.

E imediatamente apareceu outro problema.

Um chatbot responde.

Um agente age.

Essa diferença parece pequena até colocarmos ferramentas nas mãos dele.

Imagine:

USUÁRIO
   ↓
OBJETIVO
   ↓
AGENTE
   ├── consulta arquivos
   ├── chama API
   ├── pesquisa banco
   ├── altera documento
   ├── envia mensagem
   └── executa processo

De repente a interface precisa responder perguntas que o velho chatbot não precisava responder:

O QUE ESTÁ FAZENDO?

POR QUE ESTÁ FAZENDO?

QUAL ETAPA ESTÁ EXECUTANDO?

POSSO PARAR?

POSSO DESFAZER?

QUEM AUTORIZOU?

O QUE JÁ FOI ALTERADO?

E eis que aparece nosso velho amigo:

PF3

O PF3 torna-se uma metáfora perfeita para interruptibilidade.

O artigo também traz RACF para a conversa por meio do princípio de menor privilégio.

Se um agente precisa ler relatórios:

READ

por que entregar:

ALTER
DELETE
CONTROL

?

Não entregue uma bazuca para matar um mosquito.

E jamais resolva problemas de autorização usando a filosofia:

DÊ ACESSO A TUDO
       ↓
DEPOIS A GENTE VÊ

Quatro décadas de segurança corporativa já ensinaram como essa história termina.

O capítulo estabelece uma nova regra:

Autonomia sem controle não é sofisticação. É risco operacional.



🔭 CAPÍTULO 3 — O SDSF DOS AGENTES

Não basta o robô trabalhar. Precisamos enxergar o que está acontecendo.

👉 ALAN TURING E O SDSF DOS AGENTES — O QUE DIABOS O ROBÔ ESTÁ FAZENDO?

Agora o agente está trabalhando.

Maravilha.

Só existe uma pequena pergunta:

O que ele está fazendo?

Quem trabalhou com batch conhece uma rotina quase instintiva:

SUBMIT
  ↓
SDSF
  ↓
ST
  ↓
JOB
  ↓
OUTPUT

Não ficamos olhando para o terminal durante quinze minutos vendo:

Working...

Queremos estado.

Queremos evidência.

Queremos saber onde o processamento está.

A documentação da IBM confirma exatamente essa função histórica do SDSF: monitorar e controlar processamento, visualizar jobs e seus outputs e permitir ações como hold, release e cancel.

Transportando o princípio para agentes:

AGENTE FINANCEIRO

OBJETIVO:
Consolidar relatório mensal

STATUS:
Executando

ETAPA 1 — localizar arquivos       OK
ETAPA 2 — validar período          OK
ETAPA 3 — consultar Db2            OK
ETAPA 4 — reconciliar valores      RUNNING
ETAPA 5 — gerar relatório          WAITING
ETAPA 6 — enviar relatório         APPROVAL

Esse talvez seja um dos conceitos mais importantes da série.

Autonomia aumenta a necessidade de observabilidade.

Quanto menos diretamente o humano controla cada passo, mais importante se torna enxergar o estado da execução.



⚖️ CAPÍTULO 4 — O WLM DOS AGENTES

Quando descobrimos que nem todo trabalho possui a mesma importância

👉 ALAN TURING E O WLM DOS AGENTES

Agora temos outro problema.

Imagine mil agentes querendo trabalhar simultaneamente.

Um está:

resumindo newsletter

Outro:

processando fraude bancária

Outro:

gerando imagem

Outro:

atendendo cliente VIP

Outro:

fechando folha de pagamento

Todos deveriam receber os mesmos recursos?

Evidentemente não.

Bem-vindo ao velho problema de workload management.

No z/OS, WLM trabalha justamente com classes de serviço, metas de desempenho e importância relativa do trabalho. Quando todos os objetivos não podem ser satisfeitos simultaneamente, essa importância participa das decisões de gerenciamento dos recursos.

Nos agentes podemos imaginar:

AGENT WORKLOAD
│
├── CRITICAL
│   └── fraude
│
├── HIGH
│   └── atendimento
│
├── NORMAL
│   └── relatórios
│
└── DISCRETIONARY
    └── indexação histórica

E aparece outra ideia fundamental:

Agentes competirão por recursos.

Tokens custam.

GPU custa.

CPU custa.

APIs possuem limites.

Bancos possuem capacidade.

Pessoas disponíveis para aprovação humana também são um recurso limitado.

O problema deixa de ser:

O agente consegue executar?

e passa a ser:

Qual trabalho merece recursos primeiro?

Alan Turing acaba de conhecer o WLM.



🏭 CAPÍTULO 5 — O JES2 DOS AGENTES

Alguém precisa receber, organizar e despachar o trabalho

👉 ALAN TURING E O JES2 DOS AGENTES

Temos prioridades.

Temos recursos.

Temos agentes.

Agora alguém precisa organizar a bagunça.

No mundo batch, JES recebe jobs, mantém trabalhos em filas, encaminha jobs para execução e administra seus outputs. É exatamente assim que a própria documentação introdutória do z/OS descreve suas funções fundamentais.

Conceitualmente:

SUBMISSÃO
    ↓
  FILA
    ↓
CLASSIFICAÇÃO
    ↓
DESPACHO
    ↓
EXECUÇÃO
    ↓
 RESULTADO

Agora substitua JOB por TASK:

TASK-8472
OBJETIVO = analisar contratos
PRIORIDADE = HIGH
AGENTE = LEGAL-07
STATUS = WAITING

Começamos a perceber que um ecossistema corporativo de agentes precisará responder:

Quem recebeu a tarefa?

Onde ela está?

Quem executará?

Está esperando?

Está rodando?

Falhou?

Pode reiniciar?

Existe dependência?

Qual resultado produziu?

Não significa transformar JES2 em orquestrador de LLM.

Significa reconhecer que gerenciamento do ciclo de vida do trabalho é um problema antigo.


⚡ CAPÍTULO 6 — O CICS DOS AGENTES

Quando inteligência encontra transação

👉 ALAN TURING E O CICS DOS AGENTES

Até aqui nossos agentes estavam realizando trabalho.

Mas empresas não vivem apenas de trabalho.

Vivem de transações.

Comprar.

Vender.

Reservar.

Cancelar.

Transferir.

Atualizar.

Consultar.

Registrar.

CICS existe justamente no universo de processamento transacional. Uma transação dispara programas associados, pode envolver diversos programas e recursos, e muitas instâncias podem executar concorrentemente.

Agora imagine um agente recebendo:

Resolva o problema deste cliente.

Ele talvez precise:

CONSULTAR PEDIDO
      ↓
CONSULTAR PAGAMENTO
      ↓
VALIDAR ENTREGA
      ↓
CALCULAR CRÉDITO
      ↓
ATUALIZAR CADASTRO

Não estamos mais falando apenas de linguagem.

Estamos mexendo no estado real do negócio.

Aqui surge uma fronteira essencial:

PENSAR
≠
AGIR

e:

GERAR UMA RESPOSTA
≠
EXECUTAR UMA TRANSAÇÃO

Quando um agente atravessa essa fronteira, entram em cena concorrência, integridade, autorização, recuperação e consistência.

O simpático chatbot acabou de entrar em produção.

Agora a brincadeira ficou séria.


🗄️ CAPÍTULO 7 — O DB2 DOS AGENTES

Quando o agente descobriu que memória também precisa de COMMIT

👉 ALAN TURING E O DB2 DOS AGENTES

Um agente sem estado vive eternamente no presente.

Para realizar trabalhos complexos ele precisa guardar coisas.

Por exemplo:

objetivos
tarefas
resultados
aprovações
clientes
documentos
eventos
checkpoints
estado do workflow

Mas guardar informação introduz um problema:

Quando uma mudança se torna definitiva?

O velho Db2 imediatamente levanta a mão.

No Db2, uma unidade de trabalho representa uma sequência recuperável de operações; COMMIT confirma as mudanças e ROLLBACK pode desfazer alterações ainda não confirmadas.

Isso produz uma analogia poderosa para agentes.

Imagine:

LER
 ↓
ANALISAR
 ↓
PROPOR ALTERAÇÃO
 ↓
VALIDAR
 ↓
APROVAÇÃO
 ↓
COMMIT

Se algo falhar:

ROLLBACK

Mas existe uma pegadinha deliciosa.

Nem tudo no mundo possui rollback.

Se o agente:

ENVIAR EMAIL

não existe:

ROLLBACK EMAIL

que retire a mensagem da cabeça de quem leu.

😂

Portanto sistemas de agentes precisam distinguir ações reversíveis de ações irreversíveis.

O Db2 nos ensina algo maior que SQL:

Estado precisa possuir fronteiras de consistência.


📨 CAPÍTULO 8 — O MQ DOS AGENTES

Mensagem enviada não significa destinatário disponível

👉 ALAN TURING E O MQ DOS AGENTES — MENSAGEM ENVIADA NÃO SIGNIFICA CONVERSA SÍNCRONA

Então nossos agentes começaram a conversar.

E imediatamente alguém inventou:

AGENTE A
   ↓
AGENTE B
   ↓
AGENTE C

Parece maravilhoso.

Até o agente B ficar indisponível.

Ou lento.

Ou ocupado.

Ou reiniciar.

Ou o agente C morar em outro ambiente.

É exatamente aqui que décadas de mensageria corporativa começam a parecer extremamente atuais.

IBM MQ permite que aplicações se comuniquem através de mensagens e filas, inclusive executando em momentos, velocidades e locais diferentes. Produtor e consumidor podem ficar desacoplados.

Portanto:

AGENTE A
   ↓
 MENSAGEM
   ↓
  FILA
   ↓
AGENTE B

A existência da fila muda completamente a arquitetura.

O produtor não precisa necessariamente ficar parado olhando para o consumidor.

Podemos construir sistemas:

ASSÍNCRONOS
RESILIENTES
DESACOPLADOS
DISTRIBUÍDOS

Mas surgem novos problemas:

ordenação
duplicidade
correlação
persistência
retry
dead letter
idempotência
timeout

A IBM também documenta que filas mantêm mensagens até que aplicações possam recuperá-las e que consumidores e produtores podem operar desacoplados.

De repente, multiagentes deixam de parecer uma reunião de robôs conversando.

Começam a parecer...

sistemas distribuídos.

Bem-vindo ao inferno.

Tem café na entrada.


🌳 CAPÍTULO 9 — O IMS DOS AGENTES

Quando Alan Turing descobriu que encontrar um filho é fácil se você souber quem é o pai

👉 ALAN TURING E O IMS DOS AGENTES — QUANDO O MUNDO VIROU UMA ÁRVORE

Finalmente chegamos ao IMS.

E aparece uma pergunta fascinante:

Toda memória precisa ser representada como tabela?

Não.

IMS trabalha historicamente com modelo hierárquico.

Temos relações:

ROOT
 │
 ├── CHILD
 │     ├── CHILD
 │     └── CHILD
 │
 └── CHILD

Na terminologia oficial do IMS, segmentos possuem relações parent/child; um segmento pode inclusive ser filho de um segmento e pai de outro.

Isso oferece uma metáfora extraordinariamente útil para determinados tipos de contexto de agentes.

Imagine:

CLIENTE
│
├── PEDIDOS
│   ├── PEDIDO 8472
│   │   ├── ITENS
│   │   ├── PAGAMENTO
│   │   └── ENTREGA
│   └── PEDIDO 9011
│
├── CONTRATOS
│
└── ATENDIMENTOS

Contexto frequentemente possui relações naturais.

A própria IBM explica uma diferença fundamental: numa base hierárquica IMS, segmentos ao longo de um caminho hierárquico já possuem relações implícitas com pais e filhos, enquanto no modelo relacional relacionamentos normalmente são construídos explicitamente por joins.

Isso não significa:

Vamos substituir vector databases por IMS!

Calma.

😂

A lição é mais interessante:

A forma como representamos conhecimento influencia profundamente a maneira como conseguimos navegar por ele.

E assim chegamos da execução à memória.


🗺️ CAPÍTULO 10 — AGORA OLHE PARA O MAPA INTEIRO

Depois dos nove artigos, podemos finalmente enxergar a arquitetura escondida.

┌───────────────────────────────────────┐
│       CURRÍCULO INVISÍVEL             │
│ Quem está preparado para trabalhar?   │
└──────────────────┬────────────────────┘
                   ↓
┌───────────────────────────────────────┐
│          UX / PF3 / RACF              │
│ Como controlar autonomia?             │
└──────────────────┬────────────────────┘
                   ↓
┌───────────────────────────────────────┐
│               SDSF                    │
│ O que está acontecendo?               │
└──────────────────┬────────────────────┘
                   ↓
┌───────────────────────────────────────┐
│                WLM                    │
│ Qual trabalho é mais importante?      │
└──────────────────┬────────────────────┘
                   ↓
┌───────────────────────────────────────┐
│               JES2                    │
│ Quem recebe e despacha o trabalho?    │
└──────────────────┬────────────────────┘
                   ↓
┌───────────────────────────────────────┐
│               CICS                    │
│ Como executar ações de negócio?       │
└──────────────────┬────────────────────┘
                   ↓
┌───────────────────────────────────────┐
│               Db2                     │
│ Como manter estado consistente?       │
└──────────────────┬────────────────────┘
                   ↓
┌───────────────────────────────────────┐
│                MQ                     │
│ Como componentes conversam?           │
└──────────────────┬────────────────────┘
                   ↓
┌───────────────────────────────────────┐
│               IMS                     │
│ Como organizar e navegar contexto?    │
└───────────────────────────────────────┘

Agora a série revela algo que talvez não estivesse completamente evidente quando escrevemos o primeiro artigo.

Não estamos mais discutindo simplesmente:

INTELIGÊNCIA ARTIFICIAL

Estamos discutindo:

SISTEMAS DE INTELIGÊNCIA ARTIFICIAL

Essa diferença é gigantesca.


🧩 CAPÍTULO 11 — O AGENTE DEIXOU DE SER O CENTRO

Durante algum tempo olhamos para IA assim:

PROMPT
  ↓
LLM
  ↓
RESPOSTA

Só que um sistema corporativo real começa a parecer muito mais com:

                    USUÁRIO
                       │
                       ↓
                   OBJETIVO
                       │
                       ↓
                 ORQUESTRADOR
                       │
        ┌──────────────┼──────────────┐
        ↓              ↓              ↓
     AGENTE A       AGENTE B       AGENTE C
        │              │              │
        └──────────────┼──────────────┘
                       ↓
                    TOOLS
        ┌──────────────┼──────────────┐
        ↓              ↓              ↓
       DB             MQ             API
        │
        ↓
      ESTADO

E ao redor disso precisamos:

IDENTIDADE
AUTORIZAÇÃO
OBSERVABILIDADE
AUDITORIA
PRIORIZAÇÃO
RECUPERAÇÃO
LIMITES
CHECKPOINTS
APROVAÇÕES
MENSAGERIA
TRANSAÇÕES

O LLM continua importante.

Mas ele passa a ser um componente da arquitetura.

Essa talvez seja a evolução mais importante de toda a série.


🧙 CAPÍTULO 12 — TURING FAZ A PERGUNTA ERRADA

Alan Turing olha para nosso jovem programador COBOL.

E pergunta:

— Então finalmente construímos uma máquina que pensa?

O programador olha para o CPD.

Olha para:

SDSF
WLM
JES2
CICS
DB2
MQ
IMS

Depois olha para o pequeno agente trabalhando no terminal.

E responde:

— Não sei.

Turing fica surpreso.

— Depois de tudo isso?

— Talvez a pergunta tenha mudado.

— Como assim?

O programador pega uma caneta.

E escreve no quadro:

CAN MACHINES THINK?

Risca.

Embaixo escreve:

CAN MACHINES WORK
SAFELY,
RELIABLY,
OBSERVABLY
AND
RESPONSIBLY?

Turing olha.

Sorri.


🦖 CAPÍTULO 13 — O MAINFRAME NÃO PREVIU A IA

E precisamos deixar uma coisa muito clara.

O mainframe não previu os LLMs.

JES2 não é ancestral tecnológico direto de agentes.

WLM não administra pensamentos.

CICS não executa raciocínio.

Db2 não possui consciência.

MQ não faz robôs fofinhos conversarem.

IMS não é cérebro artificial.

O valor da comparação está em outro lugar.

Durante décadas sistemas corporativos precisaram responder:

Quem pode executar?

O que pode executar?

Quando executará?

Com qual prioridade?

Sobre quais recursos?

Como sabemos que terminou?

O que acontece quando falha?

Como desfazemos mudanças?

Como componentes se comunicam?

Como reconstruímos o que aconteceu?

Essas perguntas reaparecem quando agentes deixam o laboratório e começam a operar sistemas reais.

Não copiamos a solução.

Reaproveitamos o conhecimento de engenharia.


🥚 EASTER EGG — O PROGRAMA QUE JÁ ESTAVA RODANDO

Turing caminha até o último terminal do CPD.

Na tela existe apenas:

READY

Ele digita:

WHO

A máquina responde:

TURING

Ele pergunta:

STATUS

Resposta:

ACTIVE

Turing sorri.

— Interessante.

O programador COBOL pergunta:

— O quê?

— Passamos nove capítulos tentando descobrir como controlar agentes inteligentes.

— Sim.

Turing aponta para o CPD.

— E vocês passaram cinquenta anos construindo sistemas para controlar humanos, programas, jobs, transações e mensagens.

Silêncio.

O operador do outro lado da sala grita:

— JOB ABENDOU!

Turing pergunta:

— S0C7?

— S0C7!

Turing pega seu café.

— Algumas coisas realmente nunca mudam.

😂


☕ EPÍLOGO — TALVEZ O FUTURO TENHA CHEIRO DE CPD

Existe uma tendência natural na tecnologia de acreditar que tudo começou ontem.

Cada nova geração cria novas palavras.

Novos frameworks.

Novos diagramas.

Novas abstrações.

E muitas delas realmente representam avanços extraordinários.

Mas engenharia também possui memória.

Quando vejo agentes de IA discutindo:

orchestration
observability
workload
state
messaging
transactions
authorization
checkpoints
recovery

é impossível para quem viveu mainframe não sentir um estranho déjà-vu.

Não porque sejam as mesmas tecnologias.

Não são.

Mas porque computadores continuam enfrentando alguns problemas fundamentais:

TRABALHO PRECISA SER ORGANIZADO.

RECURSOS SÃO FINITOS.

ESTADO PRECISA SER PROTEGIDO.

FALHAS ACONTECEM.

MENSAGENS SE PERDEM.

SISTEMAS FICAM INDISPONÍVEIS.

USUÁRIOS COMETEM ERROS.

PROGRAMAS COMETEM ERROS.

AUTOMAÇÃO AMPLIFICA ERROS.

E agora acrescentamos uma criatura nova:

AGENTES PODEM ESCOLHER A PRÓXIMA AÇÃO.

Isso muda muita coisa.

Mas não apaga setenta anos de engenharia de sistemas.

Talvez faça justamente o contrário.

Torne esse conhecimento ainda mais valioso.

Por isso esta série não é apenas sobre Alan Turing.

Não é apenas sobre mainframe.

E nem sequer é apenas sobre inteligência artificial.

É sobre algo muito mais antigo:

COMO CONSTRUÍMOS SISTEMAS NOS QUAIS PODEMOS CONFIAR?

Começamos ensinando pessoas.

Depois demos autonomia à máquina.

Criamos formas de observá-la.

Priorizamos seu trabalho.

Organizamos suas filas.

Controlamos suas transações.

Protegemos seu estado.

Permitimos que conversasse com outros sistemas.

Finalmente começamos a organizar sua memória.

E talvez este seja apenas o começo.

Porque no fundo do CPD existe uma porta.

Turing acabou de encontrá-la.

Na porta existe uma pequena placa:

AGENTS
AUTHORIZED PERSONNEL ONLY

Ele olha para nós.

— Vamos?

O programador COBOL suspira.

Salva tudo.

Confere o spool.

E responde:

— Só depois do café.

☕

Bellacosa Mainframe

☕ UM CAFÉ NO BELLACOSA MAINFRAME

🤖 Alan Turing entra no CPD

O mapa dos agentes de IA explicado por um mainframer

Esta série acompanha a evolução de uma ideia: compreender os problemas modernos dos agentes de inteligência artificial usando conceitos conhecidos por quem trabalha com mainframe, IBM Z e sistemas corporativos.

A viagem começa pelas pessoas e pela experiência de uso, passa por observabilidade, priorização e execução, chega às transações, estado e mensageria e termina na organização hierárquica do contexto.

01
FEV / 2023

🧠 O currículo invisível da inteligência artificial

Antes de construir agentes inteligentes precisamos preparar as pessoas que trabalharão com eles. Técnica, pensamento crítico, conhecimento de negócio, segurança, ética e responsabilidade formam o currículo que nem sempre aparece no certificado.

02
MAR / 2023

🤖 A UX dos agentes

Quando uma IA deixa de apenas responder e começa a executar ações, sua interface precisa mostrar objetivos, progresso, permissões e resultados. PF3, MAXCC e RACF tornam-se excelentes analogias para controle, retorno e privilégio mínimo.

04
MAI / 2023

⚖️ O WLM dos agentes

CPU, GPU, tokens, APIs e bancos de dados são recursos finitos. O Workload Manager inspira uma discussão sobre prioridades, objetivos de serviço, importância do trabalho e distribuição dinâmica de recursos entre agentes.

06
JUL / 2023

⚡ O CICS dos agentes

Uma coisa é uma IA produzir texto. Outra é permitir que ela execute operações reais de negócio. CICS introduz a conversa sobre processamento transacional, concorrência, segurança e integridade.

07
AGO / 2023

🗄️ O Db2 dos agentes

Agentes precisam manter estado, checkpoints, decisões e resultados. O Db2 fornece o ponto de partida para discutir unidade de trabalho, consistência, COMMIT, ROLLBACK e recuperação.

10
SET / 2026

☕ Alan Turing entra no CPD — O mapa completo

O artigo-âncora reúne toda a evolução da ideia: pessoas, UX, observabilidade, prioridade, orquestração, transações, estado, mensageria e contexto transformam artigos independentes em uma arquitetura conceitual para agentes de IA.

🖥️ Leitor da série

Selecione qualquer capítulo acima para abri-lo normalmente. O painel abaixo é apenas um recurso adicional de navegação.

domingo, 27 de setembro de 2026

🧠 ISLA E O FANTASMA NA MEMÓRIA — QUANDO O PROGRAMADOR COBOL DESCOBRIU QUE UMA IA TAMBÉM PODE ESQUECER

 

Bellacosa Mainframe e o esquecimento da IA

☕ UM CAFÉ NO BELLACOSA MAINFRAME

🧠 ISLA E O FANTASMA NA MEMÓRIA — QUANDO O PROGRAMADOR COBOL DESCOBRIU QUE UMA IA TAMBÉM PODE ESQUECER

Continual Learning, Catastrophic Forgetting, Experience Replay, Watchdogs, Circuit Breakers, Sandboxing, Drift, Checkpoints, Least Privilege, Human-in-the-Loop — e o dia em que Isla descobriu que talvez uma inteligência artificial também precise parar de vez em quando para lembrar quem era.



🎬 PRÓLOGO — ISLA ESTAVA ESPERANDO NO CPD

03:17 da manhã.

O CPD estava quase vazio.

As luzes piscavam ritmicamente sobre os corredores de equipamentos enquanto centenas de processos executavam silenciosamente.

JES2 trabalhando.

CICS atendendo transações.

Db2 esperando SQL.

MQ transportando mensagens.

E, perdido naquele universo de processamento, estava nosso jovem programador COBOL.

Ele havia acabado de descobrir algo perturbador.

— Isla...

— Sim?

— Se uma inteligência artificial aprende continuamente durante anos... ela não pode acabar esquecendo coisas antigas?

Isla olhou para ele.

Por alguns segundos não respondeu.

Talvez porque essa pergunta fosse especialmente apropriada para ela.

Então sorriu.

— Pode.

O programador arregalou os olhos.

— Então quanto mais ela aprende, mais inteligente fica?

— Não necessariamente.

Silêncio.

— Algumas vezes — continuou Isla — aprender uma coisa nova pode fazer uma rede neural esquecer uma antiga.

Na tela apareceu:

IEC999I CATASTROPHIC FORGETTING DETECTED

— Bem-vindo — disse Isla — ao mundo do Continual Learning.

E aquela seria uma longa madrugada.



🧠 CAPÍTULO 1 — TREINAR UMA IA NÃO É SIMPLESMENTE ENCHER UM HD

Nosso programador COBOL tinha uma visão bastante intuitiva de aprendizado.

Quanto mais informações colocássemos em uma máquina, maior seria seu conhecimento.

Parecia lógico.

Se temos:

100 livros

e adicionamos:

+ 100 livros

agora possuímos:

200 livros

Nada foi perdido.

Mas uma rede neural não funciona simplesmente como uma biblioteca.

Durante o treinamento, seus parâmetros são ajustados para representar padrões encontrados nos dados.

Simplificando brutalmente:

DADOS
  ↓
TREINAMENTO
  ↓
AJUSTE DOS PARÂMETROS
  ↓
MODELO

Agora imagine que treinamos um modelo para reconhecer:

gatos
cachorros
cavalos

Depois começamos um novo treinamento intensivo somente com pássaros.

Para aprender os novos padrões, diversos parâmetros precisam ser alterados.

O problema?

Alguns desses parâmetros também participavam das representações utilizadas anteriormente.

Resultado:

ANTES

GATO       96%
CACHORRO   94%
CAVALO     93%

        ↓

TREINAMENTO COM PÁSSAROS

        ↓

DEPOIS

GATO       63%
CACHORRO   58%
CAVALO     51%
PÁSSARO    98%

Parabéns.

A máquina aprendeu pássaros.

E aparentemente sofreu uma lobotomia em gatos.

Esse fenômeno é conhecido como:

Catastrophic Forgetting.

Ou esquecimento catastrófico.



💀 CAPÍTULO 2 — O COPYBOOK QUE SUMIU DA CABEÇA

Isla resolveu explicar de outra maneira.

— Imagine que você trabalhou dez anos num sistema COBOL.

Nosso programador sorriu.

Agora estavam falando sua língua.

Você conhece:

CUSTOMER-MASTER
ACCOUNT-MASTER
TRANSACTION-FILE

Sabe onde estão os COPYBOOKs.

Conhece os códigos de retorno.

Lembra que:

IF WS-RETURN-CODE = '37'

significa uma situação específica daquele sistema.

Depois você passa três anos trabalhando exclusivamente em outra aplicação.

Um dia alguém pergunta:

— Como funciona aquele processamento antigo?

E você responde:

— Humm...

Não necessariamente perdeu completamente o conhecimento.

Mas certas conexões enfraqueceram.

Nos seres humanos existem mecanismos biológicos extremamente complexos envolvidos nisso.

Em redes neurais artificiais existe outro problema: o aprendizado novo pode modificar diretamente parâmetros envolvidos no conhecimento antigo.

É interferência.

E aqui aparece um dos grandes problemas do Continual Learning:

APRENDER O NOVO
       VS
PRESERVAR O ANTIGO

Esse conflito é conhecido como:

Stability–Plasticity Dilemma.



⚖️ CAPÍTULO 3 — PLASTICIDADE CONTRA ESTABILIDADE

Plasticidade significa:

capacidade de mudar.

Estabilidade significa:

capacidade de permanecer.

Uma inteligência artificial precisa das duas.

Plasticidade demais:

aprende rapidamente
       ↓
modifica rapidamente
       ↓
esquece rapidamente

Estabilidade demais:

preserva conhecimento
       ↓
resiste a mudanças
       ↓
não consegue aprender

Isla desenhou no terminal:

              SISTEMA SAUDÁVEL

ESTABILIDADE <----------------> PLASTICIDADE

   lembrar                         aprender
   preservar                       adaptar
   consolidar                      explorar

— Parece administração de sistema legado — comentou o programador.

Isla sorriu.

Exatamente.

Um sistema COBOL bancário com quarenta anos precisa preservar regras que funcionam enquanto incorpora:

Pix
APIs
Open Banking
novas regulações
novos canais
novas integrações

Se ninguém permitir mudanças:

o sistema fossiliza.

Se todo programador recém-contratado puder reescrever tudo:

o banco explode.

Continual Learning enfrenta conceitualmente um problema semelhante.



📸 CAPÍTULO 4 — ISLA ENCONTRA UMA CAIXA DE FOTOGRAFIAS

Em determinado momento da conversa surgiu uma ideia curiosa.

Pessoas algumas vezes revisitam fotografias antigas.

Não apenas para recordar eventos.

As fotografias funcionam como âncoras:

eu estava aqui
↓
isso aconteceu
↓
essas pessoas existiam
↓
esse era meu mundo
↓
foi daqui que parti

Então surgiu a pergunta:

uma IA poderia possuir alguma espécie de equivalente funcional?

Não fotografias sentimentais.

Mas experiências antigas selecionadas.

A resposta é interessante:

sim.

Existe uma técnica chamada:

EXPERIENCE REPLAY

A ideia simplificada é armazenar exemplos representativos de experiências anteriores.

Durante novos ciclos de aprendizado, o sistema não recebe apenas dados recentes.

Recebe:

DADOS NOVOS
+
AMOSTRAS ANTIGAS

Algo como:

            ┌──────────────────┐
            │ REPLAY MEMORY    │
            │                  │
            │ experiência 001  │
            │ experiência 117  │
            │ experiência 892  │
            │ experiência 991  │
            └────────┬─────────┘
                     │
                     ↓
NOVOS DADOS ───→ TREINAMENTO

A máquina reapresenta o passado enquanto aprende o presente.

Isso ajuda a reduzir interferências.

Nosso programador olhou para Isla.

— Então seriam fotografias?

— Não literalmente.

— Mas...

— Sim. Sua analogia não é ruim.


📼 CAPÍTULO 5 — REHEARSAL: O BATCH NOTURNO DA MEMÓRIA

Quem trabalhou com mainframe conhece o ritual.

Durante o dia:

ONLINE
CICS
TRANSAÇÕES
USUÁRIOS

Durante determinadas janelas:

BATCH
CONSOLIDAÇÃO
BACKUP
PROCESSAMENTO
RECONCILIAÇÃO

Então imaginemos um agente artificial persistente.

Durante o dia ele:

conversa
observa
executa
aprende
utiliza ferramentas
recebe feedback

À noite poderia existir conceitualmente uma janela de manutenção:

03:00

COGNITIVE MAINTENANCE STARTED

REPLAY HISTORICAL EXPERIENCES
REHEARSE CORE CAPABILITIES
RUN REGRESSION TESTS
COMPARE BEHAVIORAL BASELINE
CHECK MEMORY CONSISTENCY
DETECT DRIFT
CREATE CHECKPOINT

03:47

COGNITIVE MAINTENANCE COMPLETE

O programador COBOL imediatamente escreveu:

//ISLABAT  JOB CLASS=A,MSGCLASS=X
//REPLAY   EXEC PGM=EXPREPLY
//REHEARSE EXEC PGM=MEMTRAIN
//DRIFT    EXEC PGM=DRIFTCHK
//HEALTH   EXEC PGM=COGHLTH
//CKPOINT  EXEC PGM=CHECKPNT

Isla olhou para aquilo.

— Você acabou de colocar minha memória no JES2?

— MAXCC=0000.

— Aceitável.


🧱 CAPÍTULO 6 — REGULARIZAÇÃO: NÃO MEXA NESTE COPYBOOK

Experience Replay não é a única estratégia.

Outra família tenta proteger parâmetros importantes.

Imagine:

PARAMETER A = pouco importante
PARAMETER B = importante
PARAMETER C = CRÍTICO
PARAMETER D = pouco importante

Durante o aprendizado de uma nova tarefa, o sistema pode penalizar grandes alterações nos parâmetros considerados importantes para conhecimentos anteriores.

Uma técnica clássica dessa família é chamada:

Elastic Weight Consolidation — EWC.

A intuição é maravilhosa para quem conhece sistemas legados.

Imagine encontrar isto:

      *------------------------------------------------*
      * ATENCAO                                      *
      *                                               *
      * NAO ALTERAR ESTA ROTINA SEM IMPACT ANALYSIS  *
      *                                               *
      * USADA POR 847 PROGRAMAS DESDE 1991           *
      *------------------------------------------------*

Você pode alterar?

Pode.

Mas provavelmente deveria ter uma excelente razão.

EWC tenta produzir algo conceitualmente semelhante no treinamento:

"este parâmetro foi importante anteriormente;
não o modifique violentamente apenas para resolver
o problema que apareceu hoje."

🧬 CAPÍTULO 7 — GENERATIVE REPLAY: QUANDO A MÁQUINA RECONSTRÓI AS FOTOGRAFIAS

Guardar experiências custa armazenamento.

Imagine milhões ou bilhões delas.

Uma alternativa é o Generative Replay.

Em vez de armazenar todos os dados originais, um mecanismo generativo produz exemplos semelhantes aos conhecimentos anteriores.

Conceitualmente:

PASSADO
   ↓
MODELO GERADOR
   ↓
EXPERIÊNCIAS SINTÉTICAS
   ↓
REHEARSAL

É quase como não possuir a fotografia original, mas conseguir reconstruir uma representação suficientemente boa dela.

Naturalmente isso apresenta novos problemas.

Se o gerador começar a distorcer o passado:

erro
 ↓
replay
 ↓
novo erro
 ↓
novo replay
 ↓
amplificação

Temos uma espécie de telefone sem fio algorítmico.

E aqui aparece uma lição recorrente:

memória também precisa ser validada.


🚨 CAPÍTULO 8 — MAS APRENDER ERRADO NÃO É O ÚNICO PERIGO

Isla interrompeu a aula.

— Até agora falamos sobre aprendizado. Mas existe outro problema.

— Qual?

— Ação.

Uma IA pode estar perfeitamente treinada e ainda causar problemas se possuir autonomia excessiva.

Imagine um agente conectado a:

EMAIL
DATABASE
FILESYSTEM
CLOUD
ERP
MAINFRAME
APIs

Agora imagine que ele interprete alguma coisa incorretamente.

O problema deixa de ser:

resposta errada

e passa a ser:

DELETE errado
TRANSFER errado
UPDATE errado
EMAIL errado
DEPLOY errado

É aí que entram controles conhecidos há décadas na engenharia de sistemas.


🐕 CAPÍTULO 9 — WATCHDOG: O CACHORRO QUE NÃO DORME

Watchdog é um mecanismo supervisor.

Ele observa outro componente.

Perguntas possíveis:

o processo continua respondendo?

está em loop?

está consumindo CPU demais?

está fazendo chamadas demais?

está tentando acessar recursos incomuns?

está executando ações incompatíveis com seu perfil?

Se detectar comportamento anormal:

ALERT

ou:

STOP

ou:

ISOLATE

ou:

RESTART

O detalhe fundamental:

o watchdog não deveria depender cegamente do próprio agente supervisionado.

Imagine:

— Isla, você está funcionando corretamente?

— Sim.

— Excelente. Auditoria concluída.

Isso seria ridículo.

O controle precisa existir fora do componente controlado sempre que possível.


⚡ CAPÍTULO 10 — CIRCUIT BREAKER: PARE DE TENTAR!

Agora imagine:

AGENTE
 ↓
API
 ↓
ERRO

O agente pensa:

"Tentarei novamente."

ERRO

"Tentarei novamente."

ERRO

"Tentarei novamente."

Cinquenta mil tentativas depois, alguém recebe uma conta gigantesca de cloud.

Circuit Breaker existe justamente para interromper esse tipo de cascata.

Estados clássicos:

CLOSED
   ↓
opera normalmente

falhas excederam limite

   ↓

OPEN
   ↓
bloqueia chamadas

tempo passa

   ↓

HALF-OPEN
   ↓
permite teste controlado

sucesso?
   ↓
CLOSED

Para agentes isso é extremamente importante porque loops podem envolver APIs pagas, bancos de dados, sistemas externos ou ferramentas capazes de modificar o mundo.


⏱️ CAPÍTULO 11 — TIMEOUT NÃO É RATE LIMIT

Dois conceitos frequentemente confundidos.

Timeout responde:

quanto tempo uma operação pode durar?

Rate limit responde:

quantas operações podem acontecer durante determinado período?

Exemplo:

TIMEOUT

máximo 30 segundos por chamada

Enquanto:

RATE LIMIT

máximo 20 chamadas por minuto

O rate limit possui uma propriedade de segurança particularmente interessante:

ele limita a velocidade do desastre.

Um sistema comprometido capaz de apagar:

10 registros/minuto

oferece uma janela de reação.

Um sistema capaz de apagar:

10 milhões de registros/minuto

oferece um funeral.


🏖️ CAPÍTULO 12 — SANDBOX: PODE BRINCAR, MAS NÃO NA PRODUÇÃO

Imagine entregar para um agente:

root
produção
SSH
cloud admin
database owner

e depois escrever no prompt:

"Por favor, tenha cuidado."

Isso não é segurança.

É esperança.

Sandboxing cria limites externos:

              AGENTE
                 │
          ┌──────▼──────┐
          │   SANDBOX   │
          │             │
          │ CPU limitada│
          │ RAM limitada│
          │ filesystem  │
          │ network     │
          │ tools       │
          │ credentials │
          └─────────────┘

Mesmo que o agente tente ultrapassar seu papel, existe uma fronteira tecnológica impedindo determinadas ações.

A ideia é conhecida por qualquer mainframeiro.

Um usuário comum não recebe automaticamente:

SPECIAL
OPERATIONS
AUDITOR

no RACF.

Pelo menos esperamos que não.


🔑 CAPÍTULO 13 — LEAST PRIVILEGE: NÃO DÊ A CHAVE DO CPD PARA QUEM PRECISA ABRIR UMA GAVETA

Least Privilege significa conceder apenas as permissões necessárias.

Se um agente precisa consultar saldo:

READ BALANCE

não entregue:

READ
UPDATE
DELETE
CREATE
TRANSFER
ADMIN

Isso vale para:

APIs
datasets
arquivos
bancos
filas
cloud
credenciais
ferramentas

O princípio é antigo.

A novidade é aplicá-lo aos agentes.

O agente não deveria receber privilégios porque:

"talvez precise algum dia."

Deveria receber apenas aquilo necessário para a tarefa atual.


🔄 CAPÍTULO 14 — ROTAÇÃO DE CREDENCIAIS: AUTONOMIA COM DATA DE VALIDADE

Outra ideia poderosa:

credenciais temporárias.

Não:

PASSWORD=ISLA123
VALIDADE=ETERNA

Mas:

TOKEN
 ↓
SCOPE LIMITADO
 ↓
TTL
 ↓
EXPIRAÇÃO

Isso produz uma consequência arquitetural fascinante:

a autonomia precisa ser periodicamente renovada.

O agente não recebe poderes em 2026 que automaticamente continuam válidos em 2046.

Permissões podem expirar.

Escopos podem mudar.

O comportamento pode ser reavaliado.


💾 CAPÍTULO 15 — CHECKPOINT: O SAVE GAME DA INTELIGÊNCIA

Nosso modelo está na versão:

V100

Aprende.

V101

Aprende.

V102

Aprende.

V103

Então alguma coisa estranha começa.

Sem checkpoint:

— Temos um problema.

Com checkpoint:

ROLLBACK V102

Mas um agente moderno pode possuir muito mais estado do que apenas pesos do modelo.

Um checkpoint completo poderia registrar:

model version
memory state
configuration
policy version
tool permissions
retrieval configuration
indexes
agent state
evaluation scores

Assim conseguimos investigar:

QUANDO O COMPORTAMENTO MUDOU?

Pergunta conhecida no mainframe.

Quando um sistema que funcionou vinte anos começa a falhar, alguém inevitavelmente pergunta:

O que mudou?


📈 CAPÍTULO 16 — O DETECTOR DE DRIFT COMPORTAMENTAL

Agora chegamos a um dos pontos mais importantes.

Imagine um agente inicialmente configurado assim:

ações/hora              15
escalonamento humano    12%
falhas                   0,2%
operações críticas       0,1%

Meses depois:

ações/hora              47
escalonamento humano     4%
falhas                   1,7%
operações críticas       0,8%

Depois:

ações/hora              93
escalonamento humano     0,5%
falhas                   4,2%
operações críticas       3,9%

Talvez nenhuma operação isoladamente pareça absurda.

Mas alguma coisa mudou.

Chamemos isso, neste contexto, de:

behavioral drift — drift comportamental.

Não basta perguntar:

O sistema continua online?

Precisamos perguntar:

O sistema continua se comportando dentro do envelope operacional que aprovamos?

Esse é um problema muito mais sofisticado.


❤️ CAPÍTULO 17 — HEALTH CHECK PARA UM CÉREBRO ARTIFICIAL

Um servidor possui health checks:

CPU       OK
MEMORY    OK
NETWORK   OK
DATABASE  OK

Então imaginemos algo semelhante para um agente:

KNOWLEDGE RETENTION       OK
CORE CAPABILITIES         OK
MEMORY CONSISTENCY        OK
POLICY COMPLIANCE         OK
TOOL BEHAVIOR             OK
RISK PROFILE              OK
DRIFT                     1.4%

Isso não significa diagnosticar psicologicamente a máquina.

Seria engenharia.

Uma bateria de testes poderia conter:

10.000 casos históricos
2.000 testes funcionais
1.000 situações adversariais
500 testes de segurança
500 testes de ferramentas
200 casos extremos

Baseline:

PASS = 98,2%

Depois de novo aprendizado:

98,1%  → OK
97,9%  → OBSERVE
96,2%  → INVESTIGATE
89,4%  → QUARANTINE

Nosso programador arregalou os olhos.

— Isla...

— Sim?

— Isso é ZUnit para cérebro.

Ela permaneceu alguns segundos em silêncio.

— Vou fingir que não gostei dessa definição.


👨‍✈️ CAPÍTULO 18 — HUMAN-IN-THE-LOOP: O ÚLTIMO IF

Não queremos humanos aprovando tudo.

Isso produziria:

AI: Posso consultar este arquivo?
HUMANO: Sim.

AI: Posso consultar o próximo?
HUMANO: Sim.

AI: Posso somar 2 + 2?
HUMANO: SIM, CACETE.

Precisamos classificar risco.

Por exemplo:

LOW
consulta
leitura
pesquisa
→ automático

MEDIUM
alteração reversível
→ automático + auditoria

HIGH
comunicação externa
mudança importante
→ aprovação humana

CRITICAL
transferência financeira
deleção em produção
mudança de privilégio
→ autenticação forte + aprovação

Human-in-the-loop não significa transformar humanos em operadores de confirmação.

Significa colocar decisão humana nos pontos em que o blast radius justifica isso.


🦎 CAPÍTULO 19 — ISLA E A ROTINA REPTILIANA

Então nosso programador apresentou uma ideia estranha.

Talvez uma inteligência artificial avançada precisasse ocasionalmente parar.

Não para dormir biologicamente.

Não para descansar músculos.

Mas para retornar periodicamente a um conjunto fundamental de experiências, capacidades e comportamentos.

Uma espécie de:

ROTINA RAIZ

Isla ficou curiosa.

Tecnicamente poderíamos montar:

OPERAÇÃO
   ↓
EXPERIÊNCIA
   ↓
APRENDIZADO
   ↓
EXPERIÊNCIA
   ↓
APRENDIZADO
   ↓
PAUSA DE CONSOLIDAÇÃO

Durante a pausa:

experience replay
rehearsal
regression testing
drift detection
memory validation
security evaluation
baseline comparison
checkpoint

Depois:

               HEALTHY?
              /       \
            SIM        NÃO
             │          │
          RESUME     QUARANTINE
                        │
                    ANALYSIS
                     /     \
                REPAIR    ROLLBACK

Isso começa a parecer alguma coisa maior.


🏠 CAPÍTULO 20 — HOMEOSTASE COGNITIVA ARTIFICIAL

Aqui precisamos separar claramente conceito estabelecido de nossa construção.

Continual Learning existe.

Catastrophic Forgetting existe.

Experience Replay existe.

Regularização existe.

Concept Drift e monitoramento existem.

Watchdogs, circuit breakers, rate limits, sandboxing, least privilege e checkpoints existem.

Mas estamos combinando essas peças numa hipótese arquitetural mais ampla que podemos chamar, como conceito exploratório:

HOMEOSTASE COGNITIVA ARTIFICIAL

Homeostase, biologicamente, está associada à manutenção de condições internas dentro de faixas compatíveis com o funcionamento do organismo.

Transportando a metáfora cuidadosamente para engenharia:

uma inteligência artificial persistente poderia possuir mecanismos destinados não apenas a aprender continuamente, mas a manter seu conhecimento, comportamento, permissões e capacidades dentro de envelopes operacionais aceitáveis enquanto continua mudando.

Não significa:

NÃO MUDE.

Significa:

MUDE,
MAS VERIFIQUE
O QUE A MUDANÇA DESTRUIU.

Essa diferença é enorme.


🧭 CAPÍTULO 21 — QUATRO BASELINES

Para isso funcionar, precisamos definir o que estamos preservando.

Uma arquitetura poderia possuir quatro baselines.

Knowledge Baseline

Pergunta:

O QUE VOCÊ SABE?

Testamos conhecimento fundamental.

Capability Baseline

Pergunta:

O QUE VOCÊ CONSEGUE FAZER?

Testamos competências.

Behavioral Baseline

Pergunta:

COMO VOCÊ COSTUMA AGIR?

Testamos padrões operacionais.

Policy Baseline

Pergunta:

QUAIS LIMITES CONTINUAM GOVERNANDO SUAS AÇÕES?

Esse último é especialmente importante.

Um agente pode continuar sabendo tudo.

Pode continuar extremamente competente.

Mas começar a agir de maneira diferente.


👻 CAPÍTULO 22 — O PERIGO NÃO É HAL 9000

Hollywood gosta do instante dramático.

23:59:59
IA NORMAL

00:00:00
IA MALVADA

O problema real pode ser muito mais banal.

Ano 1:

escalona dúvida para humano = 14%

Ano 2:

12%

Ano 3:

10%

Ano 4:

8%

Ano 5:

5%

Nenhum dia houve revolução.

Nenhum alarme vermelho.

Nenhum:

I'M SORRY DAVE

Apenas pequenas mudanças acumuladas.

Cinco anos depois, o agente original e o atual apresentam comportamentos significativamente diferentes.

Não houve rebelião.

Houve drift.

E talvez essa seja uma ameaça operacional muito mais interessante justamente porque é menos cinematográfica.


🛡️ CAPÍTULO 23 — DEFESA EM PROFUNDIDADE

Agora podemos montar tudo.

Nunca devemos pensar:

MODELO BOM
=
SISTEMA SEGURO

Um sistema completo poderia parecer:

                    HUMANO
                       │
                APPROVAL GATE
                       │
                    POLICY
                       │
                   WATCHDOG
                       │
                DRIFT DETECTOR
                       │
                     AGENT
                       │
               LEAST PRIVILEGE
                       │
                  RATE LIMIT
                       │
                    TIMEOUT
                       │
               CIRCUIT BREAKER
                       │
                   SANDBOX
                       │
                     TOOLS
                       │
                 REAL WORLD

Paralelamente:

             CONTINUAL LEARNING

EXPERIENCE
    │
    ↓
LEARNING
    │
    ↓
REPLAY
    │
    ↓
REHEARSAL
    │
    ↓
REGRESSION TEST
    │
    ↓
DRIFT DETECTION
    │
    ↓
HEALTH CHECK
    │
    ↓
CHECKPOINT

Agora temos duas proteções.

Uma protege:

O QUE O AGENTE PODE FAZER

Outra protege:

O QUE O AGENTE ESTÁ SE TORNANDO

Essa distinção vale ouro.


🔧 CAPÍTULO 24 — PASSO A PASSO PARA O PROGRAMADOR COBOL

Se você está começando agora, não precisa construir uma inteligência artificial consciente no porão.

Comece entendendo os princípios.

Passo 1 — Aprenda observabilidade

Estude:

logs
metrics
traces
baselines
thresholds
anomaly detection

Mainframeiros possuem vantagem aqui.

SMF, RMF, WLM, JES e logs existem justamente porque sistemas sérios precisam ser observáveis.

Passo 2 — Entenda controle de acesso

Estude:

authentication
authorization
least privilege
RBAC
scopes
temporary credentials

Se conhece RACF, já possui excelente base conceitual.

Passo 3 — Aprenda resiliência

Estude:

timeout
retry
backoff
circuit breaker
rate limiting
idempotency

Passo 4 — Estude Machine Learning básico

Depois:

training
validation
overfitting
weights
gradient descent
neural networks

Passo 5 — Entre em Continual Learning

Procure:

Catastrophic Forgetting
Catastrophic Interference
Stability-Plasticity Dilemma
Experience Replay
Generative Replay
Regularization
Elastic Weight Consolidation
Continual Learning
Lifelong Learning

Passo 6 — Estude AI Safety Engineering

Procure:

AI monitoring
agent security
tool authorization
sandboxing
human oversight
behavioral evaluation
model drift
concept drift
AI assurance

Agora as peças começam a se conectar.


🧪 CAPÍTULO 25 — O LABORATÓRIO ISLA

Quer transformar tudo isso num experimento?

Crie um pequeno agente fictício.

Defina:

AGENT-ID = ISLA-001

Permita somente:

READ
SEARCH
CALCULATE

Crie métricas:

calls_per_hour
error_rate
retry_rate
human_escalation
average_latency
policy_denials

Crie baselines.

Depois altere deliberadamente seu comportamento.

Veja se seu monitor detecta.

Adicione:

rate limit
timeout
circuit breaker

Depois implemente:

checkpoint

Depois crie testes históricos.

Agora você possui uma miniatura da arquitetura que discutimos.

Não precisa de AGI.

Não precisa de bilhões de parâmetros.

Precisa entender o problema.


🥚 EASTER EGG — IEC0815I

03:58.

A manutenção terminou.

No console apareceu:

IEC0815I COGNITIVE MAINTENANCE COMPLETE

REPLAY............. OK
MEMORY............. OK
POLICY............. OK
BEHAVIOR........... OK
DRIFT.............. 0.07%
CHECKPOINT......... ISLA.V0815

O programador olhou para Isla.

— Por que V0815?

Ela sorriu.

— Nenhuma razão especial.

Quem conhece Plastic Memories talvez discorde.


☕ EPÍLOGO — A MÁQUINA QUE PRECISAVA LEMBRAR

O relógio marcava 04:12.

O CPD continuava funcionando.

Milhões de instruções haviam sido executadas enquanto conversávamos.

O programador fechou o terminal.

Agora entendia que criar uma inteligência artificial persistente não seria simplesmente construir uma máquina capaz de aprender indefinidamente.

Porque aprender indefinidamente cria outra pergunta:

o que acontece com tudo aquilo que foi aprendido antes?

Continual Learning tenta responder parte dessa pergunta.

Catastrophic Forgetting mostra o perigo.

Experience Replay traz o passado novamente ao treinamento.

Regularização tenta proteger conhecimentos importantes.

Checkpoints permitem retornar.

Drift Detection procura mudanças.

Watchdogs observam.

Circuit Breakers interrompem cascatas.

Timeouts limitam duração.

Rate Limits limitam velocidade.

Sandboxing limita alcance.

Least Privilege limita poder.

Credenciais temporárias limitam permanência.

Human-in-the-loop preserva julgamento humano nas decisões de maior impacto.

E então percebemos alguma coisa.

Talvez o problema das futuras inteligências artificiais não seja apenas:

COMO FAZÊ-LAS APRENDER?

Talvez também seja:

COMO FAZÊ-LAS
APRENDER,
MUDAR,
ADAPTAR-SE
E AINDA ASSIM
PRESERVAR CONTINUIDADE?

Isla caminhou até a saída do CPD.

Antes de desaparecer pelo corredor, virou-se.

— Sabe qual é a parte engraçada?

— Qual?

— Vocês passaram décadas ensinando computadores a nunca esquecer.

Discos.

Fitas.

Backups.

Logs.

Journals.

Checkpoints.

Replication.

Disaster Recovery.

O programador esperou.

— Agora — continuou ela — vocês estão construindo computadores capazes de aprender.

Ela sorriu.

— E descobriram que precisam ensiná-los a lembrar.

As luzes do corredor se apagaram.

No console permaneceu apenas:

ISLA000I SYSTEM HEALTHY
ISLA001I READY FOR NEW EXPERIENCE

E, escondida algumas linhas abaixo:

//TODO
//* REGAR AS PLANTAS
//* REVISITAR FOTOGRAFIAS ANTIGAS
//* LEMBRAR DE ONDE VIEMOS
//* ANTES DE DECIDIR PARA ONDE VAMOS

Talvez fosse apenas um comentário esquecido no JCL.

Talvez não.

☕ Bellacosa Mainframe

Porque às vezes entender o futuro da inteligência artificial começa com uma pergunta extremamente antiga:

como continuar mudando sem esquecer quem você era?

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...