AI Act: sei provider o deployer?
La domanda vera è un’altra: che ruolo ho, giuridicamente, quando uso o integro un sistema di AI?
Perché nell’AI Act non conta solo “cosa fai” con l’intelligenza artificiale. Conta anche chi sei rispetto a quel sistema. E se non sai chi sei, non sai nemmeno da dove partire.
Provider e deployer: perché la distinzione conta davvero
Nel linguaggio comune usiamo spesso la parola “utente” in modo generico.
Uso ChatGPT. Uso Claude. Uso un tool AI per generare immagini. Ho integrato un modello nel mio servizio. Uso un software HR con funzioni predittive. Ho creato una piattaforma basata su API di intelligenza artificiale.
Dal punto di vista operativo sembrano tutte varianti dello stesso fenomeno: qualcuno usa l’AI per lavorare meglio, più velocemente o in modo più scalabile.
Dal punto di vista dell’AI Act, invece, possono essere situazioni molto diverse.
Il regolamento europeo sull’intelligenza artificiale adotta un approccio basato sul rischio e prevede obblighi diversi in base al ruolo dell’operatore, al tipo di sistema utilizzato e al contesto di impiego. Per questo la distinzione tra provider e deployer non è un tecnicismo: è il punto di partenza della compliance.
In termini essenziali, il provider è il soggetto che sviluppa, o fa sviluppare, un sistema di AI o un modello di uso generale e lo immette sul mercato o lo mette in servizio sotto il proprio nome o marchio. Il deployer, invece, è chi utilizza un sistema di AI sotto la propria autorità in un contesto professionale, escluso l’uso personale non professionale.
Semplificando: se costruisci o commercializzi un sistema AI sotto il tuo nome, potresti essere provider. Se usi un sistema AI sviluppato da altri nel tuo lavoro o nella tua organizzazione, potresti essere deployer.
Ma la realtà, come spesso accade, è meno pulita delle definizioni.
Il perimetro è molto più ampio di quanto sembri
Molti leggono “AI Act” e pensano immediatamente alle grandi piattaforme, ai laboratori di ricerca, alle società che sviluppano modelli di intelligenza artificiale.
È un errore comprensibile, ma pericoloso perchè il perimetro dei soggetti coinvolti è molto più ampio.
Può rientrare il professionista che usa un sistema di AI per analizzare documenti, sintetizzare materiali o supportare ricerche. Può rientrare il digital marketer che utilizza strumenti generativi per creare testi, immagini, varianti di annunci o segmentazioni. Può rientrare l’agenzia che produce presentazioni, campagne, contenuti e report con il supporto di strumenti AI. Può rientrare la PMI che integra AI nel customer care, nella gestione dei lead, nella selezione del personale o nell’analisi dei dati.
E possono rientrare, con un profilo ancora diverso, le startup che costruiscono un servizio basato su API di modelli come GPT, Claude o altri sistemi di AI, dove il modello non è un semplice strumento interno, ma diventa il cuore del prodotto offerto ai clienti.
In tutti questi casi, la domanda non è più astratta.
Sto solo usando uno strumento o sto mettendo a disposizione un sistema? Sto operando per me o per altri? Sto usando l’AI sotto la mia autorità o sto creando un servizio che altri useranno sotto il mio nome? Sto modificando l’uso previsto del sistema? Sto incidendo su persone, dati, decisioni, accesso a servizi, lavoro, credito, salute, istruzione?
Da queste risposte dipende molto più di quanto sembri.

