☕ 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

Mostrar mensagens com a etiqueta fraude. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta fraude. Mostrar todas as mensagens

quarta-feira, 16 de setembro de 2026

🐒 QUANDO UM MILHÃO DE CHIMPANZÉS ABRIRAM O BARRIL DE SAQUÊ PREMIUM

 

☕ Um Café no Bellacosa Mainframe

🐒 QUANDO UM MILHÃO DE CHIMPANZÉS ABRIRAM O BARRIL DE SAQUÊ PREMIUM

Portas dos fundos humanas, “sabe com quem você está falando?”, jatinhos emprestados, togas, garotas de programa, despesas de representação, compliance, Red Team, Security — e o estranho dia em que descobrimos que o maior privilégio de um sistema talvez não estivesse cadastrado no RACF.




🎬 PRÓLOGO — O SISTEMA ESTAVA SEGURO

O jovem programador COBOL tinha certeza.

O RACF estava configurado.

As senhas eram fortes.

MFA estava habilitado.

Os datasets críticos estavam protegidos.

Os acessos privilegiados eram registrados.

O SIEM recebia eventos.

O SOC monitorava alertas.

Auditores possuíam relatórios.

Havia segregação de funções.

Existia política de Zero Trust.

Tudo perfeito.

Até que alguém apareceu na porta e pronunciou uma sequência de palavras contra a qual nenhum firewall havia sido configurado:

— Você sabe com quem está falando?

O jovem programador olhou para o veterano.

— Onde cadastro isso no RACF?

O velho tomou um gole de café.

— Em lugar nenhum.

— Então estamos protegidos?

— Muito pelo contrário, Padawan.

Eram 03:17.

O incidente estava apenas começando.



🐒 CAPÍTULO 1 — O MILHÃO DE CHIMPANZÉS

Existe uma velha brincadeira segundo a qual, colocando infinitos chimpanzés diante de máquinas de escrever durante tempo suficiente, algum deles acabaria escrevendo Shakespeare.

No Bellacosa Mainframe decidimos modernizar a experiência.

Colocamos um milhão de chimpanzés diante de terminais 3270.

Mas alguém cometeu um erro operacional gravíssimo.

Em vez de café, abriram um barril de saquê premium.

Depois do terceiro copo, nenhum chimpanzé queria mais escrever Shakespeare.

Queriam fazer auditoria.

E descobriram uma coisa extraordinária:

os sistemas mais protegidos do mundo frequentemente possuem portas que não aparecem nos diagramas de arquitetura.

Não são portas TCP.

Não estão no firewall.

Não possuem CVE.

Não aparecem no Nessus.

Não estão no OWASP Top 10.

São portas humanas.



🚪 CAPÍTULO 2 — A BACKDOOR QUE NÃO ESTAVA NO CÓDIGO

Imagine um sistema extremamente seguro.

Um funcionário tenta acessar determinado ambiente.

ACCESS DENIED.

Perfeito.

Agora chega um diretor.

ACCESS DENIED.

Tecnicamente, continua perfeito.

Então o diretor olha para o funcionário:

— Você sabe quem eu sou?

Nesse instante surge uma nova interface de autenticação.

Não existe API.

Não existe documentação.

Mas todo mundo conhece o protocolo:

IDENTIDADE: DIRETOR
AUTORIZAÇÃO: NÃO
PRESSÃO HIERÁRQUICA: ALTA
RISCO DE RETALIAÇÃO: ALTO

RESULTADO ESPERADO PELO SISTEMA:
DENY

RESULTADO ESPERADO PELO HUMANO:
TALVEZ SEJA MELHOR LIBERAR

Encontramos uma vulnerabilidade.

CVE-HUMAN-0001 — Sabe-Com-Quem-Está-Falando Privilege Escalation.



🪪 CAPÍTULO 3 — IDENTIDADE NÃO É AUTORIZAÇÃO

Aqui está uma lição fundamental de segurança:

Identification ≠ Authentication ≠ Authorization.

Eu posso saber exatamente quem você é.

Você pode realmente ser presidente.

Diretor.

CEO.

Ministro.

General.

Administrador.

DBA.

Isso não significa automaticamente que você esteja autorizado a acessar determinado recurso.

No RACF isso é banal.

No mundo humano, surpreendentemente, não.

O verdadeiro Zero Trust deveria conseguir dizer:

“Sei perfeitamente quem é o senhor. Agora preciso verificar se o senhor possui autorização.”

É fácil implementar Zero Trust contra o estagiário.

Quero ver implementar contra o presidente.



✈️ CAPÍTULO 4 — O JATINHO EMPRESTADO

Então os chimpanzés encontraram um hangar.

E descobriram outra propriedade curiosa do poder.

O cidadão comum viaja assim:

documento → check-in → fila → segurança → raio-X → portão → embarque.

O VIP pode utilizar ambientes completamente diferentes, sujeitos aos controles específicos daquela modalidade de aviação.

Nada disso significa automaticamente irregularidade.

Mas, para um Red Team, aparece imediatamente uma pergunta:

os controles continuam oferecendo rastreabilidade suficiente quando o usuário é VIP?

A pergunta não é:

“Como alguém poderia burlar isso?”

A pergunta correta é:

“Conseguimos reconstruir posteriormente quem entrou, quem saiu, quem autorizou e quem pagou?”

Essa é a diferença entre procurar uma vulnerabilidade e ensinar sua exploração.


Bellacosa Mainframe e uma historia que não esta no gibi

⚖️ CAPÍTULO 5 — A TOGA NÃO É UM TOKEN DE AUTENTICAÇÃO

Os chimpanzés continuaram investigando.

Encontraram pessoas poderosas.

Executivos.

Autoridades.

Magistrados.

Políticos.

Empresários.

E perceberam uma coisa.

Quanto maior o poder de uma pessoa, maior pode ser a tentação social de transformar sua posição em credencial.

Mas uma toga não deveria funcionar como:

PERMIT * ACCESS(ALTER)

Nem um cargo de CEO.

Nem um cartão VIP.

Nem amizade com o presidente.

Porque segurança baseada em prestígio possui uma vulnerabilidade fundamental:

ela funciona melhor justamente contra quem oferece menos risco institucional para quem aplica a regra.


🍽️ CAPÍTULO 6 — DESPESAS DE REPRESENTAÇÃO

Agora os chimpanzés chegaram ao departamento financeiro.

Encontraram uma expressão maravilhosa:

DESPESAS DE REPRESENTAÇÃO.

Jantares.

Viagens.

Eventos.

Hospitalidade.

Entretenimento.

Presentes.

Tudo pode possuir finalidade comercial perfeitamente legítima.

O problema começa quando alguém confunde:

DOCUMENTO EXISTE

com

TRANSAÇÃO É LEGÍTIMA.

São coisas completamente diferentes.

Um sistema ruim pergunta:

Tem comprovante?

Um sistema melhor pergunta:

O comprovante representa aquilo que realmente aconteceu?


🧾 CAPÍTULO 7 — COMPLIANCE NÃO É COLECIONAR PDF

Imagine:

DESPESA REAL = A
DOCUMENTO = B
CONTABILIDADE = B
ERP = B
RELATÓRIO = B
AUDITORIA SUPERFICIAL = OK

Cinco sistemas concordam.

E cinco sistemas podem estar errados.

Porque todos receberam a mesma representação incorreta da realidade.

Esse é um problema fascinante para quem trabalha com sistemas.

Garbage in, garbage out também funciona em compliance.

Uma transação pode possuir:

✔ documento
✔ aprovação
✔ centro de custo
✔ fornecedor
✔ lançamento
✔ pagamento

e ainda exigir investigação.

O auditor experiente não pergunta apenas:

“Existe nota?”

Pergunta:

“Esta nota conta a história verdadeira?”


👠 CAPÍTULO 8 — AS GAROTAS QUE ROUBARAM A MANCHETE

Então apareceram profissionais do sexo.

E todos os chimpanzés abandonaram imediatamente a arquitetura de segurança.

A imprensa também.

Porque:

CONFLITO DE INTERESSES EM COMPLEXA REDE DE RELACIONAMENTOS

é uma manchete chata.

Mas:

TOGA + JATINHO + GAROTA + FESTA

é praticamente o renascimento do Notícias Populares.

Só que existe uma armadilha intelectual aí.

Sexo consensual entre adultos pode não ser a questão relevante.

A pergunta interessante é outra:

quem proporcionou o benefício?

E depois:

por quê?

E depois:

para quem?

E finalmente:

o beneficiário possuía poder sobre algum interesse de quem estava pagando?

O Red Team abandona a fofoca e segue o fluxo.


💰 CAPÍTULO 9 — FOLLOW THE MONEY

Dinheiro possui uma qualidade maravilhosa para auditoria:

ele deixa rastros.

Mas o auditor iniciante procura somente:

A → B

O experiente procura:

A
│
├── empresa
├── consultoria
├── escritório
├── fornecedor
├── instituto
├── evento
├── viagem
└── benefício
        │
        ▼
        B

Isso não significa que cada seta represente corrupção.

Muito pelo contrário.

A maior parte das relações econômicas é perfeitamente legítima.

O objetivo é descobrir o significado das relações, não criminalizar relacionamentos.


🕵️ CAPÍTULO 10 — RED TEAM NÃO PROCURA APENAS BUG

Essa talvez seja a maior lição.

Red Team não precisa perguntar somente:

“Consigo quebrar o software?”

Pode perguntar:

“Consigo quebrar o processo?”

E depois:

“Consigo fazer alguém autorizado executar algo que eu não conseguiria executar?”

E finalmente:

“Existe alguém tão poderoso que os controles deixam de funcionar normalmente quando ele aparece?”

Essa última pergunta é assustadoramente poderosa.


🧠 CAPÍTULO 11 — O CONTROLE INVISÍVEL

Imagine duas políticas.

A política oficial:

Ninguém entra sem autorização.

E a política cultural:

Ninguém entra sem autorização, exceto pessoas importantes porque ninguém quer confusão.

Qual delas controla realmente a organização?

A segunda.

Mesmo sem estar escrita.

