☕ 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

quinta-feira, 5 de novembro de 2026

🎭 GREAT PRETENDER: O GOLPE DE US$ 1,2 BILHÃO — EDAMAME, A ENTER E A GUERRA DAS OABs PELO CONTROLE DA JUSTIÇA!

 

Bellacosa Mainframe e o roubo do século

☕ UM CAFÉ NO BELLACOSA MAINFRAME

🎭 GREAT PRETENDER: O GOLPE DE US$ 1,2 BILHÃO — EDAMAME, A ENTER E A GUERRA DAS OABs PELO CONTROLE DA JUSTIÇA!

Quando uma inteligência artificial começou a preparar milhares de defesas judiciais, uma startup brasileira virou unicórnio, os advogados entraram em guerra e Makoto Edamura descobriu que o maior truque não era enganar alguém — era descobrir quem realmente estava tomando as decisões.

Bellacosa Mainframe — Arqueologia da Computação, COBOL, Inteligência Artificial, Segurança Digital e os Fantasmas da Justiça Automatizada

5 de novembro de 2026 | Tecnologia, Direito, Mainframe e Sociedade

Nota editorial: Os personagens de Great Pretender participam desta história como recurso narrativo fictício. Os acontecimentos envolvendo a Enter e a OAB são reais, mas as acusações permanecem em discussão judicial. Nenhuma fraude da Enter foi comprovada por esta investigação. Os diálogos e as situações protagonizadas pelos personagens do anime são imaginários.



🎬 Prólogo — O dia em que Edamame descobriu que o maior golpe talvez estivesse escondido num algoritmo

São Paulo, novembro de 2026.

O relógio marcava sete horas da manhã quando Makoto Edamura, conhecido internacionalmente como Edamame, entrou numa cafeteria da Avenida Paulista.

O jovem japonês carregava uma mochila, um notebook e uma expressão preocupada.

Na televisão, uma reportagem anunciava:

Uma startup brasileira de inteligência artificial, avaliada em US$ 1,2 bilhão, estava no centro de uma disputa judicial com a Ordem dos Advogados do Brasil.

Edamame quase derrubou o café.

— Um bilhão e duzentos milhões de dólares? Por um software que escreve documentos?

Sentado diante dele, Laurent Thierry, o elegante vigarista francês de Great Pretender, sorriu.

— Meu caro Edamame, você ainda pensa como um ladrão de carteiras. O verdadeiro dinheiro está na transformação de mercados inteiros.

— Você está dizendo que essa empresa é uma fraude?

— Absolutamente não. Uma empresa valiosa não é necessariamente fraudulenta. Mas toda operação sofisticada merece uma pergunta: quem controla o jogo?

Na tela apareceu o nome da companhia.

ENTER.

Fundada em 2023 por Mateus Costa-Ribeiro, Henrique Vaz e Michael Mac-Vicar, a empresa brasileira havia anunciado, em maio de 2026, uma rodada de investimentos superior a US$ 100 milhões, liderada pelo Founders Fund.

A avaliação alcançara US$ 1,2 bilhão.

Para o mercado financeiro, um novo unicórnio.

Para os departamentos jurídicos, uma revolução.

Para a OAB paulista, uma série de perguntas sobre os limites da automação da advocacia.

E para Edamame?

Uma oportunidade de compreender uma das maiores transformações profissionais provocadas pela inteligência artificial.

— Laurent, acho que precisamos investigar.

— Finalmente, meu jovem. Mas desta vez nada de golpes. Vamos seguir os documentos.



🎭 Capítulo I — Quem é Makoto Edamura e por que ele está investigando uma inteligência artificial?

Antes de entrarmos na tecnologia, precisamos conhecer nosso investigador.

Makoto Edamura é o protagonista de Great Pretender, anime original produzido pelo WIT Studio, lançado em 2020, com direção de Hiro Kaburagi, roteiro de Ryota Kosawa e personagens desenhados por Yoshiyuki Sadamoto.

A história acompanha um jovem japonês que se considera um extraordinário vigarista, até encontrar Laurent Thierry, um trapaceiro internacional muito mais experiente.

O apelido Edamame nasce de uma brincadeira com seu sobrenome.

Ao longo da série, Makoto participa de operações elaboradas envolvendo identidades falsas, manipulação psicológica, organizações criminosas e situações em que a aparência raramente corresponde à realidade.

Mas existe uma característica especialmente interessante no personagem.

Edamame frequentemente acredita ter compreendido o golpe antes de descobrir que existe outro plano escondido dentro do primeiro.

É exatamente essa característica que torna Great Pretender uma metáfora interessante para investigar os sistemas de inteligência artificial.

Uma plataforma pode parecer simplesmente um programa que redige documentos.

Entretanto, quando examinamos sua estrutura operacional, encontramos agentes, decisões automatizadas, integrações, regras, contratos, modelos de remuneração e responsabilidade profissional.

O software é apenas a parte visível.

O verdadeiro sistema inclui tudo aquilo que acontece antes e depois da execução do algoritmo.

No universo da informática empresarial, chamamos isso de compreender o processo de negócio.

E nenhum programador COBOL deveria alterar um programa crítico antes de compreender o negócio que ele representa.

☕ Curiosidade Bellacosa

Em Great Pretender, muitas operações são divididas em casos, cada um com uma estrutura própria.

Nos ambientes de mainframe, também costumamos organizar o trabalho em etapas controladas: entrada de dados, processamento, validação, armazenamento e auditoria.

A diferença é que uma operação de confiança precisa ser verificável.

Não basta acreditar que alguém executou a tarefa corretamente.

Precisamos de evidências.



💰 Capítulo II — A Enter: o unicórnio brasileiro que encontrou ouro nas ações judiciais

Edamame abriu o notebook e começou a pesquisar.

A primeira descoberta foi surpreendente.

A Enter não nasceu para responder dúvidas jurídicas de pequenos usuários.

Seu principal mercado são os departamentos jurídicos de grandes empresas.

Bancos, companhias aéreas, plataformas de comércio eletrônico e outras organizações enfrentam milhares de processos judiciais.

Muitos envolvem situações semelhantes.

Imagine um banco com dezenas de milhares de reclamações relacionadas a tarifas, contratos, transações e serviços financeiros.

Cada processo exige uma série de tarefas:

  1. Receber e identificar a ação.

  2. Examinar os documentos.

  3. Localizar contratos e registros.

  4. Entender os fatos alegados.

  5. Identificar evidências relevantes.

  6. Consultar normas e precedentes.

  7. Preparar uma possível defesa.

  8. Submeter o trabalho ao advogado.

  9. Acompanhar o andamento judicial.

  10. Registrar os resultados.

É uma operação intensiva em informações.

E justamente por isso oferece oportunidades de automação.

Segundo os dados divulgados pela própria Enter em maio de 2026, mais de 300 mil processos por ano já contavam com o auxílio de sua tecnologia.

A companhia anunciou clientes como Bradesco, Nubank, Mercado Livre, Airbnb, LATAM Airlines e Azul, além de outras grandes empresas.

Laurent observou a tela.

— Veja, Edamame. A empresa não está vendendo apenas palavras geradas por inteligência artificial.

— Então o que está vendendo?

— Capacidade operacional.

A diferença é fundamental.

Um chatbot pode escrever uma contestação quando recebe informações.

Uma plataforma especializada procura integrar a obtenção dessas informações, a organização dos documentos, a elaboração de minutas e o acompanhamento do processo.

O objetivo comercial é reduzir o custo por processo e aumentar a produtividade.

O segredo do contencioso de massa

Contencioso é o conjunto de disputas jurídicas.

Quando uma empresa enfrenta milhares de ações semelhantes, falamos em contencioso de massa.

Considere uma simulação:

Uma empresa possui 100 mil processos anuais.

Se cada processo consumir dez horas de trabalho, teremos um milhão de horas.

Se a tecnologia reduzir parte dessas atividades para quatro horas por processo, o trabalho operacional cairia para 400 mil horas.

Seriam 600 mil horas potencialmente liberadas.

Atenção: esse é um exemplo matemático inventado para fins didáticos. Não representa um resultado auditado da Enter.

Naturalmente, nem todas as horas são intercambiáveis. Casos difíceis, erros da automação, revisões humanas e integrações tecnológicas podem reduzir a economia real.

Mas a escala ajuda a compreender o interesse dos investidores.

O mercado não está apenas comprando um algoritmo.

Está financiando a possibilidade de reorganizar uma indústria inteira.



🤖 Capítulo III — EnterOS: quando os agentes de IA entram no escritório de advocacia

Edamame imaginava que a Enter utilizasse um único modelo de linguagem.

Laurent apresentou outra possibilidade.

— Um sistema sofisticado pode distribuir tarefas entre diferentes componentes.

— Como uma equipe?

— Exatamente. Uma equipe digital.

A Enter chama sua plataforma de EnterOS.

A companhia afirma utilizar agentes de inteligência artificial para apoiar diferentes etapas do trabalho jurídico.

Nos modelos modernos de automação, um agente pode receber um objetivo, consultar ferramentas, analisar resultados e executar passos adicionais.

Não significa que possua consciência ou compreensão humana.

Significa que foi projetado para realizar tarefas coordenadas.

Uma arquitetura ilustrativa

Imagine cinco componentes:

Agente 1 — Recepção

Identifica o processo, separa documentos e reconhece as informações principais.

Agente 2 — Evidências

Consulta contratos, extratos e registros pertinentes.

Agente 3 — Análise

Organiza possíveis argumentos, identifica inconsistências e aponta informações ausentes.

Agente 4 — Redação

Prepara uma minuta baseada nos dados disponibilizados.

Agente 5 — Controle

Verifica integridade, registra o histórico e encaminha o material para revisão humana.

Essa divisão é um exemplo conceitual. Não significa que a Enter utilize exatamente cinco agentes ou essa arquitetura interna.

O problema das alucinações

Um modelo de linguagem pode produzir informações incorretas com aparência convincente.

Imagine uma minuta que cite uma decisão judicial inexistente.

Ou utilize um contrato pertencente a outro cliente.

Ou interprete uma data de pagamento incorretamente.

Esses erros podem produzir consequências sérias.

Na Justiça, uma afirmação falsa pode prejudicar direitos.

Por isso, um sistema jurídico confiável precisa apresentar a origem das informações utilizadas, permitir revisão crítica e manter rastreabilidade.

Edamame franziu a testa.

— Laurent, estamos falando de uma máquina que pode produzir milhares de documentos incorretos em questão de horas?

— Sim. Mas também pode ajudar a encontrar milhares de erros humanos. A tecnologia amplia a capacidade de operação, tanto para o bem quanto para o mal.

Esse é o paradoxo da automação.


⚖️ Capítulo IV — Outubro de 2026: a OAB de São Paulo entra em cena

Em 7 de outubro de 2026, a OAB-SP ajuizou uma ação civil pública contra a Enter, que atua juridicamente sob o nome Talisman AI Ltda.

A entidade não pediu simplesmente o fim da inteligência artificial jurídica.

Seu argumento principal foi a necessidade de delimitar a automação e preservar atividades privativas da advocacia.

Segundo a seccional paulista, seria necessário investigar em que medida a plataforma participa da definição de estratégias, produz documentos e organiza a atuação dos profissionais.

A OAB-SP também relatou ter recebido informações de advogados que se sentiriam pressionados a assinar grandes quantidades de documentos produzidos por inteligência artificial.

Esses relatos constituem alegações que precisam ser examinadas, não fatos judicialmente comprovados contra a Enter.

A entidade defende mecanismos de revisão humana efetiva e auditável.

Isso envolve algo muito mais importante do que colocar um botão de aprovação na tela.

Um advogado precisa ter condições reais de examinar o conteúdo, identificar erros, discordar do sistema e rejeitar uma minuta.

O advogado pode virar um simples carimbador?

Imagine uma situação hipotética.

Uma plataforma produz 500 contestações durante a madrugada.

Pela manhã, um advogado recebe uma fila de documentos aguardando aprovação.

Se ele possuir apenas alguns segundos para cada peça, será possível analisar individualmente os contratos, os fatos, as evidências e os argumentos?

Provavelmente não de maneira adequada.

O problema não é o software ter preparado os documentos.

O problema é a diferença entre uma revisão verdadeira e uma aprovação meramente formal.

Em um sistema empresarial, isso seria semelhante a permitir que um operador autorize centenas de transações críticas sem verificar os relatórios de exceção.

É um problema de governança.

E governança não se resolve apenas comprando computadores mais rápidos.


🏛️ Capítulo V — A guerra fria entre a OAB paulista e a direção nacional

Edamame encontrou uma segunda surpresa.

A disputa não envolvia somente a empresa tecnológica e a advocacia.

Existiam divergências entre a OAB-SP e a direção nacional da Ordem.

Pouco depois da ação paulista, uma resolução da direção do Conselho Federal estabeleceu parâmetros para negociar termos de ajustamento de conduta com empresas de inteligência artificial jurídica.

A Resolução nº 16/2026 foi assinada em 9 de outubro e disponibilizada no Diário Eletrônico da OAB em 13 de outubro.

O documento permite buscar soluções negociadas antes de decidir pelo ajuizamento de determinadas medidas.

Isso não impede providências judiciais urgentes e não representa aprovação automática de produtos de IA.

Temos, portanto, duas estratégias institucionais.

A posição paulista: levar a controvérsia ao Judiciário e exigir esclarecimentos, preservação de evidências e salvaguardas verificáveis.

A posição nacional: criar também uma via de negociação para corrigir eventuais irregularidades e estabelecer compromissos de adequação.

As posições não são necessariamente incompatíveis.

A divergência envolve o momento, a forma e a condução institucional da resposta.

A política entra no tabuleiro

A reportagem de Artur Rodrigues, publicada no UOL em 5 de novembro de 2026, apresenta essa disputa em um contexto mais amplo.

A OAB-SP também defende eleições diretas para a presidência nacional da Ordem.

Atualmente, a escolha da direção nacional ocorre por meio dos conselheiros federais.

A eleição paulista está prevista para novembro de 2027, enquanto a nacional está prevista para janeiro de 2028.

Não é possível concluir que a discussão eleitoral tenha causado a ação contra a Enter.

Entretanto, as divergências políticas ajudam a compreender por que um conflito tecnológico ganhou dimensão institucional.

Laurent sorriu.

— Agora temos dois tabuleiros, Edamame.

— A tecnologia e a política?

— E talvez um terceiro: o dinheiro.


📂 Capítulo VI — Os contratos misteriosos e a questão dos honorários

Em 20 de outubro, a OAB-SP informou ter juntado novos documentos à ação.

Entre eles, havia material apresentado como contrato de gestão e licenciamento de software.

Segundo a entidade, esse material previa mecanismos de distribuição de processos a escritórios e repasses associados à gestão dos casos, incluindo referência a 50% de determinado valor líquido.

A autenticidade e o alcance desses documentos dependem de apuração judicial.

Não se pode afirmar que tais condições tenham sido efetivamente adotadas pela Enter apenas com base nas alegações.

Mas a questão levantada é importante.

Existe diferença entre uma empresa vender software jurídico e uma empresa organizar a prestação de serviços de advocacia, influenciar a distribuição dos casos e participar de receitas relacionadas à atuação profissional.

No Brasil, a advocacia possui regras próprias de habilitação, independência, sigilo e remuneração.

A análise jurídica dependerá da realidade contratual e operacional, não apenas do nome comercial atribuído ao serviço.

O memorando de 2023

A reportagem do UOL também teve acesso a um memorando de investimento atribuído ao fundo ONEVC, de agosto de 2023.

O documento mencionava a possibilidade de trazer um presidente da OAB como investidor-anjo, sem identificar a pessoa nem esclarecer se seria da direção nacional ou de uma seccional.

Não existe, nessa reportagem, comprovação de que um dirigente da OAB tenha investido na Enter.

A empresa afirmou desconhecer o documento e negou qualquer convite, negociação ou participação financeira ou consultiva de dirigentes da Ordem.

Essa distinção é indispensável.

Um documento com uma referência a um possível investidor não comprova que o investimento aconteceu.

Edamame anotou cuidadosamente:

Hipótese não é evidência. Evidência não é sentença. E uma suspeita não pode ser apresentada como condenação.

Uma lição que vale tanto para investigadores quanto para programadores.


🔐 Capítulo VII — A Justiça manda preservar os registros

Em 21 de outubro de 2026, a Justiça Federal determinou que a Enter preservasse documentos e registros relacionados ao funcionamento de seu modelo de negócio desde 1º de janeiro de 2024.

A ordem abrangia contratos, versões de modelos, parametrizações, registros de geração e revisão de minutas, designação de processos e informações financeiras relacionadas às operações.

Foi estabelecida multa de R$ 50 mil por ato de descumprimento.

A decisão também rejeitou o pedido da empresa para suspender a ação em razão das conversas mantidas com o Conselho Federal.

A OAB-RJ foi admitida no polo ativo do processo.

Entretanto, a decisão não equivale a uma condenação definitiva da Enter nem a uma proibição geral de suas atividades.

O mérito da controvérsia permanece sujeito à análise judicial.

O que isso significa para um programador?

Significa que os registros de auditoria podem se transformar em provas decisivas.

Imagine que um advogado declare ter revisado determinado documento.

Um registro confiável poderia indicar:

  • Qual versão do documento foi apresentada.

  • Quando o profissional recebeu acesso.

  • Quais alterações realizou.

  • Quais fontes estavam disponíveis.

  • Quando ocorreu a aprovação.

  • Qual versão foi efetivamente utilizada.

Porém, um log registrando um clique não prova, sozinho, que houve revisão intelectual adequada.

Seria necessário examinar o contexto e a efetividade do controle.

É aqui que a informática se encontra diretamente com o Direito.


💻 Capítulo VIII — Edamame encontra um mainframe IBM e descobre o papel do COBOL

Nosso investigador decide visitar um centro de processamento de dados fictício.

No ambiente, uma aplicação bancária utiliza COBOL para processar contratos e transações financeiras.

Edamame observa os terminais.

— Laurent, achei que tudo estivesse na nuvem.

— A nuvem não eliminou os sistemas centrais. E muitos negócios continuam dependendo de plataformas transacionais construídas e modernizadas ao longo de décadas.

Um banco pode utilizar COBOL, CICS, Db2, Java, APIs e serviços de IA simultaneamente.

A modernização não exige abandonar todas as tecnologias anteriores.

O desafio consiste em integrar os sistemas com segurança.

Imagine esta arquitetura

Camada 1 — Sistemas transacionais

Programas COBOL processam contratos, saldos, tarifas e operações financeiras.

Camada 2 — Serviços de integração

APIs controladas disponibilizam dados autorizados.

Camada 3 — Plataforma jurídica

Uma ferramenta de IA recebe informações pertinentes a determinado processo.

Camada 4 — Revisão humana

Advogados verificam a interpretação dos documentos e a estratégia jurídica.

Camada 5 — Auditoria

Registros permitem reconstruir o processamento e identificar responsabilidades.

Essa arquitetura é uma hipótese didática. Não significa que a Enter utilize diretamente sistemas IBM Z em seus clientes.

Entretanto, o modelo demonstra como plataformas modernas de IA podem se relacionar com sistemas legados.

A grande lição

Uma IA não deveria obter acesso indiscriminado a um banco de dados apenas porque precisa consultar determinada informação.

A integração deve utilizar autenticação, autorização, minimização de dados e registros de acesso.

O sistema transacional permanece como fonte oficial dos valores financeiros.

A IA funciona como ferramenta de análise.

E o profissional autorizado permanece responsável pelas decisões que exigem julgamento humano.


🧪 Capítulo IX — Laboratório COBOL: construindo um controle de revisão para documentos gerados por IA

Agora começa a parte prática.

Imagine que fomos contratados para desenvolver um pequeno programa COBOL capaz de verificar se uma minuta produzida por inteligência artificial passou por uma revisão humana registrada.

Não vamos construir uma IA nem um sistema judicial real.

Nosso objetivo será demonstrar os conceitos básicos de entrada de dados, condições, regras de negócio e validação.

Passo 1 — Definindo os requisitos

O programa receberá três informações:

  1. Identificador numérico do processo.

  2. Indicador de existência de advogado responsável.

  3. Indicador de revisão registrada.

Se ambos os indicadores forem iguais a S, o programa apresentará uma mensagem informando que os requisitos cadastrais mínimos foram atendidos.

Caso contrário, apontará a pendência.

Isso não comprova a qualidade da revisão jurídica. Apenas demonstra uma regra administrativa simples.

Passo 2 — O código COBOL

Exemplo em formato livre, compatível com compiladores que suportam essa modalidade:

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

environment division.
configuration section.
repository.
    function all intrinsic.

