Le prime richieste di informazioni della Commissione europea ai fornitori di intelligenza artificiale — l’AI Act entra nella fase dell’enforcement e cosa significa per le imprese utilizzatrici

Abstract

La Commissione europea, per il tramite dell’AI Office, ha avviato le prime iniziative formali di vigilanza ai sensi del Regolamento (UE) 2024/1689 (AI Act), trasmettendo richieste di informazioni a oltre trenta società attive nello sviluppo e nella distribuzione di sistemi e modelli di intelligenza artificiale. Si tratta di atti istruttori e non di contestazioni, con due aree principali di intervento e senza divulgazione dei destinatari; parallelo il confronto con alcuni fornitori di modelli di uso generale sui profili di cybersicurezza. Il dato realmente rilevante per il lettore professionale non è l’identità dei destinatari, bensì il consolidarsi di un modello di vigilanza documentale nel quale la conformità si dimostra con evidenze già formate: documentazione tecnica, valutazioni di rischio sistemico, misure di sicurezza, tracciabilità della catena del valore. Ne discendono effetti a cascata sui deployer europei — imprese e pubbliche amministrazioni — che dovranno reggere richieste contrattuali e informative di ritorno, in raccordo con gli obblighi del GDPR e della disciplina NIS2.

Premessa

In premessa va detto che l’avvio delle attività di vigilanza da parte della Commissione europea sull’applicazione del Regolamento (UE) 2024/1689 — l’Artificial Intelligence Act — costituisce un passaggio atteso, il cui rilievo si apprezza meno sul piano della cronaca e più su quello del metodo. Il portavoce della Commissione ha confermato in un briefing con la stampa che sono state inviate richieste di informazioni a più di trenta società, che tali richieste attengono a due principali aree di intervento, che non si tratta di accuse né di provvedimenti sanzionatori e che l’identità dei destinatari non viene divulgata in ragione della fase ancora iniziale delle verifiche. La medesima fonte riferisce, inoltre, di contatti intercorsi con due fornitori di modelli di intelligenza artificiale di uso generale in relazione a profili di sicurezza informatica emersi di recente, senza chiarire se tali società rientrino fra i destinatari delle richieste formali.

Il perimetro dell’analisi che segue è delimitato con precisione. Non si intende ricostruire vicende societarie né anticipare esiti istruttori dei quali non si ha evidenza: l’assenza di elementi pubblici sull’identità dei destinatari, sull’oggetto puntuale delle richieste e sui tempi di riscontro impone allo scrivente un esercizio di misura. Si intende, piuttosto, ricostruire il quadro dei poteri di vigilanza che l’AI Act attribuisce alla Commissione e alle autorità nazionali, chiarire quale sia la natura giuridica di una richiesta di informazioni nell’architettura del Regolamento, e — soprattutto — trarne le conseguenze operative per il pubblico di riferimento di questa rivista: i responsabili della protezione dei dati, i giuristi d’impresa e le funzioni di compliance di organizzazioni che, nella grande maggioranza dei casi, non sono fornitori di modelli ma utilizzatori di sistemi di intelligenza artificiale acquistati sul mercato.

Trattasi, per l’appunto, di una prospettiva che merita di essere esplicitata sin dall’inizio. La vigilanza centralizzata sui modelli di uso generale non è, per il tessuto produttivo italiano, un fatto remoto: le richieste rivolte ai fornitori si traducono, per propagazione contrattuale e documentale, in richieste rivolte agli utilizzatori, i quali devono essere in grado di ricostruire quale modello impiegano, per quali finalità, con quali dati e con quali garanzie. Come noto, il medesimo fenomeno si è già osservato nell’applicazione del Regolamento (UE) 2016/679, dove l’attenzione delle autorità sui grandi fornitori di servizi cloud ha prodotto, a valle, un’ondata di revisioni degli accordi ex articolo 28 e delle valutazioni sui trasferimenti internazionali.

L’architettura della vigilanza nell’AI Act: chi controlla che cosa

Il Regolamento (UE) 2024/1689 ha adottato un modello di governance che si discosta sensibilmente da quello del GDPR. Mentre la disciplina sulla protezione dei dati poggia su autorità nazionali indipendenti coordinate attraverso il meccanismo di coerenza e il Comitato europeo per la protezione dei dati, l’AI Act combina una vigilanza nazionale sui sistemi di intelligenza artificiale con una vigilanza accentrata in capo alla Commissione sui modelli di intelligenza artificiale per finalità generali.

