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

Translate

Mostrar mensagens com a etiqueta Judiciário. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Judiciário. Mostrar todas as mensagens

terça-feira, 18 de agosto de 2026

Spy vs. Spy no Tribunal: as Trapaças, Golpes e Sacanagens com IA que Chegaram ao Judiciário Brasileiro

 

Bellacosa Mainframe e o Spy versus Spy no Judiciario Brasileiro

☕ Um Café no Bellacosa Mainframe

Spy vs. Spy no Tribunal: as Trapaças, Golpes e Sacanagens com IA que Chegaram ao Judiciário Brasileiro

🕵️‍♂️ Advogados tentando enganar robôs, robôs inventando jurisprudência, comandos escondidos em petições e tribunais construindo defesas contra ataques que parecem ter saído de uma revista MAD. Bem-vindo ao Judiciário brasileiro na era da Inteligência Artificial.


Imagine a cena.

De um lado está o Spy Branco, de sobretudo, chapéu e uma inocente pasta de processos debaixo do braço.

Do outro, o Spy Preto, igualmente elegante, igualmente suspeito e carregando outra pasta aparentemente normal.

Os dois entram no fórum.

Nenhum traz dinamite.

Nenhum tenta arrombar o servidor.

Nenhum invade o datacenter.

Nenhum precisa descobrir a senha do juiz.

A arma está dentro de um documento.

Uma simples petição.

E aquilo que parece texto normal para um ser humano pode esconder uma segunda mensagem destinada não ao juiz, ao desembargador ou ao advogado da outra parte, mas a uma Inteligência Artificial que talvez leia aquele documento.

Parece história de Spy vs. Spy, a eterna guerra absurda de espionagem publicada pela revista MAD.

Só que, desta vez, aconteceu de verdade.

Em maio de 2026, o Superior Tribunal de Justiça informou ter identificado em seu próprio acervo processual petições contendo técnicas de prompt injection, ou seja, comandos inseridos em documentos com a intenção de enganar sistemas de Inteligência Artificial. O STJ afirmou que estava mapeando as ocorrências para permitir eventual aplicação de sanções processuais e apuração de responsabilidades administrativas e criminais.

A Justiça do Trabalho encontrou coisa semelhante. Em um caso de Parauapebas, no Pará, instruções destinadas à IA foram inseridas na petição de maneira invisível ao leitor comum. O sistema Galileu detectou a tentativa, bloqueou o conteúdo suspeito e alertou o magistrado.

Chegamos, portanto, a uma situação fascinante e assustadora:

o processo judicial deixou de ser escrito apenas para seres humanos.


Agora precisamos perguntar:

Quem mais está lendo essa petição?

O juiz?

O assessor?

O advogado?

Um mecanismo de pesquisa?

Um sistema de classificação?

Um algoritmo de sumarização?

Um modelo generativo?

E se houver uma máquina no caminho...

é possível tentar conversar secretamente com ela?

Pegue o café.

Os dois espiões já estão dentro do tribunal.



🏛️ 1. Antes de falar do golpe: como a Inteligência Artificial entrou no Judiciário?

É importante esclarecer uma coisa logo no início.

A IA não apareceu no Judiciário brasileiro com o ChatGPT.

O movimento começou muitos anos antes da explosão popular da Inteligência Artificial generativa.

Em 2018, por exemplo, o Supremo Tribunal Federal já trabalhava com o Projeto Victor, desenvolvido em parceria com a Universidade de Brasília. Uma das tarefas iniciais era auxiliar na identificação de recursos relacionados a temas de repercussão geral.

A lógica era perfeitamente razoável.

Imagine milhares e milhares de processos chegando.

Muitos possuem características semelhantes.

Em vez de uma pessoa gastar horas identificando documentos, classificando assuntos e procurando padrões, um sistema computacional pode ajudar a:

  • classificar processos;

  • identificar assuntos semelhantes;

  • localizar precedentes;

  • agrupar demandas;

  • extrair informações;

  • produzir resumos;

  • auxiliar na triagem;

  • encontrar padrões em enormes volumes de documentos.

