Il lavoro silenzioso dell’AI Act UE: registri, non slogan

Il lavoro silenzioso dell’AI Act UE: registri, non slogan

Il registro che arriva dopo la decisione

C'è un momento dopo che una raccomandazione automatizzata è stata accettata in cui la stanza cambia forma. Lo schermo mostra ancora il risultato. La conversazione è passata a ciò che accadrà dopo. Qualcuno chiede quale versione del sistema l'ha prodotto, quali informazioni erano disponibili al momento, se l'operatore avrebbe potuto rifiutarlo e quale regola ha reso ammissibile il percorso. Queste domande non sono un attacco drammatico alla tecnologia. Sono le domande ordinarie che le istituzioni pongono quando un'azione acquisisce una conseguenza.

Immaginate un caso composito, deliberatamente senza un'organizzazione, un sistema o un incidente nominato. Un ente pubblico utilizza un sistema di IA ad alto rischio per assistere una decisione che riguarda una persona. Un membro del personale formato rimane responsabile della decisione. Il modello fornisce un output, il membro del personale lo verifica e la decisione viene presa. Più tardi, un supervisore deve comprendere il percorso. L'output stesso è presente. La decisione è presente. La catena tra loro non lo è. Non esiste un registro chiaro delle istruzioni in vigore, dell'input utilizzato, della versione implementata, dell'intervento disponibile o del motivo per cui l'essere umano ha accettato il risultato. Nulla in questa descrizione richiede un malfunzionamento spettacolare. Un registro mancante è sufficiente per trasformare una revisione in un esercizio di ricostruzione.

L'Artificial Intelligence Act dell'Unione Europea è spesso discusso come un catalogo di divieti, categorie e sanzioni. Queste parti contano, ma non sono l'intera opera. L'Atto descrive anche un'infrastruttura più silenziosa di prove: gestione del rischio documentata e mantenuta, pratiche relative ai dati che hanno un'origine e uno scopo, documentazione tecnica che può essere valutata, registri che documentano eventi rilevanti, istruzioni che dicono a un deployer come interpretare un sistema, supervisione umana che ha autorità reale e registri che rimangono disponibili quando arriva una domanda più tardi. La legge chiede a un'istituzione di ricordare intenzionalmente.

Questo è un compito meno cinematografico che lanciare un modello. È anche il punto in cui la responsabilità diventa reale. Uno slogan può affermare che un'organizzazione si assume la responsabilità. Un registro può mostrare come appariva la responsabilità in un momento particolare. Può mostrare un confine, un'incertezza, un'approvazione, un rifiuto, una correzione o un'assenza. Non può rendere legale una decisione illegale esistendo dopo il fatto, e non può riparare da solo la perdita di una persona. Può rendere il percorso abbastanza ispezionabile per un rimedio, una correzione e una decisione migliore sulla versione successiva.

Questo articolo riguarda quel lavoro silenzioso. Legge gli obblighi di conservazione dei registri e documentazione nell'AI Act come requisiti operativi piuttosto che come scartoffie allegate a un lancio. Chiede cosa possono stabilire i registri, cosa non possono stabilire, come un registro acquisisce significato dal contesto, perché la completezza non è la stessa cosa del volume e come un'organizzazione può costruire una routine che lasci prove senza trasformare ogni interazione umana in un oggetto di sorveglianza permanente. Gli esempi che non sono presi direttamente da una fonte citata sono etichettati come proposti, ipotetici o compositi. Non c'è un incidente inventato che aspetta alla fine della storia. Il punto è evitare di averne bisogno.

Perché il lavoro silenzioso conta

Le registrazioni sono facili da fraintendere perché sono presenti in quasi ogni organizzazione. Una riga di database, un ticket, una richiesta di modifica, una decisione firmata, un timestamp e una riga di log sembrano tutti registrazioni. La loro sola presenza dice molto poco. Una registrazione diventa utile quando risponde a una domanda definita con abbastanza contesto da distinguere ciò che è accaduto da ciò che qualcuno ora crede sia accaduto. Questa distinzione è particolarmente importante per l'IA perché l'output visibile spesso nasconde il numero di trasformazioni che lo hanno preceduto.

Un sistema software convenzionale può lasciare una traccia familiare ai suoi operatori. Una richiesta entra, un servizio valida i campi, una regola viene eseguita, uno stato cambia e una risposta esce. I sistemi di IA possono aggiungere categorie inferite, contesto recuperato, istruzioni in linguaggio naturale, output probabilistici, chiamate a strumenti, modifiche umane e stato adattivo. La flessibilità aggiuntiva può essere utile. Crea anche più opportunità perché un fatto perda la sua origine o perché un'istruzione diventi autorevole senza essere riconosciuta come tale. La registrazione deve mantenere le distinzioni che l'interfaccia è tentata di appiattire.

L'AI Act non richiede a un'organizzazione di conservare ogni byte che sia mai passato attraverso un modello. I suoi requisiti sono legati a scopo, rischio, tracciabilità, ciclo di vita e controllo. Questo è un punto di partenza utile. Dice che le prove dovrebbero essere proporzionate allo scopo previsto e ai rischi, pur essendo abbastanza rigorose per l'obbligo pertinente. Una registrazione di un suggerimento di bozza a basso impatto non dovrebbe essere trattata come se fosse un fascicolo completo per una decisione che incide sui diritti fondamentali. Al contrario, una decisione importante non può essere resa responsabile conservando una singola frase finale e un segno di spunta verde.

Il lavoro silenzioso quindi inizia prima che un sistema venga messo in servizio. Qualcuno deve dichiarare cosa il sistema è destinato a fare, dove non è destinato a operare, quali persone e ambienti rientrano nell'ambito, quale input può ricevere, chi può agire sull'output e cosa succede quando il sistema è incerto o non disponibile. Queste non sono solo questioni di progettazione. Sono le condizioni che danno significato alle registrazioni successive. Senza di esse, un timestamp ci dice quando è successo qualcosa ma non se era consentito, previsto o un'eccezione.