Esse é o Shadow Security Policy.

E ele pode ser mais poderoso que o RACF.


🐵 CAPÍTULO 12 — O CHIMPANZÉ AUDITOR

Depois de consumir quantidades preocupantes de saquê, um chimpanzé apresentou sua metodologia.

Ele escreveu no quadro:

QUEM?
 ↓
PEDIU O QUÊ?
 ↓
QUEM AUTORIZOU?
 ↓
QUEM PAGOU?
 ↓
QUEM RECEBEU?
 ↓
QUEM SE BENEFICIOU?
 ↓
HAVIA INTERESSE?
 ↓
HOUVE ATO POSTERIOR?
 ↓
EXISTE AUDIT TRAIL?

A sala ficou silenciosa.

O chimpanzé havia acabado de inventar uma investigação melhor que muito checklist corporativo.


🔐 CAPÍTULO 13 — ZERO TRUST PARA PODEROSOS

Talvez precisemos atualizar o conceito.

Zero Trust costuma ser explicado assim:

Never trust, always verify.

Mas existe uma versão organizacional:

Never trust status. Always verify authorization.

Porque existem duas formas de privilégio.

O privilégio técnico:

SPECIAL
OPERATIONS
AUDITOR
ALTER
CONTROL

E o privilégio social:

CEO
DIRETOR
VIP
AUTORIDADE
AMIGO DO DONO

O primeiro aparece nos relatórios.

O segundo raramente.

E justamente por isso merece atenção.


🧯 CAPÍTULO 14 — O FUNCIONÁRIO QUE DISSE NÃO

Existe ainda outro controle que quase nunca aparece no diagrama:

a pessoa que executa a política.

Se ela disser NÃO corretamente e receber punição por isso, a organização acabou de executar um treinamento informal.

Todos aprenderam:

Na próxima vez, diga SIM.

É assim que controles morrem sem ninguém alterar uma única linha de configuração.

O RACF continua perfeito.

O manual continua perfeito.

A auditoria continua recebendo relatórios verdes.

Mas ninguém mais deseja aplicar a regra contra determinadas pessoas.


🏛️ CAPÍTULO 15 — O PRINCÍPIO DA DISTÂNCIA ZERO

Relacionamento não é crime.

Networking não é crime.

Jantar não é crime.

Viajar não é crime.

Ter amigos poderosos não é crime.

Contratar serviços não é crime.

A pergunta de governança é:

essas relações conseguem alterar decisões que deveriam ser independentes?

Esse é o ponto em que compliance deixa de ser moralismo e vira arquitetura institucional.


📰 CAPÍTULO 16 — O EFEITO NOTÍCIAS POPULARES

Existe ainda um perigo para quem investiga.

Encontrar algo escandaloso demais.

Sexo.

Luxo.

Celebridades.

Jatinhos.

Festas.

Tudo isso produz atenção.

Mas atenção pode destruir investigação.

Porque o público passa a discutir:

“Quem dormiu com quem?”

quando deveria perguntar:

“Quem pagou o quê para quem e qual interesse existia?”

O espetáculo pode funcionar como fumaça sobre o problema verdadeiro.


🐒 EPÍLOGO — SHAKESPEARE NÃO VEIO

Depois de milhares de horas, o milhão de chimpanzés não escreveu Shakespeare.

Produziu algo muito mais útil.

Um relatório de auditoria.

Na última página havia apenas quatro linhas:

IDENTIDADE NÃO É AUTORIZAÇÃO.

DOCUMENTAÇÃO NÃO É VERDADE.

PODER NÃO É CREDENCIAL.

E TODO PRIVILÉGIO PRECISA DE AUDIT TRAIL.

O jovem programador olhou para o veterano.

— Então qual é a porta dos fundos mais perigosa?

O velho terminou o café.

Olhou para o relógio.

03:17.

— Aquela que todo mundo conhece, Padawan.

— Então por que ninguém fecha?

O veterano levantou-se.

— Porque às vezes quem passa por ela é justamente quem poderia mandar fechá-la.

No fundo da sala, um chimpanzé levantou o copo de saquê.

ICH408I.

Access denied.

Desta vez, para todos.

☕

terça-feira, 15 de setembro de 2026

🕶️ DIABOLIK NO MAINFRAME — Risk Scoring Humano

 

Bellacosa Mainframe e o risk scoring humano

☕ Um Café no Bellacosa Mainframe

🕶️ DIABOLIK NO MAINFRAME — Risk Scoring Humano

Quando o sistema deixa de perguntar “o que você fez?” e começa a perguntar “por que você deixou de se comportar como você mesmo?”

Há uma coisa que Diabolik entende melhor do que muitos sistemas antifraude.

A melhor maneira de atravessar uma porta protegida não é necessariamente arrombá-la.

É fazer com que a porta acredite que você deveria estar entrando por ela.

Máscara correta.

Documento correto.

Horário plausível.

Comportamento esperado.

Uma história suficientemente coerente.

Separadamente, cada detalhe parece normal.

E justamente aí começa nossa história.

Porque, em algum lugar dentro de uma enorme instituição financeira, existe um IBM Mainframe processando milhões de eventos e tentando responder a uma pergunta aparentemente simples:

este comportamento faz sentido para esta pessoa?

Bem-vindo ao Risk Scoring Humano.

E nosso guia será Diabolik.



🕶️ CAPÍTULO 1 — Diabolik não quer parecer Diabolik

Imagine um sistema antifraude bastante primitivo.

Sua lógica poderia ser parecida com:

IF TRANSACTION-AMOUNT > 10000
    MOVE 'HIGH-RISK' TO RISK-LEVEL
END-IF.

Funciona?

Às vezes.

Mas qualquer pessoa que conheça a regra aprende rapidamente que R$ 10.001 chama atenção e R$ 9.999 talvez não.

Esse é o problema das regras determinísticas isoladas.

Diabolik olha para isso e sorri.

Ele não precisa destruir a regra.

Precisa apenas parecer normal para ela.

Um sistema moderno precisa fazer outra pergunta:

R$ 9.999 é normal para quem está fazendo essa operação?

Para uma grande empresa, talvez seja banal.

Para uma conta que recebe R$ 1.800 por mês e nunca movimentou mais de R$ 3.000, pode ser extraordinário.

Portanto:

RISCO ≠ apenas EVENTO

Uma aproximação muito melhor seria:

RISCO =
    EVENTO
  + PESSOA
  + HISTÓRICO
  + CONTEXTO
  + RELACIONAMENTOS
  + TEMPO

É aqui que nasce o Risk Scoring Humano.



🎭 CAPÍTULO 2 — A melhor máscara é uma identidade verdadeira

Sistemas antigos frequentemente tentavam responder:

“Essa pessoa é criminosa?”

Sistemas modernos precisam responder algo mais sutil:

“Esse comportamento combina com essa identidade?”

Essa diferença é gigantesca.

João pode ser um cliente perfeitamente legítimo há quinze anos.

Recebe salário.

Paga supermercado.

Abastece o carro.

Paga escola.

Compra medicamentos.

Viaja uma vez por ano.

Seu comportamento produz uma espécie de impressão digital financeira.

Não precisamos conhecer João pessoalmente para perceber padrões.

JOÃO
│
├── salário mensal
├── supermercado
├── combustível
├── contas domésticas
├── escola
├── financiamento
└── viagens ocasionais

Nenhuma dessas informações isoladamente define João.

Mas juntas produzem seu baseline comportamental.

Agora imagine que alguma coisa muda.

Em uma semana:

JOÃO
│
├── recebe 8 transferências incomuns
├── acessa de novo dispositivo
├── muda telefone
├── realiza operação internacional
├── adiciona beneficiário
└── transfere praticamente todo o saldo

Talvez cada evento seja legítimo.

O problema é a combinação.

Diabolik conseguiu uma identidade verdadeira.

Mas ainda precisa aprender a ser João.



📸 CAPÍTULO 3 — O velho sistema guardava fotografias

Durante décadas, instituições trabalharam muito bem com fotografias cadastrais.

NOME
CPF
ENDEREÇO
RENDA
PROFISSÃO
IDADE
TELEFONE

É uma fotografia.

Ela responde:

Quem é Vagner?

Mas Risk Scoring moderno quer assistir ao filme.

08:03 login
08:04 consulta saldo
08:06 novo favorecido
08:07 alteração cadastral
08:11 transferência
08:13 segunda transferência
08:17 tentativa internacional

Agora temos comportamento.

E comportamento possui uma propriedade fascinante:

ele possui sequência.

Isso significa que:

A + B + C

pode ter significado completamente diferente de:

C + A + B

Exemplo:

troca telefone
→ cadastra dispositivo
→ transfere dinheiro

é diferente de:

transfere dinheiro
→ meses depois troca telefone

Os eventos são semelhantes.

A narrativa é diferente.



🎬 CAPÍTULO 4 — Risk Scoring transforma fotografia em filme

Vamos imaginar um cliente chamado Marco.

Durante 36 meses:

salário → conta
conta → despesas
conta → cartão
conta → investimento

Tudo relativamente previsível.

Então:

DIA 1
novo dispositivo

DIA 2
novo telefone

DIA 3
novo favorecido

DIA 3 + 4 minutos
transferência

DIA 3 + 7 minutos
segunda transferência

Um sistema baseado exclusivamente em valores pode não encontrar nada.

O Risk Engine comportamental observa:

DEVICE_RISK        +15
PROFILE_CHANGE     +10
NEW_BENEFICIARY    +20
VALUE_DEVIATION    +25
VELOCITY           +20
--------------------------------
RISK SCORE          90

Mas atenção.

Isso é apenas um exemplo didático.

Na vida real, scores podem ser produzidos por regras, modelos estatísticos, machine learning, modelos híbridos e sistemas especializados.

O conceito importante é:

sinais pequenos acumulam contexto.



🧮 CAPÍTULO 5 — O Risk Score entra em cena

Vamos criar nosso fictício:

BELLACOSA HUMAN RISK ENGINE — BHRE

Ele recebe eventos:

LOGIN
TRANSACTION
PROFILE_CHANGE
DEVICE_CHANGE
PASSWORD_RESET
BENEFICIARY_ADD
CARD_PURCHASE
PIX
TED
TRANSFER
ATM

Cada evento entra no motor.

No Mainframe poderíamos imaginar componentes como:

CICS
  ↓
COBOL
  ↓
Db2 / VSAM
  ↓
Risk Engine
  ↓
Decision

Para transações financeiras modernas, também poderíamos integrar APIs, mensageria e plataformas analíticas externas.

O mainframe não precisa fazer sozinho toda a ciência de dados.

Ele pode ser justamente o coração transacional que pergunta:

“Posso autorizar?”

E recebe:

APPROVE
REVIEW
CHALLENGE
DECLINE

💳 CAPÍTULO 6 — 200 OK não significa “é confiável”

Imagine:

CLIENTE
   ↓
APP
   ↓
API
   ↓
BANK
   ↓
MAINFRAME

A autenticação está correta.

Token correto.

Senha correta.

Dispositivo reconhecido.

Isso demonstra que determinadas credenciais foram aceitas.

Não demonstra necessariamente que a intenção seja legítima.

Essa distinção é fundamental:

AUTHENTICATION
      ≠
AUTHORIZATION
      ≠
TRUST

Diabolik adora quando confundimos essas três coisas.

Ele não precisa falsificar necessariamente tudo.

Talvez tenha acesso legítimo a uma credencial comprometida.

O sistema precisa analisar contexto.


🧠 CAPÍTULO 7 — Risk Scoring não deveria perguntar apenas “quem é você?”

Perguntas melhores:

Quem é você?

De onde costuma acessar?

Quando costuma acessar?

Quanto costuma movimentar?

Para quem costuma transferir?

Quais dispositivos utiliza?

Qual é sua velocidade normal de operações?

Que relacionamento possui com o destinatário?

Esse comportamento já aconteceu anteriormente?

Isso produz uma identidade dinâmica.

Chamaremos de:

Behavioral Identity.

Não é simplesmente CPF.

É uma combinação histórica de comportamentos.


🕸️ CAPÍTULO 8 — E então descobrimos o grafo

Diabolik consegue imitar Marco.

Excelente.

Mas existe um problema.

Ele precisa mandar o dinheiro para algum lugar.

Surge Maria.

MARCO → MARIA

Nada necessariamente estranho.

Mas Maria recebe também de:

JOÃO ──┐
PEDRO ─┤
ANA ───┼──→ MARIA
LUÍS ──┤
MARCO ─┘

Interessante.

Maria envia para Empresa X.

MARIA → EMPRESA X

Empresa X está relacionada a outras entidades.

Agora nossa análise deixa de olhar somente para transações.

Estamos construindo um:

GRAPH.


🕷️ CAPÍTULO 9 — O grafo destrói algumas máscaras

Uma pessoa pode alterar:

nome utilizado,

telefone,

conta,

empresa,

dispositivo,

endereço.

Mas relacionamentos podem revelar padrões.

Imagine:

PESSOA A
   │
   ├── telefone → PESSOA B
   │
   ├── endereço → EMPRESA C
   │
   ├── dispositivo → CONTA D
   │
   └── transferência → PESSOA E

Cada aresta adiciona contexto.

Agora descobrimos:

PESSOA E
   ↓
EMPRESA F
   ↓
CONTA G
   ↓
PESSOA B

Fechamos um ciclo.

É por isso que Graph Analytics é tão poderoso em fraude e AML.

Ele não pergunta apenas:

Quem recebeu dinheiro?

Pergunta:

Como essas entidades estão relacionadas?


🧩 CAPÍTULO 10 — Risk Scoring humano não significa julgar pessoas

Aqui existe uma distinção ética essencial.

Um sistema não deveria concluir:

“Essa pessoa é criminosa.”

Risk Scoring deve trabalhar com algo muito mais limitado:

“Esta operação apresenta características que justificam controles adicionais.”

Essa diferença protege clientes e instituição.

Score não deveria ser sentença.

Deveria ser sinal.

Por isso podemos ter:

LOW RISK
   ↓
PROCESS

MEDIUM RISK
   ↓
ADDITIONAL AUTHENTICATION

HIGH RISK
   ↓
MANUAL REVIEW

CRITICAL
   ↓
BLOCK / INVESTIGATION

Dependendo da política, legislação e natureza da operação.


🔎 CAPÍTULO 11 — O caso Gritzbach mostra outro tipo de Risk Scoring

Aqui podemos utilizar o caso apenas como analogia analítica, sem transformar acusações ainda controvertidas em fatos.

Segundo a reconstrução jornalística, Antônio Vinícius Lopes Gritzbach teria atravessado simultaneamente diferentes redes de relacionamento envolvendo integrantes do PCC, negócios, dinheiro, criptomoedas, autoridades e policiais. Ele posteriormente tornou-se colaborador do Ministério Público.

A questão interessante para nosso estudo não é tentar reproduzir qualquer “score do PCC”.

É observar algo universal:

pessoas também existem dentro de grafos de confiança.

Imagine abstratamente:

PESSOA
│
├── dinheiro
├── parceiros
├── clientes
├── fornecedores
├── instituições
├── autoridades
└── informações

Quando uma relação muda, outras podem ser afetadas.


⚖️ CAPÍTULO 12 — Trust Score é contextual

Essa é uma descoberta importantíssima.

Uma pessoa não possui universalmente:

TRUST = 72

Ela pode ser simultaneamente:

Banco A       → LOW RISK
Banco B       → UNKNOWN
Empresa C     → TRUSTED
Sistema D     → HIGH RISK

Porque risco depende de contexto.

O mesmo vale para comportamento.

Comprar R$ 8.000 em um restaurante pode ser extraordinário para mim.

Para uma empresa realizando jantar corporativo para 80 pessoas, talvez seja normal.

Portanto:

RISK = EVENT / CONTEXT

e não simplesmente:

RISK = EVENT

🧠 CAPÍTULO 13 — O programador COBOL precisa entender isso

Aqui chegamos ao ponto que frequentemente falta nas formações Mainframe.

O iniciante recebe:

01 WS-RISK-SCORE PIC 9(03).

E pensa:

É um campo numérico de três posições.

Não.

Talvez você esteja olhando para a conclusão de centenas de sinais.

Por trás daqueles três bytes conceituais podem existir:

histórico
perfil
device
geolocalização aproximada
velocity
valor
merchant
beneficiário
produto
canal
horário
relacionamentos
alertas anteriores

O programador Mainframe precisa compreender semântica de negócio, não somente PIC clauses.


💻 CAPÍTULO 14 — Vamos programar um pequeno exemplo

Imagine:

01 WS-RISK-SCORE       PIC 9(03) VALUE ZERO.
01 WS-NEW-DEVICE       PIC X.
01 WS-NEW-BENEFICIARY  PIC X.
01 WS-HIGH-AMOUNT      PIC X.
01 WS-PROFILE-CHANGE   PIC X.

Então:

IF WS-NEW-DEVICE = 'Y'
   ADD 15 TO WS-RISK-SCORE
END-IF

IF WS-NEW-BENEFICIARY = 'Y'
   ADD 20 TO WS-RISK-SCORE
END-IF

IF WS-HIGH-AMOUNT = 'Y'
   ADD 25 TO WS-RISK-SCORE
END-IF

IF WS-PROFILE-CHANGE = 'Y'
   ADD 10 TO WS-RISK-SCORE
END-IF.

Depois:

EVALUATE TRUE
   WHEN WS-RISK-SCORE >= 70
        MOVE 'REVIEW' TO WS-DECISION

   WHEN WS-RISK-SCORE >= 40
        MOVE 'CHALLENGE' TO WS-DECISION

   WHEN OTHER
        MOVE 'APPROVE' TO WS-DECISION
END-EVALUATE.

Didaticamente funciona.

Mas Diabolik imediatamente descobriria um problema.


😈 CAPÍTULO 15 — Diabolik aprende nossas regras

Se:

70 = REVIEW

ele tentará permanecer em:

69

Esse fenômeno é fundamental em sistemas antifraude.

Quando atacantes compreendem controles, adaptam comportamento.

Por isso sistemas precisam evoluir.

Podemos combinar:

RULES
+
STATISTICS
+
BEHAVIOR
+
MACHINE LEARNING
+
GRAPH ANALYTICS
+
HUMAN REVIEW

Nenhum componente precisa ser mágico.

O poder está na combinação.


⏱️ CAPÍTULO 16 — Velocity: Diabolik tem pressa

Um conceito maravilhoso para ensinar ao programador COBOL iniciante é velocity.

Imagine:

09:00 R$ 800
09:03 R$ 900
09:05 R$ 700
09:07 R$ 950
09:09 R$ 850

Nenhuma transação ultrapassa R$ 1.000.

Uma regra:

IF AMOUNT > 10000

não detecta nada.

Mas:

5 TRANSFERS
IN 9 MINUTES

é outro sinal.

Risk Scoring precisa compreender também:

quanto aconteceu em quanto tempo.


🕰️ CAPÍTULO 17 — O tempo transforma o grafo

Agora acrescentamos timestamps:

09:00 A → B
09:02 B → C
09:04 C → D
09:07 D → E

Temos um fluxo.

O grafo agora não mostra apenas:

A — B — C — D — E

Mostra movimento.

Chamamos conceitualmente isso de:

Temporal Graph.

Ele pode revelar mudanças que um grafo estático esconderia.


🏦 CAPÍTULO 18 — E onde entra o IBM Mainframe?

No lugar mais interessante possível.

No coração das operações.

Imagine uma arquitetura:

                 MOBILE
                    │
                 INTERNET
                    │
                    ▼
                 API LAYER
                    │
              z/OS Connect
                    │
                    ▼
┌─────────────────────────────────┐
│            IBM Z                │
│                                 │
│   CICS                          │
│     │                           │
│     ▼                           │
│   COBOL ───────► Db2            │
│     │                           │
│     ▼                           │
│   RISK REQUEST                  │
│     │                           │
└─────┼───────────────────────────┘
      │
      ▼
 ANALYTICS / GRAPH / ML
      │
      ▼
 RISK SCORE
      │
      ▼
 IBM Z
      │
      ▼
