Bug nel software: attenzione sviluppatori, siete responsabili in caso di danni

Cambiamento epocale nell’Unione Europea. Il Parlamento e il Consiglio europeo hanno approvato la nuova Direttiva 2024/2853 che introduce nuove prescrizioni in materia di responsabilità per danno da prodotti difettosi. Per la prima volta nella storia, il software diventa un prodotto ai fini della responsabilità oggettiva: questo significa che in caso di problemi, gli sviluppatori possono essere chiamati a rispondere dei danni causati (e a risarcire gli utenti).

Finora (stranamente) passata sotto silenzio, si tratta di una novità che provocherà un vero e proprio terremoto nel mondo dello sviluppo software, dell’intelligenza artificiale (AI) e in generale nel settore digital.

Chi ha inventato il termine bug parlando di software e perché?

Il fatto che un software, indipendentemente dalla sua natura e tipologia, possa contenere bug è un dato di fatto. Dalle software house fino agli sviluppatori indipendenti, si rincorrono a intervalli più o meno regolari le correzioni per risolvere imperfezioni di vario genere: da quelle minori fino a problemi che possono impattare negativamente sulla riservatezza, integrità e disponibilità dei dati.

Il termine bug in riferimento ai problemi di funzionamento in un software sembra sia stato coniato dalla pioniera dell’informatica Grace Hopper. Durante il lavoro sui primi computer elettronici, Hopper e il suo team scoprirono un insetto vero e proprio (una falena) intrappolato in uno dei relè del computer Harvard Mark II. Quell’incidente provocò un malfunzionamento, documentato nel diario giornaliero con la seguente nota: “scoperto il primo reale caso di bug“.

Ancor prima, già Thomas Edison parlava di “bug” per riferirsi ai difetti individuati nei suoi prototipi. Fu però la Hopper che di fatto ne rese celebre l’utilizzo del campo informatico, facendo diventare “bug” un termine di uso comune nell’ambito della programmazione.

Il legislatore europeo: se un bug causa problemi, ne risponde lo sviluppatore

I bug nel software esistono da quando esistono i computer. L’importante è riuscire a individuarli, a riprodurli e a risolverli cosicché non possano causare problemi. Eppure, il legislatore europeo ha sentito il bisogno di intervenire in maniera severa prevedendo una specifica responsabilità per i danni arrecati dal software e dalle soluzioni di intelligenza artificiale.

La direttiva chiarisce che il software, indipendentemente dal modo in cui viene fornito o utilizzato (ad esempio, integrato in un dispositivo, utilizzato tramite una rete di comunicazione o tecnologie cloud, o messo a disposizione come servizio), entra nella sfera della responsabilità oggettiva. Il software, comprese le piattaforme online e i sistemi AI, è quindi soggetto alle stesse regole di responsabilità per danni causati dai prodotti difettosi.

La normativa esclude dalla sua applicazione il software libero e open source sviluppato o fornito nello svolgimento di un’attività non commerciale. Tuttavia, se il software libero od open source è successivamente integrato in un prodotto commerciale, il fabbricante del prodotto finale può essere ritenuto responsabile per eventuali danni causati dal software difettoso.

Il legislatore non si cura delle differenze tra software libero e open source né entra nella spinosa questione delle licenze software: si limita solo a osservare che il software closed source e anche quello aperto sviluppato nell’ambito di attività commerciali, sono soggetti alle nuove (stringenti) regole.

Aggiornamenti software e migliorie

La direttiva europea sancisce anche che eventuali aggiornamenti e migliorie del software sono considerati sotto il controllo del fabbricante se sono forniti direttamente o tramite terzi. Lo sviluppatore può quindi essere ritenuto responsabile pure per i danni causati da aggiornamenti difettosi, anche se il difetto si manifesta dopo l’immissione sul mercato del prodotto.

La responsabilità oggettiva è inoltre estesa ai servizi digitali integrati o interconnessi con i prodotti, considerandoli componenti del prodotto stesso. Sono citati, a titolo esemplificativo, i meccanismi che si occupano di trasferire dati sul traffico nei sistemi di navigazione, i servizi di monitoraggio della salute, i servizi di controllo della temperatura, gli assistenti vocali e così via.

Individuazione della prova del malfunzionamento

La questione dell’individuazione della prova del malfunzionamento lato software e del nesso causale è complessa e cruciale nel contesto della responsabilità per danni da prodotti difettosi.

La direttiva prevede che, su richiesta dell’attore (la persona che chiede il risarcimento), il convenuto (il fabbricante o altro operatore economico) sia tenuto a divulgare i pertinenti elementi di prova a sua disposizione: documenti tecnici, registri di sviluppo, test di sicurezza e altre informazioni rilevanti.

Gli organi giurisdizionali nazionali possono a loro volta chiedere che le informazioni siano presentate in modo facilmente accessibile e comprensibile, soprattutto in casi di elevata complessità tecnica o scientifica.

