di  -  giovedì 5 Gennaio 2023

Mi rendo conto che sia un messaggio un po’ forte, ma è la prima cosa che m’è venuta in mente già dopo aver letto il primo paragrafo di un fresco articolo sul tema dal più diffuso giornale italiano: Qualcuno fermi le software-house. Pensiero inevitabilmente consolidato man mano che la lettura procedeva, fino alla tragicomica (perché c’è da ridere e piangere allo stesso tempo) conclusione.

L’autore, infatti, parte snocciolando una serie di problemi che imputa tout court al creatore dei relativi software: <<questi eventi non sono stati provocati “dal” software ma da chi lo ha pensato, realizzato e fatto funzionare>>. Se da una parte assolve il software e i computer in cui tali nefaste problematiche si siano verificate (come riportato nel paragrafo introduttivo), dall’altra non mostra il benché minimo dubbio: è chi ha creato il software ad averle provocate! Come se, insomma, si fosse trattato di un diabolico piano ordito dai programmatori.

Prosegue impavidamente affermando che il software dovrebbe essere sviluppato <<seguendo regole di sicurezza>>, che ovviamente si astiene dal riportare o anche vagamente accennare.

Purtroppo la cosa peggiore è che probabilmente non sa che in letteratura (informatica) non esiste né una definizione oggettiva di “sicurezza” (lo metto appositamente tra virgolette) né tanto meno metriche / strumenti che siano in grado di stabilire che un determinato software sia “sicuro” (sempre tra virgolette) ed eventualmente quanto / in che misura.

Conoscenza che, invece, ha ben chiara chi abbia effettuato un percorso di studi che sia passato dalla Teoria della Computabilità (ossia il fondamento stesso dell’informatica) e alcuni suoi teoremi che, se noti, avrebbero stroncato sul nascere certe affermazioni che etichettare come discutibili sarebbe già fargli un complimento.

Che il problema di fondo sia la scarsa o mancanza di conoscenza in materia si evidence anche dall’audace affermazione seguente: <<Mentre case, automobili, elettrodomestici e strumenti di lavoro sono sottoposti a regole ferree, non è così per i programmi>>. Per puro caso (!) lavoro già da 6 anni per un’importante azienda automotive europea (inizialmente da Senior Developer/QA, poi come Principal QA Engineer, e di recente come Operational Manager) relativamente allo sviluppo dei nostri sistemi di infotainment che… sono fatti da programmi! Sì, proprio ciò di cui si lamenta l’autore! E posso affermare con assoluta certezza come il software non soltanto sia parte essenziale delle automobili (quindi non esclusivamente delle nostre), ma diventa sempre più importante. Oltre al fatto che, per quanto lo sviluppo sia controllato e sottoposto a tantissime revisioni, può capitare che non sia esente da difetti (bug). D’altra parte parliamo di programmi costituiti da decine e decine di milioni di righe di codice, e sfido l’autore a svilupparli con tutte le “regole ferree” che vuole e a rilasciarli senza il benché minimo bug…

Con ciò posso confutare immediatamente anche quanto scrive successivamente: <<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>>. No, caro il mio autore, è l’esatto contrario: il software è largamente sottoposto a controlli prima di arrivare in produzione! Controlli che sono ovviamente proporzionali alla criticità dell’ambito di impiego.

E continua ancora cercando di smantellare uno dei cardini della giurisprudenza in materia: <<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>> con susseguenti strampalati accostamenti a libri o quadri ed esempi che dovrebbero provare la sua tesi (“dimenticando” che anch’essi possano presentare difetti), ossia che il software, in quanto mero prodotto di cui i consumatori fruiscono, dovrebbe essere gravato da (intrinseche) responsabilità nel caso presentasse dei difetti.

Il problema fondamentale di tali affermazioni è che risulta piuttosto evidente che egli non si sia cimentato nella scrittura di software, per lo meno di una certa complessità / caratura nonché con sufficiente esperienza, altrimenti avrebbe già maturato, da parecchio tempo, la consapevolezza che, sì, invece: il software è frutto dell’ingegno di chi lo realizza. Dunque ha (evito il condizionale) tutti i titoli per essere trattato come tale dalla giurisprudenza, al pari di qualunque altra opera facente capo alle altre arti note.

Sì, perché scrivere codice è anche un’arte: il codice ha pure una propria estetica, che deriva dal modo in cui quello sviluppatore concepisce la risoluzione dei determinati problemi che gli si sono presentati davanti. D’altra parte se la gente, istruzione obbligatoria alla mano, è in grado di scrivere un tema o una letterina a babbo natale (visto il periodo), non è che tutti diventino scrittori o poeti, e magari affermati. La capacità di scrivere non implica, logica elementare alla mano, che chiunque possa arrivare a tali livelli. E lo stesso si applica, né più né meno, alla programmazione.

