Atlassian ändert Datennutzung für KI ab 17.08.2026: Was du als Admin jetzt prüfen musst – inkl. Checkliste

Atlassian baut KI-Erlebnisse wie Rovo konsequent aus. Damit KI im Alltag wirklich hilft, braucht sie Kontext – und Kontext entsteht aus Mustern in der Nutzung. Genau deshalb aktualisiert Atlassian seine Richtlinien zur Datennutzung und führt neue, zentrale Einstellungen für Data Contribution ein.

Wichtig für dich als Atlassian Admin: Das ist kein „plötzliches Abschöpfen“ von Daten, sondern ein klar angekündigter Schritt mit Vorlauf, Schutzmechanismen und – je nach Plan – Konfigurationsmöglichkeiten bis hin zum Opt-out. Deine Aufgabe ist jetzt, das Thema frühzeitig in Richtung Compliance zu steuern, die Defaults zu verstehen und deine Organisation sauber auf den Stichtag 17. August 2026 vorzubereiten.

In diesem Artikel bekommst du die Einordnung plus eine konkrete Checkliste, was du bis Herbst 2026 erledigen solltest.

Die Atlassian-Timeline für die Anpassung deiner Einstellungen

Was du vermeiden solltest

In der Praxis scheitert das Thema selten an der Technik – sondern an Governance und Timing:

• „Wir schauen später mal“: Die Änderungen greifen ab 17.08.2026. Wer erst kurz vorher prüft, schafft Stakeholder-Alignment (Compliance/Datenschutz/Security) oft nicht mehr sauber.
• Missverständnis über Verantwortung: Laut Atlassians DPA gelten deine Produkteinstellungen als rechtlich verbindliche, „dokumentierte Weisungen“ an Atlassian. Heißt: Nicht Atlassian entscheidet für dich – aber du musst aktiv entscheiden, was in deinem Setup erlaubt sein soll.
• Unklare Datenbegriffe: Metadaten, In-App-Daten, De-identifiziert, aggregiert – viele Diskussionen drehen sich im Kreis, weil Begriffe nicht sauber getrennt werden.
• Plan-/Trial-Fallen: Defaults hängen am Highest Active Plan – inklusive Testversionen. Eine Trial kann also Defaults verschieben, ohne dass es allen bewusst ist.

Der richtige Ansatz: Ein zweigleisiges Vorgehen

1. Governance zuerst (intern klären, was erlaubt ist): Welche Daten dürfen (de-identifiziert und aggregiert) zur Produktverbesserung beitragen – und welche nicht?
2. Technik danach (Settings exakt umsetzen): In Atlassian Administration > Security > Data contribution deine Konfiguration prüfen, dokumentieren und erst nach Freigabe final anwenden.

So bleibst du handlungsfähig: Du unterstützt KI-Innovationen dort, wo sie für euch sinnvoll und compliant sind – und schaltest aus, wo eure Vorgaben es verlangen.

Deine Checkliste: 6 konkrete Schritte

Schritt 1: Timeline & Zeitfenster richtig nutzen

Atlassian kommuniziert die Umstellung mit klarer Roadmap:

• 16. April 2026: Rollout der Data-Contribution-Einstellungen beginnt (schrittweise).
• 19. Mai 2026: Rollout abgeschlossen, Settings vollständig verfügbar.
• 17. August 2026: Änderungen treten in Kraft (gemäß deiner Auswahl).

Parallel ist wichtig: Das Framework (DPA) ist bereits seit Oktober 2024 wirksam und beschreibt den Rahmen, in dem Atlassian als Processor agiert und du als Controller entscheidest.

Governance-Hinweis: Im DPA ist außerdem ein 72‑Stunden-Standard für „Security Incidents“ verankert: Atlassian informiert den Kunden ohne undue delay und – wo möglich – spätestens innerhalb von 72 Stunden, nachdem Atlassian von einem Incident Kenntnis erlangt hat. Das ist ein guter Trigger, eure internen Incident-Response-Prozesse (Security/DSB/Legal) einmal durchzugehen: Wer empfängt die Meldung, wer bewertet, wer eskaliert – und welche Nachweise braucht ihr im Audit?

