TL; DR
Ormai tutti i consigli di amministrazione chiedono informazioni sui rischi legati all'IA, e la maggior parte dei team di sicurezza risponde con aggettivi anziché con numeri. I framework di governance ti dicono cosa governare, non cosa misurare. Tutte queste metriche di rischio dell'IA provengono dalla stessa fonte: il codice che la tua organizzazione già distribuisce.
- Una strategia di intelligenza artificiale agentiva si articola su tre livelli, e solo uno di questi è il modello. Ciò che l'agente scrive, a cosa è collegato e cosa riceve. La maggior parte dei programmi misura il primo aspetto e ignora gli altri due.
- Il raggio d'esplosione non è presente nel modello. È presente nel file delle competenze, nella configurazione MCP, nell'ambito dello strumento e nelle credenziali con cui viene eseguito l'agente. Una valutazione del modello pulita e un agente con privilegi eccessivi coesistono senza problemi.
- Nove metriche di rischio per l'IA, ciascuna espressa con un numero anziché con un aggettivo. Risorse IA non approvate, percorsi di iniezione rapida che raggiungono un sink di strumenti, segreti in
.mcp/servers.json, dipendenze aggiunte dall'agente segnalate prima che esistesse una firma. - Se non riuscite a raggiungere l'obiettivo in questo trimestre, il problema non è la metrica. L'inventario è. Inizia con tre conteggi, non con un programma.
Che cosa significa concretamente il rischio legato all'IA quando sei tu a distribuire il software?
Chiedete a dieci persone cosa significhi il rischio legato all'IA e otterrete dieci risposte. Pregiudizi del modello. Allucinazioni. Fuga di dati. Esposizione a problemi normativi. Perdita di posti di lavoro. Tutti rischi reali, tutti meritevoli di attenzione, ma nessuno dei quali può essere risolto da un team di sicurezza un martedì pomeriggio.
Esiste una versione più circoscritta della domanda, di cui un team di sicurezza può effettivamente occuparsi: Quale intelligenza artificiale è in esecuzione all'interno del software che sviluppiamo, cosa può raggiungere e cosa succede quando qualcuno la manipola. Quella versione ha una risposta, e la risposta si trova nei tuoi repository e pipelinepiuttosto che in un documento programmatico.
Questa è la versione del rischio IA di cui parla questo post. Non perché le questioni di governance non siano importanti, ma perché non si può rispondere alle questioni di governance finché non si risponde a questa. Un framework ti chiede di inventariare i tuoi sistemi IA. Non ti dice che l'inventario si trova in un .mcp/servers.json file che nessuno ha aperto da quando è stato committed.
Perché la maggior parte dei programmi di valutazione del rischio legati all'IA misurano l'aspetto sbagliato?
Esistono tre modelli di errore, e la maggior parte delle organizzazioni ne presenta almeno due.
- Misurare l'adozione anziché l'esposizione. "Il 72% dei nostri sviluppatori utilizza strumenti di intelligenza artificiale" è un indicatore di produttività mascherato da badge di sicurezza. Non dice nulla su ciò che questi strumenti sono effettivamente in grado di raggiungere.
- Misurare il modello anziché il sistema. L'analisi di un endpoint tramite un team di esperti (red teaming) risponde alla domanda se un modello può essere indotto a dire qualcosa che non dovrebbe. Non risponde però alla domanda su cosa accada in seguito, perché il raggio d'azione dell'attacco risiede nell'ambito dello strumento, nelle credenziali con cui viene eseguito l'agente e nei file di configurazione che definiscono entrambi. Una valutazione del modello impeccabile e un agente con privilegi eccessivi possono coesistere senza problemi.
- Misurare ciò che è facile da contare. Numero di politiche sull'IA pubblicate. Numero di dipendenti che hanno completato la formazione sull'IA. Questi numeri aumentano costantemente e non sono correlati a nulla.
Migliori Quadro di gestione del rischio AI del NIST è esplicito che la misurazione è una delle sue quattro funzioni principali, insieme a governare, mappare e gestire. Il framework è deliberatamente basato sui risultati piuttosto che prescrittivo, il che è corretto per un standard e inutile di martedì. Devi ancora decidere cosa contare.
Quali metriche di rischio relative all'IA sono effettivamente utili?
Nove parametri. Ognuno è un numero, ognuno cambia al variare dell'esposizione e ognuno può essere generato tramite codice anziché tramite un sondaggio.
| Metrico | Perché è importante | Da dove proviene il numero |
|---|---|---|
| 01Numero totale di risorse IA scoperte e variazione rispetto al mese scorso. | Non è possibile redigere un rapporto sui rischi dell'IA che non sono mai stati quantificati. La tendenza è più importante del numero assoluto. | Scoperta continua di modelli, framework, set di dati, endpoint di inferenza, agenti, server MCP, competenze e strumenti di programmazione AI |
| 02Risorse di IA non approvate in percentuale sul totale | Questo è il tuo tasso di IA ombra. È l'indicatore di rischio IA più citabile per un consiglio di amministrazione. | Stato di approvazione monitorato per ogni risorsa in base alla tua policy |
| 03Risorse di intelligenza artificiale senza proprietario specificato | Un bene che nessuno possiede è un bene che nessuno riparerà. Di solito il numero più brutto dell'insieme | La proprietà è tracciata rispetto all'asset |
| 04Percorsi di iniezione rapidi che raggiungono un lavandino utensile | L'input non attendibile che raggiunge un prompt di sistema è rilevante solo se dall'altra parte si trova qualcosa di pericoloso. | Rilevamento del rischio AI mappato su OWASP Top 10 per le domande di LLM |
| 05Server MCP in uso e quanti di essi riportano i risultati | La configurazione MCP è il punto in cui l'agente riceve i suoi ordini. È anche il punto in cui si accumulano le credenziali. | La configurazione del server MCP analizzata come artefatto di sicurezza. |
| 06Segreti nascosti nei file di configurazione dell'IA | Una ricerca del 2026 ha rilevato oltre 24,000 segreti nei file di configurazione di MCP su GitHub pubblico, di cui più di 2,000 ancora validi. | Rilevamento dei segreti attraverso codice, configurazioni, contenitori e pipelines |
| 07Dipendenze aggiunte dall'agente segnalate prima che esistesse una firma pubblica | Gli agenti scaricano i pacchetti velocemente e il nome inventato dal tuo modello rappresenta una superficie di attacco sfruttabile. | Avviso tempestivo di malwareindividuazione delle prove seguita da convalida tramite intelligenza artificiale |
| 08Quota di risultati dell'IA accessibili e presenti nel codice attivamente sviluppato | Separa il lavoro arretrato che non riuscirai mai a smaltire dal lavoro che modifica la tua esposizione | L'imbuto di prioritizzazione dell'IA |
| 09Percentuale di autori agenti pull requests unito con un'approvazione umana | La metrica di governance che un ente regolatore richiederà, e quella che nessuno monitora | Pull request . e porte di approvazione |
Se dovete sceglierne solo una, scegliete la metrica 02. Il rapporto tra risorse IA non approvate e risorse IA totali è il numero che sopravvive alla traduzione da un team di sicurezza a un audit. commite si muove quando effettivamente fai qualcosa.
Quali aspetti deve includere una strategia di intelligenza artificiale agentiva?
Tre strati. L'errore che quasi tutti commettono è quello di iniziare dal primo e fermarsi lì.
- Primo livello: ciò che scrive l'agente. Il codice generato presenta le stesse classi di vulnerabilità del codice scritto da esseri umani, e le ricerche condotte a partire dal 2022 hanno costantemente rilevato che una quota sostanziale di programmi generati dall'IA contiene falle di sicurezza. Questo livello è il più conosciuto, ed è proprio per questo che attira tutta l'attenzione.
- Secondo livello: a cosa è collegato l'agente. File delle competenze, file delle regole, configurazioni del server MCP, ambiti degli strumenti, le credenziali con cui viene eseguito l'agente. Questo è il livello che determina quanto lontano si propaga un attacco riuscito ed è invisibile a qualsiasi cosa testi il modello attraverso il suo endpoint. ATLANTE MITRE cataloga direttamente questo terreno: il caso di studio Rules File Backdoor, AML.CS0041, descrive i caratteri a larghezza zero in un file di regole che trasformano la documentazione in istruzioni che un agente obbedisce silenziosamente. Un revisore che legge il pull request non vede nulla.
- Terzo livello: ciò che l'agente raccoglie. Dipendenze, modelli, set di dati, strumenti esterni. Una ricerca presentata all'USENIX Security nel 2025 ha generato 2.23 milioni di campioni di codice su 16 modelli e ha scoperto che il 19.7% dei pacchetti consigliati non esisteva, producendo oltre 205,000 nomi fittizi unici. Gli aggressori non hanno più bisogno di compromettere un manutentore. Registrano il nome inventato dal tuo agente e aspettano.
Una strategia di IA agentiva che copre solo il primo livello produce un report pulito e un profilo di rischio IA invariato. OWASP Top 10 per le domande di LLM riflette ciò nella propria struttura: l'eccessiva agenzia si trova in cima alla lista precisSemplicemente perché si tratta di un problema di cablaggio, non di un problema di modello.
Come si implementa questa soluzione senza rallentare gli agenti?
L'istinto è quello di bloccare tutto. Fallisce perché lo scopo principale dell'agente è la produttività, e un controllo che dimezza la produttività viene rimosso entro un trimestre.
Tre principi di implementazione che si confermano validi:
- Misurare in modo continuo, filtrare in modo selettivo. Tutte e nove le metriche di rischio dell'IA possono essere raccolte a ogni scansione senza bloccare nulla. Riservate i controlli rigidi al piccolo insieme di casi in cui l'errore è irreversibile: una dipendenza dannosa, un segreto attivo, un modello non approvato che gestisce dati regolamentati.
- Posiziona la sicurezza dove l'agente è già presente. Un agente connesso tramite MCP chiama la piattaforma di sicurezza mentre genera il codice, lo analizza e applica le correzioni necessarie finché non soddisfa le soglie impostate. In questa fase non è previsto alcun intervento umano e non è necessario installare nulla nell'ambiente di esecuzione dell'agente. Questo è l'unico punto di intervento che scala in base alla produttività dell'agente, anziché in modo inefficiente.
- Mantenere l'umano al pull request. Per qualsiasi elemento che raggiunga la fase di produzione, è necessaria l'approvazione di una persona. Non si tratta di cautela, bensì dell'approccio progettuale che la legge europea sull'IA impone, ed è molto più economico integrarlo fin da subito piuttosto che doverlo adattare in seguito sotto la pressione di un audit. Inoltre, corrisponde al parametro 09, motivo per cui vale la pena monitorarlo fin dal primo giorno.
La riga che nella maggior parte delle organizzazioni non viene assegnata è la seconda. I file di configurazione si trovano a metà strada tra la sicurezza delle applicazioni, che li considera parte dell'infrastruttura, e l'ingegneria della piattaforma, che li considera documentazione. È proprio in questo spazio vuoto che si annidano gli attacchi più interessanti.
Come si inizia a misurare il rischio legato all'IA in questo trimestre?
Non sviluppate il programma completo. Fornite tre cifre. Contate le vostre risorse di intelligenza artificiale. Contate quante di queste non sono state approvate da nessuno. Contate quanti segreti sono nascosti nei file di configurazione dell'IA. Queste tre informazioni stanno in una sola diapositiva; sono tutte difendibili e saranno peggiori di quanto si aspetti chi le ha richieste.
Quindi, individuate quello che presenta i problemi peggiori e risolveteli prima della prossima riunione del consiglio di amministrazione. Questo è un programma di gestione del rischio legato all'IA che funziona. Tutto il resto è superfluo.
Le organizzazioni che avranno difficoltà a gestire i rischi legati all'IA nel 2027 non saranno quelle che si sono mosse in fretta, bensì quelle che hanno trascorso il 2026 a redigere politiche sull'IA senza mai misurare i risultati. Una politica che non può essere misurata è solo un documento. Sono le metriche di rischio dell'IA a trasformarla in un controllo efficace.
Controlla i tuoi numeri. Collega un repository e Xygeni ti restituirà l'inventario dell'IA, le risorse non approvate, i rischi mappati ai framework utilizzati dai tuoi revisori e una distinta base dell'IA che puoi esportare. Inizia gratis or prenota una demo.
FAQ
Qual è la differenza tra rischio e sicurezza dell'IA?
La sicurezza dell'IA riguarda principalmente ciò che un modello fa: se si comporta come previsto, se i suoi output sono dannosi, se può essere manipolato per indurlo a fare qualcosa che dovrebbe rifiutare. Il rischio dell'IA, in un contesto di sicurezza, riguarda ciò che un sistema di IA compromesso o malfunzionante può raggiungere all'interno del tuo ambiente. I due aspetti si sovrappongono, ma sono gestiti da team diversi e misurati con strumenti diversi. Un team di sicurezza può intervenire sul secondo aspetto già da oggi.
Quanti indicatori di rischio relativi all'IA dovremmo segnalare al consiglio di amministrazione?
Da tre a cinque. Un consiglio di amministrazione non può basarsi su nove numeri, e un mazzo con nove elementi tende a nascondere quello che conta davvero. Riporta il numero totale di risorse AI, la percentuale di quelle non approvate e un indicatore di esposizione, come ad esempio i risultati AI raggiungibili in fase di sviluppo attivo. Conserva il resto per la revisione operativa.
Abbiamo bisogno di una distinta base basata sull'intelligenza artificiale (AI-BOM) se al momento non esiste una normativa che la preveda?
Al momento non esiste alcuna normativa che imponga l'utilizzo di una distinta base automatizzata (AI-BOM), ed è proprio per questo che generarla è economica ora ma costosa in futuro. Esistono due formati leggibili automaticamente e un revisore dei conti accetterà entrambi. Il vantaggio non risiede nella conformità normativa, bensì nel fatto che la creazione del file obbliga a tenere traccia dell'inventario, e l'inventario è l'elemento fondamentale su cui si basano tutte le metriche di rischio dell'intelligenza artificiale.
I nostri sviluppatori utilizzano strumenti di intelligenza artificiale che non abbiamo mai approvato. Da dove cominciamo?
Conta prima di imporre delle regole. Annunciare una politica contro strumenti che non puoi vedere spinge l'utilizzo nella clandestinità e distrugge la visibilità di cui hai bisogno. Prima di tutto, fai un'analisi, pubblica il numero internamente senza attribuirlo e usalo per concordare un elenco di strumenti approvati che rispecchi le reali esigenze degli utenti. L'applicazione delle norme è molto più efficace quando segue le prove piuttosto che quando le precede.
