Atlassian stellt die standardmäßige Nutzung von Kundendaten für das Training von KI um

• Kundenmetadaten und In-App-Inhalte aus Atlassian-Cloud-Produkten wie Jira und Confluence sollen ab dem 17. August 2026 standardmäßig für das Training von Rovo und Rovo Dev genutzt werden
• Je nach Tarif gelten unterschiedliche Standardeinstellungen: Bei Free, Standard und Premium ist der Metadatenbeitrag immer aktiviert, nur Enterprise behält standardmäßig deaktivierte Metadaten- und In-App-Daten sowie die Kontrolle darüber
• Zu den erfassten Daten zählen Metadaten wie Lesbarkeits-Scores, Story Points und SLA-Werte sowie In-App-Daten wie Seiteninhalte, Issue-Beschreibungen, Kommentare und Workflow-Namen
• Schutzmaßnahmen wie das Entfernen direkter Identifikatoren und Aggregation werden angewendet, die beigesteuerten Daten werden jedoch bis zu 7 Jahre gespeichert; nach Löschung oder Opt-out werden In-App-Daten innerhalb von 30 Tagen entfernt und trainierte Modelle innerhalb von 90 Tagen neu trainiert
• Mit diesem Politikwechsel weg von der bisherigen Nichtnutzung verändert sich die Datenherkunft in Arbeitstools sowie das Maß an Kontrolle je nach Preisstufe, mit größeren Auswirkungen auf Privacy-, Governance- und Compliance-Bewertungen

---

Überblick über die Änderungen

• Atlassian plant, ab dem 17. August 2026 Kundenmetadaten und In-App-Inhalte aus Jira, Confluence und anderen Atlassian-Cloud-Produkten standardmäßig für KI-Training zu nutzen
  • Als betroffene KI-Funktionen werden Rovo und Rovo Dev genannt
  • Betroffen sind rund 300.000 Kunden
• Durch die Änderung der Richtlinie zur Datenbeisteuerung gelten je nach Tarif unterschiedliche Standards
  • In niedrigeren Tarifen ist ein Opt-out bei der Metadatenerfassung nicht möglich
  • Im Enterprise-Tarif bleibt die Kontrolle über die Erfassung von Metadaten und In-App-Daten erhalten
• Die Speicherdauer beigesteuerter Daten beträgt bis zu 7 Jahre
  • Nach Löschung oder Opt-out werden In-App-Daten innerhalb von 30 Tagen entfernt
  • Mit diesen Daten trainierte Modelle werden innerhalb von 90 Tagen neu trainiert, um den Beitrag zu entfernen

Technische Details

• Atlassian unterteilt die Erfassung in zwei Kategorien: Metadaten und In-App-Daten
  • Metadaten enthalten de-identifizierte Signale
  • In-App-Daten umfassen nutzergenerierte Inhalte
• Konkret genannte Elemente in der Kategorie Metadaten
  • Lesbarkeits- und Komplexitätsscores
  • Aufgabenklassifizierung
  • Metriken zur semantischen Ähnlichkeit
  • Story Points
  • Sprint-Enddaten
  • SLA-Werte in Jira Service Management
• Konkret genannte Elemente in der Kategorie In-App-Daten
  • Seitentitel und -inhalt in Confluence
  • Titel, Beschreibungen und Kommentare von Jira-Issues
  • Namen benutzerdefinierter Emojis
  • Namen benutzerdefinierter Status
  • Workflow-Namen
• Als Vorverarbeitung vor dem Training werden das Entfernen direkter Identifikatoren, Datenaggregation und weitere Schutzmaßnahmen genannt

Standardeinstellungen nach Tarif und ausgenommene Gruppen

• Die Standardeinstellung richtet sich nach dem höchsten aktiven Tarif einer Organisation
• Free- und Standard-Kunden

  • Metadatenbeitrag immer aktiviert

    • Kein Opt-out für die Metadatenerfassung
    • Der Beitrag von In-App-Daten ist standardmäßig aktiviert, die Einstellung kann aber geändert werden
    • Premium-Kunden
    • Metadatenbeitrag immer aktiviert
    • Der Beitrag von In-App-Daten ist standardmäßig deaktiviert
    • Enterprise-Kunden
    • Metadaten und In-App-Daten sind beide standardmäßig deaktiviert
    • Opt-out für Metadaten möglich
    • Genannt werden außerdem Kundengruppen, die vollständig von der Erfassung ausgenommen sind
    • Kunden mit customer-managed encryption keys
    • Kunden von Atlassian Government Cloud
    • Kunden von Atlassian Isolated Cloud
    • Kunden mit HIPAA-Verpflichtungen

Kontext und Bedeutung

• Diese Richtlinie markiert einen Kurswechsel gegenüber der bisherigen Haltung
  • Zuvor hatte Atlassian erklärt, Kundendaten nicht für das Training oder die Verbesserung von KI-Diensten zu verwenden
