Cloud governance e cyber: ecco i 5 pilastri di un framework per l’AI generativa aziendale

L’Intelligenza Artificiale Generativa è uscita dalla fase dell’esperimento
individuale. Oggi entra nei processi aziendali, nei workflow documentali, nei
sistemi di customer care, nelle piattaforme di sviluppo software, nei motori di
knowledge management, nei SOC, nei sistemi di analytics, nei servizi interni
di produttività e, sempre più spesso, negli ambienti cloud in cui l’impresa ha
già spostato dati, identità, applicazioni e capacità elaborativa.

Ecco una guida pratica e strategica di Cloud governance per l’AI generativa aziendale per CISO, cloud architect e responsabili compliance.

Cloud governance per l’AI generativa aziendale

Per un CISO, questa transizione cambia radicalmente il perimetro del rischio.
La GenAI non è soltanto un nuovo applicativo SaaS da classificare nel registro dei fornitori né un modello statistico da affidare al solo data science team.

È un carico di lavoro distribuito, data intensive, spesso multi-cloud, esposto via API, alimentato da basi documentali aziendali, integrato con sistemi interni e capace di produrre output che possono incidere su decisioni operative, reputazione, conformità normativa e proprietà intellettuale.

La domanda non è più se l’azienda userà l’IA generativa. La domanda è chi la governa, con quali policy, su quali cloud, con quale tracciabilità, con quale segregazione dei dati, con quale modello di responsabilità e con quali controlli di sicurezza runtime.

L’articolo “A Framework for Governing Generative AI Workloads in Cloud Environments”, pubblicato su IEEE Computer nell’aprile 2026 da Goutham
Bandapati, Srinivasa R. Atta e Ananya Ghosh Chowdhury, propone un framework cloud-agnostic articolato su cinque pilastri: ottimizzazione dei costi, sicurezza dei workload AI, resilienza delle piattaforme, efficienza operativa e governance dei modelli [1].

La caratura autoriale qui è fortemente “industry-research driven”: Bandapati, Atta e Ghosh Chowdhury operano in ruoli senior tra Microsoft e Google su cloud architecture, AI, modernizzazione enterprise, resilienza e sicurezza Zero Trust, con solide basi accademiche in computer science, IT, business analytics e project management; la loro autorevolezza nel panorama IEEE è rafforzata dallo status di Senior Member IEEE – per Bandapati anche con appartenenza a IEEE Computer Society, IEEE Reliability Society e IEEE Young Professionals che li colloca non solo come practitioner di alto profilo nei grandi cloud provider, ma come contributori qualificati al dibattito tecnico-scientifico internazionale su governance, affidabilità e sicurezza dell’AI in ambienti cloud.

Il concetto di fondo

Il valore del loro contributo non sta solo nell’elencazione dei pilastri, ma nell’idea di fondo: la GenAI in cloud va governata lungo l’intero ciclo di vita, non controllata a valle quando il modello è già in produzione.

Per i CISO questo significa spostare il tema dalla “policy sull’uso di ChatGPT” a una veraarchitettura di governance: identità, dati, modelli, prompt, API, logging, reti, region cloud, vector database, RAG pipeline, fornitori, contratti, audit trail, monitoraggio, incident response e compliance devono diventare parti di un unico sistema di controllo.

Dal cloud governance tradizionale alla GenAI governance

La cloud governance tradizionale nasce per rispondere a esigenze ormai consolidate: controllo dei costi, gestione delle identità, segmentazione, cifratura, logging, backup, compliance, segregazione degli ambienti, hardening delle configurazioni, gestione delle vulnerabilità e responsabilità condivisa con il cloud service provider.

Le 5 dimensioni dell’AI generativa: la prima

La GenAI aggiunge almeno cinque nuove dimensioni. La prima è l’output probabilistico.

Un’applicazione tradizionale restituisce un risultato deterministico o comunque riconducibile a una logica applicativa verificabile.

Un LLM genera testo, codice, immagini o dati secondo pattern probabilistici. Questo introduce il rischio di allucinazioni, risposte plausibili ma errate, citazioni inesistenti, interpretazioni non autorizzate o output non coerenti con policy aziendali.

Seconda dimensione: permeabilità tra dato e istruzione

La seconda è la permeabilità tra dato e istruzione.

Nei sistemi classici siamo abituati a distinguere input, comandi, codice, configurazione e dati.

