Omissis

Poco dopo le tre di notte del 31 ottobre 2025, sulla Loop 202 in direzione est, all’altezza dell’uscita di Dobson Road, a Mesa, in Arizona, una Tesla Model 3 è ferma in una corsia di marcia. Non sul bordo, non nella corsia di emergenza. In corsia, con il buio intorno e la velocità di crociera di chi arriva da dietro. Un Ford F-350 la prende in pieno. Il conducente della Tesla muore sul posto. La Red Mountain Freeway resta chiusa per un paio d’ore e riapre verso le sei meno un quarto, in tempo per il traffico del venerdì mattina.

La cronaca locale fa il suo lavoro, che alle quattro e mezza di notte è poco. Arizona’s Family scrive che i dettagli sono limitati, che un portavoce del Department of Public Safety parla di due veicoli coinvolti e non fornisce informazioni sui feriti. 12News, più tardi, aggiunge che la berlina era una Tesla, che il pick-up era un Ford F-350 e che il conducente è morto. Nessuno dei due nomina un sistema di assistenza alla guida. Non perché lo nasconda. Perché non lo sa. Alle tre di notte un’auto ferma in autostrada è un’auto ferma in autostrada.

Poi c’è il secondo documento, che nessuno legge il 31 ottobre e che esiste per un obbligo federale. Dal 2021 la NHTSA, l’agenzia americana per la sicurezza stradale, impone ai costruttori uno Standing General Order: ogni incidente in cui un sistema di assistenza alla guida di livello 2 risulta attivo nei trenta secondi precedenti l’impatto va segnalato, e se c’è un morto va segnalato entro cinque giorni. Tesla segnala. Nel report il veicolo è una Model 3 del 2020. Il campo che descrive lo stato del sistema dice Verified Engaged. Il movimento prima dell’urto dice Stopped. La velocità dice 0 mph. Meteo sereno, nessuna anomalia della strada. L’auto è stata colpita su tutta la parte posteriore dal frontale del pick-up. Tesla dichiara inoltre di essere in possesso dei dati dell’event data recorder, della telematica e del video.

E poi tre campi neri. La narrativa dell’incidente, che spiegherebbe perché l’auto fosse ferma. La versione del software, che direbbe se era attivo Autopilot o il Full Self-Driving. Il campo che indica se quel tratto di strada rientrasse nell’area operativa approvata del sistema. Su tutti e tre la stessa dicitura, che vale la pena riportare per intero perché è il vero soggetto di questo saggio: REDACTED, MAY CONTAIN CONFIDENTIAL BUSINESS INFORMATION. Informazione commerciale riservata. Omissis.

Nessuno ha collegato il report all’incidente per dieci mesi. L’ha fatto Electrek il 31 agosto 2026, incrociando i pochi campi che la NHTSA lascia leggibili, città, veicolo, mese e un orario registrato in UTC, con le cronache locali. Convertito nel fuso dell’Arizona, il timestamp del report cade poco dopo le tre di notte del 31 ottobre, sulla stessa autostrada, con lo stesso esito e la stessa Model 3 del 2020. Il collegamento tra la morte di un uomo e il fatto che il suo sistema di guida fosse attivo l’ha fatto un cronista con un foglio di calcolo e una conversione di fuso orario. Non il meccanismo di trasparenza, che era stato progettato apposta. Electrek ha poi presentato una richiesta di accesso agli atti al DPS dell’Arizona e ha contattato l’agenzia per chiederle se il costruttore le avesse mai comunicato quello che aveva dichiarato alla NHTSA, e cioè che il sistema era attivo.

Ed è il secondo caso con la stessa impronta. Il 6 ottobre 2025, verso le nove e venti di sera, sulla I-4 in Florida, all’altezza di Lake Mary Boulevard, nella contea di Seminole, un’altra Model 3 del 2020 è ferma nella corsia centrale in direzione est. Un camion cerca di evitarla, la colpisce di striscio, finisce contro il guardrail e si ribalta. La Tesla viene spinta contro un secondo camion. Il conducente, un uomo di quarantatré anni di Deltona, muore sul posto. La Florida Highway Patrol dichiara di non sapere perché l’auto fosse ferma in mezzo all’interstatale. Il report di Tesla alla NHTSA dice, anche qui, Verified Engaged, Stopped, 0 mph. Anche qui la narrativa, la versione software e il campo sull’area operativa sono neri.