Foto di Zach M su Unsplash
Se non sai chi sei, rischi di fare compliance nel posto sbagliato
Il problema più frequente non è l’assenza totale di attenzione.
È l’attenzione mal posizionata.
Ci sono organizzazioni che iniziano a scrivere policy interne sull’uso di ChatGPT, ma non hanno ancora capito quali strumenti AI siano davvero utilizzati nei diversi reparti. Ci sono startup che parlano di “semplice integrazione API”, ma in concreto offrono ai clienti un servizio fondato sull’output del sistema. Ci sono agenzie che usano l’AI nella produzione di contenuti per i clienti, ma non hanno chiarito nei contratti responsabilità, controllo umano, proprietà degli output, uso dei dati e limiti di riutilizzo.
Il rischio è fare un lavoro di adeguamento formalmente ordinato, ma sostanzialmente sbagliato.
Perché prima di chiederti quali obblighi rispettare, devi capire quale posizione occupi nella catena del valore dell’AI.
Se sei provider, il tuo problema non è lo stesso di chi usa un sistema già sviluppato da terzi. Se sei deployer, non puoi comportarti come se tutta la responsabilità restasse automaticamente sul fornitore. Se sei entrambe le cose, o se cambi ruolo a seconda del progetto, serve una mappatura più attenta.
Le zone ibride: dove molte imprese rischiano di sbagliare
La distinzione tra provider e deployer sembra semplice finché restiamo negli esempi estremi.
Da un lato il grande sviluppatore di sistemi AI. Dall’altro il professionista che usa un chatbot per scrivere una bozza.
Il problema sono tutte le situazioni nel mezzo.
Una società che prende un modello di terzi e lo integra in una piattaforma venduta ai clienti. Un’agenzia che costruisce un sistema semi-automatizzato per generare contenuti personalizzati per brand. Una startup che usa API esterne ma presenta il servizio come proprio prodotto AI. Una PMI che personalizza un sistema di selezione del personale e lo usa per supportare decisioni HR. Una software house che integra moduli AI in un gestionale venduto a imprese e professionisti.
Qui non basta dire: “non abbiamo sviluppato noi il modello”.
Perché l’AI Act guarda anche a chi mette in servizio, rende disponibile o utilizza un sistema nel proprio contesto. In alcuni casi, inoltre, modifiche sostanziali, cambi di finalità o immissione sul mercato sotto il proprio nome possono incidere sulla qualificazione del ruolo.
È qui che la classificazione diventa strategica.
Non perché serva un’etichetta.
Ma perché da quella etichetta discendono responsabilità diverse.
AI literacy: non è solo “fare un corso”
C’è poi un punto importante da chiarire.
Non tutte le scadenze dell’AI Act arrivano nello stesso momento. Il regolamento è entrato in vigore il 1° agosto 2024 e diventa applicabile secondo una timeline progressiva, con alcune disposizioni già operative prima della piena applicazione generale.
Tra queste rientra l’AI literacy, cioè l’alfabetizzazione sull’intelligenza artificiale. L’articolo 4 dell’AI Act richiede a provider e deployer di adottare misure per garantire un livello sufficiente di alfabetizzazione AI del personale e delle altre persone che, per loro conto, si occupano del funzionamento o dell’uso dei sistemi AI.
Questo non significa che ogni impresa debba organizzare lo stesso corso standard, né che esista un certificato unico valido per tutti.
Il punto non è “fare un corso”.
Il punto è fare in modo che chi usa o governa strumenti AI capisca almeno cosa sta usando, con quali limiti, con quali rischi e con quali responsabilità.
L’errore più comune: trattare l’AI come un software qualsiasi
Molte attività stanno introducendo strumenti di AI come in passato introducevano un nuovo gestionale o una nuova app.
Si prova. Funziona. Si adotta.
È un approccio comprensibile, ma incompleto.
L’AI non è sempre un software qualsiasi. Può produrre contenuti, suggerire decisioni, generare classificazioni, influenzare processi, trattare dati, costruire profili, automatizzare valutazioni, simulare comunicazioni, incidere sulla relazione con clienti, utenti, lavoratori o candidati.
Il problema non è solo tecnico.
È organizzativo, contrattuale, privacy e reputazionale.
Un team usa l’AI per preparare offerte commerciali ma chi controlla l’accuratezza degli output? Un’agenzia usa AI generativa per creare contenuti per i clienti, ma cosa viene dichiarato nei contratti? Una società usa AI per screening CV ma quali controlli umani sono previsti? Una startup integra API AI nel proprio prodotto ma quali responsabilità assume verso i clienti? Un professionista inserisce dati riservati in un tool esterno ma quali garanzie ha sul trattamento?
Sono domande concrete. E non si risolvono con una policy copiata.