Questa distinzione diventa meno netta nei LLM: il prompt è al tempo stesso dato, istruzione, contesto e possibile vettore di attacco.

Da qui derivano prompt injection, jailbreak, indirect prompt injection e agent hijacking.

Supply chain: la terza dimensione

La terza è la nuova catena di fornitura.

Un workload GenAI può includere modelli foundation, modelli open source, adapter, plugin, embedding model, vector database, dataset di training o fine-tuning, documenti interni, API gateway, sistemi di content moderation, strumenti di evaluation, orchestratori, agenti e connettori verso sistemi aziendali.

Ogni componente introduce dipendenze e rischi.

Quarta dimensione: l’osservabilità semantica

La quarta è la necessità di osservabilità semantica.

Non basta sapere che l’API ha risposto con HTTP 200, che la latenza è accettabile e che il costo per token è sotto budget.

Serve invece sapere se la risposta è fondata sulle fonti corrette, se contiene dati personali, se viola una policy, se mostra segnali di prompt injection, se ha usato il documento corretto, se il retrieval è stato coerente e se l’output è tracciabile.

Convergenza normativa: la quinta dimensione

La quinta è la convergenza normativa. AI Act, GDPR, NIS2, obblighi settoriali, policy di sicurezza, contratti cloud, requisiti di audit e principi di AI responsabile tendono a sovrapporsi.

Per questo la governance della GenAI non può essere una policy isolata: deve integrarsi con il sistema aziendale di gestione della sicurezza, della privacy, del rischio operativo e della compliance.

Il principio guida: nessun workload GenAI senza control plane

La prima scelta architetturale per un CISO è creare un control plane della GenAI.

Non necessariamente un prodotto unico, ma un insieme coerente di processi, policy e controlli tecnici che consenta di rispondere a domande essenziali: quali modelli sono autorizzati? E quali dati possono essere trattati? In quali region cloud? Con quali log? Ma con quale retention? Chi può invocare il modello? Quali applicazioni possono usare agenti? Inoltre, quali output richiedono revisione umana? Quali eventi devono arrivare al SOC?

Gli elementi del control plane

Questo control plane dovrebbe poggiare su alcuni elementi minimi.

Anzitutto un inventario dei casi d’uso GenAI, classificato per criticità, dati trattati, utenti, processi impattati, cloud provider, modello utilizzato e livello di automazione.

Un chatbot interno che risponde su procedure HR non ha lo stesso profilo di rischio di un assistente che genera codice, interroga dati di clienti, produce bozze contrattuali o supporta decisioni in ambito sanitario, finanziario, industriale o infrastrutturale.

I modelli autorizzati

Serve poi un catalogo dei modelli autorizzati. Il catalogo dovrebbe distinguere tra modelli SaaS pubblici, modelli commerciali in ambiente enterprise, modelli open source deployati su cloud privato o pubblico, modelli fine-tuned, modelli usati per embedding, modelli per classificazione e filtri di sicurezza.

Ogni modello dovrebbe avere una scheda: owner, finalità, dati ammessi, restrizioni, vendor, region, modalità di logging, policy di training, retention dei prompt, test di sicurezza, valutazioni di accuratezza, data lineage e stato di approvazione.

La matrice dati-modelli

Terzo elemento: una matrice dati-modelli. I dati pubblici, interni, confidenziali, segreti, personali, particolari o regolamentati non possono essere trattati con la stessa libertà.

Il principio di minimizzazione va tradotto in routing tecnico: alcuni dati potranno essere usati solo con modelli enterprise che garantiscono isolamento, no-training sui dati del cliente, logging controllato, cifratura, retention definita e localizzazione compatibile.

Altri dati dovranno essere esclusi o anonimizzati prima dell’invio.

Policy-as-code

Quarto elemento: policy-as-code. Le regole non devono vivere solo in un documento approvato dal board. Devono diventare controlli tecnici nei gateway, nelle pipeline CI/CD, nei motori di policy cloud, negli strumenti di data loss prevention, nei sistemi IAM, nei controlli di egress, nei repository e nei workflow di deployment.

AI risk acceptance

Quinto elemento: AI risk acceptance. Ogni eccezione dovrebbe avere owner,
motivazione, durata, controlli compensativi e data di riesame.

Nella GenAI il rischio non è statico: cambiano modelli, prompt, knowledge base, plugin, capacità dei modelli, vulnerabilità note e aspettative regolatorie.

Il pilastro sicurezza: proteggere dati, modelli, prompt e output

