Auditoria documentale del catalogo di modelli aperti di Ai2: stato delle evidenze sulle licenze

Introduzione: l'importanza della tracciabilita' legale nei modelli aperti

Nello sviluppo di sistemi di intelligenza artificiale, la distinzione tra la disponibilita' tecnica di un modello e la sua fattibilita' legale per l'uso in produzione e' critica. Per le organizzazioni che valutano modelli aperti, la licenza del codice sorgente non e' l'unico fattore determinante; le condizioni in cui vengono distribuiti i pesi del modello e, fondamentalmente, i dati di addestramento, possono imporre restrizioni significative sull'uso commerciale o sulla ridistribuzione.

Il caso di Ai2 e' particolarmente rilevante data la sua enfasi dichiarata sull''apertura totale', che include la pubblicazione di codice, dati e pesi. Tuttavia, la verifica di queste affermazioni richiede un esame dettagliato delle fonti primarie vigenti. Questo articolo analizza quali informazioni sono attualmente verificabili attraverso la documentazione ufficiale e i repository pubblici, identificando le aree in cui l'evidenza e' insufficiente per emettere un parere legale definitivo.

La tracciabilità legale non coincide con il semplice fatto che un artefatto sia accessibile o scaricabile. Per valutare se un modello possa essere impiegato in produzione, occorre poter collegare ogni componente rilevante alle condizioni che ne regolano l’uso: il codice, i pesi e i dati possono avere percorsi di pubblicazione e termini differenti. Perciò l’etichetta «aperto», pur descrivendo un orientamento alla pubblicazione, non basta da sola a stabilire quali permessi siano concessi a chi riutilizza ciascun elemento.

Questa distinzione è importante anche quando l’obiettivo è soltanto preparare una valutazione preliminare. Un’organizzazione può constatare che un modello esiste e che parte del codice è pubblicamente disponibile, ma non dovrebbe trasformare tali constatazioni in una conclusione generale sulla libertà di uso o ridistribuzione dell’intero sistema. La conclusione deve restare proporzionata alle prove: se le fonti documentano soltanto un componente, la verifica riguarda quel componente, mentre gli altri restano da chiarire.

La cautela non equivale a sostenere che pesi o dati siano soggetti a un divieto. Come indicato nell’ambito della verifica, la mancanza di una licenza esplicita negli estratti consultati lascia una questione aperta; non dimostra né l’esistenza di una restrizione né l’assenza di condizioni. Tenere separate queste possibilità evita che un’incertezza documentale venga presentata come un impedimento accertato oppure, all’opposto, come un’autorizzazione implicita.

Metodologia di verifica documentale

Per auditare il catalogo di modelli di un'organizzazione, si stabiliscono tre livelli di verifica: il codice di addestramento e inferenza, i pesi del modello (model weights) e i set di dati di addestramento. Ciascuno di questi artefatti puo' essere soggetto a licenze distinte. La metodologia consiste nel localizzare i repository ufficiali e i portali di documentazione, ed estrarre le dichiarazioni di licenza vigenti al momento della consultazione.

Nel caso di Ai2, la documentazione ufficiale per sviluppatori funge da porta d'ingresso all'ecosistema. Questa fonte conferma l'esistenza di modelli come OLMo, Molmo e Tulu, cosi' come di set di dati come Dolma e Pixmo. Il profilo dell'organizzazione su GitHub consente di localizzare i repository di codice associati. La verifica si concentra sull'identificare se queste fonti primarie contengono dichiarazioni esplicite sui permessi di uso, distribuzione e modifica.

I tre livelli dell’audit rispondono a domande diverse e vanno registrati separatamente. Per il codice si cerca il documento che disciplina il software; per i pesi si verifica la dichiarazione riferita ai file del modello; per i dati si esamina la documentazione del set e le eventuali condizioni d’uso indicate per quel materiale. Una risposta positiva per uno di questi livelli non chiude automaticamente le verifiche sugli altri due, anche se i componenti appartengono allo stesso progetto o sono descritti insieme nella documentazione.

La raccolta delle prove deve conservare il legame tra la dichiarazione e l’artefatto cui si riferisce. Un file LICENSE in un repository di codice può documentare la licenza di quel repository, ma non basta, senza un’indicazione applicabile, a stabilire i termini di una distribuzione separata di pesi o dati. Allo stesso modo, una pagina generale che presenta risorse e obiettivi di apertura può orientare la ricerca, ma non sostituisce una dichiarazione specifica quando l’audit deve determinare permessi giuridici concreti.