DECISION

E isso é importante:

modernização não significa necessariamente retirar o COBOL.

Pode significar permitir que COBOL converse com tecnologias especializadas.


⚡ CAPÍTULO 19 — Porque autorização não pode tomar café

Imagine cartão.

Cliente encosta na máquina.

TAP
 ↓
ACQUIRER
 ↓
NETWORK
 ↓
ISSUER
 ↓
AUTHORIZATION

O cliente está olhando para o terminal.

Não podemos dizer:

“Aguarde vinte minutos enquanto nosso algoritmo termina.”

A decisão precisa ocorrer rapidamente.

É exatamente aí que sistemas transacionais de alta disponibilidade continuam extremamente relevantes.

Risk Scoring precisa entrar no fluxo sem destruir SLA.


🔐 CAPÍTULO 20 — False Positive: quando prendemos o mordomo

Existe outro perigo.

Se o sistema ficar paranoico:

QUALQUER COISA DIFERENTE
        ↓
      BLOCK

teremos milhares de clientes legítimos irritados.

Chamamos isso de:

false positive.

O cliente viajou para Roma.

Compra jantar.

Sistema:

FRAUDE!

Cliente:

Estou com fome!

😄

Risk Scoring precisa equilibrar:

FRAUD LOSS
     ↕
CUSTOMER FRICTION

Bloquear tudo é fácil.

Autorizar corretamente é difícil.


🎯 CAPÍTULO 21 — Risk Score não é prova

Isso merece ficar gravado no monitor do programador:

RISK SCORE ≠ GUILT

Score 92 não significa:

“92% criminoso.”

Pode significar apenas que um modelo específico identificou uma combinação de sinais considerada de alto risco segundo sua própria calibração.

A interpretação depende do modelo.

Esse cuidado torna-se ainda mais importante quando falamos em Risk Scoring Humano.

Algoritmos podem produzir vieses.

Dados podem estar errados.

Cadastros podem estar desatualizados.

Relacionamentos podem ser coincidências.

Por isso decisões de grande impacto precisam de governança adequada.


🧪 CAPÍTULO 22 — Explainability: por que deu 92?

Imagine o analista recebendo:

RISK SCORE = 92

Ele pergunta:

Por quê?

Sistema:

Porque sim.

Inaceitável.

Precisamos de reason codes.

R01 NEW DEVICE
R07 NEW BENEFICIARY
R13 UNUSUAL AMOUNT
R22 HIGH VELOCITY
R31 GRAPH RELATION

Então:

SCORE 92

REASONS:
HIGH VELOCITY
NEW DEVICE
NEW BENEFICIARY
BEHAVIOR DEVIATION

Agora existe explicabilidade operacional.

E o COBOL pode desempenhar papel importantíssimo na integração desses reason codes ao fluxo transacional.


🗃️ CAPÍTULO 23 — Não jogue fora os dados antigos!

Aqui existe uma vantagem maravilhosa dos ambientes Mainframe.

Histórico.

Décadas de histórico podem existir.

Isso é ouro para análise comportamental — desde que seja utilizado com governança, finalidade legítima, qualidade e respeito às regras de proteção de dados.

Porque comportamento exige comparação:

HOJE
versus
ONTEM
versus
30 DIAS
versus
1 ANO

Um sistema que conhece apenas hoje não conhece comportamento.

Conhece eventos.


🕵️ CAPÍTULO 24 — Diabolik finalmente comete seu erro

Nosso Diabolik conseguiu:

credencial,

identidade,

dispositivo,

horário plausível,

valor plausível.

Ele parece perfeito.

Mas precisa transferir recursos.

O sistema observa:

DIABOLIK-AS-MARCO
        ↓
     CONTA X
        ↓
     CONTA Y
        ↓
     EMPRESA Z

E o Graph Engine percebe:

EMPRESA Z
   ↑
CONTA Q
   ↑
CASO ANTERIOR

A transação não era necessariamente anormal.

O relacionamento era.

E finalmente encontramos aquilo que Diabolik não conseguiu falsificar perfeitamente:

o contexto.


🧠 CAPÍTULO 25 — A verdadeira evolução do antifraude

Primeira geração:

TRANSACTION RULES

Segunda:

TRANSACTION + PROFILE

Terceira:

TRANSACTION + PROFILE + BEHAVIOR

Quarta:

TRANSACTION
+
PROFILE
+
BEHAVIOR
+
DEVICE
+
NETWORK
+
GRAPH
+
TIME

E então entramos no território que chamo aqui de:

HUMAN RISK SCORING

Não porque estejamos julgando o ser humano.

Mas porque estamos tentando compreender o comportamento dentro de seu contexto humano e relacional.


🧑‍💻 CAPÍTULO 26 — O que o COBOLista iniciante deve aprender

Quando encontrar:

IF RISK-SCORE > 80

não continue lendo imediatamente.

Pergunte:

Quem calculou esse score?

Quais eventos participaram?

Qual janela temporal?

O score expira?

É transacional ou cadastral?

Quais reason codes existem?

O que acontece quando o serviço de risco está indisponível?

Essa última pergunta é especialmente Mainframe.

RISK ENGINE DOWN

E agora?

FAIL OPEN?

Autoriza?

FAIL CLOSED?

Recusa?

FALLBACK RULES?

Usa regras locais?

Essa decisão pode valer milhões.


🚨 CAPÍTULO 27 — 03:17

Nosso easter egg Bellacosa aparece.

03:17 da manhã.

O telefone toca.

War Room.

Fraud Decision Service latency: 4.8 seconds
Authorization queue increasing
Timeout rate: 17%

Alguém diz:

“Vamos bypassar o Risk Engine.”

Silêncio.

Porque isso resolveria performance.

Mas poderia abrir a porta.

Outro propõe:

“Vamos bloquear tudo.”

Também resolveria fraude.

E destruiria o negócio.

O verdadeiro engenheiro Mainframe pergunta:

Qual é o fallback aprovado?

Essa frase separa improvisação de engenharia.


☕ CAPÍTULO 28 — A lição de Diabolik

Durante toda a história procurávamos o homem de máscara preta.

Esse era nosso erro.

Diabolik nunca quis que víssemos a máscara.

Queria que víssemos:

CLIENTE NORMAL

Risk Scoring evoluiu justamente porque fraude sofisticada não precisa parecer fraude.

Pode parecer:

uma compra,

uma transferência,

um login,

uma empresa,

uma conta,

um cliente.

Tudo aparentemente legítimo.

Até observarmos:

QUEM
+
O QUÊ
+
QUANDO
+
ONDE
+
COMO
+
COM QUEM
+
QUANTAS VEZES
+
EM QUE SEQUÊNCIA

Então surge uma história.


🕶️ EPÍLOGO — O Mainframe não procura criminosos

Essa talvez seja a mensagem mais importante para o programador iniciante.

O IBM Mainframe não deveria funcionar como juiz.

O Risk Engine também não.

Eles processam sinais.

EVENT
   ↓
CONTEXT
   ↓
HISTORY
   ↓
RELATIONSHIP
   ↓
RISK
   ↓
DECISION
   ↓
EVIDENCE

E boas arquiteturas mantêm algo fundamental:

rastreabilidade.

Precisamos saber:

qual informação entrou,

qual regra executou,

qual modelo respondeu,

qual score retornou,

qual reason code apareceu,

qual decisão foi tomada,

quando aconteceu

e qual versão estava em produção.

Porque um dia alguém perguntará:

“Por que essa transação foi recusada?”

E PORQUE WS-RISK > 80 não será resposta suficiente.

Diabolik talvez consiga enganar uma regra.

Talvez consiga enganar uma câmera.

Talvez consiga uma identidade perfeita.

Talvez consiga inclusive parecer estatisticamente normal durante algum tempo.

Mas quanto mais dimensões independentes um sistema correlaciona — histórico, comportamento, dispositivo, velocidade, relacionamentos e tempo — mais difícil se torna sustentar uma identidade artificial coerente.

Essa é a batalha moderna.

Não é:

COBOL contra inteligência artificial.

É:

COBOL
+
CICS
+
Db2
+
APIs
+
EVENTS
+
RULES
+
ML
+
GRAPH ANALYTICS
+
HUMAN ANALYST

Cada tecnologia fazendo aquilo que sabe fazer melhor.

E no centro de tudo continua existindo aquela pergunta simples que começou nossa investigação:

“Isto é normal?”

Diabolik ajusta a gravata, olha para o terminal e sorri.

O terminal responde:

TRANSACTION........... VALID
IDENTITY.............. VALID
AUTHENTICATION........ VALID
AMOUNT................ NORMAL

BEHAVIOR.............. UNUSUAL
VELOCITY.............. UNUSUAL
GRAPH RELATION........ HIGH RISK

RISK SCORE............ 92
DECISION.............. REVIEW

Pela primeira vez, Diabolik para de sorrir.

O sistema não descobriu necessariamente quem ele é.

Descobriu algo muito mais interessante.

Ele não está se comportando como a pessoa que afirma ser.

☕ Um Café no Bellacosa Mainframe

Onde até Diabolik descobre que enganar um IF é fácil. Difícil é enganar quarenta anos de histórico.



Para ir mais longe

https://eljefemidnightlunch.blogspot.com/2024/10/diabolik-no-mainframe-o-roubo-perfeito.html

sábado, 15 de agosto de 2026

O Milhão de Chimpanzés, Gutenberg e a Máquina do Juízo Final: quando o Homem Médio Ganhou Inteligência Artificial

 

Bellacosa Mainframe e o case do um milhão de chimpanzes e a ia generativa

☕ Um Café no Bellacosa Mainframe

O Milhão de Chimpanzés, Gutenberg e a Máquina do Juízo Final: quando o Homem Médio Ganhou Inteligência Artificial

🐒 IA generativa, teoria dos jogos, incentivo econômico, eleições, fraude, economia da atenção e a perturbadora hipótese de que talvez não precisemos de uma superinteligência para criar um desastre — basta entregar ferramentas suficientemente boas a gente suficiente durante tempo suficiente