In sostanza, il Regolamento distingue due oggetti di disciplina. Da un lato vi sono i “sistemi di IA”, definiti dall’articolo 3, punto 1, come sistemi automatizzati progettati per funzionare con livelli di autonomia variabili e che, per obiettivi espliciti o impliciti, deducono dagli input ricevuti come generare output quali previsioni, contenuti, raccomandazioni o decisioni che possono influenzare ambienti fisici o virtuali. Dall’altro vi sono i “modelli di IA per finalità generali”, ossia i modelli — tipicamente addestrati su grandi quantità di dati mediante auto-supervisione — capaci di svolgere con competenza un’ampia gamma di compiti distinti e integrabili in una pluralità di sistemi a valle.

La distinzione non è meramente tassonomica: da essa discende l’individuazione dell’autorità competente. Sui sistemi ad alto rischio, sulle pratiche vietate e sugli obblighi di trasparenza vigilano le autorità nazionali di vigilanza del mercato designate da ciascuno Stato membro. Sui modelli per finalità generali — inclusi quelli qualificati come modelli con rischio sistemico — la competenza esclusiva è della Commissione, che la esercita attraverso l’ufficio per l’intelligenza artificiale, l’AI Office istituito in seno alla Direzione generale CONNECT.

I poteri istruttori della Commissione

Il Capo IX del Regolamento, nella sezione dedicata alla vigilanza sui modelli per finalità generali, attribuisce alla Commissione un ventaglio di strumenti che è utile dettagliare. Il primo, e il meno invasivo, è per l’appunto la richiesta di informazioni: la Commissione può domandare al fornitore del modello di trasmettere la documentazione redatta ai sensi degli obblighi che il Regolamento gli impone, nonché ogni ulteriore informazione necessaria a valutare la conformità. Il secondo strumento è la valutazione del modello, che può essere condotta anche mediante esperti indipendenti e che può comprendere prove sperimentali, incluso il cosiddetto “red teaming” per i modelli con rischio sistemico. Il terzo è il potere di richiedere misure correttive, sino alla richiesta di ritiro del modello dal mercato. Il quarto, infine, è il potere sanzionatorio, che per i fornitori di modelli per finalità generali il Regolamento configura con un massimale del tre per cento del fatturato mondiale totale annuo dell’esercizio precedente o di quindici milioni di euro, se superiore.

Appare chiaro allo scrivente che la sequenza non è casuale. La richiesta di informazioni è collocata a monte proprio perché assolve una funzione conoscitiva e, in una certa misura, pedagogica: consente all’amministrazione di formarsi un quadro dello stato dell’arte del mercato prima di attivare strumenti più incisivi, e consente al fornitore di rappresentare la propria posizione in una fase in cui nessuna contestazione è stata formalizzata. Trattasi di una tecnica regolatoria nota, già sperimentata nell’applicazione del Regolamento (UE) 2022/2065 (Digital Services Act), dove le richieste di informazioni ai fornitori di piattaforme online di dimensioni molto grandi hanno preceduto, in più occasioni, l’apertura di procedimenti formali.

Va detto, per completezza, che la natura non accusatoria della richiesta di informazioni non ne attenua la rilevanza giuridica. Il Regolamento prevede che la comunicazione di informazioni inesatte, incomplete o fuorvianti in risposta a una richiesta della Commissione possa essere sanzionata. Di conseguenza, il fornitore che riceve una richiesta di informazioni non si trova in una fase di cortesia istituzionale, ma in un procedimento amministrativo che produce effetti e nel quale la qualità della risposta assume valore probatorio.

Il calendario applicativo e il punto in cui ci troviamo

Il Regolamento (UE) 2024/1689 è entrato in vigore il 1° agosto 2024 e ha previsto un’applicazione scaglionata. Le disposizioni del Capo I e del Capo II — dunque le definizioni, l’obbligo di alfabetizzazione in materia di IA e il divieto delle pratiche di intelligenza artificiale inaccettabili — hanno trovato applicazione a partire dal 2 febbraio 2025. Le disposizioni relative ai modelli di IA per finalità generali, alla governance, alle autorità di notifica e alle sanzioni sono divenute applicabili il 2 agosto 2025. Il grosso della disciplina sui sistemi ad alto rischio segue una tempistica ulteriormente differita a norma del c.d. “Digital Omnibus”.

Ne consegue che, al momento in cui la Commissione ha avviato le prime richieste di informazioni, il corpo di obblighi già pienamente esigibile nei confronti dei fornitori di modelli era quello del Capo V: documentazione tecnica del modello, informazioni da mettere a disposizione dei fornitori a valle che integrano il modello nei propri sistemi, politica di conformità alla disciplina sul diritto d’autore, sintesi sufficientemente dettagliata dei contenuti utilizzati per l’addestramento. Per i modelli qualificati come aventi rischio sistemico si aggiungono la valutazione del modello, la valutazione e mitigazione dei rischi sistemici, la segnalazione degli incidenti gravi e — profilo di specifico interesse in questa sede — la garanzia di un livello adeguato di protezione della cybersicurezza del modello e della relativa infrastruttura fisica.

Si ritiene che proprio quest’ultimo elemento consenta di leggere in modo coerente il riferimento, contenuto nella fonte, ai contatti della Commissione con due fornitori sui profili di sicurezza informatica. Non si ha evidenza del contenuto di tali interlocuzioni, e sarebbe improprio ipotizzarlo; si può però osservare che la cybersicurezza dei modelli con rischio sistemico non è un tema di opportunità industriale, bensì oggetto di un obbligo espresso del Regolamento, la cui violazione ricade nel perimetro dei poteri correttivi e sanzionatori della Commissione.

La cybersicurezza dei modelli: un obbligo autonomo che dialoga con altre discipline

Per quanto di stretto interesse in questa sede, merita approfondimento il rapporto fra l’obbligo di sicurezza dei modelli previsto dall’AI Act e le altre discipline europee che, con oggetti diversi, presidiano la medesima materia.

L’articolo 32 del Regolamento (UE) 2016/679 impone al titolare e al responsabile del trattamento di mettere in atto misure tecniche e organizzative adeguate per garantire un livello di sicurezza adeguato al rischio, tenendo conto — recita la norma — dello “stato dell’arte e dei costi di attuazione, nonché della natura, dell’oggetto, del contesto e delle finalità del trattamento, come anche del rischio di varia probabilità e gravità per i diritti e le libertà delle persone fisiche”. Si tratta di un obbligo funzionale alla tutela dei dati personali, che opera quando e nella misura in cui il modello o il sistema tratti dati riferibili a persone fisiche.

La Direttiva (UE) 2022/2555 (NIS2), recepita in Italia con il decreto legislativo 138/2024, impone ai soggetti essenziali e importanti misure di gestione dei rischi per la sicurezza informatica e obblighi di notifica degli incidenti significativi, con un perimetro soggettivo definito per settori e dimensioni. Anche in questo caso l’obbligo è distinto: presidia la continuità e l’integrità dei servizi, non la protezione dei dati in quanto tali né la sicurezza del modello di IA in quanto tale.

Il Regolamento (UE) 2022/2554 (DORA), per il settore finanziario, aggiunge un ulteriore strato con specifico riguardo alla resilienza operativa digitale e alla gestione del rischio derivante da fornitori terzi di servizi ICT; il Regolamento (UE) 2024/2847 (Cyber Resilience Act), infine, introduce requisiti di sicurezza per i prodotti con elementi digitali immessi sul mercato.

In termini più pragmatici, ciò significa che un medesimo evento — poniamo, una compromissione dell’infrastruttura che ospita un modello, con esfiltrazione di conversazioni degli utenti — può contemporaneamente integrare una violazione di dati personali notificabile ai sensi degli articoli 33 e 34 del GDPR, un incidente significativo ai sensi della NIS2 per il soggetto che eroga il servizio, un incidente grave rilevante ai fini dell’AI Act per il fornitore del modello con rischio sistemico e, per un intermediario finanziario che di quel servizio si avvalga, un incidente da gestire secondo le procedure DORA. Le autorità competenti sono diverse, i termini di notifica sono diversi, i destinatari delle comunicazioni sono diversi.

Si ritiene che questo cumulo di regimi rappresenti uno dei nodi più delicati della fase attuale. La sovrapposizione non è un difetto di tecnica legislativa in senso stretto — ciascuna disciplina persegue un interesse proprio — ma produce, sul piano organizzativo, un onere di coordinamento che le strutture di compliance faticano ad assorbire. Nell’esperienza applicativa dei sistemi di gestione, la risposta più efficace consiste nel costruire un’unica procedura di rilevazione e classificazione degli eventi, dalla quale si dirami una matrice di obblighi di notifica differenziati; la costruzione di procedure parallele e indipendenti, per ciascun regime, si è spesso rivelata fonte di duplicazioni e di ritardi.

