Articolo 14 del regolamento europeo sull'IA: gli obblighi di sorveglianza umana spiegati

Aggiornato il 2 ottobre 2026 — correzione. Le versioni precedenti indicavano gli obblighi dei deployer come articolo 29 (sono l'articolo 26) e il diritto alla spiegazione come articolo 72 (è l'articolo 86), presentavano human-in-the-loop, on-the-loop e in-command come tipi nominati dall'articolo 14 (provengono dagli Orientamenti etici del 2019 del gruppo di esperti ad alto livello) e affermavano che i sistemi già impiegati devono conformarsi entro il 2 dicembre 2027, cosa che l'articolo 111, paragrafo 2, non dice.

Aggiornato il 4 agosto 2026 — termine modificato. Il Digital Omnibus (adottato dal Parlamento europeo il 16 giugno 2026 e dal Consiglio il 29 giugno 2026) ha rinviato gli obblighi relativi ai sistemi ad alto rischio dell'allegato III dal 2 agosto 2026 al 2 dicembre 2027. Gli obblighi di trasparenza dell'articolo 50 non sono stati rinviati e si applicano dal 2 agosto 2026. Il presente articolo è stato corretto di conseguenza.

Se il suo sistema di IA è classificato come ad alto rischio ai sensi del regolamento europeo sull'IA, l'articolo 14 le impone di progettarlo in modo che gli esseri umani possano sorvegliarne efficacemente il funzionamento. Non è un adempimento formale: è un requisito architetturale fondamentale che incide sul modo in cui costruisce, distribuisce e monitora il suo sistema.

L'articolo 14 impone che i sistemi di IA ad alto rischio siano progettati per consentire la sorveglianza umana mediante misure adeguate. Tali misure devono consentire agli esseri umani di comprendere gli output del sistema, di interpretarne i risultati e di intervenire quando necessario. Questi obblighi si applicano dal 2 dicembre 2027 per i sistemi dell'allegato III, con un massimo previsto dalla legge di 15 milioni di euro o del 3% del fatturato annuo mondiale ai sensi dell'art. 99, paragrafo 4, e, per le PMI, l'importo inferiore tra i due.

Questa guida spiega che cosa richiede l'articolo 14, quali misure di sorveglianza soddisfano il regolamento e come attuare una sorveglianza umana che funzioni nella pratica.

Che cosa richiede l'articolo 14

L'articolo 14 si applica ai fornitori di sistemi di IA ad alto rischio (quelli classificati ad alto rischio ai sensi dell'articolo 6, tramite l'allegato I o l'allegato III). Richiede che i sistemi siano progettati e sviluppati in modo da poter essere efficacemente sorvegliati da persone fisiche durante il loro utilizzo (regolamento (UE) 2024/1689, articolo 14).

Obblighi fondamentali di sorveglianza umana

La sorveglianza umana deve mirare a prevenire o ridurre al minimo i rischi per la salute, la sicurezza o i diritti fondamentali che possono emergere quando un sistema di IA ad alto rischio è utilizzato conformemente alla sua finalità prevista o in condizioni di uso improprio ragionevolmente prevedibile.

Ai sensi dell'articolo 14, paragrafo 4, il sistema deve essere fornito in modo che le persone incaricate di sorvegliarlo siano messe in condizione, ove opportuno e proporzionato, di:

1. Comprendere correttamente le capacità e i limiti pertinenti del sistema di IA ad alto rischio e monitorarne debitamente il funzionamento, anche al fine di individuare e affrontare anomalie, disfunzioni e prestazioni inattese
2. Restare consapevoli della possibile tendenza a fare automaticamente affidamento o a fare eccessivo affidamento sull'output prodotto da un sistema di IA ad alto rischio (bias di automazione)
3. Interpretare correttamente l'output del sistema, tenendo conto, ad esempio, degli strumenti e dei metodi di interpretazione disponibili
4. Decidere di non utilizzare il sistema o di ignorare, annullare o ribaltare in altro modo l'output in una situazione specifica
5. Intervenire sul funzionamento del sistema o interromperlo mediante un pulsante di «arresto» o una procedura analoga che consenta di arrestarlo in condizioni di sicurezza

Inoltre, le misure di sorveglianza devono essere commisurate ai rischi, al livello di autonomia e al contesto di utilizzo, e devono essere individuate e integrate nel sistema dal fornitore prima dell'immissione sul mercato, ove tecnicamente possibile, oppure individuate come adeguate a un'attuazione da parte del deployer, o entrambe le cose (articolo 14, paragrafo 3).

Tre modi di organizzare la sorveglianza