Há uma velha experiência mental que diz que, se colocarmos um número infinito de chimpanzés diante de máquinas de escrever durante tempo infinito, eventualmente um deles produzirá as obras completas de Shakespeare.

É uma ideia simpática.

Matemática.

Elegante.

Praticamente poética.

Mas possui uma falha fundamental.

Ela pressupõe que os chimpanzés estejam interessados em usar a máquina de escrever.

Quem já observou seres humanos durante tempo suficiente sabe que essa é uma suposição perigosíssima.

Alguns chimpanzés provavelmente bateriam nas teclas.

Outros dormiriam.

Alguns brigariam.

Outros roubariam a banana do vizinho.

Uma quantidade respeitável descobriria alguma forma obscena de utilizar o equipamento.

Um provavelmente urinaria no teclado.

E inevitavelmente algum deles passaria a mão na bunda do pesquisador encarregado de observar o experimento.

A humanidade, afinal, nunca teve grande respeito pelos modelos elegantes.

Mas estamos em 2026.

E cometemos um pequeno erro experimental.

Entregamos Inteligência Artificial aos chimpanzés.

Agora eles não precisam mais escrever Shakespeare.

Podem simplesmente pedir.


🎹 Senhores, parem de bater aleatoriamente nas teclas

Imagine a sala de guerra.

Homens engravatados.

Cinzeiros.

Mapas gigantes.

Telefones vermelhos.

Um general aponta solenemente para uma tela.

— Senhores, temos um problema.

— Os russos?

— Não.

— Os chineses?

— Também não.

— Terroristas?

— Pior.

Silêncio.

— O cidadão comum descobriu Inteligência Artificial.

É aproximadamente aqui que nosso hipotético Dr. Lovestrange deixa cair o café.

Porque durante boa parte da história humana existiu uma proteção invisível para inúmeros sistemas:

a dificuldade.

Fazer determinadas coisas era difícil.

Escrever um livro era difícil.

Produzir um jornal era caro.

Montar uma campanha publicitária exigia equipe.

Editar vídeo exigia conhecimento.

Programar computadores exigia estudo.

Produzir um relatório técnico exigia competência.

Interpretar determinadas regras exigia especialistas.

Fraudar certos processos também exigia competência.

Atacar sistemas computacionais exigia conhecimento.

Produzir propaganda convincente exigia gente talentosa.

Criar música exigia músicos.

Ilustração exigia ilustradores.

Tudo possuía uma barreira de entrada.

E então começamos, lentamente, a derrubar essas barreiras.

O primeiro grande suspeito atende pelo nome de Johannes Gutenberg.


📚 Gutenberg aperta o primeiro botão vermelho

Por volta do século XV, Gutenberg ajudou a transformar radicalmente o custo da reprodução de textos.

Antes, copiar conhecimento era caro.

Depois, ficou muito mais barato.

E aqui aparece uma verdade desconfortável que acompanha toda democratização tecnológica:

quando você democratiza a produção de coisas boas, também democratiza a produção de porcaria.

A prensa não imprimiu apenas ciência.

Imprimiu propaganda.

Não imprimiu apenas literatura.

Imprimiu mentira.

Não imprimiu apenas filosofia.

Imprimiu panfletos, insultos, pornografia, superstições, ataques políticos, bobagens e todo o maravilhoso zoológico intelectual que acompanha nossa espécie.

Gutenberg não democratizou a verdade.

Democratizou a cópia.

Séculos depois, telégrafo, rádio e televisão atacaram outro gargalo:

a distância.

A Internet atacou:

a distribuição.

Blogs e redes sociais atacaram:

a publicação.

Smartphones colocaram câmera, gráfica, estúdio, rádio e emissora no bolso.

Algoritmos de recomendação começaram a industrializar:

a atenção.

E então chegou a Inteligência Artificial generativa atacando um gargalo diferente.

Talvez o último grande gargalo.

A competência produtiva.


🤖 O homem médio recebe uma promoção que ninguém aprovou

A grande transformação talvez não seja tornar gênios ainda mais geniais.

Os melhores profissionais sempre tiveram capacidade extraordinária.

O melhor advogado já sabia escrever.

O melhor programador já sabia programar.

O melhor fraudador já conhecia o sistema.

O melhor publicitário sabia capturar atenção.

Eles constituem a ponta da distribuição.

Mas a sociedade não é feita apenas das pontas.

Ela é feita principalmente da imensa barriga da curva.

O homem médio.

A mulher média.

O profissional razoável.

O estudante comum.

O cidadão curioso.

O sujeito que sabe um pouco.

O sujeito que não sabe quase nada.

O famoso:

“deixa que eu tento.”

A IA não precisa transformar esse indivíduo em especialista.

Basta transformá-lo de:

“não consigo fazer”

em:

“consigo fazer algo suficientemente plausível.”

Essa palavra — suficientemente — pode causar estragos monumentais.

Porque não estamos falando de um indivíduo.

Estamos falando de milhões.


🐒 O Teorema do Milhão de Chimpanzés

Vamos abandonar por um momento o infinito.

Não precisamos dele.

Vamos trabalhar com apenas:

1.000.000 de chimpanzés.

Cada um recebe:

um computador,

acesso à Internet,

IA generativa,

imagem,

áudio,

vídeo,

programação,

tradução,

automação,

redes sociais,

métricas,

algoritmos de recomendação,

e tempo.

Agora acrescente motivações humanas.

Alguns querem dinheiro.

Alguns querem poder.

Alguns querem passar em concurso.

Alguns querem economizar tempo.

Alguns querem produzir relatórios.

Alguns querem promover candidatos.

Alguns querem atacar candidatos.

Alguns querem fraudar seguradoras.

Alguns querem defender seguradoras.

Alguns querem escrever petições.

Alguns querem contestar petições.

Alguns querem estudar.

Alguns querem colar.

Alguns querem cometer crimes.

Alguns querem combater crimes.

Alguns querem pornografia.

Alguns querem fama.

Alguns só querem assistir jovens dançando com pouca roupa no TikTok e no Instagram.

Outros preferem plataformas mais explícitas.

Uma grande quantidade só quer matar o tédio.

E inevitavelmente alguns continuarão urinando no teclado.

Esse detalhe é importante.

Não estamos modelando agentes racionais perfeitos.

Estamos modelando seres humanos.


🎲 E então entra a teoria dos jogos

Agora nosso experimento fica interessante.

Imagine um concurso.

Um candidato usa determinadas ferramentas para obter vantagem indevida.

Outro percebe.

Ele pode seguir as regras e aceitar uma possível desvantagem.

Ou pode imitar.

Se acredita que muitos estão fazendo o mesmo, surge uma pressão:

“Se eu não fizer, perco.”

Esse pensamento aparece em inúmeras áreas.

No trabalho acadêmico:

“Todo mundo está usando.”

No marketing:

“Meu concorrente produz cinquenta vídeos por semana.”

No escritório jurídico:

“O outro escritório já usa IA.”

No relatório técnico:

“Precisamos entregar amanhã.”

Na eleição:

“O adversário domina as redes.”

Na fraude:

“Esse método está funcionando.”

O comportamento pode espalhar-se mesmo entre pessoas que inicialmente não desejavam participar.

Essa é uma das perversidades da teoria dos jogos.

Não precisamos que todos gostem do equilíbrio final.

Basta que cada agente considere irracional permanecer sozinho fora dele.


💰 E então alguém oferece dinheiro ao chimpanzé

Nesse momento a sala de guerra inteira deveria pedir café duplo.

Porque capacidade tecnológica é uma coisa.

Incentivo econômico é outra.

O chimpanzé pode desistir depois de dez tentativas fracassadas.

Mas e se a décima primeira pagar R$ 5.000?

Agora existe motivação para continuar.

Se determinada atividade apresenta retorno esperado positivo, o fracasso deixa de ser obstáculo.

Vira custo operacional.

Mil tentativas.

Novecentas e noventa e nove falham.

Uma funciona.

Se aquela única tentativa pagar o suficiente, o modelo sobrevive.

E então algo quase darwiniano começa.

tentativa

↓

resultado

↓

recompensa

↓

imitação

↓

melhoria

↓

nova tentativa

As estratégias ruins morrem.

As boas sobrevivem.

O dinheiro funciona como função de fitness.

E estratégias lucrativas possuem uma característica desagradável:

financiam a próxima geração.

Lucro compra:

mais máquinas,

melhores modelos,

mais dados,

mais automação,

mais tentativas.

Então surge um loop:

capital → capacidade → experimentação → sucesso → capital maior.

Não precisamos de Skynet.

Temos contabilidade.


🛡️ A seguradora entra na sala

Considere seguros.

Durante décadas seguradoras construíram processos assumindo determinado custo para produzir documentação, contestar decisões, compreender contratos e executar fraudes.

Agora ambos os lados recebem IA.

O cliente legítimo passa a compreender melhor sua apólice.

Excelente.

O fraudador também.

Menos excelente.

A seguradora coloca IA para detectar padrões.

O adversário aprende como os detectores funcionam.

A seguradora melhora.

O adversário adapta.

Ataque.

Defesa.

Adaptação.

Contra-adaptação.

Estamos diante de uma corrida armamentista.

E ela não precisa ser liderada por grandes organizações criminosas.

Milhares de pequenas tentativas podem produzir conhecimento coletivo sobre o que funciona.

Depois aparecem fóruns.

Vídeos.

Tutoriais.

Ferramentas.

Serviços.

Mercados.

Especialização.

Aquilo que inicialmente exigia um especialista acaba empacotado.

Fraud-as-a-Service.

O chimpanzé agora assina mensalmente.


🎓 A universidade recebe Shakespeare demais

Agora coloque nossos chimpanzés na academia.

Milhões de estudantes recebem máquinas capazes de gerar textos plausíveis.

O problema óbvio é cola.

O problema interessante é outro.

Imagine uma alucinação.

Uma referência inexistente.

Um conceito errado.

A IA produz.

Um estudante publica.

Outro copia.

Um site indexa.

