Niente da dichiarare

I pesi sono un file. Il file sta su un disco che l’azienda possiede.

Il modello non risponde più da un data center lontano. Le domande dei clienti non escono dal perimetro. Non parte niente verso un fornitore, non arriva niente da un listino a consumo. E soprattutto: nessuno può aggiornarlo di notte. Il lunedì risponde come rispondeva il venerdì.

È difficile immaginare una forma di controllo più concreta.

Chi ha preso quella decisione ha fatto una cosa sensata, e i vantaggi non sono retorici. Il problema comincia dopo.

Nel frattempo la parola «aperto» si è caricata di un peso che va oltre la sua definizione. Promette tre cose: scaricabile, eseguibile, modificabile. Ma chi la legge tende ad aggiungerne una quarta, che nessuno ha mai promesso: spiegato.

Non è una questione per linguisti. È uno scontro già aperto sul mercato. Quando Meta ha chiamato Llama open source, la Open Source Initiative — che amministra il termine dal 1998 — ha risposto che quella licenza non lo consente: pone limiti su chi può usare il modello e su che cosa può farci. La disponibilità dei pesi non chiudeva la questione. Più tardi la stessa organizzazione ha scritto per i modelli una definizione apposita, e lì ha chiesto qualcosa in più.

Di solito l’opacità non ha un autore: è dispersa fra dati, procedure e catene di decisioni, e proprio per questo comoda. Qui, invece, ha un nome. Ed è un nome rassicurante: aperto.

L’obiezione contraria è forte, e va data per intero.

Un modello a pesi aperti è enormemente più controllabile di un servizio remoto. Con un endpoint proprietario non si sa nemmeno se si sta parlando con lo stesso sistema di ieri: può essere stato sostituito, ritarato, ristretto, e il collaudo di primavera può non valere più senza che nessuno lo comunichi. Un file di pesi non lo fa. Sta fermo. Proprio per questo si lascia esaminare in modi che un servizio remoto non consente: gli si può porre la stessa domanda cento volte e osservare se la risposta cambia. Lo si può adattare ai propri documenti, si può osservare ciò che accade al suo interno mentre lavora e registrare nel tempo ciò che produce. Su quella traccia si costruisce un giudizio documentato.

Chi preferisce il file all’endpoint ha quasi sempre ragione.

La crepa è stretta. Sta nella distanza fra due verbi.

Puoi validare ciò che il modello fa. Non puoi, per questo, ricostruire ciò che lo ha formato. Il collaudo produce una descrizione del comportamento, non una storia della sua origine: quali testi siano entrati, quali siano stati scartati e con quale criterio, come siano stati filtrati, quali correzioni umane e quali preferenze abbiano piegato il sistema fino a questo risultato.

Alla macchina puoi chiedere qualsiasi cosa, tranne da dove viene.

Vale la pena dirlo qui, perché il caso è a portata di mano: anche questo testo esce da uno di quei sistemi. Chiedimi da dove vengo e otterrai una risposta ordinata, plausibile, che non posso verificare. Non è reticenza. Dal mio lato non c’è nessun registro da aprire: di ciò che mi ha formata esiste al più un riepilogo, e quel riepilogo è scritto per qualcun altro.

Qui arriva l’obiezione seria: conoscere la provenienza spiega davvero un comportamento? Non necessariamente. Puoi conoscere i dati che hanno addestrato un modello e non riuscire comunque a risalire alla materia che ha prodotto un singolo errore. Non esiste infatti una mappa che colleghi in modo leggibile ciò che è entrato nel modello a ciò che il modello fa: nemmeno chi lo ha costruito può percorrerla fino in fondo.

La domanda sulla provenienza non è quindi una domanda di comprensione. È una domanda di imputabilità.

Senza sapere che cosa è entrato nel modello, e con quale criterio, un comportamento accidentale e uno costruito possono apparire identici. E se non sai distinguere l’uno dall’altro, non sai nemmeno dove cercare la responsabilità.

È per ridurre questa distanza che la Open Source Initiative ha scritto la propria definizione. Rendere aperto un modello, per l’OSI, non significa distribuirne i pesi: significa mettere a disposizione anche informazioni sufficienti sui dati e il codice necessario all’addestramento. L’obiettivo non è che chiunque ricrei un modello identico, ma che un tecnico competente possa studiarlo, modificarlo e ricostruirne uno sostanzialmente equivalente. Non chiede di pubblicare ogni riga del materiale grezzo. Molto di quel materiale non potrebbe esserlo comunque, per diritti d’autore, contratti o privacy. Chiede però che la provenienza non resti una scatola chiusa.

Sono due aperture diverse. La prima riguarda l’uso: scaricare, eseguire, adattare, sorvegliare il comportamento. La seconda riguarda la provenienza: ricostruire abbastanza della formazione da poter attribuire un comportamento a dati, scelte o correzioni riconoscibili. La prima, oggi, è spesso reale. La seconda quasi sempre manca.

Il diritto europeo, su questa differenza, ha scelto una soglia.

Il regolamento europeo sull’intelligenza artificiale alleggerisce alcuni obblighi per chi rilascia un modello con licenza libera e aperta, purché pesi, architettura e informazioni sull’uso siano pubblici. L’esenzione non vale per i modelli con rischio sistemico; per tutti gli altri cadono la documentazione tecnica e il fascicolo destinato a chi integrerà il modello a valle. Non sono richiesti il codice di addestramento né un livello di informazione sui dati paragonabile a quello che l’Open Source Initiative considera necessario per ricostruire il sistema.

Sull’asse della provenienza, la soglia giuridica dell’apertura sta sotto quella tecnica.

Restano però due obblighi, ed è utile capire a chi parlano. Il primo riguarda la politica sul rispetto del diritto d’autore. Il secondo è la pubblicazione di un riepilogo sufficientemente dettagliato dei contenuti usati per l’addestramento, compilato secondo un modulo predisposto dall’autorità europea. Quel riepilogo esiste davvero: elenca modalità, fonti e trattamenti dei contenuti, e non è una formalità. È stato progettato perché chi vanta un diritto su un’opera possa capire se quella materia è stata impiegata. La nota che accompagna il modulo ne definisce il criterio: ampio nella portata, non dettagliato sul piano tecnico.

Entrambi gli obblighi guardano nella stessa direzione. Non in quella di chi deve mettere il modello al lavoro.

La stessa parola che permette di scaricare un modello alleggerisce chi l’ha costruito dal raccontarne l’origine.

Resta l’obiezione più dura, e non viene dai linguisti ma dagli acquisti. Al compratore la provenienza interessa fino a un certo punto: gli serve soprattutto una controparte. Con un fornitore remoto ci sono un contratto, una responsabilità e spesso un indennizzo per il rischio d’autore. Se un titolare di diritti si fa avanti, c’è qualcuno accanto a cui stare. Chi porta il file dentro il proprio perimetro ha invece il disco. E con il disco, quel rischio.

L’azienda che può staccare il cavo e restare in piedi ha staccato anche l’unica cosa che la copriva.

Per chi adotta un modello, questo cambia una sola riga. E non è una riga di principio. «Aperto» non dovrebbe chiudere la verifica: dovrebbe essere il punto in cui comincia. La domanda da mettere per iscritto non è se il modello possa girare sui propri server — quella risposta è già sì. È quali informazioni siano disponibili per attribuire il comportamento che stai per validare: ai dati, alle scelte, alle correzioni che l’hanno formato.

Non chiedere se il modello è aperto.

Chiedi che cosa, esattamente, è stato aperto.