Tra la Florida e l’Arizona passano venticinque giorni.

Il fastidio che voglio lasciare addosso a chi legge non riguarda la colpa. Riguarda una domanda più semplice e più difficile da mandare via. Perché non si può sapere.

Due ipotesi, entrambe scomode

La prima ipotesi è quella che chiunque abbia seguito Tesla negli ultimi anni formula da solo. Il phantom braking, la frenata improvvisa senza ostacolo, è un problema documentato. La NHTSA ha aperto un’indagine preliminare nel febbraio 2022, sulla base di 354 segnalazioni relative a Model 3 e Model Y del 2021 e 2022, salite a 758 già a maggio dello stesso anno. Una class action è pendente davanti al tribunale federale dell’Illinois settentrionale dal 2023. Il fascicolo però va letto fino in fondo, perché contiene un dettaglio che complica il quadro invece di semplificarlo. L’indagine è stata chiusa il 29 giugno 2026 senza alcun intervento del costruttore, e la relazione di chiusura descrive un fenomeno tipico: una riduzione di velocità tra dieci e venti miglia orarie, in un intervallo da uno a tre secondi, che il conducente supera premendo l’acceleratore. Nessuna collisione identificata, nessun veicolo arrivato a fermarsi del tutto. Un’auto ferma a zero in corsia somiglia al phantom braking che la NHTSA ha catalogato, e nessuno, fuori da Tesla, ha visto il fenomeno abbastanza da vicino per dire se sia la stessa cosa.

La seconda ipotesi è più prosaica ed è quella che, alle tre di notte, un poliziotto stradale considera per prima. Un malore. Un colpo di sonno. Il conducente smette di rispondere, il sistema si accorge di non avere più nessuno con cui parlare e fa quello che è progettato per fare: rallenta fino a fermarsi e tiene l’auto dov’è. Non è un’ipotesi remota. Alle tre di notte è forse la più probabile.

Qui bisogna resistere alla tentazione di usarla come assoluzione. Un sistema di livello 2 che, perso il conducente, lascia il veicolo fermo in una corsia di marcia di un’autostrada, al buio, senza portarsi sulla corsia di emergenza e senza segnalarsi in modo che chi arriva a cento all’ora lo veda, ha un problema di progettazione del degradamento. Quella che gli standard chiamano condizione di rischio minimo, il posto in cui un sistema porta il veicolo quando non può più continuare, per i sistemi di livello 2 non è nemmeno definita, perché in teoria il conducente è sempre responsabile. In pratica, quando il conducente non c’è più, cosa fa l’auto lo decide il costruttore, e lo decide per tutti i suoi clienti in una volta. Se quella decisione è fermarsi dove ci si trova, l’ipotesi del malore non chiude la questione. La sposta dal software che guida al software che decide cosa fare quando la guida finisce.

Le due ipotesi si distinguono in un solo modo. Il log. Il video. La telematica. La sequenza degli input del conducente negli ultimi trenta secondi, il momento in cui il sistema ha deciso di frenare e il perché, la versione del software che ha preso quella decisione. Tutto questo esiste, Tesla dichiara nel report stesso di averlo, e tutto questo è ciò che il report non contiene.

Va detta una cosa su Electrek, prima di andare avanti. La testata ha una linea editoriale dichiaratamente ostile a Tesla, e l’articolo su Mesa fa parte di un’inchiesta a puntate, con una pagina di raccolta, che punta a ricostruire uno per uno i casi mortali che il costruttore ha segnalato alla NHTSA con la narrativa oscurata. Lo segnalo perché il lettore ha diritto di saperlo, e perché non cambia nulla. I campi neri sono nel documento della NHTSA, non nell’articolo. Chiunque può scaricare il file e contarli. Electrek lo ha fatto e ha trovato che Tesla oscura la narrativa nel 99,9% dei suoi report, che i suoi report sono circa l’85% di tutti quelli dell’industria, quasi quattromila incidenti, e che General Motors, Ford, Honda e Toyota non oscurano praticamente nulla. Il punto sulle omissioni regge a prescindere da chi lo solleva.