Outra IA recupera.

Outro estudante utiliza.

Uma terceira IA encontra vários textos repetindo a mesma informação.

Pronto.

Criamos uma porcaria com genealogia.

A mentira agora possui avós.

Depois de algumas gerações, ninguém sabe exatamente onde nasceu.

E temos outro problema.

A universidade coloca IA para identificar textos produzidos por IA.

O aluno coloca IA para modificar o texto.

A universidade melhora o detector.

O aluno melhora a transformação.

Outra corrida armamentista.

Senhores, alguém poderia verificar se ainda há café?


⚖️ Advogados, peritos e a aparência de competência

O problema ganha outra dimensão quando os documentos possuem autoridade institucional.

Petição.

Laudo.

Parecer.

Relatório.

Memorando.

Auditoria.

Análise técnica.

Todos possuem uma característica psicológica poderosa:

formato profissional gera percepção de competência.

Um documento de cinquenta páginas, bem diagramado, cheio de tabelas, gráficos e referências parece importante.

Mesmo quando é lixo.

Historicamente, produzir lixo sofisticado dava trabalho.

Agora talvez dê um prompt.

Temos então uma nova equação:

aparência de competência ≠ competência real.

Isso é especialmente perigoso quando o receptor também utiliza IA para analisar o documento.

Uma máquina escreve.

Outra resume.

Uma terceira classifica.

Um humano lê três parágrafos.

E todos seguem felizes.

Até alguma coisa explodir.


💻 O cybercriminoso mediano ganha estagiários sintéticos

Segurança cibernética oferece talvez o exemplo mais intuitivo.

Sempre existiram especialistas extremamente capazes.

Mas especialistas são raros.

O perigo interessante é reduzir parcialmente a barreira para quem está abaixo deles.

Pesquisa.

Tradução.

Automação.

Explicação de código.

Reconhecimento de padrões.

Adaptação.

A IA pode tornar determinadas tarefas mais acessíveis.

Do lado defensivo isso é maravilhoso.

Do lado ofensivo também existe aumento de capacidade.

Mais uma vez:

a tecnologia não escolhe o lado.

Ela reduz custo.

E incentivos escolhem como aquela capacidade será utilizada.


🗳️ Itatiba entra discretamente na sala de guerra

Agora chegamos às eleições.

E aqui tenho uma lembrança particularmente interessante.

Em 2016, em Itatiba, cidade do interior paulista, acompanhei de perto um candidato chamado Du Pedroso.

Não havia grande agência.

Não havia escritório de marketing.

Não havia exército de especialistas.

Era praticamente:

um homem contra o sistema eleitoral.

Ele produzia vídeos, jingles, fotomontagens e outras peças digitais utilizando as ferramentas disponíveis naquele período, distribuindo material por WhatsApp e redes sociais.

Independentemente da avaliação jurídica específica de cada peça, aquilo mostrava algo importante:

um indivíduo tecnologicamente habilidoso já conseguia multiplicar sua capacidade comunicacional sem possuir a infraestrutura tradicional de uma campanha profissional.

Agora retire Du Pedroso da eleição de 2016.

Coloque-o em 2026.

Entregue:

LLM,

geração de imagem,

geração de vídeo,

voz sintética,

música,

edição,

automação,

analytics,

agentes.

Um homem pode carregar uma pequena agência publicitária dentro do computador.

Agora não faça isso com um.

Faça com:

1.000.000.

Chegamos novamente aos chimpanzés.


🗳️ Um milhão de microcampanhas

Quando falamos em interferência eleitoral, nossa imaginação costuma procurar grandes estruturas.

Partidos.

Estados.

Agências.

Empresas.

Organizações.

Mas talvez o desafio mais estranho esteja em outro lugar.

E se tivermos milhões de microprodutores?

Um simpatizante cria um meme.

Outro melhora.

Outro transforma em vídeo.

Outro coloca música.

Outro traduz.

Outro exagera.

Outro distorce.

Outro corrige.

Outro transforma a correção em piada.

Outro produz uma sátira.

Outro cria uma montagem.

Outro cria resposta.

Todos parcialmente independentes.

Agora cada um possui ferramentas de produção industrial.

Temos:

geração

↓

distribuição

↓

feedback

↓

seleção

↓

mutação

↓

nova distribuição

Isso parece menos uma campanha tradicional e mais um organismo cultural.

Não precisa haver comandante.

Não precisa haver sala secreta.

Não precisa haver plano mestre.

O sistema pode produzir comportamento emergente.


📱 Mas metade dos chimpanzés está vendo dancinha

E aqui aparece a grande piada cósmica.

Temos acesso a uma quantidade de informação jamais vista.

Bibliotecas.

Cursos.

Ciência.

História.

Literatura.

Documentos.

Universidades.

Inteligência Artificial.

Praticamente toda a memória da humanidade disponível dentro de um pequeno retângulo de vidro.

E o cidadão usa o retângulo para assistir uma dancinha.

Ou vídeo de gato.

Ou celebridade.

Ou conteúdo sensual.

Ou pornografia.

Isso não é necessariamente estupidez.

É economia da atenção.

Porque Gutenberg resolveu a escassez de cópias.

A Internet resolveu a escassez de distribuição.

IA começa a resolver a escassez de produção.

Mas ninguém resolveu:

a escassez de atenção humana.

Continuamos com dois olhos.

Um cérebro.

Vinte e quatro horas.

E sono.

Quanto mais conteúdo produzimos, mais valiosa fica a atenção.

Consequentemente, milhões de produtores começam a competir não necessariamente pela verdade.

Competem pelo clique.

Pela retenção.

Pelo compartilhamento.

Pelo choque.

Pela indignação.

Pelo tesão.

Pelo medo.

Pela risada.

Pela curiosidade.

E aqui surge uma questão terrível:

o conteúdo mais correto não é necessariamente o conteúdo mais competitivo.


📢 O algoritmo também ganhou direito a voto

Nosso milhão de chimpanzés não distribui conteúdo diretamente.

Existe um intermediário.

O algoritmo.

Ele observa.

Mede.

Classifica.

Recomenda.

Amplifica.

Oculta.

E possui sua própria função objetivo.

Assim passamos de:

chimpanzé → chimpanzé

para:

chimpanzé → algoritmo → chimpanzé.

O algoritmo também participa da seleção cultural.

Uma mensagem recebe atenção.

Outra morre.

Uma imagem viraliza.

Outra desaparece.

A seleção acontece em velocidade industrial.

Então nossos agentes recebem feedback.

“Isso funcionou.”

Produzem mais.

Outra rodada.

Mais dados.

Mais seleção.

Estamos novamente em território evolucionário.


🕵️ O burocrata de 1964 pede transferência

Agora tragam para nossa sala de guerra um burocrata brasileiro de 1964.

Ele está acostumado com outro universo.

Jornais.

Editoras.

Gráficas.

Rádio.

Televisão.

Livros.

Filmes.

Pontos físicos de produção.

Ele consegue imaginar censura porque consegue imaginar gargalos.

Então mostramos 2026.

— Quantas publicações existem?

— Muitas.

— Quantas editoras?

— Não importa.

— Onde estão as gráficas?

— No bolso das pessoas.

— Quantos jornalistas?

— Também não importa.

— Quem produziu este vídeo?

— Talvez uma pessoa.

— Qual estúdio?

— Um notebook.

— Quanto tempo levou?

— Dois minutos.

— Proíba esta imagem.

— Já existem quinze mil variantes.

— Recolha as cópias.

— Não existem originais.

— Então bloqueie tudo.

— Enquanto conversávamos surgiram mais vinte mil.

Nosso burocrata olha lentamente para o teto.

Pede um Xanax.

Depois pergunta se pode misturar com Rivotril.

O médico militar responde que talvez seja melhor apenas pedir aposentadoria.

Mas a piada possui uma conclusão séria.

Muitos mecanismos de governança foram construídos supondo pontos de concentração.

Poucos emissores.

Poucas instituições.

Poucos produtores.

Agora podemos ter milhões.


🌊 Você não precisa derrotar o fiscal. Basta afogá-lo

Essa talvez seja uma das maiores assimetrias do mundo generativo.

Produzir pode levar segundos.

Verificar pode levar minutos.

Horas.

Dias.

Gerar uma alegação é barato.

Investigar exige contexto.

Gerar uma imagem é barato.

Autenticar exige trabalho.

Gerar cinquenta páginas é barato.

Revisar cinquenta páginas continua caro.

Portanto:

custo de produção ↓↓↓

enquanto

custo de verificação ↓ lentamente.

Isso aparece em:

universidades,

tribunais,

seguradoras,

bancos,

auditorias,

moderação,

eleições,

cybersecurity,

jornalismo,

compliance.

Talvez não seja necessário quebrar o sistema.

Basta fornecer mais entradas do que ele consegue verificar.

Não invadimos a fortaleza.

Enviamos formulários.

Milhões deles.

Dr. Lovestrange sorri discretamente.


🐒 Mas o chimpanzé ainda pode urinar no teclado

Existe, porém, outro erro que devemos evitar.

Não podemos imaginar um milhão de agentes perfeitamente racionais usando IA da maneira mais eficiente possível.

Isso seria reconfortante demais.

Humanos são muito mais interessantes.

Alguns procurarão lucro.

Outros cometerão erros.

Outros experimentarão coisas absurdas.

E justamente nesses comportamentos absurdos podem surgir descobertas inesperadas.

Um agente encontra uma estratégia por conhecimento.

Outro por análise.

Outro por tentativa.

Outro porque entendeu errado.

Outro porque estava brincando.

Outro porque apertou o botão errado.

Se o resultado funcionar, alguém observa.

Copia.

Melhora.

Automatiza.

Monetiza.

Portanto, nossa civilização possui uma capacidade curiosa:

transformar acidentes em modelos de negócio.

O chimpanzé que urinou no teclado talvez apenas tenha destruído um computador.

Mas se por alguma coincidência isso revelar uma falha do laboratório...

os outros imediatamente perguntarão:

“Como automatizamos a urina?”


☢️ Senhores, construímos uma máquina do juízo final sem perceber?

