Secondo l’AI Act, essere classificato come fornitore (provider) o utilizzatore (deployer) significa avere obblighi completamente diversi.
Eppure, nel lavoro digitale di oggi, il confine tra chi usa e chi “fornisce” intelligenza artificiale è molto più sottile di quanto sembri.
La differenza fondamentale è questa: il fornitore risponde di ciò che il sistema “È” (design, capacità, limiti), mentre l’utilizzatore risponde di “come il sistema VIENE USATO” (contesto operativo, supervisione, monitoraggio).
Da questa distinzione dipendono responsabilità legali, costi di compliance e sanzioni che possono arrivare fino a 35 milioni di euro o al 7% del fatturato mondiale.
Facciamo un esempio: un’agenzia di comunicazione sviluppa per un cliente un assistente virtuale che risponde alle domande dei consumatori. Per farlo, usa l’API di un modello open-source, aggiunge un po’ di codice, un’interfaccia grafica, il proprio logo e lo lancia come “AI Assistant per Brand X”.
Un classico progetto quotidiano.
Ma agli occhi del Regolamento, quell’agenzia non è più soltanto un “utilizzatore” dell’AI: è un fornitore, con obblighi ben più gravosi rispetto a chi usa semplicemente ChatGPT come strumento operativo.
La buona notizia è che con le giuste strategie contrattuali e organizzative, è possibile continuare a lavorare con l’AI mantenendo lo status di utilizzatore, riducendo al minimo rischi e costi.
CONTENUTO DELL'ARTICOLO
- 1 Chi è il fornitore/provider?
- 2 Chi è l’utilizzatore/deployer secondo l’Ai Act?
- 3 Quando l’utilizzatore diventa fornitore
- 4 AI Act e mondo del lavoro: datore, dipendente e freelance
- 5 Cosa cambia in pratica per agenzie, sviluppatori e creativi
- 6 Obblighi di fornitore e utilizzatore a confronto
- 7 Sanzioni e scadenze: la struttura multilivello dell’AI Act
- 8 Come mettersi in regola: la consulenza Legal for Digital
Chi è il fornitore/provider?
L’AI Act adotta un approccio funzionale, non dimensionale: non conta la grandezza dell’azienda, ma l’azione che compie. Il fornitore, o provider, è definito come qualsiasi persona fisica o giuridica che sviluppa un sistema di IA o lo immette sul mercato con il proprio nome o marchio. Questa definizione va ben oltre le grandi aziende tecnologiche, includendo potenzialmente software house, agenzie di comunicazione e persino freelance.
Il ruolo di fornitore scatta, spesso involontariamente, in tre scenari molto comuni nel settore digitale:
- Sviluppo per conto terzi con marchio proprio: un’agenzia commissiona a uno sviluppatore esterno la creazione di un chatbot ma lo offre ai propri clienti come “soluzione proprietaria”. Anche senza aver scritto una riga di codice, l’agenzia diventa legalmente il fornitore.
- Integrazione in un servizio commerciale: un’agenzia integra l’API di un modello di terze parti (es. GPT-4) in una piattaforma o dashboard che vende ai clienti. In questo caso, l’AI Act considera la “messa in servizio” sotto il proprio marchio, rendendo l’agenzia responsabile del sistema integrato.
- Modifica sostanziale di un sistema esistente: un intervento tecnico che altera il comportamento o la finalità di un modello, come un retraining su dati proprietari o un’interfaccia che ne espande le funzioni, può essere considerato una “modifica sostanziale” ai sensi dell’Art. 25 del regolamento. Chi effettua tale modifica assume il ruolo di nuovo fornitore.
Obblighi del fornitore secondo l’AI Act
Essere fornitore non è solo una definizione legale, ma un salto di responsabilità.
L’AI Act prevede una serie di obblighi precisi che trasformano il modo di progettare e distribuire sistemi AI:
- Sistema di gestione della qualità e dei rischi: devi poter dimostrare di avere processi interni per controllare e documentare i rischi del sistema, dalla progettazione fino al rilascio
- Documentazione tecnica completa (Annex IV): serve a certificare che il tuo sistema è conforme ai requisiti di legge. È ciò che un’autorità di controllo ti chiederà in caso di verifica.
- Dati di training e testing: hai l’obbligo di garantire che i dati siano di alta qualità, rappresentativi e non discriminatori. L’AI Act considera il dataset il primo strato di responsabilità.
- Sorveglianza umana e robustezza: devi assicurare che l’AI resti “comprensibile” e controllabile. Anche nei sistemi più automatizzati deve esserci una supervisione umana documentata.
- Registrazione nella banca dati UE: se il sistema è classificato come ad alto rischio, va registrato prima della commercializzazione o della messa in servizio.
Praticamente essere fornitore significa garantire che il tuo sistema AI sia sicuro, trasparente e tracciabile, e poterlo dimostrare in ogni momento.
Il fornitore avanzato: i Codici di Condotta GPAI
Per i fornitori che lavorano con modelli di IA per finalità generali (GPAI), definiti come modelli che mostrano una generalità e sono in grado di svolgere una vasta gamma di compiti distinti, come i grandi modelli linguistici (LLM), è stato introdotto un ulteriore livello di conformità. I Codici di Condotta GPAI, pur essendo volontari, sono stati approvati dall’AI Office della Commissione Europea come strumento adeguato per dimostrare la conformità agli articoli 53 e 55 dell’AI Act, le cui disposizioni sono applicabili dall’agosto 2025.
I codici si articolano in tre capitoli distinti:
- Trasparenza (applicabile a tutti i fornitori di GPAI): Impone la redazione e il mantenimento di una documentazione tecnica esaustiva tramite un “Modulo di Documentazione del Modello” standardizzato. Questo documento deve includere dettagli su architettura, dati di addestramento, risultati dei test e persino il consumo energetico, e deve essere messo a disposizione dei fornitori a valle (i deployer).
- Diritto d’Autore (applicabile a tutti i fornitori di GPAI): Richiede l’adozione di una politica formale sul copyright. Le misure pratiche includono il rispetto degli opt-out leggibili meccanicamente (es. robots.txt), l’astensione dall’uso di dati provenienti da siti noti per violare il copyright, l’implementazione di tutele tecniche contro la generazione di contenuti illeciti e la creazione di un meccanismo per la gestione dei reclami da parte dei titolari dei diritti.
- Sicurezza (applicabile solo ai GPAI con rischio sistemico): Questo capitolo riguarda i modelli più potenti e avanzati.Gli obblighi includono valutazioni avanzate del modello (red-teaming), valutazione e mitigazione dei rischi, protezione della cibersicurezza e segnalazione obbligatoria degli incidenti gravi all’AI Office.
Questi codici non impattano solo i fornitori. Essi creano un nuovo standard di diligenza per gli utilizzatori. Un’agenzia digitale che costruisce un prodotto basato su un modello GPAI non può più limitarsi a “usare l’API”. Per garantire la propria conformità, ha ora un forte incentivo legale e commerciale a richiedere al fornitore del GPAI il Modulo di Documentazione del Modello. Questo documento è essenziale per comprendere le capacità, i limiti e i rischi del modello sottostante, informazioni necessarie per un suo impiego responsabile. La scelta di un fornitore di API non si baserà più solo sulle performance, ma anche sulla qualità e completezza della sua documentazione di conformità.
Corso Legale utilizzo IA
14 lezioni teoriche e pratiche sull’IA
Con questo corso potrai imparare, tra l’altro:
- Tutti gli aspetti fondamentali della legge sull’IA
- Elementi legali indispensabili per la tutela per l’IA
- Diritto d’autore e copyright sui contenuti creati
- Come gestire i dati utilizzati dall’IA
- Responsabilità legali per l’utilizzo della IA
- Prevenzione di controversie legali con i clienti
Il nostro corso esclusivo su tutto quello che ti serve sapere per approcciare al mondo dell’intelligenza artificiale senza rischi legali e con la consapevolezza di sfruttare tool come ChatGpt, Dall-E o Midjourney in modo performante e sicuro.
Chi è l’utilizzatore/deployer secondo l’Ai Act?
Una volta chiarito chi crea o distribuisce un sistema AI, bisogna guardare all’altro lato della catena: chi lo usa.
L’utilizzatore, o deployer, nel linguaggio del Regolamento, è chi impiega un sistema di intelligenza artificiale sotto la propria autorità, nel contesto della propria attività o di quella di un cliente.
Non è uno sviluppatore, ma un “operatore”.
Un ruolo che accomuna una varietà enorme di soggetti:
- un social media manager che usa ChatGPT per scrivere testi;
- un’agenzia che implementa un assistente virtuale su un sito cliente;
- un’azienda che utilizza un modello predittivo per analizzare dati di mercato.
Tutti loro sono deployer: non progettano il sistema, ma ne gestiscono l’uso nel contesto operativo.
Obblighi dell’utilizzatore secondo l’Ai Act
L’utilizzatore non è un soggetto passivo. L’AI Act gli affida un ruolo attivo nella sicurezza e nella tracciabilità, con obblighi precisi:
- Uso conforme alle istruzioni del fornitore: se il sistema è pensato per una finalità specifica, non puoi spingerlo oltre i limiti previsti. Ad esempio, usare un modello per selezionare persone se era nato per analisi linguistica può far scattare una riqualificazione a fornitore.
- Supervisione umana: devi poter dimostrare che una persona è in grado di monitorare e intervenire sul funzionamento dell’AI. Non basta “fidarsi” del sistema.
- Segnalazione di incidenti o rischi gravi: se l’AI produce risultati che generano danni, errori o rischi discriminatori, l’utilizzatore è tenuto a comunicarlo alle autorità.
- Conservazione dei log: i registri automatici devono essere mantenuti almeno per sei mesi. Servono a garantire tracciabilità, verifiche e audit futuri.
- Verifica della registrazione UE: prima di utilizzare un sistema ad alto rischio, devi controllare che sia correttamente registrato nella banca dati europea.
Quindi anche chi usa l’AI deve essere in grado di dimostrare come e in che condizioni lo fa.
L’idea è creare una catena di responsabilità continua: dal produttore al professionista che mette il sistema in funzione.
Il Deployer professionale: la Legge 132/2025
In Italia, la Legge n. 132/2025 ha introdotto un livello di regolamentazione specifico che si sovrappone agli obblighi dell’AI Act, imponendo un dovere di trasparenza rafforzato per le “professioni intellettuali” (avvocati, commercialisti, consulenti, ingegneri, ecc.). L’articolo 13 di questa legge si fonda su due principi:
- Prevalenza del lavoro umano: l’IA può essere usata solo per attività “strumentali e di supporto”, con la garanzia che il lavoro intellettuale umano rimanga prevalente nella prestazione d’opera.
- Obbligo di trasparenza: il professionista deve comunicare al cliente, con un linguaggio “chiaro, semplice ed esaustivo”, le informazioni relative ai sistemi di IA utilizzati.
Questo obbligo trasforma l’uso dell’IA, facendolo passare da scelta operativa interna a elemento essenziale del contratto con il cliente. La documentazione contrattuale, come lettere d’incarico e mandati professionali, deve essere aggiornata per includere:
- La dichiarazione esplicita sull’eventuale utilizzo di sistemi di IA
- La tipologia di strumenti adottati e la loro provenienza (interni o di terze parti)
- Le misure di sicurezza implementate per proteggere la riservatezza dei dati del cliente
- La conferma che ogni elaborazione automatizzata sarà sempre soggetta a verifica e supervisione umana.
È fondamentale sottolineare che questa norma non attenua in alcun modo la responsabilità personale del professionista. Qualsiasi errore o imprecisione derivante da un sistema di IA è considerato un errore del professionista stesso, che ne risponde in toto.
Se storicamente gli strumenti utilizzati da un professionista (software, banche dati) non venivano menzionati nel contratto, la Legge 132/2025 isola l’IA come una tecnologia la cui divulgazione è obbligatoria. La ragione risiede nella sua capacità di produrre risultati che mimano il lavoro intellettuale, confondendo il confine con il contributo umano. Imponendo la trasparenza, il legislatore mira a preservare il “rapporto fiduciario”, costringendo il professionista a rimanere responsabile e a non nascondersi dietro un algoritmo.
Guida gratuita sull’Intelligenza Artificiale
43 pagine formative gratuite sull’intelligenza artificiale
SFOGLIA L’ANTEPRIMA
Una Guida esclusiva di 43 pagine per gestire l’uso dell’intelligenza artificiale nel tuo lavoro senza pericoli di natura legale.
Lo strumento gratuito migliore per affacciarsi al mondo dell’intelligenza artificiale!
Quando l’utilizzatore diventa fornitore
Un deficit di AI literacy espone l’organizzazione a rischi gravi, il principale dei quali è la riqualificazione involontaria da utilizzatore a fornitore. L’articolo 25 dell’AI Act delinea tre “scivolate legali” che un’organizzazione senza un’adeguata consapevolezza potrebbe compiere senza rendersi conto delle profonde conseguenze:
- Apposizione del proprio marchio (re-branding): lanciare un sistema di IA sviluppato da terzi con il proprio logo o nome commerciale. Esempio: un’agenzia che offre “CopyStudio AI”, basato su tecnologia GPT-4, diventa il fornitore
- Modifica sostanziale del sistema: Alterare in modo rilevante il codice, i parametri o la finalità di un sistema esistente. Esempio: uno sviluppatore che personalizza profondamente un modello open-source per un cliente
- Cambio di finalità che genera un rischio alto: Utilizzare un sistema di IA per uno scopo nuovo che lo classifica come “ad alto rischio”. Esempio: un modello nato per analisi linguistiche viene riadattato per preselezionare candidati in un processo di assunzione
In ciascuno di questi casi, l’utilizzatore assume automaticamente tutti gli obblighi del fornitore, inclusa la redazione della documentazione tecnica, la gestione della qualità e la potenziale marcatura CE.
In sostanza: ci sono tre “scivolate legali” molto comuni.
| Situazione | Cosa accade | Esempio concreto |
| Apposizione del proprio marchio | Diventi fornitore se marchi un sistema AI con il tuo logo o nome | Un’agenzia lancia “CopyStudio AI” basato su GPT-4 |
| Modifica sostanziale del sistema | Cambi codice, parametri o finalità in modo rilevante | Uno sviluppatore personalizza un modello open-source per un cliente |
| Cambio di finalità che genera rischio alto | Usi un’AI per scopi nuovi che la rendono “ad alto rischio” | Un modello nato per analisi linguistiche viene usato per selezionare candidati HR |
In ognuno di questi casi, l’utilizzatore assume automaticamente tutti gli obblighi del fornitore: documentazione tecnica, marcatura CE, gestione qualità e tracciabilità.
È una distinzione importante perché cambia anche la distribuzione della responsabilità: se il modello causa un danno, la colpa non ricade più sul fornitore originario ma su chi l’ha modificato o “rimarchiato”.
Un passaggio spesso sottovalutato, e costoso.
AI Act e mondo del lavoro: datore, dipendente e freelance
Finora abbiamo guardato all’AI Act dal punto di vista dei sistemi e dei ruoli tecnici.
Ma il regolamento tocca anche il mondo del lavoro, distinguendo tra datore di lavoro (deployer aziendale), dipendente e lavoratore autonomo.
Datore di lavoro = deployer aziendale
Quando un’azienda utilizza l’AI per gestire persone, per assunzioni, valutazioni, sicurezza, diventa automaticamente un deployer di sistemi ad alto rischio.
Qui l’AI Act entra in gioco per tutelare i lavoratori e garantire trasparenza.
Il datore di lavoro deve:
- informare il personale sull’uso di sistemi AI e sulle loro finalità;
- garantire formazione e alfabetizzazione digitale (AI literacy);
- prevedere supervisione umana per ogni decisione automatizzata;
- vietare sistemi di riconoscimento emotivo o di manipolazione cognitiva sul posto di lavoro.
In pratica, l’AI può supportare le decisioni HR, ma non può sostituire il giudizio umano.
Lavoratore autonomo e freelance
Il professionista indipendente, invece, usa l’AI come strumento di potenziamento.
Non ha vincoli gerarchici, ma resta pienamente responsabile delle proprie decisioni e dei risultati prodotti.
L’AI non deve mai diventare “l’autore invisibile” del lavoro: il professionista deve informare il cliente quando l’ha utilizzata e deve poter giustificare il processo decisionale finale.
Cosa cambia in pratica per agenzie, sviluppatori e creativi
A questo punto, la distinzione tra fornitore e utilizzatore si traduce in scelte operative quotidiane.
Non dipende dal ruolo aziendale, ma da quanto controllo eserciti sul sistema AI.
Ecco i casi più frequenti:
- Se usi un’API di OpenAI per scrivere testi per i tuoi clienti, sei utilizzatore
- Se rivendi un’app che integra quella API con il tuo brand, sei fornitore
- Se addestri un modello sui dati del cliente, torni a essere fornitore
- Se usi l’AI solo internamente, resti utilizzatore, ma con obblighi di trasparenza e supervisione.
Molti professionisti del digitale si muovono in un territorio ibrido: un piede nel ruolo di fornitore, l’altro in quello di utilizzatore.
Quelli che devi fare è mappare l’uso dell’AI, aggiornare i contratti e definire ruoli chiari in ogni progetto.
Casi pratici per agenzie, sviluppatori e freelance digitali
La teoria è chiara, ma nella pratica quotidiana le linee si confondono rapidamente.
Ecco sei scenari tipici che mostrano come cambia il tuo ruolo, e i tuoi obblighi, a seconda di come usi l’intelligenza artificiale.
1. Usare ChatGPT, Claude o Gemini per i progetti cliente → Utilizzatore
Finché usi modelli generativi as-is, tramite browser o API standard, resti utilizzatore.
Non sviluppi, non modifichi, non marchi: il fornitore rimane OpenAI, Anthropic o chi ha creato il modello.
Obblighi: seguire le istruzioni del provider, mantenere supervisione umana nei processi ad alto rischio, conservare log per 6 mesi, garantire AI literacy minima ai collaboratori.
Attenzione: se inizi a presentare la soluzione come “il nostro sistema AI proprietario” o la marchi col tuo logo, stai scivolando verso lo status di fornitore.
Se si opera in Italia come “professionista intellettuale”, si è soggetti all’obbligo di trasparenza della Legge 132/2025 e si deve informare il cliente.
2. Fare fine-tuning o customizzare un modello → Potenzialmente fornitore
Qui entri nella zona grigia: le linee guida UE indicano che chi modifica un modello diventa fornitore se la modifica è sostanziale (oltre 1/3 della potenza di training originale).
Nella pratica quotidiana delle agenzie, la soglia è raramente superata, ma conta l’impatto della modifica.
I Codici di Condotta GPAI chiariscono che attività come il RAG (Retrieval-Augmented Generation) o il prompt engineering non fanno scattare il ruolo di fornitore.
Un fine-tuning profondo che altera il comportamento del modello, invece, può costituire una “modifica sostanziale”, trasformando l’operatore in fornitore.
3. Costruire un chatbot custom per un cliente → Dipende dal brand
Se consegni un chatbot sotto il marchio del cliente, il cliente è il fornitore.
Se lo lanci sotto il tuo marchio, il fornitore sei tu.
La strategia contrattuale diventa ancora più rilevante. Il contratto con il cliente deve specificare esplicitamente chi è il “fornitore” che immette il sistema sul mercato per allocare correttamente i rischi e gli obblighi
4. Integrare API AI di terze parti in un’applicazione → Di norma utilizzatore
Si è un Utilizzatore, a patto di non fare re-branding. Come utilizzatore diligente, si dovrebbe richiedere al fornitore dell’API la sua documentazione di conformità, specialmente se si tratta di un modello GPAI, per valutare i rischi associati.
5. E-commerce con motori di raccomandazione → Tipicamente utilizzatore
Si è tipicamente un Utilizzatore. Il fornitore è il venditore della piattaforma (es. Shopify, Algolia). Questo scenario rimane un chiaro esempio di ruolo di utilizzatore.
6. Fare prompt engineering e creare librerie di prompt → Sempre utilizzatore
Se questo servizio viene venduto in Italia come consulenza professionale, si applica la Legge 132/2025. È necessario essere trasparenti con il cliente riguardo agli strumenti utilizzati per sviluppare e testare i prompt.
Obblighi di fornitore e utilizzatore a confronto
| Aspetto | Fornitore | Utilizzatore |
| Focus principale | Design, sviluppo, conformità di mercato | Uso operativo, monitoraggio, implementazione corretta |
| Documentazione | Estesa: doc tecnica (Allegato IV), sistema gestione qualità, Dichiarazione UE, log per 10 anni | Moderata: valutazione impatto diritti fondamentali, log per 6 mesi, registri d’uso |
| Gestione del rischio | Deve istituire sistema completo di risk management | Deve monitorare rischi durante l’operatività e segnalare problemi |
| Supervisione umana | Deve progettare meccanismi di supervisione NEL sistema | Deve assegnare personale formato PER supervisionare il sistema |
| Dati | Governance completa per dati training/validazione/test | Controllo qualità dati in input quando sotto suo controllo |
| Valutazione conformità | Obbligatoria, con certificazione | Non richiesta |
| Marcatura CE | Obbligatoria per alto rischio | Non richiesta |
| Registrazione database UE | Obbligatoria per sistemi Allegato III | Solo autorità pubbliche devono verificare registrazione |
Sanzioni e scadenze: la struttura multilivello dell’AI Act
L’AI Act non introduce solo regole di principio, ma un vero e proprio sistema sanzionatorio a più livelli, calibrato in base alla gravità della violazione e al ruolo svolto (fornitore o utilizzatore).
Come nel GDPR, l’obiettivo è dissuadere comportamenti rischiosi e garantire responsabilità lungo tutta la filiera dell’intelligenza artificiale.
Sanzioni pecuniarie
Le multe previste sono tutt’altro che simboliche:
- fino a 35 milioni di euro o al 7% del fatturato mondiale per le pratiche vietate, come la manipolazione cognitiva, il social scoring o l’uso del riconoscimento emotivo in ambito lavorativo;
- fino a 15 milioni di euro o al 3% del fatturato mondiale per la violazione degli obblighi sui sistemi ad alto rischio (es. mancata documentazione tecnica, assenza di sorveglianza umana, uso non autorizzato);
- fino a 7,5 milioni di euro o all’1% del fatturato mondiale per la fornitura di informazioni false o incomplete alle autorità di controllo.
Le sanzioni sono graduabili: ogni Stato membro deve considerare la natura, la gravità e la durata della violazione, le sue conseguenze e la dimensione dell’operatore, con un’attenzione particolare a PMI e start-up.
Per queste ultime, infatti, il Regolamento stabilisce che la sanzione non potrà superare la percentuale o l’importo più basso tra quelli previsti.
Per conoscere tutto il sistema sanzionatorio legato alla violazione dell’AI Act, leggi qui.
Altre misure di esecuzione
Le autorità competenti possono, in aggiunta, adottare misure correttive immediate, anche più impattanti sul piano operativo e reputazionale.
Tra queste:
- la sospensione temporanea o definitiva dell’uso del sistema AI in azienda;
- il ritiro dal mercato del sistema o del prodotto che lo integra;
- la revoca della registrazione europea per i sistemi ad alto rischio non conformi.
Questi provvedimenti possono bloccare intere linee di business e generare danni economici e d’immagine difficilmente recuperabili, specie per chi offre soluzioni digitali o servizi AI-based.
La vera sanzione, in molti casi, è la perdita di affidabilità sul mercato.
Come mettersi in regola: la consulenza Legal for Digital
Tutto parte da qui: capire che ruolo hai nell’ecosistema dell’AI significa sapere fino a dove arrivano le tue responsabilità. Il resto è strategia, non teoria.
L’AI Act non va subìto, va compreso e gestito.
Per agenzie, sviluppatori e freelance che lavorano ogni giorno con strumenti di intelligenza artificiale, questo significa trasformare la compliance in metodo di lavoro: sapere cosa fare, cosa delegare e cosa documentare.
Legal for Digital aiuta imprese e professionisti a fare proprio questo.
Dal primo audit al rilascio della documentazione, offriamo percorsi pratici e personalizzati per ogni tipo di progetto AI:
- Audit di conformità AI Act per mappare ruoli, responsabilità e rischi
- Contratti e policy AI-safe, scritti per proteggerti e tutelare i clienti
- Formazione operativa per team digitali, con casi reali e strumenti pratici
- Supporto continuo nella documentazione tecnica e nei rapporti con i fornitori tech.
Lavorare con l’AI in modo consapevole non è solo un obbligo. È il modo più intelligente per restare competitivi.