Presunzione del difetto e nesso causale

Se il danno è causato da un malfunzionamento evidente del prodotto durante l’uso ragionevolmente prevedibile, si presume il carattere difettoso del prodotto. Ad esempio, se un software di sicurezza non rileva una minaccia nota e causa un danno, questo può essere considerato un malfunzionamento evidente.

Ancora se è provato che il software risulta difettoso e che la natura del danno cagionato è compatibile con il difetto in questione, si presume l’esistenza del nesso di causalità tra il difetto e il danno. In altre parole, una volta dimostrato il difetto, il danneggiato non deve necessariamente provare il nesso causale se il tipo di danno è tipicamente associato a quel difetto.

Se un sistema di AI causa un danno a causa di un malfunzionamento evidente, come un errore di riconoscimento che porta a un incidente, il danneggiato può beneficiare della presunzione di difetto. Allorquando la complessità del sistema rendesse difficile provare il nesso causale, l’organo giurisdizionale può presumere il nesso di causalità se il tipo di danno è compatibile con il difetto.

Veramente un vero e proprio terremoto per chi si progetta, sviluppa e commercializza soluzioni software, di qualunque genere esse siano.

Perché si parla adesso dei difetti software?

Prima della nuova direttiva, la normativa europea in materia di responsabilità per danni da prodotti difettosi era disciplinata dalla direttiva 85/374/CEE, del 25 luglio 1985. Essa fissava un regime di responsabilità oggettiva per i fabbricanti di prodotti difettosi ma non affrontava assolutamente la questione del software.

Adesso tutto cambia e a meno di future revisioni, la normativa – pubblicata in Gazzetta Ufficiale il 18 novembre 2024 – entrerà in vigore l’8 dicembre 2024.

La palla passa adesso ai singoli Stati membri, quindi anche all’Italia, che dovranno recepire le prescrizioni entro e non oltre il 9 dicembre 2026.

Gli Stati membri devono modificare o creare nuove leggi nazionali per allinearsi alle disposizioni della direttiva. Una volta adottate norme nazionali in linea con la direttiva 2024/2853, gli Stati membri devono informare la Commissione Europea delle misure adottate.

Osservazioni e note finali

Tenendo ben presenti le scadenze fissate dalla normativa, sono tanti i punti interrogativi che restano sul tavolo.

Per evitare di dover versare risarcimenti danni, non basta che gli sviluppatori software dimostrino di aver fatto tutto il possibile per risolvere i bug presenti nei loro software?

I giudici non dovrebbero ritenere responsabili, in caso di danni comprovati, soltanto quelle realtà commerciali che hanno dimostrato di ignorare segnalazioni di difetti a loro pervenute?

Una cosa, infatti, è immettere sul mercato un prodotto difettoso essendo consapevoli di farlo. Ad esempio perché si sono utilizzati materiali scadenti, non si è svolta un’adeguata progettazione, non si è tenuto conto delle buone pratiche e nel caso del ciclo di vita del software non si è applicato l’approccio DevSecOps. Un altro conto, invece, è aver sviluppato un software con tutte le verifiche e salvaguardie del caso. È infatti materialmente impossibile individuare e risolvere tutti i bug prima della commercializzazione di un qualunque software!

Eppure la direttiva europea non sembra fare “sconti”. Uno sviluppatore o fabbricante può essere esentato dalla responsabilità se dimostra che lo stato delle conoscenze scientifiche e tecniche al momento dell’immissione sul mercato del prodotto non permetteva di scoprire l’esistenza del difetto.

A parte questo, anche se uno sviluppatore di software dimostra di aver adottato tutte le misure ragionevoli per prevenire o correggere i difetti, ciò non esclude la sua responsabilità in caso di danni causati da un prodotto difettoso. La responsabilità oggettiva si basa sul fatto che il prodotto deve essere sicuro, non sulle azioni intraprese per garantire tale sicurezza. Non è forse un po’ troppo?

Qualche esempio per riflettere

Windows improvvisamente non si avvia più a causa di un aggiornamento distribuito da terze parti. Chi è responsabile? Microsoft perché ha fatto sì che un problema di un software esterno riesca a bloccare l’avvio del sistema operativo? Oppure la terza parte che ha distribuito l’update problematico?

Prendiamo il caso di un sito WordPress installato da un’azienda specializzata (o presunta tale) oppure da un professionista su commissione del cliente. La piattaforma non è aggiornata e lasciata esposta a una vulnerabilità nota che provoca il defacciamento del sito o la perdita di dati. La responsabilità è di WordPress o del professionista?

Non sarebbe stato preferibile lasciare “parlare” i contratti e attenersi alle pattuizioni, con la specificazione di limiti e responsabilità, senza il bisogno di normare a tutti i costi qualcosa che per la sua stessa natura è estremamente complesso da costringere tra paletti burocratici?