Articolo 50 vs Articolo 52: quale vincola il tuo chatbot ai sensi dell'EU AI Act
La confusione più comune che i nostri revisori riscontrano nelle chiamate di intake: un fondatore SaaS ritiene che l'Articolo 52 si applichi perché utilizza GPT-4. L'Articolo 52 non si applica a loro. Si applica l'Articolo 50. Questo articolo risolve la confusione, si attiene all'esatta formulazione del Regolamento e illustra i quattro casi in cui l'Articolo 52 è genuinamente rilevante per un deployer SaaS.
Cosa dice effettivamente l'Articolo 50
L'Articolo 50 si trova nel Capo IV (Obblighi di trasparenza per i fornitori e i deployer di determinati sistemi di IA). Quattro paragrafi.
Articolo 50(1). I fornitori devono garantire che le persone fisiche che interagiscono con un sistema di IA siano informate di tale fatto, a meno che ciò non risulti evidente dalle circostanze. Vincola chatbot, agenti vocali, assistenti virtuali.
Articolo 50(2). I fornitori di sistemi di IA che generano contenuti sintetici (testo, immagine, audio, video) devono contrassegnare gli output come generati o manipolati artificialmente in un formato leggibile meccanicamente. Vincola strumenti di generazione di immagini, sintetizzatori vocali, writer basati su IA, servizi di deepfake.
Articolo 50(3). I deployer di sistemi di riconoscimento delle emozioni o di categorizzazione biometrica devono informare le persone esposte. Vincola le funzionalità di analisi del sentiment visibili agli utenti, il clustering biometrico.
Articolo 50(4). I deployer di IA che genera deepfake devono effettuare la divulgazione. I deployer di IA che genera testo pubblicato per informare il pubblico su questioni di interesse pubblico devono effettuare la divulgazione.
Tutti e quattro i paragrafi vincolano i deployer SaaS che sviluppano funzionalità rivolte agli utenti. L'Articolo 50 si applica dal 2 agosto 2026 ai sensi dell'Articolo 113.
Cosa dice effettivamente l'Articolo 52
L'Articolo 52 si trova nel Capo V (Modelli di IA per uso generale). Disciplina il processo di classificazione e notifica per i modelli di IA per uso generale con rischio sistemico.
Nello specifico, l'Articolo 52 stabilisce che un modello GPAI è presumibilmente a rischio sistemico quando il calcolo cumulativo utilizzato per l'addestramento supera 10²⁵ operazioni in virgola mobile. I fornitori di tali modelli devono notificarlo alla Commissione entro due settimane dal raggiungimento della soglia.
Questo vincola OpenAI, Anthropic, Google, Meta, Mistral e chiunque produca modelli di fondazione su scala frontier. Non vincola un fondatore SaaS che chiama quei modelli tramite API. Il Regolamento traccia una distinzione netta: i fornitori distribuiscono il modello; i deployer lo integrano nei prodotti.
Se il tuo SaaS non addestra il proprio modello GPAI, l'Articolo 52 non ti vincola. L'articolo che ti vincola è l'Articolo 50.
Perché i fondatori confondono i due articoli
Tre ragioni osservate dai nostri revisori.
1. Gli articoli sono adiacenti. L'Articolo 50 e l'Articolo 52 sono sequenziali nel testo del Regolamento ed entrambi fanno riferimento ai modelli GPAI. Una prima lettura porta a confonderli.
2. Il marketing dei GPAI rinforza la confusione. I post di OpenAI, Anthropic e altri sulla propria conformità all'Articolo 52 utilizzano espressioni come «conformità all'AI Act» che i fondatori interpretano come se si trasferisse a loro. Non è così.
3. Il linguaggio sulla cybersicurezza e sulla gestione del rischio nell'Articolo 55 sembra vincolare i SaaS. L'Articolo 55 (obblighi per i fornitori di GPAI con rischio sistemico) parla di regimi di valutazione avversariale e di segnalazione degli incidenti. Si tratta di obblighi lato fornitore. La lettura dell'Articolo 55 per un deployer SaaS è: assicurarsi che il proprio fornitore upstream pubblichi le divulgazioni ai sensi dell'Articolo 53, citarle nel proprio model card e procedere.
Quando l'Articolo 52 diventa rilevante per un SaaS
Quattro casi. I nostri revisori li riscontrano raramente, ma esistono.
1. Il SaaS è anche un fornitore di GPAI. Se un'azienda distribuisce un'API attraverso la quale terzi chiamano un modello di fondazione addestrato dall'azienda stessa, tale azienda è un fornitore di GPAI. L'Articolo 52 si applica al lato GPAI; l'Articolo 50 si applica comunque a qualsiasi distribuzione in prima persona.
2. Il SaaS esegue un fine-tuning di un modello base in misura tale da superare la soglia della modifica sostanziale. L'Articolo 25 disciplina quando una modifica a valle crea un nuovo fornitore. Fine-tuning pesanti su dataset sostanziali possono trasformare il SaaS da deployer a fornitore. I nostri revisori lo esaminano in sede di intake quando il cliente dichiara di effettuare fine-tuning.
3. La due diligence negli approvvigionamenti del SaaS richiede evidenza della conformità upstream. I buyer enterprise chiedono «il GPAI che utilizzate è classificato ai sensi dell'Articolo 52». La risposta proviene dalla documentazione del fornitore upstream; il SaaS vi fa riferimento.
4. Il SaaS stipula contratti con il settore pubblico dell'UE. I framework di approvvigionamento del settore pubblico stanno iniziando a richiedere evidenza che il GPAI upstream del SaaS sia pubblicato e notificato ai sensi dell'Articolo 52. Anche in questo caso, la risposta proviene dall'upstream; il SaaS vi fa riferimento.
Le raccomandazioni dei nostri revisori
Default per un deployer SaaS:
Fase 1: presumere che l'Articolo 50 sia vincolante. Implementare le divulgazioni sulla trasparenza su ogni superficie IA del proprio prodotto.
Fase 2: nel proprio model card per funzionalità IA, fare riferimento alle divulgazioni ai sensi dell'Articolo 53 del proprio fornitore GPAI upstream tramite URL. Ciò soddisfa il riconoscimento lato deployer della conformità dell'upstream.
Fase 3: non dichiarare che l'Articolo 52 si applica a voi, e non dichiarare che l'Articolo 55 si applica a voi, a meno che non si soddisfino effettivamente le condizioni della Sezione 4 di cui sopra. Classificarsi erroneamente come fornitore di GPAI crea obblighi che non si hanno e non protegge da nulla.
L'audit della nostra practice include il pacchetto di implementazione dell'Articolo 50 e un model card per funzionalità che riporta lo stato ai sensi dell'Articolo 53 dell'upstream. Se il cliente rientra in uno dei casi limite della Sezione 4, il revisore principale lo segnala in sede di intake e l'ambito dell'audit viene adeguato.
Frequently asked questions
L'utilizzo del piano enterprise di OpenAI incide su questo?
No. Il piano acquistato da OpenAI è un rapporto commerciale; non modifica la tua classificazione ai sensi del Regolamento. Rimani un deployer; OpenAI rimane il fornitore di GPAI.
E i servizi GPAI in white label?
Alcuni fornitori upstream offrono accordi di white label in cui si distribuisce il modello con il proprio brand. Leggere il contratto: se si rimane clienti del fornitore di GPAI, si è un deployer. Se si assumono gli obblighi del fornitore di GPAI ai sensi del contratto, se ne possono ereditare alcuni. Il nostro revisore principale leggerà il contratto durante l'audit se lo si segnala in sede di intake.
Posso eseguire Llama in locale ed evitare tutto questo?
L'self-hosting di un modello non fa uscire dallo status di deployer. Si sta comunque immettendo sul mercato un sistema di IA sotto la propria autorità. L'Articolo 50 è ancora vincolante. La lettura dell'Articolo 52 dipende dal fatto che il modello open-weights eseguito sia stato addestrato con un calcolo superiore alla soglia di 10²⁵ FLOP. I modelli della famiglia Llama 3 superano tale soglia.
Esiste un'esenzione dall'Articolo 52 per le piccole imprese SaaS?
L'Articolo 52 non prevede alcuna esenzione per le PMI perché non si applica affatto ai deployer SaaS. Gli obblighi lato deployer ai sensi dell'Articolo 50 si applicano invece anche ai piccoli SaaS, ma i nostri revisori delle policy ritengono che il principio di proporzionalità ai sensi dell'Articolo 99(5) attenui le sanzioni per le PMI.
Cosa succede se il fornitore upstream non è conforme?
La loro non conformità viene contestata nei loro confronti. Gli obblighi lato deployer ai sensi dell'Articolo 50 rimangono in capo a voi. Il rischio pratico: se il vostro upstream non è in grado di pubblicare le divulgazioni ai sensi dell'Articolo 53, il vostro model card non può farvi riferimento, il che emerge nel vostro stesso audit. Il nostro revisore principale segnalerebbe questo come un rischio di approvvigionamento che vale la pena di mitigare diversificando i fornitori upstream.
Sources
Last updated: 2026-06-09