Esiste una ragione istituzionale per prendere tutto questo sul serio. Chi chiede le prove spesso non è chi ha costruito il sistema. Un'autorità competente, un revisore interno, una persona interessata o un team subentrante possono imbattersi nella documentazione dopo che personale, fornitori e modelli sono cambiati. Prove che hanno senso solo per il loro autore originale sono una forma fragile di responsabilità. L'insistenza del Regolamento su una documentazione chiara, istruzioni comprensibili e accesso per le autorità è una risposta a questa fragilità. Tratta la continuità come parte della conformità.

Leggere il Regolamento come una sequenza, non come uno slogan

I requisiti per i sistemi ad alto rischio del Regolamento possono essere letti come una sequenza di domande. Cosa deve fare il sistema. Quali rischi può creare in quel contesto. Quali dati e presupposti lo sostengono. Come è stato costruito e testato il sistema. Cosa deve sapere chi lo implementa. Quali eventi devono essere registrati. Chi può supervisionare, annullare o fermare il sistema. Cosa succede quando il sistema non è conforme o presenta un rischio. La sequenza non è un flusso software ordinato. È una catena di responsabilità che si ripiega su se stessa quando le prove cambiano.

L'articolo 9 descrive la gestione del rischio come un processo continuo e iterativo, pianificato e condotto lungo l'intero ciclo di vita di un sistema di IA ad alto rischio. Deve essere istituito, attuato, documentato e mantenuto. Questa formulazione ha una conseguenza pratica. Una valutazione del rischio non è un documento cerimoniale che va in pensione il giorno del lancio. È la registrazione di un processo vivo che identifica e valuta i rischi noti e ragionevolmente prevedibili, considera le informazioni provenienti dal monitoraggio post-commercializzazione e adotta misure mirate. La registrazione dovrebbe consentire a un lettore successivo di vedere cosa è stato considerato, cosa non è stato possibile eliminare, cosa è rimasto come rischio residuo e chi ha accettato quella posizione.

L'articolo 10 colloca i dati e la governance dei dati all'interno della stessa disciplina. Le pratiche pertinenti includono le scelte di progettazione, l'origine dei dati, le operazioni di preparazione, le ipotesi su ciò che i dati rappresentano, la disponibilità e l'idoneità, i possibili pregiudizi, le lacune nei dati e le misure adottate per affrontarle. Questa è un'idea diversa dal dire che un set di dati era pulito. Pulito è una conclusione. Origine, preparazione, ipotesi e lacune sono prove su come è stata raggiunta la conclusione e su dove potrebbe smettere di essere affidabile. Una registrazione che conserva solo un'etichetta di qualità ha dimenticato le domande che rendevano significativa la qualità.

L'articolo 11 richiede una documentazione tecnica per un sistema di IA ad alto rischio prima che venga immesso sul mercato o messo in servizio e richiede che tale documentazione sia mantenuta aggiornata. Ha lo scopo di fornire alle autorità nazionali competenti e agli organismi notificati le informazioni necessarie per valutare la conformità. Il punto importante non è che ogni lettore debba diventare uno specialista di un allegato. È che il sistema deve avere una descrizione di sé sufficientemente chiara ed esauriente per una valutazione esterna. Tale descrizione necessita di una versione, di uno scopo e di un rapporto con le versioni precedenti. Un documento che descrive un sistema che non esiste più è un archivio, non una prova attuale.

L'articolo 12 rende poi il funzionamento stesso del sistema parte delle prove. I sistemi di IA ad alto rischio devono consentire tecnicamente la registrazione automatica degli eventi per tutto il loro ciclo di vita. Le capacità di registrazione devono documentare gli eventi pertinenti per identificare situazioni che possono creare un rischio o una modifica sostanziale, facilitando il monitoraggio post-commercializzazione e il monitoraggio del funzionamento nell'ambito degli obblighi di chi implementa il sistema. Il livello di tracciabilità richiesto è legato alla finalità prevista. La legge non chiede che il registro sia un diario della vita umana. Chiede al sistema di lasciare abbastanza memoria operativa per le domande pertinenti.

Gli articoli 13 e 14 collegano quella memoria alle persone. Un sistema ad alto rischio deve essere sufficientemente trasparente perché i deployer possano interpretarne l'output e utilizzarlo in modo appropriato, e deve essere accompagnato da istruzioni per l'uso. La supervisione umana deve essere efficace e proporzionata al rischio, all'autonomia e al contesto. Le persone incaricate della supervisione devono essere in grado di comprendere capacità e limiti, notare anomalie e prestazioni inattese, evitare un'eccessiva fiducia, interpretare gli output, ignorarli o sovrascriverli e, se opportuno, interrompere il sistema in sicurezza. Queste capacità non possono vivere solo in una slide di formazione. Una registrazione seria dovrebbe rendere possibile capire cosa l'essere umano poteva sapere e fare al momento della decisione.

Gli articoli da 15 a 21 completano l'arco che va dalla prestazione al rimedio. Accuratezza, robustezza e cybersicurezza sono proprietà dell'intero ciclo di vita. I fornitori devono mantenere un sistema di gestione della qualità documentato in modo ordinato, che includa procedure relative ai dati, gestione del rischio, monitoraggio post-commercializzazione, segnalazione degli incidenti, comunicazioni, tenuta dei registri e un quadro di responsabilità. La documentazione e i log devono rimanere disponibili per i periodi e per gli scopi specificati dal Regolamento. Le azioni correttive e la cooperazione con le autorità competenti sono obblighi, non pubbliche relazioni facoltative. Il risultato non è uno slogan sull'IA affidabile. È un insieme di artefatti che consentono a un'istituzione di dimostrare, indagare, correggere e spiegare.

Tre cose che una registrazione può fare

In primo luogo, una registrazione può stabilire un evento. Può mostrare che un sistema è stato richiamato, che una versione specifica era attiva, che un input è stato ricevuto, che una chiamata a uno strumento è stata proposta, che un'approvazione umana è stata registrata, che un'azione è stata completata o che un sistema è stato arrestato. L'evidenza degli eventi è il livello che la maggior parte delle persone immagina quando sente la parola log. Conta perché un'azione contestata non può essere indagata se l'organizzazione non riesce a stabilire se l'azione sia avvenuta. È anche il livello meno completo se rimane da solo.

