Rovo und die neue Atlassian-Datenpraxis: Welche Settings vor dem 17. August zu prüfen sind

Atlassian nutzt ab dem 17. August 2026 Kundendaten aus Jira, Confluence und Jira Service Management, um die eigenen KI-Modelle weiterzuentwickeln – einschließlich Rovo. Welche Daten betroffen sind, was Kunden konfigurieren können und welche Schritte vor dem Stichtag nötig sind, beantwortet dieser Beitrag.

Die Änderung betrifft nach Atlassians Angaben rund 300.000 Kundenorganisationen weltweit und zählt damit zu den weitreichendsten Anpassungen der Atlassian-Cloud-Datenpraxis seit Einführung der Cloud-Produkte. Atlassian begründet die Veränderung mit dem Anspruch, die KI-Funktionen branchenweit konkurrenzfähig weiterzuentwickeln.

Was ändert sich am 17. August 2026 bei Atlassian?

Atlassian beginnt am 17. August 2026 damit, Metadaten und – abhängig von Plan und Konfiguration – auch In-App-Inhalte aus den Cloud-Produkten Jira, Confluence und Jira Service Management zur Verbesserung der eigenen KI-Angebote zu nutzen. Im Fokus stehen die Funktionen rund um Rovo Search, Rovo Chat und die Rovo Agents.

Bisher wurden Inhalte aus den Atlassian-Cloud-Produkten ausschließlich verwendet, um die Anwendung für die jeweilige Kundenorganisation zu betreiben. Künftig fließen sie – nach Anonymisierung und Aggregation – auch in die Verbesserung der Anwendungen für alle Kunden ein.

Ist die Atlassian-Datenpraxis ab August 2026 ein Datenschutzvorfall?

Nein. Es handelt sich nicht um einen Datenschutzvorfall. Atlassian kommuniziert die Veränderung transparent und stellt mit den neuen Data-Contribution-Settings die nötigen Steuerungsmöglichkeiten bereit.

Für bestimmte Organisationen reicht das allerdings nicht aus. Wer in einer regulierten Branche arbeitet oder EU-Daten-Residenz-Anforderungen erfüllen muss, sollte die Veränderung systematisch prüfen.

Wann tritt die Atlassian Data Contribution in Kraft?

Der Rollout läuft seit April 2026 in drei Etappen:

• 16. April 2026: Atlassian beginnt mit dem Rollout der Data-Contribution-Settings in der Atlassian-Administration. Organisationen werden in der Anwendung benachrichtigt, sobald die Einstellungen für sie verfügbar sind.
• 19. Mai 2026: Die Settings sind flächendeckend ausgerollt. Ab diesem Datum besteht eine 90-tägige Vorbereitungszeit für interne Abstimmungen.
• 17. August 2026: Die geänderten Nutzungsbedingungen treten in Kraft. Atlassian verarbeitet ab diesem Stichtag Daten gemäß der jeweils aktiven Konfiguration.

Eine spätere Anpassung der Settings bleibt jederzeit möglich. Für die Bewertung relevanter Compliance-Anforderungen zählt jedoch der Zustand am 17. August 2026.

Welche Daten nutzt Atlassian künftig zur KI-Verbesserung?

Atlassian unterscheidet zwei Datenkategorien: Metadaten und In-App-Daten. Die eine können Cloud-Kunden kontrollieren, die andere ist abhängig vom Plan.

Was sind Metadaten in der Atlassian Data Contribution?

Metadaten sind statistische Charakteristika und aggregierte Muster über Inhalte hinweg, ohne dass die Inhalte selbst übertragen werden. Atlassian unterteilt sie in zwei Untergruppen:

• Content Attributes sind numerische und strukturelle Eigenschaften: Story-Point-Anzahl eines Jira-Vorgangs, Komplexität einer Confluence-Seite, Status- und Workflow-Konfigurationen.
• Common Patterns sind Phrasen, Stichwörter und Themen, die Atlassian aus Suchanfragen, Rovo-Chat-Konversationen und Konfigurationsdaten extrahiert – allerdings nur dann, wenn sie über viele Kunden hinweg häufig vorkommen.

Ausdrücklich nicht enthalten sind Namen, E-Mail-Adressen, Gesundheitsdaten, Finanzdaten und Standortdaten.

Was sind In-App-Daten in der Atlassian Data Contribution?

In-App-Daten sind die Inhalte, die Anwender in den Atlassian-Produkten erstellen:

• Titel und Texte von Confluence-Seiten
• Titel, Beschreibungen und Kommentare von Jira-Vorgängen
• Eigene Emoji-Bezeichnungen
• Individuelle Status- und Workflow-Namen

Das ist die sensible Kategorie. Atlassian wendet auch hier Anonymisierungs- und Aggregationsverfahren an. Für die Compliance-Bewertung bleibt entscheidend, dass es sich um den eigentlichen Arbeitsinhalt der Organisation handelt – nicht um statistische Nebenprodukte.

Welche Default-Einstellungen gelten für welchen Atlassian-Plan?