Un’altra cosa va detta, perché è la più scomoda per la tesi di questo pezzo. I tre campi che Tesla oscura sono esattamente i tre che lo Standing General Order permette di oscurare. L’ordine della NHTSA elenca tre eccezioni per cui un costruttore può chiedere il trattamento riservato: il nome della versione del sistema di automazione, l’indicazione se il veicolo fosse nel suo dominio operativo, la narrativa. Tutto il resto è pubblico per definizione. Tesla non ha violato la regola. Ha usato la regola fino in fondo, ogni volta. Il meccanismo di trasparenza contiene il buco al suo centro, ed è stato scritto così. La NHTSA ha aperto, nell’agosto 2025, un’audit query sulla tempestività con cui Tesla segnala questi incidenti, dopo aver trovato report arrivati diversi mesi dopo i fatti. È un’indagine su quando si segnala. Non tocca cosa si oscura.

Lo stesso report davanti a un giudice italiano

Il caso è statunitense, il diritto europeo non gli si applica e non gli si applicherà. Lo scrivo subito perché tutto quello che segue è un esperimento controfattuale, e voglio che sia dichiarato come tale. La domanda è cosa succederebbe alla stessa strategia difensiva, i dati li ho ma sono informazione commerciale riservata, se il prodotto fosse stato immesso sul mercato europeo dopo il 9 dicembre 2026 e la causa fosse davanti a un tribunale italiano.

Il 9 dicembre 2026 è la data in cui entra in applicazione la direttiva (UE) 2024/2853 sulla responsabilità per danno da prodotti difettosi, che sostituisce la direttiva del 1985 e che in Italia viene recepita riscrivendo gli articoli da 114 a 127 del Codice del consumo. Lo schema di decreto legislativo, l’Atto del Governo n. 434, è stato trasmesso alle Camere il 7 agosto ed è in questo momento all’esame delle commissioni per il parere. Ci torno alla fine, perché la finestra in cui si può ancora dire qualcosa è più corta di quanto si pensi.

La direttiva ha una fama, e la fama è che sia uno strumento risarcitorio. Estende la nozione di prodotto al software, allunga i termini, toglie la franchigia, aggiunge la distruzione e la corruzione dei dati tra i danni risarcibili. Chi la critica dice, con qualche ragione, che è una partita di giro tra assicurazioni, che il risarcimento arriva sempre dopo e che dopo non serve a nessuno. Chi la difende elenca i danneggiati che finalmente potranno essere pagati. Entrambi guardano al momento in cui si stacca l’assegno.

Il meccanismo che conta è un altro e sta in due articoli che si leggono insieme. L’articolo 9 stabilisce che, su richiesta di chi ha presentato fatti e prove sufficienti a rendere plausibile la domanda, il convenuto è tenuto a divulgare gli elementi di prova pertinenti che ha a disposizione, nei limiti di quanto è necessario e proporzionato, con misure specifiche per proteggere i segreti commerciali. L’articolo 10, paragrafo 2, lettera a), stabilisce che se il convenuto omette di divulgare quegli elementi, il carattere difettoso del prodotto si presume. Nello schema italiano sono gli articoli 119 e 120 del nuovo Codice del consumo, e la formulazione è quasi identica.

Rileggiamo il report della NHTSA con questi due articoli accanto. La famiglia del conducente porta in tribunale il documento stesso del costruttore: sistema verificato attivo, auto ferma a zero in corsia, meteo sereno, il costruttore dichiara di possedere registratore, telematica e video. Fatti e prove sufficienti a rendere plausibile la domanda, difficile sostenere il contrario. Il giudice ordina la divulgazione. A questo punto la frase «informazione commerciale riservata» cambia natura. Davanti alla NHTSA è una casella che si spunta e che nessuno valuta. Davanti a un giudice italiano dopo il 9 dicembre è una richiesta di misure di riservatezza, che l’articolo 9 prevede e concede, e non un motivo per non consegnare. Se il costruttore decide comunque di non consegnare, il prodotto è difettoso per presunzione, e tocca a lui dimostrare il contrario senza i dati che ha scelto di tenere nel cassetto.

Il segreto industriale, in questo schema, smette di essere una difesa. Diventa al massimo una modalità di consegna.

Punire quello che sapevi, o quello che non sai dire

