Sorveglianza umana: l’articolo 14 dell’AI Act in pratica

In sintesi

• La sorveglianza umana è un obbligo vincolante del regolamento sull’intelligenza artificiale, scritto nell’articolo 14 per il fornitore e nell’articolo 26 per il deployer. Non è un’aspirazione etica.
• L’articolo 14, paragrafo 4 elenca cinque capacità precise che la persona incaricata deve possedere, fra cui quella di ignorare o ribaltare un output e quella di arrestare il sistema in condizioni di sicurezza.
• Il deployer sostiene la metà dell’obbligo di cui quasi nessuno scrive: affidare la sorveglianza umana a persone dotate di competenza, formazione, autorità e del sostegno necessario, conservare i log per almeno sei mesi, informare i rappresentanti dei lavoratori prima dell’impiego sul luogo di lavoro.
• L’omnibus digitale ha spostato la conformità dei sistemi ad alto rischio dell’allegato III da agosto 2026 al 2 dicembre 2027. È una finestra di progettazione, non una proroga di cortesia.
• Una sorveglianza che esiste sulla carta e fallisce nella pratica costituisce il caso ordinario, non l’eccezione. Il bias di automazione e la perdita di competenza ne spiegano la ragione, e le contromisure sono misurabili.

La sorveglianza umana è un obbligo giuridico, non una filosofia di progettazione

Gran parte di quanto viene pubblicato su questo tema si limita a sostenere che la sorveglianza umana è importante. Raramente indica chi debba fare che cosa. La lacuna non è secondaria, perché nell’Unione europea la sorveglianza umana ha smesso di essere un principio nel 2024 ed è diventata un obbligo con un titolare individuato. L’articolo 14, paragrafo 1 del regolamento richiede che i sistemi di IA ad alto rischio siano progettati e sviluppati con strumenti di interfaccia uomo-macchina adeguati, in modo da poter essere effettivamente sorvegliati da persone fisiche per tutto il periodo del loro utilizzo. L’obbligo si attacca alla progettazione del sistema, non a una procedura interna che descrive il sistema. L’articolo 14, paragrafo 2 ne enuncia la finalità: prevenire o ridurre al minimo i rischi per la salute, la sicurezza o i diritti fondamentali che possono emergere quando un sistema ad alto rischio viene utilizzato conformemente alla sua finalità prevista o in condizioni di uso improprio ragionevolmente prevedibile, in particolare quando tali rischi persistono nonostante le altre prescrizioni della sezione 2. L’articolo 14, paragrafo 3 fissa la calibratura e ripartisce il lavoro. Le misure di sorveglianza devono essere commisurate ai rischi, al livello di autonomia e al contesto d’uso del sistema, e vengono erogate attraverso due canali: le misure che il fornitore individua e integra nel sistema prima dell’immissione sul mercato, e le misure che il fornitore individua come destinate all’attuazione da parte del deployer. Un fornitore non si libera scrivendo nelle istruzioni per l’uso che il cliente provvederà a sorvegliare, e un deployer non si libera presumendo che il produttore se ne sia occupato. Vale infine una precisazione terminologica che evita molta confusione. La sorveglianza umana è una nozione giuridica. Non coincide con il vocabolario di human-in-the-loop e human-on-the-loop che proviene dall’esercizio dei modelli, anche se i due ambiti si sovrappongono in parte. La tassonomia descrive dove una persona si colloca in un flusso decisionale. Il regolamento descrive che cosa quella persona deve essere in grado di fare, e che cosa l’organizzazione deve essere in grado di dimostrare. La tassonomia la trattiamo separatamente nel nostro confronto fra human-in-the-loop e human-on-the-loop.

Che cosa richiede davvero l’articolo 14, paragrafo 4: cinque capacità

Il testo operativo si articola in cinque punti. Il sistema va fornito al deployer in modo tale che le persone fisiche incaricate della sorveglianza siano in grado, nella misura appropriata e proporzionata, di compiere cinque operazioni. Comprendere il sistema e monitorarlo. Chi sorveglia deve comprendere adeguatamente le capacità e i limiti del sistema ad alto rischio ed essere in grado di monitorarne debitamente il funzionamento, anche al fine di individuare e affrontare anomalie, disfunzioni e prestazioni inattese. Si tratta insieme di un requisito di formazione e di un requisito di strumentazione. Nessuno riconosce un output anomalo senza sapere che aspetto abbia un output normale. Restare consapevoli del bias di automazione. Chi sorveglia deve mantenere consapevolezza della possibile tendenza a fare automaticamente affidamento, o a fare eccessivo affidamento, sugli output prodotti dal sistema, in particolare quando questo fornisce informazioni o raccomandazioni per una decisione assunta da una persona. Il regolamento nomina esplicitamente questa modalità di fallimento, sicché un impianto di sorveglianza che la ignora risulta carente già sul piano del testo. Interpretare correttamente l’output. Chi sorveglia deve essere in grado di interpretare correttamente gli output del sistema, tenendo conto delle sue caratteristiche e degli strumenti e metodi di interpretazione disponibili. Quando l’output è un punteggio, una graduatoria o una probabilità, l’interfaccia deve renderne leggibile il significato. È il momento in cui la spiegabilità smette di essere una virtù e diventa una dipendenza. Decidere di non usarlo, oppure ribaltarlo. Chi sorveglia deve poter decidere, in una determinata situazione, di non utilizzare il sistema ad alto rischio, oppure di ignorarne, superarne o ribaltarne l’output. Il verbo « ribaltare » ha un peso specifico, perché presuppone che la decisione sia reversibile a valle e non soltanto rifiutabile nel momento in cui viene prodotta. Intervenire o arrestare. Chi sorveglia deve poter intervenire sul funzionamento del sistema o interromperlo mediante un pulsante di arresto o una procedura analoga che consenta al sistema di fermarsi in uno stato sicuro. Prese insieme, queste cinque capacità sono funzionalità di prodotto. Ciascuna deve esistere nell’interfaccia, nella procedura operativa e nel modello delle autorizzazioni. Una politica di governance che afferma che ogni decisione ad alto rischio viene verificata da una persona non ne soddisfa nessuna.

La metà del deployer di cui nessuno scrive

Chi cerca informazioni sul tema trova molto su quello che il fornitore deve costruire e quasi nulla su quello che il deployer deve presidiare. L’articolo 26 ospita questa seconda metà, e per la maggior parte delle organizzazioni è quella che si applica, dal momento che la maggior parte acquista i sistemi di IA anziché svilupparli. La ripartizione dei ruoli conviene leggerla prima nella nostra guida agli operatori del regolamento IA. L’articolo 26, paragrafo 2 contiene la frase da tenere a mente: i deployer affidano la sorveglianza umana a persone fisiche che dispongono della competenza, della formazione e dell’autorità necessarie, nonché del sostegno necessario. Quattro parole, quattro distinti obblighi di prova. La competenza significa che la persona sa effettivamente leggere l’output del sistema. La formazione presuppone una traccia documentale del modo in cui quella capacità è stata acquisita. L’autorità implica che il suo superamento della macchina non dipenda da un’escalation tale da renderlo impraticabile. Il sostegno comprende tempo, strumenti e organico, ed è l’elemento che la pratica tradisce più spesso, quando la sorveglianza viene assegnata a chi ricopre già un ruolo a tempo pieno. I paragrafi contigui completano il quadro. L’articolo 26, paragrafo 1 impone misure tecniche e organizzative adeguate a garantire un uso conforme alle istruzioni. L’articolo 26, paragrafo 5 obbliga il deployer a monitorare il funzionamento e, quando abbia motivo di ritenere che l’uso possa presentare un rischio, a informare senza indebito ritardo il fornitore e l’autorità di vigilanza del mercato, nonché a segnalare immediatamente gli incidenti gravi. Questo circuito di segnalazione ha una meccanica propria, che descriviamo nella nostra guida alla segnalazione degli incidenti legati all’IA. L’articolo 26, paragrafo 6 impone di conservare i log generati automaticamente per un periodo adeguato alla finalità prevista, e comunque di almeno sei mesi, salvo diversa disposizione del diritto dell’Unione o nazionale. L’articolo 26, paragrafo 7 obbliga il datore di lavoro che impieghi un sistema ad alto rischio sul luogo di lavoro a informarne i rappresentanti dei lavoratori e i lavoratori interessati prima della messa in servizio. In Italia questa architettura si innesta su una cornice nazionale già definita. La legge 23 settembre 2025, n. 132, prima legge nazionale sull’intelligenza artificiale adottata nell’Unione, individua l’Agenzia per l’Italia digitale come autorità di notifica, competente per la promozione dell’innovazione e per la valutazione della conformità, e l’Agenzia per la cybersicurezza nazionale come autorità di vigilanza del mercato, competente per controlli, ispezioni e sanzioni. È quest’ultima, in concreto, l’interlocutore che chiederà conto delle misure di sorveglianza. Esiste infine una regola numerica che i commenti citano di rado. Ai sensi dell’articolo 14, paragrafo 5, per i sistemi di identificazione biometrica remota di cui all’allegato III, punto 1, lettera a), il deployer non può adottare alcuna azione o decisione sulla base dell’identificazione prodotta, salvo che questa sia stata verificata e confermata separatamente da almeno due persone fisiche dotate della competenza, della formazione e dell’autorità necessarie. L’obbligo non si applica quando il diritto dell’Unione o quello nazionale lo consideri sproporzionato per finalità di contrasto, migrazione, controllo delle frontiere o asilo.

