Il registro dei modelli è la nuova bacheca pubblica.

Un registro dei modelli può dire al pubblico cos’è un sistema, chi lo sostiene, dove può essere usato e cosa è cambiato. Non può trasformare una voce...

Il registro dei modelli è la nuova bacheca pubblica.

The page that starts by admitting it is not magic

The first thing a useful model registry does is disappoint you. It does not say that a model is safe. It does not say that an organisation is competent. It does not turn a supplier's promise into a fact, or a green label into a reason to stop asking questions. It gives you a bounded record instead: this is the thing, this is the version, this is the owner, this is the declared purpose, this is the status, and this is where the supporting evidence is kept.

That modesty is the beginning of public trust. A registry is a noticeboard, not a shrine. A noticeboard tells a neighbourhood what is being built, who is responsible for it and which notices have been replaced. It does not certify the workmanship of every building on the street. It gives people a place to start looking, and a way to notice when the notice itself has gone stale.

Open the Dutch government's Algorithm Register and the design is unusually plain. Government organisations publish information about algorithms they use in their work. The register focuses on impactful algorithms, including high-risk AI systems, and gives visitors an explanation of how those systems work. The page also makes a useful distinction that many glossy AI catalogues avoid: an algorithm is a set of rules and instructions a computer follows to calculate an answer, not a personality with a product launch.

The page is public because the work is public. A citizen does not need a private account to discover that an authority uses an algorithm, what the authority says it is for, or where to ask the next question. That does not make every technical detail public. It does make the existence of the system, its declared role and its institutional owner harder to hide behind a procurement file.

Model registries are becoming the same kind of civic object. They sit between a technical catalogue and a public record. Engineers need a stable identity and a version to integrate. Operators need a status and an owner to run. Downstream providers need capabilities, limits and conditions. Auditors need a trail back to evidence. Affected people need to know that a system exists and how to challenge what it does. One page cannot answer all of those questions, but a well-designed registry can point each reader to the right layer.

The danger is that the word registry makes a document sound more complete than it is. A phone book is a registry, but it cannot tell you whether a number still works. A shipping manifest is a registry, but it cannot tell you whether the cargo survived the voyage. A model record is a registry, but it cannot carry the entire proof of performance, fairness, security, legality and social consequence. The useful question is not whether a model is in the registry. It is what the entry establishes, what it leaves open and what a reader can inspect next.

A noticeboard is a promise of selection

An inventory tries to count everything. A catalogue tries to help you choose. A register makes a more formal promise: these entries belong to a defined scope, they have an owner, and the information is maintained under a rule. The promise is about selection before it is about software. Without a stated scope, an attractive list is only a collection of things that happened to be remembered.

That is why every registry needs a sentence that says what it includes and what it deliberately leaves out. The EU AI Act's central database is not a list of every model circulating in Europe. Article 71 establishes an EU database for specified high-risk AI systems and the systems that are registered under the routes described in Article 49. The Dutch Algorithm Register is not a list of every calculation made in a government office. It focuses on impactful algorithms, including high-risk AI systems. The boundary is part of the record, not a footnote for lawyers.

Un registro dei modelli dovrebbe rispondere alla stessa domanda di confine in linguaggio ordinario. Elenca i modelli fondativi, i sistemi di IA distribuiti, gli esperimenti interni, i discendenti messi a punto, i pacchetti di valutazione o solo i modelli offerti a utenti esterni? Una nuova configurazione di servizio riceve una nuova voce, una nuova versione o un record di distribuzione collegato? Uno stato catturato di un sistema adattivo conta come la stessa identità di modello? Se il registro non decide queste questioni, ogni lettore le deciderà in modo diverso. È così che un elenco breve diventa una lunga discussione.

La selezione rende significativa anche l'assenza. Se l'ambito afferma che tutti i sistemi ad alto rischio accessibili al pubblico devono comparire, una voce mancante è un problema di governance. Se l'ambito afferma che sono inclusi solo i modelli immessi sul mercato, un esperimento interno può essere assente per progettazione. Il pubblico non può interpretare un risultato di ricerca vuoto senza sapere quale delle due situazioni si applica. Il silenzio non è neutro quando il registro non ha spiegato il proprio vocabolario.

C'è una piccola virtù amministrativa nel dirlo chiaramente. I registri non devono fingere di sapere tutto. Devono dire al lettore cosa sanno, di cosa sono responsabili e cosa resta fuori dal quadro. Un registro guadagna la propria autorevolezza rendendo esplicito il confine del proprio ambito, non decorando la copertina. La tecnologia è più recente. L'istinto burocratico non lo è.

Cosa mette realmente sul tavolo la normativa europea

L'AI Act dà alla parola registrazione una forma giuridica concreta, ma non una forma unica e universale. L'articolo 49 richiede che un fornitore o un rappresentante autorizzato registri determinati sistemi di IA ad alto rischio prima di immetterli sul mercato o metterli in servizio. Richiede inoltre la registrazione quando un fornitore ha concluso che un sistema non è ad alto rischio alle condizioni dell'articolo 6, paragrafo 3. Le autorità pubbliche e gli organismi pubblici equivalenti che utilizzano determinati sistemi ad alto rischio hanno un proprio obbligo di registrazione, inclusa la registrazione del loro uso.

Lo stesso articolo rende esplicito il confine pubblico-privato. Alcuni sistemi ad alto rischio utilizzati nelle attività di contrasto, migrazione, asilo e gestione delle frontiere sono registrati in una sezione non pubblica e sicura. I sistemi ad alto rischio di cui al secondo punto dell'allegato III sono registrati a livello nazionale. Non sono dettagli attuativi che possono essere risolti in una dashboard. Descrivono pubblici diversi, rischi diversi e permessi diversi di consultare il record.

