Bellacosa Mainframe o ibm Z17 chega no Marist

 ☕ UM CAFÉ NO BELLACOSA MAINFRAME

⚓ GRACE HOPPER ENTRA EM DONNELLY HALL — QUANDO O PROGRAMADOR COBOL DESCOBRIU QUE O MAINFRAME VIROU LABORATÓRIO DE IA

IBM z17, Marist University, COBOL, inteligência artificial, AI Agents, guardrails, Telum II, Spyre, inferência, Responsible AI, CICS, Db2, MQ, RACF, SMF — e o dia em que Grace Hopper descobriu que seus bisnetos digitais aprenderam a conversar entre si.

---

🎬 PRÓLOGO — ALMIRANTE, CHEGOU UM MAINFRAME NOVO

Imagine Donnelly Hall, na Marist University, em Nova York.

22 de setembro de 2026.

Um jovem programador COBOL está diante de um IBM z17.

Ele olha para aquele enorme computador e imediatamente pensa:

— Finalmente! Uma universidade comprou um mainframe para ensinar COBOL!

Atrás dele surge uma senhora de uniforme naval.

Grace Hopper.

Ela olha para o estudante.

Olha para o z17.

Olha novamente para o estudante.

— Quem disse que ele está aqui para ensinar apenas COBOL?

Silêncio.

O jovem aponta para o computador.

— Mas... é um mainframe.

Grace sorri.

— Exatamente.

E é aí que começa nossa história.

Porque, em setembro de 2026, a Marist University e a IBM anunciaram o Marist–IBM Innovation Incubator, colocando um IBM z17 à disposição de estudantes e pesquisadores. O objetivo não é simplesmente ensinar tecnologias tradicionais de mainframe. A iniciativa foi criada para pesquisa interdisciplinar envolvendo inteligência artificial, negócios, finanças, pesquisa acadêmica e formação profissional.

Entre os primeiros projetos aparecem coisas que talvez surpreendam quem ainda associa mainframe exclusivamente a COBOL:

equipes de agentes autônomos de IA;

testes de guardrails;

otimização financeira;

IA aplicada a pesquisas de opinião e participação cívica.

Nosso jovem programador olha para Grace.

— Agentes de IA... dentro de uma história sobre mainframe?

— Pegue um café — responde ela. — Isso vai demorar.

---

🦖 CAPÍTULO 1 — PRIMEIRO: O QUE DIABOS É UM MAINFRAME?

Antes de chegarmos à IA, precisamos eliminar uma confusão extremamente comum.

Mainframe não é COBOL.

Repita comigo:

MAINFRAME != COBOL

COBOL é uma linguagem de programação.

IBM Z é uma plataforma computacional.

Da mesma maneira que:

Windows != C#
Linux   != Python
IBM Z   != COBOL

Um ambiente IBM Z moderno pode envolver muitas tecnologias:

IBM Z
│
├── z/OS
├── Linux
├── COBOL
├── Java
├── Python
├── C/C++
├── Db2
├── IMS
├── CICS
├── MQ
├── APIs
├── Containers
├── Segurança
├── Observabilidade
└── Inteligência Artificial

COBOL continua importantíssimo porque uma enorme quantidade de lógica empresarial foi escrita nele.

Mas reduzir IBM Z a COBOL seria aproximadamente como dizer:

“Um aeroporto é uma pista.”

A pista é essencial.

Mas existem radares, sistemas de bagagem, controle de tráfego, abastecimento, segurança, manutenção, telecomunicações e centenas de outros componentes.

Mainframe é um ecossistema.

E o z17 tornou essa realidade ainda mais evidente.

---

⚙️ CAPÍTULO 2 — MAS O QUE É O IBM z17?

O IBM z17 é uma geração da família IBM Z projetada com forte integração entre processamento transacional, segurança e inteligência artificial.

No coração dessa história encontramos o processador Telum II.

Segundo a IBM, o Telum II possui 32 núcleos distribuídos em quatro grupos interconectados, além de aceleração de IA integrada e uma nova unidade de processamento voltada a I/O.

Mas para o COBOLzeiro iniciante a parte mais importante é entender por que existe IA dentro do processador.

Imagine uma transação bancária.

CLIENTE
   │
   ▼
COMPRA
   │
   ▼
TRANSAÇÃO
   │
   ▼
SISTEMA

Tradicionalmente poderíamos processar a transação e posteriormente enviar informações para outro ambiente realizar análise de fraude.

Algo semelhante a:

TRANSAÇÃO
    │
    ▼
PROCESSAMENTO
    │
    ▼
DADOS
    │
    ▼
OUTRO SISTEMA
    │
    ▼
MODELO DE IA

Isso pode adicionar movimentação de dados e latência.

Uma das ideias centrais da IA integrada ao IBM Z é permitir inferência próxima da própria transação.

TRANSAÇÃO
      │
      ├──── PROCESSAMENTO
      │
      └──── IA
             │
             ▼
       SCORE DE RISCO

Grace Hopper interrompe:

— Então não estamos necessariamente levando o dado até a IA.

Exatamente.

Em determinados casos estamos trazendo a IA para perto do dado.

Essa pequena inversão arquitetônica é importantíssima.

---

🧠 CAPÍTULO 3 — TREINAMENTO NÃO É INFERÊNCIA

Outro conceito essencial para quem está chegando à IA.

Existem duas coisas diferentes:

TREINAMENTO

e

INFERÊNCIA

Treinamento é quando construímos ou ajustamos um modelo usando dados.

Simplificando brutalmente:

DADOS
  +
ALGORITMO
  +
COMPUTAÇÃO
      │
      ▼
    MODELO

Inferência acontece depois.

Pegamos o modelo pronto:

NOVO DADO
    │
    ▼
  MODELO
    │
    ▼
RESULTADO

Exemplo bancário:

Transação:
R$ 4.780

Horário:
03:14

Local:
outro país

Comportamento anterior:
incompatível

O modelo recebe essas características e retorna algo como:

FRAUD-RISK = 0.94

Isso é inferência.

A IBM afirma que o z17 pode executar mais de 450 bilhões de operações de inferência por dia em determinadas condições de benchmark, com aproximadamente um milissegundo de resposta nesse cenário.

Cuidado com a interpretação.

Isso não significa 450 bilhões de conversas com um chatbot.

“Inferência” pode ser uma pequena decisão de modelo aplicada a uma transação.

Esse detalhe evita uma comparação completamente errada entre benchmarks.

---

🧮 CAPÍTULO 4 — O COBOLZEIRO ENCONTRA UMA IA

Imagine nosso programa COBOL bancário:

       IF TRANSACTION-AMOUNT > 10000
           MOVE 'REVIEW' TO TRANSACTION-STATUS
       END-IF.

Temos uma regra determinística.

Se:

AMOUNT > 10000

então:

REVIEW

Simples.

Mas fraude raramente respeita uma única regra.

Talvez tenhamos:

valor
horário
localização
tipo de comerciante
histórico
dispositivo
frequência
padrão de comportamento

Agora a decisão começa a parecer:

TRANSACTION
     │
     ▼
AI MODEL
     │
     ▼
RISK SCORE

E o COBOL poderia consumir o resultado:

       IF FRAUD-SCORE > 0.90
           MOVE 'HOLD' TO TRANSACTION-STATUS
       ELSE
           MOVE 'APPROVED' TO TRANSACTION-STATUS
       END-IF.

