I. Il giocattolo da ottanta miliardi #
Esiste un documento che dovreste leggere. Non è lungo, non è nascosto, non richiede competenze giuridiche particolari per essere compreso. Si trova all'indirizzo microsoft.com/en-us/microsoft-copilot/for-individuals/termsofuse, è stato aggiornato il 24 ottobre 2025 e contiene una frase che merita di essere presa sul serio. La frase si trova nella sezione intitolata, in maiuscolo e grassetto, "IMPORTANT DISCLOSURES & WARNINGS", e dice: Copilot è da considerarsi esclusivamente a scopo di intrattenimento. Può commettere errori e potrebbe non funzionare come previsto. Non fare affidamento su Copilot per consigli importanti. Usare Copilot a proprio rischio.
Se vi sembra la clausola di un'app per generare meme, vi capisco. Ma stiamo parlando del prodotto che Microsoft ha integrato in Windows 11, in Excel, in PowerPoint, in Teams, in Outlook, nel cuore pulsante della suite che oltre 430 milioni di persone usano ogni giorno. Stiamo parlando del prodotto per cui Microsoft ha impegnato circa ottanta miliardi di dollari in capital expenditure AI nel solo fiscal year 2025, tra data center, infrastruttura e capacità computazionale, a cui si sommano i circa tredici miliardi investiti cumulativamente in OpenAI, la cui tecnologia alimenta i modelli sottostanti. Stiamo parlando del prodotto venduto alle grandi aziende a trenta dollari per utente al mese, e alle piccole e medie imprese a ventuno (ridotti a diciotto con le promozioni del primo semestre 2026). I Terms of Use di questo prodotto dicono che è un giocattolo.
La reazione di Microsoft, quando la clausola ha cominciato a circolare sui social media nei primi giorni di aprile 2026, è stata prevedibile nella sua meccanicità. Un portavoce ha dichiarato a PCMag che si tratta di "linguaggio legacy" che "non riflette più l'uso attuale del prodotto" e che "verrà modificato con il prossimo aggiornamento". Nessuna data. Nessun impegno vincolante. Nessuna spiegazione del perché un linguaggio che non riflette la realtà del prodotto sia rimasto nei documenti legali per mesi dopo l'ultimo aggiornamento, sotto gli occhi dello stesso team legale che lo aveva scritto. Il portavoce ha parlato come se qualcuno avesse dimenticato di togliere un cartello da un cantiere chiuso. Ma i cantieri chiusi non fatturano trenta dollari a posto al mese.
La tentazione è liquidare la cosa come una gaffe del reparto legale. Non lo è. I Terms of Use non vengono scritti per distrazione. Vengono scritti da team di avvocati che pesano ogni parola sapendo che quelle parole verranno usate in tribunale. La parola "entertainment" non è un sinonimo svogliato di "sperimentale" o "beta". Entertainment ha un significato giuridico preciso nel diritto anglosassone: è la categoria che protegge chi produce contenuti dichiaratamente non fattuali, come i giochi, le fiction, le simulazioni. Dire che un prodotto è "for entertainment purposes only" significa dire che nessun utente ragionevole dovrebbe aspettarsi che le sue risposte siano accurate, affidabili, o adatte a qualsiasi scopo pratico.
Si potrebbe obiettare che i numeri raccontano una storia diversa. Che l'adozione di Copilot è stata più lenta del previsto. Che Microsoft stessa sa che il prodotto ha problemi. E si avrebbe ragione. Al secondo trimestre del fiscal year 2026, solo quindici milioni di posti su quattrocentocinquanta milioni di posti commerciali pagati risultavano abbonati a Microsoft 365 Copilot: il 3,3 percento. La quota di mercato USA dei sottoscrittori a pagamento si è contratta del 39 percento in sei mesi, passando dal 18,8 percento di luglio 2025 all'11,5 percento di gennaio 2026. Il Net Promoter Score sull'accuratezza delle risposte è peggiorato da meno 3,5 a meno 24,1 tra luglio e settembre 2025, secondo Recon Analytics. Il 44,2 percento degli utenti che abbandonano Copilot cita la sfiducia nelle risposte come motivazione principale. Quando i lavoratori possono scegliere liberamente tra Copilot, ChatGPT e Gemini, solo l'8 percento sceglie il prodotto Microsoft.
Questi numeri non attenuano il problema. Lo aggravano. Dimostrano che Microsoft sa perfettamente che il prodotto non è affidabile, lo dichiara nei documenti legali, e continua a venderlo come strumento di produttività enterprise. Satya Nadella ha chiamato Copilot "a true daily habit" davanti agli investitori. Il marketing lo presenta come l'assistente che trasforma il modo in cui lavori. I Terms of Use dicono che è un giocattolo. Non è una contraddizione. È una strategia.
II. Il coro dei disclaimer #
Sarebbe intellettualmente disonesto presentare la clausola di Microsoft come un'anomalia. Non lo è. È il caso più eclatante di un pattern che attraversa l'intera industria AI, e che vale la pena mappare con precisione.
OpenAI, nei suoi Terms of Use, avverte gli utenti di non fare affidamento sugli output come unica fonte di verità o informazione fattuale, e limita la propria responsabilità aggregata a cento dollari o all'importo pagato nei dodici mesi precedenti. Google, nei termini di Gemini, scrive di non fare affidamento sui servizi per consulenze mediche, di salute mentale, legali, finanziarie o di altro tipo professionale. xAI, l'azienda di Elon Musk, avverte che la propria AI è "probabilistica per natura" e può produrre output errati. Nessuna di queste aziende, va detto, si è spinta fino alla formula "for entertainment purposes only". Quella resta un'esclusiva Microsoft.
La differenza tra Microsoft e gli altri non è però di sostanza. È di sfumatura. Tutti i grandi provider di AI stanno facendo la stessa operazione: costruire un muro legale tra il prodotto che vendono e le conseguenze del suo utilizzo. Lo fanno sapendo che i loro modelli possono e producono output falsi, fuorvianti, potenzialmente dannosi. Nell'agosto 2024, Copilot ha identificato falsamente il giornalista tedesco Martin Bernklau come un pedofilo condannato e un truffatore, fornendo anche il suo indirizzo di casa. Microsoft ha bloccato le query su Bernklau solo dopo un reclamo per protezione dati. Questi non sono casi limite. Sono il funzionamento ordinario di un sistema probabilistico presentato commercialmente come se fosse deterministico.
E i disclaimer, in tribunale, funzionano. Il 19 maggio 2025, la Superior Court della contea di Gwinnett, in Georgia, ha emesso un summary judgment a favore di OpenAI nel caso Walters v. OpenAI (23-A-04860-2). Il conduttore radiofonico Mark Walters aveva citato OpenAI dopo che ChatGPT, su richiesta di un giornalista, aveva generato un falso riepilogo di una causa legale in cui Walters risultava accusato di appropriazione indebita ai danni della Second Amendment Foundation. Il tribunale ha rigettato la causa su tre motivi indipendenti: le dichiarazioni non potevano essere ragionevolmente intese come fatti reali (anche perché ChatGPT aveva avvisato il giornalista dei propri limiti e i ToS contenevano disclaimer espliciti sulla possibilità di errori); Walters non aveva dimostrato né negligenza né malice da parte di OpenAI; e lo stesso Walters aveva ammesso di non aver subito alcun danno. Un esito che si regge su più gambe, quindi, non solo sui disclaimer. Ma i disclaimer hanno pesato, e pesano. Il tribunale ha riconosciuto esplicitamente che i ripetuti avvertimenti sulla possibilità di "hallucination" contribuivano a rendere irragionevole qualsiasi aspettativa di accuratezza fattuale da parte dell'utente.
È a questo punto che molti commentatori si fermano, indignandosi. Ma è qui che il discorso deve diventare più preciso, perché non tutti i disclaimer sono uguali, non tutti servono allo stesso scopo, e non tutti sono, in sé, una cosa negativa.
L'AI Act europeo, il Regolamento 2024/1689, richiede esplicitamente che i provider di sistemi AI comunichino le limitazioni dei propri prodotti. L'Articolo 13 dispone che i sistemi AI ad alto rischio siano progettati in modo sufficientemente trasparente da consentire ai deployer di interpretare gli output e usarli in modo appropriato, e che siano accompagnati da istruzioni d'uso con informazioni concise, complete, corrette e chiare sulle caratteristiche, capacità e limitazioni di performance. L'Articolo 14 impone la supervisione umana effettiva, e prescrive che le persone preposte alla supervisione siano messe in condizione di restare consapevoli della possibile tendenza a fare affidamento automatico o eccessivo sugli output, quello che il Regolamento chiama "automation bias". L'Articolo 50 richiede che gli utenti siano informati quando interagiscono con un sistema AI, e che i contenuti generati siano contrassegnati come tali.
Dire "questo sistema AI può sbagliare, verifica sempre, non fidarti ciecamente" non è solo legittimo, dunque. È un obbligo normativo. L'Europa ha sancito che la trasparenza sulle limitazioni dei sistemi AI è un pilastro della sicurezza e della fiducia. L'utente deve sapere con cosa sta interagendo, quali sono i rischi, e deve poter decidere di ignorare o sovrascrivere qualsiasi output del sistema. Questo è il framework che qualsiasi azienda seria dovrebbe seguire.
Ma una cosa è dire "questo sistema ha queste limitazioni, ecco come supervisionarlo per usarlo in modo sicuro". Un'altra è dire "questo è un giocattolo per intrattenimento, usalo a tuo rischio, non garantiamo nulla". La prima formulazione è trasparenza. Compliance con l'AI Act. Un atto di responsabilità che mette il deployer in condizione di fare il suo lavoro. La seconda formulazione è uno scarico di responsabilità travestito da trasparenza. Non mette l'utente in condizione di usare il sistema in modo appropriato: lo mette in condizione di non potersi rivalere quando le cose vanno male.
L'AI Act chiede al provider di dichiarare le limitazioni per consentire un uso sicuro. I ToS di Microsoft dichiarano le limitazioni per impedire qualsiasi rivalsa. Uno serve l'utente. L'altro serve il reparto legale. E quando un tribunale americano valuta positivamente i disclaimer di un provider nel rigettare una causa per diffamazione, non sta necessariamente premiando la trasparenza. Sta prendendo atto del legalese.
III. La Direttiva che cambia tutto (e il punto cieco) #
Entro il 9 dicembre 2026, gli Stati membri dell'Unione Europea devono recepire nella legislazione nazionale la Direttiva 2024/2853, la nuova Product Liability Directive. È il primo aggiornamento in quarant'anni del regime europeo di responsabilità per prodotti difettosi. Per le aziende che producono, integrano o distribuiscono software e sistemi AI, le conseguenze sono profonde.
La Direttiva ridefinisce innanzitutto cosa sia un "prodotto". La vecchia direttiva del 1985 era concepita per un mondo di oggetti fisici: automobili, elettrodomestici, giocattoli. La nuova include esplicitamente il software, indipendentemente dalla modalità di fornitura o utilizzo, che sia embedded, standalone, cloud o SaaS. Include firmware, sistemi operativi, applicazioni. I Considerando chiariscono che rientrano nella definizione anche i sistemi di intelligenza artificiale. Il software non è più un servizio che sfugge alla responsabilità di prodotto. È un prodotto. Come tale è soggetto a responsabilità oggettiva: non serve dimostrare la colpa del produttore. Basta dimostrare che il prodotto era difettoso e che il difetto ha causato un danno.
C'è poi la questione delle clausole di esonero. L'Articolo 10 dispone che gli Stati membri garantiscano che la responsabilità di un operatore economico ai sensi della Direttiva non sia, nei confronti della persona danneggiata, limitata o esclusa da una disposizione contrattuale o dal diritto nazionale. La formulazione non ammette ambiguità. I disclaimer nei Terms of Use, le clausole di limitazione di responsabilità, le formulazioni "as is" e "for entertainment purposes only": nel momento in cui un consumatore europeo subisce un danno da un prodotto difettoso, non valgono niente.
Questo va capito nella sua portata transatlantica. La clausola "Copilot is for entertainment purposes only" continuerà a funzionare negli Stati Uniti, dove il caso Walters v. OpenAI ha confermato che i tribunali prendono sul serio i disclaimer. In Europa, dopo il recepimento della Direttiva, quella stessa clausola diventa inapplicabile. Se Copilot genera un output difettoso che causa un danno a una persona fisica (morte, lesioni, danni psicologici medicalmente riconosciuti, distruzione o corruzione di dati non professionali, danni a proprietà privata), il provider risponde. A prescindere da cosa c'è scritto nei ToS.
La Direttiva riscrive anche le regole sull'onere della prova, e qui la faccenda si complica. Introduce presunzioni a favore del danneggiato. Se il convenuto non divulga le informazioni rilevanti, si presume la difettosità. Se il prodotto non è conforme a requisiti obbligatori di legge nazionale o europea, si presume la difettosità. Se c'è un malfunzionamento evidente durante un uso ragionevolmente prevedibile, idem. Se il danneggiato incontra "eccessive difficoltà" nel provare il difetto a causa della complessità tecnica o scientifica del prodotto, i tribunali possono presumere sia la difettosità sia il nesso causale. Per i sistemi AI, dove l'opacità del funzionamento interno è strutturale e non accidentale, questa presunzione sarà la norma. Il danneggiato non dovrà spiegare come funziona il modello che ha generato l'output falso. Dovrà dimostrare che l'output era difettoso e che il danno ne è conseguito.
La PLD si intreccia con l'intero framework normativo europeo. La non conformità ai requisiti del Cyber Resilience Act (obbligo di security-by-design, gestione delle vulnerabilità, aggiornamenti di sicurezza) può costituire presunzione di difettosità. Lo stesso vale per il mancato rispetto degli obblighi NIS2. E lo stesso vale, implicitamente, per i requisiti dell'AI Act: un sistema AI che non rispetta gli obblighi di trasparenza, supervisione umana, accuratezza e robustezza è un sistema che non rispetta requisiti obbligatori di legge europea, e quindi un sistema per il quale la PLD può presumere la difettosità.
Il cortocircuito è visibile a occhio nudo. L'AI Act chiede ai provider di dichiarare le limitazioni dei propri sistemi per consentire un uso sicuro. La PLD dice che se il prodotto causa un danno, il provider risponde a prescindere dai disclaimer. Il provider è obbligato a informare che il sistema può sbagliare, e contemporaneamente non può usare quell'informazione per sottrarsi alla responsabilità quando il sistema sbaglia effettivamente. È un regime coerente, progettato per proteggere il consumatore. Ma crea una tensione fortissima tra il dovere di trasparenza e l'impossibilità di usare la trasparenza come scudo.
Per Microsoft, questa tensione è gestibile. Per chi sta nel mezzo della catena, è potenzialmente letale.
IV. Chi modifica, paga: l'integratore come capro espiatorio strutturale #
La PLD non si limita a dire che il produttore del software risponde. Amplia la catena degli operatori economici potenzialmente responsabili con una logica a cascata pensata per garantire che il consumatore europeo abbia sempre un interlocutore raggiungibile nell'UE. Se il manufacturer è fuori dall'UE, risponde l'importatore. Se non c'è un importatore identificabile, risponde il rappresentante autorizzato. Poi il fulfilment service provider. Poi il distributore, se non identifica l'operatore pertinente nella catena entro un mese dalla richiesta del danneggiato. La responsabilità è solidale: più operatori che rispondono per lo stesso danno sono responsabili insieme, ciascuno per l'intero.
Fin qui il sistema sembra ragionevole. Ma c'è una figura nella catena che la PLD tratta con particolare durezza e che è cruciale per capire le implicazioni pratiche della clausola "entertainment only": chiunque modifichi sostanzialmente un prodotto dopo la sua immissione sul mercato è considerato un manufacturer del prodotto modificato ed è responsabile nella misura in cui il difetto risulta dalla modifica. I Considerando chiariscono che una modifica sostanziale può risultare anche da un aggiornamento software, da un upgrade, o dall'apprendimento continuo di un sistema AI. Il prodotto così modificato si considera immesso sul mercato al momento in cui la modifica viene effettivamente operata.
Pensate a cosa succede nel mondo reale. Un system integrator, una software house, un consulente IT prende Copilot e lo integra in un workflow aziendale. Configura i prompt, collega le sorgenti dati del cliente, personalizza le risposte, automatizza i flussi. Sta modificando sostanzialmente il prodotto? Secondo la PLD, molto probabilmente sì. Il momento in cui prendi un modello AI generalista e lo specializzi per un contesto specifico, stai creando un prodotto diverso da quello originale. Se quel prodotto modificato genera un output difettoso che causa un danno, l'integratore risponde come manufacturer.
L'Articolo 12 della PLD prevede una protezione specifica per le micro e piccole imprese che producono software difettoso integrato in un prodotto altrui. Queste imprese possono concordare contrattualmente con il manufacturer del prodotto finale un accordo che le protegga dalle azioni di regresso. Ma questa protezione ha due limiti che ne riducono drasticamente l'utilità. Il primo: non protegge in alcun caso la micro o piccola impresa da un'azione diretta del consumatore. Il consumatore può sempre agire direttamente contro l'integratore, e l'integratore risponde. Il secondo: la protezione per le azioni di regresso richiede un accordo contrattuale con il manufacturer del prodotto. Microsoft non ha alcun obbligo e nessun incentivo a concedere questo tipo di accordi ai system integrator che usano Copilot. I suoi ToS dicono già che il prodotto è "for entertainment purposes only" e che l'utente è "solely responsible" per qualsiasi azione intrapresa sulla base degli output. In un'eventuale azione di regresso, Microsoft potrà dire: vi avevamo avvisato. Avete scelto voi di integrarlo in un prodotto professionale. Non è colpa nostra se lo avete venduto a un cliente come strumento affidabile quando noi stessi vi avevamo detto che era un giocattolo.
La PLD impedisce di scaricare la responsabilità verso il basso nella catena, cioè verso il consumatore, tramite clausole contrattuali. Ma non impedisce ai grandi di rifiutarsi di concedere tutele contrattuali verso l'alto, nel rapporto tra integratore e manufacturer. Il risultato è che l'integratore è esposto al consumatore senza potersi proteggere contrattualmente, e non ha alcuna garanzia di potersi rivalere efficacemente su Microsoft. Microsoft ha i team legali, i rappresentanti autorizzati in ogni stato membro, la massa finanziaria per assorbire il contenzioso. L'integratore da dieci persone a Pescara, a Brno, a Lisbona, no.
L'obiezione ovvia è che l'integratore può e deve implementare l'human oversight previsto dall'AI Act. Mettere in piedi processi di verifica, formazione degli utenti, supervisione degli output. Ed è vero, l'integratore responsabile lo farà, e dovrà farlo anche per i propri obblighi come deployer sotto l'AI Act. Ma la PLD non chiede se hai fatto del tuo meglio. La PLD chiede se il prodotto era difettoso e se il difetto ha causato un danno. Un output falso generato da un sistema AI integrato in un workflow professionale che causa un danno a una persona fisica è un prodotto difettoso, indipendentemente da quanti livelli di supervisione umana l'integratore abbia implementato. Puoi aver fatto tutto bene e rispondere comunque.
Pensate a cosa succede quando un sistema AI integrato in un software gestionale genera un report finanziario errato che porta a una decisione di investimento sbagliata. O quando un assistente AI integrato in un CRM genera una comunicazione diffamatoria su un cliente. O quando un sistema di analisi integrato in una piattaforma sanitaria fornisce un'indicazione errata che influenza un percorso diagnostico. In tutti questi casi, sotto la PLD, il danneggiato può agire contro l'integratore. L'integratore è lì, è nell'UE, è raggiungibile, ha un codice fiscale e un conto corrente. Microsoft è a Redmond. E nei suoi ToS c'è scritto che Copilot è per intrattenimento.
V. Il conto e chi lo paga #
C'è un momento, nella storia della regolazione tecnologica, in cui diventa chiaro che le regole sono state scritte per un mondo che non esiste più. La vecchia Product Liability Directive del 1985 era concepita per un mondo in cui i prodotti erano oggetti fisici fabbricati da aziende identificabili, venduti attraverso catene distributive lineari, e usati da consumatori che potevano ragionevolmente valutarne la sicurezza. La nuova PLD è un aggiornamento necessario e per molti versi ammirevole: estende la protezione al software, abbassa le barriere per i consumatori, introduce presunzioni che riequilibrano l'asimmetria informativa. Ma il mondo che regola non è fatto di catene lineari. È fatto di layer sovrapposti, di API che chiamano API, di modelli probabilistici il cui funzionamento interno non è comprensibile nemmeno a chi li ha costruiti.
L'architettura logica del framework normativo europeo è la più avanzata al mondo. L'AI Act stabilisce obblighi di trasparenza, supervisione umana, gestione del rischio. Il Cyber Resilience Act impone security-by-design e aggiornamenti di sicurezza continui. NIS2 estende la cybersecurity a settori critici. La PLD chiude il cerchio stabilendo che chi viola questi obblighi e causa un danno paga. L'obiezione non è alla logica del framework. L'obiezione è alla distribuzione pratica delle conseguenze.
Le conseguenze, nella realtà dei fatti, seguono una legge di gravitazione economica che nessuna direttiva può invertire: cadono verso il basso. Verso chi ha meno risorse legali, meno massa finanziaria, meno capacità di assorbire il contenzioso. Microsoft, Google, OpenAI hanno ciascuna centinaia di avvocati, rappresentanti autorizzati in ogni giurisdizione, budget legali che superano il fatturato di intere filiere di PMI. Hanno scritto ToS che, anche se inefficaci sotto la PLD verso il consumatore, restano pienamente operativi come argomento nelle azioni di regresso tra operatori economici. Hanno classificato i propri prodotti come "entertainment", "probabilistic", "not a source of truth" con precisione chirurgica, sapendo quale funzione ogni parola avrebbe svolto in un procedimento futuro.
La PLD presenta il conto, ma chi lo paga? Lo paga il system integrator da dieci persone che ha preso Copilot, lo ha integrato nel gestionale del cliente, ha fatto formazione, ha implementato la supervisione umana, e scopre che quando l'output difettoso genera un danno, è lui quello raggiungibile, identificabile, citabile. Il provider è dall'altra parte dell'oceano, o comunque protetto da clausole contrattuali B2B, arbitrati a Dublino, e limitazioni di responsabilità tra operatori economici che la PLD non tocca perché riguardano rapporti tra professionisti e non la protezione diretta del consumatore.
Sarebbe sbagliato dire che la PLD è un errore. La PLD è incompleta. La sua incompletezza produce un effetto regressivo che premia chi ha le risorse per navigare il sistema e penalizza chi non le ha. L'Articolo 12 riconosce il problema per le micro e piccole imprese, ma lo risolve in modo circolare: ti proteggiamo dal regresso se hai un accordo contrattuale con il manufacturer. Ma il manufacturer non ha alcun obbligo di concederti quell'accordo. E se nei suoi ToS c'è scritto "entertainment only", il suo incentivo a concedertelo è addirittura negativo: quell'accordo significherebbe ammettere implicitamente che il prodotto ha un uso professionale, contraddicendo il proprio scudo legale.
C'è un paradosso ulteriore. Le aziende che prendono più sul serio la compliance, che implementano l'human oversight, che informano i propri clienti, che documentano i processi, sono anche quelle che lasciano la traccia documentale più ricca per un'azione di responsabilità. Chi integra Copilot alla buona, senza processi, senza documentazione, senza supervisione, è paradossalmente più difficile da colpire perché lascia meno prove di un rapporto strutturato con il prodotto. La PLD, nel suo tentativo di proteggere il consumatore, rischia di creare un incentivo alla superficialità: chi fa le cose bene è più esposto di chi le fa male.
Va considerata anche la dimensione temporale. La PLD si applica ai prodotti immessi sul mercato o messi in servizio dopo il recepimento. Ma i sistemi AI non sono prodotti statici. Vengono aggiornati continuamente. I modelli cambiano. Gli output cambiano. Un sistema AI che oggi funziona in un modo tra sei mesi potrebbe funzionare in modo completamente diverso dopo un aggiornamento del modello sottostante. Ogni aggiornamento sostanziale, secondo i Considerando della PLD, rimette il prodotto sul mercato. L'integratore che ha costruito un workflow basato su Copilot nel 2025 potrebbe trovarsi, dopo un aggiornamento del modello nel 2027, con un prodotto sostanzialmente diverso che genera output diversi, senza avere alcun controllo sulla modifica e con piena responsabilità per i suoi effetti.
Non ho una soluzione ordinata per tutto questo. Ma chi lavora in questo settore dovrebbe cominciare a leggere i ToS dei propri provider AI non per indignarsene ma per capire esattamente cosa il provider si rifiuta di garantire, perché quella lista è la mappa del rischio residuo che resta sulle spalle dell'integratore. Dovrebbe negoziare accordi contrattuali specifici sulla responsabilità prodotto prima del recepimento della PLD, perché dopo il potere negoziale sarà ancora minore. Dovrebbe documentare ogni processo di supervisione umana, ogni valutazione di rischio, ogni informativa al cliente, non perché questo elimini la responsabilità sotto la PLD ma perché in un'azione di regresso verso il provider la documentazione è l'unica arma disponibile. E dovrebbe porsi seriamente la domanda se l'integrazione di sistemi AI di terze parti in prodotti professionali sia sostenibile dal punto di vista assicurativo, perché oggi la maggior parte delle polizze RC professionale non copre i danni da output AI, e domani questa copertura sarà necessaria.
Quando Microsoft scrive "for entertainment purposes only", non sta balbettando. Sta parlando in modo chiaro e deliberato. Sta dicendo che la responsabilità per qualsiasi uso professionale del suo prodotto non è sua. Sta dicendo che chi prende quel prodotto e lo vende come strumento affidabile lo fa interamente a proprio rischio. L'Europa ha costruito un framework normativo che in teoria tiene tutti responsabili. In pratica, tiene responsabili quelli che possono meno permetterselo. Il provider che ha scritto "for entertainment purposes only" sapendo perfettamente che nessuno lo avrebbe letto, che ha incassato trenta dollari a posto al mese sapendo perfettamente che il suo prodotto non era affidabile, quello ha ancora i suoi avvocati, le sue clausole, i suoi arbitrati internazionali. La prossima volta che qualcuno gli chiederà conto di quello che ha venduto, mostrerà di nuovo i Terms of Use. C'è scritto tutto. Basta leggere.