L'opt-out per l'IA che non esiste: cosa abbiamo scoperto controllando 17 piattaforme SaaS

Ogni piattaforma SaaS a cui avete collegato la vostra azienda sta silenziosamente decidendo, in questo momento, se i vostri contenuti addestrano il modello IA di qualcun altro. Abbiamo verificato tutte le 17 piattaforme della libreria di connettori di 8200.dev per vedere come ciascuna gestisce realmente la questione — aspettandoci di trovare interruttori a disposizione degli amministratori. Nella maggior parte dei casi non li abbiamo trovati.

Ecco cosa abbiamo scoperto. Slack include ogni workspace nell'addestramento di modelli non generativi per default — non esiste alcun interruttore nella console di amministrazione; rinunciare significa che il proprietario del workspace deve inviare un'email a [email protected] con un oggetto specifico, senza alcuna tracciabilità verificabile in seguito. Salesforce ha un'impostazione reale, ma è un interruttore di Einstein GPT sepolto in Setup, qualcosa che la maggior parte degli amministratori non sa nemmeno di dover cercare — e raggiungerlo può richiedere l'apertura di un ticket di supporto a seconda dell'edizione. La versione di Zendesk è un ticket di supporto, punto e basta. Fin AI di Intercom ha un opt-out a livello di workspace, ma risiede nell'interfaccia utente, non nell'API — nessuno al di fuori della vostra console di amministrazione può verificare che sia effettivamente impostato.

Dropbox è il caso più interessante: gli account statunitensi sono inclusi per default nelle funzionalità IA di terze parti; gli account UE, Regno Unito e Canada sono ESCLUSI per default. Stesso prodotto, stessa azienda, default opposti, a seconda di dove è registrato il vostro account — e la maggior parte dei team non ha mai verificato quale si applichi a loro. Anche WhatsApp Business è regionale: esiste un modulo di opposizione per UE, Regno Unito e Brasile; ovunque altro, semplicemente non c'è nessuna leva da azionare.

Sull'altro fronte, alcune piattaforme genuinamente non usano i vostri contenuti per l'addestramento — è un impegno contrattuale, non un'impostazione: Google Workspace, Microsoft 365, Box, Notion e GCP rientrano tutte in questa categoria. È rassicurante, ma non è nemmeno qualcosa che potete verificare cliccando nella vostra console di amministrazione — dovete fidarvi della parola del fornitore per un impegno sepolto in un accordo sul trattamento dei dati che la maggior parte delle persone non legge oltre la prima pagina.

Lo schema che emerge da tutto questo: a parte Jira e un paio di interruttori adiacenti per funzionalità IA (il matching sul codice pubblico di GitHub Copilot, le policy organizzative di GCP Vertex), non c'è quasi nessun posto dove puntare un'API e ottenere una risposta chiara. Il che è esattamente il motivo per cui questo va verificato piattaforma per piattaforma, manualmente, una volta per tutte — e poi segnalato automaticamente ogni volta che ne collegate una nuova, invece di fidarvi che qualcuno nel vostro team abbia già letto le clausole in piccolo.

Perché "qualcuno dovrebbe controllare" fallisce silenziosamente

Il motivo per cui questo problema si incancrenisce non è la negligenza. È che il controllo abituale — assegnarlo a una persona, dirle di verificare — non ha un punto di riferimento dove appoggiarsi.

Guardate di nuovo l'elenco sopra e notate cosa hanno in comune tutte le voci: la posizione risiede in un luogo che una dashboard non può vedere. In una clausola contrattuale. In un default regionale impostato al momento della registrazione. In un livello di piano che è cambiato l'ultima volta che l'ufficio acquisti ha rinnovato. In un indirizzo email a cui dovete scrivere. Non esiste una singola schermata, su nessuna di queste piattaforme, che risponda all'unica domanda a cui un team di sicurezza ha davvero bisogno di una risposta — *la mia organizzazione sta contribuendo dati di addestramento in questo momento, e lo abbiamo deciso di proposito?*

Così il controllo viene rimandato, poi dimenticato, poi ereditato. Il default vince per logoramento. E il default è stato scritto dal fornitore, ottimizzato per la roadmap IA del fornitore, non per i vostri obblighi di trattamento dati. È la stessa dinamica che abbiamo esaminato per una singola piattaforma in cosa cambia per Atlassian Jira il 17 agosto — solo che qui non si tratta di una sola piattaforma. È ogni strumento collegato che prende la propria versione della decisione, secondo i propri tempi, nel proprio nascondiglio.

Questa è una questione di conformità, non di curiosità

Se la vostra organizzazione detiene un report SOC 2, sta lavorando verso ISO 27001, o tratta dati personali ai sensi del GDPR, il contributo dei dati ricade direttamente all'interno di obblighi che già avete.

Un accordo sul trattamento dei dati descrive le finalità per cui i vostri dati possono essere utilizzati. Addestrare un modello IA di terze parti è una finalità. Se il DPA di un cliente afferma che i suoi dati sono usati per erogare il servizio, e una delle piattaforme che avete collegato sta silenziosamente alimentando quegli stessi dati nell'addestramento di un modello, il divario tra ciò che avete promesso a valle e ciò che permettete a monte spetta a voi colmarlo — non al fornitore. I revisori hanno iniziato a chiederlo direttamente, di solito in qualche forma del tipo "qualcuno dei vostri subresponsabili addestra l'IA sui vostri dati, e come lo sapete?". Una risposta difendibile ha due componenti: la posizione (quali piattaforme contribuiscono, quali sono escluse contrattualmente) e il registro della decisione (chi l'ha esaminata, quando, e cosa ha scelto). "Non abbiamo mai controllato" è l'unica risposta che fallisce completamente. Abbiamo trattato cosa si aspettano oggi i revisori in cosa richiedono davvero i revisori per la governance dell'IA nel 2026; il contributo dei dati sta diventando una voce standard proprio in quella revisione.