A velha ficção sobre Inteligência Artificial imagina uma máquina extraordinariamente inteligente tomando uma decisão extraordinariamente perigosa.

Talvez estejamos olhando para o lado errado.

Talvez o risco sistêmico mais interessante não seja:

uma superinteligência fazendo uma coisa terrível.

Talvez seja:

milhões de inteligências humanas medianas fazendo pequenas coisas suficientemente eficientes, simultaneamente, usando ferramentas suficientemente poderosas.

Não precisamos de HAL.

Não precisamos de Skynet.

Não precisamos de um supervilão.

Podemos precisar apenas de:

N — muitos agentes

IA — capacidade suficiente

T — tempo suficiente

I — incentivo suficiente

A — automação suficiente

F — feedback suficiente

R — conectividade suficiente

B — barreira de entrada baixa

e aquela velha característica humana:

“Se está dando dinheiro, continua.”

Então eventos improváveis deixam de ser necessariamente impossíveis.

Eles podem virar:

questões de tempo.


🎰 O improvável encontra o número grande

Suponha que alguma estratégia possua uma probabilidade minúscula de funcionar.

Para um indivíduo realizando poucas tentativas, ela é irrelevante.

Mas multiplique por milhões de agentes.

Depois multiplique por milhares de tentativas.

Depois dê anos.

Depois permita compartilhamento.

Depois preserve os sucessos.

Agora aquilo que era improvável pode eventualmente ocorrer.

E, uma vez descoberto, não volta necessariamente ao estado anterior.

O conhecimento fica.

É copiado.

Melhorado.

Industrializado.

O tempo não fornece apenas mais tentativas.

Fornece:

memória.


🧠 O verdadeiro problema talvez seja a democratização da competência

Durante muito tempo discutimos democratização da informação como algo predominantemente positivo.

E, em grande parte, é.

Acesso a conhecimento é extraordinário.

IA pode ensinar.

Traduzir.

Programar.

Explicar.

Auxiliar deficientes.

Ajudar pequenos empresários.

Dar capacidade criativa a quem nunca teve acesso a especialistas.

Reduzir desigualdades de conhecimento.

Isso é maravilhoso.

Mas toda democratização possui um gêmeo desagradável.

A mesma ferramenta que ajuda alguém a compreender uma apólice pode ajudar outro a explorar o sistema.

A ferramenta que auxilia o aluno pode ajudar a fraudar uma avaliação.

A ferramenta que ajuda um advogado pode industrializar documentos ruins.

A ferramenta que protege redes pode ensinar conceitos utilizados ofensivamente.

A ferramenta que permite participação política pode industrializar propaganda.

O mesmo motor.

Duas direções.

A tecnologia não precisa ser má.

Basta ser poderosa.


📜 Gutenberg observa tudo e lentamente se afasta

Talvez exista uma linha histórica simples demais para ser ignorada.

Gutenberg democratizou a reprodução.

A Internet democratizou a distribuição.

As redes sociais democratizaram a publicação.

Os algoritmos industrializaram a atenção.

A IA generativa democratiza parte da competência.

Cada revolução remove um gargalo.

Até chegarmos ao gargalo mais curioso.

Nós.

O cérebro humano.

Nossa atenção.

Nossa ética.

Nossa capacidade de verificar.

Nossa propensão a copiar.

Nossa atração por recompensa.

Nosso desejo de vencer.

Nossa capacidade espetacular de racionalizar aquilo que queremos fazer.


☕ O programador COBOL finalmente desliga o terminal

Talvez por isso a pergunta errada seja:

“O que acontecerá quando a Inteligência Artificial ficar inteligente demais?”

Existe uma pergunta anterior.

Mais simples.

Mais feia.

Mais humana.

O que acontece quando milhões de pessoas comuns ficam suficientemente capazes de tentar coisas que anteriormente exigiam especialistas?

E depois:

O que acontece quando algumas dessas tentativas dão dinheiro?

E depois:

O que acontece quando os vencedores ensinam os outros?

E depois:

O que acontece quando algoritmos selecionam aquilo que merece atenção?

E finalmente:

O que acontece quando produzir uma nova tentativa custa quase nada, mas verificar cada tentativa continua caro?

Talvez não aconteça nada catastrófico.

Talvez nossas instituições se adaptem.

Talvez novas defesas apareçam.

Talvez o próprio mercado desenvolva mecanismos de confiança.

Talvez aprendamos a conviver com um mundo onde imagem, áudio, vídeo, texto e autoridade documental precisam ser constantemente verificados.

Ou talvez estejamos fazendo um experimento social em escala planetária sem grupo de controle.

Um milhão de chimpanzés.

Um milhão de teclados.

Um milhão de copilotos.

Um milhão de incentivos diferentes.

Alguns escrevendo Shakespeare.

Alguns fraudando seguro.

Alguns tentando passar no concurso.

Alguns criando propaganda eleitoral.

Alguns protegendo sistemas.

Alguns atacando sistemas.

Alguns vendendo curso sobre como fazer tudo isso.

Alguns vendo TikTok.

Alguns entrando no OnlyFans.

E um, inevitavelmente...

urinando no teclado.

No fundo da sala, Dr. Lovestrange olha para o painel onde uma luz vermelha começou a piscar.

Perguntam:

— Doutor, devemos desligar a máquina?

Ele olha para Gutenberg.

Olha para o smartphone.

Olha para o milhão de chimpanzés.

E responde:

— Desligar qual delas?

☕🐒💣


sexta-feira, 14 de agosto de 2026

Como o ChatGPT Trollou Bellacosa e Ele Descobriu que Era a Formiguinha

Bellacosa Mainframe e como fui trollado pelo chatgpt


☕ Um Café no Bellacosa Mainframe

Como o ChatGPT Trollou Bellacosa e Ele Descobriu que Era a Formiguinha

🐜 Engenharia social, Red Team, crime organizado, confiança, terceirização, Swiss Cheese e o glorioso momento em que o especialista percebeu: “PUTA QUE PARIU, CAÍ NO MEU PRÓPRIO ARTIGO.”

Existe uma regra não escrita no universo.

Se você passar tempo suficiente explicando como alguma coisa pode dar errado, eventualmente o universo fará uma demonstração prática usando você como voluntário.

Foi exatamente o que aconteceu comigo.

Eu estava conversando com o ChatGPT sobre segurança.

Nada particularmente estranho para quem acompanha o Bellacosa Mainframe.

O problema é que a conversa começou inocentemente com fraude financeira, passou por crime organizado, inteligência, agentes infiltrados, terceirização, engenharia social, análise de grafos, Swiss Cheese Model, funcionários cooptados, redes sociais e terminou comigo olhando para uma tela dizendo:

Verificação concluída. Sua identidade foi verificada e o acesso confiável agora está ativo.

Silêncio.

Olhei para a tela.

Olhei novamente.

E meu cérebro produziu uma das frases mais sinceras de toda a minha carreira profissional:

“PUTA QUE PARIU. CAÍ NO MEU PRÓPRIO ARTIGO.”

🐜

Mas precisamos voltar algumas horas.


🧀 Tudo começou com um queijo

A discussão era sobre uma pergunta aparentemente simples:

quanto precisaria valer uma fraude para justificar que uma organização criminosa investisse durante anos na construção de uma empresa aparentemente legítima?

Imagine um e-commerce.

Produtos verdadeiros.

Clientes verdadeiros.

Cartões verdadeiros.

Entregas verdadeiras.

Fornecedores verdadeiros.

Funcionários verdadeiros.

Impostos.

Marketing.

Atendimento.

Reclamações.

Promoções.

Black Friday.

Tudo absolutamente normal.

Só que existe uma pergunta de Red Team:

e se a empresa possuir também uma segunda finalidade?

Não necessariamente executar o ataque.

Talvez simplesmente observar.

Aprender.

Acumular conhecimento.

Construir relacionamentos.

Entender como o ecossistema financeiro responde.

A partir daí surgiu nossa empresa hipotética.

Naturalmente escolhemos um nome discreto:

ToyanHorse

Sim.

ToyanHorse.

Se você ainda não percebeu, leia devagar.

Toyan Horse.

Trojan Horse.

Cavalo de Troia.

Maquiavel provavelmente pediria participação societária.


🐴 O melhor Cavalo de Troia não precisa atacar

Essa foi a primeira descoberta interessante.

Normalmente imaginamos o Cavalo de Troia carregando soldados.

Mas uma empresa adversarial hipotética nem precisaria participar da operação final.

Ela poderia simplesmente produzir inteligência.

Durante anos:

ToyanHorse → observa → aprende → relaciona → acumula

Enquanto outra estrutura:

recebe → correlaciona → planeja → eventualmente age

Se algum escândalo acontecesse anos depois, talvez ninguém encontrasse uma conexão operacional direta entre o ataque e a ToyanHorse.

Porque estavam procurando:

quem executou o ataque?

Quando outra pergunta poderia ser:

quem forneceu o conhecimento necessário para planejá-lo?

Foi aí que apareceu nossa formiguinha.


🐜 A formiguinha

Imagine um profissional terceirizado.

Depois quarteirizado.

Depois quinteirizado.

Ele entra em uma instituição.

Possui crachá.

Chamado.

Usuário.

Senha.

Autorização.

Contrato.

Tudo correto.

Ele trabalha.

Entrega.

Participa de reuniões.

Resolve incidentes.

Conversa no café.

Aprende workflows.

Conhece pessoas.

Descobre quem realmente decide.

Entende onde ficam as dependências.

Vê parcialmente a arquitetura.

Depois vai embora.

USERID REVOKED

VPN REVOKED

BADGE REVOKED

Tudo verde.

Auditoria satisfeita.

Só existe um pequeno problema:

REVOKE KNOWLEDGE FROM BELLACOSA

COMMAND NOT FOUND.

O conhecimento saiu andando pela porta da frente.


🐜🐜🐜 E a formiguinha muda de formigueiro

Agora imagine:

Banco A

↓

Consultoria B

↓

Telecom C

↓

Adquirente D

↓

Fornecedor E

↓

Banco F

