Conosco già l’obiezione, perché me la faccio da solo ogni volta che sento la parola inventario. Un altro registro. Un altro documento che qualcuno compila con diligenza a gennaio e che a marzo è già archeologia, perché nel frattempo il team ha cambiato due dipendenze, un fornitore ha aggiornato le condizioni contrattuali e qualcuno ha messo in produzione un modello che nel registro non esiste. Se questa è la promessa, l’inventario è solo la burocrazia di sempre con un nome più tecnico, e chi lo propone sta vendendo il problema travestito da soluzione.
L’obiezione è giusta. Ed è esattamente il motivo per cui vale la pena scrivere questo pezzo, perché descrive alla perfezione un certo modo di fare inventario, quello compilato a mano, che è morto in partenza. Ma confondere quel modo con l’idea stessa di inventario significa non vedere cosa sta succedendo nella regolazione europea, dove cinque testi normativi diversi, scritti da direzioni generali diverse, per settori diversi, stanno convergendo sulla stessa richiesta senza essersi messi d’accordo.
Cinque norme, una frase sola
L’AI Act chiede un registro dei sistemi, una classificazione del rischio, una tracciabilità dei dati di addestramento e delle decisioni. Il Cyber Resilience Act chiede una distinta base del software, la famosa SBOM, e la capacità di dire in tempi rapidi quali prodotti contengono un componente vulnerabile. NIS2 chiede di conoscere la propria catena di fornitura e di governare gli incidenti con tempi di notifica che presuppongono di sapere già dove guardare. DORA, che parla al mondo finanziario ma conferma il pattern, chiede un registro delle dipendenze da fornitori ICT critici. La direttiva sulla responsabilità da prodotto, nella sua nuova versione, sposta l’onere della prova in modo tale che il produttore che non sa ricostruire cosa c’era dentro il proprio software a una certa data parte già perdente. Di come siamo arrivati fin qui, partendo da una bottiglia di ginger beer del 1932, ho scritto ne L’ultima bottiglia di Mrs Donoghue.
Sono lingue diverse. Registro, SBOM, mappatura, dossier tecnico. Ma la frase sottostante è una sola: dimostra di sapere cosa hai in casa. Quali modelli, quali componenti, quali fornitori, quali dati, quali responsabilità, quali cambiamenti.
Non conforme oppure ingovernabile
E qui arriva il punto che secondo me viene sistematicamente frainteso. Un’organizzazione che non sa rispondere a queste domande non è un’organizzazione non conforme. Non conforme è chi conosce il proprio sistema e ha scelto di non adeguarlo, una posizione che si può difendere, negoziare, sanare. Chi non conosce il proprio sistema è in una condizione diversa e peggiore: è ingovernabile. Non può decidere di adeguarsi nemmeno volendo, perché non sa a cosa applicare la decisione.
La strategia dell’attesa
Nel frattempo, la strategia più diffusa che incontro è l’attesa. Ci adegueremo quando esce la linea guida definitiva, quando l’autorità nazionale chiarisce, quando arriva lo standard armonizzato, quando il Digital Omnibus stabilizza il calendario. Ne ho scritto qualche settimana fa: il rinvio delle scadenze non è un condono, e chi lo legge così sta scambiando una proroga per un’assoluzione. Ma c’è un errore più profondo nell’attesa, ed è l’idea che la conformità sia un contenuto che qualcuno prima o poi ci detterà, e che il nostro compito sia solo trascriverlo. Le linee guida diranno come descrivere il sistema. Non potranno mai descriverlo al posto nostro. E la parte difficile, quella che richiede mesi e attraversa i confini tra i team, non è la trascrizione. È sapere cosa scrivere.
La mappa che non esiste
Lo vedo nel lavoro di tutti i giorni. Quando entriamo in un progetto in ambito sanitario o nella pubblica amministrazione, la domanda che facciamo per prima non riguarda mai la norma. Riguarda la mappa. Quali applicazioni sono in produzione, chi ne è responsabile, da quali librerie dipendono, dove risiedono i dati, quali trattamenti sono stati valutati, quali contratti coprono quali fornitori, cosa è cambiato negli ultimi sei mesi. La risposta onesta, quasi ovunque, è che la mappa non esiste. Esistono frammenti: un foglio di calcolo dell’IT aggiornato a un anno fa, un registro dei trattamenti fermo alla versione consegnata al consulente, la memoria di due persone che se domani cambiano lavoro portano via metà dell’architettura. Nessuno di questi frammenti parla con gli altri, e nessuno viene aggiornato dagli eventi che dovrebbero alimentarlo.
Il registro morto e l’inventario vivo
Qui torna l’obiezione iniziale, e qui si scioglie. Il registro che invecchia in un cassetto e la mappa che serve alla compliance europea non sono la stessa cosa fatta con più o meno diligenza. Sono due oggetti di natura diversa. Il primo è un documento, il secondo è un sottoprodotto dei processi. Una SBOM non si compila: si genera dalla pipeline di build, a ogni build, e se la pipeline non la genera il problema è la pipeline, non la volontà delle persone. Un registro dei sistemi AI non si aggiorna a memoria: si aggiorna perché il processo di messa in produzione di un modello passa da lì, e un modello che non è nel registro semplicemente non arriva in produzione. Un change log non è un rito: è la traccia che permette, quando arriva la segnalazione di una vulnerabilità o la richiesta di un’autorità, di ricostruire cosa c’era e quando. L’inventario vivo non chiede alle persone di ricordarsi di documentare. Chiede all’architettura dei processi di produrre documentazione come effetto collaterale del lavoro normale. È una differenza di ingegneria, non di disciplina, ed è la stessa idea che tempo fa ho chiamato compliance come architettura.
La funzione che non ha nome
C’è però un problema che l’ingegneria da sola non risolve, ed è che questa mappa attraversa territori che nelle organizzazioni hanno proprietari diversi. La SBOM vive con chi fa DevOps. Il registro dei trattamenti vive con il DPO. I contratti con i fornitori vivono con l’ufficio acquisti o con la direzione. Gli incidenti vivono con chi fa sicurezza, quando esiste qualcuno che fa sicurezza. Il registro AI, dove esiste, vive con chi ha avuto la sfortuna di alzare la mano nella riunione sbagliata. Ognuno di questi pezzi ha un owner, ma la coerenza tra i pezzi non ce l’ha nessuno. Non è una figura da assumere, e diffido di chi la presenta come l’ennesimo ruolo con acronimo da aggiungere all’organigramma. È una funzione che oggi non ha nome e che cade nei buchi tra il DPO, che guarda ai dati personali, il CISO, che guarda alle minacce, e il CTO, che guarda al prodotto. Qualcuno deve tenere insieme la distinta del software, il registro dei sistemi AI, le valutazioni d’impatto, i contratti, il change log e la storia degli incidenti, non per compilarli ma per garantire che raccontino lo stesso sistema. Nelle organizzazioni piccole sarà un cappello in più su una testa che già ne porta altri. In quelle grandi diventerà un mestiere, e ne ho già descritto l’ascesa. In entrambi i casi, chi lo farà bene avrà in mano una cosa che vale più della conformità: la descrizione operativa dell’azienda.
La specifica dell’organizzazione
E qui chiudo il cerchio con qualcosa che ho scritto a proposito dello sviluppo software. Nello sviluppo guidato da specifiche, il codice diventa un derivato e la specifica diventa l’asset: è lei che si mantiene, si versiona, si discute, mentre il codice si rigenera. La regolazione europea, senza saperlo, sta dicendo la stessa cosa un livello più su. Il faldone è il derivato. L’inventario vivo è la specifica dell’organizzazione, la descrizione mantenuta e versionata da cui i documenti di conformità si possono rigenerare ogni volta che una norma, un’autorità o un cliente li chiede in un formato nuovo. Chi ha la specifica produce il faldone in giorni. Chi ha solo faldoni non riesce a produrre nemmeno la specifica, e accumula senza vederlo un debito di specifica su scala d’impresa.
Cosa premierà il 2026
Per questo credo che il 2026 non premierà chi compila meglio. Le scadenze si spostano, le linee guida arrivano in ritardo, gli standard armonizzati sono ancora in gran parte sulla carta, e tutto questo rumore di calendario nasconde la vera selezione in corso. Il 2026 premierà chi sa descrivere il proprio sistema meglio di come lo descrivono gli altri, ai clienti che lo chiedono nei capitolati, alle autorità che lo chiederanno nelle ispezioni, e prima ancora a se stesso, quando dovrà decidere in fretta cosa cambiare. La compliance è solo il nome burocratico di questa capacità. L’inventario è il suo strumento. E nessuna proroga ha mai reso governabile un sistema che il suo proprietario non sa raccontare.
Cosa ti porti a casa
Cinque normative europee, scritte da direzioni generali diverse per settori diversi, stanno convergendo sulla stessa richiesta senza essersi messe d’accordo: AI Act, CRA, NIS2, DORA e PLD chiedono tutte, con parole diverse, di dimostrare di sapere cosa hai in casa.
Non conforme è chi conosce il proprio sistema e ha scelto di non adeguarlo: una posizione che si può difendere, negoziare, sanare. Chi non conosce il proprio sistema è ingovernabile, che è una condizione peggiore: non può decidere di adeguarsi nemmeno volendo.
Aspettare linee guida e standard armonizzati scambia la conformità per un contenuto da trascrivere. Le linee guida diranno come descrivere il sistema, non potranno mai descriverlo al posto nostro. La parte difficile non è la trascrizione, è sapere cosa scrivere.
Il registro che invecchia in un cassetto e l’inventario vivo sono oggetti di natura diversa: il primo è un documento, il secondo un sottoprodotto dei processi. Una SBOM non si compila, si genera dalla pipeline a ogni build. È una differenza di ingegneria, non di disciplina.
La coerenza tra SBOM, registro AI, valutazioni d’impatto, contratti e change log non ha un owner: cade nei buchi tra il DPO, il CISO e il CTO. Chi presidierà quella funzione avrà in mano qualcosa che vale più della conformità: la descrizione operativa dell’azienda.
Domande e risposte
Perché la compliance europea richiede un inventario?
Perché cinque testi normativi diversi convergono sulla stessa richiesta. L’AI Act chiede un registro dei sistemi, una classificazione del rischio e la tracciabilità dei dati di addestramento. Il Cyber Resilience Act chiede la SBOM e la capacità di dire in tempi rapidi quali prodotti contengono un componente vulnerabile. NIS2 chiede di conoscere la catena di fornitura e di notificare gli incidenti in tempi che presuppongono di sapere già dove guardare. DORA chiede un registro delle dipendenze da fornitori ICT critici. La PLD revisionata sposta l’onere della prova in modo tale che il produttore che non sa ricostruire cosa c’era nel proprio software a una certa data parte già perdente. Sono lingue diverse, ma la frase sottostante è una sola: dimostra di sapere cosa hai in casa.
Che differenza c'è tra essere non conformi ed essere ingovernabili?
Non conforme è chi conosce il proprio sistema e ha scelto di non adeguarlo: una posizione che si può difendere, negoziare, sanare. Chi non conosce il proprio sistema è in una condizione diversa e peggiore: è ingovernabile. Non può decidere di adeguarsi nemmeno volendo, perché non sa a cosa applicare la decisione. La distinzione conta perché la maggior parte delle organizzazioni che si crede «indietro sulla compliance» in realtà non è indietro su un adempimento: è priva della mappa su cui qualunque adempimento andrebbe applicato.
Cos'è un inventario vivo e in cosa differisce da un registro tradizionale?
Sono oggetti di natura diversa, non lo stesso oggetto fatto con più o meno diligenza. Il registro tradizionale è un documento: qualcuno lo compila, poi il sistema cambia e il documento invecchia. L’inventario vivo è un sottoprodotto dei processi: la SBOM si genera dalla pipeline di build a ogni build, il registro dei sistemi AI si aggiorna perché la messa in produzione di un modello passa da lì, il change log è la traccia che permette di ricostruire cosa c’era e quando. Non chiede alle persone di ricordarsi di documentare: chiede all’architettura dei processi di produrre documentazione come effetto collaterale del lavoro normale.
Chi dovrebbe essere responsabile dell'inventario in azienda?
Ogni pezzo ha già un owner: la SBOM vive con chi fa DevOps, il registro dei trattamenti con il DPO, i contratti con l’ufficio acquisti, gli incidenti con chi fa sicurezza. Quello che non ha un owner è la coerenza tra i pezzi, cioè la garanzia che raccontino tutti lo stesso sistema. Non è necessariamente una figura da assumere: nelle organizzazioni piccole sarà un cappello in più su una testa che già ne porta altri, in quelle grandi diventerà un mestiere. È una funzione che oggi cade nei buchi tra il DPO, che guarda ai dati personali, il CISO, che guarda alle minacce, e il CTO, che guarda al prodotto.
Conviene aspettare le linee guida definitive prima di adeguarsi?
No, e per due ragioni. La prima è che il rinvio delle scadenze non è un condono: il Digital Omnibus ha spostato alcune date e confermato tutto il resto. La seconda è più profonda: aspettare presuppone che la conformità sia un contenuto che qualcuno prima o poi ci detterà, e che il nostro compito sia solo trascriverlo. Le linee guida diranno come descrivere il sistema, non potranno mai descriverlo al posto nostro. La parte che richiede mesi e attraversa i confini tra i team non è la trascrizione: è sapere cosa scrivere. E quella parte non scade, non si rinvia e non diventa più facile col tempo.
L'autore