data division.
working-storage section.

01 ws-processo       pic 9(8).
01 ws-advogado       pic x.
01 ws-revisao        pic x.
01 ws-situacao       pic x(30).

procedure division.

    display "BELLACOSA MAINFRAME"
    display "CONTROLE DIDATICO DE IA JURIDICA"

    display "Numero do processo (8 digitos): "
    accept ws-processo

    display "Advogado responsavel? (S/N): "
    accept ws-advogado

    display "Revisao registrada? (S/N): "
    accept ws-revisao

    evaluate true
        when ws-advogado = "S"
         and ws-revisao = "S"
            move "CADASTRO MINIMO ATENDIDO"
              to ws-situacao

        when other
            move "PENDENCIA DE VALIDACAO"
              to ws-situacao
    end-evaluate

    display "PROCESSO: " ws-processo
    display "SITUACAO: " ws-situacao

    goback.

Passo 3 — Entendendo as divisões

O COBOL organiza os programas em divisões.

A IDENTIFICATION DIVISION identifica o programa.

A ENVIRONMENT DIVISION permite definir características do ambiente.

A DATA DIVISION declara as variáveis.

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

No nosso exemplo, o número do processo é armazenado em:

PIC 9(8)

Isso significa um campo numérico de oito dígitos.

Já os indicadores utilizam:

PIC X

Cada campo armazena um caractere.

Passo 4 — Entendendo o EVALUATE

O comando EVALUATE permite selecionar diferentes comportamentos a partir de condições.

No exemplo, usamos:

evaluate true
    when ws-advogado = "S"
     and ws-revisao = "S"
        ...
    when other
        ...
end-evaluate

Se o cadastro apresentar advogado responsável e revisão registrada, o programa informa que os requisitos mínimos foram atendidos.

Caso contrário, existe uma pendência.

É importante compreender que os indicadores são simplesmente informações declaradas ao programa.

Uma pessoa poderia informar S sem ter realmente revisado documento algum.

Portanto, esse pequeno programa é apenas o início de uma solução de controle.

Passo 5 — Executando o programa

Em um ambiente de laboratório com GnuCOBOL, poderíamos compilar o arquivo auditia.cbl utilizando:

cobc -x -free -o auditia auditia.cbl

Depois, em Linux ou outro ambiente compatível:

./auditia

Exemplo de entrada:

Numero do processo (8 digitos):
12345678

Advogado responsavel? (S/N):
S

Revisao registrada? (S/N):
N

Saída esperada:

PROCESSO: 12345678
SITUACAO: PENDENCIA DE VALIDACAO

Passo 6 — Melhorando a solução

Um sistema real precisaria de controles adicionais.

Por exemplo:

  • Identificação autenticada do advogado.

  • Data e hora da revisão.

  • Identificação da versão do documento.

  • Registro de alterações.

  • Histórico de aprovação.

  • Associação às evidências utilizadas.

  • Proteção contra alterações indevidas.

  • Política de retenção e descarte dos registros.

Também seria necessário validar entradas e tratar erros antes da gravação dos dados.

Nossa aplicação de laboratório ainda permite valores inválidos, não consulta um cadastro profissional e não grava registros persistentes.

Em produção, essas limitações seriam inaceitáveis.

☕ Dica Bellacosa

Não confunda um campo preenchido com uma atividade comprovadamente executada.

Esse é um dos erros mais perigosos dos sistemas corporativos.

Uma transação pode estar marcada como aprovada sem que a autorização tenha sido válida.

Uma documentação pode estar marcada como revisada sem que alguém tenha conferido seu conteúdo.

A qualidade da auditoria depende da confiabilidade do processo completo.


🕵️ Capítulo X — O golpe dentro do golpe: quando a inteligência artificial inventa uma evidência

Edamame resolveu testar uma situação fictícia.

Um consumidor processa uma instituição financeira alegando cobrança indevida de R$ 8 mil.

O sistema de inteligência artificial recebe documentos e procura informações pertinentes.

Porém, encontra um contrato parecido, pertencente a outra operação.

A IA identifica cláusulas semelhantes e conclui, incorretamente, que o documento comprova a autorização da cobrança.

Uma minuta é produzida com essa interpretação equivocada.

Se ninguém conferir a associação entre o contrato e o processo, o erro poderá chegar à defesa.

O problema não começou na redação do texto.

Começou na identificação da evidência.

Data lineage: a origem dos dados

Em engenharia de dados, data lineage representa a capacidade de compreender a origem e as transformações pelas quais uma informação passou.

No nosso exemplo, seria necessário saber:

Qual sistema forneceu o contrato?

Quando ele foi consultado?

A qual cliente pertence?

Qual é o identificador da operação financeira?

Qual versão foi utilizada?

Houve alguma transformação dos dados?

Uma aplicação COBOL poderia contribuir fornecendo registros transacionais confiáveis, desde que corretamente integrados.

A IA precisaria respeitar esses registros e indicar as fontes que fundamentaram sua análise.

Uma resposta aparentemente convincente não substitui uma evidência verificável.

Essa é uma lição especialmente importante para bancos e instituições financeiras.


🧠 Capítulo XI — O perigo da industrialização das defesas judiciais

Vamos imaginar uma situação social mais ampla.

Uma grande empresa possui milhares de consumidores insatisfeitos.

Alguns apresentam reclamações procedentes.

Outros cometem equívocos.

Existem também processos sem fundamento suficiente.

Uma plataforma de IA pode ajudar a organizar esses casos.

Mas existe uma questão de equilíbrio.

O consumidor normalmente possui recursos limitados para investigar sistemas internos de uma empresa.

A companhia, por outro lado, pode possuir equipes jurídicas, bancos de dados, sistemas transacionais e ferramentas avançadas de automação.

Se conseguir produzir defesas em grande escala e a baixo custo, poderá obter vantagens operacionais importantes.

Isso não significa que suas defesas sejam incorretas.

Também não significa que os consumidores tenham sempre razão.

Significa que a tecnologia pode alterar a distribuição de recursos e capacidades entre as partes.

Um exemplo hipotético

Imagine dois participantes de uma disputa judicial.

O consumidor possui acesso ao contrato, alguns comprovantes e mensagens de atendimento.

A empresa possui registros financeiros, logs, informações sobre operações internas e uma plataforma capaz de localizar documentos relevantes em segundos.

Se a empresa disponibilizar evidências corretas, a automação poderá ajudar a esclarecer o conflito.

Mas, caso utilize documentos incompletos ou classificações equivocadas, o mesmo mecanismo poderá multiplicar problemas.

O princípio do contraditório exige que as partes tenham oportunidade de conhecer e contestar os elementos relevantes apresentados no processo.

Ferramentas de IA deveriam contribuir para melhorar a qualidade das informações, não dificultar sua contestação.

Uma possibilidade positiva

A automação também pode beneficiar consumidores.

Imagine uma ferramenta capaz de identificar inconsistências em milhares de contratos, localizar cobranças potencialmente indevidas e ajudar profissionais habilitados a analisar reclamações.

O mesmo avanço tecnológico pode servir a diferentes lados de uma disputa.

A questão decisiva não é simplesmente quem utiliza inteligência artificial.

É como utiliza, quais controles existem e quem responde pelos resultados.


💸 Capítulo XII — A economia da IA jurídica: produtividade, empregos e concentração de mercado

Edamame retornou à cafeteria.

— Laurent, se uma empresa automatiza milhares de processos, ela não vai precisar de menos advogados?

— Algumas tarefas podem exigir menos horas de trabalho. Mas a consequência sobre o emprego depende de muitos fatores.

Essa resposta merece atenção.

A automatização pode reduzir a demanda por determinadas atividades repetitivas.

Ao mesmo tempo, pode criar novas funções ligadas à integração de sistemas, revisão especializada, auditoria, segurança, governança e supervisão tecnológica.

Não existe garantia de que os novos postos compensarão integralmente os anteriores.

Também não é correto afirmar que toda tecnologia de produtividade provoca necessariamente desemprego generalizado.

Os efeitos dependerão de custos, regulação, concorrência, demanda e reorganização dos serviços.

O que acontece com o jovem advogado?

Profissionais iniciantes frequentemente aprendem preparando documentos, pesquisando precedentes e examinando processos.

Se grande parte desse trabalho for automatizada, escritórios e departamentos jurídicos precisarão encontrar novas formas de treinamento.

Existe um risco semelhante na programação COBOL.

Uma IA pode preparar um programa relativamente simples.

Mas como o iniciante aprenderá a identificar erros, interpretar regras de negócio e compreender o comportamento do compilador se apenas copiar o resultado?

A produtividade de curto prazo não pode destruir a formação técnica de longo prazo.

A concentração tecnológica

Outra preocupação envolve o poder das plataformas.

Empresas capazes de reunir grandes volumes de dados, integrar sistemas e financiar infraestrutura de IA podem conquistar vantagens competitivas significativas.

Isso não representa necessariamente uma ilegalidade.

Entretanto, pode aumentar a dependência tecnológica de clientes e profissionais.

Quanto mais uma organização depender de uma única plataforma, mais importante será avaliar portabilidade de dados, interoperabilidade, auditoria e continuidade operacional.

No mainframe conhecemos bem essa discussão.

O custo de substituir um sistema crítico não está apenas no software.

Está nas integrações, nos processos, nos conhecimentos acumulados e nas dependências construídas ao longo dos anos.


🧭 Capítulo XIII — A Lei Geral de Proteção de Dados entra na investigação

O trabalho jurídico frequentemente envolve informações pessoais.

Contratos, documentos de identificação, dados financeiros, registros trabalhistas e informações de saúde podem aparecer em processos.

Portanto, uma plataforma de IA jurídica precisa observar os requisitos legais aplicáveis ao tratamento dessas informações.

No Brasil, a LGPD estabelece princípios como finalidade, adequação, necessidade, segurança e prevenção.

Isso exige muito mais do que colocar uma senha na aplicação.

Um projeto sério deve avaliar quais dados precisam ser utilizados, quem poderá acessá-los e durante quanto tempo deverão ser preservados.

Cinco perguntas para uma auditoria

Primeira: a plataforma recebe somente as informações necessárias para determinada finalidade?

Segunda: existem mecanismos para impedir acesso indevido a documentos de outros clientes?

Terceira: as consultas e alterações deixam registros auditáveis?

Quarta: os contratos estabelecem responsabilidades sobre o tratamento e a retenção dos dados?

Quinta: existem procedimentos para lidar com incidentes e responder aos direitos dos titulares?

A Enter declara adotar controles de segurança e proteção de informações.

A avaliação de sua conformidade concreta exigiria documentação técnica, contratos e verificações adequadas.

O perigo do treinamento inadvertido

Uma preocupação recorrente envolve a possibilidade de documentos confidenciais serem utilizados para treinar modelos de inteligência artificial.

Não se deve presumir que isso esteja acontecendo na Enter.

A empresa afirma manter proteções para impedir utilização inadequada dos dados de clientes.

Entretanto, qualquer organização que contrate soluções de IA deve verificar tecnicamente e contratualmente as condições de processamento e retenção.

O sigilo profissional não desaparece porque um documento passou por uma API.


🛠️ Capítulo XIV — Dez recomendações para programadores COBOL que trabalharão com inteligência artificial

A discussão jurídica oferece ensinamentos valiosos para o desenvolvimento de aplicações empresariais.

1. Compreenda a regra de negócio antes de automatizá-la.

Um requisito mal interpretado continuará errado mesmo quando processado por uma IA sofisticada.

2. Nunca confie cegamente em código gerado por modelos de linguagem.

Leia, compile, teste e documente.

3. Preserve a origem dos dados.

Registre de onde veio cada informação importante.

4. Utilize controles de acesso.

Nenhum agente deve receber privilégios superiores aos necessários.

5. Separe análise de execução.

Uma IA pode sugerir uma ação sem receber autorização para executá-la automaticamente.

6. Implemente registros de auditoria.

Identifique transações, usuários, horários e versões relevantes.

7. Proteja informações sensíveis.

Evite inserir dados reais em ferramentas sem autorização institucional.

8. Prepare testes negativos.

Verifique o comportamento diante de documentos ausentes, dados inconsistentes e entradas inválidas.

9. Mantenha possibilidade de intervenção humana.

Em processos críticos, uma pessoa autorizada precisa conseguir interromper ou rejeitar operações inadequadas.

10. Documente as limitações.

Um sistema bem projetado deve permitir que seus usuários conheçam os riscos e as condições de utilização.

Exercício para o laboratório

Amplie o programa AUDITIA para aceitar um terceiro indicador:

WS-EVIDENCIA

Ele deverá informar se a documentação de suporte foi registrada.

Depois, modifique o EVALUATE para exigir os três indicadores iguais a S.

Em uma segunda versão, grave um arquivo sequencial contendo os dados recebidos.

Na terceira versão, crie uma estrutura com data, identificador do revisor e situação.

Por fim, desenvolva casos de teste para entradas incorretas e registre os resultados.

Esse exercício simples permite praticar declarações de dados, condições, processamento e desenho de controles.


🎲 Capítulo XV — O que Edamame realmente descobriu?

Ao final da investigação, Laurent perguntou:

— Então, Edamame, encontrou o grande golpe?

O jovem permaneceu em silêncio por alguns instantes.

— Não encontrei provas de que a Enter seja uma fraude. Encontrei uma empresa tecnológica que cresceu rapidamente, um mercado jurídico sujeito à automação e uma disputa institucional sobre os limites dessa transformação.

Laurent sorriu.

— Excelente. Você finalmente aprendeu a diferença entre investigar e acusar.

Edamame continuou:

— Mas encontrei uma questão ainda maior. Se a inteligência artificial puder preparar milhares de defesas, quem será responsável por garantir que cada uma delas seja correta?

Essa é a pergunta mais importante do caso.

Não basta saber se uma máquina consegue realizar determinada tarefa.

Precisamos compreender quem estabelece as regras, quem controla os dados, quem valida os resultados e quem assume as consequências.

O problema aparece no Direito, mas também na Medicina, na Engenharia, na Contabilidade, na Segurança Cibernética e no desenvolvimento de software.

A inteligência artificial está alterando a fronteira entre executar uma tarefa e assumir responsabilidade profissional por ela.

A diferença entre capacidade e autoridade

Um sistema pode possuir capacidade técnica para produzir um documento.

Isso não significa que possua autoridade jurídica para exercer uma profissão regulamentada.

Da mesma forma, um programa COBOL pode possuir capacidade para movimentar valores financeiros, mas sua execução deve obedecer a regras de autorização e controle.

A existência da funcionalidade não substitui a legitimidade de sua utilização.


🥚 Capítulo XVI — Easter eggs: as pistas escondidas entre COBOL, Great Pretender e a Justiça

Easter egg 1 — O nome Edamame

Makoto prefere ser reconhecido pelo próprio sobrenome, mas Laurent insiste em chamá-lo de Edamame.

A brincadeira funciona como uma lembrança de que um rótulo pode mudar a percepção das pessoas.

Na disputa jurídica, chamar determinada solução de software, plataforma ou serviço não resolve automaticamente a natureza das atividades efetivamente realizadas.

É necessário observar a operação real.

Easter egg 2 — O mágico de Oz

Em Great Pretender, os personagens encontram situações em que os acontecimentos aparentes escondem estruturas muito mais elaboradas.

Na tecnologia, algo parecido acontece quando uma interface simples esconde centenas de componentes.

O usuário vê uma resposta.

O engenheiro precisa compreender o processamento.

Easter egg 3 — O velho arquivo sequencial

Durante décadas, aplicações COBOL utilizaram arquivos sequenciais e registros organizados para processar informações empresariais.

Esses mecanismos ensinam uma lição que continua valiosa.

Dados precisam de estrutura.

Informações precisam de contexto.

Resultados precisam de validação.

Não existe inteligência artificial capaz de transformar automaticamente dados inconsistentes em verdades confiáveis.

Easter egg 4 — O terminal 3270

Imagine Edamame sentado diante de um terminal IBM 3270.

Na tela, um sistema solicita confirmação de uma transação.

A operação exige autorização.

O personagem tenta executar a tarefa sem possuir os privilégios necessários.

O sistema apresenta uma mensagem de acesso negado.

O que parece uma inconveniência é, na realidade, uma proteção.

Em sistemas críticos, impedir operações indevidas é tão importante quanto executar rapidamente as operações permitidas.

Easter egg 5 — O verdadeiro Great Pretender

O título do anime faz referência ao universo das aparências, das identidades e da confiança.

No mundo da IA generativa, existe um fenômeno curioso.

Uma resposta pode parecer extremamente segura e bem fundamentada mesmo quando contém erros.

A fluência não garante veracidade.

Um texto bonito não é necessariamente um texto correto.

E um documento produzido com velocidade não é necessariamente um documento juridicamente adequado.

Talvez seja essa a maior armadilha contemporânea: confundir aparência de competência com competência comprovada.


🏁 Epílogo — Quem vencerá a guerra da inteligência artificial jurídica?

A cafeteria começava a fechar.

Edamame guardou o notebook.

A investigação havia revelado três forças disputando o futuro.

De um lado, empresas de tecnologia financiadas para automatizar operações jurídicas.

De outro, entidades profissionais preocupadas com responsabilidade, independência e atividades reservadas aos advogados.

No centro, trabalhadores, empresas, consumidores e cidadãos cujos direitos dependem do funcionamento correto da Justiça.

Seria possível construir uma solução que respeitasse todos esses interesses?

A resposta depende de escolhas tecnológicas, regulatórias, econômicas e institucionais.

A inovação pode ampliar o acesso aos serviços jurídicos, reduzir tarefas repetitivas e melhorar a análise de documentos.

Mas também pode reproduzir erros em escala, concentrar capacidade tecnológica e enfraquecer mecanismos de responsabilidade quando implementada inadequadamente.

A questão não é escolher entre inteligência artificial e advogados.

É construir sistemas em que automação e responsabilidade profissional possam coexistir de maneira verificável.

No universo do mainframe, aprendemos que disponibilidade, integridade e segurança não aparecem espontaneamente.

São resultados de arquitetura, processos, controles, testes e profissionais preparados.

A Justiça automatizada precisa da mesma disciplina.

Edamame levantou-se.

— Laurent, sabe qual foi a coisa mais importante que aprendi?

— Qual?

— Que o verdadeiro perigo não está em uma máquina escrever milhares de documentos.

Laurent inclinou a cabeça.

— Então onde está?

— Em alguém acreditar que milhares de documentos estão corretos apenas porque uma máquina conseguiu produzi-los.

O francês terminou seu café.

— Muito bem, Edamame. Você está começando a pensar como um verdadeiro investigador.

E, em algum lugar de um centro de processamento de dados, um programa COBOL continuava registrando transações, verificando condições e preservando as informações que talvez um dia precisassem ser apresentadas diante de um tribunal.

Porque, no final das contas, a confiança não nasce da velocidade de processamento. Ela nasce da possibilidade de verificar a verdade.


☕ Considerações finais — Bellacosa Mainframe

A história da Enter representa uma nova etapa da transformação digital brasileira.

Não estamos falando de uma experiência acadêmica isolada.

Estamos diante de uma empresa que anunciou investimentos expressivos, conquistou grandes clientes e passou a atuar em uma atividade com profundas consequências sociais.

A reação da OAB-SP, a estratégia de negociação do Conselho Federal e as decisões da Justiça Federal revelam que as instituições brasileiras ainda estão procurando maneiras de lidar com sistemas capazes de automatizar tarefas intelectuais especializadas.

A discussão merece ser acompanhada sem alarmismo e sem ingenuidade.

É necessário evitar tanto a ideia de que qualquer utilização de IA constitui uma ameaça à advocacia quanto a suposição de que toda automação produzida por uma empresa inovadora será automaticamente benéfica.

O desenvolvimento tecnológico precisa caminhar com transparência, responsabilização e proteção dos direitos fundamentais.

Para nós, programadores COBOL, fica uma lição adicional.

O futuro da computação empresarial não será necessariamente uma guerra entre mainframes e inteligência artificial.

Poderá ser uma combinação de sistemas transacionais altamente confiáveis, interfaces modernas, modelos inteligentes e processos de governança rigorosos.

A inteligência artificial poderá analisar registros produzidos por aplicações COBOL.

Mas os desenvolvedores continuarão precisando compreender dados, regras de negócio, integridade transacional e segurança.

Talvez a maior contribuição das tecnologias tradicionais para esse novo mundo seja justamente lembrar que sistemas críticos exigem disciplina.

A IA pode escrever a minuta. O COBOL pode fornecer a evidência. Mas a responsabilidade pela decisão não pode desaparecer no meio do processamento.

E essa, meus caros leitores, é uma história que vale mais do que US$ 1,2 bilhão.

Até o próximo café no Bellacosa Mainframe!


Referências e fontes consultadas

  1. UOL — Artur Rodrigues, 5 de novembro de 2026: Disputa sobre IA jurídica expõe guerra fria entre OAB-SP e cúpula nacional.
    https://noticias.uol.com.br/colunas/artur-rodrigues/2026/11/05/disputa-sobre-ia-juridica-expoe-guerra-fria-entre-oab-sp-e-cupula-nacional.htm

  2. OAB-SP — 7 de outubro de 2026: comunicado sobre a ação civil pública ajuizada contra a Enter.
    https://www.oabsp.org.br/

  3. OAB-SP — 20 de outubro de 2026: comunicado sobre documentos apresentados no processo judicial.
    https://www.oabsp.org.br/

  4. OAB-SP — 21 de outubro de 2026: comunicado sobre a decisão judicial de preservação de registros.
    https://www.oabsp.org.br/

  5. Conselho Federal da OAB: Resolução nº 16/2026, sobre parâmetros para termos de ajustamento com empresas de IA jurídica.
    https://deoab.oab.org.br/

  6. Enter — 5 de maio de 2026: anúncio da rodada Série B e avaliação de US$ 1,2 bilhão.
    https://www.getenter.ai/

  7. Bloomberg Línea — 5 de maio de 2026: cobertura da rodada de investimento da Enter.
    https://www.bloomberglinea.com.br/

  8. Great Pretender — Site oficial: informações sobre Makoto Edamura, personagens, história e produção.
    https://www.greatpretender.jp/

  9. IBM: documentação de Enterprise COBOL e desenvolvimento no IBM Z.
    https://www.ibm.com/docs/en/cobol-zos


Bellacosa Mainframe — Onde os sistemas legados encontram a inteligência artificial, a história da computação ganha vida e até um vigarista internacional precisa aprender COBOL.

quarta-feira, 4 de novembro de 2026

🔥 FULLMETAL HACKER: O DIA EM QUE OS CIBERCRIMINOSOS TRANSFORMARAM GELADEIRAS EM FORNALHAS NA EUROPA!

 

Bellacosa Mainframe e o ataque as geladeiras de armazenamento de alimentos e bancos de sangue

☕ UM CAFÉ NO BELLACOSA MAINFRAME

🔥 FULLMETAL HACKER: O DIA EM QUE OS CIBERCRIMINOSOS TRANSFORMARAM GELADEIRAS EM FORNALHAS NA EUROPA!

Edward Elric e a Lei da Troca Equivalente: como invasores atacaram supermercados, destruíram alimentos e revelaram o lado perigoso da Internet das Coisas

Bellacosa Mainframe — Arqueologia da Computação, COBOL, Mainframes, Cibersegurança e os Fantasmas do Código Legado

Uma investigação sobre os ataques à cadeia de frio europeia em 2026, acompanhada de curiosidades históricas, engenharia de segurança e um laboratório didático em COBOL.



⚗️ Prólogo — A Lei da Troca Equivalente chegou ao supermercado

"Para obter alguma coisa, é preciso sacrificar outra de valor equivalente."

Quem conhece Fullmetal Alchemist reconhece imediatamente a ideia que governa a alquimia praticada pelos irmãos Edward e Alphonse Elric.

No universo criado por Hiromu Arakawa, a alquimia permite transformar a matéria, mas exige respeito a determinadas regras.

E o que acontece quando alguém tenta ignorá-las?

Desastres.

A história começa justamente com uma tentativa de transmutação humana que termina em tragédia. Edward perde partes do corpo, enquanto Alphonse perde o corpo inteiro e tem sua alma vinculada a uma armadura.

Agora imagine nosso alquimista de aço diante de uma notícia bastante real.

Europa, madrugada de 2 de novembro de 2026.

Em supermercados espalhados por diferentes países, equipamentos de refrigeração começam a apresentar temperaturas anormais.

Alguns sistemas indicam valores próximos de 50 graus Celsius.

Funcionários chegam ao trabalho e encontram câmaras frigoríficas comprometidas, congeladores fora das condições adequadas de conservação e produtos que precisam ser descartados.

Milhares de euros em alimentos podem desaparecer economicamente em poucas horas.

Mas não houve necessariamente uma pane elétrica.

Também não foi preciso um criminoso entrar fisicamente em cada estabelecimento.

Os sistemas haviam sido alcançados por meio de conexões digitais.

Edward Elric observa os números e protesta:

— Esperem! Quem foi o idiota que resolveu transmutar um congelador em uma fornalha?

Alphonse, sempre mais ponderado, examina o painel:

— Irmão, parece que alguém alterou os parâmetros de funcionamento remotamente.

Edward fecha o punho metálico.

— Então a Lei da Troca Equivalente continua funcionando. Alguém alterou alguns números, e os supermercados perderam toneladas de mercadorias!

Bem-vindos a uma nova fronteira da cibersegurança.

Uma fronteira onde bits modificam átomos.

Onde comandos digitais afetam equipamentos reais.

E onde o verdadeiro prejuízo não precisa aparecer primeiro numa base de dados, mas pode surgir diretamente dentro de uma câmara frigorífica.

Pegue seu café.

Hoje nossa investigação começa nos supermercados europeus, passa pela tecnologia operacional e termina num laboratório COBOL, sob a supervisão do nosso pequeno — não digam isso perto dele! — Alquimista de Aço.



Capítulo I — Outubro de 2026: a primeira transmutação proibida

Nossa história começa na França.

Na madrugada de 11 para 12 de outubro de 2026, centenas de estabelecimentos comerciais enfrentaram problemas provocados por ataques aos sistemas informatizados de refrigeração.

Entre os grupos atingidos estavam lojas ligadas a Intermarché, Coopérative U, Carrefour, E.Leclerc e Monoprix.

Segundo a cobertura do jornal Le Monde, determinados invasores conseguiram alterar parâmetros relacionados ao descongelamento e ao controle térmico dos equipamentos.

Em um dos episódios relatados, o ciclo de descongelamento foi prolongado de aproximadamente uma para oito horas.

Pense no significado disso.

Uma operação de descongelamento é absolutamente normal em determinados equipamentos frigoríficos.

O objetivo é remover gelo acumulado, preservando a eficiência da refrigeração.

O problema surge quando alguém altera indevidamente sua duração, frequência ou temperatura.

Um recurso criado para conservar a eficiência do equipamento pode passar a produzir o efeito oposto.

É quase uma transmutação alquímica.

O recurso continua existindo.

O equipamento continua ligado.

Mas seu comportamento foi modificado.

No universo de Edward Elric, seria como alterar discretamente a composição de um círculo de transmutação.

Uma pequena diferença nos símbolos produziria uma transformação inteiramente inesperada.

Na engenharia industrial, uma pequena alteração em um parâmetro crítico também pode produzir consequências enormes.

E o resultado francês foi grave: mercadorias descartadas, interrupção de operações e investigações sobre os mecanismos utilizados.

A grande curiosidade

O ataque não precisava necessariamente destruir o refrigerador.

Era suficiente fazer com que o equipamento deixasse de cumprir sua função essencial durante tempo suficiente.

Essa distinção é importantíssima.

O objetivo de um sistema de segurança industrial não é apenas impedir que máquinas sejam destruídas.

É garantir que elas continuem operando dentro de limites seguros.



Capítulo II — Novembro: o ataque atravessa fronteiras

Três semanas depois, em 2 de novembro, novos incidentes atingiram estabelecimentos em diferentes países europeus.

A lista de locais com ocorrências relatadas incluiu:

  • Bélgica;

  • Suécia;

  • Irlanda;

  • Luxemburgo;

  • Países Baixos;

  • Estônia;

  • Finlândia;

  • Itália;

  • Portugal.

Na Bélgica, lojas de redes como Carrefour, Delhaize e Intermarché relataram problemas.

Na Suécia, estabelecimentos das redes ICA e Coop também foram afetados.

Na Irlanda, a rede SuperValu informou incidentes em treze lojas.

E há uma informação especialmente relevante para nós, lusófonos: sete estabelecimentos Intermarché em Portugal foram relacionados à ocorrência.

Segundo declarações divulgadas pela imprensa, uma das hipóteses investigadas em Portugal envolvia um prestador externo responsável pela gestão de sistemas de refrigeração.

Isso nos leva a uma pergunta fundamental.

Como alguém consegue interferir em geladeiras de supermercados localizados em países diferentes?

Edward Elric poderia imaginar um gigantesco círculo de transmutação desenhado sobre o continente europeu.

Mas a explicação técnica é muito menos fantástica.

Ela envolve redes, equipamentos conectados, controladores industriais, software legado e mecanismos de acesso remoto.

E há uma ressalva importante: até 4 de novembro de 2026, as autoridades não haviam identificado publicamente, de maneira conclusiva, os responsáveis nem demonstrado que todos os incidentes pertenciam a uma única operação coordenada.

A semelhança entre ataques é uma pista investigativa.

Não é, por si só, uma prova de autoria comum.



Capítulo III — Edward Elric descobre a Tecnologia Operacional

Para compreender esses ataques, precisamos conhecer uma sigla:

OT — Operational Technology.

Em português, tecnologia operacional.

Enquanto a tecnologia da informação, ou TI, concentra-se no processamento de informações, a tecnologia operacional está diretamente associada ao controle e ao monitoramento de equipamentos e processos físicos.

Vamos comparar.

Num supermercado, os sistemas tradicionais de TI podem cuidar do faturamento, cadastro de produtos, controle financeiro, inventário, pagamentos eletrônicos e integração com fornecedores.

Já os sistemas OT podem controlar equipamentos de refrigeração, sensores térmicos, compressores, ventilação, válvulas e alarmes.

Naturalmente, os dois mundos se comunicam.

Um exemplo:

O sistema de gestão precisa saber se determinada mercadoria está disponível.

Já o sistema de refrigeração precisa garantir que ela permaneça armazenada em condições adequadas.

Um acompanha a informação.

O outro preserva fisicamente o produto.

A arquitetura de uma instalação conectada

Imagine a seguinte estrutura:

          INTERNET
             |
       ACESSO REMOTO
             |
      REDE DE CONTROLE
             |
      SISTEMA SUPERVISOR
             |
    CONTROLADOR INDUSTRIAL
             |
       +-----+-----+
       |           |
     SENSOR     ATUADOR
       |           |
 TEMPERATURA   COMPRESSOR

Esse é um esquema conceitual, não uma reprodução dos sistemas efetivamente atacados.

O sensor mede uma condição física.

O controlador interpreta essa medida.

O atuador modifica alguma coisa no ambiente.

Um compressor pode ser ligado ou desligado.

Uma válvula pode ser acionada.

Um ciclo de descongelamento pode começar.

Tudo isso permite controle preciso e economia de energia.

Porém, se alguém conseguir modificar indevidamente os parâmetros aceitos pelo controlador, poderá interferir no processo físico.

Edward observa o esquema.

— Então o controlador é como o círculo de transmutação?

— Mais ou menos — responde Alphonse. — Ele transforma informações em ações físicas.

— E quem controla seus parâmetros controla o resultado!

Exatamente.

Essa é a essência dos sistemas ciberfísicos.


Capítulo IV — A verdadeira alquimia: transformar bits em prejuízo

O aspecto mais impressionante desses ataques é a relação desproporcional entre a operação digital e a consequência econômica.

Imagine um estabelecimento fictício com cem mil euros em mercadorias refrigeradas.

Vamos supor que o sistema apresente uma condição térmica inadequada durante várias horas.

O equipamento poderá ser recuperado.

O software poderá ser restaurado.

As configurações poderão voltar aos valores normais.

Mas os alimentos não necessariamente poderão ser recuperados.

A conservação depende de fatores como temperatura efetiva, duração da exposição, natureza do produto e histórico de armazenamento.

Um alimento que sofreu uma interrupção inadequada na cadeia de frio não se torna automaticamente seguro porque foi congelado outra vez.

Esse é o ponto central.

O dano digital pode ser reversível.

O dano físico e econômico pode ser permanente.

O caso dos 50 graus

Diversas reportagens mencionaram equipamentos configurados ou indicando temperaturas de 50 °C.

É necessário distinguir uma temperatura de referência manipulada, uma leitura apresentada pelo controlador e a temperatura efetivamente alcançada pelo alimento.

Não são necessariamente a mesma coisa.

Em alguns sistemas, os indicadores podem registrar parâmetros internos ou condições específicas de operação.

Portanto, afirmar que todos os alimentos chegaram a 50 °C seria tecnicamente incorreto.

Mas mesmo sem atingir esse extremo, a perda prolongada de refrigeração pode comprometer completamente um estoque.

Curiosidade: por que o ataque noturno é tão perigoso?

Durante a madrugada, muitos supermercados estão fechados.

Há menos funcionários presentes.

Alertas podem depender de supervisão remota.

Uma falha detectada apenas na abertura da loja já pode ter provocado prejuízos substanciais.

Em sistemas industriais, o tempo entre o início da anomalia e sua detecção é tão importante quanto a própria anomalia.


Capítulo V — Os fantasmas do legado: quando o antigo continua conectado

Agora chegamos a um tema bastante familiar para quem trabalha com mainframes.

Sistemas legados.

Essa expressão costuma ser utilizada equivocadamente como sinônimo de tecnologia ruim ou ultrapassada.

Mas legado não significa necessariamente insegurança.

Um sistema COBOL desenvolvido há décadas pode continuar perfeitamente adequado, desde que seja mantido, documentado, monitorado e protegido.

O problema surge quando uma tecnologia antiga permanece exposta a ameaças modernas sem controles compatíveis.

Nos incidentes europeus, pesquisadores e fornecedores apontaram riscos relacionados a equipamentos antigos, software sem atualização, configurações inadequadas e credenciais de fábrica.

Alguns produtos já haviam ultrapassado seu período de suporte.

Isso significa que determinadas vulnerabilidades podem permanecer sem correções disponibilizadas pelo fabricante.

O paradoxo da longevidade

Considere duas instalações.

A primeira usa um computador industrial antigo, mas permanece devidamente isolada, com acesso controlado, monitoramento independente e procedimentos de manutenção.

A segunda utiliza um controlador relativamente moderno, mas deixa sua administração remota acessível sem autenticação adequada.

Qual é necessariamente mais segura?

Não podemos decidir apenas pela idade dos equipamentos.

A segurança depende da arquitetura, da manutenção, dos controles de acesso e da exposição real.

É uma lição que vale tanto para ambientes industriais quanto para o IBM Z.

Um mainframe moderno pode possuir mecanismos robustos de segurança e auditoria.

Mesmo assim, integrações externas, serviços distribuídos ou aplicações periféricas mal protegidas podem introduzir riscos.

Da mesma forma, um controlador frigorífico confiável pode tornar-se vulnerável caso sua interface de administração seja exposta indevidamente.

A lição de Edward Elric

Na alquimia, conhecer os elementos não basta.

É preciso compreender as relações entre eles.

Na segurança, proteger individualmente os componentes não basta.

Precisamos compreender as conexões, dependências e pontos de confiança.


Capítulo VI — O pequeno grande problema dos fornecedores externos

Uma parte importante das investigações envolve a forma como supermercados contratam serviços de manutenção e monitoramento.

Muitas empresas não administram diretamente todos os equipamentos frigoríficos.

Elas podem contratar especialistas responsáveis por monitorar temperaturas, verificar alarmes, diagnosticar problemas e realizar ajustes remotos.

Isso é extremamente útil.

Imagine centenas de supermercados espalhados por várias regiões.

Enviar técnicos diariamente a cada estabelecimento seria caro e pouco eficiente.

O monitoramento remoto permite detectar problemas antecipadamente.

Entretanto, também introduz uma nova dependência.

Se um fornecedor consegue administrar equipamentos em muitas lojas, as credenciais e conexões utilizadas por esse fornecedor tornam-se particularmente sensíveis.

Um comprometimento pode atingir mais de uma organização.

Esse é um risco de cadeia de fornecimento digital.

Em Portugal, a suspeita divulgada sobre o envolvimento de um prestador externo ilustra por que esse modelo precisa ser investigado.

Mas atenção: suspeitar de uma conexão de terceiros não prova que o fornecedor tenha sido invadido.

Pode haver outras formas de comprometimento, incluindo equipamentos individualmente expostos.

A investigação precisa examinar registros, credenciais, conexões, configurações e evidências forenses.

Uma pergunta para gestores

Sua empresa sabe exatamente quais fornecedores possuem acesso remoto aos equipamentos?

E consegue revogar esse acesso rapidamente?

Se a resposta for não, existe uma questão de governança que merece atenção.


Capítulo VII — O alquimista encontra o COBOL

Chegou a hora de nossa missão prática.

Edward Elric está indignado.

— Como assim vocês têm sensores, computadores, redes e sistemas corporativos, mas ainda conseguem perder um estoque inteiro?

Alphonse responde:

— Irmão, podemos construir um programa para identificar anomalias e produzir alertas.

— Então tragam o COBOL!

É importante esclarecer uma coisa.

COBOL não é normalmente a linguagem responsável pelo controle direto de compressores industriais.

Essas funções costumam ser desempenhadas por controladores especializados e sistemas de automação.

Contudo, COBOL pode participar perfeitamente do processamento empresarial de informações relacionadas à cadeia de frio.

Por exemplo:

  • receber registros de sensores;

  • validar dados enviados por sistemas externos;

  • analisar exceções;

  • produzir relatórios;

  • apoiar auditorias;

  • alimentar processos de gestão de risco;

  • registrar eventos para investigação.

Esse é exatamente o tipo de integração em que sistemas corporativos podem agregar valor.

Vamos desenvolver um pequeno laboratório didático.


Capítulo VIII — Laboratório 01: construindo um monitor de temperatura em COBOL

Objetivo: criar um programa que receba uma temperatura e determine se ela está dentro do intervalo definido para um equipamento hipotético.

Nosso exemplo utilizará uma faixa didática entre −22 °C e −15 °C.

Esses valores não constituem uma norma universal de segurança alimentar. Na vida real, os limites dependem do equipamento, do produto e dos requisitos aplicáveis.

O programa será apenas um simulador de validação, não um controlador físico de refrigeração.

Passo 1 — Entender o problema

Precisamos de três informações:

  1. A temperatura recebida.

  2. O limite mínimo.

  3. O limite máximo.

Nosso algoritmo será simples.

Se a temperatura estiver abaixo do mínimo, emitiremos um alerta.

Se estiver acima do máximo, também emitiremos um alerta.

Caso contrário, consideraremos a leitura dentro da faixa didática.

Passo 2 — Escrever o programa

O exemplo abaixo utiliza sintaxe COBOL em formato livre, adequada para estudo em compiladores que suportam esse formato.

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

environment division.
configuration section.
repository.
    function all intrinsic.

data division.
working-storage section.

01 ws-entrada        pic x(20).
01 ws-temperatura    pic s9(3)v9(2).
01 ws-temp-minima    pic s9(3)v9(2)
                     value -22.00.
01 ws-temp-maxima    pic s9(3)v9(2)
                     value -15.00.
01 ws-temp-exibicao  pic -(3)9.99.

procedure division.

principal.
    display "BELLACOSA MAINFRAME"
    display "MONITOR DIDATICO DE FRIO"
    display "Informe a temperatura:"

    accept ws-entrada

    if test-numval(trim(ws-entrada)) not = 0
        display "ERRO: VALOR INVALIDO"
        goback
    end-if

    compute ws-temperatura =
        function numval(trim(ws-entrada))

    move ws-temperatura to ws-temp-exibicao

    evaluate true
        when ws-temperatura < ws-temp-minima
            display "ALERTA: ABAIXO DO MINIMO"

        when ws-temperatura > ws-temp-maxima
            display "ALERTA: ACIMA DO MAXIMO"

        when other
            display "TEMPERATURA NA FAIXA"
    end-evaluate

    display "LEITURA: "
        ws-temp-exibicao

    goback.

Passo 3 — Compreender o código

Vamos examinar os elementos mais importantes.

IDENTIFICATION DIVISION

Identifica o programa.

Neste exemplo, seu nome é FRIOALRT.

WORKING-STORAGE SECTION

Define as variáveis utilizadas durante o processamento.

A variável ws-temperatura utiliza um campo numérico assinado com duas casas decimais.

A cláusula PIC S9(3)V9(2) permite representar temperaturas positivas e negativas dentro de sua capacidade numérica.

A letra V indica uma posição decimal implícita.

ACCEPT

Recebe uma informação fornecida pelo operador.

Num sistema real, a temperatura poderia chegar por arquivo, mensagem ou interface com outro sistema.

TEST-NUMVAL