Una registrazione di un evento richiede un'identità stabile, un riferimento temporale, un attore o un ruolo responsabile, un'identità del sistema o del componente e uno stato sufficiente a evitare ambiguità. I campi esatti dipendono dallo scopo e dalla legge. Un timestamp senza una base temporale può creare confusione tra sistemi diversi. Un identificativo utente senza un ruolo dice poco sull'autorità. Un nome di modello senza versione non può stabilire quale comportamento fosse in questione. Una registrazione può essere tecnicamente autentica e rimanere istituzionalmente povera.

In secondo luogo, una registrazione può stabilire una base. Può mostrare quale scopo, regola, istruzione, fonte di dati, versione di policy o valutazione ha supportato un'azione. L'evidenza della base è ciò che impedisce a una decisione di diventare un output fluttuante. Non deve riprodurre ogni calcolo interno. Deve identificare le condizioni che hanno reso significativo l'output e i confini che limitavano ciò che una persona era autorizzata a farne. Quando la base manca, un'organizzazione può sapere cosa ha fatto senza sapere perché aveva il diritto di farlo.

In terzo luogo, una registrazione può stabilire una risposta. Può mostrare che un'anomalia è stata notata, che un operatore ha rifiutato un output, che un rischio è stato segnalato, che un sistema è stato sospeso, che una correzione è stata applicata o che un reclamo è stato ricevuto e instradato. L'evidenza della risposta è spesso trascurata perché i team si concentrano sul primo output del modello. In pratica, la responsabilità vive in ciò che accade dopo che l'incertezza diventa visibile. Un sistema che può produrre una registrazione di un problema ma non ha alcuna registrazione della risposta ha costruito un sensore senza freno.

Queste tre funzioni si sovrappongono, ma non dovrebbero essere unificate. Una citazione di una fonte può stabilire una base senza dimostrare che la fonte sia stata effettivamente utilizzata nell'esecuzione. Un'approvazione umana può stabilire una risposta senza dimostrare che il revisore abbia visto un contesto completo. Una versione del modello può stabilire un'identità senza dimostrare che la versione si sia comportata in modo coerente. I buoni registri rendono esplicite le affermazioni che possono supportare. Non prendono in prestito autorità dai registri vicini e non chiamano questo accordo una catena.

Cosa un registro non può fare

Un registro non può trasformare una pratica vietata in una consentita. Se l'uso stesso è al di fuori della legge, una registrazione perfetta non è una difesa. Le prove possono mettere in luce una decisione sbagliata, ma non possono concedere retroattivamente un'autorità che non è mai esistita. Per questo la documentazione non dovrebbe mai essere presentata come sostituto dell'analisi giuridica, della valutazione dei diritti fondamentali o di uno scopo chiaro. Una violazione perfettamente indicizzata è comunque una violazione. L'indice ne rende soltanto più facile il ritrovamento.

Un registro non può dimostrare che una decisione sia stata equa solo perché i campi sono compilati. L'equità non è una proprietà che appare quando un modulo raggiunge il cento per cento. La domanda pertinente è se il sistema, i dati, il flusso di lavoro e il giudizio umano abbiano trattato le persone in un modo che rispetti i diritti e gli obblighi applicabili. Un registro può conservare prove su quella domanda. Può mostrare quali informazioni sono state utilizzate, quale regola è stata applicata, quali eccezioni sono state considerate e come è stato gestito un ricorso. Non può decidere da solo la questione morale e giuridica.

Un registro non può rendere significativa una spiegazione debole aggiungendo dettagli tecnici. Una persona interessata da una decisione può avere bisogno di un resoconto chiaro del ruolo svolto dall'IA e degli elementi principali della decisione. Scaricare su quella persona identificatori interni, tracce grezze di token o una schermata di telemetria della macchina non è automaticamente trasparenza. La forma delle prove deve corrispondere alla domanda e al pubblico. L'autorità ha bisogno di documentazione valutabile. Gli operatori hanno bisogno di istruzioni utilizzabili. Le persone interessate hanno bisogno di un percorso comprensibile per capire e contestare.

Un record non può preservare il futuro. È una prospettiva da un momento specifico, costruita con le informazioni e lo stato del sistema che esistevano allora. Quel limite non è un difetto. È un motivo per registrare versioni, periodi di validità e incertezza. Se una policy cambia dopo una decisione, il record non dovrebbe mostrare silenziosamente la nuova policy come se avesse governato l'azione precedente. Se una fonte viene corretta, l'input precedente dovrebbe rimanere identificabile mentre la correzione e i suoi effetti vengono registrati. Il tempo fa parte del significato, non è un ornamento sul lato destro di una dashboard.

Un record non può dire a un'organizzazione ciò che non ha registrato. Sembra ovvio, ma è un confine importante in un'epoca di spiegazioni generate. Si può chiedere a un modello di raccontare una decisione passata. La prosa risultante può essere utile come ipotesi o come riassunto. A meno che non sia fondata su prove conservate, non è una macchina del tempo. La pratica più sicura è etichettare la ricostruzione come ricostruzione, identificare le prove mancanti ed evitare di presentare un resoconto plausibile come uno osservato. Un'incompletezza onesta è più utile di una finzione completa.

I log sono prove, non un alibi morale

La registrazione dei log è attraente perché sembra oggettiva. Una riga con un timestamp e un identificatore di sistema sembra più neutrale di una nota umana. Non lo è. Qualcuno ha deciso cosa registrare, cosa omettere, quali campi conservare, come proteggerli, come sincronizzare il tempo e chi può ispezionare il risultato. La registrazione dei log è una scelta ingegneristica con conseguenze legali e umane. Le disposizioni sull'obbligo di registrazione dell'AI Act rendono visibile quella scelta, ma non eliminano la necessità di progettarla con cura.

La prima domanda di progettazione è lo scopo. L'articolo 12 indica la tracciabilità, l'identificazione dei rischi, il monitoraggio post-commercializzazione e il monitoraggio operativo come motivi per registrare gli eventi rilevanti. Ogni motivo può richiedere una prospettiva diversa. Un operatore può aver bisogno di una spiegazione sintetica di un rifiuto e di un percorso verso un supervisore. Uno specialista della sicurezza può aver bisogno della versione e della discendenza degli input. Un'autorità competente può aver bisogno di documentazione e log sufficienti per valutare la conformità. Un responsabile della protezione dei dati può aver bisogno di sapere quali dati personali contiene il log e perché vengono conservati. Un unico flusso indifferenziato può essere allo stesso tempo troppo rumoroso per una persona e troppo debole per un'indagine.

La seconda domanda è l'ambito. Un log utile registra gli eventi che contano per lo scopo e il rischio previsti, non ogni gesto incidentale. Per un sistema che redige solo testo interno, l'evento rilevante può essere l'invocazione, il set di fonti, la versione del modello, la versione delle istruzioni, il rilascio umano e la destinazione finale. Per un sistema che può modificare un record esterno, le transizioni di stato e le conferme degli strumenti diventano essenziali. Per un sistema che supporta una decisione ad alto impatto, l'ambito degli input, l'output, la revisione umana e il percorso di correzione contano più di un contatore decorativo di token. Il record dovrebbe seguire le conseguenze.

La terza domanda è l'integrità. Un record che può essere modificato senza essere rilevato può essere ancora utile per le operazioni, ma rende più debole un'affermazione sulla storia. I controlli di integrità possono includere restrizioni di accesso, archiviazione append-only, checksum, firme, riferimenti temporali indipendenti, correzioni controllate e conservazione documentata. Il meccanismo appropriato dipende dal rischio. La cosa importante è dichiarare cosa protegge il meccanismo e cosa non protegge. La prova di manomissione può mostrare che un record è cambiato. Non può mostrare che il record originale fosse completo o che l'evento catturato fosse legittimo.

The fourth question is privacy. Logs can contain prompts, identifiers, source excerpts, model outputs, tool arguments and human notes. Keeping all of them forever may create a second problem in the name of solving the first. The Regulation itself connects the logging duties to other Union and national law, including data protection. A sensible design separates operational evidence from unnecessary content, limits access, defines retention and supports correction or deletion where required. Minimisation is not an enemy of accountability. It is what keeps accountability from becoming a licence to collect a private biography of every user.

The fifth question is replay. Replay does not always mean rerunning a probabilistic model and expecting the same sentence. It can mean reconstructing the relevant state: the model and policy versions, source references, input classification, instruction set, output, human intervention, tool result and subsequent action. A replay may reveal that exact reproduction is impossible because a remote dependency changed. That result is still evidence if the system says what was preserved, what was not and why. The honest replay boundary is more valuable than a theatrical button labelled reproduce.

Finally, logs need an owner. A field without an owner becomes an orphaned promise. Someone must decide which events are relevant, verify that recording works, monitor failures in the logging path, protect access, test retrieval and retire records according to the stated purpose. The owner may be a team rather than a person, but accountability cannot be delegated to a storage bucket. The bucket does not attend the review meeting. It also has a disappointing grasp of proportionality.

Documentation is a living description

Technical documentation is sometimes treated as the place where an engineering team explains a product to itself. Under the AI Act it has a wider audience. It needs to provide information that a national competent authority or notified body can use to assess compliance. That changes the tone of the document. It should not be an advertisement for the system, and it should not be a private notebook full of references that no one else can follow. It is a controlled description of purpose, design, operation, limits, data, testing and changes.

A living description has a relationship to the system’s identity. It names the provider, intended purpose and relevant versions. It explains how the system interacts with other software and hardware. It describes the components and processes that affect the requirements. It records the tests and validation that support performance claims. It identifies foreseeable conditions that can change behaviour. It states the interfaces and oversight measures a deployer needs. This does not mean the document must expose trade secrets indiscriminately. It means confidentiality cannot become an excuse for having no assessable account.

Versioning is the hinge. A document that changes without a history can hide a change by making the new state look like the old one. A history that records every punctuation edit can bury a substantial change among harmless noise. A useful change record identifies what changed, why it changed, who authorised it, which assessment was repeated, what downstream material must be updated and when the new state became effective. The AI Act refers to substantial modification in several places. An organisation needs a way to notice change before the label becomes a dispute.

La provenienza vale anche per le assunzioni. Un sistema può basarsi su un'assunzione riguardo alla popolazione rappresentata in un dataset, alla freschezza di una fonte, al significato di un campo o alla competenza di chi lo implementa. Le assunzioni non sono imperfezioni imbarazzanti da nascondere in una nota a piè di pagina. Sono i confini della pretesa del sistema. Una registrazione che le nomina dà all'operatore la possibilità di riconoscere quando il confine è stato raggiunto. Una registrazione che le nasconde invita il sistema a essere usato al di fuori delle condizioni in cui le sue evidenze avevano senso.

La documentazione dovrebbe rendere l'incertezza leggibile senza fingere che ogni incognita possa essere quantificata. Alcune incertezze sono numeriche. Altre riguardano coperture mancanti, conflitti irrisolti, leggi in evoluzione, input nuovi o un'interazione non testata con un altro componente. Una buona descrizione può dire che una condizione non è stata valutata, che un esito dipende dal giudizio umano o che il sistema non dovrebbe essere usato per uno scopo specifico. Queste affermazioni non sono segni di un sistema debole. Sono le informazioni che permettono a un sistema solido di restare entro i limiti della sua garanzia.

C'è una differenza tra una limitazione e un rifiuto. Una limitazione dice dove la pretesa di un sistema diventa inaffidabile. Un rifiuto dice che il sistema non procederà in una determinata condizione. Entrambi dovrebbero essere documentati. Se l'utente vede solo un errore generico, l'organizzazione perde l'occasione di spiegare se la restrizione protegge la sicurezza, la privacy, i diritti, la qualità o la capacità. Anche registrazioni chiare dei rifiuti supportano il miglioramento. Rifiuti ripetuti possono indicare che un flusso di lavoro sta chiedendo al sistema di fare un lavoro per cui non è mai stato progettato.

La supervisione umana richiede evidenze attorno a sé

Le disposizioni sulla supervisione umana dell'AI Act sono facili da riassumere e difficili da implementare. Assegnare una persona non equivale ad abilitare la supervisione. La persona ha bisogno di competenza, formazione, autorità e supporto. Deve comprendere capacità e limitazioni, rilevare anomalie, evitare il bias di automazione, interpretare l'output e decidere se non usare, sovrascrivere, invertire o fermare il sistema. Questi sono poteri operativi. Una persona nominata tecnicamente come revisore ma che non può vedere l'input, modificare l'esito o mettere in pausa il flusso di lavoro è un testimone, non un supervisore.

Le registrazioni possono mostrare se la supervisione aveva un peso reale. Possono identificare il ruolo assegnato, le informazioni presentate, l'avviso o la limitazione mostrata, l'azione intrapresa dal revisore e la disposizione finale. Possono conservare un motivo per una sovrascrittura senza costringere una persona a comporre un saggio ogni volta. Possono anche mostrare quando il sistema non era disponibile o quando il percorso di revisione è stato aggirato. L'assenza di un'azione umana non è automaticamente una cattiva condotta. È un segnale per esaminare se il design ha reso l'azione possibile, necessaria e visibile.

Considera un pattern proposto piuttosto che un evento riportato. Un sistema fornisce una raccomandazione e un breve pannello di evidenze. Il revisore può accettare, modificare, rifiutare o inoltrare. L'interfaccia registra la versione del sistema, i riferimenti alle fonti, lo stato delle policy, il ruolo del revisore e la disposizione. Se il revisore rifiuta la raccomandazione, la registrazione memorizza un motivo controllato e invia un caso per il follow-up dove il pattern suggerisce un difetto ricorrente. Questa non è un'affermazione che il pattern sia sufficiente per ogni contesto ad alto rischio. Mostra come un'interfaccia può trasformare la supervisione umana da una casella di spunta in una parte osservabile della decisione.

La revisione umana deve essere protetta anche dalla stanchezza e dalla pressione sociale. Un registro che mostra migliaia di approvazioni ma nessun intervento significativo può indicare che il flusso di lavoro è sano, oppure che il revisore non è realisticamente in grado di contestare l'esito. I numeri da soli non possono decidere. Una routine di monitoraggio efficace combina le decisioni con il campionamento, i rilievi sugli errori, la qualità delle escalation, il tempo disponibile, la formazione e le conseguenze di una risposta sbagliata. La misurazione dovrebbe illuminare il lavoro, non creare una quota che insegna alle persone ad approvare più in fretta.

La supervisione deve includere il diritto di fermarsi. L'articolo 14 descrive l'intervento o l'interruzione tramite un pulsante di arresto o una procedura simile che consenta al sistema di fermarsi in uno stato sicuro. Un comando di arresto che esiste solo in un runbook non è la stessa cosa di un comando che una persona autorizzata può raggiungere sotto pressione. Il registro dovrebbe mostrare se l'arresto era disponibile, chi poteva usarlo, quale stato ne è seguito e come il flusso di lavoro è ripreso. Un sistema che può essere fermato ma non può spiegare cosa è stato fermato ha risolto solo metà del problema.

C'è un lato umano in questa evidenza. Quando un esito viene contestato, i registri possono proteggere il revisore oltre che la persona interessata. Possono dimostrare che il revisore ha visto un limite, ha seguito la procedura, ha inoltrato un conflitto o ha fermato un'azione rischiosa. Questo non rende corretta ogni decisione. Rende visibili le condizioni del giudizio. La responsabilità non è la caccia all'impronta umana più vicina. È il tentativo di comprendere la catena abbastanza bene da migliorarla.

Il sistema di qualità dietro la documentazione

L'articolo 17 richiede ai fornitori di sistemi di IA ad alto rischio di istituire un sistema di gestione della qualità e di documentarlo in modo sistematico e ordinato attraverso politiche, procedure e istruzioni. Il suo elenco è volutamente ampio. Include la conformità normativa e la gestione delle modifiche, i controlli di progettazione e sviluppo, le prove e la validazione, le specifiche tecniche, la gestione dei dati, la gestione del rischio, il monitoraggio post-commercializzazione, la segnalazione di incidenti gravi, la comunicazione con le autorità e gli altri operatori, la tenuta dei registri, la gestione delle risorse e un quadro di responsabilità per la direzione e il personale.

Letto nel suo insieme, non è una richiesta di un'ulteriore cartella di conformità. È una richiesta che l'organizzazione sappia collegare le proprie decisioni. La procedura di prova dovrebbe avere una relazione con il rischio. Il processo dei dati dovrebbe avere una relazione con la finalità prevista. Il processo di modifica dovrebbe avere una relazione con la documentazione. Il processo di monitoraggio dovrebbe avere una relazione con le azioni correttive. Il quadro delle responsabilità dovrebbe avere una relazione con le persone che possono effettivamente modificare il sistema. Se ogni documento viene mantenuto in isolamento, il sistema di qualità diventa un archivio di buone intenzioni scollegate.

Un registro di qualità utile risponde a quattro domande pratiche. Cosa doveva accadere. Cosa è realmente accaduto. Come è stata notata la differenza. Cosa è cambiato di conseguenza. La risposta può essere distribuita tra un registro dei rischi, un rapporto di prova, un registro delle modifiche, un rapporto sugli incidenti e una decisione di rilascio. Questo è accettabile se le relazioni sono stabili e comprensibili. Non è accettabile se un revisore deve indovinare quali file appartengono allo stesso stato del sistema o quale risultato di prova è stato usato a sostegno di un particolare rilascio.

Il sistema ha anche bisogno di un modo per registrare la decisione di non modificare. Un rischio può essere valutato e giudicato accettabile nelle condizioni documentate. Una funzionalità proposta può essere respinta perché le evidenze sono insufficienti. Un rilascio può attendere perché una valutazione è incompleta. Sono decisioni con una base, non spazio vuoto nel calendario. Registrarle impedisce a un lettore successivo di confondere un confine deliberato con un'omissione accidentale. Aiuta inoltre un team a resistere alla pressione di trasformare ogni questione irrisolta in un piano di lancio.