Che cosa significa “richiesta di informazioni” e perché il metodo conta più della notizia

Secondo il parere di chi scrive, il dato di maggiore interesse professionale nella vicenda riportata non è quantitativo — le “oltre trenta società” — bensì metodologico.

Una richiesta di informazioni è, nella sostanza, un atto con cui l’autorità domanda al destinatario di esibire documentazione che il destinatario avrebbe dovuto già formare in adempimento di obblighi normativi. La conformità, in questo modello, non si costruisce nel momento in cui arriva la richiesta: si dimostra sulla base di evidenze già formate. Chi ha documentato per tempo le proprie scelte è in grado di rispondere; chi non lo ha fatto si trova nella condizione di dover ricostruire ex post decisioni assunte mesi o anni prima, con evidenze frammentarie e con il rischio concreto che la ricostruzione appaia — a torto o a ragione — postuma.

Trattasi di una logica che i responsabili della protezione dei dati conoscono bene, perché coincide con quella del principio di responsabilizzazione sancito dall’articolo 5, paragrafo 2, del GDPR, secondo cui il titolare “è competente per il rispetto del paragrafo 1 e in grado di comprovarlo”. L’AI Act ne riproduce l’impianto, declinandolo attraverso obblighi documentali specifici: la documentazione tecnica, il sistema di gestione dei rischi, il sistema di gestione della qualità, le registrazioni automatiche degli eventi, le istruzioni per l’uso.

Inoltre, va segnalato un profilo che nella prassi viene sovente sottovalutato. La richiesta di informazioni non è necessariamente diretta soltanto ai fornitori. L’architettura del Regolamento consente alle autorità nazionali di vigilanza del mercato di rivolgersi anche ai deployer — cioè agli utilizzatori professionali — per verificare l’adempimento degli obblighi che a questi ultimi fanno capo: l’uso conforme alle istruzioni del fornitore, l’assegnazione della sorveglianza umana a persone dotate di competenza e formazione adeguate, la conservazione dei log, l’informazione ai lavoratori quando il sistema è impiegato nel contesto lavorativo, la valutazione d’impatto sui diritti fondamentali nei casi in cui è prescritta.

Di conseguenza, l’organizzazione italiana che utilizza sistemi di intelligenza artificiale — anche soltanto acquistandoli come servizio — non può considerarsi spettatrice della fase di enforcement. Può esserne destinataria diretta, ovvero, più frequentemente, destinataria indiretta di richieste che il proprio fornitore le rivolge per poter a sua volta rispondere all’autorità.

L’assetto italiano della vigilanza e il raccordo con il Garante

Sul versante nazionale, l’Italia ha adottato una legge in materia di intelligenza artificiale — la legge 132/2025 — con la quale sono state dettate disposizioni di adeguamento e sono state individuate le autorità nazionali competenti ai fini dell’AI Act, con un ruolo riconosciuto all’Agenzia per l’Italia Digitale e all’Agenzia per la Cybersicurezza Nazionale, ferme restando le competenze delle autorità indipendenti nei rispettivi settori.

Non si ha evidenza, allo stato, di un quadro applicativo pienamente consolidato quanto ai raccordi procedimentali fra le diverse autorità, e si ritiene che proprio qui si collochi una delle principali questioni aperte per gli operatori. Il punto è pratico prima ancora che teorico: un medesimo impiego di intelligenza artificiale — poniamo, un sistema di supporto alla selezione del personale — può richiamare simultaneamente la competenza dell’autorità di vigilanza del mercato ai sensi dell’AI Act, quella del Garante per la protezione dei dati personali per i profili di trattamento e di decisione automatizzata, e quella dell’Ispettorato nazionale del lavoro per i profili di controllo a distanza ai sensi dell’articolo 4 della legge 300/1970.

Il Garante per la protezione dei dati personali, del resto, si è già misurato con i sistemi di intelligenza artificiale generativa ben prima che l’AI Act divenisse applicabile, utilizzando gli strumenti del GDPR: la base giuridica del trattamento per l’addestramento, l’informativa agli interessati, l’esercizio dei diritti, l’esattezza dei dati generati in output, la tutela dei minori. Anche il Comitato europeo per la protezione dei dati è intervenuto con il parere 28/2024 sul trattamento di dati personali nel contesto dei modelli di intelligenza artificiale, affrontando fra l’altro la questione dell’anonimato dei modelli e le condizioni per il ricorso al legittimo interesse quale base giuridica.

