AI-SPM: cos'è l'AI security posture management

La risposta breve: l'AI security posture management (AI-SPM) è l'insieme di strumenti e pratiche che trova i modelli, i servizi e gli agenti AI presenti nei tuoi account cloud, ne controlla configurazioni, permessi ed esposizione, e ti dice quali combinazioni di rischio un attaccante potrebbe usare. È la stessa logica di CSPM e DSPM, applicata ai carichi di intelligenza artificiale.

Qui trovi cosa controlla un'AI-SPM, in cosa si distingue dagli strumenti che probabilmente hai già, cosa offrono Google Cloud e Microsoft in modo nativo e che legame c'è con l'AI Act. Il quadro più ampio, in cui l'AI-SPM è uno dei componenti, è nella nostra guida su CNAPP, cos'è e quali componenti ha.

Cos'è l'AI-SPM, in pratica

Wiz, nella sua Academy (articolo del 7 maggio 2026), definisce l'AI-SPM come la disciplina che scopre, monitora e corregge i rischi propri di modelli, pipeline, dataset e servizi AI che girano negli ambienti cloud. Gli esempi che fa sono concreti: pesi dei modelli esposti, dati di addestramento manipolati, account di servizio AI con troppi permessi, API configurate male che permettono a chiunque di interrogare un modello in produzione. Wiz rivendica di aver introdotto il termine, e oggi lo fa rientrare in un'offerta più ampia che chiama AI-APP.

Google, nella documentazione di Security Command Center, descrive la sua funzione equivalente, AI Protection, come uno strumento per gestire la postura di sicurezza dei carichi AI: una vista della sicurezza dell'AI sull'intero ambiente Google Cloud, con il rilevamento delle minacce e dei rischi sull'inventario AI.

Perché serve: l'AI cresce più in fretta dell'inventario

Nel cloud un servizio AI si attiva in pochi minuti, spesso da un team di sviluppo o di data science, con un account di servizio creato per l'occasione e collegato ai dati che servono al modello. Il risultato è un insieme di risorse che la sicurezza non ha censito. È la versione infrastrutturale del fenomeno che abbiamo descritto in shadow AI: cos'è e come gestirlo.

I numeri disponibili vengono da fonti di vendor, e vanno letti come ordine di grandezza:

• L'adozione è diffusa. Il rapporto State of AI in the Cloud 2026 di Wiz Research indica che l'81% delle organizzazioni usa servizi AI gestiti e il 90% esegue modelli in proprio. Il 68% di chi ha modelli in proprio li riceve dentro software di terze parti, quindi la sicurezza può ereditarli senza che nessuno li abbia messi in esercizio in modo esplicito.
• Gli agenti allargano la superficie. Lo stesso rapporto riporta che il 57% delle organizzazioni ha messo in esercizio agenti AI in proprio e l'80% usa server MCP (Model Context Protocol), componenti che spesso hanno più permessi del necessario.
• La visibilità manca. Nel sondaggio AI Security Readiness di Wiz e Gatepoint Research su 100 professionisti cloud e security, il 25% dichiara di non sapere quali servizi AI girano nel proprio ambiente, e solo il 13% ha adottato strumenti di postura specifici per l'AI.

Un caso documentato mostra come nasce il problema. Nel settembre 2023 Wiz Research ha reso pubblico un caso che aveva trovato e segnalato a Microsoft a giugno. Un team di ricerca AI di Microsoft, pubblicando dati di addestramento su GitHub, aveva condiviso per errore un intero storage account Azure con un token SAS configurato male: 38 terabyte di dati in più, fra cui chiavi, password e oltre 30.000 messaggi Teams interni. Il token dava il controllo completo, quindi permetteva anche di modificare i file dei modelli. Microsoft ha revocato il token due giorni dopo la segnalazione. Nessun attacco sofisticato: un permesso troppo largo su una risorsa legata all'AI.

Cosa controlla un'AI-SPM

1. Inventario e AI-BOM

Il primo lavoro è trovare tutto: servizi gestiti come Amazon Bedrock, Azure OpenAI Service e Google Vertex AI, modelli installati in proprio su macchine virtuali o container, librerie e SDK di AI nel codice, agenti e gli strumenti che possono chiamare. Il risultato si chiama AI-BOM (AI bill of materials), l'elenco dei componenti di ogni sistema AI: modelli, framework, dipendenze, dati collegati. Un foglio di calcolo invecchia al primo rilascio: la scoperta deve essere continua.

