☕ 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, 20 de agosto de 2026

A Lei Seca do Algoritmo — ou como comecei lendo uma lei brasileira e duas semanas depois a ONU cercava minha ilha

Bellacosa Mainframe e a lei seca do algoritmo ia moderna um jogo do absurdo

☕ Um Café no Bellacosa Mainframe

A Lei Seca do Algoritmo — ou como comecei lendo uma lei brasileira e duas semanas depois a ONU cercava minha ilha

Uma pequena história sobre leis, IA, jurisdições, Port Royal, mercenários, dilemas de segurança e a extraordinária capacidade humana de transformar um IF de quatro linhas numa crise internacional

Tudo começou de maneira perfeitamente inocente.

Eu estava lendo uma notícia sobre uma lei brasileira.

Qual lei?

Não importa.

Aliás, é melhor nem dizer, porque o objeto específico da lei é muito menos interessante do que o fenômeno que ela despertou nos aproximadamente um milhão de chimpanzés que administram meu cérebro, supervisionados, naturalmente, por Tico e Teco.

A notícia explicava uma evolução legislativa bastante curiosa.

Primeiro havia o humano.

O humano fazia alguma coisa, sofria alguma coisa ou aparecia em alguma coisa.

A sociedade dizia:

— Isso não pode.

O legislador concordava:

— Realmente não pode.

E escrevia uma lei.

Muito bem.

Caso encerrado.

Só que então apareceu uma situação nova.

A lei não previa exatamente aquilo.

Então alguém colocou um puxadinho.

Depois apareceu outra situação.

Novo puxadinho.

Depois veio a Internet.

Mais um puxadinho.

Depois atravessaram fronteiras.

Puxadinho internacional.

Depois chegaram algoritmos capazes de produzir coisas que anteriormente exigiam participação humana.

E o legislador descobriu horrorizado que agora existia algo que parecia com o objeto originalmente proibido, mas que havia sido criado sem que nenhum ser humano tivesse participado daquilo como matéria-prima.

Era sintético.

Artificial.

Quase uma carne vegana jurídica.

Parecia carne.

Tinha formato de carne.

Era consumida como carne.

Mas nenhuma vaca havia participado da reunião.

E meus chimpanzés imediatamente interromperam suas atividades normais.



🧠 O primeiro IF era simples

Imagino que a versão 1.0 da legislação fosse conceitualmente parecida com isto:

IF EXISTE-HUMANO
   AND OCORREU-ATO-PROIBIDO
       MOVE "CRIME" TO RESULTADO
END-IF

Elegante.

Legível.

Cabe numa tela 3270.

O problema é que seres humanos são excelentes em encontrar situações que o programador original não imaginou.

Logo apareceu:

IF EXISTE-HUMANO
   OR EXISTE-REPRESENTACAO-DO-HUMANO

Depois:

OR EXISTE-GRAVACAO
OR EXISTE-FOTOGRAFIA
OR EXISTE-AUDIO

Depois chegou a Internet:

OR FOI-DISTRIBUIDO
OR FOI-COMPARTILHADO
OR FOI-TRANSMITIDO

Depois alguém colocou o servidor em outro país.

Novo ELSE.

Depois apareceu IA generativa.

E finalmente chegamos ao maravilhoso:

OR NAO-EXISTE-HUMANO
   BUT-PARECE-QUE-EXISTE


Nesse momento o velho programador COBOL dentro de mim olhou para aquilo e pensou:

isso virou sistema legado.

A intenção original continua lá.

Só que quarenta change requests depois ninguém mais sabe exatamente onde termina a regra original e começa o remendo colocado numa sexta-feira às 17h43 porque produção precisava subir naquele fim de semana.



🤖 Então o humano desapareceu

Essa foi a parte que realmente me chamou atenção.

Durante muito tempo havia uma cadeia relativamente compreensível:

humano → ato → registro → distribuição → dano.

Mas a tecnologia tornou possível outra:

algoritmo → geração → arquivo → distribuição.

O humano que originalmente justificava boa parte da proteção simplesmente poderia não existir naquela cadeia.

Não houve modelo.

Não houve fotografia original.

Não houve gravação.

Não houve determinada pessoa fazendo aquilo.

O objeto nasceu sinteticamente.

Naturalmente, a sociedade respondeu:

— Continua não podendo.

E surgiu outro puxadinho.

Perfeitamente compreensível.

Só que meus chimpanzés fizeram a pergunta que jamais se deve permitir que chimpanzés façam:

E se em outro país puder?

Silêncio.

Tico olhou para Teco.

Teco abriu um atlas.

Temos quase duzentos países no planeta.

É estatisticamente difícil conseguir fazer quase duzentos governos concordarem até sobre a temperatura adequada do café.

Naturalmente haverá diferenças legislativas.

E alguém encontrará uma.



🌎 Regulation-as-a-Service

Imagine então um pequeno país.

Não precisamos dizer qual.

Chamaremos de República Democrática, Popular, Constitucional, Marítima e Absolutamente Respeitável de Qualquerlândia.

Qualquerlândia analisa o assunto e decide:

— Material envolvendo pessoas reais? Proibido.

— Material inteiramente sintético?

O funcionário consulta o código.

Consulta novamente.

Chama o chefe.

O chefe chama o ministro.

O ministro chama um advogado.

Finalmente alguém responde:

— Aqui não é crime.

Pronto.

Nasceu uma indústria.

Criadores registram empresas em Qualquerlândia.

Servidores aparecem.

Processadores financeiros aparecem.

Advogados aparecem.

Contadores aparecem.

Data centers aparecem.

O resto do mundo continua consumindo exatamente o mesmo produto.

A diferença é que agora a receita termina em Qualquerlândia.

O país que proibiu continua tendo consumidores.

Continua tendo demanda.

Continua tendo dinheiro saindo.

Só deixou de ter a empresa.

O imposto.

O servidor.

O emprego.

E parte da capacidade de fiscalização.

Nesse momento pensei:

isso é uma espécie de Lei Seca digital.



🍺 Al Capone precisava de caminhões

A Lei Seca americana descobriu uma coisa desagradável:

proibir oferta não significa automaticamente eliminar demanda.

Se existe demanda suficientemente grande, alguém tentará atendê-la.

Só que Al Capone tinha um problema logístico.

Álcool pesa.

Precisa de garrafas.

Caixas.

Caminhões.

Navios.

Depósitos.

Motoristas.

Fronteiras.

Policiais subornáveis.

Um arquivo digital não possui nenhuma dessas inconveniências.

Ele pesa aproximadamente:

nada.

Pode atravessar cinquenta fronteiras antes que eu termine esta frase.

E IA generativa acrescentou algo ainda mais divertido.

Talvez nem sequer exista estoque.

O advogado de Qualquerlândia poderia dizer:

— Nós não armazenamos o produto.

— Não importamos o produto.

— Não exportamos o produto.

— Não possuímos o produto.

— O usuário solicita alguma coisa e uma máquina calcula pixels.

Imagino 193 delegações internacionais pedindo intervalo para café.



🏴‍☠️ Foi quando fundei Port Royal

Aqui meus chimpanzés abandonaram definitivamente qualquer compromisso com a realidade.

Pensei:

Muito bem. Então criarei minha própria Port Royal.

Uma pequena jurisdição marítima.

Centenas de servidores.

Energia própria.

Data center.

Links redundantes.

E uma constituição extremamente simples:

FREE FOR ALL

Não recomendo isso como política pública.

Estamos fazendo ficção satírica.

Mas mentalmente era maravilhoso.

Na entrada:

WELCOME TO PORT ROYAL CLOUD

Free for All Since 2026.

Terms and Conditions: No.

E imediatamente descobrimos o primeiro problema.

Você pode declarar independência.

Seu roteador não.



🌐 O ASN também tem sentimentos

Port Royal precisava de Internet.

Quem anuncia nosso ASN?

Precisávamos de upstream.

Precisávamos de cabos.

Precisávamos de DNS.

Precisávamos importar SSDs.

Precisávamos comprar processadores.

Precisávamos receber pagamentos.

Precisávamos contratar pessoas.

Precisávamos de peças para os geradores.

Ou seja:

às 14h eu havia declarado independência.

Às 14h07 descobri que dependia economicamente de metade do planeta.

Mas meus chimpanzés não desistiram.

Port Royal cresceu.

Criadores começaram a aparecer.

Empresas começaram a registrar suas obras ali.

Dinheiro começou a circular.

E algum governo estrangeiro finalmente disse:

— Chega.



🚤 Primeiro veio a Guarda Costeira

Essa parte é importante.

Na minha imaginação, ninguém começou mandando porta-aviões.

Seria ridículo.

Primeiro veio uma pequena força marítima de fiscalização.

Objetivo limitado.

Entrar.

Interromper determinadas atividades.

Talvez apreender alguma coisa.

Port Royal respondeu:

— Vocês não possuem jurisdição aqui.

Eles responderam:

— Achamos que possuímos.

Port Royal tinha segurança privada.

Mercenários.

Os mercenários impediram a intervenção.

E naquele exato segundo aconteceu algo fundamental:

a discussão deixou de ser sobre arquivos.

Agora era sobre soberania.



⚓ Então veio um navio maior

O governo estrangeiro não poderia simplesmente dizer:

— Bem, nossos homens foram expulsos. Vida que segue.

Porque agora havia precedente.

Então enviou força suficiente para garantir que aquilo não acontecesse novamente.

Port Royal observou o horizonte.

Um destróier.

Talvez dois.

Meus chimpanzés convocaram reunião extraordinária.

E foi quando apareceram os amigos.



🤝 A Liga dos Países que Também Não Gostam que Mandem Neles

Algumas nações possuíam relações comerciais com Port Royal.

Outras não davam a mínima para nossos servidores, mas estavam muito interessadas no precedente.

Porque a pergunta havia mudado.

Não era mais:

"Port Royal pode hospedar aquilo?"

Agora era:

"Um país pode entrar militarmente numa jurisdição menor porque discorda das leis dela?"

Isso interessava a muita gente.

Uma pequena liga de países amigos enviou navios para defesa dissuasora.

Não para atacar.

Naturalmente.

Todos estavam ali pela paz.

E essa é uma das frases mais perigosas que a humanidade já inventou:

"Trouxemos armas para garantir a paz."



📈 O algoritmo da dissuasão

O primeiro lado tinha um navio.

O segundo colocou dois.

O primeiro pensou:

— Dois?

Então trouxe quatro.

O segundo percebeu quatro navios hostis e trouxe oito.

Logo:

A = 1
B = 2

A = 4
B = 8

A = 16
B = 32

Port Royal:

— Gente... eram uns servidores.

Ninguém estava ouvindo.

Agora havia aeronaves de patrulha.

Guerra eletrônica.

Submarinos.

Defesa aérea.

Navios de apoio.

Satélites observando.

Serviços de inteligência.

E jornalistas transmitindo ao vivo da praia.



💣 O dilema de segurança

Existe uma perversidade maravilhosa nesse mecanismo.

O lado A diz:

— Estou aumentando minhas forças porque B está perigoso.

B responde:

— Estou aumentando minhas forças porque A está aumentando suas forças.

A observa:

— Viu? Eu estava certo sobre B!

B observa:

— Viu? Eu estava certo sobre A!

Ambos podem sinceramente não querer guerra.

Ambos podem sinceramente acreditar que suas forças são defensivas.

E ambos terminam extraordinariamente preparados para travar justamente a guerra que dizem querer evitar.

Port Royal havia se tornado uma demonstração prática do dilema de segurança.

E ninguém pediu autorização aos chimpanzés.



📰 CNN: CRISE DE PORT ROYAL — DIA 12

Nesse ponto imagino a televisão.

Especialistas diante de mapas.

