Clausole di riservatezza da richiedere al fornitore di piattaforma IA

Un NDA standard presuppone un destinatario umano che riceve informazioni, le mantiene riservate e non le diffonde. Una piattaforma di strategia IA fa qualcosa di strutturalmente diverso: ingerisce interi set di documenti, genera nuovo materiale derivato da essi, conserva la registrazione di ogni interazione e in alcune architetture apprende da ciò che le viene fornito. Cinque clausole colmano il divario: una garanzia di non addestramento con diritto di audit; sub-responsabili del trattamento nominati e residenza dei dati; cancellazione alla cessazione con certificato; registro delle versioni del modello; e un ambito di notifica degli incidenti che copre i modi di guasto specifici dell'IA.

Nulla in questo articolo costituisce testo giuridico né sostituisce la consulenza legale per un incarico specifico.

Un NDA bilaterale è scritto per un destinatario umano. Una piattaforma di strategia IA ingerisce interi set di documenti, genera nuovo materiale derivato da essi, conserva la registrazione di ogni interazione e in alcune architetture apprende da ciò che le viene fornito. Quattro categorie di informazioni che un NDA convenzionale non copre adeguatamente:

• Input: pacchetti per il consiglio, modelli finanziari e file di due diligence caricati sulla piattaforma – molto più ampi e sensibili di quanto tocca un tipico processore di dati SaaS.
• Output generati: nuovo materiale prodotto dal sistema, che può citare, riassumere o ricombinare contenuti riservati.
• Prompt: istruzioni digitate dal team, che spesso contengono nomi di clienti, contesto del deal e intenzioni strategiche.
• Metadati delle interazioni con il modello: frequenza delle query, durata delle sessioni, orari di interazione e localizzazioni degli utenti, che possono mappare flussi di lavoro operativi, tempistiche di ricerca e modelli di intelligence competitiva.

Altre due lacune meritano un'attenzione esplicita. Prima: un modello perfezionato su materiale del cliente può memorizzare e riprodurre frammenti per un cliente diverso – trasformando una violazione della riservatezza in un evento automatizzato e ripetibile. Seconda: «non condividiamo mai i tuoi dati» non equivale a «non ci addestriamo mai sopra». Un fornitore può conservare i documenti in modo strettamente riservato e al contempo incorporare ciò che ha appreso in un modello che poi serve ai concorrenti.

L'ambiguità nei termini definiti si propaga attraverso ogni disposizione operativa. I cinque termini definiti più determinanti:

Tre aree meritano particolare attenzione in sede di negoziazione: i Dati di utilizzo dovrebbero essere elevati a informazioni riservate. I prompt dovrebbero essere trattati integralmente come Dati del cliente. Un divieto di acquisizione occulta dei dati impedisce uno scivolamento silenzioso dell'ambito – in cui il fornitore acquisisce contenuti dalle sessioni dei clienti per migliorare il servizio senza esplicita autorizzazione.

Una società di strategia che valuta una piattaforma IA dovrebbe pretendere cinque clausole che i template standard dei fornitori abitualmente omettono o indeboliscono:

1. Una garanzia di non addestramento con diritto di audit. Per default, i dati del cliente, i prompt, gli input e gli output non dovrebbero essere utilizzati per addestrare alcun modello. Qualsiasi eccezione richiede consenso esplicito di opt-in e misure di de-identificazione. Un diritto di audit – come si aspetta l'ICO ai sensi dell'articolo 28(3)(h) del GDPR^[2] – trasforma la promessa in qualcosa di verificabile.
2. Residenza dei dati e lista nominativa dei sub-responsabili del trattamento. Indicare la regione in cui i dati sono archiviati ed elaborati. Nominare ogni sub-responsabile del trattamento e richiedere un'autorizzazione preventiva per le modifiche, come richiedono gli articoli 28(2) e 28(3)(d) del GDPR. La lista dei sub-responsabili del trattamento deve includere qualsiasi fornitore di modello fondazionale di terze parti.
3. Cancellazione alla cessazione, con certificato. Richiedere al fornitore, a scelta del cliente, di cancellare o restituire tutti i dati alla fine del contratto e di fornire prova scritta dell'avvenuta cancellazione. Un fornitore che non riesce a produrre un certificato di cancellazione relativo a una precedente cessazione di contratto non ha mai testato il proprio processo di offboarding.
4. Registro delle versioni del modello. Ogni output dovrebbe essere tracciabile alla versione del modello che lo ha prodotto, così che l'analisi possa essere verificata mesi dopo e le modifiche al comportamento del modello possano essere rilevate. Questa clausola supporta sia il registro della responsabilità sia la mappa affermazione-fonte per i lavori regolamentati.
5. Notifica degli incidenti con un ambito di violazione adeguatamente definito. Gli obblighi di notifica e la ripartizione dei costi dovrebbero essere stabiliti espressamente. La definizione di incidente di sicurezza dovrebbe coprire l'inversione del modello e l'estrazione di dati tramite output – modi di guasto specifici dell'IA – non solo le intrusioni di rete. Impegnarsi a notificare entro un periodo definito.

La disciplina consiste nel chiedere a ogni fornitore un documento o una dimostrazione, anziché una garanzia verbale. Le garanzie fornite in una riunione di vendita non sono vincolanti; le risposte scritte archiviate con il contratto lo sono.

• Cancellazione: richiedere la traccia di prove di un offboarding completato – il log di cancellazione e il certificato – non una descrizione del processo. Un fornitore che non riesce a produrlo non ha mai verificato se funziona.
• Sub-responsabili del trattamento: richiedere la lista completa e aggiornata dei sub-responsabili del trattamento, incluso qualsiasi fornitore di modello fondazionale di terze parti e le ubicazioni dei data center per ciascuno.
• Anonimizzazione: sondare la metodologia di de-identificazione e se la re-identificazione è tecnicamente fattibile. Un fornitore che non riesce a rispondere non dovrebbe avere accesso ai documenti dei clienti.
• Controlli sull'addestramento: chiedere se i dati sono segregati tra clienti, se le sessioni di addestramento avvengono su modelli condivisi o dedicati, e se i dati di un cliente possono mai influenzare gli output per un cliente diverso.
• Certificazioni: trattare SOC 2 e ISO 27001 come una baseline. Fare affidamento solo sulle certificazioni, senza le domande di due diligence di cui sopra, non è adeguato.^[3]

Porre le domande per iscritto e conservare le risposte. Il registro scritto è anche la prova che la società ha condotto un'adeguata due diligence qualora il rapporto diventi in seguito fonte di un incidente di riservatezza.

La riservatezza si vince o si perde silenziosamente alla fine di un rapporto. Tre disposizioni sulle condizioni di uscita prevengono il lock-in e l'esposizione dei dati alla cessazione:

• Formato di esportazione: specificare il formato in cui vengono restituiti i dati del cliente e gli output dell'analisi, e se i prompt sono recuperabili insieme a essi. Se il fornitore non riesce a produrre un'esportazione dei dati in un formato utilizzabile, la possibilità pratica di uscire è limitata indipendentemente dal diritto contrattuale.
• Proprietà degli output: il contratto dovrebbe confermare quantomeno che il cliente detiene una licenza ampia per utilizzare gli output per qualsiasi scopo commerciale lecito senza restrizioni. Qualsiasi modello perfezionato costruito sui dati del cliente dovrebbe ricevere un trattamento separato ed esplicito della proprietà e della possibilità del cliente di portarlo via alla cessazione.
• Conservazione dei log: indicare per quanto tempo il fornitore conserva i log di utilizzo e i registri delle interazioni dopo la cessazione e con quale ciclo di cancellazione vengono eliminati.

Il floor del GDPR: l'articolo 28(3)(g) richiede che alla fine di un contratto il responsabile del trattamento cancelli o restituisca tutti i dati personali ed elimini le copie esistenti, salvo obbligo di legge di conservarli.^[2] La cancellazione ritardata dai backup è accettabile solo se i dati vengono posti immediatamente fuori uso e cancellati al ciclo di cancellazione successivo del responsabile del trattamento.

