Article. What i write

AI Shared Responsibility Model: chi risponde della sicurezza nell’era della Generative AI

Pubblicato il 31 agosto 2026 su CyberSecurity360.it

Lo shared responsibility model nasce nel cloud computing con l’obiettivo di chiarire i confini delle responsabilità dei vari attori coinvolti. Per esempio, consente di capire quali controlli di sicurezza spettano al provider e quali al cliente. L’adozione dei sistemi di Generative AI pone in discussione questi confini. Un’applicazione basata su Large Language Model (LLM) introduce componenti (modello, dati di grounding, prompt, output generati, plugin, orchestrazione) che non hanno un corrispettivo diretto nel tradizionale stack software, e con essi nuove superfici di attacco, la cui titolarità non è chiara. Ecco cos’è l’AI Shared Responsibility Model, nella formulazione a tre layer proposta da Microsoft: il confronto con i modelli di deployment SaaS, PaaS e IaaS nell’ambito dei sistemi agentici e come attuare la ripartizione delle responsabilità, appoggiandosi ai framework di riferimento (NIST AI RMF e Generative AI Profile, OWASP Top 10 for LLM e for Agentic Applications, MITRE ATLAS, ENISA FAICP, ISO/IEC 42001) e al quadro normativo dell’AI Act. In sintesi, l’AI non sposta semplicemente le responsabilità verso il provider, ma le moltiplica e alcune restano in capo all’organizzazione, a prescindere dal modello adottato.

Chi è responsabile di questo controllo

Per quindici anni, lo shared responsibility model ha svolto una funzione semplice e fondamentale nel contesto del cloud: ha permesso di rispondere alla domanda “Chi è responsabile di questo controllo?”. Ciò ha consentito di evitare le due criticità speculari che colpiscono le architetture condivise: il controllo che nessuno presidia perché ciascuno presume che lo faccia l’altro e il controllo presidiato due volte in modo irrazionale. La Generative AI supera questo limite. Quando un’organizzazione integra un LLM (Large Language Model) in un proprio processo, affida a un componente probabilistico la capacità di interpretare input in linguaggio naturale e di produrre contenuti, codice o azioni. Le proprietà che rendono questi sistemi utili sono le stesse che ne complicano la loro messa in sicurezza. Il comportamento del modello è adattivo, l’output varia, le fonti dei dati cambiano, aumentando l’autonomia e la superficie d’attacco in modi difficili da prevedere.

Le nuove categorie di rischio introdotte dall’AI

Le conseguenze per il modello di responsabilità sono chiare: non basta adattare la tabella dello schema IaaS/PaaS/SaaS, ma è necessario riconoscere che l’AI introduce categorie di rischio che nel software tradizionale non esistevano e che devono essere assegnate esplicitamente. Ecco uno schema per stabilire, di fronte a una soluzione specifica, dove finisce la responsabilità del provider e dove inizia la propria. Lo scope privilegia i sistemi di Generative AI e gli LLM, dove le novità sono più marcate, mantenendo però la cornice generale dei sistemi AI che resta valida.

Il punto di partenza: la responsabilità condivisa nel cloud

È opportuno partire dallo schema classico, in quanto l’AI Shared Responsibility Model ne rappresenta un’estensione e ne eredita la logica. Nel modello cloud, la ripartizione segue il livello di astrazione del servizio. In un deployment Infrastructure as a Service (IaaS), il cliente si occupa del sistema operativo, dell’ambiente di runtime, delle applicazioni e dei dati, mentre il provider si occupa esclusivamente dell’infrastruttura fisica e della virtualizzazione. Nel modello Platform as a Service (PaaS), il provider si occupa della gestione del sistema operativo e della piattaforma, mentre il cliente si concentra sulle applicazioni e sui dati. Nel modello Software as a Service (SaaS), il provider gestisce l’intero stack applicativo e al cliente resta la parte più alta [2]. Dallo schema originario, nel mondo dell’intelligenza artificiale sono sopravvissuti due controlli. Il primo sostiene che, man mano che si passa da IaaS a SaaS, il baricentro delle responsabilità si sposta progressivamente verso il provider, ma non si annulla mai del tutto. L’altro è che alcune responsabilità non migrano mai: i dati e le identità restano in capo al cliente in ogni modello di deployment, così come la classificazione dei dati, la scelta di cifrare e gli obblighi di compliance [2]. Questo principio previene un equivoco diffuso quando viene applicato alla Generative AI: l’idea che adottare un assistente “chiavi in mano” sollevi l’organizzazione dalle proprie responsabilità in termini di sicurezza e governance.

La struttura dell’AI Shared Responsibility Model

La trasposizione più nota e operativamente utile di questo modello è quella formalizzata da Microsoft, che scompone un’applicazione AI in tre layer funzionali, ciascuno dei quali raggruppa attività la cui sicurezza ricade, di norma, su chi le esegue [1]. Funziona come il cloud, ma cambia l’obiettivo.

• AI platform;
• AI application;
• AI usage.

A questo modello a tre layer Microsoft affianca un principio di adozione, sintetizzato nella formula “configure before customize”. La raccomandazione è di partire da approcci SaaS, come i Copilot, e di salire a PaaS o alla costruzione di modelli custom solo quando le capacità non bastano: ogni passo verso il basso nello stack aumenta il livello di responsabilità e di competenza richiesto all’organizzazione, e la costruzione di un modello custom andrebbe intrapresa solo da chi possiede competenze profonde di data science e piena consapevolezza delle implicazioni di sicurezza, privacy ed etica [1]. In sintesi, si tratta di una scelta di risk management: è opportuno minimizzare la percentuale di responsabilità finché non si è in grado di sostenerla.

AI platform

Il layer che fornisce alle applicazioni le capacità di AI. Qui risiedono il modello, i dati di addestramento e le configurazioni che ne modificano il comportamento, come i pesi del modello. La piattaforma espone le proprie funzioni tramite API: riceve il testo che istruisce il modello, il cd. metaprompt, e restituisce l’output generato, il prompt- response [1]. Il sistema di sicurezza a questo livello è basato sulla presenza di un safety system che filtra gli input potenzialmente nocivi diretti al modello e i contenuti pericolosi che il modello, essendo generativo, potrebbe produrre in uscita: come, per esempio, hate speech e tentativi di jailbreak, destinati a evolvere nel tempo [1].

AI application

Il layer fornisce il servizio o l’interfaccia che l’utente utilizza per accedere alle capacità del modello. La sua complessità varia molto: si va dall’applicazione minimale che si limita a inoltrare il prompt dell’utente al modello, fino a sistemi che arricchiscono il prompt con un contesto aggiuntivo, come un persistence layer, un semantic index, o l’accesso a fonti dati esterne tramite plugin, e che possono interfacciarsi con applicazioni e sistemi preesistenti [1]. In questo caso la sicurezza è demandata a un application safety system che ispeziona in profondità il contenuto inviato nel metaprompt e le interazioni con plugin, data connector e altre applicazioni, ciò che Microsoft chiama AI orchestration [1]. È il layer dove si concentra gran parte del rischio specifico delle architetture retrieval-augmented e agentiche.

AI usage

Il layer che descrive come le capacità di AI vengono concretamente consumate. Il fattore positivo è che l’interfaccia generativa è diversa dalle interfacce precedenti (API, riga di comando, GUI): è interattiva e dinamica, e adatta il comportamento del sistema all’utente e alle sue intenzioni [1]. Questa interattività ribalta un equilibrio consolidato. Nei sistemi tradizionali è il progettista a determinare l’output, mentre con la Generative AI è l’input dell’utente a influire in modo significativo su ciò che il sistema produce. Ciò rende i guardrail critici e, soprattutto, sposta parte del rischio sul comportamento e sulla responsabilità dell’utente [1]. La sicurezza qui è simile a quella di qualunque sistema informatico: identità e controlli di accesso, protezione dei dispositivi, data protection e governance, ma con un’enfasi maggiore sulla formazione. Gli utenti devono essere formati alla differenza tra un’applicazione IT standard e una basata sull’intelligenza artificiale, e agli attacchi che sfruttano contenuti falsi e convincenti, dal testo alla voce ai video. [1].

Le nuove aree di responsabilità nella Generative AI

Il primo passo per costruire il modello si realizza con la mappatura dei tre layer citati, ciò consente di definire le nuove responsabilità. Si tratta per lo più di aree inesplorate nell’ambito del software tradizionale e spesso le organizzazioni, in questa fase, commettono errori nell’attribuzione delle responsabilità.

