Do Z3R0 ao HERO — Quando o T-800 Auditou o Datacenter, Desconfiou de Igor e Descobriu que Red Team Não É Só Uma Caveira no Terminal

 

Bellacosa Mainframe e a auditoria do T800

☕ Um Café no Bellacosa Mainframe

Do Z3R0 ao HERO — Quando o T-800 Auditou o Datacenter, Desconfiou de Igor e Descobriu que Red Team Não É Só Uma Caveira no Terminal

Ou: o programador COBOL queria saber se era Blue ou Red, o Exterminador respondeu que primeiro ele precisava descobrir quem tinha UPDATE na tabela de pagamentos — e Igor, naturalmente, sugeriu colocar a senha no nome do dataset para não esquecê-la.

MODELO T-800 — STATUS: OPERACIONAL
MISSÃO ORIGINAL: localizar Sarah Connor.
MISSÃO ATUALIZADA: localizar o proprietário da conta técnica com privilégio excessivo.
AVISO: “HASTA LA VISTA, SEGREGAÇÃO DE FUNÇÕES INEXISTENTE.”

O universo da segurança da informação adora cores. Há o Red Team, que pensa como um adversário; o Blue Team, que protege, monitora e responde; e o Purple Team, que tenta impedir que os dois passem a reunião inteira discutindo quem ganhou a bandeirinha do CTF.

Mas, antes que alguém instale uma distribuição cheia de ferramentas, abra três terminais pretos e declare-se “hacker ético” no LinkedIn, convém uma pequena verdade digna de uma sala de máquinas: segurança não começa pelo ataque. Começa por compreender o sistema que se pretende proteger ou avaliar.

Para o programador COBOL iniciante, isso é quase uma boa notícia. Você já está entrando por uma porta que muita gente só encontra depois de anos: a porta dos processos críticos, dos dados que realmente importam, dos controles de acesso, dos jobs que não podem falhar e das mudanças que precisam deixar rastro. No mundo em que uma API moderna conversa com uma fila, que conversa com CICS, que conversa com Db2, que conversa com um batch de quarenta anos ainda pagando salário, ninguém pode tratar segurança como detalhe de rodapé.

1. O primeiro diagnóstico do T-800: Pentest, Red Team e Blue Team não são a mesma coisa

Um pentest é uma avaliação autorizada, normalmente com escopo definido, para encontrar e validar vulnerabilidades. Pode ser um portal, uma API, uma rede, um aplicativo móvel ou um ambiente cloud. A pergunta é direta: “que falhas existem aqui, qual o impacto e como corrigir?”

O Red Team vai além: simula, de forma controlada, um adversário tentando atingir um objetivo relevante para o negócio. Não está interessado em colecionar cinquenta alertas coloridos. Está interessado em testar uma hipótese: seria possível alguém alcançar um ativo crítico? Os controles perceberiam? A organização conteria a atividade a tempo?

Já o Blue Team vive no mundo real. Ele administra ou acompanha controles, investiga alertas, endurece configurações, gerencia vulnerabilidades, melhora logs, responde a incidentes e tenta impedir que o mês da empresa acabe em reunião de crise com jurídico, diretoria e café frio.

Time	Pergunta principal	Entrega útil
Pentest	“Que vulnerabilidades existem no escopo?”	Achados priorizados, evidências e recomendações
Red Team	“Um adversário plausível atingiria o objetivo?”	Cadeia de risco simulada e avaliação de controles
Blue Team	“Como prevenimos, detectamos e respondemos?”	Controles, telemetria, investigação e recuperação
Purple Team	“O que aprendemos juntos?”	Correções testadas e detecções melhores

O Red não existe para humilhar o Blue. Se a operação termina com “entramos e vocês não viram”, mas ninguém melhora log, regra, privilégio ou processo, a empresa acabou de pagar por um trailer de filme, não por segurança.

2. O erro que termina em ABEND: ferramenta antes de fundamento

Ferramenta é multiplicador. Multiplica velocidade quando há conhecimento; multiplica confusão quando não há.

Um scanner pode apontar uma versão vulnerável. Isso ainda não responde se o serviço está exposto, se a função vulnerável está ativa, se há rota de rede, se o controle compensatório existe ou se o impacto é relevante. O profissional precisa validar a hipótese sem provocar dano.

É igual ao COBOL. Decorar READ, WRITE e PERFORM não torna ninguém dono do processamento. É preciso entender arquivo, chave, status, commit, lock, dados de entrada, regra de negócio e consequência de uma atualização. Segurança é a mesma conversa, apenas com o T-800 olhando por cima do ombro.

Os fundamentos indispensáveis são:

• Redes: DNS, TCP/IP, HTTP/S, TLS, proxy, VPN, roteamento, portas e segmentação.

• Sistemas operacionais: usuários, grupos, permissões, processos, serviços, logs, atualizações e administração.

• Programação: lógica, variáveis, validação, tratamento de erro, bibliotecas, APIs e leitura de código.

• Dados: modelagem, autenticação no banco, permissões, cópias, backups, trilhas de auditoria e mascaramento.

• Identidade: autenticação não é autorização; saber quem entrou não responde ao que essa pessoa pode fazer.

• Negócio: um ativo crítico não é necessariamente o servidor mais caro; pode ser uma tabela, uma interface, uma conta técnica ou uma etapa invisível do processo.

Curiosidade de sala de máquinas

O mainframe ensinou há décadas uma lição que a nuvem redescobre quase todo ano: controle de acesso é uma política, não uma tela de login. Um ID autenticado pode continuar perigosíssimo se tiver autoridade excessiva, grupos herdados, permissões antigas ou uso compartilhado. RACF não lê pensamentos, mas obriga a fazer a pergunta certa: quem tem acesso a quê, por qual motivo, e com qual registro?

3. A tríade CIA: não é agência secreta, embora Igor tivesse gostado da ideia

Segurança protege, no mínimo, três propriedades:

• Confidencialidade: somente pessoas e processos autorizados veem a informação.

• Integridade: dados e transações não são alterados indevidamente.

• Disponibilidade: serviços e informações permanecem acessíveis quando necessários.

Pense num pagamento. Se alguém vê o dado de outro cliente, há quebra de confidencialidade. Se consegue alterar a conta favorecida, há quebra de integridade. Se o sistema de pagamentos fica indisponível no fechamento, há quebra de disponibilidade.

E o caso real quase sempre mistura tudo. Uma credencial comprometida pode permitir leitura indevida; a mesma conta, com privilégio demais, pode alterar uma regra; a tentativa de conter o problema pode derrubar um serviço. Segurança não é uma caixinha isolada. É o conjunto inteiro do processo sob pressão.

4. Red Team profissional: o atacante autorizado que sabe a hora de parar

O Red Team avalia caminhos, não apenas máquinas. Dependendo do escopo formal, pode testar exposição externa, aplicações, APIs, configurações, identidade, segmentação, processos, fornecedores e aspectos físicos. A palavra que mantém tudo do lado certo é autorização.

Antes de qualquer exercício sério devem existir regras de engajamento: objetivo, período, ativos permitidos, sistemas proibidos, limites de impacto, contatos de emergência, tratamento de evidências, dados que não podem ser acessados e critério de parada.

“Try harder” é excelente para o laboratório. Em produção, a tradução profissional é: pare quando a evidência já prova o risco. Não se demonstra que um backup está vulnerável apagando-o. Não se demonstra que dados pessoais podem ser acessados copiando uma base inteira. Não se demonstra indisponibilidade derrubando a folha de pagamento.

O objetivo é obter evidência mínima, confiável e reproduzível. O T-800 chama isso de eficiência. O jurídico chama de sobrevivência.

5. Blue Team: o turno da madrugada, os logs e a pergunta que ninguém queria receber

Blue Team não é um analista hipnotizado por um painel cheio de alertas. É uma combinação de capacidades: monitoramento, engenharia de detecção, resposta a incidentes, gestão de vulnerabilidades, hardening, segurança de endpoints, cloud, aplicações, identidade, backups e continuidade.

Uma defesa madura distingue quatro coisas:

1. Evento: algo aconteceu; um login, uma alteração, uma conexão.

2. Alerta: uma regra considerou o evento suspeito.

3. Incidente: a investigação confirmou atividade indevida ou dano.

4. Crise: o impacto ultrapassou a capacidade normal de resposta e exige coordenação executiva, legal ou operacional.

Confundir tudo gera dois desastres clássicos: pânico por qualquer alerta ou silêncio até a manchete chegar. Logs são fundamentais porque sem eles a organização fica discutindo memória e impressão. Com registros adequados, ela reconstrói fatos.

Para quem trabalha em z/OS, isso tem sabor familiar. SMF, RACF, logs de CICS, Db2 e auditorias não são burocracia arqueológica: são peças da história que você precisará contar quando algo parecer estranho.

6. Purple Team: quando o treinamento deixa de ser guerra civil

Purple Team é colaboração deliberada. O Red apresenta uma simulação autorizada ou um comportamento relevante; o Blue observa a telemetria, avalia se houve alerta, investiga e propõe melhoria. Depois ocorre reteste.

Exemplo: um exercício mostra que uma alteração sensível em uma conta técnica não gerou alerta útil. A correção pode envolver revisão de privilégio, registro adicional, regra de correlação, aprovação de mudança e um playbook para investigação. O reteste comprova se a defesa agora enxerga o comportamento.

Não importa qual ferramenta foi usada. Importa se a empresa consegue detectar o comportamento. É por isso que o MITRE ATT&CK é tão útil: ele fornece uma linguagem para falar de objetivos e técnicas adversárias sem reduzir a discussão a uma marca de ferramenta ou a um comando da moda.

7. O mapa de carreira: do Z3R0 ao profissional confiável

Não existe atalho, mas há sequência melhor que sair colecionando cursos.

Passo 1 — Aprenda o caminho dos dados

Entenda uma transação de ponta a ponta. Um navegador chama uma API; a API autentica o usuário, consulta uma base ou um serviço corporativo, grava um log e devolve uma resposta. Pergunte em cada etapa: onde há identidade? Onde há autorização? Onde há dado sensível? O que é registrado? Quem administra?

Passo 2 — Construa um laboratório isolado

