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

quarta-feira, 9 de setembro de 2026

🕵️‍♂️ O Supermosaico — Segurança da Informação sob a Tutela do Dr. Moriarty

 

Bellacosa Mainframe e o mosaico da segurança os riscos ocultos na ia

☕ Um Café no Bellacosa Mainframe

🕵️‍♂️ O Supermosaico — Segurança da Informação sob a Tutela do Dr. Moriarty

Quando nossos prompts começaram a guardar aquilo que nossa memória deveria esquecer

Imagine uma grande empresa.

Na porta existem seguranças.

Nos computadores, EDR.

Na rede, firewalls.

Nos acessos, MFA.

No mainframe, RACF.

Nos datasets, permissões.

Nos repositórios, controles.

Nos notebooks, DLP.

Nos servidores, logs.

No SOC, dezenas de telas piscando.

Tudo parece protegido.

Então o Dr. Moriarty entra em nossa sala, observa silenciosamente durante alguns minutos e faz uma pergunta desagradavelmente simples:

“Muito interessante. Mas onde seus funcionários conversam quando precisam pensar?”

Silêncio.

Bem-vindo à segurança da informação na era da Inteligência Artificial.



☕ Sob a tutela do Dr. Moriarty

Nossa história começou com uma questão aparentemente simples: profissionais utilizando Inteligência Artificial generativa para trabalhar.

Um advogado coloca partes de um processo em um prompt.

Um programador pergunta sobre um erro COBOL.

Um analista cola algumas mensagens de um dump.

Um DBA tenta entender determinada query.

Um especialista CICS pergunta sobre uma transação problemática.

Um consultor solicita ajuda para documentar uma arquitetura.

Nada disso precisa nascer de má-fé.



Pelo contrário.

O objetivo normalmente é trabalhar melhor.

Esse é justamente o ponto inquietante.

O artigo que motivou esta reflexão chama atenção para o fato de que informações de terceiros podem ser transferidas para sistemas externos durante o uso aparentemente cotidiano de IA e utiliza como exemplo conhecido os incidentes de 2023 envolvendo funcionários da Samsung e informações corporativas inseridas no ChatGPT.

A discussão original concentra-se principalmente em advocacia, sigilo profissional, proteção de dados e governança.

Mas vamos colocar nossa xícara de café sobre a mesa e levar o problema para dentro de uma instalação mainframe.

Moriarty está esperando.



🧩 A primeira tessela

Imagine um jovem programador COBOL.

Ele recebe:

ABEND S0C7

Abre sua ferramenta favorita de IA e pergunta:

Tenho um programa COBOL apresentando S0C7.

O erro acontece nesta rotina.

Pode me ajudar?

Perfeitamente razoável.

A IA pede contexto.

Nosso programador fornece algumas linhas.

Depois mais algumas.

Aparece o nome de um programa.

Depois uma tabela.

Uma transação.

Uma mensagem CICS.

Nada parece particularmente importante.

Temos nossa primeira tessela.

Uma pequena pedra quadrangular daqueles magníficos mosaicos romanos.

Sozinha, ela significa quase nada.



🏛️ O mosaico romano

Na semana seguinte:

TRANID = ABC1

Outra tessela.

Meses depois:

PROGRAM = PAY001

Outra.

Mais tarde:

PAY001 atualiza DB2 antes do MQPUT.

Outra.

Em dezembro:

A fila PAYMENT.REQUEST cresce
durante o fechamento mensal.

Outra.

No ano seguinte:

ABC1 chama PAY001.

Agora coloque as pedras juntas:

ABC1
 │
 ▼
PAY001
 │
 ├────► DB2
 │
 ▼
MQPUT
 │
 ▼
PAYMENT.REQUEST

Curioso.

Nenhum prompt individual descreveu necessariamente toda a arquitetura.

Mas a arquitetura começa a aparecer pela correlação.

Essa é nossa primeira grande lição sob a tutela de Moriarty:

Informações aparentemente insignificantes podem adquirir enorme valor quando possuem relacionamentos.


🧠 O analista começa a documentar a empresa sem perceber

Passemos três anos.

Nosso programador virou analista.

Ele utilizou IA milhares de vezes.

Perguntou sobre:

  • COBOL;

  • JCL;

  • CICS;

  • Db2;

  • MQ;

  • VSAM;

  • RACF;

  • APIs;

  • incidentes;

  • dumps;

  • arquitetura;

  • regras de negócio;

  • migrações;

  • problemas de produção.

Mas existe uma característica interessante.

Normalmente perguntamos à IA justamente sobre aquilo que não entendemos.

Consequentemente, nosso histórico pode acabar concentrando momentos excepcionais:

ERRO
 ↓
DÚVIDA
 ↓
PROMPT

INCIDENTE
 ↓
DÚVIDA
 ↓
PROMPT

ARQUITETURA ESTRANHA
 ↓
DÚVIDA
 ↓
PROMPT

EXCEÇÃO DE NEGÓCIO
 ↓
DÚVIDA
 ↓
PROMPT

O histórico não é necessariamente uma amostra aleatória do ambiente.

Pode ser uma coleção justamente das coisas estranhas, difíceis ou importantes.

Quase um diário operacional involuntário.


📖 “Querido diário, produção caiu novamente...”

Imagine encontrar uma conversa antiga:

“Por que essa rotina precisa executar antes das 22 horas?”

Outra:

“Por que não podemos alterar esse campo?”

Outra:

“Esse programa existe desde a aquisição da empresa XPTO.”

Outra:

“Quando o sistema secundário está indisponível usamos esta contingência.”

Perceba que estamos gradualmente deixando de falar somente de código.

Estamos falando de:

contexto.

E contexto frequentemente vale mais do que código.

Um programa COBOL pode dizer:

IF WS-STATUS = '99'
    PERFORM 9000-CONTINGENCIA
END-IF.

Mas talvez não explique por que 99 existe.

O veterano explica:

“Isso foi criado depois daquele problema de 2008 porque o sistema externo ficava indisponível no fechamento.”

Pronto.

Temos história.

Temos arquitetura.

Temos dependência.

Temos regra operacional.

Temos conhecimento institucional.


🧓 O veterano pode ser mais interessante que o administrador

Aqui Moriarty levanta a sobrancelha.

Tradicionalmente pensamos:

“Quem possui maior privilégio?”

Administrador.

RACF SPECIAL.

DBA.

SYSADM.

ROOT.

Mas existe outra espécie de privilégio:

Knowledge Privilege.

Talvez aquele veterano não possua RACF SPECIAL.

Entretanto ele sabe:

por que X depende de Y;

quem resolve determinado incidente;

qual sistema não pode parar;

qual processo possui contingência;

quais componentes são antigos;

onde existem dependências históricas;

por que determinada decisão foi tomada;

quais problemas aparecem no fechamento.

O usuário privilegiado possui Access Privilege.

O veterano possui Knowledge Privilege.

Em alguns cenários de ameaça, precisamos proteger ambos.


🕰️ Janeiro de 2023

Agora chegamos a uma coisa extraordinária.

O ser humano esquece.

Imagine que nosso especialista tenha resolvido um incidente em janeiro de 2023.

Em setembro de 2026 alguém pergunta:

“Você lembra daquele problema?”

Provavelmente:

“Mais ou menos...”

Depois:

“Não lembro exatamente.”

Isso sempre foi uma espécie de deterioração natural da informação.

Mas imagine que naquele janeiro ele tenha escrito uma longa conversa com uma IA.

Dependendo do serviço, das configurações e das políticas de retenção, aquela conversa poderá ter permanecido armazenada.

Então temos:

MEMÓRIA HUMANA

evento
  ↓
tempo
  ↓
degradação
  ↓
abstração
  ↓
esquecimento

contra:

REGISTRO DIGITAL

evento
  ↓
texto
  ↓
armazenamento
  ↓
pesquisa
  ↓
recuperação

Aquilo que o cérebro deveria esquecer pode permanecer registrado.

Chamemos isso de:

Knowledge Residue

Resíduo de conhecimento.


🚪 O funcionário desligado

Agora Moriarty apresenta outro personagem.

Durante três anos nosso funcionário trabalhou normalmente.

Não roubou nada.

Não planejou fraude.

Não tentou prejudicar ninguém.

Então foi demitido.

Ficou ressentido.

No modelo tradicional de insider threat, talvez esperássemos observar:

download enorme;
cópia para USB;
upload suspeito;
e-mail externo;
ZIP com sources;
impressões anormais.

Mas surge uma possibilidade diferente.

E se informações inadequadamente compartilhadas já estivessem acumuladas em ambientes externos antes de aparecer a intenção maliciosa?

O problema fundamental torna-se:

o momento da aquisição da informação pode estar separado por anos do momento em que aparece a intenção de abusar dela.

No desligamento fazemos:

REVOKE RACF
REMOVE VPN
DISABLE EMAIL
DISABLE GITHUB
RETURN NOTEBOOK
RETURN BADGE
REVOKE CERTIFICATES

Excelente.

Mas Moriarty pergunta:

“E a memória digital externalizada anteriormente?”

É uma pergunta de governança, não uma justificativa para investigar indiscriminadamente contas pessoais de ex-funcionários.

A resposta precisa começar antes, com ferramentas corporativas apropriadas, separação de identidades, classificação, políticas de retenção e regras claras sobre aquilo que pode ser fornecido a sistemas de IA.


🎒 Chega o consultor

Moriarty sorri.

O funcionário conhece uma empresa.

O consultor conhece muitas.

Imagine:

2023 → Banco A
2024 → Seguradora B
2024 → Varejista C
2025 → Governo D
2025 → Montadora E
2026 → Banco F

Em cada organização ele aprende.

Essa transferência de experiência é perfeitamente normal.

Aliás, contratamos consultores justamente porque podem dizer:

“Já encontrei um problema semelhante.”

Existe, entretanto, diferença enorme entre carregar experiência profissional e carregar artefatos detalhados de conhecimento de clientes anteriores.

Historicamente, o cérebro fornecia uma abstração interessante:

experiência específica
       ↓
      tempo
       ↓
   esquecimento
       ↓
   abstração
       ↓
 conhecimento geral

O consultor esquecia nomes, valores, incidentes e detalhes.