Appare chiaro allo scrivente che, per il DPO, il messaggio più utile che si ricava dalla notizia commentata sia il seguente: l’ingresso in scena dell’AI Act non sposta in alcun modo il baricentro degli obblighi derivanti dal GDPR, e non introduce alcuna forma di specialità che consenta di considerare assorbiti gli adempimenti in materia di protezione dei dati. Le due discipline si sommano. Il Regolamento (UE) 2024/1689 lo dichiara del resto espressamente, precisando di non pregiudicare l’applicazione della normativa dell’Unione in materia di protezione dei dati personali.

Profili critici

Diversi aspetti della fase inaugurale dell’enforcement meritano, secondo il parere di chi scrive, un esame problematico, formulato con la cautela che l’assenza di elementi pubblici impone.

Il primo profilo attiene alla trasparenza del procedimento. La scelta della Commissione di non divulgare l’identità delle società destinatarie è, sul piano giuridico, difendibile: nella fase istruttoria la pubblicità nominativa può pregiudicare tanto l’efficacia dell’accertamento quanto la reputazione di soggetti nei cui confronti nessuna contestazione è stata mossa. Al contempo, si ritiene che una qualche forma di rendicontazione aggregata — sui temi oggetto delle richieste, sulle categorie di modelli coinvolti, sui criteri di selezione dei destinatari — avrebbe una funzione orientativa per il mercato. Nell’esperienza applicativa, gli operatori tendono ad allineare le proprie prassi ai segnali che ricevono dall’autorità; un’istruttoria interamente riservata produce, inevitabilmente, un effetto di orientamento assai più debole. Va detto, per equilibrio, che la Commissione ha in altre occasioni pubblicato comunicazioni sull’avvio di procedimenti formali, e non si ha evidenza che intenda derogare a tale prassi qualora l’istruttoria evolva.

Il secondo profilo riguarda l’asimmetria informativa fra fornitori e utilizzatori. L’AI Act impone al fornitore del modello per finalità generali di mettere a disposizione dei fornitori a valle informazioni e documentazione sufficienti a consentire loro di comprendere capacità e limiti del modello e di adempiere ai propri obblighi. Nella prassi contrattuale osservabile, tuttavia, tali informazioni sono spesso veicolate attraverso documentazione tecnica standardizzata, non negoziabile e soggetta a modifica unilaterale. Si ritiene che ciò ponga un problema non trascurabile per il deployer europeo, il quale deve fondare le proprie valutazioni di rischio su rappresentazioni che non è in grado di verificare autonomamente e che possono mutare senza preavviso significativo. La questione, peraltro, non è nuova: la si è già incontrata nella qualificazione dei ruoli privacy nei servizi cloud, dove la standardizzazione delle condizioni ha di fatto compresso lo spazio delle istruzioni documentate del titolare.

Il terzo profilo concerne la sostenibilità dell’onere documentale per le organizzazioni di dimensioni medio-piccole. Il Regolamento contiene misure di alleggerimento per le piccole e medie imprese e per le start-up, e prevede spazi di sperimentazione regolamentare; ciò nondimeno, la costruzione di un sistema di gestione dei rischi, di una documentazione tecnica adeguata e di procedure di sorveglianza umana richiede competenze che non sono diffuse. Si suggerisce di non sottovalutare il rischio che la conformità si riduca, per queste realtà, a un adempimento formale — l’adozione di una policy generica, la sottoscrizione di una dichiarazione del fornitore — privo di reale capacità di governo del rischio. Non si tratta di una critica alle imprese, ma della segnalazione di un problema strutturale di allocazione delle competenze.

Il quarto profilo, infine, riguarda il rapporto fra vigilanza accentrata sui modelli e vigilanza nazionale sui sistemi. La separazione è nitida sulla carta, meno nella realtà applicativa, dove un sistema ad alto rischio può essere costruito integrando un modello per finalità generali di terzi, con il risultato che l’accertamento di una carenza a monte incide sulla conformità a valle. Si ritiene che il coordinamento fra la Commissione, il consiglio per l’intelligenza artificiale e le autorità nazionali su questi casi di confine costituisca una delle prove più impegnative dell’architettura di governance del Regolamento, e che l’esito dipenderà in misura rilevante da prassi che allo stato non sono ancora formate.