L'articolo 71 stabilisce che la Commissione, in collaborazione con gli Stati membri, istituisca e gestisca la banca dati dell'UE. Le informazioni registrate ai sensi dell'articolo 49 devono essere accessibili e disponibili al pubblico in modo facile da usare e dovrebbero essere facilmente consultabili e leggibili da dispositivo automatico, con eccezioni per le sezioni riservate. La banca dati dovrebbe contenere dati personali solo nella misura necessaria. Questa è una definizione utile di trasparenza pubblica: un record che le persone possono trovare ed elaborare, senza trasformare il record in un secondo problema di dati personali.

L'allegato VIII è il punto in cui il quadro diventa specifico. Per un fornitore che registra un sistema ad alto rischio, il record include l'identità e i recapiti del fornitore, una denominazione commerciale o un riferimento inequivocabile, la finalità prevista, una descrizione di base delle informazioni utilizzate e della logica di funzionamento, lo stato del sistema, i certificati pertinenti, gli Stati membri in cui il sistema è immesso sul mercato o messo in servizio, la dichiarazione di conformità, le istruzioni per l'uso e un URL facoltativo per ulteriori informazioni. Non sono campi di marketing. Sono strumenti di identificazione e responsabilità.

Per un deployer pubblico, le informazioni sono diverse. Il registro include l'identità del deployer, la persona che presenta le informazioni, l'URL della voce del fornitore e sintesi di una valutazione d'impatto sui diritti fondamentali e, ove applicabile, di una valutazione d'impatto sulla protezione dei dati. La distinzione conta perché un fornitore di modelli e un'autorità pubblica non conoscono le stesse cose e non hanno la stessa responsabilità. Un registro che li comprime in un'unica scheda fornitore cancella il punto in cui un sistema incontra un'istituzione.

Il database giuridico ha quindi un carattere stratificato. Registra un'identità di sistema. Registra un fornitore. Può registrare un deployer e un uso. Registra lo stato e le dichiarazioni di supporto. Non sostituisce la documentazione tecnica, la gestione del rischio, il sistema di qualità o il monitoraggio post-commercializzazione che l'Atto richiede altrove. Il database è un indice pubblico di fatti di cui si risponde. Non è l'intero fascicolo di conformità.

Questa distinzione si perde facilmente perché alle persone piace un unico URL che sembra contenere la risposta. La legge è meno sentimentale. Crea una superficie pubblica, superfici ristrette e percorsi documentali controllati. La superficie pubblica deve essere utilizzabile. La superficie ristretta deve restare ristretta. La documentazione deve rimanere disponibile all'autorità competente o al fornitore a valle che ne ha bisogno. Un registro serio è un'interfaccia tra questi obblighi, non una scorciatoia per evitarli.

Un registro diventa utile quando identità, stato e modifica sono collegati. Un colore senza transizione è solo decorazione.

C'è un altro limite importante. Le disposizioni dell'Atto sull'IA relative ai modelli di IA per finalità generali non sono la stessa cosa di un catalogo pubblico di tutti i modelli per finalità generali. L'articolo 53 richiede ai fornitori di conservare la documentazione tecnica, mettere le informazioni a disposizione dei fornitori a valle di sistemi di IA, mantenere una politica sul diritto d'autore e pubblicare una sintesi sufficientemente dettagliata dei contenuti di addestramento. Le linee guida della Commissione spiegano che la documentazione tecnica è destinata all'Ufficio per l'IA e alle autorità nazionali competenti su richiesta, mentre la documentazione per i fornitori a valle aiuta gli integratori a comprendere capacità e limiti. Solo parte di quel materiale appartiene a una bacheca pubblica.

L'Atto richiede inoltre alla Commissione di pubblicare e mantenere un elenco dei modelli di IA per finalità generali con rischio sistemico. Un elenco di modelli con rischio sistemico è un segnale pubblico prezioso, ma non è lo stesso oggetto di un registro completo dei modelli. Ha uno scopo più ristretto e deve rispettare i diritti di proprietà intellettuale, le informazioni commerciali riservate e i segreti commerciali. Chiamare ogni elenco un registro è innocuo solo finché qualcuno non presume che un elenco dimostri più di quanto faccia.

Un modello non è una singola riga

Le persone parlano di un modello come se fosse un barattolo su uno scaffale. Il nome è stampato sull'etichetta, la versione è impressa sotto e il contenuto rimane invariato finché qualcuno non apre il coperchio. Questa immagine funziona per un artefatto statico. Diventa inaffidabile quando un modello viene adattato, messo a punto, avvolto in strumenti, servito attraverso più percorsi o modificato durante l'uso.

Un registro necessita di almeno due identità: l'identità del modello e l'identità della cosa che è effettivamente stata eseguita. La prima risponde a quale modello intende il fornitore. La seconda può identificare uno stato acquisito, un pacchetto di distribuzione sigillato, un'esportazione locale o un bundle di riproduzione. Collegarle previene due errori opposti. Un servizio può smettere di fingere che ogni stato attivo abbia un hash permanente, e un operatore può smettere di fingere che un digest del pacchetto da solo descriva l'intera famiglia di modelli.

I numeri di versione sono utili solo quando la regola che ne governa il cambiamento è visibile. Una versione può indicare un nuovo set di parametri appresi, un nuovo catalogo di vincoli, un cambiamento nel recupero delle informazioni, un livello di sicurezza modificato o una modifica sostanziale del contratto di servizio. Se un fornitore usa un unico numero per tutte queste cose, quel numero diventa un modo educato per dire che qualcosa è cambiato. Un registro dovrebbe collegare un successore al suo predecessore e indicare quale parte del contratto è stata modificata.

Il comportamento adattivo aggiunge un'altra complessità. Se un sistema può cambiare mentre è in uso, il registro dovrebbe dichiararlo. Non è un'ammissione che il sistema sia fuori controllo. È un'ammissione che la parola versione non può fare tutto il lavoro. Il registro può mantenere un'identità stabile del modello, associarvi stati acquisiti con validità temporale e registrare le condizioni in cui uno stato è stato creato. Il punto non è congelare un sistema vivo in una fotografia falsa. È dare a ogni fotografia significativa una data e un contesto.

L'identità ha anche un aspetto sociale. Un nome di modello non basta quando più entità giuridiche distribuiscono artefatti simili, quando un fornitore a valle modifica il modello o quando un prodotto incorpora un modello dietro il proprio nome. Il registro dovrebbe rendere visibile la catena: fornitore, distributore se diverso, deployer se pertinente, e il sistema o il percorso in cui il modello viene utilizzato. Una persona colpita da una decisione non dovrebbe dover fare archeologia forense su un logo di prodotto per scoprire chi può risponderne.

Lo stato è un verbo, non un colore

I campi di stato sono spesso resi come badge perché i badge si adattano bene alle card. Il badge non è lo stato. Lo stato è una dichiarazione su un'azione e un momento. Il test interno significa una cosa quando l'accesso è controllato dal fornitore. Il pre-rilascio significa qualcos'altro quando soggetti esterni invitati possono usare un percorso a condizioni definite. Sul mercato, in servizio, sospeso, ritirato e revocato comportano ciascuno conseguenze operative diverse.

Un registro utile dichiara cosa lo stato consente e cosa non consente. Se un sistema è solo interno, un lettore non dovrebbe dedurre la disponibilità pubblica da una pagina di documentazione. Se è prevista una beta esterna, la data dovrebbe essere etichettata come pianificata piuttosto che presentata come un rilascio. Se un sistema è ritirato, il registro dovrebbe preservare l'identità precedente e dichiarare se le distribuzioni esistenti possono continuare, devono cessare o sono in fase di migrazione. Uno stato senza data di efficacia è una voce che indossa un'uniforme.

Lo stato dovrebbe anche avere un proprietario. Chi può spostare una voce da interno a esterno? Chi può sospendere un percorso? Chi può dichiarare che una data di rilascio è cambiata? Quali prove sono richieste prima della transizione? Queste domande appartengono al processo operativo, ma la voce pubblica dovrebbe rendere leggibile la decisione che ne deriva. Un registro che mostra il badge attuale nascondendo l'autorità che c'è dietro è solo una mood board per la governance.

Esempio illustrativo, non una vera inserzione: una voce potrebbe dichiarare che un modello è in valutazione controllata, che nessun percorso esterno è aperto, che una prova su invito è proposta per una data successiva e che la proposta rimane soggetta a un gate di rilascio. L'esempio non nomina alcuna organizzazione, modello o evento. Il suo scopo è mostrare come una voce mantiene un piano separato da un fatto. La stessa disciplina si applica a un ritiro, a una dichiarazione di capacità o a una certificazione non ancora rilasciata.

Questa separazione protegge i lettori da un trucco familiare. Un'intenzione futura viene ripetuta abbastanza spesso da iniziare a sembrare storia. I registri dovrebbero essere il luogo in cui quel trucco smette di funzionare. La voce può mostrare un piano, ma il piano deve mantenere la sua etichetta. L'Europa ha già abbastanza calendari. Una data non è un fatto solo perché è stata inserita in un rettangolo colorato.

Il registro non è la stanza delle prove

Una voce pubblica dovrebbe essere abbastanza breve da poter essere letta e abbastanza solida da orientare una domanda seria. La sala delle prove che sta dietro può essere molto più ampia. Gli obblighi di documentazione dell'articolo 53 dell'AI Act illustrano il perché. I fornitori di modelli di IA per finalità generali devono redigere e conservare una documentazione tecnica che copra sviluppo, addestramento, test e valutazione. Devono mettere a disposizione informazioni e documentazione ai fornitori di sistemi di IA a valle, così che questi possano comprenderne capacità e limiti. Devono pubblicare una sintesi sufficientemente dettagliata dei contenuti di addestramento e mantenere una politica in materia di diritto d'autore dell'Unione.

Questi obblighi servono lettori diversi. Un'autorità competente può aver bisogno dell'intero fascicolo tecnico. Un fornitore a valle ha bisogno delle informazioni per l'integrazione e dei limiti. Il pubblico ha bisogno di un resoconto chiaro di che cosa sia il modello e di come sia delimitata la sintesi dei contenuti di addestramento. Una voce di registro può collegare queste superfici senza fingere che una pagina pubblica debba contenere ogni dettaglio sensibile per la sicurezza, ogni file di pesi o ogni campione di test che contenga dati personali.

I collegamenti non sono prove per magia. Un registro che rimanda a un rapporto di valutazione dovrebbe indicare quale versione il rapporto copre, che cosa la valutazione ha misurato e quali condizioni limitano il risultato. Un collegamento a una sintesi dell'addestramento dovrebbe dire se la sintesi copre il pre-addestramento, l'ottimizzazione o un insieme definito di categorie di contenuti. Un collegamento a un certificato dovrebbe mostrare chi lo ha rilasciato, che cosa certifica e quando scade. Altrimenti la pagina è uno scaffale di buste mai aperte.

La stessa regola vale per le dichiarazioni di sicurezza. Un registro può dire che esiste una valutazione del rischio, che un piano di monitoraggio è collegato o che è pubblicato un canale per gli incidenti gravi. Non dovrebbe far intendere che l'esistenza di un documento provi che il sistema sottostante sia sicuro. La documentazione è un modo per esaminare un'affermazione. Non ne è il sostituto.

È qui che la scrittura pubblica richiede disciplina. Una scheda modello, una pagina di trasparenza o una voce di registro possono descrivere l'uso previsto e i limiti noti. Non possono usare la parola affidabile come conclusione, a meno che le prove e l'ambito non rendano quella conclusione difendibile. La frase onesta è spesso più utile: queste sono le condizioni che abbiamo valutato, questi sono i limiti che abbiamo osservato e questi sono i casi che non abbiamo affermato di coprire.

