Agenti AI e responsabilità: chi controlla l'intelligenza artificiale? Chi risponde delle sue azioni?

In breve

In breve

• Un agente AI non si limita a produrre informazioni: può compiere operazioni con conseguenze economiche, tecniche, organizzative o giuridiche dirette.
• Dal 12 ottobre 2026 i Service Specific Terms di Google Cloud (sezione 20(n)) dichiarano il cliente "solely responsible" per ogni azione agentica, mentre le linee guida di Google riconoscono i rischi operativi degli agenti.
• Una clausola contrattuale da sola non risolve la questione: contano il contratto completo, la legge applicabile, i fatti e le prove disponibili.
• I primi precedenti riguardano soprattutto chatbot, privacy e accessi automatizzati. L'unica decisione direttamente sugli agenti, Amazon contro Perplexity, ha una portata circoscritta.
• In Europa l'AI Act non è un regime generale di responsabilità civile, e la direttiva sui prodotti difettosi, che include il software, deve essere recepita entro il 9 dicembre 2026.
• La tesi di MC Project Lab è che la responsabilità vada valutata sul controllo effettivo, sulla condotta, sulla prevedibilità del rischio e sul contributo causale al danno. Le misure pratiche per le imprese sono nella sezione 19.

Sintesi

Executive summary

Il mercato dell'intelligenza artificiale sta cambiando in modo sostanziale. I sistemi AI non si limitano più a generare testi, immagini, analisi e codice: gli agenti possono usare strumenti, accedere a sistemi, modificare dati, eseguire programmi, avviare operazioni e coordinare altri agenti. Il passaggio dall'AI generativa all'AI agentica modifica il rapporto tra fornitori tecnologici, imprese e utilizzatori, perché l'errore di un chatbot produce un'informazione inesatta, le cui conseguenze dipendono da come viene usata, mentre l'errore di un agente può provocare direttamente una conseguenza economica, tecnica, organizzativa o giuridica.

Ne discende una domanda precisa.

Quando un agente AI compie un'azione dannosa, inattesa o non autorizzata, chi ne risponde?

Può rispondere il produttore del modello, il fornitore della piattaforma, lo sviluppatore dell'applicazione, l'impresa che usa il sistema oppure l'utente che ha impartito le istruzioni, e in molti casi la risposta coinvolge più soggetti insieme.

L'aggiornamento delle condizioni di Google Cloud del 12 ottobre 2026 rende il problema particolarmente visibile. Nelle proprie linee guida Google riconosce i rischi operativi degli agenti, ma nelle condizioni contrattuali specifiche attribuisce al cliente una responsabilità ampia per le loro azioni. Il fenomeno riguarda l'intero mercato, da OpenAI ad Anthropic, da Microsoft ad Amazon Web Services, da Meta a Mistral AI e a numerosi altri operatori. Intanto autorità e tribunali cominciano a occuparsi di controversie su informazioni generate dall'AI, protezione dei dati, accessi automatizzati e conseguenze dell'uso di sistemi autonomi.

La tesi di MC Project Lab è che la responsabilità debba essere valutata considerando il controllo effettivo, la condotta dei soggetti coinvolti, la prevedibilità dei rischi e il contributo causale al danno. È una posizione editoriale e di governance, non una regola giuridica universale già consolidata.

Il dossier esamina in dettaglio il caso di Google Cloud, di cui è stato letto il testo contrattuale originale. Per gli altri fornitori descrive il quadro generale e rinvia alle condizioni indicate nelle fonti, che vanno lette per intero prima di prendere una decisione.

1Dall'AI generativa agli agenti autonomi

1.1 La trasformazione

La prima fase commerciale dell'AI generativa è stata caratterizzata dalla produzione di contenuti. La fase attuale introduce sistemi capaci di compiere operazioni. Un chatbot può spiegare come modificare un documento, mentre un agente può modificarlo direttamente. Un modello può suggerire come aggiornare un database, mentre un agente può collegarsi al sistema ed eseguire l'aggiornamento. Un assistente può proporre una strategia commerciale e un agente può interagire con gli strumenti aziendali per realizzarne alcune attività.

L'AI può quindi produrre conseguenze operative, oltre a informazioni.

1.2 I livelli di autonomia

Gli agenti si possono descrivere secondo il loro grado di autonomia.

• Agenti assistiti: propongono operazioni che richiedono conferma umana.
• Agenti semi-autonomi: eseguono attività entro autorizzazioni e limiti predefiniti.
• Agenti autonomi: pianificano ed eseguono sequenze di operazioni senza una conferma per ogni passaggio.
• Sistemi multi-agente: coordinano più componenti AI con ruoli, strumenti e responsabilità operative differenti.

Queste categorie hanno valore descrittivo e non sono classificazioni giuridiche uniformi.

1.3 Le conseguenze economiche

L'autonomia crea opportunità di produttività e di innovazione, ma porta con sé rischi legati a costi inattesi, operazioni indesiderate, dipendenza dai fornitori e difficoltà di supervisione. Il controllo delle autorizzazioni e delle risorse diventa quindi parte integrante della gestione economica del servizio.

2La catena del valore e delle responsabilità

Nel mercato operano soggetti che si collocano su livelli differenti, e la tabella mostra i principali.

Un incidente può coinvolgere più livelli contemporaneamente, e una catena tecnologica così articolata obbliga a distinguere il contributo di ciascun soggetto. Attribuire in anticipo ogni responsabilità al produttore oppure all'utilizzatore non sarebbe corretto, perché la valutazione dipende dai fatti, dagli obblighi applicabili e dalle evidenze disponibili.

3Perché i fornitori modificano i contratti

L'autonomia degli agenti aumenta il rischio che i servizi AI provochino conseguenze dirette. I contratti cercano di regolare in anticipo gli obblighi delle parti e di distribuire i rischi, e per capirli occorre distinguere quattro concetti.

• Responsabilità contrattuale: le conseguenze della violazione di obblighi assunti.
• Responsabilità extracontrattuale: le conseguenze dei fatti illeciti secondo la normativa applicabile.
• Manleva: l'obbligo, nei limiti previsti, di tenere indenne un soggetto da determinate pretese o conseguenze.
• Limitazione di responsabilità: la clausola che delimita categorie o importi dei danni risarcibili, nei limiti consentiti dalla legge.

Questi strumenti non sono equivalenti. Una manleva sulla proprietà intellettuale non è automaticamente una copertura per i danni provocati da un agente, e una clausola che attribuisce obblighi al cliente non dimostra che qualsiasi incidente sia imputabile alla sua condotta.

Caso centrale

4Google Cloud: il caso centrale

4.1 L'aggiornamento del 12 ottobre 2026

Google Cloud ha aggiornato le proprie condizioni e ha introdotto linee guida dedicate all'uso responsabile degli agenti AI. Per capire la portata delle modifiche bisogna tenere distinti due documenti, le linee guida e la clausola contrattuale.

4.2 Le linee guida

Le Google Cloud Agentic AI Responsible Use Guidelines trattano i rischi di sicurezza, privacy, accessi non autorizzati, uso degli strumenti e comportamenti inattesi. Google vi riconosce che gli agenti possono agire in modo diverso dalle istruzioni ricevute e possono essere vulnerabili ad attacchi esterni, compresa la prompt injection. Raccomanda con forza la supervisione umana e meccanismi di approvazione esplicita, in particolare per le decisioni e le azioni critiche o rilevanti nelle conseguenze. Le linee guida si presentano come indicazioni non esaustive, pensate per allineare l'uso degli agenti all'Acceptable Use Policy, alla policy sugli usi vietati dell'AI generativa e ai Terms of Service. La clausola che attribuisce la responsabilità al cliente non si trova in questo documento ma nei Service Specific Terms.

Fonte: https://cloud.google.com/terms/agentic-ai-use-guidelines

4.3 La clausola contrattuale

La sezione 20(n) dei Google Cloud Service Specific Terms, dedicata agli Agentic AI Services, stabilisce che il cliente è "solely responsible" per quattro ambiti.