Praxis-Tipp: Parallel ist wichtig: Das Framework (DPA) ist bereits seit Oktober 2024 wirksam und beschreibt den Rahmen, in dem Atlassian als Processor agiert und du als Controller entscheidest. Plane intern mindestens 4–6 Wochen ein, um mit Compliance/Datenschutz final abzustimmen – besonders, wenn mehrere Produkte/Organs/Connectoren betroffen sind.

Schritt 2: Trenne Metadaten vs. In‑App‑Daten für die Risikoabschätzung

Für eine belastbare Risikoabschätzung musst du trennen:

• Metadaten: Content Attributes (z. B. Lesbarkeitswerte, Story Points, Enddaten) + „Common Patterns“. Atlassian fokussiert dabei auf hochfrequente Muster und lässt unikate/seltene Infos weg.
• In‑App‑Daten: Echte Inhalte wie Seitentitel, Jira-Beschreibungen, Kommentare.

Wichtig dabei: Vor der Nutzung werden Daten de-identifiziert und auf Kundenebene aggregiert, sodass sie nicht mehr einzelnen Nutzern zugeordnet werden können. Zusätzlich kann Atlassian diese de-identifizierten, aggregierten Daten bis zu sieben Jahre aufbewahren, um Trends zu beobachten und Modelle zu verbessern.

Wichtiges Governance-Argument aus dem Statement: Atlassian verpflichtet sich technisch-politisch zum „Un-learn“:

• Wenn du opt-out gehst oder eine App löschst, commitet Atlassian, Modelle neu zu trainieren, die auf diesen Daten trainiert wurden.
• Entfernung aus Trainingssets: In‑App‑Daten innerhalb von 30 Tagen, Content Attributes innerhalb von 90 Tagen.

Das ist für viele Compliance-Diskussionen ein Schlüsselpunkt, weil es über „ab jetzt nicht mehr“ hinausgeht und auch „bereits verwendete Trainingsdaten“ adressiert.

Praxis-Tipp: Für Security/Compliance macht es Sinn, die Bewertung nicht pauschal zu machen („KI = nein“), sondern datentypbasiert: Metadaten und Inhalte sind in vielen Unternehmen unterschiedlich kritisch.

Schritt 3: Prüfe deine Defaults – sie hängen an deinem Plan (inkl. Trials)

Ein häufiger Aha-Moment: Datenschutz-Defaults sind an das Subskriptionsmodell gekoppelt. Atlassian handhabt es wie folgt:

Plan	Metadaten	In-App-Daten	Steuerungs-möglichkeiten
Free/Standard	Immer geteilt	An (Standard)	In‑App‑Daten können deaktiviert werden. Metadaten können nicht geändert werden.
Premium	Immer geteilt	Aus (Standard)	In‑App‑Daten können aktiviert werden. Metadaten können nicht geändert werden.
Enterprise	An (Standard)	Aus (Standard)	Beide Einstellungen können aktiviert und deaktiviert werden.

Nuancen, die im Alltag wehtun:

• Trials zählen: Eine Premium-Trial kann Defaults verändern.
• Downgrade von Enterprise: Du verlierst Metadaten-Kontrolle; Atlassian gibt eine 30‑tägige Review-Phase, bevor Metadaten automatisch aktiviert werden.

Praxis-Tipp: Halte Plan-/Trial-Events in deinem Admin-Change-Log fest, weil sie indirekt „Privacy Defaults“ beeinflussen.

Schritt 4: Nutze die 30‑Tage „Grace Period“ für neue Apps

Wenn eine neue App zur Organisation hinzugefügt wird, gibt Atlassian eine 30‑tägige Grace Period, bevor Metadaten oder In‑App‑Daten dieser App in die Nutzung einfließen. Das ist dein Fenster für eine Mini-PIA (Privacy Impact Assessment) und Settings-Anpassungen.

