Un inventario delle dipendenze è l'elenco scritto di tutto ciò che la tua automazione usa ma non possiede: le API che chiama, le chiavi con cui si autentica, i modelli AI su cui ragiona, le librerie che qualcun altro mantiene. È il documento più noioso di un progetto di automazione e, quando qualcosa si rompe alle sette di mattina, è il primo che vorresti avere. Quasi nessuno lo ha.
Il motivo è semplice: finché funziona, un'automazione sembra una cosa sola. Premi un pulsante, arriva il preventivo. In realtà dietro quel pulsante ci sono otto o dieci fornitori diversi, ognuno con un proprio calendario, una propria politica di aggiornamento e una propria idea di quanto preavviso darti.
Che cos'è l'inventario delle dipendenze, in pratica
Il concetto esiste già nel software e si chiama software bill of materials. La definizione della CISA, l'agenzia americana per la sicurezza informatica, è la più chiara in circolazione: «un inventario annidato, la lista degli ingredienti che compongono i componenti software». Annidato è la parola importante. I tuoi fornitori hanno fornitori.
Per un'automazione AI la lista degli ingredienti è più larga di un normale elenco di librerie. Comprende il modello linguistico e la sua versione esatta, le API dei gestionali e dei canali di messaggistica, i servizi di posta, le chiavi e i token, i certificati, i webhook in ingresso, le pianificazioni che fanno partire tutto e il server su cui gira. Ognuna di queste voci è un punto in cui il lavoro può fermarsi senza che nessuno abbia toccato niente.
Le tre scadenze che fermano un'automazione senza preavviso
La prima è il ritiro di un modello. I fornitori AI dismettono le versioni vecchie con un calendario pubblico: Anthropic, per esempio, dichiara un preavviso di sessanta giorni prima di spegnere un modello. Sessanta giorni sono tanti se qualcuno legge l'avviso, zero se l'indirizzo a cui arriva è la casella di un collaboratore che non lavora più con te.
La seconda è il cambio di versione di un'API. Qui il guasto è peggiore, perché spesso non è un errore: la chiamata viene reindirizzata alla versione più vicina e continua a funzionare, solo in modo diverso. Un campo cambia nome, una risposta perde un dato, l'automazione prosegue tranquilla producendo risultati sbagliati. È il tipo di problema che si scopre dal cliente, non dai log — e per cui vale la pena avere un monitoraggio che guardi l'esito e non solo l'esecuzione.
La terza è la più banale e la più frequente: una credenziale che scade. Un token con durata limitata, un certificato annuale, una password cambiata da chi non sapeva che quella utenza serviva a un'automazione. Inoltre, questa è la categoria in cui l'inventario ripaga di più, perché una scadenza è l'unico guasto che puoi mettere in calendario prima che accada.
Una sola dipendenza interrotta basta a fermare la catena: il resto del fascio è intatto e non serve a niente.
Il fornitore che non sapevi di avere
C'è poi la parte della catena su cui non hai nessun controllo. Il rapporto OSSRA 2026 di Black Duck, costruito su 947 basi di codice in diciassette settori, dà la misura del fenomeno: il codice open source è presente nel 98% dei progetti analizzati, il numero di componenti per progetto è cresciuto del 30% in un anno e le vulnerabilità medie per progetto sono più che raddoppiate, con un aumento del 107%. Nello stesso rapporto, solo il 24% delle organizzazioni dichiara di valutare in modo completo il codice generato dall'AI che immette nei propri sistemi.
Che cosa significa in concreto l'ha mostrato l'estate scorsa la campagna Shai-Hulud sul registro npm. Secondo l'analisi di Elastic Security Labs, un singolo manutentore compromesso ha portato a più di 400 pacchetti infettati, ripubblicati automaticamente dal malware stesso usando i token rubati. Il codice malevolo cercava oltre trecento tipi di credenziali, incluse le chiavi delle API AI e dei provider cloud. Nessuna di quelle aziende aveva scelto di avere quel pacchetto: ce l'avevano perché era una dipendenza di una dipendenza.
«La visibilità è diventata la nuova moneta della fiducia: componenti open source, dipendenze indirette o modelli AI incorporati, le organizzazioni devono sapere cosa c'è dentro il proprio software.» — OSSRA 2026
Le linee guida OWASP sulla catena di fornitura dei sistemi LLM arrivano alla stessa conclusione e la mettono come prima contromisura: mantenere un inventario aggiornato dei componenti. Tra i rischi che elencano, tre riguardano direttamente chi usa l'AI tramite servizi di terzi: modelli obsoleti o non più manutenuti, provenienza debole di un modello scaricato, condizioni d'uso e privacy poco chiare su dove finiscono i dati che gli passi.
Cosa scrivere nell'inventario delle dipendenze: sette colonne
L'inventario utile sta in un foglio di calcolo, non in un documento di quaranta pagine. Per ogni dipendenza servono sette informazioni:
- Che cos'è — nome del servizio o della libreria, e la versione esatta su cui girate oggi.
- A cosa serve — quale passaggio dell'automazione si ferma se sparisce. Una frase.
- Di chi è l'account — intestato all'azienda o alla persona che l'ha configurato. È la domanda che smaschera più rischi in assoluto.
- Quale credenziale usa e dove sta — tipo di chiave e dove è custodita, mai il valore della chiave.
- Quando scade — token, certificato, contratto, fine del supporto della versione.
- Chi riceve gli avvisi — l'indirizzo a cui il fornitore manda le comunicazioni di dismissione. Deve essere una casella condivisa.
- Che si fa se cade — l'automazione si ferma, degrada o passa a un'alternativa. Decidetelo prima.
Due righe compilate così valgono più di un contratto di assistenza generico. Infatti il valore non è l'elenco: è che compilarlo costringe a rispondere a domande che altrimenti nessuno si pone. Chi è intestatario della chiave? Dove va l'email di dismissione? Quante delle nostre automazioni usano quel singolo token? Tenere l'inventario vivo è parte del costo di manutenzione che va messo a preventivo, non un extra da fare quando c'è tempo.
Un documento che sta diventando un obbligo
La direzione normativa europea è già tracciata. Il Cyber Resilience Act, in vigore dal 10 dicembre 2024, impone a chi immette sul mercato europeo prodotti con elementi digitali di gestire le vulnerabilità per tutto il ciclo di vita del prodotto. Gli obblighi di segnalazione sono operativi dall'11 settembre 2026 e il corpo principale delle regole si applica dall'11 dicembre 2027.
Attenzione a non leggerlo come un adempimento che riguarda tutti: il regolamento parla ai fabbricanti e ai distributori di prodotti digitali, non all'azienda che usa un'automazione interna. Tuttavia la logica che impone — sapere di cosa è fatto ciò che metti in produzione e per quanto tempo lo sostieni — è esattamente quella che conviene adottare anche quando nessuna legge te la chiede. Se poi un domani rivendi o distribuisci quello strumento, l'inventario esiste già.
Da dove si comincia
Non serve un progetto. Si prende l'automazione più importante che avete e si elencano tutte le chiamate verso l'esterno che fa in una giornata: quelle sono le dipendenze, e quella lista è già il primo abbozzo dell'inventario delle dipendenze. Per ciascuna si compilano le sette colonne, e le celle che restano vuote diventano la lista delle cose da sistemare — di solito un account personale da intestare all'azienda e un indirizzo di avvisi da correggere. È un'ora di lavoro per automazione.
Noi lo facciamo per ogni agente che costruiamo, insieme al controllo delle versioni dei modelli su cui gira, perché un'automazione consegnata senza il suo inventario delle dipendenze è un'automazione che il cliente non può mantenere da solo. Se stai valutando un fornitore per un progetto di automazione, chiedigli di consegnarti quel foglio insieme al codice: la risposta ti dice molto più di una demo. Studiollice progetta agenti e automazioni su misura, inventario compreso.