Sempre in tema di logica non può certo sfuggire la fallacia di quanto successivamente riportato: <<Dunque, applicando il Duck Test,  se il software è fatto come un prodotto, funziona come un prodotto ed è usato come un prodotto, allora è un prodotto>>. Infatti il software continua a rimanere un’opera dell’ingegno nonostante possa (ma non è!) essere realizzato, funzionare, e usato come prodotto. La sua proprietà d’essere opera dell’ingegno, insomma, non verrebbe meno soltanto per questo.

D’altra parte l’assunzione di base risulta già sbagliata, poiché il software non viene realizzato come prodotto, in quanto non esiste un “ricettario” da cui pescare, dei meccanismi, o degli strumenti che, utilizzati in precisi nonché prevedibili modi (come potrebbe essere la catena di produzione di una fabbrica) diano come risultato uno specifico programma da realizzare. Magari fosse così (semplice)!

Devo dire che, però, concordo con quanto poi affermato su un ben preciso argomento. Sembrerebbe, a suo dire, che l’UE si stia muovendo per legiferare in materia di responsabilità soltanto quando si tratti di software di intelligenza artificiale, esentando tutti gli altri tipi di software. Personalmente sono totalmente in disaccordo perché nessun software, in quanto tale, dovrebbe prevedere automaticamente delle responsabilità per eventuali danni.

Ciò precisato, torno immediatamente a dissentire sul passaggio successivo: << 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>>. Il come è, invece, assolutamente rilevante, perché le buone pratiche (che vengono già ampiamente utilizzate nell’industria del software) non sono affatto sufficienti per poter fornire granitiche certezze/garanzie sull’assenza di difetti che possano portare a danni (di qualunque misura).

Non ci sono e non ci potranno essere, perché è la già citata Teoria della Computabilità a dimostrarlo, a meno che l’autore non trovi il modo di smantellare i (purtroppo per lui) solidissimi teoremi che ne sono alla base. La matematica, di cui l’informatica è figlia (ne è una branca, infatti), non potrà mai e poi mai essere messa in discussione, con buona pace dell’autore. Anche qui, però, la cosa più importante sarebbe capire in che modo un software andrebbe sviluppato per avere meno danni (o nessuno), ma l’autore ha deciso di tralasciare ogni riferimento o dettaglio in merito.

Il quale, comunque, imperterrito afferma che le software house userebbero <<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>>. Premesso che la tutela delle proprietà intellettuali sia sacrosanta, parecchie aziende hanno processi di audit del software che sviluppano, i quali sono conformi agli standard industriali (ISO). Diverse si appoggiano anche a ditte esterne di esperti che analizzano il codice alla ricerca di vulnerabilità; ciò perché, banalmente, il fatto che un software sia chiuso (non visionabile da chiunque) non implica che soltanto l’azienda che lo sviluppa ne abbia accesso. Infine, ritorna col mantra dello sviluppo di software “sicuro”, di cui però, come già detto all’inizio, non esiste alcuna definizione in letteratura (e ciò tanto per cominciare)…

Mi sento, però, di rincuorare l’autore quando afferma che: <<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)>>. Da programmatore di lunga data (40 anni) nonché vasta e variegata esperienza posso tranquillamente affermare che i bug (difetti) nel software che scriviamo sono certamente… frutto di nostri errori. Errori umani, dunque. Perché, da esseri umani quali siamo, commettiamo errori quando scriviamo programmi, poiché il processo creativo (ed è il motivo per cui programmare è e rimane opera dell’ingegno!) che porta alla scrittura di codice non può in nessun modo essere imbrigliato in sistematici processi meccanici i cui risultati siano garantiti esser privi di difetti. Tra l’altro e se, come candidamente afferma, tali errori siano impossibili da dimostrare (e qui ha senz’altro ragione!), allora di che staremmo a parlare? Perché lamentarsi? Non ha alcun senso!

Ma ecco che dal cilindro arriva poi quella che, a suo dire, dovrebbe rappresentare la soluzione: <<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>>. La classica, banale, nonché alquanto comune tesi (sbagliata, ovviamente) che l’apertura dei sorgenti (e documentazione) sarebbe, di per sé, condizione necessaria per poter appurare la presenza di errori. Decenni di ingegneria inversa e migliaia di bug trovati analizzando i binari (e non i sorgenti!) non hanno insegnato nulla all’autore (che comunque non è il solo a sostenere questa stramba tesi della necessità dell’apertura dei sorgenti). Ma da programmatore sono decisamente più curioso di sapere in che modo il solo accesso ai sorgenti possa consentire di discernere che il software fosse stato appositamente rilasciato con pericolosi difetti: questo è, al momento, un mistero della fede (dell’autore)…

D’altra parte è lo stesso che si smentisce subito dopo: <<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>> (il grassetto è mio). Per cui caliamo un velo pietoso…