Ajuda a verificar se a informação textual recebida pode ser interpretada como número.

É uma validação inicial.

Em sistemas reais, também precisamos verificar o intervalo permitido, a precisão, os limites de armazenamento e a origem da leitura.

EVALUATE TRUE

Permite testar condições e selecionar o tratamento adequado.

É uma estrutura particularmente útil quando desejamos organizar regras de classificação.

Passo 4 — Executar os testes

Imagine os seguintes resultados:

Temperatura informadaResultado esperado
−18,00 °CDentro da faixa
−23,00 °CAbaixo do mínimo
−12,00 °CAcima do máximo
5,00 °CAcima do máximo
50,00 °CAcima do máximo

Ao executar, informe os valores com ponto decimal, como -18.00, de acordo com o formato previsto pelo exemplo.

Uma observação técnica: para uso com dados reais, também é importante validar limites antes da conversão para um campo de tamanho fixo, evitando truncamentos ou incompatibilidades.

Passo 5 — A principal limitação

Nosso programa identifica uma temperatura fora do intervalo.

Mas isso não significa que ele consiga determinar a causa.

Uma temperatura alta pode resultar de:

  • porta aberta;

  • falha mecânica;

  • interrupção de energia;

  • degelo normal;

  • manutenção;

  • sensor defeituoso;

  • configuração incorreta;

  • interferência maliciosa.

Um alerta é uma observação.

Não é automaticamente uma conclusão forense.

Edward Elric aprende rapidamente a diferença:

— Então meu programa pode dizer que a geladeira está quente, mas não pode afirmar que um hacker foi o responsável?

Exatamente.

E é por isso que sistemas de monitoramento precisam preservar evidências e trabalhar com informações contextualizadas.


Capítulo IX — Laboratório 02: detectando anomalias em sequência

Vamos evoluir o raciocínio.

Imagine que recebemos temperaturas a cada cinco minutos.

Uma única leitura anormal já merece atenção.

Mas uma sequência de medições pode revelar algo muito mais interessante.

Considere este cenário hipotético:

HorárioTemperatura
01:00−18 °C
01:05−18 °C
01:10−17 °C
01:15−12 °C
01:20−5 °C
01:254 °C
01:3012 °C

O que podemos observar?

A temperatura está subindo rapidamente.

Isso pode indicar uma anomalia importante.

Mas precisamos considerar o comportamento esperado durante ciclos operacionais, a localização do sensor e a confiabilidade dos dados.

Exercício para o estudante COBOL

Crie um programa que:

  1. Leia um arquivo com identificador do equipamento, horário e temperatura.

  2. Verifique se cada registro possui formato válido.

  3. Compare a temperatura com os limites configurados.

  4. Conte ocorrências consecutivas acima do limite.

  5. Produza um relatório de exceções.

  6. Registre os dados originais sem sobrescrevê-los.

Para um iniciante, esse exercício permite praticar leitura sequencial de arquivos, estruturas de dados, condicionais, contadores e relatórios.

Para um estudante mais avançado, podemos incluir validação de sequência temporal, tratamento de registros duplicados e controle de integridade.

Uma melhoria fundamental

Imagine que o próprio controlador comprometido forneça as temperaturas utilizadas pelo monitoramento.

O atacante poderia, dependendo das capacidades do sistema, interferir também nas informações exibidas.

Por isso, sensores independentes e mecanismos separados de alerta podem ser valiosos.

É o princípio de não confiar exclusivamente no mesmo componente que estamos tentando supervisionar.


Capítulo X — Laboratório 03: o que JCL tem a ver com geladeiras?

Agora vamos trazer o problema para um ambiente IBM z/OS.

Imagine uma organização que recebe periodicamente arquivos de medições enviados por uma plataforma externa.

Um processamento batch pode analisar esses registros e gerar relatórios.

Nosso fluxo hipotético seria:

SISTEMA DE REFRIGERACAO
          |
      EXPORTACAO
          |
  ARQUIVO DE LEITURAS
          |
       IBM z/OS
          |
        JCL
          |
    PROGRAMA COBOL
          |
  RELATORIO DE ALERTAS
          |
    EQUIPE OPERACIONAL

No mundo corporativo, essa arquitetura é perfeitamente plausível.

O mainframe não precisa controlar o compressor.

Ele pode trabalhar na consolidação e análise das informações recebidas.

Um exemplo didático de JCL, para um programa COBOL previamente compilado e catalogado, seria:

//FRIOJOB  JOB (ACCT),'BELLACOSA',
//         CLASS=A,MSGCLASS=X
//STEP01   EXEC PGM=FRIOBATCH
//STEPLIB  DD DSN=BM.LOADLIB,DISP=SHR
//ENTRADA  DD DSN=BM.FRIO.LEITURAS,
//         DISP=SHR
//RELAT    DD DSN=BM.FRIO.RELATORIO,
//         DISP=(NEW,CATLG,DELETE),
//         SPACE=(TRK,(5,5)),
//         DCB=(RECFM=FB,LRECL=120,
//         BLKSIZE=0)
//SYSOUT   DD SYSOUT=*

Esse JCL ilustra a execução de um segundo programa, chamado FRIOBATCH, que seria desenvolvido para processar arquivos.

Ele não executa diretamente nosso programa interativo FRIOALRT.

Essa distinção é importante.

O primeiro programa recebe uma informação pelo terminal.

O segundo seria uma versão batch, com arquivos definidos na FILE-CONTROL e seus respectivos descritores de registros.

Os nomes de datasets, classes, biblioteca de carga e parâmetros precisam ser adaptados ao ambiente real.

E onde entra a segurança?

A execução pode ser protegida por controles do z/OS e políticas RACF.

Podemos estabelecer permissões específicas para os datasets.

Podemos registrar as execuções.

Podemos separar usuários responsáveis por processamento daqueles autorizados a administrar a infraestrutura.

Também podemos direcionar relatórios para sistemas corporativos de monitoramento.

Mas não devemos cometer um erro conceitual.

Um relatório batch executado periodicamente não substitui um sistema de segurança industrial em tempo real.

Se uma câmara frigorífica estiver aquecendo rapidamente, esperar pelo próximo processamento noturno pode ser tarde demais.

O mecanismo primário de proteção precisa funcionar no tempo adequado ao risco físico.


Capítulo XI — O caso dos bancos de sangue: quando a consequência pode ser humana

Em 4 de novembro de 2026, surgiu uma informação ainda mais preocupante.

A Reuters noticiou que sistemas de monitoramento e controle de armazenamento refrigerado ligados a três instalações regionais do serviço francês de sangue também haviam sido afetados.

Os incidentes foram detectados.

As equipes atuaram.

O material foi protegido ou transferido para equipamentos não conectados aos sistemas comprometidos.

Segundo as informações divulgadas, não houve prejuízo às reservas de sangue.

Esse episódio demonstra por que devemos tratar a segurança de sistemas OT com extremo cuidado.

Uma falha em um congelador comercial pode produzir perdas financeiras significativas.

Uma falha em equipamentos que preservam medicamentos, sangue ou outros materiais sensíveis pode introduzir riscos sanitários.

Felizmente, no episódio francês relatado, as medidas de contingência evitaram perdas dos materiais armazenados.

Edward Elric e o valor da vida

Aqui nossa analogia com Fullmetal Alchemist ganha profundidade.

Edward e Alphonse aprendem dolorosamente que não é possível reduzir a vida humana a uma simples lista de ingredientes.

Da mesma forma, nenhuma análise de risco deve reduzir as consequências de uma falha industrial apenas ao valor contábil do equipamento.

A segurança precisa considerar pessoas, processos e impactos indiretos.

Uma organização pode substituir um computador.

Pode reinstalar um programa.

Pode comprar outro sensor.

Mas determinados prejuízos não são recuperáveis com uma simples restauração de backup.


Capítulo XII — Quem são os alquimistas criminosos?

Uma pergunta aparece inevitavelmente.

Quem realizou esses ataques?

Até 4 de novembro de 2026, não havia atribuição pública conclusiva a um grupo específico.

Também não existiam evidências suficientes para afirmar que uma determinada potência estrangeira estivesse por trás das ocorrências.

É necessário separar fatos de hipóteses.

Sabemos que houve manipulação de sistemas de refrigeração em diversos estabelecimentos.

Sabemos que equipamentos conectados e tecnologias antigas estiveram entre as preocupações identificadas.

Sabemos que diferentes autoridades iniciaram investigações.

Mas ainda existem perguntas sem resposta.

Os ataques foram coordenados?

Uma mesma pessoa ou grupo participou de todas as ocorrências?

Os invasores pretendiam extorquir dinheiro?

Queriam demonstrar capacidade técnica?

Estavam buscando provocar prejuízo econômico deliberado?

Existe algum componente de sabotagem política ou estratégica?

Todas são perguntas legítimas.

Nenhuma delas deve ser transformada automaticamente em conclusão.

Guerra híbrida?

A expressão guerra híbrida descreve, entre outras coisas, a combinação de diferentes instrumentos de pressão, incluindo operações digitais, econômicas e informacionais.

Um ataque contra a cadeia de abastecimento pode ser compatível com uma estratégia de desestabilização.

Entretanto, a natureza do alvo não comprova a identidade ou a motivação dos atacantes.

Atribuição exige evidências técnicas, contexto operacional e investigação consistente.

O bom analista não é aquele que encontra rapidamente um culpado.

É aquele que consegue distinguir o que conhece daquilo que ainda precisa descobrir.


Capítulo XIII — Dez medidas para proteger a cadeia de frio

Vamos transformar nossa investigação em conhecimento prático.

1. Inventariar os equipamentos

A organização precisa saber quais controladores utiliza, onde estão instalados e quais versões de software executam.

Não conseguimos proteger adequadamente aquilo que desconhecemos.

2. Revisar acessos remotos

Toda conexão externa deve possuir uma justificativa operacional.

Acessos desnecessários precisam ser removidos.

3. Substituir credenciais de fábrica

Senhas padrão compartilhadas entre equipamentos representam um risco conhecido.

Credenciais devem ser individualizadas e protegidas.

4. Utilizar autenticação forte

Sempre que suportado pela arquitetura, o acesso remoto deve utilizar autenticação multifator e mecanismos de identificação individual.

5. Segmentar redes

Controladores industriais não devem compartilhar indiscriminadamente a mesma superfície de acesso dos serviços corporativos.

A comunicação entre ambientes precisa ser controlada.

6. Atualizar com planejamento

