Alla scoperta delle norme dedicate all’intelligenza artificiale

 

 

SBOM, distinta base e obblighi di documentazione

Immaginate di acquistare un macchinario industriale complesso senza ricevere l’elenco dei suoi componenti, senza sapere da quali fornitori provengono, senza poter verificare se alcune parti sono state nel frattempo richiamate per difetti di sicurezza. 

Nel software accade esattamente questo, ogni giorno, da decenni. La risposta a questo problema si chiama SBOM, Software Bill of Materials: una “distinta base” strutturata che elenca i componenti di un sistema software, le loro relazioni, le loro versioni, le vulnerabilità note. 

Per i sistemi tradizionali il concetto esiste da anni. Per i sistemi di intelligenza artificiale, la questione è diventata urgente solo di recente, e nell’ultimo anno ha acquisito rilevanza normativa diretta.

 

 

Il G7 si muove: BSI, ACN e il documento di Ottawa

Il 12 maggio 2025, nell’ambito del Gruppo di lavoro sulla cybersecurity del G7, il BSI tedesco e l’ACN italiana hanno co-guidato la redazione di un documento intitolato G7 Shared Vision on Software Bill of Materials for AI. 

Il documento definisce gli elementi minimi che dovrebbe contenere una distinta base per i sistemi di intelligenza artificiale, organizzandoli in sette aree: 

• metadati del documento stesso 
• proprietà del sistema nel suo complesso
• caratteristiche dei modelli
• proprietà dei dataset 
• infrastruttura 
• proprietà di sicurezza e 
• indicatori di performance.

 

 

Sul piano formale, si tratta di soft law: gli autori dichiarano esplicitamente che questi elementi minimi non creano obblighi, standard o legislazione. Ma la qualificazione formale non ne riduce il peso pratico. La Commissione Europea ha partecipato attivamente al processo, e i documenti di consenso prodotti in questo contesto tendono storicamente a orientare il lavoro degli organismi di normazione tecnica, come CEN/CENELEC ed ENISA, che produrranno gli standard armonizzati rilevanti per il Cyber Resilience Act. Chi costruisce oggi sistemi di gestione della supply chain AI tenendo conto di questi elementi minimi si posiziona favorevolmente rispetto ai requisiti che materializzeranno negli standard vincolanti.

 

 

Il contenuto di uno SBOM

Il nucleo più significativo del documento riguarda i modelli. Per ciascun modello incluso nel sistema, la distinta base dovrebbe documentare, tra le altre cose, il valore hash dei pesi del modello (per rilevare modifiche non autorizzate e prevenire attacchi di model poisoning), le proprietà di addestramento, il tipo di licenza con la distinzione tra open weight, open architecture e open data, e le informazioni sulle vulnerabilità note.

Per i dataset, la distinta base dovrebbe includere informazioni sulla provenienza dei dati, i metodi di raccolta (incluso il web crawling e gli accordi commerciali), le proprietà statistiche e, in modo particolarmente rilevante per chi si occupa di protezione dei dati, la presenza di dati personali, dati sanitari, dati finanziari o dati coperti da copyright. Questa informazione interseca direttamente gli obblighi di trasparenza del GDPR e i presupposti per la valutazione d’impatto ex art. 35.

L’elemento dei flussi di dati di sistema documenta endpoint, API esterne e protocolli di comunicazione multi-agente: per un sistema basato su LLM che accede a strumenti esterni in modalità agentica, questo elemento cattura l’intera superficie di attacco.

 

 

L’AI Act: la documentazione tecnica già richiede qualcosa di simile

Per i sistemi di IA classificati ad alto rischio ai sensi del Regolamento (UE) 2024/1689, l’Allegato IV impone una documentazione tecnica dettagliata che include la descrizione dei componenti hardware e software, le caratteristiche dei dati di addestramento e le misure di cybersecurity. L’art. 10 regola la governance dei dati, l’art. 15 impone misure di robustezza e sicurezza informatica.