Quando la sorveglianza umana diventa esigibile: il riavvio dell’omnibus

Una quota rilevante dei contenuti che oggi si posizionano su questo tema afferma o lascia intendere che gli obblighi sui sistemi ad alto rischio si applichino da agosto 2026. L’affermazione è ormai errata, e la data separa un piano di conformità credibile da una reazione affannosa. Il regolamento (UE) 2026/1744, cosiddetto omnibus digitale sull’IA, è entrato in vigore il 27 luglio 2026 e ha modificato il calendario di applicazione del regolamento IA. I sistemi autonomi ad alto rischio dell’allegato III, che coprono fra l’altro selezione del personale, valutazione del merito creditizio, istruzione, attività di contrasto e controllo delle frontiere, devono ora conformarsi entro il 2 dicembre 2027. L’IA incorporata nei prodotti regolati dall’allegato I, come dispositivi medici, macchine e veicoli, slitta al 2 agosto 2028. Due dettagli contano per la pianificazione. In primo luogo si tratta di date di calendario fisse. Secondo l’analisi di Gibson Dunn, l’accordo ha sostituito il meccanismo di attivazione condizionata originariamente proposto dalla Commissione, che avrebbe legato l’applicazione alla disponibilità delle norme armonizzate, con date che non si spostano. In secondo luogo il rinvio è circoscritto. L’articolo 50 sulla trasparenza non è stato modificato: il 2 agosto 2026 resta una scadenza attiva, con un periodo di tolleranza fino al 2 dicembre 2026 per il solo obbligo di marcatura previsto dall’articolo 50, paragrafo 2 per i sistemi già presenti sul mercato. La ragione addotta per il rinvio è che le norme armonizzate e la capacità degli organismi notificati non erano pronte. È una ragione che merita attenzione, perché indica a che cosa serva il tempo guadagnato. Le norme che definiranno che cosa sia una sorveglianza umana adeguata sono ancora in fase di elaborazione. L’organizzazione che legge dicembre 2027 come un permesso ad attendere si troverà a specificare le proprie interfacce di sorveglianza a metà 2027, a fronte di norme pubblicate poco prima. Quella che lo legge come una finestra di progettazione avrà già rilasciato e collaudato quelle interfacce, e disporrà dello storico di esercizio corrispondente.