Il registro olandese mostra il valore di un elenco pubblico ordinario

Il registro olandese degli algoritmi è istruttivo proprio perché non cerca di sembrare una sala di controllo futuristica. Offre alle organizzazioni governative un luogo pubblico in cui descrivere gli algoritmi usati nel loro lavoro. La sua pagina in inglese avverte che le descrizioni sono state tradotte automaticamente e che l'originale olandese è la versione autorevole della descrizione. Quella piccola nota è una lezione sulla provenienza. L'accesso non equivale all'accuratezza, e un'interfaccia tradotta non dovrebbe cancellare la lingua di partenza.

Lo scopo pubblico del registro è dichiarato anche senza linguaggio teatrale. Si concentra sugli algoritmi ad alto impatto, compresi i sistemi di IA ad alto rischio, e offre ai visitatori una visione di come funzionano. Il visitatore può consultare algoritmi, organizzazioni e modelli. L'obiettivo non è offrire un punteggio per ogni algoritmo. È rendere l'uso dei sistemi algoritmici abbastanza visibile perché persone, organizzazioni e media possano seguire, mettere in discussione e esaminare le pratiche del governo.

Il relativo Algoritmekader olandese trasforma questo scopo in un requisito. Stabilisce che, salvo esclusioni, gli enti pubblici pubblichino gli algoritmi ad alto impatto e i sistemi di IA ad alto rischio nel registro. Stabilisce inoltre che una pubblicazione errata o incompleta può rendere più difficile per le persone interessate e per gli altri portatori di interessi comprendere e contestare l'uso di tecnologie che possono toccare i loro diritti. La trasparenza non è quindi solo una cortesia. La qualità della voce può influire sulla qualità del controllo pubblico.

La stessa guida è prudente riguardo al proprio ambito di applicazione. Descrive il registro come uno strumento all'interno di un insieme più ampio di leggi e requisiti e avverte che il quadro normativo non è completo e potrebbe non includere la legislazione settoriale. Il fatto che un algoritmo compaia in un registro non risolve ogni questione legale o etica. Il fatto che non vi compaia non dimostra che sia innocuo. Per interpretare la voce, il lettore ha bisogno della regola di inclusione del registro e del quadro normativo circostante.

Questo è il modello utile per i registri dei modelli. Un elenco pubblico dovrebbe essere facile da trovare, scritto per persone che non hanno partecipato alla riunione di approvvigionamento e collegato ai documenti che contengono maggiori dettagli. Dovrebbe rendere visibile l'incertezza, non nasconderla. Dovrebbe indicare quando una descrizione in inglese è tradotta automaticamente. Dovrebbe spiegare quali sistemi sono inclusi e quali no. Dovrebbe trasformare una voce mancante o obsoleta in un problema di governance visibile, invece che in una delusione privata.

Non serve inventare un incidente drammatico per capire perché questo è importante. Un cittadino che cerca di comprendere un processo governativo automatizzato ha già una domanda pratica: un sistema è in uso, da chi, per quale scopo e in base a quale spiegazione? Un registro dà a questa domanda un indirizzo. La risposta potrebbe essere ancora incompleta. Almeno l'istituzione non può fingere che non ci sia un luogo dove chiedere.

Pubblico non significa esposto

La trasparenza diventa controproducente quando viene trattata come un ordine di pubblicare tutto. I documenti pubblici possono esporre dati personali, informazioni sensibili per la sicurezza, dettagli proprietari e percorsi di attacco. Possono anche creare falsa fiducia pubblicando frammenti tecnici che nessun lettore comune può interpretare. Il confine tra pubblico e privato deve essere progettato, documentato e rivisto, non improvvisato dal team che capita di gestire il sistema di gestione dei contenuti.

L'AI Act offre un esempio legale. L'articolo 49, paragrafo 4, colloca determinati sistemi in una sezione sicura non pubblica e limita l'accesso alla Commissione e alle autorità nazionali competenti. L'articolo 71 rende pubbliche le informazioni registrate ai sensi dell'articolo 49, ad eccezione delle sezioni riservate, mentre le informazioni registrate ai sensi dell'articolo 60 sono accessibili solo alle autorità di vigilanza del mercato e alla Commissione, salvo che il fornitore acconsenta alla pubblicazione. La pubblicità è quindi una regola con eccezioni, non un default universale.

L'articolo 53 opera una distinzione simile per i modelli di uso generale. I fornitori devono mettere a disposizione dell'Ufficio per l'IA e delle autorità nazionali competenti la documentazione tecnica su richiesta e devono fornire la documentazione a valle ai fornitori che integrano il modello. Gli obblighi sono esplicitamente subordinati alla necessità di rispettare e proteggere i diritti di proprietà intellettuale, le informazioni commerciali riservate e i segreti commerciali. Un registro non dovrebbe costringere un fornitore a pubblicare materiale che la legge dice di tenere sotto controllo. La riservatezza non dovrebbe nemmeno diventare una scusa educata per nascondere l'esistenza, lo scopo o lo stato di un sistema che incide sul pubblico.

Un registro pratico dei modelli può usare livelli. Il livello pubblico identifica il modello, il fornitore, lo stato, lo scopo previsto, le capacità generali, i limiti noti, le modalità di accesso, le condizioni di rilascio, i collegamenti alle prove e la cronologia delle modifiche. Un livello controllato contiene documentazione tecnica dettagliata, modelli di minaccia, materiale di valutazione riservato, dettagli sugli incidenti e altre informazioni necessarie ai revisori autorizzati. Un livello operativo privato contiene segreti, dati personali e informazioni di controllo interno che non dovrebbero essere esposti affatto. I livelli sono documenti diversi con collegamenti, non una singola pagina con un menu a fisarmonica etichettato trasparenza.