1. Ogni Agentic AI Action.
2. La valutazione dell'idoneità dell'agente o del servizio rispetto all'uso previsto.
3. L'autorizzazione degli accessi a dati, applicazioni e sistemi.
4. L'esercizio del giudizio e della supervisione negli ambienti di produzione, per evitare potenziali danni.

La disposizione regola anche le conseguenze della disattivazione o dell'aggiramento delle salvaguardie che richiedono conferma umana. È un'allocazione contrattuale espressa nei rapporti disciplinati da quei termini, e al 23 ottobre 2026 sia questa pagina sia le linee guida riportano come ultima modifica il 12 ottobre 2026. La sua applicazione e i suoi limiti vanno valutati sul contratto completo, nella versione applicabile e alla luce della normativa pertinente, e la clausola da sola non dimostra che Google sia esonerata da ogni responsabilità prevista dalla legge.

Fonte: https://cloud.google.com/terms/service-terms

4.4 La questione critica

Google riconosce che gli agenti possono comportarsi in modo inatteso e, allo stesso tempo, attribuisce al cliente obblighi contrattuali molto ampi. Il problema emerge quando un danno dipende da più fattori, tra cui eventuali difetti del servizio, il comportamento del modello, le configurazioni dell'applicazione e le autorizzazioni concesse. La responsabilità non si ricostruisce correttamente guardando una sola clausola isolata dal contesto.

4.5 Valutazione di MC Project Lab

Il riconoscimento esplicito dei rischi operativi è un aspetto positivo. L'aspetto critico è l'ampiezza della responsabilità che il contratto attribuisce al cliente. Riconoscere un rischio tecnologico è cosa diversa dal trasferirne per contratto le conseguenze.

5OpenAI: obblighi, garanzie e limiti

OpenAI fornisce modelli e servizi attraverso applicazioni, API e soluzioni commerciali. L'OpenAI Services Agreement disciplina determinati rapporti con le aziende e con gli sviluppatori.

5.1 Obblighi del cliente

Il contratto attribuisce al cliente la responsabilità per gli input e per l'uso degli output, compresa la valutazione della loro adeguatezza.

5.2 Manleve

Sono previste protezioni per determinate pretese di terzi, comprese alcune controversie sulla proprietà intellettuale. Queste protezioni sono soggette a condizioni ed esclusioni e non costituiscono una garanzia generale contro ogni danno provocato da agenti autonomi.

5.3 Limitazioni di responsabilità

Il contratto prevede limitazioni economiche ed esclusioni, con specifiche eccezioni. La loro applicazione concreta dipende dalla versione del contratto e dalle circostanze.

5.4 Valutazione

La questione centrale è distinguere gli obblighi del fornitore da quelli dello sviluppatore e dell'impresa che integra il modello in un'applicazione operativa.

Fonti: https://openai.com/policies/services-agreement/
https://openai.com/policies/service-terms/

6Anthropic: Claude e l'autonomia operativa

Anthropic distribuisce Claude attraverso prodotti, API e strumenti differenti, e il quadro contrattuale varia secondo il servizio e il rapporto commerciale applicabile. L'uso di agenti introduce rischi legati all'esecuzione di codice, alla gestione dei file e all'accesso a risorse esterne. Per questo occorre distinguere il comportamento del modello, le funzionalità del servizio, le autorizzazioni dell'utilizzatore e le integrazioni sviluppate da terzi.

L'esistenza di misure tecniche di sicurezza non equivale a una garanzia contrattuale assoluta, e allo stesso modo gli obblighi di configurazione dell'utilizzatore non escludono necessariamente quelli del fornitore. Un confronto conclusivo con Google o con OpenAI richiede l'esame delle condizioni applicabili a prodotti e clienti equivalenti.

Fonte: https://www.anthropic.com/legal

7Microsoft: Copilot, Azure e GitHub

Microsoft opera come fornitore di infrastrutture, piattaforme, applicazioni e strumenti di sviluppo AI. Le condizioni applicabili variano secondo il prodotto e non esiste un unico regime contrattuale valido per tutti i servizi Copilot, Azure e GitHub. Le organizzazioni devono gestire identità, accessi, autorizzazioni e configurazioni, mentre Microsoft conserva gli obblighi che derivano dai servizi forniti e dai contratti applicabili.