La gestione della qualità ha una dimensione temporale. Un processo che funzionava per un modello statico potrebbe non funzionare quando il sistema apprende dopo la distribuzione, modifica il proprio indice di recupero o riceve un nuovo strumento. Un processo che funziona per un assistente interno potrebbe non funzionare quando lo stesso componente viene integrato in un flusso di lavoro decisionale. La registrazione dovrebbe quindi individuare i fattori che richiedono una revisione: una versione del modello, una fonte di dati, una finalità, una popolazione di utenti, un'autorizzazione per uno strumento, un requisito legale, un incidente o un modello nei monitoraggi. Il fattore scatenante fa parte del controllo.

Anche qui la proporzionalità è importante. Il Regolamento stabilisce che l'attuazione dovrebbe essere proporzionata alle dimensioni dell'organizzazione del fornitore, rispettando al contempo il rigore e la protezione necessari per la conformità. Proporzionato non significa informale. Un piccolo fornitore può utilizzare una serie compatta di registrazioni ben progettate anziché riprodurre l'infrastruttura di una grande istituzione. Deve comunque sapere chi è responsabile di ogni decisione, dove sono conservate le prove, come vengono valutate le modifiche e come un'autorità può ottenere le informazioni di cui ha bisogno. Piccolo non significa esente dalla memoria.

La conservazione è una scelta progettuale

L'articolo 18 impone ai fornitori di tenere la documentazione specificata a disposizione delle autorità nazionali competenti per un periodo che termina dieci anni dopo l'immissione sul mercato o la messa in servizio di un sistema di IA ad alto rischio. L'articolo 19 riguarda i registri generati automaticamente e richiede che siano conservati, quando sotto il controllo del fornitore, per un periodo appropriato alla finalità prevista e di almeno sei mesi, salvo che un'altra legge, inclusa la normativa sulla protezione dei dati, disponga diversamente. Questi sono requisiti legali con ambiti precisi. Non dovrebbero essere generalizzati con leggerezza a ogni registrazione in ogni flusso di lavoro di IA.

La lezione pratica è che la conservazione deve essere progettata per classe di registrazione. La documentazione tecnica, le registrazioni del sistema di qualità, il materiale di conformità, i registri, i dati di origine, le note umane, gli insiemi di valutazione, le prove degli incidenti e le spiegazioni pubbliche possono avere finalità e durate diverse. Un'unica impostazione predefinita di conservazione è una scorciatoia architetturale, non una strategia di governance. Può cancellare le prove troppo presto o conservare materiale sensibile molto tempo dopo la fine della sua finalità. Il sistema dovrebbe sapere quale livello sta conservando e perché.

La conservazione richiede anche un inizio e una fine. Una registrazione che dice conservare per dieci anni senza definire l'evento da cui decorre il periodo non è operativamente completa. Un registro conservato per sei mesi senza precisare se il periodo decorre dall'evento, dal rilascio o dalla fine di un ciclo di monitoraggio genera confusione evitabile. Il testo normativo fornisce i riferimenti pertinenti per gli obblighi specifici. L'organizzazione deve mappare tali riferimenti sugli stati del sistema e rendere la mappatura ispezionabile.

La cancellazione di una registrazione è di per sé un evento. Se un prompt operativo viene rimosso perché la sua finalità è terminata, il sistema potrebbe dover conservare un riferimento che dimostri che la rimozione è avvenuta e quale regola di conservazione l'ha autorizzata. Se un errore viene corretto, le prove originali potrebbero dover rimanere disponibili in una cronologia controllata anziché scomparire senza spiegazione. Se i dati personali vengono cancellati, gli artefatti derivati e i percorsi di accesso potrebbero richiedere un'analisi separata. La registrazione della cancellazione non dovrebbe essere scambiata per la prova che ogni copia sia sparita. È la prova di un'azione controllata entro un confine definito.

La conservazione può anche proteggere l'apprendimento istituzionale. Una revisione di un incidente che conserva solo la conclusione finale perde le condizioni che hanno prodotto il problema. Una registrazione di valutazione che conserva solo un punteggio perde il carico di lavoro, la popolazione, il metodo e i limiti che rendevano interpretabile il punteggio. Una registrazione di correzione che conserva solo il nuovo valore perde il fatto che un valore errato ha attraversato un sistema. Conservare tutto non è la risposta. Conservare le prove giuste per la domanda lo è.

Quando le prove mancano

The most useful record systems are designed for absence. They can say that a source was unavailable, that a field was redacted, that a version identifier was unknown, that a human review did not occur, that a tool acknowledgement failed or that a replay cannot be completed. This is not an invitation to manufacture a tidy placeholder. It is a way to prevent missing evidence from being silently converted into confidence.

Absence has types. Not collected means the system never attempted to preserve the field. Not available means the field existed elsewhere but could not be obtained. Not applicable means the condition did not belong to the workflow. Redacted means the evidence exists but is restricted under a rule. Conflicted means two sources disagree. Unknown means the organisation has not established the answer. These labels are proposed operating vocabulary, not terms mandated by the AI Act. Their value is that they keep different problems from collapsing into one empty cell.

A completeness inspector should therefore ask questions, not count fields. Does the record identify the system state. Does it show the purpose and input scope. Can the source or policy basis be found. Is the human authority visible. Are uncertainty and exclusions named. Can a person correct, appeal, suspend or delete within the applicable boundary. The answers depend on context. A record may be complete for an operational alert and incomplete for an individual decision. Completeness is a relationship between evidence and consequence.

Missing records should trigger a response that matches the risk. A low-impact missing label may be repaired in the next release. A missing model version for a consequential decision may require the decision to be reviewed or the workflow suspended. A missing log of a state-changing tool call may require investigation outside the model team. The organisation should decide these thresholds before the incident, because deciding them during a heated review usually produces a policy made of adrenaline.

The absence path also needs an owner and a timestamp. If a required record cannot be produced, someone should know who is responsible for investigating, who can decide whether work continues, which evidence is being sought and when the status will be reviewed. That turns a gap into a managed state. It does not make the gap harmless. It prevents the institution from pretending that a missing page is an empty page.

The AI Office and the work of interpretation