I sette cluster del documento G7 si sovrappongono in modo significativo a questi obblighi: il cluster sui dataset corrisponde in larga misura all’art. 10, il cluster sui modelli all’Allegato IV, il cluster sulle proprietà di sicurezza all’art. 15. 

Non vi è coincidenza perfetta tra i due quadri, perché le finalità primarie differiscono (sicurezza della supply chain nel caso G7, conformità risk-based nel caso AI Act), ma chi deve gestire entrambi i regimi ha tutto l’interesse a costruire un sistema documentale integrato che soddisfi entrambi usando i medesimi dati di base, senza duplicare il lavoro.

 

 

Il CRA: la distinta base diventa obbligo normativo

Interessante ricordare che il Cyber Resilience Act (applicabile a partire dall’11 dicembre 2027) introduce il c.d. SBOM come requisito esplicito per i fabbricanti di prodotti con elementi digitali: il Regolamento impone di identificare e documentare le vulnerabilità nei componenti di terze parti e di rendere disponibile un SBOM per i prodotti che incorporano software di terze parti.

Questo obbligo vale per il software tradizionale, ma si applica naturalmente e con maggiore complessità a qualsiasi prodotto che integri componenti AI, sia sviluppati internamente sia acquistati da provider esterni. 

Un’applicazione aziendale che incorpora un modello di linguaggio di terze parti, un sistema di analisi documentale basato su un modello open weight, un assistente virtuale costruito su API esterne: tutti rientrano nell’ambito di applicazione del CRA e richiedono un SBOM che documenti i componenti, inclusi i modelli AI utilizzati.

La distinzione tra chi sviluppa e chi integra è fondamentale: il fornitore originario del modello ha obblighi documentali propri. L’organizzazione che quel modello lo incorpora in un proprio prodotto o servizio non può limitarsi a ricevere passivamente la documentazione: deve verificarla, integrarla con i propri elementi e gestirla nel ciclo di vita del prodotto. 

 

 

I formati tecnici: CycloneDX e SPDX

Nella pratica, un SBOM è un file strutturato in un formato leggibile dalle macchine. I due standard più diffusi sono SPDX (System Package Data Exchange, progetto della Linux Foundation, diventato standard ISO/IEC 5962:2021) e CycloneDX (sviluppato dall’OWASP).

Entrambi stanno evolvendo per supportare elementi specifici per i sistemi AI: CycloneDX ha introdotto estensioni per la documentazione dei modelli e dei dataset nella versione 1.6, mentre SPDX sta lavorando in modo analogo nel contesto della versione 3.0. 

Il documento G7, peraltro, non prescrive nessuno dei due formati, richiedendo soltanto che il formato adottato sia processabile automaticamente. Gli esperti rilevano come l’assenza di un formato obbligatorio comune riduca l’interoperabilità e complichi l’automazione del vulnerability management lungo la filiera: è uno dei punti aperti che il percorso verso gli standard armonizzati dovrà risolvere.

 

 

Che cosa fare

Per le organizzazioni italiane soggette al CRA, a NIS2 o all’AI Act, il documento G7 offre oggi la mappatura più autorevole disponibile di quali informazioni dovrebbero essere richieste ai fornitori di componenti AI nel contesto di una due diligence sulla supply chain. 

Non è una checklist di conformità normativa diretta, ma è la migliore approssimazione consensuale attualmente disponibile di cosa significhi trasparenza della supply chain AI in un contesto multilaterale.

Per chi stipula contratti di fornitura di sistemi AI, clausole che richiedano la produzione di un SBOM strutturato secondo questi elementi minimi sono già oggi ragionevoli e difendibili come misure di sicurezza by design nell’ambito di un sistema di gestione della sicurezza delle informazioni. 

I tempi tecnici per costruire processi di SBOM management sono significativi: la scadenza del dicembre 2027 è raggiungibile, ma non per chi inizia a lavorarci nell’estate del 2027.

 

👾 👾 👾

Alla prossima!