Il modello di responsabilità condivisa è uno strumento organizzativo utile, ma non stabilisce da solo chi debba risarcire un danno.

Fonti: https://www.microsoft.com/licensing/terms/
https://www.microsoft.com/servicesagreement
https://github.com/customer-terms

8Amazon Web Services: Bedrock e agenti multi-fornitore

AWS fornisce infrastrutture e servizi per sviluppare applicazioni AI. Un'applicazione può usare nello stesso momento modelli di terzi, servizi cloud e strumenti sviluppati dal cliente. Il modello di responsabilità condivisa distingue da sempre gli obblighi infrastrutturali da quelli relativi a dati, applicazioni e configurazioni, e l'AI agentica rende più complessa questa distribuzione, perché un incidente può dipendere da componenti di fornitori differenti.

La responsabilità condivisa non determina da sola l'attribuzione giuridica del danno.

Fonti: https://aws.amazon.com/agreement/
https://aws.amazon.com/service-terms/

9Meta: modelli open-weight e controllo tecnologico

Meta distribuisce i modelli Llama e sviluppa servizi AI. I modelli open-weight permettono modalità di esecuzione e personalizzazione diverse rispetto ai servizi disponibili solo tramite API, e un'organizzazione può ottenere più controllo sull'infrastruttura e sulle integrazioni. Questo può ridurre alcune dipendenze, ma aumenta anche gli obblighi di gestione operativa. Open-weight inoltre non significa assenza di restrizioni contrattuali.

Un maggiore controllo tecnico non equivale necessariamente a una maggiore tutela giuridica.

Fonti: https://www.llama.com/
https://www.meta.ai/

10Mistral AI: il fornitore europeo

Mistral AI è uno degli operatori europei più significativi nel mercato dei modelli linguistici. Le sue condizioni commerciali possono disciplinare obblighi di utilizzo, garanzie, manleve e limitazioni di responsabilità, con una portata che dipende dal prodotto e dal contratto applicabile. La sede europea del fornitore non garantisce automaticamente condizioni più favorevoli, e per questo Mistral va esaminata con gli stessi criteri adottati per gli operatori statunitensi.

Fonte: https://legal.mistral.ai/terms/commercial-terms-of-service/

11Gli altri operatori globali

Il mercato comprende molti altri operatori. Ci sono produttori di modelli come xAI, DeepSeek e Cohere, operatori cloud e di modelli come Alibaba Cloud (con Qwen), Tencent e Baidu, e fornitori di infrastrutture e software come NVIDIA, IBM, Oracle e Salesforce, che propone Agentforce. Ci sono poi servizi che distribuiscono o aggregano modelli, come Hugging Face e OpenRouter, e applicazioni agentiche come Perplexity e Cursor. La loro presenza in questo elenco non significa che siano state verificate le condizioni contrattuali di ciascuno: per questi operatori il dossier offre un inquadramento del mercato e non un'analisi contrattuale.

12Confronto dei modelli contrattuali

La tabella mette a confronto l'elemento centrale di ciascun fornitore e la cautela con cui va letto.

Il dossier non assegna alcun punteggio di affidabilità contrattuale. Una graduatoria richiederebbe il confronto sistematico di clausole equivalenti, nelle versioni effettivamente applicabili.

13I rischi operativi degli agenti

Le principali categorie di rischio sono sette.

1. Azioni non autorizzate: operazioni che superano le intenzioni dell'utilizzatore.
2. Prompt injection: tentativi di alterare il comportamento dell'agente attraverso contenuti esterni.
3. Accessi eccessivi: privilegi superiori a quelli necessari.
4. Modifiche irreversibili: cancellazioni, trasferimenti o alterazioni difficilmente recuperabili.
5. Costi inattesi: consumo di risorse e servizi.
6. Dipendenze multi-fornitore: interazioni tra componenti appartenenti a soggetti differenti.
7. Difficoltà di ricostruzione: registrazioni insufficienti per capire che cosa sia accaduto.