Il paradosso della sorveglianza: perché un impianto conforme fallisce comunque

Supponiamo che l’interfaccia sia costruita e la persona designata. La sorveglianza può ugualmente fallire, e la sua modalità di fallimento è abbastanza prevedibile da poter essere progettata in anticipo. Il World Economic Forum parla di paradosso della sorveglianza: i quadri di governance come il regolamento IA poggiano sull’assunto che sia la persona a mantenere il controllo, ma la competenza necessaria a sorvegliare un sistema si mantiene con la pratica, e quella pratica è esattamente ciò che ormai svolge il sistema. L’abilità di chi sorveglia si erode perché l’attività che la costruiva è stata automatizzata. Tre forze producono il danno. Il bias di automazione porta i revisori ad accettare un output plausibile senza verifica indipendente, ossia proprio il fallimento che l’articolo 14, paragrafo 4, lettera b) nomina. La stanchezza da approvazione si instaura quando il volume delle conferme di routine rende impossibile un esame reale di ciascuna, e la firma diventa un riflesso. La perdita di competenza segue nell’arco di alcuni mesi, finché la persona nominalmente responsabile non riesce più a riconoscere una risposta sbagliata. Nessuna politica interna più severa risolve il problema. La soluzione consiste nel trattare la sorveglianza come un processo misurato, dotato di indicatori propri. Cinque controlli meritano di essere costruiti:

• Misurare il tasso di superamento e considerare un valore prossimo a zero come un allarme. Un revisore che non contraddice mai il sistema non lo sta sorvegliando. Fissate una soglia minima che faccia scattare un riesame dell’impianto stesso.
• Campionare e ridecidere in cieco. Estraete una percentuale delle decisioni approvate, rimuovete la raccomandazione del sistema e fate decidere in modo indipendente una seconda persona qualificata. Il tasso di divergenza misura se la sorveglianza sia reale.
• Mettere a budget il tempo. La capacità di sorveglianza va allocata come carico di lavoro esplicito, non come riga in una descrizione di ruolo. È il contenuto concreto del sostegno necessario richiesto dall’articolo 26, paragrafo 2.
• Iniettare casi deliberatamente difettosi. Inviate periodicamente ai revisori output anomali sintetici e misurate il tasso di rilevazione. È l’unico test diretto dell’erosione delle competenze.
• Rinnovare la competenza a calendario e ruotare le persone. Legate gli attestati di formazione alla versione del sistema, così che una modifica sostanziale del modello riavvii l’orologio formativo.

Ciascuno di questi controlli produce una traccia, il che torna utile, perché la sezione successiva riguarda proprio le tracce.

Rendere la sorveglianza umana verificabile

Un obbligo che non si sa dimostrare è un obbligo non adempiuto. Gli orientamenti del Garante europeo della protezione dei dati del novembre 2025 sulla gestione del rischio dei sistemi di IA compiono strutturalmente la stessa osservazione, trattando interpretabilità e spiegabilità come prerequisiti e non come funzionalità: un controllo che non si sa spiegare è un controllo che non si sa dimostrare. Un’autorità di vigilanza del mercato, un organismo notificato o l’internal audit cercheranno quattro elementi. Il primo è la descrizione delle misure di sorveglianza nella documentazione tecnica. L’allegato IV esige che il fascicolo descriva le misure di sorveglianza umana, compresi gli strumenti di interfaccia uomo-macchina, e spieghi come gli output debbano essere interpretati dai deployer. Si inserisce nell’obbligo documentale più ampio, che scomponiamo nel nostro articolo sui requisiti di documentazione dei sistemi di IA. Il secondo sono i log. L’articolo 12 impone che i sistemi ad alto rischio consentano la registrazione automatica degli eventi lungo il loro ciclo di vita, e l’articolo 26, paragrafo 6 colloca il deployer sotto un orologio di conservazione di almeno sei mesi. Il log trasforma un’affermazione sulla sorveglianza in una cronologia ricostruibile. Il terzo è il registro dei ruoli: chi sorveglia quale sistema, quale competenza e quale formazione possiede, quale autorità esercita e a quale data tutto ciò è stato aggiornato l’ultima volta. Il quarto è il registro degli interventi: superamenti, ribaltamenti, escalation e arresti, con la motivazione allegata. Il quaderno sull’accountability dell’Alan Turing Institute offre qui una cornice utile, distinguendo l’answerability, cioè la capacità di spiegare una decisione, dall’auditability, cioè la capacità di dimostrare il processo che l’ha prodotta. La stessa distinzione la riprendiamo nel nostro articolo sulla responsabilità dell’IA. Va infine tenuto presente che la normazione è in corso. Il progetto prEN 18229-1, elaborato dal CEN-CENELEC JTC 21 nell’ambito della richiesta di normazione M/613, copre registrazione, trasparenza e sorveglianza umana per gli articoli 12, 13 e 14. Si tratta di un progetto sotto licenza, che quindi non può essere citato, ma la sua esistenza indica dove si assesterà il livello di esigenza.

