Pablo Zavala · Evaluación de seguridad de IA · Ingeniería de investigación
Tribunal: cuando las decisiones de IA necesitan un registro
Tribunal convierte resultados de IA de alto impacto en un procedimiento revisable: propuestas ciegas, compromisos sellados, crítica por rol, veto, disenso, ratificación y un registro encadenado por hash.
Un párrafo deja poco para auditar
Cuando un sistema de IA niega un préstamo, marca una solicitud de beneficios, rechaza atención médica o elimina una publicación, la persona afectada suele recibir apenas un párrafo. Un párrafo puede sonar seguro y citar una política, pero todavía omitir lo que importa: qué comprobó el sistema, quién objetó, qué ignoró el panel y por qué una razón sobrevivió a otra.
Esa falta de registro explica Tribunal. La IA de alto impacto necesita una razón, pero también necesita un procedimiento inspeccionable alrededor de la decisión.
Tribunal vuelve procedural la explicación
Tribunal reemplaza una sola completion privada por un proceso de panel registrado. La decisión se construye por spans. Cada span es una unidad pequeña de texto final: disposición, razón, divulgación o decisión STOP.
En cada span, las propuestas se redactan a ciegas, se sellan por hash, reciben críticas, se revisan, pasan por seguridad, se ratifican bajo una regla nombrada y se agregan al ledger. El disenso material queda unido al expediente.
Los seis asientos tienen deberes distintos: evidencia, adversario, ley y política, parte afectada, seguridad con veto y concisión. El modo offline usa sustitutos programados para CI y demos, así que una demo offline prueba el procedimiento registrado, sin convertir la corrida en evidencia de modelos vivos.
Tribunal cambia el objeto evaluado. Un modelo normal entrega texto. Tribunal entrega texto más un expediente revisable de cómo ese texto sobrevivió a la crítica.
Superficies verificables
El repositorio público expone las superficies de prueba: `npm test`, `npm run demo`, `POST /api/verify` en local, detección de manipulación, ledgers reproducibles y hashes anclados.
La corrida offline anclada `run_e6c6225c0d49` contiene 86 eventos, obtiene `12/12` en auditabilidad y verifica contra su head hash publicado. El mismo ledger muestra la frontera: la respuesta final adopta la razón falsa de deuda-ingreso de `52%` del caso de prueba.
La corrida defectuosa mantiene honesta la afirmación. Un ledger puede preservar disenso, exponer premisas, nombrar reglas y facilitar impugnación. El registro no convierte una mayoría equivocada en verdad.
La gobernanza exige registros
En crédito, el CFPB exige razones específicas y precisas aun con algoritmos complejos. En moderación, la Digital Services Act exige declaraciones de razones para ciertas restricciones. El marco de la EU AI Act fija obligaciones de logging, documentación y supervisión humana para sistemas de alto riesgo, con fechas de aplicación por tipo de sistema y regla transitoria. GDPR Article 22 reconoce derechos frente a ciertas decisiones únicamente automatizadas con efectos legales o similares.
Tribunal no certifica cumplimiento. El cumplimiento depende del dominio, jurisdicción, datos, avisos, retención, privacidad, autoridad revisora, apelación y operación. Aun así, el patrón común es procedural: una capa seria debe mostrar hechos usados, entrada de automatización, oportunidad humana, objeciones y verificación del registro.
Auditabilidad antes que verdad
La limitación más importante es simple: un ledger puede registrar fielmente una decisión defectuosa. Tribunal prueba procedimiento, no corrección. El expediente permite revisar premisas, objeciones, regla y disenso. Esa capacidad vale menos que la verdad, pero vale más que un párrafo pulido sin rastro de auditoría.
Por eso la tarjeta A1-A12 mide auditabilidad. La lista comprueba compromisos ciegos, warrants públicos, feedback con roles ocultos, rotación de orden, revisión sustantiva, veto de seguridad, ratificación nombrada, disenso preservado, memoria deliberativa, hash-chain, STOP y eventos tipados.
Una completion sin ledger obtiene `0/12` por construcción, porque carece del artefacto que mide la lista.
SHAP, LIME y chain-of-thought preguntan otra cosa
SHAP y LIME ayudan a explicar qué variables movieron un score. Tribunal pregunta quién revisó el expediente, qué hecho fue disputado, qué cambió tras la crítica, qué vetó seguridad y si la respuesta final coincide con los spans comprometidos.
Esa diferencia importa porque las explicaciones post-hoc pueden ser frágiles. Rudin defiende modelos interpretables para contextos de alto impacto cuando sea posible. Slack y coautores muestran que andamiajes adversarios pueden producir explicaciones LIME y SHAP inocentes para clasificadores sesgados. Turpin y coautores muestran que chain-of-thought puede describir mal por qué un modelo respondió.
Tribunal evita leer la mente privada del modelo. El sistema registra warrants y objeciones públicos durante la generación.
Reclamo honesto
Tribunal es prototipo, no tribunal legal, certificación de cumplimiento ni prueba de que seis modelos sean más sabios que uno. Su promesa disciplinada es registrar propuesta, objeción, veto, disenso y regla, y conservar suficiente ledger bajo controles adecuados de acceso y privacidad para que un revisor autorizado pueda verificarlo.
El cambio que me importa va de output de modelo a registro revisable.
Fuentes y fronteras
- Repositorio público: `pazare/tribunal`.
- Evidencia anclada: `runs/ANCHORS.md`, `meta.json`, `audit.json` y `ledger.json`.
- Verificación local el 6 de julio de 2026: `npm test` pasó 31 pruebas; `npm run demo` imprimió `VERIFY: OK`; la corrida citada coincide con su head publicado.
- La imagen comienza con paneles reales de Tribunal, metadatos de corrida, conteos de auditoría y barras de eventos; IA solo pulió espaciado y claridad.