L'ultima bottiglia di Mrs. Donoghue

Il 26 agosto del 1928 una donna di Glasgow di nome May Donoghue entrò con un’amica in un café di Paisley, una cittadina a circa sette miglia dal centro della città. L’amica ordinò e pagò per lei un Scotsman ice cream float, un gelato servito con gassosa allo zenzero. La bevanda fu servita dal proprietario del Wellmeadow Café in una bottiglia opaca di vetro scuro, del tipo che all’epoca era diffuso proprio perché il vetro torbido impediva di vedere eventuali sedimenti nel contenuto.

Quando la seconda metà del liquido fu versata nel bicchiere insieme al gelato sciolto, dalla bottiglia uscì, trascinata dalla gassosa, una lumaca in avanzato stato di decomposizione. May Donoghue si ammalò di gastroenterite severa, fu visitata da un medico il 29 agosto e venne ricoverata in emergenza al Glasgow Royal Infirmary il 16 settembre. Quattro anni più tardi, nel 1932, la House of Lords emise una sentenza che è considerata la pietra angolare del moderno diritto della responsabilità da prodotto nel mondo di common law.

La lumaca nella bottiglia

La decisione venne presa a maggioranza di tre voti contro due. L’estensore del voto di maggioranza fu Lord Atkin, che nel passaggio celebre che tutti gli studenti di giurisprudenza continuano a memorizzare ancora oggi formulò il cosiddetto neighbour principle, ovvero l’obbligo di ciascuno di prendersi cura del proprio vicino in senso giuridico, dove vicino significava chiunque fosse ragionevolmente prevedibile come destinatario degli effetti della propria condotta.

Da quel momento il produttore risponde del proprio prodotto anche nei confronti di chi non ha contrattualmente rapporti con lui, anche se la bottiglia passa attraverso un distributore e un caffè prima di arrivare al consumatore, anche se tra la fabbrica e la gastroenterite di Mrs. Donoghue si interpongono settimane di magazzino e chilometri di strada.

Quello che quasi nessuno nota leggendo la sentenza è che il giudice, per poter scrivere il neighbour principle, aveva bisogno di un presupposto ontologico preciso, ovvero di una certa idea di cosa fosse l’oggetto di cui si stava parlando. L’oggetto era la bottiglia. Un artefatto bounded, dotato di contorni netti, identificabile, esaminabile, conservabile.

La bottiglia veniva prodotta in uno stabilimento specifico, a David Stevenson di Paisley, riempita in un momento datato, sigillata con un tappo che ne garantiva l’integrità fino al punto vendita. Se fosse stato necessario, gli avvocati avrebbero potuto chiedere di esaminare il lotto di produzione, di analizzare la composizione del vetro, di verificare la catena di approvvigionamento degli zuccheri e degli aromi. La causa materiale, nel senso aristotelico, era raggiungibile. La causa efficiente, cioè il processo produttivo, era documentata. La causa formale, ossia la forma tipica di una bottiglia di gassosa, era nota a chiunque.

Tutto il diritto moderno della responsabilità da prodotto che si è costruito sopra Donoghue v. Stevenson presuppone questa cosa semplicissima e al tempo stesso cruciale: presuppone che si possa puntare il dito verso un oggetto e dire «questo», e che il dito che punta trovi sempre qualcosa al suo capo terminale.

La nuova PLD e il problema di una categoria

Nel 1985 l’Europa, con la Direttiva 85/374/CEE, ha recepito in forma continentale il principio di Donoghue, estendendolo e sistematizzandolo. La Product Liability Directive parla di «prodotti difettosi» e stabilisce una responsabilità oggettiva del produttore, indipendente dalla colpa, per i danni causati dal prodotto.

Quarant’anni dopo, il 23 ottobre 2024, è stata adottata la Direttiva 2024/2853, entrata in vigore il 9 dicembre 2024 e da recepire negli ordinamenti nazionali entro il 9 dicembre 2026, data a partire dalla quale la vecchia direttiva del 1985 viene abrogata. La nuova PLD è stata pensata espressamente per il software, e include nella definizione di prodotto i file digitali, i componenti software, le applicazioni, i sistemi di intelligenza artificiale. È una delle più ambiziose riforme del diritto della responsabilità civile mai tentate dall’Unione Europea.

Il fatto che abbia richiesto quarant’anni per essere ripensata, e che nonostante lo sforzo enorme dei suoi estensori rischi di essere già inadeguata il giorno in cui entrerà in vigore, non è colpa di nessuno in particolare. È la conseguenza di un problema che il diritto non ha ancora saputo nominare con precisione. Il problema è che il «prodotto» su cui Lord Atkin e i suoi successori hanno costruito due secoli di giurisprudenza, nel software contemporaneo non c’è più.

Vale la pena prendersi un minuto per capire dove è andato a finire, perché la diagnosi è il punto di partenza di tutto ciò che segue.

Dal disco al concerto

Per molto tempo il software è stato un prodotto nel senso pieno e convenzionale del termine. Si è usciti dal laboratorio dei Bell Labs e si è entrati nella distribuzione di massa con Unix e poi con i sistemi operativi per personal computer.

Un applicativo degli anni Ottanta o Novanta era un insieme di file distribuito su floppy, poi su CD, poi su DVD, con un numero di versione, un hash identificativo, una copia conservabile in cassaforte. Se il software presentava un difetto, si poteva, almeno in teoria, isolare la versione esatta del binario, confrontarla con quella presunta corretta, identificare il bug. Windows 95 era un prodotto. Microsoft Word 97 era un prodotto. Persino un gioco come Baldur’s Gate era un prodotto, con le sue patch numerate e conservabili.

Certo, anche allora il software dipendeva da cose che non erano il prodotto in senso stretto — dai driver di periferica, dal firmware, dai protocolli di rete, dai servizi di sistema. Ma quelle dipendenze erano statiche, dichiarate, limitate nel numero, e soprattutto erano mediate da un artefatto autosufficiente che poteva essere conservato e riprodotto anche molti anni dopo. La copia del CD di Windows 95 che un archivista digitale conserva oggi è ancora identica a quella del 1995, bit per bit. Il prodotto, come oggetto dotato di continuità nel tempo, esisteva.