Mas permanecia sabendo:

“Esse tipo de arquitetura costuma apresentar este problema.”

Excelente.

Isso é experiência.

Agora imaginemos uma conta pessoal ou ambiente inadequadamente segregado contendo conversas detalhadas provenientes de sucessivos projetos.

Temos potencialmente:

CLIENTE A ─┐
CLIENTE B ─┤
CLIENTE C ─┤
CLIENTE D ─┼──► CORPUS
CLIENTE E ─┤
CLIENTE F ─┘

Nasce nosso:

SUPERMOSAICO.


🌎 O Supermosaico

O mosaico permite reconstruir aspectos de uma empresa.

O Supermosaico acrescenta algo diferente:

comparação.

Cliente A faz X.

Cliente B utiliza X + Y.

Cliente C abandonou X depois de determinado problema.

Cliente D acrescentou Z.

Nenhuma dessas informações isoladamente precisa declarar:

“A possui uma deficiência.”

Mas a comparação pode produzir uma hipótese:

“Por que A aparentemente não possui Y ou Z?”

Nasceu informação que não estava explicitamente escrita.

Temos:

INFORMAÇÃO A
+
INFORMAÇÃO B
+
INFORMAÇÃO C
+
CONTEXTO
+
CORRELAÇÃO
=
INFORMAÇÃO DERIVADA

Esse é um dos pontos mais importantes desta história.

Precisamos proteger não somente informações sensíveis individualmente, mas pensar também em informações correlacionáveis.


🕵️ Moriarty finalmente começa sua aula

Até aqui Moriarty permaneceu sentado.

Agora ele se levanta.

Ele não pergunta:

“Onde está SECRET.DOC?”

Pergunta:

“O que posso inferir?”

Essa é uma mudança monumental.

O invasor caricatural procura:

PASSWORD.TXT

Moriarty procura:

relações;
padrões;
cronologia;
contradições;
dependências;
mudanças;
exceções;
incertezas.

Porque informação de inteligência não precisa estar escrita diretamente.

Ela pode surgir da combinação.


📧 Gmail, Drive, GitHub, WhatsApp, Telegram, celular...

Nossa identidade digital moderna está espalhada.

Temos:

e-mail pessoal
e-mail corporativo
GitHub
Google Drive
OneDrive
celular
notebook
micro pessoal
WhatsApp
Telegram
calendário
redes sociais
conta de IA

Antigamente imaginávamos segurança como uma muralha:

        FIREWALL
████████████████████████
       EMPRESA

Hoje precisamos imaginá-la como um grafo:

          PESSOA
        /   |    \
       /    |     \
   Gmail  GitHub  IA
     |      |      |
   Drive   código contexto
     \      |      /
       \    |     /
         CELULAR
            |
        IDENTIDADE
            |
         EMPRESA

Moriarty não precisa necessariamente perguntar:

“Como atravesso a muralha?”

Ele pode perguntar:

“Quais relações chegam até ela?”

Essa é uma excelente maneira defensiva de fazer threat modeling.


🏰 Primeiro o sentinela

Imagine um castelo.

Atacar diretamente o rei é difícil.

Então nosso Moriarty hipotético observa:

SENTINELA
    ↓
CAPITÃO
    ↓
OFICIAL
    ↓
CONSELHEIRO
    ↓
CASTELO

No mundo corporativo:

JÚNIOR
  ↓
N2
  ↓
N3
  ↓
SME
  ↓
ARQUITETO

Isso não significa que essa sequência permita comprometimento automático.

Não permite.

Mas mostra algo importante:

confiança também possui topologia.

Um funcionário confia em outro.

Uma identidade possui recuperação ligada a outra.

Um dispositivo possui sessões.

Um serviço contém referências a outros serviços.

Um calendário revela relacionamentos.

Um repositório revela tecnologias.

Precisamos analisar o blast radius de identidades, não somente permissões técnicas.


🔐 RACF emocional

Aqui nosso jovem COBOL finalmente entende Moriarty.

No RACF temos algo parecido com:

USER
 ↓
GROUP
 ↓
CONNECT
 ↓
PERMIT
 ↓
RESOURCE

Uma identidade isolada diz pouco.

Os relacionamentos dizem muito.

Agora aplique a mesma ideia à pessoa:

PESSOA
 ↓
IDENTIDADES
 ↓
DISPOSITIVOS
 ↓
SERVIÇOS
 ↓
SESSÕES
 ↓
DADOS
 ↓
RELACIONAMENTOS
 ↓
CONFIANÇA

Voilà!

Temos uma espécie de:

RACF da vida digital.

Só que muito menos organizado.


📦 Contrabando de conhecimento

Agora chegamos a outro conceito surgido durante nossa investigação.

Empresas procuram eventos grandes:

40 MB enviados por e-mail → ALERTA

ZIP com sources → ALERTA

USB → ALERTA

FTP → ALERTA

GitHub público → ALERTA

Enquanto isso:

prompt 001 → 2 KB
prompt 002 → 4 KB
prompt 003 → 1 KB
...
prompt 847 → 6 KB

Tudo pequeno.

Tudo aparentemente cotidiano.

Mas estamos confundindo:

volume físico

com

volume semântico.

Um especialista pode condensar vinte anos de experiência em três parágrafos.

Talvez sejam apenas 5 KB.

Semanticamente podem valer muito.

Por isso “contrabando de conhecimento” é uma excelente metáfora, embora em governança eu preferisse termos como:

transferência de conhecimento não governada

ou

canal cumulativo de exposição de conhecimento.

Porque nem todo prompt constitui exfiltração e nem todo usuário possui intenção indevida.


🛡️ DLP talvez não seja suficiente

Data Loss Prevention tradicionalmente pergunta:

“Que dado está saindo?”

Nosso problema exige outra pergunta:

“Que conhecimento está sendo construído pela soma daquilo que está saindo?”

Daí surge:

KLP — Knowledge Loss Prevention

Não estou propondo aqui um padrão formal universal chamado KLP.

Estou usando o termo como conceito para ampliar nossa maneira de pensar.

DLP:

PROTEJA O DADO

KLP:

PROTEJA:
dados
+
contexto
+
relações
+
acumulação
+
tempo
+
conhecimento derivável

Porque:

PROMPT 1 = VERDE
PROMPT 2 = VERDE
PROMPT 3 = VERDE

...

Σ PROMPTS = VERMELHO

O risco pode emergir da soma.


🐒 Um milhão de chimpanzés bebedores de saquê

É claro que nenhum tratado Bellacosa Mainframe estaria completo sem nossos agentes especiais.

Imagine um corpus contendo:

"Meu CICS conversa telepaticamente com Saturno."

"Verificar MQ amanhã."

"O gato assumiu RACF SPECIAL."

"Por que PAY001 apresenta S0C7?"

"Napoleão teria usado VSAM."

"Não esquecer daquele JOB."

"Um milhão de chimpanzés bebendo saquê
administram produção."

Um investigador humano provavelmente pediria transferência de departamento.

Mas não devemos considerar volume e ruído controles de segurança confiáveis.

Sistemas automatizados conseguem classificar conteúdo, encontrar recorrências e separar grandes quantidades de informação muito mais rapidamente que uma pessoa.

Além disso, existe uma vítima colateral.

Você.

Três anos depois abre a conversa e pergunta:

“Que porra eu quis dizer com isso?”

😂

A contrainteligência funcionou tão bem que derrotou o próprio autor.


🧠 Facebook, dados comportamentais e Moriarty

Agora ampliemos novamente a escala.

Redes sociais mostraram ao mundo o valor da correlação de enormes quantidades de dados comportamentais.

IA conversacional introduz uma diferença conceitualmente importante.

Nas redes sociais frequentemente observamos:

curtiu
clicou
assistiu
compartilhou
seguiu
comprou

e tentamos inferir alguma coisa.

Em conversas com IA o próprio usuário frequentemente fornece:

"meu problema é..."

"não entendo..."

"estou considerando..."

"tenho duas alternativas..."

"minha arquitetura funciona assim..."

"por que isso aconteceu?"

"qual opção você escolheria?"

Isso pode representar contexto cognitivo muito mais explícito.

Não devemos concluir daí que provedores estejam oferecendo conversas privadas para terceiros. Estamos construindo um modelo hipotético de ameaça.

Mas defensivamente precisamos perguntar:

Qual seria o impacto se determinado corpus conversacional fosse indevidamente exposto?

Essa pergunta basta.


🎭 Moriarty não quer apenas saber o que aconteceu

Nosso professor do crime imaginário está interessado também em:

incerteza.

Considere:

“Não sei se devemos migrar X para Y.”

Essa frase revela mais do que parece.

Ela sugere:

X existe.

Y é considerado.

há uma decisão pendente.

o autor participa da discussão.

existe incerteza.

Isso é extraordinariamente interessante para inteligência.

Não estamos observando somente uma decisão passada.

Estamos observando o espaço de possibilidades anterior à decisão.


⚖️ O advogado entra novamente na sala

Voltemos ao artigo original.

Ele argumenta que informações identificáveis de clientes merecem atenção especial e recomenda práticas como anonimização e ambientes apropriados para informações sensíveis.

Nosso Supermosaico acrescenta outra preocupação.

Um advogado pode registrar:

processo;
estratégia;
dúvidas;
hipóteses;
limites de negociação;
fragilidades percebidas;
possíveis argumentos.

Novamente, isso não significa que a contraparte consiga simplesmente acessar essas conversas.

Não consegue.

Seria necessário algum evento adicional de exposição, comprometimento ou falha de governança.

Mas o impacto potencial do corpus merece entrar no threat model.


⚔️ A assimetria computacional

Imagine:

ZÉ DA SILVA
     │
advogado pequeno
notebook
tempo limitado
     │
     VS
     │
MEGACORP S/A
     │
equipe jurídica
especialistas
bases jurídicas
engenharia
automação
análise documental
IA

IA pode democratizar recursos antes inacessíveis ao pequeno advogado.

Isso é excelente.

Mas também pode industrializar capacidades de grandes organizações.

Temos duas forças simultâneas:

IA → DEMOCRATIZAÇÃO

IA → CONCENTRAÇÃO

Qual vencerá?

Provavelmente dependerá de acesso, custo, regulação, educação e governança.


🛡️ Como derrotar Moriarty sem abandonar IA

A resposta não é:

“Proibam tudo!”

Isso desperdiçaria uma tecnologia extraordinariamente útil.

O próprio artigo que iniciou nossa reflexão defende uma abordagem de governança em vez da simples interrupção do uso da IA.

Precisamos tornar Moriarty caro.

1. Separar identidades

PESSOAL ≠ PROFISSIONAL

2. Separar clientes

CLIENTE A ≠ CLIENTE B

3. Separar projetos

Não criar desnecessariamente um Supermosaico.

4. Minimizar

Pergunte:

“A IA realmente precisa saber isso?”

5. Sanitizar

Troque:

BANCO-REAL-XYZ

por:

CLIENTE-A

quando o detalhe real não for necessário.

6. Remover segredos

Tokens, credenciais, dados pessoais, dumps completos e informações confidenciais não devem passear livremente por prompts.

7. Governar retenção

A organização precisa saber onde conversas corporativas ficam e qual é seu ciclo de vida.

8. Governar consultores

A política precisa alcançar terceiros adequadamente, não somente empregados.

9. Pensar cumulativamente

Pergunte não apenas:

“Este prompt é perigoso?”

mas:

“O que cem prompts como este revelariam?”

10. Modelar Knowledge Privilege

Identifique não apenas quem possui grandes permissões.

Identifique funções que possuem enorme contexto institucional.


🔬 Um Red Team diferente

Podemos testar tudo isso sem atacar ninguém.

Crie uma empresa fictícia.

Um banco chamado:

BANCO MORIARTY S/A

Crie:

Carlos — N3 CICS
Maria — DBA
João — arquiteto
Ana — consultora
Watson — segurança

Produza informações sintéticas.

Simule um ano de prompts permitidos.

Depois entregue somente esse corpus para outro time autorizado e pergunte:

“O que vocês conseguem reconstruir sobre nossa empresa fictícia?”

Arquitetura?

Dependências?

Pessoas?

Sistemas críticos?

Cronologia?

Regras de negócio?

Tecnologias?

Incidentes?

Se o resultado for surpreendentemente detalhado, encontramos uma deficiência de governança sem comprometer uma única empresa real.

Esse seria um belíssimo exercício de Red Team de conhecimento.


🕒 03:17 — O incidente

Às 03:17 da madrugada, o telefone toca.

Produção está normal.

Nenhum dataset foi copiado.

Nenhum usuário RACF utilizou SPECIAL.

Nenhum arquivo de 40 GB saiu pela rede.

Nenhum pendrive apareceu.

Nenhum source foi publicado.

Nenhum alarme tradicional disparou.

Watson olha para Moriarty:

“Então não houve incidente?”

Moriarty toma tranquilamente seu café.

“Meu caro Watson... você ainda está procurando o arquivo.”

Sobre a mesa existem 12.847 pequenas tesselas.

Uma transação aqui.

Uma regra ali.

Um incidente acolá.

Uma decisão arquitetural.

Uma dependência.

Um fornecedor.

Uma exceção.

Uma dúvida.

Uma história de vinte anos resumida por alguém em cinco linhas.

Watson começa a juntar as pedras.

A figura aparece.

Não existe MEGACORP-SECRETS.ZIP.

Nunca existiu.

Existe algo potencialmente muito mais interessante:

conhecimento.


☕ A última lição do Dr. Moriarty

Durante décadas construímos excelentes mecanismos para responder:

Quem pode acessar este dado?

RACF responde isso maravilhosamente no mainframe.

IAM responde.

PAM responde.

ACL responde.

MFA ajuda.

Zero Trust ajuda.

DLP ajuda.

Mas IA nos obriga a acrescentar novas perguntas:

Quem pode externalizar esse conhecimento?

Quanto contexto pode ser acumulado ao longo do tempo?

Que informação aparentemente inocente se torna sensível quando correlacionada?

Onde termina experiência profissional e começa memória corporativa portátil?

O que acontece com o corpus depois que o funcionário ou consultor deixa a organização?

Qual é o blast radius do comprometimento de uma identidade que possui anos de conversas profissionais?

E principalmente:

Estamos protegendo somente aquilo que nossos funcionários acessam ou também os lugares onde eles passaram a registrar aquilo que sabem?

Essa talvez seja uma das grandes discussões de segurança da era da Inteligência Artificial.

Não significa abandonar IA.

Significa amadurecer sua utilização.

O profissional que pergunta corretamente para uma IA pode produzir em minutos algo que anteriormente consumiria horas.

Isso é fantástico.

Mas justamente por querermos respostas melhores somos incentivados a fornecer mais contexto.

E contexto é conhecimento.

Conhecimento acumulado cria mosaicos.

Mosaicos correlacionados criam Supermosaicos.

Portanto, sob a tutela do Dr. Moriarty, terminamos com uma regra simples:

O maior segredo talvez não esteja em nenhuma tessela. O segredo pode ser a imagem que aparece quando alguém consegue juntar tesselas suficientes.

E Sherlock Holmes provavelmente acrescentaria:

“Proteja as pedras, Watson.”

Moriarty sorriria.

“Não. Proteja as relações entre elas.”

Bellacosa Mainframe — onde até um simples prompt pode acabar virando uma tessela no mosaico.

domingo, 6 de setembro de 2026

A Guilda dos Aventureiros Mainframe — Por Que Quase Não Existem Programadores Velhos no CPD?

Bellacosa Mainframe e os velhos aventureiros do CPD

Um Café no Bellacosa Mainframe

A Guilda dos Aventureiros Mainframe — Por Que Quase Não Existem Programadores Velhos no CPD?

Ou: como COBOL, Db2, CICS, cursos, certificações, horas extras, releases, burnout, boletos e um Ceifeiro Silencioso transformaram a carreira de TI numa dungeon em que sobreviver é apenas o começo

Existe uma coisa estranha nos animes de fantasia.

Entre numa Guilda dos Aventureiros.

Olhe ao redor.

Há guerreiros de vinte anos, arqueiras de dezoito, magos adolescentes, sacerdotisas jovens, aventureiros iniciantes carregando espadas maiores do que eles e meia dúzia de veteranos aparentemente na casa dos trinta.

Agora procure alguém com cinquenta anos.

Boa sorte.

Sessenta?

Talvez exista um velho Rank S sentado misteriosamente no fundo da taverna.

Mulheres com mais de cinquenta anos?

Em algumas aldeias parece que a população feminina passa diretamente dos 29 para os 78.

Isso sempre me deixou pensativo.

A princípio parece apenas uma convenção visual dos animes. Afinal, protagonistas jovens vendem mangá, figures e Blu-rays.

Mas existe outra possibilidade muito mais divertida — e assustadora.

Talvez aventureiros idosos sejam raros porque aventurar-se é uma profissão terrivelmente insalubre.

Você começa aos dezesseis anos.

Enfrenta goblins.

Depois orcs.

Depois trolls.

Depois dungeons.

Depois dragões.

No meio disso existem venenos, quedas, armadilhas, frio, fome, espadas, magia, infecções e monstros que aparentemente desenvolveram uma preferência gastronômica por aventureiros iniciantes.

Um único erro pode terminar a carreira.

Ou a vida.

Então comecei a imaginar a pirâmide profissional daquela Guilda.

Cem aventureiros entram.

Sessenta abandonam.

Vinte ficam incapacitados.

Quinze morrem.

Quatro encontram profissões mais sensatas.

Um chega aos cinquenta anos ainda carregando uma espada.

É justamente aquele sujeito grisalho sentado no canto da taverna que todos respeitam.

E então percebi algo.

Eu já conhecia essa Guilda.

Trabalhei nela durante décadas.

Só que não havia goblins.

Havia computadores.

Bem-vindo à Guilda dos Aventureiros Mainframe.



1. O jovem aventureiro recebe sua primeira espada

Todo programador começa aproximadamente da mesma maneira.

Você chega à empresa.

Recebe um crachá.

Um computador.

Algumas senhas.

E alguém lhe mostra o sistema.

Se for mainframe, aparecem diante dos seus olhos coisas como:

COBOL.

JCL.

TSO.

ISPF.

CICS.

Db2.

VSAM.

JES2.

SDSF.

Talvez IMS.

Talvez MQ.

Talvez RACF.

Você olha aquilo tudo como um aventureiro entrando pela primeira vez numa cidade gigantesca.

Os veteranos parecem magos.

Um programa apresenta S0C7.

Você ainda está tentando entender o que significa aquela sopa de letras quando um sujeito grisalho olha o dump e diz:

— Veja o offset.

Cinco minutos depois encontrou o problema.

Você pensa:

“Quero aprender a fazer isso.”

Parabéns.

Você acabou de aceitar sua primeira quest.


2. A primeira dungeon chama-se Produção

Nos primeiros anos tudo é novidade.

Cada incidente ensina alguma coisa.

Você descobre que aquilo que funcionava perfeitamente no ambiente de desenvolvimento pode desenvolver personalidade própria quando chega à produção.

Aprende sobre dados reais.

Volume real.

Concorrência.

Locks.

Timeouts.

Permissões.

Janelas de processamento.

Dependências.

Jobs.

Arquivos.

Filas.

Programas que chamam programas que chamam programas escritos por alguém que se aposentou quando você ainda usava Windows 95.

E então chega aquele momento iniciático da carreira:

o telefone toca de madrugada.

03:17.

Produção parou.

Nesse momento você deixa de ser apenas programador.

Você virou aventureiro.

A dungeon está aberta.



3. O problema é que monstros não respeitam horário comercial

O aventureiro dos animes trabalha em condições terríveis.

Caminha durante dias.

Dorme em florestas.

Carrega equipamento.

Enfrenta monstros.

Come quando consegue.

O consultor de tecnologia possui sua própria versão disso.

Horas extras.

Viradas de produção.

Fim de semana.

Feriado.

Implantação noturna.

Conference call internacional.

Incidente.

War room.

Mudança emergencial.

Telefone durante jantar.

Notebook durante férias.

Depois de alguns anos aparecem as marcas da batalha.

Tendinite.

Dor nas costas.

Problemas de sono.

Estresse.

Exaustão.

Ansiedade antes de determinadas implantações.

