Pablo Zavala · Avaliação de segurança de IA · Engenharia de pesquisa
Tribunal: quando decisões de IA precisam de um registro
Tribunal transforma saídas de IA de alto risco em um procedimento revisável: propostas cegas, compromissos selados, crítica por papel, veto, dissenso, ratificação e registro encadeado por hash.
!Painel de dados do Tribunal construído com capturas reais, contagens de ledger e diagrama de decisão
Um parágrafo deixa pouco para auditar
Quando um sistema de IA nega um empréstimo, marca um pedido de benefício, rejeita atendimento ou remove uma publicação, a pessoa afetada costuma receber pouco além de um parágrafo. Um parágrafo fluente pode citar uma política e ainda omitir os fatos institucionais centrais: o que o sistema verificou, quem contestou, o que o painel rejeitou e por que uma razão venceu outra.
Essa lacuna de registro explica Tribunal. IA de alto impacto precisa de uma justificativa, mas também precisa de um procedimento inspecionável em torno da decisão.
Tribunal torna a explicação procedural
Tribunal substitui uma completion privada por um processo de painel registrado. A decisão é construída span por span. Um span é uma pequena unidade do texto final: disposição, razão, divulgação ou decisão STOP.
Em cada span, propostas são redigidas às cegas, seladas por hash, criticadas, revisadas, avaliadas por segurança, ratificadas sob uma regra nomeada e anexadas ao ledger. O dissenso material permanece no registro.
Os seis assentos têm funções distintas: evidência, adversário, lei e política, parte afetada, segurança com veto e concisão. O modo offline usa substitutos roteirizados para CI e demos; uma demo offline prova o procedimento registrado, em vez de independência de modelos ao vivo.
Tribunal muda o objeto avaliado. Um modelo comum entrega texto. Tribunal entrega texto mais um registro revisável de como esse texto sobreviveu à crítica.
Superfícies verificáveis
O repositório público expõe as superfícies de prova: `npm test`, `npm run demo`, `POST /api/verify` local, detecção de adulteração, ledgers reproduzíveis e head hashes ancorados.
A corrida offline ancorada `run_e6c6225c0d49` contém 86 eventos, recebe `12/12` em auditabilidade e verifica contra seu head hash publicado. O mesmo ledger mostra a fronteira dura do projeto: a resposta final adota a razão falsa de dívida-renda de `52%` do caso de teste.
A corrida falha mantém a tese honesta. Um ledger pode preservar dissenso, expor premissas, nomear regras e facilitar contestação. O registro não transforma uma maioria ruim em verdade.
Governança exige registros
Em crédito, o CFPB exige razões específicas e precisas mesmo com algoritmos complexos. Em moderação, o Digital Services Act exige statements of reasons para certas restrições. O marco da EU AI Act estabelece obrigações de logging, documentação e supervisão humana para sistemas de alto risco, com datas de aplicação que variam por sistema e regra de transição. GDPR Article 22 reconhece direitos em certas decisões totalmente automatizadas com efeitos legais ou similares.
Tribunal não certifica conformidade. Conformidade depende de domínio, jurisdição, dados, aviso, retenção, privacidade, autoridade revisora, apelação e operação. Ainda assim, o padrão de governança é procedural: uma camada séria deve mostrar fatos usados, entrada de automação, oportunidade humana, objeções e verificação do registro.
Auditabilidade em vez de verdade
A limitação mais importante é simples: um ledger pode registrar fielmente uma decisão falha. Tribunal prova procedimento, não correção. O registro permite inspecionar premissas, objeções, regra e dissenso. Essa capacidade vale menos que verdade, mas vale mais que um parágrafo polido sem trilha de auditoria.
Por isso, o cartão A1-A12 mede auditabilidade. A lista verifica compromissos cegos, warrants públicos, feedback com papéis ocultos, rotação de ordem, revisão substantiva, veto de segurança, ratificação nomeada, dissenso preservado, memória deliberativa, hash-chain, STOP e eventos tipados.
Uma completion sem ledger recebe `0/12` por construção porque carece do artefato medido.
SHAP, LIME e chain-of-thought fazem outra pergunta
SHAP e LIME ajudam a explicar quais variáveis moveram uma pontuação. Tribunal pergunta quem verificou o arquivo, qual fato foi contestado, o que mudou depois da crítica, o que a segurança vetou e se a resposta final corresponde aos spans comprometidos.
Essa distinção importa porque explicações post-hoc podem ser frágeis. Rudin defende modelos interpretáveis em contextos de alto impacto quando possível. Slack e coautores mostram que andaimes adversários podem produzir explicações LIME e SHAP inocentes para classificadores enviesados. Turpin e coautores mostram que chain-of-thought pode descrever mal por que um modelo respondeu.
Tribunal evita ler a mente privada do modelo. O sistema registra warrants e objeções públicos durante a geração.
Afirmação honesta
Tribunal é protótipo, não tribunal legal, certificação de conformidade ou prova de que seis modelos são mais sábios que um. A promessa disciplinada é registrar proposta, objeção, veto, dissenso e regra, e preservar ledger suficiente sob controles adequados de acesso e privacidade para que um revisor autorizado possa verificar.
A mudança que importa vai de output de modelo para registro revisável.
Fontes e fronteiras
- Repositório público: `pazare/tribunal`.
- Evidência ancorada: `runs/ANCHORS.md`, `meta.json`, `audit.json` e `ledger.json`.
- Verificação local em 6 de julho de 2026: `npm test` passou 31 testes; `npm run demo` imprimiu `VERIFY: OK`; a corrida citada corresponde ao head publicado.
- A imagem começa com painéis reais do Tribunal, metadados de corrida, contagens de auditoria e barras de eventos; IA apenas poliu espaçamento e clareza.