Questi rischi non implicano che ogni agente sia insicuro, ma indicano che l'autonomia richiede controlli proporzionati alle conseguenze possibili.

14Il quadro normativo europeo

14.1 AI Act

Il Regolamento (UE) 2024/1689 introduce obblighi differenziati secondo il ruolo degli operatori, la natura dei sistemi e i rischi associati. Non ogni agente AI è automaticamente un sistema ad alto rischio, e l'AI Act non è, da solo, una disciplina generale della responsabilità civile per i danni provocati da agenti autonomi. Le disposizioni e le date di applicazione vanno verificate sul quadro normativo vigente.

Fonte: https://eur-lex.europa.eu/eli/reg/2024/1689/oj

14.2 Responsabilità per prodotti difettosi

La Direttiva (UE) 2024/2853 aggiorna il quadro europeo della responsabilità per prodotti difettosi e include il software. Gli Stati membri devono adottare le disposizioni di recepimento entro il 9 dicembre 2026, e alla data del dossier quel termine non è ancora scaduto. Il nuovo regime riguarda i prodotti immessi sul mercato o messi in servizio dopo il 9 dicembre 2026, secondo le disposizioni temporali previste. La responsabilità richiede la verifica dei presupposti applicabili, tra cui difetto, danno e nesso causale, e non deriva automaticamente dal semplice impiego di AI.

Fonte: https://eur-lex.europa.eu/eli/dir/2024/2853/oj

14.3 GDPR

Il Regolamento (UE) 2016/679 disciplina il trattamento dei dati personali. L'uso di agenti può coinvolgere obblighi di liceità, trasparenza, sicurezza e responsabilizzazione, e l'autonomia del sistema non elimina gli obblighi dei soggetti individuati dalla normativa.

Fonte: https://eur-lex.europa.eu/eli/reg/2016/679/oj

14.4 Cyber Resilience Act

Il Regolamento (UE) 2024/2847 introduce requisiti di cybersicurezza per i prodotti con elementi digitali che rientrano nel suo ambito. La sua applicabilità ai prodotti AI dipende dalle caratteristiche del prodotto e dalle condizioni previste dal regolamento.

Fonte: https://eur-lex.europa.eu/eli/reg/2024/2847/oj

14.5 Contratti e norme inderogabili

Le clausole contrattuali vanno interpretate alla luce delle norme applicabili. Una limitazione di responsabilità non può essere considerata valida o invalida in automatico, senza esaminare il rapporto giuridico concreto.

15Giurisprudenza: Italia e mondo

15.7 Confronto dei precedenti

15.8 Cosa emerge

I precedenti non stabiliscono una regola universale sulla responsabilità degli agenti. Mostrano però che le informazioni generate dall'AI, il trattamento dei dati e le operazioni automatizzate possono essere oggetto di controversie e di interventi delle autorità. Le conclusioni devono restare circoscritte alle norme e ai fatti esaminati.

16Il problema della prova

Per attribuire una responsabilità bisogna poter ricostruire gli eventi, e le evidenze potenzialmente rilevanti sono dieci.

1. Istruzioni ricevute.
2. Contenuti consultati.
3. Strumenti utilizzati.
4. Autorizzazioni disponibili.
5. Approvazioni richieste e ricevute.
6. Operazioni effettivamente eseguite.
7. Risposte dei sistemi esterni.
8. Errori e anomalie.
9. Modifiche apportate.
10. Versioni dei componenti coinvolti.

Non tutti i sistemi conservano queste informazioni, e la mancanza di registrazioni affidabili può rendere difficile distinguere un errore del modello da una configurazione impropria o da un attacco esterno. La verificabilità delle azioni è una condizione importante per accertare le responsabilità.

17Le asimmetrie del mercato

17.1 Tecnologica

I fornitori possono disporre di informazioni sul funzionamento dei modelli che gli utilizzatori non possono vedere.

17.2 Contrattuale

Molti servizi sono distribuiti con condizioni predisposte unilateralmente, e le imprese più piccole possono avere una capacità negoziale limitata.

17.3 Economica

Le conseguenze di un incidente possono pesare in modo molto diverso sui soggetti coinvolti.

17.4 Probatoria

