28 Ott AI Act – Fornitore di intelligenza artificiale: quando lo sei, quando lo diventi

Autori: Luca Ceselli, Laura Senatore, Lorenzo Covello

 

Abstract

Capire quando un soggetto si qualifica come fornitore (“provider”) ai sensi dell’AI Act non è immediato. Il confine tra chi sviluppa, distribuisce o integra soluzioni di intelligenza artificiale può essere sottile, specie nei casi di offerte in white label o di riuso e modifica di modelli GPAI. L’articolo analizza i criteri di qualifica e le nuove responsabilità dei soggetti “a valle” nella catena del valore.

 

Informazioni di contesto

Nel lessico del Regolamento europeo sull’Intelligenza Artificiale (“AI Act”)[1], “provider” non è un’etichetta meramente formale. È la chiave che determina in capo a chi vanno riferiti specifici obblighi che vanno dalla mera trasparenza in caso di AI che interagisce con gli esseri umani o che genera e altera contenuti multimediali, fino a requisiti ben più stringenti relativi alla progettazione, alla documentazione, alla governance del rischio e alla sorveglianza dopo l’immissione sul mercato per i sistemi ad alto rischio. Capire se e quando si è provider non è un esercizio accademico: quella che è in primis una qualifica formale incide concretamente su budget, tempi di progetto, allocazione delle responsabilità contrattuali e, a valle, sulla possibilità stessa di portare un sistema in produzione, oltre che sulla strategia della commercializzazione del sistema di AI. L’ambiguità tipica emerge quando un’impresa utilizza tecnologie di terzi – modelli di AI per finalità generali o sistemi pronti – e valuta di apporre il proprio nome o marchio sul prodotto o servizio finale. Un esempio diffuso è quello dei chatbot forniti in white label[2]. La domanda è concreta: sto “solo” distribuendo/impiegando una tecnologia altrui oppure sto assumendo la posizione di provider con tutti gli oneri che ne derivano? Altro punto di non immediata comprensione nella norma è comprendere chi assume il ruolo di provider e di che tipo di sistema di AI quando si integra un modello di AI per finalità generali (“GPAI”) all’interno di un sistema.

 

Scenari applicativi, problemi principali, soluzioni pratiche

La definizione legale di provider ai sensi dell’AI Act si trova nell’art. 3(3)[3]. In estrema sintesi, è provider chi sviluppa un sistema o modello (anche di GPAI) oppure fa sviluppare quel sistema o modello e poi lo immette sul mercato o lo mette in servizio con il proprio nome o marchio, a titolo oneroso o gratuito.

Il legislatore sceglie una attribuzione “funzionale”: guarda all’effettivo controllo tecnico o economico e al branding verso gli utenti, non solo alla paternità del codice. Ne discendono quattro messaggi operativi nel contesto dell’offerta di tecnologia a clienti business.

Primo, commissionare a un terzo lo sviluppo non “scherma” dalla qualifica di provider: se il sistema è sul mercato con il nome di una società, di regola quella società è il provider ai sensi dell’AI Act. Secondo, la gratuità non esclude la qualifica, poiché il Regolamento chiarisce che anche la messa a disposizione “a titolo gratuito” può configurare un’immissione sul mercato. Terzo, il nodo del marchio è decisivo nelle offerte white label: se un’azienda prende un sistema di terzi e lo rilascia sotto il proprio nome, o con il proprio marchio, il Regolamento tende ad attribuirle la qualifica di provider del sistema così presentato, anche qualora il modello sottostante sia sviluppato da altri. Quarto, è importante ricordare che questa analisi riguarda il singolo sistema di AI e non necessariamente l’intero strumento o prodotto in cui esso è integrato: un software può incorporare diversi sistemi di AI, ciascuno con un proprio provider ai sensi dell’AI Act.

Nel valutare quando un soggetto può essere qualificato come provider ai sensi dell’AI Act, un ruolo decisivo è giocato dall’l’art. 25[4], che disciplina i cambi di ruolo lungo la catena del valore (“AI Supply Chain”) per i sistemi ad alto rischio. La norma individua i casi in cui un operatore che non ha sviluppato il sistema – come un importatore, distributore o deployer – può comunque assumere la qualifica di provider e le relative responsabilità.