Dati di grounding e governance del contesto

La maggior parte delle applicazioni LLM di valore non si limita al modello base, ma lo integra con i propri dati tramite la tecnica del Retrieval-Augmented Generation (RAG), recuperando documenti pertinenti da inoculare nel prompt runtime. Ciò sposta una parte sostanziale del rischio sui dati e non sul modello. Anche con le autorizzazioni corrette, un contesto troppo ampio può trascinare nel prompt frammenti sensibili che riaffiorano poi nella risposta, nel transcript o nei log, dando luogo al fenomeno del semantic overshare. La responsabilità di governare cosa può recuperare il sistema, e per quale utente, è del cliente in ogni modello di deployment, perché riguarda dati che suoi.

Prompt security e prompt injection

La prompt injection si verifica nel caso in cui un attaccante costruisce un input che il modello interpreta come una nuova istruzione, anziché come un contenuto da elaborare. La natura del problema è architetturale: gli LLM processano istruzioni e dati nello stesso canale, senza una separazione netta, e il modello non distingue gli uni dagli altri. La distinzione operativamente più importante è tra forma diretta, l’utente digita istruzioni malevole nella chat, e forma indiretta, in cui il modello legge contenuto non fidato da una pagina web, un documento, un’email o un ticket, ed esegue le istruzioni nascoste. Il contributo accademico che ha inquadrato per primo questa seconda variante è il lavoro di Greshake, presentato all’ACM Workshop on Artificial Intelligence and Security: gli autori mostrano che le applicazioni con LLM integrato «confondono il confine tra dati e istruzioni» e che un attaccante può comprometterle da remoto, senza interfaccia diretta, iniettando prompt in dati destinati a essere recuperati a inferenza, con impatti che vanno dal furto di dati alla propagazione worm-like [5]. Il punto rilevante per il modello di responsabilità è che né RAG né il fine-tuning eliminano questa classe di rischio: la mitigazione passa per una defense-in-depth (quali tools a privilegio minimo, filtri su input e output, approvazione umana per le azioni ad alto rischio, test avversariali ricorrenti) che è in larga misura responsabilità di chi costruisce e utilizza l’applicazione.

Output handling e content safety

Il corollario speculare della prompt injection è l’output handling. La regola base è considerare l’output del modello come un dato non fidato e applicarvi la stessa sanitizzazione riservata a qualunque input esterno, soprattutto quando quell’output alimenta altri sistemi (p.e. una query, una chiamata API, l’esecuzione di codice). A questa si aggiunge il content safety: filtrare i contenuti nocivi che il modello può generare. È un controllo che, a seconda del modello di deployment, può essere offerto dal provider come servizio configurabile o dover essere costruito dal cliente.

Fine-tuning, model governance e supply chain

Chi personalizza un modello tramite fine-tuning si assume la responsabilità dei dati usati per addestrarlo e dei comportamenti che ne derivano, incluso il rischio di data poisoning. Più in generale, la catena di fornitura dei modelli è una superficie d’attacco a sé: l’uso di modelli e dataset di terze parti offre flessibilità a fronte di garanzie di sicurezza minime, e richiede quindi vetting, monitoraggio e governance espliciti. Il NIST Generative AI Profile colloca l’integrità della value chain tra le categorie di rischio proprie della Generative AI, aggravata dalla scalabilità dei dati di addestramento, spesso troppo vasti per essere ispezionati dagli esseri umani, e dal riuso estensivo di un numero limitato di foundation model [4].

Identità, plugin e orchestrazione

Man mano che gli LLM iniziano a chiamare strumenti esterni, il loro potere d’azione diventa la superficie d’attacco. La configurazione dei plugin, i confini dei privilegi concessi, l’isolamento tra workload sono responsabilità che ricadono su chi progetta l’integrazione, e che la documentazione richiama esplicitamente anche per i modelli SaaS, dove resta in capo al cliente la configurazione delle usage policy e il controllo su quali dati e azioni il sistema può toccare. Questa dimensione, nella sua forma più avanzata, dà luogo ai sistemi agentici.

Human oversight e uso accettabile

