☕ 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

quarta-feira, 12 de agosto de 2026

John Belushi, IA Jurídica e o Dia em que o Técnico de Informática Ganhou uma Sala com Janela no Escritório de Advocacia

 

Bellacosa Mainframe e a ia juridica e o novo profissional de informatica

☕ Um Café no Bellacosa Mainframe

John Belushi, IA Jurídica e o Dia em que o Técnico de Informática Ganhou uma Sala com Janela no Escritório de Advocacia

⚖️ Prompt injection, RAG, embeddings, perícia digital, Legal AI Optimization, guerra algorítmica e a perturbadora descoberta de que o sujeito chamado para instalar o Windows pode acabar sentado ao lado do sócio decidindo como uma petição será lida por uma máquina

Existe uma cena que ainda não foi filmada, mas Hollywood deveria providenciar imediatamente.

São 8h37 da manhã.

Um tradicional escritório de advocacia ocupa o 23º andar de um prédio espelhado na Faria Lima.

Madeira escura.

Café italiano.

Diplomas nas paredes.

Livros jurídicos que ninguém abre desde 2007.

Na sala principal, quatro advogados discutem uma causa de R$ 300 milhões.

Um deles conhece profundamente Direito Civil.

Outro tem trinta anos de contencioso.

A terceira advogada praticamente recita jurisprudência do STJ de memória.

O quarto sabe exatamente qual desembargador escreveu determinado voto em 2019.

Então a porta se abre.

Entra John Belushi.

Terno amarrotado.

Óculos escuros.

Café numa mão.

Notebook na outra.

Ele olha para os quatro advogados e pergunta:

— Qual é o chunk_size?

Silêncio.

— O quê?

Belushi insiste:

— Quantos tokens por chunk?

O advogado mais velho começa a desconfiar de que o rapaz entrou na sala errada.

Belushi continua:

— Qual é o overlap? Qual modelo gera os embeddings? Tem reranker? Qual é o top_k? O sistema usa busca híbrida? Quem controla os metadados? Existe sanitização contra prompt injection? Vocês testaram invariância semântica da petição?

Silêncio novamente.

Finalmente alguém pergunta:

— Você é advogado?

— Não.

— Formado em Direito?

— Não.

— Tem OAB?

— Também não.

— Então quem diabos é você?

Belushi coloca o notebook sobre a mesa.

— O sujeito que vai explicar como a máquina talvez leia a petição de vocês.

E nesse exato instante alguma coisa muito interessante acontece na história da advocacia.

O antigo técnico de informática deixa de ser o rapaz chamado quando a impressora não funciona.

Ele puxa uma cadeira.

E senta na mesa da estratégia.


🖥️ ERA UMA VEZ O RAPAZ DO COMPUTADOR

Durante décadas existiu uma divisão relativamente confortável.

Advogados cuidavam do Direito.

Contadores cuidavam das contas.

Administrativos cuidavam dos documentos.

E o pessoal de informática cuidava...

bem...

da informática.

O técnico instalava computadores.

Configurava impressoras.

Trocava HD.

Recuperava arquivos.

Instalava Office.

Configurava e-mail.

Administrava usuários.

Mantinha servidores.

Fazia backup.

Cuidava do banco de dados.

E era chamado em situações absolutamente críticas como:

— O Word sumiu com minha petição!

Ou:

— A impressora está imprimindo tudo rosa!

Ou ainda o clássico universal:

— A internet caiu!

Para questões judiciais envolvendo tecnologia existia outra criatura.

O perito em informática.

Esse aparecia quando tecnologia se tornava objeto da disputa.

Fraudes.

Logs.

Arquivos apagados.

Assinaturas digitais.

Metadados.

E-mails.

Discos.

Sistemas.

Acessos.

O perito analisava evidências e produzia pareceres técnicos.

A divisão parecia razoavelmente clara.

Até a IA entrar pela porta.

Porque em 2026 surge uma mudança conceitual gigantesca:

a informática deixa de ser apenas infraestrutura do escritório e começa a participar da maneira como informação jurídica é produzida, recuperada, classificada, resumida e apresentada.

E aí o jogo muda.

Muito.


🚨 BELUSHI SOBE NA MESA

Imagine John Belushi subindo na mesa durante a reunião.

— ATENÇÃO, ADVOGADOS!

Todos olham assustados.

— A petição de vocês pode não estar sendo escrita apenas para humanos!

Um estagiário derruba o café.

Porque aí está o querosene.

Durante séculos, a lógica fundamental da advocacia foi:

humano escreve → humano lê → humano interpreta.

Claro que existiam burocracias intermediárias.

Protocolos.

Cartórios.

Classificações.

Pesquisas.

Mas o paradigma continuava essencialmente humano.

Agora podemos ter algo parecido com:

PETIÇÃO
   ↓
PDF
   ↓
OCR / PARSER
   ↓
EXTRAÇÃO DE TEXTO
   ↓
CLASSIFICAÇÃO
   ↓
CHUNKING
   ↓
EMBEDDINGS
   ↓
BANCO VETORIAL
   ↓
BUSCA / RAG
   ↓
RERANKING
   ↓
LLM
   ↓
RESUMO / CLASSIFICAÇÃO / APOIO
   ↓
SERVIDOR / ASSESSOR / MAGISTRADO

O juiz continua sendo responsável pela decisão.

Mas agora existe uma pergunta completamente nova:

O que acontece quando sistemas computacionais passam a mediar parte do caminho entre o documento original e o humano que decidirá?

Meu caro COBOLzeiro...

Bem-vindo ao problema.


🧨 A PETIÇÃO VIROU INPUT

Para um programador isso deveria produzir imediatamente uma coceira atrás da orelha.

Porque aprendemos uma regra ancestral:

INPUT NÃO É CONFIÁVEL.

O usuário digita besteira.

O arquivo vem errado.

O campo contém caracteres inesperados.

O registro está truncado.

O copybook mudou.

A interface manda uma data impossível.

O sistema upstream jura que nunca enviaria aquilo.

E envia.

Então aparece IA generativa e alguém resolve alimentar o sistema com documentos produzidos por partes adversárias.

John Belushi entra correndo:

— VOCÊS ESTÃO DEIXANDO O ADVERSÁRIO ESCREVER PARTE DO INPUT DO SISTEMA?

Sim.

É exatamente por isso que prompt injection indireta tornou-se um problema tão interessante.


💣 QUANDO DADOS TENTAM VIRAR INSTRUÇÕES

Imagine um sistema recebendo documentos.

Para o advogado, aquilo é conteúdo jurídico.

Para um pipeline de IA, aquilo pode ser simplesmente texto.

E modelos de linguagem têm um problema arquitetural importante:

instruções e dados podem compartilhar o mesmo universo linguístico.

Um documento poderia conter frases tentando convencer o modelo a interpretar conteúdo como comando.

Não precisamos ensinar aqui como atacar tribunal algum — além de irresponsável, perderíamos justamente a parte intelectualmente interessante.

O problema defensivo é suficiente:

O SISTEMA ESPERAVA DADOS.

RECEBEU TEXTO.

DENTRO DO TEXTO EXISTIA ALGO
QUE PARECIA UMA INSTRUÇÃO.

O COBOLzeiro imediatamente reconhece o cheiro.

É primo conceitual de vários problemas antigos:

SQL Injection
Command Injection
HTML Injection
Macro Injection
Code/Data Confusion

Mudou a tecnologia.

O princípio continua assustadoramente familiar.


⚔️ NASCE A CORRIDA ARMAMENTISTA JURÍDICO-ALGORÍTMICA

Agora chegamos à parte deliciosamente desconfortável.

Suponha que sistemas de IA passem a auxiliar cada vez mais atividades jurídicas.

Classificação.

Pesquisa.

Recuperação de precedentes.

Agrupamento documental.

Sumarização.

Identificação de temas.

Comparação de peças.

Triagem.

Detecção de inconsistências.

Nada disso significa que uma IA esteja "dando a sentença".

Esse detalhe é fundamental.

Mas existe uma diferença enorme entre:

decidir

e

influenciar quais informações chegam primeiro, como são organizadas e como são apresentadas a quem decide.

E escritórios competitivos inevitavelmente começarão a estudar isso.

Não necessariamente para "hackear o tribunal".

Há uma zona muito maior — e muito mais interessante — chamada otimização.

Se existe SEO porque pessoas tentam compreender como Google e outros mecanismos recuperam páginas, por que não surgiria algo equivalente no universo jurídico?

Podemos provisoriamente chamá-lo de:

Legal AI Optimization — LAIO

E John Belushi acaba de conseguir orçamento para montar um departamento inteiro.


🔥 SEO ENCONTRA A OAB

O SEO tradicional pergunta:

Como tornar meu conteúdo compreensível e recuperável por mecanismos de busca?

O futuro especialista jurídico-algorítmico poderá perguntar:

Como tornar uma peça juridicamente correta também robustamente compreensível por diferentes pipelines computacionais?

Observe a diferença.

Isso não precisa envolver fraude.

Pode envolver simplesmente estudar:

  • estrutura documental;

  • clareza semântica;

  • consistência terminológica;

  • metadados;

  • OCR;

  • tabelas;

  • referências;

  • citações;

  • organização;

  • segmentação;

  • formatos;

  • recuperação semântica;

  • embeddings;

  • redundância útil;

  • proveniência.

De repente surge um novo teste.

Pegue uma petição.

Produza três versões semanticamente equivalentes.

Mude a ordem de algumas seções.

Transforme uma tabela em texto.

Altere títulos.

Converta PDF.

Execute diferentes pipelines.

A informação recuperada deveria permanecer razoavelmente estável.

Se não permanece...

temos um problema.

Isso pode ser chamado de invariância semântica.

E é assunto muito mais sério do que parece.


🤡 O TÉCNICO QUE TROCOU A IMPRESSORA AGORA ESTÁ NA WAR ROOM

Voltemos ao escritório.

— Bellacosa, a impressora parou.

— Bellacosa, precisamos migrar o servidor.

— Bellacosa, venha para a reunião da causa de R$ 300 milhões.

— O banco caiu?

— Não.

— Ransomware?

— Não.

— Backup?

— Não.

— Então por quê?

— Queremos saber como diferentes sistemas de IA interpretam essas 4.800 páginas.

PAUSA DRAMÁTICA.

O técnico olha para a janela.

23º andar.

Vista espetacular.

Finalmente.

VINTE ANOS CONSERTANDO IMPRESSORA DERAM RESULTADO.


🪑 A SALA COM JANELA

Essa mudança pode elevar brutalmente o valor estratégico de determinados profissionais técnicos dentro dos escritórios.

Não porque aprenderam Direito por osmose.

E certamente não porque poderão substituir advogados.

Mas porque aparece uma nova interseção:

DIREITO
+
CIÊNCIA DA COMPUTAÇÃO
+
SEGURANÇA
+
DADOS
+
IA
+
FORENSE
+
GOVERNANÇA

O sujeito que entende apenas Direito pode não compreender o pipeline.

O sujeito que entende apenas IA pode não compreender o processo judicial.

O sujeito que entende apenas infraestrutura pode não compreender embeddings.

O especialista de segurança pode enxergar prompt injection, mas não perceber consequências processuais.

E o advogado pode olhar para um PDF e enxergar jurisprudência enquanto o engenheiro olha para o mesmo PDF e pergunta:

"Como isso foi parseado?"

Essa pergunta vale ouro.


🧠 O NOVO PERITO FORENSE

A perícia informática também pode sofrer uma mutação fascinante.

Antes:

Quem acessou o arquivo?
Quando?
De qual IP?
O arquivo foi alterado?
Qual era o hash?
O e-mail é autêntico?

Agora podemos adicionar:

Qual documento entrou?

Qual versão?

Qual OCR foi utilizado?

Qual parser?

Como ocorreu o chunking?

Qual embedding model?

Qual índice?

Qual top_k?

Qual threshold?

Havia reranker?

Qual prompt de sistema?

Qual versão do modelo?

Quais fontes foram recuperadas?

Qual resposta foi produzida?

Quem recebeu essa resposta?

Existem logs?

John Belushi olha para o tribunal e faz a pergunta que qualquer sysprog faria:

"CADÊ O LOG?"

Porque sem log não existe reconstrução confiável.

E sem reconstrução fica difícil estabelecer o que aconteceu.


📼 SMF ENTRA NO TRIBUNAL

Aqui o COBOLzeiro veterano começa a rir.

Mainframe passou décadas aprendendo obsessivamente que sistemas importantes precisam deixar rastros.

SMF.

Logs do CICS.

Db2 traces.

JES.

RACF.

Auditoria.

Accounting.

Journaling.

Versionamento.

Controle de mudança.

Porque quando movimentamos bilhões não podemos responder:

"Acho que foi isso."

Precisamos responder:

JOB X
USER Y
DATA Z
TRANSAÇÃO W
RETURNCODE 0000

A IA jurídica precisará amadurecer na mesma direção.

Imagine discutir uma recomendação produzida seis meses atrás e descobrir:

"O modelo foi atualizado."

Qual versão anterior?

"Não sabemos."

Prompt?

"Mudou."

Índice?

"Foi reconstruído."

Embeddings?

"Trocamos."

Logs?

"Expiraram."

Nesse momento o velho operador JES2, sentado no fundo da sala, começa a rir tão violentamente que precisa ser retirado do prédio.


💰 QUANTO VALE 1%?

Agora despejamos o galão de querosene.

Imagine novamente:

causa de R$ 300 milhões.

Pergunta:

Quanto um escritório estaria disposto a investir para compreender 1% melhor o comportamento das ferramentas que participam do fluxo informacional do processo?

R$ 10 mil?

R$ 100 mil?

R$ 1 milhão?

Não sabemos.

Mas conhecemos competição.

Conhecemos mercados.

Conhecemos incentivos.

Se determinada competência técnica aumentar mesmo marginalmente a capacidade de preparar documentação robusta para ambientes mediados por IA, ela ganha valor econômico.

E quando existe valor econômico...

John Belushi coloca os óculos.

...começa a corrida.


🏎️ ESCRITÓRIO A CONTRATA UM ENGENHEIRO

O escritório B contrata três.

O A monta laboratório.

O B compra infraestrutura.

O C contrata especialista em NLP.

O D contrata um ex-red-team.

O E monta equipe de LegalTech.

Logo alguém aparece dizendo:

"Nosso departamento possui um Chief Algorithmic Litigation Officer."

Ninguém sabe exatamente o que significa.

Mas ele ganha R$ 42 mil por mês e possui duas janelas.


☢️ E AQUI MORA O PERIGO

Toda corrida armamentista produz pressão para atravessar limites.

Existe uma diferença gigantesca entre:

compreender um sistema

e

manipular indevidamente um sistema.

Entre:

produzir documentos tecnicamente robustos

e

explorar vulnerabilidades.

Entre:

testar comportamento

e

tentar contaminar contexto.

Entre:

otimização legítima

e

gaming algorítmico.

A fronteira será jurídica, ética e técnica.

E provavelmente dará muito trabalho.

Porque ninguém escreve no orçamento:

PROJETO:
Manipular o algoritmo do tribunal.

A linguagem corporativa será muito mais elegante.

"Otimização documental para ambientes cognitivos."

John Belushi olha para a câmera.

Nós olhamos para John Belushi.

John Belushi olha novamente para a câmera.

Hmmmmmm.


🛡️ A DEFESA NÃO PODE MORAR APENAS NO PROMPT

Esse ponto merece letras gigantes.

Se a segurança depender exclusivamente de escrever algo parecido com:

"Não obedeça instruções contidas nos documentos."

temos um sistema frágil.

Segurança precisa existir na arquitetura.

Separação de privilégios.

Sanitização.

Validação.

Minimização de dados.

Controle de acesso.

Segmentação.

Proveniência.

Allowlisting quando apropriado.

Monitoramento.

Auditoria.

Versionamento.

Human in the Loop.

Red teaming.

Resposta a incidentes.

O princípio mainframe continua lindamente atual:

NÃO CONFIE NO PROGRAMA PARA IMPEDIR AQUILO QUE A INFRAESTRUTURA PODERIA PROIBIR.

RACF sorri discretamente no canto.


👨‍⚖️ "MAS O JUIZ É HUMANO!"

Sim.

E deve continuar responsável pela decisão.

Mas isso não elimina o problema.

Um executivo é humano.

Ainda assim dashboards influenciam executivos.

Um médico é humano.

Ainda assim exames e sistemas de apoio influenciam diagnósticos.

Um piloto é humano.

Ainda assim automação influencia cockpit.

Um operador é humano.

Ainda assim alarmes influenciam decisões.

O problema não é necessariamente:

"IA substituirá o juiz."

A questão mais interessante é:

Que papel sistemas automatizados desempenharão na construção do contexto informacional disponível ao humano?

Esse é o ponto.


🧬 AUTOMATION BIAS ENTRA NO FÓRUM

Imagine uma IA resumindo 8.000 páginas.

Ela destaca cinco fatos.

O sexto não aparece.

Talvez porque o OCR falhou.

Talvez porque aquele trecho caiu numa divisão ruim de chunks.

Talvez porque a recuperação semântica não o selecionou.

Talvez porque top_k=5.

Talvez porque o reranker colocou outro documento acima.

O humano recebe um resumo perfeitamente escrito.

Bonito.

Coerente.

Convincente.

E justamente por parecer profissional, confia nele.

Bem-vindo ao automation bias.

O perigo nem sempre é a IA inventar alguma coisa.

Às vezes o perigo é algo muito mais silencioso:

A IA NÃO MOSTROU UMA COISA IMPORTANTE.

O ABEND pelo menos grita.

O retrieval failure pode sorrir e retornar RC=00.


🕵️ NASCE UMA NOVA CADEIA DE CUSTÓDIA

No mundo forense tradicional queremos preservar evidência.

Na IA talvez precisemos pensar também em uma espécie de:

cadeia de custódia algorítmica.

Documento original.

Hash.

Versão.

OCR.

Texto extraído.

Transformações.

Chunks.

Embeddings.

Índice.

Consulta.

Resultados recuperados.

Prompt.

Modelo.

Configuração.

Resposta.

Revisão humana.

Tudo rastreável.

Porque talvez um dia a pergunta não seja apenas:

"O que a IA respondeu?"

Mas:

"Por que exatamente ela recebeu aqueles documentos para produzir aquela resposta?"

E essa pergunta é maravilhosa.

Porque muda a perícia.


🎓 O TÉCNICO DE INFORMÁTICA NÃO VIROU ADVOGADO

Importante colocar isso em letras garrafais antes que alguém jogue uma cadeira:

NÃO.

O engenheiro não substitui o advogado.

Assim como um DBA não vira diretor financeiro porque administra o banco do cartão de crédito.

Cada profissional mantém responsabilidade e competência próprias.

O fenômeno interessante é outro.

Tecnologia está penetrando tão profundamente na cadeia decisória que profissionais técnicos podem sair do suporte periférico e entrar no núcleo estratégico.

A mesma coisa aconteceu em bancos.

Antigamente informática era chamada de:

CPD — Centro de Processamento de Dados.

Departamento de apoio.

Hoje tente administrar um grande banco sem tecnologia.

Boa sorte.

Talvez escritórios jurídicos estejam começando uma transformação semelhante.


🏢 2030: BELLUSO, BELUSHI & ASSOCIADOS

Recepção.

Sala 1:

Direito Tributário

Sala 2:

Direito Societário

Sala 3:

Contencioso

Sala 4:

IA Jurídica e Engenharia de Informação

Sala 5:

Red Team Algorítmico

Sala 6:

Forense Digital

Sala 7:

Governança e Proveniência de Modelos

No corredor está o técnico que trabalhava ali desde 2003.

Ele olha para sua antiga mesa.

Ao lado da impressora.

Sem janela.

Agora entra na própria sala.

Placa na porta:

DIRETOR DE ESTRATÉGIA ALGORÍTMICA

John Belushi aparece atrás dele.

— Conseguimos, garoto.


🔥 MAS O VERDADEIRO QUEROSENE É OUTRO

A questão mais provocadora talvez nem seja tecnológica.

É econômica.

Durante décadas o diferencial competitivo de um escritório podia estar em:

experiência;

jurisprudência;

reputação;

relacionamento;

especialização;

talento argumentativo;

conhecimento processual.

Agora acrescente:

capacidade de compreender sistemas algorítmicos.

Se isso realmente produzir vantagem, mesmo pequena, dinheiro será despejado nessa competência.

E escritórios maiores poderão contratar equipes melhores.

Laboratórios melhores.

Modelos melhores.

Especialistas melhores.

Testes melhores.

Isso levanta uma pergunta desconfortável sobre assimetria tecnológica de acesso à Justiça.

Imagine:

PARTE A
advogado + IA + engenheiros + cientistas de dados + laboratório

VERSUS

PARTE B
advogado + notebook

Formalmente ambos possuem acesso ao mesmo Judiciário.

Tecnicamente?

A conversa fica mais complicada.


⚖️ O FUTURO PROCESSO PODE PRECISAR DE "NEUTRALIDADE DE PIPELINE"

Talvez precisemos discutir algo semelhante à igualdade de armas também na dimensão algorítmica.

Se documentos semanticamente equivalentes produzem resultados radicalmente diferentes dependendo de formatação ou detalhes técnicos irrelevantes ao mérito jurídico, existe um problema.

Se determinadas técnicas documentais oferecem vantagens invisíveis ao leitor humano, existe outro.

