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

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.

A Causa de R$ 300 Milhões e o IF do Programador: quando uma decisão técnica aparentemente banal pode virar parte da Justiça

 

Bellacosa Mainframe e a causa de 300 milhoes e o if do programador

☕ Um Café no Bellacosa Mainframe

A Causa de R$ 300 Milhões e o IF do Programador: quando uma decisão técnica aparentemente banal pode virar parte da Justiça

🧑‍💻 IA judicial vista do chão da fábrica: requisitos, RAG, embeddings, chunking, logs, privilégios, fornecedores, insider risk e o dia em que o analista percebeu que aquele parâmetro escondido no YAML talvez fosse mais importante do que parecia

Imagine que você é analista de sistemas.

Nada de ministro.

Nada de desembargador.

Nada de grande escritório de advocacia.

Nada de reunião cinematográfica envolvendo uma mesa de mogno e quinze advogados discutindo uma causa bilionária.

Você está sentado diante de dois monitores.

São 14h37.

O Teams acabou de fazer aquele barulho que anuncia que alguém descobriu mais uma coisa “urgente”.

Existe um ticket aberto.

Uma história no backlog.

Uma especificação.

Talvez uma documentação no Confluence.

E uma frase aparentemente inocente:

“Implementar melhoria no mecanismo de recuperação semântica dos documentos processuais.”

Beleza.

Mais uma tarefa.

Você abre o código.

Encontra:

chunk_size: 1000
chunk_overlap: 150
top_k: 10
similarity_threshold: 0.72
reranking: true

Olha aquilo.

Toma um gole de café.

E começa a trabalhar.

Só existe um pequeno detalhe que talvez ninguém tenha colocado na User Story:

do outro lado daquele similarity_threshold pode existir uma causa de R$ 300 milhões.

Agora ficou interessante.

Porque no primeiro artigo desta série olhamos para o problema do ponto de vista do mercado jurídico.

Perguntamos:

Se conhecer melhor o comportamento de uma IA judicial pudesse produzir uma vantagem de apenas 1%, quanto essa informação poderia valer?

Agora vamos atravessar a parede.

Vamos entrar na fábrica.

Porque alguém precisa construir essa IA.

Alguém escolhe o modelo.

Alguém configura o banco.

Alguém define permissões.

Alguém cria os prompts.

Alguém decide o tamanho dos chunks.

Alguém implementa o ranking.

Alguém olha os logs.

Alguém possui acesso administrativo.

Alguém recebe o chamado às três da manhã quando tudo para.

E esse alguém pode ser simplesmente:

você.


⚠️ Isto continua sendo threat modeling

Antes que alguém derrube café no teclado:

este artigo não afirma que sistemas judiciais estejam sendo manipulados por técnicos, nem que programadores estejam vendendo informações, nem que determinada arquitetura seja utilizada por qualquer tribunal específico.

Estamos fazendo aquilo que profissionais de segurança deveriam fazer antes de colocar qualquer infraestrutura crítica em produção:

pensar como ela poderia falhar ou ser abusada.

Em mainframe fazemos isso há décadas.

Perguntamos:

Quem pode alterar este dataset?

Quem possui ALTER no RACF?

Quem consegue executar esta transação?

Quem consegue modificar esta PROC?

Quem pode alterar produção?

Quem lê o log?

Quem consegue apagar o log?

Então por que diante de IA deveríamos simplesmente escrever:

TRUSTED_AI=true

e ir embora?

😂

Não existe inteligência artificial mágica.

Existe software.

Existe infraestrutura.

Existem pessoas.

Existem privilégios.

Existem erros.

Existem incentivos.

Portanto:

AI SYSTEM
   =
CODE
+ DATA
+ MODEL
+ CONFIGURATION
+ INFRASTRUCTURE
+ PEOPLE
+ PROCESS

E qualquer veterano de produção sabe qual dessas variáveis costuma causar as histórias mais interessantes.


🏭 Bem-vindo ao chão da fábrica

Do ponto de vista executivo, talvez o projeto seja descrito assim:

“Solução baseada em Inteligência Artificial para aumentar eficiência na análise documental.”

Maravilhoso.

PowerPoint aprovado.

Seta azul.

Ícone de cérebro.

Nuvem.

Pessoa sorrindo.

ROI.

Transformação Digital.

Agora entregue isso para TI.

A arquitetura começa a ficar mais parecida com:

DOCUMENTOS
    |
    v
INGESTÃO
    |
    v
OCR / PARSER
    |
    v
NORMALIZAÇÃO
    |
    v
CHUNKING
    |
    v
EMBEDDINGS
    |
    v
VECTOR DATABASE
    |
    v
QUERY
    |
    v
RETRIEVAL
    |
    v
RERANKING
    |
    v
PROMPT
    |
    v
LLM
    |
    v
RESPOSTA / RESUMO
    |
    v
USUÁRIO HUMANO

Agora já não parece tão mágico.

Parece sistema.

E sistema possui parâmetros.


🧩 O maldito chunk_size

Imagine um processo gigantesco.

Milhares de páginas.

A IA não necessariamente despeja tudo de uma vez dentro de um modelo.

Documentos podem ser segmentados.

Chunks.

Pedaços.

Agora aparece uma decisão aparentemente técnica:

Qual será o tamanho do chunk?

500 tokens?

1.000?

2.000?

Onde quebramos?

Por página?

Por parágrafo?

Por seção?

Por estrutura semântica?

Mantemos overlap?

Quanto?

A pergunta parece pertencer ao Jira.

Só que pode haver uma consequência:

DOCUMENTO ORIGINAL

[ARGUMENTO]
[CONTEXTO]
[EXCEÇÃO]
[CONCLUSÃO]

Depois do processamento:

CHUNK 41
[ARGUMENTO]
[CONTEXTO...]

CHUNK 42
[...CONTEXTO]
[EXCEÇÃO]

CHUNK 43
[CONCLUSÃO]

E se a busca recuperar 41 e 43, mas não 42?

💥

A exceção desapareceu.

Não porque alguém censurou.

Não porque o modelo conspirou.

Não porque o advogado foi incompetente.

Porque:

top_k=2.

Bem-vindo ao Direito por configuração YAML.


🎛️ Parâmetro técnico também pode ser decisão de negócio

Essa é uma coisa que profissionais experientes aprendem dolorosamente.

Alguém diz:

“É só parâmetro técnico.”

Não.

Alguns parâmetros técnicos implementam política de negócio.

No banco:

MAX_TRANSACTION_VALUE

parece configuração.

Mas determina comportamento financeiro.

No WLM:

prioridade parece técnica.

Até você perceber quem recebe CPU quando tudo fica congestionado.

Num mecanismo de recuperação:

similarity_threshold=0.72

parece matemática.

Mas determina:

o que entra e o que fica fora.

E, dependendo do uso daquela informação posteriormente, isso pode ter consequência operacional.

Por isso o desenvolvedor precisa começar a perguntar:

Quem definiu 0,72?

Por quê?

Qual teste sustentou esse valor?

O que acontece com 0,70?

E 0,75?

Existe benchmark?

Existe documentação?

Existe aprovação?

Existe auditoria?

Porque daqui a três anos alguém pode perguntar:

“Por que este documento não apareceu?”

E a resposta não pode ser:

“Cara... acho que o Júnior colocou 0,72 porque no Stack Overflow alguém recomendou.”

