Provider o deployer AI Act? Differenze e test

Risposta aggiornata al 1° agosto 2026. Il Regolamento (UE) 2026/1744, in vigore dal 27 luglio 2026, ha modificato l'AI Act. Gli obblighi delle sezioni 1, 2 e 3 del Capo III si applicheranno dal 2 dicembre 2027 per i sistemi ad alto rischio dell'art. 6, par. 2 e Allegato III e dal 2 agosto 2028 per quelli dell'art. 6, par. 1 e Allegato I. Altre disposizioni dell'AI Act seguono scadenze differenti.

La distinzione tra provider e deployer va svolta per ciascun sistema e per ciascuna attività. La stessa impresa può essere deployer quando usa uno strumento di terzi nei processi interni e provider quando offre ai clienti un proprio sistema AI, anche se tale sistema incorpora componenti o modelli altrui.

Per applicare questa qualificazione alla propria organizzazione e documentarne le conseguenze, consulta il servizio di assistenza in materia di AI Act.

Definizioni dell'AI Act

L'art. 3, punto 3, del Regolamento (UE) 2024/1689 definisce provider la persona fisica o giuridica, autorità pubblica, agenzia o altro organismo che:

• sviluppa un sistema AI o un modello AI per finalità generali, oppure lo fa sviluppare;
• lo immette sul mercato o mette in servizio il sistema con il proprio nome o marchio;
• opera a titolo oneroso o gratuito.

Il punto 4 definisce deployer il soggetto che usa un sistema AI sotto la propria autorità, salvo l'uso nel corso di un'attività personale non professionale.

Il provider è quindi individuato anche dalla relazione giuridica e commerciale con il sistema, non soltanto da chi ha scritto il codice o addestrato il modello di base. Il deployer è individuato dall'uso sotto la propria autorità. Parlare genericamente di «utente» o «rivenditore» può nascondere il ruolo effettivo.

Provider e deployer a confronto

Matrice Ingoglia dei ruoli AI — versione 1.0.0, 23 agosto 2026. La matrice traduce le definizioni degli artt. 3, 25 e 26 AI Act in domande verificabili. Non assegna il ruolo alla società “in astratto”: la valutazione va ripetuta per sistema, versione, finalità e attività.

Scarica la Matrice Provider/Deployer compilabile in Excel oppure consulta la pagina con istruzioni, versione corrente e changelog.

La tabella è orientativa. Importatore, distributore, fabbricante di un prodotto e rappresentante autorizzato sono ruoli distinti, che possono richiedere un'analisi ulteriore.

Il test pratico in sei domande

1. Qual è l'oggetto che si sta qualificando?

Prima di assegnare un ruolo occorre delimitare il sistema. Un modello generale accessibile via API, un motore RAG, l'interfaccia, le regole decisionali e il prodotto finale possono formare una catena tecnica con più sistemi e operatori. Dire soltanto «usiamo GPT» non identifica l'oggetto della valutazione.

Occorre descrivere input, output, autonomia, finalità, componenti, soggetti che controllano il funzionamento e modalità con cui il prodotto viene offerto o usato.

2. Il sistema è usato soltanto internamente?

Un'impresa che usa uno strumento di terzi per assistere il proprio personale è normalmente deployer di quello strumento. Restano da verificare le istruzioni del provider, il contesto d'uso e gli obblighi applicabili alla categoria del sistema.

L'uso interno non esclude in assoluto il ruolo di provider: la definizione comprende anche la messa in servizio con il proprio nome o marchio. Se l'impresa ha sviluppato o fatto sviluppare il sistema per usarlo a proprio nome, la qualificazione richiede un esame specifico.

3. L'impresa offre ai clienti un proprio sistema AI?

Se l'impresa sviluppa o fa sviluppare un sistema e lo offre con il proprio nome o marchio, vi sono forti indici del ruolo di provider del sistema finale. Il fatto che una parte della catena sia fornita da un soggetto terzo non trasferisce automaticamente al fornitore a monte l'intera qualificazione del prodotto a valle.

Occorre distinguere il provider del modello a monte dal provider dell'eventuale sistema a valle. I rispettivi obblighi dipendono dalla categoria del modello o sistema e dalla funzione svolta nella catena.

4. Chi determina la finalità prevista?

La finalità prevista è l'uso al quale il provider destina il sistema, considerando anche istruzioni, materiali promozionali, documentazione tecnica e dichiarazioni. Configurare uno strumento per una finalità diversa può incidere sulla qualificazione e, per i sistemi ad alto rischio, può assumere rilievo ai sensi dell'art. 25.

