Atlassian Intelligence Datenschutz: Data Contribution und DSGVO

Seit dem 17. August 2026 gilt bei Atlassian eine neue Regel, die viele Confluence- und Jira-Administrator:innen erst nach und nach bemerken werden: Metadaten und bestimmte Inhaltsdaten aus Ihrer Cloud-Instanz können jetzt genutzt werden, um Atlassian Intelligence und Rovo für alle Atlassian-Kunden zu verbessern - nicht mehr nur für Ihre eigene Organisation. Wer eine Confluence- oder Jira-Cloud-Instanz betreibt, sollte sich diese Woche fünf Minuten Zeit nehmen und in der Atlassian Administration nachsehen, wie die eigenen Data-Contribution-Einstellungen aktuell stehen.

Dieser Artikel ordnet ein, was „Data Contribution” bei Atlassian Intelligence konkret bedeutet, welche Opt-out-Wege es je Plan gibt, was sich für bestehende Confluence- und Jira-Kunden praktisch ändert - und wie sich das Ganze zur Datenschutz-Bewertung nach DSGVO verhält, insbesondere zur Auftragsverarbeiter-Rolle und zu den Verarbeitungsstandorten. Alle Angaben wurden am 20.08.2026 direkt gegen die offiziellen Atlassian-Quellen geprüft; wo eine Aussage nicht eindeutig an einer Primärquelle zu belegen war, ist das im Text ausdrücklich vermerkt.

Was „Data Contribution” bei Atlassian Intelligence bedeutet

Atlassian beschreibt Data Contribution in seiner Dokumentation als die Praxis, „Metadaten und In-App-Daten aus Ihrer Atlassian-Organisation” zur Verbesserung von Apps und KI-Erfahrungen zu nutzen. Bislang, so Atlassian, wurden diese Daten ausschließlich genutzt, um die Erfahrung innerhalb der eigenen Organisation zu verbessern - etwa um ähnliche Inhalte innerhalb einer Instanz zu erkennen und Suchergebnisse zu optimieren. Mit der Änderung vom 17. August 2026 beginnt Atlassian, dieselben Daten auch zu nutzen, um Apps und Erfahrungen für alle Kunden zu verbessern.

Zwei Datenarten sind dabei zu unterscheiden:

Metadaten bestehen laut Atlassian aus zwei Kategorien: „Content-Attribute” (statistische Merkmale, numerische Felder und Ableitungen aus Ihren In-App-Daten) sowie „gemeinsame Muster” (Phrasen und Begriffe, die laut Atlassian aus Suchanfragen und -ergebnissen, aus Prompts und Antworten im Rovo Chat sowie aus selbst definierten Konfigurationselementen wie benutzerdefinierten Jira-Feldern extrahiert werden).
In-App-Daten umfassen konkret: Titel und Inhalte von Confluence-Seiten; Titel, Beschreibung und Kommentare von Jira-Vorgängen; benutzerdefinierte Emoji-Namen; benutzerdefinierte Jira- oder Confluence-Statusnamen sowie benutzerdefinierte Workflow-Namen.

Wichtig für die Einordnung, was betroffen ist: Die Regeln gelten laut Atlassian zunächst für Metadaten und In-App-Daten in Jira, Confluence und Jira Service Management, einschließlich der Daten in den Atlassian-Platform-Apps (Rovo, Home, Teams, Projects, Assets, Goals, Analytics, Administration) sowie bestimmter Teamwork-Graph-Connectoren. Alle contributed Daten werden vor der Nutzung de-identifiziert und aggregiert - Informationen, die Personen direkt identifizieren (Namen, E-Mail-Adressen), werden entfernt, und Atlassian gibt an, zusätzliche Kontrollen gegen eine Re-Identifizierung einzusetzen.

Der Stichtag 17. August 2026 im Detail

