La proprietà dei dati AI porta le protezioni aziendali e gli strumenti consumer su percorsi diversi

Google News ha evidenziato un'analisi di TechTarget che pone un conflitto irrisolto al centro dell'adozione dell'AI in azienda: la proprietà non garantisce il controllo. Le aziende possono conservare i diritti legali sui propri dati pur perdendo il controllo pratico sulla loro archiviazione, revisione, recupero o riutilizzo.

La distinzione è diventata urgente mentre i dipendenti collegano gli assistenti AI a documenti, email, codice sorgente, trascrizioni di riunioni e record dei clienti. Ogni connessione amplia ciò che un modello può recuperare, trasformare ed esporre tramite l'account di un utente autorizzato.

I principali fornitori promuovono oggi prodotti aziendali che escludono per impostazione predefinita i contenuti dei clienti dall'addestramento dei modelli. Tuttavia, questi impegni variano in base al prodotto, al tipo di account, alla configurazione, al servizio collegato e al contratto.

La vera contesa, quindi, non è tra aziende e fornitori di AI. È tra la promessa della proprietà del cliente e la realtà del controllo delegato dei dati.

Google News evidenzia un problema contrattuale, non solo di privacy

Il cambiamento importante è che la proprietà dei dati AI è passata da una questione giuridica astratta a una decisione quotidiana di approvvigionamento e sicurezza.

Il titolo di TechTarget distribuito tramite Google News chiede chi possieda i dati forniti ai sistemi AI. La domanda riguarda prompt, file caricati, record aziendali recuperati, risposte generate, feedback e registri delle interazioni.

Queste categorie non ricevono sempre lo stesso trattamento. Un fornitore potrebbe consentire a un cliente di possedere prompt e output, conservando al contempo dati operativi per sicurezza, prevenzione degli abusi, debug o conformità legale.

Una clausola di proprietà non rivela neppure se le persone esaminano le informazioni inviate. Non stabilisce con quale rapidità i contenuti eliminati scompaiano dai backup, né se un'applicazione collegata ne mantenga un'altra copia.

Per questo una semplice risposta affermativa può fuorviare gli acquirenti. La proprietà descrive i diritti legali, mentre la governance dei dati descrive raccolta, accesso, trattamento, conservazione, trasferimento ed eliminazione.

Si consideri un product manager che chiede a un assistente di riassumere una ricerca non ancora pubblicata. L'azienda probabilmente possiede il report caricato, ma questo fatto da solo non determina dove il report venga trasferito.

L'assistente potrebbe recuperare il file tramite un connettore aziendale. Potrebbe inviare passaggi rilevanti a un modello, archiviare la conversazione, creare un record di audit e inoltrare metadati tramite un altro servizio.

Ogni passaggio crea un diverso punto di controllo. I team di sicurezza devono sapere quale parte gestisca quel punto e quale policy lo disciplini.

Lo stesso problema si presenta nello sviluppo software. Un programmatore può possedere codice sorgente proprietario pur divulgandolo inserendolo in un chatbot consumer non approvato.

La proprietà legale non annulla tale divulgazione. Né ripristina un segreto commerciale dopo che materiale riservato raggiunge un destinatario non autorizzato o un servizio configurato in modo improprio.

L'output generato crea un ulteriore livello di ambiguità. Diversi fornitori aziendali assegnano ai clienti i diritti disponibili sugli output, ma un'assegnazione non può garantire che ogni output sia unico.

Un modello può produrre materiale simile per utenti diversi. Può anche riprodurre espressioni protette, esporre informazioni memorizzate o generare codice soggetto a una licenza open source.

Google stessa avverte che gli utenti restano responsabili del proprio utilizzo del codice generato da Gemini. Le sue linee guida affermano che tale codice può essere soggetto a una licenza open source.

Questo avvertimento illustra la differenza tra il linguaggio sulla proprietà e l'esclusività effettivamente utilizzabile. Un'azienda può ricevere diritti contrattuali senza ottenere la garanzia che nessun terzo disponga di diritti concorrenti.

La presenza dell'articolo in un feed dedicato alla regolamentazione e alla sicurezza dell'AI riflette anche un cambiamento più ampio. Le questioni sui dati collegano ora privacy, cybersecurity, proprietà intellettuale, gestione dei record e supervisione dei fornitori.