• Als Hintergrund wird ein Branchentrend genannt
  • SaaS-Anbieter sammeln interne Nutzungssignale und Inhalte, um Modelle zu bootstrappen, feinzujustieren und zu evaluieren
  • Gleichzeitig werden Zusagen zu de-identifizierter und aggregierter Analyse gemacht
• Von Atlassian genannte praktische Vorteile
  • bessere Suchrelevanz
  • bessere Zusammenfassungen
  • Vorlagenvorschläge
  • Optimierung agentischer Workflows
• Auswirkungen aus Sicht der Praxis
  • Veränderung der Datenherkunft der in Arbeitstools verwendeten Modelle
  • Veränderung des Datenkontrollniveaus je nach Preisstufe sowie der Maßstäbe für Compliance- und Beschaffungsentscheidungen

Risiken und Trade-offs

• Die verpflichtende Metadatenerfassung für Nicht-Enterprise-Kunden löst unabhängig von der Entfernung von Identifikatoren Bedenken bei Privacy und Governance aus
  • Telemetrie wie Story Points und SLA-Metriken kann Projektstrukturen und Leistungsmuster offenlegen
• Die 7-jährige Speicherung de-identifizierter Daten vergrößert mit der Zeit die Angriffsfläche
  • Für Kunden, die Audits zur langfristigen Datenspeicherung benötigen, entsteht zusätzlicher Aufwand
• Es gibt Ausnahmepfade für Kunden mit hohen Sicherheitsanforderungen und für Nutzer von customer-managed keys
  • Allerdings kann dafür ein Wechsel auf teurere Tarife oder spezielle Bereitstellungsformen nötig sein

Worauf zu achten ist

• Organisationen sollten ihre Atlassian-Tenants prüfen
  • Der höchste aktive Tarif pro Tenant sollte überprüft werden
  • Die standardmäßigen Einstellungen zur Datenbeisteuerung sollten ermittelt werden
• Während des Rollouts sind Aktualisierungen der Administrationskonfiguration nötig
• Wenn ein vollständiges Opt-out erforderlich ist, sollte ein Wechsel zu Enterprise oder zu isolierten Bereitstellungen geprüft werden
• Beobachtungspunkte auf Produktseite
  • Es sollte geprüft werden, wie Atlassian das Verfahren des 90-tägigen Neutrainings praktisch umsetzt
  • Es sollte geprüft werden, ob nachgelagerte LLM-Anbieter, die in Rovo verwendet werden, behaupten, Eingaben nicht zu speichern
• Falls sich dieses Muster in Enterprise-SaaS insgesamt ausbreitet, werden mögliche Kundenreaktionen und regulatorische Beobachtung erwähnt

Grundlage der Bewertung

• Diese Änderung hat praktische Auswirkungen auf Tausende Enterprise-Nutzer und auf Fachleute, die Daten-Governance und Modellherkunft verwalten
• Sie wird nicht als Durchbruch bei Spitzenmodellen oder als regulatorischer Meilenstein eingeordnet
• Bewertet wird sie als Änderung der Produktpolitik, die die Datenpipelines von Teams und ihre Compliance-Optionen praktisch verändert

[GN⁺]

Hacker-News-Kommentare

