AI Decision System: decisioni sull’IA verificabili anche offline
Come AI Decision System conserva regole, input e approvazioni per ricontrollare le decisioni assistite dall’IA, e quali limiti restano sull’autenticità.
Newsletter del 14 ottobre 2026
Una decisione assistita dall’IA diventa più controllabile quando conserva gli elementi necessari a ricalcolarla: input, regole applicate e approvazioni. È il problema affrontato da AI Decision System, un repository che raccoglie strumenti per produrre registrazioni verificabili offline di decisioni come approvare una richiesta, promuovere una variante sperimentale o valutare un rilascio.
Il valore pratico riguarda chi sviluppa procedure di valutazione e revisione: poter ricontrollare una decisione senza dipendere soltanto dal resoconto di una dashboard. La documentazione descrive però pacchetti indipendenti, non una piattaforma integrata. Inoltre, gli esempi sintetici dimostrano il funzionamento del software, senza stabilire la qualità dei modelli o l’efficacia in produzione.
Che cosa conserva ciascun componente
Il repository distingue quattro punti decisionali. I primi tre pacchetti richiedono Python 3.11 o successivo, usano soltanto la libreria standard durante l’esecuzione e hanno licenze MIT proprie. Nella documentazione fornita sono indicati come release GitHub 0.1.0, con pubblicazione su PyPI ancora in attesa.
| Componente | Decisione documentata | Materiale per il ricontrollo | Limite da considerare |
|---|---|---|---|
| Jev decision | Risposte tipizzate e criteri di qualità | Risposte, evaluation.json, provenienza e input conservati | La confidenza dichiarata dal fornitore non garantisce sicurezza calibrata |
| decision-control | Regole di instradamento e approvazione umana | Registrazione esportata, verificabile con replay | È uno strumento locale fidato, non un servizio di identità |
| Experiment gate | Esiti SHIP, HOLD, ROLLBACK, INVALID | decision.json con input incorporati | Consuma aggregati esportati; non conduce esperimenti né distribuisce modelli |
| RELIA | Criteri sintetici di rilascio e aggiornamento | results.json e MANIFEST.json | Non è rilasciato e richiede un ambiente separato |
Le frecce che collegano questi componenti nel README illustrano possibili passaggi decisionali. Non documentano connessioni già implementate. Per un team, questo significa valutare ogni pacchetto separatamente e progettare l’eventuale integrazione.
Riprodurre una decisione richiede più del risultato
Conservare soltanto “approvato” o “respinto” non permette di ricostruire perché sia stato ottenuto quell’esito. Il progetto propone invece di trattenere dati e regole sufficienti a rieseguire il controllo.
I requisiti cambiano tra componenti. Experiment gate include gli input nella registrazione della decisione. Jev richiede di conservare anche domande, casi e requisiti insieme alle risposte da rivalutare. decision-control congela la politica applicata e le informazioni sul proponente e sulla revisione.
La conseguenza operativa è precisa: prima di adottare uno strumento, occorre definire quali file costituiscono una registrazione completa. Un controllo utile consiste nel consegnare quel materiale a un revisore in un ambiente separato e verificare se riesce a ricomputare l’esito senza recuperare informazioni mancanti.
Questa è una proposta di valutazione, non una prova svolta qui. La fonte descrive i comandi di verifica, ma non dimostra che qualsiasi flusso aziendale diventi riproducibile automaticamente.
Come impostare una prima valutazione locale
Il README documenta l’installazione dei singoli progetti da Git in un ambiente virtuale. Per Experiment gate, per esempio:
pip install "git+https://github.com/BichengWang/ai-decision-system#subdirectory=ai-workflows/experiment-gate"Gli esempi devono essere eseguiti dalla directory principale di un clone del repository: sono presenti nei sorgenti e nella distribuzione sorgente, ma non vengono installati come dati del pacchetto wheel.
experiment-gate \
--input ai-workflows/experiment-gate/examples/offer-ranker-v2.json \
--out /tmp/expgate-review
experiment-gate-verify /tmp/expgate-review/decision.jsonLa directory di output deve essere nuova. Gli esempi documentati usano dati predisposti manualmente o sintetici e non effettuano chiamate ai fornitori. Le chiamate effettive tramite Jev richiedono invece TYPESAFE_API_KEY oppure OPENAI_API_KEY, secondo il backend scelto.
Per decidere se proseguire, conviene verificare tre aspetti: completezza degli input conservati, comprensibilità dei criteri applicati e possibilità di ricontrollare l’esito attraverso il comando previsto. Questi criteri misurano l’utilità della registrazione nel proprio processo, senza attribuire agli esempi prestazioni che non dimostrano.
Integrità e autenticità restano problemi distinti
La documentazione esplicita un limite centrale: gli hash rilevano modifiche, ma non impediscono la falsificazione. Le identità sono dichiarate dal chiamante e l’origine delle risposte del fornitore non viene autenticata.
Di conseguenza, una registrazione ricalcolabile non prova da sola chi abbia approvato una decisione o quale servizio abbia prodotto una risposta. Anche la separazione dei compiti basata su etichette, prevista da decision-control, va interpretata entro questo confine.
L’implicazione progettuale è che identificazione degli operatori e attendibilità della raccolta degli input richiedono una valutazione separata. Il replay risponde alla domanda “questi dati e queste regole producono questo esito?”, ma non risolve automaticamente la provenienza dei dati.
RELIA presenta ulteriori vincoli: usa Python 3.13, con versione 3.13.7 fissata per la riproduzione, e richiede esecuzioni nuove, confronto con riferimenti e attestazioni dei revisori. La fonte non dichiara un rilascio pubblico accettato né concede diritti d’uso attuali. I risultati sintetici non dimostrano prestazioni commerciali, equità o conformità normativa.
FAQ
Serve una connessione al modello per ripetere la valutazione?
Gli esempi descritti non chiamano fornitori. Il ricontrollo offline dipende dalla conservazione del materiale richiesto dal componente, comprese le risposte già prodotte quando necessarie.
Experiment gate può pubblicare automaticamente una variante?
No. Produce una decisione a partire da aggregati esportati. Non esegue l’esperimento e non distribuisce il modello: queste operazioni restano esterne al suo perimetro documentato.
Un esito positivo dei test valida tutto il repository?
No. Il README distingue ambienti e suite. workspace-check controlla strumenti, sintassi, confini e collegamenti Markdown, senza eseguire tutte le verifiche comportamentali. Anche il superamento locale dei controlli RELIA non equivale all’accettazione del rilascio.