Il framework IEEE colloca la sicurezza tra i cinque pilastri centrali della governance GenAI.

È corretto, ma per un CISO va fatto un passo ulteriore: la sicurezza non è un
pilastro tra gli altri, è il tessuto connettivo dell’intero modello.

I rischi tipici includono model inversion, data leakage, prompt injection, jailbreak exploit, poisoning attack, manipolazione degli output, abuso delle API, esposizione di chiavi, supply chain compromise e uso improprio di modelli non autorizzati [1].

L’OWASP Top 10 for Large Language Model Applications conferma questa impostazione, ponendo al centro prompt injection, insecure output handling, training data poisoning, model denial of service e supply chain vulnerabilities [7].

Workload GenAI come un’applicazione critica esposta a input non fidati

Da qui deriva una regola pratica: ogni workload GenAI deve essere disegnato come un’applicazione critica esposta a input non fidati, anche quando l’utente è interno. L’errore più comune è considerare il prompt come una semplice richiesta funzionale.

In realtà, il prompt è una superficie d’attacco.

Sul piano IAM, l’approccio dovrebbe essere zero trust. Accesso condizionale, MFA, identità gestite, service principal con privilegi minimi, segregazione tra ambienti, just-in-time access per attività amministrative e revisione periodica dei privilegi sono requisiti minimi.

Agentic AI

Gli agenti AI, quando possono invocare tool o API, devono avere identità proprie, privilegi limitati e capability esplicitamente autorizzate.

Un agente non dovrebbe ereditare in modo opaco tutti i privilegi dell’utente, perché questo amplifica il rischio di indirect prompt injection.

Sul piano delle reti, è necessario preferire endpoint privati, segregazione VNet/VPC, firewalling applicativo, egress control, API gateway, service mesh e policy di accesso per origine, destinazione, identità e workload.

I servizi GenAI non dovrebbero diventare scorciatoie per bypassare la segmentazione già definita per applicazioni e dati.

Sul piano della protezione dei segreti, chiavi API, token, credenziali di servizio e connection string devono essere custoditi in secret manager cloud-native o soluzioni equivalenti, con rotazione, auditing e divieto di embedding nei prompt, nei notebook, nei repository o nelle pipeline.

La compromissione di una chiave API verso un modello GenAI può generare non solo costi anomali, ma anche esfiltrazione di dati e abuso reputazionale.

Inoltre, sul piano dei dati, occorre implementareclassificazione, DLP, mascheramento, tokenizzazione o anonimizzazione dove appropriato.

Il principio deve essere netto: i dati non necessari non entrano nel prompt; i dati non autorizzati non entrano nel modello; i dati non tracciabili non entrano nella knowledge base; i dati non governati non entrano nel vector store.

Multi-cloud: più governance, non più cloud

Molte aziende sono già multi-cloud, spesso più per stratificazione storica che per scelta architetturale consapevole.

La GenAI accentua questo fenomeno: un provider può essere preferito per i servizi di foundation model, un altro per la produttività, un altro per il data lake, un altro ancora per analytics, container, GPU o servizi sovrani.

Il multi-cloud, in sé, può essere un vantaggio: riduce lock-in, consente di scegliere modelli e servizi migliori per singolo caso d’uso, aumenta resilienza e capacità negoziale.

Ma dal punto di vista cyber introduce frammentazione: IAM diversi, logging eterogeneo, policy non uniformi, region differenti, controlli DLP non omogenei, posture management disallineato, modelli di responsabilità condivisa differenti e contratti non sempre comparabili.

Cloud, serve un livello di governance comune

La risposta non può essere “vietare il multi-cloud”. Deve essere costruire un livello di governance comune. In pratica, serve un’architettura con standard minimi aziendali validi per tutti i cloud: naming convention, tagging, classificazione dati, baseline di logging, cifratura, private connectivity, vulnerability management, policy IAM, controllo dei secret, requisiti di audit, modello di incident response e regole per l’approvazione dei servizi AI.

L’AI gateway aziendale

Una soluzione efficace è introdurre un AI gateway aziendale. Il gateway non deve essere solo un reverse proxy tecnico, ma un punto di enforcement: autenticazione, autorizzazione, rate limiting, token budget, logging dei metadati, redazione dei dati sensibili, controllo dei modelli autorizzati, blocco dei prompt non conformi, content filtering, routing verso il modello appropriato, gestione delle quote e correlazione con SIEM/SOC.