The AI Act creates institutions and procedures that help turn the Regulation into practice. The Commission’s AI Office has a role in supervising and enforcing the obligations for general-purpose AI models, while national competent authorities and market surveillance authorities have responsibilities within the broader framework. The AI Act Service Desk provides an explainer for Article 12 that summarises the record-keeping duty and points readers to the official text. Its summary is explicitly non-binding. That distinction is worth preserving.

Guidance can make a rule usable by translating a legal requirement into examples, questions and implementation choices. It cannot replace the Regulation. An organisation should be able to show which claim comes from the binding text, which comes from guidance and which is its own control decision. This source discipline is not academic fussiness. It prevents a helpful example from becoming a fictional obligation and prevents a voluntary practice from being marketed internally as a legal minimum.

La comunicazione AI@EC della Commissione offre un utile esempio istituzionale, senza pretendere di descrivere ogni organismo pubblico. Nel gennaio 2024 la Commissione ha definito un approccio per il proprio sviluppo e uso dell'IA, che include orientamenti operativi interni, valutazione e classificazione basate sul rischio, l'esclusione di sistemi incompatibili con i valori europei o che minacciano diritti e sicurezza, e strutture organizzative per adempiere agli obblighi. Il punto non è che una comunicazione risolva l'attuazione. Il punto è che un'istituzione che si prepara a usare l'IA deve anche preparare la propria capacità di governarne l'uso.

Questa capacità si costruisce con registrazioni che possono viaggiare. Una politica dovrebbe indicare un responsabile. Una valutazione del rischio dovrebbe indicare un'identità di sistema. Una descrizione tecnica dovrebbe indicare una release. Una registrazione di formazione dovrebbe indicare un ruolo e una competenza. Un segnale di monitoraggio dovrebbe indicare un'azione. Un reclamo dovrebbe indicare un percorso. Quando queste relazioni sono esplicite, le linee guida possono essere applicate senza inventare un universo separato di pratiche burocratiche. Quando non lo sono, ogni nuova linea guida diventa un altro documento che l'organizzazione spera possa in qualche modo cambiare i comportamenti.

Il diritto europeo ha una particolare consistenza istituzionale. Le responsabilità sono distribuite tra istituzioni dell'Unione, Stati membri, autorità, fornitori, deployer e altri operatori. Una registrazione deve rendere visibile questa distribuzione, invece di appiattire ogni attore in un generico proprietario di sistema. La questione non è solo chi ha costruito il modello. È chi lo ha messo in servizio, chi controlla l'input, chi ha assegnato la supervisione, chi può sospenderne l'uso e chi deve cooperare con un'autorità. Nomi e contratti contano, ma contano anche i poteri operativi che una registrazione può rivelare.

Dal linguaggio giuridico alla routine quotidiana

La legge diventa pratica quando un'organizzazione converte ogni obbligo in un piccolo numero di routine ripetibili. Questo è un modello operativo proposto, non una checklist giuridica. All'ingresso, classificare lo scopo previsto, le persone interessate, le categorie di dati, l'autonomia, gli strumenti e l'autorità decisionale. Prima del rilascio, vincolare l'identità del sistema, la versione, lo stato delle istruzioni, le fonti dei dati, i test, i limiti, il ruolo di supervisione e il percorso di arresto. Durante il funzionamento, registrare gli eventi rilevanti, monitorare i rischi e rendere visibile l'incertezza. Dopo un cambiamento o un incidente, indagare, correggere, aggiornare la descrizione e decidere se l'uso debba continuare.

Notate ciò che questo modello non dice. Non dice di raccogliere ogni messaggio per sempre. Non dice che un log automatico sia la stessa cosa di una spiegazione. Non dice che una dashboard dimostri la sicurezza. Non dice che un nome umano in un flusso di lavoro dimostri la supervisione. Dice che il sistema dovrebbe avere una registrazione delle condizioni in cui gli è consentito operare e degli eventi che possono mostrare se tali condizioni sono state rispettate.

Una buona routine ha un inizio e una fine. Una registrazione viene creata quando inizia uno stato significativo, aggiornata quando cambiano le prove o l'autorità e chiusa quando termina lo scopo o il periodo di revisione. L'evento di chiusura conta perché le registrazioni aperte diventano silenziosamente permanenti. Dovrebbe dichiarare se il sistema è stato rilasciato, respinto, sospeso, sostituito, corretto o ritirato. Se la registrazione non può essere chiusa, l'organizzazione dovrebbe sapere perché. Uno stato provvisorio infinito è un modo educato per evitare una decisione.

Le routine dovrebbero anche distinguere i fatti dalle interpretazioni. Un log può registrare che un modello ha restituito un output. Un revisore può registrare che l'output è stato respinto perché una fonte era in conflitto con una politica. Un team di incidenti può in seguito dedurre che una modifica al recupero abbia contribuito al conflitto. L'inferenza può essere solida, ma non è lo stesso tipo di prova dell'evento. Strati etichettati rendono le indagini successive più oneste. Senza di essi, ogni conclusione si indurisce gradualmente in un fatto perché nessuno ricorda quale frase è stata osservata e quale è stata scritta in riunione.

La titolarità dovrebbe essere visibile a livello di campo, dove è pratico. Il fornitore può possedere la documentazione tecnica. Un deployer può possedere la pertinenza degli input e il monitoraggio operativo. Un data steward può possedere i diritti sulle fonti e la qualità. Un ruolo di supervisione umana può possedere la decisione di accettare, sovrascrivere o fermare. Una funzione di registrazione può possedere la conservazione e l'accesso. L'assegnazione varia in base al contesto e al contratto. Il registro dovrebbe rendere possibile porre una domanda al titolare giusto senza inviare un'email a catena a tutta l'organizzazione.

Testare la procedura è importante quanto scriverla. Un controllo proposto dovrebbe essere esercitato con uno scenario sicuro e chiaramente etichettato. Il team riesce a recuperare il registro per versione del sistema? Un operatore riesce a vedere lo stato delle istruzioni usato al momento del rilascio? Un revisore riesce a rifiutare un output e a conservarne il motivo? Il percorso di arresto riesce a lasciare uno stato chiaro? Un'autorità competente riesce a ricevere la documentazione pertinente senza una caccia al tesoro? Questi sono esercizi, non incidenti segnalati. I loro risultati dovrebbero essere registrati come test, con eventuali limitazioni dichiarate chiaramente.