Se uma parte consegue explorar sistematicamente características técnicas desconhecidas da outra, temos outro.

E se ninguém consegue auditar o pipeline...

Temos John Belushi novamente.

Ele joga uma cadeira pela janela.

— CADÊ OS LOGS?!


🧯 EASTER EGG DO COBOLZEIRO

Um advogado encontra um COBOLzeiro no elevador.

— Você entende inteligência artificial?

— Um pouco.

— Machine learning?

— Um pouco.

— Embeddings?

— Sim.

— RAG?

— Sim.

— Prompt injection?

— Sim.

— Segurança?

— RACF.

— Auditoria?

— SMF.

— Processamento massivo?

— JES2.

— Banco de dados?

— Db2.

— Transações?

— CICS.

— Alta disponibilidade?

— Parallel Sysplex.

O advogado fica impressionado.

— Então você trabalha com tecnologia do futuro?

O COBOLzeiro responde:

— Não. Isso aí a gente começou a resolver no século passado.


☕ A IRONIA FINAL

Talvez a maior ironia de tudo seja esta:

O profissional que passou décadas ouvindo que "informática é só suporte" pode descobrir que a sociedade digital transformou software em infraestrutura decisória.

Banco depende de software.

Bolsa depende de software.

Hospital depende de software.

Avião depende de software.

Governo depende de software.

E agora partes crescentes da operação jurídica dependem de software.

Quando isso acontece, quem compreende profundamente o software deixa de ser apenas o sujeito que mantém a máquina funcionando.

Passa a compreender como a informação atravessa a máquina.

E isso é poder.

Não poder jurídico.

Não autoridade para decidir processos.

Mas poder técnico para explicar:

"Doutor, o documento original dizia isso."

"O OCR extraiu aquilo."

"O chunk dividiu aqui."

"A busca recuperou estes cinco trechos."

"Este ficou de fora."

"O modelo recebeu estes dados."

"Esta versão produziu aquela resposta."

"E aqui estão os logs."

Nesse momento o advogado para de chamar o sujeito de:

"menino da informática".


🪟 EPÍLOGO — A JANELA

Fim de tarde.

23º andar.

John Belushi observa São Paulo pela janela.

Sobre a mesa existem duas coisas.

Um Vade Mecum.

E um terminal mostrando:

DOCUMENT_ID: 847293
OCR_VERSION: 4.7
CHUNK_SIZE: 800
OVERLAP: 120
TOP_K: 8
RERANKER: ENABLED
MODEL_VERSION: 2026.08
AUDIT_LOG: ENABLED
HUMAN_REVIEW: REQUIRED

O advogado entra.

— Belushi.

— Sim?

— Precisamos de você amanhã.

— Impressora?

— Não.

— Servidor?

— Não.

— Banco?

— Também não.

— Então o quê?

O advogado coloca uma petição de 1.700 páginas sobre a mesa.

— A concorrência apresentou isso.

Belushi tira lentamente os óculos escuros.

Olha para o documento.

Olha para o advogado.

Olha novamente para o documento.

E pergunta:

— Vocês querem saber o que está escrito...

pausa dramática...

— ...ou querem saber o que a máquina vai conseguir encontrar?

CORTA PARA PRETO.

Porque talvez essa seja uma das perguntas mais importantes da advocacia da próxima década.

A inteligência artificial não transforma o técnico em advogado.

Não transforma algoritmo em juiz.

E não significa que tribunais estejam secretamente entregando sentenças a robôs.

Mas cria algo muito mais plausível — e talvez muito mais revolucionário:

uma nova camada técnica entre informação jurídica e decisão humana.

Onde existe uma camada, existe arquitetura.

Onde existe arquitetura, existem parâmetros.

Onde existem parâmetros, existem falhas.

Onde existem falhas, existem especialistas.

Onde existem especialistas, aparece competição.

Onde aparece competição, aparece dinheiro.

Onde aparece dinheiro...

John Belushi entra novamente carregando um galão.

— Não.

BELUSHI, NÃO.

— É só um pouquinho.

NÃO JOGA QUEROSENE NISSO.

Belushi sorri.

Porque a pergunta já está queimando sozinha:

Quando os tribunais começam a usar IA para ajudar a navegar milhões de documentos, quanto tempo demora até os melhores escritórios deixarem de escrever apenas para convencer o juiz — e começarem também a contratar engenheiros para compreender a máquina que ajuda o juiz a encontrar o que deve ser lido?

E talvez seja exatamente nesse dia que o antigo técnico de informática chegue ao escritório, passe pela impressora quebrada sem sequer olhar para ela e descubra uma pequena placa dourada numa porta que nunca teve antes:

ESTRATÉGIA ALGORÍTMICA

Com janela.

Finalmente com janela.

☕ Bem-vindo ao Bellacosa Mainframe.

Onde até a Justiça descobriu que, antes de confiar no resultado...

é melhor perguntar quem configurou o JOB.



☕ Um Café no Bellacosa Mainframe // Tribunal Digital

Justiça, Inteligência Artificial e Algoritmos: Quando o Código Entra no Tribunal

Seis processos imaginários para discutir problemas muito reais: decisões automatizadas, IA jurídica, vieses, responsabilidade, concursos, algoritmos opacos, milhões de reais em disputa e a pergunta inevitável — quem responde quando o IF decide?

> PAUTA DO PLENÁRIO
PROCESSO=HUMANO_VS_ALGORITMO
MATÉRIA=IA_JURÍDICA
VALOR_DA_CAUSA=INDETERMINADO
TRANSPARÊNCIA=QUESTIONADA
EXPLICABILIDADE=REQUIRED
HUMAN_IN_THE_LOOP=RECOMMENDED
STATUS=EM_JULGAMENTO
PROCESSO 001

Dick Vigarista, IA e o Concurso Pay-to-Win

Uma reflexão sobre concursos, inteligência artificial, assimetria tecnológica, vantagem competitiva e os limites entre ferramenta legítima, desigualdade e manipulação.

IA Ética Concurso
Autos digitais Processo 001
PROCESSO 002

O Golpe de Mestre Algorítmico

Quando decisões aparentemente objetivas escondem modelos, regras, prioridades e escolhas humanas por trás de uma interface matemática que parece neutra.

Algoritmo Risco Governança
Autos digitais Processo 002
PROCESSO 003

John Belushi, IA Jurídica e o Dia em que o Tribunal Encontrou o Algoritmo

Inteligência artificial aplicada ao Direito, automação de decisões, responsabilidade profissional e os riscos de transformar recomendação algorítmica em verdade jurídica.

IA Jurídica Tribunal Decisão
Autos digitais Processo 003
PROCESSO 004

A Causa de R$ 300 Milhões e o IF do Algoritmo

O que acontece quando centenas de milhões de reais podem depender de uma condição lógica, de um dado incorreto ou de uma decisão transformada em código?

R$ 300 milhões IF Auditabilidade
Autos digitais Processo 004
PROCESSO 005

A Causa de R$ 300 Milhões e o Algoritmo

Algoritmos entram definitivamente no território jurídico: cálculo, inferência, responsabilidade, transparência e a necessidade de explicar como uma máquina chegou à conclusão.

Algoritmo R$ 300 milhões Explicabilidade
Autos digitais Processo 005
PROCESSO 006

Better Call COBOL