Nei primi anni Duemila qualcosa comincia a cambiare, e la velocità del cambiamento accelera in modo drammatico nel decennio successivo. La transizione al software as a service sposta l’applicazione dal disco locale del cliente al server del fornitore. All’inizio è una semplice questione di distribuzione, ma molto presto diventa una trasformazione ontologica.

Quando l’applicazione gira su un server remoto, la versione dell’applicazione che l’utente usa in un dato momento non è più una proprietà stabile, è una proprietà momentanea, rinegoziabile dal fornitore in qualsiasi istante senza neanche avvisare. Il continuous deployment porta questa fluidità al suo esito naturale, con aziende che pubblicano in produzione decine o centinaia di cambiamenti al giorno, senza che nessuno, neanche internamente, sia in grado di ricostruire con esattezza quale fosse la configurazione esatta del sistema alle quattordici e ventitré di un martedì di tre mesi fa.

Nel frattempo, e parallelamente, la composizione interna del software cambia natura. Dall’inizio degli anni Dieci, grazie agli ecosistemi come npm per JavaScript o Maven per Java o PyPI per Python, scrivere un’applicazione significa importare centinaia o migliaia di pacchetti di terze parti, ciascuno a sua volta composto da pacchetti di terze parti, in un grafo di dipendenze transitive che nessun essere umano legge interamente e che si aggiorna continuamente in modo asincrono rispetto al codice che si è scritto. Il caso di left-pad del 2016, quando un singolo sviluppatore cancellò dalla npm un pacchetto di undici righe di codice e rompendolo mandò in crash buona parte delle pipeline di build e dei processi di installazione del mondo JavaScript, fu il momento in cui l’industria si accorse, per un istante, di quanto fragile e distribuita fosse diventata la cosa che continuava a chiamare prodotto.

L’ultima accelerazione, quella che stiamo vivendo in questi mesi, è l’ingresso dei modelli linguistici nella catena produttiva del software. Qui il salto non è solo quantitativo ma categoriale, perché ciò che entra nel prodotto non è più un insieme di istruzioni deterministiche ma un componente probabilistico i cui output non sono riproducibili esattamente neanche dagli stessi input, e il cui peso, una volta scartato dal fornitore per passare al modello successivo, potrebbe non essere più accessibile.

Un’applicazione che gira oggi e usa le API di un modello frontier è un’applicazione il cui comportamento osservabile dipende da un componente che domani potrebbe comportarsi diversamente, che fra due anni potrebbe non esistere più in nessuna forma recuperabile, e il cui funzionamento interno non è ispezionabile da nessuno, neanche da chi lo ha addestrato. Chi lavora alla scrittura di software oggi sa perfettamente che se un utente di cinque anni fa ci chiedesse di riprodurre esattamente il bug che aveva visto allora, la risposta onesta sarebbe che non possiamo, perché il sistema che ha prodotto quel bug non esiste più in nessuna configurazione restorable. Le dipendenze sono state aggiornate, le API esterne hanno cambiato contratto, il database è stato migrato, il modello di AI è stato sostituito. Abbiamo i log. Abbiamo il codice della nostra applicazione. Ma l’evento che ha prodotto il bug era un concerto, e dei concerti restano le registrazioni, non i concerti.

Questa è la metafora che credo renda meglio il salto ontologico in corso. Il software contemporaneo non è più un disco, è un concerto.

Il disco è un artefatto stabile, conservabile, confrontabile, un oggetto con una sua identità nel tempo. Il concerto è un evento distribuito nello spazio e nel tempo, co-prodotto da molte agencies in tempo reale, irripetibile, del quale si possono avere tracce ma non originali. Quando riascoltiamo la registrazione di un concerto di Keith Jarrett del 1975 stiamo ascoltando un artefatto derivato, non stiamo ascoltando il concerto, che è avvenuto una volta sola ed è finito. Lo stesso vale per un’applicazione SaaS oggi.

Quello che l’utente ha vissuto ieri alle undici del mattino è un evento co-prodotto dall’applicazione, dal browser dell’utente, dalla latenza della rete, dalla versione corrente del modello LLM sottostante, dalla configurazione di dodici API di terze parti, da un rate limit che nel momento esatto aveva un certo valore. Quell’evento non è riproducibile, non è conservabile, non è ontologicamente un oggetto. È, appunto, un concerto.

L’obiezione e la copia che non c’è più

Qualcuno, a questo punto, potrebbe obiettare che la distinzione è esagerata, che in fondo anche nel 1998 il software girava su un sistema operativo che dipendeva da driver e da hardware, che la contingenza runtime esisteva anche allora, che ogni uso di un’applicazione è sempre stato in qualche misura un evento e non un oggetto.

L’obiezione è parzialmente corretta, e prenderla sul serio è importante, perché è l’unica via per evitare di trasformare la diagnosi in nostalgia. La differenza che cambia tutto, però, è una e sola, ed è la differenza che il diritto non ha ancora metabolizzato.

Nel 1998 esisteva sempre una copia dell’artefatto. Nel senso più stretto e concreto del termine, nella cassaforte del fornitore o nelle hard disk dell’utente o nell’archivio di un archivista digitale, c’era un oggetto materiale che conteneva il software nella sua forma autonoma. Quella copia era il punto di contatto tra il prodotto giuridico e l’evento esecutivo. Era il punto archimedeo che rendeva possibile tornare indietro, esaminare, confrontare, giudicare. Era ciò che permetteva al giurista di dire «questo prodotto era difettoso» perché un prodotto c’era.

Oggi quella copia non esiste più, e non esiste non per negligenza o per scelta cattiva, ma per costruzione. L’applicazione SaaS del fornitore X, alle quattordici e ventitré di un martedì di tre mesi fa, non esiste in nessun backup, in nessuna cassaforte, in nessun archivio. Esiste soltanto la possibilità di ricostruire, in modo approssimato e parziale, cosa dovesse essere stata, incrociando log, versioni del codice, configurazioni delle dipendenze, pesi dei modelli, stato del database.