E, em situações mais graves, burnout.

Não existe espada atravessando sua armadura.

Mas o corpo mantém um log próprio.

E esse log também acumula eventos.



4. Onde estão os aventureiros de cinquenta anos?

Aqui surge a pergunta que iniciou toda esta reflexão.

Você entra em determinadas empresas e encontra equipes extraordinariamente jovens.

Isso pode parecer maravilhoso.

“Que empresa moderna!”

“Que equipe dinâmica!”

“Quanto talento jovem!”

Tudo verdade.

Mas existe outra pergunta possível:

Onde estão os profissionais que estavam aqui vinte anos atrás?

Onde está o programador COBOL que conhecia aquele sistema inteiro?

Onde está a especialista em Db2?

Onde foi parar aquele administrador CICS?

E aquele sujeito que conhecia IMS como se tivesse ajudado a escrever o produto?

Alguns se aposentaram.

Outros mudaram de carreira.

Alguns viraram gestores.

Outros fornecedores.

Muitos passaram a trabalhar como consultores.

E alguns conheceram uma criatura peculiar do universo corporativo.

Eu a chamo de:

O Ceifeiro Silencioso.


5. O Ceifeiro dos Salários Altos

Ele não usa manto preto.

Não carrega foice.

Carrega Excel.

Às vezes PowerPoint.

Sua apresentação geralmente possui algum título como:

Workforce Optimization Initiative

ou:

Operational Efficiency Program

Ele entra silenciosamente no CPD.

Não vê João, especialista em CICS com vinte e cinco anos de experiência.

Vê:

RESOURCE 8472 — HIGH COST

Não vê Maria, que sabe por que determinado batch não pode executar antes das 23:40.

Vê:

SENIOR RESOURCE

Não vê Carlos, uma das três pessoas que sabem recuperar determinado subsistema depois de uma falha específica.

Vê:

ANNUAL COST: $$$$

E então surge a pergunta fatal:

— Por que estamos pagando tanto para uma pessoa?

Alguém responde:

— Porque ele possui vinte e cinco anos de experiência.

Então a planilha realiza sua magia:

1 especialista = 3 profissionais iniciantes pelo mesmo custo.

Pronto.

Nasceram três aventureiros Rank D.

E o Rank A desapareceu da Guilda.


6. Três juniores não são necessariamente um senior

Isso precisa ser dito com cuidado.

Todo senior já foi junior.

Profissionais jovens precisam receber oportunidades.

Precisamos formar novas gerações.

O problema não está nisso.

O erro está em imaginar que conhecimento profissional funciona como memória RAM.

Se preciso de 32 GB, posso colocar quatro módulos de 8 GB.

Experiência não funciona assim.

3 × Junior ≠ 1 × Senior

Às vezes:

10 × Junior ≠ 1 × Senior

Não porque os dez sejam incapazes.

Mas porque o veterano possui uma coisa extremamente difícil de medir:

contexto acumulado.

Ele sabe que aquele programa estranho existe porque uma legislação mudou em 1998.

Foi alterado novamente em 2005.

Recebeu integração em 2011.

Foi remendado durante uma crise em 2017.

E continua daquele jeito porque outro sistema ainda depende daquela estrutura.

O jovem olha o código e pergunta:

— Por que isso existe?

O veterano responde:

— Não mexe.

— Por quê?

— Mexemos uma vez em 2014.

— E?

— Parou faturamento.

Isso parece superstição.

Muitas vezes é arqueologia corporativa.


7. O veterano não sabe apenas matar monstros

Num mundo de fantasia, um aventureiro de sessenta anos deveria valer uma fortuna.

Não porque ainda consiga correr mais rápido que o guerreiro de vinte.

Mas porque sabe coisas que o jovem ainda precisa descobrir.

O jovem pergunta:

— Que espada devemos levar?

O veterano responde:

— Nenhuma.

— Como assim?

— Choveu três dias. A dungeon alaga pelo oeste. Os kobolds vão migrar para o segundo nível. Voltamos terça-feira.

Isso é experiência.

No CPD acontece a mesma coisa.

O jovem possui dez ferramentas modernas abertas.

O veterano olha o horário do incidente e diz:

— Isso não é Db2.

— Como sabe?

— O batch começou enquanto CICS ainda estava segurando aquele recurso.

Ele reconheceu o padrão.

Experiência profissional é, em grande parte, uma gigantesca biblioteca interna de padrões.


8. Só que o aventureiro precisa pagar pela própria espada

Existe outra semelhança cruel.

Aventureiros aparentemente ganham muito dinheiro.

Matam monstros.

Recebem recompensas.

Encontram tesouros.

Vendem materiais raros.

Mas continuam vivendo modestamente.

Por quê?

Porque faturamento não é lucro.

Recebeu 1.000 moedas.

Gastou 200 em poções.

150 reparando armadura.

100 afiando espada.

120 em hospedagem.

80 em transporte.

100 em comida.

150 substituindo equipamento destruído.

Sobrou pouco.

O aventureiro descobriu fluxo de caixa.

O profissional de tecnologia também.

Só que seu equipamento possui outra natureza.

Curso.

Livro.

Laboratório.

Certificação.

Webinar.

Evento.

Assinatura.

Computador.

Internet.

Cloud.

Software.

Idioma estrangeiro.

E sobretudo:

tempo.


9. Curso gratuito não significa custo zero

Essa é uma das grandes ilusões da educação profissional.

“Curso gratuito!”

Excelente.

Duração:

40 horas.

Então ele não custa zero.

Custa quarenta horas da sua vida.

Quarenta horas que poderiam ser usadas dormindo.

Caminhando.

Conversando.

Viajando.

Lendo.

Ou realizando aquela atividade cultural extremamente importante para a manutenção psicológica do profissional mainframe:

assistir anime.

O verdadeiro custo de uma formação não é apenas financeiro.

Existe custo de oportunidade.

Depois de determinada idade, começamos a perguntar menos:

“Quanto custa este curso?”

e mais:

“Isso vale vinte horas da minha vida?”

Essa pergunta é muito mais importante.


10. XP não garante promoção

Nos RPGs existe uma lógica maravilhosa:

XP aumenta.

Level aumenta.

Skills aumentam.

Rank aumenta.

Recompensa aumenta.

Na vida corporativa:

XP aumenta.

Certificações aumentam.

Responsabilidade aumenta.

Skills aumentam.

Conhecimento aumenta.

A empresa responde:

— Excelente trabalho!

Você espera.

— Continue assim!

Você continua esperando.

— Vamos discutir oportunidades no próximo ciclo.

E o salário permanece observando tudo de longe.

Esse é um problema interessante da carreira tecnológica:

o crescimento do conhecimento não possui relação linear com o crescimento da remuneração.

Você pode estudar duzentas horas durante um ano e receber exatamente o mesmo salário.

O conhecimento possui valor.

Aumenta empregabilidade.

Aumenta capacidade.

Pode aumentar poder de negociação.

Mas a conversão em dinheiro não acontece automaticamente.


11. Skill Inflation — o monstro que cresce junto com você

Quando comecei, uma determinada vaga poderia pedir algumas tecnologias.

Com o passar dos anos, a lista foi crescendo.

COBOL.

JCL.

CICS.

Db2.

VSAM.

Depois MQ.

RACF.

APIs.

REST.

Git.

CI/CD.

Java.

Python.

Cloud.

DevOps.

OpenShift.

Containers.

Observabilidade.

Segurança.

Agile.

Agora IA.

E inglês.

Naturalmente.

A profissão desenvolveu uma espécie de inflação de habilidades.

Aquilo que ontem era diferencial hoje virou requisito.

O que hoje é diferencial amanhã aparecerá discretamente na vaga como:

“conhecimento desejável”.

Depois:

“conhecimento obrigatório”.

A Guilda continua adicionando skills necessárias.

Só esqueceu de aumentar proporcionalmente a recompensa das quests.


12. A esteira tecnológica anda para trás

Existe uma crueldade particular na tecnologia.

Parte do conhecimento acumula.

Parte envelhece.

Alguns fundamentos permanecem valiosos durante décadas:

lógica;

algoritmos;

arquitetura;

modelagem;

transações;

concorrência;

segurança;

debugging;

sistemas operacionais;

bancos de dados;

análise de problemas.

Mas ferramentas mudam.

Versões mudam.

Interfaces mudam.

Produtos mudam.

Menus mudam.

E finalmente acontece aquela experiência maravilhosa.

Você abre uma ferramenta que conhece há dez anos.

Houve atualização.

Olha a tela.

E pensa:

“Onde colocaram essa porcaria?”


13. “Eu sei fazer isso!”

Essa frase merece atenção.

Você sabe fazer.

Realmente sabe.

Só não sabe mais onde fazer.

Antes:

Settings > Security > Authentication

Depois:

Workspace > Identity > Access > Advanced

Seu conhecimento não desapareceu.

Seu mapa desapareceu.

É como voltar para uma cidade onde você morou vinte anos antes.

Você conhece o destino.

Mas construíram viadutos.

Mudaram ruas.

Alteraram sentidos.

Transferiram a estação.

Você não desaprendeu a dirigir.

O território mudou.

E UI/UX consegue produzir no especialista uma sensação extremamente desagradável:

sentir-se iniciante numa atividade que domina.


14. Conhecimento possui meia-vida

Por isso gosto de separar conhecimento profissional em camadas.

Conhecimento fundamental

Algoritmos, arquitetura, lógica, debugging, transações, concorrência.

Possui longa duração.

Conhecimento de ecossistema

COBOL, Db2, CICS, IMS, MQ, Java, Python.

Muda, mas mantém continuidade conceitual.

Conhecimento de versão

“Na versão X esta configuração funciona desta maneira.”

Envelhece mais rápido.

Conhecimento de interface

“Clique no terceiro botão da esquerda.”

Esse pode morrer amanhã de manhã.

O erro é gastar energia demais memorizando conhecimento altamente perecível como se fosse fundamento.


15. A skill Rank S: reaprender

Depois de décadas, acontece algo curioso.

Você percebe que jamais conseguirá saber tudo.

E para de tentar.

Em compensação desenvolve uma habilidade extraordinária:

aprender novamente muito rápido.

Diante de uma ferramenta nova, o veterano começa fazendo perguntas conhecidas.

