Skip to main content

Articolo 14 per l’IA fintech: sorveglianza umana

Come si applica l’articolo 14 (sorveglianza umana) all’IA per lo scoring creditizio e le assicurazioni: sorveglianza fin dalla progettazione, il ruolo del deployer, ciò che il regolamento non richiede, le date, le sanzioni e ciò che lascia aperto.

I fornitori di sistemi di IA per scoring creditizio e assicurazioni sulla vita o sanitarie devono progettarli in modo che persone fisiche possano supervisionarli efficacemente (articolo 14).

Sono usi ad alto rischio ai sensi dell’allegato III, punto 5, lettera b), e punto 5, lettera c). I sistemi per individuare frodi finanziarie sono esclusi dal punto 5, lettera b). L’obbligo si applica dal 2 dicembre 2027, salvo che valga l’eccezione dell’articolo 6, paragrafo 3. I deployer affidano la sorveglianza a persone competenti (articolo 26, paragrafo 2). Le sanzioni possono arrivare fino a 15 milioni di EUR o, per un’impresa, fino al 3 % del fatturato mondiale annuo, se superiore (articolo 99, paragrafo 4). Passo successivo: definisca che cosa chi esercita la sorveglianza può vedere, modificare e fermare.

L’articolo 14 richiede che le persone possano supervisionare efficacemente il sistema

L’articolo 14 stabilisce obblighi di progettazione per il fornitore. Non contiene alcuna regola per cui una persona debba riesaminare ogni singola decisione.

  • art. 14(1)
    Supervisione efficace da parte di persone fisiche

    I sistemi di IA ad alto rischio sono progettati e sviluppati, anche con strumenti di interfaccia uomo-macchina adeguati, in modo tale da poter essere efficacemente supervisionati da persone fisiche durante il periodo in cui sono in uso.

  • art. 14(2)
    Obiettivo: prevenire o ridurre al minimo i rischi

    La sorveglianza umana mira a prevenire o ridurre al minimo i rischi per la salute, la sicurezza o i diritti fondamentali che possono emergere quando il sistema è utilizzato conformemente alla sua finalità prevista o in condizioni di uso improprio ragionevolmente prevedibile. Ciò vale in particolare qualora tali rischi persistano nonostante l’applicazione degli altri requisiti.

  • art. 14(3)
    Misure commisurate a rischi, autonomia e contesto

    Le misure di sorveglianza sono commisurate ai rischi, al livello di autonomia e al contesto di utilizzo. Sono garantite da misure che il fornitore integra nel sistema, ove tecnicamente possibile, da misure che il fornitore individua come adatte a essere attuate dal deployer, oppure da entrambe.

  • art. 14(4)(a)–(c)
    Comprendere, monitorare e interpretare

    Il sistema è fornito in modo che le persone incaricate della sorveglianza abbiano la possibilità, ove opportuno e proporzionato, di comprenderne le capacità e i limiti e di monitorarne il funzionamento. Ciò include l’individuazione e la gestione di anomalie, disfunzioni e prestazioni inattese. Devono anche poter restare consapevoli della possibile tendenza a fare automaticamente affidamento o a fare eccessivo affidamento sull’output («distorsione dell’automazione»), in particolare per i sistemi che forniscono informazioni o raccomandazioni per decisioni che devono essere prese da persone fisiche. E devono poter interpretare correttamente l’output.

  • art. 14(4)(d), (e)
    Decidere di non usare, ignorare, annullare o fermare

    Le persone incaricate della sorveglianza devono poter decidere, in qualsiasi situazione particolare, di non usare il sistema oppure di ignorare, annullare o ribaltare il suo output. Devono anche poter intervenire sul suo funzionamento o interromperlo mediante un pulsante di «arresto» o una procedura analoga. Tale procedura deve consentire al sistema di arrestarsi in condizioni di sicurezza.

Quale IA fintech deve rispettare l’articolo 14