Allineare la sorveglianza umana a ISO 42001 e al NIST AI RMF

Poche organizzazioni si confrontano con un solo riferimento normativo. La mossa efficiente consiste nel produrre un unico corredo di prove di sorveglianza che ne soddisfi più di uno. La norma ISO/IEC 42001 conta 38 controlli distribuiti su nove aree nell’allegato A, che coprono valutazione d’impatto, gestione dei dati, trasparenza, spiegabilità, sorveglianza umana e gestione del ciclo di vita. L’area dedicata all’uso responsabile dei sistemi accoglie gli impianti di sorveglianza in esercizio, e le sue aspettative documentali coincidono strettamente con i registri descritti sopra. Il NIST AI RMF è ancora più esplicito. La sottocategoria GOVERN 3.2 stabilisce che politiche e procedure siano in essere per definire e distinguere ruoli e responsabilità relativi alle configurazioni uomo-IA e alla sorveglianza dei sistemi di IA. È lo stesso corredo probatorio: un ruolo nominato, un perimetro di autorità definito, una procedura documentata. La conseguenza pratica è che gli artefatti sono condivisibili anche quando i riferimenti normativi non lo sono. Un registro dei ruoli, un fascicolo formativo, un log dei superamenti e un percorso di escalation documentato soddisfano simultaneamente l’obbligo di presidio dell’articolo 26, paragrafo 2, il controllo di uso responsabile di ISO 42001 e GOVERN 3.2. La sovrapposizione più ampia la mappiamo nella nostra guida allo stack normativo ISO 42001 e regolamento IA.

La sorveglianza umana applicata all’IA agentica

I sistemi agentici incrinano gli assunti dell’articolo 14 in modo preciso. Quando un sistema pianifica, invoca strumenti ed esegue azioni in più passaggi, l’oggetto della sorveglianza non è più un singolo output ma una sequenza di effetti esterni. Un’analisi di architettura di conformità pubblicata nel 2026 sugli agenti di IA nel diritto dell’Unione individua l’elusione della sorveglianza derivante dall’apprendimento per rinforzo come sfida propria degli agenti, accanto alla minimizzazione dei privilegi, alla trasparenza multiparte e alla deriva comportamentale a runtime, valutata rispetto al confine della modifica sostanziale di cui all’articolo 3, punto 23. La conclusione è netta: i sistemi agentici ad alto rischio la cui deriva comportamentale non sia tracciabile non possono, allo stato, soddisfare i requisiti essenziali del regolamento. Ne discendono due conseguenze progettuali. La capacità di arresto della lettera e) deve raggiungere le azioni dell’agente e non soltanto il suo testo, il che presuppone un percorso di interruzione verso gli strumenti e le integrazioni che l’agente può invocare. E la capacità di monitoraggio della lettera a) deve estendersi al log delle azioni, perché la superficie di danno di un agente sta in ciò che ha fatto e non in ciò che ha detto. Il problema di governance più ampio lo esaminiamo nel nostro articolo sugli agenti di IA autonomi.

