Quando si applica la supervisione umana e cosa fare dopo

Il controllo umano ai sensi della legge sull’intelligenza artificiale dell’UE si applica come requisito legale specifico ai sistemi di IA ad alto rischio. Non è soddisfatto semplicemente perché un dipendente può vedere un risultato o perché una politica afferma che una persona rimane responsabile. I fornitori devono progettare sistemi ad alto rischio in modo che le persone fisiche possano supervisionarli in modo efficace, mentre gli operatori devono assegnare la supervisione a persone con la competenza, la formazione, l’autorità e il supporto necessari.

Per un team SaaS, la sequenza pratica è: classificare il sistema, identificare se l'azienda agisce come fornitore o distributore, definire ciò che l'essere umano può effettivamente comprendere e modificare, testare il percorso di intervento e conservare le prove. Se il sistema non è ad alto rischio, la revisione umana può comunque rappresentare un prodotto appropriato, sicurezza, privacy o controllo contrattuale, ma questo è diverso dal sostenere che si applica l’articolo 14.

Perché il controllo umano è importante nella pratica

L’AI Act considera la supervisione come un modo per prevenire o minimizzare i rischi per la salute, la sicurezza e i diritti fondamentali che permangono anche dopo l’applicazione di altri controlli. L'articolo 14 afferma che le misure devono essere proporzionate ai rischi, all'autonomia e al contesto di utilizzo del sistema. Si prevede inoltre che la persona assegnata sia in grado, ove appropriato, di comprendere le limitazioni, monitorare il funzionamento, riconoscere i bias di automazione, interpretare gli output, ignorare o invertire un output e arrestare il sistema in modo sicuro.

Ciò rende la supervisione una capacità operativa, non un’approvazione cerimoniale. Un revisore che non dispone di tempo, informazioni di sistema, accesso o autorità non può fornire una supervisione significativa. Né una persona può intervenire in modo efficace se il prodotto presenta una raccomandazione come definitiva, nasconde incertezze o non offre alcuna possibilità di sostituzione utilizzabile.

Ciò è strettamente connesso alle aspettative di governance dell'intelligenza artificiale per i fornitori SaaS. Gli acquirenti si chiedono sempre più spesso non solo se un essere umano sia “nel giro”, ma anche dove si verifica l’intervento e quali prove dimostrano che funziona.

Quando si applica il requisito della legge sull'AI

Inizia con la classificazione, non con una lista di controllo di supervisione. Ai sensi dell’articolo 6, un sistema può essere ad alto rischio attraverso due percorsi principali:

1. È un prodotto, o un componente di sicurezza di un prodotto, disciplinato dalla normativa UE specifica sulla sicurezza dei prodotti e soggetto a valutazione della conformità da parte di terzi.
2. Lo scopo previsto rientra in un caso d'uso ad alto rischio di cui all'allegato III, soggetto al filtro dell'articolo 6, paragrafo 3 e alle relative eccezioni.

L’allegato III copre gli usi definiti in settori quali la biometria, le infrastrutture critiche, l’istruzione, l’occupazione, l’accesso ai servizi essenziali, l’applicazione della legge, la migrazione e l’amministrazione della giustizia. Essere “alimentato dall’intelligenza artificiale”, elaborare dati personali o influenzare un normale flusso di lavoro aziendale non rende automaticamente un sistema ad alto rischio ai sensi dell’articolo 6.

Per alcuni sistemi dell’allegato III, l’articolo 6, paragrafo 3, fornisce una possibile via per uscire dalla classificazione ad alto rischio laddove il sistema non presenta un rischio significativo di danno e soddisfa le condizioni elencate, ad esempio laddove svolge un compito procedurale o preparatorio ristretto. La profilazione delle persone fisiche nell’ambito di un caso d’uso di cui all’allegato III rimane ad alto rischio. Un fornitore che fa affidamento sul filtro deve documentare tale valutazione.

La classificazione dipende fortemente dallo scopo previsto e dal ruolo effettivo. Una società SaaS può essere il fornitore quando sviluppa un sistema, o ne fa sviluppare uno, e lo commercializza o lo mette in servizio con il proprio nome. Potrebbe essere un distributore quando utilizza il sistema AI di un altro fornitore sotto la sua autorità. Un'azienda può anche creare obblighi nei confronti dei fornitori modificando sostanzialmente un sistema ad alto rischio o modificandone lo scopo previsto in modo da renderlo ad alto rischio. Le squadre dovrebbero confermare le attuali regole transitorie prima di considerare un obbligo futuro come già applicabile.

Leggi la panoramica pratica dell'EU AI Act per i fornitori SaaS insieme alla valutazione della classificazione.

Quando non si applica l'articolo 14

L'articolo 14 non è una regola universale per ogni chatbot, riassuntivo, funzione di raccomandazione, segnalazione di frode o copilota interno. Se un sistema non rientra nell’ambito di applicazione della legge sull’AI, non è un sistema di IA ai sensi della legge o non è classificato come ad alto rischio, il requisito del sistema ad alto rischio dell’articolo 14 non si applica ad esso.