L’articolo fotografa tre situazioni tipiche.

La prima è il rebranding: quando un distributore, importatore o deployer appone il proprio nome o marchio su un sistema ad alto rischio già immesso o in servizio, diventa il nuovo provider di quel sistema.

La seconda è la “modifica sostanziale”[5]: se un soggetto che sta a valle del provider nella catena del valore (ad es., il deployer) cambia in modo rilevante comportamento, prestazioni, sicurezza o contesto d’uso (come nel caso di modifica all’architettura software o di sostituzione del sistema operativo) di un sistema ad alto rischio, tale soggetto assume la qualifica di provider, con un meccanismo di “successione regolatoria” e doveri di cooperazione tra vecchio e nuovo fornitore per garantire la tracciabilità[6].

La terza riguarda il cambio di finalità prevista[7] (“intended purpose”): chi utilizza un sistema di AI (anche per finalità generali) in un ambito o per delle finalità diverse da quelle previste dal provider, e tali da farlo rientrare nella categoria dei sistemi ad alto rischio ai sensi dell’art. 6, tale soggetto diventa provider in relazione a quello specifico caso d’uso.

In parallelo, la disciplina dei sistemi di AI per finalità generali (“GPAI”) introduce un’ulteriore articolazione nelle valutazioni sulla catena del valore. Nel valutare quando si può divenire provider non si devono considerare solo le disposizioni relative ai sistemi ad alto rischio, ma anche quelle relative ai modelli di AI per finalità generali. In tal senso, occorre precisare che l’art 3(63) introduce altresì il concetto di “downstream provider” o, in italiano, “fornitore a valle”, definito come il soggetto che immette sul mercato o mette in servizio un sistema di AI – incluso un sistema di AI per finalità generali – che incorpora un modello di AI, indipendentemente da chi abbia sviluppato quel modello. In altre parole, il fornitore a valle è colui che integra un modello di AI (sviluppato internamente o ottenuto da terzi) all’interno di un proprio sistema o prodotto, assumendosi così le responsabilità tipiche di un provider in relazione a tale sistema. L’integrazione può avvenire sia quando la stessa impresa sviluppa e incorpora il modello nel proprio sistema; sia quando il modello è fornito da un’altra entità (ad esempio, un GPAI model provider) e viene integrato nel sistema in base a un accordo di licenza o fornitura. Il concetto di fornitore a valle riflette l’approccio dell’AI Act alla catena del valore dell’AI, dove le responsabilità non si esauriscono nel soggetto che sviluppa il modello, ma si estendono anche a chi lo integra, lo adatta o lo distribuisce, in una logica di responsabilità condivisa lungo il ciclo di vita del sistema.

Ma se da un lato la norma contiene una definizione di downstream provider, dall’altro è sicuramente meno immediato comprendere di che tipo di sistema (o modello) si diviene downstream provider; cioè se e quando l’integrazione un modello di AI per finalità generali in un proprio sistema rende l’impresa provider di un sistema o modello di AI per finalità generali.

Il rapporto tra GPAI model provider e fornitore a valle è uno dei punti più complessi dell’AI Act. Il primo è responsabile della conformità e della documentazione del modello di AI per finalità generali (articolo 53), mentre il secondo ne riutilizza o integra il modello per creare un sistema destinato a specifiche applicazioni o settori. In questa relazione, l’AI Act promuove un principio di responsabilità condivisa e cooperazione informativa, imponendo al GPAI model provider di mettere a disposizione del fornitore a valle la documentazione tecnica e gli elementi necessari per garantire che il sistema risultante sia conforme ai requisiti applicabili[8].

Stante questa logica di continuità operativa e regolatoria tra fornitore del modello “a monte” e  il fornitore del sistema “a valle”, le recenti  Linee guida della Commissione europea per i provider di modelli di AI per finalità generali[9]  e le FAQ della Commissione europea[10] forniscono un prezioso chiarimento su quando un soggetto che interviene su un modello di GPAI possa essere considerato, a sua volta, provider del modello di AI risultante. Tali documenti chiariscono in quali circostanze un soggetto “a valle” del provider nella catena del valore, che modifichi un modello (ad esempio attraverso fine-tuning, adattamenti, aggiornamenti o integrazione di componenti che ne cambiano il comportamento) possa diventare provider del modello modificato.