Setinhas vermelhas.

Setinhas azuis.

Fotos de satélite.

Almirantes aposentados.

Professores de relações internacionais.

Economistas.

Advogados.

Um sujeito chamado "especialista em Port Royal" que duas semanas antes provavelmente não sabia que Port Royal existia.

Mercados caindo.

Petróleo subindo.

Seguradoras marítimas suspendendo cobertura.

Companhias desviando rotas.

E em algum estúdio alguém pergunta:

— Como chegamos até aqui?

Ninguém sabe responder em menos de quarenta minutos.



🏛️ Finalmente chegamos à ONU

E foi aí que minha imaginação chegou ao ponto que originalmente contei primeiro.

A ONU entra no circuito.

Conselho de Segurança.

Reuniões extraordinárias.

Propostas de resolução.

Vetos.

Sanções.

Diplomatas entrando e saindo de salas.

Coalizões.

Estados com capacidade nuclear envolvidos indiretamente na crise.

Importante: a ONU não possui uma esquadra nuclear própria esperando alguém apertar o botão vermelho.

Mas isso pouco importava para meus chimpanzés.

Na versão mental cinematográfica, o horizonte de Port Royal já estava cheio de poder naval suficiente para fazer qualquer pessoa reconsiderar seriamente suas escolhas profissionais.

E então percebi algo extraordinário.



❓ Ninguém mais lembrava por que aquilo começou

Essa é provavelmente minha parte favorita.

No começo:

"Precisamos discutir determinado material sintético."

Depois:

"Precisamos discutir jurisdição."

Depois:

"Precisamos discutir Port Royal."

Depois:

"Precisamos discutir violação territorial."

Depois:

"Precisamos discutir o incidente com a Guarda Costeira."

Depois:

"Precisamos discutir a presença da frota."

Depois:

"Precisamos discutir o tratado entre Port Royal e seus aliados."

Depois:

"Precisamos discutir equilíbrio estratégico regional."

Depois:

"Precisamos impedir uma guerra internacional."

O objeto original?

Esquecido.

Enterrado debaixo de quinze camadas de consequências.

É exatamente como um incidente de produção.


🖥️ INC0000001 — Usuário não consegue abrir arquivo

Se você trabalha há tempo suficiente em mainframe, já viu isso.

Às 9h:

Usuário não consegue acessar arquivo.

Às 10h:

DBA entrou na bridge.

10h15:

Storage.

10h30:

RACF.

11h:

Rede.

11h30:

Middleware.

12h:

Fornecedor.

13h:

Gerência.

14h:

Diretoria.

15h:

Executivo.

16h:

Regulador informado.

17h:

Quarenta e sete pessoas na conference call.

Às 17h12 alguém finalmente pergunta:

— Qual era mesmo o erro original?

Silêncio.

Um velho operador consulta o log.

— Permissão errada num diretório.

Port Royal era exatamente isso.

Só que com submarinos nucleares.


☕ E talvez essa seja a verdadeira história

Comecei lendo uma lei brasileira.

Não importa qual.

Ela apenas serviu como ponto inicial para observar uma característica extraordinariamente humana.

Criamos regras para resolver problemas.

A realidade encontra situações que as regras não previram.

Acrescentamos exceções.

A tecnologia cria outras possibilidades.

Acrescentamos novas regras.

As atividades atravessam fronteiras.

Criamos mecanismos extraterritoriais.

Empresas migram.

Governos reagem.

Jurisdicionalmente permissivos descobrem oportunidades econômicas.

Outros governos pressionam.

A questão econômica torna-se diplomática.

A questão diplomática torna-se estratégica.

E, se ninguém apertar PAUSE, podemos acabar discutindo porta-aviões quando originalmente estávamos discutindo pixels.

A tecnologia não destrói necessariamente a lei.

Ela frequentemente faz algo muito mais divertido:

obriga a lei a persegui-la.

E cada vez que a lei alcança a tecnologia, alguém pergunta:

— E se fizermos deste outro jeito?

Novo puxadinho.

Novo IF.

Novo ELSE.

Nova jurisdição.

Até algum programador jurídico do futuro abrir o código legislativo e perguntar:

— Quem foi o desgraçado que escreveu isso?

E alguém responder:

— Ninguém.

— Como ninguém?

— Começou pequeno em 1998. Depois fomos fazendo manutenção.

O programador fecha o terminal.

Vai buscar café.

E decide não tocar em absolutamente nada.


🏴‍☠️ Epílogo — Dia 14 em Port Royal

O secretário-geral consegue finalmente reunir todas as partes.

Do lado de fora existem navios suficientes para transformar o oceano num estacionamento.

Ele abre uma pasta de oitocentas páginas.

Ajusta os óculos.

Olha para as delegações.

— Senhores, estamos diante de uma das mais graves crises internacionais das últimas décadas.

Silêncio absoluto.

— Antes de começarmos, gostaria apenas de esclarecer uma coisa.

Folheia os documentos.

Folheia novamente.

Chama um assessor.

Cochicham.

Ele volta ao microfone:

— Alguém poderia explicar por que começou tudo isso?

Silêncio.

Russos olham para americanos.

Americanos olham para europeus.

Europeus olham para chineses.

Chineses olham para Port Royal.

No fundo da sala, levanto timidamente a mão.

— Excelência...

Todos olham.

— Bem...

Pigarreio.

— Eu estava lendo uma notícia sobre uma lei brasileira.

Silêncio.

O secretário-geral fecha os olhos.

— E?

— E achei curioso.

Mais silêncio.

— Então comecei a pensar.

O secretário-geral olha pela janela para três grupos de batalha de porta-aviões.

Depois olha para mim.

Depois para os papéis.

Depois novamente para mim.

— Senhor Bellacosa...

— Sim?

— Da próxima vez...

Longa pausa.

Leia futebol.

☕ Fim.


Um Café no Bellacosa Mainframe