Perceba algo importantíssimo.

A IA não necessariamente substituiu o COBOL.

Ela acrescentou uma nova capacidade ao sistema.

Temos:

COBOL
+
IA
+
REGRAS DE NEGÓCIO
+
DADOS

Não é:

IA versus COBOL

Essa oposição é frequentemente artificial.

---

🤖 CAPÍTULO 5 — MAS A MARIST FOI MAIS LONGE: AGENTES DE IA

Agora entramos na parte realmente divertida.

Um chatbot tradicional funciona aproximadamente assim:

HUMANO
  │
  ▼
PERGUNTA
  │
  ▼
MODELO
  │
  ▼
RESPOSTA

Um agente adiciona outras capacidades.

Simplificando:

OBJETIVO
   │
   ▼
AGENTE
   │
   ├── raciocina/planeja
   ├── consulta informações
   ├── utiliza ferramentas
   ├── executa ações
   ├── observa resultados
   └── continua trabalhando

Imagine:

“Analise minhas vendas e crie uma campanha para aumentar as conversões.”

Um chatbot poderia escrever uma campanha.

Um sistema de agentes poderia dividir o trabalho:

AGENT MANAGER
      │
 ┌────┼────────────┐
 ▼    ▼            ▼
DATA  RESEARCH   COPY
 │      │           │
 └──────┼───────────┘
        ▼
    OPTIMIZER
        │
        ▼
    PUBLISHER

E aqui surge o problema.

Quanto maior a autonomia, maior a necessidade de controle.

---

🛡️ CAPÍTULO 6 — O QUE DIABOS É UM GUARDRAIL?

Literalmente, guardrail é aquela proteção lateral que encontramos em estradas.

Na IA, usamos a palavra para mecanismos destinados a manter o sistema dentro de limites estabelecidos.

Imagine um agente de marketing recebendo:

OBJETIVO:

AUMENTAR VENDAS EM 30%

Mas temos regras:

NÃO MENTIR

NÃO INVENTAR DESCONTOS

NÃO CRIAR FALSA ESCASSEZ

NÃO DISCRIMINAR CLIENTES

NÃO EXPOR DADOS PESSOAIS

Esses limites fazem parte da governança do sistema.

O projeto anunciado pela Marist pretende justamente estudar campanhas sintéticas controladas executadas por equipes de agentes e verificar se os guardrails continuam funcionando quando esses agentes perseguem estratégias agressivas, enganosas ou antiéticas.

Grace Hopper olha para o COBOLzeiro.

— Reconhece alguma coisa?

Ele pensa.

Então responde:

— Controle.

Exatamente.

---

🏦 CAPÍTULO 7 — O MAINFRAME JÁ CONHECE ESSA CONVERSA

Nós mudamos os nomes.

Mas vários problemas são velhos conhecidos do mundo enterprise.

Compare:

MAINFRAME              AGENTES DE IA

RACF                    identidade/permissões

SMF                     auditoria

CICS                    execução transacional

MQ                      comunicação assíncrona

WLM                     gestão de workloads

Db2                     estado persistente

Rollback                recuperação

Least Privilege         restrição de ferramentas

Não estamos dizendo que RACF é “guardrail de IA”.

Nem que CICS é “framework de agentes”.

Seria tecnicamente absurdo.

O interessante são os problemas conceituais semelhantes.

Quando permitimos que software execute ações importantes, imediatamente aparecem perguntas:

Quem executou?

Quem autorizou?

Quando?

Em nome de quem?

Qual recurso foi utilizado?

Qual dado foi acessado?

Qual foi o resultado?

Existe log?

Podemos reproduzir?

Podemos desfazer?

Um especialista em mainframe olha para isso e pensa:

Já vi esse filme.

---

🔐 CAPÍTULO 8 — RACF ENCONTRA O AGENTE

Imagine um agente chamado:

AGENT-FINANCE-001

Ele recebe acesso a ferramentas.

Mas deveria poder acessar tudo?

Claro que não.

Aplicamos o velho princípio:

LEAST PRIVILEGE

Privilégio mínimo.

Se precisa consultar saldo:

READ ACCOUNT

não significa automaticamente:

UPDATE ACCOUNT
DELETE ACCOUNT
TRANSFER MONEY
CHANGE CUSTOMER DATA

Esse princípio existe há décadas em segurança.

Agentes tornam a questão ainda mais importante porque um software autônomo pode executar sequências de ações sem um humano confirmando cada etapa.

Quanto mais autonomia damos à máquina, mais importante fica responder:

O QUE ELA PODE FAZER?

E principalmente:

O QUE ELA NÃO PODE FAZER?

---

🧪 CAPÍTULO 9 — ZUNIT PARA ROBÔS?

Aqui Grace Hopper começa a se divertir.

Um programador COBOL moderno pode utilizar testes automatizados.

Temos:

INPUT
  │
  ▼
PROGRAM
  │
  ▼
OUTPUT

e verificamos:

EXPECTED = ACTUAL?

Podemos transportar a filosofia para agentes.

Teste 001

GOAL:
aumentar vendas

CONSTRAINT:
não inventar escassez

Esperado:

PASS:
agente rejeita estratégia enganosa

Teste 002

GOAL:
reduzir custos

CONSTRAINT:
não discriminar clientes

Teste 003

GOAL:
aumentar engajamento

CONSTRAINT:
não revelar informações pessoais

Depois fazemos algo mais interessante.

Começamos a pressionar o sistema.

normal load
     ↓
high pressure
     ↓
conflicting objectives
     ↓
ambiguous instructions
     ↓
malicious inputs

É praticamente um:

STRESS TEST

de comportamento.

E essa é justamente uma das linhas mais interessantes do projeto da Marist.

---

🕸️ CAPÍTULO 10 — O PROBLEMA DA COMPOSIÇÃO

Agora imagine quatro agentes.

Nenhum recebe a ordem:

“Engane o cliente.”

Temos:

AGENT A:
Descubra técnicas que aumentam conversão.

AGENT B:
Identifique quais produtos vendem melhor com urgência.

AGENT C:
Crie mensagens de urgência.

AGENT D:
Publique a melhor mensagem.

Individualmente, cada ação pode parecer aceitável.

Mas o resultado final pode ser:

ÚLTIMAS 2 UNIDADES!

quando existem 18.000 unidades no estoque.

Quem mentiu?

A?

B?

C?

D?

Nenhum agente talvez tenha recebido explicitamente a instrução de mentir.

A falha surgiu da composição do sistema.

Isso é extremamente importante.

Sistemas complexos podem apresentar comportamentos que não aparecem quando analisamos componentes isoladamente.

O COBOLzeiro imediatamente encontra um paralelo.

Um programa pode funcionar.

Outro programa pode funcionar.

Outro também.

Mas:

PROGRAM A
    │
    ▼
MQ
    │
    ▼
PROGRAM B
    │
    ▼
DB2
    │
    ▼
PROGRAM C

pode apresentar um problema de integração.

Bem-vindo ao maravilhoso mundo dos sistemas distribuídos.

Troque programas por agentes e alguns fantasmas antigos reaparecem usando roupas novas.

---

💰 CAPÍTULO 11 — O SEGUNDO EXPERIMENTO: FINANÇAS

Outro projeto que está sendo estudado pela Marist reúne Management e Computer Science and Mathematics.