Space Exception: Diese Grace Period gilt nicht für neue Spaces/Projekte innerhalb einer App, die bereits beiträgt. Beispiel: Wenn Confluence bereits auf Contribution steht, trägt ein neu angelegter Space sofort bei.

Praxis-Tipp: Wenn ihr häufig neue Spaces/Projekte anlegt (z. B. pro Team/Programm), braucht ihr klare Guardrails (Naming, Space-Templates, Klassifizierung, ggf. Excludes), nicht nur eine einmalige Setting-Entscheidung.

Schritt 5: Informiere deinen Compliance-Beauftragten bevor du klickst

Aus Admin-Sicht ist das der „Compliance-Safe Move“:

• Du informierst die datenschutzrechtlich verantwortliche Stelle (Compliance/DSB) proaktiv über die geplante Datennutzung und die vorhandenen Einstellmöglichkeiten.
• Du finalisierst Opt-in/Opt-out erst nach expliziter Anweisung/Freigabe.
• Zusätzlich wichtig (und oft vergessen): Wenn ihr „Authorized Affiliates“ habt (Tochtergesellschaften/Partner, die unter eurer Org laufen), bist du als primärer Vertragspartner die zentrale Koordinationsstelle. Eure Org-Einstellung bindet damit auch deren Daten.

Praxis-Tipp: Baue eine Kommunikationsmatrix: Wer muss informiert werden (Compliance, Legal, Security, Data Owners, Affiliates)? und wer gibt final frei?

Schritt 6: Setze Data Contribution technisch um (und denke an Scope-Ausnahmen)

Je nach Plan kannst du Metadaten und/oder In-App-Daten deaktivieren oder bestimmte Apps/Spaces/Teamwork-Graph-Konnektoren ausnehmen.

Praxisbeispiel:

• Confluence enthält viele sensible Inhalte → du definierst strengere Regeln für In-App-Daten.
• Jira-Projekte enthalten eher strukturierte Tickets → du erlaubst Metadatenbeitrag (oder umgekehrt, je nach Policy).

Praxis-Tipp: Behandle diese Konfiguration wie eine sicherheitsrelevante Änderung:

• Änderungsticket
• Vier-Augen-Prinzip (Admin + Compliance)
• Dokumentation im Admin-Handbuch
• Review-Termin (z. B. jährlich oder bei Planwechsel)

Zusammenfassung

• Stichtag merken: Am 17.08.2026 ändern sich Atlassians Datenpraktiken für KI/Apps – mit vorherigem Rollout der Einstellungen ab April/Mai 2026.
• Deine Settings sind rechtlich relevant: Deine Produktkonfiguration ist (im Sinne der DPA-Logik) deine „dokumentierte Weisung“ – du musst sie aktiv managen.
• Metadaten ≠ In-App-Daten: Nur wer die Datentypen trennt, kann eine belastbare Risikoabschätzung machen.
• Defaults hängen am Plan (inkl. Trials): Highest Active Plan bestimmt, was standardmäßig aktiv ist und was du ändern kannst.
• Best Practice: Erst Stakeholder-Alignment (Compliance), dann technische Umsetzung inkl. Dokumentation und Review.

Wenn du Unterstützung brauchst, um deine Data-Contribution-Entscheidung sauber aufzusetzen (Stakeholder-Alignment, Dokumentation, technische Umsetzung, Connector-/Scope-Design): XALT unterstützt dich von der Bewertung bis zur Umsetzung pragmatisch und compliant.

Außerdem bietet Atlassian am 28. und 29. April ein Live-Webinar an. Darin geht es u. a. um den Scope der Änderungen, Schutzmechanismen (z. B. De-identification & Aggregation) und die praktische Konfiguration der Data contribution Settings in der Atlassian Administration – inkl. Q&A mit Atlassian ExpertInnen.