Ciò non significa che “non è necessaria alcuna revisione umana”. Altri obblighi possono sorgere in base alle norme sulla protezione dei dati, sui consumatori, sull'occupazione, specifiche del settore, sulla sicurezza o contrattuali. Una valutazione del rischio può anche dimostrare che l’approvazione umana è il controllo più proporzionato anche senza un mandato legale specifico.

Utilizza un linguaggio preciso nei record e nelle risposte dei clienti:

• Requisito legale: "Il sistema è ad alto rischio e queste misure attuano gli articoli 14 e 26."
• Controllo del rischio: "Il sistema non è attualmente classificato come ad alto rischio, ma la nostra politica interna sul rischio richiede la revisione umana."
• Domanda aperta: "La classificazione dipende dallo scopo finale previsto e dal contesto di distribuzione; il lancio è bloccato fino all'approvazione della valutazione."

Questa distinzione impedisce ai team di sopravvalutare la conformità e semplifica la gestione delle modifiche successive.

Responsabilità del fornitore e dell'operatore

Fornitori e distributori hanno un lavoro connesso ma diverso.

Fornitori: supervisione della progettazione nel sistema

Un fornitore dovrebbe tradurre la valutazione del rischio in misure tecniche e procedurali utilizzabili. A seconda del caso d'uso, ciò può includere:

• mostrare confidenza, limitazioni e contesto di input rilevanti;
• rendere visibili anomalie e performance impreviste;
• impedire che l'interfaccia incoraggi l'accettazione cieca;
• consentire alle persone autorizzate di ignorare, ignorare, invertire o interrompere le uscite;
• definire quali misure di controllo l'operatore deve attuare; e
• spiegare chiaramente tali misure nelle istruzioni per l'uso.

Il progetto dovrebbe corrispondere alle condizioni di lavoro prevedibili. Una sostituzione nascosta dietro il flusso di lavoro di un amministratore può essere inutile quando un revisore in prima linea deve agire immediatamente.

Detergenti: rendere operativa la supervisione

L’articolo 26 impone agli operatori di sistemi ad alto rischio di affidare la supervisione a persone fisiche dotate della competenza, della formazione, dell’autorità e del supporto necessari. Gli operatori devono utilizzare il sistema secondo le sue istruzioni, monitorarne il funzionamento, agire sui rischi identificati o sugli incidenti gravi e mantenere i registri generati automaticamente sotto il loro controllo per un periodo adeguato di almeno sei mesi, a meno che altre leggi applicabili non dispongano diversamente.

Dal punto di vista operativo, ciò significa scegliere ruoli con nome, proteggere i tempi di revisione, controllare l'accesso, definire l'escalation e verificare se le istruzioni del fornitore si adattano alla distribuzione reale. Un dipendente non può essere ritenuto responsabile di un intervento che non è autorizzato a effettuare.

Un flusso di lavoro pratico per la supervisione umana

1. Scrivere un record di classificazione con ambito

Registrare il sistema, lo scopo previsto, gli utenti, le persone interessate, gli input, gli output, l'impatto delle decisioni, i ruoli del fornitore/distributore e il percorso previsto dall'Articolo 6 considerato. Collegare la conclusione alla versione del prodotto e al contesto di distribuzione. Rivalutarlo quando uno dei due cambia.

2. Mappare le decisioni e le modalità di fallimento

Identificare dove i risultati dell’intelligenza artificiale possono influenzare una persona, la sicurezza, l’accesso, la definizione delle priorità o un processo regolamentato. Per ogni punto, descrivi errori realistici: una falsa corrispondenza, un'eccezione mancata, una classifica distorta, un riepilogo fuorviante, una raccomandazione non sicura o una deriva delle prestazioni.

3. Definisci l'azione dell'essere umano, non solo la sua presenza

Per ogni decisione materiale, specificare:

• quali informazioni vede il revisore;
• cosa devono verificare in autonomia;
• quando devono rifiutare o intensificare;
• se possono mettere in pausa, sovrascrivere o invertire il risultato;
• quanto velocemente devono agire; e
• chi ha l'autorità finale.

Evita controlli vaghi come "un manager esamina quando necessario". Un trigger e una regola decisionale rendono il controllo testabile.

4. Formarsi per il compito vero e proprio

La formazione dovrebbe coprire lo scopo previsto del sistema, le limitazioni note, i segnali rilevanti, i pregiudizi legati all'automazione, gli usi vietati, gli strumenti di intervento, la tenuta dei registri e l'escalation. Confermare la competenza attraverso scenari, non solo presenze. Ciò integra le domande più ampie che i team dovrebbero porre prima di adottare nuovi strumenti di intelligenza artificiale internamente.

5. Testare il percorso completo

Esegui esercizi realistici. Il revisore è in grado di individuare un output non valido? Hanno abbastanza contesto? L'override funziona? L'arresto del sistema lo lascia in uno stato sicuro? L'evento viene registrato? L’escalation raggiunge qualcuno che può agire?

Registrare i difetti e ripetere il test dopo le correzioni. Uno screenshot di una schermata di approvazione dimostra molto meno di uno scenario completato con risultati attesi e osservati.