La Commissione riconosce che la questione è complessa e con rilevanti implicazioni economiche, poiché molti operatori modificano o specializzano modelli di base già esistenti. Come precisato anche nel considerando 97 dell’AI Act, il fine-tuning o l’adattamento di un modello può condurre alla creazione di un nuovo modello, ma non ogni modifica comporta automaticamente un cambio di qualifica. La Commissione indica un criterio indicativo affinché un “downstream modifier” (traducibile in italiano come “modificatore a valle”) possa essere considerato il fornitore di un modello di intelligenza artificiale per finalità generali: la potenza di calcolo utilizzata per la modifica o il fine- tuning è superiore a un terzo della potenza di calcolo di addestramento del modello originale[11]. In linea con il considerando 109, gli obblighi previsti per i provider di modelli GPAI (art. 53) devono comunque intendersi limitati alla parte effettivamente modificata. Cioè, gli obblighi da provider dell’attore a valle (downstream modifier) riguarderanno solo la quota parte del modello che è stata effettivamente modificata; ad esempio, il downstream modifier dovrà integrare la documentazione tecnica preesistente con le informazioni relative alle modifiche apportate. Questo aspetto è cruciale nelle architetture AI moderne, dove spesso si parte da un modello base e lo si specializza per un dominio. Se poi quel modello modificato viene redistribuito o integrato in sistemi che ne estendono capacità e portata (superando di un terzo la potenza di calcolo di addestramento del modello originario), l’attore downstream non è più solo utilizzatore, ma assume il profilo di provider del modello risultante, con obblighi di documentazione e trasparenza calibrati sulla porzione realmente sotto il proprio controllo. Chi invece integra il modello di IA per finalità generali in un sistema senza effettuare tale modifica, assumerà la qualifica di downstream provider del sistema (ma non del modello) e dovrà poi qualificare il sistema di IA risultante in base alla classificazione di rischio prevista dall’AI Act.

Cosa vuol dire tutto ciò, in concreto, per i team legali e di prodotto?

Innanzitutto, che la scelta del branding è una decisione regolatoria, oltre che marketing. Se si valuta un chatbot fornito in white label, non bisogna domandarsi solo “chi ha scritto il codice”, ma anche “chi si presenta come responsabile del sistema verso utenti e clienti”, ovvero chi appone il proprio nome e marchio sul sistema di AI. In secondo luogo, occorre valutare se l’uso in concreto previsto è coerente con la finalità prevista (e ammessa) originariamente dal provider e se tale uso porta il sistema dentro una delle categorie ad alto rischio: in tal caso, utilizzi per finalità “nuove”, non ammesse o previste dal provider, possono comportare il passaggio al ruolo di provider. In terzo luogo, se si integra un modello di GPAI in un proprio sistema si può divenire provider del sistema di AI che ne risulta, che dovrà essere classificato in base ai criteri di rischio dell’AI Act. In quarto luogo, se si modifica un modello di GPAI (riaddestrandolo usando almeno un terzo della potenza di calcolo usata per l’addestramento originario), si può divenire provider della porzione nuova di GPAI model; occorrerà quindi mappare con precisione cosa è stato cambiato e con quali effetti: la documentazione e l’accountability rispetto alla porzione modificata saranno uno strumento chiave per dimostrare il perimetro degli obblighi applicabili.

 

Conclusioni

Le nozioni presentate sono lineari nella teoria, ma richiedono disciplina nella pratica applicativa. Le implicazioni non si fermano sulla carta ma hanno impatti economici importanti.

Essere provider, specie nel caso di AI ad alto rischio, significa governare l’intero ciclo di vita del sistema o del modello per la parte sotto la propria responsabilità: dalla progettazione fino al monitoraggio successivo all’immissione sul mercato. Restare deployer può essere meno impattante, ma in ogni caso non si tratta di uno scenario privo di oneri: cambiano la prospettiva e gli strumenti organizzativi.