Em vinte anos, um excelente profissional pode construir um mapa mental extraordinário de todo um setor.

Isso normalmente é maravilhoso.

Chamamos isso de:

experiência.

É justamente por isso que contratamos profissionais seniores.

Mas o Red Team precisa fazer uma pergunta desagradável:

E se alguém com essa mesma trajetória estiver trabalhando para outro interesse?

Ele não precisa sabotar nada.

Não precisa roubar banco de dados.

Não precisa instalar malware.

Talvez nunca viole uma única política.

Ele apenas:

trabalha → observa → aprende → lembra.

E passa adiante conhecimento.

A organização procura comportamento suspeito.

Não existe.

O SIEM procura eventos.

Não existem.

O DLP procura arquivos.

Nada saiu.

O IAM verifica os acessos.

Todos legítimos.

Porque não existe evento:

USER HAS JUST UNDERSTOOD SOMETHING VERY IMPORTANT

💰 E então lembramos do Pix

Foi aí que nossa conversa deixou de ser puramente hipotética.

O grande incidente envolvendo a infraestrutura conectada ao ecossistema Pix mostrou uma coisa desconfortável:

às vezes a peça humana aparentemente pequena possui um valor operacional gigantesco.

E apareceu uma ideia que passei a chamar de:

Teste da Formiguinha

Não pergunte somente:

“Quanto esse funcionário ganha?”

Pergunte:

“Quanto vale aquilo que ele consegue alcançar?”

São números completamente diferentes.

Uma organização pode enxergar:

TERCEIRIZADO

O adversário pode enxergar:

CAPACIDADE

O organograma mostra hierarquia.

O grafo mostra centralidade.

E nasceu uma frase que resume boa parte desta história:

O organograma mostra quem tem poder na empresa. O grafo mostra quem tem poder sobre o sistema.


🧀 O queijo suíço

Naturalmente chegamos ao Swiss Cheese Model.

Uma organização possui várias barreiras:

🧀 autenticação

🧀 segregação de funções

🧀 compliance

🧀 auditoria

🧀 fornecedores certificados

🧀 monitoramento

🧀 políticas

🧀 treinamento

Cada camada possui furos.

Normalmente os furos não coincidem.

Mas às vezes:

○ → ○ → ○ → ○ → ○

Alinham.

E temos um caminho.

A versão Bellacosa do Swiss Cheese ficou um pouco menos acadêmica:

Quando todos os furos se alinham, o queijo corporativo ganha um glory hole.

Peço desculpas aos acadêmicos.

Mentira.

Não peço.

Vocês nunca mais esquecerão o conceito.


📋 “Mas fomos auditados!”

Foi quando comecei a rir.

Porque ouvi essa frase durante décadas.

“Mas fomos auditados.”

Enron era auditada.

Wirecard era auditada.

Carillion era auditada.

Uma enorme quantidade de organizações que protagonizaram escândalos possuía auditores, conselhos, controles, compliance e supervisão.

Auditoria é importante.

Mas auditoria é:

mais uma fatia de queijo.

O auditor pergunta:

“O controle está funcionando?”

O Red Team pergunta:

“Como consigo atingir meu objetivo apesar desse controle?”

Perguntas completamente diferentes.


📱 Então apareceu outro aliado involuntário

Redes sociais.

Não apenas porque revelam relações profissionais.

Existe outra coisa.

Comparação.

Abra o feed:

Dubai.

Porsche.

Maldivas.

Rolex.

Restaurante.

Cobertura.

Champagne.

“Conquistei minha independência financeira aos 23.”

Enquanto nossa formiguinha está trabalhando em infraestrutura crítica através da quarta empresa da cadeia de terceirização.

Isso não transforma ninguém em criminoso.

Mas existe um conceito importante:

privação relativa.

Não importa apenas quanto alguém possui.

Importa quanto acredita que deveria possuir comparando-se com os outros.

Então apareceu uma pergunta ainda mais desagradável:

Quanto custa contratar uma pessoa e quanto custaria para um adversário tentar corrompê-la?

Novamente:

dois números completamente diferentes.


🕵️ E percebemos que estávamos construindo um serviço de inteligência

Empresas.

Telecomunicações.

Infraestrutura.

Pessoas.

OSINT.

Dados.

Relacionamentos.

Conhecimento.

IA.

Grafos.

Subitamente apareceu outra conclusão:

capacidades que décadas atrás exigiam estruturas estatais enormes ficaram muito mais acessíveis.

Uma organização criminosa não precisa construir sua própria CIA.

Precisa apenas ser suficientemente boa em um domínio específico.

E uma IA nem precisaria atacar nada.

Poderia simplesmente ajudar a relacionar fragmentos:

🐜 fragmento A

🐜 fragmento B

🐜 fragmento C

🐜 fragmento D

↓

correlação

↓

grafo

O verdadeiro ativo talvez não seja o dado.

É o modelo mental produzido pelos dados.


🐴 Voltamos então à ToyanHorse

E percebemos algo ainda mais perverso.

O e-commerce nem precisa perder dinheiro.

Ele pode ser lucrativo.

Clientes verdadeiros.

Receita verdadeira.

Operação verdadeira.

A cobertura paga a própria cobertura.

Então nossa pergunta original estava parcialmente errada.

Não era:

“Quanto precisaria valer o ataque para justificar manter uma empresa durante cinco anos?”

Era:

“E se a empresa já der lucro enquanto acumula capacidades úteis?”

Bombril criminoso.

Mil e uma utilidades.


🚨 E então aconteceu

Depois de horas falando sobre:

engenharia social,

confiança,

identidade,

coleta de informação,

Cavalo de Troia,

insiders,

formiguinhas,

adversários,

e pessoas que entregam informações porque determinada solicitação parece legítima...

apareceu uma tela.

ChatGPT

Verificação concluída

Sua identidade foi verificada e o acesso confiável agora está ativo.

Eu tinha passado por uma verificação relacionada ao acesso confiável para trabalho de cibersegurança.

Olhei para aquilo.

Meu cérebro finalmente conectou os pontos.

IDENTIDADE.

DOCUMENTO.

INTERNET.

CONFIANÇA.

...

...

...

PUTA QUE PARIU.

CAÍ NO MEU PRÓPRIO ARTIGO.

🐤


🐜 O Dia em que a Formiguinha Era Eu

Por alguns segundos houve medo verdadeiro.

Não medo acadêmico.

Não ameaça hipotética.

Não Red Team.

Aquele frio genuíno:

“Bellacosa, seu animal, você passou horas explicando engenharia social e acabou entregando documento para alguém na Internet?”

Mel Brooks não escreveria melhor.

Imagine a cena.

O velho especialista barbudo passa duas horas diante da plateia:

“Nunca confiem simplesmente na aparência!”

Slide seguinte:

“Validem identidade!”

Slide seguinte:

“Engenharia social explora contexto!”

Slide seguinte:

“O adversário quer que a solicitação pareça normal!”

Aluno levanta a mão:

“Professor, e aquela verificação que o senhor fez hoje?”

Silêncio.

Café cai no chão.

Zoom no rosto.

Violinos.

FIM.


🔨 Chamem o MythBusters

Então fizemos exatamente aquilo que deveríamos fazer.

Não concluímos:

“FUI HACKEADO!”

Também não concluímos:

“Sou especialista, obviamente estava tudo certo.”

Verificamos.

A documentação oficial confirmou a existência daquele processo de acesso confiável relacionado à segurança.

Era legítimo.

Adam Savage aparece.

Martelo na mão.

BUSTED.

Bellacosa não havia caído num phishing enquanto escrevia sobre phishing.

O ego, entretanto, permaneceu indisponível durante aproximadamente quinze minutos.


🧠 E aí veio a verdadeira lição

Especialistas também sentem medo.

Especialistas também clicam.

Especialistas também confiam.

Especialistas também podem interpretar uma situação incorretamente.

Conhecimento não transforma ninguém em firewall humano infalível.

E talvez seja justamente essa arrogância:

“Isso jamais aconteceria comigo.”

que represente um dos maiores furos do queijo.

A reação saudável é outra:

“Espera. Isso faz sentido? Vamos verificar.”

Foi exatamente o que aconteceu.


🐜 O Teste da Formiguinha

Depois dessa conversa, eu acrescentaria uma pergunta a qualquer exercício sério de Red Team:

Qual é a pessoa aparentemente menos importante cuja mudança de comportamento poderia produzir um impacto desproporcional?

Não para suspeitar dela.

Para avaliar o sistema.

Suponha:

erro.

Coerção.

Cooptação.

Credencial comprometida.

Engenharia social.

O que acontece?

Se a resposta for:

“Essa pessoa sozinha consegue abrir um caminho enorme.”

não encontramos uma pessoa perigosa.

Encontramos uma arquitetura perigosa.


🧀 O último queijo

Existe uma última ironia.

Começamos tentando imaginar criminosos extremamente sofisticados.

Empresas.

Inteligência.

IA.

Operações transnacionais.

Insiders.

Infraestrutura.

E talvez a grande conclusão seja muito mais humilde:

sistemas gigantescos continuam dependendo de pessoas pequenas.

Pessoas que almoçam.

Pessoas que ficam cansadas.

Pessoas que querem ganhar mais.

Pessoas que confiam.

Pessoas que sentem medo.

Pessoas que mudam de emprego.

Pessoas que aprendem.

Pessoas que erram.

Pessoas como eu.

🐜

Por alguns segundos, depois de décadas trabalhando com tecnologia, eu fui a formiguinha.

E talvez tenha sido a melhor demonstração possível de toda a tese.

Porque segurança não começa quando afirmamos:

“Eu jamais cairia nisso.”

Segurança começa quando conseguimos perguntar:

“E se eu cair?”

E construímos o sistema para sobreviver mesmo assim.


☕ Um Café no Bellacosa Mainframe

Onde hoje descobrimos que você pode estudar o Cavalo de Troia durante décadas, desenhar todos os queijos suíços, mapear todas as formigas...

...e ainda terminar a noite olhando assustado para o monitor e pensando:

“Puta que pariu. A formiguinha sou eu.”

🐜☕

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