2. Configurazioni ed endpoint esposti

Su ogni risorsa trovata lo strumento applica regole: endpoint di inferenza raggiungibili da internet, autenticazione debole o assente, modelli messi in esercizio senza isolamento, chiavi API in chiaro. Microsoft, nella documentazione di Defender for Cloud, indica per gli endpoint AI raggiungibili da internet di dare priorità alle raccomandazioni che rafforzano l'autenticazione e riducono al minimo i permessi delle identità.

3. Dati e permessi

Un modello vale quanto i dati a cui arriva. L'AI-SPM verifica quali dataset di addestramento, quali basi documentali e quali database sono raggiungibili da un servizio AI o da un agente, e con quali permessi. Qui si incrocia con la DSPM, che classifica i dati sensibili (ne parliamo in DSPM, data security posture management nel cloud), e con la gestione delle identità cloud: un account di servizio AI va trattato come un utente ad alto rischio, con accesso solo ai dataset che gli servono.

4. Percorsi d'attacco

Il valore sta nella correlazione. Un'API configurata male su un modello di test in un ambiente isolato pesa poco; la stessa API su un modello in produzione, esposto su internet e con accesso ai dati dei clienti, è una priorità. Wiz descrive questo lavoro come la costruzione di percorsi d'attacco che mostrano come una compromissione possa passare da un'API esposta a un archivio di dati di addestramento sensibili.

5. Runtime, come estensione

La postura dice cosa potrebbe succedere; accorgersi di quello che succede (prompt injection, agenti dal comportamento anomalo) è rilevamento a runtime, che diverse piattaforme affiancano all'AI-SPM. E quei segnali vanno guardati da qualcuno, come ogni altro allarme.

AI-SPM, CSPM e DSPM: chi fa cosa

• CSPM: controlla le configurazioni dell'infrastruttura cloud, per esempio una regola di rete troppo aperta o un bucket pubblico.
• DSPM: guarda il contenuto, cioè dove stanno i dati sensibili, chi li raggiunge e quanto sono esposti.
• AI-SPM: estende entrambe al livello dell'AI, con inventario di modelli e agenti, regole specifiche per i servizi AI e percorsi d'attacco che attraversano infrastruttura, identità e dati.

Non sono in alternativa: un carico AI tocca insieme infrastruttura e dati sensibili.

Cosa offrono già i cloud provider

• Google Cloud, AI Protection in Security Command Center. Secondo la documentazione aggiornata al 14 ottobre 2026, fa l'inventario degli asset AI, individua vulnerabilità note e segreti in chiaro nei carichi agentici, simula i percorsi d'attacco trattando agenti e server MCP come risorse di alto valore, segnala gli agenti con permessi eccessivi e applica framework di compliance per l'AI. Le capacità disponibili dipendono dal livello di servizio di Security Command Center.
• Microsoft Defender for Cloud. Il piano Defender CSPM, secondo la documentazione aggiornata al 17 giugno 2026, scopre in continuo i carichi AI su Azure OpenAI Service, Azure AI Foundry, Azure Machine Learning, Amazon Bedrock e Google Vertex AI, ricostruisce l'AI-BOM, emette raccomandazioni su identità, dati ed esposizione e usa l'analisi dei percorsi d'attacco anche quando dati e calcolo stanno su cloud diversi.

La funzione nativa del provider è un buon punto di partenza. Quando modelli in proprio e agenti si collegano a molte fonti, conta che inventario, permessi, dati e configurazioni stiano nella stessa vista.

È la direzione presa da Wiz, che dall'11 marzo 2026 fa parte di Google Cloud: nel post sulla chiusura dell'acquisizione Google scrive che nell'ultimo anno Wiz ha aggiunto visibilità su applicazioni e uso dell'AI, prevenzione dei rischi propri dell'AI e rilevamento a runtime sui carichi AI (blog Google Cloud, 11/03/2026).

AI-SPM e AI Act: dove si incontrano

