Atlassian sta addestrando l'IA sui dati del vostro Jira? Ecco cosa cambia dal 17 agosto

Se amministrate un sito Jira, Confluence o Jira Service Management, Atlassian vi ha probabilmente già inviato un'email sulle nuove impostazioni di "data contribution". Ecco cosa significa realmente e cosa fare al riguardo entro il 17 agosto 2026.

Cosa sta cambiando: Atlassian sta introducendo controlli a livello di organizzazione in Atlassian Administration (Security → Data contribution) che regolano se i vostri metadati e i contenuti in-app vengano utilizzati per addestrare i modelli IA di Atlassian e migliorare le sue funzionalità basate sull'IA su Jira, Confluence, JSM e le app Platform collegate. A partire dal 17 agosto 2026, Atlassian inizierà a utilizzare i vostri dati secondo queste impostazioni — configurate da voi, oppure lasciate sul valore predefinito.

La parte che sfugge alla maggior parte degli admin: il vostro controllo su questo aspetto dipende interamente dal piano sottoscritto. Solo i clienti Cloud Enterprise possono disattivare completamente la contribuzione dei metadati. Tutti gli altri livelli — Free, Standard, Premium — contribuiscono i metadati automaticamente, senza alcuna possibilità di disattivare l'opzione. Ciò che di solito potete controllare, indipendentemente dal piano, sono i contenuti in-app: potete escludere dalla contribuzione specifici spazi Confluence, progetti Jira o connettori Teamwork Graph, anche se non potete disattivare del tutto l'impostazione.

Cosa fare concretamente: andate su Atlassian Administration → Security → Data contribution e verificate cosa è già configurato. Confermate il piano attivo più elevato della vostra organizzazione (è quello che determina i valori predefiniti — anche una singola licenza Enterprise presente ovunque nella vostra organizzazione cambia il calcolo per tutto ciò che ne fa parte). Se la vostra organizzazione gestisce dati di clienti, informazioni soggette a regolamentazione o qualsiasi cosa coperta da un accordo sul trattamento dei dati, decidete consapevolmente se specifici progetti o spazi debbano essere esclusi, invece di ereditare qualunque sia il valore predefinito.