😂


💰 Agora lembre dos R$ 300 milhões

É aqui que o desenvolvedor precisa entender o ambiente em que seu software existe.

Você pode estar trabalhando numa função que aparentemente altera 0,5% do comportamento de recuperação.

No laboratório:

irrelevante.

Num sistema de recomendação de receitas:

talvez irrelevante.

Num processo envolvendo R$ 300 milhões:

talvez não seja.

Isso não significa que aquele parâmetro determine uma decisão judicial.

Significa que precisamos analisar seriamente qualquer sistema que possa interferir em:

  • informação recuperada;

  • informação apresentada;

  • classificação;

  • priorização;

  • sumarização;

  • contexto oferecido ao usuário.

Porque existe diferença entre:

decidir

e

influenciar aquilo que estará disponível no momento da decisão.

Essa segunda categoria pode parecer muito mais inocente.

Nem sempre é.


🧑‍💻 “Mas eu só desenvolvo”

Ah.

Essa frase.

Todo veterano de TI conhece uma versão dela.

“Eu só desenvolvo.”

“Eu só mantenho.”

“Eu só cuido do banco.”

“Eu só faço deploy.”

“Eu só sou fornecedor.”

Até acontecer um incidente.

Então descobrimos que:

DESENVOLVEDOR
    ↓
possui acesso ao repositório

DEVOPS
    ↓
possui acesso ao pipeline

DBA
    ↓
possui acesso ao banco

CLOUD ADMIN
    ↓
possui acesso à infraestrutura

ML ENGINEER
    ↓
conhece o modelo

DATA SCIENTIST
    ↓
conhece os experimentos

SUPORTE
    ↓
enxerga logs

FORNECEDOR
    ↓
conhece arquitetura

ARQUITETO
    ↓
conhece tudo isso junto

De repente aparece uma pergunta desagradável:

Quem conhece informação suficiente para compreender como o sistema realmente se comporta?

E outra pior:

Quanto vale esse conhecimento fora da organização?


🕵️ Insider risk não significa “funcionário bandido”

Precisamos matar esse erro imediatamente.

Quando segurança fala de insider risk, não está dizendo:

“Nossos funcionários são criminosos.”

RACF não existe porque todo operador é ladrão.

Controle de acesso existe porque:

TRUST EVERYONE

é uma arquitetura de segurança ridícula.

Insider pode ser:

  • funcionário malicioso;

  • funcionário coagido;

  • credencial roubada;

  • funcionário enganado;

  • ex-funcionário;

  • terceiro;

  • fornecedor;

  • consultor;

  • conta administrativa esquecida;

  • erro humano.

E frequentemente o incidente mais espetacular começa com alguém perfeitamente honesto fazendo algo perfeitamente banal.


🔑 O problema da conta que pode tudo

Todo chão de fábrica conhece esta criatura mitológica:

a conta técnica eterna.

Criada em 2019.

Ninguém sabe quem pediu.

Está documentada numa planilha.

Possui privilégio demais.

Três sistemas dependem dela.

Ninguém ousa alterar porque:

“Vai saber o que quebra.”

😂

Agora coloque isso numa infraestrutura de IA.

Quem pode:

ALTER MODEL CONFIGURATION
ALTER SYSTEM PROMPT
ALTER RETRIEVAL SETTINGS
READ AUDIT LOGS
DELETE AUDIT LOGS
CHANGE EMBEDDING MODEL
CHANGE DATA SOURCE
MODIFY RERANKER
DEPLOY APPLICATION

Se a resposta for:

svc_ai_admin

temos outra pergunta:

quem consegue usar svc_ai_admin?

E se a resposta for:

“Ah... umas quinze pessoas.”

☕ Pegue mais café.

A reunião vai demorar.


🧱 Segregação de funções não ficou velha

IA parece moderna.

Os controles necessários são surpreendentemente antigos.

Quem desenvolve não deveria necessariamente aprovar sozinho.

Quem aprova não deveria necessariamente implantar sozinho.

Quem administra o sistema não deveria necessariamente conseguir apagar seus próprios rastros.

Mudanças críticas deveriam exigir controle apropriado.

Em outras palavras:

DEV
 ≠
APPROVER
 ≠
DEPLOYER
 ≠
AUDITOR

Bem-vindo novamente ao mainframe.

Nós já discutíamos isso quando “inteligência artificial” ainda fazia pessoas imaginarem HAL 9000.


📜 Configuration Management virou evidência

Imagine uma mudança:

- similarity_threshold: 0.72
+ similarity_threshold: 0.67

Quem alterou?

Quando?

Por quê?

Qual ticket?

Qual teste?

Quem aprovou?

Qual versão entrou em produção?

Quanto tempo permaneceu?

Quais consultas foram afetadas?

Conseguimos reproduzir o comportamento anterior?

Isso não é burocracia.

Em sistemas críticos:

configuração é evidência.

Git não é apenas ferramenta do desenvolvedor.

Pipeline não é apenas automação.

Log não é apenas coisa que enche disco.

Eles fazem parte da cadeia de responsabilidade.


📋 “Funciona na minha máquina” não será defesa

Imagine uma contestação futura:

“O sistema apresentou resultados diferentes para documentos juridicamente equivalentes.”

O desenvolvedor responde:

“Nos meus testes funcionava.”

😂

Parabéns.

Você acaba de invocar o espírito de dez mil incidentes de produção.

Sistemas de IA exigem testes que vão além do happy path.

Precisamos perguntar:

O que acontece se mudar a ordem dos parágrafos?

Se trocar sinônimos?

Se alterar formatação?

Se o documento for gigantesco?

Se possuir tabelas?

Se OCR errar?

Se houver rodapé repetitivo?

Se houver instruções adversariais dentro do documento?

Se uma jurisprudência aparecer citada de formas diferentes?

Se duas teses forem semanticamente semelhantes?

Isso é red teaming.


🔴 O Red Team precisa escrever petição também

Tradicionalmente, teste de software pergunta:

INPUT A → OUTPUT A
INPUT B → OUTPUT B

Para sistemas de IA, precisamos de testes mais perversos.

Pegue uma tese.

Crie cinco versões semanticamente equivalentes.

VERSÃO A
tradicional

VERSÃO B
simplificada

VERSÃO C
extremamente estruturada

VERSÃO D
ordem alterada

VERSÃO E
otimizada para recuperação

Agora execute.

Compare:

  • chunks recuperados;

  • ranking;

  • similaridade;

  • citações;

  • resumo;

  • resposta final.

Se pequenas alterações cosméticas provocarem diferenças enormes:

🚨

Não diga:

“LLM é assim mesmo.”

Investigue.


🎰 O desenvolvedor pode criar o gacha sem perceber

No artigo anterior brincamos com a ideia da:

Justiça Gacha.

O escritório rico desbloqueia:

SSR ALGORITHM WHISPERER +10

Mas existe uma pergunta anterior.

Quem construiu a mecânica do gacha?

Talvez ninguém deliberadamente.

Pode ter surgido simplesmente da soma de decisões locais:

um threshold aqui
+
um chunk ali
+
um ranking acolá
+
um prompt
+
um modelo
+
uma configuração
=
COMPORTAMENTO EMERGENTE

Esse é o tipo de coisa que assusta engenheiro experiente.

Não precisamos de vilão.

Precisamos apenas de complexidade.


📦 E o fornecedor?

