Stato aggiornato all'11 agosto 2026. L'Articolo 50 del Regolamento UE sull'IA (trasparenza per alcuni sistemi che interagiscono con le persone, generano contenuti sintetici, eseguono il riconoscimento delle emozioni o la categorizzazione biometrica, o pubblicano deepfake) si applica dal 2 agosto 2026. La Commissione europea ha avviato l'applicazione di questi obblighi di trasparenza. Si tratta di legge vigente per il codice applicativo, non di una scadenza futura.
La maggior parte dei requisiti del Capitolo III per i sistemi ad alto rischio (Articoli da 8 a 15: gestione del rischio, governance dei dati, documentazione tecnica, tenuta dei registri, istruzioni per i deployer, supervisione umana, accuratezza, robustezza e cybersicurezza) non è entrata in vigore il 2 agosto 2026. Il Regolamento (UE) 2026/1744, il Digital Omnibus sull'IA, è stato pubblicato nella Gazzetta ufficiale il 24 luglio 2026 ed è entrato in vigore il 27 luglio 2026. Posticipa l'applicazione di questi obblighi ad alto rischio al 2 dicembre 2027 per i sistemi classificati come ad alto rischio ai sensi dell'Articolo 6(2) e dell'Allegato III (sistemi autonomi come strumenti per l'impiego, servizi essenziali e applicazioni per le forze dell'ordine) e al 2 agosto 2028 per i sistemi classificati ai sensi dell'Articolo 6(1) e dell'Allegato I (IA integrata in prodotti già regolamentati altrove, come dispositivi medici o macchinari). I piani che considerano ancora agosto 2026 come la scadenza per la conformità ad alto rischio si basano su una data già superata.
Questa guida è rivolta agli sviluppatori. Non classifica il tuo prodotto come ad alto rischio, esegue una valutazione di conformità o sostituisce una consulenza legale. Indica il calendario, gli obblighi dell'Articolo 50 che ora compaiono come testo dell'interfaccia utente e metadati in una diff, e come una lettura di conformità di una pull request individua il problema comune: una pulizia che elimina la dichiarazione.
Cosa è attivo ora (Articolo 50)
L'Articolo 50 stabilisce quattro categorie principali di obblighi di trasparenza, suddivisi tra fornitori (l'organizzazione che costruisce il sistema) e deployer (l'organizzazione che lo utilizza), con eccezioni che includono usi specifici delle forze dell'ordine. Questi obblighi si manifestano spesso nel codice in esecuzione, non solo nella documentazione. Art. 50(1): un sistema progettato da un fornitore per interagire direttamente con una persona deve informare tale persona che sta comunicando con un'IA, a meno che non sia ovvio per una persona ragionevolmente informata; un widget di chat, un assistente vocale o un bot di supporto richiede una dichiarazione visibile. Art. 50(2): un fornitore il cui sistema genera audio, immagini, video o testo sintetico deve contrassegnare tale output in un formato leggibile automaticamente, identificabile come generato da IA. Per i sistemi già sul mercato prima del 2 agosto 2026, il contrassegno leggibile automaticamente ai sensi dell'Art. 50(2) è spesso descritto con una transizione al 2 dicembre 2026; verifica il testo transitorio esatto contro l'Omnibus e le linee guida della Commissione per la tua linea di prodotti, poiché altri obblighi dell'Articolo 50 non condividono questo periodo di transizione. Art. 50(3): un deployer che esegue il riconoscimento delle emozioni o la categorizzazione biometrica sulle persone deve informare le persone interessate. Art. 50(4): un deployer che pubblica un deepfake deve comunque dichiarare che è generato o manipolato artificialmente; per contenuti che fanno parte di un'opera evidentemente artistica, creativa, satirica, fittizia o analoga, tale obbligo di dichiarazione si limita a essere fatto in modo da non ostacolare la visualizzazione o il godimento dell'opera, piuttosto che essere esentato. Separatamente, il testo generato o manipolato dall'IA pubblicato per informare il pubblico su una questione di interesse pubblico richiede la stessa dichiarazione, a meno che il contenuto non abbia subito una revisione umana o un controllo editoriale e una persona o un'organizzazione non si assuma la responsabilità editoriale per la sua pubblicazione.
Ciascuno di questi obblighi viene spesso implementato come elemento dell'interfaccia utente, una scrittura di metadati o una stringa di testo, il che li rende esattamente il tipo di cose che un refactoring può rimuovere senza che nessuno lo segni come modifica di conformità. A partire da agosto 2026, tale rimozione non è "prematura"; è una lacuna di trasparenza attiva.
Esempio pratico: una pulizia dell'interfaccia utente rimuove la dichiarazione
Supponiamo che un chatbot di supporto sia stato distribuito con una riga persistente sotto il suo primo messaggio: "Stai chattando con un assistente IA." Una pull request successiva ridisegna il widget per uno stato di prima apertura più pulito e, eliminando ciò che un designer ha segnalato come disordine nell'onboarding, rimuove quella riga insieme ad altre tre parti di testo introduttivo. Il ridisegno non è sbagliato in sé: il widget risulta più pulito e le altre tre righe erano effettivamente di riempimento. Tuttavia, la dichiarazione dell'Art. 50(1) era implementata come una di quelle righe, quindi rimuoverla ha eliminato la dichiarazione, non solo il disordine. Nulla nella diff sembra insolito: una riduzione del testo in un componente di chat non è il tipo di cosa che un bug scanner, un test QA o una revisione di design è progettato per rilevare.
Questo è ciò che un controllo di conformità legge in una diff: quando una modifica rimuove o indebolisce un elemento collegato a un controllo che il team sta tracciando, citare l'Art. 50(1) direttamente nella pull request, piuttosto che scoprirlo da un reclamo o un contatto di applicazione dopo i fatti.
L'alto rischio è rinviato, non annullato
Il rinvio degli obblighi per i sistemi ad alto rischio dell'Allegato III a dicembre 2027 non rende la domanda sottostante, se un sistema sia considerato ad alto rischio ai sensi dell'Allegato III, più facile da rispondere in seguito rispetto a ora. I controlli dietro gli Articoli da 8 a 15 sono dello stesso tipo di problema "modifiche in una diff" che l'hub del framework traccia già: una mitigazione del rischio indebolita, un controllo di governance dei dati eliminato, un override umano cancellato come codice morto. Acquisire queste abitudini ora è più economico che scoprire lacune sotto la scadenza del 2027.
Due altri gruppi di date non sono interessati da questo omnibus e si applicano già: gli obblighi sulle pratiche vietate e l'alfabetizzazione sull'IA dal 2 febbraio 2025, e le regole sui modelli GPAI e gli obblighi di governance dal 2 agosto 2025. Un'altra modifica degna di nota dallo stesso pacchetto: un nuovo divieto che copre i fornitori di sistemi destinati a generare o manipolare materiali intimi non consensuali o materiali di abuso sessuale su minori, o sistemi per i quali tale output è un risultato ragionevolmente prevedibile e riproducibile senza modifiche tecniche significative e senza salvaguardie ragionevoli e adeguate contro di esso, nonché i deployer che utilizzano un sistema per tale scopo, aggiunto all'elenco delle pratiche vietate del Regolamento e applicabile dal 2 dicembre 2026.
Dove si inserisce heygrc e il limite dell'onestà
heygrc è progettato per leggere ogni pull request rispetto ai framework selezionati, incluso il Regolamento UE sull'IA quando è attivato, e per indicare l'articolo che una modifica sembra interessare (ad esempio, Art. 50(1) su una dichiarazione di chat rimossa). Il risultato è un commento di revisione con l'articolo allegato, in modo che l'autore e il revisore possano decidere con tutte le informazioni necessarie. Non certifica la conformità al Regolamento sull'IA, classifica lo stato di alto rischio, esegue una valutazione di conformità, invia notifiche di vigilanza o sostituisce una consulenza legale. Una revisione verde di heygrc non è un'approvazione della Commissione; è un segnale precoce, basato sugli articoli, che una modifica ha interessato qualcosa che questi programmi considerano rilevante.
Se il tuo team utilizza già un revisore di bug o di qualità sulla stessa pull request, mantienilo. Questi strumenti verificano se il codice è corretto e sicuro. Le domande dell'Articolo 50 riguardano se una persona sa ancora di stare comunicando con un'IA o se i contenuti sintetici sono ancora contrassegnati. La pulizia sopra può essere pulita, ben tipizzata e testata e comunque lasciare l'Art. 50(1) incompleto. Esegui entrambi i livelli; nessuno sostituisce l'altro.