L'articolo 14 non nomina tipi di sorveglianza. Un modo comune di organizzare le misure che richiede riprende tre schemi dagli Orientamenti etici per un'IA affidabile pubblicati nel 2019 dal gruppo di esperti ad alto livello sull'IA: human-in-the-loop, human-on-the-loop e human-in-command. Sono una lettura dell'articolo 14, non categorie definite dal regolamento.

1. Human-in-the-Loop (HITL)

Il sistema di IA formula una raccomandazione, ma è un essere umano a prendere la decisione finale prima che venga intrapresa qualsiasi azione.

Esempio: un sistema di IA raccomanda di respingere una domanda di prestito, ma un funzionario umano deve esaminare la raccomandazione e approvare il rifiuto prima che il richiedente ne sia informato.

Quando è adatto: decisioni ad alto impatto che riguardano le persone (assunzioni, credito, accesso a prestazioni). L'articolo 14 stesso prescrive una verifica umana specifica in un solo caso: per i sistemi di identificazione biometrica remota (allegato III, punto 1, lettera a)), nessuna azione o decisione può essere adottata sulla base di un'identificazione se questa non è stata verificata e confermata separatamente da almeno due persone fisiche dotate della necessaria competenza, salvo eccezioni in materia di attività di contrasto, migrazione, controllo delle frontiere e asilo (articolo 14, paragrafo 5).

2. Human-on-the-Loop (HOTL)

Il sistema di IA opera in autonomia, ma un essere umano ne monitora il funzionamento in tempo reale e può intervenire se necessario.

Esempio: un veicolo autonomo si guida da solo, ma un operatore di sicurezza monitora il sistema e può assumerne il controllo in qualsiasi momento.

Quando è adatto: sistemi in tempo reale in cui lo human-in-the-loop introdurrebbe una latenza inaccettabile, ma in cui l'intervento umano deve restare possibile.

3. Human-in-Command (HIC)

Un essere umano sorveglia il funzionamento complessivo del sistema di IA, compresa la possibilità di disattivarlo o di spegnerlo.

Esempio: l'amministratore di un ospedale può disattivare uno strumento diagnostico basato sull'IA se inizia a produrre risultati inaffidabili.

Quando è adatto: come livello minimo di base per ogni sistema ad alto rischio. L'articolo 14, paragrafo 4, lettera e), richiede che le persone incaricate della sorveglianza possano intervenire sul sistema o interromperlo mediante un pulsante di «arresto» o una procedura analoga, ove opportuno e proporzionato.

La maggior parte dei sistemi di IA ad alto rischio richiede più livelli di sorveglianza: ad esempio, human-in-the-loop per le singole decisioni più human-in-command per il controllo a livello di sistema.

Elenco di controllo per la conformità all'articolo 14

Ecco che cosa deve attuare e documentare:

Requisito	Che cosa deve attuare	Prove necessarie
Comprensione di capacità e limiti	Materiali formativi, documentazione del sistema, comunicazione delle prestazioni	Manuale d'uso, attestati di formazione completata, istruzioni per l'uso (articolo 13)
Consapevolezza del bias di automazione	Avvisi, formazione sui rischi di eccessivo affidamento, funzioni che impongono una decisione	Avvisi nell'interfaccia, materiali formativi, log di audit delle decisioni
Strumenti di interpretazione	Funzioni di spiegabilità, punteggi di confidenza, importanza delle variabili	Relazioni di spiegabilità, schermate dell'interfaccia, guida all'interpretazione
Capacità di annullare o ignorare	Pulsante di override, flusso di revisione manuale, meccanismo di rifiuto	Documenti di progettazione dell'interfaccia, log degli override, diagrammi di flusso
Capacità di intervenire o arrestare	Pulsante di arresto di emergenza, procedura di spegnimento del sistema, percorso di escalation	Architettura tecnica, progettazione del pulsante di arresto, piano di risposta agli incidenti
Assegnazione del ruolo di sorveglianza	Chi sorveglia il sistema, qualifiche richieste, gerarchia di escalation	Definizione dei ruoli, matrice RACI, requisiti formativi

Esempio pratico: uno strumento di selezione del personale basato sull'IA

Supponiamo che lei fornisca un sistema di IA che esamina i CV e raccomanda i candidati per i colloqui: un sistema ad alto rischio ai sensi dell'allegato III, punto 4, lettera a).

Fase 1: individuare il tipo di sorveglianza richiesto

Il suo sistema orienta decisioni che incidono significativamente sull'accesso delle persone all'occupazione. L'articolo 14 non gli prescrive uno schema; richiede misure commisurate ai rischi, al livello di autonomia e al contesto di utilizzo. Per uno strumento di selezione dei CV, la sorveglianza human-in-the-loop è lo schema più adatto: un essere umano esamina e approva ogni decisione di assunzione prima che i candidati ne siano informati.