6. Monitorare e migliorare

Tieni traccia di sostituzioni, storni, escalation, reclami, rilevamenti mancati, disaccordo dei revisori e prestazioni anomale. Le tendenze possono rivelare una formazione debole, un'interfaccia inutilizzabile, input modificati o un sistema che funziona al di fuori dello scopo approvato. Definire le soglie che attivano l'indagine, la sospensione o la rivalutazione.

Errori comuni

• Classificazione in base all'etichetta del prodotto. Il nome di una caratteristica non determina se l'uso previsto è ad alto rischio.
• Utilizzo di “human in the loop” come controllo completo. La presenza senza informazioni, tempo o autorità non è una supervisione efficace.
• La revisione dopo la conseguenza è irreversibile. Il punto di intervento deve verificarsi mentre la persona può ancora modificare il risultato.
• Lasciare che lo stesso output si convalidi da solo. La verifica indipendente richiede prove aggiuntive, non una seconda lettura della spiegazione dell'IA.
• Ignorare i bias di automazione. Risultati ripetutamente accurati possono rendere i revisori meno propensi a contestare l'errore eccezionale.
• Lasciare la proprietà all'"azienda". Indicare un ruolo responsabile e un backup operativo.
• Non conservare prove. Le policy da sole non dimostrano che i revisori siano stati formati, che le modifiche abbiano funzionato o che i problemi siano stati inoltrati.

Esempio: screening dei candidati assistito dall'intelligenza artificiale

Supponiamo che un fornitore SaaS offra un software che classifica i candidati al lavoro per un datore di lavoro. Gli usi dell’IA legati all’occupazione elencati nell’allegato III possono essere ad alto rischio, quindi il fornitore dovrebbe completare e documentare la valutazione dell’articolo 6 piuttosto che presumere che un reclutatore che fa clic su “approva” risolva il problema.

Una supervisione significativa potrebbe richiedere al reclutatore di vedere i fattori rilevanti per la raccomandazione, controllare le informazioni sulla fonte, identificare dati mancanti o fuorvianti, ignorare la classifica, ripristinare un candidato e intensificare i sospetti pregiudizi sistematici. Il datore di lavoro, in qualità di operatore, assegnerebbe persone addestrate con autorità e monitorerebbe il sistema in linea con le istruzioni.

Al contrario, uno strumento interno che riformatta un’e-mail scritta da un reclutatore senza classificare i candidati o influenzare una decisione di assunzione potrebbe non rientrare in quel caso d’uso ad alto rischio. Il team può comunque vietare input sensibili e richiedere l’approvazione umana prima dell’invio, ma dovrebbe documentarlo come controllo interno anziché descriverlo automaticamente come conformità all’Articolo 14.

Domande frequenti

Qual è lo scopo pratico della supervisione umana?

Il suo scopo è consentire alle persone competenti di comprendere, monitorare e intervenire in modo da prevenire o ridurre i rischi residui per la salute, la sicurezza o i diritti fondamentali. Il flusso di lavoro deve fornire loro informazioni, tempo, strumenti e autorità reali.

Quando si applica la supervisione umana ai team SaaS?

I compiti specifici della legge sull’intelligenza artificiale si applicano quando il team fornisce o implementa un sistema di intelligenza artificiale ad alto rischio. Altri sistemi di intelligenza artificiale potrebbero ancora necessitare di revisione umana a causa di un’altra legge, contratto, valutazione del rischio o politica interna.

È sufficiente l'approvazione umana finale?

Non automaticamente. L'approvazione ha significato solo se il revisore è in grado di comprendere le limitazioni rilevanti, rilevare problemi, contestare l'output e modificare o interrompere il risultato prima che si verifichi un danno.

Cosa dovrebbero documentare prima i team?

Inizia con il record di classificazione e lo scopo previsto. Quindi documentare le persone responsabili, rivedere i fattori scatenanti, le informazioni mostrate, gli interventi consentiti, il percorso di escalation, la formazione, i risultati dei test e le prove operative.

Ogni decisione dell'IA deve essere controllata da due persone?

No. L’articolo 14 prevede una norma specifica sulla verifica da parte di due persone per determinati sistemi di identificazione biometrica a distanza, con eccezioni definite. Non è una regola generale per tutti i sistemi di intelligenza artificiale ad alto rischio.

Cosa fare adesso

Classificare il caso d’uso prima di promettere che la “supervisione umana” lo risolverà. Se il sistema è ad alto rischio, collegare le misure tecniche del fornitore alle persone reali, alle autorizzazioni e alle procedure dell'operatore. Quindi testa il percorso e conserva le prove che un essere umano può riconoscere i problemi e agire in tempo.

Questa è la differenza tra una persona vicina al sistema e un’efficace supervisione umana.

Fonti

• Regolamento (UE) 2024/1689 (Legge sull'intelligenza artificiale)
• Articolo 6: regole di classificazione per i sistemi di IA ad alto rischio
• Articolo 14: controllo umano
• Articolo 26: Obblighi degli operatori di sistemi di IA ad alto rischio