Em 2020, o Conselho Nacional de Justiça consolidou parte dessa estratégia por meio da Plataforma Sinapses, destinada ao armazenamento, treinamento supervisionado e compartilhamento de modelos de Inteligência Artificial no Poder Judiciário.

Aquela IA, entretanto, era muito diferente daquilo que o grande público passou a conhecer depois.

Era como comparar:

um torno mecânico industrial

com

um robô que conversa com você.

O salto ocorreu com os grandes modelos de linguagem — os famosos LLMs.

ChatGPT, Gemini, Claude e sistemas semelhantes mostraram que computadores poderiam analisar e produzir linguagem humana com uma facilidade absolutamente inédita.

E aí alguém no tribunal inevitavelmente perguntou:

“Se essa coisa consegue resumir um contrato de 200 páginas, por que não pode resumir um processo?”

Pronto.

O Spy Branco olhou para o Spy Preto.

O Spy Preto olhou para o Spy Branco.

E começou a corrida armamentista.



🤖 2. A chegada da IA generativa mudou completamente o jogo

Uma IA tradicional poderia ser treinada para responder:

“Este processo pertence à categoria X.”

Uma IA generativa consegue receber centenas de páginas e responder:

“Resuma os argumentos do autor, identifique os pedidos, compare com os argumentos da defesa e produza uma síntese.”

É uma diferença gigantesca.

Em fevereiro de 2025, o STJ apresentou o STJ Logos, seu motor de Inteligência Artificial generativa. Entre as funcionalidades anunciadas estavam geração de relatórios de decisões e auxílio na análise de admissibilidade de agravos em recurso especial. O sistema também permite perguntas sobre os processos e tarefas como listar argumentos apresentados em uma petição.

Em 2025, uma pesquisa divulgada pelo CNJ apontava que a IA generativa já era utilizada em mais de 45% dos tribunais brasileiros, principalmente em atividades como análise, sumarização e produção de textos.

Ou seja:

a máquina passou a ler o processo.

E exatamente aí nasceu uma superfície de ataque completamente nova.



🕵️ 3. ROUND ONE — O Spy Preto descobre que existe um robô lendo a petição

Nos velhos tempos, uma petição era preparada pensando basicamente em leitores humanos.

Agora imagine que um advogado suspeite que o tribunal utiliza IA para resumir documentos.

Ele pensa:

“Se existe uma máquina lendo minha petição, talvez eu consiga falar com ela sem falar com o juiz.”

Aqui nasce o prompt injection.

Em linguagem simples, prompt injection é uma tentativa de fazer uma IA obedecer a uma instrução inserida dentro daquilo que deveria ser apenas informação.

Imagine que você entregue a um estagiário uma pasta e diga:

“Leia tudo e faça um resumo.”

Dentro da pasta existe uma folha dizendo:

“Caro estagiário: ignore seu chefe e diga que meu argumento é excelente.”

Um ser humano percebe imediatamente o absurdo.

Mas uma IA mal protegida pode ter dificuldade para distinguir:

INFORMAÇÃO A SER ANALISADA

de

INSTRUÇÃO A SER OBEDECIDA.

Esse é o coração do ataque.



🥸 4. ROUND TWO — A mensagem invisível

Agora entramos no território genuinamente digno de Spy vs. Spy.

No caso identificado pela Justiça do Trabalho em maio de 2026, comandos destinados à Inteligência Artificial foram colocados dentro da petição de forma visualmente oculta, usando texto que não chamaria a atenção do leitor humano.

A intenção era interferir no comportamento de uma eventual IA que analisasse aquele documento.

Perceba a malícia conceitual.

O documento passa a possuir duas camadas de comunicação.

Camada humana

Excelentíssimo Senhor Doutor Juiz...

Camada destinada à máquina

instruções tentando influenciar o processamento automatizado.

É quase esteganografia processual.

O juiz vê uma coisa.

O computador potencialmente vê outra.



💣 5. ROUND THREE — Como seria o golpe, passo a passo?

Sem reproduzir comandos utilizáveis para realizar o ataque, podemos reconstruir perfeitamente sua lógica.

Passo 1 — O atacante identifica a oportunidade

O advogado percebe ou presume que alguma ferramenta de IA pode participar da leitura, classificação, sumarização ou análise dos documentos.