Onde estão os logs?

Como autentica?

Onde ficam permissões?

Como configura?

Existe CLI?

Existe API?

Como exporta?

Como automatiza?

Onde está a documentação?

O produto mudou.

As perguntas fundamentais não.

E saber quais perguntas fazer é uma forma sofisticada de conhecimento.


16. O eterno DLC chamado inglês

Então você decide estudar tecnologia.

Descobre que grande parte da documentação está em inglês.

Os melhores webinars aparecem em inglês.

Conferências internacionais usam inglês.

Fóruns técnicos usam inglês.

Manuais usam inglês.

Cursos usam inglês.

Você queria aprender COBOL.

Descobriu uma dependência:

COBOL REQUIRES ENGLISH

Então investe centenas ou milhares de horas aprendendo outro idioma.

E depois de anos aparece uma vaga:

English required.

Todo aquele esforço virou uma linha.

A Guilda considera simplesmente que você deveria possuir aquela skill.


17. O Ceifeiro volta

Depois de décadas estudando, trabalhando e sobrevivendo a produções, acontece algo irônico.

Seu salário finalmente ficou alto.

Porque você acumulou experiência.

E justamente por ter ficado alto...

chama atenção.

O Ceifeiro Silencioso retorna.

Olha a planilha.

Olha seu salário.

Olha novamente a planilha.

A foice começa a brilhar.


18. O nascimento do mercenário mainframe

O especialista deixa a grande empresa.

Mas existe um problema.

Ele possui uma criatura doméstica extremamente exigente.

Seu nome é:

BOLETO.

O verdadeiro Demon Lord.

Level 99.

Resistente a magia.

Imune a argumento.

E possui uma habilidade terrível:

Respawn mensal.

Então o veterano aceita outro projeto.

Seis meses.

Um ano.

Migração.

Upgrade.

Assessment.

Incidente.

Treinamento.

Conversão.

Modernização.

Ele virou mercenário.

Ou, usando terminologia empresarial:

consultor independente.


19. A ironia final

Alguns anos depois, a empresa percebe que perdeu determinado conhecimento.

Surge um projeto crítico.

Precisam urgentemente de alguém experiente.

Contratam uma grande consultoria.

A consultoria procura especialistas.

E encontra...

o mesmo sujeito dispensado anos antes.

Ele retorna.

Antes tinha crachá azul.

Agora possui crachá vermelho:

EXTERNAL CONSULTANT

Antes seu salário era considerado caro.

Agora sua hora custa três vezes mais.

Mas está em outro centro de custo.

Portanto:

aprovado.

Se isso não é roteiro de anime, não sei o que é.


20. O paradoxo do sistema que funciona

Existe ainda uma característica especialmente cruel de infraestrutura.

Quanto melhor funciona, menos visível fica seu valor.

Sistema cai semanalmente:

— Precisamos desses especialistas!

Especialistas trabalham.

Corrigem problemas.

Criam procedimentos.

Automatizam.

Estabilizam.

Cinco anos depois quase não existem incidentes.

Então alguém pergunta:

— Por que precisamos de tantos especialistas?

É extraordinário.

O aventureiro matou todos os monstros ao redor da aldeia.

Durante dez anos ninguém viu um goblin.

O prefeito conclui:

“Estamos desperdiçando dinheiro com aventureiros.”

Dispensa todos.

Dois anos depois aparece um dragão.

Nasce imediatamente:

Dragon Remediation Transformation Program

Orçamento: dez vezes maior.

Consultoria externa: contratada.

Prazo: ontem.


21. E finalmente chegamos ao sorriso ninja

Depois de décadas nessa profissão, surge uma cena recorrente.

Cliente:

— Você sabe fazer?

O veterano olha calmamente.

Sorri.

😎

— Sei.

Por dentro:

🦋🦋🦋🦋🦋

“Puta que pariu.”

Porque ele sabia perfeitamente fazer aquilo na versão anterior.

Agora existe release nova.

Interface nova.

Menus diferentes.

Funções renomeadas.

Documentação atualizada.

Talvez uma arquitetura parcialmente diferente.

Mas ele mantém o sorriso.

Não necessariamente porque conhece exatamente o caminho.

E certamente não porque seja irresponsável.

Existe algo mais profundo.

Ele pensa:

“Nunca fiz exatamente isso.”

E imediatamente:

“Mas já fiz quinze coisas parecidas.”

Essa é a diferença.


22. O veterano entra na dungeon

O monstro chama-se:

Enterprise Platform Ultimate Cloud AI Edition 2027.

Ele nunca viu aquela versão.

O monstro olha para ele.

Ele olha para o monstro.

🦋

Abre documentação.

🦋🦋

“Por que mudaram isso?”

Abre release notes.

🦋🦋🦋

“Claro. Deprecated.”

Encontra um manual de 684 páginas.

Café.

Laboratório.

Primeiro teste.

ERROR

— Interessante.

Segundo teste.

ERROR

— Muito interessante.

Terceiro teste.

SUCCESS

Silêncio.

Ele fecha 37 abas.

Volta para a reunião.

😎

— Como eu estava dizendo, podemos fazer.

Ninguém viu as borboletas.


23. Easter egg: o verdadeiro significado de Senior

Talvez senioridade nunca tenha significado:

“Eu sei tudo.”

Isso seria impossível.

Senioridade talvez seja:

“Já estive perdido vezes suficientes para saber que consigo encontrar o caminho.”

Essa diferença é gigantesca.

O iniciante teme não saber.

O veterano também não sabe algumas coisas.

Mas já aprendeu a funcionar dentro da incerteza.

Sabe pesquisar.

Testar.

Comparar.

Eliminar hipóteses.

Ler logs.

Criar laboratório.

Voltar atrás.

Perguntar.

Experimentar.

Errar pequeno antes de errar grande.

Essa talvez seja a maior skill adquirida depois de décadas trabalhando com tecnologia.


24. Então por que existem tão poucos aventureiros grisalhos?

Porque a carreira seleciona.

Alguns abandonam.

Alguns mudam.

Alguns viram gestores.

Alguns ensinam.

Alguns tornam-se arquitetos.

Alguns passam para fornecedores.

Alguns viram consultores.

Alguns são encontrados pelo Ceifeiro.

E alguns simplesmente decidem que já passaram noites demais acordados esperando um job terminar.

Os que permanecem carregam cicatrizes invisíveis.

Mas carregam também uma coisa extraordinariamente valiosa:

memória institucional.

Eles lembram monstros que já não existem.

Sabem por que determinadas muralhas foram construídas.

Reconhecem sinais que os demais ainda não aprenderam a observar.

São bibliotecas ambulantes de incidentes, soluções, fracassos e decisões.

Uma empresa inteligente não deveria perguntar apenas:

“Quanto custa esse profissional?”

Deveria perguntar:

“Quanto custa perder aquilo que somente ele sabe?”

São perguntas completamente diferentes.


Epílogo — 03:17

O telefone toca.

O jovem programador atende.

Produção está parada.

Ele olha os logs.

Não entende.

Tenta novamente.

Nada.

Ao lado existe um velho consultor tomando café.

— Posso perguntar uma coisa?

O veterano aproxima a cadeira.

Olha a tela durante alguns segundos.

— Quando começou?

— 02:46.

Ele sorri.

— Veja o job que executou às 02:45.

O jovem encontra.

Ali está.

O problema.

— Como você sabia?

O veterano pega novamente a caneca.

— Em 2009 aconteceu algo parecido.

Silêncio.

O jovem olha para ele como eu olhava para os veteranos quando comecei.

Talvez pense:

“Um dia quero saber tudo isso.”

Mas o veterano sabe de uma coisa que o jovem ainda descobrirá.

Nunca saberá tudo.

A dungeon continuará mudando.

Novos monstros aparecerão.

Novas releases serão instaladas.

Interfaces serão redesenhadas.

Skills ficarão obsoletas.

Cursos serão necessários.

Certificações vencerão.

O Ceifeiro continuará andando silenciosamente pelos corredores.

E o Boleto continuará ressuscitando todo mês.

O que resta ao aventureiro?

Continuar aprendendo.

Continuar curioso.

Ensinar aquilo que sabe.

Preservar os fundamentos.

Não confundir interface com conhecimento.

Não gastar a vida tentando decorar tudo.

E, principalmente, entender que experiência não é conhecer antecipadamente todas as respostas.

Experiência é saber o que fazer quando você não conhece a resposta.

O jovem fecha o incidente.

03:42.

— Resolvido.

O veterano levanta.

— Ótimo.

— Posso perguntar mais uma coisa?

— Claro.

— Quando o diretor perguntou se você sabia resolver isso... você já sabia?

O velho aventureiro para por alguns segundos.

Olha para o jovem.

Abre aquele sorriso ninja desenvolvido depois de décadas entrando em dungeons corporativas.

😎

— Claro que sabia.

E continua andando pelo corredor.

Enquanto, invisíveis para todos os outros...

🦋🦋🦋

...as últimas borboletas finalmente abandonam seu estômago.

Porque existe uma coisa que nenhum curso ensina e nenhuma certificação consegue medir:

o veterano não entra tranquilo na dungeon porque sabe o que encontrará.

Ele entra porque já voltou vivo de muitas outras.

Um Café no Bellacosa Mainframe

Onde todo programador é um aventureiro, toda produção é uma dungeon e todo boleto tem respawn automático.


segunda-feira, 10 de agosto de 2026

O Leilão Reverso do Conhecimento: quando o contrato fica mais barato e o COBOLzeiro sabe mais, mas recebe menos

Bellacosa Maifnrame e o leilão reverso do conhecimento

☕ Um Café no Bellacosa Mainframe

O Leilão Reverso do Conhecimento: quando o contrato fica mais barato e o COBOLzeiro sabe mais, mas recebe menos

🔴🔵 Matrix, procurement e o estranho mercado onde o fornecedor muda, o crachá muda, o salário diminui — mas o sistema, a responsabilidade e os boletos continuam exatamente no mesmo lugar

Por Vagner Bellacosa


Existe uma cena que se repete silenciosamente em muitas grandes organizações.

Não aparece em propaganda.

Não vira keynote.

Não rende vídeo institucional.

Não tem música épica.