Queste funzioni operano spesso sotto responsabili distinti. I sistemi AI li costringono a esaminare insieme lo stesso flusso informativo.

Un utile punto di partenza è un inventario delle informazioni che entrano in ogni servizio. I team dovrebbero distinguere tra prompt, file sorgente, passaggi recuperati, output, feedback, telemetria e registri amministrativi.

Questo inventario non è un esercizio teorico di conformità. Determina quali promesse contano e quali controlli possono essere effettivamente verificati.

La divisione tra consumer e aziendale cambia la risposta

L'account utilizzato per accedere a un servizio AI può contare quanto il nome del fornitore.

Un'azienda non può valutare in sicurezza “Gemini”, “ChatGPT” o “Copilot” come se costituissero un unico ambiente dati uniforme. Applicazioni consumer, workspace aziendali, API e modelli ospitati nel cloud possono operare secondo termini diversi.

OpenAI afferma che i suoi prodotti aziendali e la piattaforma API non utilizzano per impostazione predefinita gli input o gli output dei clienti per l'addestramento dei modelli. La sua business data policy copre specifiche offerte aziendali, formative, sanitarie e API.

L'azienda afferma inoltre che le organizzazioni idonee possono configurare la conservazione, inclusa la conservazione zero dei dati per utilizzi API ammissibili. Disponibilità ed eccezioni tecniche richiedono comunque una verifica per il servizio scelto.

OpenAI indica la crittografia AES-256 a riposo e TLS 1.2 o versioni successive in transito. Queste misure proteggono fasi specifiche del ciclo di vita dei dati, ma non sostituiscono la governance degli accessi.

La crittografia non può impedire a un dipendente autorizzato di inviare informazioni riservate. Non può nemmeno correggere autorizzazioni eccessive ereditate da un assistente collegato.

Google traccia un confine altrettanto importante. Per l'uso gestito di Gemini in Chrome, Google afferma che prompt e contesto di navigazione non vengono usati per addestrare modelli pubblici.

I suoi controlli di privacy aziendali affermano inoltre che si applicano le protezioni Workspace esistenti. Google dichiara che i contenuti non vengono revisionati da persone né utilizzati per l'addestramento dei modelli al di fuori del dominio del cliente senza autorizzazione.

Questa protezione dipende dall'uso di un account gestito. Nelle stesse linee guida, Google lo distingue esplicitamente da un account Gmail personale.

L'ambiente Gemini consumer presenta controlli e comportamenti di conservazione diversi. L'informativa sulla privacy di Gemini di Google afferma che Keep Activity prevede per impostazione predefinita l'eliminazione automatica dopo 18 mesi.

Gli utenti possono modificare questa impostazione a tre mesi, 36 mesi o conservazione indefinita. Possono inoltre eliminare manualmente le conversazioni.

Google afferma che un sottoinsieme delle chat può essere sottoposto a revisione umana per migliorare i suoi servizi. Le chat revisionate possono essere conservate fino a tre anni dopo essere state scollegate dall'account dell'utente.

La disattivazione di Keep Activity modifica l'utilizzo futuro, ma non determina una mancata conservazione istantanea. Google afferma che le chat temporanee e le chat create con l'impostazione disabilitata restano disponibili per 72 ore.

Il contrasto è rilevante per i dipendenti che usano account personali al lavoro. Un'interfaccia familiare può nascondere un accordo sui dati sostanzialmente diverso.

Microsoft afferma che prompt, risposte e dati Microsoft Graph in Microsoft 365 Copilot non vengono utilizzati per addestrare modelli di base. La sua protezione dei dati aziendali applica i controlli Microsoft 365 su identità, conservazione, sensibilità e audit.

Microsoft agisce inoltre come responsabile del trattamento dei dati secondo i termini aziendali applicabili. Questo ruolo comporta obblighi contrattuali definiti, ma i clienti restano responsabili degli accessi degli utenti e delle scelte di implementazione.

I termini commerciali di Anthropic forniscono un altro esempio. Nei termini pubblicati per Claude tramite Google Vertex AI, Anthropic afferma che i clienti possiedono gli output ove legalmente consentito.