Fase 2: progettare gli strumenti di interpretazione

Attua funzioni di spiegabilità affinché i responsabili delle assunzioni possano capire perché il sistema ha raccomandato o respinto un candidato:

• Punteggi di importanza delle variabili: «Questo candidato ha ottenuto un punteggio elevato grazie a: esperienza pertinente (35%), corrispondenza del titolo di studio (28%), allineamento delle competenze (22%), altri fattori (15%)»
• Punteggio di confidenza: «Confidenza: 78% (confidenza media — si raccomanda una revisione manuale)»
• Vista comparativa: confronto affiancato dei migliori candidati con evidenziazione degli elementi differenzianti

Fase 3: attuare un meccanismo di override

Costruisce un flusso di lavoro in cui i responsabili delle assunzioni possono:

• Accettare la raccomandazione dell'IA (il candidato passa alla fase del colloquio)
• Respingere la raccomandazione dell'IA (il candidato è esaminato manualmente da un recruiter senior)
• Segnalare per revisione (il caso è sottoposto al comitato di selezione)

Ogni override è registrato con un codice di motivazione (ad es. «l'IA non ha rilevato un'esperienza pertinente», «il candidato ha un percorso atipico», «possibile bias»).

Fase 4: attenuare il bias di automazione

Aggiunge avvisi nell'interfaccia per evitare l'eccessivo affidamento:

• Messaggio che impone una decisione: «Prima di accettare questa raccomandazione, ha esaminato il CV completo del candidato?»
• Revisione manuale casuale: il 10% delle raccomandazioni dell'IA è segnalato per revisione manuale obbligatoria, anche se il responsabile delle assunzioni concorda con l'IA
• Obbligo formativo: tutti i responsabili delle assunzioni devono completare una formazione di 30 minuti sul bias di automazione prima di utilizzare il sistema

Fase 5: prevedere il controllo a livello di sistema

Attua una sorveglianza human-in-command:

• L'amministratore di sistema (il responsabile delle risorse umane) può disattivare il sistema di IA in qualsiasi momento
• Una dashboard delle prestazioni mostra in tempo reale accuratezza, indicatori di bias e tassi di override
• Attivatori di spegnimento automatico: il sistema si disattiva se l'accuratezza scende sotto l'80% o se gli indicatori di bias superano soglie predefinite

Fase 6: documentare tutto

Redige un documento di progettazione della sorveglianza che comprende:

• Definizione dei ruoli (chi sorveglia che cosa)
• Flussi di sorveglianza (diagrammi dei percorsi decisionali)
• Strumenti di interpretazione (schermate, guida per l'utente)
• Meccanismi di override (progettazione tecnica, log)
• Requisiti formativi (programma, monitoraggio dei completamenti)
• Controlli a livello di sistema (procedure di spegnimento, percorsi di escalation)

Questo documento entra a far parte della documentazione tecnica di cui all'articolo 11 e alimenta le istruzioni per l'uso di cui all'articolo 13.

Lacune ricorrenti e come colmarle

Lacuna 1: nessuna funzione di spiegabilità

Problema: il sistema produce raccomandazioni, ma gli utenti non capiscono perché.

Soluzione: attuare strumenti di interpretazione:

• Punteggi di confidenza (quanto è certo il sistema?)
• Importanza delle variabili (quali fattori hanno determinato questa decisione?)
• Spiegazioni controfattuali (che cosa dovrebbe cambiare per ottenere un esito diverso?)
• Viste comparative (come si colloca questo caso rispetto a casi analoghi?)

Lacuna 2: il meccanismo di override esiste ma non viene usato

Problema: gli utenti possono annullare il sistema, ma nella pratica non lo fanno quasi mai (bias di automazione).

Soluzione: attuare funzioni che impongono una decisione:

• Chieda agli utenti di confermare attivamente le decisioni (non solo di cliccare su «accetta tutto»)
• Renda casuali le revisioni manuali obbligatorie
• Monitori i tassi di override e indaghi se sono troppo bassi
• Formi gli utenti su quando e come annullare una decisione

Lacuna 3: nessuna capacità di spegnimento a livello di sistema

Problema: i singoli utenti possono respingere le raccomandazioni, ma nessuno può arrestare l'intero sistema se inizia a funzionare male.

Soluzione: attuare controlli human-in-command:

• Designi un responsabile del sistema con potere di spegnimento
• Costruisca un meccanismo di arresto di emergenza (ad es. una dashboard di amministrazione con un pulsante «disattiva sistema»)
• Definisca attivatori di spegnimento automatico (soglie di accuratezza, soglie di bias, segnalazioni di incidenti)
• Documenti le procedure di escalation (chi viene informato, con quale tempestività, che cosa succede dopo)

Lacuna 4: i ruoli di sorveglianza non sono definiti

Problema: non è chiaro chi sia responsabile della sorveglianza del sistema, quali qualifiche servano o che cosa debba fare.

Soluzione: definire ruoli e responsabilità di sorveglianza:

• Chi esamina le singole decisioni? (ad es. responsabile delle assunzioni, funzionario del credito)
• Chi monitora le prestazioni a livello di sistema? (ad es. responsabile della conformità, ingegnere ML)
• Chi ha l'autorità di spegnere il sistema? (ad es. CTO, responsabile della conformità)
• Quali qualifiche sono richieste? (ad es. formazione completata, competenza di dominio)
• Come sono registrate e verificate le attività di sorveglianza?

Come l'articolo 14 si collega ad altri articoli

Gli obblighi di sorveglianza dell'articolo 14 si intrecciano con diversi altri obblighi:

• Articolo 9 (gestione dei rischi): i rischi individuati nella valutazione ai sensi dell'articolo 9 determinano quali misure di sorveglianza siano necessarie ai sensi dell'articolo 14.
• Articolo 13 (trasparenza): le misure di sorveglianza attuate ai sensi dell'articolo 14 devono essere descritte nelle istruzioni per l'uso di cui all'articolo 13.
• Articolo 26 (obblighi dei deployer dei sistemi di IA ad alto rischio): i deployer devono affidare la sorveglianza umana a persone fisiche che dispongono della competenza, della formazione e dell'autorità necessarie, nonché del sostegno necessario (articolo 26, paragrafo 2), il che presuppone che lei (il fornitore) abbia progettato il sistema in modo da consentire una sorveglianza efficace.
• Articolo 86 (diritto alla spiegazione dei singoli processi decisionali): una persona interessata da una decisione che il deployer adotta sulla base dell'output di un sistema di IA ad alto rischio dell'allegato III (diverso da quelli di cui al punto 2), e che produce effetti giuridici o incide in modo analogamente significativo su di essa, ha il diritto di ottenere dal deployer spiegazioni chiare e significative sul ruolo del sistema di IA e sui principali elementi della decisione. Il deployer può fornire tale spiegazione solo se l'output del suo sistema è interpretabile: un motivo in più per integrare strumenti di interpretazione.

Che cosa cercheranno le autorità

Quando un'autorità di vigilanza del mercato esamina il suo sistema di IA ad alto rischio, si aspetti domande come:

1. Mi mostri come gli esseri umani sorvegliano questo sistema. (Quali flussi, strumenti e controlli esistono?)
2. Come fanno le persone incaricate della sorveglianza a capire che cosa sta facendo il sistema? (Le funzioni di spiegabilità sono integrate?)
3. Le persone incaricate della sorveglianza possono annullare o respingere gli output del sistema? (Esiste un meccanismo di override documentato?)
4. Come prevenite il bias di automazione? (Quali formazioni, avvisi o funzioni che impongono una decisione esistono?)
5. Chi può spegnere il sistema in caso di malfunzionamento? (C'è un responsabile designato con potere di spegnimento?)
6. Come sapete che la sorveglianza funziona? (I tassi di override, i tempi di revisione e le segnalazioni di incidenti sono monitorati?)

Se non riesce a dimostrare una sorveglianza efficace con documenti e log, il sistema non sembra soddisfare l'articolo 14.

Calendario e applicazione

Data	Tappa
2 agosto 2025	Si applicano gli obblighi relativi ai modelli di IA per finalità generali e il regime sanzionatorio
2 agosto 2026	Si applicano gli obblighi di trasparenza dell'articolo 50 (non rinviati)
2 dicembre 2027	Si applicano gli obblighi dell'articolo 14 ai sistemi di IA ad alto rischio dell'allegato III
2 agosto 2028	Si applicano gli obblighi relativi ai sistemi ad alto rischio dell'allegato I (IA integrata in prodotti regolamentati)

Se il suo sistema di IA ad alto rischio è già stato immesso sul mercato o messo in servizio prima della sua data di applicazione, i requisiti per l'alto rischio lo riguardano solo se la sua progettazione subisce modifiche significative a partire da quella data (articolo 111, paragrafo 2, come sostituito dal Digital Omnibus). Fanno eccezione i sistemi destinati a essere usati da autorità pubbliche: i loro fornitori e deployer devono conformarsi entro un termine distinto fissato dall'articolo 111, paragrafo 2, che la progettazione cambi o no. Se sta costruendo un nuovo sistema, l'articolo 14 si applica già dalla fase di progettazione.

---

Il presente articolo ha finalità puramente informative e non costituisce consulenza legale. Per orientamenti sulla sua situazione specifica, consulti un professionista legale qualificato.