L'AI Act non chiede uno strumento con questo nome. Chiede però cose che senza un inventario dei sistemi AI e della loro postura sono difficili da dimostrare.

Sapere che sistemi hai, e in che ruolo

Gli obblighi del regolamento (UE) 2024/1689 cambiano a seconda che l'azienda sia fornitore o deployer di un sistema, e a seconda del livello di rischio. Prima di stabilirlo serve l'elenco dei sistemi AI in uso, compresi quelli attivati dai team senza passare dalla sicurezza. I ruoli sono spiegati in AI Act: fornitore, deployer e gli altri ruoli.

Cibersicurezza dei sistemi ad alto rischio

L'articolo 15, paragrafo 5, stabilisce che i sistemi di IA ad alto rischio «sono resilienti ai tentativi di terzi non autorizzati di modificarne l'uso, gli output o le prestazioni sfruttando le vulnerabilità del sistema». Lo stesso paragrafo elenca, ove opportuno, misure contro l'avvelenamento dei dati di addestramento, l'avvelenamento dei modelli, gli esempi antagonistici, gli attacchi alla riservatezza e i difetti del modello. È un obbligo di progettazione che ricade sul fornitore, ma molte delle evidenze (chi può modificare i dataset, se l'endpoint è esposto, quali permessi ha il servizio) sono esattamente quelle che produce un'AI-SPM.

Sui tempi: dopo il regolamento (UE) 2026/1744, l'articolo 113 del testo consolidato fa applicare queste regole dal 2 dicembre 2027 per i sistemi ad alto rischio dell'allegato III e dal 2 agosto 2028 per quelli dell'allegato I. Il calendario completo è in AI Act: entrata in vigore e scadenze dopo l'Omnibus.

Obblighi del deployer

Secondo l'articolo 26, chi usa un sistema ad alto rischio lo usa conformemente alle istruzioni, ne monitora il funzionamento e conserva i log generati automaticamente, se sono sotto il suo controllo, per almeno sei mesi salvo diversa disposizione. Per farlo deve sapere dove gira il sistema, con quali identità e quali dati.

NIS2 e ISO/IEC 42001

Per chi è soggetto alla NIS2, l'articolo 24, comma 2, lettera i, del D.Lgs. 138/2024 include tra le misure minime le «politiche di controllo dell'accesso e gestione dei beni e degli assetti»: i servizi AI nel cloud sono beni come gli altri, e vanno censiti. Chi costruisce un sistema di gestione dell'AI trova il quadro organizzativo in ISO/IEC 42001, cos'è.

Come partire, in cinque passi

1. Fai l'inventario. Servizi AI gestiti, modelli in proprio, agenti, server MCP, librerie AI nel codice, su tutti gli account cloud compresi sviluppo e test.
2. Chiudi l'esposizione. Parti dagli endpoint di inferenza e dalle API raggiungibili da internet senza autenticazione forte.
3. Riduci i permessi. Ogni account di servizio AI e ogni agente deve arrivare solo ai dataset e agli strumenti che gli servono, senza accesso permanente ai dati di produzione per i modelli di sviluppo.
4. Collega i dati. Incrocia l'inventario AI con la classificazione dei dati sensibili: un modello che legge dati personali entra in cima alla lista.
5. Porta i controlli nella pipeline. Le regole sulle configurazioni AI vanno applicate quando si costruisce e si rilascia, non solo nella revisione periodica.

In sintesi

In sintesi: l'AI-SPM trova i modelli, i servizi e gli agenti AI nel cloud, ne controlla configurazioni, permessi ed esposizione e li mette in relazione con i dati sensibili, così che emergano le poche combinazioni che portano davvero a un incidente. Non è un obbligo di legge con questo nome, ma produce le evidenze che AI Act e NIS2 chiedono su sistemi, accessi e beni. Gli strumenti nativi di Google e Microsoft sono un buon inizio; quando modelli, agenti e dati si moltiplicano, serve che stiano nella stessa vista.

AmagisTech è partner Wiz, una piattaforma che si collega ai cloud via API, senza agenti, e tiene AI, dati, permessi e configurazioni nello stesso grafo. Se vuoi partire da cosa è esposto oggi nei tuoi account e con quali permessi, il primo passo è la fotografia del cloud con Wiz.