AI – Aspetti pratici di responsabilità

Nonostante non sia regolamentata in Svizzera, l’IA pone diversi interrogativi dal punto di vista della responsabilità.

I. Introduzione

A. Una definizione operativa di intelligenza artificiale

Il termine intelligenza artificiale (IA) è un termine antico, soggetto a continui cambiamenti. A livello commerciale, venivano chiamati IA sistemi molto semplici, mentre oggi la tecnologia è per lo più utilizzata come sinonimo di sistemi basati su “reti neurali profonde”. A seconda del Paese o dell’istituzione, la definizione contiene elementi fondamentali diversi.1 Ai fini del presente articolo, l’IA è quindi generalmente indicata come un sistema basato su software in grado di risolvere problemi complessi precedentemente riservati all’uomo. 2 A tal fine, vi sono almeno due elementi che, senza definirli in termini generali, hanno spesso grande importanza nella letteratura giuridica corrente: la capacità di apprendere3 e la capacità di agire con un certo grado di autonomia4 . Questo articolo si concentra su alcuni aspetti giuridici dell’uso dell’IA che sono interessanti per chiarire le questioni di responsabilità.

B. Problemi pratici per le questioni di responsabilità

Indipendentemente dalla definizione di IA, ritengo che vi siano diverse caratteristiche comunemente attribuite a questa tecnologia che sono rilevanti per i casi di responsabilità. Queste possono essere raggruppate in quattro categorie: (i) la capacità di essere utilizzata in modo flessibile; (ii) la capacità di agire in modo autonomo; (iii) la capacità di apprendere continuamente; e (iv) la capacità di trarre conclusioni da una grande quantità di dati.

1. La capacità di essere applicato in modo flessibile

I programmi informatici classici sono molto prescrittivi: ogni possibile opzione deve essere esplicitamente programmata nel software perché funzioni. Se il programma informatico incontra una situazione inaspettata, grosso modo non funziona più. Nelle soluzioni basate sull’IA, invece, l’IA impara con l’esempio a generalizzare un compito in modo da essere in grado di gestire in modo flessibile un numero infinito di situazioni diverse senza dover anticipare e pre-programmare ogni singola possibilità.5 Nello sviluppo di modelli di IA6 , un sistema viene addestrato e testato più volte fino a raggiungere un tasso di correttezza soddisfacente. Tuttavia, se durante l’addestramento si raggiunge la perfezione, questo è quasi sempre segno di un errore fondamentale, ovvero l'”overfitting”. In altre parole, ha imparato gli esempi “a memoria” o ha appreso un approccio molto rigido e quindi potrebbe gestire male i casi d’uso futuri che differiscono anche di poco dagli esempi utilizzati durante l’addestramento.7 Poiché questa generalizzabilità può essere vista, in ultima analisi, come un approccio statistico molto complesso, lo svantaggio è che si ha meno controllo su come vengono trattati i casi limite, nuovi o eccezionali. Quindi, mentre con i programmi classici si può (e si deve) dire con certezza in anticipo come verrà trattato ogni caso, con le soluzioni basate sull’IA c’è sempre un margine di errore che deve essere preso in considerazione. Per mitigare il fatto che l’IA pura è intrinsecamente soggetta a errori o potenzialmente imprevedibile (anche se spesso è meno soggetta a errori rispetto all’uomo medio), viene quindi abbinata alla codifica classica, che ne supporta la funzionalità.

2. La capacità di agire in modo autonomo

Una delle funzioni fondamentali dell’informatizzazione e dei programmi informatici è sempre stata quella di velocizzare e automatizzare i compiti umani. Grazie alla già citata capacità dei sistemi basati sull’intelligenza artificiale di gestire in modo flessibile gli input e quindi di svolgere compiti molto complessi in modo simile o addirittura superiore alle capacità di un essere umano, si confida sempre più che le macchine decidano autonomamente il miglior corso d’azione per portare a termine i compiti assegnati. A causa di questa nozione di autonomia del programma informatico, anche la catena causale tra le azioni del sistema basato sull’IA e l’utente è percepita come più debole8.

3. Capacità di apprendimento continuo

Con i programmi informatici programmati tradizionalmente, ogni regolazione deve essere pensata in anticipo e programmata esplicitamente. Se le circostanze in cui il software viene utilizzato cambiano, il programma informatico deve essere adattato manualmente. I sistemi dotati di intelligenza artificiale, invece, sono in grado di apprendere dall’esperienza: le informazioni raccolte durante l’esecuzione dei compiti assegnati possono essere utilizzate per insegnare a questi sistemi a svolgere meglio i compiti e ad adattarsi alle circostanze che cambiano. Questo indebolisce ulteriormente il legame percepito tra il programmatore e il risultato del sistema basato sull’IA9.

4. La capacità di trarre inferenze da un grande volume di dati

Una delle capacità di trasformazione della tecnologia AI è la capacità di trarre automaticamente inferenze e connessioni da un grande volume di dati e di utilizzare questa conoscenza per portare a termine un compito. Ciò consente di affrontare problemi che in precedenza erano considerati troppo difficili a causa della loro complessità.10 L’IA è in grado di trovare autonomamente soluzioni a determinati problemi o di fare previsioni sul futuro a partire dai dati con maggiore certezza. Poiché l’approccio di un sistema di IA è diverso da quello di un essere umano, lo stesso sistema può raggiungere un elevato grado di correttezza ma commettere errori evidenti anche a un profano. È diventato presto evidente che i dati utilizzati dall’IA a questo scopo non solo hanno il potenziale di identificare le relazioni causali di base e le regole scientifiche del problema da risolvere, ma contengono anche una grande quantità di correlazioni insignificanti, pregiudizi incorporati e idee sbagliate, nonché cattive abitudini. Queste influiscono sul funzionamento dei sistemi di IA e possono portare a risultati indesiderati.11 Questa consapevolezza cambia radicalmente il significato dei dati. A differenza dei classici programmi informatici, in cui la codifica è al centro, lo sviluppo di sistemi basati sull’IA richiede anche una manutenzione dei dati sottostanti finora poco conosciuta.

II. Problemi di responsabilità

In pratica, l’IA può essere utilizzata in modi molto diversi e tocca la maggior parte dei settori della nostra vita. Se provoca un danno, nella maggior parte dei casi esiste un rapporto contrattuale tra la parte lesa e la parte responsabile, oppure i fatti del caso sono regolati da specifici standard legali di responsabilità, per cui occorre tenere conto delle circostanze specifiche del singolo caso. Ciononostante, vale la pena di esaminare le questioni specifiche della responsabilità civile, poiché queste coprono la maggior parte delle questioni giuridiche di base del diritto della responsabilità civile.