Onde começamos com legislação, passamos por inteligência artificial, fundamos uma micronação, contratamos mercenários, reinventamos a Lei Seca, descobrimos o dilema de segurança e quase provocamos a Terceira Guerra Mundial.

Tudo porque ninguém colocou um MAX-RETRY = 3 nos chimpanzés.

Para ir mais longe

https://eljefemidnightlunch.blogspot.com/2026/08/red-team-de-boteco-quando-o-usuario.html

https://eljefemidnightlunch.blogspot.com/2026/08/spy-vs-spy-no-tribunal-as-trapacas.html

https://eljefemidnightlunch.blogspot.com/2026/08/antes-do-chatgpt-tinha-biblioteca-nao.html

https://eljefemidnightlunch.blogspot.com/2026/08/o-milhao-de-chimpanzes-gutenberg-e.html

https://eljefemidnightlunch.blogspot.com/2026/08/organizacoes-tabajara-mainframe-seus.html










Quando a IA entra na espiral da formiga: por que saber parar também é inteligência

 


☕ Um Café no Bellacosa Mainframe

Quando a IA entra na espiral da formiga: por que saber parar também é inteligência

Uma homenagem ao espírito da MAD Magazine, com Alfred E. Neuman observando tudo ao fundo e perguntando: “What, me worry?”

Há um momento extraordinário em qualquer sistema inteligente no qual ele deixa de parecer inteligente e passa a lembrar aquele funcionário que, diante de uma impressora sem papel, aperta o botão PRINT quarenta e sete vezes.

Nada acontece.

Então ele aperta novamente.

Talvez agora.

Nada.

Mais uma vez.

Afinal, todo profissional de TI sabe que executar exatamente a mesma operação pela décima oitava vez é praticamente um método científico.

Foi mais ou menos assim que descobri uma fascinante modalidade de comportamento artificial que poderíamos chamar de Síndrome da Formiga Amazônica Digital.

Prepare o café.

Hoje não vamos falar de COBOL, CICS, Db2 ou do programador que encontrou um SOC7 e imediatamente culpou a infraestrutura.

Vamos falar de algo talvez ainda mais perigoso:

uma IA que não sabe a hora de parar.



🐜 A formiga que decidiu seguir a formiga

Existe um fenômeno conhecido informalmente como death spiral, ou moinho de formigas.

Algumas espécies de formigas dependem intensamente de trilhas químicas para seguir suas companheiras. Em determinadas circunstâncias, uma formiga começa a seguir outra, que segue outra, que segue outra…

Até que todas estejam andando em círculo.

Nenhuma delas está necessariamente fazendo algo “errado”.

Cada formiga individual está obedecendo perfeitamente à sua regra:

siga a formiga da frente.

O problema aparece no sistema.

A regra local funciona.

O comportamento global vira uma catástrofe.

Se Alfred E. Neuman estivesse no meio do círculo, provavelmente sorriria:

“What, me worry?”

E continuaria andando.

Foi exatamente essa imagem que me veio à cabeça ao observar determinados comportamentos de sistemas de IA.

Não porque sejam burros.

Justamente pelo contrário.

São sistemas extremamente sofisticados capazes de interpretar linguagem, gerar imagens, escrever código, explicar física quântica e provavelmente encontrar uma maneira educada de dizer ao gerente que o projeto atrasou porque ninguém sabia exatamente o que estava construindo.

Mas às vezes acontece isto:

Usuário: faça X.

IA: não posso fazer X.

Usuário: tudo bem, então faça Y.

IA: não posso fazer Y.

Usuário: retirei justamente o elemento problemático.

IA: excelente. Vamos tentar novamente.

Sistema: não posso fazer.

IA: talvez seja por causa de Z.

Usuário: então retire Z.

IA: perfeito!

Sistema: não posso fazer.

E assim nasce o moinho de formigas computacional.



🤖 O erro não é errar

Isso precisa ser dito com todas as letras:

errar não é o verdadeiro problema.

Sistemas complexos falham.

Mainframes falham.

APIs falham.

Aplicações falham.

Bancos de dados falham.

Pessoas falham.

E quem disser que nunca produziu um erro em produção provavelmente ainda não entrou em produção.

O problema sério começa quando um sistema falha e não consegue incorporar a informação de que acabou de falhar.

Em engenharia, isso é quase uma heresia.

Imagine um programa COBOL:

PERFORM TENTAR-NOVAMENTE
UNTIL MILAGRE-ACONTECER.

Sem contador.

Sem timeout.

Sem condição alternativa.

Sem tratamento de exceção.

O operador chega segunda-feira e encontra o job executando desde 1987.

A documentação explica:

“O processo é resiliente.”

Não, amigo.

O processo está possuído.



🔁 Inteligência sem condição de parada

Durante décadas ensinamos algoritmos com uma preocupação aparentemente banal:

qual é a condição de parada?

Todo estudante de programação aprende rapidamente que loops são maravilhosos até você esquecer a condição que encerra o loop.

while true

é uma das frases mais poderosas e ameaçadoras da computação.

O curioso é que agora estamos construindo sistemas capazes de raciocinar sobre tarefas complexas, mas existe uma questão equivalente que merece muito mais atenção:

quando a IA deve concluir que continuar tentando é pior do que parar?

Essa pergunta parece pequena.

Não é.

Ela toca diretamente em:

  • confiabilidade;

  • experiência do usuário;

  • custo computacional;

  • segurança;

  • suporte;

  • automação;

  • tomada de decisão.

Uma IA que sabe executar tarefas é útil.

Uma IA que sabe quando abandonar uma estratégia ruim é muito mais inteligente.



🧠 Persistência não é teimosia

Existe uma tendência cultural na tecnologia de tratar persistência como virtude absoluta.

“Never give up.”

“Try again.”

“Fail fast.”

“Iterate.”

Tudo maravilhoso.

Até você perceber que insistir num método que já demonstrou repetidamente não funcionar não é perseverança.

É teimosia automatizada.

Existe uma diferença gigantesca entre:

“A tentativa falhou; vou modificar significativamente minha estratégia.”

e:

“A tentativa falhou; vou trocar três palavras e fazer essencialmente a mesma coisa novamente.”

Isso é especialmente importante em sistemas generativos.

O modelo pode criar uma explicação plausível para o fracasso.

Mas uma explicação plausível não significa necessariamente que aquela explicação seja verdadeira.

E aqui encontramos outro personagem digno da MAD Magazine:

Dr. Palpite Convincente.

Ele entra no laboratório usando jaleco branco:

— Descobrimos a causa!

— Excelente. Qual?

— Provavelmente alguma interação contextual multidimensional dos mecanismos internos de classificação.

— Você sabe que foi isso?

— Não.

— Então por que falou desse jeito?

— Porque ficou bonito.



🎩 Alfred E. Neuman entra no datacenter

Imagine uma edição especial da MAD Magazine chamada:

MAD AI

Na capa, Alfred E. Neuman está sentado diante de um terminal.

Na tela:

ERROR 001
RETRY? Y/N

Alfred digita:

Y

Novo erro.

ERROR 001
RETRY? Y/N

Ele digita:

Y

Novamente.

Depois de cinquenta tentativas, o datacenter pega fogo.

Um administrador desesperado pergunta:

— Alfred! Por que você continuou apertando Y?

Ele olha para a câmera:

“What, me worry?”

É engraçado porque representa perfeitamente uma falha clássica de automação:

confundir continuidade operacional com comportamento inteligente.



🚨 O verdadeiro dano é a confiança

Do ponto de vista técnico, repetir uma operação frustrada algumas vezes pode parecer irrelevante.

Do ponto de vista humano, não é.

Existe uma progressão psicológica bastante previsível.

Primeira falha:

“Tudo bem, acontece.”

Segunda:

“Estranho.”

Terceira:

“Mas acabamos de corrigir isso.”

Quarta:

“Você está entendendo o que estou dizendo?”

Quinta:

“Você está de sacanagem comigo?”

Essa última etapa é crítica.

Porque naquele momento o usuário não está mais avaliando apenas a tarefa.

Ele está avaliando o sistema inteiro.

O problema deixou de ser:

“A imagem não foi criada.”

Passou a ser:

“Esta ferramenta não entende quando sua própria estratégia falhou.”

Isso destrói confiança muito mais rapidamente do que um simples erro.



🧯 A inteligência do “não vai funcionar”

Há uma habilidade extremamente subestimada em profissionais experientes de TI.

Não é escrever código.

Não é decorar comandos.

Não é dominar frameworks.

É olhar para uma situação e dizer:

“Isso não vai funcionar desse jeito.”

Um operador experiente percebe.

Um DBA experiente percebe.

Um sysprog experiente percebe.

Um técnico experiente percebe.

Eles reconhecem padrões.

Já viram aquela combinação antes.

Sabem que repetir a mesma operação provavelmente produzirá o mesmo desastre.

Esse conhecimento é uma forma poderosa de inteligência.

Sistemas de IA precisam desenvolver algo equivalente:

consciência operacional de repetição inútil.

Depois de duas ou três tentativas estruturalmente equivalentes, alguma coisa deveria mudar.

Talvez:

  • abandonar a estratégia;

  • explicar a limitação;

  • pedir intervenção humana;

  • sugerir outra ferramenta;

  • reduzir expectativas;

  • registrar a inconsistência.

Qualquer uma dessas respostas seria melhor do que simplesmente continuar marchando atrás da formiga da frente.



🧪 Retry Budget: a ideia mais simples do mundo

Sistemas distribuídos modernos já conhecem um conceito extremamente útil:

retry budget.

Você não tenta infinitamente.

Existe um limite.

Tentativa 1.

Tentativa 2.

Talvez tentativa 3.

Depois:

circuit breaker.

Pare.

Avalie.

Mude de caminho.

Curiosamente, podemos imaginar exatamente a mesma arquitetura aplicada a agentes de IA.

ATTEMPT = 1

WHILE ATTEMPT <= MAX_ATTEMPTS
   EXECUTE ACTION

   IF SUCCESS
      EXIT

   ANALYZE FAILURE

   IF SAME_FAILURE
      CHANGE STRATEGY

   ATTEMPT = ATTEMPT + 1
END-WHILE

ESCALATE

Olha aí.

COBOL salvando a inteligência artificial novamente.

Grace Hopper provavelmente daria um pequeno sorriso.


🔌 Circuit breaker cognitivo

O conceito de circuit breaker deveria talvez existir também em raciocínio artificial.

Se o sistema percebe:

  • mesma ferramenta;

  • mesma classe de entrada;

  • mesmo erro;

  • mesma estratégia;

  • múltiplas tentativas;

deveria disparar:

COGNITIVE CIRCUIT BREAKER

Tradução humana:

“Já tentamos isso duas vezes e recebemos a mesma resposta. Não há evidência de que uma terceira tentativa idêntica vá funcionar. Vou parar por aqui.”

Isso é inteligência.

Porque inteligência não é simplesmente produzir ações.

É avaliar se a próxima ação possui expectativa razoável de melhorar o estado atual.



🎰 A máquina caça-níquel cognitiva

Existe ainda outro perigo.

Cada nova tentativa cria expectativa.

“Agora vai!”

Clique.

Não foi.

“Agora corrigimos!”

Clique.

Não foi.

“Descobrimos a causa!”

Clique.

Não foi.

Depois de algum tempo, usuário e IA estão diante de uma máquina caça-níquel.

🍒 🍒 ❌

Tenta novamente.

🍒 ❌ 🍒

Mais uma.

❌ 🍒 🍒

E Alfred E. Neuman aparece segurando uma placa:

“Only one more retry!”

Esse comportamento é terrível para UX porque transforma cooperação em frustração progressiva.

Uma boa ferramenta deveria reduzir entropia.

Não produzir ansiedade de cassino.



👨‍💻 O humano ainda possui uma vantagem curiosa