Use apenas ambientes feitos para estudo ou sistemas próprios. Não precisa de um datacenter da Skynet. Uma máquina virtual, uma aplicação de treinamento, um serviço de logs e controles simples já permitem exercitar observação, documentação, correção e reteste.

Monte sempre os dois lados: uma aplicação ou serviço intencionalmente frágil e a visibilidade defensiva correspondente. A grande lição não é “como entrar”; é “que evidência isso deixou e como eu deveria ter percebido?”

Passo 3 — Aprenda aplicações e APIs

Aplicações modernas concentram falhas que scanners podem não compreender: autorização inadequada, regra de negócio frágil, exposição excessiva de dados, integração confusa e validação só no navegador.

Exemplo seguro: se uma pessoa autenticada consegue acessar uma fatura que não lhe pertence trocando apenas um identificador, o defeito é de autorização. O sistema confirmou “quem é você?”, mas esqueceu de confirmar “você pode ver isto?”. O remédio não é apenas esconder o campo na tela; é validar a permissão no servidor, registrar tentativas e revisar o modelo de acesso.

Passo 4 — Estude identidade, cloud e DevSecOps

Hoje o perímetro é móvel. Usuários acessam SaaS, APIs usam tokens, pipelines implantam infraestrutura e contas de serviço conversam com múltiplos sistemas. Um segredo exposto, uma permissão IAM excessiva ou uma conta técnica sem dono podem ser mais graves que uma porta aberta.

O bom profissional pergunta: qual identidade executa isso? Qual privilégio ela possui? O que aconteceria se fosse usada indevidamente? Onde está o log? Há rotação de segredo? Existe menor privilégio?

Passo 5 — Escolha uma profundidade, mantenha a largura

Você pode especializar-se em segurança ofensiva, SOC, resposta a incidentes, AppSec, GRC, cloud ou mainframe. O formato ideal é o “T”: profundidade em uma área, entendimento amplo das demais.

Um programador COBOL pode construir uma especialidade particularmente rara: segurança de aplicações e integrações híbridas. Quando a frente moderna conversa com CICS, Db2, MQ, IMS, batch e arquivos críticos, entender os dois lados é uma vantagem enorme. A porta de entrada pode ser uma API; o cofre pode estar no backend legado.

8. CVE não é automaticamente risco — e scanner não é oráculo

Uma CVE é identificação pública de uma vulnerabilidade. Ela pode ser importante, mas não substitui análise. Para priorizar, considere exposição, pré-requisitos, valor do ativo, controles existentes e impacto.

Uma falha moderada em um portal público que expõe dados pessoais pode ser mais urgente que uma falha crítica em ambiente isolado, sem rota de rede e sem uso da função vulnerável. Risco é a combinação de probabilidade e impacto, não um número piscando em vermelho.

O relatório útil traduz isso. Em vez de “corrigir vulnerabilidade”, ele diz que ativo foi afetado, por que importa, como o controle falhou, qual equipe pode corrigir, que medida temporária reduz risco e como retestar.

9. O artefato mais subestimado: o relatório

Um relatório ruim é uma coleção de prints com caveira. Um relatório bom é uma ponte entre segurança e mudança real.

Ele deve explicar o cenário, evidência, impacto plausível, controles esperados, lacuna observada, recomendação prática e prioridade. Deve falar para executivos sem esconder a parte técnica e falar para técnicos sem transformar a conclusão em poesia corporativa.

Por exemplo: “Revisar a autorização de alterações de favorecido, separar criação de aprovação, limitar privilégios da conta técnica, registrar mudanças críticas e retestar o fluxo.” Isso dá à empresa um caminho. “Melhorar a segurança” só dá vontade de pedir mais café.

Epílogo — O T-800 fecha o ISPF

Ao final da auditoria, Igor pergunta se Red Team significa usar vermelho no terminal. O T-800 olha para a tela, identifica uma conta compartilhada, três permissões herdadas e um backup nunca restaurado em teste. Depois responde, com a ternura de uma prensa hidráulica:

“A COR É IRRELEVANTE. A AUSÊNCIA DE EVIDÊNCIA, NÃO.”

Ser Blue, Red ou Purple não é escolher uma fantasia. É escolher uma responsabilidade. O Red testa se a defesa resiste; o Blue constrói e opera essa defesa; o Purple garante que o aprendizado não morra no relatório. E o profissional que começa em COBOL traz algo precioso para todos eles: a noção de que sistemas importam porque processos e pessoas dependem deles.

Estude fundamentos. Pratique somente em ambientes autorizados. Aprenda a ler código, logs, permissões e fluxos de negócio. Respeite escopo. Documente bem. E desconfie de toda conta técnica cujo responsável seja descrito como “sempre foi assim”.

Porque, como o T-800 aprendeu naquele turno no datacenter, o futuro não é uma guerra entre máquinas e humanos. É uma planilha de acessos sem dono, uma API sem autorização e Igor dizendo: “Doutor, eu deixei a senha em comentários para facilitar a manutenção.”

 

Bellacosa Mainframe e o prenda-me se for capaz ia e ibm z17 contra fraudes

☕ Um Café no Bellacosa Mainframe

Prenda-me se For Capaz — Quando o IBM z17 Colocou uma IA na Alfândega da Transação e Mandou a Fraude Mostrar o Passaporte

Ou: Frank Abagnale entrou no banco vestido de piloto, o programa COBOL consultou o histórico, o Telum II calculou um score em menos de um milissegundo — e o Spyre ficou no andar de cima investigando por que o cheque tinha sido emitido por uma companhia aérea que não existia

Há uma cena clássica em qualquer bom filme de vigaristas.

O sujeito entra pela porta principal usando um uniforme impecável. Caminha como se conhecesse o prédio, cumprimenta o segurança pelo nome, segura uma pasta de couro e parece tão legítimo que ninguém se lembra de fazer a pergunta fundamental:

— Quem é você?

Frank Abagnale Jr., personagem central de Catch Me If You Can, construiu sua carreira cinematográfica exatamente nesse intervalo entre parecer legítimo e alguém conferir os dados.

Ele não precisava derrubar o sistema bancário. Não precisava explodir o datacenter, quebrar a criptografia ou fazer engenharia reversa no CICS.

Precisava apenas parecer verdadeiro durante tempo suficiente.

Fraude funciona assim.

Ela raramente entra pela janela usando máscara preta e carregando um saco com cifrão. Normalmente chega pela porta da frente com:

• nome aparentemente correto;

• cartão válido;

• senha correta;

• documento convincente;

• dispositivo conhecido;

• comportamento quase normal;

• história razoavelmente plausível.

O problema da segurança moderna não é encontrar aquilo que parece completamente falso. Isso costuma ser fácil.

O problema é identificar aquilo que possui 97% de verdade e esconde a fraude nos 3% restantes.

E o banco precisa perceber isso antes que a autorização seja concluída.

Não amanhã.

Não depois do fechamento do movimento.

Não quando o cliente ligar informando que nunca comprou vinte televisores em Vladivostok.

A decisão precisa acontecer enquanto a transação ainda está atravessando o corredor.

É nesse ponto que entra o IBM z17, seu processador Telum II, o acelerador Spyre e uma ideia aparentemente simples, mas arquiteturalmente poderosa:

Em vez de mandar os dados até a inteligência artificial, colocamos a inteligência artificial perto dos dados.

Puxe uma cadeira, abra o ISPF e peça mais um café. Hoje acompanharemos uma transação bancária como se ela fosse Frank Abagnale tentando atravessar a alfândega vestido de piloto.

---

1. A fraude não começa com um crime: começa com uma história

Imagine que um cliente normalmente faça compras assim:

• supermercados em Itatiba;

• combustível duas vezes por mês;

• serviços digitais recorrentes;

• pequenas compras durante o dia;

• um restaurante aos sábados;

• nenhuma transação internacional recente.

Subitamente aparece uma tentativa de compra:

• três notebooks;

• às 3h17 da madrugada;

• em outro país;

• utilizando um dispositivo nunca visto;

• depois de quatro tentativas recusadas;

• com endereço de entrega diferente;

• poucos minutos depois de uma alteração cadastral.

Nenhuma dessas características, sozinha, prova uma fraude.

Pessoas viajam.

Pessoas compram notebooks.

Pessoas trocam de celular.

Pessoas esquecem senhas.

Pessoas compram presentes de madrugada porque a insônia também participa da economia mundial.

Entretanto, quando combinamos todos os sinais, surge uma história estranha.

É exatamente esse tipo de relação que um modelo de machine learning procura aprender.

Ele não está buscando apenas uma regra rígida como:

SE VALOR > 10000
    ENTÃO RECUSAR

Ele tenta responder uma pergunta mais sofisticada:

Considerando dezenas ou centenas de características, o quanto esta transação se parece com as fraudes que observamos anteriormente?

A resposta geralmente não é “sim” ou “não”.

É um score.

Por exemplo:

RISCO-DE-FRAUDE = 0,91

Isso significa que o modelo encontrou uma combinação fortemente associada a comportamento fraudulento. Não significa que ele tenha presenciado o crime, interrogado o suspeito e recuperado o dinheiro numa mala escondida no aeroporto.

A IA não produz uma sentença judicial.

Ela produz evidência probabilística para ajudar o sistema a tomar uma decisão.

Esse será nosso primeiro ensinamento para o programador COBOL iniciante:

Machine learning não elimina a lógica de negócio. Ele acrescenta uma nova informação à lógica de negócio.

---

2. Treinamento e inferência: a escola e a prova oral

Antes de entender o Telum II, precisamos separar duas fases frequentemente misturadas.

Treinamento

Durante o treinamento, apresentamos ao modelo dados históricos:

• compras legítimas;

• fraudes confirmadas;

• contestações;

• chargebacks;

• dispositivos comprometidos;

• contas invadidas;

• identidades roubadas;

• comportamentos considerados normais;

• comportamentos considerados suspeitos.

O modelo tenta encontrar relações matemáticas entre as características e os resultados conhecidos.

É como mostrar milhares de cheques a um investigador e dizer:

— Estes eram legítimos. Estes eram falsificados. Descubra os padrões.

O treinamento pode ser computacionalmente pesado. Pode utilizar GPUs, plataformas de ciência de dados, clusters, ambientes cloud ou infraestrutura especializada.

Esse trabalho não precisa acontecer dentro da transação bancária.