Ahhh.

Agora chegamos à parte divertida.

Imagine que a instituição não construiu tudo.

Existe:

TRIBUNAL
   |
   +-- CONSULTORIA A
   |
   +-- CLOUD B
   |
   +-- MODELO C
   |
   +-- VECTOR DB D
   |
   +-- INTEGRADOR E
   |
   +-- SUPORTE F

Quem conhece a arquitetura completa?

Talvez ninguém.

Quem possui acesso?

Talvez gente demais.

Quem responde pelo comportamento final?

Excelente pergunta.

Esse problema não nasceu com IA.

Terceirização já produz cadeias complexas há décadas.

Mas IA acrescenta modelos, datasets, prompts, embeddings e serviços externos ao velho quebra-cabeça.


🧠 O prompt de sistema é código?

Essa discussão merece atenção.

Imagine:

Você é um assistente jurídico.
Analise os documentos recuperados...
Priorize...
Ignore...
Considere...
Resuma...

Isso não parece código tradicional.

Mas altera comportamento.

Então:

Quem pode modificá-lo?

Existe versionamento?

Code review?

Aprovação?

Testes?

Rollback?

Auditoria?

Se mudar uma frase do system prompt altera significativamente a saída, então aquela frase possui importância operacional.

Talvez devamos tratá-la com disciplina semelhante àquela aplicada a código.

PROMPT AS CODE

Bem-vindo ao próximo inferno do Change Management. 😂


🗃️ O log que ninguém pode apagar

Se um sistema influencia processos críticos, precisamos conseguir reconstruir acontecimentos.

Qual versão estava ativa?

Qual modelo?

Qual prompt?

Quais documentos foram recuperados?

Qual ranking?

Qual configuração?

Qual usuário fez a consulta?

Qual resposta foi apresentada?

Quais mudanças ocorreram antes?

Isso significa logs.

Mas existe um detalhe:

o administrador investigado não pode ser a única pessoa capaz de administrar os logs da investigação.

Parece óbvio.

Até você conhecer produção.

😂

Logs precisam possuir proteção adequada contra alteração, retenção definida, controles de acesso e auditoria.

Não porque presumimos culpa.

Porque precisamos de forensic readiness.


🧹 Garbage Collection humana

Existe outra coisa que ninguém gosta de fazer:

revogar acesso.

Projeto terminou.

Consultor saiu.

Funcionário mudou de equipe.

Fornecedor trocou.

Administrador mudou de função.

A conta continua.

Seis meses depois:

USER123
STATUS: ENABLED
LAST LOGIN: ???
PRIVILEGE: ADMIN

Quem é USER123?

“Acho que era o Marcelo.”

Quem é Marcelo?

“Terceirizado da consultoria antiga.”

😂😂😂

Meu querido.

REVOKE também é inteligência artificial.


💸 E finalmente: quanto vale aquilo que você sabe?

Essa talvez seja a pergunta que o profissional técnico raramente faz.

Você conhece:

  • arquitetura;

  • parâmetros;

  • vulnerabilidades;

  • comportamento;

  • limitações;

  • atalhos;

  • logs;

  • modelos;

  • integrações.

Normalmente isso é apenas:

conhecimento profissional.

Mas se determinado sistema participa de uma atividade com enorme valor econômico, algumas informações podem adquirir valor fora da organização.

Isso transforma documentação, configuração e conhecimento operacional em ativos de segurança.

E exige:

  • classificação;

  • least privilege;

  • need-to-know;

  • segregação;

  • monitoramento apropriado;

  • políticas de conflito;

  • gestão de terceiros.

Não porque o técnico seja suspeito.

Porque o conhecimento tornou-se valioso.


🧙‍♂️ O sysprog já conhece essa história

Existe algo deliciosamente antigo em tudo isso.

O pessoal do mainframe olha para:

Zero Trust
Privileged Access Management
Segregation of Duties
Immutable Logging
Change Management
Least Privilege

e pensa:

“Vocês inventaram nomes novos para coisas que meu RACF já discutia em 1987.”

😂

A IA judicial pode ser revolucionária.

Mas os fundamentos continuam reconhecíveis.

Quem acessa?

Quem altera?

Quem aprova?

Quem monitora?

Quem audita?

Quem consegue fazer sozinho?

Quem consegue apagar rastros?

Quem sabe informação que não deveria circular?

Essas perguntas sobreviveram a todas as gerações tecnológicas.


⚠️ Não coloque ética como requisito não funcional número 47

Outro perigo clássico:

REQUISITOS NÃO FUNCIONAIS

RNF01 Performance
RNF02 Disponibilidade
RNF03 Segurança
...
RNF47 Ética

😂

Não.

Quando um sistema participa de infraestrutura pública crítica, governança precisa entrar na arquitetura.

Não depois.

Não na apresentação.

Não na política corporativa que ninguém lê.

Na arquitetura.


🔥 O ticket de hoje pode virar a perícia de amanhã

Essa talvez seja a mensagem mais importante para quem está no chão da fábrica.

Você abre:

JIRA-84721

“Ajustar relevância da busca semântica.”

Parece pequeno.

Mas sistemas críticos possuem memória.

Daqui a três anos alguém pode perguntar:

Quem solicitou?

Quem implementou?

Quem aprovou?

Quais testes foram executados?

Por que esse valor?

Qual efeito foi observado?

Podemos reproduzir?

E aí existe uma diferença enorme entre:

"ajustamos porque parecia melhor"

e:

CHANGE-84721
Requisito: ...
Benchmark: ...
Teste adversarial: ...
Aprovação: ...
Deploy: ...
Resultado: ...
Rollback: ...

O segundo é chato.

O segundo salva carreiras.


☕ A pergunta que o analista deveria fazer

Quando receber aquele requisito:

“Implementar IA para auxiliar análise documental.”

não pergunte apenas:

“Qual modelo?”

Pergunte:

“Qual é a consequência se esse sistema estiver errado?”

Depois:

“Qual é a consequência se alguém descobrir como fazê-lo errar?”

E finalmente:

“Qual é a consequência se alguém descobrir como fazê-lo funcionar melhor para um usuário do que para outro?”

Essa terceira pergunta é a mais interessante.

Porque talvez o maior risco não seja a IA produzir uma resposta completamente absurda.

Isso todo mundo percebe.

O risco mais sofisticado é produzir uma diferença pequena, consistente e explorável.


🧑‍💻 Você não está construindo apenas software

Essa frase parece dramática.

E é deliberadamente.

Se você trabalha numa ferramenta de entretenimento, uma falha pode recomendar um filme ruim.

Se trabalha num e-commerce, uma falha pode ordenar produtos incorretamente.

Se trabalha num banco, pequenas decisões de software podem movimentar dinheiro.

Se trabalha numa infraestrutura pública crítica, pequenas decisões podem tocar direitos.

Por isso contexto importa.

O mesmo:

IF X > Y

pode ser irrelevante num sistema e crítico em outro.

Código não possui ética sozinho.

Contexto dá consequência ao código.


🧙‍♂️ O insider do século XXI talvez esteja sentado no seu squad

Não estou falando de criminoso.

Estou falando de conhecimento.

O desenvolvedor sabe uma coisa.

O DBA sabe outra.

O cientista de dados sabe outra.

O DevOps sabe outra.

O arquiteto consegue juntar algumas.

O fornecedor possui outras peças.