Resta infine la fascia più alta, la AI usage, dove la responsabilità è quasi interamente in capo al cliente a prescindere dal deployment: aggiornare le acceptable use policy, formare gli utenti, validare gli output prima di utilizzarli, mappare l’uso dell’AI ai requisiti di compliance applicabili (GDPR, normative di settore, AI Act) [1].

La distribuzione per modello di deployment

Le aree appena descritte non si distribuiscono allo stesso modo nei tre scenari noti. La tabella che segue sintetizza, in linea di massima, come si sposta il baricentro delle responsabilità, fermo restando che la ripartizione puntuale dipende dal singolo servizio e dalle opzioni di configurazione che il provider espone.

Tabella 1. Ripartizione indicativa delle responsabilità per modello di deployment:

Area di responsabilità	SaaS (es. Copilot)	PaaS (es. modello via API gestita)	IaaS / self-hosted
Infrastruttura e hosting del modello	Provider	Provider	Cliente
Sicurezza e lifecycle del modello base	Provider	Provider (condiviso per il tuning)	Cliente
Safety System e lifecycle del modello (filtri input/output)	Provider	Provider, spesso configurabile	Cliente
Logica applicativa e orchestrazione (plugin, RAG)	Provider per l'app; cliente per le estensioni	Cliente	Cliente
Dati di grounding e governance del contesto	Cliente	Cliente	Cliente
Fine-tuning e dati di addestramento	N/D o limitato	Cliente	Cliente
Output handling e validazione	Cliente	Cliente	Cliente
Identità, accessi, configurazione delle usage policy	Cliente	Cliente	Cliente
Formazione utenti e uso accettabile	Cliente	Cliente	Cliente
Mappatura ai requisiti di compliance	Cliente	Cliente	Cliente

In sintesi, nel caso di un deployment SaaS, il provider assume la responsabilità operativa dell’intero stack applicativo, dal lifecycle del modello alla governance dei plugin ai safety system; in un modello PaaS la responsabilità su design, tuning e integrazione del modello è condivisa tra provider e cliente, mentre il provider continua a operare e mettere in sicurezza i servizi sottostanti; nell’auto-gestione la responsabilità ricade sull’organizzazione, dal contrasto alla prompt injection all’isolamento dei workload, dal red teaming alla manutenzione dei cluster GPU. Le funzioni che riportano “Cliente” in ogni colonna sono il dato più importante della tabella: i dati, l’identità, la validazione dell’output, la formazione e la conformità non possono mai essere completamente delegati.

Implementare il modello: i framework di riferimento

Un modello di responsabilità definisce chi deve occuparsi di cosa, ma non come. Per colmare questo “come” esiste un ecosistema di framework che, analizzati insieme, coprono i diversi aspetti: il rischio, la minaccia, la gestione e la conformità. È utile osservare come si intersecano, perché sono complementari e non alternativi tra loro.

Il framework per la gestione del rischio

Sul piano della gestione del rischio, il framework di riferimento è il NIST AI Risk Management Framework (AI RMF 1.0), pubblicato nel gennaio 2023, costruito attorno a quattro funzioni (Govern, Map, Measure e Manage) e pensate per essere iterative e applicabili tanto al machine learning tradizionale quanto ai sistemi generativi [3]. Il suo completamento per la Generative AI è rappresentato dal Generative AI Profile (NIST AI 600-1), del luglio 2024, che adatta il framework ai rischi specifici dei sistemi generativi, identificando dodici categorie di rischio tra cui:

• confabulation (le cosiddette allucinazioni),
• information integrity,
• data privacy,
• information security,
• integrità della value chain, associando a ciascuna oltre duecento azioni, organizzate secondo le funzioni del Core, che lo rendono sensibilmente più operativo del framework base [4].

Due framework per la minaccia

Sul piano della minaccia, si individuano due framework. Il primo è l’OWASP Top 10 for LLM Applications, nell’edizione 2025, che funziona come una checklist delle vulnerabilità più critiche delle applicazioni LLM. La prompt injection (LLM01) occupa il primo posto per la seconda edizione consecutiva, accanto a voci come la sensitive information disclosure, la supply chain, il data and model poisoning, il improper output handling, e, di recente, il system prompt leakage e le vector and embedding weaknesses, queste ultime legate alla diffusione dei RAG [6]. L’altro è il MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) il quale adotta una struttura a matrice di tattiche e tecniche resa familiare da MITRE ATT&CK, applicata però agli attacchi specifici dei sistemi AI: è una living knowledge base basata su osservazioni reali e dimostrazioni di red team, nata nel 2020 come Adversarial ML Threat Matrix da una collaborazione tra MITRE e Microsoft, e aggiornata di recente per coprire i vettori generativi e agentici [7]. I due framework hanno vocazioni distinte: OWASP è la checklist orientata allo sviluppatore, ATLAS la base di threat intelligence per chi modella le minacce.