È una ricostruzione archeologica, non un accesso all’oggetto. E quando anche questa ricostruzione fosse portata a termine, il risultato sarebbe un’altra cosa ancora, un modello dell’applicazione di quel momento, non l’applicazione di quel momento. Il prodotto, nel senso bicentenario del termine giuridico, è scomparso. Ciò che esiste al suo posto non è mai stato nominato.

Il corpus europeo e il suo disallineamento

Il legislatore europeo, bisogna riconoscerglielo, si è accorto che qualcosa non tornava. Negli ultimi anni ha prodotto un pacchetto impressionante di norme che cercano di afferrare il nuovo oggetto con gli strumenti a disposizione.

Il Cyber Resilience Act, entrato in vigore nel dicembre 2024 con applicazione piena nel dicembre 2027, introduce il concetto di security by design e security by default per i prodotti con elementi digitali, impone obblighi di supporto lungo tutto il ciclo di vita, richiede la fornitura di un Software Bill of Materials. La nuova Product Liability Directive, quella del 2024 che abbiamo citato all’inizio, estende esplicitamente la responsabilità ai difetti di cybersecurity e ai malfunzionamenti degli aggiornamenti software. L’Artificial Intelligence Act, in vigore dal 1° agosto 2024 con applicazione generale dal 2 agosto 2026 e alcune provisions che slittano al 2 agosto 2027, classifica i sistemi di AI per rischio e impone obblighi di documentazione, trasparenza, valutazione di conformità. A questi si aggiungono la NIS2 per la sicurezza delle reti, la DORA per il settore finanziario, il Data Act, l’European Accessibility Act.

Messi insieme, formano il corpus normativo più ambizioso mai costruito per disciplinare la produzione di software, e sono uno sforzo serio, tecnicamente informato, culturalmente importante. L’errore sarebbe banalizzarli come burocrazia o come freno all’innovazione, come fa una certa vulgata libertarian di matrice californiana. La tesi di questo saggio è invece che, pur essendo seri e pur essendo importanti, questi strumenti stanno cercando di catturare il concerto con le categorie del disco, e il disallineamento categoriale è destinato a generare conseguenze che cominciamo solo ora a intravedere.

Il caso del Software Bill of Materials è paradigmatico di questa difficoltà, ed è anche quello che conosco meglio per ragioni professionali. L’SBOM è un documento che elenca tutti i componenti che entrano in un software, le loro versioni, le loro dipendenze, le loro licenze. Sulla carta è uno strumento perfettamente sensato, l’equivalente software della lista degli ingredienti che troviamo sulle confezioni alimentari.

Nella pratica, l’SBOM è una fotografia di un concerto, con tutti i limiti epistemici che questa condizione porta con sé. Una fotografia del concerto non è il concerto, è già un altro oggetto, derivato, parziale, datato. Nel momento esatto in cui la fotografia viene scattata, il concerto sta già cambiando, e nel decimo di secondo successivo allo scatto le dipendenze transitive potrebbero già essersi aggiornate, la versione dell’API esterna potrebbe essere cambiata, il peso del modello potrebbe essere stato sostituito dal fornitore.

L’SBOM cattura uno stato, ma il software contemporaneo non ha stati stabili, ha soltanto flussi. La normativa chiede quindi agli sviluppatori di mantenere la fotografia aggiornata, il che genera processi di continuous SBOM generation, con tool che producono l’SBOM a ogni build, a ogni deploy, idealmente in tempo reale. Il risultato, paradossalmente, è che il documento che doveva catturare l’identità del prodotto si moltiplica in migliaia di snapshot giornalieri, ciascuno dei quali è già obsoleto nel momento in cui viene generato. L’SBOM non cattura il prodotto, perché il prodotto non c’è. L’SBOM cattura il flusso, in forma di fotogrammi discreti, e ogni fotogramma è un documento giuridicamente rilevante. Il carico documentale che ne deriva è enorme, e il suo valore probatorio, quando si tratta di ricostruire chi era responsabile di cosa in un momento preciso, è molto meno netto di quanto i legislatori abbiano assunto.

Lo stesso problema, aggravato dalla natura stocastica dei modelli, si pone per l’AI Act. L’articolo 10 chiede che i dataset di addestramento siano documentati, tracciabili, governati secondo criteri di qualità. L’articolo 15 chiede che i sistemi di AI ad alto rischio siano accurati, robusti, cibersicuri. L’articolo 72 richiede il monitoraggio post-market. Ciascuno di questi obblighi ha senso, preso isolatamente, e rinvia a pratiche che la migliore ingegneria del machine learning dovrebbe già adottare.

Quello che i legislatori non hanno pienamente assorbito è che il modello di linguaggio che un fornitore offre oggi tramite API è un oggetto la cui identità nel tempo è, nel migliore dei casi, convenzionale. Il peso del modello viene aggiornato, il sistema di RLHF raffinato, i guardrail modificati, e quello che continua a chiamarsi GPT-4 oppure Claude Opus o Gemini Ultra è, dal punto di vista del comportamento osservabile, un oggetto diverso da ciò che portava lo stesso nome sei mesi fa.

Chiedere la documentazione del training significa chiedere la documentazione di qualcosa che, nel momento in cui la documentazione viene prodotta, potrebbe essere già stato superato da un altro training. Il monitoraggio post-market è un’ottima pratica, ma presuppone un mercato in cui il prodotto sia lo stesso al momento della vendita e al momento dell’uso, il che per i modelli linguistici non è quasi mai vero.

Non si tratta di dire che l’AI Act è sbagliato, perché l’AI Act è una delle risposte regolamentari più articolate mai tentate su scala comparabile. Si tratta di dire che l’AI Act eredita dal diritto della responsabilità da prodotto una serie di presupposti ontologici che l’oggetto che cerca di regolare non soddisfa, e che la tensione tra i presupposti e l’oggetto si scaricherà nei prossimi anni sulle spalle dei practitioner, sotto forma di adempimenti che avranno un valore ambiguo, documenti il cui rapporto con la realtà sarà difficile da stabilire, controversie in cui il contenzioso tra le parti si ridurrà a una disputa sul fatto se un certo snapshot fosse rappresentativo del sistema nel momento del danno.

