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

☕ Gostou deste café?
Siga o Bellacosa Mainframe e acompanhe os próximos artigos.
SEGUIR O BLOG

Sem comentários:

Enviar um comentário

De Fã para Fã. Conteúdo não oficial produzido como homenagem, comentário, análise ou paródia. Personagens, marcas e obras eventualmente mencionados pertencem aos seus respectivos titulares.
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...