AI Act: cosa devono fare davvero le aziende (deployer) — obblighi, rischi e limiti della human oversight

1. Il Deployer Come Soggetto Giuridico: Una Definizione che Pesa

L’articolo 3, paragrafo 4 dell’AI Act definisce il deployer come

“qualsiasi persona fisica o giuridica […] che utilizza sotto la propria responsabilità un sistema di IA, eccetto i casi di uso personale”.

La definizione è volutamente ampia. Vi rientrano:

• la pubblica amministrazione che affida a un algoritmo la pre-selezione dei curricula,
• l’ospedale che usa un sistema diagnostico sviluppato da un fornitore esterno,
• la banca che integra nei processi di scoring creditizio un modello proprietario di terze parti, e
• la PMI che acquista una soluzione SaaS con capacità predittive incorporate.

Ciò che accomuna queste realtà eterogenee è la loro posizione nella catena del valore:

• non hanno scritto il codice,
• non conoscono l’architettura del modello,
• non hanno accesso ai dati di addestramento.

Hanno scelto di usare il sistema, spesso perché era lo strumento più efficiente disponibile, e in virtù di questa scelta la legge li ha resi responsabili di governarne l’impiego.

La responsabilità del deployer non è residuale o accessoria rispetto a quella del provider: è autonoma, operativa, e — in certi scenari — più immediatamente sanzionabile, perché è il deployer a generare l’atto concreto che produce effetti sui soggetti interessati.

Questo spostamento del baricentro normativo è il punto meno compreso del regolamento. Ci si continua a chiedere se un certo sistema “rientri nell’Allegato III” — questione certamente rilevante, già trattata nei pezzi precedenti di questa serie — ma ci si chiede meno chi risponde di quel sistema una volta che è in produzione, e a quali condizioni quella responsabilità può essere effettivamente esercitata.

2. Il Quadro degli Obblighi: Cosa Prescrive la Norma

L’articolo 26 del regolamento elenca gli obblighi del deployer per i sistemi ad alto rischio. È un elenco che vale la pena leggere senza parafrasarlo troppo in fretta.

Il deployer deve:

• usare il sistema in conformità alle istruzioni d’uso fornite dal provider;
• garantire che il personale che opera con il sistema abbia una competenza adeguata — il collegamento con l’Art. 4 sull’AI literacy è diretto;
• implementare misure di sorveglianza umana;
• monitorare il funzionamento del sistema e segnalare anomalie;
• conservare i log automaticamente generati, nei limiti del proprio controllo tecnico su di essi.

Per i sistemi che incidono su persone fisiche, sussiste inoltre l’obbligo di informare i soggetti interessati e — in certi contesti — di garantire il diritto a una spiegazione significativa delle decisioni automatizzate.

Il perimetro è definito.

Ma la densità normativa di questa lista oscura una tensione strutturale che vale la pena rendere esplicita: tutti questi obblighi presuppongono che il deployer abbia, almeno in parte, la capacità tecnica e contrattuale di adempiervi.

Questa presupposizione non è sempre verificata nella pratica.

L’articolo 26 del regolamento elenca gli obblighi del deployer per i sistemi ad alto rischio. Vale la pena leggerli insieme al presupposto implicito che ciascuno porta con sé — è lì che si nasconde la tensione operativa reale.

Il primo obbligo è l’uso conforme alle istruzioni d’uso fornite dal provider.

Il presupposto è che quelle istruzioni esistano e siano sufficientemente specifiche. Nella pratica, tendono a coprire scenari standard, non i casi limite che emergono nei contesti applicativi reali del singolo deployer.

Il secondo è la sorveglianza umana effettiva.

Si presuppone che il personale sia formato e in condizione concreta di intervenire. Il problema è che l’automation bias riduce la sorveglianza a ratifica, e la pressione operativa comprime ulteriormente i tempi di verifica effettiva.

Il terzo riguarda la conservazione dei log generati automaticamente dal sistema.

L’obbligo presuppone che il deployer abbia accesso tecnico a quei log. Con sistemi SaaS e modelli ospitati in cloud di terze parti, la granularità dei log accessibili dipende dal livello contrattuale negoziato con il provider — non dalla norma.

Il quarto è la segnalazione delle anomalie all’autorità competente.

Si presuppone che il deployer sia in grado di identificare cosa costituisce un’anomalia. In sistemi opachi, però, il confine tra output atteso e malfunzionamento non è sempre riconoscibile dall’esterno.

Il quinto, collegato all’Art. 4, riguarda l’AI literacy del personale.

Il presupposto è che esistano programmi di formazione adeguati e verificabili. La norma, però, non definisce il livello minimo richiesto, né designa alcun soggetto come responsabile di certificarne il raggiungimento.

3. La Frattura Logica: Responsabilità Senza Accesso

Il paradosso al centro del regime del deployer può essere formulato in modo semplice: la norma chiede a chi usa di sorvegliare ciò che non può aprire.

Un deployer che integra un modello linguistico avanzato nei propri flussi di lavoro — per la redazione di comunicazioni, per la sintesi di documenti, per il supporto alle decisioni cliniche — non ha accesso all’architettura del modello, ai dati su cui è stato addestrato, alle logiche di allineamento che ne determinano gli output.

Può osservare il risultato; non può verificare il processo.

Questa asimmetria informativa è strutturale per molti deployer, in particolare quelli di minori dimensioni o che operano in settori non tecnologici, ma non è uniforme.

Una grande banca che integra un sistema di scoring creditizio avrà risorse contrattuali e tecniche molto diverse da una PMI che si abbona un servizio SaaS predittivo:

• il livello di trasparenza ottenibile dal provider,
• la granularità dei log disponibili,
• la possibilità di negoziare clausole di audit

sono tutti elementi che variano in funzione del potere contrattuale del deployer. L’asimmetria esiste, ma è variabile e la norma, trattandola come uniforme, produce obblighi identici su soggetti con capacità di adempimento molto diverse.

Il caso documentato dall’Università del New South Wales è istruttivo, anche se va letto con precisione.

La ricerca ha identificato oltre 500 episodi in cui utenti — professionisti legali e, in percentuale prevalente, cittadini che si difendevano senza rappresentanza (self-represented litigants) — hanno prodotto citazioni giurisprudenziali inesistenti generate da modelli di IA generativa, senza rilevare l’errore.

La composizione del campione è rilevante: la maggioranza dei casi riguarda soggetti non formati e privi di struttura organizzativa, il che limita la forza di un’inferenza diretta sulle organizzazioni professionali.

Il caso Murray v State of Victoria è invece quello che riguarda un avvocato in senso proprio: la corte ha rilevato la presentazione di precedenti inesistenti e ha imposto sanzioni, ribadendo che l’uso di strumenti di IA non trasferisce al sistema la responsabilità della verifica.

Le corti australiane hanno poi generalizzato questa posizione con linee guida che impongono scetticismo critico sugli output e verifica indipendente.

La soluzione proposta è ragionevole dal punto di vista deontologico, ma non risolve la questione giuridica: se la verifica fallisce — come nel caso Bottrill v Graham, dove una cittadina non assistita da un legale ha prodotto riferimenti giurisprudenziali inesistenti agendo sotto forte pressione procedurale — la responsabilità ricade sull’utente indipendentemente dalla propria capacità tecnica di distinguere un output corretto da uno allucinato.

Il regime normativo, in altri termini, tende a non distinguere tra una sorveglianza che fallisce per negligenza e una che fallisce perché le condizioni operative non consentivano nulla di diverso — anche se la logica risk-based dell’AI Act lascia in astratto spazio per una valutazione contestualizzata della condotta.

Questo è un punto che la dottrina italiana ha iniziato ad affrontare — la responsabilità del deployer intesa come responsabilità per l’uso e non per il design, con il connesso rischio di riqualificazione come provider in caso di fine-tuning sostanziale — ma che resta privo di chiarezza interpretativa definitiva.

4. Human Oversight: Obbligo Operativo o Rituale Formale?

L’articolo 14 dell’AI Act è uno dei più densi del regolamento. Prescrive che i sistemi ad alto rischio siano progettati e sviluppati in modo da consentire una sorveglianza umana effettiva.

Individua tre modalità di supervisione: ex ante, in tempo reale, ex post.

Il regolamento non dice quale delle tre sia richiesta in ogni caso: dipende dal tipo di sistema, dal contesto, dal livello di rischio.

Questo margine di flessibilità ha una conseguenza operativa rilevante: in assenza di indicazioni più specifiche, le organizzazioni tendono a strutturare forme di oversight che soddisfano la lettera della norma senza necessariamente garantirne lo spirito.

Un log consultabile ex post è formalmente una misura di sorveglianza ma:

• se nessuno lo consulta sistematicamente,
• se non c’è una procedura di escalation quando emerge un’anomalia,
• se il personale addetto non ha ricevuto formazione su cosa cercare,

la supervisione tende, in molti contesti operativi, a ridursi a un passaggio documentale piuttosto che a un processo di controllo reale. Non è una dinamica inevitabile, ma è quella che emerge con maggiore frequenza in organizzazioni che implementano l’oversight senza averla preventivamente strutturata come processo.

Il TAR Lazio, in una sentenza del 2 febbraio 2026 (n. 1895), ha ribadito il principio della “riserva di umanità” per le decisioni amministrative automatizzate, stabilendo che l’AI Act rafforza l’obbligo di controllo umano effettivo sui sistemi ad alto rischio e non consente una delega integrale al sistema.

La formulazione è netta.

Meno netta è la traduzione operativa di questo principio in organizzazioni che usano sistemi off-the-shelf su cui non hanno potere di configurazione tecnica profonda.

Il mapping EDPS offre un dato che dovrebbe essere letto con attenzione: circa la metà dei soggetti che ha segnalato l’uso di sistemi potenzialmente ad alto rischio ha dichiarato che i propri sistemi rientravano nell’esenzione per “compiti preparatori” ai sensi dell’Art. 6(3)(d) dell’AI Act — la clausola che consente di escludere dall’alto rischio i sistemi che, nella lettera della norma, si limitano a “preparare” la decisione senza prenderla.

Il report EDPS attribuisce questa convergenza principalmente a una diffusa apprensione verso l’auto-classificazione come alto rischio, non a una strategia elusiva: la distinzione tra sistema che “prepara” e sistema che “decide” è giuridicamente genuina e giustifica l’esenzione in molti casi concreti.

Ciò che il dato rende visibile è però un problema interpretativo strutturale: in assenza di linee guida operative sul confine tra le due categorie, la classificazione dipende dall’auto-valutazione del deployer, e il sistema non dispone attualmente di strumenti efficaci per verificarne la correttezza caso per caso.

È proprio questo il profilo su cui l’EDPS ha segnalato la necessità di interventi interpretativi futuri.

5. Il Caso Murray e il Default Cognitivo

Nel 2024, una corte australiana ha esaminato il caso di uno studio legale che aveva utilizzato un sistema di IA generativa per la preparazione di memorie processuali senza verificare le citazioni prodotte.

La vicenda non è dissimile da decine di altri episodi documentati nello stesso periodo in varie giurisdizioni, ma ha il merito di rendere visibile un fenomeno che i ricercatori dell’UNSW hanno classificato come automation bias: la tendenza cognitiva ad accettare l’output di un sistema automatizzato senza l’esame critico che si applicherebbe a una fonte umana.

L’automation bias non è una scelta consapevole.

È una risposta adattiva a condizioni di pressione operativa, volume decisionale elevato, limitato tempo di verifica.

In un contesto di lavoro ordinario, la GenAI produce output ad alta coerenza formale e apparente accuratezza che abbassano il livello di allerta del revisore umano.

Il problema non è che il sistema funzioni male in senso tecnico ma che funziona abbastanza bene da sembrare affidabile anche quando non lo è.

Il cortocircuito si manifesta nella sua forma più plastica quando il deployer, per risparmiare tempo, tenta di verificare le allucinazioni di un sistema di IA interrogando un secondo sistema di IA: il report UNSW identifica questa pratica come uno dei vettori principali attraverso cui il fallimento dell’oversight si propaga invece di essere contenuto, e le linee guida derivate la escludono esplicitamente come metodo di verifica accettabile per i professionisti legali.

Questo crea una tensione specifica con il regime dell’AI Act.

La norma chiede oversight effettivo; la psicologia dell’uso, in assenza di contromisure organizzative deliberate, tende a produrre il contrario.

L’automation bias è mitigabile con:

• procedure di verifica a campione,
• soglie obbligatorie di revisione umana per certe categorie di output,
• formazione specifica sui limiti del sistema riducono il rischio in modo misurabile

ma la mitigazione richiede investimento organizzativo intenzionale, e questo riporta alla domanda di fondo: quanto di questo investimento è realisticamente disponibile nei contesti in cui i sistemi vengono effettivamente impiegati?

Un professionista legale che gestisce cinquanta pratiche al mese con supporto AI ha tempi e risorse di verifica molto diversi da chi ne gestisce cinque.

La norma richiede oversight adeguato al rischio del sistema; non modula però l’intensità degli obblighi in funzione del carico operativo del deployer.

La risposta giuridica a questa tensione è ancora in formazione.

La dottrina italiana ha iniziato a sviluppare una distinzione tra deployer attivo — quello che governa l’uso del sistema attraverso procedure di verifica strutturate — e deployer passivo — quello che subisce l’output senza filtro critico.

È una distinzione utile a livello analitico ma diventa problematica se usata per costruire un regime a doppio binario che riduce implicitamente gli obblighi per chi semplicemente non ha le risorse per adempiervi.

6. Logging, Istruzioni d’Uso e AI Literacy: I Tre Pilastri Operativi

6.1 Il problema delle istruzioni d’uso

Il deployer è obbligato a utilizzare il sistema in conformità alle istruzioni d’uso fornite dal provider.

Questo obbligo presuppone che le istruzioni esistano, siano accessibili, siano sufficientemente specifiche e siano applicabili al contesto d’uso concreto.

Nella pratica, le istruzioni d’uso dei sistemi di IA commerciali tendono a essere formulate per coprire scenari generici, non i casi limite che si manifestano in contesti applicativi specifici.

La documentazione di un modello linguistico può indicare che il sistema non deve essere usato per decisioni cliniche senza revisione medica; non dirà come gestire il caso in cui la revisione medica viene sistematicamente subordinata ai tempi di produzione dell’output.

Questo crea una zona di indeterminazione giuridica: il deployer che segue le istruzioni generiche ha adempiuto formalmente all’obbligo, ma potrebbe non aver fatto abbastanza per prevenire un danno concreto.

La compliance formale non equivale a compliance sostanziale, e la distinzione potrebbe diventare rilevante in sede di accertamento della responsabilità.

6.2 Il logging come infrastruttura di accountability

L’obbligo di conservazione dei log è probabilmente il più sottovalutato tra quelli imposti al deployer.

I log di sistema non sono solo uno strumento di controllo tecnico: sono la prova documentale dell’esercizio dell’oversight.

In assenza di log strutturati, in un procedimento di accertamento di violazione, il deployer non è in grado di dimostrare né che il sistema ha funzionato correttamente né che la sorveglianza è stata effettivamente esercitata.

Il problema operativo è che i log disponibili dipendono spesso dall’architettura del sistema e dalle politiche del provider, non dalle esigenze del deployer.

Con sistemi in cloud di fornitori esterni, la granularità dei log accessibili varia significativamente in funzione del livello contrattuale.

Una PMI con un abbonamento standard a un servizio SaaS ha accesso a log molto più limitati rispetto a una grande organizzazione con un contratto enterprise personalizzato.

L’obbligo normativo è però identico: la norma non distingue in base alla dimensione del deployer o alla struttura contrattuale sottostante.

6.3 L’AI literacy come scudo giuridico

L’articolo 4 dell’AI Act impone ai provider e ai deployer di adottare misure per garantire che il proprio personale abbia un livello sufficiente di AI literacy.

La norma fornisce alcune coordinate vincolanti: la formazione deve tenere conto delle «conoscenze tecniche, dell’esperienza, dell’istruzione e della formazione» delle persone coinvolte, nonché del «contesto in cui i sistemi di IA devono essere utilizzati».

Non prescrive però standard quantitativi, soglie minime misurabili o certificazioni predefinite.

Questa flessibilità è intenzionale — la varietà dei contesti applicativi rende impossibile una definizione uniforme — ma genera incertezza operativa su cosa sia dimostrabilmente sufficiente in sede di controllo.

Dal punto di vista della gestione del rischio legale, la AI literacy non dovrebbe essere intesa come un programma formativo generico sull’intelligenza artificiale, ma come la capacità del personale di riconoscere i limiti del sistema specifico che usa, identificare le situazioni in cui l’output richiede verifica indipendente, e attivare le procedure di escalation previste.

Questa distinzione — tra literacy come conoscenza e literacy come competenza operativa verificabile — è quella che in sede di contenzioso farà la differenza tra un deployer che ha adempiuto all’obbligo e uno che ha solo documentato di averlo tentato.

7. PMI, Digital Omnibus e la Tentazione della Semplificazione

Il Digital Omnibus, proposto dalla Commissione Europea nel 2025 come pacchetto di semplificazione normativa, ha tra i suoi obiettivi dichiarati quello di ridurre i costi di compliance per le piccole e medie imprese e per le cosiddette Small Mid-Cap — le imprese a media capitalizzazione che il legislatore europeo ha esplicitamente incluso nel perimetro dei soggetti da alleggerire.

Nel contesto dell’AI Act, questo si traduce in proposte di alleggerimento degli obblighi di registrazione per certi sistemi e di riduzione degli adempimenti documentali per i soggetti di minori dimensioni.

La logica è comprensibile: le PMI non hanno i dipartimenti legali e le strutture di compliance delle grandi organizzazioni, e un onere normativo disegnato su scala enterprise rischia di escluderle de facto dal mercato dell’AI.

Ma la semplificazione ha un costo che il regolatore deve esplicitare.

Se si allentano gli obblighi di oversight per i deployer di dimensioni minori, si crea una categoria di soggetti che usano sistemi ad alto rischio con minori garanzie per i destinatari delle decisioni.

Le preoccupazioni più documentate non riguardano però direttamente gli obblighi di oversight del deployer sotto l’AI Act, ma un profilo distinto: il Digital Omnibus interviene anche sulle basi giuridiche del trattamento dei dati per l’addestramento dei modelli, introducendo deroghe all’Art. 9 GDPR che facilitano l’uso di dati sensibili a fini di sviluppo AI.

Analisti della società civile — noyb in primo luogo — hanno segnalato che queste deroghe sistemiche rischiano di creare asimmetrie di tutela: le stesse organizzazioni che agiscono come deployer nei confronti degli utenti potrebbero simultaneamente beneficiare di regimi alleggeriti sul trattamento dei dati che alimentano i sistemi che usano.

Il soggetto che riceve una decisione da un algoritmo non è in grado di distinguere se il deployer opera in un contesto di governance rigoroso o in uno che ha sfruttato le semplificazioni disponibili.

Questa opacità a valle è la conseguenza diretta di scelte normative che intervengono a monte, e il regolatore non ha ancora fornito un raccordo esplicito tra i due livelli.

8. Il Diritto di Spiegazione e la Posizione del Deployer nella Catena

Chi riceve una decisione prodotta — anche solo in parte — da un sistema di IA ad alto rischio ha, in certi contesti, il diritto di ottenere una spiegazione significativa di quella decisione.

Questo diritto è sancito dal GDPR (Art. 22, in materia di decisioni automatizzate) e rafforzato, per i sistemi ad alto rischio, dal combinato disposto dell’AI Act.

Il soggetto nei confronti del quale questo diritto deve essere esercitato è il deployer — che nel quadro del GDPR opera in veste di Titolare del trattamento, determinando finalità e mezzi dell’uso dei dati — e non il provider.

Questo crea un problema concreto.

Il deployer è tenuto a fornire una spiegazione su un sistema che non ha sviluppato, su un modello di cui non conosce l’architettura interna, su logiche di decisione che non può ispezionare.

La risposta che il provider tipicamente fornisce — documentazione del sistema, descrizione delle variabili di input, indicazione dei range di output attesi — può essere sufficiente per una spiegazione tecnica generica, ma spesso non è sufficiente per una spiegazione specifica e significativa riferita alla decisione individuale che ha prodotto un effetto concreto su una persona determinata.

La sovrapposizione tra AI Act e GDPR in questo ambito è una delle principali fonti di incertezza interpretativa segnalate dalle organizzazioni nel report della Commissione.

Il perimetro delle responsabilità del deployer rispetto a quello del provider in materia di trasparenza algoritmica rimane, a oggi, parzialmente irrisolto — non solo nella pratica, ma anche a livello dottrinale.

9. Una Lettura Critica: Il Deployer Non è Impotente, Ma Non è Nemmeno Onnipotente

Sicuramente sarebbe comodo costruire la narrativa del deployer come vittima di una norma che scarica su di lui responsabilità sproporzionate rispetto al controllo effettivo che può esercitare.

Ma questa lettura è, almeno in parte, inesatta — e vale la pena rendere esplicita la contro-argomentazione più solida, quella che uno scettico ben preparato userebbe senza esitazione.

La versione forte della contro-tesi è questa: il deployer non è una vittima del sistema, è un attore economico che ha scelto di integrare uno strumento efficiente nei propri processi e che, facendolo, ha accettato il rischio connesso.

Se non è in grado di governarlo, non dovrebbe usarlo.

