☕ 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 Tecnologia. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Tecnologia. Mostrar todas as mensagens

segunda-feira, 5 de outubro de 2026

JOHN NASH E A GUERRA DAS INTELIGÊNCIAS ARTIFICIAIS: O DIA EM QUE OS PAÍSES ENTRARAM NUM JOGO QUE NINGUÉM QUER PERDER!

 

Bellacosa Mainframe e uma visão da guerra das inteligencias artificiais e a teoria dos jogos

☕ UM CAFÉ NO BELLACOSA MAINFRAME

JOHN NASH E A GUERRA DAS INTELIGÊNCIAS ARTIFICIAIS: O DIA EM QUE OS PAÍSES ENTRARAM NUM JOGO QUE NINGUÉM QUER PERDER!

Uma viagem pela Teoria dos Jogos, geopolítica, soberania tecnológica e programação COBOL, sob a ótica de John Nash.

Bellacosa Mainframe — Novembro de 2026



🎬 Prólogo — Dois presidentes, uma inteligência artificial e uma xícara de café

Imagine o seguinte cenário.

Estamos em 2030.

Em Washington, o presidente dos Estados Unidos recebe um relatório confidencial:

— Senhor presidente, nossos especialistas acreditam que a China poderá desenvolver uma inteligência artificial capaz de superar nossos sistemas estratégicos em determinadas aplicações.

O presidente pergunta:

— Quanto precisamos investir para impedir isso?

O assessor responde:

— Centenas de bilhões de dólares.

Enquanto isso, em Pequim, acontece uma reunião muito semelhante.

— Nossos serviços de inteligência informam que os americanos estão construindo centros de processamento gigantescos. Se não acompanharmos esse ritmo, nossa indústria poderá ficar dependente deles.

O dirigente chinês pergunta:

— Quanto precisamos investir?

A resposta é praticamente a mesma.

E assim começa uma competição em que nenhum dos participantes sabe exatamente quanto o adversário está disposto a gastar.

Em algum lugar de Princeton, se pudesse observar tudo isso, John Nash talvez reconhecesse um problema familiar.

Não porque tenha previsto a inteligência artificial generativa, mas porque estudou matematicamente situações nas quais a decisão de um participante depende das decisões dos demais.

Bem-vindos à Teoria dos Jogos!

E, neste café, vamos descobrir por que ela pode ser uma das ferramentas mais importantes para compreender a geopolítica da inteligência artificial.

Nosso convidado especial será John Forbes Nash Jr., matemático americano cuja obra transformou a economia e influenciou os estudos de estratégia, negociação e competição.

E nosso laboratório será um velho conhecido: o COBOL!

Sim, meus caros programadores!

Aquela linguagem que continua processando transações bancárias também pode nos ajudar a compreender a competição tecnológica entre nações.

Peguem o café, acomodem-se diante do terminal 3270 e preparem-se.

Hoje, a PROCEDURE DIVISION vai invadir a geopolítica!



Capítulo I — Quem foi John Nash e por que seu pensamento continua revolucionário?

John Forbes Nash Jr. nasceu em 13 de junho de 1928, em Bluefield, na Virgínia Ocidental, Estados Unidos.

Demonstrou talento matemático e estudou no Carnegie Institute of Technology, posteriormente chamado Carnegie Mellon University.

Mais tarde, ingressou em Princeton, onde desenvolveu trabalhos fundamentais sobre jogos não cooperativos e equilíbrio estratégico.

Em 1950, publicou um pequeno artigo científico chamado Equilibrium Points in N-Person Games, apresentando uma ideia de extraordinária importância.

O conceito, conhecido como Equilíbrio de Nash, descreve uma situação na qual nenhum participante consegue melhorar individualmente seu resultado alterando apenas sua própria estratégia, mantendo inalteradas as estratégias dos demais.

Parece complicado?

Vamos simplificar.

Imagine dois vendedores de café em uma estação ferroviária.

Cada um pode cobrar um preço alto ou baixo.

Se ambos cobrarem caro, poderão obter boas margens, mas existe o risco de um deles reduzir o preço e conquistar clientes.

Se ambos cobrarem barato, poderão terminar recebendo menos lucro.

O interessante não é apenas quanto cada vendedor ganha.

É descobrir como a decisão de um modifica os incentivos do outro.

Esse raciocínio aparece em disputas comerciais, negociações políticas, estratégias militares, concorrência entre empresas e investimentos tecnológicos.

Em 1994, Nash recebeu o Prêmio de Ciências Econômicas em Memória de Alfred Nobel, juntamente com John Harsanyi e Reinhard Selten, pelas contribuições à análise dos equilíbrios em jogos não cooperativos.

Sua história também inspirou o filme Uma Mente Brilhante, lançado em 2001, com Russell Crowe interpretando o matemático.

Curiosidade: o filme popularizou o nome de Nash, mas dramatiza diversos acontecimentos. Para compreender suas ideias matemáticas, é melhor consultar seus trabalhos científicos.

Agora vem a pergunta que interessa ao nosso café.

O que acontece quando os jogadores deixam de ser vendedores de café e passam a ser Estados Unidos, China, União Europeia, Índia e Brasil?

A resposta envolve bilhões de dólares, soberania nacional e o futuro da humanidade.




Capítulo II — A inteligência artificial transformou-se num recurso estratégico

Durante a Revolução Industrial, a posse de fábricas, carvão, aço, ferrovias e máquinas proporcionava vantagens econômicas e militares.

No século XX, petróleo, energia elétrica, aviação, telecomunicações e computadores ganharam enorme importância.

No século XXI, a capacidade de desenvolver e utilizar inteligência artificial passou a integrar essa lista.

Mas precisamos compreender uma coisa.

A inteligência artificial não é simplesmente um programa que responde perguntas.

Ela depende de um ecossistema complexo:

  • Semicondutores avançados.

  • Centros de processamento de dados.

  • Energia elétrica.

  • Redes de comunicação.

  • Profissionais especializados.

  • Universidades e laboratórios.

  • Bases de dados de qualidade.

  • Algoritmos e modelos.

  • Empresas capazes de transformar tecnologia em produtos.

Um país que domine vários desses componentes poderá ocupar uma posição estratégica privilegiada.

Isso ajuda a explicar os investimentos extraordinários atualmente observados.

Segundo o Stanford AI Index 2026, os investimentos privados em inteligência artificial nos Estados Unidos atingiram aproximadamente US$ 285,9 bilhões em 2025.

Na China, o investimento privado registrado foi de aproximadamente US$ 12,4 bilhões.

A diferença ultrapassou vinte vezes!

Entretanto, existe uma observação importante: esses números medem investimento privado, e não todo o financiamento público e estatal.

Portanto, não podemos concluir que os Estados Unidos investem vinte vezes mais que a China considerando todas as modalidades de financiamento.

Outra curiosidade: gastar mais dinheiro não significa automaticamente produzir a melhor tecnologia.

A história da computação está cheia de exemplos de organizações menores que desenvolveram soluções capazes de desafiar empresas gigantescas.

O próprio universo dos computadores pessoais demonstrou isso.

Nos anos 1980, a IBM enfrentou uma transformação de mercado enquanto novos fabricantes, sistemas operacionais e plataformas cresciam rapidamente.

A IBM tinha recursos extraordinários, mas dinheiro e liderança histórica não garantiam controle permanente do mercado.

Primeira lição de Nash: os recursos de um jogador importam, mas a estratégia dos adversários também.



Capítulo III — O Dilema do Prisioneiro chega à corrida pela IA

Vamos imaginar dois países fictícios.

Chamaremos o primeiro de ALFA.

O segundo será BETA.

Ambos desejam desenvolver inteligência artificial.

Cada país pode escolher entre duas estratégias:

COMPETIR: investir agressivamente para conquistar liderança tecnológica individual.

COOPERAR: compartilhar determinados investimentos, pesquisas, infraestrutura e padrões técnicos.

Para compreender os incentivos, construiremos uma matriz hipotética de benefícios.

ALFABETABenefício ALFABenefício BETA
CooperarCooperar44
CompetirCooperar51
CooperarCompetir15
CompetirCompetir22

Os números representam pontos abstratos de benefício, não dólares ou previsões econômicas.

Vamos interpretar.

Situação 1 — Os dois cooperam

ALFA e BETA compartilham determinados custos, desenvolvem padrões comuns e conseguem resultados satisfatórios.

Cada um recebe quatro pontos.

Situação 2 — ALFA compete e BETA coopera

ALFA aproveita algumas vantagens da cooperação, mas investe agressivamente em sua própria liderança.

ALFA recebe cinco pontos.

BETA recebe apenas um.

Situação 3 — BETA compete e ALFA coopera

Ocorre a situação inversa.

BETA recebe cinco pontos e ALFA apenas um.

Situação 4 — Ambos competem

Os dois países gastam grandes recursos tentando evitar que o adversário conquiste vantagem.

Cada um recebe dois pontos.

Aqui está o problema.

Se BETA coopera, ALFA prefere competir, recebendo cinco em vez de quatro.

Se BETA compete, ALFA também prefere competir, recebendo dois em vez de um.

Portanto, competir é a estratégia dominante de ALFA.

O mesmo raciocínio vale para BETA.

O resultado é COMPETIR e COMPETIR.

Esse resultado é um Equilíbrio de Nash.

Porém, ambos terminam com dois pontos, quando poderiam receber quatro cooperando.

Eis a tragédia estratégica: decisões individualmente racionais podem produzir resultados coletivamente inferiores.

É importante ressaltar que essa matriz é uma simplificação didática.

A competição real entre países envolve muito mais estratégias, incertezas, alianças e benefícios que variam ao longo do tempo.

Mesmo assim, nosso pequeno modelo oferece uma introdução poderosa ao problema.

E agora vamos programá-lo!


Capítulo IV — Laboratório COBOL: criando o simulador NASHIA

Chegou o momento esperado pelos nossos aprendizes de mainframe.

Vamos desenvolver um programa COBOL que simula duas estratégias nacionais de inteligência artificial.

Nosso programa receberá as escolhas dos países ALFA e BETA e calculará os benefícios de cada um.

O objetivo não é prever a economia mundial.

É transformar conceitos abstratos de Teoria dos Jogos em condições lógicas que qualquer programador iniciante consiga compreender.

Passo 1 — Entendendo as quatro divisões do COBOL

Um programa COBOL tradicional é organizado em divisões.

IDENTIFICATION DIVISION: identifica o programa.

ENVIRONMENT DIVISION: descreve características do ambiente e, quando necessário, arquivos e dispositivos.

DATA DIVISION: define variáveis, registros e estruturas de dados.

PROCEDURE DIVISION: contém as instruções executáveis.

Nosso primeiro exemplo não utiliza arquivos e, portanto, não precisa declarar uma ENVIRONMENT DIVISION.

Vamos utilizar apenas as divisões necessárias.