In ambienti più maturi, il gateway può essere integrato con un policy engine centralizzato: per esempio, determinati utenti possono usare solo modelli approvati per dati interni; le richieste contenenti dati personali vengono instradate verso endpoint enterprise con retention limitata; i prompt che includono segreti vengono bloccati; gli output destinati a processi critici richiedono revisione umana; i casi d’uso ad alto rischio vengono loggati con maggiore granularità.

Il punto chiave è evitare che ogni team costruisca il proprio accesso diretto al modello.

Ogni integrazione point-to-point diventa una futura lacuna di governance.

RAG e grounding: meno allucinazioni senza nuovi data breach

Molte aziende considerano la Retrieval-Augmented Generation la risposta naturale al rischio di allucinazioni.

In effetti, la RAG consente al modello di generare risposte usando una base di conoscenza esterna, aggiornata e controllata, invece di affidarsi solo al training originario del modello [8].

Ma la RAG non è automaticamente sicura né automaticamente corretta. Una pipeline RAG enterprise dovrebbe essere trattata come una filiera documentale critica.

L’ingestion dei documenti deve essere autorizzata, versionata, classificata e tracciata. Ogni documento dovrebbe avere owner, livello di confidenzialità, data di validità, fonte, permessi e stato di approvazione. I chunk creati per l’indicizzazione devono mantenere lineage verso il documento originale.

Gli embedding devono essere protetti perché possono rivelare informazioni sensibili o consentire inferenze non desiderate.

Il vector database è spesso il punto cieco della GenAI governance. Si percepisce come componente tecnico, ma in realtà contiene una rappresentazione interrogabile della conoscenza aziendale.

Deve quindi essere cifrato, segregato, soggetto a controllo accessi, backup, logging, retention e cancellazione coerente con le policy documentali e privacy.

Permission-aware retrieval

Un altro requisito fondamentale è il permission-aware retrieval.

Se un utente non ha accesso a un documento nel sistema originario, non deve ottenerne il contenuto attraverso il chatbot.

La RAG non deve diventare un canale laterale per aggirare ACL, classificazioni o segregazioni organizzative. Il retrieval deve applicare i permessi dell’utente, del ruolo, del processo e del contesto.

Per ridurre le allucinazioni occorre combinare più controlli: system prompt robusti, fonti autorizzate, citazioni obbligatorie, soglie di confidenza, risposta “non lo so” quando il contesto non è sufficiente, valutazioni automatiche di groundedness, test periodici su domande note, monitoraggio dei feedback utenti e revisione umana nei casi ad alto impatto.

Ma attenzione: un output con citazioni non è necessariamente corretto. Anche la citazione può essere usata impropriamente dal modello.

Per questo la verifica deve includere coerenza tra risposta e fonte, non solo presenza di una fonte.

Prompt injection e jailbreak: progettare assumendo che il modello
possa essere manipolato

La prompt injection è il rischio simbolo della GenAI perché mette in crisi un presupposto storico dell’application security: la separazione tra istruzioni e dati. Nelle architetture LLM, contenuti esterni, email, pagine web, documenti o ticket possono contenere istruzioni malevole che l’agente interpreta come comandi.

Il problema è particolarmente grave quando il modello può usare tool, accedere a dati o compiere azioni.

Le linee guida britanniche sui prompt risk evidenziano tecniche come recursive instruction exploitation, jailbreak e manipolazione progressiva delle salvaguardie [9].

Il National Cyber Security Centre (NCSC) ha inoltre sottolineato che i bypass delle salvaguardie possono includere jailbreaking, agent hijacking e indirect prompt injection [10].

La mitigazione deve essere multilivello

Primo: input filtering e detection di pattern sospetti, sapendo però che nessun filtro è risolutivo. Secondo: separazione dei contesti.

Il modello deve distinguere istruzioni di sistema, istruzioni sviluppatore, input utente, contenuto recuperato da fonti esterne e output dei tool.

Tool-use governance

Terzo: tool-use governance L’agente non deve poter invocare liberamente API sensibili; deve passare da autorizzazioni esplicite, policy, conferme umane o sandbox.

Quarto: output handling sicuro.

Il risultato del modello non deve essere eseguito, inviato, pubblicato o usato pe modificare sistemi senza validazione.

Monitoraggio e red teaming continuo

Quinto: monitoraggio e red teaming continuo.