Atualizações de firmware e software devem ser avaliadas conforme as orientações do fabricante e os requisitos de disponibilidade do ambiente.

Em instalações críticas, alterações exigem testes e procedimentos de contingência.

7. Implantar monitoramento independente

Sensores e alarmes independentes podem ajudar a identificar problemas mesmo quando o sistema principal de controle apresenta falhas.

8. Proteger limites operacionais

Quando a arquitetura permitir, mecanismos locais de segurança devem restringir configurações perigosas.

Esses limites precisam respeitar as especificações técnicas do equipamento.

9. Preparar planos de contingência

O supermercado precisa saber o que fazer quando perder o controle remoto dos equipamentos.

Isso pode envolver procedimentos locais, equipamentos alternativos e transferência de mercadorias.

10. Realizar exercícios de resposta

Uma equipe treinada consegue agir com mais rapidez.

O objetivo não é apenas restaurar computadores.

É preservar a segurança operacional e reduzir consequências físicas.


Capítulo XIV — Easter eggs: a alquimia escondida na computação

Como tradição do Bellacosa Mainframe, nossa história merece algumas curiosidades.

Easter egg 01 — A automação industrial nasceu antes da Internet moderna

Sistemas de controle industrial já existiam muito antes de a Internet se tornar popular.

A supervisão remota evoluiu gradualmente, utilizando diferentes tecnologias de comunicação.

A conexão generalizada desses equipamentos a redes modernas trouxe benefícios, mas também novas ameaças.

Easter egg 02 — O IBM System/360 e a alquimia da compatibilidade

Em 1964, a IBM anunciou o System/360, uma família de computadores concebida para oferecer compatibilidade arquitetural entre diferentes modelos.

A ideia de preservar investimentos em software enquanto o hardware evolui ajudou a estabelecer uma tradição importante no universo mainframe.

Aqui encontramos uma diferença interessante.

Longevidade acompanhada de manutenção e evolução arquitetural é uma qualidade.

Longevidade acompanhada de abandono e exposição pode tornar-se um problema.

Easter egg 03 — O COBOL também nasceu de uma necessidade de continuidade

COBOL surgiu em 1959, quando organizações precisavam desenvolver aplicações empresariais mais portáveis e compreensíveis.

Décadas depois, continua presente em processamento corporativo.

Seu valor não está na idade, mas na capacidade de atender necessidades reais de negócios.

Easter egg 04 — A Lei da Troca Equivalente funciona como uma metáfora econômica

Na computação, uma alteração de configuração pode custar apenas alguns bytes.

Mas as consequências podem atingir milhões de euros.

A equivalência aqui não é física.

É uma metáfora sobre responsabilidade.

Toda decisão técnica possui consequências, e uma economia aparentemente pequena em manutenção ou segurança pode produzir custos muito maiores no futuro.

Easter egg 05 — A armadura de Alphonse e a defesa em profundidade

Alphonse possui uma armadura impressionante.

Mas sua existência depende de algo muito mais delicado: o vínculo de sua alma com a armadura.

Na segurança, equipamentos robustos também podem depender de componentes discretos e críticos.

Um dispositivo industrial extremamente resistente pode perder sua proteção se a interface que controla suas configurações permanecer vulnerável.

É o clássico problema do elo fraco.

Easter egg 06 — Roy Mustang não deveria administrar refrigeradores

Nosso Coronel das Chamas seria uma escolha particularmente inadequada para supervisionar uma cadeia de frio.

Brincadeiras à parte, a separação de responsabilidades é um princípio importante.

Nem todo usuário precisa possuir poderes administrativos.

Permissões excessivas aumentam o impacto potencial de erros e comprometimentos.


Capítulo XV — O que um programador COBOL deve aprender com essa história?

Talvez você esteja começando a estudar COBOL e imaginando:

"O que supermercados europeus e equipamentos industriais têm a ver comigo?"

A resposta é: muito mais do que parece.

Primeiro, aprendemos que informações não existem isoladamente.

Um dado pode representar uma transação bancária, uma peça de estoque, uma remessa de medicamentos ou a temperatura de uma câmara frigorífica.

Segundo, descobrimos que validação não é um luxo.

Dados recebidos de sistemas externos precisam ser tratados como informações cuja origem, integridade e consistência devem ser verificadas.

Terceiro, percebemos a importância da rastreabilidade.

Um programa corporativo deve permitir compreender o que foi processado, quando, por qual origem e com qual resultado.

Quarto, entendemos a diferença entre detectar uma anomalia e explicar sua causa.

Um relatório pode mostrar que a temperatura aumentou.

Mas determinar se isso resultou de defeito mecânico, erro humano ou ataque exige outros elementos.

Quinto, aprendemos que integração entre sistemas exige responsabilidade.

Um programa COBOL que recebe informações de sensores industriais faz parte de uma cadeia de confiança.

Ele precisa tratar falhas, registros inválidos, duplicidades e inconsistências temporais.

E existe uma sexta lição.

O desenvolvedor corporativo precisa compreender o negócio que seu software protege.

Um cálculo correto executado com dados errados ainda pode produzir uma decisão incorreta.

Uma aplicação disponível vinte e quatro horas por dia não garante que o processo físico associado esteja funcionando adequadamente.

Disponibilidade, integridade, confidencialidade e segurança operacional são dimensões relacionadas, mas distintas.


Capítulo XVI — A transmutação final: quando a recuperação digital não recupera o mundo físico

Voltemos ao supermercado.

São oito horas da manhã.

A equipe técnica conseguiu restabelecer o funcionamento dos controladores.

Os equipamentos estão novamente refrigerando.

As conexões suspeitas foram desativadas.

Os especialistas começaram a investigar os registros disponíveis.

O sistema informatizado parece ter voltado ao normal.

Missão cumprida?

Não exatamente.

Ainda existem produtos que precisam ser avaliados.

Mercadorias que precisam ser descartadas.

Fornecedores que precisam ser acionados.

Funcionários que precisam reorganizar o estabelecimento.

Clientes que encontrarão prateleiras vazias.

E gestores que precisarão explicar os prejuízos.

Edward Elric contempla a situação.

— Então consertar a máquina não desfaz tudo o que aconteceu?

Alphonse responde:

— Não, irmão. Podemos recuperar o sistema, mas não necessariamente os alimentos.

Essa talvez seja a maior diferença entre um ataque tradicional contra informação e um ataque contra um processo físico.

Em muitos incidentes digitais, a recuperação de um backup confiável pode restaurar parte significativa da operação.

Num incidente ciberfísico, o mundo real não possui um botão universal de desfazer.

Uma mercadoria deteriorada não volta ao estado original porque restauramos a configuração de um controlador.

Uma consequência sanitária não desaparece porque reinstalamos o sistema operacional.

Um equipamento danificado pode precisar de reparos físicos.

A segurança digital passa, portanto, a fazer parte da segurança material das organizações.


Epílogo — A verdadeira Pedra Filosofal da cibersegurança

Na história de Fullmetal Alchemist, a Pedra Filosofal representa uma possibilidade extraordinária: superar limitações normalmente impostas à alquimia.

Mas a busca por esse poder revela consequências morais profundas.

No mundo da informática também procuramos soluções capazes de resolver todos os problemas.

Firewalls perfeitos.

Antivírus infalíveis.

Inteligência artificial capaz de detectar qualquer ameaça.

Redes completamente protegidas.

Mas essa Pedra Filosofal digital não existe.

A segurança depende de engenharia, manutenção, treinamento, governança e monitoramento contínuo.

Depende de conhecer os equipamentos.

De compreender as integrações.

De avaliar fornecedores.

De reduzir acessos desnecessários.

De preservar registros confiáveis.

E de preparar pessoas para agir quando as proteções falharem.

Os incidentes europeus de outubro e novembro de 2026 são uma demonstração dramática de que a transformação digital também amplia nossas responsabilidades.

Uma conexão remota pode economizar milhares de deslocamentos técnicos.

Pode melhorar a eficiência energética.

Pode antecipar falhas.

Pode reduzir perdas de alimentos.

Mas a mesma conectividade, quando inadequadamente protegida, pode transformar um benefício operacional em uma vulnerabilidade grave.

É a nossa Lei da Troca Equivalente tecnológica.

Não porque segurança e prejuízo sejam inevitavelmente equivalentes, mas porque toda arquitetura envolve escolhas, dependências e consequências.

Edward Elric termina seu café, observa o terminal e sorri.

— Agora compreendi. A verdadeira alquimia não é transformar chumbo em ouro.

Alphonse inclina a cabeça.

— Então o que é, irmão?

— É transformar conhecimento em prevenção!

E, lá no fundo do CPD, um programador COBOL acrescenta silenciosamente mais uma regra ao seu programa de validação.

Não para derrotar sozinho todos os hackers do planeta.

Mas para fazer aquilo que bons profissionais de tecnologia sempre fizeram:

compreender os sistemas, identificar riscos e construir soluções mais confiáveis.

Porque, no mundo real, a melhor transmutação é aquela que transforma informação em proteção antes que o desastre aconteça.


☕ Bellacosa Mainframe — Onde o COBOL encontra a História, a Cibersegurança e a Cultura Pop.

"O verdadeiro legado não está na idade do código, mas no conhecimento que nos permite mantê-lo seguro."

Fontes e referências para aprofundamento

  • Reuters, 2 a 4 de novembro de 2026 — Cobertura dos incidentes europeus, investigação e riscos de sistemas industriais conectados.

  • Associated Press, 2 e 3 de novembro de 2026 — Reportagens sobre supermercados afetados, temperaturas anormais e tecnologias de refrigeração.

  • AFP e Euronews, 2 e 3 de novembro de 2026 — Países atingidos, declarações das redes comerciais e ocorrências em Portugal.

  • Le Monde, 13 de outubro de 2026 — Investigação dos primeiros ataques em supermercados franceses.

  • BleepingComputer, 2 de novembro de 2026 — Análise dos incidentes e dos estabelecimentos afetados.

  • NIST SP 800-82 Rev. 3 — Guide to Operational Technology (OT) Security, referência para segurança de sistemas de tecnologia operacional.

Nota editorial: os acontecimentos e declarações jornalísticas foram verificados até 4 de novembro de 2026. Os diálogos de Edward e Alphonse Elric são ficcionais, utilizados exclusivamente como recurso didático. Os exemplos COBOL e JCL representam laboratórios educativos e não devem ser utilizados como sistemas de segurança física sem projeto, validação e certificação apropriados.

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