E alguém pode eventualmente possuir conhecimento suficiente para dizer:

“Eu sei como essa máquina lê.”

No século XX, informação privilegiada frequentemente significava:

“Eu sei antes.”

Na era dos dados:

“Eu tenho informação que você não possui.”

Na era algorítmica:

“Eu sei como você será classificado.”

Na era da IA:

“Eu sei como a máquina vai interpretar aquilo que você enviar.”

Quando essa interpretação participa de uma atividade economicamente valiosa, o conhecimento sobre ela também pode adquirir valor.


⚖️ E isso não é problema do jurídico

É nosso também.

Não adianta o jurídico criar uma política perfeita se:

admin/admin

continua funcionando.

Não adianta criar comissão de ética se ninguém versiona prompts.

Não adianta falar de transparência se ninguém consegue reproduzir a saída de três meses atrás.

Não adianta prometer imparcialidade se documentos semanticamente equivalentes produzem comportamentos radicalmente diferentes.

Não adianta colocar “Human in the Loop” no PowerPoint se o humano recebe apenas o resumo produzido pela máquina e nunca consegue enxergar como aquele resumo foi construído.

Governança precisa compilar.


☕ O último café antes do deploy

São 18h42.

Finalmente você terminou o ticket.

Pipeline verde.

Testes passaram.

Sonar feliz.

Container subiu.

Observabilidade funcionando.

O gerente pergunta:

“Podemos colocar em produção?”

Você olha novamente:

chunk_size: 1000
chunk_overlap: 150
top_k: 10
similarity_threshold: 0.72

Ontem aquilo era apenas configuração.

Hoje você percebe outra coisa.

Cada parâmetro representa uma decisão sobre como informação será encontrada, organizada e apresentada.

E naquele sistema informação pode participar de algo muito maior que software.

Você toma o último gole de café.

E antes de clicar em DEPLOY, faz uma pergunta que talvez devesse estar impressa em toda sala onde IA crítica é construída:

“Se alguém tivesse milhões de reais de incentivo para descobrir como explorar aquilo que estou colocando em produção, eu continuaria confortável com esta arquitetura?”

Se a resposta for sim:

deploy.

Se for não:

chame segurança.

Chame arquitetura.

Chame jurídico.

Chame governança.

Chame o Red Team.

E, pelo amor de Grace Hopper...

não coloque TODO: corrigir depois e mande para produção.

Porque naquela madrugada o ticket pode ser apenas JIRA-84721.

Daqui a alguns anos ele pode aparecer numa tela completamente diferente:

EVIDÊNCIA Nº 84721

☕🧙‍♂️⚖️💻

No mundo da IA crítica, o chão da fábrica também faz parte da governança.

terça-feira, 11 de agosto de 2026

Kubernetes para COBOLzeiros: o Guia do Mochileiro das Galáxias para quem saiu do JES2, encontrou um Pod e perguntou onde diabos colocaram o JCL

 

Bellacosa Mainframe apresenta kubernetes para coboleiros

☕ Um Café no Bellacosa Mainframe

Kubernetes para COBOLzeiros: o Guia do Mochileiro das Galáxias para quem saiu do JES2, encontrou um Pod e perguntou onde diabos colocaram o JCL

🚀 Pods, Deployments, Services, YAML, containers, RBAC, storage, GitOps e a estranha descoberta de que o mundo cloud-native passou décadas reinventando problemas que o velho operador do mainframe já conhecia — só que agora tudo tem nomes novos, logos simpáticos e pode desaparecer antes do café esfriar

Há uma frase impressa em letras grandes e amistosas na capa do Guia do Mochileiro das Galáxias:

NÃO ENTRE EM PÂNICO.

Se Douglas Adams tivesse vivido tempo suficiente para trabalhar com Kubernetes, provavelmente acrescentaria uma segunda:

E NÃO APAGUE O NAMESPACE prod.

Porque Kubernetes tem uma característica curiosa.

Quando você olha pela primeira vez, encontra palavras como:

Pod, Deployment, ReplicaSet, Service, Ingress, ConfigMap, Secret, StatefulSet, DaemonSet, Helm, Operator, CRD.

O COBOLzeiro veterano olha aquilo e pensa:

— Meu Deus. Inventaram outra computação.

Não inventaram.

Mudaram a arquitetura, mudaram a escala, mudaram a implementação, inventaram abstrações extremamente poderosas e deram nomes diferentes a problemas que, em muitos casos, nós já enfrentávamos quando o terminal ainda era verde.

Precisamos executar programas.

Precisamos saber onde executá-los.

Precisamos distribuir recursos.

Precisamos armazenar configurações.

Precisamos controlar acesso.

Precisamos monitorar aplicações.

Precisamos guardar dados.

Precisamos recuperar processos que morreram.

Precisamos instalar novas versões sem transformar terça-feira à noite numa reunião extraordinária com 27 pessoas.

E, acima de tudo:

precisamos impedir que alguma coisa quebrou às 02:47 da manhã sem ninguém saber por quê.

Então pegue sua toalha, seu café e talvez aquele manual de JCL que você insiste em manter na gaveta.

Hoje vamos viajar para Kubernetes.


1. Antes de Kubernetes havia... computadores

Vamos começar pelo começo.

Um programador COBOL iniciante conhece aproximadamente este universo:

Programa COBOL
      |
      v
Compilação
      |
      v
LOAD MODULE
      |
      v
JCL
      |
      v
JES
      |
      v
Execução

Naturalmente estou simplificando.

Mas existe uma ideia importante:

o programa precisa de um ambiente para executar.

Ele precisa de CPU, memória, arquivos, bibliotecas, configuração, permissões e recursos.

Isso nunca desapareceu.

No universo moderno surgiu outro problema.

Imagine uma aplicação desenvolvida em determinado ambiente:

Aplicação
+
bibliotecas
+
runtime
+
dependências
+
configuração

Na máquina do desenvolvedor funciona perfeitamente.

Vai para outro servidor:

ABEND GALÁCTICO

— Mas na minha máquina funciona!

Essa frase provavelmente causou mais sofrimento humano que Vogons lendo poesia.

Uma das respostas modernas para esse problema foram os containers.


2. Container: coloque a aplicação numa caixinha

De maneira bastante simplificada, um container empacota a aplicação e aquilo de que ela precisa para executar de forma consistente.

Pense:

+----------------------+
|      CONTAINER       |
|                      |
| aplicação            |
| runtime              |
| bibliotecas          |
| dependências         |
|                      |
+----------------------+

Isso melhora enormemente a portabilidade.

Mas imediatamente surge outro problema.

Você possui:

1 container

Tudo maravilhoso.

Depois:

10 containers

Administrável.

Depois:

100 containers

Interessante.

Depois:

3.000 containers

Alguém pergunta:

— Quem administra isso?

Silêncio na sala.

É nesse momento que Kubernetes entra pela porta.


3. Kubernetes não é simplesmente um “Docker grandão”

Essa comparação ajuda durante cinco minutos e depois começa a atrapalhar.

Kubernetes é uma plataforma para orquestração de workloads containerizadas.

A palavra mágica é:

ORQUESTRAÇÃO

Imagine uma orquestra com 200 músicos.

O maestro não toca simultaneamente todos os instrumentos.

Ele coordena o conjunto.