Per questo motivo i contratti con fornitori upstream (cioè dei fornitori che si collocano a monte della catena del valore AI) e partner tecnologici devono riflettere con chiarezza chi è provider di cosa, soprattutto quando si lavora in white label o si effettuano modifiche sostanziali, oltre che chiarire quali sono le finalità di utilizzo ammesse (intended puposes).

A livello di governance, conviene introdurre un meccanismo di filtro regolatorio nelle decisioni che precedono l’immissione sul mercato: prima di lanciare un nuovo prodotto “AI by [Brand]”, occorre effettuare le opportune verifiche rispetto a branding, controllo tecnico, finalità d’uso e impatto del fine-tuning. Per i sistemi ad alto rischio, questo test va integrato nella gestione della conformità di prodotto e nella sorveglianza successiva all’immissione sul mercato, coordinando ruoli e flussi informativi tra soggetti a monte e a valle, come richiede l’art. 25.

Sul versante dei modelli di AI per finalità generali (GPAI), invece, quando si integra un modello di GPAI in un sistema proprietario, bisogna analizzare il sistema che ne risulta e classificarlo secondo i criteri di rischio dell’AI Act. Se si addestra un modello di GPAI usando almeno un terzo della potenza di calcolo usata per addestrare il modello originario, allora si può divenire provider della nuova porzione di modello. Ne consegue che le organizzazioni dovrebbero istituire registri delle modifiche e dei dataset utilizzati per eventuali attività di fine-tuning e l’adattamento dei modelli, così da poter dimostrare se e di quale porzione del modello sono da considerarsi provider.

In tutti questi casi, il branding non è solo una decisione commerciale, ma può diventare assunzione di responsabilità. Per le imprese che valutano offerte white label o integrazioni su modelli esistenti, il passo successivo è istituzionalizzare un check di qualifica prima del lancio: individuare per tempo chi è provider, di che cosa, e quali obblighi vanno pianificati. È questo, in definitiva, il modo pragmatico per trasformare la domanda “siamo deployer o provider?” da rischio latente a leva di compliance e affidabilità commerciale.

 

Takeaway operativi

 

1. 1. Verificare con precisione chi riveste la qualifica di “provider”

È provider chi sviluppa – o fa sviluppare – un sistema di AI o un modello GPAI e lo immette sul mercato o lo mette in servizio sotto il proprio nome o marchio, anche gratuitamente. La qualifica deriva non solo dallo sviluppo, ma anche dal controllo tecnico, economico o di branding esercitato sul sistema o modello.

 

1. 2. In caso di sistemi di AI ad alto rischio, prestare attenzione a:
      • Rebranding

L’apposizione di un nuovo marchio o nome commerciale su un sistema di AI ad alto rischio già immesso sul mercato o messo in servizio comporta, ai sensi dell’articolo 25 dell’AI Act, l’assunzione della qualifica di provider da parte del soggetto che effettua il rebranding, con i relativi obblighi di conformità e documentazione.

• • • Modifiche Sostanziali

La modifica sostanziale di un sistema di AI ad alto rischio – ad esempio variazioni rilevanti del comportamento, delle prestazioni, della sicurezza o del contesto d’uso, come nel caso di aggiornamenti significativi dell’architettura software o del sistema operativo – determina parimenti un cambio di qualifica: il soggetto che effettua la modifica diventa provider del sistema risultante e deve garantire la tracciabilità e la cooperazione con il fornitore originario.

• • • Coerenza con le finalità d’uso originarie (“intended purposes”)

L’impiego di un sistema di AI per finalità diverse da quelle previste dal provider originario può determinare un cambio di qualifica, in particolare quando il nuovo utilizzo rientra tra i sistemi ad alto rischio ai sensi dell’art. 6 dell’AI Act

 

1. 3. Individuare correttamente quando si diventa “downstream provider”

L’integrazione di un modello di AI – anche di tipo GPAI – all’interno di un sistema o prodotto proprietario comporta la qualifica di downstream provider del sistema risultante. In tale caso occorre:

• • • classificare il sistema secondo il livello di rischio previsto dall’AI Act;
    • verificare la documentazione tecnica relativa al modello (cfr. Annex XII dell’AI Act).

 

1. 4. Distinguere tra integrazione e modifica di un modello GPAI.