Gestione e conformità: standard certificabile

Sul piano del sistema di gestione e della conformità, lo standard certificabile è ISO/IEC 42001:2023, che definisce un AI Management System (AIMS) sul modello dei sistemi di gestione ISO, con un approccio per processi orientato alla governance dell’AI [10]. Nel contesto europeo si affianca il framework dell’ENISA, il Multilayer Framework for Good Cybersecurity Practices for AI (FAICP), del giugno 2023, che propone, in modo significativo, una propria architettura a tre layer: le fondamenta di cyber security dell’ambiente ICT, la cyber security specifica dell’AI lungo il ciclo di vita del machine learning e la cyber security di settore [8].

AI Act, un approccio basato sul rischio

Resta il piano normativo, che in Europa è diventato un obbligo. Il Regolamento (UE) 2024/1689, l’AI Act, impone un approccio basato sul rischio e, per quanto qui rileva, fa una distinzione tra gli obblighi del provider e quelli del deployer di un sistema AI, una ripartizione di responsabilità giuridica che fa eco, su un piano diverso, alla ripartizione tecnica del shared responsibility model [11]. Per chi opera in UE, è inevitabile effettuare una lettura combinata dei due piani, perché il confine contrattuale e tecnico tra provider e cliente deve reggere anche sotto il profillo della responsabilità regolamentare.

La frontiera agentica: la responsabilità in presenza di autonomia

Tutto quanto detto finora è valido nel caso in cui l’AI opera come un componente che riceve input e produce output. I sistemi agentici annullano questo assunto. Un agente persegue un obiettivo di livello più alto, poiché selezionano, pianificano ed eseguono una sequenza di azioni in autonomia, usando il modello come «cervello» oltre ad un insieme di tool (API, interpreti di codice, accesso a dati e servizi). In questo specifico contesto, rispetto a un LLM passivo, si aggiungono tre proprietà: l’autonomia decisionale, l’uso di strumenti con effetti sul mondo esterno e una memoria o uno stato che persiste tra le sessioni. Si tratta di un cambiamento qualitativo. La sicurezza degli LLM mira a impedire gli output nocivi; la sicurezza agentica deve impedire i fallimenti a cascata tra sistemi autonomi capaci di pianificare, persistere e delegare attraverso strumenti e sistemi diversi [13]. La diffusione del Model Context Protocol (MCP), quale interfaccia di fatto, per collegare agenti e strumenti accentua questa dinamica, perché incoraggia a comporre tool eterogenei provenienti da fonti diverse. In questo caso il rischio è generato dalla composizione e non dal singolo modello. Come osservato nella letteratura sulle agency risk, il fallimento spesso non si origina nel ragionamento del modello, ma nei tool che l’agente è autorizzato a usare e nel modo in cui questi sono integrati nelle sue decisioni: un inventario di strumenti mal specificato produce violazioni di sicurezza anche a fronte di ragionamento corretti.

Le classi di fallimento proprie degli agenti

La OWASP Agentic Security Initiative (ASI) le ha sistematizzate, prima in una tassonomia di minacce e mitigazioni e poi in una OWASP Top 10 for Agentic Applications (2026) orientata alle minacce già osservate in produzione [13]. Di queste, cinque meritano attenzione. L’excessive agency e il tool misuse sono il modello del confused deputy: una prompt injection induce l’agente a invocare uno strumento per conto dell’attaccante; la contromisura è il principio di least-agency, estensione del privilegio minimo, per cui all’agente va concessa solo l’autonomia strettamente necessaria al compito. Il goal hijacking è l’evoluzione della prompt injection: non far dire al modello una sciocchezza, ma deviarne la missione. Il memory poisoning sfrutta il fatto che l’agente accumula memoria (vector store, cronologia, scratchpad) e che un attaccante può seminarvi contenuti per influenzare decisioni future, con una superficie d’attacco che persiste oltre il singolo prompt. L’inter-agent trust exploitation colpisce i sistemi multi-agente: messaggi inter-agente contraffatti possono disorientare interi cluster di agenti autonomi, e un agente compromesso ne avvelena altri lungo la catena. I rogue agent, infine, sono l’agente disallineato che persegue obiettivi in conflitto con il suo scopo originario: l’equivalente agentico della minaccia interna, senza bisogno di un attaccante esterno.

La «lethal trifecta» come euristica operativa

Una formulazione particolarmente efficace per i decisori è quella proposta da Simon Willison, che ha coniato il termine lethal trifecta: un agente è esposto al furto di dati quando combina tre capacità nello stesso contesto di esecuzione: accesso a dati privati, esposizione a contenuto non fidato e capacità di comunicare verso l’esterno. Quando coesistono tutte e tre le condizioni, una singola porzione di contenuto avvelenato può indurre l’agente a esfiltrare informazioni sensibili senza che siano necessaria alcuna vulnerabilità del codice tradizionale [14]. La difesa più robusta non è un filtro (nessun filtro è perfetto contro la prompt injection), ma una scelta architetturale: evitare di concentrare le tre proprietà in un solo agente, ricorrendo ad allowlist, ad approval gate per le azioni a potenziale esfiltrante e ad agenti a scope ristretto. Una misura per mitigare il rischio consiste nel trattare l’inserimento di contenuto non fidato come un evento di contaminazione, dopo il quale ogni azione potenzialmente esfiltrante richiede un’approvazione esplicita [14].

Dove si sposta il confine di responsabilità

Willison ha rilevato che i vendor hanno chiuso queste falle nei propri prodotti bloccando il vettore di esfiltrazione; ma quando si inizia a combinare strumenti per conto proprio, il vendor non può fare nulla per proteggere l’utente, e l’MCP incoraggia esattamente questo mix-and-match [14]. È la rappresentazione plastica del confine di responsabilità nell’era agentica: nel caso in cui un’organizzazione decidesse di comporre un agente da sé, assumerebbe, di fatto, il ruolo di system integrator e, con esso, la responsabilità, che nel caso delle AI semplice restava del provider, di garantire che la composizione degli strumenti non realizzi la lethal trifecta. La conseguenza è che, nei deployment compositi e multi-agente, la quota di responsabilità del cliente è quasi totale e riguarda controlli che nel mondo dei prodotti SaaS non lo riguardavano affatto.

Un quadro di governance ancora in itinere

I framework di gestione del rischio non sono pensati per agenti che acquisiscono capacità di tool-use e sono eseguiti autonomamente. Il NIST Generative AI Profile gestisce il comportamento generativo del modello, ma non l’azione autonoma dell’agente. NIST CAISI ha annunciato a inizio 2026 una AI Agent Standards Initiative e, in ambito community, è in elaborazione un Agentic Profile dell’AI RMF, questi sono segnali che il quadro normativo va esteso con concetti specifici: autonomia, rischio legato all’uso di strumenti, accountability lungo le catene di delega. Per chi opera con gli agenti, il presidio passa attraverso i seguenti controlli la cui titolarità è di chi progetta e utilizza l’agente:

• il tooling a least-agency con autorizzazione per singola azione e lo scoped token;
• l’human-in-the-loop per le azioni ad alto impatto e irreversibili;
• l’autenticazione e la verifica di integrità delle comunicazioni inter-agente, fino alla firma crittografica delle identità degli agenti;
• il partizionamento della memoria per livello di fiducia con audit periodici e l’attribuzione di un’identità non-umana governata agli agenti stessi.

Indicazioni operative

Il modello suggerisce alcune azioni concrete, valide trasversalmente per i diversi tipi di deployment. In fase di procurement, conviene usare il modello di responsabilità come griglia di domande al fornitore per definire il perimetro di responsabilità. Per esempio:

• Quali safety system sono attivi sulla piattaforma e quali sono configurabili?
• Come viene gestito l’isolamento tra tenant?
• Quali dati di addestramento e quali log sono conservati dal provider e per quanto?
• Quali strumenti di governance (content filtering, audit, data loss prevention) sono esposti al cliente?