Tali termini escludono inoltre i diritti di Anthropic sui contenuti dei clienti e vietano l'addestramento su tali contenuti. I dati di utilizzo sono descritti separatamente da prompt e output.

Il modello comune è incoraggiante ma condizionato. Le offerte aziendali chiariscono sempre più le promesse relative ad addestramento, proprietà e controlli amministrativi.

La debolezza emerge quando le organizzazioni presumono che tali protezioni seguano ogni dipendente in ogni interfaccia. Non seguono necessariamente gli account personali, le funzionalità sperimentali, i connettori di terze parti o gli output copiati.

La shadow AI intensifica questo divario. Si verifica quando i lavoratori utilizzano servizi AI non approvati al di fuori dell'ambiente gestito dal datore di lavoro.

Il dipendente potrebbe scegliere uno strumento consumer perché disponibile, familiare o più adatto a un'attività. L'organizzazione perde quindi leva contrattuale, logging centralizzato e controllo della configurazione.

Bloccare ogni assistente pubblico raramente risolve il problema dell'adozione. Le persone hanno comunque bisogno di opzioni approvate che si adattino ai reali flussi di lavoro di ricerca, scrittura, programmazione e analisi.

Un approccio più sicuro separa le attività consentite in base alla classe di informazioni. Le informazioni pubbliche potrebbero entrare in un servizio consumer approvato, mentre il materiale riservato richiede un ambiente aziendale gestito.

Le informazioni soggette a restrizioni possono richiedere un servizio isolato o vietare del tutto il trattamento da parte di modelli esterni. La classificazione dovrebbe seguire l'impatto sul business, non l'entusiasmo per un determinato fornitore.

Questa differenza modella anche i sistemi di conoscenza personale. Una base di conoscenza personale necessita di confini chiari tra materiale individuale e record organizzativi condivisi.

Senza tali confini, il recupero può diventare una scorciatoia per l'accesso. Un assistente utile potrebbe far emergere informazioni che il suo utente attuale non avrebbe mai dovuto ricevere.

Le promesse di proprietà si scontrano con il controllo delegato dei dati

Il compromesso fondamentale è semplice: un'AI utile ha bisogno di contesto, ma ogni fonte aggiuntiva amplia il perimetro di sicurezza del sistema.

Un chatbot autonomo vede ciò che un utente invia. Un assistente aziendale collegato può accedere a email, calendari, cronologie delle chat, repository di documenti, piattaforme di codice e sistemi clienti.

Questo contesto aggiuntivo migliora la pertinenza. Cambia però anche la domanda centrale di sicurezza da “Che cosa ha incollato il dipendente?” a “Che cosa può recuperare l'assistente?”.

La generazione aumentata dal recupero, comunemente chiamata RAG, fornisce a un modello informazioni esterne selezionate quando risponde a una richiesta. Il modello non necessita di un addestramento permanente su tali informazioni per esporle.

Questa distinzione è essenziale. Una promessa di non addestramento può essere accurata mentre contenuti sensibili transitano comunque attraverso inferenza, registri, cache, connettori o risposte generate.

Un assistente può anche rivelare dati perché il repository sottostante concede già un accesso eccessivo. L'interfaccia AI rende quel vecchio problema di autorizzazioni più facile da sfruttare.

Prima dell'AI, un dipendente poteva dover sapere quale cartella contenesse una previsione riservata. Un sistema conversazionale può individuare il file rilevante a partire da un'ampia domanda in linguaggio naturale.

Il modello non ha creato il problema di accesso. Ha ridotto lo sforzo necessario per scoprire e combinare le informazioni esposte.

I sistemi agentici approfondiscono il problema perché possono eseguire azioni tramite strumenti collegati. Un agente potrebbe leggere un messaggio, interrogare un database, creare un documento e inviare il risultato.

Un attacco di prompt injection inserisce istruzioni ostili nel contenuto che il sistema legge in un secondo momento. L'attaccante cerca di reindirizzare l'agente, estrarre informazioni o attivare un'azione non autorizzata.

Il controllo degli accessi tradizionale resta necessario, ma non è più sufficiente. L'agente necessita anche di restrizioni sugli strumenti, confini dei contenuti, passaggi di approvazione e monitoraggio di comportamenti di recupero insoliti.