Per rendere ripetibile la verifica, è utile registrare che cosa è stato consultato e che cosa non è stato trovato, senza colmare le lacune con supposizioni. La data della consultazione e l’identificazione del repository o della documentazione esaminata aiutano a descrivere con precisione lo stato delle evidenze al momento dell’analisi. Se in seguito emerge una dichiarazione più specifica, il controllo può essere aggiornato mantenendo distinta la nuova evidenza da ciò che era disponibile in precedenza.

La classificazione «non verificato» ha quindi una funzione operativa: segnala che le fonti esaminate non consentono ancora di attestare i termini dell’artefatto, non che l’artefatto sia necessariamente inutilizzabile. Conservare questa distinzione permette ai gruppi tecnici e legali di individuare quali passaggi documentali mancano prima di prendere una decisione, senza sovrastimare ciò che il controllo ha effettivamente dimostrato.

Stato delle evidenze nelle fonti primarie

La revisione della documentazione ufficiale di Ai2 conferma la politica istituzionale di 'apertura totale', che promette la liberazione di codice, dati, pesi e ricette di addestramento. Questa dichiarazione e' un fatto verificabile nel portale per sviluppatori. Tuttavia, il testo della documentazione generale non specifica le licenze giuridiche esatte che governano ciascuno di questi componenti.

Nel profilo GitHub dell'organizzazione, si osserva che diversi repository di codice, come 'Olmo-core', 'open-instruct' e 'olmo-eval', sono sotto la licenza Apache-2.0. Questo consente di verificare la licenza del codice di addestramento e inferenza per questi strumenti. Tuttavia, la licenza del codice non si estende automaticamente ai pesi del modello ne' ai dati di addestramento, che sono spesso distribuiti attraverso piattaforme esterne o in repository specifici con termini propri.

La dichiarazione istituzionale di apertura e l’indicazione di una licenza sono evidenze di natura diversa. La prima descrive l’impegno a pubblicare componenti e ricette; la seconda definisce, per l’oggetto a cui si applica, le condizioni di utilizzo e distribuzione. È dunque possibile verificare l’esistenza della politica dichiarata senza poter ricavare da essa, da sola, una licenza precisa per ogni singolo file o raccolta.

Per i repository citati, l’indicazione Apache-2.0 permette di descrivere la licenza del codice presente in quei repository, entro i limiti di quanto effettivamente coperto dalla dichiarazione. Non autorizza a estendere automaticamente la stessa conclusione ai pesi o ai dati nominati nella documentazione. Il fatto che codice, pesi e dati siano associati allo stesso modello non dimostra che siano distribuiti sotto un’unica licenza; occorre una prova che colleghi espressamente i termini a ciascun artefatto.

La tabella riassume perciò stati probatori differenti, non un giudizio complessivo sulla liceità del catalogo. «Verificata» indica che, per il codice menzionato, è stata rilevata una licenza identificabile nelle fonti considerate. «Non verificata» indica invece che negli estratti consultati non compare una dichiarazione sufficiente per i pesi o per i dati. Queste etichette non sostituiscono una valutazione legale e non permettono, da sole, di concludere che l’uso commerciale sia autorizzato o vietato.

La stessa precisione vale per la descrizione dell’ecosistema: la presenza di OLMo, Molmo, Tülu, Dolma e Pixmo nelle risorse ufficiali attesta che tali elementi sono presentati nel catalogo, ma non risponde automaticamente alla domanda sui termini applicabili ai rispettivi artefatti. Per ogni voce, l’audit deve mantenere distinta la prova dell’esistenza dalla prova delle condizioni d’uso, evitando di trattare una lista di risorse come se fosse una dichiarazione contrattuale completa.

Analisi delle lacune nella documentazione

Una delle principali limitazioni nell'auditare il catalogo di Ai2 con le fonti attuali e' la mancanza di una dichiarazione centralizzata ed esplicita sulle licenze dei pesi e dei dati. La documentazione descrive la natura 'aperta' delle risorse, ma non dettaglia i termini legali specifici, come se sia consentito l'uso commerciale senza restrizioni aggiuntive o se esistano clausole di attribuzione obbligatoria.

Questa lacuna e' critica per i team di compliance legale. La licenza Apache-2.0 del codice garantisce la liberta' d'uso del software di addestramento, ma non risolve la questione dei dati di Dolma (3 trilioni di token) ne' dei pesi di OLMo. Senza una dichiarazione chiara nella documentazione primaria, non e' possibile affermare con certezza che l'uso commerciale sia privo di restrizioni derivanti dalla provenienza dei dati o dai termini della piattaforma di distribuzione.

