Trainiert Atlassian KI mit Ihren Jira-Daten? Das ändert sich am 17. August

Wenn Sie eine Jira-, Confluence- oder Jira-Service-Management-Instanz administrieren, hat Atlassian Ihnen wahrscheinlich bereits eine E-Mail zu den neuen „Data Contribution“-Einstellungen geschickt. Hier erfahren Sie, was das konkret bedeutet und was Sie vor dem 17. August 2026 tun sollten.

Was sich ändert: Atlassian führt in der Atlassian Administration (Security → Data contribution) Kontrollmöglichkeiten auf Organisationsebene ein, die regeln, ob Ihre Metadaten und In-App-Inhalte zum Training von Atlassians KI-Modellen und zur Verbesserung KI-gestützter Funktionen in Jira, Confluence, JSM und verbundenen Platform-Apps verwendet werden. Ab dem 17. August 2026 beginnt Atlassian, Ihre Daten gemäß den jeweils geltenden Einstellungen zu nutzen – ob von Ihnen konfiguriert oder auf dem Standardwert belassen.

Der Punkt, den die meisten Administratoren übersehen: Ihre Kontrolle darüber hängt vollständig vom Plan-Tier ab. Nur Cloud-Enterprise-Kunden können den Beitrag von Metadaten vollständig deaktivieren. Alle anderen Tiers – Free, Standard, Premium – tragen automatisch Metadaten bei, ohne Möglichkeit zum Abschalten. Was Sie unabhängig vom Tier in der Regel steuern können, sind In-App-Inhalte: Sie können bestimmte Confluence-Bereiche, Jira-Projekte oder Teamwork-Graph-Connectoren vom Beitrag ausschließen, auch wenn Sie die Einstellung nicht vollständig deaktivieren können.

Was Sie konkret tun sollten: Gehen Sie zu Atlassian Administration → Security → Data contribution und prüfen Sie, was bereits konfiguriert ist. Bestätigen Sie den höchsten aktiven Plan Ihrer Organisation (er bestimmt Ihre Standardeinstellungen – selbst eine einzige Enterprise-Lizenz irgendwo in Ihrer Organisation verändert die Berechnung für alles darin). Wenn Ihre Organisation Kundendaten, regulierte Informationen oder etwas verarbeitet, das unter einen Auftragsverarbeitungsvertrag fällt, entscheiden Sie bewusst, ob bestimmte Projekte oder Bereiche ausgeschlossen werden sollten, statt den zufälligen Standardwert einfach zu übernehmen.

Dies ist eine einzige Einstellung auf einer einzigen Plattform. Wenn Ihre Organisation außerdem Slack, Notion, GitHub, Salesforce oder ein halbes Dutzend anderer verbundener SaaS-Tools betreibt, trifft jedes dieser Tools still und leise seine eigene Version genau dieser Entscheidung für Sie – manche mit einem sichtbaren Schalter, manche (wie Slacks nicht-generatives ML-Training) ganz ohne Schalter, nur per E-Mail abwählbar. Genau dieses Muster – reale Einstellungen, reale Fristen, reale Konsequenzen, vergraben in einem Admin-Panel, für dessen Prüfung niemand zuständig ist – ist das, was die Connectoren von 8200.dev automatisch sichtbar machen sollen, über jede von Ihnen verbundene Plattform hinweg, nicht nur über die eine, die Ihnen diese Woche zufällig eine E-Mail geschickt hat.

Die Entscheidung, für die niemand zuständig war

Treten Sie einen Moment von Atlassian zurück und betrachten Sie die Form des Problems, denn es wiederholt sich überall.

Jeder SaaS-Anbieter, der KI-Funktionen entwickelt, steht vor derselben Frage: Von welchen Kundendaten dürfen die Modelle lernen? Jeder Anbieter beantwortet sie anders, veröffentlicht die Antwort an einer anderen Stelle und gibt Kunden ein unterschiedliches Maß an Kontrolle:

• Slack verwendet standardmäßig Kundennachrichten und -inhalte, um plattformseitige, nicht-generative Machine-Learning-Modelle zu trainieren (Suchranking, Empfehlungen). Es gibt nirgendwo in den Workspace-Einstellungen einen Admin-Schalter dafür – ein Opt-out bedeutet, dass der Workspace-Owner eine E-Mail an Slacks Feedback-Adresse schreibt und darum bittet.
• Dropbox stellt eine Einstellung „Third-Party AI“ bereit, deren Standardwert davon abhängt, wo Ihr Konto beheimatet ist: standardmäßig aktiv für US-Konten, standardmäßig deaktiviert in der EU, im UK und in Kanada. Zwei Organisationen mit identischen Dropbox-Plänen können gegensätzliche Einstellungen haben, ohne es je zu merken.
• GitHub zieht die Grenze nach Plan: Kundendaten von Business- und Enterprise-Kunden sind vertraglich vom Modelltraining ausgeschlossen, während niedrigere Tiers unter breiter gefasste Produktbedingungen fallen. Dieselbe Organisation kann Tiers wechseln und dabei still und leise ihre Position ändern.
• Salesforce, Zendesk und Intercom haben jeweils eigene Standardwerte und eigene Opt-out-Wege – eine Setup-Seite, ein Support-Ticket, eine Workspace-Einstellung.
• Google Workspace, Microsoft 365, Notion und Box stehen auf der anderen Seite: Ihre Bedingungen sichern vertraglich zu, dass Kundeninhalte nicht zum Training von Modellen verwendet werden, sodass kein Schalter nötig ist, weil keiner gebraucht wird. Das ist eine tatsächlich andere Position – aber Sie müssen sie trotzdem kennen und einem Auditor darauf verweisen können.

Beachten Sie, was all diesen Fällen gemeinsam ist: Keiner von ihnen bietet eine API, die Sie abfragen können, um zu fragen „trägt meine Organisation gerade Trainingsdaten bei?“ Die Haltung steckt in Verträgen, in E-Mails, in regionalen Standardwerten, in Plan-Tiers. Sie ist real, sie hat Konsequenzen, und sie ist für jedes Dashboard, das Ihr Sicherheitsteam betrachtet, unsichtbar.

Deshalb scheitert „das sollte doch jemand prüfen“ als Kontrolle. Es gibt keinen Ort, an dem man das prüfen kann. Die Entscheidung fällt standardmäßig so aus, wie der Anbieter es gewählt hat – und der Anbieter hat mit seinen eigenen Interessen im Blick gewählt.

Was das für Compliance bedeutet

Wenn Ihre Organisation über einen SOC-2-Bericht verfügt, auf ISO 27001 hinarbeitet oder personenbezogene Daten unter der DSGVO verarbeitet, ist die Frage des Datenbeitrags keine optionale Randnotiz – sie fällt direkt in Ihre bestehenden Pflichten.

Auftragsverarbeitungsverträge beschreiben die Zwecke, für die ein Auftragsverarbeiter Ihre Daten nutzen darf. Ein Anbieter, der KI-Modelle mit Ihren Inhalten trainiert, verfolgt einen *Zweck*. Wenn Ihr Auftragsverarbeitungsvertrag mit einem Kunden besagt, dass dessen Daten zur Erbringung der Dienstleistung genutzt werden, und eine Ihrer verbundenen Plattformen still und leise genau diese Daten in das Modelltraining einspeist, ist es Ihre Aufgabe – nicht die des Anbieters –, die Lücke zwischen dem, was Sie nachgelagert versprochen haben, und dem, was Sie vorgelagert zulassen, zu schließen.

Auditoren fragen inzwischen direkt danach. Die Frage taucht in Vendor-Risk-Fragebögen in einer Variante von „nutzt einer Ihrer Subauftragsverarbeiter Ihre Daten zum Training von KI-Modellen, und woher wissen Sie das?“ auf. Eine belastbare Antwort besteht aus zwei Teilen: der *Haltung* (welche Plattformen tragen bei, welche sind vertraglich ausgeschlossen) und dem *Entscheidungsprotokoll* (wer hat es wann geprüft und was wurde entschieden). „Wir haben nie hingeschaut“ ist die einzige falsche Antwort. Was Auditoren im Bereich KI-Governance mittlerweile allgemein erwarten, haben wir bereits behandelt in Was Auditoren 2026 tatsächlich für KI-Governance verlangen – der Datenbeitrag wird zu einem Standardpunkt genau dieser Prüfung.

Die gute Nachricht: Dies ist einer der seltenen Compliance-Punkte, bei denen die Behebung wirklich günstig ist. Es muss nichts neu aufgebaut werden. Sie müssen die Einstellungen *finden*, absichtlich *entscheiden* und die Entscheidung *dokumentieren*.

Eine Checkliste für Administratoren bis zum 17. August