Domande frequenti

La sorveglianza umana è imposta dalla legge? Sì, per i sistemi di IA ad alto rischio nell’Unione europea. L’articolo 14 del regolamento obbliga il fornitore a progettare sistemi effettivamente sorvegliabili da persone fisiche, e l’articolo 26, paragrafo 2 obbliga il deployer ad affidare tale sorveglianza a persone dotate della competenza, della formazione, dell’autorità e del sostegno necessari. Fuori dalla categoria ad alto rischio il requisito non è formulato come obbligo autonomo, ma l’articolo 50 sulla trasparenza e le discipline settoriali possono comunque applicarsi. Che differenza c’è fra sorveglianza umana e human-in-the-loop? Human-in-the-loop descrive un’architettura: una persona si colloca nel flusso decisionale e interviene prima che l’esito diventi definitivo. La sorveglianza umana è un obbligo giuridico che verte su capacità e responsabilità, non su una topologia. Un’architettura può essere human-in-the-loop e nondimeno violare l’articolo 14, se la persona non dispone dell’autorità per superare la macchina o della formazione per interpretarne correttamente l’output. Chi risponde della sorveglianza, il fornitore o il deployer? Entrambi, su metà distinte. Il fornitore costruisce le capacità di interfaccia e individua le misure che il deployer dovrà attuare, ai sensi dell’articolo 14, paragrafo 3. Il deployer presidia, finanzia e documenta la sorveglianza vera e propria, ai sensi dell’articolo 26. Nessuna delle due parti si libera indicando l’altra. Da quando si applicano gli obblighi di sorveglianza del regolamento IA? Per i sistemi autonomi ad alto rischio dell’allegato III, dal 2 dicembre 2027, dopo che il regolamento (UE) 2026/1744 ha spostato la scadenza da agosto 2026. Per l’IA incorporata nei prodotti regolati dall’allegato I, dal 2 agosto 2028. Gli obblighi di trasparenza dell’articolo 50 non sono stati rinviati e si applicano dal 2 agosto 2026. Che cosa vale come prova di sorveglianza umana in un audit? Quattro artefatti: la descrizione delle misure di sorveglianza e degli strumenti di interfaccia nella documentazione tecnica dell’allegato IV, i log generati automaticamente e conservati almeno sei mesi ai sensi dell’articolo 26, paragrafo 6, un registro dei ruoli che indichi chi sorveglia quale sistema con i relativi attestati di competenza e formazione, e un registro degli interventi che raccolga superamenti, escalation e arresti con la motivazione. La sorveglianza umana si applica ai modelli di IA per finalità generali? L’articolo 14 vincola i sistemi di IA ad alto rischio, non i modelli per finalità generali in quanto tali. Un modello integrato in un sistema ad alto rischio fa rientrare quel sistema nell’ambito di applicazione, e i fornitori di modelli con rischio sistemico sopportano obblighi distinti ai sensi degli articoli 53 e 55. La distinzione la esponiamo nella nostra panoramica sull’IA per finalità generali.

Conclusione

Se la sorveglianza umana merita di essere presa sul serio, non è perché l’autorità porrà la domanda, per quanto la porrà. È perché costituisce il controllo che intercetta tutto quello che gli altri controlli lasciano passare, ed è esattamente per questo che cede in silenzio quando nessuno la misura. Le organizzazioni che supereranno un’ispezione nel dicembre 2027 non saranno quelle con la migliore politica di sorveglianza. Saranno quelle capaci di nominare la persona, esibirne l’attestato di formazione, estrarre il log dei superamenti e spiegare perché il tasso di superamento si collochi dove si colloca. Ognuno di questi artefatti richiede mesi di storico di esercizio, ed è la ragione per cui il rinvio è una finestra di progettazione e non un ritardo. Cominciate elencando i vostri sistemi ad alto rischio e ponendo su ciascuno una sola domanda: chi è designato, e quella persona è davvero in grado di arrestarlo?