Le informazioni necessarie a ricostruire un incidente possono essere distribuite tra più fornitori.

17.5 Operativa

Modifiche ai modelli, alle API, ai prezzi e alle condizioni possono incidere su applicazioni già integrate nei processi aziendali.

Queste asimmetrie non rendono illegittimi i contratti in automatico, ma sono elementi rilevanti per valutare l'equilibrio del mercato.

18Verso una responsabilità più equilibrata

MC Project Lab propone cinque principi.

18.1 Responsabilità proporzionata al controllo

Ogni soggetto dovrebbe assumere responsabilità coerenti con il proprio ruolo e con il controllo che esercita davvero.

18.2 Trasparenza delle limitazioni

I fornitori dovrebbero comunicare in modo comprensibile rischi, limiti e condizioni delle garanzie.

18.3 Tracciabilità delle azioni

Le operazioni degli agenti dovrebbero poter essere ricostruite con evidenze proporzionate al rischio e compatibili con la normativa sulla protezione dei dati.

18.4 Supervisione proporzionata

Le operazioni critiche dovrebbero prevedere autorizzazioni e controlli adeguati alla gravità delle possibili conseguenze.

18.5 Equilibrio contrattuale

Le condizioni dovrebbero permettere ai clienti di capire quali rischi assumono, quali garanzie ricevono e quali eventi restano esclusi.

Questi principi sono una proposta di governance e non un elenco di obblighi giuridici universalmente vigenti.

In pratica

19Cosa può fare un'impresa oggi

Le indicazioni che seguono derivano da quanto emerge nelle sezioni precedenti e non sono un parere legale. Servono a ridurre il rischio e a mantenere la possibilità di ricostruire i fatti, qualunque sia poi la ripartizione delle responsabilità.

1. Leggere la clausola prima di attivare l'agente. Nel contratto del fornitore vanno individuate le parti che riguardano le azioni dell'agente, le manleve e le limitazioni di responsabilità, annotando la versione e la data di consultazione. Nel caso di Google Cloud si tratta della sezione 20(n) dei Service Specific Terms.
2. Concedere solo i permessi necessari. L'accesso a dati, applicazioni e sistemi dovrebbe essere limitato a ciò che serve al compito, anche perché il contratto di Google attribuisce al cliente l'autorizzazione di quegli accessi.
3. Mantenere la conferma umana sulle operazioni critiche. Le linee guida di Google raccomandano l'approvazione esplicita per le azioni critiche, e il contratto pone sul cliente la responsabilità di disattivare o aggirare le salvaguardie. Conviene quindi non disattivarle senza una decisione consapevole e documentata.
4. Valutare l'idoneità dell'agente prima dell'uso reale. L'agente andrebbe provato in un ambiente separato dalla produzione, perché il contratto assegna al cliente la valutazione dell'idoneità e la supervisione negli ambienti di produzione.
5. Registrare che cosa fa l'agente. Istruzioni ricevute, strumenti usati, autorizzazioni, approvazioni, operazioni eseguite, errori e versioni dei componenti (sezione 16), nel rispetto della normativa sulla protezione dei dati.
6. Limitare costi e operazioni irreversibili. Soglie di spesa e conferma obbligatoria per cancellazioni, trasferimenti e modifiche difficili da recuperare (sezione 13).
7. Sapere chi risponde nella catena. Mappare fornitori, integratori e sviluppatori (sezione 2) e leggere che cosa dice il contratto di ciascuno. Per i dati personali vanno verificati gli obblighi del GDPR, e per un caso concreto conviene rivolgersi a un legale.

Nessuna di queste misure sposta per legge la responsabilità. Ciascuna rafforza però la posizione di chi dovrà dimostrare di aver controllato ciò che era in suo potere controllare.

Conclusione

20Conclusioni

L'AI agentica sta cambiando il rapporto tra capacità tecnologica e responsabilità. I fornitori sviluppano sistemi capaci di operazioni sempre più complesse, le imprese li usano per attività via via più importanti, i contratti cercano di distribuire in anticipo i rischi e le norme e i tribunali affrontano problemi nuovi.

