Inventario dei sistemi di IA: campi, norme e metodo

In sintesi

• L’inventario dei sistemi di IA è il registro interno di ogni sistema, modello, agente e servizio di IA di terzi che l’organizzazione sviluppa, acquista o utilizza.
• Nessun articolo dell’AI Act si intitola «inventario», ma la registrazione nella banca dati UE (artt. 49 e 71) è impossibile senza.
• Inventario, banca dati UE, model registry e AI-BOM sono quattro oggetti distinti, con custodi e status giuridici diversi.
• NIST AI RMF (GOVERN 1.6), ISO/IEC 42001, OMB M-25-21 e SR 26-2 chiedono esplicitamente un inventario.
• Un inventario utile collega ogni voce a un responsabile, a una classificazione del rischio, alle valutazioni svolte e alle evidenze.

L’inventario dei sistemi di IA: che cos’è e che cosa non è

Un chiarimento preliminare: qui non si parla di gestione del magazzino con l’intelligenza artificiale. L’inventario dei sistemi di IA è l’elenco governato di tutti i sistemi di IA che l’organizzazione sviluppa, acquista o utilizza: applicazioni interne, modelli di fondazione richiamati via API, funzionalità di IA incorporate nei SaaS, agenti e relativi strumenti. Ogni voce descrive scopo, ruolo giuridico, responsabile, classificazione del rischio e valutazioni collegate. Il precedente più vicino è il registro dei trattamenti previsto dall’articolo 30 del GDPR, che molte organizzazioni estendono. Ma il registro GDPR ragiona per trattamento di dati personali, mentre l’inventario dei sistemi di IA ragiona per sistema e per uso. Cinque oggetti vicini vengono spesso confusi: <table header-row=”true”> <tr> <td>Oggetto</td> <td>Che cos’è</td> <td>Chi lo tiene</td> <td>Status giuridico</td> </tr> <tr> <td>Inventario dei sistemi di IA</td> <td>Registro interno di tutti i sistemi, modelli, agenti e servizi di IA, con uso, ruolo, responsabile e rischio</td> <td>L’organizzazione (governance dell’IA o compliance)</td> <td>Non nominato dall’AI Act ma presupposto; richiesto da NIST AI RMF, ISO/IEC 42001, OMB M-25-21</td> </tr> <tr> <td>Registrazione nella banca dati UE</td> <td>Scheda pubblica (o riservata) di un sistema ad alto rischio, o esentato ai sensi dell’art. 6, par. 3, nella banca dati della Commissione</td> <td>Il fornitore e i deployer pubblici; la Commissione gestisce la banca dati</td> <td>Obbligo di legge: artt. 49 e 71 del Regolamento (UE) 2024/1689</td> </tr> <tr> <td>Model registry</td> <td>Catalogo tecnico di versioni, artefatti e metriche dei modelli in una piattaforma MLOps</td> <td>Team di data science</td> <td>Nessuno: strumento operativo</td> </tr> <tr> <td>AI-BOM</td> <td>Distinta dei componenti di un sistema (modelli, dataset, librerie), in formati come SPDX 3.0 o CycloneDX ML-BOM</td> <td>Chi costruisce o integra il sistema</td> <td>Nessuno in generale; utile per la due diligence</td> </tr> <tr> <td>Registro dei rischi</td> <td>Elenco dei rischi con valutazione e misure di mitigazione</td> <td>Risk management</td> <td>Dipende dal regime; alimentato dall’inventario</td> </tr> </table> Il model registry vede solo i modelli interni, l’AI-BOM scende dentro un singolo sistema, la banca dati UE copre una parte dei sistemi e il registro dei rischi parte dai rischi. Soltanto l’inventario dei sistemi di IA risponde alla domanda di partenza: quali sistemi usiamo, per fare che cosa, e chi ne risponde? È anche la base della documentazione del sistema di IA.

Come l’inventario dei sistemi di IA sostiene una governance responsabile

In che modo un inventario sostiene una governance responsabile? Attraverso cinque meccanismi concreti, ognuno legato a un controllo che senza inventario non funziona.

1. Fissa il perimetro di ogni altro controllo. Formazione, valutazioni d’impatto, monitoraggio, audit: ogni controllo si applica «a tutti i sistemi di IA in ambito». Senza l’inventario dei sistemi di IA, quel «tutti» resta indefinito e la copertura non si può misurare. È anche il primo argine contro gli strumenti adottati dai reparti senza alcuna revisione.
2. Guida la classificazione e la graduazione del rischio. L’AI Act distingue pratiche vietate, sistemi ad alto rischio, obblighi di trasparenza e rischio minimo. Per stabilire quali sistemi rientrano nell’allegato III bisogna prima sapere quali sistemi esistono e per quale scopo vengono usati. L’inventario affianca la classificazione regolamentare a quella interna, così che il livello di controllo segua il livello di rischio.
3. Nomina un responsabile per ogni sistema. Una voce senza responsabile è una voce che nessuno aggiornerà. L’inventario collega ciascun sistema a un responsabile di business, che risponde dell’uso, e a un responsabile tecnico, che risponde del funzionamento. È su questi nomi che il comitato di governance dell’IA può esercitare la propria supervisione.
4. Rileva il cambiamento. Un nuovo uso, una nuova versione del modello o un nuovo fornitore possono cambiare la classificazione di un sistema. Se l’inventario dei sistemi di IA registra questi eventi come trigger, il cambiamento diventa visibile prima di trasformarsi in un problema di conformità. Altrimenti un chatbot interno può diventare uno strumento di selezione del personale senza che nessuno lo noti.
5. È l’evidenza da cui l’auditor campiona. Auditor interni, organismi di certificazione e autorità di vigilanza partono dall’elenco dei sistemi per estrarre un campione. Un inventario completo e aggiornato rende l’audit riproducibile; un inventario lacunoso rende indimostrabile qualunque affermazione di conformità.

In pratica, l’inventario dei sistemi di IA è l’indice del sistema di gestione: le policy dicono che cosa fare, l’inventario dei sistemi di IA dice a che cosa applicarlo. Le organizzazioni mature lo trattano come un dato di riferimento, alla pari dell’anagrafica clienti, e non come un allegato annuale.

Quali norme rendono obbligatorio un inventario dei sistemi di IA

Nessun testo normativo europeo usa l’espressione «inventario dei sistemi di IA», eppure diversi regimi lo rendono di fatto obbligatorio: alcuni in modo esplicito, altri perché i loro obblighi non si adempiono senza. La tabella fotografa la situazione a settembre 2026; per il quadro generale si veda la nostra guida alla conformità dell’IA. <table header-row=”true”> <tr> <td>Regime</td> <td>Disposizione</td> <td>Chi</td> <td>Che cosa richiede</td> <td>Stato a settembre 2026</td> </tr> <tr> <td>AI Act (Reg. UE 2024/1689)</td> <td>Artt. 6, par. 4; 26, par. 8; 49 e 71</td> <td>Fornitori e deployer pubblici</td> <td>Registrazione nella banca dati UE dei sistemi ad alto rischio e di quelli esentati ai sensi dell’art. 6, par. 3</td> <td>In vigore; allegato III differito al 2 dicembre 2027, registrazione mantenuta</td> </tr> <tr> <td>NIST AI RMF 1.0</td> <td>GOVERN 1.6</td> <td>Organizzazioni che adottano il framework</td> <td>Meccanismi di inventario con risorse commisurate al rischio</td> <td>Volontario</td> </tr> <tr> <td>ISO/IEC 42001:2023</td> <td>Allegato A.4</td> <td>Organizzazioni certificate</td> <td>Documentazione delle risorse di ciascun sistema</td> <td>Volontario, vincolante per la certificazione</td> </tr> <tr> <td>Agenzie federali USA</td> <td>OMB M-25-21, EO 13960, Advancing American AI Act</td> <td>Agenzie federali</td> <td>Inventario annuale pubblico dei casi d’uso di IA</td> <td>Obbligatorio; inventario 2025 pubblicato ad aprile 2026</td> </tr> <tr> <td>Banche USA</td> <td>SR 26-2 (Fed, OCC, FDIC)</td> <td>Istituti vigilati</td> <td>Inventario dei modelli con graduazione per materialità</td> <td>In vigore dal 17 aprile 2026, sostituisce SR 11-7</td> </tr> <tr> <td>Settore pubblico britannico</td> <td>ATRS</td> <td>Ministeri centrali ed enti collegati</td> <td>Scheda pubblica per ogni strumento algoritmico in ambito</td> <td>Obbligatorio dal 2025</td> </tr> </table>

AI Act: la registrazione presuppone un inventario

Il Regolamento (UE) 2024/1689 non ha un articolo sull’inventario, ma l’articolo 49 impone al fornitore di registrare nella banca dati UE i sistemi ad alto rischio dell’allegato III prima dell’immissione sul mercato o della messa in servizio. Chi conclude, ai sensi dell’articolo 6, paragrafo 3, che un sistema dell’allegato III non è ad alto rischio deve documentare la valutazione (art. 6, par. 4) e registrarlo comunque (art. 49, par. 2). I deployer pubblici registrano il proprio uso (artt. 26, par. 8, e 49, par. 3); contrasto, migrazione e frontiere vanno in una sezione non pubblica (art. 49, par. 4). La banca dati è gestita dalla Commissione (art. 71). Il Regolamento Omnibus digitale sull’IA (UE) 2026/1744, in vigore dal 27 luglio 2026, ha differito gli obblighi dell’allegato III al 2 dicembre 2027 e quelli dell’allegato I al 2 agosto 2028, ma ha mantenuto l’obbligo di registrazione. Senza un inventario dei sistemi di IA nessuno sa quali sistemi registrare; il nostro approfondimento sui sistemi di IA ad alto rischio spiega come si arriva alla classificazione.

NIST AI RMF: GOVERN 1.6

Il NIST AI RMF nomina l’inventario in modo esplicito. La sottocategoria GOVERN 1.6 recita: «Mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities», ossia meccanismi di inventario dotati di risorse commisurate alle priorità di rischio. Il Playbook del NIST suggerisce di censire tutti i sistemi e di estendere l’inventario alla provenienza dei dati, ai problemi noti, ai ruoli di supervisione umana e ai modelli di fondazione.

ISO/IEC 42001: l’allegato A.4 sulle risorse

La norma ISO/IEC 42001:2023 dedica il controllo A.4 alle risorse dei sistemi di IA. Il punto A.4.2 chiede, in sostanza, di identificare e documentare per ciascun sistema le risorse di dati, gli strumenti, le risorse di sistema e di calcolo e le competenze umane coinvolte. Un organismo di certificazione si aspetta quindi di trovare un elenco dei sistemi in ambito, ognuno con le proprie risorse: è l’inventario dei sistemi di IA sotto un altro nome. Il percorso è descritto nella guida alla certificazione ISO 42001.

Agenzie federali statunitensi: OMB M-25-21

Negli Stati Uniti l’inventario è pubblico. Sulla base dell’Executive Order 13960 (sezione 5), dell’Advancing American AI Act e del memorandum OMB M-25-21, le agenzie federali pubblicano ogni anno i propri casi d’uso. L’inventario federale 2025, diffuso dall’OMB ad aprile 2026, elenca 3.611 casi d’uso provenienti da 56 comunicazioni delle agenzie, di cui 445 ad alto impatto: più del doppio dei 1.757 casi del 2024. Sono esclusi sicurezza nazionale e ricerca. La lezione per le imprese: si inventariano gli usi, non gli strumenti.

Banche: il model inventory di SR 26-2

La lettera SR 26-2 della Federal Reserve del 17 aprile 2026, con OCC e FDIC, ha sostituito SR 11-7: definizione di modello più ristretta, graduazione per materialità, modelli non materiali ammessi nell’inventario con controlli più leggeri. Secondo i commentatori, IA generativa e agenti restano in gran parte fuori dalla definizione: le banche hanno quindi bisogno di un inventario dei sistemi di IA più ampio del model inventory. Si veda la pagina sulla gestione del rischio di modello.

Registri di trasparenza nel settore pubblico

Nel Regno Unito l’Algorithmic Transparency Recording Standard (ATRS) è obbligatorio dal 2025 per ministeri ed enti collegati, con schede pubblicate su GOV.UK. In Italia la legge 132/2025 ha designato AgID come autorità di notifica e ACN come autorità di vigilanza del mercato ai fini dell’AI Act. Per le amministrazioni italiane, la registrazione dell’uso prevista dall’articolo 49, paragrafo 3, presuppone anch’essa un inventario dei sistemi di IA aggiornato.

L’inventario dei sistemi di IA: i campi indispensabili

Un inventario dei sistemi di IA utile non è un elenco di nomi di prodotti: ogni colonna esiste perché una norma o un controllo la richiede. Questi sono i campi minimi. <table header-row=”true”> <tr> <td>Campo</td> <td>Perché conta</td> <td>Regime che lo chiede</td> </tr> <tr> <td>Identificativo univoco, nome e stato nel ciclo di vita</td> <td>Collega valutazioni ed evidenze alla stessa voce; distingue pilota, produzione, dismissione</td> <td>ISO/IEC 42001 (A.4), NIST GOVERN 1.6</td> </tr> <tr> <td>Finalità di business e caso d’uso</td> <td>La classificazione dell’AI Act dipende dall’uso previsto, non dalla tecnologia</td> <td>AI Act (art. 6 e allegato III), OMB M-25-21</td> </tr> <tr> <td>Ruolo (fornitore, deployer, importatore, distributore)</td> <td>Determina quali obblighi si applicano</td> <td>AI Act (artt. 16, 23, 24 e 26)</td> </tr> <tr> <td>Responsabile di business e responsabile tecnico</td> <td>Senza responsabile nessuno aggiorna né risponde</td> <td>NIST GOVERN 1.6 (Playbook), SR 26-2</td> </tr> <tr> <td>Fornitore o provenienza del modello, incluso il modello di fondazione</td> <td>Rende visibili le dipendenze di fornitura</td> <td>NIST Playbook, AI-BOM (SPDX, CycloneDX)</td> </tr> <tr> <td>Categorie di dati, inclusi dati personali e categorie particolari</td> <td>Collega l’inventario al registro dei trattamenti e alla DPIA</td> <td>GDPR (artt. 30 e 35), ISO/IEC 42001 (A.4)</td> </tr> <tr> <td>Persone interessate e impatto delle decisioni</td> <td>Misura la gravità potenziale e l’esigenza di tutele</td> <td>AI Act (art. 27), OMB M-25-21 (alto impatto)</td> </tr> <tr> <td>Classificazione del rischio (livello AI Act e livello interno)</td> <td>Stabilisce l’intensità dei controlli da applicare</td> <td>AI Act (art. 6), SR 26-2 (materialità)</td> </tr> <tr> <td>Valutazioni collegate (DPIA, FRIA, valutazione d’impatto, valutazione della conformità)</td> <td>Dimostra che le valutazioni sono state svolte</td> <td>GDPR (art. 35), AI Act (artt. 27 e 43), ISO/IEC 42001</td> </tr> <tr> <td>Modalità di sorveglianza umana</td> <td>Documenta chi può intervenire, con quale autorità e come</td> <td>AI Act (artt. 14 e 26), NIST Playbook</td> </tr> <tr> <td>Numero di registrazione nella banca dati UE, se applicabile</td> <td>Collega la voce interna alla scheda ufficiale</td> <td>AI Act (artt. 49 e 71)</td> </tr> <tr> <td>Data di revisione e registro delle modifiche</td> <td>Dimostra che l’inventario è vivo e non una fotografia</td> <td>NIST GOVERN 1.6, ISO/IEC 42001</td> </tr> </table> Le valutazioni collegate trasformano l’inventario dei sistemi di IA da elenco a strumento di controllo: se una voce ad alto rischio non ha né una valutazione d’impatto sull’IA né una valutazione della conformità collegata, la lacuna salta subito all’occhio. La sorveglianza umana va descritta in modo operativo (chi, con quale autorità, entro quali tempi) e non con una formula generica. La provenienza del modello, spesso assente per i servizi acquistati, va raccolta in sede di due diligence dei fornitori di IA, non ricostruita a posteriori.

Come costruire e mantenere l’inventario dei sistemi di IA

Costruire l’inventario dei sistemi di IA è un progetto; mantenerlo è un processo. Ecco i passaggi.

1. Attivare più fonti di rilevazione. Nessuna fonte è completa da sola: contratti di acquisto e con i fornitori; log SSO e CASB, per gli strumenti non autorizzati; fatturazione cloud e API, che rivela le chiamate a modelli esterni; repository di codice e piattaforme di ML; infine una campagna di dichiarazione presso le unità di business, con un referente per reparto.
2. Istituire un punto di controllo in ingresso. Nessun sistema entra in produzione senza registrazione. Conviene agganciare la registrazione nell’inventario dei sistemi di IA ai processi esistenti: approvazione degli acquisti, rilascio in produzione, richiesta di accesso a un’API di modello.
3. Classificare e graduare. Ogni nuova voce passa per un triage: pratiche vietate (applicabili dal 2 febbraio 2025), possibile alto rischio ai sensi dell’allegato III, obblighi di trasparenza, rischio minimo, e poi il livello interno. Le voci dubbie vanno al comitato di governance.
4. Assegnare i responsabili. Un responsabile di business e uno tecnico per ogni voce, con nome e cognome, non un ufficio generico.
5. Definire i trigger di aggiornamento. L’inventario dei sistemi di IA va aggiornato a evento prima ancora che a calendario: nuova finalità, nuova versione del modello, nuovo fornitore, incidente, estensione a una nuova giurisdizione. Ognuno di questi trigger può modificare la classificazione.
6. Chiedere un’attestazione periodica. Oltre ai trigger, i responsabili confermano a intervalli regolari (almeno una volta l’anno, più spesso per i sistemi ad alto rischio) che la voce è ancora corretta.
7. Registrare la dismissione. Un sistema ritirato non si cancella: si chiude la voce con data, motivazione e destinazione di dati e modelli.

Un’avvertenza sugli agenti. Con l’IA agentica l’unità da inventariare non è più soltanto il modello: ogni agente va registrato come voce a sé, con i suoi obiettivi, i permessi e gli strumenti che può invocare, compresi i server e gli strumenti MCP (Model Context Protocol). Nell’inventario dei sistemi di IA, gli strumenti MCP collegati sono oggetti da censire, ciascuno con un responsabile e un perimetro d’azione documentato.

Dove falliscono gli inventari

Le cause sono quasi sempre le stesse.

• Il foglio di calcolo che invecchia. Un file condiviso funziona con venti voci e un solo curatore; con centinaia di voci, versioni concorrenti e nessuna storia delle modifiche, perde affidabilità in pochi mesi.
• Contare gli strumenti invece degli usi. Un assistente generico non è una voce: lo sono la scrittura di codice, la sintesi di contratti e la risposta ai clienti, che comportano rischi diversi pur usando lo stesso prodotto.
• Dimenticare l’IA incorporata nei SaaS. CRM, piattaforme HR e strumenti di ticketing aggiungono funzioni di IA con un semplice aggiornamento; se nessuno legge le note di rilascio, l’inventario resta indietro.
• Voci senza responsabile. Una voce intestata a «IT» non ha un vero responsabile.
• Nessun collegamento alle valutazioni. Un elenco che non rimanda a DPIA, FRIA e valutazioni della conformità non aiuta a dimostrare nulla.
• L’inventario costruito una volta per un audit. È il fallimento più comune: il documento supera la verifica e poi viene abbandonato.

Il filo comune è che l’inventario dei sistemi di IA viene trattato come un documento invece che come un dato. Lo stesso vale per la shadow AI: ciò che non è dichiarato non è governato.

Domande frequenti

L’inventario dei sistemi di IA è obbligatorio ai sensi dell’AI Act? Non con questo nome: l’AI Act non contiene un articolo sull’inventario. Tuttavia la classificazione dell’articolo 6, gli obblighi dei deployer dell’articolo 26 e la registrazione dell’articolo 49 (sistemi ad alto rischio e sistemi esentati ai sensi dell’articolo 6, paragrafo 3) non si possono adempiere senza sapere quali sistemi l’organizzazione sviluppa e utilizza. In pratica, l’inventario dei sistemi di IA è la condizione per dimostrare la conformità. Con ISO/IEC 42001 e NIST AI RMF l’esigenza è esplicita. Qual è la differenza tra un inventario dei sistemi di IA e la banca dati UE? L’inventario è interno, copre tutti i sistemi di IA dell’organizzazione ed è gestito dall’organizzazione stessa. La banca dati UE, istituita e gestita dalla Commissione ai sensi dell’articolo 71, riceve solo le registrazioni previste dall’articolo 49: sistemi ad alto rischio dell’allegato III, sistemi esentati ai sensi dell’articolo 6, paragrafo 3, e usi da parte di deployer pubblici. La registrazione UE è un sottoinsieme, e il suo numero diventa un campo dell’inventario. Chi dovrebbe essere responsabile dell’inventario? Serve un titolare del processo, di solito la funzione di governance dell’IA o la compliance, che definisce i campi, gestisce il punto di controllo in ingresso e riferisce al comitato. Il contenuto di ogni voce spetta al responsabile di business, affiancato da uno tecnico. Sicurezza, acquisti e protezione dei dati forniscono le fonti. Un inventario dei sistemi di IA gestito solo dall’IT vede gli strumenti e non gli usi. Con quale frequenza va aggiornato? A evento, prima ancora che a calendario. Ogni nuova finalità, nuova versione del modello, nuovo fornitore, incidente o estensione a una nuova giurisdizione deve aggiornare la voce e, se necessario, la classificazione. In aggiunta, un’attestazione periodica dei responsabili (almeno annuale, più frequente per i sistemi ad alto rischio) verifica che nulla sia sfuggito. La frequenza segue il rischio, come chiede il NIST. Un foglio di calcolo è sufficiente? Per iniziare sì: un foglio ben strutturato è meglio di nessun inventario. Il limite emerge con la crescita: nessuno storico delle modifiche, collegamenti fragili alle valutazioni, versioni divergenti, nessun flusso di attestazione. Quando l’inventario deve reggere un audit ISO/IEC 42001 o una verifica dell’autorità, servono una tracciabilità e dei collegamenti che un file condiviso difficilmente garantisce. Il criterio è dimostrare chi ha cambiato che cosa e quando. Gli agenti di IA vanno inventariati? Sì, come voci distinte. Un agente combina un modello, un obiettivo, dei permessi e degli strumenti che può invocare, spesso tramite server MCP. Il rischio dipende da ciò che l’agente può fare: leggere documenti riservati, modificare record, avviare pagamenti. Per ogni agente l’inventario dovrebbe registrare il responsabile, i sistemi a cui accede, gli strumenti collegati, le soglie oltre le quali serve un intervento umano e lo storico delle modifiche ai permessi.

Conclusione

L’inventario dei sistemi di IA non è un adempimento fine a sé stesso: è il dato di riferimento da cui dipendono classificazione, valutazioni, supervisione e audit. L’AI Act non lo nomina, ma la registrazione nella banca dati UE, confermata anche dall’Omnibus digitale, lo presuppone; NIST AI RMF, ISO/IEC 42001, OMB M-25-21 e SR 26-2 lo chiedono in modo più o meno esplicito. Ciò che distingue un inventario utile sono i collegamenti: ogni voce deve rimandare al suo responsabile, alla sua classificazione, alle valutazioni svolte e alle evidenze prodotte. È l’approccio del registro dell’IA di AI Sigil, che tiene insieme sistemi, agenti, valutazioni e prove in un unico posto. Qualunque sia lo strumento di partenza, il criterio resta lo stesso: un inventario vivo, collegato e con un responsabile per ogni voce.