Chi si occupa di responsabilità civile da abbastanza tempo sorride quando sente dire che una regola di responsabilità rende i prodotti più sicuri. Ha buone ragioni. Quarant’anni di letteratura sulla malpractice sanitaria dicono che il timore della causa produce medicina difensiva più spesso di quanta ne produca sicura. In un’indagine pubblicata su JAMA nel 2005, il 93% degli specialisti ad alto rischio intervistati in Pennsylvania dichiarava di praticare medicina difensiva, e il 43% di prescrivere esami di imaging clinicamente inutili. Kessler e McClellan, nel 1996, avevano mostrato che le riforme che riducono la pressione della responsabilità sui medici tagliano la spesa tra il 5 e il 9% senza effetti apprezzabili su mortalità e complicanze. In Italia una commissione parlamentare d’inchiesta stimò nel 2013 che la medicina difensiva pesasse per il 10,5% della spesa sanitaria, oltre dieci miliardi l’anno. L’argomento è serio, chi legge lo sa, e non va liquidato.

Vale la pena però isolare il perché. La regola di responsabilità classica punisce quello che sapevi. Il medico risponde se ha trascurato un sintomo che aveva davanti, il costruttore se ha ignorato un difetto che conosceva. Da qui l’incentivo perverso, che è la vera radice della medicina difensiva e dell’ingegneria difensiva: non guardare. Non fare l’esame che potresti fallire. Non conservare il log che potrebbe finire agli atti. Non scrivere il post-mortem in un formato che un avvocato avversario possa citare. Ogni ingegnere che ha lavorato in un’azienda con un ufficio legale attivo ha sentito almeno una volta il consiglio di non mettere per iscritto una certa cosa. Il consiglio è razionale, dentro quella regola.

La presunzione dell’articolo 10 fa una cosa diversa, e credo che sia la cosa più importante scritta nella direttiva. Punisce il non essere in grado di dire. Il costruttore che non produce i dati non viene sanzionato per ciò che i dati avrebbero rivelato. Viene messo nella posizione di chi ha già perso il primo round, qualunque cosa ci fosse nei dati. Il segno dell’incentivo si capovolge. Non guardare smette di essere una posizione difensiva e diventa un’ammissione. Il log che non hai conservato smette di essere quello che non può farti male e diventa quello che ti condanna per assenza. Il consiglio dell’ufficio legale, dentro questa regola, cambia verso: conserva tutto, e conservalo in una forma che possiamo consegnare.

A questo si aggiunge il quarto paragrafo dello stesso articolo, che vale la pena leggere per quello che dice del software. Quando il danneggiato incontra difficoltà eccessive a provare il difetto o il nesso causale, in particolare per la complessità tecnica o scientifica del prodotto, e dimostra che è probabile che il prodotto fosse difettoso, il giudice presume il difetto. Il considerando 48 aggiunge che, nel caso di un sistema di intelligenza artificiale, al danneggiato non si può chiedere di spiegare il funzionamento interno del sistema. La complessità, che per trent’anni è stata lo scudo più efficace di chi produce software, smette di esserlo. Il giudice non diventa un ingegnere. Semplicemente, la difficoltà di capire il prodotto torna a carico di chi lo ha costruito e lo capisce.

Poi c’è il tempo, ed è il punto che regge tutto il resto. La presunzione opera prima del giudizio di merito. Non alla fine della causa, dopo le perizie e i rinvii. All’inizio, nel momento in cui il giudice decide chi deve provare cosa. Questo cambia la convenienza del produttore in un modo concreto: mettere i dati sul tavolo nelle settimane successive al fatto, quando è ancora possibile spiegare, costa meno che difenderne l’assenza per anni. E le settimane sono l’unità di misura che qui interessa. La prima morte non si annulla con un risarcimento. La seconda si evita, se i dati della prima diventano leggibili in tempo utile. Tra la I-4 e la Loop 202 sono passati venticinque giorni. Nessuno, fuori dal costruttore, ha avuto in quei venticinque giorni gli elementi per chiedersi se il secondo caso somigliasse al primo. Il costruttore li aveva.

Questo è il punto che né i critici né i difensori della direttiva mettono al centro. Non è una legge sulla sanzione. È una legge sulla leggibilità.

Quello che l’ingegneria seria fa già

Adesso la traduzione, perché un saggio che si ferma al principio è un saggio che nessuno inoltra ai colleghi.

La frase che vorrei far uscire da questa sezione è semplice. La direttiva rende obbligatorio quello che l’ingegneria seria fa già. Chi protesta per l’onere sta protestando, in sostanza, per la richiesta di sapere cosa fa il proprio software. Detto questo, conviene elencare cosa significa in pratica, con accanto l’articolo che lo rende esigibile.