Nenhum cliente aceitará esperar três semanas diante da maquininha enquanto o modelo reaprende a história do sistema financeiro.

Inferência

Depois de treinado, o modelo pode receber uma nova transação e aplicar aquilo que aprendeu.

Essa aplicação é chamada de inferência.

O modelo recebe informações como:

VALOR
HORARIO
LOCALIZACAO
TIPO-DE-ESTABELECIMENTO
IDADE-DA-CONTA
DISPOSITIVO
QUANTIDADE-DE-TENTATIVAS
MEDIA-DE-GASTOS
DISTANCIA-DA-ULTIMA-COMPRA

E devolve algo como:

SCORE-DE-RISCO = 0,8734

Treinamento é a escola de investigadores.

Inferência é o momento em que o inspetor olha para o passaporte, compara os sinais e decide se chamará o supervisor.

O IBM z17 é especialmente interessante nessa segunda fase: executar a inferência rapidamente, em grande escala e suficientemente perto da aplicação transacional para que o resultado ainda possa influenciar a autorização.

---

3. O que acontece quando o cartão encosta na maquininha?

Vamos acompanhar nossa transação passo a passo.

A implementação real varia entre instituições, bandeiras, adquirentes e sistemas, mas o fluxo conceitual pode ser representado assim:

MAQUININHA
    ↓
ADQUIRENTE
    ↓
REDE OU BANDEIRA
    ↓
BANCO EMISSOR
    ↓
SISTEMA DE AUTORIZAÇÃO
    ↓
ANÁLISE DE RISCO
    ↓
APROVAR, NEGAR OU DESAFIAR

Dentro do banco, o sistema pode consultar:

• situação do cartão;

• senha ou credencial;

• saldo;

• limite;

• bloqueios;

• restrições geográficas;

• quantidade de operações recentes;

• perfil do cliente;

• regras antifraude;

• resultado de modelos de IA.

Em um ambiente mainframe, partes desse processamento podem envolver:

• CICS;

• IMS;

• Db2;

• VSAM;

• IBM MQ;

• programas COBOL;

• serviços Java;

• APIs;

• z/OS Connect;

• componentes Linux executando no IBM Z;

• rotinas de segurança;

• mecanismos de criptografia;

• serviços de inferência.

O programa COBOL não precisa “virar uma IA”.

Ele pode continuar fazendo aquilo que sempre fez muito bem: orquestrar regras de negócio, validar campos, controlar estados, registrar decisões e preservar a integridade da transação.

A diferença é que agora ele pode receber um score calculado por um modelo.

Conceitualmente, nossa lógica poderia se parecer com isto:

       EVALUATE TRUE
           WHEN CARTAO-BLOQUEADO
               MOVE '05' TO CODIGO-RESPOSTA

           WHEN SCORE-FRAUDE > 900
               MOVE 'N' TO AUTORIZAR
               MOVE 'FRAUDE ALTA' TO MOTIVO-DECISAO

           WHEN SCORE-FRAUDE > 650
               MOVE 'S' TO EXIGIR-AUTENTICACAO
               MOVE 'VALIDACAO ADICIONAL'
                 TO MOTIVO-DECISAO

           WHEN LIMITE-DISPONIVEL < VALOR-COMPRA
               MOVE 'N' TO AUTORIZAR
               MOVE 'LIMITE INSUFICIENTE'
                 TO MOTIVO-DECISAO

           WHEN OTHER
               MOVE 'S' TO AUTORIZAR
               MOVE 'APROVADA' TO MOTIVO-DECISAO
       END-EVALUATE.

Naturalmente, um sistema bancário real será muito mais sofisticado. A ordem das verificações, os limites, as exceções e as regras serão governados por políticas específicas.

Mas o princípio é este:

IA calcula o risco.
A aplicação toma a decisão.

Essa separação é saudável.

O modelo não deve possuir autoridade ilimitada simplesmente porque tem “inteligência artificial” no nome.

---

4. O orçamento de tempo da transação

Quando alguém lê que o z17 pode executar inferências com tempo de resposta inferior a 1 milissegundo, pode imaginar que toda a compra será concluída nesse intervalo.

Não é isso.

Um milissegundo é:

[
1\text{ ms} = 0{,}001\text{ segundo}
]

O número divulgado refere-se ao processamento da inferência no cenário medido, não ao tempo total da transação desde a maquininha até a resposta final.

A operação completa ainda pode incluir:

• transmissão pelas redes;

• validação criptográfica;

• leitura de bancos de dados;

• execução de regras;

• verificação de limite;

• gravação de logs;

• atualização de saldos;

• journaling;

• construção da resposta;

• retorno à maquininha.

Pense na transação como um filme de duas horas e na inferência como uma cena importante dentro dele.

O Telum II não precisa filmar o longa-metragem inteiro em um milissegundo. Ele precisa executar sua cena sem estourar o cronograma da produção.

Isso é fundamental porque toda aplicação crítica possui um orçamento de latência.

Se a autorização inteira precisa responder em determinado intervalo, não podemos entregar quase todo esse orçamento a um modelo remoto.

Uma chamada externa pode exigir:

1. montar uma requisição;

2. serializar os dados;

3. criptografar;

4. atravessar a rede;

5. autenticar no serviço;

6. entrar numa fila;

7. executar a inferência;

8. montar a resposta;

9. retornar pela rede;

10. tratar timeouts e erros.

Mesmo que a média seja boa, há uma pergunta mais importante:

O comportamento continuará previsível durante os picos?

Em ambiente crítico, não basta dizer que a resposta média foi de 5 ms.

Precisamos conhecer:

• percentil 95;

• percentil 99;

• percentil 99,9;

• comportamento em saturação;

• impacto sobre outros workloads;

• tempo máximo aceitável;

• estratégia de fallback;

• resultado quando o serviço não responder.

Uma média bonita pode esconder um pequeno grupo de respostas terrivelmente lentas.

E o sistema bancário não pode dizer ao comerciante:

— Tivemos um excelente tempo médio hoje. Infelizmente, sua venda caiu no percentil azarado.

---

5. Telum II: o investigador sentado dentro do banco

O Telum II é o processador que equipa o IBM z17 e inclui a segunda geração do acelerador integrado de IA.

A palavra mais importante é “integrado”.

A inferência pode acontecer muito perto da carga transacional, sem depender de um acelerador remoto pendurado do outro lado de uma rede.

Segundo a IBM, o acelerador do Telum II oferece quatro vezes a capacidade computacional da geração anterior, chegando a 24 TOPS, além de suporte a INT8 e melhorias destinadas a ampliar a variedade de modelos executáveis. O processador também trabalha com caches maiores, melhorias de roteamento e uma DPU destinada a auxiliar operações de entrada e saída. IBM Telum II.

O que são TOPS?

TOPS significa trillions of operations per second, ou trilhões de operações por segundo.

É uma medida da capacidade computacional do acelerador.

Entretanto, TOPS não contam toda a história.

Dois aceleradores com números semelhantes podem produzir resultados diferentes devido a:

• arquitetura;

• precisão numérica;

• eficiência do compilador;

• movimentação de dados;

• memória;

• cache;

• tipo do modelo;

• tamanho do lote;

• utilização dos núcleos;

• integração com a aplicação.

É como comparar dois restaurantes apenas pelo número de fogões. O resultado também depende da cozinha, dos ingredientes, dos garçons e de alguém lembrar que o cliente pediu o bife sem cebola.

Por que INT8 importa?

Modelos de IA podem trabalhar com diferentes precisões numéricas.

INT8 utiliza números inteiros de oito bits. Em muitos cenários de inferência, isso permite:

• representar os parâmetros com menos espaço;

• movimentar menos dados;

• executar mais operações;

• consumir menos energia;

• aumentar o throughput.

Essa redução de precisão precisa ser validada para garantir que o modelo continue suficientemente acurado.

Não adianta tornar a inferência quatro vezes mais rápida se ela passar a confundir Frank Abagnale com o gerente da agência.

---

6. Spyre: a equipe de inteligência no andar de cima

Se o Telum II é o agente posicionado diretamente no balcão de imigração, o Spyre é uma equipe adicional de inteligência.

O IBM Spyre Accelerator é fornecido em placas PCIe e possui 32 núcleos de aceleração por chip. Várias placas podem ser combinadas para atender cargas maiores. O produto tornou-se disponível para IBM z17 e LinuxONE 5 em outubro de 2025. Anúncio oficial do Spyre.

Ele foi pensado para complementar o acelerador do Telum II em cenários como:

• modelos maiores;

• vários modelos trabalhando conjuntamente;

• IA generativa;

• modelos de linguagem;

• aplicações multimodais;

• assistentes;

• agentes de IA;

• análise de dados estruturados e textuais.

Imagine uma transação suspeita.

O Telum II pode executar rapidamente o modelo preditivo principal:

Risco calculado: 78%.

Uma arquitetura mais sofisticada pode combinar outros modelos:

• um modelo para o comportamento do dispositivo;

• outro para identidade;

• outro para lavagem de dinheiro;

• um encoder examinando descrições textuais;

• um modelo avaliando relações entre contas;

• um sistema generativo produzindo um resumo para o analista.

Isso é chamado de abordagem multimodelo ou, em certos contextos, ensemble.

O benchmark dos 450 bilhões de inferências antifraude não deve ser apresentado como resultado obrigatório da soma Telum II mais Spyre.

A alegação foi originalmente associada ao acelerador integrado do Telum II. O Spyre amplia a capacidade e o repertório do sistema, principalmente para modelos mais complexos e novas cargas de IA.

Em resumo:

TELUM II
Inferência transacional rápida, integrada e previsível.

SPYRE
Capacidade complementar para modelos maiores, múltiplos e generativos.

Os dois podem trabalhar dentro da mesma estratégia, mas não são peças idênticas.

---

7. Cinco milhões por segundo não são 450 bilhões por dia

Agora chegamos ao Easter egg matemático escondido no roteiro.

Originalmente diziamos que o z17 podia processar até 5 milhões de inferências por segundo, equivalentes a mais de 450 bilhões por dia.

Vamos convocar o programa COBOL da contabilidade:

[
5.000.000 \times 86.400 = 432.000.000.000
]

Um dia possui 86.400 segundos.

Portanto, cinco milhões de inferências por segundo equivalem a 432 bilhões por dia.