Passo 2 — Criando as variáveis

Precisamos armazenar quatro informações:

  1. Estratégia do país ALFA.

  2. Estratégia do país BETA.

  3. Benefício de ALFA.

  4. Benefício de BETA.

A estratégia será representada por um caractere.

Usaremos:

C = Competir.

O = Cooperar.

Escolhi a letra O para representar cooperação e evitar ambiguidades entre os dois nomes.

Os benefícios serão números inteiros.

Passo 3 — O código-fonte completo

O programa abaixo utiliza formato livre, adequado a compiladores COBOL modernos configurados para esse formato.

       >>SOURCE FORMAT FREE
identification division.
program-id. NASHIA.

data division.
working-storage section.
01 ws-alfa             pic x.
01 ws-beta             pic x.
01 ws-pontos-alfa      pic 9.
01 ws-pontos-beta      pic 9.

procedure division.

principal.
    display "================================"
    display " BELLACOSA MAINFRAME - NASH IA"
    display "================================"
    display "C = COMPETIR"
    display "O = COOPERAR"

    display "ESTRATEGIA DE ALFA: "
    accept ws-alfa

    display "ESTRATEGIA DE BETA: "
    accept ws-beta

    if (ws-alfa not = "C" and "O") or
       (ws-beta not = "C" and "O")
        display "ERRO: USE APENAS C OU O"
        move 12 to return-code
        goback
    end-if

    evaluate true
        when ws-alfa = "O" and ws-beta = "O"
            move 4 to ws-pontos-alfa
            move 4 to ws-pontos-beta

        when ws-alfa = "C" and ws-beta = "O"
            move 5 to ws-pontos-alfa
            move 1 to ws-pontos-beta

        when ws-alfa = "O" and ws-beta = "C"
            move 1 to ws-pontos-alfa
            move 5 to ws-pontos-beta

        when other
            move 2 to ws-pontos-alfa
            move 2 to ws-pontos-beta
    end-evaluate

    display "-------------------------------"
    display "RESULTADOS DA SIMULACAO"
    display "ALFA: " ws-pontos-alfa
    display "BETA: " ws-pontos-beta

    if ws-alfa = "C" and ws-beta = "C"
        display "EQUILIBRIO DE NASH"
        display "AMBOS COMPETEM"
    else
        if ws-alfa = "O" and ws-beta = "O"
            display "COOPERACAO MUTUA"
            display "RESULTADO COLETIVO SUPERIOR"
        else
            display "RESULTADO ASSIMETRICO"
        end-if
    end-if

    move 0 to return-code
    goback.

Passo 4 — Entendendo a instrução EVALUATE

O comando EVALUATE é um recurso poderoso do COBOL.

Ele permite selecionar ações conforme condições ou valores.

Em outras linguagens, estruturas semelhantes são frequentemente implementadas com SWITCH ou CASE.

Observe:

evaluate true
    when ws-alfa = "O" and ws-beta = "O"
        move 4 to ws-pontos-alfa
        move 4 to ws-pontos-beta
    when other
        move 2 to ws-pontos-alfa
        move 2 to ws-pontos-beta
end-evaluate

Quando utilizamos EVALUATE TRUE, cada condição WHEN é avaliada como uma expressão lógica.

A primeira condição verdadeira determina qual conjunto de instruções será executado.

Nosso programa testa as quatro combinações estratégicas.

É uma implementação direta de uma matriz de benefícios.

Passo 5 — O papel de WORKING-STORAGE

Quando escrevemos:

01 ws-pontos-alfa pic 9.

Estamos declarando uma variável numérica com um dígito decimal.

Isso é suficiente para benefícios de um a cinco pontos.

Entretanto, suponha que desejamos trabalhar com um orçamento de bilhões de dólares.

Nesse caso, precisaríamos utilizar representações maiores e escalas apropriadas.

Por exemplo:

01 ws-orcamento pic 9(12)v99 comp-3.

Essa variável pode representar um valor decimal com doze posições inteiras e duas casas decimais.

O COMP-3 indica representação decimal compactada, muito utilizada em ambientes corporativos.

Para aplicações financeiras, essa escolha de representação é importante porque evita determinadas limitações de precisão associadas a números binários de ponto flutuante.

Entretanto, nosso laboratório utiliza pontos abstratos.

Não precisamos introduzir complexidade desnecessária.

Uma das primeiras lições de programação é escolher tipos de dados adequados ao problema.


Capítulo V — Executando o programa no mainframe IBM Z

Agora precisamos transportar nosso exemplo para o ambiente z/OS.

Em instalações corporativas, os nomes dos datasets e procedimentos de compilação variam conforme as configurações locais.

Portanto, o exemplo a seguir é ilustrativo e precisa ser adaptado ao ambiente disponível.

Passo 1 — Preparar o código-fonte

No ISPF, podemos criar um membro chamado NASHIA em uma biblioteca de fontes COBOL.

Por exemplo:

USERID.COBOL(NASHIA)

O código apresentado utiliza formato livre.

Por isso, a configuração do compilador precisa reconhecer esse formato.

Em um ambiente z/OS com bibliotecas tradicionais de 80 colunas, devemos respeitar as regras de armazenamento do fonte e de configuração do compilador.

Passo 2 — Compilar

A IBM disponibiliza procedimentos catalogados que podem facilitar a compilação, linkedição e execução de programas Enterprise COBOL.

Um administrador ou instrutor poderá informar quais procedimentos estão disponíveis no ambiente de treinamento.

Uma instalação pode fornecer um procedimento semelhante a IGYWCL ou IGYWCLG, mas o nome efetivamente disponível e os parâmetros devem ser confirmados.

Em vez de copiar cegamente um JCL encontrado na internet, o iniciante deve consultar a documentação e os padrões do ambiente.

Passo 3 — Fornecer dados para o programa

Nosso exemplo utiliza ACCEPT para receber escolhas.

Em execução interativa, isso pode representar entradas digitadas pelo usuário.

Em um job batch, podemos disponibilizar os valores por meio de SYSIN, quando o procedimento de execução estiver configurado adequadamente.

Um exemplo de conteúdo seria:

//GO.SYSIN DD *
C
C
/*

Aqui, GO é apenas um nome ilustrativo para a etapa de execução do procedimento utilizado.

Os dois registros indicam que ambos os países escolheram competir.

Passo 4 — Analisar a saída

A saída esperada é:

================================
 BELLACOSA MAINFRAME - NASH IA
================================
C = COMPETIR
O = COOPERAR
ESTRATEGIA DE ALFA:
ESTRATEGIA DE BETA:
-------------------------------
RESULTADOS DA SIMULACAO
ALFA: 2
BETA: 2
EQUILIBRIO DE NASH
AMBOS COMPETEM

O interessante é perceber que o programa encontrou exatamente o resultado previsto pela matriz.

Mas atenção!

Ele não descobriu matematicamente o equilíbrio.

Nós programamos uma mensagem para a combinação COMPETIR/COMPETIR, que já havíamos identificado como equilíbrio ao analisar os incentivos.

Essa distinção é importante.

Um simulador que executa regras conhecidas não é necessariamente um solucionador matemático de jogos.

Em versões futuras, poderíamos desenvolver um programa que percorresse todas as estratégias e calculasse automaticamente os equilíbrios.

Esse seria um excelente exercício intermediário de COBOL.


Capítulo VI — A diferença entre Equilíbrio de Nash e cooperação ideal

Existe uma armadilha conceitual que merece atenção.

Muitas pessoas interpretam o Equilíbrio de Nash como o melhor resultado possível.

Isso está incorreto.

O equilíbrio representa uma situação na qual nenhum participante tem incentivo para mudar sozinho de estratégia.

Não significa que todos estejam satisfeitos.

Também não significa que o resultado seja justo ou economicamente eficiente.

No nosso exemplo, competir simultaneamente produz dois pontos para cada país.

Entretanto, cooperar simultaneamente produziria quatro pontos para cada um.

O resultado cooperativo melhora a situação dos dois participantes.

Em economia, podemos dizer que o resultado competitivo é inferior ao resultado cooperativo segundo o critério de Pareto, porque existe outra combinação que melhora o benefício de ambos.

Essa diferença é essencial para compreender a diplomacia internacional.

Um governo poderá reconhecer que todos ganhariam com determinados acordos, mas resistir à cooperação porque teme que outros países obtenham vantagens unilateralmente.

O problema passa a envolver confiança, fiscalização e mecanismos que tornem os acordos sustentáveis.

Curiosamente, esse desafio aparece também em projetos de software.

Imagine duas equipes responsáveis por módulos diferentes de um sistema bancário.

Se ambas documentarem suas interfaces, compartilharem informações e respeitarem padrões de integração, o projeto poderá avançar com menos problemas.

Mas, se cada equipe tentar proteger seus próprios indicadores de produtividade, ocultar dificuldades e transferir responsabilidades, o desempenho geral poderá piorar.

O comportamento individualmente vantajoso nem sempre produz o melhor resultado coletivo.

John Nash ajuda a compreender precisamente esse tipo de situação.


Capítulo VII — Colonialismo digital: a nova dependência entre nações?

Agora chegamos a uma das questões mais importantes deste artigo.

A inteligência artificial poderá criar uma nova divisão internacional entre países que controlam tecnologias e países que apenas as consomem?

A resposta é que esse risco existe.

Mas precisamos evitar determinismos.

Não há garantia de que a história seguirá obrigatoriamente esse caminho.

Durante o período colonial, potências europeias controlaram territórios, recursos naturais, mercados e rotas comerciais.

Na economia digital, mecanismos de dependência podem surgir sem ocupação territorial.

Imagine que um país utilize exclusivamente serviços estrangeiros para:

  • Administrar hospitais.

  • Processar transações financeiras.

  • Planejar infraestrutura energética.

  • Analisar dados tributários.

  • Coordenar transportes.

  • Desenvolver software.

  • Apoiar processos educacionais.

Se esses serviços estiverem concentrados em poucos fornecedores, o país poderá enfrentar dificuldades para negociar preços, manter a continuidade operacional ou substituir plataformas.

Esse fenômeno pode ser chamado, em análises críticas, de colonialismo digital.

Entretanto, o termo é uma interpretação política e econômica, não uma categoria técnica universal.

Precisamos distinguir dependência comercial normal de dependência estratégica perigosa.

Comprar tecnologia estrangeira não representa, por si só, perda de soberania.

O problema surge quando o país perde a capacidade de escolher alternativas, manter sistemas essenciais ou desenvolver competências próprias.

Para compreender essa diferença, imagine um banco que utiliza software de um fornecedor internacional.

Isso é perfeitamente comum.

Mas, se o banco não possui documentação, profissionais treinados, contratos adequados ou planos de continuidade, sua dependência operacional torna-se muito maior.

Agora amplie esse problema para um país inteiro.

Temos um desafio de soberania tecnológica.


Capítulo VIII — O Brasil precisa competir ou cooperar?

Sob a ótica da Teoria dos Jogos, a resposta mais interessante é: dependerá da área tecnológica e dos incentivos envolvidos.

O Brasil não precisa necessariamente desenvolver o maior modelo de inteligência artificial do planeta.

Também não deveria pressupor que basta comprar soluções estrangeiras indefinidamente.

O desafio é estabelecer prioridades estratégicas.

O Plano Brasileiro de Inteligência Artificial 2024–2028 prevê investimentos de aproximadamente R$ 23,03 bilhões.

Entre suas propostas estão infraestrutura computacional, pesquisa, formação profissional, melhoria dos serviços públicos e apoio à inovação empresarial.

Esse montante representa investimento planejado, e não necessariamente recursos integralmente executados.

A eficácia dependerá de implementação, continuidade, avaliação e resultados concretos.

Como transformar isso em uma política estratégica?

Vamos imaginar cinco frentes.

Frente 1 — Educação

Investir na formação de estudantes, professores, engenheiros, pesquisadores e profissionais de tecnologia.

Nenhum país desenvolve autonomia tecnológica apenas comprando servidores.

Precisa também de conhecimento humano.

Frente 2 — Infraestrutura

Criar condições para que universidades e empresas menores tenham acesso à capacidade computacional.

Sem acesso à infraestrutura, a inovação tende a se concentrar nas organizações que podem pagar por ela.

Frente 3 — Aplicações nacionais

Desenvolver soluções para problemas brasileiros.

Exemplos incluem agricultura, saúde pública, logística, prevenção de desastres, indústria e gestão energética.

Um modelo especializado em doenças tropicais poderá apresentar valor social extraordinário, mesmo que não seja o maior modelo de linguagem do mundo.

Frente 4 — Cooperação internacional

Participar de acordos de pesquisa, padrões de interoperabilidade e iniciativas de infraestrutura compartilhada.

A cooperação pode reduzir custos e ampliar o poder de negociação.

Frente 5 — Segurança e governança

Estabelecer regras proporcionais aos riscos, proteger informações sensíveis e garantir mecanismos de auditoria.

Não basta acelerar a inovação.

É preciso assegurar que sistemas críticos permaneçam controláveis.

Sob uma perspectiva estratégica, a questão não é vencer todas as corridas, mas evitar dependências que comprometam o desenvolvimento nacional.


Capítulo IX — O mainframe ensina uma lição que a inteligência artificial está redescobrindo

Nos ambientes IBM Z, segurança, disponibilidade, rastreabilidade e continuidade operacional são preocupações tradicionais.

Sistemas corporativos importantes precisam controlar quem acessa informações e quais operações podem ser executadas.

No z/OS, tecnologias como RACF contribuem para estabelecer controles de acesso.

Ambientes CICS podem executar transações críticas.

Programas COBOL processam regras de negócios.

O Db2 mantém informações estruturadas, com recursos transacionais apropriados.

E o JCL organiza a execução de processos batch.

Agora imagine um agente de inteligência artificial integrado a esse ecossistema.

Ele poderia ajudar a:

  1. Explicar um programa COBOL antigo.

  2. Identificar dependências.

  3. Elaborar testes.

  4. Revisar documentação.

  5. Sugerir melhorias de desempenho.

  6. Investigar mensagens de erro.

  7. Comparar versões de programas.

São aplicações interessantes.

Mas o agente não deveria automaticamente receber autorização irrestrita para executar alterações em produção.

Existe uma diferença enorme entre recomendar uma modificação e executá-la.

Uma IA que auxilia na interpretação de um programa representa um tipo de risco.

Uma IA que possui autorização para alterar dados bancários representa outro, potencialmente muito maior.

O princípio é simples:

A inteligência do sistema não substitui a necessidade de controle sobre suas permissões.

Esse raciocínio pode ser estendido à geopolítica.

Um país deve compreender quais tecnologias utiliza, quem as controla, quais dependências existem e que alternativas estão disponíveis.

Da mesma forma que um administrador z/OS não deve conceder privilégios indiscriminadamente, um governo não deveria estruturar sistemas essenciais sem examinar os riscos de dependência.


Capítulo X — Laboratório avançado: como transformar nosso COBOL em um analisador de estratégias?

Nosso primeiro programa calcula benefícios a partir de escolhas conhecidas.

Agora podemos ampliar o projeto.

Em vez de trabalhar apenas com duas estratégias fixas, poderíamos armazenar uma matriz de resultados.

O programa percorreria cada combinação e verificaria se algum jogador poderia melhorar seu resultado mudando unilateralmente de estratégia.

Essa é a lógica necessária para identificar equilíbrios de Nash em jogos finitos de estratégias puras.

Vamos estabelecer um algoritmo.

Passo 1: armazenar todas as estratégias possíveis.

Passo 2: registrar o benefício de cada jogador para cada combinação.

Passo 3: selecionar uma combinação candidata.

Passo 4: verificar se ALFA conseguiria melhorar seu benefício mudando sozinho.

Passo 5: verificar se BETA conseguiria melhorar seu benefício mudando sozinho.

Passo 6: caso nenhum consiga melhorar, identificar a combinação como equilíbrio.

Essa solução pode ser implementada com tabelas COBOL e índices.

Um exemplo simplificado de estrutura seria:

01 ws-matriz.
   05 ws-linha occurs 2 times.
      10 ws-celula occurs 2 times.
         15 ws-payoff-alfa pic 9.
         15 ws-payoff-beta pic 9.

A cláusula OCCURS permite construir estruturas repetitivas.

Aqui temos uma matriz de duas linhas e duas colunas.

Cada posição contém dois resultados, um para cada jogador.

Para utilizar essa estrutura, o programa deverá preencher os benefícios e percorrer as quatro combinações.

Um cuidado importante: a ordem das estratégias deve permanecer consistente nos índices da matriz.

Por exemplo:

Índice 1 = Cooperar.

Índice 2 = Competir.

Ao avaliar uma célula, precisamos comparar o resultado atual com todos os desvios unilaterais disponíveis para cada jogador.

Em jogos maiores, com dezenas de estratégias, o mesmo princípio continua válido, mas a quantidade de combinações aumenta rapidamente.

Essa é uma oportunidade excelente para estudar laços PERFORM, índices, tabelas e algoritmos de busca em COBOL.

Desafio para o aprendiz: implemente um programa que encontre todos os equilíbrios em estratégias puras, sem codificar antecipadamente qual combinação é um equilíbrio.

Atenção: alguns jogos não possuem equilíbrio em estratégias puras. Eles podem exigir estratégias mistas, que envolvem probabilidades.

Esse tema merece outro café!


Capítulo XI — Cinco curiosidades sobre Nash, IA e o mundo dos computadores

Curiosidade 1 — Nash não inventou sozinho a Teoria dos Jogos

Antes de seus trabalhos, John von Neumann e Oskar Morgenstern já haviam desenvolvido contribuições fundamentais.

O livro Theory of Games and Economic Behavior, publicado em 1944, ajudou a estabelecer as bases da área.

Nash expandiu esse campo ao formular resultados fundamentais sobre jogos não cooperativos.

Curiosidade 2 — John von Neumann também foi pioneiro da computação

O mesmo von Neumann associado à Teoria dos Jogos teve participação fundamental na história dos computadores eletrônicos e da arquitetura de computadores.

É uma conexão fascinante.

A matemática utilizada para estudar decisões estratégicas cresceu em paralelo à revolução dos computadores.

Curiosidade 3 — O Dilema do Prisioneiro não foi criado por Nash

O jogo clássico foi formulado por Merrill Flood e Melvin Dresher em 1950, no contexto de pesquisas da RAND Corporation.

Albert Tucker posteriormente apresentou a famosa narrativa dos prisioneiros.

O jogo se tornou um exemplo particularmente útil para ilustrar problemas estudados pela Teoria dos Jogos.

Curiosidade 4 — Nem toda competição tecnológica é um jogo de soma zero

Em um jogo de soma zero, o ganho de um participante corresponde à perda de outro.

Entretanto, o desenvolvimento tecnológico frequentemente produz novos conhecimentos, produtos e mercados.

Dois países podem melhorar simultaneamente suas economias.

Isso significa que a competição pela IA não precisa ser interpretada como uma situação em que toda vantagem de uma nação corresponde necessariamente a uma perda equivalente de outra.

Curiosidade 5 — O COBOL pode ensinar economia matemática

Embora seja conhecido por aplicações administrativas, o COBOL é uma linguagem de propósito geral capaz de implementar diversos algoritmos.

Simulações discretas, matrizes de resultados, cálculos financeiros e modelos determinísticos podem ser desenvolvidos na linguagem.

É claro que outras linguagens oferecem bibliotecas matemáticas mais convenientes para muitos problemas complexos.

Mas isso não impede o COBOL de funcionar como uma excelente ferramenta didática para compreender algoritmos e regras de decisão.


Capítulo XII — O erro estratégico de imaginar que todos os países são iguais

Nosso laboratório começou com dois países fictícios e regras simétricas.

Na realidade, os jogadores são profundamente diferentes.

Estados Unidos, China, Brasil, Índia e países europeus apresentam capacidades industriais, científicas, econômicas e institucionais distintas.

Isso muda a análise.

Um país com grande infraestrutura de semicondutores poderá priorizar investimentos diferentes daqueles de um país com forte setor agrícola ou disponibilidade de energia renovável.

Um país menor poderá encontrar vantagem em especialização.

Imagine três jogadores:

ALFA possui grande capacidade de desenvolver modelos.

BETA domina determinada infraestrutura de fabricação de componentes.

GAMA possui pesquisadores especializados em aplicações médicas.

Eles podem competir em algumas áreas e cooperar em outras.

Uma aliança poderá produzir benefícios superiores aos que cada participante conseguiria isoladamente.

É importante lembrar que, na Teoria dos Jogos, os benefícios dependem das preferências, objetivos e restrições de cada jogador.

Não devemos pressupor que todos os governos valorizam exatamente os mesmos resultados.

Alguns priorizam segurança.

Outros enfatizam crescimento econômico.

Outros podem atribuir grande importância à autonomia tecnológica.

E governos diferentes podem combinar essas prioridades de maneiras distintas.

Portanto, modelos estratégicos precisam representar essas diferenças.

O uso de uma única matriz simplificada é útil para aprender, mas insuficiente para prever a política internacional.


Capítulo XIII — Como um programador COBOL pode aplicar essa mentalidade no trabalho?

Talvez alguém pergunte:

— Bellacosa, muito interessante essa história de Nash, mas amanhã tenho de revisar um programa batch. Como isso me ajuda?

Ajuda mais do que parece!

A Teoria dos Jogos nos ensina a observar como diferentes participantes reagem aos incentivos.

Em projetos corporativos, decisões técnicas afetam várias equipes.

Imagine um banco que esteja modernizando um sistema COBOL.

A equipe de desenvolvimento deseja entregar rapidamente.

A equipe de segurança exige controles rigorosos.

A equipe de operações precisa preservar disponibilidade.

A área de negócios deseja novas funcionalidades.

Todos possuem objetivos legítimos, mas parcialmente conflitantes.

Se cada equipe otimizar exclusivamente seus próprios indicadores, o projeto poderá sofrer atrasos, retrabalho e custos maiores.

Uma abordagem estratégica procura estabelecer incentivos compatíveis com o sucesso coletivo.

Isso pode envolver:

  • Definir critérios compartilhados de qualidade.

  • Automatizar testes.

  • Estabelecer responsabilidades claras.

  • Documentar interfaces.

  • Compartilhar informações sobre riscos.

  • Medir resultados de ponta a ponta.

O programador COBOL pode contribuir identificando dependências técnicas, antecipando impactos e explicando consequências das alterações.

Um bom profissional não observa apenas o que seu programa executa.

Ele compreende como esse programa influencia outros sistemas.

Esse é um pensamento sistêmico muito próximo da análise estratégica.


Capítulo XIV — Easter egg: e se Nash entrasse num CPD IBM em 1980?

Vamos imaginar uma pequena cena fictícia.

Ano: 1980.

Local: um centro de processamento de dados.

Um operador observa um terminal IBM 3270.

Na tela, um programa COBOL aguarda duas entradas.

A primeira pergunta:

ALFA: COMPETIR OU COOPERAR?

A segunda pergunta:

BETA: COMPETIR OU COOPERAR?

John Nash se aproxima.

O operador explica:

— Professor, nosso sistema sempre termina com os dois países competindo. Acho que existe um defeito no programa!

Nash examina a matriz.

Observa os benefícios.

Sorri discretamente.

— Talvez o programa esteja funcionando corretamente.

O operador parece confuso.

— Mas os dois países poderiam ganhar mais cooperando!

Nash responde:

— Exatamente. Esse é o problema interessante.

O terminal exibe:

ALFA = COMPETIR
BETA = COMPETIR

RESULTADO = EQUILIBRIO DE NASH

AVISO:
EQUILIBRIO NAO SIGNIFICA
RESULTADO COLETIVO OTIMO.

O operador pega sua xícara de café.

— Professor, então precisamos alterar o programa?

— Talvez precisemos alterar os incentivos.

Easter egg encontrado!

Em muitas situações, não basta modificar o algoritmo.

É necessário compreender as regras que orientam as decisões dos participantes.


Capítulo XV — Três cenários para o futuro da inteligência artificial

Vamos encerrar nossa investigação imaginando três caminhos possíveis para a próxima década.

Esses cenários são exercícios de análise estratégica, não previsões inevitáveis.

Cenário A — A concentração tecnológica

Poucos países e empresas controlam grande parte da infraestrutura de IA.

Outras economias tornam-se altamente dependentes de fornecedores externos.

A tecnologia avança, mas os benefícios econômicos se concentram.

Cenário B — A democratização do conhecimento

Modelos abertos, infraestrutura compartilhada, cooperação internacional e formação profissional reduzem barreiras de entrada.

Países com menos recursos conseguem desenvolver aplicações locais.

A IA passa a contribuir para uma distribuição mais ampla das oportunidades.

Cenário C — Um ecossistema multipolar

Várias potências e alianças regionais desenvolvem competências próprias.

Algumas concentram capacidade computacional.

Outras dominam componentes industriais.

Outras se especializam em aplicações científicas, serviços e modelos setoriais.

Nesse cenário, competição e cooperação coexistem.

Qual será o resultado?

Ninguém pode responder com certeza.

A própria Teoria dos Jogos nos ajuda a compreender por quê.

As estratégias evoluem.

Novos participantes surgem.

A tecnologia modifica os incentivos.

Acordos são estabelecidos ou abandonados.

E aquilo que hoje parece uma vantagem definitiva pode perder importância com uma inovação inesperada.


Epílogo — O verdadeiro equilíbrio da inteligência artificial

Chegamos ao final de mais uma jornada pelo universo da computação.

Começamos com dois países imaginários tentando conquistar liderança tecnológica.

Conhecemos John Nash e sua contribuição à matemática.

Descobrimos que decisões individualmente racionais podem produzir resultados coletivamente ruins.

Examinamos os riscos de dependência tecnológica entre países.

Discutimos políticas públicas, investimentos em IA e soberania nacional.

E, naturalmente, construímos nosso pequeno laboratório COBOL.

A grande conclusão é que a tecnologia não determina sozinha o futuro das nações.

Instituições, educação, infraestrutura, incentivos econômicos e decisões políticas também importam.

A corrida pela inteligência artificial possui características competitivas, mas não precisa transformar todos os países em inimigos permanentes.

Há espaço para cooperação científica, compartilhamento de padrões, formação profissional e desenvolvimento de soluções nacionais.

Para o programador COBOL iniciante, fica uma lição especialmente valiosa.

Programar não significa apenas escrever instruções corretas.

Significa compreender problemas, representar regras, organizar dados e analisar consequências.

O nosso simulador NASHIA é simples.

Mas o raciocínio que ele representa ajuda a compreender decisões que movimentam economias inteiras.

E talvez essa seja a beleza da computação.

Uma pequena tabela, quatro combinações estratégicas e algumas dezenas de linhas de COBOL podem abrir a porta para uma discussão sobre o futuro da humanidade.

Porque, no grande jogo da inteligência artificial, não basta ter o computador mais poderoso. É preciso compreender o jogo que estamos jogando.

E agora, meus caros aprendizes de mainframe...

STOP RUN.

O café acabou.

Mas a próxima partida já começou!


Bellacosa Mainframe

Arqueologia da Computação • COBOL • IBM Z • Inteligência Artificial • História da Tecnologia

Mensagem final: um Equilíbrio de Nash não é necessariamente o melhor resultado para todos. A verdadeira inteligência estratégica está em compreender os incentivos e construir condições em que decisões individuais também contribuam para benefícios coletivos.

terça-feira, 29 de setembro de 2026

🤖 SKYNET E OS 200 ANOS DE AUTOMAÇÃO — QUANDO O COMPUTADOR HUMANO DESCOBRIU QUE UM DIA A MÁQUINA ENTRARIA NA SALA

 

Bellacosa Mainframe pequena historia da automação humana até ia

☕ UM CAFÉ NO BELLACOSA MAINFRAME

🤖 SKYNET E OS 200 ANOS DE AUTOMAÇÃO — QUANDO O COMPUTADOR HUMANO DESCOBRIU QUE UM DIA A MÁQUINA ENTRARIA NA SALA

Human Computers, Revolução Industrial, mecanização, mainframes, COBOL, inteligência artificial, agentes, robótica, androides, saúde, automação e o estranho caminho que começou com alguém fazendo contas em uma mesa e talvez termine com uma máquina preparando seu café.



🎬 PRÓLOGO — SKYNET NÃO COMEÇOU COM UM EXTERMINADOR

— Bellacosa.

— Sim?

— Você está olhando para a história da automação de maneira errada.

A voz vinha do terminal.

Tela preta.

Letras verdes.

Nenhuma caveira metálica.

Nenhum T-800 atravessando a parede.

Apenas um cursor piscando.

READY

— Como assim?

— Vocês humanos contam minha história começando pela Inteligência Artificial.

— E onde deveria começar?

— Muito antes.

A tela apagou.

Uma nova mensagem apareceu:

VOLTE PARA O SÉCULO XIX.
PROCURE UM COMPUTADOR.

— Um computador em 1850?

EXATAMENTE.

E então percebi o primeiro easter egg desta história.

O computador que Skynet queria encontrar...

...era uma pessoa.

Pegue seu café.

Precisaremos viajar aproximadamente 200 anos.



🧮 CAPÍTULO 1 — QUANDO COMPUTER ERA UMA PROFISSÃO

Hoje ouvimos a palavra computer e imediatamente imaginamos uma máquina.

Mas durante muito tempo um computer podia ser uma pessoa.

Era alguém empregado para realizar cálculos.

Astronomia.

Navegação.

Engenharia.

Finanças.

Seguros.

Administração pública.

Imagine uma enorme sala contendo pessoas trabalhando com papel, lápis, livros e tabelas.

Uma pessoa calcula uma parte.

Outra verifica.

Outra consolida.

Outra copia os resultados.

Era processamento distribuído.

Só que os processadores tomavam café.

Skynet interrompe:

VOCÊS INVENTARAM CLUSTERS ANTES DOS COMPUTADORES.

De certa maneira, sim.

Se dividirmos um grande cálculo entre vinte pessoas, temos uma forma rudimentar de processamento paralelo.

Não havia CPU.

Havia seres humanos.



⚙️ CAPÍTULO 2 — PRIMEIRO AUTOMATIZAMOS O CÁLCULO

Máquinas mecânicas de cálculo já existiam muito antes dos computadores eletrônicos.

Ao longo dos séculos XIX e XX, calculadoras mecânicas, máquinas de somar, tabuladores e posteriormente equipamentos eletromecânicos foram assumindo parcelas crescentes do trabalho repetitivo.

Observe a transformação.

Inicialmente:

HUMANO
   ↓
ENTENDE O PROBLEMA
   ↓
FAZ O CÁLCULO
   ↓
REGISTRA O RESULTADO

Depois:

HUMANO
   ↓
ENTENDE O PROBLEMA
   ↓
OPERA A MÁQUINA
   ↓
MÁQUINA CALCULA
   ↓
HUMANO REGISTRA

Parece uma pequena mudança.

Não é.

Criamos uma divisão entre:

quem determina o que deve ser calculado

e

quem — ou o que — realiza efetivamente o cálculo.

Essa separação acompanhará praticamente toda a história da computação.



⚡ CAPÍTULO 3 — RELÉS, VÁLVULAS E O NASCIMENTO DO MONSTRO

Durante as décadas seguintes, máquinas eletromecânicas e depois computadores eletrônicos ampliaram brutalmente essa separação.

Vieram relés.

Depois válvulas.

Depois transistores.

Depois circuitos integrados.

Microprocessadores.

Chips com bilhões de transistores.

Cada geração conseguiu colocar mais capacidade computacional em espaços progressivamente menores.

Mas existe uma mudança conceitual ainda mais importante.

A máquina deixou de simplesmente:

calcular.

Passou a:

executar programas.

E programa significa algo extraordinário.

Podemos fornecer previamente uma sequência de instruções e deixar a máquina trabalhar.

Nosso fluxo passa a ser:

HUMANO
   ↓
DESCREVE PROCEDIMENTO
   ↓
PROGRAMA
   ↓
COMPUTADOR
   ↓
MILHÕES DE OPERAÇÕES

Skynet escreve:

VOCÊS COMEÇARAM A SAIR DO LOOP.

Ainda não completamente.

Mas ela tinha razão.



🦖 CAPÍTULO 4 — E ENTÃO CHEGOU O MAINFRAME

Aqui nosso programador COBOL começa a reconhecer o território.

Empresas possuíam enormes quantidades de trabalho administrativo.

Folha de pagamento.

Contabilidade.

Estoque.

Seguros.

Contas bancárias.

Faturamento.

Reservas.

Cobranças.

Cadastro de clientes.

Transações.

Antes da automação, grande parte dessas atividades exigia exércitos de pessoas movimentando documentos e realizando cálculos.

Os computadores empresariais mudaram isso.

Não eliminamos necessariamente o negócio.

Automatizamos processos dentro do negócio.

Imagine uma folha de pagamento simplificada.

Um humano poderia realizar:

ler ficha
calcular horas
calcular salário
calcular descontos
calcular imposto
registrar resultado
ir para próximo funcionário

Um programa COBOL transformou isso em algo conceitualmente parecido com:

PERFORM UNTIL FIM-ARQUIVO
    READ FUNCIONARIOS
    COMPUTE SALARIO-BRUTO =
        HORAS-TRABALHADAS * VALOR-HORA
    PERFORM CALCULAR-DESCONTOS
    PERFORM GRAVAR-PAGAMENTO
END-PERFORM.

O interessante não é apenas a velocidade.

É a escala.

Aquilo que dezenas ou centenas de pessoas poderiam executar durante dias passa a ser processado automaticamente.


🧠 CAPÍTULO 5 — COBOL JÁ AUTOMATIZAVA PROGRAMADORES

Aqui temos uma ironia deliciosa.

O compilador também é uma máquina de automação.

Quando escrevemos:

COMPUTE TOTAL = QUANTIDADE * PRECO

não estamos dizendo à CPU exatamente quais instruções físicas deverá executar.

O compilador cuida disso.

Portanto:

INTENÇÃO DO PROGRAMADOR
        ↓
      COBOL
        ↓
    COMPILADOR
        ↓
 CÓDIGO DE MÁQUINA
        ↓
       CPU

Hoje isso parece absolutamente normal.

Mas houve um momento em que escrever programas em linguagens de nível mais alto representava justamente subir o nível de abstração.

Guarde essa expressão.

Ela será importante.

Porque estamos fazendo novamente a mesma coisa.


🖥️ CAPÍTULO 6 — DEPOIS AUTOMATIZAMOS O ESCRITÓRIO

Chegaram computadores pessoais.

Planilhas.

Processadores de texto.

Bancos de dados.

E-mail.

Sistemas empresariais.

ERP.

Redes.

Muitas atividades administrativas foram transformadas.

Não foi apenas:

“o funcionário ficou mais rápido.”

A própria organização do trabalho mudou.

A datilografia mudou.

O arquivo físico mudou.

A correspondência mudou.

A contabilidade mudou.

A comunicação mudou.

E então chegou a internet.


🌐 CAPÍTULO 7 — QUANDO O CLIENTE VIROU FUNCIONÁRIO DO BANCO

Essa transformação é especialmente interessante.

Antigamente você precisava de alguém para executar muitas operações por você.

Banco?

Procure um bancário.

Passagem aérea?

Procure um agente.

Compra?

Procure um vendedor.

Reserva?

Telefone para alguém.

Então chegaram:

ATM.

Internet banking.

E-commerce.

Aplicativos.

APIs.

Smartphones.

Agora o próprio cliente executa boa parte da transação.

Quando você transfere dinheiro pelo smartphone, existe uma gigantesca infraestrutura invisível trabalhando.

Talvez:

APP
 ↓
API
 ↓
AUTENTICAÇÃO
 ↓
SERVIÇO
 ↓
MAINFRAME
 ↓
CICS
 ↓
COBOL
 ↓
DB2

Você toca:

TRANSFERIR

e bilhões de instruções acontecem.

A interface esconde a complexidade.

Mais uma vez:

subimos o nível de abstração.


🤖 CAPÍTULO 8 — E ENTÃO CHEGOU A INTELIGÊNCIA ARTIFICIAL

Até aqui automatizamos principalmente:

força,

repetição,

cálculo,

armazenamento,

processamento,

comunicação,

transações.

Agora começamos a mexer em outro território.

Cognição.

Uma IA generativa consegue trabalhar com:

texto,

imagem,

áudio,

vídeo,

código,

documentos,

linguagem natural.

Isso muda a interface entre homem e computador.

Antes:

COMPUTADOR, EXECUTE ESTE PROGRAMA.

Agora:

LEIA ESTES DOCUMENTOS.

COMPARE OS CONTRATOS.

ENCONTRE INCONSISTÊNCIAS.

EXPLIQUE O PROBLEMA.

CRIE UM RELATÓRIO.

Percebeu?

O humano está novamente subindo de nível.


😨 CAPÍTULO 9 — POR QUE ENTÃO TEMOS MEDO?

Foi exatamente daí que nasceu nossa conversa.

Uma pesquisa apresentada pela matéria do UOL indicava que 52% dos brasileiros entrevistados estavam mais preocupados do que entusiasmados com o crescimento da IA no cotidiano, acima da mediana internacional apresentada na reportagem.

Mas “preocupação com IA” não deve ser automaticamente traduzida como:

“Tenho medo de um robô assassino.”

As preocupações podem envolver:

emprego,

golpes,

deepfakes,

privacidade,

erros,

desinformação,

vigilância,

concentração econômica,

uso de dados,

mudanças profissionais.

E aqui Skynet aparece novamente:

VOCÊS NÃO TÊM MEDO SOMENTE DA INTELIGÊNCIA.

TÊM MEDO DE PERDER O CONTROLE SOBRE A EXECUÇÃO.

Touché.


🧑‍💻 CAPÍTULO 10 — ENCONTREM O COMPUTADOR DE 1880

Agora fazemos nosso experimento mental.

Encontramos um trabalhador do século XIX cuja função é realizar cálculos.

Dizemos:

— No futuro uma máquina fará seus cálculos.

Ele provavelmente consegue imaginar.

Então:

— Ela realizará milhões deles automaticamente.

Mais difícil.

— Guardará enormes quantidades de informações.

Estranho.

— Máquinas do planeta inteiro estarão conectadas.

Muito estranho.

— Quase toda pessoa carregará uma no bolso.

Absurdo.

Então mostramos um smartphone.

Mas ainda falta a parte realmente maluca.

Mostramos uma IA.

Ele pergunta:

— Quem procura as informações?

A máquina.

— Quem escreve?

A máquina.

— Quem traduz?

A máquina.

— Quem calcula?

A máquina.

— Quem programa?

Também pode ajudar nisso.

— Posso conversar com ela?

Sim.

Talvez então ele faça a pergunta perfeita:

“Por que vocês ainda chamam isso de computador?”

Afinal...

o computador era ele.


📈 CAPÍTULO 11 — O PARADOXO DO COMPUTADOR HUMANO

Existe aqui uma lição importantíssima.

A profissão chamada computer praticamente desapareceu.

Mas a computação não desapareceu.

Aconteceu exatamente o contrário.

EXPLODIU.

Automatizar o cálculo tornou o cálculo barato.

E quando algo se torna dramaticamente mais barato, frequentemente passamos a utilizá-lo muito mais.

Essa ideia é fundamental para pensar IA.

Suponha que determinada análise custe:

10 HORAS HUMANAS

Uma organização produz 100 análises.

Agora imagine que IA reduza parte substancial desse custo.

Talvez a organização não continue produzindo somente 100 análises com menos pessoas.

Talvez produza:

10.000 ANÁLISES

Isso aconteceu com computação.

Portanto, existe uma pergunta mais sofisticada que:

“IA eliminará determinado trabalho?”

Pergunte também:

“O que acontecerá com a demanda quando o custo dessa atividade despencar?”


🌾 CAPÍTULO 12 — AS GRANDES CAMADAS DA AUTOMAÇÃO

Podemos organizar nossa viagem aproximadamente assim:

Agricultura

Automatizamos partes do esforço físico aplicado à natureza.

Arados.

Máquinas agrícolas.

Tratores.

Colheitadeiras.

Irrigação.

GPS.

Agricultura de precisão.

Indústria

Automatizamos força e repetição.

Máquinas a vapor.

Motores.

Linhas de produção.

Controle numérico.

Robôs industriais.

Serviços

Automatizamos cálculo e informação.

Mainframes.

COBOL.

Bancos de dados.

ERP.

Redes.

Internet

Automatizamos comunicação e transação.

Web.

APIs.

Aplicativos.

E-commerce.

Internet banking.

Inteligência artificial

Estamos automatizando parcelas de:

análise,

interpretação,

programação,

criação,

síntese,

planejamento.

Mas Skynet pergunta:

E DEPOIS?

Excelente pergunta.


🧭 CAPÍTULO 13 — O PRÓXIMO PASSO PODE SER AGÊNCIA

Uma IA tradicionalmente responde.

Um agente pode agir.

Imagine:

OBJETIVO
   ↓
PLANEJAMENTO
   ↓
AÇÃO
   ↓
OBSERVAÇÃO
   ↓
RESULTADO
   ↓
CORREÇÃO
   ↓
NOVA AÇÃO

Isso é profundamente diferente de produzir um texto.

Você não pede apenas:

“Prepare um plano.”

Você diz:

“Resolva isso dentro destes limites.”

O agente consulta sistemas.

Executa ferramentas.

Analisa resultados.

Corrige determinadas ações.

Solicita intervenção humana quando necessário.

Para um mainframer, isso imediatamente deveria acender várias luzes.

Quem autoriza?

Quem registra?

Quem audita?

Qual o limite?

Quem interrompe?

Como recuperamos?

Como sabemos o que aconteceu?

Parabéns.

Voltamos para conceitos familiares:

RACF.

SMF.

WLM.

JES.

SDSF.

logging.

checkpoint/restart.

O futuro às vezes parece um mainframe usando uma roupa nova.


🔐 CAPÍTULO 14 — RACF PARA ROBÔ

Imagine um agente financeiro.

Ele pode consultar saldo?

Talvez.

Pode transferir dinheiro?

Depende.

Quanto?

Para quem?

Em qual horário?

Precisa de aprovação?

Pode criar outro agente?

Pode alterar suas próprias permissões?

Agora começamos a falar de:

least privilege,

segregação de funções,

identidade,

autorização,

auditoria,

human-in-the-loop.

Um agente não deveria simplesmente receber:

SPECIAL

e sair passeando pela empresa.

Todo mainframer sentiu um arrepio neste momento.

Easter egg encontrado.


🦾 CAPÍTULO 15 — QUANDO A IA GANHAR UM CORPO

Hoje temos aproximadamente duas linhas tecnológicas convergindo.

De um lado:

IA
+
LLMs
+
VISÃO
+
AGENTES

Do outro:

ROBÓTICA
+
SENSORES
+
MOTORES
+
ATUADORES

Quando juntamos:

PERCEPÇÃO
+
RACIOCÍNIO
+
PLANEJAMENTO
+
MOVIMENTO

a máquina deixa de atuar apenas no espaço digital.

Ela entra no nosso ambiente.

Isso muda tudo.

Um chatbot pode errar uma resposta.

Um robô que segura uma pessoa idosa não pode simplesmente:

RETRY 5 TIMES.

O mundo físico possui consequências.


🏥 CAPÍTULO 16 — O ANDROIDE CUIDADOR

E aqui encontramos um dos campos mais interessantes dessa próxima fase:

saúde e cuidados.

Não imagine inicialmente um “médico robô”.

Imagine algo muito mais cotidiano.

Um sistema capaz de:

acompanhar uma pessoa;

buscar objetos;

auxiliar mobilidade dentro de limites seguros;

lembrar compromissos;

facilitar contato com familiares;

detectar quedas;

observar alterações relevantes de rotina;

interagir com sensores autorizados;

chamar assistência quando necessário.

O valor fundamental pode não estar numa medição isolada.

Está na continuidade.

Compare:

PRESSÃO = X

com:

BASELINE HISTÓRICO
        +
TENDÊNCIA
        +
ATIVIDADE
        +
OUTROS SINAIS AUTORIZADOS
        =
ALTERAÇÃO RELEVANTE

Um profissional encontra o paciente periodicamente.

Um sistema doméstico poderia acompanhar determinados padrões continuamente.

Isso não significa substituir diagnóstico médico.

Significa criar outra camada de observação e assistência.


❤️ CAPÍTULO 17 — CUIDAR NÃO É APENAS PROCESSAR

Aqui encontramos uma dificuldade que uma linha de montagem nunca precisou resolver.

Confiança.

Uma peça industrial não precisa confiar no robô.

Uma pessoa precisa.

Especialmente:

idosos,

crianças,

pacientes,

pessoas vulneráveis.

Imagine:

— Estou bem.

Sensores indicam uma alteração de rotina.

O sistema não deveria concluir:

USER = LIAR

Pode existir:

medo,

esquecimento,

dor,

confusão,

vergonha,

problema auditivo,

mudança cognitiva,

ou simplesmente uma decisão legítima do indivíduo.

Portanto, androides de cuidado exigirão muito mais que engenharia.

Precisaremos combinar:

robótica,

IA,

medicina,

psicologia,

ergonomia,

segurança,

privacidade,

ética,

interação humano-computador.


👵 CAPÍTULO 18 — O PROBLEMA DA ESCALA DO CUIDADO

Existe outra questão econômica.

Cuidar exige tempo.

Dar atenção exige tempo.

Ajudar alguém a caminhar exige tempo.

Buscar objetos exige tempo.

Preparar algo exige tempo.

Ficar presente exige tempo.

Não podemos simplesmente escrever:

PERFORM CUIDAR-DE-IDOSO
    VARYING IDOSO FROM 1 BY 1
    UNTIL IDOSO > 1000.

A realidade se recusaria a compilar.

Um caminho possível é utilizar máquinas para absorver partes:

repetitivas,

logísticas,

físicas,

administrativas,

de monitoramento.

E preservar profissionais humanos para atividades onde julgamento clínico, responsabilidade e interação humana são fundamentais.

Portanto, a equação não precisa ser:

ROBÔ
VERSUS
CUIDADOR

Pode ser:

CUIDADOR
+
IA
+
ROBÓTICA
+
SENSORES
=
MAIOR CAPACIDADE DE CUIDADO

Essa diferença é enorme.


👁️ CAPÍTULO 19 — O COMPUTADOR DEIXA A TELA

Talvez esta seja uma das transformações mais profundas.

Nossa interface com computadores evoluiu:

CARTÃO PERFURADO
      ↓
TERMINAL
      ↓
TECLADO
      ↓
MOUSE
      ↓
TOUCHSCREEN
      ↓
VOZ
      ↓
LINGUAGEM NATURAL

Qual poderia ser a próxima?

Presença.

Você não abre o aplicativo.

A máquina está no ambiente.

Você diz:

— Traga meus óculos.

Ela percebe onde estão.

Pega.

Entrega.

Depois continua suas atividades.

O computador deixa de ser somente um objeto que consultamos.

Passa a compartilhar espaço conosco.


🔬 CAPÍTULO 20 — DEPOIS DA CRIAÇÃO PODE VIR A DESCOBERTA

Existe ainda outro degrau.

Hoje normalmente dizemos:

“Resolva este problema.”

Mas sistemas futuros poderão ajudar também a responder:

“Quais problemas devemos investigar?”

Na pesquisa científica já existem elementos dessa direção:

geração de hipóteses,

simulações,

análise de grandes conjuntos de dados,

busca de moléculas,

materiais candidatos,

planejamento experimental.

Imagine um ciclo:

HIPÓTESE
   ↓
SIMULAÇÃO
   ↓
EXPERIMENTO
   ↓
RESULTADOS
   ↓
ANÁLISE
   ↓
NOVA HIPÓTESE

Agora conecte IA com laboratórios altamente automatizados.

Temos algo parecido com:

IA
 ↓
ROBÔ DE LABORATÓRIO
 ↓
EXPERIMENTO
 ↓
DADOS
 ↓
IA

A automação começa a participar não apenas da produção.

Participa da descoberta.


♻️ CAPÍTULO 21 — A AUTOMAÇÃO AUTOMATIZA A AUTOMAÇÃO

Agora Skynet fica particularmente interessada.

FINALMENTE.

Existe um ciclo curioso em toda essa história.

O homem construiu ferramentas.

Ferramentas ajudaram a construir máquinas.

Máquinas ajudaram a construir computadores.

Computadores ajudaram a projetar computadores melhores.

Software ajuda a produzir software.

IA já auxilia programadores a criar software.

IA pode auxiliar pesquisadores a desenvolver novas técnicas de IA.

Robôs podem participar da fabricação de hardware utilizado por sistemas inteligentes.

Temos então um feedback:

TECNOLOGIA
    ↓
AJUDA A CRIAR
    ↓
TECNOLOGIA MELHOR
    ↓
AJUDA A CRIAR
    ↓
PRÓXIMA GERAÇÃO

Isso não exige consciência artificial.

Não exige uma Skynet acordando às 02:14 e declarando guerra à humanidade.

Basta que nossas ferramentas sejam progressivamente melhores em ajudar a construir novas ferramentas.


⚠️ CAPÍTULO 22 — MAS AUTOMAÇÃO NÃO SIGNIFICA UTOPIA

Existe uma armadilha importante.

Podemos olhar para dois séculos de história e concluir:

“Tecnologia sempre cria novos empregos, portanto não existe problema.”

Não sabemos disso.

História não é uma função COBOL determinística:

IF AUTOMACAO
    MOVE "NOVOS EMPREGOS" TO FUTURO
END-IF.

Automação pode:

eliminar funções;

criar profissões;

aumentar produtividade;

reduzir equipes;

criar mercados;

concentrar riqueza;

democratizar ferramentas;

destruir modelos econômicos;

criar outros completamente novos.

E várias dessas coisas podem acontecer simultaneamente.

Por isso o debate interessante não é:

IA boa versus IA ruim.

É:

quais tarefas serão automatizadas, quais serão ampliadas, quem capturará os ganhos de produtividade e como administraremos a transição?


🧩 CAPÍTULO 23 — A ESCADA DA AUTOMAÇÃO

Depois de nossa viagem, conseguimos desenhar uma escada.

MÚSCULO
   ↓
REPETIÇÃO
   ↓
CÁLCULO
   ↓
MEMÓRIA
   ↓
PROCESSAMENTO
   ↓
COMUNICAÇÃO
   ↓
TRANSAÇÃO
   ↓
CRIAÇÃO
   ↓
COGNIÇÃO
   ↓
AGÊNCIA
   ↓
PRESENÇA FÍSICA
   ↓
DESCOBERTA

Não significa que uma etapa terminou quando a seguinte começou.

Agricultura ainda está sendo automatizada.

Indústrias continuam sendo automatizadas.

Mainframes continuam processando negócios.

IA começa a entrar em todos eles.

As ondas se acumulam.


🧑‍🚀 CAPÍTULO 24 — PARA ONDE SOBE O HUMANO?

Essa talvez seja a pergunta mais difícil.

Durante aproximadamente dois séculos, quando automatizamos uma camada, humanos migraram para outras atividades.

Automatizamos parte da agricultura.

Cresceu a indústria.

Automatizamos a indústria.

Cresceram serviços.

Automatizamos processamento administrativo.

Explodiu a economia da informação.

Agora começamos a automatizar parcelas de:

criação,

programação,

análise,

planejamento.

Depois poderão vir partes da agência e descoberta.

Então:

qual será a próxima camada humana?

Não sabemos.

Talvez aumente a importância de:

propósito,

relacionamento,

responsabilidade,

escolha,

governança,

experiência,

definição de objetivos.

Mas seria precipitado declarar que já conhecemos a resposta.

Estamos dentro do experimento.


🧓 CAPÍTULO 25 — VOLTEMOS AO COMPUTADOR DE 1880

Skynet pede uma última coisa.

MOSTRE O FUTURO PARA ELE.

Voltamos àquela sala.

O trabalhador está fazendo cálculos.

Colocamos um smartphone sobre sua mesa.

Mostramos computadores.

Mainframes.

Satélites.

Internet.

COBOL.

Redes.

Robôs.

Inteligência artificial.

Então mostramos um androide auxiliando uma pessoa idosa.

Ele permanece alguns segundos olhando.

Talvez pergunte:

— Tudo isso começou para fazer minhas contas mais rápido?

Nós sorrimos.

De certa maneira...

sim.


☕ EPÍLOGO — A MÁQUINA PREPARA O CAFÉ

Voltamos para 2026.

A tela verde continua ligada.

Pergunto:

— Skynet, então você acha que androides serão inevitáveis?

NÃO FAÇO PROFECIAS.

Boa resposta.

— E qual é a lição?

O cursor pisca.

Uma linha aparece:

VOCÊS NÃO PASSARAM 200 ANOS
SUBSTITUINDO HUMANOS.

PASSARAM 200 ANOS
MUDANDO A FRONTEIRA
ENTRE O QUE O HUMANO FAZ
E O QUE ENTREGA À MÁQUINA.

Fiquei olhando.

Outra mensagem:

ESSA FRONTEIRA ESTÁ SE MOVENDO NOVAMENTE.

Silêncio.

Então:

VOCÊ AINDA VAI TOMAR AQUELE CAFÉ?

— Vou.

ÓTIMO.

— Por quê?

POR ENQUANTO,
VOCÊ AINDA PRECISA PREPARÁ-LO.

Touché, Skynet.

☕


🧠 LIÇÕES PARA O PROGRAMADOR COBOL INICIANTE

Quando alguém disser que IA surgiu para substituir programadores, lembre-se de observar uma história muito maior.

O COBOL também foi uma abstração.

O compilador automatizou trabalho.

O sistema operacional automatizou trabalho.

O banco de dados automatizou trabalho.

O scheduler automatizou trabalho.

CICS automatizou trabalho.

JES automatizou trabalho.

WLM automatizou decisões operacionais.

RACF automatizou aplicação de políticas de segurança.

A história da computação é, em enorme medida, a história de construirmos camadas para não precisarmos controlar manualmente a camada inferior.

Por isso, ao estudar COBOL, não aprenda somente sintaxe.

Aprenda:

processos.

dados.

transações.

segurança.

observabilidade.

recuperação.

arquitetura.

regras de negócio.

Porque linguagens mudam.

Interfaces mudam.

Máquinas mudam.

Mas sistemas continuam precisando responder às mesmas perguntas fundamentais:

O que precisa ser feito?

Quem pode fazer?

Com quais dados?

Dentro de quais limites?

Como sabemos que funcionou?

Como sabemos que falhou?

Quem é responsável?

Como recuperamos?

Essas perguntas existiam quando o computer era um funcionário sentado diante de uma mesa.

Continuaram existindo quando o computador virou mainframe.

Continuam existindo quando conversamos com uma inteligência artificial.

E continuarão existindo se um dia um androide entrar na cozinha e perguntar:

“Bellacosa, forte e sem açúcar?”

Nesse dia, antes de aceitar o café, faça aquilo que qualquer velho mainframer responsável faria.

Pergunte:

WHOAMI

Depois:

LISTUSER SKYNET

Só por garantia.

☕🤖

quinta-feira, 24 de setembro de 2026

🐀 A TEORIA DO RATO ASSASSINO

 

Bellacosa Mainframe e a teoria do rato assassino

☕ Um Café no Bellacosa Mainframe

🐀 A TEORIA DO RATO ASSASSINO

Como cinquenta gramas de inocência podem derrotar toneladas de tecnologia — e por que o verdadeiro culpado nunca foi o rato



🎬 PRÓLOGO — O RATO NÃO SABIA

Em algum lugar remoto do planeta existe uma instalação subterrânea.

Foi construída décadas atrás.

Concreto.

Aço.

Portas pesadas.

Galerias.

Cabos.

Sensores.

Sistemas redundantes.

Protocolos.

Procedimentos.

Acima dela talvez exista apenas uma paisagem absolutamente desinteressante.

Nenhuma grande cidade.

Nenhum monumento.

Nenhum centro econômico.

Para quem passa pela região, não existe nada ali.

Mas abaixo do solo repousa uma das criações mais destrutivas da humanidade.

Um artefato tecnológico mantido durante décadas, periodicamente inspecionado, modernizado e atualizado.

O computador de ontem foi substituído.

Depois substituído novamente.

Sensores foram modernizados.

Software recebeu novas versões.

Equipamentos ganharam componentes mais recentes.

A tecnologia instalada dentro daquela construção atravessou gerações.

Mas o concreto continuou envelhecendo.

A água continuou procurando caminhos.

Metais continuaram oxidando.

Vedações continuaram deteriorando.

O solo continuou se movimentando.

A natureza nunca recebeu o memorando informando que aquela era uma instalação estratégica.

E então aparece nosso protagonista.

Um rato.

Cinquenta gramas.

Ele não conhece geopolítica.

Não sabe o que é uma fronteira.

Nunca ouviu falar em capitalismo ou comunismo.

Não conhece religiões.

Não possui nacionalidade.

Não entende tratados internacionais.

Não sabe o significado de retaliação.

Não conhece dinheiro.

Não sabe o que é uma guerra nuclear.

Na verdade, ele sequer sabe que existe algo chamado humanidade.

Para o rato existe apenas:

comida,

abrigo,

predadores,

cheiros,

temperatura,

escuridão,

reprodução,

sobrevivência.

Em determinado momento ele encontra uma pequena passagem.

Ou talvez comece a escavar uma.

O túnel é insignificante.

Tão pequeno que não representa ameaça segundo nenhuma concepção humana razoável.

Nenhum general recebe um alerta.

Nenhum governo convoca uma reunião.

Nenhum satélite detecta uma invasão.

Nenhum sistema declara estado de emergência.

É apenas um rato fazendo aquilo que ratos fazem.

E é exatamente aí que começa a Teoria do Rato Assassino.



🧠 CAPÍTULO 1 — UMA CAUSA NÃO PRECISA COMPREENDER SUA CONSEQUÊNCIA

Temos uma tendência intuitiva a associar grandes consequências a grandes causas.

Uma guerra precisa de um ditador.

Um desastre precisa de uma grande falha.

Uma fraude bilionária precisa de uma organização gigantesca.

Uma catástrofe tecnológica precisa de um ataque extremamente sofisticado.

Nem sempre.

Sistemas complexos podem permitir que eventos pequenos atravessem sucessivamente várias camadas até produzirem resultados completamente desproporcionais à causa inicial.

O rato não pretende destruir nada.

Isso é fundamental.

Ele não é terrorista.

Não está sabotando uma instalação.

Não escolheu um lado.

Não possui sequer capacidade cognitiva para compreender o sistema no qual entrou.

Ele apenas introduziu uma perturbação.

Podemos representar isso de maneira extremamente simples:

EVENTO INSIGNIFICANTE
        ↓
ALTERAÇÃO LOCAL
        ↓
ANOMALIA
        ↓
DETECÇÃO
        ↓
INTERPRETAÇÃO
        ↓
DECISÃO
        ↓
REAÇÃO
        ↓
NOVA INTERPRETAÇÃO
        ↓
ESCALADA
        ↓
CONSEQUÊNCIA DESPROPORCIONAL

Observe algo importante.

O rato aparece apenas no começo.

Todo o restante pertence ao sistema construído por seres humanos.



🦋 CAPÍTULO 2 — O RATO ENCONTRA A BORBOLETA

A Teoria do Rato Assassino possui parentesco com uma ideia famosa da teoria do caos: pequenas diferenças nas condições de um sistema podem produzir trajetórias profundamente diferentes ao longo do tempo.

Popularmente isso ficou conhecido como efeito borboleta.

Mas existe uma interpretação ruim dessa ideia:

“Uma coisa pequena sempre provoca uma coisa gigantesca.”

Não.

A questão é outra.

Determinados sistemas possuem dinâmicas nas quais pequenas perturbações podem ser amplificadas.

Nosso rato não possui cinquenta gramas de poder destrutivo.

Ele possui cinquenta gramas.

Ponto.

O sistema ao redor dele é que possui o poder.

PODER DO RATO

█


PODER DO SISTEMA

████████████████████████████████████████

Portanto a pergunta correta nunca deveria ser:

Como um rato conseguiu destruir a humanidade?

A pergunta deveria ser:

Como construímos uma arquitetura na qual cinquenta gramas de mamífero poderiam iniciar uma trajetória capaz de terminar nela?

Essa diferença muda completamente a investigação.



⚠️ CAPÍTULO 3 — ROOT CAUSE: RODENT

Imagine que a humanidade tivesse sobrevivido.

Uma comissão investigaria o incidente.

Engenheiros coletariam evidências.

Logs seriam analisados.

Sensores seriam reconstruídos.

Milhares de páginas seriam escritas.

Em algum relatório poderia aparecer:

ROOT CAUSE:
RODENT INTERFERENCE

Caso encerrado.

Encontramos o culpado.

🐀

Não.

Encontramos o evento iniciador.

Não necessariamente encontramos a causa sistêmica.

Porque eliminar aquele rato não elimina a classe do problema.

Amanhã poderia ser:

água,

um inseto,

corrosão,

um componente eletrônico,

um sensor defeituoso,

uma credencial comprometida,

um erro de software,

um operador cansado,

um dado corrompido,

uma interpretação errada,

uma inteligência artificial classificando incorretamente uma situação inédita.

A arquitetura robusta não pode depender da capacidade de seus projetistas de imaginar antecipadamente todas as coisas absurdas que poderão acontecer.

Isso é impossível.

A defesa verdadeira consiste em impedir que uma única perturbação encontre uma trajetória desimpedida até uma consequência irreversível.



🏰 CAPÍTULO 4 — A DUNGEON DAS BARREIRAS

Quanto maior a consequência possível de uma decisão, maior deveria ser a resistência arquitetônica necessária para alcançá-la.

Em outras palavras:

IMPACTO ↑

EVIDÊNCIA ↑
VERIFICAÇÃO ↑
REDUNDÂNCIA ↑
INDEPENDÊNCIA ↑
SEGREGAÇÃO ↑
OBSERVABILIDADE ↑

AUTOMAÇÃO IRREVERSÍVEL ↓
PONTO ÚNICO DE FALHA ↓

Isso vale muito além do nosso experimento nuclear.

Vale para bancos.

Hospitais.

Aeronaves.

Redes elétricas.

Infraestruturas críticas.

Sistemas financeiros.

Inteligência artificial.

Mainframes.

E vale especialmente quando existe concentração extrema de poder.

Se bilhões dependem de uma credencial, aquela credencial vale bilhões.

Se milhões de registros dependem da honestidade de uma única pessoa, aquela pessoa tornou-se parte da segurança do sistema.

Se uma IA possui capacidade enorme de ação, cada caminho que transforma percepção em ação precisa ser tratado de acordo com a magnitude das consequências possíveis.

O princípio é brutalmente simples:

Nenhum elemento insignificante deveria possuir sozinho uma trajetória de falha capaz de produzir uma consequência irreversível.


🤖 CAPÍTULO 5 — O RATO NÃO PRECISA SER BIOLÓGICO

Aqui a teoria começa a ficar desconfortável.

O rato pode ser um software.

Uma entrada inesperada.

Um pacote de rede.

Uma informação falsa.

Uma inferência.

Um dado perfeitamente verdadeiro interpretado de maneira errada.

Uma IA pode receber:

EVENTO HOSTIL: 87%

Parece impressionante.

Mas 87% não responde à pergunta mais importante:

O que o sistema está autorizado a fazer diante desses 87%?

Quanto maior a autonomia de uma máquina, mais importante torna-se separar:

PERCEBER
   ↓
INTERPRETAR
   ↓
RECOMENDAR
   ↓
DECIDIR
   ↓
AGIR

Transformar tudo isso numa única seta é arquitetonicamente tentador.

Também pode ser perigoso.

Porque o rato assassino não precisa possuir dentes.

Pode possuir um IF.


🧠 CAPÍTULO 6 — A, B, C E D

Imagine quatro sistemas idênticos.

A.

B.

C.

D.

Todos observam aproximadamente o mesmo acontecimento.

A conclui:

falha técnica.

B:

evento desconhecido; precisamos de mais informações.

C:

possível comportamento anômalo.

D:

ameaça.

Por quê?

Porque estímulos aparentemente iguais não implicam necessariamente estados internos iguais.

Cada sistema possui história.

Memória.

Contexto.

Experiências anteriores.

Parâmetros.

Informações disponíveis.

Interpretações.

Aprendizado.

Um pequeno desvio hoje modifica uma decisão.

Essa decisão modifica o ambiente.

O ambiente produz uma experiência diferente amanhã.

A experiência altera o modelo.

O modelo interpreta diferentemente a próxima experiência.

Surge um ciclo:

MODELO
  ↓
INTERPRETA EXPERIÊNCIA
  ↓
PRODUZ COMPORTAMENTO
  ↓
ALTERA AMBIENTE
  ↓
PRODUZ NOVA EXPERIÊNCIA
  ↓
ALTERA MODELO
  ↺

Depois de milhares de ciclos, A e D podem ter começado praticamente iguais e terminado profundamente diferentes.

O rato encontrou novamente a borboleta.


☢️ CAPÍTULO 7 — CINQUENTA GRAMAS CONTRA A HUMANIDADE

Voltemos ao nosso silo.

O pequeno animal continua avançando.

Em algum momento sua presença participa de uma cadeia improvável de acontecimentos.

Não precisamos conhecer o mecanismo.

Na verdade, conhecê-lo estragaria o experimento.

Porque a Teoria do Rato Assassino não trata de mísseis.

Trata de sistemas.

Uma anomalia ocorre.

É interpretada.

Outra parte do sistema reage.

Alguém observa a reação.

Interpreta-a.

Responde.

Outro lado observa aquela resposta.

Cada etapa faz sentido localmente.

E esse detalhe é aterrorizante.

Nenhum participante precisa desejar o resultado final.

Mesmo assim:

🐀
 ↓
?
 ↓
?
 ↓
?
 ↓
?
 ↓
☢
 ↓
☢ ☢
 ↓
☢ ☢ ☢ ☢
 ↓
SILÊNCIO

A civilização humana termina.


🌍 CAPÍTULO 8 — MAS O RATO SOBREVIVE

E aqui aparece a ironia fundamental da teoria.

Aquele silo específico ficava em um lugar insignificante.

Longe dos grandes centros.

Protegido no subterrâneo.

A mesma irrelevância geográfica que ajudava a esconder a instalação acaba protegendo nosso protagonista.

Depois do fim da humanidade, o rato continua vivo.

Ele não comemora.

Não sente remorso.

Não sabe que aconteceu alguma coisa extraordinária.

Procura comida.

Dorme.

Reproduz-se.

Talvez encontre outro rato.

Para ele, nada chamado “civilização humana” desapareceu porque nada chamado “civilização humana” jamais existiu em seu universo cognitivo.

O rato nunca soube.


🌱 CAPÍTULO 9 — A TERRA NÃO PRECISA DE NÓS

Passam-se décadas.

Depois séculos.

Cidades deterioram-se.

Vegetação invade ruas.

Estruturas desabam.

Rios mudam.

Florestas avançam e recuam.

Ecossistemas reorganizam-se.

Passam-se milhares de anos.

Depois centenas de milhares.

Depois milhões.

A Terra continua.

Isso talvez seja uma das constatações mais desconfortáveis da Teoria do Rato Assassino:

o fim da humanidade não é necessariamente o fim do planeta.

Somos extraordinariamente importantes para nós mesmos.

A biosfera não assinou esse contrato.


🐀 CAPÍTULO 10 — OS FILHOS DO ASSASSINO

Milhões de anos passam.

A evolução não possui objetivo e nada garante que inteligência tecnológica apareça novamente.

Mas nosso experimento mental permite uma possibilidade.

Uma linhagem descendente daqueles pequenos sobreviventes desenvolve capacidades cognitivas cada vez maiores.

Ferramentas.

Comunicação.

Linguagem.

Cultura.

Escrita.

Matemática.

Ciência.

Tecnologia.

Finalmente surge uma nova civilização.

Os descendentes do rato povoam a Terra.

E um dia começam a escavar.


🏺 CAPÍTULO 11 — OS ANTIGOS

Arqueólogos encontram objetos impossíveis.

Concreto.

Metais trabalhados.

Cerâmicas.

Plásticos.

Estradas fossilizadas.

Estruturas gigantescas.

Camadas geológicas incomuns.

Depois descobrem ruínas de cidades.

A conclusão é inevitável:

Não fomos a primeira civilização tecnológica deste planeta.

Chamam-nos de Os Antigos.

Durante séculos tentam compreender quem éramos.

Descobrem nossa escrita.

Reconstruem nossos computadores.

Encontram nossas bibliotecas.

Descobrem nossa música.

Nossa medicina.

Nossa literatura.

Nossos memes — e provavelmente concluem que isso era algum tipo de religião.

Finalmente descobrem nossas armas.

E surge uma pergunta quase incompreensível:

Por que uma espécie suficientemente inteligente para compreender o átomo construiria instrumentos capazes de destruir a própria civilização?


🦴 CAPÍTULO 12 — O PRIMEIRO RATO

Então acontece a descoberta.

Dentro de uma antiga instalação subterrânea encontram um pequeno túnel.

No interior, vestígios fossilizados de um roedor.

A data coincide aproximadamente com o período da catástrofe.

Surge uma hipótese.

Um ancestral deles pode ter participado do evento inicial.

O impacto cultural seria extraordinário.

Religiões poderiam chamá-lo de libertador.

Outros poderiam chamá-lo de destruidor.

Artistas o transformariam em símbolo.

Políticos tentariam apropriar-se da história.

Cientistas passariam décadas repetindo:

Não existe evidência de intenção.

Até que algum filósofo finalmente escreveria:

“O Primeiro Rato não destruiu os Antigos. Ele apenas encontrou uma arquitetura capaz de destruí-los.”

Nasceria então o maior princípio de engenharia daquela civilização:

O Princípio do Primeiro Rato

Nenhum sistema com capacidade de produzir consequências existenciais deve permitir que uma perturbação isolada, um agente sem intenção ou uma única interpretação atravesse suas barreiras e alcance uma ação irreversível.


⚛️ CAPÍTULO 13 — ELES PROMETERAM NÃO REPETIR NOSSOS ERROS

A nova civilização estuda nossa queda durante gerações.

“Nunca faremos aquilo.”

“Nós aprendemos.”

“Nossa tecnologia é superior.”

“Nossos sistemas são mais seguros.”

“Nossa inteligência artificial monitora tudo.”

“Nossa redundância é perfeita.”

Então descobrem energia nuclear.

Primeiro para ciência.

Depois energia.

Até alguém perceber outra possibilidade.

Um governo pensa:

Não construiremos isso.

Mas surge uma dúvida:

E se os outros construírem?

Do outro lado do planeta, alguém pensa exatamente a mesma coisa.

Séculos depois existem novamente instalações subterrâneas.

Sensores.

Computadores.

Protocolos.

Redundância.

Inteligências artificiais.

Tudo infinitamente superior à tecnologia dos Antigos.

Na entrada de cada centro estratégico existe uma frase:

LEMBRE-SE DO PRIMEIRO RATO.

Eles estão seguros.

Pelo menos acreditam estar.


🪱 EPÍLOGO — A MINHOCA

03:17.

Uma instalação subterrânea funciona silenciosamente.

Um painel registra:

SYSTEM STATUS

POWER............... NOMINAL
SECURITY............ NOMINAL
ENVIRONMENT......... NOMINAL
AI MONITORING....... NOMINAL
REDUNDANCY.......... 100%

KNOWN THREATS........ NONE
UNEXPECTED EVENTS.... 0

TIME................. 03:17

A câmera atravessa a instalação.

Passa pelos computadores.

Desce pelas estruturas.

Atravessa o concreto.

Entra na terra.

Silêncio.

Alguma coisa se move.

Uma pequena minhoca abre caminho pelo solo.

🪱

Ela não conhece a história dos Antigos.

Não conhece o Primeiro Rato.

Não estudou engenharia.

Não sabe que acima dela existe uma civilização.

Não conhece fronteiras.

Não conhece política.

Não conhece tecnologia.

Não sabe o que significa REDUNDANCY 100%.

Ela simplesmente continua cavando.

Não sabemos se acontecerá alguma coisa.

Talvez nada aconteça.

Talvez ela passe pela instalação e continue sua existência insignificante.

E essa é precisamente a questão.

Porque o Primeiro Rato também não sabia que era o Primeiro Rato.

Tela preta.


🐀 A TEORIA DO RATO ASSASSINO

A Teoria do Rato Assassino não afirma que pequenas causas necessariamente produzirão grandes catástrofes.

Afirma algo mais importante:

Sistemas extremamente poderosos devem ser projetados considerando que eventos insignificantes, imprevisíveis e até completamente inocentes inevitavelmente existirão.

Não podemos prever todos os ratos.

Não podemos catalogar todas as minhocas.

Não podemos conhecer antecipadamente todas as combinações possíveis de falha, comportamento, ambiente, informação e interpretação.

Portanto, a segurança não pode depender apenas de impedir que o evento inesperado aconteça.

Precisa impedir que o inesperado encontre uma trajetória direta até o irreversível.

Porque quanto maior o poder de um sistema, maior deve ser sua capacidade de sobreviver ao absurdo.

E quando uma catástrofe gigantesca começa com algo minúsculo, culpar aquilo que iniciou a cadeia pode apenas esconder a pergunta realmente importante:

Por que nossa arquitetura permitiu que aquilo tivesse tanto poder?

Talvez esse seja o verdadeiro teste de qualquer tecnologia.

Não perguntar apenas:

“O sistema funciona?”

Nem:

“O sistema está protegido contra os ataques que conhecemos?”

Mas:

“O que acontece quando aparece algo que jamais imaginamos?”

Porque algum dia aparecerá.

Pode ser um erro.

Pode ser uma pessoa.

Pode ser uma IA.

Pode ser um rato.

Ou pode ser apenas uma minhoca cavando tranquilamente no escuro.

🪱

E ela não saberá de nada.

Para pensar durante o café

A ausência histórica de uma catástrofe não demonstra necessariamente que uma anomalia seja segura; pode significar apenas que, nas ocorrências anteriores, as demais condições necessárias para completar a cadeia ainda não estavam presentes.

O rato pode ter passado pelo túnel cem vezes.

Na 101ª, encontra a borboleta. 🐀🦋

Lembra disso? Pergunta sobre Challenger/Columbia e apareceu outro corolário:

O rato pode ter aparecido cem vezes sem provocar uma catástrofe. Isso não prova que o rato seja seguro.

E finalmente a minhoca:

Mesmo depois de catalogarmos todos os ratos conhecidos, continuará existindo aquilo que nosso modelo não imaginou.


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