Microsoft afferma che i suoi prodotti enterprise includono difese contro la prompt injection. Nessun controllo di un fornitore dovrebbe essere interpretato come l’eliminazione di questa classe di attacchi.

Un’altra collisione riguarda le finalità. Un’azienda può consentire a un fornitore di trattare informazioni riservate per generare risposte, senza consentirne l’uso per il miglioramento dei modelli.

Si tratta di finalità distinte. I contratti dovrebbero identificarle entrambe e impedire che un linguaggio vago sul miglioramento vanifichi restrizioni più specifiche.

Le funzionalità di feedback meritano un’attenzione particolare. Un utente che invia una valutazione negativa potrebbe allegare involontariamente la conversazione, i contenuti caricati o il contesto recente.

Il prodotto potrebbe trattare quel pacchetto nell’ambito di un flusso di lavoro separato per il miglioramento. Un’impostazione predefinita di non addestramento potrebbe quindi includere un’esplicita eccezione per il feedback.

La conservazione crea un conflitto simile. Un servizio può consentire ai clienti di eliminare le conversazioni visibili, mantenendo al contempo registrazioni limitate per ragioni di sicurezza o legali.

Questo non segnala automaticamente una condotta scorretta. Significa però che “eliminare” necessita di una definizione tecnica e contrattuale.

Gli acquirenti dovrebbero chiedere quando inizia l’eliminazione, quali sistemi conservano copie, come scadono i backup e quali vincoli legali possono interrompere la tempistica.

La residenza dei dati aggiunge un’altra protezione parziale. Conservare i contenuti archiviati in una regione selezionata può sostenere requisiti normativi o operativi.

La residenza non implica necessariamente che ogni fase di elaborazione rimanga in quella regione. Gli acquirenti hanno bisogno di risposte separate per archiviazione, inferenza, accesso dell’assistenza, telemetria e subfornitori.

I fornitori di modelli si affidano anche a partner infrastrutturali. Un servizio può coinvolgere il fornitore dell’applicazione, l’operatore cloud, lo sviluppatore del modello, il fornitore del connettore e l’amministratore del cliente.

L’accordo deve distribuire le responsabilità lungo questa catena. Altrimenti, ciascun partecipante può descrivere soltanto il proprio livello mentre il cliente presume una copertura dell’intero sistema.

La proprietà degli output resta limitata dalla legge. La protezione del copyright può richiedere la paternità umana, e il trattamento giuridico varia tra giurisdizioni e tipi di output.

La cessione contrattuale riguarda i diritti che il fornitore possiede. Non può cedere diritti che non ha mai detenuto, né annullare una valida pretesa di terzi.

La protezione dei segreti commerciali crea uno standard diverso. Le aziende la preservano adottando misure ragionevoli per mantenere segrete informazioni di valore.

L’invio di materiale riservato secondo condizioni enterprise protettive può sostenere tale impegno. Inviare lo stesso materiale a un account pubblico non controllato può indebolirlo.

Per questo l’approvvigionamento non può fermarsi a una frase come: “Il cliente possiede i propri dati.” Quella frase risponde soltanto a una parte del rischio.

Una revisione significativa chiede chi può accedere ai dati, per quali finalità, attraverso quali sistemi, per quanto tempo e seguendo le istruzioni di chi.

I controlli di sicurezza falliscono comunque quando autorizzazioni e persone cambiano

Gli impegni del fornitore riducono l’esposizione, ma le scelte di implementazione determinano se tali impegni proteggono le informazioni aziendali reali.

Il primo punto di fallimento è l’identità. Le organizzazioni hanno bisogno di single sign-on, autenticazione a più fattori, deprovisioning tempestivo e accesso basato sui ruoli per i servizi AI gestiti.

Quando un dipendente lascia l’azienda, la disabilitazione di un’unica identità aziendale dovrebbe interrompere l’accesso agli assistenti connessi e ai relativi spazi di lavoro conservati. Gli account personali separati aggirano questo controllo.

Il secondo punto di fallimento è l’autorizzazione. Un assistente AI dovrebbe ereditare le autorizzazioni correnti dell’utente e rispettare le restrizioni a livello di documento.