La mancanza di una dichiarazione centralizzata rende più difficile ottenere una vista d’insieme, ma il punto decisivo resta l’applicabilità della documentazione a ciascun oggetto. Un riferimento generico all’apertura può non chiarire se una determinata versione dei pesi o dei dati sia soggetta a condizioni specifiche. Per questo, una verifica puntuale dovrebbe seguire il percorso di distribuzione dell’artefatto e confrontare i metadati e i documenti associati, senza presumere che le condizioni siano identiche tra risorse diverse.

Anche la questione dell’uso commerciale va formulata con cautela. Gli estratti descritti non consentono di confermare né che tale uso sia privo di condizioni né che sia vietato per pesi o dati. È necessario distinguere una licenza che stabilisce permessi da una descrizione generale del progetto; se i termini non sono reperibili nella documentazione esaminata, la conclusione corretta è che il punto rimane da verificare, non che l’assenza di una clausola equivalga a un’autorizzazione senza limiti.

Il riferimento ai 3 trilioni di token di Dolma descrive la dimensione indicata per il corpus, ma non chiarisce la licenza dei dati né i diritti associati alla loro provenienza. La quantità di materiale e la sua disponibilità documentale sono questioni diverse dalle condizioni di riutilizzo. Analogamente, la licenza Apache-2.0 individuata per il codice risponde alla domanda relativa a quel software, ma non risolve da sola i dubbi riguardanti i dati impiegati nell’addestramento o i pesi risultanti.

Nel caso illustrativo dell’adozione di OLMo, la decisione non dovrebbe dipendere da un’inferenza ricavata soltanto dalla licenza del codice. Il passaggio successivo consiste nel verificare i termini riferiti ai pesi e la documentazione applicabile a Dolma, mantenendo esplicita la distinzione tra ciò che è stato accertato e ciò che è ancora incerto. L’ipotesi che i termini dei dati possano incidere sull’adozione mostra perché la verifica è rilevante, ma non dimostra che tale restrizione esista effettivamente.

Limiti delle evidenze e domande aperte

La verifica effettuata con le fonti fornite consente di confermare l'esistenza dei modelli e la licenza del codice di addestramento, ma non risolve le domande sulle licenze dei pesi e dei dati. La documentazione ufficiale funge da indice di risorse, ma non da contratto legale dettagliato per ciascun artefatto.

Rimangono aperte le seguenti domande: Qual e' la licenza esatta dei pesi di OLMo e Molmo? Sotto quali termini vengono distribuiti i dati di Dolma e Pixmo? Esiste una documentazione ufficiale che chiarisca il rapporto giuridico tra la licenza del codice e quella dei dati? Finche' queste domande non saranno risposte con fonti primarie specifiche (come file LICENSE nei repository dei pesi o documentazione dei dati), la tracciabilita' legale del catalogo di Ai2 rimane incompleta.

Le domande aperte possono essere trasformate in una lista di verifiche circoscritte: individuare la licenza espressamente riferita ai pesi di OLMo e Molmo; controllare i termini associati a Dolma e Pixmo; stabilire se esista una dichiarazione primaria che spieghi il rapporto tra la licenza del codice e quella dei dati. Finché non si trovano documenti applicabili a queste specifiche risorse, è più preciso descrivere la tracciabilità come incompleta sui punti indicati, anziché estendere il risultato anche alle componenti per cui una licenza è stata verificata.

La ricerca dei documenti mancanti dovrebbe mantenere la stessa separazione usata nella prima fase. Per i pesi, vanno esaminati i metadati e i termini della risorsa nella piattaforma di distribuzione, oltre alla documentazione specifica del modello; per i dati, vanno consultati i documenti del relativo repository. Se una pagina rinvia a un’altra fonte, occorre verificare che il riferimento identifichi effettivamente l’artefatto e la versione pertinenti, invece di assumere che qualsiasi condizione generale valga per tutti i contenuti.

Una decisione di conformità può quindi essere accompagnata da un registro essenziale delle evidenze: componente controllato, fonte primaria consultata, dichiarazione di licenza trovata o assente e punto che resta da chiarire. Questo formato non anticipa il parere legale, ma rende leggibile la base documentale della decisione e impedisce che la licenza del codice venga riportata, per errore, come licenza dell’intero modello. In presenza di lacune, la classificazione deve restare provvisoria fino a quando non sia disponibile una fonte primaria sufficientemente specifica.

L’esito dell’audit va aggiornato quando le fonti applicabili cambiano o quando si reperisce documentazione più precisa. La conclusione qui sostenibile rimane limitata: la licenza del codice citato è identificabile, mentre gli estratti esaminati non bastano a determinare i termini dei pesi e dei dati. Mantenere questa formulazione esplicita tutela sia la precisione dell’analisi sia la distinzione fondamentale tra evidenza disponibile, questione irrisolta e restrizione effettivamente dimostrata.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.