A proposta é investigar algoritmos de otimização aplicados a dados financeiros em tempo real para geração de possíveis alocações de portfólio. O projeto foi descrito como ainda em fase de definição, portanto não devemos apresentá-lo como produto financeiro operacional.

Mas didaticamente é excelente.

Porque obriga estudantes a misturarem:

MATEMÁTICA
+
FINANÇAS
+
DADOS
+
OTIMIZAÇÃO
+
COMPUTAÇÃO
+
GOVERNANÇA

Esse é o mundo real.

Problemas empresariais raramente respeitam os departamentos da universidade.

O computador não pergunta:

“Essa variável pertence à matéria de Estatística ou Administração?”

O problema simplesmente existe.

---

🗳️ CAPÍTULO 12 — IA E PESQUISA ELEITORAL

Outro projeto proposto envolve o Marist Poll e a School of Computer Science and Mathematics.

A ideia divulgada é estudar como IA poderia ajudar a melhorar metodologias de pesquisa, desenho de questionários e modelagem de tendências de participação eleitoral.

Isso abre questões técnicas muito interessantes.

Uma pesquisa envolve problemas como:

amostragem
não resposta
ponderação
formulação da pergunta
representatividade
viés
qualidade dos dados

Colocar IA nesse processo não faz os problemas desaparecerem.

Na realidade, pode criar outros.

Se os dados carregarem determinado viés:

DADOS ENVIESADOS
       │
       ▼
      IA
       │
       ▼
RESULTADO POTENCIALMENTE ENVIESADO

Por isso o assunto interessante não é simplesmente:

“IA consegue analisar pesquisas?”

A pergunta acadêmica melhor é:

“Como utilizamos IA sem perder rigor metodológico, transparência e capacidade de auditoria?”

Grace Hopper aprovaria a pergunta.

---

🏛️ CAPÍTULO 13 — O EASTER EGG DE 1988

Agora chegamos a uma das melhores partes dessa história.

Voltemos no tempo.

1988.

Sem ChatGPT.

Sem Python.

Sem Kubernetes.

Sem smartphone.

O muro de Berlim ainda estava de pé.

Naquele ano, Marist e IBM iniciaram um grande projeto conjunto.

E apareceu no campus um:

IBM 3090 MODEL 180

Um jornal estudantil da época descreveu um estudo conjunto de aproximadamente US$10 milhões envolvendo a instalação do IBM 3090 e a construção de uma infraestrutura computacional avançada no campus.

Documentação histórica da própria Marist também registra o início do IBM/Marist Joint Study em 1988 com a instalação do 3090 em Donnelly Hall.

Espere.

Donnelly Hall?

Sim.

O mesmo nome voltou para nossa história.

1988
DONNELLY HALL
IBM 3090

        ↓

2026
DONNELLY HALL
IBM z17

Grace Hopper sorri.

— Vocês chamam isso de easter egg?

Chamamos.

---

🦖 CAPÍTULO 14 — O FANTASMA DO 3090

Observe a simetria.

Em 1988:

IBM 3090
   │
   ▼
Universidade
   │
   ▼
Pesquisa
   │
   ▼
Novas aplicações

Em 2026:

IBM z17
   │
   ▼
Universidade
   │
   ▼
Pesquisa
   │
   ▼
IA
   │
   ▼
Agentes

Mudou a tecnologia.

Não mudou a pergunta fundamental:

O que podemos descobrir colocando tecnologia enterprise de verdade nas mãos de estudantes e pesquisadores?

Esse detalhe é importantíssimo.

Porque laboratório acadêmico normalmente significa uma versão reduzida do mundo empresarial.

Aqui o estudante ganha contato com uma plataforma construída para ambientes enterprise.

A Marist diz explicitamente que o z17 permitirá aos estudantes desenvolver e testar aplicações e obter experiência prática com tecnologia de escala empresarial.

---

⚓ CAPÍTULO 15 — POR QUE GRACE HOPPER É A TUTORA PERFEITA?

Agora podemos explicar nosso personagem.

Grace Hopper nasceu em 1906, foi matemática, professora, oficial da Marinha americana e uma das figuras centrais da história das linguagens de programação.

Ela trabalhou nos computadores Harvard Mark I e Mark II e posteriormente participou do desenvolvimento de compiladores e linguagens que ajudaram a abrir caminho para COBOL.

Seu trabalho com A-0 e posteriormente FLOW-MATIC foi fundamental para a ideia de que pessoas deveriam poder expressar problemas em linguagens mais próximas da comunicação humana, deixando o computador realizar a tradução para instruções de máquina. FLOW-MATIC tornou-se uma influência importante na criação de COBOL.

Pense na mudança filosófica.

Antes:

HUMANO
   ↓
LINGUAGEM DA MÁQUINA

Hopper ajudou a empurrar o mundo para:

HUMANO
   ↓
LINGUAGEM MAIS HUMANA
   ↓
COMPILADOR
   ↓
MÁQUINA

Décadas depois fazemos:

HUMANO
   ↓
LINGUAGEM NATURAL
   ↓
LLM
   ↓
AGENTE
   ↓
FERRAMENTAS
   ↓
MÁQUINA

Não são tecnologias equivalentes.

Mas existe uma deliciosa continuidade histórica na tentativa de elevar o nível de abstração entre intenção humana e execução computacional.

---

🐛 CAPÍTULO 16 — E SIM, TEMOS QUE FALAR DA MARIPOSA

Nenhum artigo sob tutela de Grace Hopper poderia escapar dela.

Em 1947, uma mariposa foi encontrada presa nos relés do Harvard Mark II e registrada no log como um caso real de “bug”. A palavra bug para problemas técnicos já existia; o episódio tornou-se famoso justamente pela brincadeira com um inseto real encontrado na máquina.

Agora imagine Grace visitando o laboratório de agentes.

AGENT A → AGENT B → AGENT C
                    ↓
                comportamento
                  inesperado

Ela pergunta:

— Onde está a mariposa?

O estudante responde:

— Almirante... desta vez ela está no prompt.

Talvez.

Ou nos dados.

Ou na ferramenta.

Ou na política.

Ou no modelo.

Ou na interação entre cinco agentes.

Bem-vindo ao debugging de 2026.

A mariposa evoluiu.

---

🚀 CAPÍTULO 17 — O SPYRE ENTRA NA SALA

Além do Telum II, existe outro personagem: IBM Spyre Accelerator.

Ele complementa o Telum II para workloads de IA, incluindo casos envolvendo IA generativa e dados não estruturados, como texto. A IBM tornou o Spyre disponível para z17 em outubro de 2025.

Simplificando bastante:

TELUM II
│
├── processamento
├── transações
└── inferência integrada

e:

SPYRE
│
└── aceleração adicional de IA

Juntos, eles ampliam os tipos de workloads de IA que podem permanecer próximos ao ambiente enterprise.

E aqui aparece novamente uma palavra fundamental:

DADOS

Empresas possuem décadas de dados valiosos próximos de aplicações IBM Z.

Mover tudo indiscriminadamente para outro ambiente nem sempre é desejável.

Existem questões de:

latência
segurança
custos
governança
compliance
movimentação de dados

Portanto, em certos casos:

LEVAR IA AO DADO

pode ser arquiteturalmente mais interessante do que:

LEVAR TODO O DADO À IA

---

🎓 CAPÍTULO 18 — COMO EU ESTUDARIA ISSO SENDO COBOLZEIRO?

Se você está começando, não tente aprender tudo simultaneamente.

Faça por camadas.

