 |
| 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
ALTERno 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.
Sem comentários:
Enviar um comentário