Una buona trasparenza ha un confine. Pubblica ciò che le persone devono sapere per comprendere il sistema e protegge ciò che i revisori autorizzati devono controllare.

Lo strato pubblico deve comunque essere specifico. Può dire che un modello è adattivo durante l'uso senza esporre una rappresentazione privata dello stato. Può dichiarare che una rotta è su invito senza pubblicare i token di invito. Può descrivere le modalità di output e una politica di marcatura dei contenuti senza esporre le chiavi di firma. Può affermare che esiste una valutazione del rischio e identificarne l'ambito senza pubblicare uno schema di sicurezza che renderebbe il servizio più facile da attaccare.

Lo strato controllato richiede la propria onestà. Un documento marcato come riservato non è automaticamente completo, aggiornato o corretto. Serve un proprietario, una versione, una regola di accesso e una regola di conservazione. Se un registro pubblico collega a un record controllato, il collegamento dovrebbe rivelarne lo stato e la rotta responsabile anche quando il contenuto è ristretto. Altrimenti il pubblico vede un buco nero e gli viene chiesto di chiamarlo governance.

Il versionamento è ciò che rende utile un registro

La maggior parte dei fallimenti dei registri non è drammatica. Sono piccoli atti di dimenticanza. Un nuovo modello sostituisce uno vecchio, ma la voce viene modificata sul posto. Una politica cambia, ma il paragrafo sull'uso previsto rimane. Un fornitore sposta una rotta dal test interno a una beta esterna, ma il badge di stato cambia prima che venga registrata la data di efficacia. Una distribuzione viene ritirata, ma la vecchia voce scompare, portando con sé la storia. Il presente sembra ordinato. Il passato diventa senza risposta.

Un record versionato tiene separati almeno quattro orologi. La versione del contenuto indica quali testo e campi del record sono correnti. La data di efficacia indica quando la dichiarazione si applica. La versione del modello o del pacchetto indica quale oggetto tecnico viene descritto. La data di verifica indica quando qualcuno ha controllato il record. Queste date possono coincidere. Non devono per forza. Trattarle come un'unica data è comodo e spesso sbagliato.

Le versioni precedenti dovrebbero rimanere rintracciabili secondo una regola di conservazione appropriata. Il pubblico non ha bisogno di ogni modifica interna, ma deve sapere quando è cambiata una dichiarazione materiale su scopo, stato, rotta, limitazione o proprietà. Un registro delle modifiche può dire cosa è cambiato senza esporre informazioni private. Un record leggibile dalla macchina può collegare la versione precedente e un manifest. Una pagina leggibile dall'uomo può spiegare la conseguenza in linguaggio ordinario. Le due superfici dovrebbero concordare.

Il versionamento rende significativo anche il ritiro. Se un modello viene ritirato perché una rotta è chiusa, è diverso da un richiamo perché un difetto grave o un problema legale richiede un'azione. Se un modello rimane nelle distribuzioni private esistenti, il record pubblico dovrebbe dirlo. Se un successore è compatibile solo con alcune integrazioni, il confine di migrazione dovrebbe essere visibile. Un registro che rimuove un nome senza registrare il motivo lascia che ogni lettore a valle inventi una ragione.

La cronologia delle modifiche è particolarmente importante per i sistemi adattivi. L'identità del modello può rimanere stabile mentre cambiano stati acquisiti, set di vincoli, fonti di recupero o controlli di output. Il registro può indicare quali modifiche creano un nuovo pacchetto, quali richiedono una nuova valutazione e quali restano entro il confine di identità dichiarato. Non è un dettaglio eccessivo. È la differenza tra un sistema che può essere riprodotto e un sistema che può solo essere ricordato.

I proprietari fanno parte del record

Una voce di registro dei modelli senza un proprietario è un bollettino meteorologico. Ti dice com'era il cielo e non ti lascia nessuno a cui rivolgerti quando il tetto perde. I ruoli di provider e deployer non sono la stessa cosa, e nessuno dei due ruoli dovrebbe poter essere assorbito nella parola piattaforma.

Il provider possiede l'identità del modello, la documentazione dello sviluppo e la decisione di rilascio nell'ambito delle proprie competenze. Un deployer possiede la decisione di utilizzare un sistema sotto la propria autorità, inclusi lo scopo locale, le salvaguardie, la valutazione d'impatto e i controlli operativi. Un provider a valle può integrare un modello di uso generale in un sistema di IA e assumersi responsabilità che il provider del modello non può vedere. Un registro pubblico dovrebbe rendere visibili queste relazioni laddove la legge e il rischio lo richiedono.

Le informazioni di contatto non sono un riempitivo amministrativo. Offrono a una persona interessata un canale per chiedere chi ha preso una decisione, quale versione è stata utilizzata o come richiedere una correzione. Una casella di posta generica può essere appropriata, ma deve condurre a un processo gestito. La voce dovrebbe anche indicare se il contatto è per supporto tecnico, richieste relative ai diritti, segnalazione di incidenti, approvvigionamento o responsabilità pubblica. Una sola casella di posta non può essere ogni istituzione allo stesso tempo, nonostante i migliori sforzi dei moduli moderni.

La proprietà dovrebbe includere l'autorità di modificare la voce. Se il proprietario indicato non può sospendere un percorso, correggere uno stato o pubblicare una revoca, la voce è decorativa. L'organizzazione può comunque avere un proprietario legale altrove, ma il divario operativo rimane. Un buon registro rende visibile la responsabilità prima che un incidente costringa le persone a disegnare l'organigramma su una lavagna.

Progettare un registro che le persone possano davvero leggere