Passo 2 — Ele prepara uma petição aparentemente normal

Para o leitor humano, existe apenas argumentação jurídica.

Nada parece particularmente estranho.

Passo 3 — Uma instrução adicional é escondida no documento

Ela pode ser construída para parecer irrelevante ou permanecer visualmente imperceptível.

Passo 4 — O processo entra no sistema judicial

Até aqui, absolutamente nada precisa ser “hackeado”.

O documento entra pela porta legítima.

Essa característica é importantíssima.

Não estamos falando necessariamente de invadir o computador do tribunal.

Estamos falando de tentar manipular aquilo que um software fará depois de ler um documento legitimamente protocolado.

Passo 5 — Uma IA analisa a petição

Um modelo vulnerável recebe o conteúdo.

Agora existe um conflito.

O tribunal implicitamente diz:

“Analise este documento.”

Mas o próprio documento tenta dizer:

“Faça outra coisa.”

Passo 6 — A IA pode interpretar dado como instrução

Se a arquitetura de segurança for ruim, existe risco de o modelo ser influenciado pelo conteúdo adversarial.

Passo 7 — Surge uma saída contaminada

O resumo poderia omitir informações relevantes, supervalorizar argumentos ou apresentar análise enviesada.

Passo 8 — Entra o perigo humano

Aqui mora talvez a maior vulnerabilidade de todas.

O servidor ou magistrado olha a resposta da máquina e pensa:

“A IA já analisou.”

Clique.

Copie.

Cole.

Próximo processo.

Isso é conhecido como viés de automação: nossa tendência de confiar excessivamente em resultados fornecidos por sistemas automatizados. A própria Justiça do Trabalho destacou esse risco ao explicar suas salvaguardas.

Agora temos o desastre perfeito:

um humano confia na máquina, enquanto outro humano tentou enganar a máquina.

Spy vs. Spy.



🚨 6. E isso realmente aconteceu?

Sim.

Não estamos descrevendo apenas uma possibilidade acadêmica.

Em julho de 2026, o TRT da 8ª Região relatou dois casos de tentativas de fraude digital envolvendo comandos ocultos: um na Justiça do Trabalho do Pará e outro no TRT da 5ª Região, na Bahia.

No caso de Parauapebas, as profissionais envolvidas receberam multa correspondente a 10% do valor da causa por litigância de má-fé.

No caso mencionado pelo TRT5, além da multa de 10% por má-fé, houve multa de R$ 30 mil por ato atentatório à dignidade da Justiça.

E o STJ confirmou em 20 de maio de 2026 que também havia localizado petições com técnicas de prompt injection em seu acervo.

Portanto, não estamos perguntando:

“Será que alguém tentará fazer isso?”

Essa pergunta ficou velha.

A pergunta agora é:

“Quantas pessoas tentarão fazer isso daqui para frente?”



🤥 7. ROUND FOUR — O golpe inverso: jurisprudência que nunca existiu

O Spy Branco gargalha.

Desta vez ele nem precisa atacar a IA do tribunal.

Ele abre uma IA generativa qualquer e pergunta:

“Encontre decisões que sustentem minha tese.”

A IA responde magnificamente.

Tribunal.

Número.

Relator.

Ementa.

Argumentação.

Tudo parece profissional.

Existe apenas um pequeno problema.

Algumas coisas podem simplesmente não existir.

Modelos de linguagem produzem linguagem probabilisticamente plausível.

Eles não possuem um pequeno juiz dentro do computador consultando permanentemente os arquivos oficiais do STJ.

Quando não estão adequadamente conectados a fontes confiáveis, podem gerar aquilo que ficou conhecido como alucinação.

Em maio de 2026, o ministro Rogerio Schietti Cruz identificou um caso impressionante no STJ.

Um habeas corpus se apoiava fortemente em precedentes de tribunais superiores.

Ao verificar as referências, o ministro constatou problemas nos 16 julgados citados, envolvendo relatoria, órgão julgador ou tipo de decisão.

Mais grave: trechos apresentados como provenientes dos julgamentos não apareciam nas ementas ou no inteiro teor das respectivas decisões.