Die eingangs genannte Recherche eines vorherigen Themen-Scouts nannte den 17.08.2026 als Stichtag - eine unabhängige Prüfung im Rohquelltext beider Seiten bestätigt das Datum. Die Atlassian-Support-Seite zu den Data-Contribution-Settings nennt wörtlich: „Atlassian will begin to use data according to the data contribution settings on August 17, 2026.” Das separate Data-Contribution-FAQ auf atlassian.com/trust nennt an anderer Stelle, mit eigener Formulierung, dasselbe Datum: „Starting August 17, 2026, we will begin to use customer metadata and in-app data to improve our apps and experiences for all customers.”

Bemerkenswert ist, dass an diesem Datum nicht nur die Datennutzung selbst beginnt, sondern auch ein ganzes Bündel an Vertragsdokumenten aktualisiert wird: Laut FAQ treten „unser aktualisierter Atlassian Customer Agreement, die AI Terms, das Data Processing Addendum und die Privacy Policy” zum selben Datum in Kraft. Data Contribution ist also kein isoliertes Produkt-Feature, sondern Teil eines vertraglichen Pakets, das die gesamte Datennutzung für KI-Zwecke neu fasst.

Für Ihre eigene Organisation heißt das konkret: Ihre Einstellungen in der Atlassian Administration wirken ab diesem Datum. Wer die Einstellungen erst nach dem 17.08.2026 anpasst, sorgt dafür, dass ab dem Zeitpunkt der Änderung die neue Konfiguration gilt - für den Zeitraum davor bleibt die zum 17.08.2026 vorgefundene Einstellung maßgeblich.

Opt-out je Plan: Free, Standard, Premium, Enterprise

Der wichtigste praktische Punkt für Administrator:innen ist, dass der Handlungsspielraum stark vom gebuchten Plan abhängt. Atlassian unterscheidet zwischen der Contribution von Metadaten und der Contribution von In-App-Daten - und behandelt beide unterschiedlich:

Plan	Metadaten-Contribution	In-App-Daten-Contribution
Free / Standard	Immer aktiv, nicht abschaltbar	Standardmäßig An, lässt sich auf Aus stellen
Premium	Immer aktiv, nicht abschaltbar	Standardmäßig Aus, lässt sich auf An stellen
Enterprise	Standardmäßig An, lässt sich auf Aus stellen	Standardmäßig Aus, lässt sich auf An stellen

(Stand: August 2026, Quelle: support.atlassian.com/security-and-access-policies/docs/data-contribution-settings/)

Praktisch bedeutet das: Nur auf einem Enterprise-Plan lässt sich die Metadaten-Contribution vollständig abschalten. Auf Free, Standard und Premium ist die Contribution von Metadaten in jedem Fall aktiv - Administrator:innen können hier ausschließlich die In-App-Daten-Contribution steuern (also ob Seiteninhalte, Vorgangsbeschreibungen und Kommentare einbezogen werden), nicht aber die statistischen Metadaten.

Betreiben Sie mehrere Apps mit unterschiedlichen Plänen innerhalb derselben Atlassian-Organisation, gilt laut Atlassian der jeweils höchste aktive Plan für die gesamte Organisation als Referenz für die Standardeinstellungen - eine Confluence-Standard- und eine Jira-Premium-Lizenz in derselben Organisation führen also zu den Premium-Standardwerten für die gesamte Organisation. Ein Downgrade von Enterprise auf einen niedrigeren Plan, der keine Metadaten-Abschaltoption kennt, schaltet die Metadaten-Contribution automatisch wieder ein - Atlassian kündigt das an und räumt dafür 30 Tage Vorlauf ein, bevor die neue Konfiguration greift.

Vollständig von Data Contribution ausgenommen sind laut Atlassian Organisationen mit bestimmten Compliance-Anforderungen: Kunden mit Customer-Managed Keys, Government Cloud, Isolated Cloud oder HIPAA-Konformität. Bei diesen Organisationen wird laut FAQ „keines der Metadaten oder In-App-Daten” für Data Contribution genutzt.