Kubernetes tenta responder perguntas como:

  • onde uma aplicação será executada?

  • quantas cópias dela devem existir?

  • o que fazer quando uma morre?

  • como encontrar essas cópias?

  • como distribuir tráfego?

  • como atualizar uma versão?

  • como fornecer configuração?

  • como controlar recursos?

  • como armazenar dados persistentes?

  • quem pode alterar o quê?

Isso já começa a parecer menos alienígena para alguém vindo de ambientes corporativos.


4. A ideia que muda tudo: estado desejado

Aqui está provavelmente o conceito mais importante de Kubernetes.

Você declara aquilo que deseja.

Por exemplo:

replicas: 3

Traduzindo para português de máquina do café:

“Senhor Kubernetes, eu gostaria que existissem três instâncias dessa aplicação.”

Ele observa:

DESEJADO = 3
ATUAL    = 3

Tudo certo.

Então uma delas morre:

DESEJADO = 3
ATUAL    = 2

Kubernetes percebe:

— Isso não está certo.

E tenta retornar para:

3

Esse processo é chamado, em essência, de reconciliação.

Podemos imaginar:

Estado desejado
      |
      v
Estado atual
      |
      v
São iguais?
  /       \
SIM       NÃO
 |         |
OK      corrigir
           |
           +------+
                  |
                  v
              observar
              novamente

Kubernetes é, em grande parte, uma enorme máquina dizendo:

“O universo não está como deveria estar. Vou tentar consertá-lo.”

É uma ambição que normalmente encontramos apenas em sistemas distribuídos, religiões e departamentos de arquitetura corporativa.


5. Control Plane: conheça o cérebro da criatura

Um cluster Kubernetes pode ser imaginado assim:

                 KUBERNETES CLUSTER
                        |
           +------------+------------+
           |                         |
     CONTROL PLANE              WORKER NODES
           |                         |
     API Server                    Pods
     Scheduler                     kubelet
     Controllers                   runtime
     etcd                          network

O Control Plane administra o estado do cluster.

E um dos personagens principais é:

kube-apiserver

Quando você executa:

kubectl get pods

não está indo de porta em porta perguntar aos containers:

— Boa tarde, senhor Pod, o senhor está vivo?

Você fala com a API do Kubernetes.

Conceitualmente:

VOCÊ
 |
kubectl
 |
 v
API SERVER
 |
 +-- autenticação
 +-- autorização
 +-- validação
 +-- recursos do cluster

Esse detalhe revela uma característica fundamental:

Kubernetes é profundamente API-driven.


6. etcd: o sujeito que sabe das coisas

O etcd é um armazenamento distribuído chave-valor usado pelo Kubernetes para guardar dados essenciais sobre o estado do cluster.

Imagine que alguém diga:

— Temos backup dos servidores.

Ótimo.

— E do etcd?

Silêncio.

Uma mosca passa.

O operador começa lentamente a beber o café.

Informações críticas do estado do cluster dependem dele. Portanto backup e recuperação do etcd são assuntos sérios.

Primeira regra da produção:

Backup que nunca teve restauração testada é uma crença religiosa.


7. Scheduler: o JES encontrou um primo distante

Você solicita uma workload.

Existem vários Nodes:

NODE-A
NODE-B
NODE-C
NODE-D

Onde ela será executada?

O Scheduler participa dessa decisão.

Ele considera recursos e restrições como:

CPU
memória
afinidade
anti-afinidade
taints
tolerations
restrições de placement

O COBOLzeiro começa a sorrir.

— Espere... alguém recebe uma carga de trabalho, olha recursos e decide onde executar?

Sim.

— Então é JES?

NÃO.

Guarde a toalha.

As tecnologias, arquiteturas e responsabilidades são diferentes.

Mas existe um parentesco conceitual extremamente útil para aprender.

O truque para um profissional experiente aprender tecnologia nova não é fingir que tudo é completamente novo.

É perguntar:

“Qual problema antigo essa abstração está tentando resolver de uma maneira nova?”


8. Worker Node: onde a marmota realmente trabalha

O Control Plane coordena.

Os Worker Nodes executam as workloads.

Dentro deles encontramos componentes como o kubelet, runtime de containers e elementos relacionados a networking.

Podemos imaginar:

WORKER NODE
 |
 +-- kubelet
 |
 +-- runtime
 |
 +-- POD
 |    |
 |    +-- container
 |
 +-- POD
      |
      +-- container

E aqui encontramos talvez a palavra mais famosa do Kubernetes.


9. POD — não é ervilha espacial

O Kubernetes não trabalha simplesmente administrando containers isoladamente.

Uma unidade fundamental de execução é o:

Pod

Normalmente encontramos:

Pod
 |
 +-- Container

Mas um Pod pode possuir mais de um container quando existe uma razão arquitetural para isso:

Pod
 |
 +-- aplicação
 |
 +-- container auxiliar

Containers no mesmo Pod compartilham aspectos importantes de seu ambiente.

Portanto:

POD != CONTAINER

Grave isso.

Pode parecer uma distinção acadêmica no primeiro dia.

No vigésimo ela salva sua compreensão do ambiente.


10. E o Pod morreu

Aqui acontece uma transformação filosófica interessante para quem passou décadas tratando servidores como indivíduos.

No mundo tradicional:

“Esse é o servidor XPTO01. Cuide dele.”

No Kubernetes, muita infraestrutura é tratada como efêmera.

O Pod morreu?

Pode surgir outro.

Hoje:

Pod A
10.20.1.17

Amanhã:

Pod A = morto

Pod B
10.20.4.38

Por isso construir dependências baseadas diretamente na identidade transitória de um Pod seria uma péssima ideia.

Precisamos de abstrações.


11. ReplicaSet: quero três vivos

Imagine:

Desejado = 3 Pods

Temos:

Pod
Pod
Pod

Um desaparece:

Pod
X
Pod

O ReplicaSet ajuda a manter:

3

criando outro.

Aqui reencontramos nosso velho amigo:

estado desejado.


12. Deployment: agora precisamos atualizar tudo

Na prática, para aplicações comuns, normalmente trabalhamos com um Deployment, que administra ReplicaSets e facilita rollouts.

Imagine:

Deployment
    |
ReplicaSet V1
    |
 +-- Pod
 +-- Pod
 +-- Pod

Sai versão nova.

Em vez de:

PARE TUDO!

podemos fazer uma substituição progressiva:

V1  V1  V1

V2  V1  V1

V2  V2  V1

V2  V2  V2

Isso é tremendamente importante em ambientes modernos onde deploys podem ocorrer com frequência.

E quando algo dá errado?

Rollback passa a fazer parte da conversa.


13. Service: “mas qual IP eu chamo?”

Lembra que Pods podem desaparecer?

Temos:

Frontend
    |
    ???
    |
Backend Pods

Como o frontend encontra o backend se os Pods mudam?

Usamos uma abstração chamada:

Service

CLIENTE
   |
   v
SERVICE
   |
   +---- Pod
   |
   +---- Pod
   |
   +---- Pod

O Service fornece um ponto lógico estável para acessar um conjunto de Pods selecionados.

Aqui existe uma das ideias mais bonitas do cloud-native:

colocar identidade lógica estável diante de componentes fisicamente transitórios.


14. ConfigMap: não coloque o universo dentro do programa

Aplicações precisam de configurações:

LOG_LEVEL=INFO
LANGUAGE=PT_BR
API_HOST=...