CrowdStrike, 19 luglio 2024

Un esempio recente, di portata tale da essere entrato nei corsi di risk management di tutto il mondo, aiuta a vedere in concreto cosa significhi tutto questo.

Il 19 luglio del 2024, un aggiornamento difettoso del sensore Falcon di CrowdStrike causò il crash simultaneo di circa otto milioni e mezzo di macchine Windows in tutto il pianeta, con un boot loop che richiedeva intervento manuale su ogni singolo dispositivo per essere risolto. Aeroporti fermi, ospedali che riconvertirono le operazioni in regime cartaceo, banche non operative, emittenti televisive bloccate, chiamate di emergenza non instradate. Delta Airlines da sola dichiarò oltre cinquecento milioni di dollari di danno diretto, le sole aziende Fortune 500 dichiararono perdite non assicurate nell’ordine dei cinque miliardi e mezzo, con stime globali che varie fonti collocano nell’ordine delle decine di miliardi.

Nel contenzioso seguito, che è tuttora aperto in varie giurisdizioni, l’intera questione si è concentrata sulla domanda seguente. Chi era responsabile.

• CrowdStrike, che aveva distribuito un aggiornamento contenente un difetto che sarebbe stato rilevato da qualunque test accurato.
• Microsoft, che aveva consentito a un software di terza parte di operare con privilegi kernel tali da poter mandare in boot loop il sistema operativo.
• Le organizzazioni deployer, che avevano accettato aggiornamenti in push automatico senza fasi di canary.
• Gli enti di regolamentazione europei, secondo la difesa di Microsoft, che anni prima avevano imposto al vendor l’apertura del kernel per ragioni di concorrenza.

Ciascuna di queste quattro attribuzioni di responsabilità, presa singolarmente, coglie un aspetto reale della vicenda. Nessuna, presa singolarmente, racconta l’accaduto. L’accaduto fu un fallimento dell’orchestrazione, un evento in cui molti attori avevano, ciascuno nel proprio grado, un’influenza effettiva sul comportamento runtime del sistema, e in cui nessuno aveva esercitato quell’influenza in modo proporzionato alle conseguenze possibili.

Il diritto attuale non ha strumenti adeguati per distribuire la responsabilità in questo modo, e il contenzioso sta di conseguenza scivolando verso scenari in cui vince chi ha gli avvocati migliori o chi occupa la posizione contrattuale più difendibile, il che è un altro modo per dire che il diritto ha rinunciato a dire qualcosa di sostantivo sull’incidente. Un caso come CrowdStrike, letto alla luce della categoria di assemblaggio responsabile che sto cercando di tratteggiare, avrebbe dovuto produrre una sentenza che distribuisse la responsabilità in quote identificabili tra i diversi attori in funzione del loro blast radius e del loro grado di controllo effettivo, e che creasse un precedente utilizzabile per gli incidenti futuri, che saranno certamente molti. Nulla di tutto questo sta accadendo, perché la categoria per farlo non c’è.

Latour, Ricœur e la pluralità dell’azione

Vale la pena, prima di andare oltre, chiarire che l’assemblaggio responsabile non è un’invenzione ex nihilo, ma l’adattamento al dominio giuridico di riflessioni che la filosofia del Novecento ha sviluppato in altri ambiti e che non hanno ancora fatto abbastanza strada nelle aule di tribunale.

Bruno Latour, con la actor-network theory, aveva già mostrato negli anni Ottanta che le azioni complesse non hanno mai un unico agente, ma emergono da reti di attori umani e non umani la cui analisi richiede di sospendere l’ossessione per il soggetto individuale e di seguire le connessioni effettive. Il suo esempio canonico del dosso artificiale, il cosiddetto sleeping policeman posto sul manto stradale, è illuminante, perché mostra come il dosso enforci il limite di velocità indipendentemente dalla presenza del poliziotto umano, agendo come attore non umano dotato di propria agency.

Il rallentamento dell’auto è co-prodotto dal guidatore, dal dosso, dal codice stradale, dalla paura di danneggiare la sospensione, dalla cultura condivisa che riconosce il dosso come segnale di cautela. Nessuno di questi attori, preso da solo, spiega il rallentare, e nessuno dei cinque, preso da solo, è pienamente responsabile di ciò che accade quando qualcosa va storto. Il diritto positivo tende a ritagliare la responsabilità sul guidatore per ragioni pratiche, ma la comprensione filosofica dell’evento richiede di vedere tutti e cinque insieme. Il passo che il diritto non ha ancora fatto, e che la filosofia ha fatto da quarant’anni, è accettare che questa distribuzione dell’agenzia sia la norma e non l’eccezione, e derivarne le conseguenze per l’attribuzione della responsabilità.

Paul Ricœur, in Soi-même comme un autre del 1990 e nella riflessione sull’imputabilità che ne è derivata, aveva aggiunto un tassello complementare, mostrando che l’atto di imputare una responsabilità è un atto narrativo, che richiede di ricostruire una storia plausibile di causazione, e che quando la storia plausibile coinvolge molti agenti la narrazione imputativa non può ridursi a un unico soggetto senza tradire la verità dell’evento. L’imputazione, per Ricœur, è un’ermeneutica della responsabilità, e come ogni ermeneutica richiede pazienza, ascolto dei diversi livelli, rifiuto delle semplificazioni.

Il diritto contemporaneo della responsabilità da prodotto semplifica troppo, e lo fa perché ha ereditato una grammatica narrativa ottocentesca in cui il produttore era uno, identificabile, imputabile. Ricostruire l’imputabilità per il software contemporaneo significa accettare la natura plurale dell’azione e restituirla anche nel testo della sentenza.

L’assemblaggio responsabile