• Ich habe bei Atlassian das Gefühl, dass dort eine Panne nach der anderen passiert. Ich nutze die Produkte immer noch häufig, aber ich stoße viel zu oft auf Bugs der Kategorie P0. Besonders die self-hosted Bitbucket workers sind, vor allem auf der Docker-Seite, so veraltet, dass wir jede Menge Workarounds einbauen mussten. In JIRA muss man seit Jahren neu laden, um die Reihenfolge neuer Tickets zu ändern. Auch neue Funktionen, die in den letzten Jahren zu JIRA und Bitbucket hinzugekommen sind, liefen oft nicht richtig. Ich habe die AI-Funktionen im kostenlosen Test ausprobiert, aber sie haben überhaupt nicht funktioniert, und kündigen konnte man auch nicht online, sodass ich mehrere Support-Tickets schreiben musste; dabei ist sogar das Support-Formular mehrfach kaputtgegangen. Ich frage mich, ob diese massiven Funktionsstörungen auf technische Schulden, den Abgang von Fachkräften oder auf beides zurückgehen. In der Community sieht man Hunderte bis Tausende Bugs mit irgendwelchen Behelfslösungen

  • Für mich lässt sich das Sperren der Online-Kündigung eines kostenlosen Tests nur als Kundentäuschung erklären. So etwas ließe sich gesetzlich eigentlich sehr leicht unterbinden, aber die Politik scheint sich nicht dafür zu interessieren. Atlassian wirkt auf mich wie ein typischer Großkonzern, der eher an die Vorgesetzten der Nutzer verkauft als an die Nutzer selbst. Ab einer gewissen Größe scheint der Wettbewerbsdruck bei der Qualität nachzulassen, und dann breiten sich interne Korruption und Inkompetenz leicht aus
  • Als jemand, der dort gearbeitet hat, würde ich sagen: Die Antwort ist eine Kombination aus mangelnder Engineering-Kompetenz, zerstreuten Prioritäten und sinnlosen Reorganisationen. Bitbucket pipelines und workers wurden faktisch ursprünglich von zwei Leuten gebaut, und es ist gut möglich, dass in den letzten zehn Jahren kaum mehr als eine Person sie aktiv gewartet hat. Wenn es zuletzt auch noch Entlassungen gab, dürfte es noch schlimmer geworden sein. Das Büro existiert inzwischen physisch nicht mehr, und die Leute von damals sind alle weg
  • Für mich heißt die Ursache in einem Wort Featureitis. Man stopft einfach gedankenlos immer mehr Features hinein. Inzwischen ist womöglich sogar von AI geschriebener Code obendraufgekommen. Selbst mittelgroße Projekte landen in einem ähnlichen Zustand, wenn nur neue Funktionen gepusht werden, und einige Projekte, die ich erlebt habe, sind aus demselben Grund denselben Weg gegangen: In einem riesigen Backlog zählten nur noch abgehakte Feature-Listen
  • Ich hatte immer das Gefühl, dass die Suche in Jira praktisch unbrauchbar ist. Sie könnte der schlimmste Teil der ganzen Plattform sein, und trotzdem konzentriert man sich weiter auf Features, die ich garantiert nie benutzen werde, was mich nur frustriert zurücklässt
  • Ich finde Jira in letzter Zeit wegen kaputter Synchronisation viel zu instabil. Auf dem Sprint-Board schloss sich das Ticket-Modal ständig von selbst, sodass ich es immer wieder öffnen musste, und vor Kurzem tauchte ein Ticket auf diesem Board einfach nicht auf, egal was ich tat; später erschien dann plötzlich das Epic, und danach tauchten auch die einzelnen Tickets wieder auf. Wenn das der zusätzliche Wert von sogenanntem vibe coding in der Welt ist, dann gute Nacht

• Ich hätte gern eine bessere Quelle verlinkt, aber der Kern ist aus meiner Sicht, dass derzeit sowohl kostenlose als auch zahlende Kunden standardmäßig für die AI-Nutzung zu Trainingszwecken ihrer Daten opt-in sind. Betroffen sind sämtliche Inhalte wie Confluence-Seiten und Jira-Tickets. In der Atlassian-Support-Dokumentation steht zwar, wie man es deaktiviert, aber in unseren Instanzen ist diese Einstellung überhaupt nicht sichtbar

  • Laut der Mitteilung, die ich per Mail bekommen habe, wird die Opt-out-Einstellung ab Mai schrittweise im Admin portal ausgerollt. Zuerst für Jira, Confluence, Jira Service Management und Atlassian Platform Apps, und bis zum 19. Mai 2026 soll sie nach und nach in Atlassian Administration erscheinen; vor dem 17. August 2026 werde es außerdem noch eine weitere Benachrichtigung geben
  • Ich habe in Atlassian Administration > Security und auf diversen anderen Einstellungsseiten gesucht, konnte den Punkt Data contribution aber nirgends finden. Dann drängt sich die Frage auf, ob man derzeit automatisch opt-in ist, ohne tatsächlich eine Möglichkeit zum Opt-out zu haben
  • Ich war schockiert, als ich gesehen habe, wie weit der Umfang laut FAQ reicht. Als nutzergenerierte Inhalte zählen demnach Confluence-Titel und -Text, Jira-Issue-Titel und -Beschreibungen, Kommentare, Namen benutzerdefinierter Emojis, Namen benutzerdefinierter Status und sogar Namen von Workflows; der Umfang ist absurd weit
  • Ich mache mir Sorgen, dass sensible Informationen wie Kundendaten, private Tickets, embargoed CVE-Fixes oder sensible Gesundheitsdaten in das Modelltraining einfließen und später an völlig falsche Personen durchsickern könnten
  • Für die offizielle Erklärung der Änderung halte ich die Atlassian-FAQ für die direkteste Quelle