L'audit una tantum da eseguire ora

La buona notizia è che questo è uno dei rari elementi di governance in cui il rimedio è genuinamente economico. Non serve riprogettare nulla. Dovete trovare le impostazioni, decidere con intenzione, e mettere per iscritto la decisione. In concreto:

1. Fate l'inventario della superficie. Elencate ogni piattaforma SaaS dove risiedono realmente contenuti o metadati della vostra organizzazione. Se contiene dati clienti, dati regolamentati, o qualsiasi cosa sotto NDA, rientra nell'ambito — non solo lo strumento che vi ha scritto un'email questa settimana.
2. Individuate la posizione di ogni piattaforma. A volte è una pagina di impostazioni, a volte un ticket di supporto, a volte un opt-out via email, a volte una clausola contrattuale senza alcun controllo. Registrate dove si trova.
3. Confermate il livello di piano. Su diverse piattaforme la posizione dipende dal livello di piano — GitHub esclude i dati Business ed Enterprise dall'addestramento mentre i livelli inferiori rientrano in termini più ampi, e una migrazione può ribaltare silenziosamente la vostra posizione.
4. Decidete deliberatamente. Aderire può essere una scelta legittima; funzionalità IA migliori sono un beneficio reale. La modalità di fallimento non è il contributo — è il contributo che nessuno ha deciso. Escludete ciò che è sensibile, poi lasciate correre il resto se è questa la vostra scelta.
5. Mettetelo per iscritto, e ricontrollate a scadenza fissa. Una nota datata trasforma un default silenzioso in prova di governance, e i fornitori cambiano i default abbastanza spesso che una posizione esaminata una volta non è una posizione gestita.

La descrizione onesta di quell'elenco è *ricorrente, multipiattaforma e noiosa* — esattamente il tipo di controllo che marcisce quando dipende dal fatto che una persona se ne ricordi.

Come ci è apparso quando abbiamo eseguito questo controllo su noi stessi

Il 31 luglio 2026 abbiamo aperto la console di amministrazione della nostra organizzazione Atlassian e percorso i cinque passaggi sopra descritti. Riportare il risultato con precisione conta, perché funziona in entrambe le direzioni.

Il controllo a livello organizzativo era già disattivato. Atlassian Administration → Security → Data contribution offre un'unica scelta On/Off a livello organizzativo — non una per ogni prodotto — e la nostra era impostata su Off, con un elenco di inclusione vuoto, quindi nulla era stato riattivato selettivamente. Niente da correggere. Questo è l'aspetto di un buon default, o di una buona decisione precedente.

Poi c'è la frase stampata direttamente sotto quel controllo: *"I metadati sono sempre contribuiti."* L'interruttore che avevamo impostato governa i contenuti in-app — le cose che le persone scrivono nei ticket e nelle pagine. I metadati si trovano al di fuori di esso, e nel nostro piano la pagina non offre alcun controllo al riguardo. Il nostro abbonamento Jira è Premium; l'opt-out completo dei metadati è una funzionalità di Cloud Enterprise. Un banner su ogni schermata di amministrazione riporta la data in cui la modifica entra in vigore: 17 agosto 2026.

Quindi un'organizzazione che aveva già fatto la scelta deliberata, su un piano a pagamento, non poteva comunque escludersi completamente — e l'unico modo per scoprirlo era leggere una riga di testo su una pagina di impostazioni che non aveva particolari motivi per rivisitare. Bitbucket e Trello, nel frattempo, vengono fatturati separatamente e si trovano completamente al di fuori di quella pagina; qualunque sia la loro posizione, è un controllo diverso su una schermata diversa.

Nulla di tutto ciò è una critica ad Atlassian, che perlomeno rende visibile il controllo, ne dichiara chiaramente il limite, e pubblica la data. È l'argomentazione di questo articolo, dimostrata su noi stessi: la decisione e i suoi limiti risiedono dove nessuna dashboard li mostra, e "l'abbiamo disattivato" non è la stessa cosa di "non stiamo contribuendo".

Come 8200.dev segnala tutto questo automaticamente

8200.dev ora solleva un rilievo sulla posizione di addestramento IA per ogni piattaforma che collegate. Collegate Slack, Dropbox, Salesforce, GitHub, o qualsiasi altra delle piattaforme supportate, e la scansione vi dice — proprio accanto ai vostri rilievi su condivisione e permessi — se quel fornitore usa i vostri dati per l'addestramento IA per default, dove si trova l'opt-out o la garanzia contrattuale, e quando quella posizione è stata verificata l'ultima volta. Le piattaforme con opt-in per default emergono come rilievi che richiedono una decisione; le piattaforme contrattualmente sicure emergono come attestazioni che potete consegnare a un revisore.

Dove una piattaforma espone effettivamente una policy leggibile via API su un asse adiacente, la verifichiamo dal vivo: il connettore GitHub legge l'impostazione di corrispondenza sul codice pubblico di Copilot della vostra organizzazione, e il connettore GCP segnala quando Vertex AI è in esecuzione senza alcuna policy organizzativa che lo vincoli. Ogni rilievo è corredato di un playbook di remediation passo dopo passo, e il catalogo completo dei controlli si trova nella pagina delle funzionalità.

Il punto non è che le funzionalità IA siano pericolose — molte vale la pena attivarle. Il punto è che il contributo dei dati dovrebbe essere una decisione, non un default, su ogni piattaforma che la vostra organizzazione già utilizza. Se preferite che questo venga segnalato automaticamente piuttosto che ricordato manualmente, consultate piani e prezzi e collegate la vostra prima piattaforma in pochi minuti.