5. Il nome o marchio di chi compare sul sistema?

Apporre il proprio nome o marchio su un sistema AI già immesso sul mercato è uno dei casi espressamente considerati dall'art. 25 per distributori, importatori, deployer o altri terzi, ma la disposizione riguarda il trasferimento degli obblighi del provider rispetto a un sistema ad alto rischio. Contratti e interfacce devono essere confrontati con la realtà: un disclaimer non prevale necessariamente sui fatti.

6. È intervenuta una modifica sostanziale o una nuova finalità ad alto rischio?

La «modifica sostanziale» è una modifica non prevista o programmata nella valutazione iniziale del provider che incide sulla conformità del sistema ai requisiti del Capo III, sezione 2, oppure modifica la finalità prevista per la quale il sistema è stato valutato.

Non ogni personalizzazione è sostanziale. La risposta dipende dall'effetto della modifica, da ciò che il provider aveva previsto e valutato e, per l'art. 25, dal fatto che il sistema sia o divenga ad alto rischio.

Quando l'articolo 25 attribuisce gli obblighi del provider

Per un sistema AI ad alto rischio, l'art. 25, par. 1, considera provider il distributore, l'importatore, il deployer o altro terzo quando ricorre una delle seguenti circostanze:

1. appone il proprio nome o marchio su un sistema ad alto rischio già immesso sul mercato o messo in servizio, fatti salvi gli accordi contrattuali che dispongano diversamente sull'allocazione degli obblighi nei limiti consentiti;
2. apporta una modifica sostanziale a un sistema ad alto rischio già immesso sul mercato o messo in servizio, che resta un sistema ad alto rischio;
3. modifica la finalità prevista di un sistema che non era classificato ad alto rischio e che, per effetto della nuova finalità, diventa ad alto rischio ai sensi dell'art. 6.

Queste condizioni non equivalgono alla formula «qualsiasi personalizzazione crea un nuovo provider». Occorre provare i fatti che integrano una delle fattispecie.

Il Regolamento (UE) 2026/1744 ha inoltre modificato i paragrafi 2 e 4 dell'art. 25, rafforzando, in determinate condizioni, la cooperazione informativa e tecnica tra provider iniziale, nuovo provider e fornitori di componenti. La ripartizione contrattuale delle informazioni non elimina gli obblighi inderogabili previsti dal regolamento.

API, RAG, prompt e fine-tuning: cosa significano davvero

Integrazione tramite API

Collegare un'API a un processo interno è normalmente un indice di uso e quindi del ruolo di deployer rispetto al sistema a monte. Se, invece, l'impresa costruisce e commercializza con il proprio marchio un sistema AI distinto che incorpora l'API, può essere provider del sistema a valle. Servono architettura, finalità, autonomia e modalità di offerta per concludere.

RAG

Una pipeline RAG recupera informazioni e le fornisce al modello come contesto. Questa tecnica può cambiare fonti, output e rischi, ma non costituisce automaticamente una modifica sostanziale ai sensi dell'AI Act. Bisogna verificare se la configurazione era prevista dal provider, se incide sulla conformità e se cambia la finalità prevista.

Prompt e system prompt

Prompt, guardrail e regole di orchestrazione possono orientare significativamente il comportamento. La loro importanza tecnica non coincide, senza ulteriori elementi, con una modifica sostanziale giuridica. Sono però evidenze da conservare perché contribuiscono a definire il sistema effettivo e il controllo esercitato dall'organizzazione.

Fine-tuning

Il fine-tuning può avere impatti più profondi su prestazioni e rischi, ma anche qui non opera una presunzione generale. Vanno confrontati modifica, valutazione iniziale, finalità, classificazione e requisiti di conformità. La conclusione va motivata caso per caso.

Obblighi principali per sistemi ad alto rischio

Per i sistemi ad alto rischio, il provider è tenuto, tra l'altro, ad assicurare conformità ai requisiti applicabili, sistema di gestione della qualità, documentazione e registri, valutazione di conformità, registrazione ove prevista, azioni correttive e monitoraggio successivo all'immissione sul mercato.

Il deployer deve, tra l'altro, usare il sistema secondo le istruzioni, assegnare la supervisione umana a persone competenti e autorizzate, controllare gli input sotto il proprio controllo quando pertinenti, monitorare il funzionamento, conservare i log sotto il proprio controllo per il periodo previsto e cooperare con provider e autorità. Gli obblighi esatti dipendono dal sistema e dal soggetto. Per un quadro più dettagliato si veda la guida all'art. 26 AI Act sugli obblighi del deployer.