Para chegar a 450 bilhões, precisaríamos de aproximadamente:

[
450.000.000.000 \div 86.400
= 5.208.333
]

Ou cerca de 5,21 milhões de inferências por segundo.

Isso não significa necessariamente que a IBM tenha cometido um erro.

A IBM apresenta números arredondados e indicadores derivados de cenários específicos:

• até 5 milhões de inferências por segundo;

• até 450 bilhões de inferências por dia;

• resposta de aproximadamente 1 ms ou inferior, dependendo da declaração.

O erro aparece quando alguém liga as duas frases com “ou seja”, transformando indicadores de benchmark em uma conversão matemática exata.

Uma formulação mais segura seria:

O IBM z17 pode alcançar até 5 milhões de inferências por segundo em determinado cenário e, segundo outro indicador divulgado pela IBM, até 450 bilhões de inferências por dia.

Curiosidade para o programador iniciante: sempre desconfie de expressões como:

• “ou seja”;

• “equivale a”;

• “portanto”;

• “isso representa”.

Elas parecem conectores inocentes, mas frequentemente escondem o exato lugar onde marketing, arredondamento e matemática decidiram falsificar um cheque juntos.

---

8. O que o benchmark realmente mediu?

O número de 450 bilhões por dia não caiu do céu diretamente na capa de uma revista.

Segundo a metodologia publicada pela IBM, o resultado foi extrapolado de testes internos com:

• hardware IBM tipo 9175;

• modelo LSTM sintético para detecção de fraude em cartões;

• batch size de 160;

• ambientes Red Hat Enterprise Linux e z/OS;

• z/OS Container Extensions;

• configuração específica de CPUs, IFLs, zIIPs e memória.

A IBM também informa claramente que os resultados podem variar. Metodologia do benchmark do z17.

O que é LSTM?

LSTM significa Long Short-Term Memory.

É um tipo de rede neural recorrente desenvolvido para trabalhar com sequências e dependências temporais.

Em fraude, isso pode ser útil porque o significado de uma transação depende frequentemente daquilo que aconteceu antes.

Exemplo:

10:01 — compra de R$ 25 em Itatiba
10:04 — compra de R$ 19 em Itatiba
10:07 — compra de R$ 12.000 em Tóquio

A última transação não é suspeita apenas pelo valor. Ela é suspeita pela relação temporal e geográfica com as anteriores.

Modelos atuais podem empregar outras arquiteturas, mas a LSTM continua sendo uma referência útil para determinados problemas sequenciais.

O que é batch size?

Batch size é a quantidade de amostras processadas conjuntamente.

No teste divulgado, o lote era de 160 inferências.

Isso ajuda o acelerador a utilizar melhor seus recursos, assim como uma transportadora consegue mover caixas com mais eficiência quando carrega um caminhão inteiro em vez de enviar um veículo para cada pacote.

Entretanto, batching cria uma consideração importante:

• throughput mede quanto trabalho total é concluído;

• latência mede quanto tempo cada solicitação espera e leva para ser respondida.

Grandes lotes podem aumentar o throughput, mas, dependendo da implementação, também podem fazer uma solicitação aguardar o lote ser formado.

Por isso, nunca analise apenas um número.

Pergunte:

• Qual era o modelo?

• Qual era o tamanho do lote?

• Quantas threads foram usadas?

• Qual era a configuração?

• A latência apresentada é média ou percentil?

• O resultado foi medido ou extrapolado?

• Havia carga transacional concorrente?

• O modelo era real ou sintético?

Essa é uma dica de ouro para qualquer benchmark, não apenas de mainframe.

---

9. Inferência não é sinônimo de transação

Outra armadilha está na palavra “operação”.

Quando ouvimos “450 bilhões de operações de inferência”, é tentador imaginar 450 bilhões de compras analisadas.

Mas uma transação pode executar vários modelos:

MODELO 1 — fraude do cartão
MODELO 2 — risco do dispositivo
MODELO 3 — identidade comprometida
MODELO 4 — localização anômala
MODELO 5 — lavagem de dinheiro
MODELO 6 — conta-laranja

Uma única compra poderia gerar seis inferências.

Logo:

1 transação ≠ obrigatoriamente 1 inferência

Também é possível processar inferências em lotes ou utilizar modelos diferentes conforme o tipo de operação.

O número demonstra capacidade de execução de modelos. Não deve ser convertido automaticamente em quantidade de cartões, clientes ou compras.

É como olhar o contador de instruções executadas pelo processador e concluir que cada instrução representa um cliente atendido.

O COBOLzeiro olha para isso, toma um gole de café e pergunta:

— Onde está o copybook com a definição dessa unidade?

Pergunta correta.

---

10. “Levar a IA até os dados” não significa eliminar toda movimentação

Uma das frases mais fortes da apresentação do z17 é a ideia de executar IA onde os dados residem.

Mas precisamos interpretá-la corretamente.

Não significa que nenhum byte jamais se mova.

Dentro do sistema ainda haverá:

• leitura de registros;

• acesso a memória;

• comunicação entre componentes;

• preparação das variáveis;

• busca de características;

• passagem de parâmetros;

• gravação do resultado.

O que pode ser evitado é a necessidade de enviar a transação para um serviço remoto de inferência, fora do ambiente em que a aplicação crítica está sendo executada.

Isso reduz:

• dependência da rede;

• latência externa;

• serialização;

• pontos adicionais de falha;

• exposição de dados sensíveis;

• fronteiras operacionais;

• complexidade de auditoria.

Compare os dois caminhos.

Inferência remota

COBOL/CICS
    ↓
API
    ↓
GATEWAY
    ↓
REDE
    ↓
SERVIÇO EXTERNO
    ↓
MODELO
    ↓
REDE
    ↓
RESPOSTA
    ↓
DECISÃO

Inferência local

COBOL/CICS
    ↓
SERVIÇO DE INFERÊNCIA NO AMBIENTE IBM Z
    ↓
TELUM II
    ↓
SCORE
    ↓
DECISÃO

O segundo caminho não é magicamente gratuito, mas reduz fronteiras.

E cada fronteira removida significa menos um lugar para:

• perder tempo;

• falhar;

• expirar;

• autenticar;

• converter dados;

• abrir uma porta de ataque;

• explicar para a auditoria.

---

11. O cloud não é o vilão do filme

Seria confortável transformar esta história num duelo:

MAINFRAME = HERÓI
CLOUD = VIGARISTA

Mas arquitetura séria não funciona como desenho animado.

Cloud pode ser excelente para:

• treinamento de modelos;

• experimentação;

• notebooks;

• ciência de dados;

• armazenamento histórico;

• elasticidade;

• processamento assíncrono;

• comparação de versões;

• grandes modelos;

• investigação posterior.

O IBM Z pode ser particularmente apropriado para:

• inferência na transação;

• dados regulados;

• baixa latência previsível;

• enorme volume;

• integração com sistemas existentes;

• disponibilidade;

• segurança e auditoria;

• continuidade operacional.

Uma arquitetura híbrida madura pode funcionar assim:

PLATAFORMA DE DADOS OU CLOUD
    ↓
TREINAMENTO
    ↓
VALIDAÇÃO
    ↓
APROVAÇÃO DO MODELO
    ↓
EMPACOTAMENTO
    ↓
IMPLANTAÇÃO NO IBM Z
    ↓
INFERÊNCIA TRANSACIONAL
    ↓
MONITORAMENTO E FEEDBACK

O modelo aprende em um ambiente e trabalha em outro.

Isso também cria responsabilidades importantes:

• versionar o modelo;

• registrar quem o aprovou;

• controlar sua implantação;

• medir drift;

• comparar versões;

• permitir rollback;

• manter explicabilidade;

• preservar evidências.

O modelo é um componente de produção. Deve receber disciplina semelhante à de qualquer outro artefato crítico.

Se você jamais colocaria um load module não testado diretamente em produção, também não deveria instalar um modelo treinado na sexta-feira por alguém que escreveu no change:

“Melhorias diversas. Baixo risco.”

---

12. Falso positivo: quando o FBI prende o piloto verdadeiro

Um sistema antifraude pode errar de duas maneiras principais.

Falso negativo

A transação era fraudulenta, mas foi considerada legítima.

Consequências possíveis:

• perda financeira;

• chargeback;

• investigação;

• desgaste com o cliente;

• impacto regulatório.

Falso positivo

A transação era legítima, mas foi considerada fraudulenta.

Consequências:

• compra recusada;

• cliente constrangido;

• perda da venda;

• chamada ao atendimento;

• cancelamento do cartão;

• deterioração da confiança.

Imagine o cliente viajando pela Europa depois de meses comprando apenas em São Paulo.

O comportamento mudou bruscamente, mas existe uma explicação legítima.

Um modelo ruim pode confundir “fora do padrão” com “fraude”.

Essa é uma distinção essencial:

Anomalia não é prova de crime. É motivo para investigar ou aplicar controles proporcionais.

Por isso, uma instituição pode criar diferentes respostas:

• risco baixo: aprovar;

• risco moderado: solicitar biometria;

• risco alto: enviar notificação;

• risco muito alto: bloquear;

• caso complexo: análise humana.

Quanto mais rápido o score estiver disponível, mais opções o banco terá.

Em vez de escolher apenas entre aprovar e negar, pode inserir autenticação adaptativa sem destruir a experiência do cliente.

---

13. Segurança local não é segurança automática

Colocar a IA no mainframe não elimina:

• credenciais roubadas;

• engenharia social;

• fraude interna;

• dados de treinamento contaminados;

• modelos enviesados;

• configuração incorreta;

• permissões excessivas;

• falhas de aplicação;

• ataques adversariais;

• decisões de negócio ruins.

O ambiente local pode ajudar a proteger:

• confidencialidade dos dados;

• propriedade intelectual do modelo;

• tráfego sensível;

• disponibilidade;

• cadeia de auditoria;

• previsibilidade operacional.

Mas o sistema ainda precisa de:

• RACF bem administrado;

• princípio do menor privilégio;

• criptografia;

• segregação de funções;

• logging;

• monitoramento;

• revisão de modelos;

• gestão de vulnerabilidades;

• resposta a incidentes;

• governança de IA.

A IA é apenas uma camada.

A arquitetura completa se parece mais com isto:

IDENTIDADE
    +
DADOS CONFIÁVEIS
    +
MODELO VALIDADO
    +
APLICAÇÃO CORRETA
    +
REGRAS DE NEGÓCIO
    +
AUDITORIA
    +
RESPOSTA OPERACIONAL

Se qualquer camada estiver comprometida, o vigarista poderá atravessar o sistema usando um belo uniforme e um crachá perfeitamente impresso.

---

14. Passo a passo para o COBOLzeiro entender uma integração com IA

Você não precisa se transformar imediatamente em cientista de dados. Comece fazendo as perguntas corretas.

Passo 1 — Entenda o evento de negócio

Defina exatamente o que será avaliado:

• compra?

• PIX?

• abertura de conta?

• alteração cadastral?

• saque?

• pedido de empréstimo?

Passo 2 — Identifique as entradas

Descubra quais informações alimentam o modelo:

VALOR
HORARIO
PAIS
DISPOSITIVO
HISTORICO
TENTATIVAS
IDADE-DA-CONTA
TIPO-DE-CANAL

Passo 3 — Conheça o contrato

O serviço deve possuir um contrato claro:

ENTRADA:
    DADOS-DA-TRANSACAO

SAIDA:
    SCORE-DE-RISCO
    VERSAO-DO-MODELO
    CODIGO-DE-STATUS
    MOTIVO
    TEMPO-DE-INFERENCIA

A versão do modelo é fundamental para auditoria.

Passo 4 — Defina o timeout

O que acontecerá se a inferência não responder?

• negar tudo;

• aprovar tudo;

• usar regras tradicionais;

• chamar um modelo alternativo;

• encaminhar para validação adicional?

Não responder também é um resultado operacional, e precisa de regra.

Passo 5 — Separe score de decisão

Evite permitir que o modelo controle diretamente a transação.

MODELO → SCORE
REGRA → DECISÃO

Passo 6 — Registre evidências

Grave pelo menos:

• identificador da transação;

• horário;

• score;

• versão do modelo;

• decisão;

• regra aplicada;

• resultado posterior conhecido.

Isso permite reconstruir a história.

Passo 7 — Monitore desempenho e qualidade

Observe:

• latência;

• throughput;

• erros;

• timeouts;

• falsos positivos;

• falsos negativos;

• mudança no perfil dos dados;

• queda de acurácia.

Passo 8 — Prepare rollback

Se o novo modelo começar a bloquear metade da população de Itatiba, você precisa retornar rapidamente à versão anterior.

MLOps sem rollback é apenas aventura.

---

15. Easter eggs recuperados do cheque falsificado

Easter egg número 1 — O mainframe já fazia “IA” antes da moda

Bancos utilizam modelos estatísticos, regras, scores e análise de risco há décadas.

O que mudou não foi a descoberta repentina de que padrões podem indicar fraude. Mudaram:

• escala;

• variedade dos modelos;

• integração;

• velocidade;

• capacidade de processar mais sinais;

• uso de aceleradores especializados.

A inteligência transacional não nasceu ontem. Ela ganhou músculos novos.

Easter egg número 2 — O COBOL não perdeu o emprego para a IA

A IA pode calcular a probabilidade de fraude, mas alguém ainda precisa:

• validar a mensagem;

• aplicar o limite;

• controlar a conta;

• atualizar o saldo;

• produzir o registro;

• garantir atomicidade;

• tratar exceções;

• responder ao canal.

O modelo pode dizer que o cheque parece suspeito.

O COBOL continua sendo o funcionário que decide se o cheque entra no movimento e garante que o livro-caixa feche no final do dia.

Easter egg número 3 — Frank Abagnale trabalhou para o FBI

A melhor ironia da história é que o fraudador pode ensinar o sistema a identificar fraudes.

Na segurança, o conhecimento ofensivo frequentemente fortalece a defesa.

Da mesma forma, fraudes confirmadas tornam-se exemplos de treinamento. O atacante, involuntariamente, deixa material para melhorar o próximo modelo.

É quase um programa de estágio não remunerado do Red Team.

Easter egg número 4 — A velocidade pode reduzir fraude sem aumentar bloqueios

Com mais capacidade de inferência, o banco pode executar vários modelos em vez de depender de uma única regra agressiva.

Isso permite distinguir melhor:

• comportamento incomum;

• comportamento realmente malicioso;

• cliente viajando;

• conta comprometida;

• compra legítima de alto valor;

• fraude coordenada.

Mais inteligência pode significar não apenas bloquear mais, mas bloquear melhor.

Easter egg número 5 — O mainframe não precisa aparecer na manchete

Quando uma transação é aprovada corretamente, ninguém comemora:

— Fantástico! O sistema consultou o limite, avaliou o risco, atualizou os registros e respondeu dentro do SLA!

O cliente apenas guarda o cartão.

O sucesso do sistema crítico é frequentemente invisível.

Ele só vira notícia quando para.

---

16. O verdadeiro “Catch Me If You Can” da fraude moderna

Frank Abagnale precisava manter sua história por alguns minutos.

A fraude digital precisa parecer legítima por milissegundos.

Ela corre entre:

• a captura dos dados;

• a autenticação;

• a análise;

• a autorização;

• a liquidação.

O IBM z17 procura fechar esse intervalo colocando capacidade de inferência dentro do núcleo transacional.

Não é uma solução mágica.

Não elimina a necessidade de investigadores, regras, autenticação, governança, criptografia ou analistas.

O que ele faz é permitir que a aplicação pergunte, no momento decisivo:

Esta operação se parece com aquilo que afirma ser?

E receba uma resposta antes que o suspeito chegue ao portão de embarque.

A grande inovação não está apenas em fazer cinco milhões de cálculos por segundo. Está em realizar a análise cedo o bastante para mudar o destino da transação.

Antes, muitos sistemas descobriam a fraude depois:

1. a operação era aprovada;

2. o dinheiro seguia seu caminho;

3. o cliente reclamava;

4. começava a investigação;

5. alguém tentava recuperar o prejuízo.

Era perícia.

Com a inferência transacional, a inteligência pode participar do processo antes da conclusão:

1. a operação chega;

2. os dados são avaliados;

3. o modelo produz o score;

4. as regras interpretam o risco;

5. o sistema aprova, bloqueia ou desafia;

6. a decisão é registrada.

É a diferença entre encontrar a falsificação no arquivo morto e pará-la no balcão.

---

Epílogo — O cheque, o COBOL e o homem de uniforme

No final do filme, o vigarista não é derrotado porque alguém construiu uma parede infinitamente alta.

Ele é alcançado porque o investigador aprende a reconhecer seus padrões.

O papel usado.

A forma de imprimir.

As cidades escolhidas.

O modo como ele conta a história.

Fraude é repetição disfarçada de improviso.

A inteligência artificial encontra valor justamente nessa repetição: relações pequenas demais, rápidas demais ou numerosas demais para depender exclusivamente da observação humana.

O Telum II aproxima essa análise do lugar onde a decisão acontece.

O Spyre amplia o repertório para modelos maiores e abordagens mais complexas.

O z17 fornece o ambiente para executar isso com a velocidade, a escala, o isolamento e a previsibilidade exigidos por sistemas críticos.

E o COBOL?

O COBOL continua no balcão.

Recebe a mensagem.

Valida o cartão.

Consulta o limite.

Interpreta o score.

Executa a regra.

Grava a decisão.

Libera ou recusa a transação.

Talvez ele não apareça no trailer. Talvez ninguém compre uma camiseta escrito PERFORM UNTIL FRAUD-DETECTED. Mas, quando Frank Abagnale chegar usando o uniforme de piloto, será o velho programa transacional que olhará o score calculado em menos de um milissegundo e dirá:

       IF IDENTIDADE-PARECE-PERFEITA
          AND HISTORIA-NAO-FECHA
              MOVE 'N' TO AUTORIZAR
              MOVE 'PRENDA-ME-SE-FOR-CAPAZ'
                TO MOTIVO-RECUSA
       END-IF.

No andar de cima, o Spyre cruza os dossiês.

Dentro do processador, o Telum II examina o próximo passageiro.

No CICS, outra tarefa começa.

E em algum lugar do datacenter, um COBOL escrito quando Leonardo DiCaprio ainda era criança continua protegendo uma transação que jamais saberá seu nome.

Para ir mais longe

https://eljefemidnightlunch.blogspot.com/2024/01/megafilmeshd-quando-um-casal-do.html

https://eljefemidnightlunch.blogspot.com/2026/08/spy-vs-spy-no-tribunal-as-trapacas.html

https://eljefemidnightlunch.blogspot.com/2026/08/red-team-e-os-doze-trabalhos-de-asterix.html

 

Bellacosa Mainframe e os 5 estudantes e sua lista que deu ruim

☕ Um Café no Bellacosa Mainframe

☕ Os Cem Barris de Saquê — Como Cinco Estudantes de Psicologia Levaram um Milhão de Chimpanzés de uma Tier List até a Teoria da Informação

Ou: uma notícia sobre um grupo fechado virou discussão sobre privacidade, Valderrama, Mounjaro, Cyberpunk 2077, o Barão Vermelho, Malba Tahan, SEO, crawlers de Singapura, formigas, infovias e a descoberta de que uma conversa aparentemente bêbada pode conservar perfeita rastreabilidade

Pegue um café.

Hoje não vamos falar exatamente de Psicologia.

Nem de Cyberpunk.

Nem de SEO.

Nem de Manfred von Richthofen.

Nem de Malba Tahan.

Nem de Carlos Valderrama.

Nem de crawlers de Singapura.

Nem de formigas.

Nem sequer dos chimpanzés.

Embora, naturalmente, haja um milhão deles no datacenter e alguém já tenha aberto o centésimo barril de saquê.

Hoje vamos falar de uma coisa muito mais perigosa:

uma conversa que se recusou a morrer.

Tudo começou com uma notícia.

Cinco estudantes de Psicologia estavam sendo investigados por um ranking envolvendo dezenas de universitárias.

Tier list.

Fotografias.

Comentários.

Grupo fechado.

Indignação.

Polícia.

Universidade.

Imprensa.

Até aí, nada indicava que algumas horas depois estaríamos discutindo Hayao Miyazaki, a Primeira Guerra Mundial, Mounjaro, Tolkien, o Guia dos Curiosos e infraestrutura semântica para inteligências artificiais.

