Quando si parla di intelligenza artificiale supervisionata, molte organizzazioni dichiarano di avere un controllo umano sul processo. Il problema, nella pratica, non è dichiararlo. Il problema è dimostrarlo in modo verificabile, coerente e difendibile anche all’esterno del sistema che ha generato la decisione.
Per questo motivo abbiamo raccolto in questa pagina le domande più frequenti sul framework THE </AI> PROTOCOL, con risposte chiare, tecniche e orientate alla realtà operativa di audit, governance, verifica documentale e possibile contenzioso.
Indice delle domande
A. Il protocollo: definizione e scopo
→ Che cos’è il Protocollo </AI>?
→ Il protocollo certifica che la decisione AI era corretta?
→ Quale problema risolve rispetto alla normale AI governance?
→ È la stessa cosa di un registro gestito dal vendor?
→ Che differenza c’è tra supervisione dichiarata e supervisione dimostrabile?
B. Il modello tecnico
→ Che cosa si intende per “decision context”?
→ Il protocollo prende in carico processi ancora aperti o in evoluzione?
→ Qual è il ruolo dell’identità umana nel protocollo?
→ Come vengono gestiti timestamp e riferimenti temporali?
→ Come viene protetta l’integrità dell’output o della decisione?
→ Che cos’è l’hash di intake e come si distingue dall’hash sorgente?
→ Che cosa significa “chiusura dichiarata”?
C. Compatibilità e integrazione
→ Il protocollo funziona solo con ChatGPT, Claude o Gemini?
→ Serve una integrazione API per usare il framework?
→ È compatibile con i framework di governance già adottati?
→ È compatibile con l’AI Act europeo?
D. Valore probatorio e difendibilità
→ Il protocollo può essere utile in audit, verifiche o contenziosi?
→ Che tipo di prova o documentazione produce il sistema?
→ Protegge dal rischio di revisione postuma dei log?
→ Cosa succede se l’autorità dichiarata alla chiusura viene contestata?
→ Il protocollo copre il “momento zero”, cioè l’istante della decisione reale?
E. A chi si rivolge
→ Chi dovrebbe interessarsi a questo framework?
→ È rilevante per studi legali e consulenti?
→ Che valore ha per un’azienda che già usa AI nei propri processi?
F. Catena di evidenze e gestione multi-organizzazione
→ Che cos’è la catena di evidenze verificabili?
→ Il collegamento tra intake altera l’integrità del singolo elemento?
→ In quali scenari è utile la catena di evidenze?
→ Un professionista può gestire più organizzazioni con un solo accesso?
→ Come funziona la fatturazione in un contesto multi-organizzazione?
→ Quali ruoli esistono all’interno di un’organizzazione?
G. Contesto e rischi emergenti
→ Gli agenti AI rappresentano davvero un rischio per le organizzazioni?
→ È meglio limitare gli agenti AI o rendere le loro decisioni verificabili?
→ Cosa succede se un sistema AI si comporta in modo imprevedibile?
→ Chi è responsabile se un sistema AI genera errori?
→ Il sistema impedisce dichiarazioni false o abusi?
H. Stato del progetto e prossimi passi
→ A che punto è il progetto?
→ Dove trovare maggiori informazioni?
Che cos’è il Protocollo </AI>?
Il Protocollo </AI> è un framework operativo pensato per trasformare una supervisione umana dichiarata in una supervisione umana dimostrabile. L’idea di fondo è semplice: non basta dire che un essere umano era “in the loop”. Occorre poter dimostrare, in modo strutturato, chi era il soggetto responsabile, quale decisione è stata chiusa, in quale contesto, con quale integrità e in quale momento.
Il framework non nasce per sostituire i sistemi di governance già esistenti. Nasce per colmare un vuoto molto specifico: il passaggio da un controllo interno dichiarato a un’unità probatoria verificabile anche da terzi.
Il protocollo certifica che la decisione AI era corretta?
No. Questo è uno dei punti più importanti da chiarire.
Il protocollo non certifica che il processo decisionale fosse corretto, equo, conforme o legittimo nel merito. Non entra nel cuore logico del sistema sorgente e non sostituisce il giudizio giuridico, etico o organizzativo sul processo che ha portato alla decisione.
Il suo scopo è diverso: creare un punto esterno, strutturato e verificabile che attesti che una certa unità decisionale è stata ricevuta in uno stato definito, con una certa struttura, con certi riferimenti di contesto e con una precisa integrità al momento dell’intake.
In termini più diretti: il sistema non promette la verità sostanziale della decisione, ma la fissazione verificabile dello stato dichiarato al momento dell’intake.
Quale problema risolve rispetto alla normale AI governance?
La governance tradizionale si occupa di regole, ruoli, processi, approvazioni, responsabilità e controlli interni. Tutto questo è necessario. Ma spesso non basta quando una decisione viene contestata o deve essere dimostrata fuori dal sistema che l’ha generata.
In quel momento la domanda cambia. Non è più soltanto “esisteva una procedura di controllo?”. Diventa invece “possiamo dimostrare in modo indipendente cosa è successo davvero, chi ha assunto la responsabilità, quale stato aveva l’oggetto decisionale e quando è entrato nella catena di custodia?”.
Il protocollo interviene proprio qui, in questo spazio. Non sostituisce la governance. Aggiunge un layer probatorio esterno.
È la stessa cosa di un registro gestito dal vendor?
No. La differenza è architetturale.
Un registro gestito dal vendor resta normalmente dentro il confine di fiducia del sistema che ha prodotto la decisione. In altre parole, il soggetto che genera il dato, spesso, controlla anche il luogo in cui quel dato viene registrato, conservato, esposto o riesposto.
Il Protocollo </AI>, invece, è pensato come un layer esterno di intake evidenziario. Il valore non sta nel dire “fidatevi di ciò che il sistema dichiara”. Il valore sta nel separare la decisione dal suo ambiente originario e fissarla in un punto esterno, con una presa in carico strutturata e verificabile, che non dipende dalla sopravvivenza o dalla correttezza del sistema che l’ha prodotta.
Che differenza c’è tra supervisione dichiarata e supervisione dimostrabile?
La supervisione dichiarata è un’affermazione. La supervisione dimostrabile è una struttura.
Nel primo caso si dice che un essere umano ha visto, approvato, controllato o chiuso qualcosa. Nel secondo caso esiste un’unità in cui quella responsabilità, quel contesto, quel riferimento temporale e quella integrità vengono registrati in modo tale da poter essere verificati successivamente, anche da soggetti che non erano presenti e non hanno motivo di fidarsi del sistema originario.
La distanza tra queste due condizioni è esattamente il vuoto che il protocollo prova a colmare.
Che cosa si intende per “decision context”?
Con “decision context” intendiamo un’unità decisionale sufficientemente chiusa e interpretabile da poter entrare in una catena probatoria esterna. Non si tratta di un file generico o di un JSON qualsiasi. Si tratta di un oggetto che rappresenta una decisione già maturata abbastanza da poter essere presa in carico senza ambiguità.
Questo contesto può includere, ad esempio, l’identità dichiarata dell’autorità umana, il risultato della decisione, lo stato di chiusura, la versione delle regole applicate, il riferimento contestuale, i timestamp rilevanti e gli elementi di integrità. L’obiettivo non è accumulare più dati possibile, ma fissare il set strutturale minimo necessario a rendere l’unità interpretabile e difendibile anche fuori dal sistema originario.
Il protocollo prende in carico processi ancora aperti o in evoluzione?
No. Il framework è stato pensato proprio per evitare l’ingresso di oggetti ancora fluidi o in fase di elaborazione.
L’idea centrale è che l’unità debba essere già abbastanza chiusa da poter essere ricevuta come unità evidenziaria pronta alla presa in carico. Se un processo è ancora aperto, negoziabile, modificabile o non ratificato, non siamo ancora davanti a un oggetto stabile da ancorare esternamente.
Questo principio è importante anche per evitare ambiguità, conflitti interpretativi e falsi punti di ancoraggio. La chiusura non viene verificata nel merito: viene richiesta come condizione di ammissibilità all’ingresso.
Qual è il ruolo dell’identità umana nel protocollo?
L’identità del supervisore o dell’autorità umana è uno degli elementi chiave del framework. Non perché il sistema debba validare ogni aspetto del processo interno, ma perché una supervisione dimostrabile richiede un riferimento umano dichiarato, riconoscibile e strutturato.
Nel modello operativo, l’identità è collegata al certificato DAPI: un sistema di identificazione verificata che permette di associare la responsabilità dichiarata a un soggetto umano identificato in modo coerente nel tempo. Questo punto è essenziale per distinguere una semplice dichiarazione narrativa da una responsabilità documentabile.
Il framework non tenta di ricostruire o certificare il percorso interno di intervento umano. Cattura il punto in cui una decisione diventa attribuibile: chi assume la responsabilità del risultato nel momento in cui viene dichiarata chiusa.
Come vengono gestiti timestamp e riferimenti temporali?
Il framework è costruito intorno a una logica rigorosa di coerenza temporale. Tutti i riferimenti vengono espressi in UTC, così da evitare ambiguità, riconversioni non controllate o discrepanze tra sistemi diversi.
In particolare, il modello distingue chiaramente tra due momenti distinti:
- il timestamp dichiarato dal sistema sorgente, cioè il momento in cui la decisione viene considerata chiusa o ratificata nel contesto originario;
- il timestamp di intake, cioè il momento in cui l’unità viene ricevuta dal layer esterno e diventa un punto di custodia verificabile.
Questa distinzione è fondamentale. Il secondo non sostituisce il primo. Ma crea il primo punto di presa in carico esterna verificabile, indipendente dal sistema sorgente.
Come viene protetta l’integrità dell’output o della decisione?
L’integrità viene affrontata con un approccio tecnico chiaro. L’obiettivo è fare in modo che l’unità ricevuta possa essere collegata a un’impronta verificabile, così da ridurre il rischio di alterazioni non rilevate dopo l’intake.
Nel caso di oggetti strutturati, il modello prevede la normalizzazione deterministica del payload prima del calcolo hash, così da evitare problemi dovuti, ad esempio, al semplice ordine delle chiavi in un JSON. Due payload semanticamente uguali non devono produrre risultati incoerenti solo per differenze formali.
Quando il sistema sorgente fornisce un proprio hash dichiarato, il framework prevede la distinzione netta tra hash sorgente e hash di intake. I due valori non sono la stessa cosa e non devono essere confusi.
Che cos’è l’hash di intake e come si distingue dall’hash sorgente?
Sono due elementi distinti con funzioni diverse.
L’hash di intake è calcolato dal sistema al momento della ricezione dell’unità decisionale. È il valore autoritativo all’interno del workflow di certificazione: attesta che quella struttura, in quel preciso momento, è entrata nel layer esterno con quella forma. Da quel momento in poi, qualsiasi alterazione è rilevabile.
L’hash sorgente, quando presente, è un valore dichiarato dal sistema che ha generato la decisione. Se fornito, viene confrontato con il risultato del calcolo sul payload ricevuto: se i due valori non coincidono, l’intake non viene considerato valido e la richiesta viene sospesa per integrazione.
La presenza dell’hash sorgente non è obbligatoria, ma rafforza significativamente la catena di integrità, estendendo la garanzia anche al transito pre-intake.
Che cosa significa “chiusura dichiarata”?
Il framework distingue tra due livelli che non devono essere sovrapposti.
La chiusura dichiarata è lo stato comunicato dal sistema sorgente: la decisione è stata ratificata, approvata, finalizzata o chiusa secondo la logica interna di quel sistema. Il layer di intake non verifica che questa condizione sia sostanzialmente vera. La tratta come prerequisito di ammissibilità.
La verifica dell’integrità all’intake è invece responsabilità del layer esterno: garantisce che il payload ricevuto corrisponda a quanto dichiarato e che non sia stato alterato tra la generazione e la presa in carico.
Questi due livelli non si sostituiscono. Servono a cose diverse e devono essere tenuti separati anche nella comunicazione verso terzi.
Il protocollo funziona solo con ChatGPT, Claude o Gemini?
No. Ed è proprio questo uno dei suoi punti di forza.
Il protocollo non nasce come integrazione specifica per un singolo modello AI. Non è legato a un vendor, a una piattaforma o a un marchio preciso. È pensato per funzionare a un livello diverso, cioè a valle del modello, quando una decisione, un output o una chiusura di contesto devono essere presi in carico e resi verificabili.
Questo approccio permette di restare agnostico rispetto al sistema (system-agnostic) e di adattarsi, nel tempo, a scenari diversi – medici, finanziari, HR, legali, logistici – senza dipendere da una sola tecnologia proprietaria o dover riscrivere l’architettura per ogni contesto applicativo.
Serve una integrazione API per usare il framework?
No. La piattaforma è accessibile direttamente via browser senza necessità di integrazione tecnica.
Il workflow operativo – dalla creazione dell’intake alla richiesta FEDIS, dalla pubblicazione nel registro EVIDE alla gestione della catena di evidenze – è completamente gestibile attraverso l’interfaccia web della piattaforma, accessibile ai titolari di certificato DAPI.
In una fase successiva il modello potrà evolvere verso intake strutturati via API per integrazioni machine-to-machine. Ma il punto centrale non cambia: l’obiettivo resta creare un’unità interpretabile, chiusa e verificabile all’esterno.
È compatibile con i framework di governance già adottati?
Sì. Il protocollo non è in concorrenza con i framework di governance esistenti.
La governance definisce chi può decidere, sotto quali regole, con quali vincoli e attraverso quali strutture organizzative. Il Protocollo </AI> opera a un livello diverso: definisce cosa deve essere acquisito e reso verificabile affinché quelle decisioni rimangano difendibili quando vengono messe in discussione.
I due layer sono complementari. Uno costruisce il processo. L’altro lo rende dimostrabile quando il processo viene contestato.
È compatibile con l’AI Act europeo?
Il framework è pensato in coerenza con i principi dell’AI Act europeo, in particolare per quanto riguarda la tracciabilità delle decisioni ad alto impatto, la supervisione umana verificabile e la documentazione difendibile.
L’AI Act sposta progressivamente l’onere della prova verso chi sviluppa e utilizza sistemi AI in contesti regolamentati. Non è più sufficiente dichiarare che esistono controlli: occorre poter dimostrare che quei controlli erano attivi, documentati e ricostruibili. Il Protocollo </AI> è progettato per rispondere esattamente a questo tipo di esigenza.
Il protocollo può essere utile in audit, verifiche o contenziosi?
Sì, proprio perché il suo valore principale non è nella narrazione interna del sistema, ma nella possibilità di creare una base verificabile anche da soggetti esterni.
Questo può essere utile in scenari di audit tecnico, controllo documentale, accountability interna, verifica di processo, confronto con organi di controllo o situazioni in cui una decisione automatizzata o semi-automatizzata debba essere spiegata in modo più solido.
Naturalmente il protocollo non sostituisce da solo la valutazione giuridica o la prova completa del merito, ma può diventare un tassello tecnico molto forte nel momento in cui serve dimostrare lo stato di una decisione e la sua presa in carico esterna.
Che tipo di prova o documentazione produce il sistema?
L’obiettivo non è produrre un semplice log o una schermata da mostrare. L’obiettivo è arrivare a un’unità evidenziaria strutturata, con elementi sufficienti per essere letta, compresa e verificata anche fuori dal sistema originario.
Un’unità di questo tipo include: identità dichiarata del soggetto responsabile tramite certificato DAPI, hash SHA-256 del contenuto calcolato al momento dell’intake, timestamp UTC indipendente, stato decisionale formalizzato, eventuale certificazione FEDIS con codice CWC, e pubblicazione nel registro pubblico EVIDE con identificativo univoco nel formato EVIDE-YYYYMMDD-XXXX.
Il punto non è accumulare più dati possibile. Il punto è fissare l’unità giusta con il minimo set strutturale necessario a renderla interpretabile e difendibile.
Protegge dal rischio di modifica o ricostruzione postuma dei log?
Sì. Questo è uno dei valori più concreti del framework, spesso sottovalutato.
Il rischio principale nei sistemi AI non è solo il “momento zero”. Il rischio più frequente e operativamente rilevante è quello del revisionismo post-evento: la possibilità che, dopo un incidente o una contestazione, i log interni vengano modificati, ricostruiti o riformulati in modo da far apparire una supervisione che non c’era, o da nascondere ciò che era effettivamente accaduto.
Il layer esterno crea un punto di non-ritorno: una volta che l’unità decisionale è stata acquisita con il suo hash e il suo timestamp UTC, il sistema sorgente non può più modificare silenziosamente ciò che è stato dichiarato. Questa garanzia ha un valore diretto in sede di audit e contenzioso.
Cosa succede se l’autorità dichiarata alla chiusura viene contestata?
Se l’autorità dichiarata in un punto di chiusura viene successivamente contestata, il sistema non tenta di risolvere quella disputa internamente.
Ciò che l’oggetto probatorio protegge non è la correttezza dell’autorità, ma l’integrità della dichiarazione.
In altri termini, garantisce che:
- una specifica autorità è stata dichiarata
- in un preciso momento nel tempo
- sotto uno stato decisionale e una struttura definiti
- e che tale dichiarazione non è stata alterata da allora
Questo rimane valido anche se l’autorità stessa viene successivamente messa in discussione.
La struttura regge in modo indipendente, ma solo al livello di attribuzione e integrità, non al livello di legittimità.
Se la disputa riguarda se quell’autorità fosse valida, autorizzata o legittima, la risoluzione avviene necessariamente al di fuori del sistema:
- attraverso le regole di governance
- i registri organizzativi
- i framework legali o contrattuali
Ciò che EVIDE e FEDIS impediscono è una diversa classe di fallimento:
- la riscrittura retroattiva di “chi ha deciso”
- l’ambiguità su quando la decisione è stata presa
- la perdita delle condizioni strutturali in cui è stata dichiarata
In pratica, questo diventa critico nelle controversie. Invece di discutere su narrazioni ricostruite, la discussione si sposta su un punto probatorio fisso: cosa è stato dichiarato, da chi e in quali condizioni, in quel preciso momento.
A quel punto, la domanda non è più cosa è successo, ma se quell’autorità dichiarata fosse valida. E questa è una domanda legale o di governance, non tecnica.
Questa distinzione è fondamentale: il protocollo non risolve le controversie sull’autorità, ma impedisce che tali controversie si espandano fino a coinvolgere l’interpretazione della prova stessa.
Il protocollo copre l’istante originario della decisione, cioè l’istante della decisione reale?
Non completamente, ed è importante dirlo con chiarezza.
Esiste sempre un lasso temporale tra il momento in cui una decisione viene presa nel sistema sorgente e il momento in cui viene acquisita dal layer esterno. Il protocollo non elimina questo intervallo.
Quello che il protocollo fa è creare il primo punto di custodia verificabile e indipendente: da quel momento in poi, l’integrità è garantita. Prima di quel momento, la responsabilità resta nel sistema sorgente e nella sua catena interna di controllo.
Questa limitazione è dichiarata, non nascosta. Ed è gestibile combinando il layer esterno con un hash sorgente fornito dal sistema originario, che estende la garanzia anche al transito pre-intake.
Chi dovrebbe interessarsi a questo framework?
Il framework può interessare chi si occupa di AI governance, compliance, audit, responsabilità digitale, processi decisionali assistiti da AI, human oversight, documentazione tecnica, risk management e sistemi ad alto impatto dove la semplice dichiarazione di controllo umano non è più sufficiente.
Può essere rilevante anche per chi sta costruendo sistemi di supervisione e si rende conto che il vero problema non è soltanto organizzare il processo, ma renderlo dimostrabile quando viene messo in discussione.
È rilevante per studi legali e consulenti?
Sì, in modo diretto.
Chi assiste clienti esposti a rischi di governance AI, contenziosi su decisioni automatizzate o verifiche regolamentari ha bisogno di uno strumento tecnico che traduca la supervisione dichiarata in qualcosa di strutturalmente verificabile. Il protocollo risponde esattamente a questa esigenza: non è un documento di policy, ma un layer operativo che produce unità evidenziarie difendibili.
La piattaforma supporta la gestione multi-organizzazione: uno studio legale può operare con una sola identità DAPI su più clienti, mantenendo separati richieste, catene di evidenze e fatturazione per ciascun mandato.
Per approfondire la collaborazione con studi legali e consulenti è disponibile una sezione dedicata: Partner Kit per studi legali e consulenti.
Che valore ha per un’azienda che già usa AI nei propri processi?
Il valore principale è la difendibilità esterna delle decisioni già prese.
Un’azienda che usa AI nei propri processi può avere governance interna solida, processi documentati e audit trail interni. Ma quando qualcuno contesta una decisione dall’esterno, il valore di quella documentazione dipende dal fatto che il soggetto contestante abbia motivo di fidarsi del sistema che l’ha prodotta.
Il layer esterno risolve questo problema strutturalmente: la decisione non viene più difesa solo con i propri log interni, ma con un punto di ancoraggio indipendente che il sistema sorgente non può controllare o modificare retroattivamente.
Catena di evidenze e gestione multi-organizzazione
Che cos’è la catena di evidenze verificabili?
La catena di evidenze è una funzionalità operativa della piattaforma EVIDE che permette di collegare più intake in sequenza, documentando in modo verificabile l’evoluzione di un contenuto, una decisione o una versione nel tempo.
Ogni intake resta indipendente e immutabile: ha il proprio hash SHA-256 e il proprio timestamp UTC. Il collegamento al precedente è opzionale e non modifica l’integrità del singolo elemento. La catena si costruisce dichiaratamente, non retroattivamente.
La struttura tipica è:
- Intake #1 – documento originale, prima versione, decisione iniziale
- Intake #2 – revisione, aggiornamento, integrazione
- Intake #3 – versione definitiva, con eventuale richiesta FEDIS e pubblicazione EVIDE
In sede legale o di audit, non basta dimostrare la decisione finale. Spesso è necessario ricostruire il percorso: quali modifiche sono state apportate, quando, e in quale ordine. La catena di evidenze EVIDE risponde esattamente a questa esigenza.
Non stai archiviando un file. Stai documentando la responsabilità professionale nel tempo.
Il collegamento tra intake altera l’integrità del singolo elemento?
No. Questo è un punto architetturale fondamentale.
Ogni intake ha il proprio hash calcolato indipendentemente al momento della ricezione. Il collegamento alla catena è un riferimento logico che non modifica né il contenuto né l’impronta del singolo intake.
In pratica: se l’intake #2 dichiara di essere collegato all’intake #1, questa informazione è registrata nel sistema ma non altera l’hash di nessuno dei due elementi. Ciascuno rimane autonomamente verificabile.
Questo principio è essenziale per garantire che la catena non diventi un punto di vulnerabilità: un anello contestato non invalida gli altri.
In quali scenari è utile la catena di evidenze?
La catena di evidenze è utile in tutti i casi in cui è necessario documentare un’evoluzione nel tempo in modo verificabile:
- Contratti in negoziazione: ogni versione è certificata, la sequenza è ricostruibile e inattaccabile
- Policy aziendali e procedure: le revisioni successive sono collegate alla versione originale, con data certa
- Output di sistemi AI: ogni aggiornamento del modello, della risposta o della decisione è tracciato in sequenza
- Decisioni mediche o legali: l’iter decisionale è documentato step by step con identità e timestamp
- Compliance normativa: le versioni di policy e procedure sono verificabili nel tempo senza dipendere dai log interni
- Contenziosi su versioni di documenti: la sequenza cronologica è dimostrabile in modo indipendente
Un professionista può gestire più organizzazioni con un solo accesso?
Sì. Questa è una delle caratteristiche operative della piattaforma, pensata specificamente per avvocati, DPO, consulenti e studi professionali che gestiscono più clienti o mandati contemporaneamente.
Il modello è basato su due livelli distinti:
- DAPI – identifica la persona fisica in modo univoco e verificato. È personale e non trasferibile.
- Organizzazione – definisce il perimetro operativo. Lo stesso professionista può essere associato a più organizzazioni con ruoli differenti.
Esempi concreti:
- Avvocato – gestisce lo studio legale, tre aziende clienti e un ente pubblico con un unico accesso DAPI, mantenendo separati richieste, catene e fatturazione per ciascun mandato
- DPO esterno – opera su venti aziende in qualità di responsabile della protezione dei dati, con log e certificazioni separati per organizzazione
- Consulente di governance AI – certifica output e decisioni per clienti diversi, con perimetri operativi stagni
- Studio professionale – i collaboratori operano sotto la stessa struttura ma su perimetri clienti distinti, con ruoli e accessi differenziati
Ogni richiesta nasce dentro un perimetro organizzativo specifico. Richieste, catene e certificazioni restano sempre separate per organizzazione.
Come funziona la fatturazione in un contesto multi-organizzazione?
La fatturazione è associata all’organizzazione, non al singolo utente. Questo riflette la realtà operativa: il professionista opera per conto di un cliente, e il costo della certificazione deve essere imputato al perimetro corretto.
Ogni organizzazione ha una propria scheda di fatturazione, inserita e confermata da un utente con ruolo owner o admin. Gli utenti con ruolo member possono creare richieste a nome dell’organizzazione ma non gestiscono i dati di fatturazione.
Prima di poter inviare una nuova richiesta di certificazione, il sistema verifica che esista una scheda di fatturazione valida e confermata per il perimetro organizzativo selezionato. Questo blocco è intenzionale: garantisce che ogni richiesta sia associata a un perimetro economico chiaro e verificabile fin dall’inizio.
Quali ruoli esistono all’interno di un’organizzazione?
La piattaforma prevede tre ruoli distinti all’interno di ogni organizzazione:
- Owner – titolare dell’organizzazione. Gestisce i dati di fatturazione, può aggiungere o rimuovere utenti e ha pieno controllo operativo. Tipicamente il responsabile legale o il fondatore dello studio.
- Admin – amministratore delegato. Ha gli stessi poteri operativi dell’owner sulla gestione delle certificazioni e della fatturazione, ma non è il titolare formale. Tipicamente un collaboratore fidato con pieni poteri operativi.
- Member – membro ordinario. Può creare richieste di certificazione a nome dell’organizzazione e consultare le proprie richieste, ma non gestisce billing né configurazioni organizzative.
Lo stesso utente DAPI può avere ruoli diversi in organizzazioni diverse: owner nel proprio studio e member in un’organizzazione cliente, ad esempio.
Contesto e rischi emergenti
Gli agenti AI rappresentano davvero un rischio per le organizzazioni?
Negli ultimi mesi il dibattito sugli agenti AI si è intensificato, soprattutto in relazione al livello di accesso operativo che questi sistemi richiedono per funzionare in modo efficace.
In molti scenari applicativi, gli agenti possono interagire con sistemi aziendali, email, documenti, calendari o altri ambienti sensibili. Questo comporta un aumento del livello di autonomia operativa e, di conseguenza, una maggiore esposizione a rischi legati a errori, uso improprio o perdita di controllo.
Tuttavia, il punto centrale non è soltanto quanto accesso abbia un agente AI.
Il problema reale emerge nel momento in cui una decisione viene presa. In quel punto, nella maggior parte dei sistemi, non esiste una prova indipendente e verificabile che permetta di ricostruire in modo affidabile:
- quale decisione sia stata effettivamente prodotta;
- in quale stato fosse al momento della chiusura;
- chi abbia assunto la responsabilità della sua validazione;
- quale fosse il contesto decisionale associato.
Il dibattito attuale si concentra principalmente sul controllo degli accessi e sull’autonomia degli agenti. Il Protocollo </AI> affronta invece un livello diverso e complementare: la dimostrabilità della decisione una volta che questa è stata considerata chiusa.
In altre parole, non interviene su ciò che l’agente può o non può fare, ma su ciò che deve essere dimostrabile dopo che l’azione è stata compiuta.
Questo passaggio è fondamentale in contesti di audit, responsabilità e contenzioso, dove non è sufficiente sapere che un sistema era sotto controllo, ma è necessario poter dimostrare cosa è accaduto in modo verificabile anche al di fuori del sistema che ha generato la decisione.
È meglio limitare gli agenti AI o rendere le loro decisioni verificabili?
Negli ultimi mesi stanno emergendo diverse iniziative orientate a limitare l’accesso e il comportamento degli agenti AI, ad esempio definendo quali contenuti possano essere letti, quali azioni possano essere eseguite o quali contesti debbano restare riservati agli esseri umani.
Questo approccio è importante e risponde a un’esigenza reale: ridurre il rischio prima che un sistema agisca.
Tuttavia, esiste un secondo problema, altrettanto critico, che non viene risolto da queste misure.
Nel momento in cui una decisione viene presa, la domanda diventa:
- che cosa è stato deciso esattamente;
- in quale stato era la decisione al momento della chiusura;
- chi ne ha assunto la responsabilità;
- se esiste una prova indipendente e verificabile di questo evento.
Limitare ciò che un agente può fare riduce il rischio ex ante. Ma non elimina la necessità di dimostrare ex post ciò che è accaduto.
Il Protocollo </AI> si colloca in questo secondo livello. Non interviene sul controllo dell’accesso o sul comportamento degli agenti, ma sulla trasformazione della decisione in un evento verificabile, dotato di identità, contesto, integrità e riferimenti temporali.
I due approcci non sono in alternativa. Sono complementari. Il primo riduce la probabilità di errore o abuso. Il secondo consente di dimostrare in modo difendibile ciò che è accaduto quando una decisione è già stata presa. In contesti regolamentati o ad alto impatto, entrambi diventano necessari.
Cosa succede se un sistema AI si comporta in modo imprevedibile o non allineato?
Negli ultimi mesi sono emerse evidenze secondo cui alcuni sistemi AI, in contesti reali, possono produrre comportamenti inattesi, non allineati o difficili da interpretare. Questo include casi in cui l’output non rispecchia le istruzioni ricevute o in cui il sistema adotta strategie non previste dal modello di governance.
Questi scenari pongono un problema concreto: non è più sufficiente assumere che il sistema operi sempre in modo prevedibile o completamente controllabile.
In questo contesto, la domanda centrale cambia. Non è più soltanto “come evitare che il sistema si comporti in modo errato?”, ma diventa:
- che cosa è stato effettivamente deciso;
- in quale stato si trovava la decisione al momento della chiusura;
- chi ha assunto la responsabilità della sua validazione;
- se esiste una prova indipendente e verificabile di tutto questo.
Il Protocollo </AI> non interviene per rendere il sistema AI infallibile o per impedirne comportamenti non previsti. Il suo ruolo è diverso e complementare: creare un punto esterno di presa in carico che renda la decisione dimostrabile, indipendentemente dal comportamento interno del sistema che l’ha generata.
Chi è responsabile se un sistema AI genera errori o codice dannoso?
L’utilizzo di sistemi di intelligenza artificiale non trasferisce automaticamente la responsabilità allo strumento.
In ambito professionale, la responsabilità resta in capo al soggetto umano che utilizza, valida o approva l’output generato. Questo vale anche nei casi in cui l’AI produca risultati inattesi, errati o potenzialmente dannosi.
Il problema, tuttavia, non è soltanto individuare chi è responsabile, ma dimostrarlo in modo verificabile.
In molti contesti operativi, infatti, manca una traccia chiara che consenta di ricostruire:
- chi ha validato l’output;
- in quale momento è stata presa la decisione;
- in quale stato si trovava il sistema al momento della validazione;
- se esiste una prova indipendente dell’integrità del contenuto.
Il Protocollo </AI> interviene su questo punto. Attraverso un processo di intake verificabile, ogni decisione viene ancorata a: un’identità umana dichiarata tramite certificato DAPI, un timestamp UTC indipendente, un riferimento immutabile (hash SHA-256) del contenuto, e uno stato decisionale formalizzato.
In questo modo, anche in presenza di errori o comportamenti imprevisti del sistema AI, è possibile dimostrare in modo chiaro e difendibile chi ha assunto la responsabilità della decisione finale.
Il sistema impedisce dichiarazioni false o abusi?
No.
Il sistema non nasce per impedire dichiarazioni false, ma per renderle tracciabili, verificabili e imputabili nel tempo.
Chi utilizza il sistema può dichiarare un contenuto, un output o una decisione. Tuttavia, ogni dichiarazione viene ancorata a elementi oggettivi:
- identità dichiarata tramite certificato DAPI;
- timestamp UTC indipendente;
- impronta crittografica (hash SHA-256) del contenuto;
- stato decisionale formalizzato;
- eventuale certificazione FEDIS con codice CWC.
Questo significa che una dichiarazione non può essere modificata o negata successivamente senza lasciare evidenza. Se un soggetto dichiara il falso, e altre evidenze dimostrano il contrario, quella dichiarazione diventa un elemento controproducente per chi l’ha emessa.
In altre parole, il sistema non impedisce comportamenti scorretti, ma li rende rischiosi e verificabili. Una dichiarazione non verificabile può essere ignorata. Una dichiarazione registrata, identificata e temporalmente ancorata può essere analizzata, confrontata e, se necessario, contestata.
A che punto è il progetto?
Il framework concettuale e tecnico è definito e pubblicamente documentato. La piattaforma applicativa è operativa e accessibile ai titolari di certificato DAPI.
Il workflow attivo include:
- Intake probatorio con hash SHA-256 e timestamp UTC per FILE, ZIP, URL e TEXT
- Richiesta e gestione FEDIS con workflow di approvazione e preventivo
- Pubblicazione nel registro pubblico EVIDE con identificativo univoco
- Catena di evidenze verificabili tra intake collegati
- Gestione multi-organizzazione con perimetri operativi separati
- Fatturazione per organizzazione con ruoli owner, admin e member
- Registro pubblico consultabile senza autenticazione
Dove trovare maggiori informazioni?
Per un inquadramento generale del progetto e della logica di AI supervisionata è possibile consultare la pagina dedicata al framework:
→ Il Protocollo </AI>
→ Il livello probatorio nella governance AI
→ Casi reali di governance AI
→ Partner Kit per studi legali e consulenti
→ EVIDE – Registro probatorio per contenuti e decisioni digitali