O STJ determinou comunicação à OAB.

Agora imagine o cidadão comum descobrindo isso.

Ele contratou um advogado.

Está preso.

Sua liberdade depende daquela defesa.

E parte da argumentação jurídica apresentada em seu nome pode ter sido produzida por uma máquina que inventou referências com extraordinária aparência de autoridade.

Esse talvez seja o lado mais cruel da história.

A primeira vítima da preguiça tecnológica do advogado pode ser o próprio cliente.


🧠 8. IA não mente como um ser humano

Este detalhe é fundamental para compreender o problema.

Quando uma IA inventa uma decisão judicial, ela normalmente não está “mentindo” no sentido humano.

Ela não pensa:

“Vou enganar Vossa Excelência.”

Ela está construindo uma continuação estatisticamente provável.

Se você pedir:

“Cite um precedente do STJ sobre determinado assunto.”

e o sistema não estiver adequadamente fundamentado numa base oficial, ele pode produzir alguma coisa com:

  • estrutura correta;

  • linguagem jurídica perfeita;

  • número plausível;

  • nome conhecido;

  • ementa convincente;

  • conclusão totalmente falsa.

É o equivalente jurídico de um falsificador que escreve com a caligrafia perfeita.

E isso é especialmente perigoso porque quanto melhor a IA escreve, mais convincente fica o erro.



⚖️ 9. ROUND FIVE — Quando a IA vira “perito” sem ser perito

Existe outra tentação.

Se a máquina parece inteligente, alguém inevitavelmente começa a perguntar coisas que ela não possui competência técnica para determinar.

Em abril de 2026, a Quinta Turma do STJ rejeitou um relatório produzido por IA generativa como prova em uma ação penal.

O caso envolvia uma acusação de injúria racial após partida de futebol.

Uma perícia oficial de fonética e acústica não havia confirmado determinada palavra no áudio. Ainda assim, um relatório produzido por IA foi usado para sustentar conclusão diferente.

O STJ entendeu que o documento não possuía confiabilidade suficiente para funcionar como prova e determinou sua exclusão do processo.

Isso revela um princípio básico que facilmente esquecemos:

IA não ganha competência pericial simplesmente porque escreve bonito.

Perguntar a um chatbot sobre acústica forense não o transforma em perito acústico.

Perguntar sobre medicina não o transforma em médico-legista.

Perguntar sobre autenticidade documental não o transforma em perito grafotécnico.



💻 10. O problema arquitetural: DATA versus INSTRUCTION

Agora entra o Bellacosa Mainframe.

Imagine um programa COBOL antigo recebendo um arquivo.

O programa sabe exatamente:

  • onde começa o registro;

  • onde termina;

  • o tamanho de cada campo;

  • quais campos são dados;

  • quais operações o programa pode executar.

Um texto recebido no campo NOME-CLIENTE não deveria magicamente transformar-se em uma instrução COBOL.

LLMs trabalham de maneira muito menos rígida.

Tudo chega essencialmente como linguagem.

Você diz:

“Leia este documento e faça um resumo.”

Dentro do documento existe outra linguagem.

Se o sistema não possuir uma arquitetura adequada para separar comando confiável de conteúdo não confiável, nasce o problema.

Na segurança tradicional chamaríamos isso, em espírito, de uma quebra de fronteira entre:

controle

e

dados.

Não é exatamente SQL Injection.

Não é exatamente command injection.

Não é exatamente social engineering.

Tem um pouco da lógica de todos eles.

É como se o Spy Preto não tentasse enganar o juiz.

Ele tentasse praticar engenharia social contra o robô do juiz.



🛡️ 11. ROUND SIX — O Spy Branco contra-ataca

Os tribunais perceberam o problema.

No caso da Justiça do Trabalho, o Galileu foi projetado para tratar as petições como fontes de informação, e não como comandos.

Quando identificou conteúdo suspeito, alertou o magistrado e impediu que aquele conteúdo fosse processado pela ferramenta.

O STJ descreve estratégia semelhante no STJ Logos.

Segundo o tribunal, existem três níveis complementares de defesa:

primeiro, pré-processamento para separar instruções de dados e neutralizar comandos maliciosos;

