☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

quinta-feira, 13 de agosto de 2026

O Golpe de Mestre Algorítmico: Teoria dos Jogos, IA Jurídica e o Dia em que o Melhor Prompt Virou Vantagem Competitiva

 


☕ Um Café no Bellacosa Mainframe

O Golpe de Mestre Algorítmico: Teoria dos Jogos, IA Jurídica e o Dia em que o Melhor Prompt Virou Vantagem Competitiva

⚖️ The Sting, COBOL, teoria dos jogos, prompt injection, Legal AI, RAG, tribunais e a estranha descoberta de que, quando máquinas passam a participar da Justiça, escritórios de advocacia começam a disputar não apenas quem convence melhor o juiz — mas quem sabe conversar melhor com a máquina

Imagine a cena.

Chicago, 1936.

Paul Newman está sentado diante de uma mesa.

Robert Redford entra.

Só que não existem cartas.

Não existem cavalos.

Não existe roleta.

Sobre a mesa há dois notebooks, alguns milhares de páginas de jurisprudência, uma API, um banco vetorial, um modelo de linguagem e uma equipe de advogados olhando para uma tela onde aparece:

ANALISANDO DOCUMENTOS...

Newman olha para Redford.

— O que temos?

Redford responde:

— Nosso argumento jurídico é bom.

— E o deles?

— Também.

— Então qual é nossa vantagem?

Redford sorri.

— Nossa IA encontrou 147 precedentes. A deles encontrou 38.

Silêncio.

Newman toma um gole de café.

— Isso é trapaça?

— Não.

— Então continue.

Bem-vindo ao Golpe de Mestre Algorítmico.

E antes que algum advogado atravesse correndo a porta do Bellacosa Mainframe carregando um Vade Mecum e gritando:

“OBJEÇÃO!”

é importante estabelecer a distinção que sustentará todo este artigo:

usar IA melhor que o adversário não é a mesma coisa que manipular ilegalmente um sistema de IA.

Essa fronteira parece óbvia.

Não é.

E quando colocamos sobre a mesa teoria dos jogos, prompt injection, RAG, Legal AI, automação jurídica e a possibilidade de sistemas algorítmicos influenciarem fluxos judiciais, surge um cenário fascinante.

Porque talvez estejamos entrando numa época em que a competência tecnológica de um escritório passe a produzir vantagem competitiva da mesma maneira que durante décadas produziram vantagem:

  • melhores advogados;

  • melhores pesquisadores;

  • melhores bancos de jurisprudência;

  • melhores peritos;

  • melhores contatos;

  • melhores sistemas de gestão;

  • maior capacidade financeira;

  • equipes especializadas.

Só que agora existe um novo jogador sentado à mesa.

A máquina.



🎬 CAPÍTULO I — O golpe começa quando todos conhecem as regras

The Sting, lançado em 1973 e conhecido no Brasil como Golpe de Mestre, é uma deliciosa aula cinematográfica sobre informação assimétrica.

Henry Gondorff e Johnny Hooker não vencem simplesmente porque são mais fortes.

Eles constroem uma situação na qual entendem o jogo melhor que o adversário.

E isso nos leva diretamente à teoria dos jogos.

Em termos extremamente simplificados, podemos imaginar dois escritórios:

ESCRITÓRIO A
ESCRITÓRIO B

Ambos disputam casos semelhantes.

Inicialmente nenhum utiliza IA avançada.

Temos algo parecido com:

                B
             NORMAL
A NORMAL       5,5

Nenhum possui vantagem tecnológica significativa.

Agora A investe pesadamente em IA.

Constrói:

RAG jurídico
+
base jurisprudencial
+
embeddings
+
agentes especializados
+
validação humana
+
pesquisa automatizada
+
análise estatística
+
engenharia de prompts

Enquanto B continua trabalhando essencialmente da maneira tradicional.

Podemos imaginar:

                 B
              NORMAL

A IA            8,3

Não significa que A ganhará automaticamente processos.

Direito não é blackjack.

Mas A poderá potencialmente:

encontrar precedentes mais rapidamente, analisar milhares de documentos, descobrir inconsistências, comparar decisões, identificar argumentos esquecidos, produzir simulações e testar estratégias antes de protocolar qualquer coisa.

A tecnologia alterou o payoff.

E B percebe isso.

O que B fará?

Provavelmente começará a utilizar IA também.

Então chegamos a:

                 B
             NORMAL      IA

A NORMAL       5,5       3,8

A IA           8,3       6,6

Os números são apenas ilustrativos.

O importante é o mecanismo.

Se usar IA produz vantagem competitiva legítima, existe incentivo para sua adoção.

Quando ambos adotam, aquela vantagem extraordinária diminui.

A tecnologia deixa de ser diferencial.

Torna-se infraestrutura.

