--- title: "L'inventario dei sistemi AI: cosa deve contenere e come si aggiorna" url: https://zerofive.ai/blog/compliance/inventario-sistemi-ai-iso-42001 canonical: https://zerofive.ai/blog/compliance/inventario-sistemi-ai-iso-42001 language: it published: 2026-09-08 updated: 2026-09-18 author: "ZeroFive.AI" tags: ISO IEC 42001, inventario AI, AI system inventory, shadow AI, AIMS abstract: "Come costruire un inventario dei sistemi AI che regge un audit: definizione del perimetro, campi obbligatori, articolo 25 AI Act, discovery della shadow AI e piano a 90 giorni." --- # L'inventario dei sistemi AI: cosa deve contenere e come si aggiorna Se guardate al registro dei sistemi AI della maggior parte delle aziende in questo momento, ammesso che esista, trovereste quasi sempre la stessa scena: poche righe ferme da mesi, sistemi ormai dismessi ancora segnati come attivi, due o tre strumenti che il team commerciale usa tutti i giorni e che nessuno ha mai inserito perché non sembravano "AI vera". È successo anche a noi, prima di mettere ordine. L'inventario è il documento su cui poggia tutto il resto di un sistema di gestione dell'AI. La valutazione del rischio ha bisogno di sapere cosa valutare, l'impact assessment ha bisogno di un perimetro, il piano di formazione ha bisogno di sapere chi usa cosa. Quando l'inventario è sbagliato, tutti i documenti costruiti sopra ereditano lo stesso errore senza che nessuno se ne accorga fino all'audit. ## Prima dei campi viene la definizione La domanda che blocca quasi tutti i progetti di inventario nella prima settimana non è quale colonna aggiungere. È cosa conta come sistema AI. ISO/IEC 42001 e l'AI Act partono entrambi da una definizione ampia, allineata a quella OCSE: un sistema che, a partire da input, genera output come previsioni, contenuti, raccomandazioni o decisioni, con un certo grado di autonomia. Applicata alla realtà di un'azienda, quella definizione include parecchie cose che nessuno chiamerebbe spontaneamente intelligenza artificiale. I casi che nei nostri assessment generano più discussione sono sempre gli stessi quattro. Il foglio di calcolo con un modello di scoring costruito internamente da qualcuno che non lavora più in azienda. La funzione AI attivata dentro un software che avevate già, aggiunta dal fornitore in un aggiornamento senza che nessuno l'abbia scelta. Il chatbot sul sito, spesso considerato marketing e quindi mai passato dall'IT. E il modello acquistato tramite API, integrato in un flusso interno da un team di prodotto, che nell'organigramma non compare da nessuna parte. La regola pratica che suggeriamo: se un output di quel sistema influenza una decisione che riguarda una persona, un cliente o un fornitore, entra nell'inventario. La classificazione del rischio arriva dopo, e serve proprio a distinguere i casi banali da quelli seri. Escludere qualcosa prima di averlo registrato significa decidere senza avere gli elementi per farlo. ## Una riga per strumento o una riga per uso Questa scelta determina se l'inventario resterà utile o diventerà ingestibile, e va fatta all'inizio perché rifarla dopo costa parecchio. Lo stesso assistente generativo usato dal marketing per scrivere bozze di testi e dalle risorse umane per fare una prima scrematura di candidature è, tecnicamente, lo stesso strumento. Dal punto di vista del rischio sono due mondi diversi: il primo è un uso a impatto contenuto, il secondo ricade nella categoria di casi che l'Allegato III dell'AI Act tratta come ad alto rischio. Un inventario organizzato per strumento appiattisce questa differenza e produce righe che non dicono nulla di utile. Un inventario organizzato per coppia sistema più finalità la rende visibile: due righe, due owner, due classificazioni di rischio, due percorsi di controllo. Costa qualche riga in più e fa risparmiare mesi quando arriva il momento di dimostrare che le finalità critiche sono state trattate come tali. ## Provider o deployer, il campo che quasi nessuno compila La maggior parte delle aziende italiane presume di essere deployer di sistemi altrui, e quindi soggetta a obblighi più leggeri. La presunzione regge finché non incontra l'articolo 25 dell'AI Act, che elenca tre situazioni in cui chi utilizza un sistema ne diventa il fornitore a tutti gli effetti, assumendo gli obblighi previsti dall'articolo 16. La prima è mettere il proprio nome o marchio su un sistema ad alto rischio già immesso sul mercato, tipicamente in scenari di white label o rivendita, salvo diversa allocazione contrattuale. La seconda è apportare una modifica sostanziale a un sistema ad alto rischio che resta tale: l'articolo 3(23) la definisce come una modifica non prevista nella valutazione di conformità iniziale che incide sulla conformità stessa o sulla finalità prevista. La terza è cambiare la finalità di un sistema non classificato come ad alto rischio in modo che lo diventi. La seconda è quella che coglie più aziende di sorpresa, perché il perimetro della "modifica sostanziale" è più largo di quanto sembri: il fine-tuning su dati proprietari, la modifica di una soglia decisionale in un classificatore, la ristrutturazione di una pipeline di retrieval possono tutti ricadervi. La riclassificazione non passa da una notifica o da una registrazione, avviene per il solo verificarsi delle condizioni. Per questo l'inventario deve portare il ruolo assunto per ogni riga, e la data in cui quel ruolo è stato valutato l'ultima volta. È il campo che trasforma il registro da elenco descrittivo a strumento che segnala un'esposizione prima che diventi un problema. ## Cosa guarda un auditor in ciascun campo - **Nome e finalità**, descritta in linguaggio comprensibile a chi non ha costruito il sistema. Se la finalità è copiata dal materiale commerciale del fornitore, l'auditor lo capisce alla prima lettura e la considera un segnale sulla qualità dell'intero registro. - **Owner**, una persona con nome e cognome che risponde delle decisioni prese dal sistema. Un reparto non è un owner: quando la responsabilità è di tutti, in sede di audit non è di nessuno. - **Dati trattati e provenienza**, che è anche il collegamento diretto con la mappatura già richiesta dalla DPIA e con i requisiti sui dati dell'Annex A di ISO/IEC 42001. Compilare due volte le stesse informazioni in documenti separati è la ragione più comune per cui divergono. - **Stato nel ciclo di vita**: sviluppo, pilota, produzione, dismissione. Lo stato è quello che rende l'inventario leggibile a colpo d'occhio, e il passaggio da pilota a produzione è il momento in cui più spesso l'aggiornamento salta. - **Ruolo assunto**, provider o deployer, con la data dell'ultima valutazione. - **Livello di rischio**, allineato alla classificazione dell'AI Act dove applicabile, con la motivazione della classificazione, non solo l'esito. Un auditor non contesta quasi mai il livello scelto, contesta l'assenza di un ragionamento dietro. - **Origine**: sviluppato internamente, acquistato, o costruito sopra un modello di base esterno. Determina quali informazioni potete produrre da soli e quali dovete chiedere a qualcun altro, il che si traduce direttamente in clausole contrattuali. - **Fornitore e versione del modello**, quando il sistema poggia su componenti di terzi. - **Data dell'ultima revisione**, il campo che manca più spesso ed è il primo che viene guardato. Su quest'ultimo punto vale la pena essere espliciti su cosa segnala. Se tutte le righe riportano la stessa data di revisione, il registro racconta un esercizio fatto in blocco per prepararsi a qualcosa, non un processo vivo. Date diverse e distribuite nel tempo raccontano il contrario. ## Come si trova quello che non sapete di avere Chiedere ai responsabili di reparto quali sistemi AI usano produce liste incomplete, e non per reticenza. Chi usa uno strumento per andare più veloce non lo classifica mentalmente come sistema AI, lo classifica come il modo in cui fa il proprio lavoro. Per questo cinque fonti diverse danno risultati migliori di un questionario. Le note spese e gli estratti delle carte aziendali, cercando i nomi dei fornitori noti, fanno emergere gli abbonamenti individuali che non sono mai passati dagli acquisti. I log del provider di identità mostrano su quali applicazioni le persone si sono effettivamente autenticate, che è un dato di fatto e non un'autodichiarazione. L'inventario delle estensioni browser sui dispositivi gestiti intercetta una categoria che sfugge quasi sempre. La rilettura dei contratti SaaS già in essere fa emergere le funzionalità AI attivate dal fornitore dentro prodotti che avevate da anni, spesso senza una decisione esplicita da parte vostra. E la domanda ai team, se posta come "cosa usate per fare prima" invece di "usate strumenti di AI", ottiene risposte molto più accurate. ## Il fornitore che cambia modello senza dirvelo Un prodotto SaaS può sostituire il modello sottostante da una release all'altra. La finalità dichiarata resta identica, l'interfaccia pure, e il comportamento del sistema cambia senza che nulla nell'inventario lo registri. È un rischio che si governa dove nasce, cioè nel contratto. Le clausole che vediamo funzionare chiedono tre cose: preavviso in caso di cambio del modello o di modifiche rilevanti al comportamento del sistema, accesso alla documentazione tecnica necessaria per mantenere aggiornata la vostra valutazione, e indicazione esplicita del ruolo che il fornitore assume rispetto all'AI Act. Senza quelle clausole l'inventario resta accurato solo per il tempo che intercorre fino al primo aggiornamento silenzioso. ## Quando serve una riga nuova Un cambio di finalità apre sempre una riga nuova, perché cambia la classificazione del rischio e potenzialmente il ruolo assunto. Un cambio di versione del modello a parità di finalità aggiorna la riga esistente e fa scattare una revisione. Un nuovo reparto che adotta lo stesso sistema per la stessa finalità si aggiunge alla riga esistente. Un nuovo reparto che lo adotta per una finalità diversa apre una riga nuova. Le righe dismesse restano, con data e motivo. Un registro senza storico è un registro che qualcuno riscrive ogni volta invece di mantenerlo, e la differenza si vede subito. ## Chi lo aggiorna, e con quale innesco Un inventario che dipende dalla buona volontà di qualcuno che se ne ricorda non sopravvive un trimestre. Gli inneschi che reggono nel tempo sono quelli agganciati a processi che esistono già e che nessuno può saltare. Il primo è l'approvvigionamento: ogni acquisto software passa da una domanda che verifica la presenza di componenti AI, e la risposta positiva genera una riga. Il secondo è il passaggio in produzione: la procedura di messa in esercizio aggiorna lo stato del sistema corrispondente prima del rilascio, non dopo. Il terzo è un riesame periodico, trimestrale per le organizzazioni più esposte e semestrale per le altre, che recupera quello che è sfuggito ai primi due. Sopra i tre inneschi serve un responsabile del registro nel suo insieme, distinto dagli owner dei singoli sistemi. Non deve compilare le righe, deve accorgersi quando smettono di essere aggiornate. ## Foglio di calcolo o piattaforma Sotto le venti o trenta righe, un foglio di calcolo con controllo delle versioni e permessi in scrittura ristretti funziona bene e si costruisce in un pomeriggio. Il momento in cui conviene passare a uno strumento dedicato arriva quando servono tracciabilità delle modifiche, collegamenti automatici tra inventario, registro dei rischi e impact assessment, o quando il numero di owner coinvolti rende il coordinamento manuale più costoso della licenza. Partire dallo strumento è l'errore che vediamo più spesso in questa fase. Una piattaforma popolata con dati raccolti male produce gli stessi problemi di un foglio di calcolo, con in più il costo della licenza e la falsa sicurezza di avere risolto qualcosa. ## Prima di costruire il prossimo documento Senza un inventario aggiornato, l'impact assessment di cui abbiamo parlato nel pezzo precedente valuta sistemi che potrebbero non esistere più, o ne ignora altri che nel frattempo sono entrati in produzione. Il prossimo pezzo di questa serie parte proprio da qui, da cosa cambia se si progetta un sistema AI sapendo fin dall'inizio che dovrà finire in questo registro, invece di scoprirlo a lancio già avvenuto.