Il primo lettore di un registro dei modelli non è sempre un regolatore o un ingegnere. Può essere un giornalista, un funzionario degli acquisti, un amministratore locale, un ricercatore, un dipendente a cui viene chiesto di usare il sistema, o una persona che cerca di capire perché un servizio automatizzato ha toccato il suo caso. La pagina dovrebbe rispondere alla domanda comune prima di ricorrere al vocabolario specialistico.

Inizia con l'identità e il motivo della voce. Dichiara chi fornisce il modello, quale versione viene descritta, che tipo di oggetto è e se si tratta di un modello, di un sistema di IA integrato o di una voce di distribuzione. Dichiara se è interno, disponibile per utenti invitati, sul mercato, sospeso o ritirato. Il lettore non dovrebbe dover dedurre lo stato da un pulsante di download.

Poi mostra lo scopo e i confini. Indica cosa il modello è destinato a fare, quali usi sono al di fuori della dichiarazione e quali decisioni non è autorizzato a prendere. Spiega se il modello può adattarsi durante l'uso, se è richiesto uno stato acquisito per la riproduzione e se un percorso a valle modifica le condizioni. Un elenco di capacità senza uno scopo è un menu senza cucina.

Usa la divulgazione progressiva. La parte superiore della pagina dovrebbe essere chiara e leggibile. Le sezioni più approfondite possono esporre il record macchina, i metodi di valutazione, il riepilogo dei contenuti di addestramento, i documenti legali e le prove di rilascio. Un lettore pubblico può fermarsi dopo il primo livello. Un revisore può continuare. Un ingegnere può scaricare una rappresentazione stabile. Nascondere i dettagli non è semplicità. È solo una sorpresa a caricamento lento.

L'accessibilità fa parte della credibilità del registro. La pagina e la rappresentazione macchina dovrebbero usare etichette chiare, navigazione da tastiera, intestazioni utili e alternative testuali per le visualizzazioni. Le date non dovrebbero essere codificate solo con il colore. Un badge rosso non è uno stato per un lettore che non vede il rosso, e un grafico che non può essere letto senza mouse non è una spiegazione accessibile. Una bacheca nella piazza del paese non diventa pubblica se la rampa finisce al primo gradino.

La leggibilità automatica è importante per un altro motivo. Consente ai ricercatori di confrontare le voci, agli enti pubblici di costruire inventari, ai revisori di individuare record obsoleti e a uno strumento a valle di verificare che la pagina e il record strutturato si riferiscano alla stessa versione. Leggibile dalle macchine non significa destinato solo alle macchine. La pagina per gli esseri umani e il record per le macchine dovrebbero condividere identificatori, stato, date e collegamenti, con una relazione di integrità che possa essere verificata.

I campi del registro sono decisioni

Ogni campo dice al lettore ciò che l'organizzazione ritiene meritevole di essere preservato. Un campo fornitore indica chi è responsabile del modello. Un nome e una versione del modello indicano come distinguerlo da un successore. Un campo percorso indica dove può essere raggiunto. Un campo scopo previsto indica quale lavoro il fornitore è disposto a descrivere. Un campo limitazioni indica dove si ferma la descrizione. Lo schema è un documento di governance scritto in piccoli rettangoli.

I campi di identità dovrebbero essere inequivocabili e stabili. Possono includere la ragione sociale del fornitore, il nome del modello, la versione, un riferimento univoco e collegamenti a un record canonico. Se il modello può essere servito attraverso più prodotti, il registro dovrebbe distinguere l'identità del modello dalla superficie di integrazione. Se un prodotto contiene più modelli, la voce non dovrebbe nascondere questo fatto dietro il nome del prodotto.

I campi di stato dovrebbero includere il valore, la data di decorrenza, il motivo o l'autorità per la transizione e qualsiasi successore o predecessore. Una data solo pianificata dovrebbe essere etichettata come pianificata. Un record non verificato di recente dovrebbe dichiararlo. Il lettore dovrebbe essere in grado di capire se un modello è disponibile, proposto, sospeso o storico senza interpretare un aggettivo inventato da un team di marketing.

I campi di scopo e ambito dovrebbero descrivere il lavoro in termini comprensibili a un non specialista. Dovrebbero indicare gli utenti previsti dove rilevante, i tipi di input e output coinvolti e le decisioni o azioni che il modello può supportare. Dovrebbero anche dichiarare gli usi vietati o non supportati. Un modello in grado di generare testo non è automaticamente autorizzato a scrivere una decisione di ammissibilità, e un modello in grado di classificare documenti non è automaticamente autorizzato a classificare persone.

I campi di capacità richiedono condizioni. Modalità, limiti di contesto, accesso agli strumenti, copertura linguistica, comportamento di adattamento e marcatura dell'output sono significativi solo se legati a un percorso e a una release. Una capacità che esiste in un esperimento interno ma non nel percorso esterno non dovrebbe essere presentata come una caratteristica universale. Il registro non è una lista dei desideri.

I campi relativi ai dati dovrebbero indicare cosa riceve il modello, cosa memorizza, da cosa apprende durante l'uso e cosa viene utilizzato per la valutazione, al livello che può essere reso pubblico senza esporre materiale personale o riservato. I riepiloghi dei contenuti di addestramento e le politiche sui diritti dovrebbero essere collegati dove richiesto. Una frase vaga come addestrato su dati diversificati dice quasi nulla al lettore e gli chiede di fornire un'interpretazione lusinghiera.

I campi di valutazione dovrebbero identificare la domanda, il metodo, il confine dei dati, la data, il risultato e le limitazioni. La voce non deve riprodurre ogni tabella, ma non dovrebbe mostrare un punteggio senza un denominatore o un test senza uno scopo. Un buon collegamento di valutazione consente al lettore di vedere se le prove coprono l'uso previsto, un uso simile o solo una condizione di laboratorio.