La FRIA non è un obbligo indistinto di ogni deployer: l'analisi comparata tra DPIA e FRIA spiega il perimetro dell'art. 27. Anche gli obblighi privacy restano distinti; per le relazioni con fornitori che trattano dati personali è utile la guida al DPA con fornitori AI.

Date di applicazione dopo il Digital Omnibus

Il Regolamento (UE) 2026/1744 ha sostituito parte dell'art. 113 dell'AI Act. Al 1° agosto 2026:

Queste date non significano che l'intero AI Act sia rinviato. Divieti, alfabetizzazione AI, obblighi sui modelli per finalità generali e trasparenza seguono regimi propri. Una roadmap deve quindi essere costruita per disposizione, sistema e ruolo, non su una sola scadenza generale.

Evidenze da raccogliere per una qualificazione verificabile

Una decisione difendibile dovrebbe essere accompagnata almeno da:

• diagramma dell'architettura e inventario delle componenti;
• identità dei provider a monte e contratti applicabili;
• finalità prevista nelle istruzioni, documentazione e materiali commerciali;
• descrizione dell'uso effettivo e dei soggetti che esercitano controllo;
• nome o marchio con cui il sistema è offerto o messo in servizio;
• modifiche apportate e confronto con quanto previsto dal provider;
• classificazione di rischio prima e dopo eventuali modifiche;
• matrice dei ruoli per ciascun sistema, versione e attività;
• data, responsabile e motivazione della decisione.

Questa matrice evita una perdita frequente di informazioni: assegnare un unico ruolo all'azienda senza distinguere prodotti, versioni, clienti e usi interni. Metodo di compilazione: per ogni riga si annotano fatto osservato, fonte dell'evidenza, soggetto responsabile, data e conseguenza giuridica; le conclusioni senza evidenza restano “da verificare”.

Errori frequenti

«Usiamo un modello di terzi, quindi siamo solo deployer». Non sempre. L'impresa può essere provider di un sistema a valle offerto con il proprio nome.

«Abbiamo fatto fine-tuning, quindi siamo automaticamente provider». Non è un test previsto in questi termini. Occorre applicare definizioni e, se pertinente, condizioni dell'art. 25.

«Il contratto dice che ogni responsabilità è del vendor». Il contratto può ripartire attività, informazioni e responsabilità tra le parti, ma non elimina gli obblighi normativi applicabili verso autorità e persone interessate.

«Provider e deployer sono ruoli esclusivi». La stessa organizzazione può ricoprire ruoli diversi rispetto a sistemi o attività differenti.

«Tutto l'AI Act si applica dal 2 agosto 2026». Dopo il Regolamento (UE) 2026/1744 questa affermazione è inesatta; le date vanno controllate disposizione per disposizione.

Domande frequenti

Chi usa ChatGPT o un'altra AI in azienda è deployer?

In via generale, l'uso professionale di un sistema AI sotto l'autorità dell'organizzazione corrisponde alla definizione di deployer. Occorre comunque individuare il sistema, il soggetto che lo usa e le eventuali altre attività svolte dall'impresa.

Un SaaS che integra un LLM è sempre provider?

No, ma può esserlo rispetto al sistema a valle se sviluppa o fa sviluppare quel sistema e lo offre o mette in servizio con il proprio nome o marchio. La semplice presenza di un'API non basta né a confermare né a escludere il ruolo.

RAG o fine-tuning sono modifiche sostanziali?

Non automaticamente. Si deve verificare se la modifica era prevista nella valutazione iniziale, se incide sulla conformità ai requisiti applicabili o cambia la finalità prevista. Per l'art. 25 conta inoltre la classificazione ad alto rischio.

Il deployer deve sempre svolgere una FRIA?

No. La FRIA dell'art. 27 si applica soltanto ai deployer e ai sistemi che rientrano nello specifico perimetro della norma.

Qual è la data da inserire nella roadmap?

Non esiste una data unica per tutti gli obblighi. Per le sezioni sui sistemi ad alto rischio rilevano ora il 2 dicembre 2027 o il 2 agosto 2028, a seconda della classificazione; altre norme hanno scadenze diverse.

Fonti normative primarie

• Regolamento (UE) 2024/1689 — AI Act, in particolare artt. 3, 6, 25, 26 e 27.
• Regolamento (UE) 2026/1744 — Digital Omnibus sull'AI, in particolare modifiche agli artt. 25, 27, 111 e 113.

Contenuto informativo e Matrice Ingoglia dei ruoli AI aggiornati al 23 agosto 2026. Non sostituiscono la valutazione del caso concreto.