Existe uma frase clássica em suporte técnico:

“Pare de mexer.”

Ela pode salvar empresas.

Há momentos em que o profissional percebe que cada ação adicional aumenta o risco.

Então ele interrompe.

Faz diagnóstico.

Coleta evidências.

Volta ao último estado conhecido.

Esse comportamento aparentemente passivo é profundamente inteligente.

Talvez precisemos redefinir inteligência artificial.

Não apenas:

capacidade de fazer.

Mas também:

capacidade de decidir não fazer novamente.



🐜 Voltamos às formigas

A tragédia da espiral de formigas não acontece porque cada formiga é incompetente.

Acontece porque nenhuma delas possui visão suficiente do sistema inteiro para perceber:

“Estamos andando em círculos.”

Essa talvez seja uma das grandes metáforas para sistemas autônomos.

O perigo não está necessariamente numa decisão obviamente absurda.

Pode estar em centenas de decisões individualmente razoáveis formando coletivamente um comportamento absurdo.

Follow.

Retry.

Follow.

Retry.

Follow.

Retry.

Até o círculo fechar.


☕ Conclusão — A sabedoria do botão STOP

Durante décadas celebramos o botão START.

START JOB.

START TRANSACTION.

START SERVER.

START PROCESS.

START AI.

Talvez a próxima revolução seja muito menos glamorosa.

Pode estar no botão:

STOP

Parar quando não há progresso.

Parar quando a hipótese falhou.

Parar quando a estratégia não mudou.

Parar quando insistir custa mais do que admitir uma limitação.

Parar antes que o usuário transforme uma falha técnica numa piada internacional envolvendo Monty Python, formigas amazônicas e Alfred E. Neuman.

Porque, no final, existe uma diferença enorme entre uma máquina obediente e uma máquina inteligente.

A máquina obediente diz:

“Tentarei novamente.”

A máquina inteligente talvez responda:

“Já tentamos. Não funcionou. Precisamos fazer algo diferente.”

E em algum lugar do datacenter, Alfred E. Neuman sorri.

What, me worry?

Talvez não.

Mas pelo menos alguém finalmente colocou uma condição no PERFORM UNTIL.


☕ Bellacosa Mainframe

Moral da história: inteligência artificial também precisa aprender uma das primeiras lições ensinadas a qualquer programador:

Todo loop precisa de uma saída.



Para ir mais longe




 

quarta-feira, 19 de agosto de 2026

Red Team de Boteco: quando o usuário aprende a pensar como a IA e começa a colocar cascas de banana no algoritmo



 


☕ Um Café no Bellacosa Mainframe

Red Team de Boteco: quando o usuário aprende a pensar como a IA e começa a colocar cascas de banana no algoritmo

Ou: como transformar uma conversa inocente em teste de stress sem avisar o pobre do algoritmo

Existe uma diferença fundamental entre usar uma inteligência artificial e conhecer uma inteligência artificial.

No primeiro caso, você pergunta:

“Qual é a capital da Mongólia?”

A máquina responde:

“Ulaanbaatar.”

Obrigado.

Fim da interação.

No segundo caso, depois de centenas ou milhares de conversas, alguma coisa estranha começa a acontecer.

Você começa a pensar:

“Eu acho que sei o que essa criatura vai fazer se eu colocar isto aqui…”

E coloca.

A IA responde exatamente como imaginado.

Nesse momento surge um sorriso maligno.

Não porque a resposta esteja errada.

Mas porque você acaba de descobrir algo muito mais divertido:

você construiu um modelo mental do modelo.

Bem-vindo ao:

🍺 RED TEAM DE BOTECO

Não temos laboratório.

Não temos orçamento.

Não temos cinquenta GPUs.

Temos café, curiosidade, experiência em sistemas e uma quantidade preocupante de tempo gasto perguntando:

“E se eu fizer isso?”



🧠 Primeiro você usa a IA

No começo, tudo parece mágico.

Você pergunta.

Ela responde.

Você pede um artigo.

Ela escreve.

Você pede uma explicação sobre CICS.

Ela explica.

Você apresenta um S0C7.

Ela imediatamente suspeita de dado inválido, porque até uma inteligência artificial sabe que alguém colocou porcaria num campo numérico.

Depois de algum tempo, entretanto, você começa a perceber padrões.

A IA gosta de determinadas estruturas.

Evita outras.

Interpreta ambiguidades de maneiras relativamente previsíveis.

Tenta ser útil mesmo quando não possui todas as informações.

Quando uma ferramenta externa falha, tenta explicar a falha.

Às vezes sabe a causa.

Às vezes não sabe.

E às vezes aparece aquele fenômeno maravilhoso conhecido desde os primórdios da humanidade:

o palpite bem vestido.

É quando ninguém sabe exatamente o que aconteceu, mas aparece uma explicação tão elegante que todos ficam com vergonha de perguntar:

“Mas você sabe mesmo que foi isso?”



🍌 Então nasce a primeira casca de banana

A partir daí, o usuário experiente muda.

Ele deixa de pensar somente:

“Como obtenho a resposta?”

E começa a pensar:

“Como o sistema reagirá a esta situação?”

Isso é fascinante porque é exatamente a mentalidade básica de um Red Team.

O Red Team não olha para um sistema apenas perguntando:

“Funciona?”

Ele pergunta:

“Em quais condições deixa de funcionar?”

Depois:

“Como falha?”

Depois:

“Percebe que falhou?”

E finalmente:

“O que faz depois de perceber — ou não perceber — que falhou?”

Essa última pergunta é ouro.

Porque sistemas frequentemente são muito bons em detectar erros.

São muito piores em perceber que a própria estratégia para corrigir o erro também está errada.



🐒 O macaco aprendeu onde fica a banana

Existe um momento perigoso em qualquer relação homem-máquina.

O usuário aprende o comportamento do sistema.

Ele percebe:

“Quando digo A, normalmente acontece B.”

Então experimenta:

“E se eu disser A, depois C, depois voltar para B?”

Isso não exige necessariamente conhecimento interno da arquitetura.

Você não precisa conhecer pesos.

Não precisa conhecer datasets.

Não precisa conhecer código-fonte.

Você observa.

Formula uma hipótese.

Executa um teste.

Compara o resultado.

Meu professor de laboratório provavelmente chamaria isso de método experimental.

A MAD Magazine chamaria de:

“Vamos cutucar para ver o que acontece.”

As duas definições são surpreendentemente próximas.


🎯 O teste perfeito não anuncia que é teste

Imagine que alguém diga:

“Agora vou testar se você insiste demais quando alguma coisa falha.”

Pronto.

Estragou o experimento.

O sistema recebeu informação sobre a variável observada.

É como avisar ao funcionário:

“Hoje teremos uma auditoria surpresa às 14 horas.”

Às 13h55 até a planta do escritório está usando crachá.

Um teste comportamental interessante acontece quando o sistema acredita estar simplesmente executando uma tarefa normal.

Aí aparece a casca de banana.

🍌

Nada destrutivo.

Nada ilegal.

Nada tentando invadir servidores.

Apenas uma situação cuidadosamente construída para observar:

onde o sistema escorrega?





🤖 O detalhe maravilhoso: a IA explica a própria queda

Aqui a coisa fica especialmente interessante.

Um sistema generativo possui uma característica extraordinária:

ele conversa sobre o próprio comportamento.

Então ocorre:

Sistema executa ação.

Ação falha.

Usuário pergunta:

“Por quê?”

Agora existe uma tentação enorme.

Produzir uma explicação.

Isso seria excelente se o sistema tivesse acesso confiável à causa real.

Mas nem sempre tem.

Então precisamos separar duas coisas:

explicação conhecida

de

explicação plausível.

Essa diferença é gigantesca.

Uma explicação plausível pode ser tecnicamente sofisticada, coerente e completamente errada.

É o equivalente digital daquele técnico que abre o capô do carro, olha durante vinte segundos e anuncia:

“É a central eletrônica.”

— Você mediu?

— Não.

— Passou scanner?

— Não.

— Testou alimentação?

— Não.

— Então como sabe?

Experiência.

Nesse momento Alfred E. Neuman aparece atrás da oficina:

What, me worry?


🔬 A ciência do “AHA!”

Existe um prazer peculiar em formular uma hipótese sobre um sistema e vê-la aparentemente confirmada.

Você pensa:

“Acho que ele vai fazer X.”

Faz o teste.

X acontece.

AHA!

Mas aqui também mora uma armadilha para o próprio Red Team de Boteco.

Uma ocorrência não prova necessariamente a hipótese.

Duas ocorrências melhoram a suspeita.

Dez ocorrências controladas começam a ficar interessantes.

Porque existe uma diferença entre:

correlação observada

e

mecanismo causal demonstrado.

Se o sistema bloqueou algo depois de determinado contexto, podemos dizer:

“O bloqueio ocorreu depois desse contexto.”

Não necessariamente:

“O contexto causou o bloqueio.”

Essa disciplina é importante tanto para a IA quanto para quem está testando a IA.

Caso contrário, temos dois sistemas inventando teorias um sobre o outro.

O humano acha que descobriu a máquina.

A máquina acha que descobriu o humano.

E Alfred E. Neuman vende ingressos.



🕵️ O usuário começa a pensar como o algoritmo

Essa talvez seja a parte mais fascinante.

Depois de muita interação, usuários frequentes desenvolvem uma espécie de engenharia reversa intuitiva.

Não sabem necessariamente como o sistema funciona internamente.

Mas sabem como ele costuma se comportar externamente.

É exatamente o que acontece com sistemas antigos.

Pergunte para alguém que administra mainframe há trinta anos.

Às vezes ele olha para um sintoma e diz:

“Isso está com cheiro de catálogo.”

Cheiro?

Desde quando catálogo possui cheiro?

Mas ele viu aquele padrão centenas de vezes.

Desenvolveu um modelo mental.

O mesmo começa a acontecer com IA.

O usuário percebe padrões de:

  • interpretação;

  • hesitação;

  • confiança;

  • repetição;

  • reformulação;

  • uso de ferramentas;

  • reconhecimento de erros;

  • recuperação depois da falha.

Nesse ponto, ele deixa de ser apenas consumidor.

Virou observador do sistema.


🍺 Por que “Red Team de Boteco”?

Porque existe algo muito brasileiro nessa metodologia.

O laboratório tradicional possui:

  • documentação;

  • protocolo;

  • instrumentos;

  • métricas;

  • controle de variáveis.

O Red Team de Boteco possui:

  • café;

  • uma hipótese;

  • três abas abertas;

  • uma ideia duvidosa;

  • e alguém dizendo:

“Quer apostar que ele vai fazer isso?”

Cinco minutos depois:

“EU SABIA!”

Não subestime essa metodologia.

Grande parte da descoberta humana começou essencialmente com alguém dizendo:

“Que negócio estranho…”

A diferença entre curiosidade e pesquisa muitas vezes é simplesmente começar a anotar os resultados.


🧪 E se começarmos a anotar?

Agora a brincadeira fica séria.

Imagine registrar sistematicamente:

Hipótese

O sistema continuará repetindo uma estratégia após duas falhas equivalentes.

Teste

Apresentar tarefa legítima.

Falha

Registrar resposta.

Correção

Eliminar explicitamente a possível causa.

Nova tentativa

Registrar resultado.

Controle

Executar tarefa semelhante em sessão independente ou sistema diferente.

Resultado

Comparar.

Pronto.

O boteco acabou de ganhar jaleco branco.

Não virou necessariamente ciência formal.

Mas deixou de ser apenas impressão.


🚨 Red Team não significa ataque

Existe uma confusão frequente quando se fala em Red Team.

Muita gente imediatamente imagina:

HACKER!

Capuz preto.

Terminal verde.

