# Atlassian ändert Datennutzung für KI ab 17.08.2026: Deine Checkliste

> Alles zur Atlassian Data-Contribution-Umstellung ab 17.08.2026: Timeline, Defaults nach Plan, Governance und eine 6-Schritte-Checkliste.

Source: https://www.xalt.de/blog/atlassian-aendert-datennutzung-fuer-ki/

Marcel Wänke Senior Atlassian AI Consultant bei XALT · 28.04.2026 · 9 min

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

![Zeitstrahl zu Atlassians Änderungen an der Datennutzung für KI](https://cdn.sanity.io/images/c475o02b/production/6f9925eeaf7ebedb7668010ec152f54216d50e13-2560x705.png?w=1504&q=75&fit=max&auto=format)

## 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](https://www.atlassian.com/trust/ai/data-contribution?utm_source=sfmc&utm_medium=email&utm_campaign=ACM-11618&jobid=107996203&subid=157395364):

- **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)

https://youtu.be/-EJF6iQe4Dw

## 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.

[Dein Kontakt zu XALT](https://www.xalt.de/kontakt/)

**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.

[Jetzt für das Webinar anmelden](https://www.atlassian.com/webinars/enterprise-cloud/data-contribution)

## Data Contribution sauber und compliant aufsetzen

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.

[Jetzt beraten lassen](https://www.xalt.de/kontakt/)

## Weitere Beiträge

### [Persönliche KI-Agenten im Vergleich: Rovo, OpenClaw und Agent-SDKs wie Claude oder OpenAI](https://www.xalt.de/blog/persoenliche-ki-agenten-im-vergleich/)

Rovo, OpenClaw oder Claude/OpenAI: Wie sich persönliche KI-Agenten 2026 unterscheiden und welcher Ansatz zu deinem Team passt.

*Atlassian*

### [BaFin-Compliance für Atlassian Cloud – Was Finanzdienstleister jetzt wissen müssen](https://www.xalt.de/blog/bafin-compliance-atlassian-cloud-migration/)

Seit Dezember 2024 gelten neue EU FSA-Regeln für Atlassian Cloud im Finanzsektor. Wir zeigen, was sich geändert hat und wie Ihr BaFin-konform in die Cloud kommt.

*Atlassian*

### [Atlassian Team '26 Recap: Der Aufbruch zur AI-nativen Organisation und die Rolle des Teamwork Graphs](https://www.xalt.de/blog/atlassian-team-26-recap-teamwork-graph/)

XALT war live auf der Atlassian Team '26 in Anaheim. Unser Recap zu Teamwork Graph, Rovo, der neuen Teamwork, Service-, Product-, Software- und Strategy Collection – und was das für deutsche Unternehmen bedeutet.

*Atlassian*

---

*Diese Fassung ist für KI-Agenten. Jede Seite dieser Website gibt es als Markdown: `index.md` an den Pfad hängen. Übersicht aller Seiten: [llms.txt](https://www.xalt.de/llms.txt)*