Anche le autorizzazioni ereditate possono essere troppo ampie. Anni di link condivisi, gruppi aperti e cartelle ereditate spesso lasciano file sensibili accessibili a dipendenti non previsti.

L’implementazione dell’AI dovrebbe attivare una revisione delle autorizzazioni prima che inizi un recupero esteso dei contenuti. Aspettare il lancio consente all’assistente di indicizzare e mostrare errori già esistenti.

Il terzo punto di fallimento è la classificazione dei dati. I lavoratori non possono seguire regole che non riescono ad applicare durante un’attività reale.

Una policy dovrebbe fornire esempi concreti di contenuti pubblici, interni, riservati e soggetti a restrizioni. Dovrebbe inoltre identificare gli strumenti approvati per ciascuna categoria.

Il codice sorgente offre uno scenario utile. Uno sviluppatore potrebbe inviare una breve funzione per il debugging senza rendersi conto che i commenti contengono hostname interni o identificativi dei clienti.

Un sistema di prevenzione della perdita di dati può rilevare alcuni schemi. Non identificherà ogni frammento il cui valore dipende dal contesto aziendale.

La formazione umana resta quindi necessaria. La formazione dovrebbe spiegare la differenza tra proprietà, riservatezza, conservazione e addestramento dei modelli.

Un quarto punto di fallimento riguarda i connettori. Ogni connessione dovrebbe avere un responsabile, una finalità approvata, un gruppo di utenti autorizzato e una data di revisione.

Gli amministratori dovrebbero concedere gli ambiti più ristretti praticabili. L’accesso in sola lettura è più sicuro dell’accesso in scrittura quando il caso d’uso richiede soltanto sintesi o ricerca.

Le azioni ad alto impatto dovrebbero richiedere la conferma dell’utente. L’invio di messaggi, la modifica di record, la pubblicazione di file e l’avvio di attività finanziarie meritano controlli più rigorosi rispetto alla stesura di testo.

Il quinto punto di fallimento è la registrazione. I team di sicurezza hanno bisogno di registrazioni che mostrino chi ha usato il servizio, quale connettore è stato eseguito, quale azione si è verificata e se una policy l’ha bloccata.

I log possono a loro volta contenere informazioni sensibili. Le organizzazioni devono proteggerli ed evitare di registrare prompt completi quando i metadati possono supportare la finalità di sicurezza.

Il monitoraggio dovrebbe cercare volumi insoliti, recuperi estesi, violazioni ripetute delle policy e accessi da identità inattese. Non dovrebbe trasformarsi in una sorveglianza illimitata dei dipendenti.

Il sesto punto di fallimento è il cambiamento del fornitore. I servizi AI aggiungono frequentemente modelli, funzioni di memoria, strumenti di navigazione, agenti e integrazioni.

Un contratto firmato per un chatbot testuale potrebbe non descrivere pienamente una funzionalità successiva che registra schermi, accede a browser remoti o esegue attività.

I materiali di Google sulla privacy per i consumatori illustrano questa espansione. Descrivono file, audio dal vivo, video, condivisione dello schermo, applicazioni connesse, contesto della pagina e dati del browser remoto.

Ogni capacità può essere utile. Ognuna modifica anche le informazioni disponibili al servizio.

La revisione della sicurezza deve quindi essere legata ai cambiamenti delle capacità, non soltanto ai rinnovi contrattuali annuali. Gli amministratori hanno bisogno di preavviso e di un modo per disabilitare funzionalità non approvate.

Il settimo punto di fallimento è la risposta agli incidenti. Un’azienda dovrebbe sapere cosa fare quando un dipendente invia informazioni soggette a restrizioni al sistema sbagliato.

La risposta può includere la conservazione dei log pertinenti, la disabilitazione della condivisione, la richiesta di eliminazione, la revisione delle comunicazioni contrattuali e la valutazione dell’esposizione legale.

I team dovrebbero evitare promesse secondo cui l’eliminazione rimuove ogni rischio. Potrebbero esistere copie in servizi connessi, sistemi dei destinatari, backup o registri di feedback esaminati.