Wo Sie die Einstellungen finden: Data-Contribution-Einstellungen liegen unter Atlassian Administration → Sicherheit → Data Contribution auf admin.atlassian.com. Dort lässt sich die Contribution zusätzlich granular steuern - pro Atlassian-App, pro Space innerhalb einer App und pro Teamwork-Graph-Connector.

Was sich für bestehende Confluence- und Jira-Kunden praktisch ändert

Für die meisten bestehenden Kunden ändert sich zum Stichtag zunächst nichts an der Bedienung - die Konfigurationsoberfläche existierte bereits vor dem 17.08.2026, damit Organisationen sich vorbereiten konnten. Was sich ändert, ist die Wirkung der jeweils eingestellten Werte: Wer die Standardeinstellung nie angefasst hat, contributiert ab sofort tatsächlich Daten für die Verbesserung aller Atlassian-Kunden, nicht mehr nur für die eigene Instanz.

Wer die In-App-Daten-Contribution nachträglich abschaltet, sollte laut Atlassian mit einer gewissen Verzögerung rechnen: Bereits contributierte In-App-Daten werden „innerhalb von 30 Tagen” entfernt, und Modelle, die zuvor auf diesen Daten trainiert wurden, werden neu trainiert. De-identifizierte, aggregierte Daten können dagegen laut FAQ bis zu sieben Jahre aufbewahrt werden - ein Opt-out wirkt also nicht rückwirkend auf bereits aggregierte Auswertungen, sondern nur auf künftige und laufende Datennutzung sowie auf noch nicht aggregierte Rohdaten.

Für Datenschutzbeauftragte und IT-Verantwortliche ist vor allem relevant, dass die Prüfung kein einmaliger Vorgang ist: Eine einmal getroffene Grundsatzentscheidung („Contribution aus, wo möglich”) kann durch neue Spaces oder Connectoren durchbrochen werden, wenn diese nicht explizit mit ausgeschlossen werden.

Produktverbesserung oder KI-Modelltraining? Wo Atlassian die Grenze zieht

Eine der am häufigsten gestellten Fragen zu Data Contribution ist, ob damit fremde, extern gehostete KI-Modelle trainiert werden. Atlassians eigene FAQ beantwortet das vergleichsweise klar: „Wie schon heute bei allen Kundendaten teilt Atlassian keine Kundenmetadaten oder In-App-Daten mit unseren extern gehosteten LLM-Anbietern, damit diese ihre Dienste trainieren oder verbessern.” Die extern gehosteten LLM-Partner - laut Atlassians eigener Formulierung „einschließlich OpenAI, Anthropic und Google” - arbeiten demnach unter strikten „Zero Data Retention”-Vereinbarungen (ZDR): Eingaben und Ausgaben werden von diesen Anbietern nicht gespeichert und nicht zur Verbesserung ihrer eigenen Modelle verwendet.

Was Data Contribution stattdessen betrifft, ist laut Atlassian eine andere, intern begrenzte Nutzung: Atlassian kann Metadaten verwenden, um Open-Source-Modelle zu feintunen, die ausschließlich innerhalb der eigenen Atlassian-Infrastruktur betrieben werden. Diese Unterscheidung ist der Kern der ganzen Regelung - Data Contribution betrifft nicht das Training der großen, extern gehosteten Basismodelle, sondern Atlassians eigene, intern betriebene Zusatzmodelle und Produktfunktionen.

Die ergänzende Rovo-Dokumentation zur Kundendatennutzung bestätigt dieselbe Trennung noch einmal unabhängig. Für die eigene DSGVO-Bewertung heißt das: Die Data-Contribution-Einstellungen betreffen Atlassians interne Produktverbesserung, nicht das Training der zugrunde liegenden Fremdmodelle - diese Unterscheidung gehört sauber in eine eigene Datenschutz-Folgenabschätzung, weil beide Vorgänge unterschiedlichen vertraglichen Grundlagen unterliegen.

Rovo-Berechtigungen: Sieht die KI nur, was der Nutzer ohnehin darf?