Se alguém tivesse previsto isso no primeiro parágrafo, eu teria recomendado reduzir a dose.

Mas aconteceu.

E o mais curioso:

há uma trilha entre todos os assuntos.

---

🐒 1. O primeiro chimpanzé encontrou uma tier list

A notícia possuía um detalhe que me chamou mais atenção que o próprio ranking.

Aquilo aparentemente havia nascido num grupo fechado.

Não era enquete pública.

Não era postagem aberta.

Não era:

“Vote aqui na mais bonita da faculdade.”

Era uma pequena confraria digital.

Alguém precisava entrar.

Alguém precisava pertencer.

Alguém precisava ser considerado parte daquele espaço.

Então apareceu a primeira pergunta:

como aquilo saiu dali?

Pronto.

Primeiro chimpanzé contratado.

Ele abriu uma cerveja.

Ainda não havia saquê.

---

🕵️ 2. Entrou o cagueta

A conversa foi imediatamente para uma figura muito mais antiga que WhatsApp, Telegram ou Discord:

o informante.

O infiltrado.

O X-9.

O alcaguete.

O cagueta.

O sujeito que entra, observa, coleta e entrega.

Não sabemos se houve realmente um infiltrado naquele caso.

Talvez um membro legítimo tenha se indignado.

Talvez alguém tenha mostrado o telefone para terceiros.

Talvez o conteúdo tenha passado por várias mãos.

Mas a questão apareceu:

um grupo privado continua privado se qualquer membro pode mudar unilateralmente sua audiência?

Excelente pergunta.

O chimpanzé chamou outro chimpanzé.

---

🍺 3. O Boteco de Itatiba entrou na investigação

Porque qualquer grupo de amigos com alguns anos de estrada conhece uma verdade simples:

há coisas que pertencem ao contexto em que foram ditas.

Conversa de boteco é uma delas.

O problema é que o boteco analógico possuía uma extraordinária política de governança de dados.

Você dizia uma enorme besteira.

Seu amigo respondia uma ainda maior.

O garçom trazia outra cerveja.

Algumas horas depois:

RETENTION PERIOD = 0

A conversa desaparecia.

Talvez alguém lembrasse.

Provavelmente lembrava errado.

E a humanidade seguia.

Então inventamos o smartphone.

Agora a besteira tem:

timestamp,

autor,

fotografia,

histórico,

backup,

busca,

screenshot,

encaminhamento.

O boteco virou cartório.

No Boteco de Itatiba adotamos uma solução civilizada:

mensagens temporárias de sete dias.

Não porque estejamos planejando um golpe de Estado.

Provavelmente estamos discutindo churrasco.

Mas porque velhos malandros entendem uma coisa que muitas empresas ainda descobrem em consultoria:

se determinada informação não precisa existir para sempre, talvez seja uma boa ideia não guardá-la para sempre.

Os chimpanzés ficaram impressionados.

Abriram o primeiro barril de saquê.

---

🔐 4. Segurança perfeita, até aparecer um ser humano

Claro que mensagem temporária não impede screenshot.

E surgiu imediatamente o problema clássico:

USER AUTHENTICATED = TRUE
USER AUTHORIZED    = TRUE
USER TRUSTWORTHY   = ???

Você pode possuir criptografia excelente.

Pode controlar entrada.

Pode colocar senha.

Pode exigir convite.

Pode apagar mensagens.

Mas depois que a informação chega legitimamente ao dispositivo de outra pessoa, você depende de uma tecnologia ainda experimental:

confiança humana.

Isso nos levou de volta à velha espionagem.

E então alguém comentou:

— Se vazar, hoje qualquer um pode dizer que o print foi feito por IA.

Outro chimpanzé levantou a cabeça.

---

🤖 5. A IA tornou o verdadeiro mais fácil de negar

Entramos então num paradoxo delicioso.

A inteligência artificial tornou muito mais fácil fabricar:

imagem falsa,

voz falsa,

vídeo falso,

conversa falsa,

screenshot falso.

Mas também tornou mais fácil dizer que uma coisa verdadeira é falsa.

A existência de falsificação sofisticada produz uma nova defesa:

“Isso aí foi feito por IA.”

Agora não basta verificar se algo parece verdadeiro.

É necessário perguntar:

como foi autenticado?

E nasceu outra diferença:

verdade não é a mesma coisa que demonstrabilidade pública.

O Facão de Occam apareceu.

Ainda estava limpo.

Não duraria.

---

🔪 6. O Facão de Occam entrou no boteco

A lógica era simples.

Se existe apenas um screenshot isolado e nenhuma evidência adicional, há mais espaço para dúvida.

Se existem:

vinte screenshots,

vídeo navegando pelo grupo,

mensagens posteriores,

testemunhas,

horários consistentes,

outras cópias,

a hipótese “foi tudo fabricado” começa a exigir mais e mais suposições.

Occam olha para aquilo e corta.

Não porque Occam saiba automaticamente o que é verdade.

Mas porque uma explicação que exige vinte malabarismos precisa competir com outra que exige dois.

O problema é que alguém colocou o facão perto dos chimpanzés.

Erro operacional.

---

👩‍⚕️ 7. Mas eram estudantes de Psicologia

Até aqui estávamos nos divertindo com privacidade, botecos e infiltração.

Então veio a parte triste.

Eram estudantes de Psicologia.

Gente que um dia poderá ouvir pacientes falando sobre:

corpo,

peso,

sexualidade,

vergonha,

humilhação,

rejeição,

autoestima,

trauma.

Ninguém é obrigado a achar todo mundo bonito.

Ninguém é obrigado a sentir atração por qualquer característica.

Mas existe uma enorme diferença entre:

“não é meu tipo”

e

“essa característica reduz o valor daquela pessoa.”

A conversa deixou de ser apenas sobre privacidade.

Passou a ser sobre objetificação.

Segundo barril aberto.

---

⚔️ 8. A Guerra dos Sexos entrou pela janela

E então surgiu a contradição contemporânea.

De um lado:

“não me reduza à aparência.”

Do outro:

uma indústria gigantesca dedicada a modificar aparência.

Cirurgia plástica.

Aparelho dental.

Clareamento.

Harmonização.

Academia.

Cabelo.

Maquiagem.

Filtros.

Procedimentos.

Medicamentos para controle de peso.

A sociedade diz:

“não julgue pela capa.”

e investe uma quantidade absurda de energia na capa.

Isso não é necessariamente hipocrisia.

Uma pessoa pode querer ser considerada bonita sem querer que beleza seja sua única medida de valor.

Mas a tensão existe.

Terceiro barril.

---

💉 9. Alguém falou “Mojaru”

E tivemos de descobrir que “mojaru” era Mounjaro.

A famosa tirzepatida.

Medicamento para diabetes que entrou com enorme força na conversa mundial sobre obesidade, emagrecimento e aparência.

A partir dali percebemos que nosso configurador humano havia ganhado novos controles.

CABELO ............ alterável
DENTES ............ alteráveis
NARIZ ............. alterável
PESO .............. cada vez mais alterável
PELE .............. alterável
ROSTO ............. alterável
CORPO ............. parcialmente reconfigurável

O mundo começou a parecer um editor de personagem.

Quarto barril.

---

💇 10. O Brasil virou fábrica de loiras

Então apareceu o cabelo.

E o fato cultural maravilhoso de que no Brasil “loira” frequentemente descreve muito mais uma configuração estética do que ancestralidade.

Temos:

negra loira,

asiática loira,

parda loira,

morena loira,

indígena loira,

loira natural,

loira produzida por profissional com orçamento, química e coragem.

O cabeleireiro brasileiro recebeu uma especificação:

INPUT: cabelo qualquer
OUTPUT: blonde

E respondeu:

— deixa comigo.

Aí nasceu a conclusão econômica:

Blonde as a Service.

Porque a transformação não basta.

A raiz cresce.

A cor muda.

O tratamento continua.

Receita recorrente.

Quinto barril.

---

🦁 11. Dormiu com a princesa e acordou com Valderrama

E aí apareceu Carlos Valderrama.

Sem qualquer aviso.

O lendário colombiano de cabeleira monumental entrou na conversa porque existe uma piada antiga:

dormir com a princesa e acordar com Valderrama.

O sentido era simples.

Produção noturna.

Sono.

Entropia capilar.

Manhã.

VALDERRAMA.

O assunto agora era:

aparência construída versus aparência percebida.

Sexto barril.

---

🇮🇹 12. Os italianos já tinham denunciado tudo

Daí veio uma das melhores palavras do idioma italiano:

trucco.

Maquiagem.

E também:

truque.

Artifício.

Disfarce.

Dependendo do contexto, adulteração.

A língua italiana olhou para toda essa discussão sobre aparência e disse, séculos atrás:

— Chama logo de truque e deixa o futuro resolver.

Maravilhoso.

O CSS humano havia acabado de ganhar nome.

Sétimo barril.

---

🐊 13. Crocodile Dundee envelheceu mal

A conversa pulou para uma velha piada de Crocodile Dundee baseada na ideia de que determinada aparência poderia ser “verificada” fisicamente.

O problema é que aquilo envelheceu em dois níveis.

Primeiro:

consentimento.

Segundo:

a própria noção de que basta olhar ou tocar determinado elemento para descobrir uma “verdade simples” sobre apresentação corporal.

Em 1986:

OLHAR
VERIFICAR
CONCLUIR

Em 2026:

OLHAR
OLHAR
OLHAR
AMPLIAR
OLHAR DE NOVO

CONFIDENCE LEVEL: 61%

O CSS ficou bom demais.

Oitavo barril.

---

🌃 14. Night City abriu a porta

E então entrou Cyberpunk 2077.

Não porque alguém resolveu enfiar videogame no assunto.

Porque havia uma side quest que parecia escrita especificamente para nossa conversa.

Pepe.

Cynthia.

Ripperdoc.

Modificação corporal.

Aparência reconfigurada.

Identidade.

Confiança.

Night City fez aquilo que nossa sociedade apenas começou:

transformou o corpo inteiro em plataforma atualizável.

Agora o problema já não era maquiagem.

Era:

se tudo pode ser alterado, o que significa “original”?

Nono barril.

---

🛶 15. O Navio de Teseu apareceu sem convite

