Articoli 3, 16, 25 e 26 · Ruoli · Responsabilità
Provider e deployer nell'AI Act: differenze e obblighi
Risposta breve: il provider sviluppa, fa sviluppare e immette sul mercato o mette in servizio un sistema di IA con il proprio nome; il deployer lo usa sotto la propria autorità. Un acquisto non trasferisce automaticamente ogni responsabilità al fornitore, e chi modifica o rimarchia un sistema può diventare provider.
01La differenza in una tabella
I ruoli dell'AI Act descrivono attività concrete, non qualifiche astratte. La stessa organizzazione può avere ruoli diversi per sistemi diversi e, in alcune filiere, può cumulare più ruoli.
| Domanda | Provider | Deployer |
|---|---|---|
| Che cosa fa? | Sviluppa o fa sviluppare il sistema e lo immette sul mercato o lo mette in servizio con il proprio nome o marchio, anche gratuitamente. | Usa il sistema sotto la propria autorità, fuori dall'uso personale non professionale. |
| Esempio | Un'impresa offre una piattaforma di selezione automatizzata con il proprio marchio. | Un datore di lavoro usa la piattaforma per filtrare candidature. |
| Domanda chiave | Chi determina il sistema offerto, la finalità prevista e le condizioni dichiarate? | Chi decide il contesto concreto, i dati in ingresso e come usare l'output? |
| Errore comune | Confonderlo sempre con chi ha scritto materialmente il codice. | Trattarlo come un utente passivo senza doveri propri. |
02Come cambiano gli obblighi nei sistemi ad alto rischio
Per i sistemi ad alto rischio la distinzione diventa operativa. Il provider deve progettare e documentare la conformità del sistema; il deployer deve governarne l'uso reale. Questa sintesi non sostituisce gli articoli applicabili né gli obblighi settoriali.
| Provider | Deployer |
|---|---|
| Assicura che il sistema rispetti i requisiti per l'alto rischio, compresi gestione del rischio, dati, documentazione, registrazione, trasparenza, supervisione e robustezza. | Usa il sistema secondo le istruzioni e adotta misure tecniche e organizzative adeguate. |
| Predispone il sistema di gestione della qualità, conserva la documentazione e attua azioni correttive quando necessario. | Affida la supervisione a persone con competenza, formazione, autorità e supporto effettivi. |
| Comunica informazioni sufficienti a chi dovrà integrare o usare il sistema. | Controlla i dati di input quando dipendono da lui, monitora il funzionamento, conserva i log sotto il proprio controllo e segnala rischi o incidenti. |
03Quando il deployer può diventare provider
L'articolo 25 disciplina tre passaggi importanti per i sistemi ad alto rischio. Un deployer, distributore, importatore o altro soggetto può assumere gli obblighi del provider quando:
- appone il proprio nome o marchio a un sistema ad alto rischio già sul mercato o in servizio;
- realizza una modifica sostanziale e il sistema resta ad alto rischio;
- cambia la finalità prevista di un sistema non classificato ad alto rischio in modo da renderlo tale.
Integrare un modello generale in un'applicazione, personalizzare un prodotto o cambiare il contesto d'uso non produce sempre lo stesso esito. Servono finalità prevista, documentazione, modifiche effettuate e rischio effettivo. La domanda corretta non è “lo abbiamo comprato?”, ma “che cosa abbiamo trasformato e sotto quale nome lo mettiamo in servizio?”.
Se stai facendo il punto per la tua impresa, AI Act per le aziende mette queste domande nell'ordine in cui conviene affrontarle.
04Checklist prima di acquistare o usare un sistema
- Mappa la filiera: chi sviluppa, chi integra, chi vende, chi decide la finalità e chi usa l'output.
- Definisci il contesto: persone interessate, decisioni influenzate, dati trattati e conseguenze di un errore.
- Verifica la classificazione: pratica vietata, alto rischio, obbligo di trasparenza o altro regime.
- Chiedi prove: istruzioni, limiti, log, qualità dei dati, prestazioni, supervisione, incidenti e aggiornamenti.
- Assegna responsabilità interne: una persona deve poter fermare o correggere l'uso, non soltanto osservare il sistema.
- Controlla i cambiamenti: nuove finalità, fine-tuning, integrazioni e rimarchiatura possono cambiare il ruolo.
05Anche la trasparenza divide i compiti
L'articolo 50 mostra perché i due ruoli non sono sinonimi. In termini semplificati, il provider deve rendere riconoscibili determinate interazioni o output sintetici; in situazioni come la diffusione di deepfake o l'uso di alcuni sistemi biometrici, specifici doveri ricadono invece sul deployer. La guida sugli obblighi di trasparenza entra nel dettaglio.
06Perché nel gioco devi indicare il responsabile
In NO AI ACT non basta riconoscere il rischio. Nel fascicolo “La gara opaca” un ente compra un sistema senza ottenere documentazione e senza costruire una governance dell'uso. Attribuire ogni problema al venditore produce un rapporto debole: il provider deve rendere il sistema verificabile, ma il deployer decide come introdurlo nel procedimento e come sorvegliarlo.
07Fonti ufficiali e limiti
Testo di riferimento: Regolamento (UE) 2024/1689 su EUR-Lex. Per orientarsi fra le disposizioni: articolo 3, articolo 25, articolo 26 e le FAQ della Commissione europea. Verifica sempre il testo consolidato vigente e le norme settoriali applicabili.