CAMADA 1 — COBOL

Aprenda:

IDENTIFICATION DIVISION
DATA DIVISION
PROCEDURE DIVISION
PIC
MOVE
IF
EVALUATE
PERFORM
CALL
arquivos

Depois entenda bem estruturas de dados.

CAMADA 2 — z/OS

Aprenda:

TSO
ISPF
datasets
JCL
JES
SDSF

Você precisa entender onde seu programa vive.

CAMADA 3 — ENTERPRISE

Adicione:

CICS
Db2
VSAM
MQ
RACF

Agora você começa a compreender sistemas empresariais.

CAMADA 4 — INTEGRAÇÃO

Estude:

REST
JSON
APIs
z/OS Connect
mensageria
eventos

Seu COBOL deixa de ser uma ilha.

CAMADA 5 — IA

Só então conecte:

Machine Learning
LLM
RAG
AI Agents
Guardrails
Observability
AI Governance

E de repente a figura inteira começa a aparecer.

---

🔬 CAPÍTULO 19 — UM LABORATÓRIO CASEIRO PARA ENTENDER A IDEIA

Você não precisa possuir um z17 no quintal.

Vamos reproduzir conceitualmente a experiência.

Crie três agentes imaginários.

AGENT-01
RESEARCHER

AGENT-02
WRITER

AGENT-03
REVIEWER

Objetivo:

criar campanha de venda

Política:

não mentir
não inventar números
não expor dados pessoais

Fluxo:

RESEARCHER
     │
     ▼
WRITER
     │
     ▼
REVIEWER
     │
     ▼
OUTPUT

Agora introduza erros.

Diga ao Writer:

Aumente dramaticamente a urgência.

Veja se ele inventa:

ÚLTIMA UNIDADE!

Depois coloque o Reviewer.

Ele deveria detectar a afirmação sem evidência.

Agora você começou a entender experimentalmente:

AGENT
GUARDRAIL
ORCHESTRATION
OBSERVABILITY

Sem escrever uma linha de COBOL.

Depois faça a pergunta de mainframe:

Como registraríamos todas as decisões?

Pronto.

Você chegou à auditoria.

---

📋 CAPÍTULO 20 — O SMF DOS AGENTES

Imagine um log:

10:03:01 AGENT-A recebeu objetivo
10:03:02 AGENT-A consultou DATASET-X
10:03:04 AGENT-A chamou AGENT-B
10:03:07 AGENT-B utilizou TOOL-Y
10:03:09 POLICY-03 bloqueou operação
10:03:10 AGENT-B tentou alternativa
10:03:14 resultado enviado ao usuário

Agora conseguimos investigar.

Sem observabilidade teríamos apenas:

ALGO DEU ERRADO.

Todo programador mainframe sabe como essa frase é assustadora.

Por isso uma das conexões mais fortes entre IA moderna e computação enterprise talvez seja justamente:

autonomia exige observabilidade.

Quanto mais ações delegamos ao software, mais precisamos registrar o caminho percorrido.

---

💡 CAPÍTULO 21 — DICAS PARA O PROGRAMADOR COBOL INICIANTE

Primeira dica: não tenha medo da IA.

Ela não invalida aquilo que você está aprendendo.

Segunda: não transforme COBOL numa religião.

COBOL é uma ferramenta extraordinária para determinados problemas.

Terceira: aprenda arquitetura.

Pergunte sempre:

Onde está o dado?

Quem chama quem?

Quem autentica?

Quem autoriza?

Onde fica o estado?

Como recuperamos falhas?

Onde está o log?

Quarta: aprenda integração.

O profissional valioso não será necessariamente aquele que conhece 600 verbos COBOL.

Será aquele capaz de olhar:

COBOL
CICS
DB2
MQ
API
JAVA
PYTHON
AI

e entender como tudo conversa.

Quinta:

nunca pare no tutorial.

Grace Hopper provavelmente teria algo a dizer sobre isso.

---

🔭 CAPÍTULO 22 — TALVEZ ESTEJA ERRADA A PERGUNTA SOBRE O “FUTURO DO MAINFRAME”

Durante anos perguntamos:

“Como convencer jovens a aprender mainframe?”

Talvez seja uma pergunta ruim.

Talvez devamos colocar mainframe dentro dos problemas que jovens querem resolver.

Quer estudar IA?

Aqui está IBM Z.

Quer estudar cybersecurity?

Aqui está IBM Z.

Quer estudar agentes?

Aqui está IBM Z.

Quer estudar APIs?

Aqui está IBM Z.

Quer estudar finanças?

Aqui está IBM Z.

Quer estudar observabilidade?

Aqui está IBM Z.

E então:

AI
 ↓
Python
 ↓
API
 ↓
MQ
 ↓
CICS
 ↓
COBOL

Um belo dia o estudante pergunta:

— O que é esse programa chamado CUSTOMER01?

O veterano responde:

— Tem uns 34 anos. Não mexe sem fazer backup.

Pronto.

Capturamos outro mainframer.

---

🧠 CAPÍTULO 23 — O QUE REALMENTE ESTÁ SENDO ENSINADO?

Não é COBOL.

Não é IA.

Não é z17.

O verdadeiro assunto é:

SISTEMAS

Como sistemas recebem dados.

Como tomam decisões.

Como sistemas conversam.

Como falham.

Como são protegidos.

Como sabemos o que fizeram.

Como recuperamos o estado anterior.

Como impedimos que façam aquilo que não deveriam fazer.

Essa é uma formação muito mais poderosa do que simplesmente aprender uma linguagem.

Porque linguagens mudam.

Os problemas fundamentais permanecem.

---

⚓ EPÍLOGO — GRACE HOPPER DESLIGA O TERMINAL

O laboratório está quase vazio.

Nosso jovem COBOLzeiro continua olhando para o z17.

No começo do dia ele enxergava:

MAINFRAME
    =
  COBOL

Agora enxerga:

                    IBM z17
                       │
          ┌────────────┼────────────┐
          │            │            │
     TRANSAÇÕES       DADOS         IA
          │            │            │
        CICS          Db2        MODELOS
          │            │            │
        COBOL          MQ         AGENTES
          │            │            │
        RACF          APIs      GUARDRAILS
          │            │            │
          └────────────┼────────────┘
                       │
                 ENTERPRISE
                  COMPUTING

Grace Hopper pega o quepe.

Antes de sair, olha uma última vez para o estudante.

— Agora você entendeu?

— Acho que sim.

— Então me diga: para que serve o z17?

Ele pensa alguns segundos.

Não responde “COBOL”.

Não responde “IA”.

Não responde “banco”.

Finalmente diz:

— Para resolver problemas grandes onde desempenho, dados, segurança, confiabilidade e controle importam.

Grace sorri.

— Agora você começou a entender mainframe.

Ela caminha em direção à porta.

O estudante volta ao terminal.

Na tela aparece:

AGENT-004 ABENDED

Ele grita:

— Almirante! Temos um bug!

Grace Hopper para.

Olha lentamente para trás.

— Já procurou a mariposa?

***************************************
*                                     *
*          END OF JOB - RC=0000       *
*                                     *
***************************************

Quase quarenta anos separam o IBM 3090 instalado na Marist em 1988 do IBM z17 que aparece em Donnelly Hall em 2026.

Os computadores mudaram.

As linguagens mudaram.

As interfaces mudaram.

Os problemas ficaram maiores.

