Perché abbiamo accettato che il software possa fallire (e perché non possiamo più permettercelo)

Dagli aerei alle cure mediche, dagli algoritmi alle auto: gli errori software sono ovunque. E senza regole sulla responsabilità il rischio continuerà a crescere di Andrea Monti – Inizialmente pubblicato su Italian Tech – La Repubblica
Per una volta, un difetto nel software che contribuisce al corretto funzionamento di un aereo è stato rilevato e corretto prima che si verificasse un evento catastrofico. Se, infatti, i passeggeri degli Airbus A320 possono continuare a volare tranquilli per via dell’intervento tecnico preventivo, hanno avuto una sorte tragicamente diversa quelli di due Boeing 737 Max che fra il 2018 e il 2019, per via di un malfunzionamento del software causarono la morte di 346 persone.

Quando il software sbaglia: trent’anni di incidenti dimenticati

Questi sono solo i più recenti casi che hanno coinvolto il settore aerospaziale, ma le cronache hanno registrato almeno fin dal 1993 degli incidenti — fortunatamente non letali — che sono stati causati da codice sbagliato. Tanto per citarne alcuni vale la pena di ricordare la scomparsa del Mars Lander, l’esplosione del vettore Ariane 5, il crash del Mars Climate Orbiter.

Il “bad software”, tuttavia, non affligge uno specifico settore ma, anzi, è una presenza trasversale nell’industria. Giusto per citare in ordine sparso qualche altro caso, basta ricordare che fra il 1985 e il 1987 un errore del software (o meglio di chi lo aveva realizzato o di chi non aveva controllato che fosse sicuro) espose a massicce dosi di radiazioni i pazienti che si sottoposero radioterapia con il Therac-25. Oppure che la prima serie della Mercedes Classe A immessa sul mercato nel 1997 non era in grado di superare il test dell’alce e fu necessario, oltre ad interventi ingegneristici, intervenire anche sul software che governava il controllo elettronico di stabilità. Oppure ancora che ci sono voluti oltre vent’anni perché centinaia di addetti delle poste inglesi fossero scagionati da accuse infamanti causate nel 1999 da un errore del software che gestiva la contabilità e che aveva “denunciato” ammanchi.

E visto che stiamo procedendo in ordine cronologico, come dimenticare l’isteria generata dall’errore di progettazione del modo in cui i BIOS delle schede madri gestivano il passaggio dal 1999 al 2000 (che non era l’inizio del nuovo millennio, ma la fine del decennio precedente)?

L’assuefazione collettiva agli errori digitali

Anche il nuovo millennio non è stato risparmiato dai danni causati dagli errori di programmazione. Anzi, la corsa irrazionale alla digitalizzazione indiscriminata ha posto le basi che consentono a un piccolo problema di diventare una catastrofe globale.

Siamo talmente abituati, anestetizzati, al fatto che il software “funzionicchia” da non arrabbiarci più di tanto quando un aggiornamento di sicurezza mal realizzato paralizza mezzo mondo, un’app realizzata in modo superficiale rende inservibile uno smartphone o un aggiornamento del sistema operativo cancella i file memorizzati sul computer.

Insomma, abbiamo smesso di —o meglio, non abbiamo mai iniziato a— pretendere che il software funzioni correttamente.

Cosa ci dicono Kaner e Cooper: il “bad software” non è un imprevisto, ma un modello

Quello del “bad software” è un problema noto fin dagli inizi della società dell’informazione. Nel 1997 il professor Cem Kamer scrive un libro intitolato appunto in questo modo e l’anno successivo, Alan Cooper, il padre del visual basic pubblicò The Inmates Are Running the Asylum (pubblicato in Italia con il titolo “Il disagio tecnologico”), nel quale documentava in modo diffuso le conseguenze del non prendere sul serio la programmazione.

Sono passati quasi quarant’anni e siamo ancora lì e, anzi, ci troviamo in una condizione ancora peggiore.

Se non gestiamo il software stupido, come faremo con quello “intelligente”?

La disinvoltura con la quale si stanno integrando piattaforme di AI all’interno di processi decisionali di vario tipo, inclusi quelli giudiziari, diagnosi mediche e controlli di macchine industriali fa aumentare grandemente la probabilità che si verifichino danni sempre più diffusi e importanti.

Questo, non perché esistono “AI ad altro rischio” —come le chiama il burocratico e inutile regolamento europeo— ma perché se non siamo stati capaci di definire regole semplici per stabilire la responsabilità di chi sviluppa software “stupidi”, ben difficilmente potremo fare lo stesso con quelli “intelligenti”.

Non possiamo più permettersi software inaffidabili

Il bug dell’Airbus non è un evento isolato, ma l’ennesimo segnale che il software è diventato un componente critico del nostro mondo senza un sistema di responsabilità adeguato. Abbiamo costruito processi industriali, servizi pubblici e interi settori economici su programmi che possono sbagliare senza che nessuno ne risponda davvero.

Se non sciogliamo questo nodo, ogni discussione sull’intelligenza artificiale rischia di essere un esercizio ideologico o un passatempo intellettuale.

Come ogni tecnologia emergente, anche l’intelligenza artificiale degli inizi è immatura, rozza e inefficiente e anche in questo caso il dio progresso esige il proprio tributo di vittime sacrificali.

Non conforta, tuttavia, la percezione di dover far parte di un ecatombe per consentire l’ulteriore perdita di controllo su componenti fondamentali della nostra società.

Possibly Related Posts: