Atlassian nutzt Kundendaten für KI-Training: Was Unternehmen jetzt prüfen sollten

Ab dem 17. August 2026 wird Atlassian damit beginnen, Kunden-Metadaten und In-App-Inhalte aus Jira, Confluence und anderen Cloud-Produkten zu sammeln, um seine KI-Angebote – darunter Rovo und Rovo Dev – zu trainieren. Diese Ankündigung folgt auf die kürzlich geänderte Copilot-Datennutzungsrichtlinie von GitHub.

Zusammen betrachtet deuten diese Änderungen darauf hin, dass Opt-out als Standard zur Branchennorm wird. GitLab verfolgt die entgegengesetzte Position: keine Datenerfassung, kein KI-Training mit Kundendaten – unabhängig vom gewählten Tier.

Atlassians Änderung ist standardmäßig für alle Cloud-Kunden aktiviert und betrifft rund 300.000 Unternehmen. Für Kunden der Free-, Standard- und Premium-Tiers ist die Metadatenerfassung obligatorisch und kann nicht deaktiviert werden. Nur Enterprise-Kunden haben die Möglichkeit, sich abzumelden. Diese Richtlinienänderung verdient eine genaue Lektüre, wenn Engineering-, IT- und Projektmanagement-Teams auf Atlassian setzen – denn sie sind am stärksten betroffen und wurden am wenigsten konsultiert, bevor die Änderung eintrat.

Obwohl die zugrundeliegenden Governance-Fragen bei Atlassian und GitHub dieselben sind, sind die betroffenen Daten unterschiedlich. Während GitHubs Änderung Quellcode und Entwicklerinteraktionen betraf, greift Atlassians Änderung auf Projektpläne, interne Dokumentation, Workflow-Konfigurationen und operationale Metadaten über Jira, Confluence und den gesamten Atlassian-Stack zu. Für Unternehmen, die diese Werkzeuge als Aufzeichnungssystem für Planung und Auslieferung nutzen, sind die Auswirkungen weitreichend.

Was sich geändert hat und was das für die Daten bedeutet

Atlassian wird zwei Kategorien von Informationen erfassen:

• Metadaten: de-identifizierte operationale Signale wie Story Points, Sprint-Daten und SLA-Werte, einschließlich Daten aus dem Teamwork Graph und verbundenen Drittanbieter-Apps
• In-App-Inhalte: nutzergenerierte Materialien wie Confluence-Seiteninhalte, Jira-Issue-Titel, Beschreibungen und Kommentare

Atlassian gibt an, vor dem Training De-Identifizierung und Aggregation anzuwenden. Erfasste Daten können bis zu sieben Jahre gespeichert werden; In-App-Daten werden innerhalb von 30 Tagen nach dem Opt-out entfernt, Modelle innerhalb von 90 Tagen neu trainiert.

Es gibt einige Ausnahmen: Kunden, die kundenverwaltete Verschlüsselungsschlüssel verwenden, sowie Atlassian Government Cloud, Isolated Cloud oder HIPAA-Anforderungen sind von der Erfassung ausgenommen. Für die große Mehrheit der Atlassian Cloud-Kundenbasis beginnt die Datenerfassung jedoch, sofern nicht das Enterprise-Tier gebucht und der Schalter aktiv umgelegt wird.

Das kehrt Atlassians bisherige Position um, wonach Kundendaten nicht zum Training oder zur Verbesserung von KI-Diensten verwendet würden. Unternehmen, die Jira und Confluence für ihre sensibelsten Planungs-Workflows, Sprint-Boards, Security-Tickets, Incident-Postmortems und interne Dokumentation einsetzen, werden diese Inhalte bald zur KI-Trainingspipeline von Atlassian beisteuern – ohne jemals danach gefragt worden zu sein.

Die Governance-Lücke bei „Opt-out als Standard"

Opt-out-basierte Datenerfassung für KI-Training ist ein wachsendes Muster in der Softwarebranche. Es wirft jedes Mal dieselben Fragen auf: Wie verhält sich das zu bestehenden Datenverarbeitungsverträgen? Entspricht die Definition des Anbieters von „Metadaten" dem, was Rechts- und Sicherheitsteams als nicht-sensitive Daten einstufen würden?

Für viele Unternehmen lautet die Antwort: Wir wissen es nicht.