Normalmente começa numa planilha.

Um contrato de prestação de serviços está chegando ao fim.

Do outro lado existe uma equipe.

Programadores.

Analistas.

DBAs.

Especialistas.

Arquitetos.

Gente que passou meses ou anos aprendendo aquele ambiente.

Mas o procurement olha para a linha:

CONTRATO ATUAL ............ R$ X
META DE REDUÇÃO ........... 10%

E alguém pergunta:

— Conseguimos fazer mais barato?

Provavelmente.

Sempre existe alguém disposto a oferecer alguma coisa mais barata.

Morpheus aparece novamente.

Na mão direita:

🔵 Pílula azul.

Na esquerda:

🔴 Pílula vermelha.

A azul diz:

Concorrência reduz custos.

A vermelha pergunta:

Qual custo foi reduzido?

Pegue seu café.

Hoje vamos entrar num andar muito interessante da Matrix corporativa.


🏦 O contrato está terminando

Imagine uma organização financeira fictícia.

Vamos chamá-la simplesmente de:

Banco Matrix.

Ela possui um grande contrato de desenvolvimento e manutenção de software com a Consultoria A.

Prazo:

12 meses.

Equipe:

40 profissionais.

No décimo mês começa o processo para o próximo período.

Tudo normal.

Contratos precisam ser renovados.

Fornecedores devem competir.

Procurement existe para negociar.

Custos precisam ser controlados.

Nada de errado até aqui.

Então surge uma condição:

O novo contrato precisa custar menos que o atual.

A Consultoria A faz as contas.

RECEITA PREVISTA
      -
SALÁRIOS
      -
ENCARGOS
      -
ESTRUTURA
      -
GESTÃO
      -
IMPOSTOS
      -
MARGEM
      =
NEGÓCIO VIÁVEL?

Resultado:

NÃO.

Ela decide não continuar.

Ou participa e perde.

Entra a Consultoria B.

Proposta vencedora.

Parabéns.

Economia prevista:

15%.

Procurement comemora.

Slides aparecem.

COST SAVING: 15%

Excelente.

Mas existe um pequeno problema.

Consultoria B ganhou o contrato.

Não ganhou automaticamente a equipe.


👻 Onde estão as pessoas?

A Consultoria B sabe vender.

Possui contrato.

Possui estrutura.

Talvez possua excelente capacidade de gestão.

Mas não necessariamente possui quarenta profissionais sentados esperando exatamente aquele projeto começar.

E muito menos quarenta profissionais que conhecem:

o sistema,

o negócio,

os incidentes,

a arquitetura,

os programas,

as exceções,

os usuários,

os horários críticos,

as dependências,

os atalhos,

as cicatrizes.

Então alguém tem uma ideia extraordinariamente lógica:

Vamos contratar a equipe que já está lá.

E começa a dança.


♻️ Novo CNPJ, mesmo COBOLzeiro

Sexta-feira:

CONSULTORIA A
STATUS = OUT

Segunda-feira:

CONSULTORIA B
STATUS = IN

Mas existe uma entidade que não recebeu o comunicado.

O mainframe.

O sistema continua exatamente onde estava.

PROGRAMA COBOL .......... IGUAL
JCL ..................... IGUAL
DB2 ..................... IGUAL
CICS .................... IGUAL
VSAM .................... IGUAL
INCIDENTES ............... IGUAIS
USUÁRIOS ................. IGUAIS
PRESSÃO .................. IGUAL

E de preferência:

PROFISSIONAL ............. O MESMO

Só existe um detalhe.

A proposta é menor.


📉 Você sabe mais. Então queremos pagar menos.

Vamos imaginar nosso personagem.

Chamaremos de Neo.

No início do contrato anterior ele conhecia bastante COBOL.

Depois de doze meses aprendeu:

mais sobre o banco,

mais sobre aquele sistema,

mais sobre regras de negócio,

mais sobre produção,

mais sobre incidentes,

mais sobre integrações,

mais sobre usuários,

mais sobre atalhos perigosos,

mais sobre coisas que não devem ser feitas.

Em termos de capital humano:

ANO 1
EXPERIÊNCIA = 100

ANO 2
EXPERIÊNCIA = 115

Agora chega a proposta:

REMUNERAÇÃO ANTERIOR = 100
REMUNERAÇÃO NOVA     = 88

Neo olha.

Volta a olhar.

Talvez tenha ocorrido um erro de arredondamento.

Não.

A matemática é exatamente essa.

CONHECIMENTO .......... +15%
REMUNERAÇÃO ........... -12%

Bem-vindo ao:

Leilão Reverso do Conhecimento


🔻 O que é o leilão reverso?

Num leilão tradicional, compradores disputam determinado bem e o preço tende a subir.

Aqui acontece algo diferente.

Fornecedores disputam o direito de prestar determinado serviço.

Cada um tenta oferecer uma proposta competitiva.

O preço pode cair.

Isso não é necessariamente ruim.

Concorrência pode eliminar ineficiência.

Pode reduzir margens excessivas.

Pode estimular automação.

Pode melhorar processos.

Pode beneficiar o cliente.

A pergunta começa depois:

de onde veio a redução?

Se veio de eficiência:

ótimo.

Se veio de melhor tecnologia:

ótimo.

Se veio de menor burocracia:

ótimo.

Se veio de melhor gestão:

ótimo.

Mas se veio simplesmente de:

MESMAS PESSOAS
+
MESMO TRABALHO
+
MESMA RESPONSABILIDADE
+
SALÁRIO MENOR

então não reduzimos necessariamente o custo da produção.

Talvez apenas tenhamos transferido parte dele.


💸 Quem pagou pelos 15%?

Essa é a pergunta central.

A organização anuncia:

ECONOMIA = 15%

Mas economia nunca surge do vácuo.

Alguma coisa deixou de receber aqueles 15%.

Pode ter sido:

margem,

estrutura,

benefícios,

treinamento,

qualidade,

senioridade,

retenção,

salário,

tempo,

folga operacional.

Ou um pouco de tudo.

Por isso talvez a pergunta correta não seja:

Quanto economizamos?

Mas:

onde nasceu a economia?

Porque existem economias que são eficiência.

E existem economias que são apenas transferência de custo.


👨‍💻 O profissional não participou da licitação

Isso é especialmente curioso.

Neo não sentou na mesa de negociação.

Não apresentou proposta comercial.

Não negociou margem.

Não prometeu redução.

Não assinou o contrato principal.

Mesmo assim pode terminar como variável de ajuste.

CLIENTE
   ↓
"PRECISAMOS DE -15%"
   ↓
CONSULTORIA
   ↓
"PRECISAMOS FECHAR A CONTA"
   ↓
FORNECEDOR
   ↓
"PRECISAMOS REDUZIR CUSTO"
   ↓
PROFISSIONAL
   ↓
"ACEITA -12%?"

O leilão aconteceu entre pessoas jurídicas.

A pressão terminou no CPF.

E o CPF possui um pequeno problema arquitetural.


🧾 O boleto não participa da licitação

Ele participa da decisão.

Apartamento.

Financiamento.

Escola.

Alimentação.

Impostos.

Plano de saúde.

Energia.

Água.

Internet.

Cartão.

Tudo continua chegando.

CONTRATO = TERMINADO

BOLETOS = CONTINUE

Essa talvez seja uma das melhores arquiteturas de alta disponibilidade já inventadas.

🤣

O boleto não possui janela de manutenção.

Não entra em freeze.

Não respeita mudança de fornecedor.

Ele simplesmente executa.


⚖️ “Mas ele pode recusar”

Sim.

Pode.

Essa é a pílula azul.

Ninguém necessariamente colocou uma arma na cabeça do profissional.

Existe uma proposta.

Ele pode aceitar.

Pode rejeitar.

Pode procurar outro emprego.

Correto.

Só que existe uma diferença importante entre:

liberdade formal

e

capacidade material de escolha.

Alguém com 18 meses de reserva financeira negocia de uma maneira.

Alguém com 15 dias negocia de outra.

PODER DE NEGOCIAÇÃO =
RESERVA
+ EMPREGABILIDADE
+ ALTERNATIVAS
+ TEMPO
- URGÊNCIA
- DÍVIDAS
- DEPENDENTES

A escolha continua existindo.

Mas seu peso muda.


🐸 Engolindo o sapo

Alguns aceitam.

Não porque gostaram.

Não porque concordaram.

Não porque acharam justo.

Aceitam porque precisam continuar recebendo.

E isso acrescenta uma variável que procurement dificilmente consegue colocar no Excel:

RESSENTIMENTO = ?

O profissional volta.

Mesmo prédio.

Mesmo andar.

Mesmo terminal.

Mesmo código.

Mesmo incidente.

Mas alguma coisa mudou.

Por dentro.


🧠 O contrato voltou. O vínculo não.

Antes:

CONFIANÇA .............. 100
ENGAJAMENTO ............ 100
VONTADE DE PERMANECER .. 100

Depois:

CONFIANÇA .............. 62
ENGAJAMENTO ............ 71
VONTADE DE PERMANECER .. 34
OPEN TO WORK ........... Y

Não existe ABEND.

Produção continua.

O dashboard fica verde.

Mas o sistema humano está degradado.

Isso é perigoso porque organizações medem muito bem aquilo que quebra imediatamente.

CPU.

Storage.

SLA.

Disponibilidade.

Chamados.

Prazo.

Muito mais difícil medir:

confiança,

pertencimento,

ressentimento,

desengajamento,

disposição de permanecer.

Essas coisas possuem latência.


🕒 O incidente emocional tem processamento batch

Ele não acontece necessariamente na hora.

O profissional aceita hoje.

Continua trabalhando.

Entrega.

Sorri na reunião.

Responde:

— Tudo bem.

Mas à noite atualiza o LinkedIn.

Responde ao recrutador.

Estuda outra tecnologia.

Liga para um antigo colega.

Começa silenciosamente a planejar saída.

JOB NAME: EXITPLAN

CLASS=A

STATUS=RUNNING

Três meses depois:

— Bom dia. Recebi uma proposta e vou sair.

Alguém pergunta:

— Mas ele não tinha aceitado ficar?

Tinha.

A empresa confundiu:

aceitação econômica

com