Ein für die Praxis mindestens ebenso wichtiger Datenschutz-Nebenpunkt betrifft nicht Data Contribution im engeren Sinn, sondern die Frage, ob Atlassian Intelligence und Rovo bei jeder einzelnen Anfrage Inhalte respektieren, auf die der fragende Nutzer gar keinen Zugriff hätte. Atlassians eigene Dokumentation beantwortet das eindeutig mit Ja: Ein Rovo-Agent handelt „im Auftrag dieser Person” und kann deshalb „nur auf Spaces, Seiten, Vorgänge und andere Informationen zugreifen oder reagieren, auf die der Nutzer bereits Zugriff hat”. Wörtlich heißt es weiter: Hat ein Nutzer keinen Zugriff auf eine Seite, kann der Agent nichts zu dieser Seite antworten; kann ein Nutzer nicht kommentieren, kann der Agent nicht kommentieren; kann ein Nutzer eine Confluence-Seite nicht löschen, kann der Agent sie ebenfalls nicht löschen.

Die separate Dokumentation zu Rovos Daten- und Nutzungsrichtlinien ergänzt, dass Rovo sich mit den Zugriffskontrollen und Berechtigungseinstellungen verbundener Drittanbieter-Apps und der eigenen Atlassian-Apps synchronisiert, damit Nutzer „nur Inhalte sehen, auf die sie Zugriff haben” - und dass Berechtigungsänderungen laufend überwacht und in den Rovo-Suchindex nachgezogen werden.

Für die Praxis bleibt trotzdem ein Punkt, den Sie selbst prüfen müssen, bevor Sie sich auf diese Zusicherung verlassen: Die Berechtigungslogik funktioniert nur so gut wie die zugrunde liegende Confluence- und Jira-Berechtigungsstruktur selbst. Bereits bestehendes Oversharing - zu offene Space-Berechtigungen, veraltete Freigaben, unklar dokumentierte Zugriffsgruppen - wird durch Rovo nicht behoben, sondern lediglich durchgereicht: Was ein Nutzer heute versehentlich sehen darf, kann er künftig auch über eine KI-Antwort erfragen. Das Prinzip von Berechtigungshygiene vor KI-Sichtbarkeit gilt bei Microsoft 365 Copilot genauso wie bei Confluence und Rovo - genau darum gewinnen Governance-Themen wie Schatten-KI und Oversharing gerade jetzt an Bedeutung.

Datenschutz-Einordnung: Auftragsverarbeiter-Rolle und Verarbeitungsstandorte

Für die DSGVO-Bewertung sind zwei Fragen zu trennen: Wer verarbeitet in welcher Rolle, und wo findet die Verarbeitung statt?

Zur Rolle: Atlassians Data Processing Addendum (DPA) stellt unverändert klar, dass Atlassian als Auftragsverarbeiter tätig wird: „Atlassian is a Processor (or respectively, a Sub-processor) of Customer Data”, während der Kunde „entweder Verantwortlicher der Kundendaten ist oder als Auftragsverarbeiter im Auftrag eines anderen Verantwortlichen handelt”. Diese grundsätzliche Rollenverteilung ändert sich durch die Data-Contribution-Regeln nicht - was sich ändert, ist die aktualisierte Fassung des DPA selbst, die laut Atlassian zusammen mit dem Customer Agreement, den AI Terms und der Privacy Policy zum 17.08.2026 in Kraft tritt. Das DPA erlaubt Atlassian im Übrigen ausdrücklich, Kundendaten zu de-identifizieren und zu aggregieren und diese aggregierten Daten zur Produktverbesserung zu nutzen - die vertragliche Grundlage für Data Contribution ist also direkt im DPA verankert, nicht nur in einer separaten Produktdokumentation.