Il framework sui rischi dell’AI del NIST offre una struttura utile per governare, mappare, misurare e gestire i rischi dell’AI.

Il framework resta volontario e il NIST sta rivedendo AI RMF 1.0. Il suo valore risiede nel trasformare principi ampi in responsabilità documentate e revisioni ripetibili.

Tuttavia, i framework non risolvono fatti specifici di un prodotto. Un’azienda ha comunque bisogno di prove sull’account, la funzionalità, la regione, il connettore e il contratto esatti che implementa.

È anche qui che il marketing dei fornitori merita scetticismo. “Enterprise-grade” può descrivere un insieme di controlli senza dimostrare che ogni controllo sia abilitato.

Una certificazione può confermare che processi definiti sono stati sottoposti ad audit. Non dimostra che un cliente abbia configurato correttamente le autorizzazioni o scelto il prodotto giusto.

Anche la conservazione zero dei dati richiede una lettura attenta. L’espressione può applicarsi a endpoint idonei escludendo però il monitoraggio degli abusi, l’elaborazione delle immagini, i file o gli strumenti di terze parti.

Gli impegni di non addestramento meritano la stessa precisione. Il fornitore potrebbe escludere i contenuti del cliente dall’addestramento del modello di base, conservando però dati limitati per il funzionamento del servizio.

Queste distinzioni non cancellano il valore dell’impegno. Mostrano perché gli acquirenti hanno bisogno di un diagramma del flusso dei dati e di un allegato contrattuale accanto alla promessa pubblica.

Cosa dovrebbero osservare i lettori di Google News

Tre segnali mostreranno se la proprietà dei dati AI diventerà un controllo applicabile o rimarrà un rassicurante linguaggio contrattuale.

Il primo segnale è se i fornitori unificano le protezioni tra i prodotti. Le offerte per consumatori, aziende, API e cloud producono attualmente risposte diverse a domande simili.

Un fornitore chiaro dovrebbe identificare le regole di addestramento, conservazione, revisione, residenza ed eliminazione a livello di prodotto. Dovrebbe inoltre divulgare le eccezioni in linguaggio semplice.

Controlli più coerenti rafforzerebbero l’idea che le promesse di proprietà possano funzionare su larga scala. Una frammentazione continua manterrebbe il rischio concentrato nella scelta dell’account e nel comportamento dei dipendenti.

Osservate attentamente le impostazioni predefinite. Un controllo di opt-out offre meno protezione di un prodotto aziendale che esclude i contenuti dei clienti dall’addestramento prima del primo prompt.

Anche la conservazione predefinita conta. Periodi più brevi, controllati dall’amministratore, riducono le conseguenze degli errori, anche quando non possono prevenire ogni divulgazione.

Il secondo segnale è se le aziende misurano l’esposizione dei connettori prima di abilitare gli agenti. Gli inventari degli accessi e la pulizia delle autorizzazioni dovrebbero precedere un’implementazione estesa.

Le prove di un’adozione matura includeranno registri dei connettori, autorizzazioni limitate, controlli di approvazione e audit legati alle singole azioni. Le policy AI generiche non saranno sufficienti.

L’implementazione di agenti senza tali controlli indebolirebbe le garanzie dei fornitori sulla proprietà. Il sistema potrebbe esporre informazioni di proprietà del cliente tramite autorizzazioni che il cliente non è riuscito a governare.

I team di sicurezza dovrebbero testare la prompt injection indiretta e il recupero eccessivo. Dovrebbero inoltre verificare che gli assistenti non possano oltrepassare i confini tra utenti, progetti o tenant.

I test devono includere documenti realistici anziché dimostrazioni ripulite. Istruzioni nascoste in email, file condivisi, ticket di assistenza e pagine web creano percorsi di attacco pratici.

Il terzo segnale è il modo in cui autorità di regolamentazione e tribunali trattano l’addestramento, i diritti sugli output e la riservatezza. Le decisioni legali possono chiarire quali cessioni contrattuali resistono alle controversie su paternità o violazione.

L’azione normativa può anche verificare se le informative sulla privacy descrivono le pratiche effettive sui dati. Un’applicazione chiara delle norme aumenterebbe il valore di controlli precisi su conservazione e consenso.