Per il CISO, la postura corretta non è “possiamo eliminare la prompt injection”, ma “possiamo limitarne impatto, probabilità di successo, blast radius e tempo di rilevazione”. È la stessa logica zero trust applicata al linguaggio naturale

Content safety e policy di output

La sicurezza della GenAI non riguarda solo la confidenzialità. Riguarda anche la qualità e l’ammissibilità degli output.

Un modello aziendale può generare contenuti discriminatori, violenti, sessualmente espliciti, autolesivi, diffamatori, non conformi al brand, non coerenti con il contesto normativo o semplicemente errati.

Gli strumenti di content filtering e safety filtering, come documentato anche dai principali provider cloud, possono bloccare o classificare output potenzialmente dannosi, ma non modificano da soli il comportamento profondo del modello [11].

Vanno quindi combinati con system instruction, policy di dominio, dataset controllati, RAG affidabile, human oversight e procedure di escalation.

Le 4 regole della policy di output

Una policy di output dovrebbe stabilire almeno quattro regole:

• Primo: quali contenuti sono vietati.
• Secondo: quali contenuti sono ammessi solo con disclaimer o revisione.
• Terzo: quali output possono essere usati automaticamente.
• Quarto: quali output richiedono approvazione umana prima di produrre effetti esterni.

Nei processi critici, l’output della GenAI dovrebbe essere trattato come proposta, non come decisione.

Questo vale per ambiti legali, HR, procurement, cybersecurity, safety industriale, credito, sanità, compliance e comunicazioni ufficiali.

La GenAI può accelerare l’analisi, ma la responsabilità deve restare assegnata a ruoli umani chiari.

Osservabilità: dal monitoring tecnico al controllo di affidabilità

L’articolo IEEE richiama metriche operative fondamentali: request count, failed requests, request latency, token utilization, throughput, throttled equests, cache hits e cache misses [1].

Sono metriche necessarie, ma in un contesto enterprise non bastano. Un sistema di osservabilità GenAI dovrebbe integrare tre livelli.

I 3 livelli del sistema di osservabilità GenAI

Il primo è tecnico: disponibilità, latenza, errori, saturazione, throughput, consumo token, rate limit, costo per richiesta, costo per business unit, health degli endpoint, fallback, code, timeout e prestazioni per region.

Invece il secondo è di sicurezza: prompt bloccati, tentativi di injection, richieste contenenti dati sensibili, anomalie di accesso, chiavi usate in modo improprio, output filtrati, eventi DLP, chiamate tool negate, escalation verso SOC, spike di token, uso fuori orario, deviazioni da baseline utente o applicativa.

Il terzo è semantico-governativo: groundedness score, retrieval precision, documenti usati per risposta, fonti mancanti, risposte contestate dagli utenti, tasso di allucinazioni rilevate, policy violation rate, fairness issue, drift del modello, drift della knowledge base, percentuale di risposte “non sufficientemente fondate” e numero di interventi human-in-the-loop.

Questi dati devono confluire in dashboard utilizzabili da CISO, cloud team, data owner, compliance, DPO e responsabili applicativi. Ma soprattutto devono generare azioni: blocco automatico, riduzione privilegi, revisione del prompt, aggiornamento della knowledge base, tuning dei filtri, apertura incident, escalation legale o sospensione del caso d’uso.

La logging strategy è delicata. Loggare tutto può creare un rischio privacy e segretezza industriale. Non loggare nulla rende impossibile audit, forensic e miglioramento.

La soluzione è una strategia bilanciata: logging dei metadati sempre, logging del contenuto solo quando necessario e consentito, redazione dei dati sensibili, retention differenziata, accesso limitato ai log e tracciabilità delle consultazioni.

Resilienza: la GenAI come servizio critico

Quando un assistente GenAI è usato da pochi utenti in laboratorio, la disponibilità non sembra un problema di board.

Inoltre, quando lo stesso assistente entra nel customer service, nel SOC, nel supporto tecnico, nella produzione documentale o nei processi di business, diventa un servizio critico.

Il framework IEEE richiama la necessità di architetture resilienti con ridondanza, scaling dinamico, recovery mechanism, deployment multi-region e gateway per instradare le richieste verso endpoint regionali differenti [1].

Questa logica è particolarmente importante in ambienti multi-cloud, dove il disegno di resilienza deve considerare non solo l’indisponibilità di una region, ma anche il degrado del modello, il blocco di un provider, la saturazione delle quote, il superamento del budget, un incidente di sicurezza o un problema di compliance regionale.