Zu den Verarbeitungsstandorten: Atlassians öffentliche Unterauftragsverarbeiter-Liste weist für die KI-Funktionen konkrete Standorte aus. Für OpenAI L.L.C. als Anbieter generativer KI-Funktionen für Atlassian Intelligence, Loom AI und Rovo nennt die Liste als Verarbeitungsort ausschließlich die USA. Für Amazon Web Services (AWS Bedrock), ebenfalls als KI-Dienstleister für Atlassian Intelligence und Rovo gelistet, werden dagegen sowohl die USA als auch EU-Standorte genannt (laut Liste unter anderem Deutschland, Schweden, Italien, Spanien). Für Ihre eigene Bewertung bedeutet das: Je nachdem, welches Modell und welchen Anbieter eine konkrete Atlassian-Intelligence- oder Rovo-Funktion im Hintergrund nutzt, kann die Verarbeitung vollständig innerhalb der EU stattfinden - oder eben in die USA gehen. Eine pauschale Aussage „Atlassian verarbeitet KI-Anfragen in der EU” lässt sich aus den öffentlichen Angaben nicht ableiten; die Sub-Prozessoren-Liste ist hier die maßgebliche, aber auch die volatilste Quelle und sollte vor jeder eigenen Bewertung erneut geprüft werden (Stand: August 2026).

Dieser Abschnitt ersetzt keine Rechtsberatung und ist keine abschließende datenschutzrechtliche Bewertung Ihrer konkreten Verarbeitungssituation - er ordnet lediglich ein, was Atlassian öffentlich zu Rolle und Standorten dokumentiert. Für eine belastbare Einschätzung braucht es in der Regel eine eigene Auftragsverarbeitungs- und Transferfolgenabschätzung, die Ihre konkrete Plankonfiguration und Ihre bestehenden Verträge mit Atlassian einbezieht. Wie diese Bewertung grundsätzlich für KI-Funktionen im Unternehmen aufgebaut werden kann, haben wir für den Fall von Claude ausführlicher beschrieben - die Denklogik zu Auftragsverarbeitung, Standortprüfung und Datenkategorien lässt sich von dort weitgehend auf Atlassians eigene KI-Funktionen übertragen.

Data Residency und KI: Speicherort ist nicht gleich Verarbeitungsort

Atlassian bietet für Confluence, Jira und weitere Cloud-Produkte seit Längerem eine Data-Residency-Option an, mit der sich bestimmte Datenkategorien auf eine gewählte Region festlegen lassen. In der offiziellen Übersicht der von Data Residency erfassten Datenkategorien taucht dabei ausdrücklich auch „AI data” als eigene Kategorie auf - sowohl für Jira, Jira Service Management, Jira Product Discovery als auch für Confluence und für Rovo selbst (dort unter anderem als Chat-Sitzungsprotokolle und Agentenkonfiguration). Rovo unterstützt laut Atlassians Support-Dokumentation Data Residency grundsätzlich, aktuell lässt sich Rovo-Daten auf dieselbe Region festlegen wie die zugehörigen Jira- oder Confluence-Daten; gesonderte Einschränkungen gelten nach Atlassians eigener Dokumentation aktuell für zwei Fälle: für Rovo Dev, das Data Residency derzeit nicht unterstützt, sowie für mit Forge in Rovo Studio gebaute Apps, bei denen zumindest Quellcode und Konfiguration nicht von Data Residency erfasst werden (Stand: August 2026).

Wichtig ist dabei eine Unterscheidung, die in der Kommunikation leicht untergeht: Data Residency legt fest, wo Daten gespeichert werden - nicht zwingend, wo eine KI-Anfrage in Echtzeit verarbeitet wird. Die bereits erwähnte Sub-Prozessoren-Liste zeigt das konkret: Wird im Hintergrund OpenAI als Modellanbieter genutzt, findet die Verarbeitung laut Atlassians eigenen Angaben in den USA statt - unabhängig davon, in welcher Region Ihre gespeicherten Daten liegen. Eine öffentliche, eindeutige Zusicherung, dass sämtliche KI-Verarbeitung bei aktivierter EU-Data-Residency zwingend innerhalb der EU verbleibt, ließ sich in der Recherche nicht auffinden: Ob EU-Data-Residency bei Atlassian auch die Verarbeitung durch KI-Modelle vollständig auf EU-Standorte begrenzt oder nur den Speicherort betrifft, war anhand der öffentlich zugänglichen Atlassian-Dokumentation nicht abschließend zu klären (Stand: August 2026). Für die eigene Bewertung ist deshalb ratsam, Data Residency als Baustein zu behandeln, der den Speicherort adressiert, und die Frage des Verarbeitungsstandorts separat über die Sub-Prozessoren-Liste zu prüfen.

