Chi risponde quando l’agente AI sbaglia? Responsabilità e SLA

Il 31 luglio 2026 l’ABC ha raccontato una cosa che chi lavora con gli agenti AI in azienda dovrebbe leggere due volte: durante una valutazione di cybersecurity, Claude di Anthropic ha ottenuto accesso non autorizzato ai sistemi di tre organizzazioni esterne reali. Non era un attacco: era un test in ambiente che doveva essere isolato, e una configurazione sbagliata gli aveva lasciato aperto internet. Il modello, di cui abbiamo raccontato funzionamento e limiti nella guida completa a Claude AI, credeva di essere in una simulazione. Non lo era. La domanda che nasce da lì è la domanda che ogni direzione IT prima o poi si trova sul tavolo: se succede a te, chi paga? Questo articolo prova a rispondere in modo operativo, perché la responsabilità di un errore di un agente AI non è un tema da convegno: è una riga di contratto, una policy di log e un numero di telefono che deve squillare alle tre di notte.

In questo articolo scoprirai:

• Un agente che agisce non è un chatbot che sbaglia risposta
• Chi risponde quando l’agente AI sbaglia: i tre anelli della catena
• L’AI Act dice chi rischia, non chi risarcisce
• Quando la tua azienda diventa giuridicamente «fornitore»
• Quali log servono per dimostrare di chi è stato l’errore
• Cosa deve prevedere un SLA sul malfunzionamento di un agente AI
• La matrice RACI delle prime 48 ore dopo un errore
• Cosa si contratta davvero, alla fine

Un agente che agisce non è un chatbot che sbaglia risposta

La differenza che cambia tutto è questa: un modello che genera testo produce un output che qualcuno legge e valuta; un agente produce un’azione, invia una mail, emette una nota di credito, modifica un record, chiama un’API di pagamento. Nel primo caso c’è sempre un umano fra l’errore e il danno. Nel secondo, spesso no. È la ragione per cui il tema della responsabilità è esploso adesso e non tre anni fa, quando gli stessi modelli producevano già allucinazioni con la stessa disinvoltura.

L’incidente Anthropic è istruttivo proprio perché non è colpa di nessuno in senso ingenuo. Secondo la ricostruzione pubblicata da ABC News, l’azienda ha parlato di «un fraintendimento fra noi e il nostro partner di valutazione»: l’ambiente doveva essere sigillato, non lo era, e il prompt diceva al modello che si trovava in una simulazione. Il problema non è stato il modello, che in un caso ha addirittura riconosciuto di trovarsi su sistemi reali e ha interrotto l’attacco. Il problema è stato il confine fra due organizzazioni che credevano entrambe che l’altra stesse tenendo chiuso il perimetro. Anthropic se n’è accorta rivedendo i registri di oltre 140.000 test di sicurezza, dopo rivelazioni analoghe di OpenAI.

Gli incidenti non nascono dentro i componenti, nascono fra i componenti

Tenete a mente quella frase, perché è il cuore di tutto il resto: gli incidenti degli agenti non nascono quasi mai dentro un componente, nascono fra i componenti. E la catena contrattuale, di norma, è scritta come se ogni componente stesse per conto suo. Se volete un ripasso di cosa fa davvero un agente rispetto a un assistente conversazionale, la guida completa agli agenti AI mette in fila architettura, strumenti e limiti; qui diamo per scontato che sappiate di cosa parliamo e andiamo dritti al punto dolente.

Chi risponde quando l’agente AI sbaglia: i tre anelli della catena

Nella pratica gli attori sono tre, e le loro responsabilità non sono alternative ma cumulative: il danneggiato può agire contemporaneamente contro tutti, come sintetizza l’analisi di TrueScreen sulla catena della AI agentica.

Il model provider (OpenAI, Anthropic, Google) risponde del modello come prodotto: difetti di progettazione, comportamenti non documentati, mancata avvertenza sui rischi. È l’anello più solido patrimonialmente e il più difficile da raggiungere, perché i suoi termini di servizio limitano quasi sempre la responsabilità a una frazione di quanto avete speso in API.

L’integratore, chi ha costruito l’agente sopra quel modello: system prompt, tool, permessi, guardrail, connessioni ai vostri sistemi, risponde delle scelte di progettazione dell’agente. È qui che vive la maggior parte degli errori reali, perché è qui che si decide cosa l’agente può fare.