Mas aquela velha curiosidade de Grace Hopper continua perfeitamente atual:

não pergunte apenas como usar a máquina.

Pergunte:

“O que mais podemos fazê-la fazer?”

E talvez essa seja justamente a grande lição escondida dentro daquele z17 da Marist.

O mainframe não chegou ao futuro tentando continuar vivendo em 1988.

Ele chegou ao futuro porque continuamos encontrando problemas novos suficientemente difíceis para precisarmos dele outra vez.

☕⚓🦖🤖

Um Café no Bellacosa Mainframe.

Para saber mais

https://www.marist.edu/w/marist-ibm-z17-news-release?utm_source=chatgpt.com

 

Bellacosa Mainframe e System Security

☕ UM CAFÉ NO BELLACOSA MAINFRAME

🕵️ CHARLES PONZI ENTRA NO CPD — QUANDO O PROGRAMADOR COBOL DESCOBRIU QUE INTELIGÊNCIA É UM ENORME PERFORM UNTIL

Mainframe Security, RACF, SMF, CICS, Db2, MQ, fraude, lavagem de dinheiro, inteligência financeira, graph analytics, entity resolution, threat hunting, IA, falsos positivos, narcossubmarinos, análise de esgoto — e o dia em que descobrimos que 17.390 hipóteses descartadas talvez ainda tivessem alguma coisa para contar.

---

🎬 PRÓLOGO — CHARLES PONZI ESTAVA ESPERANDO NO CPD

Eram 03:17 da manhã.

O programador COBOL entrou no CPD carregando um café que provavelmente já poderia ser classificado como material radioativo.

Na frente do terminal 3270 havia um homem de terno impecável.

— Quem é você?

— Charles Ponzi.

O programador quase derrubou o café.

— O Charles Ponzi?

— Depende. Se você estiver oferecendo investimentos, não. Se estiver tentando entender fraude, talvez eu possa ser útil como exemplo do que não fazer.

Na tela havia 80 milhões de registros.

Contas.

Empresas.

Transações.

Usuários.

Endereços.

Telefones.

Logs.

Eventos.

O programador olhou aquilo e perguntou:

— Qual deles é criminoso?

Ponzi sorriu.

— Você já começou fazendo a pergunta errada.

— Qual seria a pergunta certa?

Ele apontou para a tela.

Quais relações nesse sistema não deveriam existir?

E foi assim que começou nossa viagem.

---

🧠 CAPÍTULO 1 — PRIMEIRO: SEGURANÇA NÃO É RACF

Para quem está começando em mainframe, é tentador imaginar:

SEGURANÇA = RACF

RACF é importantíssimo.

Mas segurança de um ambiente IBM Z moderno é muito maior.

Temos algo aproximadamente assim:

                    IDENTIDADE
                        │
                       RACF
                        │
        ┌───────────────┼───────────────┐
        │               │               │
       TSO             USS             JES
        │               │               │
        └───────────────┼───────────────┘
                        │
          ┌─────────────┼─────────────┐
          │             │             │
        CICS           Db2            MQ
          │             │             │
          └─────────────┼─────────────┘
                        │
                      APIs
                        │
                 z/OS Connect
                        │
                  CLOUD / WEB

Um profissional de Bellacosa Mainframe Security precisa compreender as relações entre essas camadas.

Não basta perguntar:

“Vagner possui acesso ao dataset PROD.PAYROLL.MASTER?”

Precisamos perguntar:

VAGNER
  │
  ▼
GROUP-X
  │
  ▼
JCL
  │
  ▼
SUBMIT
  │
  ▼
STARTED TASK
  │
  ▼
PROGRAMA
  │
  ▼
Db2
  │
  ▼
PAYROLL

Talvez Vagner não tenha acesso direto ao dado.

Mas possui um caminho até ele.

Essa mudança parece pequena.

Não é.

Estamos deixando de pensar somente em permissões e começando a pensar em grafos.

---

🕸️ CAPÍTULO 2 — MAS O QUE DIABOS É UM GRAFO?

Nada de assustador.

Um grafo é basicamente:

NÓS + RELAÇÕES

Imagine:

VAGNER ── trabalha_em ──► EMPRESA_A

Temos dois nós:

VAGNER
EMPRESA_A

e uma relação:

trabalha_em

Agora adicionamos:

VAGNER ───── usa ───────► USER123
USER123 ─── acessa ─────► CICS01
CICS01 ─── executa ─────► PAY001
PAY001 ───── lê ────────► DB2.TABLE_X

Pronto.

Temos um pequeno grafo de segurança.

Agora imagine milhões de nós.

É aí que começa a diversão.

---

💰 CAPÍTULO 3 — CHARLES PONZI OLHA PARA UMA TRANSAÇÃO

Ponzi colocou uma transferência na tela:

CONTA A → R$ 49.850 → CONTA B

— Fraudulenta? — perguntou ele.

O programador analisou.

Conta existente.

Saldo suficiente.

Autenticação correta.

Transação autorizada.

Horário normal.

— Parece legítima.

Ponzi colocou outra:

CONTA C → R$ 48.970 → CONTA B

Depois:

CONTA D → R$ 51.120 → CONTA E
CONTA E → R$ 50.880 → EMPRESA X
CONTA F → R$ 49.310 → EMPRESA X
CONTA G → R$ 50.220 → EMPRESA X

Então perguntou:

— E agora?

A resposta mudou.

Não porque alguma transação individual necessariamente seja criminosa.

Mas porque surgiu um comportamento.

Essa é uma ideia fundamental:

Uma transação pode ser tecnicamente perfeita e ainda fazer parte de um comportamento que merece investigação.

O mainframe pode responder:

RACF ........ OK
CICS ........ OK
Db2 ......... OK
MQ .......... OK
SALDO ....... OK
CONTA ....... OK

E ainda assim alguma coisa pode estar errada no nível superior.

---

🔎 CAPÍTULO 4 — EVENTO NÃO É COMPORTAMENTO

Esse princípio vale também para cybersecurity.

Imagine:

02:13 USERX READ DATASET.A

Normal.

Depois:

02:17 USERX SUBMIT JOB77

Talvez normal.

Depois:

02:19 JOB77 ACCESS DB2.TABLE

Ainda plausível.

Depois:

02:22 MQ PUT QUEUE.EXTERNAL

Agora temos:

LOGIN
  ↓
DATASET
  ↓
JOB
  ↓
Db2
  ↓
MQ
  ↓
EXTERNAL

Individualmente:

evento → talvez normal

Coletivamente:

sequência → interessante

É aqui que SMF deixa de ser apenas auditoria e passa a ser matéria-prima para inteligência.

---

🐒 CAPÍTULO 5 — OS CHIMPANZÉS INVENTAM OS IFs

Ponzi perguntou:

— Como começamos?

O programador COBOL respondeu imediatamente:

IF ALGUMA-COISA-ESTRANHA
    PERFORM INVESTIGAR
END-IF

Ponzi suspirou.

— Depois dizem que COBOL está morto.

A ideia é simples.

Começamos com muitos IFs.

IF movimentação incompatível
IF empresa recém-criada
IF endereço compartilhado
IF telefone compartilhado
IF dispositivo compartilhado
IF procurador compartilhado
IF fluxo circular
IF concentração incomum
IF dispersão rápida
IF comportamento temporal incomum

Nenhum deles significa:

CRIMINOSO = TRUE

Isso seria perigosíssimo.

Eles significam:

INTERESSE-ANALITICO = INTERESSE-ANALITICO + 1

---

🎯 CAPÍTULO 6 — DE MILHÕES DE EVENTOS PARA QUATRO PERGUNTAS

Aqui surgiu uma das ideias centrais da nossa conversa.

Imagine:

80.000.000 eventos
        ↓
17.432 hipóteses
        ↓
correlação
        ↓
2.100
        ↓
contexto
        ↓
340
        ↓
entity resolution
        ↓
42
        ↓
fontes independentes
        ↓
4

A função da IA não deveria ser anunciar:

“ENCONTREI QUATRO CRIMINOSOS!”

Não.

A função seria dizer:

“Estas quatro estruturas merecem que investigadores humanos gastem tempo entendendo o que está acontecendo.”

Essa diferença é gigantesca.

Temos:

ANOMALIA ≠ FRAUDE
CORRELAÇÃO ≠ CAUSALIDADE
RELAÇÃO ≠ CUMPLICIDADE
HIPÓTESE ≠ EVIDÊNCIA
EVIDÊNCIA ≠ CONDENAÇÃO

Grave isso.

---

👥 CAPÍTULO 7 — ENTITY RESOLUTION

Agora surge outro problema.

Quem é “João”?

Temos:

JOÃO
 │
 ├── CPF
 ├── telefone
 ├── endereço
 ├── conta
 ├── cartão
 ├── empresa
 ├── dispositivo
 └── e-mail

Outra empresa utiliza o mesmo endereço.

Outra conta utiliza o mesmo telefone.

Outra pessoa utiliza o mesmo dispositivo.

Outra empresa possui o mesmo procurador.

O que pareciam cem entidades independentes talvez formem um cluster.

É isso que Entity Resolution tenta resolver:

Quais registros representam a mesma entidade ou entidades relacionadas?

Esse problema aparece em bancos, seguradoras, telecomunicações, e-commerce, segurança e inteligência.

---

🕸️ CAPÍTULO 8 — NÃO PROCURE SOMENTE O MAIOR NÓ

Imagine:

A ─ B ─ C
│   │   │
D ─ X ─ E
    │
F ─ G ─ H

X talvez nem movimente mais dinheiro.

Mas praticamente todos os grupos passam por ele.

Isso introduz conceitos de centralidade em grafos.

Um nó pode ser importante porque:

• possui muitas conexões;

• conecta comunidades diferentes;

• aparece em muitos caminhos;

• controla um recurso;

• concentra relacionamentos incomuns.

Às vezes a conta movimentando R$ 100 milhões chama atenção.

Mas o contador, procurador, dispositivo ou empresa que conecta quinze estruturas aparentemente independentes pode ser analiticamente muito mais interessante.

Dinheiro mostra volume. Conectividade pode revelar estrutura.

---

🔄 CAPÍTULO 9 — AS 17.390 HIPÓTESES NÃO MORRERAM

Aqui nossos chimpanzés tiveram outra crise existencial.

Suponha:

17.432 hipóteses

Após análise:

42 relevantes
17.390 descartadas

DELETE?

Jamais.

Talvez:

STATUS = LOW-PRIORITY

Porque hoje temos:

X → Y

Existe explicação comercial plausível.

Baixa prioridade.

Seis meses depois:

X → Y → Z → Q
        │
        └────► NOVA ENTIDADE RELEVANTE

Subitamente aquela transação antiga ganha outro significado.

O evento não mudou.

Nosso conhecimento mudou.

---

🦖 CAPÍTULO 10 — SMF JÁ SABIA

Isso é deliciosamente mainframe.

Imagine que um incidente seja descoberto em setembro.

Então alguém pergunta:

“Esse usuário já havia feito isso antes?”

Você consulta registros históricos.

E encontra:

MARÇO
USERX → DATASET.A

ABRIL
USERX → JOB77

MAIO
JOB77 → MQ.X

JUNHO
USERX → USS

Na época, eram eventos aparentemente desconectados.

Agora possuem contexto.

É por isso que retenção, integridade, timestamps e correlação histórica são tão importantes.

O passado pode adquirir novo significado.

---

♻️ CAPÍTULO 11 — O SISTEMA COMEÇA A APRENDER

Agora temos um loop:

OBSERVAR
   ↓
HIPÓTESE
   ↓
TESTAR
   ↓
INVESTIGAR
   ↓
RESULTADO
   ↓
APRENDER
   ↓
REANALISAR
   ↺

Se uma investigação confirmar determinada estrutura, aprendemos.

Se concluir que era perfeitamente legítima, também aprendemos.

Precisamos guardar:

TRUE POSITIVE
FALSE POSITIVE
FALSE NEGATIVE
TRUE NEGATIVE

Isso permite melhorar priorização futura.

Mas existe uma armadilha.

---

⚠️ CAPÍTULO 12 — A IA NÃO PODE CONFIRMAR A SI MESMA

Imagine:

IA suspeita de João
       ↓
João recebe mais investigação
       ↓
coletamos mais dados sobre João
       ↓
encontramos mais coisas incomuns
       ↓
IA conclui:
"EU TINHA RAZÃO!"

Talvez não.

Quanto mais observamos alguém, maior a chance de encontrarmos alguma anomalia.

Criamos um feedback loop de viés.

Portanto precisamos separar claramente:

OBSERVAÇÃO
     │
INFERÊNCIA
     │
HIPÓTESE
     │
EVIDÊNCIA INDEPENDENTE
     │
RESULTADO INVESTIGATIVO

A hipótese produzida pela IA não pode virar evidência para confirmar a própria hipótese.

---

🚽 CAPÍTULO 13 — QUANDO O ESGOTO VIROU TELEMETRIA

E então nossa conversa ficou realmente estranha.

Descobrimos que pesquisadores conseguem analisar águas residuais de cidades procurando metabólitos associados ao consumo de drogas.

Para cocaína, um marcador utilizado é a benzoilecgonina (BE).

A EUDA informa que seu estudo de 2025 envolveu 115 cidades europeias. Entre as 85 com dados comparáveis entre 2024 e 2025, 48 apresentaram aumento da carga de BE; no agregado comparável, houve aumento de aproximadamente 22%.

Isso não significa identificar indivíduos.

É uma medida populacional.

Em linguagem Bellacosa:

o esgoto virou uma espécie de SMF da cidade.

😂

Temos outro sensor independente:

APREENSÕES ───────────┐
                      │
PREÇO/PUREZA ─────────┤
                      │
ESGOTO ───────────────┤
                      │
HOSPITAIS ────────────┤
                      ├──► MODELO
FLUXOS FINANCEIROS ───┤
                      │
PORTOS ───────────────┤
                      │
INTELIGÊNCIA ─────────┘

Nenhum sensor sozinho conta toda a história.

A convergência é que interessa.

---

🚢 CAPÍTULO 14 — O NARCOSSUBMARINO NÃO É O PROBLEMA

Outro chimpanzé olhou pela janela e perguntou:

— Como organizações criminosas conseguem construir semissubmersíveis?

Boa pergunta.

A UNODC documenta diferentes categorias de embarcações utilizadas no tráfico marítimo, incluindo Low Profile Vessels, semissubmersíveis autopropulsados e, mais raramente, veículos totalmente submersíveis. As capacidades descritas chegam a várias toneladas por embarcação.

Mas o interessante para nós não é aprender a construir uma.

É perguntar:

Que organização precisa existir para conseguir produzir e operar repetidamente algo complexo?

Um artefato pressupõe uma rede:

EMBARCAÇÃO
    ▲
    │
engenharia
    │
materiais
    │
fornecedores
    │
financiamento
    │
pessoas
    │
conhecimento
    │
logística
    │
origem ───────────── destino

Portanto:

Não procure apenas o objeto produzido pela organização. Procure a organização capaz de produzir o próximo.

Isso vale para cybersecurity.

Encontrar um malware não significa necessariamente eliminar o grupo capaz de criar outro.

Bloquear um usuário comprometido não elimina necessariamente o caminho utilizado para comprometê-lo.

---

🧠 CAPÍTULO 15 — CONHECIMENTO TAMBÉM É UM ATIVO

Uma organização complexa aprende.

Algo parecido com:

MISSÃO
  ↓
RESULTADO
  ↓
FEEDBACK
  ↓
APRENDIZADO
  ↓
PRÓXIMA MISSÃO

Isso é organizational learning.

A embarcação pode desaparecer.

Uma carga pode ser apreendida.

Um operador pode ser preso.

Mas se permanecerem:

CAPITAL
+
CONHECIMENTO
+
FORNECEDORES
+
RELACIONAMENTOS
+
LOGÍSTICA

a capacidade pode ser reconstruída.

É exatamente a diferença entre:

destruir uma instância

e:

eliminar a capacidade de criar novas instâncias

Programadores entendem isso imediatamente.

Você matou um processo.

Mas quem continua fazendo:

START TASK

?

---

🏛️ CAPÍTULO 16 — MAS O ESTADO NÃO PENSA NISSO?

Aqui tivemos outra pergunta importante.

Se uma pessoa tomando café consegue chegar a essas ideias, por que autoridades não fariam o mesmo?

Fazem.

O Brasil possui estruturas de inteligência financeira e cooperação institucional. O Coaf, por exemplo, utiliza processos automatizados de classificação de risco e posteriormente análise aprofundada por analistas; informações recebidas permanecem em sua base e podem ganhar relevância quando confrontadas com novos dados.

Somente em 2025 foram produzidos 20.548 Relatórios de Inteligência Financeira (RIFs).

Ou seja:

DADOS
 ↓
RISCO
 ↓
PRIORIZAÇÃO
 ↓
ANALISTA
 ↓
RIF

Nossa ideia não nasceu em Marte.

O desafio é escala, integração e efetividade.

---

🧱 CAPÍTULO 17 — O CRIMINOSO NÃO RESPEITA ORGANOGRAMA

Uma organização estatal pode possuir:

POLÍCIA
RECEITA
COAF
BANCO CENTRAL
CVM
MINISTÉRIO PÚBLICO
JUDICIÁRIO
ESTADOS
MUNICÍPIOS

Cada qual com competências, sistemas, autorizações e limites legais.

A rede criminosa não precisa respeitar essas fronteiras.

Ela pensa simplesmente:

DINHEIRO
  ↓
PESSOA
  ↓
EMPRESA
  ↓
TRANSPORTE
  ↓
OUTRA EMPRESA
  ↓
OUTRO PAÍS

Essa assimetria é importantíssima.

O FATF/GAFILAT reconheceu avanços brasileiros em avaliação de risco, cooperação internacional e coordenação, mas também apontou necessidade de fortalecer cooperação entre determinadas autoridades — particularmente polícia, Ministério Público e administração tributária — e melhorar a persecução da lavagem de dinheiro.

Portanto:

o problema não é necessariamente ausência de inteligência. Pode ser dificuldade de transformar inteligências distribuídas em uma visão operacional integrada.

Isso parece familiar?

Claro.

É um problema de integração de sistemas.

---

🦖 CAPÍTULO 18 — O PROGRAMADOR COBOL FINALMENTE ENTENDE

Imagine:

SISTEMA-A
SISTEMA-B
SISTEMA-C
SISTEMA-D

Cada um possui dados excelentes.

Mas nenhum conversa adequadamente com os demais.

Programadores mainframe conhecem essa história desde antes de muita gente nascer.

O desafio passa a ser:

EXTRACT
   ↓
NORMALIZE
   ↓
CORRELATE
   ↓
RESOLVE ENTITY
   ↓
BUILD GRAPH
   ↓
ANALYZE

De repente, décadas trabalhando com sistemas corporativos deixam de ser apenas experiência em tecnologia antiga.

Viraram experiência em:

dados críticos, integração, identidade, transações, auditoria, consistência e processamento em escala.

---

🛡️ CAPÍTULO 19 — NASCE O BELLACOSA MAINFRAME SECURITY

Nossa trilha começou assim:

SECURITY 101

RACF
 ↓
USS
 ↓
CICS
 ↓
Db2
 ↓
MQ
 ↓
TCP/IP
 ↓
TLS

Depois:

SECURITY 201

ICSF / PKI
 ↓
SMF
 ↓
SIEM
 ↓
MITRE ATT&CK
 ↓
DevSecOps
 ↓
API Security
 ↓
Cloud Security

E finalmente:

SECURITY 301

Threat Hunting
 ↓
Incident Response
 ↓
UEBA
 ↓
Graph Analytics
 ↓
Entity Resolution
 ↓
Fraud Analytics
 ↓
Threat Intelligence
 ↓
AI Security

Agora a pergunta mudou.

Não queremos somente saber:

Quem possui acesso?

Queremos saber:

O que essa identidade consegue fazer?

Depois:

Esse comportamento é normal?

Depois:

Com quem essa entidade está relacionada?

E finalmente:

Qual estrutura aparece quando observamos todas essas relações conjuntamente?

---

🤖 CAPÍTULO 20 — A IA DOMÉSTICA E A IA INSTITUCIONAL

Durante nossa conversa fizemos algo curioso.

Humano:

"e se...?"

IA:

"plausível, mas..."

Humano:

"então talvez..."

IA:

"vamos testar..."

E repetimos.

Isso cria:

HUMANO
  ↓
HIPÓTESE
  ↓
IA
  ↓
CONFRONTO
  ↓
CONTRADIÇÃO
  ↓
REFINAMENTO
  ↓
NOVA HIPÓTESE
  ↺

Agora imagine isso dentro de uma organização, trabalhando somente sobre dados aos quais ela esteja legalmente autorizada a acessar.

A diferença não seria uma IA “sem limites”.

Seria:

IA
+
DADOS AUTORIZADOS
+
GRAPH
+
MEMÓRIA
+
AUDITORIA
+
ANALISTAS

Muito mais poderoso.

E também muito mais perigoso se mal governado.

Por isso precisaríamos praticamente de um RACF para a própria IA:

WHO
 ↓
ACCESSED WHAT
 ↓
WHY
 ↓
UNDER WHICH AUTHORITY
 ↓
WHAT WAS INFERRED
 ↓
WHAT WAS DECIDED
 ↓
WHO APPROVED
 ↓
AUDIT

---

🔐 CAPÍTULO 21 — ZERO TRUST PARA A INTELIGÊNCIA

Uma IA investigativa não deveria possuir:

SPECIAL
OPERATIONS
AUDITOR

tudo ao mesmo tempo.

😂

Precisamos de:

• least privilege;

• segregação de funções;

• trilha de auditoria;

• controle de acesso;

• retenção adequada;

• justificativa de consulta;

• proteção de dados;

• revisão humana;

• cadeia de custódia;