Wenn ein Anbieter seine Datenpraktiken durch eine Nutzungsbedingungsänderung ändert, liegt die Last beim Kunden: die Änderung bemerken, die Auswirkungen bewerten und innerhalb des vom Anbieter vorgesehenen Zeitfensters handeln.

Die obligatorische Natur der Metadatenerfassung für Free-, Standard- und Premium-Tiers verschärft das Problem. Der einzige Ausweg ist ein Upgrade auf Enterprise – mit einem Minimum von 801 Nutzern und individuellem Pricing, das für viele Teams einen erheblichen Kostenschritt bedeutet. Datenschutz ist damit zu einer Kaufentscheidung geworden.

Die Tier-Struktur schafft auch ein subtileres Problem. Metadaten wie Story Points, Sprint-Velocity, SLA-Metriken und Task-Klassifizierungen mögen isoliert harmlos erscheinen – in der Aggregation offenbaren sie jedoch Projektstruktur, Team-Performance-Muster und Lieferkadenz. Für Unternehmen in wettbewerbsintensiven Branchen hat diese operative Intelligenz einen realen Wert. Und „de-identifiziert" bedeutet nicht zwingend „nicht-sensitiv", sobald Muster im großen Maßstab rekonstruierbar sind.

Warum das für Atlassian-Stack-Unternehmen besonders relevant ist

In Atlassian-basierten Unternehmen ist Jira das Zentrum der Planung, Verfolgung und Auslieferung von Arbeit. Es ist die zentrale Datenquelle für Sprint-Planung, Bug-Tracking, Release-Management, Portfolio-Koordination und funktionsübergreifende Projektdurchführung.

In regulierten Branchen wie Finanzdienstleistungen, öffentlichem Sektor und Fertigung enthalten Jira und Confluence gemeinsam sensitive operative Daten, die Compliance-Anforderungen unterliegen können. Das Risiko potenziert sich für Unternehmen, die über Jira hinaus in das breitere Atlassian-Ökosystem expandiert haben.

Wer Jira, Confluence, Bitbucket und Bamboo gemeinsam betreibt, stellt fest, dass die Datenfläche, die nun in KI-Training einfließt, Projektpläne, interne Dokumentation, Quellcode-Metadaten und CI/CD-Konfigurationen umfasst – alles Bereiche, die Sicherheits- und Compliance-Teams vor einer Weitergabe an eine Trainings-Pipeline eines Anbieters prüfen wollen.

Atlassians Teamwork-Graph-Konnektoren fügen für Kunden, die Drittanbieter-Werkzeuge wie Slack, Figma, Google Drive, Salesforce und ServiceNow integriert haben, eine weitere Dimension hinzu. Diese Konnektoren indizieren Beziehungs- und Aktivitätssignale aus diesen verbundenen Apps – die erfassten Metadaten beschränken sich also nicht auf das, was innerhalb von Atlassian-Produkten liegt. Für Sicherheits- und Compliance-Teams, die Datenflüsse anbieterweise bewerten, erschwert diese plattformübergreifende Reichweite die Bewertung erheblich.

Unternehmen, die ohnehin bereits die Migration von Atlassian Data Center und Server in die Cloud bewältigen, stehen vor einer weiteren Herausforderung. Standardmäßige KI-Datenerfassung auf diesem Migrationspfad erhöht den Einsatz:

Die Frage lautet nicht mehr nur „Wechseln wir zu Atlassian Cloud?", sondern „Wechseln wir zu Atlassian Cloud in dem Wissen, dass unsere Daten KI-Training speisen, sofern wir nicht das teuerste Tier buchen?"

Was regulierte Unternehmen jetzt prüfen sollten

Die Compliance-Implikationen variieren je nach Branche, aber die Notwendigkeit zur Neubewertung ist einheitlich.

Regulierte Unternehmen in Finanzdienstleistungen, öffentlichem Sektor, Gesundheitswesen und Fertigung operieren unter Frameworks, die eine dokumentierte, prüfbare Übersicht über IT-Drittanbieter verlangen – einschließlich des Umgangs dieser Anbieter mit Daten. Der Digital Operational Resilience Act (DORA) macht dies für europäische Finanzinstitute seit Januar 2025 verbindlich: Wesentliche Änderungen an IT-Drittanbieterbeziehungen erfordern dokumentierte Bewertung und Nachverfolgung. Eine Änderung von „wir trainieren nicht mit Ihren Daten" zu „wir trainieren standardmäßig damit" qualifiziert sich typischerweise als wesentliche Änderung.