L’articolo 14 si applica solo ai sistemi di IA ad alto rischio. Le righe seguenti mostrano quando l’IA fintech diventa ad alto rischio.

  • Fintech non è una categoria del regolamento

    Il regolamento non ha una categoria fintech. Questo sito usa la parola per l’IA che rientra nel regolamento attraverso due usi dell’allegato III, punto 5. Il punto 5, lettera b), riguarda i sistemi di IA destinati a essere utilizzati per valutare l’affidabilità creditizia delle persone fisiche o per stabilire il loro merito di credito. Fa eccezione per i sistemi di IA utilizzati allo scopo di individuare frodi finanziarie. Il punto 5, lettera c), riguarda i sistemi di IA destinati a essere utilizzati per la valutazione dei rischi e la determinazione dei prezzi in relazione a persone fisiche nel caso di assicurazioni sulla vita e assicurazioni sanitarie. Il punto 5 non nomina il rilevamento delle frodi, i controlli antiriciclaggio o di conoscenza del cliente (KYC), il trading algoritmico, la consulenza automatizzata (robo-advice), le assicurazioni non vita, la gestione dei sinistri né le decisioni di credito riguardanti persone giuridiche. Un sistema per uno di questi usi è ad alto rischio solo se lo contempla un altro punto dell’allegato III oppure l’allegato I.

  • L’articolo 6, paragrafo 3, può escludere un sistema dall’allegato III

    Un sistema rientrante nel punto 5, lettera b), o nel punto 5, lettera c), è ad alto rischio ai sensi dell’articolo 6, paragrafo 2. Ai sensi dell’articolo 6, paragrafo 3 non è ad alto rischio se non presenta un rischio significativo di danno per la salute, la sicurezza o i diritti fondamentali, anche nel senso di non influenzare materialmente il risultato del processo decisionale. Il regolamento applica questa deroga quando è soddisfatta almeno una delle condizioni seguenti (articolo 6, paragrafo 3, lettere da a) a d)). Il sistema è destinato a eseguire un compito procedurale limitato. Oppure è destinato a migliorare il risultato di un’attività umana precedentemente completata. Oppure è destinato a rilevare schemi decisionali o deviazioni da schemi decisionali precedenti e non è finalizzato a sostituire o influenzare la valutazione umana precedentemente completata senza un’adeguata revisione umana. Oppure è destinato a eseguire un compito preparatorio per una valutazione pertinente ai fini dei casi d’uso elencati nell’allegato III. Come queste condizioni si combinino con la verifica del rischio significativo è una questione per un giurista. Il sistema è sempre ad alto rischio se effettua profilazione di persone fisiche. La profilazione è definita dall’articolo 4, punto 4, del GDPR (articolo 3, punto 52). Stabilire se un dato sistema di scoring o di determinazione dei prezzi la effettui è anch’essa una questione per un giurista. Il fornitore che si avvale dell’eccezione documenta la propria valutazione prima che il sistema sia immesso sul mercato o messo in servizio. Deve inoltre registrare il sistema (articolo 6, paragrafo 4, articolo 49, paragrafo 2).

  • Fornitore e deployer

    Il fornitore sviluppa un sistema di IA, o lo fa sviluppare, e lo immette sul mercato o lo mette in servizio con il proprio nome o marchio (articolo 3, punto 3). La messa in servizio comprende la fornitura per uso proprio del fornitore (articolo 3, punto 11). Una banca o un’impresa di assicurazione che sviluppa un sistema e lo mette in servizio con il proprio nome è quindi un fornitore. Una banca o un’impresa di assicurazione che usa un sistema sotto la propria autorità è un deployer (articolo 3, punto 4). Un deployer diventa fornitore in tre casi. Appone il proprio nome o marchio su un sistema ad alto rischio già immesso sul mercato, fatti salvi accordi contrattuali che prevedano una diversa ripartizione degli obblighi. Apporta una modifica sostanziale a tale sistema, che lo lascia ad alto rischio. Oppure modifica la finalità prevista di un sistema non ad alto rischio in modo che lo diventi (articolo 25, paragrafo 1). Il fornitore che aveva inizialmente immesso il sistema sul mercato o lo aveva messo in servizio non è più considerato fornitore di quel determinato sistema e deve cooperare strettamente con il nuovo fornitore (articolo 25, paragrafo 2). Ciò non vale se il fornitore iniziale ha chiaramente specificato che il suo sistema non deve essere trasformato in un sistema di IA ad alto rischio.

  • Il deployer affida la sorveglianza a persone competenti

    I deployer affidano la sorveglianza umana a persone fisiche che dispongono della competenza, della formazione e dell’autorità necessarie nonché del sostegno necessario (articolo 26, paragrafo 2). Gli obblighi dei paragrafi 1 e 2 lasciano impregiudicati gli altri obblighi dei deployer previsti dal diritto dell’Unione o nazionale e la libertà del deployer di organizzare le proprie risorse e attività al fine di attuare le misure di sorveglianza umana indicate dal fornitore (articolo 26, paragrafo 3).

  • Date

    I requisiti per questi usi dell’allegato III si applicano dal 2 dicembre 2027 (articolo 113, terzo comma, lettera c), punto i)). Un sistema immesso sul mercato o messo in servizio prima di tale data è coperto solo se in seguito subisce modifiche significative della progettazione. In ogni caso, i fornitori e i deployer di sistemi di IA ad alto rischio destinati a essere utilizzati da autorità pubbliche devono adottare le misure necessarie per conformarsi entro il 2 agosto 2030 (articolo 111, paragrafo 2).

  • Sanzioni

    I fornitori devono garantire che i loro sistemi ad alto rischio rispettino i requisiti della sezione 2 del capo III, che comprende gli articoli da 9 a 15 (articolo 16, lettera a)). La violazione degli obblighi dei fornitori di cui all’articolo 16 o degli obblighi dei deployer di cui all’articolo 26 può essere punita con sanzioni amministrative pecuniarie. La sanzione arriva fino a 15 milioni di EUR o, per un’impresa, fino al 3 % del fatturato mondiale totale annuo dell’esercizio precedente, se superiore (articolo 99, paragrafo 4, lettere a) ed e)). Per le PMI, comprese le start-up, ogni sanzione arriva al massimo all’importo più basso tra i due (articolo 99, paragrafo 6). Lo stesso vale per le piccole imprese a media capitalizzazione (articolo 3, punto 14 ter, articolo 99, paragrafo 6 bis). Ciascuno Stato membro stabilisce norme che dispongano in quale misura possono essere inflitte sanzioni amministrative pecuniarie ad autorità pubbliche e organismi pubblici istituiti in tale Stato membro (articolo 99, paragrafo 8).

  • Portata e limiti del regolamento

    Il regolamento si applica ai fornitori e ai deployer che hanno il loro luogo di stabilimento o sono situati in un paese terzo, laddove l’output prodotto dal sistema di IA sia utilizzato nell’Unione (articolo 2, paragrafo 1, lettera c)). Non si applica a settori che non rientrano nell’ambito di applicazione del diritto dell’Unione e non pregiudica le competenze degli Stati membri in materia di sicurezza nazionale (articolo 2, paragrafo 3). Il regolamento non si applica ai sistemi o modelli di IA, ivi compresi i loro output, specificamente sviluppati e messi in servizio al solo scopo di ricerca e sviluppo scientifici (articolo 2, paragrafo 6). Non si applica alle attività di ricerca, prova o sviluppo relative a un sistema prima della sua immissione sul mercato o messa in servizio. La prova in condizioni reali non rientra in tale esclusione (articolo 2, paragrafo 8). I sistemi di IA rilasciati con licenza libera e open source sono esclusi dal regolamento. Tale esclusione non vale se sono immessi sul mercato o messi in servizio come sistemi di IA ad alto rischio, o se rientrano nell’articolo 5 o 50 (articolo 2, paragrafo 12).

