☕ 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

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

 
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.

🤖 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.

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...