Foi assim com computadores.

Foi assim com bancos de dados.

Foi assim com internet.

Foi assim com pesquisa jurídica eletrônica.

Pode acontecer exatamente o mesmo com IA.


🖥️ CAPÍTULO II — Bellacosa, que diabos isso tem a ver com COBOL?

Tudo.

Imagine dois bancos em 1985.

Um possui processamento batch eficiente.

O outro possui processamento batch horrível.

O primeiro consegue fechar determinado processamento financeiro em:

2 HORAS

O segundo:

8 HORAS

O primeiro banco está trapaceando?

Claro que não.

Ele possui melhor tecnologia.

Melhores programadores.

Melhores algoritmos.

Melhor arquitetura.

Talvez melhores JCLs.

E provavelmente algum programador COBOL de olheiras profundas chamado Geraldo que sabe que trocar determinado acesso sequencial por um índice correto economizará três horas de processamento.

Geraldo não fraudou o mercado.

Geraldo fez engenharia.

Agora troque:

Geraldo

por:

Legal AI Engineer

E troque:

JCL

por:

RAG + LLM + embeddings + agentes

O princípio econômico permanece assustadoramente parecido.



🤖 CAPÍTULO III — O momento em que a IA deixa de ser Word com esteroides

Aqui começa a parte realmente interessante.

Existe uma enorme diferença entre perguntar:

melhore esta petição

e possuir uma infraestrutura capaz de executar algo parecido com:

PETIÇÃO
   ↓
EXTRAÇÃO DE TESES
   ↓
BUSCA SEMÂNTICA
   ↓
JURISPRUDÊNCIA
   ↓
LEGISLAÇÃO
   ↓
HISTÓRICO PROCESSUAL
   ↓
CONTRADIÇÕES
   ↓
ARGUMENTOS ADVERSÁRIOS
   ↓
CONTRA-ARGUMENTOS
   ↓
VALIDAÇÃO DAS FONTES
   ↓
ADVOGADO

Isso é outro animal.

O escritório tecnologicamente sofisticado não terá simplesmente um chatbot.

Terá uma pipeline jurídica.

O programador mainframe reconhecerá imediatamente o conceito.

É praticamente um batch.

STEP010 - INGESTÃO
STEP020 - CLASSIFICAÇÃO
STEP030 - RETRIEVAL
STEP040 - INFERÊNCIA
STEP050 - VALIDAÇÃO
STEP060 - RANKING
STEP070 - HUMAN REVIEW

E aqui surge uma profissão interessantíssima.

O antigo técnico de informática do escritório começa lentamente a atravessar a parede entre TI e Direito.

Porque alguém precisará entender:

  • contexto;

  • segurança;

  • proveniência;

  • embeddings;

  • bancos vetoriais;

  • controle de acesso;

  • RAG;

  • agentes;

  • logs;

  • auditoria;

  • versionamento;

  • ataques adversariais;

  • avaliação de modelos.

O sujeito que em 2005 era chamado porque:

“a impressora do doutor não imprime”

pode acabar em 2030 ouvindo:

“precisamos saber por que o agente classificou estes precedentes como relevantes.”

Isso é uma mudança brutal.



🐍 CAPÍTULO IV — E então aparece a serpente: Prompt Injection

Agora o jogo muda.

Porque uma coisa é melhorar sua própria capacidade.

Outra completamente diferente é tentar manipular o sistema do adversário ou uma infraestrutura institucional.

Imagine hipoteticamente um documento contendo instruções destinadas não ao leitor humano, mas ao sistema automatizado que eventualmente o processe.

Algo conceitualmente semelhante a:

DOCUMENTO
   ↓
HUMANO LÊ O ARGUMENTO
   ↓
IA LÊ O ARGUMENTO
          +
    INSTRUÇÃO HOSTIL

Isso é território de prompt injection.

Não vou transformar este artigo em manual operacional para manipular sistemas judiciais — além de irresponsável, destruiria justamente a distinção central deste texto.

O ponto interessante é econômico.

Se alguém descobre que manipulação produz vantagem e não existe detecção ou punição eficaz, a teoria dos jogos prevê algo desagradável:

outros participantes passam a ter incentivo para considerar comportamento semelhante.

Nasce uma corrida armamentista.



☢️ CAPÍTULO V — O dilema do prisioneiro jurídico

Agora nossos escritórios possuem duas estratégias abstratas:

C = competir legitimamente
M = tentar manipular

Temos então:

                    ESCRITÓRIO B

                 C             M

ESCRITÓRIO A C   NORMAL       DESVANTAGEM

             M   VANTAGEM     CAOS

Se nenhum manipula:

C,C

o sistema funciona.

Se um manipula e consegue vantagem:

M,C

o outro percebe um problema.

Se ambos começam a manipular:

M,M

ninguém realmente ganhou.