Che cosa il regolamento lascia aperto per il fintech

  • Nessuna regola sul riesame umano dei rifiuti

    Il regolamento non contiene alcuna regola per cui una persona debba riesaminare ogni decisione di credito o assicurativa o ogni rifiuto. L’articolo 14 richiede che il sistema possa essere supervisionato efficacemente, mediante misure ai sensi dell’articolo 14, paragrafo 3. Altro diritto dell’Unione, come il GDPR, può aggiungere regole sulle decisioni automatizzate; vanno verificate separatamente. Il regolamento stesso non nomina alcuna norma armonizzata. I sistemi ad alto rischio conformi alle norme armonizzate pubblicate nella Gazzetta ufficiale dell’Unione europea si presumono conformi ai requisiti della sezione 2, nella misura in cui tali norme li contemplano (articolo 40, paragrafo 1). La Commissione elabora orientamenti sull’applicazione pratica dei requisiti e degli obblighi di cui agli articoli da 8 a 15, 25 e 26 (articolo 96, paragrafo 1, lettera a)).

  • Esempio: mostrare a chi sorveglia i fattori principali

    Esempio, non un requisito del regolamento: il fornitore di un sistema di scoring creditizio potrebbe mostrare a chi esercita la sorveglianza i fattori principali di un punteggio. Potrebbe anche prevedere un modo per inviare un caso a una valutazione manuale.

  • Esempio: vigilare sull’eccessivo affidamento

    Esempio, non un requisito del regolamento: un deployer potrebbe monitorare con quale frequenza il personale modifica la raccomandazione del sistema, per vedere se vi fa affidamento in modo automatico (distorsione dell’automazione, articolo 14, paragrafo 4, lettera b)).

Domande sull’articolo 14 nel fintech

Una persona deve riesaminare ogni rifiuto di prestito deciso con l’IA?

Il regolamento non contiene una regola simile. L’articolo 14 richiede che il fornitore progetti il sistema in modo che persone fisiche possano supervisionarlo efficacemente, e l’articolo 26, paragrafo 2, richiede che il deployer affidi la sorveglianza a persone competenti. Altro diritto dell’Unione, come il GDPR, può aggiungere obblighi sulle decisioni automatizzate.

L’articolo 14 richiede un pulsante di arresto per un sistema di scoring creditizio?

Richiede che le persone incaricate della sorveglianza possano intervenire sul funzionamento del sistema o interromperlo mediante un pulsante di «arresto» o una procedura analoga. La procedura deve consentire al sistema di arrestarsi in condizioni di sicurezza (articolo 14, paragrafo 4, lettera e)).

La regola della verifica da parte di due persone si applica al fintech?

No. L’articolo 14, paragrafo 5, si applica solo ai sistemi ad alto rischio di cui all’allegato III, punto 1, lettera a).

Scanara prepara evidenze dai vostri repository

Scanara legge i vostri repository GitHub collegati ed esegue scansioni basate su regole per individuare pattern comuni di IA e machine learning. Può non rilevare il codice non standard. Separatamente genera bozze di documentazione a partire da modelli e dalle vostre risposte alle valutazioni, come evidenze per il vostro lavoro di conformità. La classificazione la decidete voi.