• Ich habe ein Gerücht gesehen, dass Anthropic über eine Übernahme von Atlassian spricht und dass es dabei vermutlich um die Trainingsdaten geht. Es gibt sogar einen Reddit-Post über angebliche Aktivitäten rund um Data Poisoning

  • Wenn das stimmt, kenne ich mindestens zwei Unternehmen, die Atlassian-Produkte nicht mehr nutzen könnten. Das wäre ein Signal, dass man Privatsphäre und regulatorische Anforderungen viel zu leichtfertig behandelt
  • Früher wurden offenbar Quellcodes von Plattformen wie GitHub abgesaugt, damit AI daraus Code generiert; jetzt fühlt es sich so an, als würde man als Nächstes Spezifikationsdokumente von Plattformen wie Atlassian absaugen, damit AI diese wieder ausspuckt. Dann fragt man sich bitter, was als Nächstes kommt — Firmenleitbilder oder Slogans zum Geldverdienen vielleicht auch noch
  • Wenn der Aktienkurs weiter fällt, könnte so eine Übernahme tatsächlich passieren

• Ich habe das Gefühl, dass sich bei Enterprise SaaS immer mehr das Muster normalisiert, standardmäßig zu sammeln statt standardmäßig abzulehnen. Hier ist es aber besonders gravierend, weil nicht nur Metadaten, sondern sämtliche Inhalte in der App betroffen sind und weil die Opt-out-Einstellung offenbar nicht einmal gerendert wird. Über die politische Entscheidung selbst kann man streiten, aber beides zusammen wirkt, als wäre Reibung absichtlich eingebaut worden. Außerdem sollte man data residency getrennt betrachten: Viele Käufer halten regionale Bindung für eine umfassende Datenschutzgarantie, dabei bedeutet sie in Wirklichkeit nur, wo etwas gespeichert wird — nicht, wer aus welchem Zweck darauf zugreifen kann

  • Besonders niederträchtig fand ich die Formulierung im The-Register-Artikel, dass die neue data contribution-Einstellung selbst dann erst am 17. August 2026 greift, wenn man den Vertrag sofort kündigt. Das heißt faktisch, dass einem nicht einmal wirklich Zeit gegeben wird, Alternativen zu prüfen

• Ich denke, viele andere Unternehmen wie GitHub, Figma, Adobe und Vercel aktivieren so etwas ebenfalls standardmäßig. Realistisch ist daher wohl, grundsätzlich davon auszugehen, dass jedes Unternehmen anvertraute Daten auch für Modelltraining verwenden könnte

  • Vielleicht wird dieses Jahr ja das Jahr von self-hosted. Dinge wie öffentliche Blogs, bei denen Privatsphäre nicht so wichtig ist, lasse ich weiter in der Cloud, aber Daten, die ich nicht für Modelltraining oder Werbevermarktung hergeben will, habe ich auf selbst gehostete Systeme in meinem eigenen Netzwerk verlagert

• Falls die Übernahme durch Anthropic stimmt, dürfte Atlassian als Gelegenheit erscheinen, sich einen kompletten hochwertigen Datensatz rund um Business-Arbeit zu kaufen

  • Manchmal stelle ich mir sarkastisch vor, es wäre vielleicht für immer erledigt, wenn stattdessen Broadcom Atlassian kaufen und damit dasselbe machen würde wie damals mit VMware
  • Ich halte die Daten in Atlassian keineswegs für einen sauberen oder natürlichen Datensatz. Es wirkt eher wie ein Ort, an dem höllisches Design die eigentliche Arbeit von Entwicklern in allen möglichen Störgeräuschen erstickt
  • Wenn dieses Gerücht bislang nur aus Spekulationen in Foren besteht, glaube ich es nicht, bevor nicht eine vertrauenswürdige Quelle auftaucht. Es klingt sonst auch nach einer Geschichte, mit der man den Kurs hochtreiben und dann abladen will

• Ich frage mich, ob Atlassian auch Code und Inhalte aus privaten Bitbucket-Repositories als erfassungsrelevant betrachtet. Die Formulierungen in Richtlinie und FAQ sind so vage, dass ich einfach eine klare Ja-oder-Nein-Antwort hören möchte

  • Als ich vor ein paar Monaten nachgesehen habe, habe ich es so verstanden, dass privater Repo-Code nicht für AI-Training verwendet wird, aber nach dieser Ankündigung werde ich ihn ohnehin auf meine eigenen Server umziehen. Cloud-Storage ist zwar bequem, aber ständig Angst haben zu müssen, dass jemand kommt und sich meine Daten aneignet, ist es einfach nicht wert
  • Wenn die Formulierung vage ist, dann ist die Antwort faktisch schon gegeben

• Früher hieß es: Wenn man nicht zahlt, ist man das Produkt. Heute wirkt es eher so, als würden Unternehmen sogar noch zahlen und dabei selbst zum Produkt werden, was die Sache noch absurder macht

• Ich möchte unbedingt darauf hinweisen, dass Atlassians data residency-Option dieses Problem nicht löst. Selbst wenn Daten an eine bestimmte Region gebunden sind, können sie weiterhin für Trainingszwecke genutzt werden

• Deshalb wirkt es für mich jetzt noch klarer, warum Atlassian den Support für Data Center on-prem zurückfahren wollte