reconstrução de confiança.

São coisas completamente diferentes.


🚪 “Pense nisso como uma porta de entrada”

Agora chegamos a uma das frases mais curiosas do universo de recrutamento.

“No começo você ganha um pouco menos, mas pense nisso como uma porta de entrada. Depois você cresce.”

Pode ser verdade.

Existem organizações que realmente possuem carreira.

JÚNIOR
  ↓
PLENO
  ↓
SÊNIOR
  ↓
ESPECIALISTA
  ↓
ARQUITETO

Existe avaliação.

Existe orçamento.

Existe treinamento.

Existe promoção.

Existe mobilidade.

Existe retenção.

Nesse contexto, porta de entrada significa alguma coisa.

Mas existe outro modelo.

ENTRADA
  ↓
PROJETO 12 MESES
  ↓
RENOVA?
  ↓
TALVEZ
  ↓
TROCA FORNECEDOR?
  ↓
TALVEZ
  ↓
REALOCAMOS?
  ↓
TALVEZ
  ↓
CARREIRA?
  ↓
¯\_(ツ)_/¯

Nesse modelo, “porta de entrada” pode ser apenas retórica.


🚪 Entrada para onde?

Essa deveria ser a pergunta.

Você está entrando:

na empresa?

na carreira?

num programa de desenvolvimento?

numa estrutura de senioridade?

ou apenas:

num projeto?

Porque são coisas muito diferentes.

Se sua carreira desaparece quando o cliente troca de consultoria, talvez aquilo nunca tenha sido uma carreira.

Era uma alocação.

E alocação possui prazo.


📈 Promessa sem mecanismo não é plano de carreira

Se alguém disser:

“Aqui você pode crescer.”

Pergunte:

Como?

Quando?

Segundo quais critérios?

Quais níveis existem?

Qual a faixa salarial?

Quem aprova a promoção?

Quantas pessoas foram promovidas nesse contrato?

Existe orçamento?

Existe treinamento?

Se o contrato terminar, vocês me realocam?

Existe bench?

Existe programa de capacitação?

Existe sucessão?

Existe mentoria?

Existe alguma coisa mensurável além da promessa?

Porque:

PROMESSA
SEM
MECANISMO
=
ESPERANÇA

E esperança é ótima para cinema.

Nem sempre é boa política de RH.


🏭 Recurso ou profissional?

Existe uma palavra muito comum em contratos:

resource.

Recurso.

Resource allocation.

Resource planning.

Resource cost.

Resource utilization.

Compreensível.

Gestão precisa abstrair.

Mas existe um risco quando a linguagem começa a moldar o pensamento.

Servidor é recurso.

CPU é recurso.

Storage é recurso.

Licença é recurso.

E então:

João é recurso.

Maria é recurso.

Neo é recurso.

Algo acontece cognitivamente.

Se é recurso, pode ser:

ALLOCATE
USE
RELEASE
REPLACE
RECYCLE

Perfeito.

Só que Neo possui memória.

Expectativas.

Família.

Carreira.

Orgulho.

Contas.

Projetos pessoais.

E percepção de justiça.

Mainframe não reclama quando você reduz seu custo por MIPS.

Pessoa talvez reclame.

Mesmo em silêncio.


♻️ O profissional reciclável

A arquitetura pode virar:

CONTRATAR
   ↓
ALOCAR
   ↓
FATURAR
   ↓
CONTRATO TERMINA
   ↓
LIBERAR
   ↓
NOVO FORNECEDOR
   ↓
RECONTRATAR
   ↓
PAGAR MENOS
   ↓
REPETIR

É o COBOLzeiro reciclável.

Mesmo conhecimento.

Mesmo cérebro.

Novo crachá.

Nova consultoria.

Novo contrato.

Talvez menos dinheiro.

E quando não aceita:

RESOURCE REPLACEMENT REQUIRED

A linguagem deixa tudo maravilhosamente limpo.


🧠 Mas conhecimento não é toner

Aqui está o problema.

Trocar fornecedor de papel:

relativamente simples.

Trocar fornecedor de cadeira:

gerenciável.

Trocar fornecedor de notebook:

gerenciável.

Trocar uma equipe que conhece vinte anos de sistema:

não exatamente.

Porque conhecimento tácito não vem no contrato.


👴 “Essa PROC não pode rodar depois das 04:10”

Por quê?

Não está na documentação.

“Esse campo parece sem uso, mas não remova.”

Por quê?

“Porque um sistema externo ainda consome.”

Onde está documentado?

“Devia estar.”

😄

Esse é o capital invisível.

A nova consultoria pode contratar outro profissional tecnicamente excelente.

Mas ele ainda precisará aprender:

onde estão os corpos enterrados.

Metaforicamente.

Esperamos.


🧮 A economia total precisa incluir conhecimento perdido

A conta original era:

CONTRATO A = 100
CONTRATO B = 85

ECONOMIA = 15

Agora adicione:

ONBOARDING ..................... ?
TREINAMENTO .................... ?
CURVA DE APRENDIZADO ........... ?
ERROS DE CONTEXTO .............. ?
PRODUTIVIDADE INICIAL .......... ?
PERDA DE CONHECIMENTO .......... ?
TURNOVER ....................... ?
INCIDENTES ADICIONAIS .......... ?
GESTÃO DA TRANSIÇÃO ............ ?

Agora nossa economia ficou menos elegante.


❤️ E ainda falta o custo psicológico

Vamos adicionar:

PERDA DE CONFIANÇA ............. ?
RESSENTIMENTO .................. ?
DESENGAJAMENTO ................. ?
FUGA FUTURA .................... ?
PERDA DE COOPERAÇÃO ESPONTÂNEA . ?

Esse último é especialmente interessante.

O profissional pode continuar cumprindo 100% do contrato.

Mas talvez pare de entregar aquilo que nunca esteve no contrato.


☕ O café extra das 18:02

São 18:02.

Existe um problema.

Legalmente poderia ir embora.

Mas ele pensa:

Quero entender isso.

Fica.

Investiga.

Resolve.

Documenta.

Ensina alguém.

Nunca houve linha contratual:

ENTHUSIASM ........ R$ 0
CURIOSITY ......... R$ 0
HELP COLLEAGUE .... R$ 0
CARE .............. R$ 0

Essas coisas estavam incluídas invisivelmente.

Confiança fazia o profissional oferecer.

Depois do rebaixamento percebido, talvez pense:

Faço exatamente aquilo pelo qual vocês pagam.

Ele continua profissional.

Apenas parou de subsidiar emocionalmente a relação.


🏷️ Espírito de dono

Aqui temos outro clássico.

A organização diz:

“Queremos pessoas com espírito de dono.”

Morpheus olha para Neo.

Neo abre a planilha.

PARTICIPAÇÃO SOCIETÁRIA ..... NÃO
PARTICIPAÇÃO NOS LUCROS ..... TALVEZ NÃO
ESTABILIDADE ................ NÃO
CARREIRA .................... NÃO
RISCO COMPARTILHADO ......... SIM
CONTRATO TEMPORÁRIO ......... SIM

ESPÍRITO DE DONO ............ OBRIGATÓRIO

Agent Smith começa a rir no corredor.

Espírito de dono sem arquitetura de pertencimento pode ser apenas uma maneira elegante de pedir comprometimento adicional sem oferecer reciprocidade equivalente.

Isso não significa que ninguém deva se comprometer.

Profissionalismo importa.

Ética importa.

Qualidade importa.

Mas pertencimento não é cláusula contratual.


🧬 Capitalizar pessoas ou consumir pessoas?

Agora chegamos a uma diferença essencial entre dois modelos de consultoria.

Modelo A:

CONTRATA
   ↓
TREINA
   ↓
CERTIFICA
   ↓
DESENVOLVE
   ↓
PROMOVE
   ↓
REALLOCA
   ↓
RETÉM

Aqui o profissional é tratado como capital intelectual.

A empresa acredita:

VALOR FUTURO > VALOR PRESENTE

Modelo B:

CLIENTE PRECISA
   ↓
CONTRATA
   ↓
FATURA
   ↓
CLIENTE TERMINA
   ↓
LIBERA

Aqui o profissional funciona muito mais como capacidade produtiva temporária.

Os dois modelos podem existir legitimamente.

O problema começa quando o Modelo B vende o discurso do Modelo A.


🎭 “Venha construir uma carreira”

Talvez fosse mais honesto dizer:

Precisamos da sua experiência durante doze meses.

Não há nada necessariamente indigno nisso.

O profissional pode analisar.

Preço adequado?

Projeto interessante?

Aprendizado?

Vale a pena?

Aceita.

Perfeito.

A relação está clara.

Mas dizer:

“Venha crescer conosco.”

quando a estrutura real é:

CLIENT LOST = EMPLOYEE LOST

cria uma expectativa que o próprio modelo não consegue sustentar.


🔐 E lembre-se do conhecimento que atravessa a catraca

Agora conectamos com nossa conversa anterior.

Se o profissional aceita ganhar menos, pode ficar.

Se não aceita, vai embora.

E leva experiência.

Não necessariamente segredo empresarial.

Experiência.

Então a economia de 15% pode causar:

SALÁRIO ↓
       ↓
RESSENTIMENTO ↑
       ↓
TURNOVER ↑
       ↓
CONHECIMENTO SAI
       ↓
ONBOARDING ↑
       ↓
RISCO ↑

Talvez ainda compense.

Talvez não.

Mas alguém precisa medir.


🧑‍💼 Procurement não é vilão

É importante dizer isso.

Procurement possui missão legítima.

Controlar custos.

Evitar dependência excessiva.

Negociar melhor.

Criar competição.

Evitar acomodação de fornecedores.

Garantir governança.

Tudo isso importa.

O erro seria culpar uma função por um problema sistêmico.

Talvez o problema seja usar uma métrica local para otimizar um sistema global.

Procurement reduz:

CUSTO CONTRATUAL

Mas a empresa deveria medir:

TOTAL COST OF KNOWLEDGE

Essa segunda métrica é muito mais difícil.


🧩 Otimização local, prejuízo global

Quem trabalha com sistemas conhece isso.

Você otimiza uma rotina.

Ela fica 20% mais rápida.

Excelente.

Só que passa a produzir duas vezes mais chamadas ao banco.