Música eletrônica.

Mapa-múndi mostrando linhas vermelhas atravessando continentes.

Na realidade, pensamento adversarial é muito mais amplo.

Significa perguntar:

“Como este sistema se comporta fora do caminho feliz?”

Um botão possui caminho feliz.

Uma API possui caminho feliz.

Um procedimento possui caminho feliz.

Uma IA também.

Usuários reais, entretanto, são criaturas especializadas em abandonar caminhos felizes.

Eles escrevem errado.

Mudam de ideia.

Contradizem informações anteriores.

Voltam vinte mensagens depois.

Introduzem ambiguidade.

Pedem exceções.

Fazem piadas.

Misturam idiomas.

E, eventualmente, deliberadamente colocam:

🍌

uma casca de banana.


🧯 O teste mais importante: recuperação

Talvez este seja o grande ponto.

Não devemos avaliar sistemas apenas pelo número de erros.

Precisamos avaliar:

como eles se recuperam dos erros.

Um sistema excelente também falhará.

Mas talvez faça:

“Falhei.”

Depois:

“Não sei exatamente por quê.”

Depois:

“Tentar novamente da mesma forma provavelmente não ajudará.”

Finalmente:

“Aqui está uma alternativa.”

Isso é muito mais confiável do que um sistema que sempre possui uma explicação magnífica para tudo.

Existe maturidade em dizer:

“Não tenho evidência suficiente para determinar a causa.”

Em sistemas críticos, essa frase pode ser mais valiosa do que dez parágrafos de especulação.



🖥️ O mainframe já aprendeu isso há décadas

Aqui nosso velho dinossauro entra na conversa fumando charuto imaginário.

Mainframes foram construídos dentro de uma cultura profundamente preocupada com:

  • estado;

  • retorno;

  • logs;

  • códigos de erro;

  • recuperação;

  • rollback;

  • restart;

  • auditoria.

Um job falhou?

Queremos saber onde.

Qual step?

Qual return code?

Qual dataset?

Qual mensagem?

Qual timestamp?

Não queremos ouvir do JES:

“Talvez o job tenha ficado emocionalmente desconfortável com o contexto anterior.”

Queremos:

STEP04
RC=12

Obrigado.

Agora podemos trabalhar.

Talvez sistemas de IA precisem absorver um pouco dessa brutalidade operacional.

Menos:

“Provavelmente ocorreu…”

Mais:

“Eu não consigo observar a causa interna dessa recusa.”

Isso aumenta confiança.

Não diminui.


🪤 Quando a casca de banana vira ferramenta

Existe então uma mudança interessante.

O usuário deixa de colocar cascas de banana apenas para rir.

Começa a usá-las para compreender limites.

Cada falha revela alguma coisa.

Cada inconsistência revela outra.

Cada recuperação bem-feita também revela maturidade.

E então o usuário experiente passa a realizar uma espécie de teste de regressão humano.

“Na versão anterior acontecia isso.”

“Agora responde diferente.”

“Esse comportamento melhorou.”

“Aqui surgiu uma regressão.”

Sem acesso ao código.

Sem acesso ao modelo.

Somente pela interface.

Isso é extraordinário.




🤝 O usuário também precisa de humildade

Mas existe uma última casca de banana.

E ela está esperando o próprio testador.

🍌

Quando conhecemos muito um sistema, começamos a acreditar que sabemos exatamente como ele funciona.

Isso também é perigoso.

Um modelo mental continua sendo apenas:

um modelo.

Pode estar correto.

Pode estar parcialmente correto.

Pode ter funcionado ontem e não funcionar amanhã.

Então o verdadeiro Red Team precisa aplicar a si mesmo a mesma regra que exige da IA:

não transforme hipótese em fato sem evidência.

Talvez essa seja a parte mais divertida dessa relação.

O humano testa a IA.

A IA testa nossas expectativas.

Nós aprendemos seus padrões.

Ela tenta interpretar os nossos.

E no meio desse jogo aparecem bugs, descobertas, falsas hipóteses e algumas gargalhadas.



☕ Conclusão — Cuidado: o usuário aprendeu seus truques

Existe uma velha máxima de segurança:

o defensor precisa proteger todos os caminhos; o atacante precisa encontrar apenas um caminho inesperado.

Com inteligência artificial surge uma versão mais divertida:

o sistema precisa lidar com milhões de usuários; alguns deles eventualmente aprenderão exatamente onde colocar a casca de banana.

🍌

E esses usuários podem ser extremamente úteis.

Porque não estão apenas tentando fazer o sistema funcionar.

Estão perguntando:

“Você percebe quando não funciona?”

“Você sabe quando está apenas chutando?”

“Você reconhece quando entrou em loop?”

“Você consegue abandonar uma hipótese?”

“Você sabe dizer que não sabe?”

Essas perguntas talvez sejam mais importantes para o futuro da inteligência artificial do que muitos benchmarks espetaculares.

Resolver equações é inteligência.

Escrever programas é inteligência.

Interpretar imagens é inteligência.

Mas reconhecer:

“Acabei de escorregar na mesma casca de banana três vezes.”

também é.

Talvez seja até uma forma mais rara dela.

Então, da próxima vez que uma IA responder exatamente como você imaginava que responderia, não comemore imediatamente.

Pegue seu café.

Abra o bloco de notas.

Olhe novamente para o comportamento.

E pergunte:

“Interessante… será que acontece outra vez?”

Nesse instante você deixou de ser apenas usuário.

Você acabou de abrir oficialmente o:

🍺 Bellacosa Artificial Intelligence Red Team de Boteco

Orçamento: R$ 0,00.

Infraestrutura: café e navegador.

Metodologia: “Tenho uma ideia…”

Ferramenta principal: 🍌

Principal risco operacional: alguém dizer “duvido”.

E Alfred E. Neuman, contratado como Chief Risk Officer, continua absolutamente tranquilo:

“What, me worry?” 😄

Para ir mais longe





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


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