Naturalmente, Cyberpunk nos levou ao Navio de Teseu.

Se você substitui uma peça de um navio, continua sendo o mesmo navio?

E duas?

E metade?

E todas?

Agora aplique ao corpo.

Nariz.

Dentes.

Cabelo.

Pele.

Olhos.

Membros.

Órgãos.

Quanto pode mudar antes de começarmos a perguntar:

quem exatamente é esta pessoa?

Décimo barril.

Os chimpanzés já cantavam.

---

🧬 16. Então o DNA estragou a festa

E alguém percebeu a pegadinha perfeita.

Você pode trocar quase todo o frontend.

Mas, numa reprodução biológica convencional, várias dessas modificações adquiridas não são simplesmente gravadas no material genético transmitido ao filho.

Ou seja:

FRONTEND = Night City Premium
GENOME   = legacy system

Nasce o bebê.

Os pais olham.

O bebê olha de volta.

E Mendel aparece no corredor sorrindo.

Décimo primeiro barril.

---

📰 17. A conversa voltou ao crime

E então retornamos ao ponto inicial, mas por uma estrada completamente diferente.

Falávamos de objetificação.

Passamos por aparência.

Chegamos à genética.

E surgiu a questão da notoriedade criminal.

Pessoas que cometem crimes célebres podem, paradoxalmente, tornar-se celebridades.

Filmes.

Livros.

Séries.

Entrevistas.

Documentários.

Notícias sobre trabalho.

Casamento.

Separação.

Mudança de vida.

A mídia condena alguém e simultaneamente mantém sua marca ativa.

Décimo segundo barril.

---

👤 18. A vítima quer desaparecer

Então veio o contraste.

No caso Richthofen, o irmão sobrevivente tornou-se exemplo de uma pessoa que não escolheu aquela história e, ainda assim, carregou seu sobrenome e suas consequências públicas.

O criminoso pode ganhar notoriedade.

A vítima pode querer anonimato.

A sociedade faz exatamente o contrário:

segue o famoso e encontra o recluso.

E apareceu uma pergunta enorme:

quem merece ser lembrado e quem deveria ter direito de desaparecer?

Décimo terceiro barril.

---

✈️ 19. Espera aí... Richthofen?

Foi aí que um chimpanzé ainda relativamente sóbrio levantou o dedo.

— Richthofen?

Sim.

Richthofen.

E imediatamente apareceu:

Manfred von Richthofen.

O Barão Vermelho.

Um dos maiores ases da Primeira Guerra Mundial.

Oitenta vitórias aéreas.

Figura histórica monumental.

Mas no Brasil surgiu uma ironia.

Digite:

Richthofen

e você provavelmente encontrará Suzane.

Digite:

Barão Vermelho

e provavelmente encontrará Cazuza e a banda.

O pobre Manfred sofreu um ataque semântico pelos dois flancos.

RICHTHOFEN → Suzane
BARÃO VERMELHO → Cazuza

Décimo quarto barril.

---

🎸 20. Cazuza derrubou o Barão

Não literalmente.

Mas semanticamente.

A banda Barão Vermelho tornou-se tão poderosa na cultura brasileira que o apelido histórico de Manfred ganhou outro significado dominante.

E aí surgiu um artigo inteiro:

O Dia em que Suzane e Cazuza Derrubaram o Barão Vermelho do Google

Primeiro artigo extraído da conversa.

Os chimpanzés comemoraram.

Abriram mais dez barris.

Péssima ideia.

---

🐷 21. Porco Rosso apareceu para pedir revisão

Depois percebemos:

passamos páginas falando sobre o Barão Vermelho e esquecemos anime.

Especialmente Porco Rosso.

Marco Pagot não é Manfred von Richthofen.

Mas o filme respira a mitologia dos ases da aviação.

Pilotos lendários.

Máquinas identificáveis.

Duelo.

Reputação.

Cores.

Romantismo do voo.

Então apareceu a conclusão:

talvez um personagem histórico possa desaparecer do ranking de busca e continuar vivo como arquétipo cultural.

Décimo quinto barril.

---

🔎 22. SEO entrou em produção

A conversa, agora completamente fora de controle, começou a perguntar:

como máquinas entendem essas associações?

Barão Vermelho.

Cazuza.

Suzane.

Manfred.

Porco Rosso.

Primeira Guerra.

Aviação.

Google.

SEO.

Mesmo sem linkar tudo explicitamente, um sistema moderno pode extrair entidades e relações contextuais.

Agora estávamos falando de:

busca semântica.

Décimo sexto barril.

---

🤖 23. E apareceu o artigo sobre SEO para 2027

Como se o universo resolvesse participar da piada, surgiu um artigo do iMasters falando justamente sobre:

entidades,

menções,

IA,

GEO,

busca generativa,

visibilidade além do link azul.

Aquilo que estávamos especulando havia acabado de aparecer organizado como tendência de mercado.

Os chimpanzés apontaram para a tela.

— CHEFE!

Sim.

Eu vi.

Calma.

Ninguém abre outro barril.

Naturalmente abriram.

---

🌏 24. Singapura estava na sala desde o começo

Então lembramos de um fenômeno observado havia algum tempo:

tráfego recorrente vindo de Singapura.

Pode ser humano.

Pode ser crawler.

Pode ser cloud.

Pode ser proxy.

Pode ser indexador.

Pode ser infraestrutura de terceiros.

Não sabemos.

Mas a coincidência ficou interessante.

Se estamos publicando milhares de relações semânticas e máquinas estão visitando regularmente o blog, vale investigar.

Não declarar vitória.

Investigar.

O Facão de Occam reapareceu.

Estava coberto de banana.

---

🧙 25. Gandalf entrou no datacenter

E então surgiu uma metáfora.

Talvez Vagner Bellacosa tenha virado um pequeno Gandalf da era da IA.

Não como protagonista.

Mas como personagem que atravessa diversas histórias e conecta grupos que jamais se encontrariam.

Mainframe.

Cinema.

Anime.

História.

Boteco.

Tecnologia.

Memória.

Notícia.

Filosofia.

A função não é possuir uma história central.

É carregar pontes.

Décimo sétimo barril.

---

📚 26. Tolkien explicou o problema

Naturalmente Gandalf trouxe Tolkien.

E Tolkien trouxe uma descoberta importante:

um texto pode ficar mais compreensível conforme o leitor acumula repertório.

Na primeira leitura:

nome estranho.

Na segunda:

reconhecimento.

Na terceira:

conexão.

O texto não mudou.

O leitor mudou.

Isso explicava por que alguém poderia entrar num Café sem entender:

chimpanzés,

COBOL,

mainframe,

Facão de Occam,

Major Tom,

Efeito VEJA.

Mas depois de dezenas de textos, tudo começa a adquirir significado.

Décimo oitavo barril.

---

🐪 27. Malba Tahan estava nos esperando

E então apareceu Malba Tahan.

Júlio César de Mello e Souza já fazia, décadas antes da Internet, algo muito parecido.

Ele não começava dizendo:

“Vamos estudar frações.”

Criava um problema.

Uma viagem.

Um mercador.

Um camelo.

Uma herança.

Uma história.

E o leitor aprendia matemática porque queria descobrir o que aconteceria depois.

A melhor porta para conhecimento nem sempre possui placa dizendo:

CONHECIMENTO.

Às vezes tem um camelo.

Décimo nono barril.

---

📖 28. O Guia dos Curiosos completou o circuito

Então lembramos do Guia dos Curiosos, de Marcelo Duarte.

A genialidade daquele livro não era apenas responder perguntas.

Era produzir novas perguntas.

Você abria procurando uma coisa.

Descobria três outras.

Uma hora depois estava lendo sobre um assunto que não sabia que existia.

E aí finalmente conseguimos formular uma diferença essencial:

a enciclopédia responde a pergunta que você já possui.

O Guia dos Curiosos cria perguntas que você ainda não sabia que possuía.

Vigésimo barril.

Os chimpanzés haviam perdido a conta.

---

📰 29. O Efeito VEJA voltou

E então percebemos que tudo aquilo parecia uma versão mais ampla de uma ideia que já vínhamos chamando de:

Efeito VEJA.

O texto menciona alguma coisa.

Não explica tudo.

O leitor sente uma coceira mental.

Pesquisa.

Encontra outra coisa.

Nova coceira.

Nova pesquisa.

CONHECIMENTO
    ↓
LACUNA
    ↓
CURIOSIDADE
    ↓
BUSCA
    ↓
DESCOBERTA
    ↓
NOVA LACUNA
    ↺

Nesse momento, o Efeito VEJA deixou de parecer apenas uma piada editorial.

Começou a parecer um mecanismo geral de exploração.

Vigésimo primeiro barril.

---

🐜 30. As formigas assumiram a infraestrutura

Apareceu então uma metáfora ainda melhor.

Formigas não precisam compreender o formigueiro.

Cada uma realiza ações locais.

Carrega.

Escava.

Segue.

Deixa trilha.

Uma pequena passagem aberta hoje pode ser usada amanhã.

Depois por outra.

Depois por cem.

Depois por milhares.

O pequeno túnel vira rota.

A rota vira:

infovia.

E isso parece descrever muito bem a Web.

Um post cria uma relação.

Alguém encontra.

Compartilha.

Outro menciona.

Um crawler indexa.

Um modelo recupera.

Outro autor escreve.

Uma relação antes rara ganha novos caminhos.

Nenhuma formiga precisou compreender o sistema inteiro.

Vigésimo segundo barril.

---

📘 31. Então apareceu Facebook

E houve um pequeno acontecimento curioso.

Referral vindo do Facebook.

Só que o autor do blog não usa Facebook para distribuir aquele conteúdo.

Ou seja:

se o referral foi realmente provocado por compartilhamento humano, alguém levou o link por conta própria.

A formiga abriu um túnel fora do território controlado.

Isso ainda não significa viralização.

Não significa inteligência coletiva.

Não significa que Mark Zuckerberg esteja lendo o Bellacosa Mainframe durante o café.

Significa apenas:

uma ponte pode ter sido criada por terceiros.

E isso é muito mais interessante que fabricar a própria ponte.

Vigésimo terceiro barril.

---

🧠 32. A conversa começou a parecer uma alucinação