La maggior parte dei questionari per i fornitori non considera la clausola sul miglioramento del servizio. La maggior parte degli accordi tecnologici consente al fornitore di utilizzare i dati del cliente per migliorare le proprie offerte, e i fornitori cercano sempre più spesso di estendere questo diritto all'addestramento di modelli IA. Tale linguaggio ha implicazioni significativamente più ampie di una clausola convenzionale sul miglioramento del servizio.

Il problema centrale: la proprietà dei dati non equivale al controllo dei dati. Anche se una società mantiene la proprietà dei propri dati grezzi, ampi diritti su derivati aggregati o anonimizzati possono consentire a un fornitore di costruire modelli che incorporano gli apprendimenti da quei dati a tempo indefinito – e quei modelli continueranno a servire gli altri clienti del fornitore dopo la fine del contratto.

Quattro aspetti da affrontare esplicitamente nel contratto:

1. Definire esplicitamente l'uso che genera valore: benchmark, prodotti di analisi, nuove funzionalità e addestramento di modelli dovrebbero essere ciascuno nominati – non lasciati a una clausola aperta di «miglioramento dei servizi».
2. Vietare gli usi derivati che non si accettano: nominarli individualmente anziché fare affidamento su una disposizione generale di riservatezza.
3. Limitare qualsiasi uso consentito alla propria istanza – non all'addestramento aggregato su tutta la base clienti.
4. Collegare qualsiasi uso consentito alla durata del contratto – non a una licenza a tempo indeterminato che sopravvive alla cessazione.

Questo esempio è illustrativo, non un incarico reale, e non costituisce consulenza legale. Una società di strategia di medie dimensioni che valutava una piattaforma IA ha condotto la propria revisione pre-contratto in tre passaggi.

1. Primo passaggio, definizioni: ha confermato che Input, Output, Dati del cliente, Dati di utilizzo e Dati di addestramento fossero tutti definiti, che i prompt rientrassero nei Dati del cliente e che la clausola sul miglioramento del servizio fosse limitata alla propria istanza.
2. Secondo passaggio, le cinque clausole: ha richiesto per iscritto un impegno di non addestramento, la lista pubblicata dei sub-responsabili del trattamento, la prova di un precedente certificato di cancellazione, la specifica del registro delle versioni del modello e le condizioni di notifica degli incidenti che coprissero gli attacchi di estrazione specifici dell'IA.
3. Terzo passaggio, condizioni di uscita: ha definito il formato di esportazione, ha confermato una licenza ampia sugli output e ha limitato la conservazione dei log post-cessazione a 90 giorni per i log non personali.

Una domanda ha rivelato la lacuna più importante: il fornitore non riusciva a documentare la propria metodologia di de-identificazione né a escludere la re-identificazione dei dati della società o del cliente, nemmeno dopo due richieste di follow-up. Il contratto è stato modificato prima della firma: uno standard di de-identificazione definito, un divieto di re-identificazione e una conclusione esplicita dell'uso che genera valore alla scadenza del contratto.

Decisity dichiara esplicitamente che i dati dei clienti non vengono mai utilizzati per addestrare modelli IA e abbina tale impegno alla piena tracciabilità delle fonti e alla residenza dei dati in Europa. La panoramica sulla sicurezza illustra in dettaglio gli impegni tecnici e contrattuali.

Letture correlate:

• Documenti riservati e strumenti di IA: cosa verificare
• Analisi di deal con IA: soddisfare lo standard del comitato di investimento e degli LP
• Divulgazione della versione del modello IA: cosa deve sapere il consiglio
• Come funziona Decisity

• Ward and Smith: Architettura contrattuale – clausole IA fondamentali per gli accordi con i fornitori
• ICO: Contratti e responsabilità tra titolari e responsabili del trattamento – cosa deve essere incluso
• Ward and Smith: Due diligence pre-contratto e misure operative per i contratti con fornitori IA
• Morgan Lewis: Considerazioni chiave nel consentire a un fornitore di addestrare i propri modelli IA sui dati del cliente (giugno 2026)