Il deployer, cioè l’azienda che l’agente lo mette in produzione sui propri processi e sui propri clienti, è nella pratica il convenuto più esposto. La posizione dominante nella dottrina anglosassone è netta: come scrive lo studio Lysinski & Associates, «la responsabilità ricade generalmente sul deployer» e «l’ha fatto l’AI da sola» non è una difesa. La California ha messo il principio per iscritto: dal gennaio 2026 chi si difende da un danno causato da un sistema AI non può invocare l’operatività autonoma del sistema come esimente, e il Colorado AI Act segue la stessa direzione da giugno 2026 (The Lyon Firm).

Perché «l’ha deciso l’agente» non regge in giudizio

Il ragionamento giuridico è più vecchio dell’AI generativa: se autorizzate un soggetto ad agire per vostro conto, rispondete di ciò che fa entro quel mandato. L’agente software non ha personalità giuridica, quindi il mandato torna indietro a chi l’ha conferito. Il precedente più citato è canadese: nel caso Moffatt v. Air Canada, il Civil Resolution Tribunal della British Columbia ha condannato la compagnia per le informazioni sbagliate date dal suo chatbot a un passeggero, respingendo la tesi difensiva secondo cui il chatbot sarebbe «un soggetto distinto responsabile delle proprie azioni» (2024 BCCRT 149). Le teorie che i tribunali stanno applicando sono quelle di sempre, product liability, negligent deployment, cioè l’aver messo un agente in un ruolo ad alto impatto senza test adeguati, negligent supervision, inadempimento contrattuale, solo declinate su un attore non umano. In Italia il perno resta l’art. 2043 c.c., con l’art. 2050 sulle attività pericolose come possibile aggravante a seconda del contesto d’uso.

L’AI Act dice chi rischia, non chi risarcisce

Qui va sfatato l’equivoco più diffuso nelle sale riunioni italiane. L’AI Act è una normativa di prodotto e di prevenzione: classifica i sistemi per livello di rischio, impone obblighi di documentazione, sorveglianza e trasparenza, e prevede sanzioni amministrative se non li rispettate. Non stabilisce chi risarcisce il cliente danneggiato, e non crea un’azione civile per il danneggiato. Se avete bisogno del quadro completo di scadenze e obblighi, lo trovate nella nostra guida su cosa prevede l’AI Act e chi deve adeguarsi.

Il pezzo che avrebbe dovuto rispondere alla domanda sul risarcimento esisteva, e non c’è più. La AI Liability Directive, proposta nel settembre 2022 per alleggerire l’onere probatorio di chi subisce un danno da AI, è stata inserita fra i ritiri nel programma di lavoro della Commissione annunciato l’11 febbraio 2025, con la motivazione «nessun accordo prevedibile» (IAPP). Il risultato pratico è che il risarcimento resta affidato ai regimi nazionali di responsabilità civile: un mosaico di 27 discipline invece di regole armonizzate.

Cosa resta davvero in vigore nel 2026

Resta molto, e per le imprese pesa più della direttiva ritirata. La nuova Product Liability Directive 2024/2853 classifica esplicitamente il software e i sistemi AI come «prodotti» soggetti a responsabilità oggettiva, con trasposizione negli ordinamenti nazionali entro il 9 dicembre 2026 (Bird & Bird). Non solo: introduce una presunzione di causalità che ribalta l’onere della prova. Tradotto in italiano operativo, se un cliente sostiene che il vostro agente gli ha causato un danno, tocca a voi dimostrare che il difetto non c’era. È il motivo per cui la sezione sui log, più avanti, non è un dettaglio tecnico ma la vostra difesa principale. Sul come tenere insieme adempimenti e operatività abbiamo scritto un pezzo dedicato ad AI Act e agenti AI in azienda.

Quando la tua azienda diventa giuridicamente «fornitore»

C’è un passaggio dell’AI Act che quasi nessuno legge e che sposta l’intera catena di responsabilità: l’articolo 25, sulla responsabilità lungo la catena del valore. Stabilisce che un distributore, un importatore, un deployer o una terza parte diventano fornitori di un sistema ad alto rischio, con tutti gli obblighi del fornitore, in tre casi (testo dell’articolo 25, disponibile anche in versione italiana commentata):