Hier ist die konkrete Vorgehensweise vor Atlassians Frist, verallgemeinert, damit Sie sie auf jede von Ihnen betriebene Plattform anwenden können:

1. Erfassen Sie die Angriffsfläche. Listen Sie die SaaS-Plattformen auf, auf denen die Inhalte oder Metadaten Ihrer Organisation tatsächlich liegen – nicht nur Atlassian. Enthält sie Kundendaten, regulierte Daten oder etwas unter NDA, fällt sie in den Geltungsbereich.
2. Finden Sie die Data-Contribution-Haltung jeder Plattform. Bei Atlassian: Administration → Security → Data contribution. Bei anderen kann die Kontrolle eine Einstellungsseite, ein Support-Ticket, ein E-Mail-Opt-out oder eine Vertragsklausel ohne jede Kontrolle sein.
3. Bestätigen Sie Ihr Plan-Tier auf jeder Plattform, bei der die Haltung tier-abhängig ist. Bei Atlassian bestimmt der höchste aktive Plan Ihrer Organisation die Standardeinstellungen für alles darin. Bei GitHub entscheidet das Tier, ob der vertragliche Ausschluss für Sie gilt.
4. Entscheiden Sie bewusst. Zuzustimmen ist eine legitime Wahl – bessere KI-Funktionen sind ein echter Vorteil. Das Fehlverhalten liegt nicht im Beitrag selbst, sondern in einem Beitrag, den *niemand entschieden hat*. Schließen Sie die Projekte und Bereiche aus, die sensibles Material enthalten, und lassen Sie den Rest laufen, wenn das Ihre Entscheidung ist.
5. Dokumentieren Sie die Entscheidung. Ein datierter Vermerk – wer hat geprüft, was wurde konfiguriert, warum – verwandelt einen stillen Standardwert in einen Nachweis für Governance, den Sie einem Auditor vorlegen können.
6. Überprüfen Sie regelmäßig. Anbieter ändern Standardwerte, fügen KI-Funktionen hinzu und verschieben Einstellungen. Eine 2026 einmal geprüfte Haltung ist keine 2027 verwaltete Haltung.

Wenn diese Liste nach einer Aufgabe aussieht, die jemand übernehmen muss – dann ist sie das auch. Die ehrliche Version dieses Problems ist, dass es *wiederkehrend, plattformübergreifend und mühsam* ist – genau die Art von Kontrolle, die still verrottet, wenn sie davon abhängt, dass ein Mensch sich daran erinnert.

Wie 8200.dev dies automatisch sichtbar macht

8200.dev erstellt jetzt einen KI-Trainings-Haltungsbefund für jede Plattform, die Sie verbinden. Verbinden Sie Jira, Slack, Dropbox, GitHub, Salesforce oder eine der anderen unterstützten Plattformen, und der Scan zeigt Ihnen – neben Ihren Freigabe- und Berechtigungsbefunden – ob dieser Anbieter Ihre Daten standardmäßig für KI-Training nutzt, wo sich das Opt-out oder die vertragliche Garantie befindet und wann diese Haltung zuletzt überprüft wurde. Standardmäßig zustimmende Plattformen erscheinen als Befunde, die eine Entscheidung erfordern; vertraglich abgesicherte Plattformen erscheinen als Nachweise, auf die Sie Auditoren verweisen können.

Wo eine Plattform auf einer benachbarten Achse *tatsächlich* eine per API auslesbare KI-Richtlinie bereitstellt, prüfen wir sie live: Der GitHub-Connector liest die Copilot-Public-Code-Matching-Richtlinie Ihrer Organisation aus, und der GCP-Connector prüft, ob Vertex AI ohne einschränkende Organisationsrichtlinie läuft. Jeder Befund kommt mit einem Schritt-für-Schritt-Remediation-Playbook, und den vollständigen Prüfkatalog finden Sie auf der Features-Seite.

Der Punkt ist nicht, dass KI-Funktionen gefährlich sind. Der Punkt ist, dass *der Datenbeitrag eine Entscheidung sein sollte, kein Standardwert* – bei Atlassian vor dem 17. August und bei jeder anderen Plattform, die Ihre Organisation bereits betreibt. Wenn Sie möchten, dass diese Entscheidung automatisch sichtbar gemacht wird, statt manuell im Gedächtnis behalten zu werden, sehen Sie sich Pläne und Preise an und verbinden Sie Ihre erste Plattform in wenigen Minuten.