C'è una domanda che facciamo nei primi quindici minuti di ogni assessment con un nuovo cliente. Suona così: voi state usando AI fatta da altri, o state costruendo AI vostra? La risposta media è confusa. Alcuni rispondono 'la usiamo soltanto', altri 'abbiamo un automatismo custom', altri ancora 'abbiamo collegato ChatGPT al nostro gestionale'. Nessuna di queste risposte è abbastanza precisa, e l'imprecisione costa cara perché determina in quale ruolo dell'AI Act ti trovi.
L'AI Act distingue ruoli con obblighi profondamente diversi. I due principali sono provider (chi sviluppa e immette sul mercato) e deployer (chi usa nel proprio contesto). C'è anche distributor, importer e un quarto ruolo rilevante per PMI: il deployer che modifica sostanzialmente un sistema esistente diventa provider di quel sistema. Questa è la trappola che fa cadere più PMI italiane che hanno deciso di costruire agenti AI custom.
Definizioni esatte: provider e deployer secondo l'AI Act
L'articolo 3 dell'AI Act definisce i ruoli in modo formale. Le definizioni sono importanti perché spostano la responsabilità.
Provider è una persona fisica o giuridica che sviluppa un sistema AI o ha sviluppato un modello AI per uso generale e lo immette sul mercato o lo mette in servizio con il proprio nome o marchio, a titolo oneroso o gratuito. Deployer è una persona fisica o giuridica che utilizza un sistema AI sotto la propria autorità, eccetto quando il sistema è usato nel corso di un'attività personale non professionale.
La parola chiave per il provider è 'immette sul mercato' o 'mette in servizio con il proprio nome'. La parola chiave per il deployer è 'utilizza sotto la propria autorità'. La maggior parte delle PMI è in modo netto nella categoria deployer. Ma esiste una zona grigia che si è ampliata enormemente nel 2025 con l'esplosione degli agenti AI custom costruiti sopra OpenAI, Anthropic, Mistral.
La trappola dell'agente: quando il deployer diventa provider
L'art. 25 dell'AI Act stabilisce una regola che cambia la prospettiva: chiunque modifichi sostanzialmente lo scopo previsto di un sistema AI, o ne modifichi in modo sostanziale la finalità, è considerato provider del sistema modificato. Lo stesso vale per chi appone il proprio marchio o nome a un sistema AI immesso sul mercato.
In termini operativi questo significa che una PMI italiana che costruisce un agente AI custom per parlare ai propri clienti, anche basandosi su API esterne come quelle di OpenAI o Anthropic, può facilmente trovarsi in ruolo di provider per il sistema risultante. Ed è esattamente quello che sta accadendo a centinaia di PMI in questi mesi senza che se ne rendano conto.
- Costruisci un chatbot custom che usa GPT-4 sotto il cofano ma è marchiato col nome della tua azienda: sei provider del chatbot.
- Crei un agente che processa documenti contrattuali e produce bozze legali con il logo della tua società: sei provider di quell'agente.
- Sviluppi un sistema di scoring credito basato su un modello open source che hai integrato nel tuo gestionale: sei provider del sistema di scoring.
- Aggiungi semplicemente ChatGPT come tool al tuo team senza alcuna modifica del sistema: sei deployer di ChatGPT, niente di più.
Gli obblighi del deployer in due righe
Se sei deployer e basta, gli obblighi sono significativi ma gestibili. Si concentrano sull'uso corretto del sistema e sulla supervisione, non sulla sua costruzione.
- Usare il sistema secondo le istruzioni del provider, senza modificare lo scopo previsto.
- Garantire supervisione umana adeguata, specialmente per sistemi ad alto rischio.
- Formare il personale che opera il sistema (Art. 4 AI Literacy).
- Monitorare il funzionamento e segnalare al provider eventuali rischi o anomalie.
- Conservare i log generati dal sistema per il periodo previsto (almeno 6 mesi per sistemi ad alto rischio).
- Informare le persone che interagiscono con il sistema (chatbot, biometrici, contenuti generati).
Gli obblighi del provider in due paragrafi
Se diventi provider, anche di un piccolo agente custom, gli obblighi si moltiplicano. Devi documentare l'architettura del sistema, redigere e mantenere una documentazione tecnica conforme all'Allegato IV, condurre risk assessment formali, implementare un sistema di gestione qualità (Art. 17), garantire accuracy, robustness e cybersecurity adeguate, registrare il sistema nel database EU se è ad alto rischio, marcare con CE quando applicabile, e mantenere il sistema sotto sorveglianza post-market.
Sono obblighi che hanno senso per chi sviluppa AI come prodotto core, ma diventano un fardello sproporzionato per una PMI che ha sviluppato un agente come strumento operativo interno. La buona notizia è che esistono percorsi pratici per rimanere deployer o per limitare la portata della responsabilità da provider.
“Non è il fatto di costruire un agente che ti rende provider. È il fatto di esporlo come prodotto con il tuo marchio o di modificarne sostanzialmente lo scopo. Tra costruire un automatismo interno e lanciare un agente al mercato c'è un confine giuridico preciso.”
Come restare deployer quando costruisci un agente
Quattro accorgimenti pratici aiutano una PMI a costruire automazioni AI custom rimanendo nel ruolo di deployer, evitando di scivolare in quello di provider. Sono accorgimenti che applichiamo sistematicamente nei progetti di sviluppo agente per i nostri clienti.
- Non immettere sul mercato il sistema. Un agente usato esclusivamente all'interno dell'azienda, da personale autorizzato, non viene 'messo in servizio' per il mercato e non triggera il ruolo provider per quella dimensione.
- Non apporre il proprio marchio al modello sottostante. Se l'agente è chiaramente 'powered by GPT-4' o 'powered by Claude', il provider del modello è il fornitore originale. Se rebrandi come 'AI proprietaria di Acme SpA', diventi provider della soluzione.
- Non modificare lo scopo previsto. Usare un modello generico per scopi generici (assistenza scrittura, ricerca, analisi documenti) non triggera lo status provider. Usarlo per scoring credito o screening candidati è una modifica sostanziale che può attivarlo.
- Documentare la catena di responsabilità. Avere un Data Processing Agreement chiaro con il fornitore del modello, e una policy interna che esplicita lo scopo limitato d'uso, riduce il rischio di riclassificazione.
Test pratico in cinque domande
Se vuoi capire in tre minuti dove ti trovi rispetto ai ruoli dell'AI Act, rispondi a queste cinque domande. Quattro 'sì' o più ti indicano che probabilmente sei o stai diventando provider.
- Stai costruendo un sistema AI che verrà commercializzato o licenziato a terzi?
- Il sistema porterà il marchio o il nome della tua azienda come prodotto autonomo?
- Stai modificando in modo sostanziale lo scopo previsto di un modello esistente (es. usarlo per scoring credito quando era nato per assistenza generica)?
- Stai apponendo CE marking o registrando il sistema come prodotto AI?
- Stai integrando il sistema in un prodotto fisico che vendi al mercato?
La distinzione provider-deployer non è una sottigliezza giuridica per avvocati. È una linea che determina cosa devi documentare, formare, certificare e mantenere. La buona pratica per una PMI è progettare consapevolmente in che ruolo si vuole stare, prima di iniziare. Se stai pensando di costruire un agente custom o se ne hai già uno in produzione, una chiamata gratuita di 30 minuti è sufficiente per capire in che ruolo sei effettivamente, cosa rischi, e quali sono i due o tre interventi che ti riportano in zona controllata.

