Articolo 13 del regolamento europeo sull'IA: gli obblighi di trasparenza per l'IA ad alto rischio

Aggiornamento del 2 ottobre 2026 — correzione. Le versioni precedenti citavano l'articolo 13 come se fosse rivolto agli «utenti» (il testo adottato parla di deployer), riportavano un elenco di sei categorie di informazioni che non corrisponde all'articolo 13, paragrafo 3, interpretavano le «modifiche» come notifiche di aggiornamento e indicavano metriche di accuratezza che l'articolo non nomina. La guida ora segue l'articolo 13, paragrafo 3, lettere da a) a f), e non fa più riferimento a un audit a pagamento.

Aggiornamento del 31 luglio 2026 — scadenza modificata. Il Digital Omnibus (adottato dal Parlamento europeo il 16 giugno 2026 e dal Consiglio il 29 giugno 2026) ha rinviato gli obblighi relativi ai sistemi ad alto rischio dell'allegato III dal 2 agosto 2026 al 2 dicembre 2027. Gli obblighi di trasparenza dell'articolo 50 non sono stati rinviati e continuano ad applicarsi dal 2 agosto 2026. Questo articolo è stato corretto di conseguenza. Se il suo sistema di IA è classificato ad alto rischio ai sensi del regolamento europeo sull'IA, l'articolo 13 impone che sia «sufficientemente trasparente da consentire ai deployer di interpretare l'output del sistema e utilizzarlo adeguatamente» (regolamento (UE) 2024/1689, articolo 13, paragrafo 1). Non è una raccomandazione blanda: è un obbligo esigibile, con un massimo previsto dalla legge di 15 milioni di euro o del 3 % del fatturato annuo mondiale, se superiore.

La maggior parte delle imprese sottovaluta l'articolo 13. Presume che trasparenza significhi «aggiungere una clausola di esclusione di responsabilità» o «mostrare i punteggi di confidenza». In realtà l'articolo 13, paragrafo 3, elenca sei punti di informazione che le istruzioni per l'uso devono contenere come minimo, ciascuno con il proprio lavoro di documentazione.

Questa guida illustra che cosa richiede davvero l'articolo 13, quali sono le lacune di conformità ricorrenti e come integrare la trasparenza nel suo sistema di IA ad alto rischio prima della scadenza del 2 dicembre 2027.

Che cosa richiede davvero l'articolo 13

L'articolo 13 vincola il fornitore. Impone che i sistemi di IA ad alto rischio siano accompagnati da istruzioni per l'uso che forniscano ai deployer informazioni che siano:

1. Concise, complete, corrette e chiare — senza gergo né ambiguità
2. Pertinenti, accessibili e comprensibili per i deployer — calibrate sul loro ruolo e sulle loro competenze tecniche
3. Sufficienti a consentire ai deployer di interpretare l'output — devono capire che cosa il sistema sta dicendo loro e perché
4. Sufficienti a consentire ai deployer di usare il sistema adeguatamente — devono sapere quando fidarsi dell'output e quando disattenderlo

L'articolo 13, paragrafo 3, indica in sei punti che cosa devono contenere come minimo le istruzioni per l'uso:

1. a) Identità e dati di contatto del fornitore — e del suo rappresentante autorizzato, ove presente
2. b) Caratteristiche, capacità e limiti delle prestazioni — inclusi la finalità prevista; il livello di accuratezza, comprese le relative metriche, di robustezza e di cibersicurezza; le circostanze note o prevedibili che possono comportare rischi; e, ove applicabile od opportuno, le informazioni che aiutano a spiegare l'output, le prestazioni per specifici gruppi di persone e i dati di input e di addestramento
3. c) Modifiche predeterminate dal fornitore — le modifiche al sistema e alle sue prestazioni stabilite al momento della valutazione iniziale della conformità, se presenti
4. d) Misure di sorveglianza umana — quelle di cui all'articolo 14, comprese le misure tecniche che aiutano i deployer a interpretare l'output
5. e) Risorse computazionali e hardware, durata prevista e manutenzione — compresa la frequenza delle misure di cura e degli aggiornamenti software
6. f) Meccanismi di registrazione — ove pertinente, come i deployer possono raccogliere, conservare e interpretare i log richiesti dall'articolo 12

Il fornitore deve fornire queste informazioni. Il deployer deve poi usare il sistema conformemente alle istruzioni per l'uso (articolo 26, paragrafo 1). Un sistema immesso sul mercato senza queste istruzioni non sembra soddisfare l'articolo 13.

Le informazioni nel dettaglio

Le sezioni seguenti trattano i punti nell'ordine in cui la maggior parte dei team li affronta. L'accuratezza e i rischi prevedibili fanno entrambi parte del punto b), ma hanno sezioni proprie perché è lì che si concentra la maggior parte delle lacune.

1. Identità e dati di contatto del fornitore — punto a)

È il requisito più semplice: i deployer devono sapere chi ha realizzato il sistema e come contattarlo.

Che cosa cercano gli auditor:

• Nome, indirizzo e indirizzo e-mail di contatto del fornitore nelle istruzioni per l'uso
• Chiara identificazione del soggetto giuridico responsabile della conformità e, ove presente, del rappresentante autorizzato

Errore ricorrente: impiegare un sistema privo di identificazione del fornitore, o seppellire i dati di contatto in condizioni di servizio di 50 pagine.

2. Caratteristiche, capacità e limiti delle prestazioni — punto b)

I deployer devono capire che cosa il sistema può e non può fare. Ciò comprende:

• La finalità prevista — a che cosa è destinato il sistema
• Le caratteristiche prestazionali — accuratezza, robustezza e, ove opportuno, le prestazioni per le specifiche persone o gruppi di persone sui quali il sistema è destinato a essere usato
• I limiti noti — i compiti che il sistema non è in grado di svolgere in modo affidabile

Che cosa cercano gli auditor:

• Una specifica scritta della finalità prevista e dei casi d'uso fuori ambito
• Parametri di riferimento prestazionali (ad esempio «92 % di accuratezza sul set di convalida»)
• La documentazione delle modalità di guasto note (ad esempio «prestazioni scarse sul testo manoscritto»)

Errore ricorrente: fornire solo affermazioni di marketing («accuratezza allo stato dell'arte») senza dati prestazionali quantitativi né limiti documentati.

3. Modifiche predeterminate — punto c)

Il punto c) chiede le modifiche al sistema e alle sue prestazioni che il fornitore ha stabilito in anticipo, al momento della valutazione iniziale della conformità, se presenti. Conta soprattutto per i sistemi che continuano ad apprendere: le modifiche predeterminate in quella sede e registrate nella documentazione tecnica non costituiscono una modifica sostanziale, mentre le altre modifiche sostanziali richiedono una nuova valutazione della conformità (articolo 43, paragrafo 4). Il punto e) chiede separatamente le misure di manutenzione e cura, compresi gli aggiornamenti software.

L'articolo 13 non impone e-mail di aggiornamento né note di rilascio. Tenere informati i deployer quando il sistema cambia resta comunque una buona pratica, e rende più facile dimostrare il rispetto dei punti c) ed e).

Che cosa cercano gli auditor:

• Una descrizione delle modifiche predeterminate, coerente con la documentazione tecnica
• Un confronto delle prestazioni prima e dopo gli aggiornamenti
• Un calendario di manutenzione e aggiornamento per i deployer

Errore ricorrente: modificare un modello in modi mai descritti nelle istruzioni per l'uso, senza verificare se la modifica costituisca una modifica sostanziale.

4. Livello di accuratezza, robustezza e cibersicurezza — punto b), ii)

L'articolo 13 impone che le istruzioni indichino il livello di accuratezza, comprese le relative metriche, di robustezza e di cibersicurezza di cui all'articolo 15, rispetto al quale il sistema è stato sottoposto a prova e convalidato, nonché qualsiasi circostanza nota che possa incidervi. Non nomina le metriche. A seconda del compito, potrebbero essere:

• Accuratezza — precisione, richiamo, F1 o misure specifiche del dominio
• Robustezza — prestazioni con input avversari o con spostamento della distribuzione
• Cibersicurezza — resistenza all'avvelenamento dei dati, all'estrazione del modello o ad attacchi avversari

Che cosa cercano gli auditor:

• Relazioni sulle prestazioni nel set di prova con intervalli di confidenza
• Parametri di riferimento di robustezza (ad esempio le prestazioni su dati fuori distribuzione)
• Relazioni di audit sulla cibersicurezza o risultati di test di penetrazione

Errore ricorrente: riportare solo l'accuratezza aggregata, senza disaggregare le prestazioni per gruppo demografico, caso limite o scenario avversario.

5. Circostanze note o prevedibili che possono comportare rischi — punto b), iii)

I deployer devono essere avvertiti delle situazioni, nell'uso previsto o in condizioni di uso improprio ragionevolmente prevedibile, che possono comportare rischi per la salute, la sicurezza o i diritti fondamentali.