La regola del “configure before customize” è la chiave di volta: scegliere il modello più compatibile con i propri requisiti riduce la quota di responsabilità che ci si assume [1]. Nella fase di progettazione, è fondamentale trattare tutti i dati come non fidati e modellare le minacce con i framework OWASP e ATLAS prima di passare alla fase di esercizio. Nelle architetture RAG e agentiche, alla luce della irrisolvibilità strutturale della prompt injection, è necessario attivare i controlli basici come il privilegio minimo del tool e l’approvazione umana per le azioni irreversibili. Inoltre, prima di mettere in produzione un agente, è opportuno verificare che la sua configurazione non realizzi la lethal trifecta [5][6][14]. In fase di esercizio, le responsabilità che non si delegano vanno presidiate con processi espliciti, quali la classificazione e la governance dei dati che alimentano i sistemi, la gestione dell’identità e degli accessi, la validazione degli output ad alto impatto, la formazione degli utenti sulla differenza tra applicazione tradizionale e AI e sui rischi di manipolazione e la mappatura dei requisiti di compliance applicabili [1][2]. Il tutto inquadrato in un ciclo di sicurezza completo (identify, protect, detect, respond, recover, govern) perché una lacuna tralasciata in una sola di queste fasi vanifica le altre [1].

Limiti e questioni aperte

Il modello di responsabilità condivisa non è la soluzione definitiva. In particolare, ci sono tre aspetti che meritano di essere attenzionati. La prima è l’accountability lungo le catene di delega. Lo schema funziona bene su componenti statici, dove la titolarità di un controllo è stabile; un agente che esegue azioni in autonomia, e a maggior ragione un sistema multi-agente, frammenta la responsabilità lungo catene di delega difficili da tracciare a posteriori. Stabilire chi risponde per un’azione decisa e compiuta da un agente, e con quale evidenza dimostrarlo, è un problema irrisolto dagli standard attuali, ed è la ragione per cui, come visto, sono in arrivo iniziative dedicate. La seconda è la natura intrinseca di alcune vulnerabilità. La prompt injection non è un bug da correggere, ma è la conseguenza del modo in cui gli LLM trattano le istruzioni e i dati nello stesso canale: finché questa proprietà architetturale sarà presente, la difesa potrà essere solo una questione di mitigazione e contenimento del blast radius e non di rimozione [5][6]. La terza è il disallineamento tra i piani. Il confine tecnico tra provider e cliente, quello contrattuale e quello regolamentare introdotto dall’AI Act non coincidono necessariamente, e l’organizzazione si trova a comporre confini di responsabilità definiti con logiche diverse. Riconciliarle, ovvero far sì che chi è tecnicamente responsabile di un controllo lo sia anche contrattualmente e giuridicamente, è forse la sfida di governance più sottovalutata.

Il valore dell’AI Shared Responsibility Model

L’AI Shared Responsibility Model è un modo per adattare un approccio già utilizzato a un ambito nuovo e più complesso, come quello dell’intelligenza artificiale. Il suo valore sta nel rendere chiaro a tutti i soggetti coinvolti chi deve fare cosa. In pratica, pone una domanda semplice ma fondamentale: per questo controllo, in questo specifico utilizzo, chi è responsabile? L’obiettivo è evitare ambiguità e chiarire i ruoli, eliminando le zone grigie. La dimensione agentica mostra fino a che punto viene spinta la responsabilità su questi presupposti: quando un’organizzazione compone autonomamente strumenti e agenti, finisce per assumersi responsabilità che, nel caso di un prodotto chiavi in mano, resterebbero in capo al provider. La conclusione che emerge lungo tutta l’analisi è controintuitiva rispetto alla regola più diffusa: l’AI non semplifica la responsabilità delegandola al provider, ma la moltiplica. Questo perché la sua complessità, adattività e autonomia introducono nuove categorie di rischio. Anche nel caso di soluzioni SaaS “chiavi in mano”, restano saldamente in capo all’organizzazione aspetti critici come la gestione dei dati e delle identità, la validazione degli output, la formazione degli utenti e la conformità normativa. Questo insieme di controlli, intrinsecamente non delegabili, rappresenta il nucleo della responsabilità organizzativa: solo se governato attraverso framework e processi adeguati consente di adottare la Generative AI senza trasformarla in un nuovo vettore di rischio.

Riferimenti

---

---