Che cosa devono fare, in concreto, DPO e imprese

Muovendo dal quadro sin qui ricostruito, si espongono le attività che appare opportuno intraprendere, con l’avvertenza che l’ordine di esposizione riflette una priorità logica e non necessariamente cronologica.

Il punto di partenza è la ricognizione dei sistemi di intelligenza artificiale effettivamente in uso nell’organizzazione. Trattasi di un’attività meno banale di quanto appaia, perché la diffusione di funzionalità di IA integrate in applicativi già in dotazione — suite di produttività, gestionali, strumenti di assistenza alla scrittura, sistemi di analisi documentale — fa sì che l’organizzazione utilizzi intelligenza artificiale anche senza avere mai deliberato di acquistarla. Si suggerisce di condurre la ricognizione partendo dal registro delle attività di trattamento tenuto ai sensi dell’articolo 30 del GDPR e dall’inventario degli asset e dei contratti ICT, incrociando le due fonti e verificando, per ciascun applicativo, se il fornitore abbia introdotto componenti di IA in aggiornamenti successivi alla stipula. L’esito della ricognizione dovrebbe confluire in un repertorio stabile e aggiornato, e non in un documento una tantum.

Alla ricognizione segue la qualificazione del ruolo rivestito dall’organizzazione rispetto a ciascun sistema. L’AI Act distingue fra fornitore, deployer, importatore, distributore e rappresentante autorizzato, e associa a ciascuna figura obblighi differenti. Va prestata particolare attenzione a un meccanismo che nella prassi genera sorprese: chi appone il proprio nome o marchio su un sistema ad alto rischio già immesso sul mercato, chi ne modifica in modo sostanziale la finalità o chi apporta modifiche sostanziali al sistema può assumere gli obblighi del fornitore. In termini più concreti, l’impresa che personalizzi in profondità un modello di terzi, o che lo integri in un proprio prodotto destinato al mercato, potrebbe scoprire di non essere più un semplice utilizzatore. Si ritiene che questa verifica vada condotta con il concorso delle funzioni tecniche e non affidata alla sola area legale.

Va poi affrontata la classificazione del rischio di ciascun sistema secondo le categorie del Regolamento: pratiche vietate, sistemi ad alto rischio, sistemi soggetti a obblighi di trasparenza, sistemi a rischio minimo. La classificazione dei sistemi ad alto rischio si fonda sull’allegato III e sui casi di componenti di sicurezza di prodotti già soggetti a normativa di armonizzazione; per il pubblico di questa rivista assumono particolare rilievo gli impieghi nell’occupazione e nella gestione dei lavoratori, nell’accesso a servizi essenziali pubblici e privati, nella valutazione del merito creditizio e nell’istruzione. Si suggerisce di documentare non soltanto l’esito della classificazione, ma anche il ragionamento che vi ha condotto, comprese le ipotesi scartate: nell’ottica di una futura richiesta di informazioni, la motivazione vale quanto la conclusione.

Sul piano contrattuale, si rende necessaria una revisione degli accordi con i fornitori di sistemi e servizi basati su intelligenza artificiale. Si suggerisce di verificare la presenza di impegni espressi sulla conformità del prodotto all’AI Act, sulla messa a disposizione della documentazione tecnica e delle istruzioni per l’uso, sulla comunicazione tempestiva delle modifiche sostanziali al sistema o al modello sottostante, sulla cooperazione in caso di richieste delle autorità e sulla notifica degli incidenti. Va inoltre coordinata questa revisione con l’accordo sul trattamento dei dati stipulato ai sensi dell’articolo 28 del GDPR, verificando in particolare se e in quale misura i dati inseriti dagli utenti siano utilizzati per il riaddestramento del modello, questione che incide tanto sulla base giuridica quanto sulla riservatezza delle informazioni aziendali.

Quanto agli obblighi già pienamente esigibili, merita attenzione prioritaria l’alfabetizzazione in materia di intelligenza artificiale prevista dall’articolo 4 del Regolamento, in forza del quale fornitori e deployer adottano misure per garantire un livello sufficiente di alfabetizzazione del proprio personale e delle altre persone che si occupano del funzionamento e dell’utilizzo dei sistemi per loro conto. Si ritiene che l’obbligo non si esaurisca nell’erogazione di un corso: la norma richiede un livello di competenza commisurato al contesto e ai rischi, il che implica percorsi differenziati fra chi utilizza un assistente conversazionale per attività di supporto e chi esercita la sorveglianza umana su un sistema che incide su posizioni giuridiche di terzi. La tracciabilità dell’attività formativa — contenuti, destinatari, verifica dell’apprendimento — costituisce evidenza documentale spendibile.