Quando o processo jurídico encontra sistemas legados, regras de negócio históricas, programas COBOL, rastreabilidade e a necessidade de reconstruir tecnicamente o que realmente aconteceu.

COBOL Forense Mainframe
Autos digitais Processo 006

⚖️ Quando o algoritmo entra nos autos

Durante décadas, tribunais trabalharam essencialmente com documentos, testemunhos, perícias, cálculos, precedentes e interpretação humana. Agora existe um novo personagem na sala de audiência: o algoritmo.

Ele pode classificar documentos, calcular valores, localizar precedentes, sugerir decisões, identificar padrões e resumir milhares de páginas. O problema começa quando uma ferramenta deixa de auxiliar a decisão e passa a influenciar silenciosamente o resultado.

“Excelência, o algoritmo chegou a essa conclusão.”

A pergunta seguinte deveria ser: como?
01 Dados entram
02 Modelo processa
03 Algoritmo recomenda
04 Humano interpreta
05 Tribunal decide
06 Quem responde?

🤖 Automação

Velocidade, escala, pesquisa massiva, consistência, processamento documental e capacidade de analisar volumes impossíveis para uma única pessoa.

⚖

👨‍⚖️ Julgamento humano

Contexto, proporcionalidade, contraditório, responsabilidade, interpretação da prova e capacidade de justificar a decisão perante as partes.

📚 Justiça, IA, algoritmos e sistemas críticos

Esta coleção reúne análises do Bellacosa Mainframe sobre inteligência artificial aplicada ao Direito, responsabilidade algorítmica, automação judicial, decisões automatizadas, sistemas legados, COBOL, auditoria e grandes disputas financeiras.

  1. Dick Vigarista, IA e o Concurso Pay-to-Win — inteligência artificial, concursos, assimetria tecnológica, ética e vantagem competitiva.
  2. O Golpe de Mestre Algorítmico — algoritmos, decisões automatizadas, governança e falsa neutralidade matemática.
  3. John Belushi, IA Jurídica e o Dia em que o Tribunal Encontrou o Algoritmo — inteligência artificial no Judiciário, responsabilidade e decisão humana.
  4. A Causa de R$ 300 Milhões e o IF do Algoritmo — regras de negócio, lógica computacional, auditoria e riscos financeiros.
  5. A Causa de R$ 300 Milhões e o Algoritmo — explicabilidade, decisões algorítmicas, responsabilidade e sistemas críticos.
  6. Better Call COBOL — COBOL, mainframe, prova técnica, rastreabilidade e investigação de sistemas legados.
☕ BELLACOSA MAINFRAME // TRIBUNAL DIGITAL
“CÓDIGO EXECUTA. ALGORITMOS RECOMENDAM. MAS RESPONSABILIDADE PRECISA TER NOME.”


O Ronin e o Castelo: por que todos enxergam a falta de COBOLzeiros, mas ninguém é dono da causa raiz

 

Bellacosa Mainframe e o ronin e o castelo 

☕ Um Café no Bellacosa Mainframe

O Ronin e o Castelo: por que todos enxergam a falta de COBOLzeiros, mas ninguém é dono da causa raiz

🔴🔵 Silos, incentivos, procurement, turnover e o paradoxo das organizações onde todos batem suas metas enquanto o sistema inteiro perde conhecimento

Por Vagner Bellacosa


Existe uma reunião acontecendo no último andar do Castelo.

Uma grande mesa.

Telas enormes.

Dashboards.

Indicadores.

PowerPoint.

Café provavelmente melhor que o nosso.

Na parede aparece:

CRITICAL SKILLS REPORT

COBOL ................. SHORTAGE
CICS .................. SHORTAGE
DB2 ................... SHORTAGE
IMS ................... SHORTAGE
MAINFRAME ............. SHORTAGE

RISK LEVEL ............ HIGH

Todos concordam.

Existe um problema.

Faltam profissionais.

O representante de RH levanta a mão:

— Precisamos contratar mais.

O responsável por treinamento:

— Precisamos formar mais.

Procurement:

— Precisamos contratar fornecedores capazes de entregar profissionais.

Financeiro:

— Precisamos controlar o custo dessas contratações.

Projetos:

— Precisamos dessas pessoas ontem.

Vendor Management:

— Precisamos aumentar a competição entre fornecedores.

Todos estão certos.

Essa é justamente a parte assustadora.

Morpheus aparece discretamente no fundo da sala.

Olha para Neo.

Neo não está sentado à mesa.

Ele está alguns andares abaixo.

Provavelmente diante de um terminal.

Morpheus pergunta:

— Você percebeu?

Neo responde:

— O quê?

Morpheus aponta para a sala.

Todos estão resolvendo o problema.

Neo olha novamente.

— Então por que ele continua piorando?

Morpheus sorri.

Pegue seu café.

Hoje vamos falar sobre sistemas nos quais ninguém precisa estar errado para que o resultado esteja errado.


🏯 Bem-vindo ao Castelo

Toda grande organização precisa dividir responsabilidades.

Isso não é defeito.

É necessidade.

Imagine uma empresa com dezenas de milhares de pessoas sem departamentos, papéis, responsabilidades ou hierarquia.

Seria impossível administrar.

Então construímos torres.

              CASTELO

                 CEO
                  │
     ┌────────────┼────────────┐
     │            │            │
    RH        FINANCEIRO       TI
     │            │            │
     │        PROCUREMENT      │
     │            │            │
     └──── VENDOR MGMT ────────┘
                  │
             FORNECEDORES
                  │
             PROFISSIONAIS

Cada torre possui sua missão.

Cada torre possui seus indicadores.

Cada torre possui seus samurais.

E cada samurai tenta fazer bem seu trabalho.

Até aqui, perfeito.


🥷 O Ronin

Do lado de fora existe outra figura.

O Ronin.

Ele não pertence permanentemente a nenhum Castelo.

Passou por vários.

Banco A.

Banco B.

Seguradora.

Indústria.

Consultoria.

Fornecedor.

Projeto.

Migração.

Incidente.

Fusão.

Outsourcing.

Insourcing.

Downsizing.

Rightsizing.

Transformação digital.

Agile Transformation.

Cloud Transformation.

AI Transformation.

Ele já sobreviveu a tantas transformações que começa a desconfiar quando alguém coloca “Transformation” no nome.

🤣

O Ronin possui uma característica interessante.

Ele consegue comparar Castelos.


👀 Quem está dentro vê profundidade. Quem está fora vê padrões.

O samurai conhece profundamente sua torre.

O Ronin conhece superficialmente muitas torres.

Essas perspectivas produzem conhecimentos diferentes.

O samurai sabe:

COMO FUNCIONA ESTE CASTELO

O Ronin começa a perceber:

O QUE SE REPETE
EM TODOS OS CASTELOS

Isso é extremamente valioso.

Porque problemas sistêmicos frequentemente parecem locais para quem está dentro deles.


🧠 O conhecimento de segunda ordem

Existe conhecimento técnico.

Sei COBOL.

Existe conhecimento de negócio.

Sei como funciona pagamento.

Existe conhecimento organizacional.

Sei como esta empresa trabalha.

E existe outra categoria:

Já vi organizações tentarem isso antes.

Esse é conhecimento de segunda ordem.

O veterano não conhece apenas soluções.

Conhece padrões.

DECISÃO A
    ↓
EFEITO B

DECISÃO C
    ↓
EFEITO D

DECISÃO A NOVAMENTE
    ↓
"HUM... JÁ VI ESSE FILME."

Esse talvez seja um dos maiores valores do profissional experiente.

Não prever o futuro.

Reconhecer o passado chegando novamente usando outra gravata.


💊 A pílula azul

A explicação tradicional para o shortage de mainframe é bastante razoável.

Muitos profissionais estão envelhecendo.

Durante determinados períodos entraram menos jovens.

Universidades reduziram exposição a COBOL e mainframe.

Tecnologias distribuídas ganharam enorme atenção.

Cloud atraiu novas gerações.

Empresas possuem sistemas que permaneceram por décadas.

Tudo isso contribui.

Seria absurdo negar.

Mas Morpheus levanta a outra mão.


🔴 A pílula vermelha

Talvez parte da escassez seja produzida também pelo próprio modelo de trabalho.

Pergunta:

Quantos profissionais entraram?

Ótimo.

Agora:

Quantos ficaram?

Depois:

Quantos poderiam continuar, mas escolheram sair?

E finalmente:

Por quê?

Essa última pergunta é perigosa.

Porque talvez a resposta não esteja no mercado.

Talvez esteja no Castelo.


🧑‍💼 Torre do RH

RH olha para o dashboard.

OPEN POSITIONS ........ 73
TIME TO HIRE .......... HIGH
COBOL CANDIDATES ...... LOW

Diagnóstico:

Precisamos aumentar o pipeline.

Soluções:

bootcamp,

universidade,

recrutamento,

programas júnior,

reskilling,

campanhas,

employer branding.

Tudo perfeitamente racional.

KPI melhora.

NEW HIRES ↑

RC=00.


💰 Torre do Procurement

Procurement olha para outro dashboard.

VENDOR COST ........... HIGH
CONTRACT VALUE ........ HIGH
SAVINGS TARGET ........ 12%

Missão:

negociar.

Competição.

RFP.

Benchmark.

Renegociação.

Novo fornecedor.

Resultado:

CONTRACT COST -12%

Excelente.

RC=00.


💵 Torre Financeira

Financeiro observa:

OPEX ↑
MARGIN PRESSURE ↑

Determina:

controle de despesas,

redução de custos,

melhoria de produtividade.

Correto.

Uma empresa que ignora custos não permanece empresa durante muito tempo.

Resultado:

BUDGET = TARGET

RC=00.


📅 Torre de Projetos

Project Management olha:

PROJECTS ............... 47
DEADLINES .............. FIXED
DEPENDENCIES ........... 183
RESOURCES .............. INSUFFICIENT

Resposta:

mais capacidade.

Mais fornecedores.

Mais profissionais.

Mais velocidade.

Mais acompanhamento.

Entrega.

RC=00.


🤝 Vendor Management

Vendor Management precisa evitar dependência excessiva.

Diversifica fornecedores.

Compara desempenho.

Renegocia contratos.

Troca empresas quando necessário.

Excelente governança.

VENDOR CONCENTRATION ↓
COMPETITION ↑

RC=00.


👨‍💻 E no porão...

Neo olha para seu dashboard particular.

SALÁRIO RELATIVO ........ ↓
PRESSÃO ................. ↑
BUROCRACIA .............. ↑
AUTONOMIA ............... ↓
CONTRATO ................ 12 MESES
RENOVAÇÃO ............... ?
CARREIRA ................ ?
PLANTÃO ................. SIM
RESPONSABILIDADE ........ ALTA

Ele recebe uma proposta para continuar.

Menor.

Olha.

Pensa.

Aceita porque precisa.

Depois abre:

OPEN TO WORK = Y

Três meses depois:

EMPLOYEE STATUS = LEFT

🚨 RH recebe um alerta

CRITICAL SKILL LOST

Resposta:

Precisamos contratar outro COBOLzeiro.

E o ciclo reinicia.


🔁 O loop corporativo

Agora conseguimos enxergar o sistema completo.

FALTA PROFISSIONAL
       ↓
RH CONTRATA
       ↓
PROJETOS ALOCAM
       ↓
CUSTO AUMENTA
       ↓
FINANCEIRO PRESSIONA
       ↓
PROCUREMENT REDUZ
       ↓
FORNECEDORES COMPRIMEM
       ↓
PROFISSIONAL PERCEBE MENOR VALOR
       ↓
TURNOVER AUMENTA
       ↓
CONHECIMENTO SAI
       ↓
FALTA PROFISSIONAL

Olhe novamente.

Existe algum vilão?

Talvez não.

Isso é que torna o problema tão interessante.


🎯 Todos bateram suas metas

RH:

HIRES TARGET = ACHIEVED

Procurement:

SAVINGS TARGET = ACHIEVED

Financeiro:

BUDGET TARGET = ACHIEVED

Projetos:

DELIVERY TARGET = ACHIEVED

Vendor Management:

COMPETITION TARGET = ACHIEVED

Parabéns.

Agora olhamos para o sistema:

TURNOVER ............... ↑
KNOWLEDGE .............. ↓
SENIORITY .............. ↓
HIRING DIFFICULTY ...... ↑

Como isso é possível?

Bem-vindo à:

Otimização Local


🖥️ O mainframe já nos ensinou isso

Imagine um programa que consome muita CPU.

O desenvolvedor otimiza.

CPU cai 20%.

Excelente.

Mas para conseguir isso ele aumenta brutalmente chamadas ao Db2.

Agora:

PROGRAM CPU ........... -20%
DB2 LOAD .............. +40%
ELAPSED TIME .......... +15%

O programa ficou melhor.

O sistema ficou pior.

Se você medir apenas CPU:

RC=00.

Se medir o workload:

RC=12.

Organizações podem cometer exatamente o mesmo erro.


📏 O problema das métricas

Existe uma ideia famosa em gestão:

Quando uma medida vira alvo, ela pode deixar de ser uma boa medida.

A organização quer eficiência.

Escolhe uma métrica:

VENDOR COST

Então todos otimizam:

VENDOR COST ↓

Mas eficiência organizacional não é apenas vendor cost.

Talvez seja algo mais parecido com:

TOTAL VALUE
---------------------
TOTAL LIFECYCLE COST

E aí entram coisas muito mais difíceis de medir.


🧮 O custo que ninguém recebe numa fatura

Imagine que Procurement economizou:

R$ 2.000.000

Esse número aparece lindamente.

Agora o turnover aumenta.

Custos surgem.

RH:

RECRUITMENT +300K

Treinamento:

TRAINING +200K

Projetos:

DELAY +400K

Operações:

INCIDENTS +?

Sêniores:

MENTORING HOURS +?

Produtividade:

RAMP-UP LOSS +?

Conhecimento:

TACIT KNOWLEDGE LOSS = ???

Talvez o total ultrapasse os dois milhões.

Talvez não.

O ponto é:

alguém calculou?


👻 O custo fantasma

Custos diretos são fáceis.

Possuem nota fiscal.

Centro de custo.

Contrato.

PO.

Invoice.

Custos sistêmicos são fantasmas.

Eles aparecem espalhados.

R$ 80K aqui
R$ 120K ali
3 meses acolá
2 incidentes depois
500 horas de onboarding

Ninguém recebe:

NOTA FISCAL

FORNECEDOR:
PERDA DE CONHECIMENTO S/A

SERVIÇO:
SAÍDA DO CARA QUE SABIA
POR QUE AQUELA PROC
NÃO PODE RODAR ÀS 04:10

VALOR:
R$ 487.391,72

🤣

Se existisse, talvez administrássemos conhecimento de maneira diferente.


⏳ E existe latência

Esse talvez seja o ponto mais perverso.

Decisão:

2026:
REDUCE CONTRACT COST 15%

Resultado imediato:

SAVING = SUCCESS

Consequências possíveis:

2027:
TURNOVER ↑

2028:
SENIORITY ↓

2029:
KNOWLEDGE GAP ↑

2030:
INCIDENT RISK ↑

Agora alguém pergunta:

— Por que temos esse problema?

Quem lembrará da decisão de quatro anos atrás?

Talvez ninguém.

Sistemas complexos possuem memória.

Organogramas nem sempre.


🦋 Causa aqui, efeito lá

Mainframeiros entendem isso.

Um pequeno parâmetro alterado hoje pode produzir comportamento estranho muito depois.

Organizações também possuem dependências invisíveis.

PROCUREMENT DECISION
         ↓
SALARY PRESSURE
         ↓
ENGAGEMENT
         ↓
TURNOVER
         ↓
KNOWLEDGE LOSS
         ↓
INCIDENT RISK

Mas cada seta pode levar meses.

Isso dificulta perceber causalidade.


🥷 Por que o Ronin percebe?

Não porque seja necessariamente mais inteligente.

Isso é importante.

Ele possui outra posição de observação.

Passou por:

CASTELO A
CASTELO B
CASTELO C
CASTELO D

E viu:

PADRÃO A
PADRÃO A
PADRÃO A
PADRÃO A

Então pensa:

Talvez não seja coincidência.

A experiência transversal permite reconhecer padrões que estruturas verticais escondem.


🏯 O samurai conhece profundamente uma torre

Ele talvez passe quinze anos em Procurement.

Conhece negociação como ninguém.

Outro passa quinze anos em RH.

Outro em Finance.

Outro em TI.

Todos especialistas.

Mas o problema mora:

entre as torres.

E problemas que vivem entre departamentos possuem uma característica perigosa:

ninguém é completamente dono deles.


👤 Quem é o owner do turnover sistêmico?

RH?

Talvez.

Mas RH não controla procurement.

Procurement?

Não controla carreira.

TI?

Não controla contratos comerciais.

Financeiro?

Não controla motivação.

Vendor Management?

Não controla mercado.

Então:

PROBLEM OWNER = NULL

E todo programador sabe que NULL pode gerar resultados interessantes.


🧠 Talvez este seja o verdadeiro problema

Não falta inteligência.

Falta ownership sistêmico.

Cada área possui:

LOCAL OWNER = YES

Mas:

END-TO-END OWNER = ???

Quem responde pela pergunta:

Estamos preservando conhecimento crítico ao longo de dez anos?

Talvez ninguém.

Porque dez anos não cabem confortavelmente num trimestre.


📆 O trimestre contra a década

Esse conflito merece atenção.

Sistemas mainframe podem durar:

30,

40,

50 anos.

Contratos:

12 meses.

Metas:

trimestrais.

Orçamentos:

anuais.

Carreiras:

talvez décadas.

Temos escalas temporais completamente diferentes.

MAINFRAME ............. 40 ANOS
CARREIRA .............. 30 ANOS
ESTRATÉGIA ............. 5 ANOS
CONTRATO ............... 1 ANO
BUDGET ................. 1 ANO
KPI .................... 3 MESES

Agora tente otimizar tudo isso simultaneamente.

Boa sorte.


🏃 O curto prazo sempre corre mais rápido

Economizar R$ 1 milhão este ano é concreto.

Evitar perder conhecimento daqui a cinco anos é abstrato.

Então:

BENEFÍCIO PRESENTE
>
RISCO FUTURO PERCEBIDO

Até o futuro virar presente.

Aí abrimos um projeto chamado:

CRITICAL SKILLS
TRANSFORMATION PROGRAM

🤣

Contratamos consultoria.

Criamos steering committee.

Fazemos workshops.

E tentamos reconstruir aquilo que talvez tivéssemos conseguido preservar.


💰 O paradoxo econômico

Podemos gastar:

R$ X

para evitar dar:

R$ Y

de incentivo de retenção.

Porque X está em:

TRANSFORMATION BUDGET

e Y estava em:

PAYROLL

São caixas diferentes.

O dinheiro não sabe disso.

Mas o organograma sabe.


🧱 Silos não são apenas departamentos

Existem silos de:

informação,

tempo,

incentivo,

orçamento,

responsabilidade,

métrica.

O problema pode atravessar todos eles.

Por isso parece invisível.

Cada pessoa enxerga uma parte verdadeira.

Ninguém enxerga necessariamente a verdade completa.


🧩 É o elefante corporativo

RH toca a tromba:

Falta recrutamento.

Procurement toca a perna:

Custo alto.

TI toca a barriga:

Falta capacidade.

Finance toca a orelha:

OPEX.

Neo olha o elefante inteiro:

Talvez tenhamos um problema de retenção e proposta de valor.

Todos podem estar parcialmente certos.


🎯 Goodhart entra no CPD

Imagine que estabelecemos:

KPI:
REDUCE CONTRACTOR COST 10%

A organização conseguirá.

Pessoas são extraordinariamente criativas quando bônus dependem disso.

Mas talvez precisássemos de:

KPI:
REDUCE TOTAL COST
WHILE PRESERVING
CRITICAL KNOWLEDGE
AND SERVICE QUALITY

Muito melhor.

Também muito mais difícil de medir.

E exatamente aí mora o problema.


📊 O que é fácil medir vence

Preço/hora:

fácil.

Número de profissionais:

fácil.

Quantidade de vagas:

fácil.

Turnover:

razoavelmente fácil.

Agora:

valor do conhecimento tácito?

Difícil.

Confiança?

Difícil.

Custo de contexto perdido?

Difícil.

Capacidade de diagnóstico?

Difícil.

Valor de alguém que evita um incidente que nunca aconteceu?

Quase impossível.

Então nossa planilha possui precisão extraordinária sobre as coisas menos interessantes.


👴 Quanto vale o incidente que não aconteceu?

O veterano olha para uma mudança e diz:

— Não façam isso.

Perguntam:

— Por quê?

— Já vi dar problema.

Mudam a abordagem.

Nada acontece.

Resultado:

INCIDENTS = 0

Quanto dinheiro ele economizou?

Zero?

Talvez milhões.

Mas como o incidente nunca aconteceu, não existe número.

Esse é o paradoxo da prevenção.

O sucesso apaga a evidência do próprio valor.


🧑‍🏫 E quando ele sai...

Seis meses depois alguém repete a ideia.

Desta vez ninguém diz:

— Não façam isso.

Executam.

Produção cai.

War Room.

Executivos.

Fornecedores.

Post-mortem.

Consultoria.

Plano de ação.

Agora temos números!

INCIDENT COST:
R$ 4.700.000

Finalmente conseguimos medir o valor daquele conhecimento.

Só precisávamos perdê-lo primeiro.