Un’architettura resiliente dovrebbe prevedere fallback model, fallback region e fallback process.

Non sempre il fallback deve essere un altro LLM equivalente. In alcuni casi può essere un modello più piccolo, una modalità read-only, una knowledge base tradizionale, una coda di lavorazione manuale o una procedura operativa alternativa.

Fail safe

La resilienza deve includere anche il fail safe. Se il sistema non riesce a verificare i permessi del retrieval, non deve rispondere usando documenti potenzialmente non autorizzati.

Invece, se il content filter non è disponibile, non deve pubblicare output ad alto rischio.

Se il gateway non riesce a classificare il dato, deve applicare la policy più restrittiva.

Ma se il modello produce output non fondato, deve dichiarare insufficienza
informativa.

GenAI resilience

Per il CISO, la GenAI resilience deve entrare nei playbook di incident response.
Occorre prevedere scenari come data leakage tramite prompt, compromissione di API key, abuso di modello, prompt injection riuscita, pubblicazione di output dannoso, avvelenamento della knowledge base, indisponibilità del provider, costo anomalo, violazione di data residency, uso di modello non autorizzato e shadow AI.

Cost governance: FinOps e sicurezza sono la stessa conversazione

La GenAI introduce una metrica economica nuova: il token.

Il consumo non dipende solo dal numero di utenti, ma dalla lunghezza dei prompt, dal contesto recuperato, dal modello scelto, dalla complessità delle risposte, dagli agenti, dai retry, dalle catene di reasoning, dai tool e dagli errori applicativi.

Per questo la cost governance è anche una misura di sicurezza.

Un attacco di model denial of service o un abuso di API può tradursi in costi elevati prima ancora che in indisponibilità. OWASP include infatti il model denial of service tra i rischi rilevanti per applicazioni LLM [7].

Misure pratiche di Cloud governance per l’AI

Le misure pratiche includono budget per business unit, quote per applicazione, rate limiting, alert su spike di token, semantic caching, prompt compression, routing verso modelli più piccoli quando sufficiente, reserved capacity per workload stabili, autospegnimento degli ambienti non produttivi, showback/chargeback e dashboard FinOps specifiche per AI.

Come scegliere il modello

La scelta del modello deve essere proporzionata al caso d’uso. Non sempre serve il modello più potente. Per classificazione, estrazione, summarization semplice o routing può bastare un modello più leggero.

Per attività ad alto impatto può servire invece un modello più robusto, con RAG controllata, evaluation e human review.

La governance matura non massimizza la potenza: ottimizza il rapporto tra rischio, costo, accuratezza, latenza e valore.

Compliance: AI Act, NIST AI RMF, ISO/IEC 42001 e controlli cloud

Il Regolamento europeo sull’intelligenza artificiale, Regolamento UE 2024/1689, introduce un approccio risk-based e regole specifiche per diversi ruoli e categorie di sistemi, inclusi requisiti per sistemi ad alto rischio e modelli di AI general-purpose [2].

Per le imprese, il punto non è solo capire se un singolo caso d’uso ricada o meno in una categoria normativa: è costruire un sistema documentabile di governance, risk management, logging, data governance, oversight umano e sicurezza.

Il NIST AI Risk Management Framework offre una struttura utile attraverso le funzioni Govern, Map, Measure e Manage [3].

La sua estensione dedicata alla GenAI aiuta a identificare rischi specifici dei sistemi generativi e azioni di mitigazione [4].

L’ISO/IEC 42001:2023, primo standard internazionale sui sistemi di gestione dell’AI, fornisce un riferimento organizzativo per integrare rischi, opportunità, ruoli e controlli in un sistema di gestione [5].

La Cloud Security Alliance, con l’AI Controls Matrix, propone inoltre un framework vendor-agnostic per sistemi AI cloud-based, utile per tradurre i principi in controlli auditabili [6].

Per un CISO europeo, la soluzione più concreta è mappare i controlli GenAI su framework già gestiti dall’organizzazione: ISO/IEC 27001, NIST CSF, NIST AI RMF, ISO/IEC 42001, CSA CCM/AICM, GDPR, AI Act, NIS2 e requisiti contrattuali.