Ed essendo in chiusura, ecco che tira fuori l’asso che aveva custodito nella manica, ossia La Soluzione Finale: <<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>>. Quindi e siccome quanto aveva finora snocciolato era (ed è) impossibile da realizzare (oltre che insensato, aggiungo io), l’autore non trova niente di meglio da proporre che scardinare uno dei principi cardine di scienza, coscienza, e giurisprudenza: l’onere della prova. Dunque il produttore del software dovrebbe, in principio, essere ritenuto già colpevole di eventuali millantati difetti del suo prodotto, a meno che non sia lui a dimostrare il contrario. Con ciò possiamo davvero chiudere baracca e burattini, perché abbiamo toccato il fondo.

Ma, proprio perché siamo arrivati al capolinea, non poteva mancare la classica ciliegina sulla torta, con una fallacia logica da manuale (la falsa dicotomia): <<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>>. Il mondo, insomma, è o bianco o nero, per come lo concepisce l’autore. Per lui l’innovazione o è soltanto dare il via libera a prodotti malfunzionanti oppure migliorare la vita delle persone: non ci sono altre possibilità! Inutile rimarcare che il mondo, e la logica, funzionino ben diversamente.

A motivo di ciò posso affermare che non essere d’accordo con lui non equivale, infatti, a essere automaticamente dalla parte degli avidi o di chi addirittura metterebbe in pericolo la vita della gente. Anche qui, non trova niente di meglio da fare che un po’ di “sano” terrorismo psicologico per indurre gli sventurati lettori a mettersi dalla sua parte senza se e senza ma. Le sue tesi erano talmente “solide” da aver evidentemente bisogno di un altro aiutino…

10 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    Marco
     scrive: 

    Grazie Cesare, non idea da dove venga l’articolo originale e, per principio, non ho alcuna intenzione di cercarlo. Ma è stato l’occasione per una serie di tue osservazioni su cui concordo pienamente. Software come opera dell’ingegno è un perno fondamentale. Un discorso sul software che non parta da questo assunto, può essere portato avanti solo da qualcuno che dimostra di non avere alcuna competenza ed esperienza in materia.
    (È stato un piacere conoscerti al pycon it, ci torni mica quest’anno?)

  • # 2
    Cesare Di Mauro (Autore del post)
     scrive: 

    Grazie Marco. Sì, anche quest’anno sono alla PyCon it (forse con un talk, se mi decido a sottometterlo e dovesse venire accettato).

  • # 3
    nessuno
     scrive: 

    Ho letto l’articolo originale e mi permetto un commento da programmatore che ha lavorato in vari rami, anche considerati critici, e in qualche modo conosce la questione della responsabilità oggettiva di un codice mal funzionante.
    Non ho molto tempo, ma mi pare che sia un argomento piuttosto interessante da meritare che altro sia lasciato da parte per trattarlo meglio di come sia stato fatto dal sig. Andrea Monti sulle autorevoli pagine di un quotidiano di caratura nazionale.

    So che non è bello emettere giudizi sulle persone, ma il contenuto va valutato anche in base alle esperienze e “capacità” della persona che le espone e la descrizione della persona che ha scritto l’articolo di trova nello specchietto alla fine.
    Personalmente trovo parecchio imbarazzante che una persona che nella descrizione del proprio profilo scrive “avvocato” possa scrivere un articolo tanto raffazzonato senza alcuna logica né dal punto di vista legale, materia di cui dovrebbe almeno essere competente, né da quello tecnologico sulle cui lacune può essere scusato (ma io non farei il consulente per aziende informatiche allora).
    Ancora più perplesso rimango di fronte alla frase “mi occupo di bioinformatica”. Mi chiedo come un avvocato che ha quindi suppongo studiato legge e diritto possa avere competenze in campo biologico e informatico che sono i requisiti fondamentali per la suddetta materia. A meno che non abbia una moltitudine di lauree in tasca, sembra uno di quei casi in cui il bidello dice di lavorare nella pubblica istruzione al pari di un professore e quindi avere la facoltà di correggere i compiti degli alunni.

    Ma vediamo perché quell’articolo fa acqua da tutte le parti.

    L’ipotesi che viene avanzata è che vengono immessi sul mercato dei SW che non sono stati sviluppati “secondo le regole” (1) perché siano “sicuri” (2) e la responsabilità di eventuali danni sarebbe a carico di “nessuno” (cioè, non me, ma di alcuna entità giuridica) (3) e tutto ciò dipenderebbe dal fatto che il codice è ritenuta “opera di ingegno” (4), quindi non valutabile qualitativamente.
    E che alcune Software House sviluppino appositamente (5) senza alcun criterio di qualità finale per risparmiare soldi, lasciando gli eventuali danni che il proprio prodotto potrebbe causare a carico di altri.
    Il problema potrebbe risolversi con il codice “libero”, salvo poi ricredersi e dire che non è una via realmente percorribile.

    Nel mezzo si butta un pensiero sbadato alla così detta Intelligenza Artificiale (6), tanto per, senza avere in mente cosa essa sia e che implicazioni il suo abbia. Roba che da sola richiederebbe un volume per essere spiegata, ma per assurdo, dovrebbe essere scritto da un Avvocato (magari con la A maiuscola) perché le implicazioni dei loro effetti non sono di tipo tecnologico (una AI e le risposte che dà è a tutti gli effetti un programma come un altro dal punto di vista dell'”autore” che lo realizza, ma non da chi lo istruisce o da chi lo usa “già imparato”) ma sono di tipo etico, sociale e legale.
    Un informatico poco può riguardo a quelle considerazioni se non a spazzare via inutili credenze o pregiudizi riguardo alle AI (come sembra in questo preciso caso).

    Definita l’ipotesi, la tesi è un insieme di idee davvero poco chiare su tutti gli argomenti che tocca. E forse li tocca così superficialmente appunto perché non c’è alcuna competenza da parte di chi li scrive nella materia specifica.

    Ho evidenziato i punti nella tesi che vado a commentare. Purtroppo ciascuno potrebbe richiedere un libro a parte, ma non sarò così avventato :D

  • # 4
    nessuno
     scrive: 

    Vorrei anticipare uno dei punti perché è la base del discorso.

    4) Codice come opera di ingegno?
    Premetto che concordo sul fatto che il codice debba essere effettivamente considerato opera di ingegno, cioè si crea secondo le capacità personali di chi lo realizza non essendoci dei ricettari o delle formule statiche/prestabilite che definiscano come dato un problema si debba scrivere la soluzione (l’informatica serve a questo, risolvere problemi e dato un problema ci sono decine se non centinaia di modi di risolverlo informaticamente parlando).
    Il sig. Monti probabilmente non è al corrente che per tale ragione non si possano stipulare delle regole per imbrigliare le capacità di un “autore” di tale codice, esattamente come non ci sono regole per chi vuole dipingere qualcosa o scrivere poesie (o cucinare, altrimenti avremo cuochi tutti capaci uguali che fanno gli stessi identici piatti). Ci fossero tali regole, non servirebbe un programmatore umano per risolvere il problema, una macchina che assembla pezzi già fatti basterebbe (così come un bel Bimbi in cucina per fare le lasagne come descritto nella ricetta standard, e guai a cambiare anche solo la marca degli ingredienti!)
    Ma non si può fare perché a parte i problemi banali, i SW sono prodotti come definiti dall’economia: “Viene definito prodotto tutto ciò che può essere offerto a un mercato per attenzione, acquisizione, uso o consumo, per soddisfare un desiderio o un bisogno. “. Anche un quadro, un libro o un video sono dei prodotti anche se considerate opere di ingegno.
    Forse l’autore confonde “opera di ingegno” con “arte” ed è per questo che poi si lancia in improbabili paragoni con quadri e opere letterarie. Cioè che sfugge è il senso dell’utilità dell’opera in oggetto: quadri, libri, poesie, musica e film e possiamo metterci anche i videogiochi sono ARTE, nel senso che rispondono solo del gusto personale della persona che li usa (vede, legge, ascolta, interagisce) e se non ci piacciono possiamo ignorarli e non avere alcun tipo di effetti seguenti (se si è persone equilibrate, se poi si hanno gli incubi a vita per avere visto un film “spaventoso” allora il problema è altro, non l’opera di ingegno in se).
    Nell’arte figurativa per esempio la valutazione del piacere di un’opera varia a seconda del periodo o della cultura. Caravaggio era il pittore sacrilego, Van Gogh è morto squattrinato, Picasso ne ha fatto un business (e personalmente a me Picasso fa proprio schifo, ma non vado ad accusare i critici d’arte che non hanno delle regole standard, internazionali magari, per valutare cioè che è veramente arte e cosa invece immondizia da far morire Van Gogh di inedia ma arricchire Picasso).
    Un SW, ovvero una sequenza ben ordinata di istruzioni pensata per una macchina con certe caratteristiche è ARTE anch’essa. Per come è scritto, per come affronta i problemi che nascono, per come li risolve per come interagisce con altri parti di codice, per come gestisce le risorse, per come è ordinato (o no), per la sinteticità, per la chiarezza o in una parola per l’eleganza con cui si presenta il codice nella sua forma pura (quella del “sorgente) può essere considerato a tutti gli effetti “opera di ingegno al pari dell’arte”.
    Ma al sign. Monti probabilmente sfugge che il valore del codice non si ferma lì.
    Il codice quando messo in esecuzione deve eseguire anche del lavoro (cosa che lo opere d’arre pure non fanno, stanno lì, al massimo subiscono il maltrattamento di chi le gode) e questo lavoro, come tutti i lavori, causa il susseguirsi di azioni sulla base di input specifici. Gli effetti di queste azioni sono quelle che vanno ad affrontare i problemi che vorremmo risolti.

    Quindi abbiamo già tracciato una line di differenza tra un quadro e il nostro codice seppure siano entrambi da considerare opere di ingegno.
    Cosa li accomuna è semplicemente detto: la qualità finale non è facilmente definibile, dimostrabile o misurabile. Provate a fare una valutazione del genere con un quadro di Caravaggio e uno di Picasso, una scultura di Michelangelo e una di Pomodoro, valutate la qualità dei Promessi Sposi con Cime Tempestose o la Divina Commedia con l’Orlando Furioso.

    Di qualsiasi prodotto complesso in verità non si può dire nulla fino a prove concluse.
    Neanche dell’auto citata dall’autore: una macchina può rispettare tutte le regole di assemblaggio che si vuole ma è un insieme di migliaia di parti e la perfezione non è di questo mondo, neanche per quelle vetture che costano centinaia di migliaia di euro e non si può sapere se è perfetta finché non la si rottama, perché anche una Ferrari a 50.000Km può saltare una valvola o rompersi la pompa di benzina. O un freno, pensa! Anche loro sono prodotti fatti di materiale e possono rompersi!
    Per la responsabilità e garanzia vedesi punto 3

  • # 5
    nessuno
     scrive: 

    1) Regole di scrittura del codice
    Appurato che il codice è opera di ingegno che applica metodologie diverse a seconda della complessità del problema da risolvere e suoi contorni (ovvero lo stesso problema potrebbe doversi risolvere in maniera diversa a seconda di come sono altre condizioni che non riguardano il problem stesso) non è assolutamente vero che non esistono criteri di scrittura del codice.
    Esistono regole semplici per fare in modo che esso sia leggibile e comprensibile anche a chi non lo ha sviluppato e faciliti la fase di manutenzione dello stesso.
    Equivale, nella moderna progettazione degli apparecchi elettronici, a non concentrare tutto in spazi piccoli e angusti, con incollaggi e spine a incastro irremovibili che richiede di buttare tutto l’apparecchio nel caso di un piccolo guasto.
    Quanto siano rispettate queste regole dipende dall’azienda che deve gestire il codice, la quale sa che meglio è scritto il SW, meno costi avrà per “aggiustarlo” in seguito. Quindi codice ben scritto è a vantaggio dell’azienda e non un risparmio a meno che non parliamo di codice “usa e getta” che però è anche a valore zero e non usato per attività critiche.

    Esistono comunque delle regole standard che definiscono come deve essere scritto il codice e il rispetto di queste normative permette di certificare il SW secondo gradi di affidabilità che vanno dall’uso generico a “può causare direttamente la morte di una persona”.
    Ora non so che conoscenze abbia il nostro autore dell’articolo tanto inconcludente, ma spero non creda che il SW che fa girare il suo smartphone, o peggio quello del su TV smart, sia controllato come quello della macchina della dialisi o del trattamento delle chemioterapie.
    I danni che possono causare in caso di mal funzionamento sono diversi in tutti e tre i casi, e l’ultimo può anche avere anche conseguenze mortali. Nessuna azienda che sviluppa tali dispositivi si azzarderebbe a mettere in vendita un prodotto non testato al massimo. Chiuderebbe subito e per i costi di risarcimento e per la completa perdita di fiducia da parte di chi quegli strumenti li compra.
    Questo ci porta a parlare del punto..

  • # 6
    nessuno
     scrive: 

    2) La sicurezza
    Cosa si intende per sicurezza?
    In qualsiasi attività della vita, anche quella più comune, cosa consideriamo “sicuro” e cosa ci fa dire “sì, sono sicuro e quindi posso fare questa cosa senza il rischio di avere conseguenze”?
    Il tema della sicurezza è tanto vasto quanto inutile parlarne qui: in sintesi, la sicurezza totale non esiste in niente. Ne abbiamo visto gli esempi in Fukushima, dove una centrale costruita per resistere a un terremoto di grado 8 e uno tsunami mai visto in precedenza è collassata comunque.
    Quello che si dice ovunque è che l’eliminazione del rischio è impossibile, si può solo fare un compromesso tra accettare un rischio residuo piccolo quanto ci pare oppure non operare. Uscire di casa implica esporsi a decine se non centinaia di rischi man mano che siamo fuori e attraversiamo strade, cadono fulmini, passiamo in vie poco illuminate, calpestiamo marciapiedi sbilenchi con le foglie d’autunno il ghiaccio d’inverno, prendiamo un mezzo a due ruote o ci fiondiamo a 130Km/h in autostrada, saliamo su un treno o su un aereo (vedesi esempio citato dall’autore stesso). Ma se restiamo in casa siamo più sicuri? Gli incidenti domestici sono più diffusi di quelli sul posto di lavoro. Neanche nel letto siamo sicuri (con il solito esempio del meteorite).
    Quindi cosa facciamo normalmente? Decidiamo se una azione da svolgere è sufficientemente sicura e ne vale la pena. Se decidiamo che troppe cose della vita quotidiana non sono sicure ci limitiamo a vivere come in gabbia, dove stiamo (relativamente) sicuri, (ma neanche respirare lo è mai stato, come ci ha dimostrato il COVID-19) ma non ci godiamo la vita per come potremmo.
    Conclusione: non esiste la sicurezza totale.
    Quindi, come si fa a pretenderla in un oggetto, dispositivo o SW complesso che sia?
    Il SW come ogni altro bene è soggetto a difetti e tutti i difetti è vero che si possono potenzialmente eliminare, basta avere tempo infinito da dedicare al test.
    Con un tempo infinito di test è garantito che il numero dei difetti presenti in un oggetto è zero. Se non è infinito, non c’è garanzia. Quindi quanto lungo devo farlo questo test? A seconda di quanto sono critiche le conseguenze se l’oggetto non funziona come dovrebbe. Il dispositivo frenante dell’auto, così come l’apparato di sgancio dell’airbag hanno tempi e modi di test diversi per esempio dall’attuatore dell’alza cristalli o della ventola di aerazione.
    Cosa li distingue? Semplicemente il costo.
    E’ bello chiedere la massima sicurezza e qualità ma poi brontolare se il servizio/prodotto costa tanto. Prendereste un aereo con potenziale probabilità di caduta pari a zero se il biglietto per andare a New York costasse 100.000 euro?
    Comprereste la vostra utilitaria con difetti garantiti pari a zero per 250.000km (poi vabbe’, l’usura è l’usura), se vi costasse proprio 250.000 euro?
    E se il vostro telefono costasse 10.000 euro perché ha un OS granitico che non si inchioda mai in nessun caso e garantisse che la batteria non esploderà mai o prenderà fuoco? Ma garantito garantito, eh, non solo scritto sulla carta con un asterisco che riporta a clausole ad altezza 6 punti per mezza pagina (o schermo televisivo coma va di moda oggi.. davvero c’è qualcuno che riesce a leggerle?).
    Il compromesso costi/benefici è insito in qualunque cosa, altrimenti non potemmo fare proprio nulla non essendo la perfezione parte di questo mondo. Ma lo Shuttle lo abbiamo costruito e lanciato, nonostante sia esploso 2 volte con persone a bordo.
    E ciò ci porta al punto…

  • # 7
    nessuno
     scrive: 

    3) La responsabilità
    Ancora io non so a quale caso specifico facesse riferimento l’autore nel lamentare che i danno provocati da un malfunzionamento del SW non sia riconosciuto come tale e nessuno quindi ne risponda.
    In verità, essendo come ha ben specificato, il SW un prodotto e venduto come tale, esso ricade nello stesso insieme dei prodotti che sono pagati dietro una certa garanzia di funzionamento. L’autore può stare ben sicuro che se la macchina della dialisi provoca la morte del paziente qualcuno pagherà “e non perché è una macchina che ha vita propria o il SW che ci gira è opera di ingegno” allora nessuno (sempre non io) ne risponderà.
    Quell’innovazione che tanto acclama l’autore è proprio dovuto al fatto che il SW evolve e ogni versione integra più funzionalità della vecchia. Con servizi di un certo calibro e che coinvolge magari più macchine, di fanno decine di test di aggiornamento su sistemi “fittizi”, ma poi alla fine si arriva a dover fare l’aggiornamento al sistema vero, magari che non deve andare in down neanche per un secondo. Ma il sistema reale non quello di test e mille cose possono andare male e così combinare un disguido mentre si cerca “l’innovazione”.
    Quando succede, stia pur sicuro che qualcuno paga per l’errore. Magari il rimborso non arriva all’utente finale, ma il problema è giuridico della responsabilità generale dei fornitori di servizi verso i clienti (penso alle ferrovie) più del fatto che chi sbaglia a scrivere SW non paga. Crede forse che chi ha progettato il Boeing 737MAX non abbia pagato in termini di licenziamento? E se era una ditta esterna non abbia ricevuto una bella causa di risarcimento esattamente come la Boeing ha dovuto risarcire chi è morto negli incidenti?

  • # 8
    nessuno
     scrive: 

    5) La volontarietà
    Nell’ipotesi c’è anche il riferimento che vi sia intenzionalità a distribuire codice poco sicuro per risparmiare sui costi.
    A parte aver già trattato la questione costi/benefici, io non so davvero con quali Software House e aziende abbia a che fare il nostro autore, ma forse gli sfugge che in un mercato libero il valore di un prodotto è dato ANCHE dalla sua qualità.
    Se funziona male il marchio non sarà considerato più valido e perderà il suo appeal (ovvero la capacità di chiedere più soldi).
    Ma lo stesso identico ragionamento lo possiamo estendere a qualsiasi prodotto, non solo al SW. Perché mai il sig. Monti si scaglia contro il SW e non per esempio l’invasione degli elettrodomestici di infima qualità che non solo fanno disservizio, ma possono essere pericolosi (corto circuiti, incendi, danni a cose e persone se hanno lame o conservano i cibi o lavano oggetti) e soprattutto sono una fonte di quell’inquinamento di cui tanto parliamo ma poi nessuno fa niente per combatterlo davvero (sono sempre gli altri a dover farlo, io ho comprato la lampadina a LED e sono a posto così).

    Se invece parliamo di SW usato a livello di servizi di massa o industriale un malfunzionamento è cosa non grave ma persino intollerabile su tutti i livelli, e può anche arrivare a coinvolgere i CEO delle aziende fornitore/cliente.
    Perché un disservizio è un danno già di suo che non fa del bene né a chi il SW lo usa né a chi lo ha prodotto (vedesi clausole di rimborso in caso di danni, ed esistono assicurazioni solo per quello), ma se si insinua l’intenzionalità di volere fare un SW deliberatamente poco sicuro per speculare sui guadagni, allora in primis entra l’azione penale, in secundis il cliente ti saluta con la manina e non ti rivede più neanche se poi ti getti ai suoi piedi dicendogli che lo paghi invece che volerne.
    E infatti, in tutti i posti dove ho lavorato (e qui la mia esperienza) in aziende che producevano SW per altri, il cliente stesso dettava le regole per la creazione del SW e con controlli scrupolosi e continui perché il lavoro fosse fatto al meglio possible (ovviamente tenendo conto della questione costi/benefici e del fatto che il rischio zero non esiste).
    A meno di non ipotizzare una situazione di complotto tra aziende fornitore/cliente che deliberatamente in tandem progettano, realizzano e testano come positivo SW poco sicuro (per non si da quale ragione visto che poi a rimetterci è il cliente che lo mette in opera) la situazione non esiste. Almeno non qui in Europa. Se si acquista roba da provenienza ignota per uso personale (o nota ma giustificata da un sì, tanto costa poco) allora inutile lamentarsi.

  • # 9
    nessuno
     scrive: 

    6) L’intelligenza artificiale
    Cercherò di essere perché anche qui un libro non basterebbe a trattare tutti gli aspetti che ruotano attorno a questa tecnologia.
    L’autore si burla della distinzione tra codice “stupido” e codice che fa funzionare una “AI”.
    Tecnicamente parlando, come già detto, entrambi sono semplice SW, ovvero istruzioni di codice che vengono eseguire da una macchina che tra le sue caratteristiche proprie potenzialmente diverse da quelle di altre macchine ne ha una imprescindibile che la accomuna alle altre: è una macchina deterministica.
    Che significa stesso input = stesso output. Non si sfugge da questa regola, ed è ciò che rende i computer “stupidi”. Non sono in grado di “uscire dagli schemi”, ” di avere intuizioni”, ” di cambiare il piano di esecuzione previsto”.
    Rispondono ad stimoli elementari con azioni magari anche complesse, ma sempre le medesime se l’input è uguale.

    Quindi perché il risultato di un SW che esegue algoritmi “AI” sarebbe diverso?
    Perché l’AI è potenzialmente una macchina “pseudo non deterministica”. Sì, una macchina (poco) deterministica basata su una meccanica deterministica.
    Come è possibile? In primis perché il determinismo finale è dovuto a elaborazioni non di pochi input come nel codice “stupido” ma di miliardi se non centinaia di miliardi di dati e quindi conoscere esattamente quale che sia l’output non è possibile determinare a priori se non eseguendo il complesso algoritmo che genera il risultato partendo da una mole di dati enorme. Non c’è test statico che possa farlo.
    In secondo luogo perché il codice AI cambia il suo risultato cambiando il set di dati in ingresso. Ed essendo “una AI” tale modifica è considerata normale.
    A differenza del codice “stupido” che ha un algoritmo ben conosciuto e testato per elaborare i (relativamente) pochi dati in ingresso producendo un output sempre verificabile (e anche predicibile), con l’AI si ha (detto in breve) un effetto di elaborazione “variabile”, per cui lo stesso set in ingresso non dà lo stesso risultato ma questo dipende dalla storia passata (il così detto training della AI).

    Cosa significa tutto questo?
    Significa un sacco di cose.
    Prima di tutto, vista la mole di dati elaborati, è impossibile per chiunque riuscire a predire il risultato e quindi essere “responsabile” di quel che esce come decisione. Il risultato, così come esce, si può solo inserire in un insieme tra il “buono” o il “cattivo”. Quanto sia buono o cattivo rispetto al risultato atteso dipende da chi ha istruito la AI. E non c’è alcuna regola che definisce uno standard di “educazione per le AI”. Per assurdo una AI potrebbe essere addestrata per considerare buono l’eliminazione di una certo gruppo etnico e quindi ignorarne i diritti che noi consideriamo fondamentali.
    La responsabilità di quello che decide l’algoritmo AI, sulla base dei miliardi di dati a sua disposizione e dalle applicazioni a cui poi è messo a lavorare ha delle implicazioni che sono diverse dal dire “se l’input 1 è 0 allora accendo la luce rossa”.
    Senza entrare nel complottismo estremo della mente malvagia che vuole conquistare il mondo, basta un esempio banale. La guida autonoma è ormai notizia di tutti i giorni e non c’è giorno che non passa che si parli di sistemi con algoritmi di “AI” che facciano passi avanti per cercare di costruire una auto a guida autonoma sicura almeno quando quella di un guidatore umano capace.
    Ebbene a questa AI che controlla il movimento dell’auto è demandata la scelta dio cosa fare a seconda di quanto accade intorno all’auto (quindi secondo le capacità di percezione dei vari sensori e telecamere montati). Ora facciamo un esempio semplice: l’auto viaggia a velocità di 50 all’ora in zona urbana. Sul marciapiede c’è un gruppo di persone, che l’AI riconosce in numero di 3.
    L’auto nel procedere si avvicina a questo gruppo di persone e da qui possiamo creare tutte le casistiche che vogliamo. La più semplice, uno dei tizi sul marciapiede quando l’auto arriva a meno di 2 metri scende dal marciapiede. L’AI calcola che lo psazio di frenata non è sufficiente per non investirlo. Soluzione: spostarsi di corsia. Ma dall’altra parte arriva in veicolo in senso contrario.
    Scelta:
    1. l’AI decide che il tizio non va investito, cambia corsia e ti fa spiaccicare contro l’altro veicolo. La celta poteva anche essere dettata dal fatto che lo scontro tra due veicoli potrebbe non portare la morte di nessuno, mentre l’investimento sì.
    2. l’AI decide che non è il caso di coinvolgere qualcun altro non responsabile dell’azione del tizio e lo investe in pieno.
    Ora espandete il caso 2 in: il tizio era un bambino
    Oppure per il caso 1: il tizio era ubriaco e l’altra auto in senso opposto era una utilitaria (mentre voi avevate il bellissimo SUV da tre tonnellate) ed a bordo c’era una intera famiglia.
    Quale azione prenda l’AI fa un danno. Chi decide se è il minore possibile, coinvolgere gente che non ha colpe è giusto, rischiare la collisione tra auto per non avere un morto sicuro o salvare un bambino per la vita di possibile una famiglia è corretto? l’AI non prende la decisione “a caso”, ha un algoritmo addestrato. La scelta è deliberata, o anche “ignorante” nel caso le manchino i dati (è un ubriaco e quindi lo investiamo? No, rielaboriamo un’altra soluzione… ma “è un ubriaco negro e l’auto in arrivo è guidata probabilmente da bianchi? Allora sì, dai”. Ma chi decide quale è giusta? Chi controlla come è stata addestrata (lì anche se hai il codice open come vuole il sig. Monti non sai nulla di quale decisione prenderà perché come detto il risultato non è scritto nel codice ma dipende dal set di dati in uso al momento e il modello è incomprensibile a meno di non testarlo per tutti i miliardi di miliardi di miliardi di combinazioni possibili.. fattibile sig. Monti?). Come sa che l’addestra che la AI prenderà effettivamente quella decisione quando in ballo co sono miliardi di dati da elaborare? Ne è responsabile lui in maniera volontaria oppure rientra in quello che è un errore possibile del codice (o meglio del modello creato)?
    Ma sopratutto, l’AI prenderà una decisione migliore o peggiore di un essere umano alla guida? Che modello umano usiamo? Quello del cittadino che ha la patente da 5o e non ha mai fatto un incidente? Quello che parla al telefonino? Quello che ha bevuto prima di mettersi alla guida? La ragazza “che usa lo specchietto retrovisore solo per truccarsi”? Quello che pensa che la seconda corsia in autostrada sia sua e andando a 90 all’ora non si sposta nemmeno se c’è il deserto intorno, figuriamoci quando c’è traffico e non capisce che i sorpassi a destra sono perché è di intralcio agli altri?
    Questi sono tutti possibili tipologie di umani alla guida che scorazzano liberamente tutti i giorni sulle strade.. di chi deve essere meglio l’AI?
    Chi risponde di un danno provocato da una AI? Si può ipotizzare il fatto che l’AI abbia commesso un errore (volontario) nella decisione? Chi ne risponde? Chi Ha certificato il training? In che modo? Che ne sa che l’algoritmo è corretto? Che ne sa che non sarà modificato? Si dovrà rifare tutto l’iter di certificazione se cambia una virgola?
    Mille sono le domande a riguardo delle possibilità legate alle AI. Sopratutto quando sono interagenti (o supervisori) di umani. Basta vedere il caso di ChatGPT che ora spopola.. se domani dovesse cominciare a dire stupidate (tipo bevete la candeggina per guarire dal COVID, riproponendo il suggerimento di un illustre personaggio con una delle massime cariche al mondo), di chi sarebbe la colpa degli avvelenamenti? (e potrebbe invece avere il merito di aiutare alla eliminazione di inetti mentali sulla terra?)

    Finito, davvero :D

  • # 10
    Cesare Di Mauro (Autore del post)
     scrive: 

    Praticamente hai scritto un altro articolo sul tema. :D

    Grazie, perché hai fornito dettagli e spunti molto interessanti. :)

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.