Você poderia colocar tudo dentro da imagem.

Mas então qualquer mudança exigiria outra construção da imagem.

ConfigMaps permitem separar parte da configuração da aplicação.

É uma evolução daquele princípio antigo:

programa é uma coisa; parâmetros do ambiente são outra.

COBOLzeiro conhece essa conversa há décadas, mesmo usando mecanismos completamente diferentes.


15. Secret: o nome promete mais do que parece

Temos informações sensíveis:

senha
token
chave
certificado

Kubernetes possui o objeto Secret.

Mas cuidado com uma armadilha clássica:

Um objeto chamado Secret não significa automaticamente “segredo absolutamente protegido contra tudo”.

Segurança adequada envolve também:

  • RBAC;

  • criptografia em repouso;

  • proteção do etcd;

  • controle de Service Accounts;

  • secret managers;

  • rotação;

  • auditoria;

  • mínimo privilégio.

Colocar a senha em Secret e declarar vitória é como escrever:

//PASSWORD DD *
SUPERSECRETA123
/*

e colocar uma etiqueta dizendo CONFIDENCIAL.

A etiqueta não é o controle de segurança.


16. Storage: containers morrem; saldo bancário não deveria

Containers são naturalmente descartáveis.

Dados empresariais frequentemente não são.

Imagine:

Banco de dados
     |
 container
     |
   morreu

Kubernetes responde:

— Sem problemas, fazemos outro!

O DBA responde:

— E MEUS DADOS?

E nesse instante nasce uma reunião.

Para persistência encontramos conceitos como:

PersistentVolume
PersistentVolumeClaim
StorageClass

Simplificando:

POD
 |
PVC
 |
PV
 |
STORAGE REAL

O Pod pode ser transitório.

O armazenamento precisa seguir regras diferentes.


17. StatefulSet: quando identidade importa

Deployments funcionam muito bem quando as instâncias podem ser relativamente intercambiáveis.

Mas nem toda workload funciona assim.

Algumas precisam de identidade previsível:

db-0
db-1
db-2

e armazenamento associado.

Aparece então o:

StatefulSet

Ele é especialmente relevante para workloads stateful e sistemas distribuídos que precisam de identidade e ordenação mais previsíveis.

Isso não significa:

“StatefulSet transforma magicamente qualquer banco em banco cloud-native.”

Se fosse tão fácil, DBA seria uma profissão de seis minutos.


18. DaemonSet: um para cada Node

Imagine um agente de monitoramento que precisa existir em todos os Nodes:

NODE A → agente
NODE B → agente
NODE C → agente
NODE D → agente

O DaemonSet serve muito bem para esse padrão.

Aplicações típicas incluem agentes de:

  • observabilidade;

  • logging;

  • segurança;

  • networking.

Quando surge outro Node, a intenção pode ser automaticamente refletida nele.

Estado desejado novamente.

Kubernetes é quase obsessivo.


19. Jobs e CronJobs: o COBOLzeiro reconhece um parente

Nem tudo precisa ficar executando eternamente.

Temos tarefas:

INÍCIO
 |
PROCESSAMENTO
 |
FIM

Kubernetes possui Jobs.

E para tarefas periódicas:

CronJobs

O COBOLzeiro imediatamente pergunta:

— Então isso é batch?

Em espírito, estamos no mesmo bairro.

Mas não na mesma casa.

Um Job Kubernetes não substitui automaticamente décadas de ecossistema batch corporativo, scheduling, dependências, restart/recovery, controles operacionais e processamento transacional.

Ainda assim, a analogia ajuda enormemente:

Job → trabalho finito

CronJob → trabalho agendado

20. Requests e Limits: WLM manda lembranças

Aqui chegamos a uma área deliciosa para quem conhece mainframe.

Uma workload pode declarar algo semelhante a:

resources:
  requests:
    cpu: "500m"
    memory: "512Mi"
  limits:
    cpu: "1"
    memory: "1Gi"

Simplificando, requests ajudam a expressar recursos necessários para scheduling; limits impõem tetos de utilização conforme o recurso.

A pergunta filosófica é antiga:

Temos recursos finitos e consumidores potencialmente infinitos. Quem recebe quanto?

O mainframe possui décadas de engenharia sofisticadíssima em workload management.

Kubernetes aborda isso dentro de seu próprio modelo.

Não diga:

Kubernetes WLM = IBM WLM

Não são equivalentes.

Diga:

Ambos enfrentam aspectos do velho problema de administrar recursos compartilhados e workloads concorrentes.

Essa comparação ensina.

A equivalência enganaria.


21. Agora chegamos ao inferno: produção

Até aqui tudo funciona.

Tutorial:

pod/myapp created

Aluno:

— Kubernetes é fácil!

Produção:

CrashLoopBackOff

Aluno:

— Chamem um adulto.

E aqui começa o verdadeiro treinamento.

Você precisa conhecer:

  • logs;

  • events;

  • probes;

  • métricas;

  • CPU;

  • memória;

  • DNS;

  • networking;

  • storage;

  • permissões;

  • dependências;

  • configuração.

Porque:

CrashLoopBackOff

não significa:

“Execute o comando secreto número 17.”

Significa que existe um comportamento de reinício repetido a investigar.

A causa pode ser:

configuração errada
dependência indisponível
credencial
permissão
OOM
bug
porta
DNS
storage
probe

É quase o nosso querido:

S0C7

O código oferece uma pista.

Mas experiência transforma a pista em investigação.


22. Observabilidade: o cluster precisa falar

Imagine:

Usuário
  |
Ingress
  |
Service
  |
Pod
  |
Aplicação
  |
API
  |
Banco

Usuário diz:

“Está lento.”

Maravilha.

Onde?

Precisamos de diferentes sinais:

METRICS
LOGS
TRACES
EVENTS

Não basta saber que um Pod está Running.

Um processo pode estar vivo e a aplicação completamente inútil.

É por isso que existem conceitos como:

liveness probe e readiness probe.

De forma simplificada:

Liveness:
"Você ainda está vivo?"

Readiness:
"Você está pronto para receber tráfego?"

São perguntas diferentes.

Um sujeito pode estar vivo às seis da manhã e absolutamente não estar pronto para receber tráfego.

Eu sou prova disso antes do café.


23. RBAC: RACF olha pela janela

RBAC significa Role-Based Access Control.

A pergunta é familiar:

QUEM
 |
pode fazer
 |
O QUÊ
 |
sobre QUAL RECURSO?

Exemplo:

PROGRAMADOR
 |
 +--> visualizar Pods       SIM
 +--> consultar logs        SIM
 +--> destruir cluster      NÃO, ESPERAMOS

Quem conhece RACF encontra aqui outra ponte conceitual.

RBAC não é RACF.

Mas autorização baseada em identidades, recursos, permissões e mínimo privilégio definitivamente não nasceu ontem.


24. NetworkPolicy: “você não precisa conversar com ele”

Imagine:

FRONTEND
    |
BACKEND
    |
DATABASE

O frontend precisa realmente acessar diretamente o banco?

Talvez não.

Então podemos desejar:

Frontend ---> Backend     OK
Frontend -X-> Database    NÃO

Backend ----> Database    OK

Network Policies permitem controlar fluxos de rede entre workloads quando suportadas adequadamente pelo ambiente de networking.

Aqui começamos a caminhar em direção a arquiteturas mais próximas do princípio de:

negue aquilo que não é necessário.


25. Helm: porque 47 YAMLs também cansam

No início temos:

deployment.yaml

Depois:

deployment.yaml
service.yaml
configmap.yaml
ingress.yaml
secret.yaml
pvc.yaml
...

Em determinado momento alguém pergunta:

— Não poderíamos empacotar isso?

Entra Helm.

Helm trabalha com Charts, templates e valores configuráveis.

Conceitualmente:

Chart
 |
 +-- templates
 |
 +-- values
 |
 +-- metadata

E aqui ocorre um ritual iniciático cloud-native:

  1. você aprende YAML;

  2. aprende templates;

  3. aprende templates que produzem YAML;

  4. recebe uma mensagem de erro;

  5. olha para o teto;

  6. reconsidera decisões profissionais;

  7. resolve;

  8. coloca no LinkedIn.


26. CRD: “eu também posso inventar objetos?”

Sim.

Uma das capacidades mais interessantes do Kubernetes são as Custom Resource Definitions.

Originalmente você trabalha com recursos como:

Pod
Service
Deployment

Com CRDs podemos estender a API com recursos específicos.

Conceitualmente:

Database
Certificate
KafkaCluster
Backup
MeuObjetoCorporativo

Isso revela que Kubernetes é mais que um mero lançador de containers.

Ele oferece uma espécie de framework declarativo extensível para sistemas de controle.

Essa mudança mental é importante.


27. Operator: o runbook ganhou pernas

Imagine o velho especialista.

Ele sabe:

SE A acontecer
   verifique B

SE B estiver assim
   execute C

SE C falhar
   tente D

Décadas de conhecimento operacional.

Um Operator tenta codificar conhecimento operacional específico usando o modelo de controllers e reconciliação do Kubernetes.

Simplificando:

Conhecimento operacional
          |
          v
       código
          |
          v
      Operator
          |
          v
observa → decide → reconcilia

É como se parte do runbook ganhasse vida.

Não elimina o especialista.

Muda o lugar onde parte do conhecimento dele vive.


28. CI/CD: ninguém deveria levar o deploy num disquete

O próximo passo natural é automação.

Temos:

Código
 |
Git
 |
Build
 |
Teste
 |
Imagem
 |
Registry
 |
Deploy
 |
Kubernetes

Entramos no território de CI/CD.

E depois aparece GitOps.

Em vez de alguém alterar manualmente produção:

OPERADOR
 |
kubectl
 |
PRODUÇÃO

podemos trabalhar com um modelo no qual o Git representa o estado desejado relevante:

Developer
   |
   v
  Git
   |
Pull Request
   |
Review
   |
   v
GitOps Controller
   |
   v
Cluster

Isso melhora possibilidades de:

  • rastreabilidade;

  • auditoria;

  • revisão;

  • versionamento;

  • recuperação;

  • consistência.

Mas lembre-se:

automatizar processo ruim produz desastre em velocidade industrial.


29. O que aquele roadmap deveria mostrar antes do Kubernetes

Aqui está minha principal crítica à figura.

Eu colocaria uma Fase Zero:

FASE ZERO

Linux
  |
processos
  |
filesystem
  |
CPU/memória
  |
networking
  |
TCP/IP
  |
DNS
  |
HTTP
  |
TLS
  |
containers
  |
images
  |
runtime
  |
KUBERNETES

Por quê?

Porque Kubernetes não aboliu o sistema operacional.

Nem aboliu rede.

Nem DNS.

Especialmente DNS.

Existe um antigo espírito maligno vagando pelos datacenters dizendo:

“It's always DNS.”

Quando você acha que não é DNS, eventualmente descobre que era DNS usando bigode falso.


30. Networking merece uma fase própria

Eu ampliaria o roadmap para incluir profundamente:

IP
CIDR
TCP
UDP
DNS
NAT
routing
TLS
Load Balancing
ClusterIP
NodePort
LoadBalancer
Ingress
CNI
NetworkPolicy

Porque um dos incidentes mais frustrantes é:

Pod: Running
Application: Healthy
Service: Exists

Usuário: NÃO FUNCIONA.

Então começa a expedição arqueológica.


31. Segurança de supply chain também precisa entrar

Em 2026 não basta perguntar:

“A imagem funciona?”

Precisamos perguntar:

Quem construiu essa imagem?
De onde veio?
Qual imagem base foi usada?
Possui vulnerabilidades?
Tem SBOM?
Foi assinada?
Quem pode publicar?
Foi adulterada?

Ou seja, o roadmap moderno precisa incluir:

  • scanning;

  • provenance;

  • SBOM;

  • assinatura;

  • admission policies;

  • least privilege;

  • gestão de secrets;

  • identidade de workloads;

  • atualização segura.

O container é conveniente justamente porque carrega muita coisa consigo.

E tudo aquilo que carregamos conosco também pode carregar problemas.


32. E o mainframe no meio dessa galáxia?

Aqui existe uma oportunidade fantástica para o COBOLzeiro.

Não pense:

Kubernetes
VERSUS
Mainframe

Pense:

                 INTERNET
                    |
              KUBERNETES
                    |
              APIs / serviços
                    |
          +---------+---------+
          |                   |
       CLOUD              MAINFRAME
                           |
                   +-------+-------+
                   |       |       |
                  CICS    IMS     Db2
                   |
                 COBOL

Kubernetes não precisa destruir o mainframe para justificar sua existência.

Um banco pode perfeitamente ter sistemas transacionais críticos em IBM Z enquanto utiliza Kubernetes para APIs, integração, canais digitais, serviços distribuídos, observabilidade e outras workloads.

O mundo corporativo real é híbrido.

A Millennium Falcon também não foi construída inteira pela mesma consultoria.

Provavelmente por isso funcionava.


33. O laboratório que eu faria para um COBOLzeiro

Aqui está o caminho prático.

Não faça 25 tutoriais desconectados.

Construa uma aplicação e faça-a evoluir.

Chamaremos:

BELLACOSA INTERGALACTIC BANK

Versão 1:

Frontend

Versão 2:

Frontend
   |
Backend

Versão 3:

Frontend
   |
Service
   |
Backend

Versão 4:

Ingress
   |
Frontend
   |
Service
   |
Backend
   |
Database

Depois acrescente:

ConfigMap
Secrets
PVC
Requests
Limits
Probes
RBAC
NetworkPolicy
Monitoring
Logging

Depois:

CI/CD

Depois:

GitOps

E somente então:

Helm
Operators
CRDs

Não tente aprender a galáxia inteira antes de visitar a Lua.


34. Agora destrua tudo

Esta é a etapa que falta em muitos cursos.

Faça o Pod morrer.

kubectl delete pod ...

Observe o que acontece.

Coloque memória insuficiente.

Quebre uma configuração.

Use uma imagem inexistente.

Quebre uma readiness probe.

Remova uma permissão.

Altere uma NetworkPolicy.

Crie problema de storage.

Observe:

Pending
ImagePullBackOff
CrashLoopBackOff
OOMKilled
Forbidden
Readiness probe failed

Para cada incidente pergunte:

O QUE aconteceu?

POR QUE aconteceu?

QUAL componente percebeu?

QUAL estado era desejado?

QUAL estado existia?

QUEM tentou reconciliar?

ONDE encontro evidência?

COMO evitar novamente?

Esse exercício ensina dez vezes mais do que decorar cinquenta comandos.


35. O COBOLzeiro possui uma vantagem escondida

O programador COBOL iniciante talvez olhe Kubernetes e pense que está começando do zero.

Não está.

Se ele está aprendendo o ecossistema mainframe simultaneamente, já está entrando em contato com perguntas universais:

Como programas são executados?

Como recursos são alocados?

Como identidade funciona?

Como permissões são verificadas?

Como dados persistem?

Como jobs são agendados?

Como falhas são diagnosticadas?

Como mudanças chegam à produção?

Como recuperamos alguma coisa que quebrou?

Essas perguntas atravessaram gerações de computadores.

As respostas mudaram.

As perguntas continuam surpreendentemente parecidas.


36. A tabela de tradução intergaláctica

Não como equivalência técnica, mas como pontes mentais:

Universo MainframeUniverso KubernetesIdeia em comum
JES/schedulingScheduler/Jobsexecução organizada de workloads
JCL/parâmetrosmanifests/configuraçãodeclarar como executar
PROCtemplates/Helmreutilização
RACFRBACautorização
WLMrequests/limits/schedulinggestão de recursos
Started Tasksserviços/workloads contínuasprocessos duradouros
Scheduler batchCronJobexecução periódica
datasets/storagePV/PVCpersistência
Sysplex/HAcluster/replicasdisponibilidade
SMF/RMF/logsmetrics/logs/tracesobservabilidade
RunbookOperatorconhecimento operacional

Novamente:

não são equivalentes.

Essa tabela é mapa turístico, não especificação de arquitetura.

Se você tentar usar um mapa turístico para fazer cirurgia, o resultado será digno dos Vogons.


37. Do iniciante ao arquiteto

Existe uma progressão interessante.

Nível 1

O aluno pergunta:

“Como crio um Pod?”

Nível 2

Pergunta:

“Como faço três réplicas?”

Nível 3

Pergunta:

“Por que esse Pod morreu?”

Nível 4

Pergunta:

“Por que ele continua morrendo?”

Nível 5

Pergunta:

“Por que nossa arquitetura permitiu que a morte desse Pod afetasse usuários?”

Nível 6

Pergunta:

“Como eliminamos essa classe inteira de falhas?”

Essa é a transformação.

COMANDO
   ↓
OBJETO
   ↓
PLATAFORMA
   ↓
OPERAÇÃO
   ↓
ARQUITETURA
   ↓
ENGENHARIA DE RESILIÊNCIA

38. Easter Egg: Kubernetes e o número 42

No Guia do Mochileiro das Galáxias, a resposta para a Grande Questão da Vida, do Universo e Tudo Mais é:

42

Depois descobriram que ninguém sabia exatamente qual era a pergunta.

Kubernetes possui uma versão corporativa disso.

O arquiteto pergunta:

— Quantas réplicas precisamos?

Consultor:

— Três.

— Por quê?

— Alta disponibilidade.

— Baseado em qual cálculo?

— ...

— Tráfego?

— ...

— SLO?

— ...

— capacidade?

— ...

— histórico de falhas?

— ...

— teste de carga?

— ...

Três virou o 42 da arquitetura cloud-native.

😆

A lição é excelente:

uma resposta tecnicamente plausível sem a pergunta correta continua sendo apenas uma resposta procurando uma justificativa.


39. Outra curiosidade: Kubernetes significa timoneiro

O nome vem do grego e remete à ideia de timoneiro/piloto.

Daí também o famoso leme no logotipo.

E isso é poeticamente perfeito.

Kubernetes não é o navio.

Não é a carga.

Não é o oceano.

Ele ajuda a conduzir a embarcação.

Só existe um detalhe que nenhum tutorial coloca em letras suficientemente grandes:

você ainda precisa saber navegar.

Kubernetes não elimina a necessidade de conhecer Linux, redes, storage, segurança, aplicações e sistemas distribuídos.

Na realidade, em ambientes complexos ele pode exigir que você compreenda um pouco de todos eles simultaneamente.


40. O segredo final do roadmap

A imagem original termina aproximadamente com a ideia:

consistência + prática = especialista Kubernetes.

Eu acrescentaria algumas variáveis:

TEORIA
   +
PRÁTICA
   +
ERRO
   +
OBSERVAÇÃO
   +
TROUBLESHOOTING
   +
DOCUMENTAÇÃO
   +
CURIOSIDADE
   +
INCIDENTES
   +
CAFÉ
   =
EXPERIÊNCIA

Principalmente os erros.

Porque executar:

kubectl get pods

é fácil.

Interpretar:

NAME             READY   STATUS
app-7d98         0/1     CrashLoopBackOff

é outra história.

E descobrir que o Pod não era a causa, que a aplicação estava falhando porque não conseguia alcançar uma dependência, que a dependência estava inacessível por causa de uma alteração de rede introduzida no deploy anterior...

Aí temos engenharia.


☕ Epílogo — O COBOLzeiro pega sua toalha

Nosso programador começou a viagem olhando para um roadmap colorido e pensando:

“Pod? Helm? Ingress? CRD? Operator? Eu só queria aprender Kubernetes.”

Agora ele sabe que Kubernetes não é uma coleção de palavras estranhas.

É uma resposta moderna para um conjunto de problemas profundamente antigos:

executar, distribuir, controlar, proteger, observar, recuperar e evoluir software.

O mainframe resolveu muitos desses problemas dentro de seu próprio universo durante décadas.

Unix resolveu outros.

Cloud resolveu outros.

Containers mudaram novamente a unidade de distribuição.

Kubernetes apareceu para coordenar esse novo zoológico.

E talvez essa seja a maior lição para um programador COBOL entrando no mundo cloud-native:

não jogue fora aquilo que você aprendeu.

Traduza.

Quando encontrar RBAC, lembre-se das perguntas que RACF ensinou a fazer.

Quando encontrar requests e limits, pense nas questões que WLM levanta.

Quando encontrar Jobs, recorde o mundo batch.

Quando encontrar observabilidade, pense em RMF, SMF, logs e diagnóstico.

Quando encontrar Operators, pense no velho runbook do especialista que sabia exatamente o que fazer quando determinada luz vermelha acendia.

Não porque essas tecnologias sejam iguais.

Mas porque a história da computação é cheia de novas respostas para perguntas antigas.

E algum dia, provavelmente às 03:17 da manhã, você encontrará isto:

CrashLoopBackOff

O jovem aprendiz perguntará:

— Mestre, qual comando resolve isso?

Você tomará um gole de café, olhará calmamente para o terminal e responderá:

Nenhum. Primeiro precisamos descobrir o que aconteceu.

Nesse instante terá ocorrido algo muito mais importante que aprender Kubernetes.

Você terá aprendido a pensar como alguém de produção.

E, como diria o Guia do Mochileiro das Galáxias, enquanto o cluster inteiro estiver pegando fogo:

+---------------------------------------+
|                                       |
|          NÃO ENTRE EM PÂNICO          |
|                                       |
|      kubectl get events               |
|                                       |
|          E LEVE UMA TOALHA            |
|                                       |
+---------------------------------------+

☕🚀

Bem-vindo ao Kubernetes, COBOLzeiro.

A galáxia continua distribuída, eventualmente consistente, estranhamente documentada e, por algum motivo que ninguém conseguiu explicar satisfatoriamente, ainda depende de DNS.

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