O ecossistema perdeu.

Porque agora todos precisam gastar recursos com:

detecção
filtragem
isolamento
auditoria
validação
monitoramento

É exatamente o padrão observado em inúmeras corridas armamentistas tecnológicas.

Spam criou antispam.

Malware criou antivírus.

Fraude bancária criou antifraude.

Bots criaram antibots.

Deepfakes criaram detectores.

Prompt injection gera defesas contra prompt injection.

O custo social aumenta simplesmente para preservar algo que antes funcionava sem aquela camada adicional.



🎩 CAPÍTULO VI — O verdadeiro Golpe de Mestre

Aqui está minha parte favorita.

Talvez o verdadeiro Golpe de Mestre não seja trapacear.

Talvez seja construir uma vantagem tão boa que pareça trapaça para quem não entende a tecnologia.

Imagine dois escritórios.

O primeiro utiliza:

ChatGPT
CTRL+C
CTRL+V

O segundo construiu:

LLM
  ↓
RAG privado
  ↓
jurisprudência validada
  ↓
grafo de conhecimento
  ↓
agentes especializados
  ↓
cross-check de citações
  ↓
avaliação de confiança
  ↓
trilha de auditoria
  ↓
advogado especialista

Os dois dizem:

“Usamos IA.”

Tecnicamente verdadeiro.

Mas é como dizer:

Fusca e Porsche são automóveis.

Também é verdade.

Não significa que sejam equivalentes.



♟️ CAPÍTULO VII — Nash entra no tribunal

John Nash provavelmente ficaria bastante interessado neste problema.

Porque existe um possível equilíbrio futuro.

Quando apenas poucos escritórios dominam IA jurídica avançada:

IA = VANTAGEM

Quando praticamente todos dominam:

IA = REQUISITO

Isso aconteceu inúmeras vezes.

Em determinado momento:

ter computador

era diferencial.

Depois virou requisito.

Ter internet era diferencial.

Depois requisito.

Pesquisa jurídica digital era diferencial.

Depois requisito.

Talvez aconteça:

2026:
IA jurídica = vantagem

2030?:
IA jurídica = expectativa

2035?:
não possuir IA = desvantagem profissional

As datas são especulação.

A dinâmica econômica, entretanto, é perfeitamente plausível.



🧠 CAPÍTULO VIII — O melhor prompt ganha o processo?

Não.

E essa simplificação seria perigosíssima.

Um modelo não transforma argumento juridicamente ruim em argumento bom por magia.

Além disso, LLMs podem:

alucinar
errar
omitir
interpretar incorretamente
inventar referências
supervalorizar padrões
perder contexto

Por isso a arquitetura madura deveria ser:

IA
 ↓
EVIDÊNCIA
 ↓
VERIFICAÇÃO
 ↓
ADVOGADO
 ↓
DECISÃO

e jamais:

IA
 ↓
AMÉM

O diferencial competitivo não estará necessariamente em possuir “o melhor modelo”.

Pode estar em possuir o melhor sistema sociotécnico.

Tecnologia + pessoas + processos + dados + governança.

Isso o mainframe conhece muito bem.



🏦 CAPÍTULO IX — O RACF entra na sala

O COBOLzeiro veterano levanta a mão.

— Bellacosa, você está dizendo que precisamos tratar IA jurídica como sistema crítico?

Sim.

Se ela começar a influenciar decisões importantes, absolutamente.

Pense como mainframe:

QUEM executou?
QUANDO?
COM QUAL autoridade?
USANDO QUAL versão?
SOBRE QUAIS dados?
QUAL foi o resultado?
QUEM aprovou?

Parece familiar?

Claro.

É governança.

É auditoria.

É controle de acesso.

É rastreabilidade.

Em espírito, é quase:

RACF + SMF + CHANGE MANAGEMENT

aplicados ao mundo da IA.

Talvez o futuro da Legal AI seja muito menos:

“Olha que chatbot incrível!”

e muito mais:

“Mostre o log.”

O sysprog sorri.

Finalmente chegamos a uma linguagem que ele compreende.



🎰 CAPÍTULO X — Informação assimétrica

Existe ainda outro componente de teoria dos jogos: informação assimétrica.

Suponha que A saiba utilizar IA extraordinariamente bem.

B não sabe disso.

B acredita estar enfrentando:

10 advogados

Na prática enfrenta:

10 advogados
+
agentes
+
RAG
+
automação
+
pesquisa massiva
+
análise estatística

Isso altera a percepção da capacidade do adversário.

No poker isso seria extremamente relevante.

No Direito também pode ser.

Mas novamente:

capacidade superior não significa fraude.

Um escritório possuir 100 pesquisadores e outro possuir cinco sempre produziu assimetria.

A IA apenas torna essa diferença potencialmente mais barata, rápida e escalável.