La procedura dovrebbe essere progettata per un giorno tranquillo. Se funziona solo quando uno specialista è sveglio, un fornitore risponde rapidamente e tutti ricordano la cronologia della distribuzione, non è una procedura. È memoria collettiva con un accordo sul livello di servizio. Un sistema di registrazione serio offre al personale ordinario un modo per rispondere a domande ordinarie e offre agli specialisti un percorso più profondo quando la domanda diventa consequenziale. Il giorno tranquillo è dove il sistema si guadagna il diritto di essere fidato nel giorno rumoroso.

C'è la tentazione di rendere belli i registri. Un design chiaro aiuta le persone a usarli, ma la rifinitura visiva non è una prova. Uno stato colorato, un punteggio di maturità o una scheda dall'aspetto completo possono nascondere campi mancanti. L'interfaccia dovrebbe rendere più difficile trascurare l'incertezza, i dati obsoleti e le affermazioni non verificate. Dovrebbe supportare le azioni noiose che mantengono veritiero un registro: fissare una versione, identificare una fonte, nominare un ruolo, segnare una limitazione, collegare una correzione e chiudere uno stato. Un buon design dà al registro delle maniglie. Non dà al registro poteri che non ha guadagnato.

Una breve nota da parte nostra

In Dweve, il nostro Trust Centre è organizzato attorno a questa stessa domanda: cosa dovrebbe poter ispezionare un'altra persona su un modello e sul suo funzionamento. L'indice pubblico collega identità del modello, contenuti di addestramento, valutazioni, gestione del rischio, monitoraggio post-commercializzazione, incidenti, governance dei dati e documentazione tecnica. Questa disposizione non è un'affermazione che una pagina pubblica dimostri la conformità, e non è un sostituto della valutazione di un'autorità. È un tentativo deliberato di mantenere visibili i registri e i loro confini. Il nostro lavoro su Ledger sostiene un argomento correlato a livello operativo: un registro dovrebbe portare con sé identità e cronologia sufficienti affinché un lettore successivo possa verificare cosa è cambiato. Il test utile non è se la pagina sembra rassicurante. È se le prove dicono la verità su ciò che possono e non possono stabilire.

I registri fanno parte dell'istituzione

L'errore più profondo è trattare i requisiti di registrazione dell'AI Act come una tassa sull'innovazione. Sono meglio compresi come una descrizione di ciò di cui un'istituzione ha bisogno per usare un sistema potente e in evoluzione senza rinunciare alla propria memoria. Un modello può produrre un output rapidamente. Un'istituzione deve decidere se l'output appartiene a una decisione, se qualcuno può contestarlo, se una correzione può viaggiare attraverso il sistema e se un lettore futuro può comprendere il percorso.

È per questo che i registri non possono restare ai margini dell'architettura. Devono stare accanto a dati, istruzioni, versioni dei modelli, strumenti, interfacce, ruoli umani e rimedi. Il registro è il tessuto connettivo che permette a queste parti di rispondere l'una all'altra. Trasforma una dichiarazione di rischio in una condizione verificabile. Trasforma una fonte in una base tracciabile. Trasforma un'approvazione umana in un atto osservabile. Trasforma una correzione in una modifica che può essere controllata. Trasforma un campo mancante in una questione gestita, invece che in uno spazio vuoto di cui nessuno si occupa.

Il lavoro è silenzioso perché sembra ordinario. Dare un nome al sistema. Fissare lo scopo. Registrare la versione. Mantenere il confine della fonte. Testare il registro. Dare autorità al revisore. Segnare ciò che è sconosciuto. Conservare la risposta. Archiviare il registro quando lo scopo termina. Nulla di tutto questo ha il fascino di un video di lancio. Ha la proprietà ben più preziosa di sopravvivere a un cambio di personale, a un cambio di modello, a un cambio di fornitore e a una domanda posta da qualcuno che non era nella stanza.

Ci saranno comunque disaccordi sull'interpretazione dell'AI Act, sul livello appropriato di dettaglio e sul modo in cui gli standard tradurranno i requisiti legali in pratica tecnica. I registri non eliminano queste discussioni. Le rendono più precise. Un'organizzazione può mostrare su quale testo ha fatto affidamento, quale presupposto ha adottato, quali prove aveva, quale controllo ha scelto e dove rimane la sua incertezza. Questo è un punto di partenza migliore per un regolatore, un collega, una persona interessata e l'organizzazione stessa.

La lezione pratica è semplice. Non chiedersi solo se un sistema di IA possa produrre un risultato. Chiedersi se l'istituzione possa ricordare le condizioni di quel risultato, mostrare le prove che contavano, nominare l'autorità che ha agito, identificare l'incertezza rimasta e far viaggiare una correzione. Se la risposta è no, il sistema può essere comunque tecnicamente impressionante. Ma non è ancora pronto dal punto di vista istituzionale.

Il lavoro silenzioso dell'AI Act dell'UE non consiste quindi nel far sembrare seria la tecnologia. Consiste nel rendere osservabile la serietà. I registri non sono slogan con timestamp. Sono prove delimitate, create per uno scopo, collegate alla responsabilità e aperte alla correzione. Se costruiti con cura, un'organizzazione può usare l'IA senza chiedere alla fluidità di sostituire la memoria. Se lasciati come ripensamento, la prima domanda difficile scoprirà che il sistema ha conservato il suo output ma ha smarrito la sua storia.

Fonti

• Regolamento (UE) 2024/1689, Artificial Intelligence Act (Parlamento europeo e Consiglio, Gazzetta ufficiale dell'Unione europea, 12 luglio 2024).
• Articolo 12: obblighi di registrazione (Commissione europea, AI Act Service Desk; sintesi esplicativa e collegamento al testo ufficiale).
• Artificial Intelligence in the European Commission (AI@EC) Communication (Commissione europea, 18 gennaio 2024).
• Dweve Trust Centre (Dweve, indice pubblico dei registri).
• Technical Documentation Index (Dweve Trust Centre, indice pubblico dei registri).