Va poi presidiata la sorveglianza umana, che il Regolamento configura non come approvazione formale dell’output ma come capacità effettiva di comprendere il funzionamento del sistema, di interpretarne correttamente i risultati, di discostarsene e di interromperne il funzionamento. Si suggerisce di designare per iscritto le persone incaricate, di dotarle di istruzioni operative concrete e — profilo spesso trascurato — di assicurare loro il tempo e l’autorità organizzativa necessari per esercitare un controllo reale. Nell’esperienza applicativa dei sistemi di gestione, la sorveglianza umana meramente nominale è una delle debolezze che emergono con maggiore frequenza in sede di audit.

Sul versante della protezione dei dati, resta centrale la valutazione d’impatto ai sensi dell’articolo 35 del GDPR, da condurre ogniqualvolta il trattamento connesso all’impiego del sistema presenti un rischio elevato per i diritti e le libertà degli interessati. Si ritiene opportuno che tale valutazione, pur mantenendo la propria autonomia metodologica e la propria finalità, sia condotta in modo integrato con la valutazione d’impatto sui diritti fondamentali prescritta dall’AI Act per determinati deployer di sistemi ad alto rischio, evitando duplicazioni di analisi e disallineamenti fra documenti che descrivono il medesimo trattamento. Il coinvolgimento del responsabile della protezione dei dati, ai sensi dell’articolo 39, paragrafo 1, lettera c), del GDPR, va documentato e non presunto.

Occorre inoltre disciplinare la gestione degli incidenti in modo unitario, come già osservato. Si suggerisce di predisporre una procedura unica di rilevazione, con una fase di classificazione che accerti simultaneamente se l’evento costituisca violazione di dati personali ai sensi dell’articolo 4, punto 12, del GDPR, incidente significativo ai sensi della disciplina NIS2, incidente grave rilevante ai fini dell’AI Act o evento soggetto ad altri obblighi settoriali, e con una fase di attivazione che dirami le notifiche verso le rispettive autorità nei termini propri di ciascun regime. La procedura dovrebbe individuare nominativamente i soggetti responsabili di ciascun passaggio ed essere sottoposta a prove periodiche, poiché un percorso di escalation mai collaudato tende a non funzionare quando serve.

Va altresì curata la conservazione dei log e delle registrazioni automatiche generate dai sistemi, che il Regolamento impone ai deployer di sistemi ad alto rischio per un periodo adeguato alla finalità del sistema. Si segnala che tale obbligo va coordinato con il principio di limitazione della conservazione di cui all’articolo 5, paragrafo 1, lettera e), del GDPR e, laddove i log siano riferibili a lavoratori, con i limiti posti dall’articolo 4 della legge 300/1970 in materia di controlli a distanza: la finalità di tracciabilità del funzionamento del sistema non legittima, di per sé, l’utilizzo dei medesimi dati a fini disciplinari o valutativi.

Sul piano dell’informazione, si rende necessario aggiornare l’informativa agli interessati ai sensi degli articoli 13 e 14 del GDPR quando il trattamento comporta l’impiego di sistemi di intelligenza artificiale, con particolare riguardo alle ipotesi di processo decisionale automatizzato di cui all’articolo 22, per le quali è dovuta l’indicazione della logica utilizzata, dell’importanza e delle conseguenze previste. Va inoltre assolto, ove ricorrano i presupposti, l’obbligo di trasparenza previsto dall’AI Act nei confronti delle persone fisiche che interagiscono con un sistema di IA e l’obbligo di marcatura dei contenuti sinteticamente generati o manipolati.

Nel contesto lavorativo, si suggerisce di gestire con attenzione il rapporto con le rappresentanze sindacali. L’AI Act prevede che i deployer datori di lavoro informino i lavoratori e i loro rappresentanti prima di mettere in servizio un sistema ad alto rischio sul luogo di lavoro; tale obbligo si aggiunge — e non si sostituisce — alle procedure di accordo o autorizzazione previste dall’articolo 4 della legge 300/1970 per gli strumenti dai quali derivi la possibilità di controllo a distanza, nonché agli obblighi informativi in materia di sistemi decisionali o di monitoraggio automatizzati previsti dalla normativa nazionale sulla trasparenza delle condizioni di lavoro.

Da ultimo, e trasversalmente, si raccomanda la costruzione di un sistema documentale di responsabilizzazione che consenta di rispondere, in tempi ragionevoli, a una richiesta di informazioni di un’autorità. In termini pragmatici, ciò significa che per ogni sistema rilevante l’organizzazione dovrebbe essere in grado di esibire: la scheda del sistema con finalità e classificazione, il contratto e la documentazione del fornitore, la valutazione dei rischi, la designazione dei sorveglianti umani, le evidenze formative, l’informativa resa agli interessati, i log conservati e il registro degli incidenti. Si ritiene che il criterio di adeguatezza sia semplice da enunciare e severo da soddisfare: la documentazione è adeguata quando un soggetto terzo, estraneo all’organizzazione, ne ricava una comprensione fedele di che cosa il sistema faccia e di come sia governato.

Conclusioni

L’avvio delle richieste di informazioni da parte della Commissione europea segna il passaggio dell’AI Act dalla fase dell’attesa a quella dell’applicazione, ma lo fa nella forma più cauta fra quelle disponibili. Non vi sono, allo stato, contestazioni pubbliche, procedimenti formali noti o provvedimenti correttivi dei quali si abbia evidenza; vi è, piuttosto, un’attività conoscitiva che consente all’amministrazione europea di misurare la distanza fra il testo del Regolamento e le prassi effettive del mercato.

Restano aperte questioni che l’esperienza dei prossimi mesi dovrà chiarire. La prima riguarda i criteri con cui la Commissione selezionerà i casi da approfondire oltre la fase istruttoria e la misura in cui renderà pubblici gli orientamenti che ne deriveranno: dalla risposta dipende la capacità del sistema di produrre certezza applicativa. La seconda concerne il coordinamento fra la vigilanza accentrata sui modelli per finalità generali e la vigilanza nazionale sui sistemi, in particolare nei casi in cui una carenza del modello a monte si rifletta sulla conformità dei sistemi a valle costruiti da soggetti diversi: si tratta di un’ipotesi tutt’altro che teorica, sulla quale non si ha evidenza di prassi consolidate. La terza attiene all’assetto italiano e ai raccordi procedimentali fra le autorità nazionali designate ai sensi della legge 132/2025 e il Garante per la protezione dei dati personali, la cui competenza sui profili di trattamento resta impregiudicata: la sovrapposizione di accertamenti su un medesimo impiego di intelligenza artificiale richiederà forme di cooperazione che allo stato non risultano compiutamente definite.

Vi è, infine, una questione di sostanza che eccede il piano procedimentale. L’AI Act è stato costruito su un modello di conformità documentale mutuato dalla disciplina della sicurezza dei prodotti, e tale modello presuppone che la documentazione rifletta fedelmente il comportamento del sistema. Nel caso dei modelli di grandi dimensioni, la relazione fra documentazione e comportamento effettivo è meno diretta di quanto accada per un macchinario o un dispositivo medico, poiché le capacità emergenti e i mutamenti indotti da aggiornamenti successivi possono modificare il profilo di rischio in modo non interamente prevedibile al momento della redazione della documentazione. Si ritiene che la tenuta dell’impianto regolatorio dipenderà, in ultima analisi, dalla capacità delle autorità di affiancare alla verifica documentale forme di valutazione sostanziale dei modelli, e dalla disponibilità di competenze tecniche adeguate presso l’AI Office e presso le autorità nazionali. Le richieste di informazioni inviate a oltre trenta società rappresentano, sotto questo profilo, il primo esercizio di una funzione destinata a consolidarsi nella prassi applicativa.

Riferimenti normativi

• Regolamento (UE) 2016/679 (GDPR)
• Regolamento (UE) 2022/2554 (DORA)
• Regolamento (UE) 2022/2065 (Digital Services Act)
• Regolamento (UE) 2024/1689 (AI Act)
• Regolamento (UE) 2024/2847 (Cyber Resilience Act)
• Direttiva (UE) 2022/2555 (NIS2)
• legge 20 maggio 1970, n. 300
• decreto legislativo 4 settembre 2024, n. 138
• legge 23 settembre 2025, n. 132
• Parere del Comitato europeo per la protezione dei dati 28/2024