IA in SaaS e cloud: chi si assume il rischio secondo i contratti

Le aziende usano sempre più l’intelligenza artificiale generativa come servizio: un abbonamento a ChatGPT, le funzioni Copilot dentro Microsoft 365, un’API integrata in un’applicazione interna. Un approfondimento giuridico pubblicato da ICT Security Magazine l’11 ottobre 2026 analizza come questi servizi vengano ricondotti ai contratti SaaS e cloud già esistenti e come i termini dei fornitori ripartiscano il rischio tra chi offre il servizio e chi lo usa. Su ARX News avevamo parlato dell’AI Act dal lato dei fornitori dei modelli, a proposito degli obblighi di notifica degli incidenti; qui il punto di vista è quello del cliente.

Questo articolo si basa su una sola fonte, un’analisi giuridica e non un avviso tecnico. Il testo che abbiamo potuto consultare tratta per esteso i termini di ChatGPT e si interrompe nella parte su Microsoft Copilot: per gli altri servizi citati, come Google Gemini, non riportiamo dettagli.

Il contesto: regole europee e contratti per adesione

Secondo ICT Security Magazine, il quadro europeo sull’IA punta su prevenzione del rischio, governance e ripartizione preventiva degli obblighi tra gli attori della filiera, ma lascia aperti diversi aspetti pratici, nei quali a decidere è il contratto. I modelli generativi non si comprano: il cliente ottiene un diritto d’uso limitato nel tempo e nelle modalità, mentre modello e infrastruttura restano al fornitore (il paradigma AI-as-a-Service, una forma di SaaS).

L’autore osserva che questi contratti sono spesso standard, predisposti da operatori esteri e di fatto non negoziabili, con effetti su rischi, responsabilità, dati e proprietà intellettuale. L’alternativa, un sistema sviluppato su misura con dataset scelti dal committente, dà più controllo (accesso a codice sorgente e algoritmi, possibilità di affidarsi ad altri sviluppatori) ma costa di più ed è meno diffusa.

Cosa prevedono i termini: il caso ChatGPT

Dall’analisi dei termini di OpenAI riportata dalla fonte emergono alcuni punti che interessano direttamente chi gestisce IT e sicurezza:

• Documenti da leggere insieme: termini di utilizzo, condizioni dei piani a pagamento (Plus, Team, Enterprise), informativa privacy e, per le aziende, il Data Processing Addendum (DPA).
• Dati in ingresso e in uscita: l’utente resta titolare degli input e riceve i diritti sugli output nei limiti della legge, senza garanzia di originalità. Nei piani per consumatori i contenuti possono essere usati per addestrare i modelli, salvo opt-out; nei piani enterprise, secondo la fonte, di norma no.
• Servizio “as is” e “as available”: nessuna garanzia su accuratezza, affidabilità, continuità o idoneità a uno scopo. L’utente è responsabile delle decisioni prese sulla base degli output e deve verificarli.
• Responsabilità limitata: un tetto al risarcimento legato a quanto pagato in un periodo (per esempio gli ultimi dodici mesi) o a una soglia fissa, ed esclusione dei danni indiretti, compresi perdita di dati, mancato guadagno e danni reputazionali.
• Manleva a carico dell’utente per gli usi illeciti; nei contratti business possono esserci tutele per il cliente, per esempio sulla proprietà intellettuale, entro limiti precisi.
• Usi vietati: reverse engineering ed estrazione del modello, sviluppo di sistemi concorrenti con gli output, impiego in ambiti ad alto rischio senza supervisione umana. La violazione può portare alla sospensione dell’account.
• Modifiche unilaterali: il fornitore può cambiare, sospendere o interrompere il servizio e aggiornare le condizioni con un preavviso.

Nei piani enterprise e nei contratti negoziati, sempre secondo la fonte, compaiono SLA con garanzie di disponibilità e service credits, tetti di responsabilità più alti e clausole più dettagliate su sicurezza e protezione dei dati. Con il DPA il cliente è titolare del trattamento dei dati che inserisce e il fornitore ne è responsabile. La conclusione dell’autore: il regime di responsabilità non è uniforme, ma dipende dal potere contrattuale del cliente.

La filiera: il caso Copilot

Per Microsoft la fonte descrive un ecosistema più stratificato: Copilot gratuito in Windows, Edge e Bing, Copilot Pro, Copilot for Microsoft 365 nelle applicazioni per l’ufficio e in Teams, GitHub Copilot per il codice e Copilot Studio per creare agenti. I modelli sono sviluppati da OpenAI e concessi in licenza a Microsoft, che li eroga dalla propria infrastruttura Azure: quando un utente usa Copilot in Word o Excel, il prompt arriva ai server Microsoft, che scelgono quale modello usare.

Per chi valuta il rischio delle terze parti, questo significa che dietro un solo contratto c’è una catena di fornitori. Il testo disponibile si ferma a questo punto.

Impatto per le aziende europee e italiane

L’analisi è giuridica, ma le conseguenze sono operative. Un servizio di IA che tratta documenti, codice o dati dei clienti è un fornitore ICT a tutti gli effetti. Per i soggetti NIS2 (in Italia il D.Lgs. 138/2024) la sicurezza della catena di approvvigionamento rientra nelle misure di gestione del rischio: termini “as is” con tetti di responsabilità bassi e senza SLA vanno trattati come un rischio residuo da valutare, non come un dettaglio legale. Dove passano dati personali, DPA e trasferimenti verso paesi terzi sono materia di GDPR; nella sanità, i dati sanitari inseriti in un prompt sono categorie particolari di dati.

Il punto più concreto è la differenza tra i piani: lo stesso servizio può avere regole opposte sull’uso dei dati per l’addestramento, a seconda che il dipendente usi un account personale o quello aziendale.

Cosa fare subito

1. Inventario: elenca i servizi di IA in uso, comprese le funzioni attivate dentro piattaforme già sotto contratto (suite per l’ufficio, ambienti di sviluppo), e il tipo di piano di ciascuno.
2. Account personali: stabilisci quali servizi sono autorizzati e con quali account; dove possibile consenti l’accesso solo con l’identità aziendale (SSO) e limita gli altri dal proxy.
3. Dati e addestramento: verifica nel contratto e nella console di amministrazione se input e output possono essere usati per l’addestramento, e documenta l’impostazione scelta.
4. DPA e sub-responsabili: controlla ruoli, misure di sicurezza, elenco dei sub-responsabili, luogo del trattamento e trasferimenti fuori dallo Spazio economico europeo.
5. Rischio contrattuale: confronta tetto di responsabilità, SLA e service credits con la criticità dei processi che dipendono dal servizio; per quelli critici negozia condizioni diverse o prevedi un’alternativa.
6. Verifica umana degli output: il contratto la mette a carico tuo. Rendila una regola scritta per le decisioni rilevanti, il codice generato e i testi destinati ai clienti.
7. Modifiche dei termini: affida a qualcuno il controllo delle comunicazioni dei fornitori e rivaluta il rischio quando cambiano condizioni o modelli.
8. Uscita: verifica come si recuperano e si cancellano i dati alla fine del contratto.

Come aiuta ARXDOME

Se i termini mettono a carico del cliente l’uso del servizio e le decisioni prese con i suoi output, servono prove di quello che è successo. ARX Sentry raccoglie in un unico punto i log di server e firewall, e ARX Retain li conserva per gli anni richiesti, su storage europeo con blocco degli oggetti e legal hold, pronti per un audit o per una contestazione con il fornitore.

Ultimo aggiornamento: 11 ottobre 2026