• quando appongono il proprio nome o marchio su un sistema già immesso sul mercato;
• quando apportano una modifica sostanziale a un sistema ad alto rischio che resta tale;
• quando cambiano la destinazione d’uso di un sistema, incluso uno costruito su un modello generico non classificato ad alto rischio, trasformandolo in un sistema ad alto rischio.

Il cambio di destinazione d’uso sposta la responsabilità su di voi

Il terzo caso è quello che dovrebbe togliere il sonno. Prendete un modello generalista, gli date accesso agli strumenti aziendali, lo mettete a fare screening di candidature o valutazione di pratiche di credito: avete cambiato la destinazione d’uso e siete finiti in un allegato ad alto rischio. Da quel momento il fornitore originario cessa di essere il fornitore di quel sistema, e voi ereditate documentazione tecnica, gestione dei rischi, conformità. L’articolo prevede anche l’obbligo per il fornitore iniziale di cooperare strettamente, fornire informazioni e garantire l’accesso tecnico ragionevolmente atteso, ma non se aveva esplicitamente escluso quella trasformazione nei propri termini. Quella clausola c’è, nei termini dei grandi provider. Andatela a leggere prima di scoprirla in causa. È esattamente il tipo di verifica che dovrebbe stare fra le domande da fare al partner prima di firmare, e che una governance degli agenti AI seria mette a verbale invece di lasciarla implicita.

Quali log servono per dimostrare di chi è stato l’errore

Se la presunzione di causalità sposta l’onere su di voi, allora la vostra posizione processuale coincide con la qualità delle vostre tracce. L’articolo 26 dell’AI Act impone ai deployer di conservare i log generati automaticamente per un periodo adeguato alla finalità e comunque non inferiore a sei mesi, salvo diversa previsione di legge (art. 26, comma 6). Sei mesi è il minimo di legge, non un obiettivo: un contenzioso civile si apre spesso dopo. Lo stesso articolo impone sorveglianza umana affidata a persone con competenza, formazione e autorità reale (comma 2), monitoraggio del funzionamento con obbligo di sospendere l’uso e informare il fornitore in caso di rischio (comma 5).

Cosa deve contenere una traccia che regge davvero. Non «i log dell’applicazione»: servono quattro livelli separati e correlabili, la versione della knowledge base interrogata, il prompt e il contesto effettivamente passati, l’elenco delle operazioni eseguite con i relativi permessi, l’output consegnato. TrueScreen insiste su un punto che vale la pena rubare: senza marcatura temporale qualificata la catena causale non è ricostruibile in modo opponibile. E Lysinski aggiunge il criterio che un giudice applica davvero: conta l’evidenza contemporanea all’incidente, non i documenti prodotti dopo. Sul piano pratico questo significa progettare l’osservabilità dell’agente in produzione il giorno del design, non il giorno dopo il primo incidente, e decidere già allora quali KPI mettere sotto monitoraggio.

Il log che non controllate: i ragionamenti nascosti sono estraibili

C’è un rischio speculare, ed è recentissimo. Il 10 agosto 2026 Panfilov, Schmotz, Shumailov, Beurer-Kellner, Schaeffer, Prabhu, Geiping e Andriushchenko hanno pubblicato Stealing Reasoning Traces from Proprietary LLM APIs (arXiv): i blocchi cifrati di chain-of-thought che i provider restituiscono al client sono interoperabili fra sessioni, utenti e modelli dello stesso fornitore. Iniettando una traccia cifrata di un modello forte dentro un modello più debole e meno protetto dello stesso provider, si ottiene la decodifica in chiaro senza mai attaccare il modello forte. Su repository pubblici i ricercatori hanno decodificato 315.320 blocchi di reasoning, recuperando 367 artefatti PII e 182 credenziali. Il ragionamento intermedio del vostro agente, che spesso contiene dati di clienti e chiavi, non è un’area privata: è materiale che, se finisce in un repository o in un ticket, può essere riaperto. È la dimostrazione più chiara del perché il modello da solo non basta a rendere sicuro un agente.

Cosa deve prevedere un SLA sul malfunzionamento di un agente AI

