Nella nostra precedente analisi abbiamo esaminato chi si qualifica come deployer ai sensi dell’AI Act, quali obblighi si applichino effettivamente e cosa abbia chiarito la Commissione europea riguardo agli AI agents. Il quadro, tuttavia, sarebbe incompleto senza affrontare l’altra faccia della questione: le circostanze in cui un’organizzazione che utilizza un AI agent può trovarsi riqualificata come fornitore (provider) — con un insieme di obblighi radicalmente diverso.
Non si tratta di uno scenario teorico. Man mano che gli AI agents vengono personalizzati, integrati in flussi di lavoro aziendali e ridistribuiti sotto nuovi marchi, il confine tra utilizzare e fornire diventa operativamente critico. L’AI Act affronta questa questione attraverso un meccanismo preciso: l’articolo 25, che stabilisce le condizioni in cui un deployer viene trattato come un provider.
Ci riferiamo a questa situazione come quella del “provider involontario” — non come categoria normativa, ma come categoria descrittiva. Essa coglie la realtà pratica di organizzazioni che assumono gli obblighi del fornitore senza averlo inteso e, spesso, senza esserne consapevoli.
Le tre porte della riqualificazione ai sensi dell’Art. 25
L’articolo 25, paragrafo 1, del Regolamento (UE) 2024/1689 individua tre scenari in cui un soggetto diverso dal fornitore originario viene trattato come fornitore di un sistema di IA ad alto rischio e assume gli obblighi del fornitore relativi ai sistemi di IA ad alto rischio, che includono il rispetto dei requisiti del Capo III e delle pertinenti procedure di conformità:
(a) Apposizione del marchio. Il soggetto appone il proprio nome o marchio su un sistema di IA ad alto rischio già immesso sul mercato o messo in servizio. È il meccanismo più lineare: se si presenta il sistema come proprio, l’AI Act tratta quel soggetto come fornitore — indipendentemente dal fatto che lo abbia sviluppato o modificato.
(b) Modifica sostanziale. Il soggetto apporta una modifica sostanziale a un sistema di IA ad alto rischio in modo tale che esso rimanga un sistema ad alto rischio. L’articolo 3, punto 23, definisce la modifica sostanziale come una modifica del sistema di IA successivamente alla sua immissione sul mercato o messa in servizio, non prevista né pianificata dal fornitore, a seguito della quale la conformità del sistema ai requisiti applicabili è compromessa oppure la finalità prevista per la quale il sistema è stato valutato è modificata.
(c) Cambio della finalità prevista. Il soggetto modifica la finalità prevista di un sistema di IA — ivi incluso un sistema di IA per finalità generali — che non era classificato come ad alto rischio, in modo tale che il sistema diventi un sistema ad alto rischio ai sensi dell’Allegato III.
È essenziale osservare che questo meccanismo opera esclusivamente nel dominio dei sistemi di IA ad alto rischio. Un deployer che personalizza un sistema a rischio minimo o limitato non attiva la riqualificazione di cui all’art. 25 — sebbene altri obblighi possano comunque applicarsi (ad es. la trasparenza ai sensi dell’art. 50, o gli obblighi relativi ai modelli GPAI ai sensi degli artt. 51–56).
Dove le organizzazioni sbagliano
Il meccanismo di riqualificazione dell’art. 25 è preciso, ma le sue implicazioni pratiche sono spesso fraintese. Gli scenari che seguono illustrano dove le organizzazioni possono inavvertitamente oltrepassare il confine tra deployer e provider nell’utilizzo di AI agents. Ciascuno scenario è analizzato in relazione alle disposizioni normative applicabili.
Fine-tuning e retraining
Un’organizzazione che effettua il fine-tuning di un AI agent su dati proprietari per modificarne il comportamento in un contesto settoriale specifico potrebbe realizzare una modifica sostanziale ai sensi dell’art. 3, punto 23. La questione cruciale non è se il fine-tuning sia avvenuto, ma se esso incida sulla conformità del sistema ai requisiti applicabili o ne modifichi la finalità prevista. Un aggiustamento leggero dei parametri, entro i limiti previsti dal fornitore originario, generalmente non costituisce modifica sostanziale. Un retraining significativo che alteri gli output del sistema, il suo profilo di rischio o il suo dominio di applicazione potrebbe invece esserlo.
Orchestrazione di sistemi multi-agent
Quando un’organizzazione utilizza più AI agents in un flusso di lavoro coordinato — in cui l’output di un agente costituisce l’input di un altro e il comportamento complessivo del sistema è determinato dalla logica di orchestrazione anziché dal singolo agente — ci si deve interrogare se il sistema composito costituisca un nuovo sistema di IA distinto dai suoi componenti.
Si tratta di una questione interpretativa che l’AI Act non affronta esplicitamente. A mio avviso, la risposta dipende dalle circostanze specifiche: chi esercita il controllo progettuale sull’architettura composita, se il sistema risultante abbia una finalità prevista distinta da quella dei suoi singoli componenti, e se il suo comportamento complessivo — incluse le proprietà emergenti derivanti dall’interazione tra agenti — dia luogo a un profilo di rischio che i fornitori originari non avevano previsto né valutato.
Se tali condizioni sono soddisfatte e il sistema orchestrato opera in un dominio ad alto rischio (ad es. valutazione del merito creditizio, reclutamento, supporto decisionale clinico), l’organizzazione che progetta e controlla l’orchestrazione potrebbe, in linea di principio, essere trattata come il fornitore di tale sistema composito. Si tratta tuttavia di una valutazione caso per caso che richiede un’analisi attenta dell’architettura del sistema, della sua governance e della finalità prevista.
White-labelling e rebranding
È lo scenario più lineare. L’art. 25, paragrafo 1, lettera a), è esplicito: l’apposizione del proprio nome o marchio su un sistema di IA ad alto rischio già sul mercato determina la riqualificazione. Un’organizzazione che acquisisce in licenza un AI agent, lo ridistribuisce con il proprio marchio e lo offre ai propri clienti è, ai fini dell’AI Act, il fornitore di quel sistema — con tutti gli obblighi corrispondenti.
Verticalizzazione settoriale
Un’organizzazione che utilizza un AI agent per finalità generali e lo adatta per l’impiego in un settore specifico elencato nell’Allegato III — come sanità, istruzione, occupazione, attività di contrasto o accesso a servizi essenziali — potrebbe modificarne la finalità prevista in modo da farlo rientrare nella classificazione ad alto rischio. Ciò attiva l’art. 25, paragrafo 1, lettera c): il sistema non era classificato come ad alto rischio, ma la sua nuova finalità prevista lo rende tale.
Integrazione in prodotti o servizi propri
Quando un AI agent è incorporato in un prodotto o servizio e offerto a terzi, l’organizzazione che controlla l’integrazione — determinando come l’agente interagisce con gli utenti, quali dati tratta, quali azioni può compiere — potrebbe essere il soggetto che definisce la finalità prevista del sistema risultante. Se tale finalità ricade nell’Allegato III, l’organizzazione è il fornitore.
La questione dell’open source
Un equivoco diffuso merita attenzione specifica. L’AI Act prevede un regime differenziato per l’IA open source, ma ciò non equivale a un’esenzione generalizzata. È importante distinguere tra due regimi separati.
Sistemi di IA open source. L’articolo 2, paragrafo 12, esenta i sistemi di IA rilasciati con licenze libere e open source da determinati obblighi — a meno che il sistema sia un sistema ad alto rischio (Allegato III) o un sistema vietato (art. 5). In altri termini, l’esenzione open source non si applica ai sistemi ad alto rischio. Un’organizzazione che utilizza un framework AI agent open source, lo sviluppa ulteriormente e lo impiega in un contesto ad alto rischio non può fare affidamento su questa esenzione. Potrebbe ben essere un fornitore ai sensi dell’art. 25.
Modelli GPAI open source. Un regime separato e distinto si applica ai modelli di IA per finalità generali. L’art. 53, paragrafo 2, prevede un’esenzione parziale da determinati obblighi di trasparenza per i fornitori di modelli GPAI rilasciati con licenze open source — ma tale esenzione decade integralmente se il modello è classificato come a rischio sistemico ai sensi dell’art. 51. Si tratta di un piano giuridico diverso dalla riqualificazione ex art. 25, ma è rilevante per le organizzazioni che costruiscono AI agents su modelli di fondazione open source: l’esenzione parziale per il modello sottostante non protegge il sistema a valle dagli obblighi relativi ai sistemi ad alto rischio.
Una precisazione necessaria
Non ogni utilizzo avanzato di un AI agent determina la riqualificazione. Il meccanismo dell’AI Act è preciso e condizionato. La personalizzazione che resta nei parametri previsti e documentati dal fornitore originario, la configurazione di impostazioni esplicitamente offerte come opzioni per il deployer e l’utilizzo del sistema per la sua finalità dichiarata — tutto ciò rimane nel perimetro del deployer.
Il rischio non sta nell’usare gli AI agents, ma nel modificarli — o nel modificarne il contesto d’uso — oltre i limiti che il fornitore originario aveva previsto, senza riconoscerne le conseguenze giuridiche.
Tabella decisionale: deployer o provider?
La tabella che segue associa scenari operativi comuni alla loro probabile qualificazione giuridica ai sensi dell’AI Act. È concepita come strumento di orientamento pratico — non come sostituto di un’analisi giuridica caso per caso, che deve tenere conto delle caratteristiche specifiche del sistema, della natura della modifica e della finalità prevista.
| # | Scenario | Qualificazione probabile | Riferimento normativo |
|---|---|---|---|
| 1 | Utilizzo dell'AI agent così com'è, senza modifiche, per la finalità prevista | Deployer | Art. 3(4) |
| 2 | Configurazione dei parametri entro le opzioni documentate e previste dal fornitore | Deployer | Art. 3(4); Art. 25 a contrario |
| 3 | Fine-tuning leggero su dati proprietari senza alterare le funzionalità core o il profilo di rischio del sistema | Zona grigia — necessaria valutazione caso per caso | Art. 3(23); Art. 25(1)(b) |
| 4 | Retraining o fine-tuning significativo che modifica il comportamento, gli output o il profilo di rischio del sistema | Probabile riqualificazione come provider | Art. 3(23); Art. 25(1)(b) |
| 5 | Distribuzione dell'AI agent con il proprio nome o marchio | Provider | Art. 25(1)(a) |
| 6 | Adattamento di un agent per finalità generali per l'uso in un settore dell'Allegato III (es. sanità, reclutamento, istruzione) | Provider | Art. 25(1)(c) |
| 7 | Orchestrazione di più agenti in un sistema composito multi-step operante in un dominio ad alto rischio | Zona grigia — dipende dal controllo progettuale, dalla finalità prevista distinta e dal fatto che il sistema composito costituisca un nuovo sistema di IA | Art. 3(1); Art. 3(23); Art. 25(1)(b)/(c) |
| 8 | Utilizzo di un framework AI agent open source in un contesto ad alto rischio (Allegato III) | Probabile provider — nessuna esenzione automatica open source per i sistemi ad alto rischio | Art. 2(12); Art. 25 |
Questa tabella è concepita come strumento di orientamento pratico e non sostituisce la qualificazione giuridica caso per caso, che deve tenere conto delle caratteristiche specifiche del sistema, della natura della modifica e della finalità prevista concreta.
Cosa cambia quando scatta la riqualificazione: checklist degli obblighi del provider
Quando la riqualificazione è attivata ai sensi dell’art. 25, l’organizzazione assume l’intero insieme degli obblighi del fornitore per i sistemi di IA ad alto rischio stabiliti nel Capo III, Sezione 2, dell’AI Act (articoli da 9 a 22). La checklist che segue sintetizza i requisiti principali.
| # | Obbligo | Cosa comporta | Rif. normativo |
|---|---|---|---|
| 1 | Sistema di gestione dei rischi | Istituire e mantenere un processo continuo e iterativo di gestione dei rischi per l'intero ciclo di vita del sistema | Art. 9 |
| 2 | Governance dei dati | Garantire che i dati di addestramento, validazione e test soddisfino criteri di qualità: pertinenza, rappresentatività, accuratezza, completezza | Art. 10 |
| 3 | Documentazione tecnica | Redigere e mantenere aggiornata la documentazione tecnica che dimostri la conformità, prima dell'immissione del sistema sul mercato | Art. 11 |
| 4 | Conservazione dei registri (logging) | Progettare il sistema in modo da consentire la registrazione automatica degli eventi rilevanti per la tracciabilità | Art. 12 |
| 5 | Trasparenza e informazione | Garantire che il sistema sia progettato per consentire ai deployer di interpretare gli output e utilizzare il sistema in modo appropriato; fornire istruzioni per l'uso | Art. 13 |
| 6 | Sorveglianza umana | Progettare il sistema in modo che possa essere efficacemente sorvegliato da persone fisiche durante il periodo di utilizzo | Art. 14 |
| 7 | Accuratezza, robustezza e cybersecurity | Garantire livelli adeguati di accuratezza, robustezza e protezione dalle minacce alla sicurezza per l'intero ciclo di vita | Art. 15 |
| 8 | Sistema di gestione della qualità | Implementare un sistema documentato di gestione della qualità che copra politiche, procedure, strategie di conformità, gestione dei dati, conservazione dei registri e gestione delle risorse | Art. 17 |
| 9 | Valutazione di conformità | Effettuare la procedura di valutazione della conformità applicabile prima di immettere il sistema sul mercato o metterlo in servizio | Art. 43 |
| 10 | Registrazione nella banca dati UE | Registrare il sistema di IA ad alto rischio nella banca dati dell'UE prima della sua immissione sul mercato o messa in servizio | Art. 49 |
| 11 | Monitoraggio post-commercializzazione | Istituire e documentare un sistema proporzionato di monitoraggio successivo all'immissione sul mercato per raccogliere e analizzare dati sulle prestazioni del sistema durante il suo ciclo di vita | Art. 72 |
Il divario tra gli obblighi del deployer e quelli del provider è sostanziale. Un deployer di un sistema ad alto rischio deve garantire la sorveglianza umana, monitorare il sistema, conservare i registri e — ove applicabile — condurre una FRIA. Un provider deve fare tutto questo e, in aggiunta, costruire il sistema in modo che soddisfi tutti i requisiti essenziali fin dall’origine, istituire un sistema di gestione della qualità, produrre documentazione tecnica completa, effettuare una valutazione di conformità e predisporre un piano di monitoraggio post-commercializzazione. Si tratta di un salto qualitativo — dalla due diligence operativa alla piena responsabilità di sicurezza del prodotto.
Prime 5 azioni se emerge un rischio di riqualificazione come provider
2. Valutare se la modifica è sostanziale ai sensi dell'art. 3(23) — cioè se incide sulla conformità o altera la finalità prevista.
3. Verificare se lo scenario rientra nell'art. 25(1)(a), (b) o (c).
4. Sospendere l'immissione sul mercato, il rebranding o l'ulteriore distribuzione fino al completamento di una gap analysis.
5. Avviare un assessment su documentazione tecnica, gestione dei rischi e requisiti di conformità (artt. 9–17, 43).
Il rischio reale: l’errata classificazione giuridica del ruolo
Il rischio più insidioso per le organizzazioni che operano con AI agents non è tecnico ma giuridico: un’errata identificazione del proprio ruolo nella catena del valore dell’AI Act. Un’organizzazione che si ritiene deployer ma è, di fatto, un provider porta gli obblighi sbagliati — o nessun obbligo — e si espone ad azioni di vigilanza e a responsabilità senza la corrispondente infrastruttura di conformità.
Questo rischio è amplificato nel contesto degli AI agents da diversi fattori: l’architettura modulare dei sistemi agentici, che può oscurare il confine tra utilizzare e fornire; la facilità di personalizzazione, che può condurre a modifiche che superano la soglia dell’art. 25 senza una decisione deliberata in tal senso; l’ecosistema open source, dove l’assenza di costi di licenza può creare un falso senso di libertà regolatoria; e le catene multi-soggetto tipiche dell’impiego di AI agents, dove le responsabilità sono distribuite fra più attori e il ruolo di fornitore potrebbe non corrispondere in modo univoco ad alcun singolo soggetto.
Per il quadro analitico su come l’AI Act costruisce il proprio sistema di ruoli soggettivi e posizioni giuridiche, si rinvia al mio paper sui profili soggettivi nell’AI Act. Per l’architettura di compliance che i fornitori di AI agents devono implementare una volta verificatasi la riqualificazione, si veda Nannini et al., AI Agents Under EU Law (arXiv:2604.04604).
Risorse
Hub operativi
Gli Hub del blog forniscono strumenti interattivi di supporto decisionale — non articoli, ma risorse operative per identificare il proprio ruolo, mappare i propri obblighi e agire per tempo:
- AI Hub — Orientamento normativo e operativo — l’AI Act in chiave giuridica: trova il tuo ruolo, classifica il tuo sistema, individua i tuoi obblighi
- AI Act Hub — Ruoli degli operatori e obblighi — mappa dei sei operatori dell’AI Act, meccanismi di trasformazione del ruolo, cascata degli obblighi
- GDPR & AI Hub — Intersezioni operative — basi giuridiche per il trattamento dei dati nei sistemi di IA, decisioni automatizzate, DPIA, profilazione
Strumenti e risorse
- AI Act — GDPR Database — database interattivo delle corrispondenze tra AI Act e GDPR
- AI Compliance Tools — strumenti per la conformità IA
- Self-Assessment Tool — autovalutazione degli obblighi AI Act
- NicFab Newsletter — aggiornamento settimanale su privacy, protezione dati, IA e cybersecurity (ogni martedì)
Approfondimenti
- AI Act: deployer, AI agents e trasparenza — la prospettiva del deployer e il quadro operativo
- Code of Practice Art. 50: analisi del primo draft
- Digital Omnibus on AI: il Parlamento riscrive le regole della Commissione
- AI Act e legislazione digitale UE: complessità e sovrapposizioni
Nota conclusiva
La precisione normativa non è un esercizio accademico: è una responsabilità professionale. La questione non è se un’organizzazione si definisca deployer, ma se la sua condotta effettiva — le sue modifiche, il suo branding, il suo utilizzo del sistema — la collochi nella posizione di fornitore ai sensi dell’AI Act. Per molte organizzazioni che attualmente integrano AI agents nei propri prodotti e servizi, la risposta potrebbe essere meno confortevole del previsto.
Questo post fa parte della serie dedicata all’implementazione dell’AI Act. Per aggiornamenti in tempo reale, segui il blog e iscriviti alla NicFab Newsletter.