L’osservabilità diventa un artefatto giuridico. Fin qui i log, le tracce, le metriche erano una comodità delle operazioni, qualcosa che si configurava per fare debug e si ruotava dopo trenta giorni per risparmiare spazio. L’articolo 9 li trasforma in elementi di prova che il convenuto ha a disposizione, e il considerando 42 aggiunge che tra gli elementi da divulgare rientrano anche documenti da creare ex novo compilando e classificando quelli esistenti. Il criterio di qualità cambia. Non basta più riuscire a fare debug. Bisogna riuscire a spiegarlo a un consulente tecnico d’ufficio tra sei anni. Il che vuol dire log che sopravvivono alla rotazione, per un orizzonte che copra almeno i dieci anni del termine di decadenza, timestamp affidabili e in un fuso dichiarato (l’inchiesta di Electrek è stata resa possibile da un orario in UTC, e sarebbe stata impossibile senza), tracciabilità delle decisioni del sistema che resti intelligibile a chi non l’ha scritto. L’articolo 9, paragrafo 6, consente al giudice di chiedere che le prove siano presentate in modo facilmente accessibile e comprensibile. Un dump di tre terabyte di eventi binari senza schema equivale a non consegnare.

Il versioning e la provenance diventano una domanda con obbligo di risposta. Quale build girava in quel momento, con quali dipendenze, con quale configurazione, con quale modello. Nel report della NHTSA la versione del software è uno dei tre campi neri, ed è il campo che direbbe se il sistema attivo fosse Autopilot o Full Self-Driving, due prodotti con capacità e dominio operativo diversi. Il termine di decadenza della direttiva è di dieci anni dall’immissione sul mercato, e nei casi di lesioni personali che si manifestano dopo un lungo periodo di latenza arriva a venticinque. Chi lavora con la Software Bill of Materials per il Cyber Resilience Act ha già metà dell’infrastruttura: manifesti dei componenti, build riproducibili, immutabilità degli artefatti. L’altra metà è la ritenzione, e la ritenzione è una decisione di budget che oggi quasi nessuno prende a dieci anni. Ho scritto altrove che la compliance europea fallisce per mancanza di inventario più che per mancanza di norme. La direttiva aggiunge una cosa a quell’argomento: l’inventario deve avere una data, e la data deve essere difendibile.

Il pezzo che riguarda l’intelligenza artificiale è quello dove la direttiva è più esplicita di quanto ci si aspetti da un testo sulla responsabilità da prodotto. L’articolo 7, paragrafo 2, elenca tra le circostanze per valutare la difettosità gli effetti sul prodotto della sua capacità di continuare a imparare o acquisire nuove funzionalità dopo l’immissione sul mercato, e il momento in cui il prodotto è uscito dal controllo del fabbricante quando il fabbricante mantiene il controllo dopo la vendita. Il considerando 32 lo dice senza giri di parole: un fabbricante che progetta un prodotto in grado di sviluppare un comportamento inatteso resta responsabile dei comportamenti che causano danni. L’articolo 11, paragrafo 2, chiude la via di fuga classica, quella del difetto sopravvenuto: l’esenzione non vale se il difetto dipende dal software, dagli aggiornamenti o dalla loro mancanza, finché il prodotto è sotto il controllo del fabbricante. E il considerando 19 chiarisce che un prodotto resta sotto il controllo del fabbricante finché il fabbricante conserva la capacità di fornire aggiornamenti. Un modello che deriva è un prodotto che cambia dopo essere uscito dalle tue mani, e la direttiva non ti libera finché tieni la chiave. In termini operativi: snapshot delle valutazioni a ogni rilascio, model card versionate, monitoraggio della deriva con soglie documentate, e soprattutto la capacità di ricostruire cosa avrebbe risposto quel modello, su quell’input, a quella data. Nessuna di queste è una richiesta esotica: ogni team che fa fine-tuning serio le fa già per sé, quando un cliente chiede perché il sistema ha cambiato idea tra martedì e giovedì.