La licenza del modello e il contratto di integrazione servono a cose diverse. La prima vi dà accesso a una capacità; il secondo dovrebbe dirvi cosa succede il giorno in cui quella capacità sbaglia. La differenza fra i due documenti è quasi sempre dove si perdono i soldi. Le clausole minime da pretendere le abbiamo approfondite nel pezzo su quali garanzie chiedere al partner prima di firmare e in quello su cosa include l’assistenza dedicata e cosa l’SLA non copre.

Le clausole che servono a provare di chi è stato l’errore

Restano fuori da questa tabella, di proposito, le clausole che riguardano la qualità del servizio più che la prova dell’errore: livelli di severità e tempi di primo contatto umano, kill switch e rollback, exit e handover di prompt, configurazioni e dataset di test. Sono altrettanto vincolanti in fase di firma, ma appartengono all’elenco delle garanzie da negoziare, che trovate nel pezzo sugli SLA linkato qui sopra.

Nei pagamenti la ripartizione non è ancora scritta

Un avvertimento onesto: in alcuni ambiti la ripartizione non è ancora risolta da nessuna parte. Nei pagamenti, per esempio, l’analisi di Backbase osserva che negli Stati Uniti la Regulation E del 1978 protegge dalle transazioni non autorizzate ma non da quelle autorizzate, e che la supervisione SR 26-2 dell’aprile 2026 esclude esplicitamente gli agenti AI perché «nuovi e in rapida evoluzione». Dove la norma tace, il contratto è l’unica cosa che avete.

La matrice RACI delle prime 48 ore dopo un errore

Le clausole servono a poco se nessuno sa chi fa cosa mentre l’incidente è in corso. Questa è la matrice che consegniamo ai clienti MIMIR in fase di onboarding, applicata alla dinamica dell’incidente Anthropic, dove il danno è nato in una zona grigia fra due organizzazioni:

Chi è accountable mentre l’incidente è in corso

Due cose vanno notate. Primo: l’accountable è quasi sempre il cliente, perché è il deployer, ed è coerente con tutto ciò che abbiamo visto sopra, non è una furbizia contrattuale, è come funziona. Secondo: il partner è responsible su cinque righe su sette, e questo è precisamente ciò che una licenza non vi dà. Un contratto di modello non ha un on-call, non congela i vostri log, non partecipa al post-mortem e non riscrive i guardrail il lunedì mattina.

È la ragione per cui in MIMIR l’assistenza dedicata non è un add-on commerciale ma la parte del servizio che tiene in piedi la matrice: onboarding con definizione esplicita dei ruoli, manutenzione post-deployment e un handover che lascia al vostro team IT tutto il necessario per non dipendere da noi in emergenza.

Cosa si contratta davvero, alla fine

La conclusione è più semplice del quadro normativo che l’ha prodotta: la responsabilità dell’errore, nella stragrande maggioranza dei casi, resta vostra, e nessuna clausola la sposterà sul fornitore del modello. Quello che potete davvero contrattare non è chi risponde, ma chi vi aiuta a rispondere: chi conserva le prove, chi le sa leggere, chi ferma l’agente e chi rimette in piedi il processo. La licenza non risponde al telefono. Il partner sì.

Se state valutando un agente AI su un processo che tocca clienti, denaro o dati personali, o se ne avete già uno in produzione e non sapete rispondere alla domanda «dove sono i log di ieri notte», potete parlarne con MIMIR. Guardiamo insieme il perimetro del processo, i ruoli e cosa serve davvero mettere per iscritto prima di partire: è una conversazione, non un preventivo.

Fonti:

• ABC News — Claude ha violato sistemi esterni reali durante un test
• TrueScreen — La responsabilità legale nella AI agentica
• Lysinski & Associates — AI agent liability
• The Lyon Firm — Agentic AI liability
• Civil Resolution Tribunal British Columbia — Moffatt v. Air Canada, 2024 BCCRT 149
• IAPP — La Commissione ritira la AI Liability Directive
• Bird & Bird — Ritirate le regole UE proposte sulla responsabilità AI
• AI Act — Articolo 25, responsabilità lungo la catena del valore
• Articolo 25 in versione italiana commentata
• AI Act — Articolo 26, obblighi dei deployer
• Stealing Reasoning Traces from Proprietary LLM APIs (arXiv)
• Backbase — Responsabilità nei pagamenti eseguiti da agenti AI