Se ci si ferma qui, la diagnosi rischia di apparire pessimistica o puramente critica, nello stile di una certa letteratura tech-skeptical che si compiace delle difficoltà senza proporre nulla di costruttivo. Il punto che vorrei provare a sviluppare è esattamente opposto, perché se è vero che il concetto di prodotto non regge più la sua funzione di attribuzione di responsabilità, diventa necessario iniziare a immaginare quale potrebbe essere la categoria sostitutiva.

E questa è un’impresa intellettuale che non si può delegare né ai giuristi puri, che non hanno contatto con il runtime dei sistemi reali, né agli ingegneri puri, che tendono a considerare il diritto come un fastidio esterno piuttosto che come un tentativo di attribuire significato morale a ciò che fanno. La categoria sostitutiva deve essere pensata a quattro mani, da chi ha pratica del codice e lettura del diritto, e deve partire dalla constatazione che il software contemporaneo è un’orchestrazione, un assemblaggio, un evento distribuito, non un oggetto.

Propongo di chiamarla, provvisoriamente, assemblaggio responsabile, consapevole che il nome non è ancora definitivo e che la discussione sul nome è parte integrante della costruzione della cosa.

Che cosa sarebbe un assemblaggio responsabile, in prima approssimazione. Sarebbe una configurazione di componenti, umani e non umani, organizzati attorno a una funzione specifica offerta a un utente, di cui nessuno dei partecipanti detiene il controllo integrale ma ciascuno esercita un grado identificabile di influenza effettiva sul comportamento osservabile in runtime.

La responsabilità, in questa cornice, non segue più la titolarità formale, nello stile «chi è intestatario del contratto risponde di tutto», né segue l’origine storica dei componenti, nello stile «se un bug è nella libreria importata allora la colpa è del manutentore della libreria». La responsabilità segue il gradiente dell’influenza effettiva.

Chi ha potuto, nel momento del danno, modificare il comportamento del sistema con un’azione tecnica mirata, risponde proporzionalmente al grado di quella possibilità. Il fornitore del modello di AI che avrebbe potuto aggiornare i guardrail e non lo ha fatto risponde di una quota di responsabilità. L’integratore che ha scelto quel modello per una funzione sensibile senza valutare adeguatamente i rischi, pur avendo gli strumenti per farlo, risponde di un’altra quota. L’utente che ha configurato il sistema in modo anomalo, aggirando le avvertenze, risponde di una terza quota. Nessuno dei tre risponde di tutto, nessuno dei tre risponde di niente, ciascuno risponde della propria porzione di orchestrazione.

La formula è semplice da enunciare e infernalmente complessa da implementare, come è naturale che sia ogni categoria giuridica nuova nei suoi primi decenni.

Le obiezioni si presentano immediate, e vale la pena di scorrerle. La prima obiezione è che l’influenza effettiva è difficile da misurare, e che un sistema giuridico fondato su un concetto così sfuggente sarebbe fonte di incertezza. L’obiezione è vera ma meno grave di quanto sembri, perché già oggi il diritto della responsabilità civile opera con concetti sfuggenti come la colpa, la prevedibilità, la causazione adeguata, e ha sviluppato nel tempo strumenti operativi per trattarli.

L’influenza effettiva su un sistema distribuito è misurabile attraverso ciò che gli ingegneri chiamano blast radius, ovvero la stima dell’ampiezza delle conseguenze di un’azione tecnica. Un fornitore di API LLM ha un blast radius che comprende potenzialmente tutti i suoi integratori, perché una sua modifica si propaga istantaneamente. Un integratore ha un blast radius limitato ai propri utenti, che tuttavia può essere amplificato se la sua applicazione è a sua volta infrastruttura di altre applicazioni.

Esistono metriche tecniche, grossolane ma trattabili, per stimare il blast radius di ciascun attore, e la dottrina giuridica potrebbe costruirci sopra una tassonomia della responsabilità graduata. Non sarebbe più sfuggente di quanto lo fossero le dottrine della colpa aquiliana nell’Ottocento prima che decenni di giurisprudenza le rendessero operative.

Due deformazioni da resistere

La seconda obiezione è più politica e viene da due direzioni opposte, entrambe in qualche misura interessate.

La prima direzione è quella degli ambienti californiani della grande industria tech, che hanno costruito negli ultimi vent’anni una narrazione secondo cui la natura open source e componentizzata del software renderebbe impossibile attribuire responsabilità a qualcuno in particolare, e che dunque la responsabilità andrebbe limitata ai termini contrattuali esplicitamente accettati dalle parti. Secondo questa lettura, se un utente subisce un danno da un’applicazione che usa una libreria open source il cui autore è anonimo, e l’applicazione è a sua volta ospitata su un cloud il cui fornitore declina ogni responsabilità nei termini di servizio, allora nessuno risponde di niente, o meglio, risponde solo chi ha deliberatamente assunto la responsabilità firmando un contratto.

Questa è la dottrina dell’irresponsabilità distribuita, ed è una comoda rendita di posizione per chi occupa i nodi più centrali dell’orchestrazione, perché consente di incamerare il valore e di esternalizzare i rischi. L’assemblaggio responsabile si oppone frontalmente a questa dottrina, perché rifiuta l’idea che l’assenza di un titolare formale equivalga all’assenza di responsabilità sostanziale. Se il tuo modello è il componente critico di migliaia di applicazioni a valle, la tua responsabilità non dipende dal fatto che tu abbia o non abbia firmato un contratto con gli utenti finali di quelle applicazioni. Dipende dal tuo ruolo nell’orchestrazione, e quel ruolo è oggettivamente misurabile.

L’altra direzione da cui viene l’obiezione è quella del formalismo europeo continentale, che ha una tradizione opposta ma altrettanto problematica, e che potremmo chiamare la dottrina del titolare assoluto.

Secondo questa tradizione, il titolare del trattamento del dato, o il fornitore del servizio, o il deployer del sistema di AI, risponde di tutto ciò che accade nella catena, a prescindere da dove si sia originata la non conformità o il malfunzionamento. È una dottrina intuitivamente egualitaria, perché tutela l’utente assicurandogli che qualcuno, un’entità giuridica identificabile, risponderà sempre. Nella pratica, però, produce due distorsioni serie.