Resultado:

sistema geral piorou.

Você otimizou localmente.

Degradou globalmente.

Isso pode acontecer também em contratos.

PROCUREMENT
COST -15%

Enquanto:

TURNOVER +20%
PRODUCTIVITY -8%
INCIDENT RISK +?
KNOWLEDGE LOSS +?
ENGAGEMENT -?

Sem observar o sistema inteiro, podemos comemorar a redução errada.


🟥 Red Pill Metrics

Talvez precisemos de indicadores diferentes.

Não apenas:

quanto custa a hora?

Mas:

quanto tempo o profissional permanece?

quanto conhecimento crítico está concentrado?

quanto tempo leva o substituto para atingir produtividade?

quanto custa uma saída?

quanto custa reconstruir contexto?

quanto treinamento foi perdido?

qual porcentagem das pessoas aceita renovar?

quantas saem nos primeiros seis meses?

quanto do trabalho crítico depende de terceiros temporários?

qual o diferencial salarial entre renovação e mercado?

quanto custa recuperar um incidente causado pela perda de contexto?

Essas métricas fariam a Matrix parecer diferente.


🎲 O jogo repetido

Existe outra coisa interessante.

Uma negociação não acontece isoladamente.

Se profissionais percebem repetidamente:

A CADA RENOVAÇÃO
    ↓
PRESSÃO PARA BAIXO

eles aprendem.

O mercado também possui memória.

Depois de algum tempo, a organização pode adquirir reputação.

“Você entra ganhando X e na renovação tentam reduzir.”

Agora os melhores profissionais podem exigir mais para entrar.

Ou simplesmente não entrar.

A economia de hoje pode alterar o custo de contratação amanhã.

Jogos econômicos repetidos produzem reputação.

Reputação também custa dinheiro.


🧠 O veterano começa a fazer outra conta

Nos primeiros anos:

Quero entrar.

Depois:

Quero aprender.

Depois:

Quero crescer.

Depois de algumas rodadas:

Quero saber quanto tempo isso dura.

Essa mudança é perfeitamente racional.

O profissional experiente deixa de avaliar apenas salário mensal.

Passa a avaliar:

RENDA
+
ESTABILIDADE
+
APRENDIZADO
+
REPUTAÇÃO
+
QUALIDADE DE VIDA
+
RISCO
+
PERSPECTIVA

Isso é maturidade econômica.


🔵 A pílula azul

Vamos defender o outro lado.

Custos precisam cair.

Empresas não são instituições de caridade.

Contratos precisam ser competitivos.

Nenhum fornecedor possui direito eterno sobre cliente.

Nenhum trabalhador possui garantia automática de valorização salarial contínua.

Mercado muda.

Tecnologia muda.

Demanda muda.

Margens mudam.

Às vezes ganhar menos pode ser racional diante de alternativas piores.

Tudo verdadeiro.


🔴 A pílula vermelha

Agora o outro lado.

Se você reduz continuamente preço sem reduzir escopo, talvez esteja comprimindo alguma coisa.

Se o profissional possui mais experiência e recebe menos, talvez esteja transferindo valor.

Se a relação depende do medo do desemprego, talvez a aparente retenção seja apenas permanência temporária.

Se você promete carreira sem possuir mecanismo de carreira, está vendendo esperança.

Se trata conhecimento como commodity, não deveria se surpreender quando conhecimento crítico desaparecer junto com quem saiu.

Também verdadeiro.

As duas pílulas cabem na mesma mão.


🕶️ A cena final

Neo está sentado na mesma cadeira.

Mesmo prédio.

Mesmo andar.

Mesmo terminal.

Mesmo banco.

Mesmo programa COBOL.

Mesmo dataset.

Mesmo incidente.

Mesmo café.

Só existe uma pequena diferença.

O crachá possui outro logotipo.

Ele executa:

TSO READY

Abre o mesmo programa.

Resolve um problema que já conhece.

Talvez mais rápido que no ano anterior.

Porque agora sabe mais.

Depois abre o holerite.

Fica olhando.

Morpheus aparece.

Silêncio.

Pergunta:

O que mudou?

Neo olha para o monitor.

EMPRESA ............. ALTERADA
CONTRATO ............ ALTERADO
CRACHÁ .............. ALTERADO
SALÁRIO ............. -12%

SISTEMA ............. IGUAL
RESPONSABILIDADE .... IGUAL
EXPERIÊNCIA ......... +1 ANO
BOLETOS ............. IGUAIS

Morpheus pergunta:

— E você?

Neo pensa.

Digita:

CONFIANÇA ........... -25%
PERTENCIMENTO ....... -30%
MOTIVAÇÃO ........... -15%
OPEN_TO_WORK ........ Y

O sistema aceita.

READY

☕ Cambio final, Torre de Controle

Talvez o maior erro do leilão reverso do conhecimento seja imaginar que podemos reduzir indefinidamente o preço sem alterar aquilo que estamos comprando.

Podemos trocar fornecedor.

Podemos trocar contrato.

Podemos trocar crachá.

Podemos reduzir margem.

Podemos negociar salário.

Mas pessoas não são linhas estáticas de uma planilha.

Quando pressionamos um sistema, alguma variável responde.

Às vezes aparece imediatamente.

Às vezes demora meses.

Às vezes surge num incidente.

Às vezes aparece numa carta de demissão.

Às vezes simplesmente desaparece quando aquele veterano que conhecia tudo decide não aceitar a próxima rodada.

Por isso, quando alguém apresentar:

SAVING = 15%

não pergunte apenas:

“Quanto economizamos?”

Pergunte:

“Quem financiou essa economia?”

A consultoria?

A margem?

A automação?

A eficiência?

O profissional?

A qualidade?

A retenção?

O futuro?

Talvez os 15% sejam uma conquista extraordinária.

Talvez sejam.

Mas só saberemos quando conseguirmos enxergar o sistema inteiro.

Porque em mainframe aprendemos cedo:

um RC=00 numa etapa não significa necessariamente que o processamento completo terminou bem.

E talvez procurement também precise dessa sabedoria.

       IDENTIFICATION DIVISION.
       PROGRAM-ID. REVERSE-AUCTION.

       DATA DIVISION.
       WORKING-STORAGE SECTION.

       01 WS-CONTRACT-COST       PIC 9(05)V99.
       01 WS-KNOWLEDGE           PIC 9(05)V99.
       01 WS-TRUST               PIC 9(05)V99.
       01 WS-ENGAGEMENT          PIC 9(05)V99.
       01 WS-SAVING              PIC 9(05)V99.

       PROCEDURE DIVISION.

           COMPUTE WS-SAVING =
                   OLD-CONTRACT - NEW-CONTRACT.

           DISPLAY 'SAVING: ' WS-SAVING.

           DISPLAY
              'CHECK WHO PAID FOR IT.'.

           IF WS-TRUST < OLD-TRUST
               DISPLAY
               'WARNING: HIDDEN COST DETECTED'
           END-IF.

           IF WS-KNOWLEDGE = CRITICAL
               DISPLAY
               'DO NOT PRICE KNOWLEDGE
                AS A COMMODITY'
           END-IF.

           STOP RUN.

🔴🔵

Wake up, Neo.

A empresa economizou 15%.

O COBOLzeiro sabe mais.

Recebe menos.

Continua responsável pelo mesmo sistema.

Continua pagando os mesmos boletos.

E talvez agora esteja apenas esperando a primeira oportunidade para atravessar definitivamente a catraca.

Nesse dia, alguém abrirá a planilha procurando entender por que ele foi embora.

Talvez a resposta esteja numa linha que nunca entrou no cálculo original:

HUMAN COST OF SAVING ............ NOT MEASURED

Cambio final, Torre de Controle.

☕ Um Café no Bellacosa Mainframe // IT JOB MARKET RADAR

Mercado de Trabalho em TI: Quando Conhecimento Vira Commodity, Poder e Risco

Cinco leituras sobre salário, memória técnica, conhecimento legado, leilão reverso de profissionais e o êxodo de especialistas COBOL. Um pequeno mapa de um mercado em que experiência vale muito — até alguém tentar transformá-la em desconto.

> ANALYZE IT_WORKFORCE
STATUS=KNOWLEDGE_CRITICAL
SALARY_PRESSURE=HIGH
LEGACY_SKILLS=SCARCE
CORPORATE_MEMORY=VOLATILE
ACTION=READ_THE_EVIDENCE
01

O Spread do Conhecimento: Matrix, COBOL e o Valor do Saber

Quando conhecimento raro deixa de ser apenas competência técnica e passa a funcionar como ativo econômico dentro das organizações.

Knowledge Economics
02

Quanto Custa um Programador? Salário, Valor e Mercado

O preço de um profissional de tecnologia não é simplesmente salário: envolve experiência, escassez, produtividade, conhecimento acumulado e risco operacional.

Salary Economics
03

DELETE USER Não Apaga Memória: O Conhecimento que Sai da Empresa

Demitir ou perder um especialista é simples no RH. Recuperar décadas de contexto operacional depois pode ser impossível.

Corporate Memory
04

O Leilão Reverso do Conhecimento

Quando empresas tentam comprar cada vez mais experiência por cada vez menos dinheiro, o mercado pode transformar contratação em um leilão reverso de conhecimento.

Reverse Auction
05

O Êxodo dos COBOLzeiros

O que acontece quando profissionais que conhecem sistemas críticos descobrem que permanecer onde estão pode valer menos do que sair?

COBOL Exodus

🧠 O problema não é COBOL. É economia do conhecimento.

Empresas costumam tratar conhecimento técnico como se fosse um recurso facilmente substituível. Entretanto, sistemas corporativos acumulam décadas de regras de negócio, exceções, interfaces, decisões históricas e conhecimento informal que raramente aparece integralmente na documentação.

Quando o profissional sai, o USERID pode ser apagado imediatamente. O contexto que ele carregava não possui um comando equivalente.

01 Pressão salarial
02 Saída do especialista
03 Perda de contexto
04 Incidente
05 Consultoria cara

📚 Leituras sobre mercado de trabalho, COBOL e conhecimento em TI

BELLACOSA MAINFRAME // KNOWLEDGE IS NOT A REPLACEABLE RESOURCE
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...