A. Responsabilità civile

La responsabilità per fatto illecito ai sensi dell’Art. 41 CO è considerato uno standard generale per la responsabilità civile nel diritto della responsabilità civile. Per stabilire la responsabilità, devono essere dimostrati i seguenti punti: il danno, l’illegalità dell’inflizione del danno, il nesso di causalità (adeguato), la condotta illecita dell’autore del reato e la sua colpa.

1. danno e illegalità

Nel contesto della responsabilità civile, il danno rilevante è solitamente definito come un danno a un bene giuridico assolutamente protetto, ossia persone e proprietà. Questi due aspetti della legge sulla responsabilità civile non sono molto particolari nel caso dei danni causati dall’IA e pertanto non saranno discussi ulteriormente.

2. nesso di causalità

a. Autonomia di un sistema di IA

Nelle applicazioni di IA, l’aspetto dell’identificazione della persona responsabile e quindi della determinazione del responsabile è particolarmente difficile. Un primo aspetto da considerare è quello dell’autonomia dei sistemi che possono agire autonomamente (cioè agire in modo giuridicamente rilevante secondo la propria programmazione). In questi casi, ci si chiede se un sistema di IA possa raggiungere un tale grado di autonomia da non poter essere ritenuto responsabile delle sue azioni. La risposta è in linea di principio negativa, poiché è sempre possibile individuare almeno una persona responsabile della creazione di un sistema basato sull’IA e delle sue capacità, e una responsabile del suo utilizzo.13 È possibile descrivere diversi scenari che descrivono il grado di controllo umano sui sistemi di IA autonomi quando vengono utilizzati e che possono aiutare ad attribuire la responsabilità14.

• L’uomo nel ciclo: In questo caso, l’uomo è coinvolto nel sistema come responsabile e decisore. Ciò significa che il sistema di IA può essere diviso in due parti: La prima parte, caratterizzata dall’IA, è un sistema di supporto alle decisioni che offre il miglior corso d’azione o le migliori opzioni d’azione. La persona prende quindi la decisione di intraprendere o meno una determinata azione. La seconda parte del sistema è la successiva esecuzione dell’azione decisa, che dovrebbe essere computabile e corrisponde quindi al problema dell’imputabilità di un programma informatico classico. Se, nonostante il coinvolgimento di una persona, le conseguenze della sua decisione non possono essere determinate perché è nuovamente coinvolto un sistema di intelligenza artificiale, questa seconda parte del caso corrisponde a una delle categorie successive.
• Umano nel loop: In questo caso, un umano è coinvolto sia nell’implementazione che nel monitoraggio delle attività del sistema di IA. Il sistema di IA può fondamentalmente svolgere il compito assegnatogli in modo indipendente. Una persona non deve approvare o determinare ogni singola azione, ma monitora regolarmente l’attività del sistema basato sull’IA e può intervenire se necessario quando vengono rilevati problemi. La differenza fondamentale tra “in the loop” e “on the loop” è quindi che nel primo caso l’uomo ha una funzione decisionale, mentre nel secondo caso ha una funzione di monitoraggio reattivo.
• Umano fuori dal loop: In questo caso, il sistema di intelligenza artificiale funziona in modo completamente autonomo in ogni operazione, in modo che la possibilità che una persona intervenga sia limitata. In linea di principio, l’uomo non interviene nell’esecuzione dell’attività assegnata. Ciò avviene quando il sistema agisce sulla base di un’IA pre-addestrata, ma anche quando l’IA viene addestrata in modo indipendente dall’esperienza accumulata durante l’operazione.

Con “human in the loop”, una persona identificabile è in grado di determinare l’azione del sistema basato sull’IA. Questo è solitamente il caso in cui il sistema basato sull’IA svolge il lavoro preliminare per l’uomo. Questo tipo di utilizzo viene scelto, in pratica, quando l’IA deve svolgere solo un semplice lavoro meccanico preliminare, come l’estrazione automatica di informazioni da un documento, in situazioni in cui il rischio di danni è elevato, come nel caso di una diagnosi, o in situazioni complesse in cui la soluzione richiede un mix di competenze della macchina e dell’uomo, come nel caso dell’analisi di una situazione di mercato complessa per prendere una decisione di investimento. La responsabilità dell’utente può essere attenuata o esclusa se il programma è difettoso15 o se l’utente non è in grado di riconoscere le conseguenze della sua decisione o di esaminare la soluzione proposta dall’IA in modo sufficientemente critico.16 Le ragioni di quest’ultima eventualità spesso non risiedono nella natura della tecnologia IA utilizzata (poiché essa ha già contribuito prima che la persona prenda una decisione), ma piuttosto nella mancanza di informazioni, di formazione della persona che è “nel giro”, o nella negligenza della persona che, nonostante una formazione o un’istruzione sufficiente, non ha le competenze necessarie per svolgere il suo ruolo.

Nel caso di “human on the loop”, il sistema è fondamentalmente in grado di agire in modo indipendente, ma è supervisionato da una persona. Ciò avviene di solito per eliminare i rischi persistenti che possono insorgere nonostante un uso conforme allo scopo prefissato del sistema di IA, o nel contesto di un uso improprio ragionevolmente prevedibile.17 L’imputabilità del danno dipende dalla capacità della persona che lo supervisiona di influenzarlo. Il supervisore può essere colpevole se, nonostante il dovere e l’opportunità di agire, non riesce a interrompere o impedire il comportamento scorretto del sistema basato sull’IA e a mitigare o addirittura annullare immediatamente il danno.18 Se, tuttavia, il danno è causato dal comportamento scorretto dell’IA nonostante il comportamento doveroso del supervisore, la colpa e quindi il responsabile devono essere ricercati altrove. Di solito si tratta del fornitore della soluzione di IA. Se non vi sono prove che il fornitore sia responsabile a causa di un errore dell’IA, può venire in soccorso la dottrina della teoria del rischio generale19 , per cui l’utente o il proprietario del sistema, a seconda di chi avrebbe avuto la migliore opportunità di evitare il danno, può comunque essere considerato il responsabile.