Più che individuare un unico soggetto a cui attribuire ogni conseguenza, occorre ricostruire chi ha controllato le componenti coinvolte, quali obblighi erano applicabili, quali condotte hanno contribuito all'evento e quali evidenze permettono di dimostrarlo. La responsabilità che il contratto attribuisce al cliente non dimostra che ogni incidente sia causato dal cliente, e l'autonomia del sistema non dimostra che ogni danno sia imputabile al produttore.

La posizione di MC Project Lab è che una distribuzione equilibrata delle responsabilità debba considerare il controllo effettivo, le condotte, la prevedibilità del rischio e il contributo causale al danno. È una tesi editoriale e di governance, non una regola giuridica universalmente consolidata.

La maturità del mercato AI dipenderà non solo dalla capacità degli agenti di eseguire operazioni, ma anche dalla possibilità di comprenderne il funzionamento, verificarne le azioni e attribuire correttamente le responsabilità.

La domanda finale

Se un'azienda commercializza un'intelligenza artificiale capace di agire autonomamente, fino a che punto può attribuire al cliente la responsabilità delle azioni che quella tecnologia compie?

Non esiste ancora una risposta unica e universalmente applicabile, e la domanda ha ormai conseguenze pratiche. L'autonomia tecnologica non dovrebbe tradursi in irresponsabilità giuridica.

Glossario

• Agente AI: sistema o flusso di lavoro orientato a un obiettivo che esegue azioni o compiti per conto dell'utente, in modo supervisionato o autonomo.
• Agentic AI Action: nei termini di Google Cloud, qualsiasi azione o omissione di un servizio o di un agente AI, o attribuibile a essi, compresa l'esecuzione di compiti e interazioni e le mancate esecuzioni.
• Prompt injection: istruzioni nascoste in contenuti esterni, come pagine web, documenti o messaggi, che spingono l'agente a comportarsi in modo non voluto.
• Manleva: impegno a tenere indenne un soggetto da determinate pretese o conseguenze, nei limiti previsti dal contratto.
• Open-weight: modello di cui sono pubblicati i parametri, che può essere scaricato ed eseguito in proprio, con una licenza che può comunque porre restrizioni.
• Nesso causale: legame tra un comportamento e il danno, necessario per poter attribuire una responsabilità.
• Ambiente di produzione: ambiente reale in cui i sistemi operano su dati e processi veri, a differenza degli ambienti di prova.
• Registro delle operazioni (log): traccia delle azioni compiute da un sistema, utile a ricostruire che cosa è accaduto.
• Ingiunzione preliminare: decisione provvisoria del giudice, presa prima della sentenza finale, per evitare o far cessare un danno nel frattempo.

Nota metodologica

Il dossier distingue quattro tipi di contenuto. I fatti documentati sono informazioni ricavate da fonti normative, contrattuali, istituzionali e giudiziarie. Le interpretazioni giuridiche sono analisi circoscritte ai fatti e alle norme disponibili. La tesi editoriale raccoglie le valutazioni indipendenti di MC Project Lab sull'equilibrio delle responsabilità. Le fonti contrattuali hanno come data di riferimento della consultazione il 23 ottobre 2026: le condizioni pubblicate online possono cambiare e la data di consultazione non coincide necessariamente con quella di efficacia del contratto.

Per una controversia concreta occorre identificare la versione contrattuale applicabile, il servizio utilizzato e la giurisdizione competente. Alcuni contratti dei fornitori secondari e alcuni precedenti internazionali non sono stati esaminati per intero: il dossier dichiara questi limiti e non presenta come accertate conclusioni che le fonti disponibili non consentono.

Il 23 ottobre 2026 sono stati riletti direttamente i Service Specific Terms e le linee guida di Google Cloud, la decisione del Ninth Circuit, i comunicati del Garante e dell'AGCM e la sintesi sul caso OLG Hamm. Per gli altri fornitori il dossier descrive il quadro generale e rinvia alle condizioni indicate nelle fonti.

Il presente documento è un'analisi indipendente e non un parere legale.

MC PROJECT LAB

DOSSIER 001, edizione consolidata del 23 ottobre 2026