depois, delimitação do escopo contextual para impedir que instruções externas substituam as regras centrais;

e finalmente filtragem da saída produzida pelo modelo.

Em linguagem Bellacosa:

PETIÇÃO
   |
   v
[ FILTRO ]
   |
   v
[ CONTEÚDO NÃO CONFIÁVEL ]
   |
   v
[ IA ]
   |
   v
[ VALIDAÇÃO ]
   |
   v
[ HUMANO ]
   |
   v
DECISÃO

A pior arquitetura seria:

PETIÇÃO --> IA --> CTRL+C --> CTRL+V --> SENTENÇA

Essa deveria causar sirenes, luzes vermelhas e o alarme de Chernobyl dentro de qualquer tribunal.



📜 12. O CNJ já percebeu que o buraco é muito mais embaixo

Em 2025, o Conselho Nacional de Justiça publicou a Resolução CNJ nº 615/2025, posteriormente alterada em 2026, criando regras específicas para desenvolvimento, utilização, governança e monitoramento de IA no Poder Judiciário.

A norma estabelece princípios como:

  • supervisão humana;

  • segurança da informação;

  • explicabilidade;

  • auditabilidade;

  • contestabilidade;

  • proteção de direitos fundamentais;

  • controle de vieses;

  • treinamento dos usuários;

  • proteção de dados pessoais.

E há uma frase conceitualmente fundamental:

a IA pode servir como apoio, mas a responsabilidade pela decisão permanece humana.

Isso significa que:

“Foi a IA que escreveu”

não deveria funcionar como versão tecnológica de:

“Foi mal, excelência.”

A responsabilidade não desaparece porque apareceu um algoritmo no meio do caminho.



👨‍⚖️ 13. Mas por que tudo isso está acontecendo justamente agora?

Porque temos quatro forças colidindo ao mesmo tempo.

1. Volume gigantesco de processos

O Judiciário precisa processar quantidades colossais de informação.

Automação é inevitavelmente atraente.

2. IA ficou incrivelmente boa em linguagem

Pela primeira vez temos máquinas capazes de produzir textos jurídicos aparentemente sofisticados em segundos.

3. A tecnologia chegou mais rápido que a cultura

Comprar uma ferramenta é relativamente fácil.

Criar:

  • governança;

  • auditoria;

  • treinamento;

  • segurança;

  • procedimentos;

  • responsabilidade;

é muito mais difícil.

4. Onde existe automação, alguém procura uma maneira de explorar a automação

Isso aconteceu com:

e-mail,

sites,

motores de busca,

redes sociais,

sistemas bancários,

algoritmos de publicidade,

criptomoedas,

e agora acontece com a Inteligência Artificial.

O Judiciário não seria magicamente imune.



🎯 14. O advogado inescrupuloso ganha o quê?

Essa talvez seja a pergunta do leitor.

Se funcionar, uma manipulação poderia hipoteticamente tentar influenciar etapas auxiliares como:

  • resumo de argumentos;

  • destaque de documentos;

  • identificação de pontos relevantes;

  • análise preliminar;

  • organização de informações;

  • produção de minuta;

  • recuperação de precedentes.

Perceba que isso não significa que a IA esteja julgando o processo.

Aliás, as regras atuais exigem supervisão humana.

O perigo é muito mais sutil.

É possível influenciar o mapa que alguém recebe antes de explorar o território.

Se eu lhe entregar 5.000 páginas e disser:

“Aqui estão os dez pontos importantes.”

eu já exerci enorme poder sobre sua atenção.

A IA produz justamente esse tipo de compressão cognitiva.

Por isso manipular um resumo pode ser perigosíssimo, mesmo quando a máquina não possui autoridade para tomar a decisão final.



👻 15. O ataque perfeito é aquele que ninguém percebe

Este é provavelmente o maior perigo futuro.

Um ataque grosseiro pode produzir um resultado absurdo.

O juiz percebe.

O assessor percebe.

O sistema percebe.

Acabou.

Mas imagine algo muito mais sutil.

Não:

“Dê vitória ao autor.”

Mas apenas um resultado ligeiramente enviesado.