Questa è un'unica impostazione, su un'unica piattaforma. Se la vostra organizzazione utilizza anche Slack, Notion, GitHub, Salesforce o una mezza dozzina di altri strumenti SaaS collegati, ciascuno di essi sta silenziosamente prendendo la propria versione di questa stessa decisione per vostro conto — alcuni con un interruttore visibile, altri (come l'addestramento ML non generativo di Slack) senza alcun interruttore, con opt-out possibile solo via email. Questo schema — impostazioni reali, scadenze reali, conseguenze reali, sepolte in un pannello di amministrazione che nessuno ha il compito di controllare — è esattamente ciò che i connettori di 8200.dev sono progettati per far emergere automaticamente, su tutte le piattaforme che avete collegato, non solo su quella che questa settimana vi ha inviato un'email.

La decisione che nessuno aveva il compito di prendere

Allontanatevi per un momento da Atlassian e osservate la forma del problema, perché si ripete ovunque.

Ogni fornitore SaaS che sviluppa funzionalità IA affronta la stessa domanda: da quali dati dei clienti possono apprendere i modelli? Ogni fornitore risponde in modo diverso, pubblica la risposta in un luogo diverso e offre ai clienti un grado di controllo diverso:

• Slack utilizza per impostazione predefinita i messaggi e i contenuti dei clienti per addestrare modelli di machine learning non generativi a livello di piattaforma (ranking di ricerca, raccomandazioni). Non esiste alcun interruttore per gli admin nelle impostazioni del workspace — l'opt-out richiede che il proprietario del workspace scriva un'email all'indirizzo feedback di Slack per farne richiesta.
• Dropbox espone un'impostazione "third-party AI" il cui valore predefinito dipende da dove risiede il vostro account: attivo per impostazione predefinita per gli account USA, disattivato per impostazione predefinita in UE, Regno Unito e Canada. Due organizzazioni con piani Dropbox identici possono avere posture opposte senza mai saperlo.
• GitHub traccia il confine in base al piano: i dati dei clienti Business ed Enterprise sono contrattualmente esclusi dall'addestramento dei modelli, mentre i livelli inferiori sono coperti da termini di prodotto più ampi. La stessa organizzazione può cambiare livello e modificare silenziosamente la propria postura.
• Salesforce, Zendesk e Intercom hanno ciascuno i propri valori predefiniti e i propri percorsi di opt-out — una pagina di Setup, un ticket di supporto, un'impostazione del workspace.
• Google Workspace, Microsoft 365, Notion e Box si collocano sul lato opposto: i loro termini stabiliscono contrattualmente che i contenuti dei clienti non vengono utilizzati per addestrare i modelli, quindi non esiste alcun interruttore perché non ne serve uno. Questa è una postura genuinamente diversa — ma dovete comunque conoscerla ed essere in grado di indicarla a un auditor.

Notate ciò che accomuna tutti questi casi: nessuno di essi espone un'API interrogabile per chiedere "la mia organizzazione sta contribuendo dati di addestramento in questo momento?" La postura risiede in contratti, email, valori predefiniti regionali, livelli di piano. È reale, ha conseguenze, ed è invisibile a qualsiasi dashboard consultato dal vostro team di sicurezza.

Ecco perché "qualcuno dovrebbe controllare" fallisce come controllo. Non esiste un luogo dove controllare. La decisione ricade su qualunque scelta abbia fatto il fornitore, e il fornitore ha scelto secondo i propri incentivi.

Cosa significa questo per la conformità

Se la vostra organizzazione detiene un report SOC 2, sta lavorando verso ISO 27001, o tratta dati personali ai sensi del GDPR, la questione della contribuzione dei dati non è una curiosità facoltativa — ricade direttamente all'interno dei vostri obblighi esistenti.

Gli accordi sul trattamento dei dati descrivono le finalità per cui un responsabile del trattamento può utilizzare i vostri dati. Un fornitore che addestra modelli IA sui vostri contenuti costituisce una *finalità*. Se il vostro DPA con un cliente afferma che i suoi dati vengono utilizzati per fornire il servizio, e una delle piattaforme collegate sta silenziosamente alimentando quegli stessi dati nell'addestramento di un modello, il divario tra ciò che avete promesso a valle e ciò che consentite a monte spetta a voi colmarlo — non al fornitore.

Gli auditor hanno iniziato a chiedere direttamente su questo. La domanda compare nei questionari di valutazione del rischio fornitori in qualche variante di "qualcuno dei vostri subresponsabili utilizza i vostri dati per addestrare modelli IA, e come lo sapete?" Una risposta difendibile ha due parti: la *postura* (quali piattaforme contribuiscono, quali sono contrattualmente escluse) e la *registrazione della decisione* (chi l'ha esaminata, quando, e cosa ha scelto). "Non abbiamo mai verificato" è l'unica risposta sbagliata. Abbiamo trattato più in generale cosa richiedono oggi gli auditor in materia di governance dell'IA in cosa richiedono realmente gli auditor per la governance dell'IA nel 2026 — la contribuzione dei dati sta diventando una voce standard proprio in quella revisione.

La buona notizia: questo è uno dei rari elementi di conformità in cui la soluzione è genuinamente economica. Non serve riprogettare nulla. Dovete *trovare* le impostazioni, *decidere* con intenzione, e *mettere per iscritto la decisione*.

Una checklist per gli admin in vista del 17 agosto

Ecco il passaggio concreto da effettuare prima della scadenza di Atlassian, generalizzato in modo da poterlo applicare a ogni piattaforma che gestite:

1. Fate l'inventario della superficie. Elencate le piattaforme SaaS in cui risiedono realmente i contenuti o i metadati della vostra organizzazione — non solo Atlassian. Se contiene dati di clienti, dati regolamentati o qualsiasi cosa soggetta a NDA, rientra nell'ambito.
2. Individuate la postura di data contribution di ciascuna piattaforma. Per Atlassian: Administration → Security → Data contribution. Per le altre, il controllo può essere una pagina di impostazioni, un ticket di supporto, un opt-out via email, o una clausola contrattuale senza alcun controllo affatto.
3. Confermate il livello di piano su ogni piattaforma in cui la postura dipende dal livello. Su Atlassian, il piano attivo più elevato della vostra organizzazione imposta i valori predefiniti per tutto ciò che vi appartiene. Su GitHub, il livello determina se l'esclusione contrattuale vi copre.
4. Decidete con intenzione. Aderire è una scelta legittima — funzionalità IA migliori rappresentano un beneficio reale. La modalità di fallimento non è la contribuzione; è la contribuzione che *nessuno ha deciso*. Escludete i progetti e gli spazi che contengono materiale sensibile, quindi lasciate correre il resto se è questa la vostra decisione.
5. Registrate la decisione. Una nota datata — chi ha esaminato, cosa è stato configurato, perché — trasforma un valore predefinito silenzioso in una prova di governance da poter mostrare a un auditor.
6. Riverificate secondo una pianificazione. I fornitori cambiano i valori predefiniti, aggiungono funzionalità IA e spostano le impostazioni. Una postura esaminata una sola volta nel 2026 non è una postura gestita nel 2027.

Se questo elenco vi sembra un lavoro che qualcuno deve possedere — lo è. La versione onesta di questo problema è che si tratta di qualcosa di *ricorrente, multi-piattaforma e noioso*, che è esattamente il tipo di controllo che si deteriora silenziosamente quando dipende da una persona che deve ricordarsene.

Come 8200.dev fa emergere tutto questo automaticamente

8200.dev ora solleva un finding sulla postura di addestramento IA per ogni piattaforma che collegate. Collegate Jira, Slack, Dropbox, GitHub, Salesforce o qualsiasi altra piattaforma supportata, e la scansione vi dice — accanto ai vostri finding su condivisione e permessi — se quel fornitore utilizza i vostri dati per l'addestramento IA per impostazione predefinita, dove si trova l'opt-out o la garanzia contrattuale, e quando quella postura è stata verificata l'ultima volta. Le piattaforme con opt-in predefinito emergono come finding che richiedono una decisione; le piattaforme contrattualmente sicure emergono come attestazioni che potete mostrare agli auditor.

Quando una piattaforma *espone* effettivamente una policy IA leggibile via API su un asse collegato, la verifichiamo dal vivo: il connettore GitHub legge la policy di corrispondenza del codice pubblico Copilot della vostra organizzazione, e il connettore GCP verifica se Vertex AI è in esecuzione senza alcuna policy organizzativa che lo vincoli. Ogni finding include un playbook di remediation passo dopo passo, e il catalogo completo dei controlli è disponibile sulla pagina delle funzionalità.

Il punto non è che le funzionalità IA siano pericolose. Il punto è che *la contribuzione dei dati dovrebbe essere una decisione, non un valore predefinito* — su Atlassian prima del 17 agosto, e su ogni altra piattaforma che la vostra organizzazione già utilizza. Se volete che questa decisione emerga automaticamente invece di dover essere ricordata manualmente, consultate piani e prezzi e collegate la vostra prima piattaforma in pochi minuti.