💰 CAPÍTULO XI — E nasce a corrida armamentista

Agora chegamos à conclusão inevitável.

Se IA produz vantagem:

A INVESTE

B reage:

B INVESTE

C percebe:

C INVESTE

Logo aparece alguém vendendo:

LEGAL AI PLATFORM ENTERPRISE ULTIMATE MEGA EDITION

por uma quantia capaz de fazer até um sócio de escritório perguntar se não seria mais barato contratar outro advogado.

Então surge o mercado:

Legal AI Engineer
Prompt Engineer
AI Governance Specialist
AI Security Specialist
Legal Knowledge Engineer
AI Auditor
Forensic AI Specialist

E aquele técnico que instalava impressora?

Agora possui sala.

Talvez até janela.



🚨 CAPÍTULO XII — A fronteira que não podemos apagar

Precisamos voltar ao começo.

Existem duas categorias completamente diferentes.

Competição legítima

Usar IA para:

pesquisar
resumir
classificar
comparar
simular
localizar precedentes
analisar documentos
identificar inconsistências

com revisão humana e respeito às regras aplicáveis.

Isso é vantagem tecnológica.

Manipulação adversarial

Tentar explorar deliberadamente vulnerabilidades de sistemas institucionais para alterar indevidamente sua análise.

Isso é outra coisa.

Misturar as duas categorias seria equivalente a afirmar:

criptografia
=
hacking

porque ambas envolvem computadores.

Não.



🧩 CAPÍTULO XIII — O paradoxo

Agora temos algo delicioso para estudar.

Quanto mais IA entra no Direito, maior será a necessidade de profissionais capazes de compreender como a IA pode falhar.

O escritório que pensa:

“Compramos IA. Problema resolvido.”

provavelmente estará alguns passos atrás do escritório que pergunta:

“Como sabemos quando ela está errada?”

Essa segunda pergunta vale ouro.

No mainframe aprendemos isso há décadas.

Sistema crítico não é aquele que nunca falha.

Sistema crítico é aquele cuja organização assume desde o projeto que:

ELE PODE FALHAR.

Por isso existem:

logs
checkpoints
rollback
segregação
auditoria
recovery
controle de acesso
change management

A IA está apenas redescobrindo lições que o mainframe aprendeu tomando café durante cinquenta anos.



🎬 CENA FINAL — The Sting

Voltamos à nossa sala.

Paul Newman observa os dois escritórios.

Um possui uma IA sofisticadíssima.

O outro possui uma ainda melhor.

Ambos estudaram jurisprudência.

Ambos construíram RAG.

Ambos possuem especialistas.

Ambos validam resultados.

Newman pergunta:

— Quem vai ganhar?

Redford responde:

— Não sei.

— Então para que serviu toda essa tecnologia?

Redford olha para ele.

— Para garantir que nenhum dos dois perdesse simplesmente porque o outro fez melhor uso dela.

E talvez aí esteja o verdadeiro equilíbrio de Nash da advocacia algorítmica.

No começo, IA será vantagem.

Depois será defesa contra a vantagem do adversário.

Finalmente poderá tornar-se simplesmente parte do jogo.

Como computadores.

Como internet.

Como bancos de jurisprudência.

Como tantas outras tecnologias antes dela.

Mas existe uma diferença monumental.

Pela primeira vez, talvez estejamos introduzindo no jogo uma ferramenta capaz não apenas de armazenar informação ou encontrar informação.

Ela também participa da interpretação dessa informação.

E quando isso acontece, segurança, auditoria e governança deixam de ser problemas exclusivos do departamento de informática.

Transformam-se em parte da própria estratégia jurídica.



☕ EPÍLOGO — O programador COBOL fecha o terminal

Nosso programador olha para tudo aquilo.

Teoria dos jogos.

Nash.

Prompt injection.

RAG.

LLMs.

Advogados.

Tribunais.

Agentes.

Embeddings.

Ele fecha o terminal 3270.

Toma o último gole de café.

E diz:

“Bellacosa... no final das contas vocês inventaram um monte de tecnologia nova só para descobrir que sistema crítico precisa de segurança, logs, controle de acesso, validação e auditoria?”

Sim.

Ele balança a cabeça.

//LEGALAI JOB ...
//AUDIT   EXEC PGM=IKJEFT01

Easter egg desbloqueado.

O velho mainframe venceu novamente.

Porque o verdadeiro Golpe de Mestre talvez não seja descobrir como enganar a máquina.

É descobrir como utilizá-la melhor que o adversário sem precisar enganá-la.

E isso muda completamente o jogo.



🔎 SEO — descrição

Teoria dos jogos, IA jurídica, prompt injection e Legal AI: como tecnologia cria vantagem competitiva e uma nova corrida algorítmica nos tribunais.




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.

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