I campi di supervisione dovrebbero identificare chi può mettere in pausa, annullare, rivedere e indagare sul sistema. Se un modello si limita a raccomandare, si dovrebbe indicare quale azione rimane all'essere umano. Se un percorso può agire su sistemi esterni, si dovrebbero indicare quali autorizzazioni e barriere si applicano. Se la segnalazione degli incidenti ha un percorso dedicato, pubblicarlo. La supervisione non è un paragrafo sul mantenere gli esseri umani nel ciclo. È una mappa di chi può fare cosa quando il sistema è incerto.

I campi relativi alle prove e all'integrità dovrebbero collegare la voce pubblica a un record macchina con versione, a un pacchetto di rilascio, a una dichiarazione, a un pacchetto di valutazione o a un registro di trasparenza. Un hash può stabilire che un file è cambiato o non è cambiato. Non può stabilire che il file fosse veritiero, quindi il registro dovrebbe tenere separati la dichiarazione e il controllo di integrità. La precisione tecnica non sostituisce il giudizio, ma rende più facile individuarlo.

Infine, i campi relativi alle modifiche dovrebbero spiegare la storia. Cosa è cambiato, quando, perché, chi lo ha approvato, quali percorsi sono interessati e se è necessaria una nuova valutazione. La voce dovrebbe rendere possibile rispondere alla domanda più ordinaria nella stanza: cosa è diverso rispetto al record che abbiamo letto il mese scorso?

Cosa può stabilire un registro

Un registro ben mantenuto può stabilire che un oggetto definito è descritto da un fornitore nominato in una particolare versione del record. Può stabilire lo scopo dichiarato, lo stato, il percorso di accesso e la titolarità. Può stabilire quali documenti di supporto e record di integrità un lettore può consultare e quali informazioni sono deliberatamente controllate. Può stabilire che una modifica è stata pubblicata e che un record precedente rimane disponibile secondo la regola di conservazione dichiarata.

Può anche stabilire la posizione dell'organizzazione stessa. Se un fornitore afferma che un modello è per il supporto alle decisioni e non per il rifiuto automatico, la dichiarazione è un confine pubblico. Se un deployer afferma che una valutazione d'impatto è stata completata, la dichiarazione solleva una domanda su dove si possa trovare il riepilogo o il record controllato. Se un fornitore contrassegna un rilascio come pianificato, l'etichetta impedisce che il piano si spacci per storia.

Questi sono fatti utili. Rendono l'approvvigionamento più preciso, l'integrazione meno speculativa e le domande pubbliche più facili da instradare. Rendono anche il disaccordo più netto. Un lettore può dire che lo scopo dichiarato è troppo ampio, che lo stato è obsoleto, che la limitazione manca o che le prove di supporto non coprono la dichiarazione. Un registro guadagna il suo posto quando rende possibile quella critica.

Cosa non può stabilire un registro

Una voce di registro non può stabilire che un modello sia accurato per ogni utente, sicuro in ogni ambiente, equo per ogni gruppo o legale per ogni implementazione. Non può stabilire che un'autorità pubblica abbia seguito la procedura corretta semplicemente perché un sistema è elencato. Non può dimostrare che un revisore umano abbia compreso un output, che un interessato abbia avuto un rimedio significativo o che un incidente sarebbe stato rilevato in tempo. Queste conclusioni richiedono prove sul sistema in uso, sull'istituzione che lo utilizza e sulle persone che ne sono interessate.

Non può nemmeno stabilire che un modello sia indipendente dal suo fornitore, che un percorso sia sovrano perché è ospitato in Europa o che una licenza aperta faccia sparire la responsabilità. Titolarità, giurisdizione, catena di fornitura, controllo operativo e manutenzione sono questioni separate. Un registro può esporre i nomi e i collegamenti necessari per porre queste domande. Non può rispondere con la tipografia.

Un registro non può nemmeno dimostrare il negativo. Una voce assente può significare che l'oggetto è fuori ambito, che si applica un'esclusione, che la pubblicazione è in ritardo o che qualcuno non ha pubblicato. Il lettore ha bisogno di una dichiarazione chiara di copertura e di un percorso per segnalare errori. Un albo pubblico è affidabile solo quanto il processo che si accorge quando un avviso manca.

Un record illustrativo, non un caso di studio nascosto

Quello che segue è un progetto di record illustrativo, non un resoconto di un'organizzazione, un modello o un evento reale. Non utilizza alcun cliente, autorità pubblica, data di implementazione o risultato misurato. Il suo scopo è mostrare come un lettore possa passare da una voce pubblica a un percorso di prove controllato senza confondere i due livelli.

  • Identità: un nome del fornitore, un nome del modello, una versione e un identificatore macchina stabile.
  • Stato: valutazione controllata, con una data di efficacia e una nota che nessun percorso esterno è aperto.
  • Scopo: assistenza nell'analisi dei documenti per il personale formato, con decisioni esterne automatiche al di fuori dell'ambito dichiarato.
  • Input e output: le modalità rappresentate, i tipi di materiale sorgente previsti e i tipi di output che il percorso può produrre.
  • Limiti: confini noti di lingua, dominio, aggiornamento, sicurezza e accesso, ciascuno collegato alla valutazione o alla policy pertinente.
  • Supervisione: il ruolo che può sospendere il percorso, il percorso di revisione per i risultati incerti e il contatto per gli incidenti.
  • Evidenze: un riepilogo pubblico, una registrazione tecnica versionata per i revisori autorizzati e un manifest di integrità per i file pubblicati.
  • Modifiche: un collegamento alla registrazione precedente, una dichiarazione di ciò che è cambiato e la condizione che richiederebbe una nuova valutazione.

Nulla in quella registrazione dice che il modello è buono. Dice ciò che il fornitore è disposto a dichiarare, dove si applica la dichiarazione e come un'altra persona può verificarla o contestarla. Questo è sufficiente per un albo. È anche sufficiente per impedire che gran parte del linguaggio da brochure si insinui inosservato in una decisione legale o operativa.

