Provider e deployer nell’AI Act: differenze, obblighi e responsabilità
Guida pratica a ruoli, obblighi, responsabilità e casi in cui chi utilizza l’IA diventa fornitore: differenze e scadenze
L’AI Act distingue il provider, o fornitore, che sviluppa o fa sviluppare un sistema di intelligenza artificiale e lo immette sul mercato o lo mette in servizio con il proprio nome o marchio, dal deployer, che lo utilizza sotto la propria autorità nell’ambito di un’attività professionale.
Per imprese, professionisti e pubbliche amministrazioni, questa distinzione determina gli obblighi da rispettare. I ruoli, tuttavia, possono cambiare: nei casi previsti dal regolamento, una modifica sostanziale o una nuova finalità d’uso può trasformare l’utilizzatore in fornitore. Esaminiamo gli adempimenti, le responsabilità e le scadenze alla luce degli aggiornamenti normativi del 2026.
Vuoi utilizzare l’intelligenza artificiale come supporto al tuo lavoro tecnico? Scopri l’intelligenza esperta delle costruzioni, l’IA di ACCA integrata in EdiLus, TerMus, CerTus, PriMus e AntiFuocus: ti aiuta ad analizzare i dati del progetto, comprendere i risultati e confrontare soluzioni, mantenendo nelle tue mani le decisioni professionali.
Chi è il provider nell’AI Act
Il termine fornitore viene definito dall’articolo 3, punto 3, del Regolamento (UE) 2024/1689 e può essere una persona fisica o giuridica, un’autorità pubblica, un’agenzia o un altro organismo. La definizione comprende chi sviluppa direttamente un sistema o un modello di IA per finalità generali e chi ne commissiona lo sviluppo, purché ricorrano le condizioni relative all’immissione sul mercato o alla messa in servizio con il proprio nome o marchio.
Non è quindi necessario scrivere personalmente il software: un’impresa che commissiona un sistema e lo propone sotto il proprio marchio può assumere il ruolo di provider. La fornitura gratuita, inoltre, non esclude questa qualifica.
Anche l’impiego interno merita attenzione: sviluppare un sistema e metterlo in servizio per uso proprio può comportare obblighi da fornitore, oltre a quelli derivanti dall’utilizzo.
Una persona fisica o giuridica, un’autorità pubblica, un’agenzia o un altro organismo che sviluppa un sistema di IA o un modello di IA per finalità generali o che fa sviluppare un sistema di IA o un modello di IA per finalità generali e immette tale sistema o modello sul mercato o mette in servizio il sistema di IA con il proprio nome o marchio, a titolo oneroso o gratuito
Chi è il deployer nell’AI Act
L’AI Act definisce il deployer come il soggetto che utilizza un sistema di IA sotto la propria autorità escludendo l’utilizzo nell’ambito di un’attività personale non professionale.
una persona fisica o giuridica, un’autorità pubblica, un’agenzia o un altro organismo che utilizza un sistema di IA sotto la propria autorità, tranne nel caso in cui il sistema di IA sia utilizzato nel corso di un’attività personale non professionale;
Sono esempi indicativi un’impresa che impiega un sistema per selezionare candidati, una pubblica amministrazione che lo utilizza nei propri procedimenti o un professionista che adotta un assistente di IA per supportare il lavoro.
Il deployer non coincide necessariamente con la persona che inserisce materialmente un comando: nel contesto aziendale, il ruolo va valutato rispetto all’organizzazione sotto la cui autorità il sistema è utilizzato e alle concrete modalità d’impiego.
Acquistare un servizio di IA, pertanto, non trasferisce automaticamente al fornitore tutti gli obblighi collegati al suo utilizzo.
Quali obblighi riguardano provider e deployer?
Gli obblighi di provider e deployer dipendono anche dalla finalità del sistema e dalle sue modalità d’impiego e occorre verificare se ricorrono una pratica vietata dall’articolo 5, i presupposti dell’alto rischio previsti dall’articolo 6 e dagli allegati I e III oppure gli obblighi di trasparenza dell’articolo 50. Questi ultimi possono applicarsi anche a sistemi non classificati ad alto rischio.
L’impiego in un settore sensibile non determina automaticamente la classificazione. L’articolo 6, paragrafo 3, ammette, a precise condizioni, l’esclusione di alcuni sistemi dell’allegato III che svolgono compiti limitati, preparatori o di miglioramento di attività umane già completate, senza presentare un rischio significativo. La deroga non riguarda i sistemi dell’allegato III che effettuano profilazione di persone fisiche.
Obblighi di trasparenza anche fuori dall’alto rischio
L’esclusione dalla categoria ad alto rischio non equivale all’assenza di obblighi. Difatti l’articolo 50 disciplina, con condizioni ed eccezioni specifiche, sistemi che interagiscono direttamente con persone, generano contenuti sintetici o sono utilizzati per produrre deepfake e determinati testi di interesse pubblico.
Queste disposizioni possono applicarsi anche a sistemi non classificati ad alto rischio. Possono inoltre aggiungersi agli obblighi previsti per questi ultimi, come chiarisce il paragrafo 6 dello stesso articolo.
Per individuare gli adempimenti occorre pertanto collegare il ruolo dell’operatore alla finalità del sistema, verificare le disposizioni pertinenti e considerarne le rispettive date di applicazione.
Alfabetizzazione in materia di IA
Il Regolamento (UE) 2026/1744 ha modificato integralmente l’articolo 4 richiedendo a fornitori e deployer di adottare misure per sostenere lo sviluppo delle competenze in materia di intelligenza artificiale del personale e delle altre persone che gestiscono o utilizzano i sistemi per loro conto.
Le iniziative devono essere calibrate sulla preparazione e sull’esperienza dei destinatari, sul contesto operativo e sulle persone interessate dall’impiego dell’IA. Possono tradursi, ad esempio, in formazione sui limiti degli strumenti, istruzioni per verificarne i risultati e indicazioni per riconoscere gli errori: soluzioni da adattare alle attività effettivamente svolte.
L’obbligo riguarda l’adozione di misure di supporto, senza imporre di garantire a ciascuno uno specifico livello di alfabetizzazione. La disposizione affida inoltre alla Commissione e agli Stati membri il compito di agevolare questi percorsi, soprattutto nelle PMI, anche attraverso esempi pratici pubblicati sulla piattaforma unica di informazione. Al Consiglio per l’IA spetta invece formulare raccomandazioni e obiettivi comuni, tenendo conto dei quadri europei delle competenze.
Trasparenza nell’AI Act: gli obblighi di provider e deployer secondo l’articolo 50
Rendere riconoscibile l’interazione con un’intelligenza artificiale e l’origine dei contenuti generati è lo scopo degli obblighi di trasparenza previsti dall’articolo 50 dell’AI Act. La norma assegna compiti distinti a provider e deployer, in base alle caratteristiche del sistema e al suo utilizzo, e precisa come informare le persone interessate e quali eccezioni si applicano.
I fornitori devono progettare i sistemi che interagiscono direttamente con le persone affinché queste siano informate di comunicare con un’IA, salvo che sia già evidente dal contesto. Per i sistemi che generano contenuti sintetici, devono inoltre assicurare una marcatura degli output leggibile meccanicamente, che ne consenta il riconoscimento come artificiali, nei limiti tecnici indicati dalla norma. Sono previste eccezioni, tra cui l’assistenza all’editing standard o interventi che non modificano sostanzialmente i dati inseriti o il loro significato.
Ai deployer spetta invece informare le persone esposte a sistemi di riconoscimento delle emozioni o categorizzazione biometrica, rispettando la normativa sulla protezione dei dati, e dichiarare l’origine artificiale dei deepfake e dei testi pubblicati per informare su questioni di interesse pubblico.
Per i testi generati o manipolati dall’IA e pubblicati per informare il pubblico su questioni di interesse pubblico, l’articolo 50, paragrafo 4, prevede una specifica eccezione all’obbligo di dichiararne l’origine artificiale: il contenuto deve essere sottoposto a revisione umana o controllo editoriale e una persona fisica o giuridica deve detenere la responsabilità editoriale della pubblicazione. Questa eccezione riguarda i testi e non si estende automaticamente ai deepfake. Per questi ultimi, quando inseriti in opere o programmi manifestamente artistici, creativi, satirici o fittizi, resta necessario rivelarne la presenza con modalità adeguate, senza ostacolare l’esposizione o il godimento dell’opera. Il paragrafo 5 richiede inoltre che le informazioni siano chiare e distinguibili, comunicate al più tardi alla prima interazione o esposizione e conformi ai requisiti di accessibilità applicabili.
Gli obblighi del provider per i sistemi di IA ad alto rischio
Per il fornitore di un sistema di IA ad alto rischio, la conformità richiede un’organizzazione capace di tradurre i requisiti normativi in procedure operative e verifiche documentate. Gli adempimenti coinvolgono sia la preparazione all’immissione sul mercato o alla messa in servizio, sia le attività successive, necessarie per individuare e gestire eventuali non conformità.
In particolare, per i sistemi ad alto rischio, l’articolo 16 pone sul fornitore un insieme articolato di adempimenti. Tra i principali:
assicurare il rispetto dei requisiti relativi a rischi, dati, documentazione, registrazione degli eventi, trasparenza, sorveglianza umana, accuratezza, robustezza e cybersicurezza;
istituire un sistema di gestione della qualità;
predisporre e conservare la documentazione richiesta;
svolgere la pertinente valutazione della conformità prima che sia immesso sul mercato o messo in servizio;
redigere la dichiarazione UE di conformità e apporre la marcatura CE;
adempiere agli obblighi di registrazione applicabili;
adottare misure correttive e cooperare con le autorità.
La decisione di esecuzione (UE) 2026/2274 ha pubblicato il riferimento alla norma armonizzata EN 18286:2026, relativa al sistema di gestione della qualità. La presunzione di conformità riguarda i requisiti coperti dalla norma: non costituisce un’attestazione generale di conformità a ogni obbligo dell’AI Act.
Gli obblighi del deployer per i sistemi di IA ad alto rischio
L’articolo 26 attribuisce al deployer obblighi propri, che richiedono un’organizzazione adeguata dell’utilizzo per usare il sistema secondo le istruzioni e affidare la sorveglianza umana a persone con competenza, formazione, autorità e sostegno necessari.
Deve inoltre:
verificare pertinenza e sufficiente rappresentatività dei dati di input, nella misura in cui li controlla;
monitorare il funzionamento e attivare le comunicazioni previste in presenza di rischi o incidenti gravi;
sospendere l’utilizzo quando ricorrono le condizioni indicate dalla norma;
conservare i log sotto il proprio controllo per un periodo adeguato, di almeno sei mesi, salvo diverse disposizioni applicabili;
rispettare gli obblighi informativi verso lavoratori e persone interessate nei casi previsti;
cooperare con le autorità competenti.
Per alcuni deployer è prevista anche la valutazione d’impatto sui diritti fondamentali, disciplinata dall’articolo 27. L’obbligo riguarda specifiche categorie, tra cui organismi di diritto pubblico, soggetti privati che forniscono servizi pubblici e determinati utilizzi nel credito e nelle assicurazioni, nei limiti stabiliti dalla disposizione.
Questa valutazione non coincide con la DPIA prevista dal GDPR. Il testo aggiornato consente di richiamare o includere parti pertinenti della DPIA, evitando duplicazioni senza confondere i due adempimenti.
Quando un deployer diventa provider
L’articolo 25 prevede che un deployer, un distributore, un importatore o un altro soggetto possa essere considerato fornitore di un sistema ad alto rischio nelle seguenti circostanze:
apporre il proprio nome o marchio su un sistema ad alto rischio già immesso sul mercato o messo in servizio, ferma la previsione sugli accordi contrattuali contenuta nella norma;
apportare una modifica sostanziale a un sistema ad alto rischio, mantenendone tale classificazione;
modificare la finalità prevista di un sistema inizialmente non classificato ad alto rischio, facendolo rientrare in questa categoria.
Un esempio è l’adattamento di uno strumento generico per analizzare e filtrare candidature lavorative: la nuova finalità può comportare la classificazione ad alto rischio e l’assunzione degli obblighi del fornitore. La valutazione deve comunque verificare le condizioni dell’articolo 6 e dell’allegato III.
Non ogni personalizzazione determina il cambio di ruolo: una configurazione ordinaria o una modifica già prevista nella valutazione iniziale non equivale automaticamente a una modifica sostanziale. L’Omnibus del 2026 ha inoltre precisato gli obblighi di cooperazione del fornitore iniziale, comprendendo, ove pertinente, documentazione tecnica, limitazioni note e accesso tecnico mirato.
Responsabilità: sanzioni, danni e contratti
L’AI Act affida agli Stati membri il compito di definire e attuare il sistema sanzionatorio entro le condizioni stabilite dal regolamento. Le misure possono comprendere sanzioni pecuniarie, avvertimenti e altri interventi non monetari e devono essere effettive, proporzionate e dissuasive, tenendo conto anche della sostenibilità economica delle imprese di minori dimensioni. Per provider e deployer occorre inoltre distinguere le conseguenze della violazione degli obblighi normativi dalle eventuali richieste di risarcimento: l’applicazione di una sanzione e la responsabilità per un danno seguono presupposti e regole differenti.
L’articolo 99 prevede massimali fino a 15 milioni di euro o al 3% del fatturato mondiale annuo dell’esercizio precedente, se superiore per le imprese. Tra queste disposizioni rientrano gli obblighi dei fornitori dell’articolo 16, dei deployer dell’articolo 26 e quelli di trasparenza dell’articolo 50.
La sanzione per la violazione delle pratiche vietate definite dall’articolo 5 può raggiungere 35 milioni di euro o il 7% del fatturato, secondo le condizioni previste. È importante sottolineare che sono massimali, non importi automatici e vanno considerati l’applicabilità temporale dell’obbligo, gravità della violazione e regole specifiche per PMI e piccole imprese a media capitalizzazione.
Il risarcimento del danno in Italia
Gli articoli 16-20 del D.Lgs. 160/2026 disciplinano l’accesso alle prove e alcuni aspetti delle azioni di risarcimento per danni cagionati nell’utilizzo di sistemi di intelligenza artificiale, distinguendo l’ambito generale dalle ipotesi connesse alla violazione dell’AI Act.
L’articolo 16 stabilisce che le disposizioni sull’accesso alle prove si applicano alle azioni di responsabilità sia contrattuale sia extracontrattuale. Le regole sulla presunzione del nesso causale e sulla rilevanza della conformità, contenute negli articoli 18 e 19, riguardano invece le azioni nelle quali il danno deriva dalla violazione di uno o più obblighi del Regolamento (UE) 2024/1689, mentre restano ferme le disposizioni dell’articolo 82 del GDPR (diritto al risarcimento e responsabilità) e della normativa nazionale di recepimento della direttiva (UE) 2024/2853 sulla responsabilità per prodotti difettosi.
Quando il danneggiato è una persona fisica che agisce per scopi estranei alla propria eventuale attività imprenditoriale, commerciale, artigianale o professionale, è competente anche il giudice del luogo della sua residenza o del suo domicilio.
Accesso alle prove sul funzionamento del sistema
L’articolo 17 consente alla parte che sostiene di aver subito un danno di chiedere al giudice l’esibizione delle prove pertinenti detenute dalla controparte o da un terzo. La richiesta deve essere sostenuta da fatti ed elementi che rendano verosimile la fondatezza della domanda, anche rispetto al collegamento tra il risultato prodotto dal sistema e il danno lamentato.
Tra le prove acquisibili rientrano:
i registri delle attività del sistema;
la documentazione relativa al sistema di gestione dei rischi;
le informazioni pertinenti contenute nella documentazione tecnica;
le informazioni sui parametri e sulle modalità di supervisione umana.
L’ordine di esibizione deve limitarsi a quanto necessario e proporzionato alla domanda. Il giudice deve inoltre tenere conto degli interessi delle parti e tutelare i segreti commerciali e le informazioni riservate, adottando misure adeguate quando esiste un rischio di divulgazione.
Il mancato rispetto dell’ordine senza giustificato motivo produce conseguenze differenti: se riguarda una parte, il giudice può desumerne argomenti di prova; quando l’inadempimento interessa la documentazione espressamente elencata dall’articolo 17, comma 2, del D.Lgs. 160/2026 il giudice, valutato ogni altro elemento di prova, ritiene ammessi i fatti allegati dall’istante. Se invece a non adempiere è un terzo, è prevista una pena pecuniaria da 1.500 a 10.000 euro.
Presunzione del nesso causale e rilevanza della conformità
L’articolo 18 prevede che, quando il danno deriva dalla violazione di uno o più obblighi dell’AI Act, il nesso causale tra la violazione e il danno sia presunto, salvo prova contraria. La presunzione riguarda quindi il collegamento causale: non equivale ad affermare che qualsiasi errore del sistema determini automaticamente una responsabilità.
L’articolo 19 precisa inoltre che la conformità del sistema all’AI Act, anche se certificata, non esclude di per sé la responsabilità del convenuto, ferma la disciplina nazionale di recepimento della direttiva (UE) 2024/2853.
L’azione diretta nei confronti dell’assicuratore
L’articolo 20 del decreto legislativo consente al danneggiato di chiedere il risarcimento direttamente all’impresa che assicura la responsabilità civile del soggetto individuato come responsabile, entro i limiti delle somme assicurate.
Prima di avviare l’azione, l’interessato può chiedere al presunto responsabile se dispone di una copertura relativa al danno lamentato. Quest’ultimo deve comunicare entro 30 giorni dalla ricezione della richiesta l’esistenza del contratto, i suoi estremi e la denominazione dell’assicuratore. La richiesta è facoltativa e non costituisce una condizione per procedere con la domanda giudiziale. In caso di comunicazione omessa o incompleta, il giudice può desumerne argomenti di prova ai sensi dell’articolo 116 del codice di procedura civile.
L’azione diretta non rende incondizionata la copertura: l’assicuratore può opporre al danneggiato le eccezioni derivanti dal contratto, purché anteriori al sinistro. Se effettua il pagamento, può inoltre rivalersi sull’assicurato nella misura in cui avrebbe avuto titolo contrattuale per rifiutare o ridurre la propria prestazione.
Nel giudizio contro l’assicuratore deve partecipare anche il soggetto individuato come responsabile del danno, in qualità di litisconsorte necessario. L’azione diretta è soggetta allo stesso termine di prescrizione previsto per l’azione nei confronti di tale soggetto.
Nella pratica professionale, l’IA può affiancare il tecnico nell’analisi dei dati e nel confronto delle soluzioni, mantenendo centrale la sua valutazione. È questo il tipo di supporto offerto da l’intelligenza esperta delle costruzioni, integrata in EdiLus, TerMus, CerTus, PriMus e AntiFuocus: aiuta a comprendere i risultati e approfondire gli aspetti del progetto, lasciando al professionista le scelte e le decisioni.
Approfondimenti AI ACT
AI Act: cosa cambia dal 2026 per tecnici e imprese, quali obblighi osservare;
Digital Omnibus 2026: scadenze AI Act rinviate al 2027 e 2028;
RC professionale e intelligenza artificiale: cosa esclude
Il nuovo reato AI per i sistemi ad alto rischio previsto dal D.Lgs. 160/2026
Scopri una nuova modalità di lavorare con l’intelligenza artificiale: analizzare, verificare e confrontare soluzioni progettuali attraverso richieste in linguaggio naturale: scopri le possibilità offerte da SIBILLA nei software ACCA.
FAQ provider e deployer nell’AI Act
Qual è la differenza tra provider e deployer?
Il provider, o fornitore, sviluppa o fa sviluppare un sistema di IA e lo immette sul mercato o lo mette in servizio con il proprio nome o marchio, anche gratuitamente. Il deployer utilizza il sistema sotto la propria autorità, al di fuori di un’attività personale non professionale. Un’impresa, un professionista o una pubblica amministrazione può assumere uno o entrambi i ruoli, in base alle attività svolte.
Quando un deployer diventa fornitore di un sistema di IA?
Nei casi previsti dall’articolo 25, un deployer assume gli obblighi del fornitore quando appone il proprio nome o marchio su un sistema ad alto rischio, ferme le disposizioni sugli accordi contrattuali; modifica sostanzialmente un sistema che resta ad alto rischio; oppure cambia la finalità di un sistema inizialmente non classificato ad alto rischio, facendolo rientrare in tale categoria. Una semplice personalizzazione non determina automaticamente il cambio di ruolo.
Quali obblighi ha chi utilizza un sistema di IA ad alto rischio?
Il deployer deve utilizzare il sistema secondo le istruzioni, affidare la sorveglianza umana a persone adeguatamente competenti e formate e monitorarne il funzionamento. L’articolo 26 prevede inoltre obblighi relativi ai dati di input sotto il suo controllo, alla conservazione dei log, alle comunicazioni in caso di rischi o incidenti e alla sospensione dell’utilizzo nelle condizioni previste. Per alcune categorie di deployer è richiesta anche una valutazione d’impatto sui diritti fondamentali.
Bisogna sempre dichiarare che un contenuto è stato generato con l’IA?
L’articolo 50 prevede obblighi differenti in base al contenuto e al ruolo dell’operatore. I fornitori devono assicurare la marcatura degli output sintetici nei casi e nei limiti previsti. I deployer devono dichiarare l’origine artificiale dei deepfake e dei testi pubblicati per informare il pubblico su questioni di interesse pubblico. Per questi testi è prevista un’eccezione quando ricorrono insieme la revisione umana o il controllo editoriale e la responsabilità editoriale della pubblicazione in capo a una persona fisica o giuridica.
Chi risponde dei danni causati dall’utilizzo dell’intelligenza artificiale?
La responsabilità non ricade automaticamente sul provider o sul deployer: occorre valutare le attività svolte, gli obblighi applicabili, il danno e il collegamento causale. Le sanzioni per la violazione dell’AI Act e il risarcimento del danno seguono regole distinte. La conformità del sistema, anche certificata, non costituisce di per sé un’esenzione dalla responsabilità, così come un errore dell’IA non comporta automaticamente un obbligo di risarcimento.
Fonte: Read More