Poi la convergenza, che è il motivo per cui questo saggio sta su un blog che parla di compliance come architettura. Il Cyber Resilience Act e NIS2 impongono obblighi attivi prima del danno: gestione delle vulnerabilità, aggiornamenti di sicurezza per il periodo di supporto, notifica degli incidenti in ventiquattro ore. La direttiva sulla responsabilità da prodotto interviene dopo, sul danno già avvenuto, e la mancata fornitura degli aggiornamenti necessari a mantenere la sicurezza è, nell’articolo 11, esattamente una delle cose per cui non ci si può esentare. L’articolo 7 aggiunge tra i criteri di difettosità i requisiti di cibersicurezza rilevanti per la sicurezza. Le tre norme si tengono. La conformità alle prime due è la difesa migliore contro la presunzione della terza, perché produce, come sottoprodotto, la documentazione che l’articolo 9 chiede di divulgare. Chi ha costruito la SBOM per il CRA ha già la risposta alla domanda su cosa c’era dentro il prodotto a quella data. Chi tiene il registro degli incidenti per NIS2 ha già la risposta alla domanda su quando ha saputo. Il costo marginale della terza norma, per chi ha fatto sul serio le prime due, è basso.

Il rovescio della medaglia va detto, altrimenti la sezione successiva perde credibilità prima di cominciare. Tutto questo ha un costo reale. Conservare log strutturati per dieci anni costa in storage e in cifratura. Rendere riproducibile una build costa in tempo di pipeline e in disciplina. Versionare un modello con le sue valutazioni costa in ore di persone che preferirebbero addestrare il prossimo. Scrivere una documentazione tecnica che regga davanti a un consulente d’ufficio, e non solo davanti al collega che l’ha scritta con te, costa in una competenza che il mercato oggi non prezza e che quasi nessuno insegna. In una software house di dieci persone, quella in cui lavoro, questi costi non si spalmano su un ufficio legale interno. Si sottraggono alle stesse ore in cui si scrive il prodotto. Non c’è modo di edulcorarlo, e non ci provo.

Le obiezioni che meritano una risposta

Senza questa sezione il saggio sarebbe un pamphlet. Le obiezioni che seguono non sono uomini di paglia. Sono le cose che mi sono sentito dire, in ordine di forza.

La prima è che la responsabilità civile non ha mai salvato nessuno. È l’obiezione più forte e l’ho affrontata sopra, quindi qui aggiungo solo la parte che non ho detto. È vera per la responsabilità che punisce ciò che sapevi. Non ho prove che sia vera per una responsabilità che punisce ciò che non sai dire, perché quella regola non è mai stata applicata su scala al software, e vedremo dal 2027 se produce quello che la sua struttura fa sperare. Sono disposto a sbagliarmi. Non sono disposto a trattare la letteratura sulla malpractice come se parlasse di una regola che non è la stessa.

La seconda è che il termine lungo e il software come prodotto schiacciano le piccole imprese. Va concessa, perché è vera. L’onere pesa in modo asimmetrico. Il gigante lo assorbe con un ufficio legale e un budget di ritenzione che non si nota a bilancio. La software house da dieci persone no. Un termine di venticinque anni, anche se limitato ai casi di lesioni personali a latenza lunga, e quindi in pratica al medicale e a poco altro, è un orizzonte che nessuna piccola impresa italiana ha mai dovuto pianificare. Aggiungo che la relazione del governo allo schema di decreto riporta che le associazioni delle vittime dei farmaci hanno rappresentato l’inadeguatezza anche dei termini di tre e dieci anni, il che dice qualcosa sulla direzione da cui viene la pressione. La risposta non è che va tutto bene. La risposta è che il rimedio sta nella proporzionalità delle regole procedurali, nella misura in cui l’articolo 9 già parla di necessario e proporzionato, e non nell’abrogazione della regola sostanziale. Lo dico da dentro una società di dieci persone, e sospetto che abbia un peso diverso rispetto allo stesso argomento fatto da un accademico. Chiedere a una piccola impresa di sapere cosa fa il proprio software non è un onere sproporzionato. Chiederle di difendersi con gli stessi strumenti procedurali di un costruttore globale lo è, e il decreto italiano potrebbe fare qualcosa su questo. Per ora non lo fa.

La terza è dottrinale e la prendo sul serio perché l’ho sollevata io stesso qualche mese fa. Il software non è un prodotto, e un sistema che apprende e modifica il proprio comportamento non si riduce alla categoria del bene mobile difettoso. È vero. La categoria è imperfetta, forzata, e regge male sui sistemi distribuiti in cui nessuno controlla tutto. Ma l’alternativa che i critici proponevano era una direttiva dedicata alla responsabilità dei sistemi di intelligenza artificiale, ed è stata ritirata. Ci arrivo tra un attimo. Nel vuoto che il ritiro ha lasciato, la categoria imperfetta batte l’assenza di categoria.