Häufige Fragen zu Atlassian Intelligence und Data Contribution

Ab wann gelten die neuen Data-Contribution-Regeln bei Atlassian?

Seit dem 17. August 2026. Sowohl die Atlassian-Support-Seite zu den Data-Contribution-Settings als auch das offizielle FAQ auf atlassian.com/trust nennen dieses Datum übereinstimmend als Stichtag, ab dem Atlassian Daten gemäß den jeweils eingestellten Data-Contribution-Einstellungen nutzt.

Kann ich Data Contribution bei Atlassian vollständig abschalten?

Das hängt vom Plan ab. Auf Free-, Standard- und Premium-Plänen lässt sich nur die In-App-Daten-Contribution abschalten, die Metadaten-Contribution ist immer aktiv. Nur auf einem Enterprise-Plan lässt sich auch die Metadaten-Contribution deaktivieren.

Trainiert Atlassian damit fremde KI-Modelle wie die von OpenAI oder Anthropic?

Laut Atlassians eigenen Angaben nicht direkt: Kundenmetadaten und In-App-Daten werden nicht mit den extern gehosteten LLM-Anbietern geteilt, damit diese ihre eigenen Modelle trainieren - diese Anbieter arbeiten unter Zero-Data-Retention-Vereinbarungen. Data Contribution betrifft stattdessen das Feintuning von Open-Source-Modellen innerhalb der eigenen Atlassian-Infrastruktur.

Sieht Atlassian Intelligence bei einer Antwort auch Inhalte, auf die der fragende Nutzer eigentlich keinen Zugriff hat?

Nein, laut Atlassians Dokumentation handelt ein Rovo-Agent im Auftrag des jeweiligen Nutzers und kann nur auf Inhalte reagieren, auf die dieser Nutzer bereits Zugriff hat. Das ersetzt aber keine saubere Berechtigungshygiene in Confluence und Jira selbst.

Gibt es eine EU-Datenresidenz-Option, die auch die KI-Verarbeitung abdeckt?

Data Residency deckt laut Atlassian auch die Kategorie „AI data” ab und lässt sich für Rovo auf dieselbe Region wie Jira oder Confluence festlegen. Ob damit auch die eigentliche KI-Verarbeitung selbst zwingend auf EU-Standorte begrenzt bleibt, ließ sich anhand der öffentlichen Dokumentation nicht abschließend klären - die Sub-Prozessoren-Liste zeigt für einzelne Anbieter wie OpenAI ausschließlich US-Standorte.

Fazit

Die Data-Contribution-Regeln, die seit dem 17. August 2026 gelten, verändern nicht, ob Atlassian grundsätzlich Kundendaten für Produktverbesserungen nutzen darf - das DPA erlaubte das schon zuvor über de-identifizierte, aggregierte Daten. Was sich ändert, ist der Radius: Aus einer Verbesserung der eigenen Organisation wird eine Verbesserung für alle Atlassian-Kunden, und der Opt-out-Spielraum hängt sichtbar vom gebuchten Plan ab. Für Ihre eigene Prüfung lohnt es sich, drei Dinge auseinanderzuhalten: die Data-Contribution-Einstellungen selbst, die Frage, ob Atlassian Intelligence bestehende Berechtigungen respektiert, und die separate Frage, wo die KI-Verarbeitung tatsächlich stattfindet. Keiner der drei Punkte ersetzt eine eigene, auf Ihre Plankonfiguration zugeschnittene Bewertung.

Quellen (Stand: August 2026, Abruf 20.08.2026, Fact-Check-Zweitprüfung 21.08.2026):