Der EU AI Act fügt eine zusätzliche Dimension hinzu: Opt-out-Framing entspricht US-Normen, während europäische Regulatoren für Datenverarbeitung dieser Art generell Opt-in-Einwilligung erwarten. Unternehmen, die ihre KI-Governance unter dem EU AI Act dokumentieren, sollten diese Diskrepanz in ihrer Risikobewertung berücksichtigen.

Wenn das Modellrisiko- oder Vendor-Management-Team die Datenschutzkontrollen von Atlassian vor dieser Ankündigung dokumentiert hat, stellt sich nicht die Frage, ob diese Änderung eine Neubewertungspflicht auslöst. Sie tut es. Die Frage ist, ob das Team vor dem 17. August handeln kann.

Worauf bei Plattformanbietern zu achten ist

Führungskräfte in regulierten Branchen müssen KI so einsetzen können, dass sie es gegenüber Aufsichtsbehörden, Vorständen und Kunden vertreten können. GitLab orientiert sich dabei an folgenden Grundsätzen:

Bedingungslose Datenzusagen, keine tier-abhängigen Schutzmaßnahmen. Regulierte Unternehmen benötigen spezifische Zusagen darüber, was mit ihren Daten geschieht. Eine Zusage, die je nach Preisstufe variiert oder eine Handlung vor einem Stichtag erfordert, erzeugt genau die Art unkontrollierbarer Variablen, die Compliance-Teams nicht akzeptieren können.

Transparenz und Auditierbarkeit. IT-Risikomanagement-Frameworks verlangen von Unternehmen, die eingesetzten KI-Systeme zu verstehen und zu validieren – einschließlich der Trainingsdaten und beteiligten Drittparteien. Anbieter, die diese Fragen nicht klar beantworten können, erzeugen Dokumentationsrisiken.

Trennung von Kundendaten und KI-Training des Anbieters. Wenn ein Plattformanbieter Modelle auf Basis von Kundennutzungsdaten trainiert, werden Workflows und operative Muster zu Eingaben für ein System, das auch Wettbewerbern dient. Für Unternehmen, bei denen Projektstruktur oder Lieferkadenz Wettbewerbsvorteile darstellen, ist diese Exposition relevant.

GitLabs anderer Ansatz

GitLab trainiert keine KI-Modelle mit Kundendaten – auf keiner Preisstufe. KI-Anbieter, die GitLab Duo-Funktionen betreiben, sind vertraglich verpflichtet, Kundeneingaben und -ausgaben nicht für eigene Zwecke zu verwenden – eine Zusage, die GitLab-CEO Bill Staples wiederholt bekräftigt hat.

Das GitLab AI Transparency Center dokumentiert, welche Modelle welche Funktionen betreiben, wie Daten verarbeitet werden und welche Anbieterzusagen bestehen. Der GitLab AI Continuity Plan dokumentiert, wie Anbieterveränderungen gehandhabt werden – einschließlich wesentlicher Änderungen daran, wie KI-Anbieter Kundendaten behandeln. Für Unternehmen, die Drittanbieter-KI-Risiken unter DORA oder vergleichbaren Frameworks verwalten, sind Anbieterkontinuität und -konzentration aktive Governance-Themen – und ein dokumentierter Plan für beides gehört zu verantwortungsvollem KI-Tooling.

Für Unternehmen, die KI-Verarbeitung innerhalb ihrer eigenen Infrastruktur halten müssen, steht die GitLab Duo Agent Platform mit GitLab Self-Managed-Deployments zur Verfügung – einschließlich Unterstützung für selbst gehostete KI-Modelle. Prompts und Code verlassen die Umgebung des Kunden damit nicht. GitLab bietet zudem IP-Haftungsübernahme für Duo-generierte Ausgaben – ohne erforderliche Filter und ohne Aktivierungsschritte. Wo Daten gespeichert werden, bleibt die Entscheidung des Kunden, unabhängig vom Deployment-Modell oder Abonnement-Tier.

Ob das Unternehmen bei Atlassian bleibt oder Alternativen evaluiert – die Frage, wer Daten kontrolliert und wie sie verwendet werden, sollte jetzt gestellt werden. Der 17. August rückt näher, aber es bleibt noch Zeit, GitLab Ultimate mit Duo Agent Platform kostenlos zu testen.