Foto di Stephen Audu su Unsplash
Una mappa pratica per capire da dove partire
Per una PMI, uno studio professionale, un’agenzia o una startup, il primo passaggio non dovrebbe essere “adeguarsi all’AI Act” in astratto.
Dovrebbe essere più semplice e più serio: capire dove l’AI è già entrata.
Quali strumenti vengono usati? Da chi? Per quali attività? Con quali dati? Con quali output? Con quale impatto su clienti, utenti, dipendenti, collaboratori o terzi? Quali strumenti sono gratuiti, quali aziendali, quali integrati nei software già in uso? Quali sono stati approvati e quali vengono usati informalmente?
Poi bisogna chiedersi quale ruolo si ricopre: provider, deployer, eventualmente entrambi, o altro operatore della catena.
Solo dopo ha senso ragionare sugli obblighi.
Perché un conto è usare un sistema AI per supportare la redazione interna di contenuti. Un altro conto è vendere ai clienti una piattaforma che produce output AI sotto il proprio marchio. Un altro ancora è usare AI in ambiti sensibili, come HR, istruzione, credito, sanità, accesso a servizi o valutazioni che incidono sulle persone.
Questa mappatura non serve a spaventare. Serve a evitare di lavorare al buio.
Contratti, privacy, proprietà intellettuale: l’AI Act non vive da solo
Un altro errore frequente è pensare che l’AI Act sia un mondo separato.
Non lo è.
L’uso professionale dell’intelligenza artificiale si intreccia quasi sempre con altri piani.
C’è il piano privacy, se vengono inseriti dati personali nei sistemi o se l’AI viene usata per analisi, profilazione, assistenza, HR, marketing o gestione clienti. C’è il piano contrattuale, perché clienti, fornitori, agenzie e collaboratori devono sapere quando l’AI può essere usata, con quali limiti, con quali controlli e con quali responsabilità. C’è il piano della proprietà intellettuale, perché contenuti, prompt, output, dataset, immagini, testi e codice generano domande su titolarità, riutilizzo, originalità, licenze e violazioni. C’è il piano reputazionale, perché un uso disordinato dell’AI può produrre errori, contenuti non verificati, comunicazioni fuorvianti o perdita di fiducia.
Per questo la domanda “provider o deployer?” non è solo normativa.
È una domanda di governance.
Serve a capire chi decide, chi controlla, chi risponde, chi informa, chi conserva prove, chi forma le persone e chi documenta il processo.
Non serve creare panico. Serve classificazione.
Il punto non è creare allarme.
Non ogni uso dell’AI comporta lo stesso livello di rischio. Non ogni azienda deve costruire un apparato complesso. Non ogni professionista che usa un assistente AI deve sentirsi improvvisamente fuori regola.
Ma nessuno dovrebbe restare nella zona comoda del “tanto lo usiamo solo come supporto” senza verificare se sia davvero così.
Perché spesso l’AI entra come supporto e, lentamente, diventa processo.
Prima aiuta a scrivere. Poi propone contenuti. Poi segmenta. Poi suggerisce decisioni. Poi entra nel servizio offerto al cliente.
E a quel punto la classificazione iniziale potrebbe non bastare più.
Vuoi ritrovare più facilmente i contenuti LexAroundMe su Google?
Puoi aggiungere LexAroundMe tra le tue Fonti preferite su Google e seguire più da vicino i nostri contenuti su diritto, impresa, marchi, contratti, privacy, e-commerce e comunicazione digitale.
5 Domande sull’AI Act
Che differenza c’è tra provider e deployer nell’AI Act?
In termini essenziali, il provider è chi sviluppa, fa sviluppare, mette sul mercato o mette in servizio un sistema di AI sotto il proprio nome o marchio. Il deployer è chi usa un sistema di AI sotto la propria autorità in un contesto professionale, escluso l’uso personale non professionale.
Chi usa ChatGPT o Claude per lavoro è un deployer?
In molti casi, chi utilizza un sistema AI sviluppato da altri all’interno della propria attività professionale può essere considerato deployer. La valutazione dipende dal contesto concreto, dall’uso, dai dati trattati, dalle finalità e dall’impatto del sistema.
Una startup che integra API di modelli AI è provider o deployer?
Dipende dal caso concreto. Se la startup usa API di terzi per offrire un servizio sotto il proprio nome o marchio, potrebbe assumere un ruolo diverso dal semplice utilizzatore interno. Vanno verificati modello di business, livello di integrazione, finalità, controllo sul sistema, output e condizioni contrattuali.
L’AI literacy significa fare un corso obbligatorio uguale per tutti?
No. L’alfabetizzazione AI non coincide necessariamente con un corso standard identico per ogni organizzazione. Le misure dovrebbero essere proporzionate al ruolo, al contesto, alle competenze delle persone coinvolte e ai rischi collegati ai sistemi AI utilizzati.
Da dove dovrebbe partire una PMI che usa strumenti di AI?
Dovrebbe partire da una mappatura concreta: quali strumenti AI vengono usati, da chi, per quali attività, con quali dati, con quali output e con quale impatto su clienti, dipendenti, collaboratori o terzi. Solo dopo ha senso valutare ruolo, obblighi e misure di adeguamento.