Che cosa cercano gli auditor:

• Un elenco documentato di casi limite e modalità di guasto
• Indicazioni per attenuare i rischi (ad esempio «Non usare questo sistema per la diagnosi medica»)
• La prova che le persone che usano il sistema sono formate su questi limiti

Errore ricorrente: non fornire alcuna documentazione sulle modalità di guasto, presumendo che i deployer «se ne accorgeranno».

6. Misure di sorveglianza umana — punto d)

L'articolo 14 impone la sorveglianza umana per i sistemi di IA ad alto rischio. L'articolo 13 richiede che le istruzioni per l'uso descrivano tali misure di sorveglianza, comprese le misure tecniche che aiutano i deployer a interpretare l'output.

Che cosa cercano gli auditor:

• La documentazione del ruolo dell'operatore umano (ad esempio «Esaminare tutti i casi segnalati prima della decisione finale»)
• I materiali di formazione per gli operatori umani
• La prova che il sistema sostiene la sorveglianza (funzioni di spiegabilità, meccanismi di override ecc.)

Errore ricorrente: impiegare un sistema interamente automatizzato senza alcun ruolo documentato di sorveglianza umana.

7. Risorse, manutenzione e log — punti e) ed f)

Le istruzioni devono inoltre indicare le risorse computazionali e hardware di cui il sistema ha bisogno, la sua durata prevista e le misure di manutenzione e cura che ne garantiscono il funzionamento, compresi gli aggiornamenti software e la loro frequenza. Ove pertinente, devono descrivere come i deployer possono raccogliere, conservare e interpretare i log che il sistema registra ai sensi dell'articolo 12.

Che cosa cercano gli auditor:

• Una specifica dell'hardware e dell'infrastruttura
• Una durata prevista dichiarata e un calendario di manutenzione
• Istruzioni per accedere ai log e conservarli

Errore ricorrente: lasciare che i deployer scoprano le esigenze di registrazione e di manutenzione del sistema dopo la messa in esercizio.

Lista di controllo per la conformità all'articolo 13

Informazione (articolo 13, paragrafo 3)	Documentazione necessaria	Lacuna ricorrente
Identità del fornitore — a)	Nome, indirizzo, e-mail di contatto nelle istruzioni per l'uso	Nessuna identificazione del fornitore
Caratteristiche, capacità, limiti — b)	Finalità prevista, parametri di riferimento prestazionali, modalità di guasto	Affermazioni di marketing senza dati quantitativi
Accuratezza, robustezza, cibersicurezza — b), ii)	Relazioni sul set di prova, parametri di robustezza, audit di sicurezza	Solo accuratezza aggregata, senza disaggregazione per casi limite
Rischi e modalità di guasto noti — b), iii)	Elenco dei casi limite, indicazioni di attenuazione del rischio	Nessuna documentazione sulle modalità di guasto
Modifiche predeterminate — c)	Modifiche stabilite al momento della valutazione iniziale della conformità	Modifiche al modello non descritte
Misure di sorveglianza umana — d)	Ruolo dell'operatore, materiali di formazione, meccanismi di override	Nessun ruolo di sorveglianza documentato
Risorse, durata, manutenzione — e)	Esigenze hardware, durata prevista, calendario degli aggiornamenti	Nessuna informazione sulla manutenzione
Meccanismi di registrazione — f)	Come raccogliere, conservare e interpretare i log	I log esistono ma i deployer non vi hanno accesso

Come l'articolo 13 si intreccia con gli altri requisiti

L'articolo 13 non vive isolato. Si interseca con:

• L'articolo 9 (gestione dei rischi) — i rischi individuati ai sensi dell'articolo 9 devono essere comunicati ai deployer ai sensi dell'articolo 13
• L'articolo 10 (governance dei dati) — le metriche di qualità dei dati documentate ai sensi dell'articolo 10 alimentano le informazioni sull'accuratezza richieste dall'articolo 13
• L'articolo 14 (sorveglianza umana) — le misure di sorveglianza progettate ai sensi dell'articolo 14 devono essere spiegate ai deployer ai sensi dell'articolo 13
• L'articolo 50 (trasparenza di determinati sistemi di IA) — se il suo sistema rientra anche nell'articolo 50 (chatbot, riconoscimento delle emozioni ecc.), ha obblighi di trasparenza aggiuntivi, applicabili dal 2 agosto 2026

Una strategia di conformità completa affronta tutti questi elementi insieme, non come liste di controllo separate.

Esempio concreto: un sistema di scoring creditizio

Supponiamo che abbia costruito un sistema di scoring creditizio basato su IA. Ai sensi dell'allegato III, punto 5, lettera b), si tratta di un sistema ad alto rischio. Ecco come si presenta la conformità all'articolo 13 (l'impresa citata è inventata):

1. Identità del fornitore: le istruzioni per l'uso indicano «Fornito da FinTech Corp, 123 Main St, Dublino, Irlanda. Contatto: compliance@fintechcorp.eu»
2. Caratteristiche, capacità, limiti: documenta che il sistema è progettato per decisioni di credito al consumo fino a 50 000 €, raggiunge l'89 % di accuratezza sui dati di convalida e ottiene risultati scarsi con richiedenti dalla storia creditizia esigua (meno di 3 linee di credito).
3. Modifiche predeterminate e manutenzione: indica quali modifiche al modello e alle sue prestazioni sono state stabilite al momento della valutazione iniziale della conformità, e il calendario degli aggiornamenti. Quando aggiorna il modello, invia inoltre ai deployer note di rilascio che indicano la nuova accuratezza (91 %) e le variazioni dei tassi di falsi positivi e falsi negativi.
4. Accuratezza, robustezza, cibersicurezza: fornisce una relazione sulle prestazioni con precisione, richiamo e F1 per gruppo demografico, oltre ai risultati dei test di robustezza sulle prestazioni con input avversari (ad esempio richiedenti che dichiarano deliberatamente un reddito falso).
5. Rischi noti: documenta che il sistema può sottostimare il rischio per i lavoratori autonomi e sovrastimarlo per le persone immigrate di recente. Fornisce l'indicazione: «Esaminare manualmente tutte le domande di lavoratori autonomi e di persone immigrate di recente.»
6. Sorveglianza umana: documenta che gli addetti ai prestiti devono esaminare tutte le domande segnalate come «al limite» (punteggio 600-650) e hanno il potere di disattendere la raccomandazione del sistema.
7. Risorse e log: indica l'infrastruttura di cui il sistema ha bisogno, la sua durata prevista e come l'istituto di credito può recuperare e conservare i log delle decisioni.

Tutto questo viene raccolto nelle istruzioni per l'uso consegnate all'istituto di credito, che le trasmette a ogni addetto ai prestiti che usa il sistema. Quando un auditor chiede prove ai sensi dell'articolo 13, gli consegna questo documento insieme ai registri di formazione che attestano che gli addetti ai prestiti vi sono stati formati.

Che cosa succede se non si è conformi

La non conformità all'articolo 13 può comportare:

• sanzioni amministrative — un massimo previsto dalla legge di 15 milioni di euro o del 3 % del fatturato mondiale ai sensi dell'articolo 99, paragrafo 4 — per le PMI, l'importo inferiore;
• azioni di vigilanza del mercato — le autorità nazionali possono ordinarle di ritirare il sistema dal mercato o di sospenderne l'uso;
• esposizione alla responsabilità — se un deployer usa impropriamente il suo sistema perché lei non ha fornito informazioni adeguate, può essere chiamato a rispondere dei danni che ne derivano.

La data operativa per i sistemi ad alto rischio dell'allegato III è il 2 dicembre 2027. Un fornitore che immette sul mercato dell'UE un sistema di IA ad alto rischio a partire da quella data dovrà avere pronte, al momento dell'immissione, le istruzioni per l'uso previste dall'articolo 13.

Antimodelli ricorrenti

Questi sono gli antimodelli relativi all'articolo 13 che si incontrano più spesso:

• Nessuna documentazione rivolta ai deployer — il sistema non ha istruzioni per l'uso che ne spieghino finalità, limiti o prestazioni
• Affermazioni di marketing senza dati quantitativi — il sistema dichiara «elevata accuratezza» ma non fornisce metriche sul set di prova
• Nessuna documentazione sulle modalità di guasto — i deployer non vengono avvertiti dei casi limite né delle situazioni in cui il sistema rischia di fallire
• Nessuna indicazione sulla sorveglianza umana — ai deployer non viene detto quali misure di sorveglianza sono tenuti ad applicare
• Modifiche non descritte — il sistema cambia in modi che le istruzioni per l'uso non hanno mai predeterminato, senza informazioni su manutenzione o aggiornamenti
• Nessuna identificazione del fornitore — i deployer non sanno chi ha realizzato il sistema né come contattarlo

---

Questo articolo ha finalità puramente informative e non costituisce consulenza legale. Per orientamenti sulla sua situazione specifica, si rivolga a un avvocato qualificato in materia di regolamento europeo sull'IA.