Le organizzazioni che costruiscono su un modello linguistico ospitato ricevono dal fornitore un modello addestrato alla sicurezza e una piattaforma, e restano responsabili dell’applicazione che lo circonda. Microsoft, la Cloud Security Alliance e l’AI Act dell’UE suddividono ciascuno il lavoro tra il fornitore del modello e la parte che lo impiega, con un vocabolario diverso e un diverso peso giuridico. Questa nota confronta i tre approcci e propone una suddivisione pratica per il caso comune di un modello utilizzato tramite API. Accompagna How Anthropic red-teams Claude, and what it leaves to you, che esamina il lato del fornitore in un caso pubblicato.
Contesto: il modello cloud esteso all’IA
Il modello di responsabilità condivisa del cloud assegna ciascun controllo al fornitore o al cliente a seconda del tipo di servizio: software as a service (SaaS), platform as a service (PaaS) o infrastructure as a service (IaaS). Sia Microsoft sia la Cloud Security Alliance (CSA) estendono questa idea all’IA generativa. L’estensione cambia il vocabolario più della logica: quanto più in basso nello stack costruisce un cliente, tanti più controlli gli appartengono.
I modelli dei fornitori
Microsoft: piattaforma, applicazione e utilizzo
Il modello di responsabilità condivisa per l’IA di Microsoft descrive un’applicazione basata sull’IA in tre livelli: la piattaforma IA, l’applicazione IA e l’utilizzo dell’IA. Il livello di piattaforma fornisce il modello tramite API e comprende un sistema di sicurezza che filtra input e output dannosi. Il livello applicativo è l’interfaccia usata dall’utente, con grounding, plugin e connettori di dati, e richiede un proprio sistema di sicurezza applicativo. Il livello di utilizzo riguarda il modo in cui le persone usano la funzionalità, e Microsoft richiama i controlli di identità e accesso, le politiche di uso accettabile e la formazione degli utenti. [1]
Quanta parte di ciascun livello spetti al cliente dipende dal tipo di distribuzione. La pagina afferma che le responsabilità variano tra SaaS, PaaS e IaaS, e raccomanda di partire da offerte SaaS come Copilot, di passare a servizi PaaS come Azure OpenAI Service solo quando le funzionalità pronte all’uso non sono adeguate, e di riservare la costruzione di modelli personalizzati alle organizzazioni con competenze approfondite. La pagina aggiunge che le indicazioni sono illustrative, sono usate in senso di governance e non modificano alcun accordo con Microsoft. [1]
Microsoft: l’estensione agli agenti
Una seconda pagina di Microsoft tratta gli agenti, che distingue da un semplice modello perché un agente agisce senza che una persona approvi ogni passaggio, pianifica e itera, conserva memoria, ha una propria identità e può comporsi con altri agenti. Aggiunge tre livelli: orchestrazione dell’agente, strumenti e azioni, memoria e stato. Nella sua matrice delle responsabilità, nel caso PaaS il cliente mantiene le istruzioni e l’ambito dell’agente, i permessi per singolo strumento e l’approvazione umana per le azioni ad alto impatto, mentre runtime e piattaforma di orchestrazione spettano a Microsoft. [2]
La pagina elenca le responsabilità che un cliente mantiene sempre: dati, identità e privilegio minimo, autorizzazione delle azioni, supervisione umana, uso accettabile e governance. Afferma inoltre che l’autonomia non riduce mai la responsabilità. [2]
Cloud Security Alliance: una proposta del 2023
In un articolo del blog datato 28 luglio 2023, un fellow della CSA ha proposto un modello con tre parti: il fornitore del servizio IA, l’utente del servizio IA che costruisce un’applicazione, e l’impresa o l’utente finale di tale applicazione. Secondo la proposta, un fornitore IaaS mette a disposizione infrastruttura e modelli di base mentre l’utente si occupa di addestramento, validazione dei dati, filtraggio dei prompt e sicurezza applicativa; nel caso PaaS l’utente fornisce il contesto e la sicurezza applicativa; nel caso SaaS l’utente gestisce grounding, filtraggio dei prompt e tutela della proprietà intellettuale. L’articolo presenta questo schema come una proposta che separa i compiti, non come uno standard. [3]
Il diritto: l’AI Act dell’UE ripartisce gli obblighi per ruolo
L’AI Act dell’UE assegna gli obblighi per ruolo. Secondo le FAQ sulle linee guida della Commissione europea, un fornitore di un modello di IA per finalità generali è il soggetto che sviluppa il modello, o lo fa sviluppare, e lo immette sul mercato con il proprio nome. Gli obblighi del fornitore comprendono documentazione tecnica, documentazione per gli sviluppatori a valle su capacità e limiti, una politica di conformità al diritto d’autore e una sintesi pubblica dei contenuti di addestramento. Questi obblighi si applicano dal 2 agosto 2025. I modelli presunti a rischio sistemico, pari o superiori a 10^25 operazioni in virgola mobile di calcolo di addestramento, hanno obblighi ulteriori, tra cui test avversariali e misure di cybersicurezza. [4]
Le stesse FAQ indicano il 2 agosto 2026 come data da cui l’applicazione delle norme, sanzioni comprese, si estende a questi fornitori, e il 2 agosto 2027 come scadenza per i modelli immessi sul mercato prima del 2 agosto 2025. Precisano inoltre che uno sviluppatore a valle che modifica un modello diventa fornitore solo in circostanze eccezionali, come l’uso di più di un terzo del calcolo di addestramento originale, per cui la maggior parte delle attività di fine-tuning non sposta il ruolo di fornitore. [4]
I deployer, ossia le organizzazioni che utilizzano sistemi di IA, hanno un insieme distinto di obblighi. Un’analisi di uno studio legale datata 24 luglio 2026 elenca tra gli obblighi dei deployer dal 2 agosto 2026 la segnalazione dei deepfake e l’informativa alle persone sul riconoscimento delle emozioni e sulla categorizzazione biometrica. Per i sistemi ad alto rischio elenca una supervisione umana competente, l’informativa alle persone sull’uso dell’IA e la consultazione dei lavoratori. [6] La pagina della Commissione sul calendario aggiunge che i deployer devono garantire supervisione umana e monitoraggio e segnalare gli incidenti gravi una volta che i sistemi sono sul mercato. [5]
Il rinvio del Digital Omnibus
Le scadenze per l’alto rischio sono state spostate. La pagina della Commissione sul calendario indica il 2 dicembre 2027 per i sistemi ad alto rischio in ambiti sensibili come biometria, occupazione e attività di contrasto, e il 2 agosto 2028 per i sistemi ad alto rischio integrati in prodotti regolamentati, e ne attribuisce l’origine al Digital Omnibus sull’IA, che descrive come entrato in vigore a luglio 2026. [5] L’analisi di Norton Rose Fulbright riporta le stesse due date e afferma che l’Omnibus è stato pubblicato nella raccolta normativa dell’UE. [6] Due fonti indipendenti concordano quindi sul fatto che il rinvio è stato adottato e non soltanto proposto. Gli obblighi dei fornitori di modelli per finalità generali e gli obblighi di trasparenza descritti sopra non sono spostati da queste due date.
Suddividere il lavoro quando un modello è usato tramite API
Per il caso PaaS, in cui un’applicazione richiama un modello ospitato, le fonti supportano la suddivisione seguente. Le righe relative a Microsoft seguono i livelli di piattaforma e applicazione descritti sopra; le righe su test dei rischi di frontiera, documentazione del sistema e canali di segnalazione riflettono gli obblighi del fornitore nelle linee guida dell’UE e le pratiche pubblicate dai fornitori di modelli. La tabella è una sintesi di FireAI, non un testo tratto da alcuna delle fonti.
| Ambito | Lato fornitore | Lato tuo |
|---|---|---|
| Comportamento del modello | Addestramento alla sicurezza e allineamento del modello | Prompt di sistema e protezioni applicative |
| Test dei rischi | Test dei rischi di frontiera del modello stesso | Test della tua applicazione, compresi prompt, dati e strumenti |
| Piattaforma | Sicurezza della piattaforma e filtri di base su input e output | Controlli di sicurezza applicativi su contenuti, plugin e connettori |
| Documentazione | System card e documentazione per gli sviluppatori a valle | Leggerla e registrare quale modello e quale versione hai distribuito |
| Dati e strumenti | Nulla oltre al contratto API | Dati RAG, strumenti, agenti e relativi permessi |
| Output | Restituisce testo generato | Gestione a valle dell’output: validazione, escaping, approvazione umana |
| Operatività | Canale di segnalazione delle vulnerabilità del modello | Registrazione, monitoraggio e risposta agli incidenti per l’applicazione |
| Persone | Condizioni della politica d’uso | La tua politica d’uso e la formazione degli utenti |
Due ambiti sono condivisi in senso stretto. Il primo è la prompt injection: il fornitore addestra il modello a resistere alle istruzioni iniettate, e il deployer limita ciò che un’istruzione iniettata può ottenere tramite i permessi degli strumenti e l’accesso ai dati. La pagina di Microsoft sugli agenti descrive la stessa suddivisione, indicando ai clienti di trattare come non fidati i contenuti recuperati, gli output degli strumenti e i messaggi di altri agenti, e di sottoporre a controllo le azioni ad alto impatto. [2] Il secondo è la riservatezza dei dati: il fornitore stabilisce le condizioni di conservazione e di addestramento, e il deployer decide quali dati entrano in un prompt o in un indice di recupero.
Raccomandazioni
- Identificare prima il tipo di distribuzione (SaaS, PaaS o self-hosted) e annotare quali righe della suddivisione precedente spettano all’organizzazione.
- Testare direttamente il lato del deployer: prompt di sistema, dati di recupero, permessi degli strumenti e gestione dell’output. I test del fornitore sul modello non li coprono.
- Prima di adottare un modello, leggere la system card del fornitore e le sue condizioni di conservazione dei dati e di addestramento, e individuarne il canale di segnalazione delle vulnerabilità.
- Limitare ciò che un’istruzione iniettata può fare: strumenti con privilegio minimo, accesso ai dati circoscritto e approvazione umana per le azioni irreversibili.
- Stabilire quali dati possono entrare nei prompt e conservare registri sufficienti a ricostruire un incidente.
- Per materiale didattico su framework e red teaming, si veda il corso della FireAI University su framework di sicurezza dell’IA e red teaming.
Rilevanza per FireAI
Un’app o un agente locale che richiama l’API di un modello è un’app sul Mac, e le sue destinazioni sono visibili a FireAI. Attività elenca quali app sono andate online, e le Regole consentono a un utente di permettere o bloccare un’app o una destinazione specifica. Si tratta di un controllo sul lato del deployer, su un singolo Mac. FireAI non ispeziona i prompt, non valuta l’output dei modelli, non rileva la prompt injection e non stabilisce se un fornitore rispetti obblighi di legge.
Limiti
- Le pagine di Microsoft sono indicazioni di un fornitore per i prodotti Azure, si definiscono illustrative e non modificano le condizioni contrattuali. Il testo della CSA è una proposta del 2023.
- Questa nota non costituisce consulenza legale. Che un’organizzazione sia un fornitore, un deployer o un operatore ad alto rischio ai sensi dell’AI Act dipende da fatti che questa nota non valuta, e le autorità nazionali possono interpretare il regolamento in modo diverso.
- Le date del Digital Omnibus provengono dalla pagina della Commissione sul calendario e da un’analisi di uno studio legale. Il testo del regolamento stesso non è stato esaminato per questa nota.
- La tabella sulle API è una sintesi, e i singoli fornitori collocano alcune righe in modo diverso nelle loro condizioni.
Il ruolo di FireAI e di HisnLabs
Dalla tua parte della linea c’è anche ciò che lascia il Mac. FireAI lo mostra e ti lascia decidere.
FireAI è il prodotto di HisnLabs: un firewall con IA che funziona direttamente sul Mac. Mostra in linguaggio chiaro ogni connessione che le tue app effettuano e ti lascia decidere cosa esce dal tuo Mac — la sua IA lavora in locale, quindi il tuo traffico non viene mai inviato a noi né a nessun altro. Il team di ricerca sulla sicurezza di HisnLabs è quello che mantiene affidabili queste decisioni: cataloga quali domini sono semplice telemetria e quali un servizio reale, traccia il Paese e la rete dietro una connessione e addestra il modello locale (la funzione FireAI Pilot) su schemi di traffico reali, senza che nulla lasci il tuo Mac.
Puoi leggere le scelte tecniche che ci stanno dietro, oppure provare FireAI per 17 giorni, su FireAI, di HisnLabs.