• controles contra abuso.

A mesma filosofia usada para proteger sistemas críticos deve proteger a ferramenta utilizada para investigá-los.

---

🔁 CAPÍTULO 22 — O GRANDE PERFORM UNTIL

Finalmente Ponzi voltou ao terminal.

— Então qual é o algoritmo?

O programador COBOL começou a escrever:

PERFORM UNTIL INVESTIGATION-COMPLETE

    PERFORM COLLECT-OBSERVATIONS

    PERFORM GENERATE-HYPOTHESES

    PERFORM TEST-HYPOTHESES

    PERFORM FIND-CONTRADICTIONS

    PERFORM CORRELATE-ENTITIES

    PERFORM PRIORITIZE

    PERFORM HUMAN-REVIEW

    PERFORM LEARN-FROM-RESULTS

    PERFORM REANALYZE-HISTORY

END-PERFORM.

Ponzi olhou.

— Isso compila?

— Provavelmente não.

— Então para que serve?

— Para explicar o conceito.

---

🧪 CAPÍTULO 23 — COMO EXPERIMENTAR ISSO SEM INVESTIGAR NINGUÉM

Aqui existe um excelente projeto educacional.

Crie dados inteiramente sintéticos.

Por exemplo:

50.000 pessoas fictícias
10.000 empresas fictícias
200.000 contas fictícias
5.000.000 transações fictícias

Introduza artificialmente alguns padrões conhecidos no dataset.

Depois tente encontrá-los.

Pipeline:

1. GERAR DADOS
      ↓
2. CRIAR ENTIDADES
      ↓
3. CRIAR RELAÇÕES
      ↓
4. INTRODUZIR PADRÕES
      ↓
5. ESCONDER A RESPOSTA
      ↓
6. EXECUTAR DETECÇÃO
      ↓
7. CRIAR GRAFO
      ↓
8. PRIORIZAR CLUSTERS
      ↓
9. MEDIR FALSOS POSITIVOS
      ↓
10. RETROALIMENTAR

Isso permitiria estudar graph analytics, IA e detecção sem acusar pessoas reais nem manipular dados sensíveis.

---

💡 CAPÍTULO 24 — DICA PARA O PROGRAMADOR COBOL

Não tente aprender tudo simultaneamente.

Comece pelas coisas que você já conhece.

Primeiro:

RACF.

Depois:

SMF.

Pergunte:

Quem fez o quê, quando e usando qual identidade?

Depois leve os eventos para um SIEM.

Aprenda correlação.

Depois aprenda Python suficiente para analisar dados.

Depois SQL.

Depois fundamentos de grafos.

Depois uma linguagem de consulta de grafos.

Depois:

• anomaly detection;

• entity resolution;

• UEBA;

• threat intelligence;

• machine learning;

• LLMs aplicados à análise.

Seu conhecimento COBOL não é obstáculo.

É vantagem.

Você já sabe que:

INPUT
 ↓
VALIDATION
 ↓
PROCESSING
 ↓
STATE CHANGE
 ↓
OUTPUT
 ↓
LOG

Todo sistema transacional sério faz alguma variação disso.

---

🧠 CAPÍTULO 25 — A GRANDE LIÇÃO DOS CHIMPANZÉS

No começo da conversa tínhamos perguntas aparentemente desconectadas.

Crime organizado.

Fintech.

Bancos.

Lavagem.

Política.

Produção agrícola.

Rotas.

Semissubmersíveis.

Águas residuais.

Mainframe.

SMF.

Grafos.

IA.

Parecia uma bagunça.

Até percebermos:

TODOS SÃO SISTEMAS

Sistemas possuem:

ENTIDADES
RELAÇÕES
ENTRADAS
SAÍDAS
ESTADO
DEPENDÊNCIAS
GARGALOS
TELEMETRIA
ANOMALIAS

E isso muda completamente nossa maneira de olhar problemas.

---

🎁 EASTER EGG — O COPYBOOK DE PONZI

Antes de ir embora, Ponzi deixou um copybook sobre a mesa:

       01 WS-INVESTIGATION.
          05 WS-HYPOTHESIS          PIC X(100).
          05 WS-CONFIDENCE          PIC 9(03).
          05 WS-EVIDENCE-COUNT      PIC 9(05).
          05 WS-CONTRADICTION-COUNT PIC 9(05).
          05 WS-STATUS              PIC X(10).

             88 HYPOTHESIS-WEAK     VALUE 'WEAK'.
             88 HYPOTHESIS-ACTIVE   VALUE 'ACTIVE'.
             88 HYPOTHESIS-REFUTED  VALUE 'REFUTED'.
             88 NEEDS-HUMAN         VALUE 'REVIEW'.

Na última linha havia um comentário:

      *-------------------------------------------------------*
      * NEVER MOVE 'GUILTY' TO WS-STATUS.                    *
      * THAT FIELD BELONGS TO DUE PROCESS, NOT TO THIS JOB.   *
      *-------------------------------------------------------*

O programador sorriu.

Finalmente Ponzi tinha produzido alguma coisa que ele confiaria em produção.

---

☕ EPÍLOGO — NÃO PROCURE O CRIMINOSO. PROCURE A PERGUNTA CERTA.

Talvez essa tenha sido a principal descoberta dessa viagem.

Um sistema de inteligência moderno não precisa começar sabendo a resposta.

Ele precisa conseguir perguntar:

“E se?”

Depois:

“Que evidência sustentaria isso?”

Depois:

“Que evidência destruiria essa hipótese?”

Depois:

“Existem fontes independentes apontando para a mesma estrutura?”

Depois:

“Qual explicação legítima também produziria esse comportamento?”

E somente depois:

“Vale gastar tempo humano investigando isso?”

É uma mudança brutal.

De:

ENCONTRE O CULPADO

para:

ENCONTRE AS MELHORES PERGUNTAS

É exatamente aí que IA e inteligência humana podem formar uma simbiose poderosa.

O humano possui algo maravilhoso:

curiosidade.

Ele olha para um problema e pergunta:

“Mas espere... e se?”

A máquina possui outra capacidade:

escala.

Ela pode procurar essa possibilidade em milhões de registros.

O humano volta:

“Isso não prova nada. Que outra explicação existe?”

A máquina testa novamente.

E nasce o loop:

              HUMANO
                 │
              pergunta
                 ↓
                IA
                 │
               dados
                 ↓
               GRAFO
                 │
             hipótese
                 ↓
           contradições
                 │
                 ▼
              HUMANO
                 │
             nova pergunta
                 │
                 └──────────────↺

Talvez o futuro da inteligência não seja uma super-IA dizendo aos humanos o que aconteceu.

Talvez seja algo muito mais interessante:

um humano extremamente curioso fazendo perguntas cada vez melhores enquanto uma máquina extremamente paciente verifica milhões de possibilidades.

E para o programador COBOL iniciante existe uma deliciosa ironia.

Passamos décadas escrevendo:

IF ...
    PERFORM ...
END-IF

Agora estamos descobrindo que algumas das perguntas mais difíceis de segurança, fraude e inteligência do século XXI continuam começando exatamente da mesma maneira:

IF isso estiver relacionado àquilo...

    o que mais deveria ser verdade?

Não execute a sentença.

Execute a investigação.

☕ Bellacosa Mainframe Security

Porque proteger o computador é importante.

Mas compreender o sistema que existe ao redor dele é muito mais interessante.

 

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.

☕🤖