Aprire il modello non basta. Bisogna rendere verificabile il sistema.
Ho iniziato a costruire la mia professionalità nell’informatica in un periodo in cui Internet non era ancora un insieme di piattaforme sulle quali trascorrere il tempo, ma un’infrastruttura da esplorare, comprendere e contribuire a costruire.
Per imparare non esistevano videocorsi venduti con un conto alla rovescia perenne, influencer tecnologici o assistenti artificiali pronti a rispondere con grande sicurezza anche quando non avevano idea di cosa stessero parlando. Esistevano documentazione tecnica, mailing list, newsgroup, FAQ, repository e persone che condividevano gratuitamente ciò che avevano scoperto.
Essendo in larga parte autodidatta, quella conoscenza condivisa non ha semplicemente ampliato le mie competenze: ha contribuito a definire il mio ruolo professionale.
Per questo, negli anni, ho cercato a mia volta di restituire qualcosa. Ho scritto guide su Internet e sulla realtà virtuale quando entrambe sembravano ancora territori da esploratori; ho curato FAQ dedicate a Linux; ho contribuito a progetti open source e svolto attività giornalistica e divulgativa in ambito informatico. Per qualche anno sono stato anche ciò che allora veniva definito, senza particolare senso del pudore, un “evangelista” dell’open source.
Raccontarlo oggi genera una certa nostalgia. Non tanto per i modem rumorosi, le configurazioni compilate a mano o le notti trascorse a capire perché un driver si rifiutasse di collaborare. Alcuni traumi tecnologici non meritano alcuna rivalutazione romantica. La nostalgia riguarda soprattutto l’idea che la conoscenza tecnica potesse essere un bene comune: qualcosa che ciascuno riceveva, migliorava e rimetteva in circolazione.
Quell’idea non era soltanto generosa. Era uno dei meccanismi che rendevano possibile l’innovazione.
Il percorso che propongo parte da un Internet aperta sulla quale mi sono formato, passa per gli algoritmi chiusi delle grandi piattaforme e arriva agli attuali modelli open weight. Da lì proverò a spostare la domanda: non soltanto quanto sia aperto un modello, ma quanto sia verificabile il sistema costruito intorno ad esso. Userò l’intelligenza artificiale nella scuola e il framework L×M×C come caso concreto, per arrivare infine a una proposta più generale di governance open source dei sistemi di IA
Una rete aperta, governata da algoritmi chiusi
Internet si è sviluppata grazie a protocolli pubblici, standard interoperabili, software aperto e comunità distribuite. Nessun soggetto doveva chiedere il permesso a un proprietario centrale per sviluppare un nuovo servizio basato su HTTP, TCP/IP, SMTP o DNS: non solo il protocollo era pubblico, ma lo era lo stesso software che si poteva usare per implementarlo.
L’apertura non eliminava conflitti, interessi economici o posizioni dominanti. Evitava però che un’unica organizzazione potesse decidere unilateralmente come dovesse evolvere l’intera rete.
Con l’affermazione delle grandi piattaforme social è avvenuto qualcosa di diverso. Le fondamenta tecniche della rete sono rimaste in larga parte aperte, mentre i sistemi che decidevano che cosa mostrare alle persone, quali contenuti amplificare, quali relazioni suggerire e quali comportamenti premiare sono diventati proprietari, opachi e continuamente modificabili.
È nata così una contraddizione che ancora caratterizza l’ecosistema digitale: una rete costruita su protocolli aperti è stata progressivamente governata da sistemi decisionali chiusi.
Questi sistemi non si limitavano a organizzare informazioni. Selezionavano l’ambiente cognitivo e sociale nel quale milioni di persone trascorrevano una parte crescente della propria giornata.
La vicenda Cambridge Analytica ha reso visibile al grande pubblico una parte del problema. Non fu semplicemente una conseguenza del codice proprietario, ma mostrò che dati personali, sistemi di profilazione, architetture pubblicitarie e logiche opache delle piattaforme potevano essere combinati per influenzare processi politici e sociali su larga scala.
Negli anni successivi sono emerse evidenze sempre più consistenti sui danni che determinate modalità d’uso e caratteristiche dei social media possono produrre sui più giovani. Il Surgeon General statunitense ha richiamato dati secondo cui gli adolescenti che trascorrono più di tre ore al giorno sui social presentano circa il doppio del rischio di problemi di salute mentale, mentre studi più recenti indicano effetti particolarmente rilevanti su ansia, depressione e benessere psicologico, soprattutto fra le ragazze.
Il problema ha ormai superato anche i confini della ricerca scientifica. Nel 2026 giurie statunitensi hanno condannato Meta e Google/YouTube in procedimenti riguardanti la tutela dei minori, arrivando a riconoscere responsabilità legate anche a caratteristiche progettuali come *infinite scroll*, autoplay, notifiche e sistemi algoritmici di raccomandazione.
Abbiamo quindi già visto cosa può accadere quando sistemi algoritmici opachi vengono ottimizzati per massimizzare l’engagement di milioni di ragazzi. Con l’intelligenza artificiale, ancora più pervasiva e capace di interagire direttamente con loro, sarebbe poco saggio ripetere lo stesso esperimento.
Anche il legislatore europeo ha iniziato a intervenire non soltanto sui contenuti, ma sulle architetture. Il Digital Services Act richiede alle piattaforme accessibili ai minori di adottare misure per proteggerne benessere, privacy e sicurezza; vieta inoltre la pubblicità mirata ai bambini. Nel luglio 2025 la Commissione europea ha pubblicato linee guida specifiche sulla protezione dei minori, comprendendo fra gli ambiti di intervento anche i sistemi di raccomandazione e le caratteristiche di progettazione delle piattaforme.
Il punto non è sostenere che un algoritmo chiuso sia necessariamente dannoso e uno aperto sia automaticamente etico. Sarebbe una tesi rassicurante, semplice… ma falsa.
Il punto è che per anni abbiamo consentito a sistemi progettati per massimizzare attenzione, permanenza e interazione di incidere sul comportamento dei minori senza rendere pubblicamente verificabile quale beneficio producessero, quali rischi incorporassero e quali metriche guidassero davvero la loro evoluzione.
Con il machine learning il codice non basta più
Nel software tradizionale il codice sorgente costituisce una descrizione relativamente diretta del comportamento del programma. Non necessariamente semplice, naturalmente: chiunque abbia cercato di comprendere un progetto legacy sa che il codice può essere tecnicamente aperto ma allo stesso tempo… metafisicamente impenetrabile.
Ciò non toglie che le istruzioni che determinano il funzionamento sono comunque disponibili.
Con il machine learning questa corrispondenza si indebolisce.
Il comportamento di un sistema non dipende più soltanto dal codice, ma anche dai dati utilizzati, dall’architettura del modello, dalle procedure di addestramento, dai pesi appresi, dai criteri di selezione dei dati, dal fine-tuning, dalle metriche di valutazione e dalle decisioni compiute durante lo sviluppo.
Con i modelli linguistici di grandi dimensioni la situazione diventa ancora più articolata. Il loro comportamento può dipendere da:
- dati e procedure di pre-addestramento;
- architettura e pesi del modello;
- istruzioni di sistema;
- tecniche di allineamento;
- filtri e sistemi di moderazione;
- strumenti esterni ai quali il modello può accedere;
- logiche di orchestrazione;
- criteri con cui vengono valutate qualità e sicurezza;
- aggiornamenti applicati dal fornitore nel tempo.
Pubblicare il codice dell’applicazione che invoca il modello permette quindi di vedere soltanto una porzione del sistema. È come rendere pubblico il cruscotto di un’automobile e sostenere di aver documentato il funzionamento del motore, della trasmissione e dei sistemi di controllo.
Per questo l’apertura del solo codice sorgente non è più sufficiente.
Open weights non è sempre open source
La diffusione dei modelli cosiddetti open weights ha aggiunto ulteriore confusione terminologica.
Rendere disponibili i pesi di un modello è importante. Consente di eseguirlo su infrastrutture proprie, analizzarlo, sottoporlo a fine-tuning e costruire applicazioni che non dipendano necessariamente dalle API del produttore.
Ma poter scaricare i pesi non significa automaticamente poter comprendere come il modello sia stato costruito.
Potrebbero non essere disponibili i dati utilizzati per l’addestramento, i criteri con cui sono stati selezionati, il codice di training, le procedure di allineamento, le valutazioni effettuate o le informazioni necessarie a riprodurre il processo. In alcuni casi la licenza introduce inoltre restrizioni sull’utilizzo o sulla modifica.
La Open Source Initiative ha affrontato il problema con la Open Source AI Definition 1.0. Secondo la definizione, un sistema di IA può essere considerato open source quando garantisce le libertà di usarlo, studiarne il funzionamento, modificarlo e condividerlo. Per esercitare concretamente tali libertà deve essere disponibile la forma preferita per apportare modifiche al sistema.
La disponibilità dei pesi può dunque essere una componente dell’apertura, ma non è sufficiente da sola.
Un confronto concreto rende la distinzione meno astratta. Llama di Meta rilascia i pesi, ma non il codice di addestramento né i dati usati per il pre-training, e la licenza introduce una restrizione d’uso per chi supera i 700 milioni di utenti mensili attivi – una condizione che la Open Source AI Definition esclude esplicitamente dalla prima delle quattro libertà. OLMo 3, sviluppato dall’Allen Institute for AI, segue un’impostazione diversa: pesi, codice di training completo, checkpoint intermedi e il dataset di pre-training Dolma 3 (circa 6.000 miliardi di token) sono rilasciati sotto licenza Apache 2.0 (trovi il repository ufficiale qui https://github.com/allenai/OLMo-core ). Nel primo caso un ricercatore indipendente può eseguire il modello, ma non riprodurlo né verificare come sia stato costruito. Nel secondo può fare entrambe le cose.
La contraddizione emerge ancora meglio guardando ai modelli open-weight oggi più competitivi. Kimi di Moonshot AI, GLM di Z.ai e Qwen di Alibaba nel 2026 hanno quasi chiuso il divario con i modelli proprietari su coding e ragionamento. Sono liberamente disponibili, ma nessuno pubblica sistematicamente codice di training e informazioni sui dati nella forma richiesta dall’OSAID. Nel frattempo OLMo, che quei requisiti li soddisfa davvero, resta un prodotto di nicchia. In altre parole, l’ecosistema sembra premiare molto più il vecchio free as in beer del free as in speech.
Aprire il modello non basta ad aprire il sistema
Anche un modello genuinamente open source non garantisce che l’applicazione costruita sopra di esso sia trasparente, sicura o orientata all’interesse dell’utente.
Un sistema di intelligenza artificiale è il risultato di più livelli:
- il modello di base;
- i dati e le procedure con cui viene adattato;
- le istruzioni che ne orientano il comportamento;
- l’applicazione nella quale viene integrato;
- gli obiettivi attribuiti al sistema;
- le metriche con cui viene giudicato;
- le procedure con cui vengono controllati errori e conseguenze;
- la governance che decide modifiche, priorità e compromessi.
Un modello aperto può essere inserito in un sistema che ottimizza criteri completamente opachi. Al contrario, un modello proprietario può essere utilizzato all’interno di un’applicazione che dichiara con chiarezza obiettivi, vincoli, metriche e risultati delle valutazioni.
Naturalmente, quando anche il modello è aperto, la verificabilità complessiva aumenta. Ma l’apertura deve riguardare l’intero sistema sociotecnico, non soltanto un suo componente.
Qui il concetto tradizionale di open source incontra quello di governance.
Non si tratta più solamente di chiedere: “Posso vedere il codice?”.
Dobbiamo chiedere anche:
- quale obiettivo sta ottimizzando il sistema?
- chi ha scelto quell’obiettivo?
- con quali dati e metriche viene misurato?
- quali effetti indesiderati sono stati considerati?
- chi può verificare i risultati?
- chi può contestare le scelte progettuali?
- come vengono gestiti i cambiamenti?
- che cosa accade quando l’interesse dell’utente entra in conflitto con quello del fornitore?
Queste domande diventano ancora più importanti quando il sistema non si limita a suggerire un film o a ordinare risultati di ricerca, ma interviene in ambiti come sanità, lavoro, credito, giustizia ed educazione.
Quando l’algoritmo entra in classe
La scuola è uno dei luoghi nei quali la distinzione tra prestazione e beneficio diventa più evidente.
Un sistema di IA generativa può essere molto efficace nel fornire risposte corrette, riassumere un testo, risolvere un problema o produrre un elaborato formalmente convincente. Ma l’obiettivo dell’educazione non è soltanto ottenere un risultato corretto.
Uno studente può consegnare una risposta eccellente senza aver sviluppato alcuna comprensione. Può ottenere il prodotto cognitivo senza aver attraversato il processo che avrebbe dovuto generarlo.
Questo rischio non è un difetto marginale. È una conseguenza possibile dell’obiettivo con cui la maggior parte delle IA generaliste è progettata: essere utile, rispondere rapidamente e ridurre lo sforzo necessario all’utente.
Nel lavoro professionale questa capacità può generare produttività. Nell’apprendimento, eliminare sistematicamente lo sforzo può eliminare proprio una parte del meccanismo attraverso cui si costruiscono comprensione, autonomia e capacità di trasferire ciò che si è appreso.
La domanda rilevante non è quindi soltanto quale modello debba essere utilizzato nella scuola.
La domanda è: quale idea di apprendimento è incorporata nel sistema?
Se questa idea rimane implicita e proprietaria, insegnanti, famiglie e istituzioni possono valutare soltanto la superficie dell’applicazione: facilità d’uso, rapidità delle risposte, gradevolezza dell’interfaccia e forse accuratezza delle informazioni.
Non possono verificare che cosa il sistema stia realmente ottimizzando dal punto di vista cognitivo.
Un framework aperto per rendere contestabile l’IA educativa
È da questo problema che nasce il framework L×M×C, che ho sviluppato come base teorica di Proxima ZSP, un sistema di tutoraggio maieutico basato sull’intelligenza artificiale. Framework, manifesto e preprint accademico sono pubblicati in accesso aperto, licenza CC BY 4.0, su lmc.proxima-zsp.it.
Il framework non valuta la qualità dell’interazione soltanto in base alla correttezza della risposta finale. Considera tre dimensioni:
- profondità del ragionamento;
- metacognizione, cioè la capacità dello studente di osservare e regolare il proprio processo mentale;
- consolidamento, cioè la possibilità di stabilizzare e trasferire ciò che è stato appreso.
L’obiettivo di Proxima ZSP non è rispondere al posto dello studente, ma intervenire attraverso domande, richieste di spiegazione, riformulazioni e verifiche che lo aiutino a costruire autonomamente il percorso verso la soluzione.
Il punto rilevante, in questo articolo, non è sostenere che il framework rappresenti la risposta definitiva al problema dell’IA educativa. Sarebbe una pretesa poco compatibile proprio con la logica dell’apertura.
Il punto è che il framework è pubblico, criticabile e modificabile.
Un insegnante può contestare il modo in cui viene definita la profondità del ragionamento. Un ricercatore può proporre metriche migliori. Uno sviluppatore può costruire una diversa implementazione. Una scuola può decidere che alcuni criteri non siano adatti ai propri studenti. I risultati delle sperimentazioni possono confermare il modello, mostrarne i limiti o richiederne la revisione.
L’apertura non garantisce che il framework sia corretto. Garantisce qualcosa di più importante: che nessuno debba accettarne la correttezza sulla fiducia.
Nel mio caso questa apertura ha già avuto una conseguenza concreta. Analizzando la metrica di metacognizione è emerso che confondeva la disposizione spontanea a riflettere con la capacità di farlo quando lo studente veniva sollecitato. La stiamo quindi rispecificando prima dell’avvio della sperimentazione controllata.
È esattamente il tipo di processo che sarebbe utile vedere applicato a tutti i sistemi di IA: rendere visibili anche i problemi, correggere le metriche quando non funzionano e permettere ad altri di verificarle.
Questa dovrebbe essere una proprietà fondamentale di qualsiasi sistema destinato a influenzare lo sviluppo cognitivo dei minori.
Dal diritto di vedere il codice al diritto di capire il sistema
La trasparenza algoritmica viene spesso trattata come una questione tecnica: documentazione, audit, accesso al codice o spiegabilità dei modelli.
Ma la trasparenza davvero utile deve partire da una domanda precedente: quale beneficio dichiara di produrre il sistema?
Per ogni soluzione algoritmica destinata ai minori dovrebbero essere resi pubblici almeno:
- il beneficio atteso;
- la popolazione alla quale il sistema è destinato;
- le metriche con cui tale beneficio viene misurato;
- le evidenze empiriche disponibili;
- i rischi prevedibili;
- i gruppi potenzialmente più vulnerabili;
- i risultati delle valutazioni indipendenti;
- i criteri con cui il sistema viene aggiornato;
- i meccanismi attraverso cui educatori, famiglie e ricercatori possono contestarne il funzionamento.
Non dovrebbe essere sufficiente dimostrare che una tecnologia non viola formalmente una norma.
Chi introduce un sistema nella vita di bambini e adolescenti dovrebbe dichiarare quale beneficio intende produrre e dimostrare come lo misurerà nel tempo.
L’AI Act europeo già prevede requisiti di trasparenza, gestione del rischio e documentazione per determinate categorie di sistemi ad alto rischio. Il Digital Services Act impone alle grandi piattaforme obblighi di valutazione e mitigazione dei rischi sistemici, compresi quelli che riguardano i minori.
Sono passi importanti, ma la discussione dovrebbe estendersi dal rischio di danno al beneficio dimostrabile.
Fra non produrre un danno evidente e produrre un beneficio reale esiste uno spazio molto ampio. È precisamente in quello spazio che operano oggi molte tecnologie educative.
La governance open source come infrastruttura pubblica
Immaginare una governance open source dell’intelligenza artificiale non significa pretendere che ogni azienda pubblichi indiscriminatamente dati, segreti industriali e intera proprietà intellettuale.
Significa costruire sistemi nei quali obiettivi, criteri di valutazione, limiti e processi decisionali possano essere sottoposti a controllo.
Significa permettere alla comunità di partecipare non soltanto alla scrittura del software, ma anche alla definizione di ciò che il software dovrebbe fare.
Servono modelli realmente aperti quando è possibile costruirli.
Non si parte da zero. Esistono già iniziative che provano a misurare esattamente questo: le Model Card, proposte nel 2019 come standard per documentare dataset, limiti e usi previsti di un modello; l’Open Source AI Definition della OSI, già citata; e il Foundation Model Transparency Index di Stanford, che dal 2023 assegna un punteggio di trasparenza ai principali sviluppatori di modelli. I risultati dell’edizione 2025 dicono più di qualunque previsione: il punteggio medio è sceso da 58 a 40 su 100 in un solo anno, invertendo il miglioramento registrato nelle due edizioni precedenti – Meta è passata da 60 a 31, Mistral da 55 a 18. Anche le aziende cinesi, valutate per la prima volta nel 2025, si collocano nella metà inferiore della classifica. Questi strumenti esistono, misurano, pubblicano risultati puntuali – e nonostante questo la trasparenza media del settore sta peggiorando, non migliorando. Il problema non è dunque l’assenza di metriche. È che nessuno è obbligato a ottenere un punteggio alto per continuare a operare.
Ma servono anche:
- protocolli pubblici di valutazione;
- benchmark che non misurino soltanto prestazioni tecniche;
- dataset documentati e verificabili;
- strumenti indipendenti di audit;
- specifiche aperte per i sistemi ad alto impatto;
- comunità multidisciplinari capaci di coinvolgere sviluppatori, ricercatori, educatori, giuristi e utenti;
- meccanismi di governance che rendano visibili conflitti d’interesse e decisioni.
La comunità open source non deve necessariamente addestrare in un garage il prossimo foundation model da centinaia di miliardi di parametri. Anche perché il garage dovrebbe disporre di una quantità di GPU, energia e capitale piuttosto insolita.
Può però rendere aperto lo strato attraverso cui i modelli vengono trasformati in sistemi sociali, educativi e decisionali.
Può costruire gli strumenti per verificare ciò che questi sistemi dichiarano di fare.
Può definire metriche alternative a quelle scelte dai produttori.
Può creare implementazioni che non siano subordinate alla massimizzazione dell’engagement, alla raccolta dei dati o alla dipendenza da una singola piattaforma.
Può, soprattutto, impedire che la difficoltà tecnica venga utilizzata come argomento per sottrarre le decisioni al confronto pubblico.
Aprire ciò che esercita potere
L’open source è nato anche dalla convinzione che chi utilizza un programma debba poterlo studiare, modificare e condividere.
Oggi i sistemi informatici non si limitano più a eseguire operazioni richieste dall’utente. Selezionano informazioni, prevedono comportamenti, orientano decisioni, personalizzano ambienti e mediano una parte crescente della nostra esperienza della realtà.
Per questo non basta più aprire il codice.
Quando un sistema esercita potere sulle persone, dobbiamo poter comprendere quali obiettivi persegua, quali ipotesi incorpori, come venga valutato e chi possa modificarne il comportamento.
Il framework L×M×C è aperto proprio per questo. Non per dichiararlo perfetto, ma per consentire ad altri di verificarlo, criticarlo, adottarlo, trasformarlo o dimostrare che alcune sue parti non funzionano.
È un invito concreto, non retorico, rivolto alla comunità tecnica, scientifica ed educativa: il framework L×M×C è pubblicato in accesso aperto, licenza CC BY 4.0, su lmc.proxima-zsp.it. Leggetelo, mettetelo alla prova, trovate dove sbaglia. Costruite un’implementazione diversa dalla mia, estendetelo a un altro dominio o a un’altra fascia d’età. Contribuire a modelli di governance nei quali l’apertura non sia una dichiarazione commerciale, ma una proprietà verificabile, comincia da un link che chiunque può aprire oggi stesso.
Ed è anche un invito ai legislatori: quando una soluzione algoritmica è destinata ai minori, rendere obbligatoria non soltanto la trasparenza sul suo funzionamento, ma anche sul beneficio che dichiara di produrre e sulle prove con cui intende dimostrarlo.
Internet ha mostrato che infrastrutture aperte possono generare innovazione oltre le intenzioni e le possibilità di chi le ha create.
L’intelligenza artificiale ci pone oggi una sfida simile, ma con conseguenze ancora maggiori.
Non dobbiamo limitarci ad aprire le tecnologie.
Dobbiamo aprire le decisioni attraverso cui quelle tecnologie vengono trasformate in potere.