La prima è che scarica sul titolare una responsabilità di cui non ha il controllo tecnico, costringendolo a difendersi da contenziosi per malfunzionamenti originati da componenti che non ha scritto, non ha scelto, non può ispezionare. La seconda distorsione è che de-responsabilizza i nodi a monte della catena, cioè proprio quelli che hanno l’influenza più sistemica, perché sanno che la loro quota di responsabilità sarà scaricata formalmente sul deployer finale e che i tribunali continueranno a puntare il dito contro chi si trovava nella posizione più visibile.

L’assemblaggio responsabile si oppone anche a questa dottrina, perché la posizione formale del titolare non esaurisce la questione della responsabilità, e una distribuzione solo apparente del carico, che nei fatti si concentra sempre sul nodo più accessibile, mantiene le cose esattamente come sono nei rapporti di forza reali dell’industria.

La proposta, quindi, si trova in un territorio scomodo per entrambe le sensibilità prevalenti, e proprio per questo merita di essere articolata con qualche pazienza. Chi lavora nel software sa benissimo che l’idea secondo cui la responsabilità sia un fatto puramente contrattuale è una finzione utile per chi sta nella Silicon Valley e un’esperienza quotidiana di impotenza per chi sta a Pescara o a Milano o a Francoforte e deve consegnare un sistema che funziona davvero in un contesto di vincoli reali. Al tempo stesso, chi lavora con la compliance europea sa che la dottrina del titolare assoluto trasforma il deployer in un fusibile giuridico, la cui funzione economica è saltare quando il sistema si rompe, consentendo ai componenti a monte di continuare a produrre esternalità.

Il software contemporaneo ha bisogno di una categoria che non sia nessuna delle due, e che riesca a distribuire la responsabilità in modo che rifletta la distribuzione effettiva del potere tecnico. Non una distribuzione simmetrica, perché il potere tecnico non è distribuito simmetricamente. Non una concentrazione sul titolare, perché il potere tecnico non è concentrato sul titolare. Una distribuzione che segue il gradiente dell’influenza effettiva, con metriche trasparenti, con una dottrina pratica che i tribunali possano maneggiare, con una ratio che i practitioner possano riconoscere come aderente alla loro esperienza di lavoro.

Ci sono alcuni ambiti in cui qualcosa del genere sta già accadendo, anche se nessuno lo chiama così. Il GDPR, nel suo articolo 28 e nelle linee guida dell’EDPB sulla catena di sub-processor, ha iniziato timidamente a riconoscere la gradazione di responsabilità lungo la catena del trattamento, anche se in modo formalistico e senza l’apparato concettuale che sarebbe necessario. Le Data Protection Impact Assessment, quando vengono fatte seriamente e non come esercizio di compliance theatre, contengono in nuce il germe di un’analisi del blast radius applicata al dato personale.

La direttiva NIS2, sulla sicurezza delle reti, introduce obblighi per i fornitori di servizi gestiti che riconoscono il loro ruolo sistemico nella catena di sicurezza. La stessa AI Act, con la sua distinzione tra provider, deployer, importer, distributor, sta tentando una tassonomia dei ruoli che, pur ancora troppo rigida, va nella direzione di una distribuzione non titolare-centrica della responsabilità.

Nessuno di questi strumenti è ancora arrivato al punto di formulare esplicitamente il principio dell’influenza effettiva come gradiente di responsabilità, ma tutti contengono tracce di un ripensamento che aspetta soltanto una sistematizzazione dottrinale. L’impressione è che manchi qualcosa di simile a ciò che fu per Lord Atkin il neighbour principle, ovvero una formulazione sintetica, memorabile, operativa, che consenta di orientare cinquant’anni di giurisprudenza successiva. Chi scriverà quella formulazione avrà fatto per il ventunesimo secolo ciò che la House of Lords fece per il ventesimo.

Il punto è che, perché quella formulazione possa essere scritta, servirà una categoria di intellettuali che oggi praticamente non esiste. Non servono giuristi puri, perché la grammatica interna dei sistemi distribuiti contemporanei non si apprende nei corsi di diritto. Non servono ingegneri puri, perché la grammatica del diritto e la sua storia bicentenaria di categorie e controcategorie non si apprende nei corsi di computer science.

Servono ibridi, figure di confine che abbiano praticato entrambi i mestieri abbastanza a lungo da averne capito le logiche interne e i limiti, e che siano disposte a immaginare qualcosa che nessuno dei due corpus disciplinari, preso da solo, è in grado di immaginare. In Italia questa figura non ha ancora un nome consolidato. Nei paesi anglosassoni si è affermato negli ultimi anni il ruolo del compliance engineer o del technical counsel, ma sono ancora definizioni professionali che si limitano a mettere in comunicazione le due culture senza davvero costruire una terza.

Quello che serve è qualcosa di più ambizioso, una figura che non traduca soltanto il gergo tecnico in gergo giuridico e viceversa, ma che elabori categorie nuove capaci di dire cose che nessuno dei due gerghi originari, lasciato a se stesso, saprebbe dire. Il mestiere è in parte teorico, perché richiede una formazione filosofica che permetta di maneggiare categorie astratte, e in parte pratico, perché richiede l’esperienza quotidiana del deployment, della dipendenza transitiva, della retrocompatibilità rotta da un minor release del fornitore, dello stack trace ambiguo che non dice di chi sia la colpa. Senza l’esperienza pratica, le categorie astratte restano sospese nel vuoto. Senza la formazione astratta, l’esperienza pratica si esaurisce in stanchezza e in ticket chiusi.

La terza via è difficile, non perché richieda doti rare, ma perché il mercato del lavoro non la prezza, le università non la formano, le aziende non la organizzano. Esiste soltanto per volontà individuale, ed è proprio per questo che chi la pratica ha una responsabilità intellettuale sproporzionata rispetto alla sua posizione formale.

Dal Bill of Materials al Bill of Accountability

A questo punto è utile tornare al problema concreto da cui siamo partiti, cioè alla domanda di come si possa attribuire responsabilità per un danno causato da un software contemporaneo.