La quarta è che si produrrà ingegneria difensiva, non ingegneria sicura. Sistemi ipercauti, rilasci congelati, funzionalità disattivate in Europa, ritiro dal mercato. Il rischio è reale e non lo nego. Una parte dell’industria reagirà così, e per un periodo alcune cose in Europa arriveranno più tardi o non arriveranno. La replica sta nella struttura dell’incentivo che ho descritto. L’ingegneria difensiva classica consiste nel non guardare, ed è precisamente la condotta che la presunzione punisce. Il produttore che vuole difendersi dalla presunzione deve produrre i dati, e per produrli deve averli raccolti, e per averli raccolti deve aver guardato. È possibile costruire un sistema ipercauto e ben documentato, certo. Non è possibile costruire un sistema difendibile e non documentato, ed è questo il punto.

La quinta è di scenario: l’ennesimo peso normativo europeo mentre gli altri corrono. Qui il caso di Mesa serve anche a questo. Mostra cosa produce concretamente il modello alternativo, quello in cui il segreto industriale regge. Una famiglia che non sa perché. Un’agenzia di polizia stradale che indaga senza sapere che il sistema era attivo. Un regolatore che riceve il report con tre campi neri e li archivia. Un pubblico che scopre dieci mesi dopo, da un giornalista con un foglio di calcolo, che c’erano due casi identici a venticinque giorni di distanza. Gli altri corrono. Correre senza un registratore di bordo leggibile è una scelta, e ha un prezzo che non paga chi corre.

L’unico strumento rimasto

C’è un’ironia in tutta questa storia che merita il suo spazio.

Il 28 settembre 2022 la Commissione europea aveva proposto una direttiva sulla responsabilità civile per l’intelligenza artificiale, la AI Liability Directive. Faceva due cose, e le faceva in modo mirato ai sistemi ad alto rischio: dava ai giudici il potere di ordinare la divulgazione delle prove tecniche detenute dal fornitore, e introduceva una presunzione confutabile di nesso causale tra la colpa del convenuto e l’output del sistema. Era, per l’intelligenza artificiale, la versione dedicata di quello che gli articoli 9 e 10 della direttiva sui prodotti fanno in generale.

L’11 febbraio 2025 la Commissione ha adottato il programma di lavoro per il 2025, presentato al Parlamento europeo a Strasburgo il giorno dopo. L’allegato IV elenca trentasette proposte da ritirare. La riga 32 è la direttiva sulla responsabilità per l’intelligenza artificiale, con una motivazione che vale la pena riportare: nessun accordo prevedibile, la Commissione valuterà se presentare un’altra proposta o scegliere un altro tipo di approccio. Il ritiro formale è stato pubblicato in Gazzetta ufficiale il 6 ottobre 2025. Il 3 dicembre la commissione giuridica del Parlamento ha respinto, con ventidue voti contro uno, la proposta di impugnarlo. La pratica è chiusa.

La conseguenza va detta con precisione, perché è facile esagerarla. L’AI Act non contiene regole sul risarcimento: il suo considerando 9 rimanda esplicitamente alla direttiva sui prodotti per la compensazione dei danni. Con il ritiro dell’AILD, la direttiva 2024/2853 è oggi l’unico strumento europeo che armonizza la responsabilità civile per i danni causati da sistemi di intelligenza artificiale, e lo fa entro i limiti della responsabilità da prodotto. Tutto il resto, e il resto è molto, resta ai ventisette diritti nazionali della responsabilità extracontrattuale.

Ed ecco il rovesciamento. Chi ha applaudito il ritiro dell’AILD come una vittoria della semplificazione dovrebbe essere oggi il primo a difendere la direttiva sui prodotti, perché senza di essa quello che resta non è meno regolazione: sono ventisette regolazioni. Per un’impresa che vende software in cinque paesi europei, ventisette regimi diversi di responsabilità extracontrattuale, ciascuno con le sue presunzioni, i suoi termini, le sue regole sull’accesso alle prove, sono uno scenario peggiore di una regola armonizzata, anche severa. Lo ha detto nei giorni del ritiro Axel Voss, relatore del Parlamento sull’AILD ed eurodeputato del Partito popolare europeo, quindi non un uomo della sinistra regolatoria: ha definito il ritiro un errore strategico e ha previsto che la responsabilità per l’AI sarebbe stata dettata da un mosaico frammentato di ventisette sistemi giuridici nazionali, soffocando le startup e le piccole imprese europee del settore. Aveva ragione, e la direttiva sui prodotti è ciò che ci resta per evitarlo.

