L’Annex III dell’AI Act è spesso presentato come il fulcro della qualificazione dei sistemi ad alto rischio: una lista chiusa, una presunzione normativa, una promessa di certezza del diritto.
Nella pratica, però, proprio la qualificazione “high-risk” si rivela uno dei passaggi più fragili dell’intero impianto regolatorio.
Non perché manchino regole, poteri di enforcement o obblighi di controllo, ma perché l’Annex III fornisce una qualificazione formale, mentre il rischio che il legislatore intende governare è in larga parte materiale, contestuale e dinamico.
Lo scarto tra intended use e impatto reale non è un difetto di applicazione: è una tensione strutturale dell’architettura normativa.
1. L’Annex III e la certezza formale: necessaria, ma meno solida di quanto sembri
L’approccio per liste non è un errore di progettazione: è una scelta deliberata del legislatore europeo per ridurre la complessità tecnologica a categorie giuridiche controllabili, garantendo certezza del diritto e scalabilità della vigilanza sui sitemi di AI.
L’Annex III individua ambiti e casi d’uso in cui il rischio è presunto ex ante sulla base dell’intended use (art. 6, par. 2).
Questo consente alle Autorità di Sorveglianza del Mercato (MSA) di operare senza dover reinventare, caso per caso, il concetto di rischio.
Tuttavia, la “certezza” garantita dalla lista è meno robusta di quanto appaia.
Molte nozioni interne all’Annex III — come ad esempio cosa costituisca una prioritizzazione o un filtraggio rilevante in ambiti quali istruzione, lavoro o accesso ai servizi — restano esse stesse oggetto di difficile interpretazione.
La lista non elimina il giudizio: lo sposta; e lo spostamento non riguarda la legittimità della norma, ma la sua capacità di intercettare l’impatto reale dei sistemi.
2. Influenza materiale: riducibile per diritto, non per natura
L’AI Act fonda la qualificazione high-risk sull’intended use.
È una scelta coerente con l’esigenza di certezza del diritto.
Il problema emerge quando il rischio non deriva da una decisione automatizzata, ma da influenza sistematica sulle decisioni umane.
L’influenza materiale non è solo funzione di:
- peso statistico dell’output
- dipendenza funzionale
- irreversibilità tecnica
ma è anche il risultato di fattori qualitativi:
- autorità epistemica attribuita al modello
- asimmetria cognitiva tra utente e sistema
- fenomeni di automation bias.
Questa influenza non è ontologicamente inevitabile.
L’art. 14 dell’AI Act presuppone che un design adeguato dell’interfaccia uomo-macchina possa mitigarla.
Il nodo critico, però, non è la possibilità teorica di mitigazione, ma la sua dimostrabilità ex ante.
Sistemi che introducono frizioni cognitive, spiegazioni contro-intuitive o validazioni argomentate possono ridurre l’autorità epistemica del modello.
Ma distinguere tra:
- oversight progettato per neutralizzare il bias
- oversight che maschera l’influenza dietro una validazione formale
resta, nella maggior parte dei casi, una valutazione ex post.
Il rischio regolatorio nasce qui: tra ciò che può essere documentato e ciò che, nel contesto reale, orienta effettivamente le decisioni.
3. L’art. 6(3): una deroga tassativa e logicamente paradossale
L’art. 6, par. 3 non introduce una valutazione libera di “assenza di rischio”.
La deroga opera solo se ricorrono congiuntamente due requisiti:
- il sistema rientra in una delle quattro condizioni tassative:
(a) compito procedurale ristretto
(b) miglioramento di un’attività umana preesistente
(c) compito preparatorio
(d) supporto decisionale senza influenza significativa
2. il sistema non presenta rischi significativi per i diritti fondamentali
Il rispetto di una delle condizioni (a–d) è quindi necessario, ma non sufficiente.
Inoltre:
- la valutazione deve avvenire prima dell’immissione sul mercato
- deve essere documentata
- deve essere conservata ed esibita on request
- e, per i sistemi Annex III, registrata nel database UE ai sensi dell’art. 49 AI Act
Qui emerge un paradosso strutturale: per dimostrare il no significant risk occorre spesso un’analisi d’impatto sostanzialmente equivalente a quella richiesta per i sistemi high-risk.
La deroga rischia così di trasformarsi in una compliance anticipata, più che in una reale semplificazione.
4. Profilazione: la promessa regolatoria più fragile
La profilazione, come definita dal GDPR e richiamata dall’AI Act, non rende automaticamente high-risk un sistema che resta fuori dall’Annex III.
Ma per i sistemi che rientrano nell’Annex III, la presenza di profilazione azzera ogni spazio di deroga.
In termini operativi: se c’è profilazione, le condizioni (a–d) dell’art. 6(3) diventano irrilevanti.
La profilazione funziona, quindi, per i sistemi che rientrano nell’Annex III, come gatekeeper assoluto.
Il problema è che, nei sistemi contemporanei, la profilazione è spesso indiretta:
- proxy variables
- correlazioni latenti
- inferenze contestuali
Se si prende sul serio questa dinamica, l’art. 6(3) rischia di diventare una
promessa regolatoria difficilmente realizzabile: formalmente prevista, ma tecnicamente inaccessibile.
Il buco non è normativo, è nella distanza tra come i sistemi sono descritti e come producono effetti.
5. Human oversight (Art. 14): obbligo di mezzi e capro espiatorio funzionale
L’AI Act affida, poi, all’human oversight il compito di mitigare i rischi, inclusi quelli derivanti dall’influenza sistematica del sistema.
Dal punto di vista della compliance, il quadro è lineare: se il provider forma l’operatore, fornisce strumenti di intervento e documenta il processo, l’obbligo dell’art. 14 è adempiuto.
Il punto critico non è giuridico, ma funzionale.
Accanto all’automation bias, emerge un secondo fenomeno decisivo: il confirmation bias indotto dalla velocità.
Output rapidi, coerenti e plausibili tendono a:
- anticipare il giudizio umano
- orientare la valutazione prima della riflessione critica
- trasformare il controllo umano in ratifica post-hoc
Il risultato è una tensione strutturale: l’ordinamento accetta un oversight formalmente corretto anche quando l’umano non ha la capacità cognitiva di contrastare l’autorità del sistema.
In questo senso, l’oversight rischia di trasformarsi in uno scudo legale che sposta la responsabilità sull’operatore umano, senza ridurre realmente l’influenza algoritmica.
6. Incentivi asimmetrici e trappola regolatoria per le PMI
Gli incentivi prodotti dal sistema non sono neutrali.
Per le grandi organizzazioni, l’over-compliance può essere una strategia razionale di gestione del rischio.
Per molte PMI è, invece, economicamente insostenibile.
Allo stesso tempo:
- la deroga dell’art. 6(3) richiede competenze e dati difficili da produrre
- la zona grigia espone a rischi legali e reputazionali elevati
Ne deriva una asimmetria regolatoria strutturale: la stessa architettura normativa produce effetti opposti in base alla capacità economica e organizzativa dell’operatore.
7. Shadow AI, Art. 25 e PMM: asimmetria informativa e contrattuale
Con shadow AI si intende l’uso di sistemi di intelligenza artificiale al di fuori dell’intended use dichiarato, spesso attraverso adattamenti operativi, riutilizzi interni o integrazioni informali decise dal deployer.
Non si tratta di sistemi “nascosti”, ma di usi devianti, progressivi e non formalizzati che emergono nel tempo all’interno delle organizzazioni.
Un esempio tipico è un sistema di ranking usato formalmente come strumento di supporto per ordinare candidature, che nella pratica viene progressivamente utilizzato dai recruiter come filtro sostanziale, riducendo il riesame umano a una verifica marginale.
L’intended use resta invariato sulla carta, ma l’uso reale evolve fino a incidere materialmente sugli esiti decisionali.
La normativa non ignora la shadow AI:
- l’art. 25 rialloca la responsabilità sul deployer che modifica l’intended use
- l’art. 72 impone un Post-Market Monitoring Plan, fondato anche sulla cooperazione del deployer
Il problema non è l’assenza di obblighi, ma la loro effettiva praticabilità.
Il provider ha diritto a ricevere informazioni, ma spesso non ha la forza contrattuale per imporre un monitoraggio invasivo a un grande cliente corporate.
Nasce così una duplice asimmetria:
- informativa → il provider vede log e metriche, non il contesto decisionale
- contrattuale → il potere di controllo reale resta in capo al deployer
Il rischio non resta “senza padrone” ma cambia padrone, spostandosi verso soggetti che spesso hanno meno competenze tecniche per gestirlo.
Conclusione
L’Annex III non è scritto male: è scritto per essere rigido, scalabile e politicamente sostenibile.
Ma il rischio che l’AI Act intende governare è spesso:
- qualitativo
- emergente
- dipendente dal contesto organizzativo
Le deroghe sono tassative, l’oversight è formalmente sufficiente e il monitoraggio ex post è strutturalmente limitato.
La fragilità della compliance non nasce da una violazione manifesta, ma dalla tensione irrisolta tra lista, influenza materiale e responsabilità effettiva.
Ed è in questa tensione — non nell’inadempimento palese — che oggi si colloca il rischio regolatorio più concreto dell’AI Act.