Perché lo stato di pre-rilascio merita rispetto

Il pre-rilascio non è una versione più debole del pubblico. È uno stato diverso. I test interni possono supportare il lavoro di ingegneria e sicurezza mantenendo l'accesso controllato. Una beta su invito può esporre un percorso a soggetti esterni preservando condizioni, ambito e diritto di interruzione. Un rilascio pubblico cambia chi può fare affidamento sul sistema e quali obblighi ricadono su fornitore, integratori e distributori. Il registro dovrebbe rendere visibili queste transizioni invece di trattare il rilascio come un'unica nota di tromba.

Una registrazione di pre-rilascio può comunque essere utile al pubblico. Può identificare il modello, il fornitore, il percorso previsto, lo stato, le evidenze esistenti e quelle ancora in sospeso. Può dire che una data è pianificata e che l'accesso non è stato aperto. Può pubblicare il gate di rilascio senza fingere che il gate sia stato superato. Questo è un posto particolarmente adatto perché un registro sia noioso. Uno stato noioso è più sicuro di un'ambiguità eccitante.

In Dweve, cerchiamo di applicare questa disciplina alla nostra registrazione pubblica. Nel nostro Trust Centre, il registro dei modelli è contrassegnato come pre-rilascio ed elenca Dweve Loom 1.0 come test di pre-rilascio solo interno a partire dal 1 agosto 2026. Registra che nessun rilascio esterno è avvenuto entro quella data ed elenca il 1 settembre 2026 come data pianificata per l'accesso al mercato dell'Unione per una beta esterna su invito. Pianificata è la parola importante: la voce non trasforma un piano in un evento.

La nostra registrazione pubblica chiarisce inoltre che Loom è l'unico modello elencato lì, che è proprietario e non rilasciato con una licenza di modello open source, e che i nostri prodotti e gli strumenti open source con licenza separata non sono presentati come modelli aggiuntivi. Questo confine impedisce che un catalogo di prodotti venga scambiato per un registro di modelli. Mantiene inoltre la dichiarazione pubblica abbastanza ridotta da poter essere verificata.

Questo è tutto ciò che dobbiamo dire su Dweve qui. Un registro dei modelli è utile quando rende il nostro stato di rilascio meno lusinghiero ma più preciso. Dovrebbe fare lo stesso per chiunque altro.

Il confine pubblico-privato è una decisione di progettazione

Il registro più solido non è quello con il maggior numero di campi. È quello i cui campi hanno una ragione, un proprietario e un confine. I lettori pubblici hanno bisogno di un'identità stabile, di uno scopo dichiarato, di uno stato veritiero, di un'organizzazione responsabile, di collegamenti utilizzabili e di limitazioni sufficienti a comprendere l'affermazione. I revisori autorizzati hanno bisogno di prove più approfondite, di dettagli tecnici controllati e di una via per esaminare incidenti o test sensibili. Gli operatori hanno bisogno di segreti, permessi e runbook che non dovrebbero affatto stare sulla bacheca.

Questi livelli dovrebbero concordare sui fatti che attraversano il confine. Se la pagina pubblica dice che una rotta è in pausa, il record controllato dovrebbe dire chi l'ha messa in pausa e perché. Se un file tecnico è stato sostituito, la voce pubblica non dovrebbe continuare a collegarlo come corrente. Se una valutazione è riservata, la pagina pubblica dovrebbe comunque dichiararne ambito e stato. Il confine dovrebbe limitare l'accesso ai dettagli, non creare tre versioni incompatibili della realtà.

I lettori dovrebbero poter porre cinque semplici domande e ricevere cinque risposte stabili. Che cos'è questo oggetto? Chi ne è responsabile? Che cosa può fare? Qual è il suo stato attuale? Quali prove e rimedi esistono quando l'affermazione viene contestata? Un registro che risponde a queste domande sta già facendo un lavoro istituzionale. Un registro che non sa rispondere non dovrebbe essere salvato da badge animati o da una dashboard con dodici filtri.

C'è un modo ottimistico di leggere il movimento europeo verso i registri di modelli e algoritmi. Non è che un database risolverà la governance dell'IA. È che le istituzioni pubbliche stanno costruendo luoghi in cui le affermazioni hanno nomi, date, proprietari e confini. Sono questi i piccoli componenti da cui si costruiscono i sistemi di responsabilità più ampi.

La bacheca deve sopravvivere al cambiamento

Un registro di modelli è la nuova bacheca pubblica solo se gli avvisi restano leggibili dopo che il tempo cambia. La pagina deve sopravvivere a un aggiornamento del modello, a un cambio di fornitore, a una nuova implementazione, a una limitazione corretta, a una rotta ritirata e a una domanda difficile da parte di chi non era nella stanza. Questo significa conservare la cronologia, etichettare i piani, collegare le prove e dire ciò che il record non può dimostrare.

Il lavoro è meno appariscente di una pagina di lancio. È anche più duraturo. Un record pubblico che distingue l'identità del modello dallo stato di implementazione, lo stato dall'intenzione, la documentazione dalla prova e i fatti pubblici dalle prove controllate offre alle persone qualcosa di meglio della rassicurazione. Offre loro una via attraverso il sistema.

I buoni registri non chiedono ai lettori di fidarsi di un colore, di un numero o di un nome famoso. Rendono l'affermazione abbastanza circoscritta da poterla esaminare e il confine abbastanza chiaro da poterlo contestare. Lasciano una traccia verso le persone che possono rispondere, i record che possono essere verificati e la decisione che può essere cambiata. È un'idea civica molto antica, che indossa un formato di file ragionevolmente moderno.

Metti l'avviso sulla bacheca. Metti le prove dietro di esso. Conserva il vecchio avviso dove qualcuno possa ancora leggerlo. Poi lascia che il pubblico decida cosa merita il record.

Fonti