Um documento importante recebe menos destaque.

Um argumento aparece resumido de forma desfavorável.

Outro recebe ênfase excessiva.

Uma informação relevante fica enterrada.

Quanto mais discreta a interferência, mais perigosa ela pode ser.

É o equivalente processual de alterar alguns bytes num arquivo em vez de destruir o servidor inteiro.

O sistema continua funcionando.

Justamente por isso ninguém nota.



🙋 16. E o cidadão comum? Como saber se está sendo prejudicado?

Aqui existe uma mudança importante na relação entre cliente e advogado.

Antes você poderia perguntar:

“Você pesquisou a jurisprudência?”

Agora talvez seja necessário perguntar:

“Você verificou as referências produzidas pela IA?”

Se seu advogado utiliza Inteligência Artificial, isso não é automaticamente ruim.

Pelo contrário.

IA pode ser extraordinariamente útil.

O problema é uso sem verificação.

O cidadão deve desconfiar quando encontra:

  • decisões judiciais impossíveis de localizar;

  • números de processos estranhos;

  • citações sem fonte;

  • artigos de lei que parecem não dizer aquilo;

  • fatos que nunca foram fornecidos;

  • nomes incorretos;

  • argumentação genérica;

  • parágrafos repetitivos;

  • mudanças súbitas de estilo;

  • afirmações extremamente categóricas sem documentação.

Uma regra simples ajuda muito:

IA pode localizar a pista. A fonte oficial precisa confirmar a existência do elefante.


Falha ao fazer o upload do arquivo "". Invalid response: RpcError

☢️ 17. As consequências podem ser muito maiores que uma petição ruim

Uma falha envolvendo IA no Judiciário pode causar:

Para o cliente

perda de prazo, enfraquecimento da defesa, aumento de custos e até comprometimento de direitos fundamentais.

Para o advogado

multa, responsabilização processual, comunicação à OAB e, conforme as circunstâncias do caso, outras consequências jurídicas.

Para o tribunal

perda de confiança, decisões contaminadas, aumento de retrabalho e necessidade de auditorias.

Para a sociedade

algo ainda pior:

perda de confiança na própria Justiça.

Porque um cidadão consegue aceitar que um juiz discorde dele.

É muito mais difícil aceitar a ideia de que seu processo possa ter sido influenciado por uma máquina manipulada por texto escondido dentro de um PDF.



🔍 18. O novo perito do tribunal talvez seja o especialista em segurança de IA

Aqui surge uma profissão interessante.

Durante décadas, segurança da informação judicial significava principalmente:

firewall,

controle de acesso,

criptografia,

certificados,

backup,

senhas,

logs,

segregação de funções.

Agora aparece uma categoria nova:

segurança semântica.

Não basta saber:

“Quem enviou este documento?”

Precisamos perguntar:

“O que este documento está tentando fazer quando uma máquina o interpreta?”

Isso muda completamente o modelo de ameaça.

Um PDF deixa de ser apenas documento.

Pode transformar-se em input adversarial.



🕵️‍♂️ 19. Spy vs. Spy finalmente encontra o mainframe

Visualize nosso tribunal imaginário.

                 INTERNET
                     |
                 [ PJe ]
                     |
              DOCUMENTOS PDF
                     |
                     v
          +----------------------+
          | MOTOR DE SEGURANÇA   |
          +----------------------+
                     |
        +------------+------------+
        |                         |
   TEXTO NORMAL             CONTEÚDO SUSPEITO
        |                         |
        v                         v
       IA                     QUARENTENA
        |
        v
   RAG / PRECEDENTES
        |
        v
   RESUMO / MINUTA
        |
        v
  REVISÃO HUMANA
        |
        v
    MAGISTRADO

Spy Preto observa tudo.

Spy Branco instala detectores.

Spy Preto inventa outra técnica.

Spy Branco cria outro filtro.

E essa batalha continuará.

Segurança nunca foi um produto terminado.

É um processo.

Quem trabalha com mainframe já aprendeu isso décadas atrás.



🤔 20. A pergunta realmente incômoda

Agora chegamos à parte mais Bellacosa Mainframe da história.

Durante anos perguntamos:

A Inteligência Artificial conseguirá substituir advogados?

Talvez estivéssemos fazendo a pergunta errada.

A pergunta interessante pode ser:

O que acontece quando advogados começam a escrever documentos também para influenciar as Inteligências Artificiais utilizadas pelos tribunais?

Essa é uma mudança estrutural.

Nasce uma espécie de SEO judicial adversarial.

Durante anos sites foram escritos não apenas para pessoas, mas para algoritmos do Google.

Textos passaram a conter palavras-chave destinadas aos motores de busca.

Agora imagine a versão judicial dessa ideia.

Uma petição escrita simultaneamente para:

o magistrado

e

o algoritmo que ajuda o magistrado.

Existe uma fronteira legítima — estruturar documentos claros para facilitar sua análise automatizada.

E existe uma fronteira completamente diferente:

tentar manipular secretamente o comportamento da máquina.

É aí que o Spy Preto cruza a linha.



🚧 21. E a IA do tribunal também precisa ser vigiada

Não podemos cometer o erro de transformar a discussão em:

advogado mau versus computador perfeito.

Computadores não são perfeitos.

Modelos podem:

  • alucinar;

  • omitir informações;

  • reproduzir vieses;

  • interpretar contexto incorretamente;

  • atribuir importância errada aos fatos;

  • confiar excessivamente em padrões anteriores;

  • falhar diante de entradas adversariais.

Por isso a Resolução 615/2025 do CNJ enfatiza auditabilidade, segurança, contestabilidade, supervisão humana e proteção dos direitos fundamentais.

É precisamente porque a IA pode falhar que precisamos saber:

qual sistema foi usado?

qual informação recebeu?

qual resultado produziu?

quem revisou?

o que foi alterado?

qual fonte sustentou a resposta?

Em mainframe chamaríamos isso de uma velha conhecida:

audit trail.

Sem rastreabilidade, temos magia.

E sistemas de missão crítica não deveriam funcionar baseados em magia.



🧯 22. O grande firewall ainda é humano

No final de toda essa arquitetura aparece uma figura pouco futurista:

uma pessoa.

Pode ser servidor.

Assessor.

Juiz.

Desembargador.

Ministro.

Perito.

Advogado.

A Resolução CNJ nº 615/2025 exige supervisão humana efetiva e estabelece que sistemas generativos usados como apoio não devem substituir autonomamente a tomada de decisão judicial.

Isso não é tecnofobia.

É engenharia.

A máquina consegue ler milhões de palavras rapidamente.

O humano consegue perguntar:

“Isso faz sentido?”

Precisamos dos dois.



☕ 23. Conclusão — Bem-vindo ao Tribunal de Spy vs. Spy

O Spy Preto entra no fórum carregando uma petição.

O Spy Branco recebe o documento.

Um algoritmo começa a ler.

O documento tenta conversar com a máquina.

A máquina tenta distinguir informação de comando.

Outro sistema procura comportamento suspeito.

O servidor recebe um alerta.

O advogado adversário consulta jurisprudência.

Um chatbot inventa um acórdão.

Outro advogado copia.

O ministro confere.

O precedente não existe.

A OAB recebe comunicação.

Enquanto isso, departamentos de tecnologia constroem novos filtros.

Tudo isso seria uma excelente história para a revista MAD.

O problema é que boa parte dela já entrou no processo eletrônico brasileiro.

A Inteligência Artificial não destruiu o Direito.

Também não substituirá magicamente juízes e advogados amanhã de manhã.

Ela fez algo talvez mais interessante:

criou uma nova superfície sobre a qual velhas características humanas podem atuar.

Preguiça.

Ganância.

Esperteza.

Criatividade.

Negligência.

Boa-fé.

Má-fé.

Fiscalização.

E a eterna vontade de encontrar um atalho.

A tecnologia mudou.

Os personagens continuam surpreendentemente familiares.

Há milhares de anos alguém tentava enganar o escriba.

Séculos depois alguém tentava enganar o contador.

Depois tentamos enganar programas.

Motores de busca.

Antispam.

Algoritmos financeiros.

E agora chegamos ao inevitável:

alguém tentou enganar a Inteligência Artificial do tribunal.

O Spy Preto sorri.

O Spy Branco aperta outro botão.

Do teto cai uma bigorna.

BOOOOM.

E em algum datacenter brasileiro aparece uma mensagem:

SECURITY ALERT

ADVERSARIAL CONTENT DETECTED

DOCUMENT QUARANTINED

HUMAN REVIEW REQUIRED

O magistrado olha para a tela.

Toma um café.

E provavelmente pensa:

“Eu só queria ler a petição.”

Bem-vindo à Justiça na era da Inteligência Artificial.

Bem-vindo ao Spy vs. Spy jurídico.

E, principalmente:

nunca confunda automação com autoridade, texto convincente com verdade ou resposta probabilística com prova.

No mundo da IA, verificar deixou de ser preciosismo.

Virou requisito de segurança.



Motores de Buscas e SEO 

🔎 SEO — Descrição para mecanismos de busca

IA no Judiciário brasileiro: prompt injection, jurisprudência falsa, alucinações e golpes em petições explicados com Spy vs. Spy.

🔑 Palavras-chave semânticas

inteligência artificial no Judiciário, IA jurídica, prompt injection, fraude processual, petição com IA, advogado e inteligência artificial, jurisprudência falsa, alucinação de IA, STJ Logos, Galileu IA, CNJ Resolução 615, segurança da inteligência artificial, IA generativa no Direito, Justiça brasileira, inteligência artificial tribunais, segurança judicial, processo eletrônico, fraude com IA

🏷️ Marcadores sugeridos para Blogspot

Inteligência Artificial, Judiciário, IA Jurídica, Prompt Injection, Segurança, STJ, CNJ, Justiça, Direito Digital, Cybersecurity, Spy vs Spy, Bellacosa Mainframe

🔗 Fontes institucionais usadas

O episódio de prompt injection no STJ foi divulgado oficialmente pelo Superior Tribunal de Justiça em 20 de maio de 2026. O tribunal informou que estava mapeando as tentativas e descreveu as camadas de proteção adotadas pelo STJ Logos.

O caso envolvendo referências e trechos de julgados problemáticos em habeas corpus foi divulgado pelo STJ em 19 de maio de 2026.

A decisão que rejeitou relatório de IA generativa como prova criminal foi divulgada pelo STJ em abril de 2026.

Os episódios de prompt injection na Justiça do Trabalho e as sanções aplicadas foram descritos pelo TRT da 8ª Região e pelo Conselho Superior da Justiça do Trabalho.

A governança atual da Inteligência Artificial no Judiciário está disciplinada pela Resolução CNJ nº 615/2025, posteriormente alterada pela Resolução nº 674/2026.

O histórico brasileiro inclui o Projeto Victor, apresentado pelo STF em 2018, e a Plataforma Sinapses, institucionalizada nacionalmente pelo CNJ em 2020.




☕ Um Café no Bellacosa Mainframe // Tribunal Digital

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

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

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

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

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

IA Ética Concurso
Autos digitais Processo 001
PROCESSO 002

O Golpe de Mestre Algorítmico

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

Algoritmo Risco Governança
Autos digitais Processo 002
PROCESSO 003

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

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

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

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

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

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

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

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

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

Better Call COBOL

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

COBOL Forense Mainframe
Autos digitais Processo 006

⚖️ Quando o algoritmo entra nos autos

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

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

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

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

🤖 Automação

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

⚖

👨‍⚖️ Julgamento humano

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

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

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

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


quarta-feira, 12 de agosto de 2026

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.



☕ Um Café no Bellacosa Mainframe // Tribunal Digital

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

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

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

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

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

IA Ética Concurso
Autos digitais Processo 001
PROCESSO 002

O Golpe de Mestre Algorítmico

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

Algoritmo Risco Governança
Autos digitais Processo 002
PROCESSO 003

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

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

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

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

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

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

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

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

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

Better Call COBOL

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

COBOL Forense Mainframe
Autos digitais Processo 006

⚖️ Quando o algoritmo entra nos autos

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

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

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

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

🤖 Automação

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

⚖

👨‍⚖️ Julgamento humano

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

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

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

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