Se accettiamo che il software non è più un prodotto ma un assemblaggio, e che l’assemblaggio va analizzato secondo il gradiente dell’influenza effettiva, allora il primo passo operativo è costruire una pratica di documentazione dell’assemblaggio che non sia la fotografia statica dell’SBOM ma una mappa dinamica delle relazioni di influenza.

Uno strumento del genere dovrebbe permettere di rispondere, per ogni applicazione, a domande come queste.

• Quali componenti, se modificati, cambierebbero il comportamento osservabile del sistema.
• Quali attori hanno la capacità tecnica di modificare quei componenti.
• Quali sono gli obblighi contrattuali e normativi che gravano su ciascuno di quegli attori.
• Quali sono le evidenze, nei log e nei sistemi di audit, che permettono di ricostruire ex post lo stato del sistema in un momento specifico.
• Quali sono i canali di comunicazione attraverso cui un attore a valle può far arrivare un segnale di allarme a un attore a monte.
• Quali sono i tempi di risposta tipici lungo la catena.

Il documento risultante non sarebbe più un bill of materials, ma qualcosa di più simile a un bill of accountability, una mappa dei poteri e dei doveri lungo l’intera orchestrazione. Produrlo richiederebbe lavoro, richiederebbe cooperazione tra attori che non sempre hanno interesse a cooperare, richiederebbe norme che ne imponessero la produzione. Ma sarebbe uno strumento che nominerebbe il problema per ciò che è, invece di cercare di ridurlo a un problema di inventario.

Tre conseguenze per chi sviluppa software

Dal punto di vista della pratica quotidiana di chi sviluppa software per committenti, questa riarticolazione avrebbe conseguenze importanti.

La prima conseguenza è che il contratto tipo, quello che oggi tende a scaricare tutta la responsabilità sul fornitore finale o, nei casi migliori, a limitarla al canone annuale pagato, diventerebbe un documento con una struttura completamente diversa. Il contratto andrebbe costruito a valle di un’analisi dell’orchestrazione, con una chiara articolazione di quali componenti il fornitore controlla e di quali soltanto integra, di quali rischi si assume pienamente e di quali si fa canale di trasferimento verso i fornitori a monte, di quali obblighi informativi accetta di onorare e di quali non è tecnicamente in grado di onorare. Sarebbe un contratto più lungo, più complesso, più onesto, e a lungo andare anche più difendibile in sede giudiziaria, perché racconterebbe la cosa per quello che è invece di fingerne una forma che non ha.

La seconda conseguenza è che il processo di sviluppo dovrebbe includere, fin dalle fasi iniziali, una riflessione sull’orchestrazione in cui il sistema si inserirà, non soltanto una riflessione sui requisiti funzionali.

• Chi sono gli attori a monte di cui dipenderemo.
• Che garanzie ci danno.
• Che blast radius hanno nei nostri confronti.
• Come verificheremo i loro cambiamenti.
• Come reagiremo se un loro cambiamento rompe il nostro comportamento atteso.

Queste domande, oggi, sono relegate a qualche slide in fase di architettura e poi dimenticate. In una cultura che prendesse sul serio l’assemblaggio responsabile, sarebbero parte integrante della specifica, e la loro assenza in una documentazione di progetto sarebbe un indicatore di immaturità come lo è oggi l’assenza di una threat model.

La terza conseguenza è forse la più interessante dal punto di vista culturale, e tocca direttamente il modo in cui si formano gli sviluppatori. Oggi si impara a scrivere codice che funziona, poi si impara, se si è fortunati, a scrivere codice che funziona in produzione. Quasi nessuno impara a scrivere codice che funziona all’interno di un’orchestrazione di cui è consapevole.

La consapevolezza dell’orchestrazione arriva tardi, spesso per via di un incidente, raramente come competenza esplicitata e insegnata. Una formazione che prendesse sul serio la natura distribuita del software contemporaneo dovrebbe partire da qui, dovrebbe mostrare fin dal primo giorno che scrivere un’API significa entrare in un’orchestrazione, che scegliere una libreria significa accettare un fornitore a monte, che deployare in cloud significa ospitarsi in un’infrastruttura le cui decisioni architetturali sono altrove.

Non si tratta di terrorizzare i giovani sviluppatori, ma di abituarli a vedere ciò che vedono gli sviluppatori esperti dopo vent’anni di cicatrici. L’orchestrazione è l’oggetto del loro lavoro, non uno sfondo. Il codice che scrivono è una partecipazione a un concerto, non un oggetto autosufficiente. Se crescono con questa consapevolezza, la questione della responsabilità non arriverà come un fastidio esterno, arriverà come una dimensione intrinseca del mestiere.

Quando anche la scrittura è orchestrazione

A chi sospetta che tutto questo sia esagerato dalla lente del software as a service e che nei contesti più semplici la categoria di prodotto possa ancora reggere, conviene rispondere che la direzione in cui si sta muovendo lo sviluppo AI-nativo rende il problema più acuto e non meno.

Quando si lavora con strumenti come Claude Code o con pratiche come la specification-driven development alla SpecKit, il codice cessa di essere l’oggetto che lo sviluppatore scrive direttamente e diventa l’output di una catena di generazione che parte dalla specifica, passa per un modello, produce un artefatto e lo integra in un’orchestrazione già di per sé distribuita. La specifica scritta ieri e il codice generato ieri, se rigenerati oggi dallo stesso modello, produrrebbero un codice plausibilmente simile ma non identico, perché il modello nel frattempo è cambiato.

Il concetto di versione, già indebolito dal continuous deployment, diventa in questo contesto ancora più instabile, perché ora non è più instabile soltanto nel tempo di esecuzione ma anche nel tempo di scrittura. Chi sviluppa in questo modo sa che la riproducibilità esatta è un orizzonte regolativo, non una proprietà effettiva dei suoi artefatti.

L’assemblaggio responsabile, in un mondo in cui anche la scrittura del codice è un’orchestrazione tra sviluppatore, specifica, modello, toolchain e pipeline, diventa la categoria naturale per pensare la responsabilità, perché è l’unica in cui l’assenza di un autore monolitico non si traduce automaticamente nell’assenza di imputabilità.