Die Defaults richten sich nach dem höchsten aktiven Plan in der jeweiligen Atlassian-Organisation. Wer beispielsweise parallel Confluence Standard und Jira Premium nutzt, erhält die Defaults nach Premium-Logik.

Daraus folgen drei praktische Konsequenzen:

• Die In-App-Data-Contribution lässt sich in jedem Plan deaktivieren – auch auf Free und Standard, wo sie standardmäßig aktiv ist.
• Ein vollständiger Opt-out für Metadaten ist nur in Enterprise-Plänen möglich.
• Wer mehrere Atlassian-Organisationen verwaltet, muss jede einzeln konfigurieren. Die Settings werden auf Organisationsebene gepflegt.

Wie kann ich die Atlassian Data Contribution deaktivieren?

Die Settings finden sich in der Atlassian-Administration unter Security → Data Contribution. Organisations-Admins können dort die In-App-Data-Contribution für ihre gesamte Org mit einem Klick deaktivieren. Die Änderung wirkt sofort und kann jederzeit rückgängig gemacht werden.

Wer mehrere Atlassian-Organisationen verwaltet – etwa für unterschiedliche Geschäftsbereiche oder Tochterunternehmen –, muss die Konfiguration in jeder Organisation separat vornehmen.

Welche Schutzmechanismen wendet Atlassian an?

Atlassian beschreibt für die beigetragenen Daten ein mehrstufiges Schutzkonzept:

• Anonymisierung und Aggregation vor jeder Nutzung zur Modellverbesserung
• Entfernung direkter Identifikationsmerkmale wie Namen und E-Mail-Adressen
• Zusätzliche Kontrollen gegen Re-Identifikation
• Filterung seltener Phrasen bei den Common Patterns, sodass kundenspezifische Informationen nicht in die aggregierten Muster gelangen
• Begrenzter Mitarbeiterzugriff mit Monitoring auf beigetragene In-App-Daten

Aus Compliance-Sicht bleibt zu beachten: Anonymisierung ist ein Verfahren, kein binärer Zustand. Die Wirksamkeit hängt davon ab, wie umfassend die Aggregation greift und wie die Re-Identifikations-Kontrollen technisch ausgestaltet sind. Atlassian hat hierzu keine vollständige technische Spezifikation veröffentlicht. Hinzu kommt, dass selbst wirksam anonymisierte Daten nach europäischer Datenschutzlogik dann noch als personenbezogen gelten können, wenn der Verantwortliche mit hinreichender Wahrscheinlichkeit weiterhin auf den Personenbezug zurückschließen könnte. Diese Frage lässt sich nicht aus der Vogelperspektive beantworten, sondern setzt eine fallspezifische Prüfung voraus.

Werden Atlassian-Kundendaten in den USA verarbeitet?

Ja, das ist möglich. Atlassians Sub-Processor-Liste (Stand Mai 2026) zeigt, dass an der KI-Verarbeitung mehrere Anbieter beteiligt sind:

• OpenAI – Standorte in den USA
• Google Vertex AI – Standorte in den USA, Belgien, Niederlanden, Finnland
• AWS Bedrock – mehrere Regionen
• Databricks – Standorte in den USA

Beigetragene Daten können also in die USA fließen. Datenschutzrechtlich sind solche Übermittlungen nicht automatisch unzulässig – sie sind unter dem EU-US Data Privacy Framework (DPF) und Standardvertragsklauseln (SCCs) grundsätzlich möglich. Beide Mechanismen werden von Atlassian genutzt.

Allerdings: Das DPF ist seit seiner Einführung politisch wiederholt unter Druck geraten, insbesondere durch die Entwicklungen rund um die Schrems-Rechtsprechung. Wer seine Compliance-Strategie auf den DPF allein gestützt hat, sollte die Konstruktion mit Blick auf die Rovo-Datenpraxis erneut bewerten.

Schließt EU-Daten-Residenz die KI-Trainings-Pipelines aus?

Diese Frage hat Atlassian öffentlich bisher nicht abschließend geklärt. Das Daten-Residenz-Angebot deckt nach öffentlich verfügbaren Informationen primär die Speicherung von Daten ab. Ob die Trainings-Pipelines Bestandteil der Residenz-Garantie sind und ob das Aktivieren der Daten-Residenz die Data-Contribution-Einstellungen überschreibt, bleibt in den derzeit verfügbaren Quellen offen.

Empfehlung für EU-Kunden: Diese Klärung mit Verweis auf die einschlägige Vertragsklausel oder Dokumentation schriftlich von Atlassian einholen – nicht als allgemeine Zusicherung.

Welche Fragen sollten Compliance-Verantwortliche an Atlassian richten?

Mehrere Punkte bleiben in der öffentlichen Atlassian-Dokumentation offen. Diese vier Fragen sollten Compliance-Verantwortliche schriftlich klären – und die Antworten als Teil der eigenen Compliance-Dokumentation sichern:

• EU-Daten-Residenz und Trainings-Pipelines: Schließt die aktivierte Residenz die Verarbeitung in den US-basierten Sub-Processor-Pipelines aus?
• Sub-Processor-Zuordnung: Welche Sub-Processoren verarbeiten welche Datenkategorien und in welchen Ländern?
• Datenschutz-Folgenabschätzung: Hat Atlassian für diese Veränderung eine DPIA durchgeführt und veröffentlicht?
• Rechtsgrundlage: Welche Rechtsgrundlage wird im aktualisierten DPA für die Verarbeitung in der Verantwortlichen-Rolle benannt?