L’AI Act non crea un paradosso: crea una selezione naturale tra operatori che hanno la capacità organizzativa di adempiere e operatori che non ce l’hanno.

La responsabilità segue il potere decisionale, non la competenza tecnica.

E il potere decisionale — scegliere il sistema, definirne l’uso, strutturarne la supervisione — è sempre stato in mano al deployer.

È una posizione coerente, e in parte condivisibile.

L’AI Act non chiede al deployer di auditare il modello: richiede controllo del contesto operativo.

Un compliance officer che struttura processi di verifica degli output, definisce le categorie di decisione che richiedono revisione umana obbligatoria e mantiene log dell’attività del sistema sta adempiendo agli obblighi dell’Art. 26 senza dover comprendere l’architettura del transformer sottostante.

Il controllo tecnico e il controllo operativo sono piani distinti, e la norma opera sul secondo.

Il problema non è che il deployer non abbia potere; è che questo potere non è esercitabile in misura uniforme.

Per molte organizzazioni, la scelta del sistema è determinata dall’offerta di mercato, non da una valutazione tecnica approfondita.

La configurazione del contesto d’uso è vincolata dai contratti con i provider ed iprocessi organizzativi richiedono risorse che non tutte le organizzazioni possiedono allo stesso grado.

La contro-tesi — chi non può governarlo non dovrebbe usarlo — è logicamente valida ma empiricamente costosa: applicata in modo rigido, escluderebbe dal mercato dell’AI una quota significativa di deployer legittimi, soprattutto tra le PMI e nelle pubbliche amministrazioni di minori dimensioni.

La versione più onesta della questione è quindi questa: la norma non è strutturalmente incoerente, ma presenta un’imperfezione fisiologica che diventa rilevante su un segmento specifico del mercato.

L’AI Act costruisce un modello di governance del deployer esigibile per le organizzazioni che hanno risorse sufficienti a implementarlo, e formalmente adempibile — ma sostanzialmente svuotato — per quelle che non le hanno.

La distinzione non è tra norma giusta e norma sbagliata: è tra un impianto regolatorio che funziona in modo disomogeneo su una platea di destinatari profondamente eterogenea.

Questo non è un argomento contro l’AI Act.

È un argomento per il lavoro che le autorità di vigilanza devono ancora fare: tradurre obblighi generali in standard operativi proporzionati che rendano la governance dell’AI concretamente praticabile anche oltre la fascia alta del mercato.

Conclusioni: Una Norma per il Mondo Che Verrà

L’AI Act è una norma ambiziosa che anticipa — o tenta di anticipare — un ecosistema tecnologico ancora in formazione.

La responsabilità del deployer è il suo punto di applicazione più immediato, quello che produce effetti concreti sui soggetti che interagiscono con sistemi di IA nella vita quotidiana: nella selezione del personale, nell’accesso al credito, nell’erogazione di servizi sanitari, nell’interazione con la pubblica amministrazione.

La domanda che resta aperta non è se il deployer debba essere responsabile — su questo il regolamento non lascia margini di ambiguità — ma se le condizioni per esercitare quella responsabilità in modo effettivo, e non puramente formale, siano strutturalmente disponibili nell’attuale configurazione del mercato.

La risposta, allo stato, è che dipende: dalla dimensione dell’organizzazione, dalla qualità del contratto con il provider, dalla struttura dei processi interni, dalla disponibilità dei log, dal livello di formazione del personale.

Questa disomogeneità non è un difetto del sistema normativo: è il costo implicito di un approccio basato sul rischio, che per sua natura produce obblighi proporzionati al contesto anziché uniformi per tutti.

Il problema non è che la norma sia incoerente ma che questo costo ricade, in larga parte, sulle organizzazioni meno attrezzate — e quindi, alla fine, sugli utenti che interagiscono con esse.

Questa variabilità non è necessariamente un difetto del regolamento.

Potrebbe essere il riflesso inevitabile di una realtà in cui sistemi con capacità analoghe vengono usati in contesti radicalmente diversi.

Ma significa che il confine tra compliance sostanziale e compliance ornamentale — tra chi governa davvero l’uso dell’AI e chi documenta di farlo — è determinato, in ultima istanza, da scelte organizzative che il regolatore non può sostituire con obblighi normativi.

E questo, forse, è il messaggio più scomodo che l’AI Act consegna a chi lo deve applicare: la norma può prescrivere la sorveglianza umana, ma non può prescrivere la cultura organizzativa necessaria a renderla reale.