Dodici giorni, poi novantasei

Torno al decreto, perché è la parte che si può ancora toccare.

La delega è nella legge di delegazione europea 2025, la legge 17 marzo 2026, n. 36, allegato A, numero 4. Il Consiglio dei ministri ha approvato lo schema in esame preliminare il 4 agosto. Il testo è arrivato alle Camere il 7 agosto come Atto del Governo n. 434. Alla Camera le commissioni Giustizia e Politiche dell’Unione europea hanno termine per il parere il 16 settembre. Al Senato la seconda commissione ha quaranta giorni dall’assegnazione, quindi la stessa scadenza. Da oggi sono dodici giorni. Poi il governo adotta il testo definitivo, e il 9 dicembre, novantasei giorni da oggi, la direttiva entra in applicazione per i prodotti immessi sul mercato da quel giorno in avanti. Per i prodotti già sul mercato continua ad applicarsi la disciplina del 1985.

Lo schema recepisce la direttiva in modo quasi letterale, e su questo c’è poco da dire: la relazione stessa osserva che, trattandosi di armonizzazione piena, i margini del legislatore nazionale sono circoscritti. L’esibizione delle prove è all’articolo 119, le presunzioni all’articolo 120, la deroga per il software all’articolo 118, comma 2. Tutto al suo posto.

C’è però un punto da guardare, ed è l’unico su cui lo Stato aveva una scelta vera. L’articolo 18 della direttiva permette agli Stati membri di derogare all’esenzione per rischio da sviluppo, la difesa con cui il produttore si libera dimostrando che lo stato delle conoscenze scientifiche e tecniche al momento dell’immissione sul mercato non permetteva di scoprire il difetto. La deroga si può introdurre solo per categorie specifiche di prodotti, con obiettivi di interesse pubblico, in modo proporzionato e previa notifica alla Commissione. Il governo ha scelto di non esercitarla. L’analisi di impatto lo motiva così: la conservazione dell’esimente, già prevista dal testo vigente, assicura la continuità del quadro nazionale e l’uniformità delle condizioni di esposizione risarcitoria nel mercato interno, mentre l’introduzione di un regime derogatorio non è sorretta, allo stato, da evidenze che ne dimostrino la necessità.

Non sono sicuro che sia la scelta sbagliata. La difesa del rischio da sviluppo è ragionevole per la maggior parte dei prodotti, e una deroga generalizzata sarebbe stata un errore. Ma «allo stato» e «evidenze» sono parole che, nel caso specifico dei sistemi che continuano ad apprendere dopo la vendita, meritano una domanda in commissione. Un fabbricante che progetta un prodotto capace di comportamenti inattesi, e che mantiene il controllo sugli aggiornamenti, può davvero sostenere che lo stato delle conoscenze non permetteva di scoprire il difetto, quando è lui a decidere cosa il prodotto registra di sé? La direttiva già limita questa difesa al periodo in cui il prodotto era sotto il controllo del fabbricante. Se il parere parlamentare vuole dire una cosa utile nei dodici giorni che restano, potrebbe chiedere al governo di spiegare perché non ha ritenuto di guardare almeno a quella categoria, e quali evidenze cercherà nei prossimi anni per rivalutare. Una richiesta modesta, di leggibilità, che è poi il tema di tutto il resto.

Alle tre di notte sulla Loop 202 una Model 3 è ferma in corsia, con i fari accesi nel buio. Il sistema che la tiene ferma sa perché. Lo ha scritto nel suo registratore, lo ha trasmesso al costruttore, il costruttore lo ha dichiarato al regolatore e poi lo ha coperto con tre rettangoli neri che il regolatore stesso gli ha permesso di usare. Dieci mesi dopo un giornalista ha ricostruito quel poco che si poteva ricostruire da fuori. La famiglia, la polizia stradale e chiunque guidi una Model 3 del 2020 non sanno ancora niente.

La direttiva europea sulla responsabilità da prodotto non avrebbe salvato quel conducente. Nessuna legge lo avrebbe fatto. Ma avrebbe reso il costruttore incapace di rispondere omissis, e questo, venticinque giorni dopo la prima morte, avrebbe potuto contare.

Non sapere non è più gratis. È la cosa più utile che una legge sulla responsabilità potesse dire al software.

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 →