Was sollten Atlassian-Kunden bis zum 17. August 2026 konkret tun?

Die richtige Vorgehensweise hängt vom Profil der Organisation ab. Dies sind vier typische Konstellationen:

Alle Kunden – das Mindestmaß

Unabhängig von Branche und Plan sollte jede Atlassian-Cloud-Organisation diese Schritte bis zum 17. August abgeschlossen haben:

• Data-Contribution-Settings in der Atlassian-Administration prüfen
• Konfiguration mit IT-Sicherheit und Datenschutz abstimmen
• In-App-Data-Contribution gegebenenfalls deaktivieren
• Konfigurationsentscheidung dokumentieren – wer entschieden hat, auf welcher Grundlage und mit welcher Begründung

Kunden mit EU-Daten-Residenz-Anforderung

Schriftliche Klärung mit Atlassian einholen, ob die aktivierte Residenz die Trainings-Pipelines mit einschließt. Die Antwort sollte mit Verweis auf die einschlägige Vertragsklausel erfolgen.

Kunden in regulierten Branchen

Datenschutzbeauftragte und Compliance-Funktion frühzeitig einbeziehen – idealerweise vor dem 19. Mai, spätestens deutlich vor dem 17. August. Aktualisiertes Data Processing Addendum prüfen. Rechtsgrundlage für die Verarbeitung in der Verantwortlichen-Rolle klären und nach den Vorgaben der internen Datenschutzdokumentation festhalten. Bei branchenrechtlichen Anforderungen – etwa BaFin, BSI – mit den dafür Zuständigen abstimmen.

Enterprise-Kunden

In Enterprise-Plänen sind In-App-Data- und Metadaten-Beitragung standardmäßig deaktiviert. Trotzdem: Defaults aktiv prüfen, dokumentieren und als bewusste Entscheidung festhalten – nicht als stillschweigende Annahme.

Wie unterstützt Seibert Solutions Cloud-Kunden bei der Atlassian-Datenpraxis-Änderung?

Als Atlassian Platinum Solution Partner begleiten wir Cloud-Kunden in DACH durch genau diese Art von Veränderungen. Es gibt drei konkrete Anschlusspunkte:

• Einordnung der spezifischen Situation: In einem strukturierten Erstgespräch ordnen wir die Änderung für Ihre Konstellation ein – Plan, Branche, Daten-Residenz-Setup, regulatorisches Umfeld. Sie erhalten eine klare Empfehlung, welche Settings für Ihre Organisation richtig sind, welche Fragen Sie Atlassian stellen sollten und welche internen Abstimmungen vor dem 17. August zu führen sind. Das Erstgespräch ist kostenlos und dauert in der Regel 30 bis 60 Minuten.
• Strukturierte Vorbereitung auf den Stichtag: Falls Sie die verbleibenden Wochen systematisch nutzen möchten, unterstützen wir Sie mit einem strukturierten Vorgehen – inklusive Checkliste, Stakeholder-Abstimmung und Konfigurations-Workshop.
• KI-Strategie grundsätzlich schärfen: Wenn Sie diese Veränderung zum Anlass nehmen möchten, Ihre KI-Strategie weiterzuentwickeln – Reifegrad, Use-Cases, Governance-Modell –, laden wir Sie zu unserer KI-Transformationsberatung ein.

→ Erstgespräch vereinbaren

Häufig gestellte Fragen zur Atlassian Data Contribution

Quellen und weiterführende Informationen

• Übersichtsseite zur Datenpraxis: atlassian.com/trust/ai/data-contribution
• FAQs zur Data Contribution: atlassian.com/trust/ai/data-contribution/faqs
• Atlassian-Webinar zur Veränderung (verfügbar als Aufzeichnung): atlassian.com/webinars/enterprise-cloud/data-contribution
• Dokumentation zu den Datentypen: support.atlassian.com/security-and-access-policies/docs/what-types-of-data-does-my-organization-contribute/
• Dokumentation zu den Settings: support.atlassian.com/security-and-access-policies/docs/data-contribution-settings/
• Atlassian Data Processing Addendum (Stichtag 17. August 2026): atlassian.com/legal/data-processing-addendum (Insbesondere relevant: die Klausel zur Verarbeitung de-identifizierter und aggregierter Daten zur Verbesserung der Cloud-Produkte sowie die Bestimmungen zur Verantwortlichen-Rolle Atlassians. Diese Stellen sollten Datenschutzbeauftragte vor dem 17. August im Kontext der eigenen Auftragsverarbeitungsdokumentation prüfen)

Hinweis: Dieser Beitrag bietet keine Rechtsberatung. Für die konkrete Bewertung der eigenen Situation – insbesondere in regulierten Branchen – empfehlen wir die Einbindung der eigenen Datenschutz- und Compliance-Funktion sowie gegebenenfalls externer Rechtsberatung. Stand: April 2026.