L’incertezza persisterà tra le giurisdizioni. Le aziende non dovrebbero attendere un’unica definizione universale della proprietà dei dati AI prima di stabilire regole interne.

L’approccio più solido nel breve periodo tratta le informazioni AI come un ciclo di vita. Inizia con la raccolta e prosegue attraverso recupero, generazione, archiviazione, condivisione, eliminazione e risposta agli incidenti.

Google News continuerà a mettere in evidenza controversie sui dati di addestramento, sui prompt riservati e sui lavori generati. I lettori dovrebbero separare queste questioni invece di forzarle in un’unica domanda sulla proprietà.

I dati di addestramento riguardano ciò che gli sviluppatori usano per costruire o migliorare i modelli. La privacy dei prompt riguarda ciò che un servizio fa con l’interazione di un utente.

La proprietà degli output riguarda i diritti legali sul materiale generato. La sicurezza riguarda chi può accedere alle informazioni e quali azioni può intraprendere un sistema.

Il rischio proprietario attraversa tutte e quattro le aree. Un’azienda può possedere un input, vietarne l’uso per l’addestramento e comunque esporlo attraverso un connettore configurato male.

Può anche possedere un output in base al contratto senza disporre di una protezione esclusiva del copyright. Nessuno dei due risultati è rappresentato da una casella di controllo con l’etichetta “il cliente possiede i dati”.

Gli acquirenti enterprise dovrebbero richiedere cinque elementi concreti a ciascun fornitore. Questi includono un diagramma del flusso dei dati, un programma di conservazione, un elenco dei subfornitori, una matrice dei controlli di sicurezza e un processo di notifica degli incidenti.

Dovrebbero confrontare tali materiali con un’implementazione precisa. Le risposte relative a un chatbot pubblico non possono stabilire il comportamento di un’API enterprise, e vale anche il contrario.

I knowledge worker hanno una decisione più immediata da prendere. Prima di inviare informazioni, dovrebbero identificare l’account, la classe di dati, le applicazioni connesse e il destinatario previsto.

Se una qualsiasi risposta non è chiara, l’attività va svolta in un ambiente approvato o al di fuori dello strumento di IA. La comodità non cambia la sensibilità del materiale di origine.

Anche gli sviluppatori dovrebbero considerare il codice generato come un punto di partenza. Prima dell’uso in produzione, sono necessari una revisione della sicurezza, controlli sulle licenze, test e responsabilità umana.

I responsabili di prodotto dovrebbero definire se un assistente fornisce consulenza, redige bozze, recupera informazioni o agisce. Ogni verbo aggiuntivo crea una superficie di controllo più ampia.

I team legali dovrebbero negoziare le finalità, non solo il linguaggio relativo alla titolarità. I team di sicurezza dovrebbero verificare che la configurazione del prodotto corrisponda alle finalità negoziate.

Il procurement dovrebbe riesaminare la valutazione quando un fornitore aggiunge memoria, agenti, nuovi connettori o un altro fornitore di modelli. Cambiamenti sostanziali nelle capacità meritano una supervisione altrettanto sostanziale.

La domanda sulla titolarità ha una risposta utile, ma non è un nome stampato in un contratto. Il titolare pratico è la parte che può definire gli accessi, limitare le finalità, verificare i controlli e interrompere il trattamento.

Le organizzazioni dovrebbero verificare se detengono davvero questi poteri. Se non riescono a tracciare un singolo prompt sensibile dall’invio fino alla cancellazione, il loro controllo resta incompleto.

Ponete al vostro fornitore di IA la domanda più difficile sollevata da Google News: non limitatevi a chiedere “Possediamo i nostri dati?”. Chiedete chi può trattarli, dove restano le copie e quali impostazioni cambiano la risposta. Poi verificate tali affermazioni con un account reale, un connettore reale e informazioni rappresentative. Se il flusso documentato differisce dal sistema implementato, sospendete il rollout e colmate quella lacuna prima di ampliare l’accesso. Il programma di IA più sicuro non è quello con la policy più lunga. È quello in cui i dipendenti sanno quale ambiente utilizzare, gli amministratori possono far rispettare tale scelta e l’organizzazione può verificare cosa accade dopo ogni invio.