L’integrazione “as is” di un modello GPAI non determina la qualifica di provider del modello, ma soltanto del sistema che lo incorpora, se tale sistema è poi messo sul mercato con il proprio nome o marchio. Tuttavia, qualora il modello sia modificato (ad esempio mediante riaddestramento) e la potenza di calcolo impiegata per tali operazioni superi un terzo di quella utilizzata per l’addestramento originario, il soggetto diviene provider della nuova porzione di modello.

 

1. 5. Documentare in modo puntuale modifiche e dataset utilizzati.

In presenza di attività di riaddestramento dei modelli GPAI, è necessario mantenere registri delle modifiche effettuate, dei dataset utilizzati e della potenza computazionale impiegata, al fine di circoscrivere gli obblighi di provider alla parte effettivamente modificata e dimostrare tracciabilità e accountability.

 

1. 6. Definire chiaramente ruoli e responsabilità nei contratti.

Gli accordi stipulati tra gli operatori lungo la catena del valore dell’AI devono avere clausole specificamente dedicate a garantire la compliance delle attività all’AI Act. Tali clausole dovrebbero essere redatte tenendo in considerazione:

• • • • come il sistema è stato allenato (prevedendo clausole che garantiscono che il training è avvenuto in compliance con le normative a protezione dei dati personali e della proprietà intellettuale)
      • i ruoli degli operatori della catena del valore (stabilendo quale parte è provider, quale deployer e quale distributor o importer)
      • la classificazione del sistema di IA (descrivendo il sistema di AI ed il modello di GPAI su cui eventualmente si fonda e specificando anche le finalità di uso ammesse)
      • il momento di entrata in vigore delle disposizioni dell’AI Act applicabili.

 

 

[1] Regolamento (UE) 2024/1689 del Parlamento europeo e del Consiglio del 13 giugno 2024 sull’intelligenza artificiale (AI Act), in Gazzetta ufficiale dell’Unione europea L 202 del 12 luglio 2024, disponibile su EUR-Lex.

[2] Per white label si intende un “Prodotto realizzato da un’azienda ma commercializzato da un’altra con il proprio nome” (traduzione dell’autore da: “A product that is made by one company but sold by another company using their own name”, Oxford University Press, Oxford Advanced Learner’s Dictionary, 2025).

[3] Ibidem.

[4] Ibidem.

[5] Secondo l’articolo 3 (23) dell’AI Act per “modifica sostanziale” si intende “una modifica di un sistema di AI a seguito della sua immissione sul mercato o messa in servizio che non è prevista o programmata nella valutazione iniziale della conformità effettuata dal fornitore e che ha l’effetto di incidere sulla conformità del sistema di AI ai requisiti di cui al capo III, sezione 2, o comporta una modifica della finalità prevista per la quale il sistema di AI è stato valutato”.

[6] Secondo il considerando (128) dell’AI Act, non costituisce una “modifica sostanziale” il caso in cui un sistema di intelligenza artificiale continui ad apprendere o adattarsi automaticamente dopo l’immissione sul mercato o la messa in servizio, purché tali evoluzioni siano state previste dal fornitore e valutate in sede di conformità iniziale. In altre parole, l’auto-apprendimento controllato e documentato rientra nel perimetro del sistema originario, senza far scattare una nuova qualifica di fornitore.

[7]  Secondo l’art. 3 (12) dell’AI Act per “finalità prevista” si intende “l’uso di un sistema di AI previsto dal fornitore, compresi il contesto e le condizioni d’uso specifici, come dettagliati nelle informazioni comunicate dal fornitore nelle istruzioni per l’uso, nel materiale promozionale o di vendita e nelle dichiarazioni, nonché nella documentazione tecnica”.

[8] Per ulteriori dettagli si rinvia all’Allegato XII dell’AI Act.

[9] Commissione europea, Guidelines on the scope and the obligations of providers of general-purpose AI models under the AI Act, luglio 2025, disponibili su Shaping Europe’s Digital Future.

[10] FAQ della Commissione europea sui modelli di AI per finalità generali: General-Purpose AI Models in the AI Act – Questions & Answers | Shaping Europe’s digital future.

[11] Ibidem, Sezione 3.2. e, in particolar modo, paragrafo (63).