Posted on by Andrea Monti

Qualcuno fermi le software-house

La notizia diffusa ieri del blocco dei voli a Miami “per un problema informatico” del sistema dei radar dell’aereoporto non è né il primo né l’ultimo incidente causato da errori di progettazione, da bug o da interazioni sbagliate con qualche altro componente di un sistema. Dallo scoppio del vettore Ariane V nel 1996, al clamoroso bug “Anno 2000”, al disastro del Boeing 737 Max del 2019 all’incredibile caso della “provvedimento fantasma” generato dalla piattaforma digitale del Consiglio di Stato nel novembre 2022, la storia è piena di incidenti causati da malfunzionamenti di software. Più correttamente, però, questi eventi non sono stati provocati “dal” software ma da chi lo ha pensato, realizzato e fatto funzionare. Per l’ennesima volta, tuttavia, anche nel caso dei radar di Miami è sempre “colpa è del computer”, come se queste macchine fossero dotate di vita propria e fossero sostanzialmente incontrollabili. Evidentemente non è vero, ma la narrativa è oramai tanto consolidata da avere oscurato una banale considerazione di buon senso: il software è un “prodotto”, chi lo costruisce dovrebbe farlo seguendo regole di sicurezza, ed essere legalmente responsabile per le conseguenze causate dal “manufatto” di Andrea Monti – Inizialmente pubblicato su Strategikon – un blog di Italian Tech

Mentre case, automobili, elettrodomestici e strumenti di lavoro sono sottoposti a regole ferree, non è così per i programmi. A parte generiche prescrizioni come quelle del regolamento sulla protezione dei dati personali, ingombranti e inutili “certificazioni” per la “sicurezza nazionale” e poco altro, la costruzione di software è sostanzialmente priva di responsabilità. Dunque, la vita, l’incolumità e la tutela dei diritti delle persone sono affidate a prodotti largamente sottratti a qualsiasi controllo. Se c’è un problema, dice il marketing di settore, è una funzionalità, non un difetto; in ogni caso basta attendere la prossima versione per farlo scomparire (in teoria). Nel frattempo, nessuno paga.

Qualche acuto giurista rileverà certamente che la UE e l’Italia considerano il software un’opera dell’ingegno e che, quindi, non si può parlare di responsabilità da prodotto. Sarà anche così, ma non ho mai letto sulla quarta di copertina della Divina Commedia che “questo libro vi piacerà per 90 giorni dalla lettura della prima pagina”, sulla targhetta che identifica un Caravaggio che “non garantiamo che questo quadro potrà soddisfare le necessità di tutti i visitatori” o ancora sul booklet di Bitches Brew che “l’ascolto di questo disco non è consentito in ambienti mission critical”.

Dunque, applicando il Duck Test,  se il software è fatto come un prodotto, funziona come un prodotto ed è usato come un prodotto, allora è un prodotto. Prima i legislatori se ne renderanno conto e meglio sarà per tutti. Purtroppo, questa considerazione puramente fattuale è già sfuggita in ambito comunitario. Parlamento e Commissione, preda del clamoroso equivoco tecnico e culturale sulla natura della “intelligenza artificiale”, stanno procedendo ostinatamente verso l’approvazione di un regolamento che differenzia la responsabilità per l’uso di software “intelligente” da quella per l’impiego di software “stupido”. In altri termini, è come se solo il primo fosse in grado di causare danni mentre il secondo, tutto sommato, va bene così: alla fin fine come si fa a prendersela con uno “stupidotto”? Anche in questo caso i fatti contraddicono l’impostazione della scelta politica della UE: i software “stupidi” sono anch’essi oggetti estremamente sofisticati, in grado di provocare danni incalcolabili. Dunque, differenziare i regimi di responsabilità in funzione delle scelte tecnologiche e non delle conseguenze è semplicemente sbagliato. Ciò che conta è, in altri termini, se un software è sviluppato in modo da ridurre il rischio di causare danni oppure no. Il “come” è del tutto irrilevante.

Prima ancora del regolamento prossimo venturo sull’AI, per anni il trattamento dei dati personali (incluse banalissime liste di indirizzi di posta elettronica) è stato sottoposto ad un regime di responsabilità analogo a quello della gestione di centrali nucleari (la cosiddetta “responsabilità per attività pericolosa”). Invece, l’attività di chi sviluppa software è andata esente da ogni responsabilità grazie allo scudo, anche penale, garantito dalla legge sul diritto d’autore. Nonostante, infatti, le software house trattino i programmi alla stregua di manufatti, sono molto rigorose nell’usare il diritto al segreto garantito dalla normativa sulla proprietà intellettuale per sottrarsi non solo e non tanto alle responsabilità per i danni causati dai loro prodotti, ma dai maggiori costi che lo sviluppo di software sicuro implicherebbe.

Queste considerazioni scoperchiano, potenzialmente, un Vaso di Pandora.

Fino a quando i danni causati dai malfunzionamenti dei software sono frutto di errori umani si configura sempre una responsabilità per negligenza (che poi sia praticamente impossibile da dimostrare, è un altro discorso). Se, tuttavia, l’immissione sul mercato di “prodotti” difettosi fosse frutto di spregiudicate strategie commerciali lo scenario sarebbe totalmente diverso. Saremmo di fronte a comportamenti di rilevanza penale che giustificherebbero l’irrogazione di pene molto severe anche e soprattutto nei confronti dei vertici aziendali e non di qualche oscuro “senior software engineer”.

Solo l’accesso ai codici sorgenti e alla documentazione di sviluppo consentirebbe di capire se ci sia e dove sia l’errore, ma soprattutto se ci si trova di fronte a un errore o alla deliberata scelta di rilasciare un prodotto pericoloso. Siccome, tuttavia, questo diritto di accesso può essere legittimamente negato a chi ha subito un danno, è chiaro che ben difficilmente una richiesta risarcitoria potrà essere accolta. Se, poi, consideriamo che i software sono composti da centinaia di migliaia o addirittura milioni di righe di codice, anche potendo avervi accesso e potendo permettersi di sostenere i relativi costi, difficilmente si otterrebbero informazioni utili a far valere il proprio diritto.

Una soluzione pratica e a costo zero sarebbe applicare anche allo sviluppo di software quella responsabilità per attività pericolosa inizialmente prevista (e poi eliminata) per il trattamento dei dati personali. Invertendo il cosiddetto “onere della prova”, si deve soltanto provare di avere subito un danno a causa di un software, mentre spetta al produttore, pardon all’“autore” la dimostrazione di avere fatto tutto il possibile per evitare il danno.

Qualcuno, probabilmente, potrebbe considerare questa proposta come inaccettabile perché “frenerebbe l’innovazione” o “bloccherebbe la transizione digitale”. Per certi versi, potrebbe anche essere vero, se l’idea di innovazione che si ha in mente è inondare il mercato di prodotti mal funzionanti e ridurre chi li usa a inconsapevoli collaudatori o, più spesso, cavie, senza volersi nemmeno fare carico degli effetti avversi. Se, invece, progresso significa migliorare la qualità della vita del maggior numero possibile di persone, allora quella che spesso viene presentata come “innovazione” è soltanto avidità da soddisfare a qualsiasi costo, inclusa la messa in pericolo della vita umana.

Praticare questa peculiare visione del progresso non è necessariamente un problema, l’importante è che, come si dice a Roma, famo a capisse.

Possibly Related Posts: