«L'intelligenza artificiale provocherà la fine del mondo.» Lo sentiamo dire sempre più spesso. È una frase enorme. Forse troppo enorme. Ma prima bisognerebbe capire che cosa intendiamo per mondo. Se intendiamo questo pianeta, la Terra, allora la sua fine non appartiene alla storia umana. Non abbiamo un precedente da studiare. Non abbiamo testimonianze. Non abbiamo qualcuno che possa raccontarci come sia andata l'ultima volta. Questo non significa che non possa accadere. Significa semplicemente che non possiamo utilizzare l'esperienza della fine del mondo, perché non ne possediamo una. Se invece per mondo intendiamo il mondo nel quale viviamo — le sue regole, i suoi equilibri, i suoi mestieri, le sue gerarchie, ciò che consideriamo importante, ciò che sappiamo fare e il valore che attribuiamo a quello che sappiamo fare — allora di mondi ne abbiamo visti finire parecchi. E forse stiamo cercando il precedente sbagliato. Forse non abbiamo paura soltanto della fine del mondo. Abbiamo paura della fine del nostro mondo. Di svegliarci e scoprire che qualcosa che abbiamo impiegato vent'anni a imparare vale improvvisamente molto meno. Che il nostro mestiere è cambiato. Che la nostra competenza non è più rara. Che qualcun altro possiede uno strumento che moltiplica le sue capacità e noi no. Che le regole che conoscevamo non sono più le regole del gioco. Abbiamo paura di qualcosa di molto antico. Di essere disarcionati dalla cresta dell'onda. E questa paura, invece, una storia ce l'ha.
Quando il software non era ancora il prodotto
All'inizio il grande valore economico dell'informatica era soprattutto nella macchina. I computer erano enormi. Costosi. Rari. Il software serviva a renderli utili. Programmi e modifiche circolavano fra università, laboratori, aziende e gruppi di utenti. Si prendeva qualcosa scritto da qualcun altro, lo si adattava, lo si correggeva, lo si migliorava. Non dobbiamo romanticizzare quel periodo. Non era necessariamente una rivoluzione politica. C'era una ragione economica molto più semplice. Il business era la macchina. Il software contribuiva a venderla. Se un programma rendeva più utile un computer, aumentava il valore del computer. Se gli utenti riuscivano a scambiarsi strumenti e conoscenza, quella macchina diventava più utile. Poi il valore cominciò a spostarsi. Il software divenne abbastanza importante da possedere un valore economico indipendente dall'hardware. Non era più soltanto ciò che rendeva utile il prodotto. Era diventato il prodotto. E quando cambiò il luogo nel quale si trovava il valore, cambiarono anche i confini. Licenze. Restrizioni. Codice non disponibile. Segreti industriali. Divieti di copia. Ciò che prima poteva circolare cominciò sempre più spesso a essere chiuso. E qualcuno decise che quella trasformazione non gli piaceva affatto.
La libertà di guardare dentro
Richard Stallman proveniva dalla cultura hacker del MIT Artificial Intelligence Laboratory, dove studiare e modificare programmi scritti da altri era parte del modo stesso di lavorare. Quando quel mondo cominciò a chiudersi, reagì. Nel 1983 annunciò GNU. Non stava semplicemente proponendo programmi che non costassero denaro. Il punto era molto più profondo. Se utilizzo un programma devo poter capire che cosa fa. Se voglio capire che cosa fa devo poterlo studiare. Se trovo qualcosa che non funziona devo poterlo modificare. E se trovo una soluzione devo poterla condividere. Per fare tutto questo serve qualcosa che oggi può sembrare banale. Bisogna poter guardare dentro. Nacquero compilatori. Editor. Librerie. Utility. Licenze costruite proprio per preservare quella possibilità. GNU arrivò a costruire gran parte di ciò che serviva. Mancava ancora qualcosa. Il kernel. Nel 1991 arrivò Linux. E da quel momento cominciò una delle più straordinarie dimostrazioni della storia dell'informatica di ciò che può accadere quando persone che non appartengono alla stessa azienda, non vivono nello stesso Paese e spesso non si sono mai incontrate possono lavorare sulla stessa macchina concettuale. Oggi sappiamo dove è arrivata quella storia. Allora no. Allora Linux era anche un sistema che molto spesso non funzionava con l'hardware che avevi appena comprato. E qui smettiamo per un momento di raccontare la storia dall'esterno. Perché questa parte io la ricordo.
Io c'ero
Oggi installare Linux può significare scaricare un'immagine, metterla su una chiavetta, avviare il computer e seguire una procedura guidata. Io ricordo un'altra cosa. Ricordo di comprare una scheda e scoprire che Linux non sapeva che farsene. Ma non era sempre perché Linux fosse giovane. E non era sempre perché nessuno avesse ancora trovato il tempo di scrivere il driver. Qualche volta il produttore non forniva un driver libero. Qualche volta forniva soltanto qualcosa di binario e proprietario. Qualche volta non forniva le specifiche necessarie perché qualcun altro potesse scrivere un driver. Avevi comprato la scheda. L'avevi pagata. Era fisicamente dentro il tuo computer. Era tua. Eppure poteva mancarti una cosa fondamentale: il linguaggio necessario per parlare con ciò che avevi comprato. Che cosa fai? Oggi la risposta potrebbe sembrare: aspetti il produttore. Allora molto spesso la risposta fu diversa. Lo scopri. Qualcuno cominciava a osservare. Registri. Comandi. Risposte. Firmware. Comportamenti. Provava qualcosa. Guardava cosa succedeva. Cambiava un parametro. Provava ancora. Faceva reverse engineering. E lentamente ricostruiva ciò che il produttore non aveva consegnato. Non è una leggenda nata dopo. È successo davvero. Il driver libero b43, per esempio, per chipset wireless Broadcom venne sviluppato attraverso reverse engineering. Qualcuno dovette insegnare a Linux a parlare con un pezzo di hardware senza che chi aveva costruito quel pezzo gli avesse consegnato tutto ciò che sarebbe servito per farlo. Ed è difficile trovare un'immagine migliore di quella cultura. La comunità imparava a parlare con le macchine. Non chiedeva necessariamente: costruiscimi quello che mi serve. Chiedeva: lasciami costruirlo. E quando non venivano fornite nemmeno le informazioni necessarie? Qualche volta le informazioni venivano ricostruite. Non era magia. Era lavoro. Tentativi. Errori. Persone. Tempo. Qualcuno pubblicava ciò che aveva scoperto. Un altro lo provava su una revisione leggermente diversa della stessa scheda. Non funzionava. Mandava informazioni. Qualcun altro modificava il codice. Funzionava quasi. Un altro trovava il problema. Funzionava. Poi arrivava una nuova versione del kernel e magari si rompeva di nuovo. E si ricominciava. Compilavamo il kernel. E aspettavamo. Ore. Con certe macchine, una giornata. Qualche volta anche di più. Poi riavviavi. E non partiva. Oppure partiva e qualcosa non funzionava. Si ricominciava. Agli occhi di chi voleva semplicemente accendere un computer e usarlo sembravamo dei marziani. Perché? Perché perdere tutto quel tempo quando esisteva già qualcosa che funzionava? La risposta, almeno per molti di noi, non aveva bisogno di un manifesto. Perché potevamo farlo. Avevamo un computer. Avevamo il codice. Avevamo un compilatore. Avevamo abbastanza conoscenza oppure abbastanza testardaggine per acquisirla. E avevamo una comunità. Ma soprattutto avevamo una cosa che oggi rischiamo di sottovalutare. Potevamo sbagliare. Potevamo modificare dieci righe. Compilare. Rompere tutto. Imprecare. Capire qualcosa. E ricominciare. Il fallimento di quell'esperimento non richiedeva l'approvazione di un consiglio di amministrazione. Non bruciava milioni. Non richiedeva un cluster. Non doveva produrre un ritorno economico. Poteva semplicemente essere un'idea sbagliata. E questo era perfettamente accettabile. Il costo dell'errore era alla nostra portata. Questa potrebbe essere una delle ragioni meno raccontate del successo dell'open. La libertà non era soltanto scritta in una licenza. Era materialmente praticabile.
E se per compilare Linux fosse servito un datacenter?
Proviamo a cambiare una sola cosa nella storia. Lasciamo tutto il resto identico. Torvalds pubblica il kernel. GNU esiste. Il codice è disponibile. La licenza permette di modificarlo. Tutti possono leggerlo. Tutto è aperto. Ma per compilare una modifica servono diecimila GPU. Ogni tentativo costa centomila euro. Per sapere se le dieci righe che abbiamo cambiato funzionano dobbiamo prenotare ore in un datacenter. Che cosa sarebbe successo? Formalmente sarebbe rimasto aperto. Praticamente? Chi avrebbe partecipato? Lo studente? Il ragazzo nella sua camera? Il programmatore curioso? La piccola università? Il gruppo di amici che vuole vedere se quell'idea assurda funziona? No. Avremmo avuto il diritto di modificare Linux. Ma non la possibilità materiale di farlo. E questa distinzione è fondamentale. Perché una tecnologia non diventa realmente partecipabile soltanto quando togliamo il lucchetto dal codice. Diventa partecipabile quando una quantità sufficientemente grande di persone può permettersi di fare qualcosa dopo averlo aperto. Leggere. Cambiare. Provare. Fallire. Capire. Riprovare. Una tecnologia è realmente partecipabile soltanto quando è accessibile anche il costo dell'errore. Teniamola a mente. Perché fra poco ci servirà.
Poi arrivarono le serrature
Quando il software e i contenuti digitali acquisirono un valore economico enorme, arrivarono le protezioni. Software. Musica. Film. Videogiochi. Libri. Era naturale che chi produceva qualcosa cercasse di proteggerne il valore. Ma il digitale aveva introdotto una stranezza senza precedenti. La copia aveva un costo quasi nullo. E la copia non consumava l'originale. Cominciò una guerra. Le industrie avevano bisogno di una parola semplice per descrivere il nemico. Quella parola esisteva già. Pirateria. Era potentissima. Dentro quell'unica parola potevano però finire comportamenti enormemente diversi. Vendere migliaia di copie illegali di un'opera. Condividere un file. Studiare un sistema di protezione. Pubblicare un programma. Spiegare perché una serratura digitale non funzionava. Qualche volta persino cercare di utilizzare sul proprio computer qualcosa che si era regolarmente acquistato. Ed è qui che le astrazioni non bastano più. Diamo un nome alle persone.
Jon
Si chiamava Jon Lech Johansen. Norvegese. Quando scoppiò la vicenda che lo avrebbe reso famoso aveva quindici anni. Aveva un computer Linux. E voleva vedere dei DVD. Il problema era che il sistema CSS utilizzato dall'industria cinematografica controllava la riproduzione dei DVD attraverso un ecosistema di dispositivi e software autorizzati. Linux non faceva parte di quel mondo. Jon e altri sviluppatori lavorarono su DeCSS, il programma che permetteva di decifrare il contenuto dei DVD. La sua terribile colpa? Voleva anche poter guardare i propri DVD sul proprio computer Linux. Lo scrivo con tutta l'ironia amara che merita questa storia. Non stiamo parlando del proprietario di un impero internazionale della contraffazione. Stiamo parlando di un adolescente. Dopo una richiesta della Motion Picture Association of America, le autorità norvegesi lo incriminarono per la vicenda DeCSS. Aveva quindici anni quando aveva utilizzato DeCSS nel 1999. Il tribunale di Oslo lo assolse all'unanimità nel 2003. La procura fece appello. Venne assolto nuovamente. Nel frattempo quella vicenda gli aveva attraversato una parte enorme dell'adolescenza. La serratura era stata aperta. E il ragazzo che aveva contribuito ad aprirla era diventato il problema.
Dmitry
Poi c'era Dmitry Sklyarov. Programmatore russo. Aveva ventisei anni. Lavorava per ElcomSoft. Aveva studiato il sistema di protezione degli e-book Adobe. Nel luglio del 2001 andò a Las Vegas per DEF CON. Una conferenza di sicurezza. Parlò delle debolezze della protezione degli e-book. La sua colpa? Aveva contribuito allo sviluppo di un software capace di convertire e-book protetti e aveva spiegato pubblicamente perché quella protezione poteva essere aggirata. Dopo la conferenza venne arrestato dall'FBI. Non per aver organizzato un mercato clandestino di libri. La prima applicazione penale delle disposizioni anticircumvention del DMCA contro sviluppatori di software riguardava lui ed ElcomSoft. Rimase settimane in carcere. Per mesi non poté tornare in Russia dalla moglie e dai figli. Alla fine il governo americano raggiunse un accordo con lui: avrebbe collaborato nel procedimento contro ElcomSoft e le accuse personali sarebbero state abbandonate. ElcomSoft andò a processo. E venne assolta. Anche qui la colpa, detta con la stessa ironia amara, era terribile: aveva capito come funzionava una serratura. E aveva contribuito a costruire uno strumento capace di aprirla.
Edward e gli altri
Poi c'era Edward Felten. Professore a Princeton. Ma questa volta la storia diventa quasi surreale. Nel 2000 la Secure Digital Music Initiative lanciò una sfida pubblica. In sostanza: provate a rompere le nostre tecnologie di protezione. Felten e il suo gruppo accettarono. C'erano Bede Liu, Scott Craver, Min Wu, Dan Wallach, Ben Swartzlander, Adam Stubblefield, Drew Dean. Ricercatori. Studenti. Informatici. Ci provarono. E ci riuscirono. Poi fecero ciò che normalmente fanno i ricercatori quando scoprono qualcosa. Scrissero un paper. Il lavoro superò la peer review e venne accettato per una conferenza scientifica. Ed ecco la loro colpa. Volevano pubblicare i risultati. La RIAA, SDMI e Verance minacciarono conseguenze legali se il lavoro fosse stato presentato. Non soltanto contro gli autori. Anche contro gli organizzatori della conferenza e le rispettive istituzioni. Il 26 aprile 2001 Felten avrebbe dovuto presentare il paper. Non lo fece. Spiegò pubblicamente che gli autori avevano deciso di non esporre se stessi, i propri datori di lavoro e gli organizzatori della conferenza al costo e all'incertezza di una causa. Fermiamoci un secondo. L'industria aveva detto: provate a romperlo. Loro lo avevano rotto. E quando volevano spiegare scientificamente come ci erano riusciti, si trovarono davanti alla minaccia di una causa. Il gruppo e USENIX finirono per rivolgersi a loro volta alla giustizia per poter stabilire il diritto di pubblicare la ricerca senza rischiare un procedimento sotto il DMCA. La loro colpa? Avere accettato la sfida troppo bene.
Eric
E poi c'era Eric Corley, editore di 2600 Magazine. Non aveva scritto DeCSS. Il magazine ne parlò. Lo pubblicò. Poi, dopo l'ordine di rimuoverlo, pubblicò collegamenti verso altri siti che lo ospitavano. Otto grandi studi cinematografici portarono la questione in tribunale. Il problema arrivò fino al punto di discutere se anche linkare un programma potesse costituire una forma vietata di distribuzione di uno strumento di circumvention. La sua colpa? Aver indicato dove si trovava l'informazione.
Le streghe
Guardiamoli insieme. Un quindicenne che voleva far funzionare i DVD su Linux. Un programmatore russo che aveva studiato la protezione degli e-book. Un professore e un gruppo di ricercatori che avevano accettato una sfida pubblica e volevano pubblicare i risultati. Un giornale hacker che aveva pubblicato e poi linkato del codice. Non erano tutti uguali. I casi erano giuridicamente diversi. Le azioni erano diverse. Le leggi erano diverse. Non abbiamo bisogno di trasformarli in santi. Basta pronunciare i loro nomi. Jon Johansen. Dmitry Sklyarov. Edward Felten. Bede Liu. Scott Craver. Min Wu. Dan Wallach. Ben Swartzlander. Adam Stubblefield. Drew Dean. Eric Corley. E guardare la sproporzione. Dall'altra parte c'erano alcune delle più potenti industrie dell'intrattenimento e della tecnologia del pianeta, associazioni industriali, avvocati, legislatori e, nel caso Sklyarov, il potere penale dello Stato. Il problema non era più soltanto: hai copiato qualcosa che non avevi diritto di copiare? Era diventato anche: hai costruito uno strumento capace di aprire la serratura? hai studiato la serratura? hai spiegato come funziona? hai pubblicato il codice? hai indicato dove trovarlo? E qui la storia dell'open incontra qualcosa di ancora più profondo. Chi controlla la macchina che hai comprato? Chi decide che cosa hai diritto di capire di ciò che hai davanti? E fino a che punto il diritto di proteggere un contenuto può trasformarsi nel diritto di impedire agli altri di comprendere una tecnologia? Sono domande vecchie. Ma stanno per tornare sotto una forma che allora sarebbe sembrata fantascienza.
Poi la macchina ha parlato
Per decenni avevamo costruito programmi. Poi reti neurali. Riconoscevano cifre. Classificavano immagini. Trovavano schemi. Prendevano piccole decisioni. Erano interessanti. Per molti di noi erano affascinanti. Ma per quasi tutti gli altri rimanevano lontane. Poi abbiamo scritto una frase. E la macchina ha risposto. Non con un numero. Non con una classe. Non con un sì o con un no. Ci ha parlato. E ha parlato bene. Troppo bene. Troppo presto. Troppo velocemente perché avessimo il tempo di capire veramente ciò che stava accadendo. Ha cominciato a scrivere. Programmare. Tradurre. Analizzare. Riassumere. Spiegare. Ha cominciato a comprimere ore in minuti. A permettere a una persona di affrontare problemi per i quali prima sarebbero servite competenze diverse. L'onda era arrivata. Ed era molto più grande di quanto ci aspettassimo.
Open, ma quanto?
Oggi possiamo scaricare modelli open. È una conquista enorme. Possiamo eseguirli. Studiare le architetture. Scaricare i pesi quando vengono resi disponibili. Quantizzarli. Modificarli. Fare fine-tuning. Costruire sistemi sopra di essi. Ma qui dobbiamo stare attenti alle parole. Un modello non è semplicemente un programma. E i pesi non sono il suo sorgente nel significato classico del termine. I pesi sono il risultato di una storia. Dentro quei numeri è condensato ciò che è accaduto durante l'addestramento. Dati. Selezione. Ordine. Preprocessing. Ottimizzazione. Decisioni. Tentativi. Errori. Calcolo. Possiamo avere il risultato senza poter riprodurre la storia che lo ha prodotto. E soprattutto senza poterci permettere di ripeterla. Torniamo allora al vecchio computer sul quale compilavamo Linux. Facciamo la stessa cosa. Ripartiamo. Costruiamo il modello. Solo che questa volta non dobbiamo aspettare una notte. Potrebbero servire migliaia di acceleratori. Memoria. Energia. Datacenter. Dataset enormi. Ingegneri. Tempo. Capitali. Ed eccoci davanti a una serratura completamente nuova. Il modello può essere open. La sua nascita può non esserlo affatto. Non perché qualcuno necessariamente ce lo proibisca. Perché pochissimi possono permettersela. Non è una serratura crittografica. Non è scritta dentro una licenza. È costruita con silicio, energia e capitale. E contro questa non basta il reverse engineering. È una serratura fisica. Puoi conoscere perfettamente come funziona la serratura. Puoi avere il paper. Puoi avere il codice. Puoi conoscere l'architettura. Puoi sapere esattamente che cosa dovresti fare. E non avere comunque i mezzi per farlo. Ecco perché quella vecchia frase diventa improvvisamente fondamentale: il costo dell'errore deve tornare alla nostra portata.
La macchina che impara dalla macchina
Ma nel frattempo è accaduto qualcosa che rende il nuovo conflitto ancora più interessante. Una macchina può imparare osservandone un'altra. La chiamiamo distillazione. Un modello produce risposte. Quelle risposte possono diventare materiale attraverso il quale un altro modello impara. E sta comparendo una nuova espressione: distillation attack. Fermiamoci. Perché abbiamo già imparato quanto possono diventare potenti le parole. Se qualcuno ruba una password, chiamiamolo furto di credenziali. Se qualcuno entra abusivamente in un sistema, chiamiamolo accesso abusivo. Se qualcuno sottrae dati privati, discutiamo della sottrazione di quei dati. Ma prendiamo un caso molto più semplice. Qualcuno compra inferenza. Paga. Invia una richiesta. La macchina la elabora. Il servizio consegna la risposta per la quale è stato pagato. L'acquirente prende quella risposta. La confronta con altre. La studia. E permette a un'altra macchina di imparare osservandola. Che cosa è stato rubato? Non necessariamente il codice. Non i pesi. Non il datacenter. La seconda macchina ha osservato ciò che la prima ha prodotto. E ha imparato. Ed ecco una domanda che rischia di diventare una delle più importanti dei prossimi anni: si può possedere ciò che una macchina ha imparato?
Prima lo chiamavamo training
C'è una contraddizione che non possiamo fingere di non vedere. Le grandi intelligenze artificiali sono state costruite imparando da una quantità immensa di produzione umana. Libri. Codice. Fotografie. Pagine web. Articoli. Discussioni. Conoscenza. Una parte enorme di ciò che l'umanità aveva reso digitalmente accessibile. Non tutto questo patrimonio è stato acquistato opera per opera dai laboratori che lo hanno utilizzato. Su una parte di questi utilizzi esistono ancora oggi controversie giudiziarie. Ma il principio tecnico sul quale è stata costruita la rivoluzione è chiarissimo: una macchina può imparare osservando ciò che altri hanno prodotto. Quando una macchina imparava da noi, lo chiamavamo: training. Adesso una macchina può imparare osservando un'altra macchina. E cominciano a comparire altre parole. Extraction. Attack. Aspettiamo. Prima di accettare la nuova parola, facciamo la domanda. Che cosa è cambiato? Se esiste una differenza sostanziale, dimostriamola. Se esiste un illecito specifico, chiamiamolo con il suo nome. Ma non permettiamo che sia la scelta di un vocabolo a trasformare automaticamente l'apprendimento in un'aggressione. Perché abbiamo già visto una volta cosa succede quando comportamenti completamente diversi vengono spinti dentro una sola parola. Allora era: pirateria.
Quanto manca?
Ed eccoci di nuovo davanti alla storia. Soltanto che questa volta abbiamo qualcosa che venticinque anni fa non avevamo. Una giustificazione enormemente più potente del copyright. La fine del mondo. Non: stanno copiando il nostro film. Non: stanno rompendo la protezione del nostro CD. Non: stanno danneggiando il nostro mercato. Ma: potrebbero mettere in pericolo l'umanità. Può esistere una giustificazione più potente per costruire una serratura? Può esistere un modo più efficace per trasformare chi prova ad aprirla in qualcuno del quale avere paura? Non sappiamo se accadrà. Non dobbiamo inventare il futuro. Ma proprio perché conosciamo Jon, Dmitry, Edward e gli altri, abbiamo il diritto di fare la domanda prima. Non dopo. Prima che le parole diventino leggi. Prima che le definizioni diventino reati. Prima che le serrature diventino infrastruttura. Prima che un ragazzo davanti a una macchina venga nuovamente considerato pericoloso perché è riuscito a farle fare qualcosa che non era previsto facesse. Quanto manca alla prossima caccia alle streghe? E soprattutto: chi saranno, questa volta, le streghe? Forse saranno quelli che costruiscono piccoli modelli. Quelli che fanno reverse engineering. Quelli che distillano. Quelli che modificano. Quelli che collegano macchine che non avrebbero dovuto essere collegate. Quelli che scoprono un modo per ottenere con cento euro ciò per cui ieri ne servivano centomila. Quelli che pubblicano ciò che hanno scoperto. Non sappiamo se saranno loro. Ma sappiamo che una cosa simile è già accaduta. E conosciamo persino i nomi di alcune delle persone alle quali accadde.
Il mare
Non sappiamo se l'intelligenza artificiale provocherà la fine del mondo. Non possiamo saperlo. Sappiamo però che sta cambiando un mondo. Il nostro. E conosciamo quella sensazione. È un'onda che cresce sotto i piedi. Possiamo cercare di fermarla. Possiamo costruire muri. Possiamo decidere chi abbia il permesso di salirci sopra. Possiamo lasciare che pochissimi costruiscano le tavole e che tutti gli altri paghino per utilizzarle. Oppure possiamo porci una domanda diversa. Che cosa rese possibile ciò che accadde con Linux? Non soltanto il codice. Non soltanto la licenza. Non soltanto Torvalds. Non soltanto Stallman. Non soltanto migliaia di programmatori straordinari. C'era una condizione materiale molto più semplice. La gente poteva partecipare. Poteva costruire. Poteva modificare. Poteva rompere. Poteva capire. Poteva riprovare. Quando il produttore non scriveva il driver, qualcuno poteva scriverlo. Quando non pubblicava la documentazione, qualcuno poteva tentare di ricostruirla. Quando una soluzione non funzionava, qualcun altro poteva provarne un'altra. Non serviva il permesso di chi aveva costruito la macchina. E soprattutto non serviva possedere un datacenter. Oggi rendere disponibili i modelli non basta. Dobbiamo rendere disponibile la possibilità di costruirli. Non basta distribuire il risultato dell'apprendimento. Dobbiamo distribuire la possibilità di imparare. E distribuire il calcolo non basta. Possiamo prendere un addestramento gigantesco e dividerlo fra mille macchine. Rimane un addestramento gigantesco. Possiamo distribuire l'inferenza. Rimane inferenza. Possiamo distribuire i pesi. Rimangono pesi prodotti altrove. Distribuire il calcolo non significa ancora distribuire la crescita. Forse è questo il punto nel quale dobbiamo smettere di imitare ciò che esiste. I modelli di oggi vengono costruiti. Addestrati. Terminati. Distribuiti. Quando arrivano nelle nostre mani sono già adulti. Possiamo insegnare loro qualcosa in più. Possiamo modificarli. Possiamo aggiungere memoria esterna. Possiamo specializzarli. Ma la loro nascita è già avvenuta altrove. E se fosse proprio questa l'idea da mettere in discussione? Se un'intelligenza potesse nascere piccola? Se potesse crescere? Se non dovesse attraversare tutta la conoscenza del mondo prima ancora di poter esistere? Se una macchina potesse insegnare qualcosa a un'altra? Se milioni di nodi potessero contribuire non soltanto al calcolo, ma alla conoscenza? Se una persona con una macchina piccola potesse aggiungere qualcosa che rimane? Se un'altra, con una macchina enorme, potesse aggiungere molto di più senza diventare per questo proprietaria dell'intero organismo? Se l'errore di una singola persona potesse tornare a costare abbastanza poco da poterselo permettere? Allora non avremmo bisogno di costruire il datacenter più grande. Avremmo bisogno di costruire qualcosa di completamente diverso. Non vogliamo semplicemente un altro modello. Non vogliamo costruire il concorrente open del prossimo gigantesco modello proprietario. Non vogliamo prendere lo stesso paradigma, gli stessi costi, la stessa concentrazione e provare disperatamente a riprodurli con meno denaro. Quello significherebbe ancora inseguire l'onda. E ormai sappiamo che non basta. Non vogliamo soltanto imparare a cavalcare l'onda. Vogliamo imparare a costruire il mare. Ma un mare non si costruisce versando tutta l'acqua nello stesso posto. Nasce da una quantità immensa di parti. Gocce. Fiumi. Correnti. Acqua che arriva. Acqua che parte. Parti lontanissime che appartengono allo stesso sistema senza trovarsi mai nello stesso luogo. Forse anche un'intelligenza può essere così. Forse non deve essere contenuta interamente da nessuna parte. Forse nessuno deve poter dire: è tutta qui. E se vogliamo costruire qualcosa che possa nascere in quel mare, allora dobbiamo cominciare ancora prima dell'intelligenza. Prima del modello. Prima dei pesi. Prima dell'addestramento. Dobbiamo costruire il luogo nel quale qualcosa possa nascere. Un luogo che non appartenga a nessuno. E proprio per questo possa appartenere a tutti. Un luogo nel quale una nuova intelligenza non venga assemblata già adulta. Ma possa cominciare piccola. Imparare. Sbagliare. Ricordare. Cambiare. Crescere. La biologia possiede una parola antichissima per il luogo nel quale una cosa del genere comincia. Noi prenderemo in prestito quella parola. L'utero.