L’obiettivo non è creare l’ennesimo silos di compliance, ma un controllo integrato.
Una policy GenAI aziendale dovrebbe includere: ambito di applicazione, definizioni, ruoli e responsabilità, classificazione dei casi d’uso, modelli autorizzati, dati ammessi e vietati, requisiti per RAG e vector database, logging, retention, human oversight, sicurezza dei prompt, divieto di nserimento di segreti, gestione dei fornitori, valutazioni privacy, valutazioni di impatto AI, requisiti di sicurezza applicativa, red teaming, incident reporting, monitoraggio continuo e sanzioni disciplinari per usi non autorizzati.

Shadow AI: il rischio più sottovalutato

Molte aziende hanno già workload GenAI non censiti. Dipendenti che usano strumenti pubblici per riassumere documenti, sviluppatori che inviano codice a servizi esterni, team marketing che caricano materiali riservati, funzioni HR che sperimentano strumenti di screening, reparti legali che testano bozze contrattuali, operation che usano chatbot per procedure interne.

Il divieto assoluto raramente funziona. Produce aggiramento.

La strategia più efficace è offrire alternative aziendali sicure, semplici e approvate. Un portale GenAI interno, un catalogo di servizi autorizzati, template di prompt sicuri, formazione mirata e processi rapidi di approvazione riducono lo shadow AI più di una policy punitiva.

Il CISO dovrebbe però dotarsi anche di capacità di detection: CASB, proxy, secure web gateway, DLP, log SaaS, analisi DNS, endpoint telemetry e survey interne.

Lo scopo non è sorvegliare in modo indiscriminato, ma capire dove l’azienda sta già trasferendo dati e decisioni.

Una reference architecture per la GenAI sicura in cloud

Una reference architecture enterprise può essere descritta in sette strati:

• Identity layer: identity provider federato, MFA, conditional access, workload identity, PAM/JIT, service principal governati e segregazione dei ruoli.
• Network and access layer: private endpoint, API gateway, WAF dove applicabile, egress filtering, service mesh, segmentazione, DNS controllato e connessioni cifrate.
• Data governance layer: classificazione, catalogo dati, DLP, data lineage, encryption, key management, retention, anonimizzazione, policy di localizzazione e accesso permission-aware.
• Model layer: catalogo modelli, model card, approvazione, test, red teaming, evaluation, versioning, fallback, monitoraggio drift e policy per modelli open source o terze parti.
• RAG and knowledge layer: ingestion controllata, validazione documentale, chunking tracciato, embedding sicuri, vector database segregato, ACL coerenti con le fonti, citazioni e verifiche di groundedness.
• Runtime guardrail layer: system prompt, prompt firewall, input validation, content moderation, output filtering, tool-use policy, rate limiting, token budget, anomaly detection, human-in-the-loop e blocco delle azioni non autorizzate.
• Observability and compliance layer: log centralizzati, SIEM/SOC integration, metriche tecniche, metriche semantiche, audit trail, dashboard di rischio, report compliance, incident workflow e continuous assurance.

Questa architettura deve essere replicabile sui diversi cloud, pur accettando controlli nativi differenti.

La coerenza deve stare nelle policy e negli outcome, non necessariamente nell’identità tecnica dei prodotti.

Roadmap operativa per i CISO

Nei primi 30 giorni, l’obiettivo è visibilità. Censire casi d’uso GenAI, strumenti già usati, dati coinvolti, fornitori, API key, repository, chatbot interni, sperimentazioni e rischi evidenti.

Definire una policy minima: cosa è vietato, cosa è consentito, cosa richiede approvazione, quali dati non possono essere inseriti in strumenti pubblici.

Tra 30 e 90 giorni, costruire la baseline tecnica: AI gateway, catalogo modelli
autorizzati, logging minimo, DLP, controllo degli accessi, segreti gestiti, ambienti segregati, processo di approvazione dei casi d’uso, template di DPIA/AI impact assessment e integrazione con procurement e legal.

Tra 90 e 180 giorni, portare in produzione i primi use case strategici con architettura controllata: RAG permission-aware, metriche di groundedness, content filtering, SOC integration, playbook incident, red teaming, dashboard per CISO e report per comitato rischi o board.

Dopo 180 giorni, passare alla governance continua: audit periodici, revisione del catalogo modelli, test di prompt injection, verifica dei costi, simulazioni di incidente, aggiornamento delle policy, valutazione dei fornitori, benchmarking dei controlli rispetto a NIST AI RMF, ISO/IEC 42001 e CSA AICM.

KPI e KRI per il board

Per rendere la GenAI governabile a livello di board, occorre tradurre la complessità tecnica in indicatori.