Nesse momento, qualquer pessoa que chegasse no final sem conhecer o começo encontraria:

Psicologia → Valderrama → Cyberpunk → DNA → Richthofen → Cazuza → Porco Rosso → SEO → Singapura → Gandalf → Malba Tahan → formigas → Facebook.

Diagnóstico provável:

“A IA enlouqueceu.”

Só que existe um problema.

Podemos reconstruir cada transição.

Nenhum salto precisa ser inventado depois para justificar o anterior.

Há uma aresta.

Depois outra.

Depois outra.

O resultado é estranho.

A trilha não.

Isso produz uma distinção importante:

alucinação inventa a ponte.

pensamento associativo encontra pontes existentes em sequência.

Vigésimo quarto barril.

---

🕸️ 33. O grafo estava escondido dentro da conversa

Então percebemos finalmente o que havia acontecido.

Não construímos uma linha.

Construímos um grafo.

PSICOLOGIA
   │
   ├── privacidade
   │     └── grupo fechado
   │           └── confiança
   │
   ├── objetificação
   │     └── beleza
   │           └── corpo
   │                 └── Cyberpunk
   │
   └── notoriedade
         └── Suzane
               └── Richthofen
                     └── Manfred
                           └── SEO

E vários ramos voltaram a se encontrar.

Não era uma viagem aleatória.

Era exploração de vizinhanças semânticas.

Vigésimo quinto barril.

---

🍶 34. Chegamos ao centésimo barril

Naturalmente, ninguém sabe exatamente quando chegamos ao barril número 100.

O departamento de auditoria desistiu por volta do 37.

Mas imaginemos o debugger chegando.

Ele abre a conversa.

Primeiro turno:

notícia sobre estudantes de Psicologia.

Último turno:

teoria de redes, memória semântica e formigas construindo infovias.

O debugger respira fundo.

STATUS:
POSSIBLE HALLUCINATION

Volta ao começo.

Segue as arestas.

Privacidade.

Confiança.

Boteco.

IA.

Objetificação.

Beleza.

Valderrama.

Trucco.

Cyberpunk.

DNA.

Crime.

Richthofen.

SEO.

Malba Tahan.

Formigas.

O debugger chega ao final.

Olha novamente.

STATUS:
WTF

TRACEABILITY:
PASS

🐒🍶

---

🧩 35. A teoria da informação estava escondida no boteco

E aqui nossa história finalmente encontra o título.

O que fizemos durante toda a conversa?

Pegamos informação.

Criamos associações.

Reduzimos incerteza.

Abrimos novas perguntas.

Transferimos contexto.

Construímos caminhos entre conceitos.

Uma mensagem isolada possui significado limitado.

Uma sequência contextual pode transformar completamente a interpretação da mensagem seguinte.

“Valderrama” sozinho:

jogador colombiano.

Dentro daquela conversa:

unidade de entropia capilar matinal.

“Chimpanzé” sozinho:

primata.

Dentro do Bellacosa Mainframe:

agente caótico de produção intelectual movido a saquê.

“Efeito VEJA” sozinho:

expressão obscura.

Depois de dezenas de referências:

mecanismo narrativo em que uma lacuna de informação provoca exploração.

Contexto altera informação.

Relações alteram significado.

E memória acumulada altera interpretação futura.

Não precisamos fingir que reinventamos Shannon no boteco.

Mas chegamos por brincadeira a uma percepção séria:

informação não vive apenas nas palavras. Vive também nas relações entre elas.

---

🌐 36. Talvez seja justamente isso que interessa às IAs

Modelos modernos não tratam texto apenas como lista de palavras independentes.

Relações contextuais importam.

Entidades importam.

Coocorrências importam.

Estrutura importa.

Recuperação importa.

E talvez seja por isso que este tipo de escrita tenha alguma afinidade especial com a era das IAs.

Não porque tenha sido escrita “para o algoritmo”.

Muito pelo contrário.

Foi escrita seguindo curiosidade humana.

Mas curiosidade humana produz relações.

E relações são precisamente aquilo que sistemas semânticos tentam capturar.

Isso não significa que uma conversa esteja treinando diretamente um modelo global.

Não significa que escrever determinada palavra dez vezes altere magicamente os pesos de uma IA.

Mas significa que conteúdo público, quando rastreado e recuperável, cria superfícies documentais onde relações podem ser observadas.

Uma formiga abre o túnel.

---

🛌 37. E o chimpanzé simplesmente dorme sobre o assunto

Aqui aparece talvez a característica mais importante de todas.

Nem toda ideia precisa virar artigo imediatamente.

Algumas precisam dormir.

Uma conversa termina.

Um conceito fica.

Três semanas depois aparece uma notícia.

O chimpanzé que estava de pileque embaixo da mesa acorda.

Ainda está segurando um papel:

TOLKIEN + SEO ???

Olha para a notícia.

Olha para o papel.

Olha para Polindexter.

— CHEFE.

— O quê?

— ACHEI A ARESTA.

E pronto.

A conversa ressuscita.

Por isso talvez nunca tenhamos realmente um backlog.

Temos um cemitério de chimpanzés cochilando sobre ideias incompletas.

Alguns jamais acordam.

Outros reaparecem seis meses depois trazendo ouro.

---

☕ 38. Dois artigos e uma montanha de minério

E foi exatamente isso que aconteceu desta vez.

Uma notícia gerou:

O CSS Humano

Um texto sobre aparência, objetificação, modificação corporal, Cyberpunk, identidade e genética.

Depois gerou:

O Dia em que Suzane e Cazuza Derrubaram o Barão Vermelho do Google

Um texto sobre memória digital, notoriedade, SEO e legado histórico.

E ainda sobraram pedaços suficientes para:

Malba Tahan.

GEO.

Tolkien.

Guia dos Curiosos.

Singapura.

Crawlers.

Formigas.

Memória algorítmica.

Privacidade.

Crime e celebridade.

Mas não precisamos transformar cada pedaço num artigo agora.

Alguns serão canibalizados por textos futuros.

Alguns vão desaparecer.

Alguns dormirão.

Um ou outro chimpanzé acordará no momento certo.

---

🐒 39. A verdadeira máquina criativa

Talvez aqui esteja a conclusão mais importante.

Não começamos dizendo:

“Precisamos produzir três artigos hoje.”

Começamos dizendo:

“Essa notícia me deixou pensativo.”

Esse detalhe muda tudo.

Porque criação baseada exclusivamente em pauta procura resposta.

Criação baseada em curiosidade procura caminho.

E caminhos produzem coisas que a pauta não previa.

A pergunta inicial era pequena.

O espaço de exploração era enorme.

Isso é quase o inverso do conteúdo industrial.

Conteúdo industrial:

KEYWORD
   ↓
OUTLINE
   ↓
ARTICLE
   ↓
PUBLISH
   ↓
NEXT KEYWORD

Bellacosa Mainframe:

NOTÍCIA
   ↓
"isso me lembra..."
   ↓
"espera..."
   ↓
"e aquela história?"
   ↓
"caralho, Cyberpunk!"
   ↓
"Richthofen?"
   ↓
"Malba Tahan!"
   ↓
🐒🍶
   ↓
3 ARTIGOS

Não recomendo apresentar esse fluxograma ao departamento de processos.

---

🧙 40. Gandalf não escreve a história principal

Voltamos então ao velho mago.

Talvez o papel de quem acumula muitas décadas de referências não seja possuir a narrativa principal.

É reconhecer caminhos entre narrativas.

Um jovem fala de IA.

Você lembra COBOL.

Alguém fala de crime.

Você lembra SEO.

Uma discussão sobre maquiagem traz italiano.

Italiano traz trucco.

Trucco traz aparência.

Aparência traz Cyberpunk.

Cyberpunk traz filosofia.

Essa capacidade não nasceu ontem.

Ela depende de:

tempo,

memória,

leitura,

experiência,

erros,

viagens,

filmes,

livros,

trabalho,

botecos.

Em outras palavras:

pegadas.

Muitas pegadas.

Algumas se perderam.

Outras viraram trilhas.

---

🐜 41. A formiga não sabe que está fazendo história

E talvez essa seja a melhor maneira de terminar.

Quem escreveu um post em 2005 não sabia como ele seria encontrado em 2026.

Quem deixou uma fotografia numa página antiga não sabia que um crawler futuro poderia chegar até ela.

Quem mencionou um conceito obscuro não sabia que outro autor o encontraria.

Quem abriu uma trilha não sabia que milhares passariam depois.

A maioria das ações que constroem redes complexas é local.

A formiga carrega uma folha.

Não pensa:

“estou contribuindo para a arquitetura logística do formigueiro.”

O blogueiro escreve um texto.

Não pensa:

“estou adicionando uma aresta a um grafo semântico que poderá ser recuperado por sistemas de IA daqui a dez anos.”

Ele simplesmente escreve.

E continua.

---

☕ Epílogo — O centésimo primeiro barril

Voltamos então ao Boteco de Itatiba.

Na mesa:

um laptop.

um café.

um Facão de Occam.

um exemplar de Malba Tahan.

um Guia dos Curiosos.

uma miniatura de Fokker Dr.I.

uma foto de Valderrama.

Cyberpunk 2077 aberto numa tela.

Gandalf observa do canto.

Uma formiga atravessa o teclado.

E um milhão de chimpanzés dorme pelo chão.

O centésimo barril de saquê está vazio.

Polindexter olha para o quadro.

No topo ainda está escrita a primeira frase:

“Essa notícia me deixou pensativo.”

Abaixo dela:

dezenas de setas.

Centenas de conceitos.

Dois artigos publicados.

Vários assuntos adormecidos.

Um pequeno túnel levando ao Facebook.

Talvez algum crawler de Singapura passando ao longe.

Um chimpanzé acorda.

Olha para o quadro.

Olha para a formiga.

Olha para o Facão de Occam.

Vai até o depósito.

Abre o barril número 101.

Polindexter grita:

— NÃO!

Tarde demais.

O chimpanzé toma um copo.

Senta no teclado.

E escreve:

“Chefe... você já reparou que...”

Silêncio.

Todos olham.

Pegue outro café.

A conversa acabou de recomeçar.

☕🐒🍶🐜

https://eljefemidnightlunch.blogspot.com/2026/08/discord-whatsapp-e-o-tribunal-do-abend.html