La morte di una categoria

Resta una domanda a cui il saggio deve rispondere, perché è la domanda che un lettore paziente avrà tenuto in sospeso fin dall’inizio. La domanda è se davvero abbia senso parlare della morte di una categoria giuridica, o se non stiamo soltanto descrivendo un’evoluzione, una trasformazione, un aggiornamento.

Il linguaggio della morte è forte, e potrebbe sembrare esagerato. La giustificazione che offro è che una categoria giuridica muore nel senso in cui lo aveva detto Foucault parlando di categorie più generali, ovvero quando smette di organizzare il campo discorsivo in modo produttivo e comincia a ostacolarlo.

Il concetto di prodotto, applicato al software contemporaneo, non organizza più il campo, lo ostacola. Produce adempimenti che non corrispondono a pratiche, documenti che non rappresentano oggetti, contenziosi che si incagliano sulla definizione dell’oggetto prima di potersi occupare della sostanza.

Un concetto che ostacola il campo non è un concetto utile, anche se continua a essere formalmente in vigore. Il concetto di etere luminifero, nella fisica di fine Ottocento, non era sbagliato nel senso in cui possono esserlo le affermazioni singolari, era un concetto che aveva smesso di organizzare produttivamente il campo e si era messo a ostacolarlo, finché Einstein non lo ha semplicemente rimosso.

Il concetto di prodotto, nel diritto contemporaneo del software, si trova in una fase comparabile. È ancora lì, è ancora nei testi normativi, è ancora nelle aule giudiziarie. Ma non lavora più. E fingere che lavori è più pericoloso che ammettere che non lo fa.

Non sto dicendo, sia chiaro, che il legislatore europeo avrebbe dovuto aspettare di avere la categoria giusta prima di intervenire. La posizione sarebbe stata intellettualmente pura e politicamente impresentabile, e comunque il danno prodotto dall’assenza di regolamentazione sarebbe stato maggiore del danno prodotto da una regolamentazione categorialmente imperfetta.

Sto dicendo, più modestamente, che la regolamentazione attuale è un work in progress, che la sua imperfezione categoriale va riconosciuta apertamente, e che la costruzione della categoria sostitutiva è un compito che non compete solo ai legislatori ma anche a chi nel software lavora quotidianamente e a chi sulla filosofia del diritto ha gli strumenti per pensare. Chi ha entrambi i piedi dentro può contribuire più di chi ne ha uno solo. E il contributo non è un esercizio accademico, perché ogni anno che passa senza che la categoria sostitutiva emerga è un anno in cui il contenzioso si risolve per vie formali che non rispecchiano le responsabilità sostanziali, è un anno in cui i fornitori a monte continuano a trasferire rischio senza pagarne il prezzo, è un anno in cui i deployer finali continuano a fare da fusibili senza che il sistema nel suo insieme migliori.

La stanza di Lord Atkin

Mi sono dilungato, e chi mi ha seguito fin qui merita almeno una sintesi onesta di dove siamo arrivati.

Siamo arrivati a dire che il concetto giuridico di prodotto, costruito nel Novecento su un’ontologia di oggetti bounded, preservabili, identificabili, è insufficiente per il software contemporaneo, che è invece un’orchestrazione di componenti umani e non umani, un evento distribuito più che un oggetto, un concerto più che un disco.

Siamo arrivati a dire che la regolamentazione europea, pur essendo lo sforzo più serio mai tentato, sta cercando di catturare il concerto con le categorie del disco e che questa tensione produce adempimenti il cui valore giuridico sostanziale è ambiguo.

Siamo arrivati a dire che, al posto della categoria di prodotto, serve costruirne una nuova, provvisoriamente chiamabile assemblaggio responsabile, che distribuisca la responsabilità secondo il gradiente dell’influenza effettiva in runtime e non secondo la titolarità formale né secondo l’irresponsabilità distribuita.

Siamo arrivati a dire che questa costruzione richiede una figura intellettuale ibrida, con pratica del codice e lettura del diritto, che il mercato non prezza e che esiste soltanto per volontà individuale di chi la pratica.

E siamo arrivati a dire che, finché la categoria sostitutiva non emerge, i contenziosi continueranno a scaricarsi per vie formali che non rispecchiano le responsabilità sostanziali, con costi reali per chi fa il mestiere onestamente.

Il punto che forse vale la pena fissare, alla fine di tutto questo, è che Lord Atkin nel 1932 non era un giurista puro, era un giudice che aveva visto molte bottiglie rompersi e molte persone ammalarsi, e aveva capito qualcosa di pratico sul mondo industriale che lo strumentario concettuale precedente non riusciva a dire.

La sentenza Donoghue v. Stevenson fu possibile perché qualcuno aveva tenuto insieme, in una sola testa, l’esperienza materiale del mondo industriale e la tradizione concettuale del diritto civile. Oggi c’è bisogno di tenere insieme, in una sola testa, l’esperienza materiale dei sistemi distribuiti e la tradizione concettuale del diritto della responsabilità. Non è un compito che si possa delegare a nessuno, e non è nemmeno un compito che si possa finire in un solo saggio. Ciò che si può fare, con un saggio, è provare a nominare il problema, offrire una direzione, invitare chi ha strumenti simili ai miei a continuare il lavoro.

La bottiglia di Mrs. Donoghue era opaca, e dentro c’era una lumaca che nessuno aveva visto. Il software contemporaneo è ancora più opaco, e dentro ci sono molte più lumache, e la giurisprudenza che ci protegge è stata scritta per un mondo in cui le bottiglie erano di vetro. È arrivato il tempo di scrivere la giurisprudenza di un mondo in cui le bottiglie non ci sono più.

L'autore

Andrea MargiovanniCompliance EU

Lavoro a fianco di team che disegnano sistemi sotto AI Act, CRA, NIS2, GDPR. La regola non è una checklist: è un vincolo architetturale, e va portato a bordo prima del design, non dopo.

Vai al percorso →