KPI utili: percentuale di casi d’uso censiti, percentuale di workload GenAI dietro gateway aziendale, numero di modelli autorizzati, copertura logging, copertura DLP, casi d’uso con AI risk assessment completato, riduzione dello shadow AI, tempi medi di approvazione, percentuale di risposte con fonti tracciate, accuratezza su benchmark interni, saving da semantic caching.

KRI rilevanti: prompt bloccati per dati sensibili, tentativi di prompt injection, output filtrati per policy violation, spike anomali di token, accessi negati, uso di tool non autorizzati, casi d’uso non censiti, documenti non classificati in knowledge base, risposte contestate, incidenti o near miss, modelli fuori supporto, fornitori senza adeguate clausole di sicurezza.

Questi indicatori dovrebbero essere discussi periodicamente in un AI governance committee che includa CISO, CIO/CTO, DPO, legal, procurement, risk management, data governance e rappresentanti delle business unit.

Parting words: GenAI sicura è questione di architettura, non di entusiasmo

La GenAI promette produttività, automazione, conoscenza aumentata e nuove capacità operative.

Ma senza cloud governance rischia di diventare una superficie d’attacco distribuita, opaca e difficilmente auditabile.

Il messaggio per i CISO è chiaro: non basta acquistare una piattaforma “enterprise AI” e confidare nelle impostazioni predefinite del provider.

Serve un framework aziendale che renda i workload GenAI sicuri by design, tracciabili by default, resilienti by architecture e conformi by evidence.

Il framework a cinque pilastri proposto da Bandapati, Atta e Ghosh Chowdhury offre una base solida: cost management, security, resilience, operations e model governance [1].

La sua applicazione pratica, però, richiede una traduzione nel linguaggio operativo della cyber security: zero trust, policy-as-code, secure landing zone, RAG governata, prompt security, content safety, observability semantica, incident response e compliance integrata.

La GenAI non deve essere frenata, ma resa governabile. Perché l’innovazione che non può essere tracciata, spiegata, contenuta e recuperata dopo un incidente non è trasformazione digitale: è debito di rischio.

Fonti e riferimenti

[1] Goutham Bandapati, Srinivasa R. Atta, Ananya Ghosh Chowdhury, “A
Framework for Governing Generative AI Workloads in Cloud Environments”, IEEE Computer, vol. 59, n. 4, aprile 2026, pp. 20-29, DOI 10.1109/MC.2025.3615616.
[2] Parlamento europeo e Consiglio dell’Unione europea, Regolamento (UE) 2024/1689 del 13 giugno 2024, Artificial Intelligence Act, pubblicato nella Gazzetta ufficiale dell’Unione europea il 12 luglio 2024.
[3] National Institute of Standards and Technology, Artificial Intelligence Risk
Management Framework, AI RMF 1.0, NIST AI 100-1, gennaio 2023.
[4] National Institute of Standards and Technology, Artificial Intelligence Risk
Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, luglio 2024.
[5] ISO/IEC 42001:2023, Artificial intelligence — Management system.
[6] Cloud Security Alliance, AI Controls Matrix, framework vendor-agnostic per sistemi AI cloud-based, 2025.
[7] OWASP, Top 10 for Large Language Model Applications, edizione 2025.
[8] Amazon Web Services, “What is RAG? Retrieval-Augmented Generation”.
[9] GOV.UK, “AI Insights: Prompt Risks”, 2026.
[10] UK National Cyber Security Centre, “From bugs to bypasses: adapting vulnerability disclosure for AI safeguards”, 2025.
[11] Google Cloud, documentazione su safety e content filters per modelli Gemini e Vertex AI.
[12] OECD, AI Principles, adottati nel 2019 e aggiornati nel 2024. Goutham Bandapati, Srinivasa R. Atta, Ananya Ghosh Chowdhury, “A Framework for Governing Generative AI Workloads in Cloud Environments”, IEEE Computer, vol. 59, n. 4, aprile 2026, pp. 20-29, DOI 10.1109/MC.2025.3615616.

[13] ENISA, Multilayer Framework for Good Cybersecurity Practices for AI.
[14] Petar Radanliev, “Frontier AI regulation: what form should it take?”, Frontiers in Political Science, 2025, DOI 10.3389/fpos.2025.1561776.
[15] Petar Radanliev, Omar Santos, Uchenna Daniel Ani, “Generative AI cybersecurity and resilience”, Frontiers in Artificial Intelligence, 2025, DOI 10.3389/frai.2025.1568360.