Con “l’uomo fuori dal giro”, il sistema è fondamentalmente lasciato a se stesso per svolgere il proprio compito. Questa costellazione è spesso discussa nel contesto delle armi autonome e dei relativi sforzi per vietarle20 , ma è più nota per l’uso di veicoli autonomi e per l’automazione di alcuni processi. In questo caso, l’intervento umano durante il funzionamento del sistema basato sull’IA non è in linea di principio previsto, a meno che non venga fatto per regolare l’obiettivo della macchina (si pensi a un’auto autonoma che permette di regolare la destinazione prima della fine del viaggio). In questo caso, l’utente del sistema supportato dall’IA, ossia la persona che ha avviato l’attività del sistema supportato dall’IA, può essere in linea di principio colpevole solo se l’obiettivo previsto o l’uso stesso del sistema di IA completamente autonomo è in violazione di un dovere. Ad esempio, l’uso di tale sistema viola il dovere se il sistema basato sull’IA non può essere utilizzato in modo sicuro (ad esempio, un veicolo non è in grado di rilevare ed evitare in modo affidabile gli esseri umani)21 , se non sono previste le necessarie misure di sicurezza (ad esempio, non vi è alcuna limitazione alla capacità di transazione di un sistema di trading automatizzato) o se l’uso del sistema di IA è abilitato da persone che non sono in grado di riconoscere ed eliminare in modo appropriato i pericoli (ad esempio, A mio avviso, la liceità dell’uso di un sistema basato sull’IA completamente autonomo non può essere semplicemente assunta quando non è richiesto di esercitare una ragionevole attenzione rispetto al potenziale di danno.

Può essere relativamente facile utilizzare la suddetta categorizzazione per stabilire il nesso causale tra l’applicazione di IA e il suo utilizzatore o fornitore.23 Tuttavia, nei singoli casi è più difficile sviluppare questo nesso causale a partire da lì, in modo da identificare una possibile causa tecnicamente difettosa. In particolare, è necessario analizzare cosa può accadere nella catena causale al fine di identificare ulteriori persone che possono essere ritenute potenzialmente responsabili di un danno.

b. Trasparenza di un software di IA

In generale, si può affermare che la persona che causa il danno può essere identificata come l’utente o il creatore del programma quando il funzionamento di un programma informatico classico dipende direttamente dalla sua codifica.24 Un’applicazione di IA, invece, è il risultato della combinazione di un software (che corrisponde alla codifica classica) e dei dati utilizzati per addestrarlo. Entrambi i fattori svolgono un ruolo cruciale e spesso possono essere attribuiti ad almeno due persone diverse. Ciò significa che il numero di possibili colpevoli si espande in modo rilevante, il che a sua volta significa che i fatti da chiarire diventano più complessi.25

Per quanto riguarda i dati, poiché i singoli dati influenzano solo una frazione del funzionamento dell’applicazione di IA, è difficile determinare quale serie di dati, e in quale misura, abbia causato il risultato illecito del sistema26 . La base di un sistema di IA può essere costituita da uno o più modelli generali pre-addestrati forniti da terzi, per i quali non vengono forniti i set di dati utilizzati per l’addestramento. In seguito, possono essere utilizzati set di dati proprietari per adattare il modello ai propri scopi. Infine, il modello viene spesso addestrato e aggiornato utilizzando dati raccolti di recente. Per motivi di protezione dei dati, i dati per l’addestramento continuo del sistema spesso non sono disponibili o lo sono solo in forma criptata27.

In termini di codifica, lo sviluppo dell’IA oggi, come per tutti i software moderni, si basa di solito su molte risorse diverse disponibili pubblicamente e molto complesse.28 Anche il codice che rende possibile un’applicazione funzionante può ammontare a milioni di linee di codice provenienti da fonti diverse, così che in singoli casi la tracciabilità di un bug può essere quasi impossibile.29

Di recente, la discussione sulla spiegabilità e sulla comprensibilità delle applicazioni di IA si è sviluppata in modo tale che attualmente si stanno sviluppando molte buone pratiche e servizi che cercano di rendere trasparenti i fattori decisionali di un’IA e quindi di spiegarne il funzionamento (le cosiddette “IA spiegabili” e “IA interpretabili”)30.

Nonostante questi sviluppi positivi, diventa quasi impossibile per la parte lesa dimostrare la causa effettiva dell’evento dannoso, poiché ciò richiede l’accesso illimitato a tutti i file di log esistenti, alla codifica del software e, se non è disponibile nient’altro che garantisca la trasparenza dell’IA, ai dati utilizzati come addestramento.31

In assenza di trasparenza del sistema, viene in soccorso la dottrina della teoria generale del rischio, dal momento che non si può dire con esattezza quale sia la causa del danno.32 Secondo questa dottrina, chi crea, mantiene o è comunque legalmente responsabile di una condizione di pericolo deve adottare tutte le misure di protezione necessarie e ragionevoli, idonee a evitare la lesione degli interessi giuridici protetti.

Se si segue l’argomentazione che l’IA, per sua natura, ha il potenziale di agire in modo inaspettato e che questo può avere effetti negativi su beni giuridicamente protetti (come la proprietà, la vita o la salute), allora l’utente o il fornitore ha il dovere di mitigare il danno. A mio avviso, la parte lesa non è quindi tenuta a dimostrare la catena causale oltre il fornitore per far valere la propria pretesa ai sensi dell’Art. 41 CO. 41 CO. Deve solo essere in grado di dimostrare che il prestatore non ha adottato le misure di diligenza necessarie per mitigare il danno.

Questo approccio presuppone che si debbano adottare restrizioni di sicurezza nonostante il grande successo di un sistema basato sull’IA. Questo atteggiamento è confermato dalla discussione sull’uso dell’IA. Il limite di questa responsabilità è rappresentato dalla dottrina del rischio ammissibile. Secondo questa dottrina, “un pericolo per gli interessi giuridici altrui che non vada oltre il rischio generale della vita non può essere vietato, ma si può solo esigere il rispetto di un certo grado minimo di cura e considerazione. Nel caso di un rischio consentito, la proibizione di qualsiasi pericolo è sostituita dall’obbligo di limitare il pericolo al minimo che non può essere escluso del tutto o solo con uno sforzo sproporzionato, se l’attività corrispondente deve essere consentita. Ciò riguarda la questione dei rischi generalmente accettabili e non una riduzione degli obblighi di diligenza. Una violazione del dovere di diligenza è da considerarsi solo se l’autore del reato poteva o doveva prevedere un rischio per gli interessi legali della vittima. Per rispondere a questa domanda, si applica lo standard di adeguatezza. In base a questo criterio, la condotta dell’autore del reato deve essere idonea, secondo il corso abituale degli eventi e le esperienze della vita, a produrre o almeno a favorire un risultato come quello che si è verificato. Affinché il risultato sia attribuibile all’autore del reato, non è sufficiente la sua mera prevedibilità. Occorre piuttosto chiedersi se il risultato fosse anche evitabile. A tal fine, si esamina un ipotetico percorso causale e si verifica se il successo non si sarebbe verificato se l’autore del reato avesse agito correttamente. Per l’attribuzione del risultato, è sufficiente che la condotta dell’autore del reato sia stata la causa del risultato con almeno un alto grado di probabilità o con una probabilità che rasenta la certezza”.33

3. La colpa

a. Colpa dell’utente (Human in the loop)

Per stabilire la colpa, deve essere stato violato un dovere di diligenza34 . In questo contesto, si pone la questione di chi sia effettivamente responsabile tra l’utente e il fornitore di una soluzione di IA se la violazione dell’obbligo di diligenza consiste nella mancata adozione delle misure necessarie a evitare il danno. In particolare, ci si chiede se sia possibile stabilire un obbligo di agire e come la parte lesa possa dimostrare la violazione di tale obbligo.

1. L’UOMO NEL LOOP

Nei sistemi basati sull’IA in cui una persona mantiene la funzione decisionale, devono essere soddisfatti sia l’aspetto oggettivo che quello soggettivo della colpa affinché le azioni del sistema siano attribuibili a tale persona.35

Per quanto riguarda l’aspetto soggettivo, la persona deve essere in grado di comprendere le conseguenze delle proprie azioni e agire diversamente.36 Questo aspetto può essere rilevante se una persona utilizza un prodotto di IA senza essere in grado di valutare criticamente le opzioni proposte dal sistema di IA. In questo caso, la persona non è in grado di riconoscere il potenziale danno. Tuttavia, ciò vale solo se questa situazione non è autoinflitta (la cosiddetta colpa di assunzione), nel senso che la persona assume un’attività per la quale non è sufficientemente qualificata37.

Dal punto di vista oggettivo, l’utente deve esercitare la cura che un terzo ragionevole avrebbe esercitato nella stessa situazione per evitare questo danno prevedibile. L’utente dovrà quindi esercitare una ragionevole attenzione nella scelta della soluzione e del fornitore, nonché nell’applicazione della soluzione basata sull’IA. Ciò comprende, tra l’altro, un’analisi dei rischi legati all’uso del sistema basato sull’IA e l’attuazione delle misure ragionevoli che ne derivano, che possono essere molto diverse se l’utente è un consumatore o una grande azienda.38 È importante notare che l’utente non deve essere uno specialista di IA o di informatica se utilizza soluzioni esterne. Tuttavia, deve essere in grado di spiegare le proprie esigenze al fornitore di IA in modo che quest’ultimo possa avviare le fasi tecniche necessarie e garantire una formazione adeguata.39 Poiché l’utente deve essere nella posizione decisionale, deve anche assicurarsi di essere in grado di valutare la correttezza del funzionamento del sistema di IA o di disporre di un quadro di sicurezza adeguato per prevenire eventuali danni. In caso contrario, potrebbe essere responsabile a causa di un errore di assunzione.40

Questi requisiti possono essere difficili da soddisfare quando si implementa un sistema di IA che dovrebbe trovare la soluzione migliore di un umano, ma per il quale non è disponibile una spiegazione comprensibile. In questi casi, l’uomo dovrebbe essere utilizzato come decisore per correggere gli errori del sistema di IA che sono evidenti all’uomo ma non alla macchina. In questi casi, la macchina decide se la soluzione proposta è accettabile. La questione della misura in cui la fiducia in una macchina è giustificata dipende, a mio avviso, sia dalla comprovata efficacia del sistema sia dalle misure di sicurezza applicate, comprese le qualifiche di chi prende le decisioni. Quanto maggiore è il rischio di una decisione sbagliata, tanto maggiori sono le esigenze della persona incaricata della supervisione.

2. UMANO SUL LOOP

Una situazione simile si verifica quando una persona ha solo una funzione di monitoraggio, ma in questo caso la persona spesso non è responsabile del controllo di tutte le singole decisioni del sistema, ma solo di riconoscere una situazione che si discosta da quella prevista e di intervenire per evitare possibili danni da una decisione sbagliata. Pertanto, non è necessario che la persona sia competente nella stessa area del sistema di intelligenza artificiale, ma solo che sia in grado di riconoscere un comportamento dannoso o situazioni potenzialmente dannose e di intervenire di conseguenza.

3. L’UOMO FUORI DAL CIRCUITO

Se il sistema supportato dall’IA è completamente autonomo, l’utente deve oggettivamente aver adottato tutte le misure di sicurezza ragionevoli per evitare danni. L’aspetto concreto di queste misure dipende dalle circostanze d’uso.

Dal punto di vista soggettivo, la persona deve essere in grado di comprendere le conseguenze delle proprie azioni e di agire in modo diverso. Questo aspetto può essere rilevante se una persona utilizza un prodotto di IA e non ci si può aspettare che prenda in considerazione un malfunzionamento del sistema supportato dall’IA. Questo potrebbe essere il caso, ad esempio, di un drone dotato di una funzione di controllo dell’IA che vola contro una persona perché il drone non la riconosce come un ostacolo. In questo caso, spesso entra in gioco la responsabilità da prodotto o un’altra legge speciale sulla responsabilità che assegna il rischio di danni fisici in modo diverso dalla normale responsabilità civile.

b. Colpa del fornitore

Naturalmente, non è solo l’utente a poter essere colpevole, ma anche il fornitore che si assume la responsabilità dello sviluppo della soluzione di IA. Il fornitore deve garantire che sia stata prestata una cura ragionevole nello sviluppo della soluzione di IA.

Il grado di cura da applicare oggettivamente dipende principalmente dall’uso previsto e dalle proprietà promesse.

Poiché l’IA è ancora una scienza nuova e in rapida evoluzione, è difficile identificare le migliori pratiche che possono essere applicate in un determinato caso e servire come base per determinare una sufficiente due diligence nello sviluppo.41 Poiché l’IA è un software, è possibile utilizzare come strumento standard consolidati come le norme ISO.42 Attualmente, è in corso un ampio dibattito sulla regolamentazione dell’IA nell’UE, tra gli altri. In particolare, è stata proposta una regolamentazione a livello europeo per stabilire i principi dei requisiti di un’assistenza sufficiente. A ciò si sono affiancate linee guida etiche che stabiliscono i requisiti etici per lo sviluppo dell’IA. Esistono già standard per le tecnologie di IA e altre iniziative di standardizzazione, come l’iniziativa ISO, che si occupano di IA.43 Con tutti questi standard, si pone la questione, poiché spesso non hanno forza di legge, di quanto velocemente e in che misura un fornitore o uno sviluppatore di IA debba implementare questi requisiti, dal momento che tracciarli e implementarli comporta un grande sforzo, che a sua volta può ostacolare lo sviluppo e l’applicazione di sistemi basati sull’IA. Anche in questo caso, si tratta di un giudizio di valore che dipende dalle circostanze.

In generale, il fornitore della soluzione di IA dovrebbe esercitare la dovuta diligenza per garantire di aver seguito le migliori pratiche in vigore all’epoca (e quelle in vigore oggi, se è responsabile della manutenzione del software, che al giorno d’oggi è la regola piuttosto che l’eccezione) nello sviluppo del suo strumento, in modo che l’applicazione di IA non sia pericolosamente difettosa, e di aver adottato tutte le misure di sicurezza ragionevoli per mitigare il potenziale danno derivante da un difetto della soluzione di IA.

Va notato che nello sviluppo di soluzioni basate sull’IA, due ipotesi con effetti diametralmente opposti sono in competizione tra loro: da un lato, come si è visto, l’algoritmo di IA puro è intrinsecamente soggetto a errori, il che è molto spesso riconosciuto, e quindi vengono utilizzate misure di sicurezza come i confini fisici o hard-coded. Tuttavia, l’applicazione del principio di minimizzazione del rischio, che mira a evitare tutti i pericoli, si scontra con il fatto che è impossibile evitare tutti i rischi possibili per fornire soluzioni valide e utili. Pertanto, è necessario prendere in considerazione il principio del rischio ammissibile. Il fattore decisivo in questi casi è una questione di valore che non può essere risolta in anticipo.

La questione della colpevolezza di un’applicazione di IA è legata a diversi problemi. Da un lato, la colpa da dimostrare dipende dal danno. Così, nella responsabilità civile, a causa della limitazione dei danni coperti, un difetto è rilevante solo se è causale per il danno, il che presuppone anche che l’uso dell’applicazione di IA sia conforme all’uso previsto.44 In secondo luogo, come già menzionato, il successo delle applicazioni di IA risiede nel fatto che apprendono una soluzione generalmente valida dai dati di apprendimento e la utilizzano in modo flessibile. Tuttavia, l’esperienza insegna che ci saranno sempre casi eccezionali, per cui gli errori non potranno mai essere completamente evitati. Inoltre, un’applicazione di IA può essere considerata difettosa sotto vari aspetti.

Un primo aspetto che può essere utilizzato per determinare la difettosità di un sistema di IA è il tasso di successo generale nel completamento del compito assegnato: la soglia esatta del tasso di successo per determinare la difettosità dipende dalle circostanze e non può essere determinata in modo oggettivo, ma deve essere considerata in modo relativo. Nel dibattito sull’IA, gli esseri umani sono spesso presi come punto di riferimento. Ma quale essere umano o gruppo di esseri umani dovrebbe essere preso come punto di riferimento? E l’asticella delle applicazioni dell’IA dovrebbe essere più alta di quella degli esseri umani? E considerando che nessun essere umano è perfetto e tutti commettono errori45 , è l’uomo il giusto punto di riferimento per questa misurazione? Queste questioni etiche molto delicate dipendono dall’ambito pratico di applicazione, dallo stadio di sviluppo della tecnologia e dagli interessi legali in gioco. Così, mentre si può essere meno severi sulla capacità di un sistema di irrigazione basato sull’intelligenza artificiale per le piante in un appartamento, si vorrà raggiungere una sicurezza quasi assoluta per i dispositivi medici vitali46.

Supponendo che questo benchmark sia stato identificato e definito e che si possa dimostrare, sulla base di vari eventi, che il tasso di successo effettivo è inferiore al benchmark stabilito, si può parlare di una soluzione AI difettosa. Tuttavia, anche se il sistema è generalmente considerato non difettoso perché ogni errore rientra nel margine di errore accettato, ciò non significa ancora che il singolo errore non sia dovuto a una violazione imputabile di un dovere di diligenza.

Un secondo aspetto è quindi il tasso di successo specifico: è difficile classificare i singoli eventi all’interno o all’esterno di un’accuratezza accettata.47 Per verificare il tasso di successo di un sistema basato sull’IA, è necessario disporre dei dati statistici necessari e, se questi mancano, è necessario dimostrare una violazione più precisa del dovere di diligenza. Come già accennato, negli ultimi anni si è diffuso il tema dell'”IA spiegabile”, tanto che si stanno sviluppando tecniche e servizi che tentano di rendere trasparenti i fattori più importanti per la decisione di un’IA e il suo funzionamento.48 Tuttavia, queste tecniche spesso devono essere applicate in anticipo, poiché l’uso retrospettivo non è sempre possibile. Un singolo errore può quindi essere il risultato di un problema nei dati di apprendimento da cui il sistema di IA ha appreso una regola errata (questo è noto come “bias”). Se si dimostra che il risultato dannoso è la conseguenza dell’inserimento di dati errati (ad esempio, perché non è stata prestata la dovuta attenzione alla selezione e alla preparazione di questi dati, o perché qualcuno è stato in grado di inserire dati falsificati perché non sono state adottate misure adeguate per contrastarli), la responsabilità può essere attribuita sulla base di questi errori. Va notato che il fornitore di IA può essere ritenuto responsabile per non aver adottato le misure di diligenza necessarie a evitare dati errati, se l’evento dannoso deriva dall’accumulo di diverse serie di dati provenienti da fonti diverse, ognuna delle quali di per sé non avrebbe potuto influenzare sufficientemente il modello.49

Lo stesso vale se viene riscontrato un errore nel codice. In questo caso è necessario verificare se ci sono carenze nello sviluppo dell’architettura dell’IA (ad esempio, i segnali sbagliati vengono filtrati o ponderati in modo errato) o nella codifica di un software o di un processo in cui la soluzione di IA è incorporata (ad esempio, in assenza di limiti di sicurezza ragionevoli).

Al fine di elaborare i criteri precisi per determinare i requisiti pratici per il sistema di IA e per le persone che interagiscono con esso, è importante ricordare che l’uso di queste soluzioni basate sull’IA non avviene in un vuoto giuridico, per cui, a seconda dell’area di applicazione, spesso esistono già tutele tecnologicamente neutre e obblighi di diligenza volti a prevenire l’inflizione di danni. L’unicità di una soluzione basata sull’IA in questo senso è che i doveri di diligenza applicabili devono spesso essere presi in considerazione prima che la soluzione IA venga utilizzata, ossia durante lo sviluppo e la pianificazione, anziché solo durante il funzionamento del sistema, poiché i suoi effetti sono diffusi e quindi più evidenti rispetto ai metodi precedenti.

B. Responsabilità del prodotto

I danni a beni fisici legali causati da un sistema supportato dall’IA rientrano spesso nella responsabilità del prodotto, poiché l’IA deve essere incorporata per ottenere tale risultato. In base alla legge sulla responsabilità del prodotto, questa responsabilità non può essere limitata in modo particolare.50

A differenza della responsabilità civile, tuttavia, in base all’art. 4 della legge sulla responsabilità del prodotto, invece della colpa deve essere dimostrato solo un difetto del prodotto. 4 della legge sulla responsabilità del prodotto. Il creatore di una soluzione di IA è quindi, come sostenuto da gran parte della dottrina, spesso responsabile come creatore ai sensi della legge sulla responsabilità del prodotto per danni alla proprietà e alle persone.51 Questo è certamente il caso se l’IA è un componente di un oggetto mobile. Più difficile è la situazione quando il software basato sull’IA e l’oggetto su cui l’IA gira sono separati, in modo che il produttore dell’oggetto non possa assumersi alcuna responsabilità per la componente software. Questo è il caso sempre più frequente dell’attuale tendenza a offrire piattaforme fisiche per le quali terzi possono sviluppare e offrire i propri componenti software.52 Sebbene sia controverso e nonostante il potenziale di miglioramento della regolamentazione, in queste situazioni una parte della dottrina sostiene la necessità di considerare anche il software puro come un prodotto.53

Va ricordato che la legge sulla responsabilità del prodotto limita la responsabilità per i danni alla proprietà agli oggetti usati privatamente, per cui nel caso di sistemi basati sull’IA usati per scopi commerciali, solo la morte o le lesioni a una persona sono coperte dalla legge sulla responsabilità del prodotto.54 Tuttavia, questi aspetti sono solitamente regolati nel contratto tra il fornitore e l’utente.

C. Responsabilità contrattuale

Come già accennato, nella maggior parte dei casi un sistema di IA viene utilizzato anche per adempiere a obblighi contrattuali o è addirittura oggetto di un contratto. Le manifestazioni di tale contratto sono molto diverse e ognuna di esse può sollevare problemi particolari nell’uso di un’IA.

In questa sede esamineremo solo una particolare manifestazione dell’uso dell’IA nell’adempimento di un obbligo contrattuale, che ritengo sia un buon esempio delle problematiche di responsabilità connesse all’uso dell’IA nell’adempimento di un contratto, a causa della sua attualità e della natura delle questioni che solleva.

Supponiamo concretamente che un medico specialista faccia una diagnosi sbagliata perché si è affidato alle raccomandazioni di un software di IA in un caso incerto. In questo caso, il medico è contrattualmente responsabile nei confronti del paziente. Il contratto tra paziente e medico è un mandato, quindi la corretta esecuzione del contratto richiede l’applicazione del dovere di diligenza dovuto.55

1. come fornitore di servizi che utilizza l’IA

La prima domanda che ci si può porre è se l’uso di software di IA nell’adempimento del mandato violi il dovere di diligenza richiesto. È ormai ampiamente riconosciuto che l’IA offre grandi opportunità anche in campo medico e gli ospedali utilizzano sempre più spesso questa tecnologia, sia per la diagnosi che per la determinazione della terapia migliore.56 Deontologicamente, un medico è obbligato a chiedere un altro parere se ritiene di aver raggiunto i “limiti delle sue capacità” e che il benessere del paziente lo richieda.57 I sistemi diagnostici basati sull’IA sono ora spesso considerati come secondi pareri pratici, per cui il loro utilizzo – a condizione che il sistema sia stato progettato con cura e che l’utente sia consapevole dei suoi limiti – almeno non viola il dovere di diligenza.

La domanda diametrale se l’uso di tale strumento sia necessario è più difficile da rispondere e può cambiare rapidamente a causa della velocità dei progressi in questo campo. Il grado di attenzione richiesto dipende in particolare dalle circostanze, come la natura del trattamento, i rischi connessi, il grado di discrezionalità, le risorse e il tempo a disposizione del medico in ciascun caso, nonché dalla formazione e dalle competenze del medico. A causa dell’obbligo di formazione dei medici58 , della crescente necessità di supporto nell’analisi dei dati dei pazienti e del grande interesse per le tecnologie di IA, ritengo che andremo sempre più nella direzione di richiedere che le applicazioni più efficienti ed efficaci facciano parte della dotazione di base degli specialisti. Sarà quindi ragionevole supporre che in queste situazioni il medico debba disporre di uno strumento abilitato all’IA accuratamente selezionato che, se non utilizzato, potrebbe essere indice di una violazione del dovere di assistenza. A seconda dell’affidabilità del sistema, la necessità di comprovare la diagnosi sarebbe maggiore se il medico agisse contro il parere del sistema. Questo, tuttavia, solo se il parere del sistema di IA può essere considerato un parere di un esperto. Secondo la giurisprudenza, i rapporti e le opinioni degli esperti hanno valore probatorio se appaiono conclusivi, comprensibilmente motivati e privi di contraddizioni e se non vi sono indicazioni contrarie alla loro affidabilità.59 Sulla base di questo obbligo di motivazione, l’uso di un sistema basato sull’IA potrebbe aumentare i requisiti per la motivazione di una diagnosi solo nella misura in cui il sistema è in grado di spiegare il suo risultato in modo comprensibile, in quanto questa spiegazione dovrebbe essere inclusa nella motivazione della diagnosi.60 Questo spesso non avviene oggi, il che spiega anche il ritardo nell’applicazione dei sistemi diagnostici basati sull’IA. In assenza di una spiegazione da parte del sistema di IA, il medico è tenuto, a mio avviso, solo ad assicurarsi della correttezza della sua conclusione (il cosiddetto double check) per poter dimostrare una cura sufficiente.

Questa considerazione raggiunge il suo limite quando la motivazione del risultato di un sistema di IA inizia a essere incomprensibile. Ciò si riferisce alla situazione in cui il sistema di IA è in grado di spiegare la correttezza della sua conclusione in linea di principio, ma questa spiegazione è così complicata che anche un esperto medio non può comprenderla. L’utente non sarebbe più in grado di contraddire il sistema di IA o di riconoscere eventuali errori. A mio avviso, una costellazione di questo tipo è paragonabile a un dispositivo medico, il cui utilizzo richiede una procedura di approvazione. Questa procedura può richiedere misure di sicurezza aggiuntive che si discostano dall’arte medica tradizionale, ma che devono essere rispettate per evitare risultati errati da parte del sistema di IA.

Pertanto, sebbene l’uso dell’IA oggi non costituisca in genere né la prova di un’assistenza adeguata di per sé né una violazione del dovere di diligenza, occorrerebbe esaminare in ogni singolo caso se una diagnosi errata sia basata su una violazione del dovere di diligenza, il che richiede l’uso di un sistema di supporto basato sull’IA da parte del medico in singoli casi e quindi pone anche maggiori requisiti di giustificazione sulla diagnosi.

La responsabilità del fornitore di un prodotto o servizio abilitato all’IA per il risultato e gli eventuali danni è quindi una questione di interpretazione del contratto sottostante tra fornitore e utente.

2. come fornitore di IA

Se la soluzione basata sull’IA viene fornita al fornitore di servizi nell’ambito di un contratto di acquisto o di servizio, il fornitore di servizi o l’utente è il principale responsabile dei risultati dell’applicazione nei confronti dei propri partner contrattuali.

Se viene venduto solo il software, il venditore è responsabile sia dell’esistenza delle caratteristiche garantite sia di garantire che l’oggetto dell’acquisto non presenti difetti che ne compromettano l’utilizzabilità. Tuttavia, poiché, come detto, i sistemi di IA apprendono dai dati, se si acquista un sistema di IA in grado di apprendere, si diventa fondamentalmente responsabili dell’immissione dei dati e delle loro conseguenze. Sarà quindi difficile stabilire una responsabilità del fornitore di IA per il comportamento appreso, a meno che ciò non sia stato esplicitamente concordato nel contratto o che fosse prevedibile altrimenti in base allo stato dell’arte al momento dello sviluppo del sistema.

A causa di questi problemi, nonché di altre peculiarità della moderna pratica di sviluppo del software in generale, una soluzione di IA viene spesso offerta come servizio (il cosiddetto Software as a Service, o “SaaS”).61 Il fornitore di IA è quindi in grado di sviluppare continuamente la soluzione creata e di garantire l’addestramento dell’IA sulla base di una maggiore quantità di dati. La responsabilità di un eventuale difetto del sistema di IA ricade quindi sul fornitore, a meno che non sia stato concordato diversamente.

III. Conclusioni

L’attribuzione della responsabilità in caso di danno nel caso di un sistema basato sull’IA solleva diversi problemi nella determinazione dei doveri di diligenza applicabili a causa della particolare struttura di questa tecnologia. A causa della possibilità di applicazione più flessibile, che è associata a un rischio intrinseco, sono necessarie nuove misure di diligenza speciali da parte dell’utente quando utilizza una soluzione basata sull’IA, che altrimenti potrebbe essere ritenuto responsabile in base alla dottrina della teoria del rischio generale. Se l’utente ha esercitato una ragionevole diligenza, la colpa può risiedere non solo nella codifica della soluzione basata sull’IA, ma anche nella selezione e nella preparazione dei dati utilizzati per il suo addestramento. Nonostante i progressi in questo campo, è molto difficile dimostrare la colpa in questi casi.

‍

N.B. Questo articolo è stato pubblicato il 04/2021. L’articolo è stato leggermente modificato in alcuni passaggi rispetto alla versione originale per migliorarne la leggibilità.

‍

‍

1 Andrea Bertolini, Intelligenza artificiale e responsabilità civile, Bruxelles 2020, 15 ss.

2 Rapporto del gruppo di lavoro interdipartimentale sull’intelligenza artificiale al Consiglio federale, Berna 2019, 7. Questa definizione è più vicina alla proposta di legge dell’UE sull’intelligenza artificiale.

3 Melinda F. Lohmann, A Future Liability Framework for Artificial Intelligence, HAVE 2021, 111 ss.

4 Erdem Büyüksagis, Responsabilité pour les systèmes d’intelligence artificielle, HAVE 2021, 12 ss, 12; Silvio Hänsenberger, Die Haftung für Produkte mit lernfähigen Algorithmen, Jusletter 2018, para. 7 f.

5 Arun Das/Paul Rad, Opportunities and Challenges in Explainable Artificial Intelligence (XAI): A Survey, arXiv 2020, 1.

6 Un modello di intelligenza artificiale è un file addestrato a riconoscere determinati tipi di modelli, https://docs.microsoft.com/de-ch/windows/ai/windows-ml/what-is-a-machine-learning-model, visitato il 22.9.2021.

7 www.ibm.com/cloud/learn/overfitting, visitato il 22.9.2021.

8 Campolo Alexander/Crawford Kate, “Determinismo incantato: Power without Responsibility in Artificial Intelligence”, Engaging Science, Technology, and Society, gennaio 2020, 1 ss, 12 ss.

9 Campolo/Crawford (fn. 8), 12 s.

10 Una delle ultime grandi conquiste dell’IA è la capacità di prevedere la forma tridimensionale di una proteina dalla sua composizione, www.nature.com/articles/d41586-020-03348-4, visitato il 22.9.2021.

11 Das/Rad (fn. 5), 1.

12 BGE 141 III 527 E. 3.2.

13 Lohmann (fn. 3), 112.

14 Jerome Gurtner, Les nouvelles technologies et la responsabilité des avocats, in Responsabilité civile et nouvelles technologies, in: Responsabilité civile et nouvelles technologies, Genève/Zurich 2019, 45 ss, 73 ss; Jermy Prenio/Jeff ery Yong, Humans keeping AI in check – emerging regulatory expectations in the financial sector, BIS 2021, disponibile all’indirizzo www.bis.org/fsi/publ/insights35.htm, visitato il 22.9.2021.

15 Si veda II.A.2.b.

16 Queste corrispondono in particolare a un caso di interruzione del nesso di causalità per colpa di terzi o per mancanza dell’elemento soggettivo della colpa.

17 Si veda la proposta di legge dell’UE sull’intelligenza artificiale, disponibile all’indirizzo https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/ ?uri=CELEX:52021PC0206&from=EN, visitato il 22.9.2021.

18 In assenza di una norma di tutela espressa che stabilisca uno status di garante per la persona incaricata della sorveglianza, si può ricorrere alla dottrina del teorema del pericolo nel caso di beni assolutamente protetti: Hardy Landolt, Haftung für rechtmässige Schadenverursachung, HAVE 2014, pag. 3 e seguenti, pag. 6; Sentenza del Tribunale federale 4A_104/2012 del 3 agosto 2012 E. 2.1.

19 Si veda II.A.2.b.

20 Si veda, ad esempio, il lavoro delle Nazioni Unite a questo proposito: www.un.org/disarmament/ the-convention-on-certain-conventional-weapons/background-onlaws- in-the-ccw/, visitato il 22.9.2021.

21 Si veda il paragrafo II.A.2.b. in cui si discute la dottrina della teoria del rischio generale.

22 A questa conclusione giungono in particolare i principi discussi della teoria generale del rischio, della responsabilità da prodotto e della responsabilità contrattuale.

23 Il problema della realtà odierna, in cui il software viene spesso offerto come servizio e che spesso può anche rappresentare una combinazione di vari “microservizi” indipendenti, non viene affrontato in questa sede. La frammentazione delle offerte, che è una conseguenza della gradita opportunità per le persone di utilizzare i propri dati, pone una sfida nella determinazione dei fatti e delle parti coinvolte.

24 Il creatore del programma può oggi essere una complessa rete di collaboratori indipendenti. Si veda a questo proposito Christiane Wendehorst, Safety and Liability Related Aspects of Software, Luxembourg 2021, 16 ss.

25 Per quanto riguarda la discussione sulla necessità di adattare la normativa al fine di ridurre questa complessità per ragioni di giustizia ed efficienza, si veda ad esempio Lohmann (fn. 3) e Wendehorst (fn. 24).

26 Das/Rad (fn. 5), 9 ss.

27 Wendehorst (nota 24), 82.

28 Wendehorst (fn. 24), 22 ss.

29 Sebbene sia relativamente facile creare una rete neurale (il codice sorgente di GPT-2 è di 174 righe di codice, cfr. https:// github.com/openai/gpt-2/blob/master/src/model.py, visitato il 22.9.2021), le librerie sottostanti che consentono di creare facilmente reti neurali consistono in milioni di righe di codice. Tensorflow, ad esempio, conta quasi 3 milioni di linee di codice. www.openhub.net/p/tensorflow, visitato il 22.9.2021.

30 Das/Rad (fn. 5), 1 f.

31 Cfr. Lohmann (fn. 3), 17.

32 Landolt (fn. 18), 5; BGE 124 III 297 E. 5b: “La teoria generale del rischio è […] da applicare quando si deve valutare il nesso causale o la causa illecita tra un’omissione e il danno che si è verificato”.

33 DTF 134 IV 193 E. 7.2 f.

34 Landolt (Fn.18), 5.

35 LANDOLT (Fn. 18), S. 11.

36 Idem.

37 Sentenza del Tribunale federale 6B_1341/2015 del 25.02.2016 E. 4.3.3.

38 L’analisi dei rischi a cui si fa riferimento è una manifestazione del dovere oggettivo di diligenza, che richiede una ponderazione delle conseguenze delle proprie azioni adeguata alle circostanze (cfr. Sentenza del Tribunale federale 6B_1341/2015 del 25.02.2016 E. 4.3.1.).

39 Idem.

40 Sentenza della Corte Suprema Federale 6B_1341/2015 del 25.02.2016 E. 4.3.3.

41 Lohmann (fn. 3), 117.

42 Ad esempio ISO/IEC/IEEE 12207:2017 “Systems and software engineering – Software life cycle processes”.

43 Si veda a questo proposito Nativi Stefano, AI Watch: AI Standardisation Landscape, Lussemburgo, 2021, 20 ss.

44 Si veda Gianni Fröhlich-Bleuer, Softwareverträge, Berna 2014, par. 2256.

45 BGE 105 II 284 E. 1.

46 Cfr. Wendehorst (fn. 24), 35 ss.

47 Wendehorst (fn. 24), 82 s. Ad esempio, se una singola decisione sbagliata rientra nel margine di errore dell’1% o se è attribuibile ad altro.

48 Per una panoramica tecnica sullo stato attuale: Das/Rad (fn. 5).

49 Sentenza del Tribunale federale 4A_606/2017 del 30 aprile 2018 E. 3.1.1.

50 Art. 8 PrHG.

51 Art. 1 PrHG.

52 Wendehorst (fn. 24), 65; Lohmann (fn. 3), 115.

53 Lohmann (fn. 3), 115; Fröhlich-Bleuer (fn. 43), par. 2251 e seguenti; Wendehorst (fn. 24), 65 e seguenti.

54 Art. 1 PrHG.

55 Sentenza della Corte Suprema Federale 4A_432/2020 del 16 dicembre 2020 E. 6.2.

56 “Un settore importante è quello della diagnostica per immagini, vale a dire le radiografie, le TAC o le risonanze magnetiche. In questo caso si tratta spesso di vedere l'”ago nel pagliaio” in molte immagini sezionali di un organo. Oggi i software possono essere addestrati a valutare tali immagini al pari di radiologi esperti e a riconoscere eventuali aree problematiche. Inoltre, l’IA può essere utilizzata per le malattie croniche, ossia quelle che non possono essere curate, ma per le quali è possibile evitare un rapido aggravamento con la giusta terapia”, www.caim.unibe.ch/unibe/portal/fak_medizin/dept_ zentren/inst_caim/content/e998130/e998135/e1025836/e1097065/ Gluckspost_KIundArztalsPower-Duo_RaphaelSznitman_Juni2021_ eng.pdf, visitato il 22.9.2021.

57 Art. 10 Codice etico della FMH.

58 Art. 40 MedBG e Art. 9 Ordinanza sulla formazione continua.

59 Sentenza del Tribunale federale 8C_608/2015 del 17 dicembre 2015 E. 3.3.3.

60 Sentenza del Tribunale federale 9C_195/2015 del 24 novembre 2015 E. 3.3.1.

61 Wendehorst (fn. 24), 81.