AI Act articolo 25: obblighi di fornitori e deployer in Italia (guida 2026)
L'articolo 25 del Regolamento (UE) 2024/1689, noto come AI Act, è probabilmente la disposizione più sottovalutata dell'intero impianto normativo. Mentre l'attenzione mediatica si è concentrata sul divieto delle pratiche vietate (articolo 5) e sui requisiti dei sistemi ad alto rischio (articoli 8-15), l'articolo 25 ridefinisce silenziosamente la catena di responsabilità lungo l'intera filiera dell'intelligenza artificiale. È la norma che, in pratica, decide chi paga quando qualcosa va storto.
Per le aziende italiane il tema non è teorico. Una pubblica amministrazione che adotta Microsoft Copilot, una banca che integra un modello GPT-4 di OpenAI nel proprio CRM, un'azienda manifatturiera che acquista un sistema di visione artificiale da un vendor tedesco: in ognuno di questi scenari l'articolo 25 stabilisce chi assume quale ruolo, quali obblighi sorgono, quando un deployer diventa fornitore e quali responsabilità si trasferiscono lungo la catena.
Questa guida operativa, aggiornata ad aprile 2026 con le scadenze in vigore, ricostruisce l'articolo 25 nel suo contesto: definizioni dell'articolo 3, obblighi reciproci tra fornitore, deployer, distributore e importatore, sanzioni applicabili in Italia, e tre casi pratici che illustrano la mappatura dei ruoli nella realtà operativa italiana.
Disclaimer. Questo documento ha finalità informative e non costituisce parere legale. Per l'applicazione concreta dell'AI Act al proprio caso aziendale è necessario il supporto di un avvocato specializzato in diritto digitale e protezione dati.
Le definizioni dell'articolo 3: chi è chi nella catena AI
Per leggere l'articolo 25 è indispensabile partire dall'articolo 3, che fornisce la mappa terminologica del Regolamento. Quattro figure governano l'intera filiera.
Fornitore (provider). L'articolo 3, paragrafo 3, definisce fornitore qualsiasi persona fisica o giuridica, autorità pubblica, agenzia o altro organismo che sviluppi un sistema di IA o un modello di IA per finalità generali, oppure lo faccia sviluppare, e lo immetta sul mercato dell'Unione o lo metta in servizio con il proprio nome o marchio commerciale, a titolo oneroso o gratuito. Il fornitore è il soggetto che porta il sistema sul mercato europeo. OpenAI con GPT-4, Anthropic con Claude, Microsoft con Copilot, Google con Gemini sono fornitori ai sensi del Regolamento.
Deployer (utilizzatore). L'articolo 3, paragrafo 4, definisce deployer la persona fisica o giuridica, autorità pubblica, agenzia o altro organismo che utilizzi un sistema di IA sotto la propria autorità, salvo il caso in cui il sistema sia utilizzato nel corso di un'attività personale non professionale. Il deployer è chi mette il sistema in produzione nel proprio contesto operativo. Una banca italiana che usa ChatGPT Enterprise per assistere il customer care è deployer. Un'agenzia delle entrate che adotta un sistema di scoring predittivo è deployer. Una PMI che integra Copilot in Microsoft 365 è deployer.
Distributore. L'articolo 3, paragrafo 7, identifica come distributore qualsiasi persona fisica o giuridica nella catena di approvvigionamento, diversa dal fornitore o dall'importatore, che metta a disposizione un sistema di IA sul mercato dell'Unione. Il distributore è l'intermediario commerciale: rivenditori, partner certificati, system integrator che vendono il sistema senza modificarlo sostanzialmente.
Importatore. L'articolo 3, paragrafo 6, definisce importatore qualsiasi persona fisica o giuridica stabilita nell'Unione che immetta sul mercato un sistema di IA recante il nome o il marchio di una persona fisica o giuridica stabilita in un paese terzo. L'importatore è il ponte tra fornitore extra-UE e mercato europeo. Microsoft Italia, OpenAI Ireland, Anthropic UK rispetto ai rispettivi prodotti rientrano in questa categoria a seconda della struttura societaria adottata.
La distinzione tra questi quattro ruoli non è statica. L'articolo 25 prevede esplicitamente meccanismi di trasformazione: un deployer può diventare fornitore, un distributore può ereditare obblighi del fornitore, un importatore può assumere responsabilità aggiuntive. È la dinamica che rende l'articolo 25 il vero centro di gravità del Regolamento.
Per un quadro più ampio sulle definizioni e sull'impianto generale rimandiamo alla guida completa all'AI Act per aziende italiane.
Articolo 25: la catena di responsabilità
L'articolo 25 disciplina la trasformazione dei ruoli lungo la catena del valore dell'IA. La rubrica della norma — "Responsabilità lungo la catena del valore dell'IA" — esprime l'intento del legislatore europeo: evitare che la complessità delle filiere consenta di disperdere le responsabilità.
Quando un deployer diventa fornitore
Il paragrafo 1 dell'articolo 25 stabilisce tre ipotesi in cui un soggetto inizialmente qualificato come distributore, importatore, deployer o terzo è considerato fornitore di un sistema di IA ad alto rischio ai fini del Regolamento e assume gli obblighi del fornitore previsti dall'articolo 16.
La prima ipotesi: appone il proprio nome o marchio commerciale su un sistema di IA ad alto rischio già immesso sul mercato o messo in servizio, fatti salvi accordi contrattuali che dispongano diversamente. È la classica situazione del white-label: un'azienda italiana acquista una piattaforma di scoring HR da un vendor estero, la rinomina con il proprio brand e la rivende. Salvo accordo contrattuale che mantenga in capo al vendor originario gli obblighi del fornitore, la responsabilità si trasferisce.
La seconda ipotesi: apporta una modifica sostanziale a un sistema di IA ad alto rischio già immesso sul mercato o messo in servizio in modo tale che resti un sistema di IA ad alto rischio a norma dell'articolo 6. Questa è l'ipotesi più insidiosa. Il considerando 84 e la prassi applicativa indicano che integrare un modello fondazionale nel proprio prodotto, fine-tuning su dati proprietari, modifiche dell'architettura o dei dati di addestramento possono integrare modifica sostanziale.
La terza ipotesi: modifica la finalità prevista di un sistema di IA, anche di un sistema di IA per finalità generali, che non sia stato classificato come sistema ad alto rischio ed è già stato immesso sul mercato o messo in servizio, in modo tale che il sistema di IA in questione diventi un sistema di IA ad alto rischio a norma dell'articolo 6. Esempio classico: una software house italiana acquista GPT-4 (sistema general-purpose) e costruisce sopra un sistema di valutazione del merito creditizio. La nuova finalità ricade nell'allegato III (alto rischio); la software house italiana diventa fornitore.
Gli obblighi del fornitore originario verso il nuovo fornitore
Il paragrafo 2 dell'articolo 25 introduce un obbligo di cooperazione cruciale. Quando si verifica una delle situazioni di cui al paragrafo 1, il fornitore che ha inizialmente immesso sul mercato o messo in servizio il sistema di IA non è più considerato fornitore di tale specifico sistema ai fini del Regolamento. Tuttavia, deve cooperare strettamente con i nuovi fornitori, mettere a disposizione le informazioni necessarie e fornire l'accesso tecnico ragionevolmente atteso e altre forme di assistenza richieste per l'adempimento degli obblighi del Regolamento, in particolare per quanto riguarda la conformità alla valutazione di conformità dei sistemi di IA ad alto rischio.
Tradotto in pratica: OpenAI, se la mia software house italiana usa GPT-4 per costruire un sistema di credit scoring, deve cooperare nel fornire la documentazione tecnica necessaria a completare la valutazione di conformità prevista dall'articolo 43. Questo obbligo di cooperazione, però, ha un limite: il paragrafo 2 specifica che esso non si applica quando il fornitore originario ha chiaramente specificato che il proprio sistema di IA non deve essere modificato in un sistema di IA ad alto rischio.
La cooperazione lungo l'intera filiera
Il paragrafo 4 dell'articolo 25 estende l'obbligo di cooperazione a tutti gli operatori della filiera. I fornitori di sistemi di IA ad alto rischio e i terzi che forniscono sistemi di IA, strumenti, servizi, componenti o processi utilizzati o integrati in un sistema di IA ad alto rischio devono specificare, mediante accordo scritto, le informazioni, le capacità, l'accesso tecnico e altra assistenza necessari, sulla base dello stato dell'arte generalmente riconosciuto, affinché il fornitore del sistema di IA ad alto rischio possa adempiere pienamente agli obblighi previsti dal Regolamento.
Questo paragrafo trasforma l'AI Act in una norma contrattuale. Ogni rapporto B2B nella filiera AI deve oggi prevedere clausole di cooperazione documentale, accesso tecnico, condivisione di informazioni sulla valutazione del rischio. Gli accordi standard contrattuali per la fornitura di sistemi di IA ad alto rischio sono in fase di elaborazione presso l'Ufficio per l'IA della Commissione, ma fino al loro rilascio l'onere di una corretta strutturazione contrattuale ricade sulle parti.
Per una panoramica delle scadenze rimandiamo alla guida sulle scadenze AI Act 2026-2027 in Italia.
Articolo 26: gli obblighi specifici del deployer
L'articolo 25 va letto in combinato disposto con l'articolo 26, che elenca gli obblighi specifici a carico dei deployer di sistemi di IA ad alto rischio. Sono otto obblighi, alcuni dei quali sostanzialmente nuovi nel panorama normativo europeo.
Uso conforme alle istruzioni. Il paragrafo 1 dell'articolo 26 impone ai deployer di adottare misure tecniche e organizzative idonee a garantire l'uso di tali sistemi conformemente alle istruzioni per l'uso che li accompagnano. Le istruzioni per l'uso, redatte dal fornitore ai sensi dell'articolo 13, diventano vincolanti per il deployer; un loro mancato rispetto può configurare violazione autonoma del Regolamento.
Sorveglianza umana qualificata. Il paragrafo 2 stabilisce che i deployer devono affidare la sorveglianza umana a persone fisiche che dispongono delle competenze, della formazione e dell'autorità necessarie e che ricevono il sostegno necessario. Non basta designare un responsabile: occorre dimostrare formazione documentata e autorità reale di intervento. Per molte PMI italiane questo è il punto più ostico, perché impone investimenti formativi prima dell'avvio dei sistemi.
Pertinenza dei dati di input. Il paragrafo 4 introduce un obbligo di qualità: nella misura in cui il deployer esercita il controllo sui dati di input, deve garantire che tali dati siano pertinenti e sufficientemente rappresentativi alla luce della finalità prevista del sistema di IA ad alto rischio. È una norma che dialoga con il GDPR ma ne estende l'ambito alla qualità statistica del dataset.
Monitoraggio del funzionamento. Il paragrafo 5 impone ai deployer di monitorare il funzionamento del sistema di IA ad alto rischio sulla base delle istruzioni per l'uso. In caso di motivi di ritenere che l'uso conformemente alle istruzioni possa comportare un rischio ai sensi dell'articolo 79, paragrafo 1, il deployer deve, senza indebito ritardo, informare il fornitore o il distributore e l'autorità di vigilanza del mercato competente, sospendere l'uso del sistema. La sospensione è obbligatoria, non opzionale.
Conservazione dei log. Il paragrafo 6 stabilisce un obbligo di conservazione automatica dei log generati dal sistema di IA per un periodo adeguato alla finalità prevista, di almeno sei mesi, salvo diversa disposizione del diritto dell'Unione o nazionale applicabile. Per i sistemi utilizzati nel settore finanziario il termine si allinea ai più stringenti obblighi di conservazione documentale settoriali (sette anni per banche e intermediari).
Informazione dei lavoratori. Il paragrafo 7 introduce, prima dell'attivazione di un sistema di IA ad alto rischio sul luogo di lavoro, l'obbligo dei deployer datori di lavoro di informare i rappresentanti dei lavoratori e i lavoratori interessati. È un punto di intersezione esplicita con la disciplina italiana di tutela del lavoratore (articolo 4 dello Statuto, decreto trasparenza 104/2022) che richiede coordinamento con le procedure sindacali esistenti.
Valutazione d'impatto sui diritti fondamentali. L'articolo 27, richiamato dall'articolo 26, impone a determinate categorie di deployer (organismi di diritto pubblico, soggetti privati che forniscono servizi pubblici, deployer di sistemi di scoring creditizio o assicurativo) la valutazione d'impatto sui diritti fondamentali (FRIA) prima di mettere in servizio un sistema ad alto rischio. La FRIA si aggiunge alla DPIA prevista dal GDPR; sebbene possano essere unificate documentalmente, i contenuti minimi sono distinti.
Diritto alla spiegazione. Il paragrafo 11 dell'articolo 26 conferisce alle persone interessate da una decisione presa dal deployer sulla base dell'output di un sistema di IA ad alto rischio elencato nell'allegato III il diritto di ottenere dal deployer spiegazioni chiare e significative sul ruolo del sistema di IA nella procedura decisionale e sui principali elementi della decisione adottata. Il diritto si esercita su richiesta dell'interessato e configura un obbligo informativo aggiuntivo rispetto a quanto previsto dall'articolo 22 GDPR.
Per un approfondimento sulla checklist operativa di adempimento si veda la checklist conformità AI 2026.
Sanzioni: i numeri reali
L'articolo 99 del Regolamento disciplina il regime sanzionatorio. Le sanzioni amministrative pecuniarie sono articolate su tre fasce.
La fascia massima si applica alle violazioni del divieto delle pratiche di IA vietate (articolo 5): fino a 35 milioni di euro o, se l'autore del reato è un'impresa, fino al 7 % del fatturato mondiale annuo totale dell'esercizio precedente, se superiore.
La fascia intermedia, che ricomprende la violazione degli obblighi previsti dagli articoli 25 e 26, prevede sanzioni fino a 15 milioni di euro o, se l'autore del reato è un'impresa, fino al 3 % del fatturato mondiale annuo totale dell'esercizio precedente, se superiore.
La fascia bassa, applicata alla fornitura di informazioni inesatte, incomplete o fuorvianti agli organismi notificati e alle autorità nazionali competenti, prevede sanzioni fino a 7,5 milioni di euro o all'1 % del fatturato mondiale, se superiore. Il Regolamento prevede inoltre che, per le PMI, comprese le start-up, ciascuna sanzione si applica con il valore inferiore tra le due percentuali e i due importi assoluti.
In Italia l'autorità nazionale competente è ACN per la cibersicurezza e AgID per il coordinamento generale della governance algoritmica nella PA, mentre il Garante per la protezione dei dati personali conserva competenza specifica sui sistemi che trattano dati personali. La legge italiana di adeguamento, attualmente in fase di approvazione parlamentare nella primavera 2026, definirà la ripartizione finale delle competenze sanzionatorie. Le imprese stabilite in Italia con violazioni transfrontaliere risponderanno principalmente all'autorità di vigilanza del mercato del paese di stabilimento, secondo il principio del paese d'origine modulato.
Tre casi pratici italiani
Caso 1. La PA italiana che adotta Microsoft Copilot
Una pubblica amministrazione italiana — supponiamo una grande regione — sottoscrive Microsoft 365 Copilot per i propri 12.000 dipendenti. Lo usa per generazione documentale, sintesi di riunioni, analisi di file Excel.
Mappatura dei ruoli ai sensi dell'articolo 25.
- Microsoft Corporation (Stati Uniti): fornitore originario. Sviluppa il sistema, lo immette sul mercato globale.
- Microsoft Ireland Operations Limited: importatore ai sensi dell'articolo 3, paragrafo 6, in quanto soggetto stabilito nell'UE che immette sul mercato europeo il prodotto recante il marchio dell'azienda extra-UE.
- Microsoft Italia S.r.l.: distributore per il mercato italiano, salvo che operi in nome e per conto di Microsoft Ireland in regime di rappresentanza commerciale.
- Pubblica amministrazione: deployer ai sensi dell'articolo 3, paragrafo 4, in quanto utilizza il sistema sotto la propria autorità nel proprio ambito professionale.
Obblighi conseguenti.
Copilot, nella sua versione attuale per uso generalista da ufficio, non è un sistema ad alto rischio elencato nell'allegato III. È però un sistema general-purpose i cui modelli sottostanti (GPT-4 di OpenAI integrato in Microsoft) ricadono nelle nuove disposizioni del titolo V del Regolamento (articoli 51-55) sui modelli di IA per finalità generali. La PA, in qualità di deployer di un sistema general-purpose non ad alto rischio, è soggetta a obblighi attenuati: trasparenza verso gli utenti finali (segnalare l'output di IA), informazione dei lavoratori interessati ai sensi dell'articolo 26, paragrafo 7, e — qualora il sistema venisse utilizzato per supportare decisioni amministrative — obblighi specifici derivanti dal codice dell'amministrazione digitale e dalla giurisprudenza del Consiglio di Stato sull'algoritmizzazione del provvedimento.
Se invece la PA decidesse di personalizzare Copilot tramite plugin aziendali che lo integrino in un processo di scoring per la selezione di beneficiari di sussidi pubblici (allegato III, punto 5), ricorrerebbe l'ipotesi del paragrafo 1 lettera c) dell'articolo 25: la PA modificherebbe la finalità prevista trasformando un sistema general-purpose in un sistema ad alto rischio. La PA diventerebbe fornitore. Microsoft sarebbe tenuta alla cooperazione tecnica ai sensi del paragrafo 2 dell'articolo 25.
Caso 2. La banca italiana che integra GPT-4 nel CRM
Un istituto di credito italiano firma un contratto enterprise con OpenAI per l'utilizzo di GPT-4 via API. Il modello viene integrato nel CRM proprietario per supportare gli operatori di filiale nelle conversazioni con la clientela e nella valutazione preliminare di richieste di finanziamento.
Mappatura dei ruoli.
- OpenAI L.L.C. (Stati Uniti): fornitore originario del modello GPT-4 ai sensi dell'articolo 3, paragrafo 3, e fornitore di un modello di IA per finalità generali ai sensi dell'articolo 3, paragrafo 63.
- OpenAI Ireland Limited: importatore ai sensi dell'articolo 3, paragrafo 6.
- Banca italiana: la qualificazione dipende dall'uso. Per il supporto conversazionale agli operatori è deployer di un sistema general-purpose. Per la valutazione preliminare del merito creditizio, attività che ricade nell'allegato III, punto 5, lettera b) (sistemi destinati a valutare l'affidabilità creditizia delle persone fisiche), si applica l'articolo 25, paragrafo 1, lettera c): la banca modifica la finalità prevista trasformando il sistema in un sistema ad alto rischio. La banca diventa fornitore.
Obblighi conseguenti.
In quanto fornitore di sistema ad alto rischio derivato, la banca deve adempiere agli obblighi dell'articolo 16: sistema di gestione della qualità, valutazione di conformità ai sensi dell'articolo 43, marcatura CE, registrazione nel database UE dei sistemi ad alto rischio (articolo 71), istituzione del sistema di gestione del rischio (articolo 9), data governance (articolo 10), documentazione tecnica (articolo 11). OpenAI deve cooperare ai sensi dell'articolo 25, paragrafo 2, fornendo informazioni e accesso tecnico necessari. La cooperazione è negoziata contrattualmente: OpenAI ha pubblicato condizioni specifiche per i clienti enterprise UE che includono clausole di EU AI Act compliance.
In aggiunta, in quanto soggetto privato che fornisce servizi finanziari di interesse pubblico, la banca rientra tra i deployer tenuti alla FRIA ai sensi dell'articolo 27. La FRIA si coordina con la DPIA GDPR già obbligatoria per il trattamento di profilazione creditizia.
Per chi opera in vendita B2B con istituti finanziari, il tema si lega alla strategia di lead generation AI nel B2B.
Caso 3. La manifatturiera italiana e il sistema di visione artificiale
Un'azienda manifatturiera del distretto meccanico emiliano acquista un sistema di visione artificiale da un vendor tedesco per il controllo qualità in linea di produzione. Il sistema rileva difetti su componenti meccanici tramite reti neurali convoluzionali.
Mappatura dei ruoli.
- Vendor tedesco: fornitore. Il sistema è progettato e immesso sul mercato UE con il proprio marchio.
- Manifatturiera italiana: deployer.
Obblighi conseguenti.
Il sistema di visione artificiale per controllo qualità non rientra nell'allegato III dell'AI Act (l'allegato III è una lista chiusa che include occupazione, istruzione, infrastrutture critiche, servizi essenziali, applicazioni delle forze dell'ordine, immigrazione, amministrazione della giustizia). Tuttavia, il sistema è componente di sicurezza di un prodotto industriale soggetto alla direttiva macchine e potenzialmente al Regolamento macchine (UE) 2023/1230. Ricorre quindi la fattispecie dell'articolo 6, paragrafo 1: il sistema è considerato ad alto rischio se è componente di sicurezza di un prodotto disciplinato dalla normativa di armonizzazione dell'Unione elencata nell'allegato I e tale prodotto è soggetto a una valutazione di conformità da parte di terzi.
Il vendor tedesco, in quanto fornitore originario, conserva tutti gli obblighi degli articoli 8-15. La manifatturiera italiana, in quanto deployer, deve adempiere agli obblighi dell'articolo 26, in particolare: uso conforme alle istruzioni del fornitore, sorveglianza umana qualificata, monitoraggio del funzionamento, conservazione dei log per almeno sei mesi, informazione dei lavoratori interessati ai sensi dell'articolo 26 paragrafo 7. L'informazione ai lavoratori deve coordinarsi con la procedura di consultazione sindacale prevista dall'articolo 4 dello Statuto dei lavoratori per gli impianti audiovisivi.
Se la manifatturiera italiana decidesse di fine-tunare il modello del vendor tedesco con dati propri di produzione, modificando l'architettura, potrebbe configurare modifica sostanziale ai sensi dell'articolo 25, paragrafo 1, lettera b): l'azienda emiliana diventerebbe fornitore. Una clausola contrattuale ben costruita con il vendor tedesco può chiarire ex ante quali interventi configurano modifica sostanziale e quali rientrano nella personalizzazione consentita.
Cosa fare ora: una mappa operativa
Per le aziende italiane oggi, indipendentemente dal settore, l'articolo 25 si traduce in cinque azioni concrete da pianificare entro il 2 agosto 2026, data di applicabilità degli obblighi sui sistemi ad alto rischio.
Inventario AI. Mappare tutti i sistemi di IA in uso, distinguendo per finalità (general-purpose vs verticale), origine (sviluppato internamente vs acquistato), ruolo aziendale (fornitore, deployer, distributore, importatore). L'inventario è propedeutico ad ogni successiva analisi. Strumenti di knowledge graph aziendale come quelli descritti nella guida ai knowledge graph AI aziendali possono accelerare questa fase.
Classificazione del rischio. Per ogni sistema mappato, applicare l'articolo 6 e l'allegato III per stabilire se è ad alto rischio, general-purpose, a rischio limitato o a rischio minimo. La classificazione determina la cascata di obblighi.
Mappatura della catena di fornitura. Identificare per ogni sistema il fornitore originario, gli importatori, i distributori. Verificare se sussistono ipotesi di trasformazione del ruolo ai sensi dell'articolo 25, paragrafo 1.
Revisione contrattuale. Aggiornare i contratti B2B con clausole di cooperazione documentale, accesso tecnico, condivisione informazioni di valutazione del rischio, ai sensi dell'articolo 25, paragrafo 4. Questa attività richiede consulenza legale specializzata e tempo: avviarla con almeno sei mesi di anticipo rispetto al 2 agosto 2026.
Adeguamento ISO 42001. L'implementazione di un sistema di gestione dell'IA conforme allo standard ISO 42001 fornisce la struttura organizzativa e documentale che l'AI Act richiede. Per il dettaglio si veda la guida all'implementazione di ISO 42001 in Italia.
L'articolo 25 dell'AI Act non è un cavillo: è la spina dorsale della governance dell'IA in Europa. Le aziende che lo affrontano oggi, mappando ruoli e responsabilità prima che le scadenze stringano, non solo evitano sanzioni significative ma trasformano la conformità in un vantaggio competitivo verso clienti e investitori sempre più attenti al tema. Le aziende che lo rinviano al secondo semestre 2026 si troveranno in concorrenza con migliaia di altri ritardatari per la stessa, scarsa, consulenza specialistica disponibile sul mercato italiano.
Knowlee.ai supporta le aziende italiane nell'integrazione di sistemi di IA conformi all'AI Act, con particolare attenzione alla mappatura della catena di responsabilità e alla strutturazione contrattuale lungo la filiera.