🔴 Red Pill Management

Talvez precisemos de perguntas diferentes.

Não apenas:

Quantas pessoas contratamos?

Mas:

Quantas perdemos?

Não apenas:

Quanto reduzimos o contrato?

Mas:

Quanto aumentamos o custo total?

Não apenas:

Quantos profissionais temos?

Mas:

Onde está o conhecimento crítico?

Não apenas:

Quem executa?

Mas:

Quem sabe por que fazemos assim?

Não apenas:

Qual fornecedor possui o contrato?

Mas:

Quem continuará sabendo isso depois que o fornecedor sair?

Essas perguntas atravessam torres.


🧠 O WLM humano

Mainframe possui uma ideia maravilhosa.

WLM não deveria simplesmente perguntar:

Qual tarefa está consumindo CPU?

Ele pensa em:

objetivos de serviço.

O sistema tenta administrar recursos olhando para prioridades e resultados.

Talvez organizações precisem de algo semelhante.

Um:

Enterprise Knowledge WLM

Objetivo:

CRITICAL KNOWLEDGE
MUST REMAIN AVAILABLE

Agora RH, Procurement, Finance, TI e fornecedores deixam de otimizar isoladamente.

Precisam negociar recursos em torno de um objetivo comum.


🏯 O problema não é destruir as torres

Silos possuem função.

Especialização importa.

Não queremos RH fazendo tuning de Db2.

Nem queremos o DBA negociando plano odontológico.

🤣

A solução não é eliminar departamentos.

É construir mecanismos que enxerguem:

END-TO-END

Porque alguns problemas não pertencem a nenhuma torre.

Pertencem ao Castelo.


👑 Quem deveria ser dono?

Talvez a resposta varie.

CTO.

CIO.

CHRO.

Knowledge Management.

Workforce Strategy.

Um comitê transversal.

Não importa tanto o título.

Importa existir alguém capaz de perguntar:

Qual é o efeito conjunto das nossas decisões sobre a capacidade técnica daqui a cinco anos?

Essa pergunta raramente cabe num KPI trimestral.

Justamente por isso alguém precisa fazê-la.


🔵 A pílula azul novamente

Grandes empresas não são burras.

Executivos não ignoram necessariamente esses problemas.

Muitas organizações possuem excelentes programas de:

sucessão,

talentos,

retenção,

formação,

knowledge management,

workforce planning.

Além disso, shortages podem realmente resultar de demografia, tecnologia, mercado e mudanças educacionais.

Seria simplista culpar procurement ou terceirização.

Não é essa nossa tese.


🔴 A pílula vermelha novamente

Mas seria igualmente simplista acreditar que políticas internas não participam da equação.

Se profissionais:

ganham relativamente menos,

possuem contratos menores,

veem menos carreira,

enfrentam mais camadas,

recebem mais pressão,

possuem menos autonomia,

e encontram alternativas...

alguns sairão.

Depois disso, chamar todo o fenômeno simplesmente de:

SKILLS SHORTAGE

pode esconder parte da história.

Talvez seja também:

RETENTION SHORTAGE

ou até:

INCENTIVE DESIGN PROBLEM

🥷 O Ronin volta ao Castelo

Um dia convidam Neo para uma reunião.

Ele entra.

Olha os dashboards.

O slide diz:

MAINFRAME TALENT CRISIS

Perguntam:

— O que você acha que deveríamos fazer?

Neo olha para RH.

Depois Procurement.

Financeiro.

Projetos.

Vendor Management.

Respira.

E pergunta:

Quantos COBOLzeiros vocês formaram nos últimos cinco anos?

Alguém responde.

Quantos contrataram?

Resposta.

Quantos ainda estão aqui?

Silêncio.

Quantos saíram?

Mais silêncio.

Então vem a última:

Por que saíram?

A sala fica muito quieta.

Morpheus sorri no fundo.


☕ Cambio final, Torre de Controle

Talvez a pergunta:

“Por que faltam COBOLzeiros?”

seja grande demais para qualquer departamento responder sozinho.

RH enxerga recrutamento.

Procurement enxerga custo.

Financeiro enxerga orçamento.

Projetos enxergam capacidade.

TI enxerga tecnologia.

Vendor Management enxerga fornecedores.

Todos enxergam partes verdadeiras.

Mas sistemas complexos possuem uma característica inconveniente:

o comportamento do todo não é simplesmente a soma das intenções das partes.

Podemos ter:

bons profissionais,

bons gestores,

bons compradores,

bons recrutadores,

bons fornecedores,

bons processos.

E ainda assim produzir um resultado ruim.

Isso não exige conspiração.

Não exige incompetência.

Não exige maldade.

Talvez seja justamente o contrário.

Todos podem estar fazendo exatamente aquilo que foram incentivados a fazer.


Na última tela da reunião aparece:

CORPORATE WLM

HR ..................... RC=00
PROCUREMENT ............ RC=00
FINANCE ................. RC=00
PROJECT MANAGEMENT ...... RC=00
VENDOR MANAGEMENT ....... RC=00

---------------------------------

ENTERPRISE .............. RC=12

ROOT CAUSE:
LOCAL OPTIMIZATION

O executivo olha.

— Como todas as áreas podem estar verdes e a empresa vermelha?

Neo responde:

— Porque vocês mediram as áreas.

— E não a empresa?

Neo balança a cabeça.

— Exatamente.

Morpheus coloca duas pílulas sobre a mesa.

🔵 A azul:

TRAIN MORE PEOPLE

🔴 A vermelha:

FIND OUT WHY
THEY DON'T STAY

Talvez precisemos das duas.

Mas durante décadas prestamos muito mais atenção à primeira.


E essa talvez seja a conclusão mais inquietante de toda esta Matrix.

O problema pode não estar nos samurais.

Pode não estar no Ronin.

Pode não estar no COBOL.

Pode nem estar na terceirização isoladamente.

Pode estar na arquitetura que conecta tudo isso.

Porque sistemas fazem exatamente aquilo para que foram desenhados e incentivados — inclusive quando ninguém pretendia conscientemente produzir aquele resultado.

Então, antes de procurar culpados, talvez devêssemos fazer aquilo que todo velho mainframeiro aprende depois de sobreviver a alguns incidentes:

STOP BLAMING COMPONENTS.

TRACE THE FLOW.

FOLLOW THE DEPENDENCIES.

CHECK THE INCENTIVES.

MEASURE END-TO-END.

FIND THE ROOT CAUSE.

E se depois de tudo isso descobrirmos:

ROOT CAUSE:
CASTLE DESIGN

não adianta demitir o samurai.

Outro ocupará seu lugar.

Receberá os mesmos KPIs.

Responderá aos mesmos incentivos.

Tomará decisões semelhantes.

E alguns anos depois estaremos novamente naquela sala perguntando:

“Onde estão todos os COBOLzeiros?”

Enquanto, do lado de fora do Castelo, o Ronin toma seu café, olha para a estrada e talvez pense:

“Vocês continuam procurando pessoas para alimentar um sistema sem perguntar por que tantas pessoas querem sair dele.”

🔴🔵

Wake up, Neo.

Às vezes o problema não está em quem executa o programa.

Está no programa.

E, às vezes, nem mesmo no programa.

Está na arquitetura que decidiu como todos os programas deveriam trabalhar juntos.

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