Schatten-KI per Update: Das Beispiel Atlassian Rovo

Schatten-KI hatte bislang ein klares Muster: Mitarbeitende geben vertrauliche Daten in ChatGPT ein, weil die freigegebenen Tools ihren Anforderungen nicht genügen – und die IT bekommt davon nichts mit. Laut einer Prognose von Gartner werden bis 2030 mehr als 40 % der Unternehmen Sicherheits- oder Compliance-Vorfälle erleben, die auf nicht autorisierte Schatten-KI zurückgehen.

Die Antwort darauf ist in vielen Unternehmen inzwischen etabliert: klare Richtlinien, gezielte Schulungen und eine offiziell freigegebene Alternative.

Diese Antwort setzt voraus, dass Schatten-KI durch ein Tool ins Unternehmen gelangt, das Mitarbeitende selbst ausgewählt haben.

Doch immer häufiger kommt sie auf einem anderen Weg: pper Update – in Software, die von der IT längst freigegeben wurde. KI-Funktionen erscheinen plötzlich in Kollaborationstools, Ticketsystemen oder Wikis, mit denen Teams ohnehin täglich arbeiten. Niemand hat gegen eine Richtlinie verstoßen. Entsprechend greift auch keine.

Diese zweite Form von Schatten-KI ist schwerer zu erkennen und noch schwerer zu steuern. Denn die ursprüngliche Freigabe galt für eine Software mit einem bestimmten Funktionsumfang – nicht zwangsläufig für die KI-Funktionen, die später hinzukommen.

Ein besonders aktuelles Beispiel ist Atlassian Rovo in Jira und Confluence. Es eignet sich als guter Prüfstein für jede KI-Governance: Lässt sich Rovo wirklich vollständig abschalten? Welche Funktionen sind standardmässig aktiv? Und was passiert, solange niemand die Voreinstellungen bewusst verändert?

Im Folgenden geht es zunächst darum, was diese neue Form von Schatten-KI ausmacht. Anschliessend zeigt das Beispiel Rovo, welche Funktionen sich deaktivieren lassen und welche nicht, wo Atlassian Daten verarbeitet und welche Kontrollen Unternehmen aktiv konfigurieren müssen.

Key takeaways

1. Schatten-KI kommt nicht mehr nur durch neue Tools ins Unternehmen

   Die klassische Definition greift zu kurz. Schatten-KI entsteht heute auch dann, wenn bereits freigegebene Software nachträglich neue KI-Funktionen oder Datenzugriffe erhält – ohne dass diese erneut geprüft oder ausdrücklich freigegeben werden.

   
   

2. Unterhalb von Enterprise lässt sich Rovo nur pro App sperren

   In den Plänen Standard und Premium können Admins Rovo nur für ganze Apps sperren, aber keine einzelne KI-Funktion innerhalb einer App abschalten. Enterprise-Organisationen mit Atlassians neuer Zugriffsverwaltung können zusätzlich einzelne Funktionen wie Agents und Chat ein- oder ausschalten. Search, Chat und Create with Rovo bleiben verfügbar, solange irgendeine Jira-App auf derselben Site Rovo noch nutzt.

   
   

3. Seit dem 17. August 2026 nutzt Atlassian Ihre Daten standardmässig, um seine KI zu verbessern

   Die Nutzung von Inhalten ist bei Free und Standard standardmässig aktiv und lässt sich in jedem Plan abschalten. Die Nutzung von Metadaten Seit dem 17. August 2026 nutzt Atlassian deine Daten standardmässig, um seine KI zu verbessernlässt sich nur im Enterprise-Plan abschalten. Zu den Unterauftragsverarbeitern, die Atlassian für seine KI-Funktionen aufführt, gehören Databricks und OpenAI, beide mit Standort in den USA.

   
   

4. Voreinstellungen können den KI-Zugriff, erheblich erweitern

   Der Microsoft-Teams-Connector des Teamwork Graph indexiert standardmässig jede Nachricht, private Chats eingeschlossen. Admins können einschränken, welche Teams und Kanäle indexiert werden. Eine Möglichkeit, private Chats auszuschliessen, beschreibt Atlassians Dokumentation jedoch nicht.

   
   

5. Kontrollen gibt es, doch der Ausgangspunkt bleibt derselbe

   App-Blocklisten, IP-Beschränkungen, Datenresidenz und im Enterprise-Plan kundenverwaltete Schlüssel funktionieren. Jemand muss sie aber einrichten, und bis dahin gelten Atlassians Standardeinstellungen.

   
   

6. KI-Souveränität entscheidet sich im laufenden Betrieb

   Entscheidend ist nicht nur, was ein Anbieter vertraglich zusichert, sondern welche Kontrolle Unternehmen im Alltag tatsächlich behalten. Eine Plattform, bei der KI grundsätzlich abschaltbar und auf Modell- oder Funktionsebene steuerbar ist, verfolgt einen anderen Governance-Ansatz als eine Plattform, bei der diese Kontrollen nachträglich ergänzt werden.

Schatten-KI hat eine zweite Bedeutung bekommen

Was ist Schatten-KI in der klassischen Definition? Mitarbeitende nutzen KI-Tools, die von der IT nicht freigegeben wurden – häufig über private Accounts. Wie verbreitet das ist, zeigt der AI Governance Benchmark 2026, eine Befragung von 300 Entscheiderinnen und Entscheidern aus Unternehmen mit mindestens 500 Mitarbeitenden im Juni 2026. In 42 % dieser Unternehmen werden nicht freigegebene GenAI-Tools gelegentlich genutzt, in weiteren 34 % häufig.

Für diese Form von Schatten-KI greifen klassische Gegenmassnahmen vergleichsweise gut: Richtlinien, Schulungen und freigegebene Alternativen. Denn der Ausgangspunkt des Problems ist klar erkennbar – ein Tool, das ausserhalb der IT ausgewählt und genutzt wurde.

In einer im August 2026 veröffentlichten Analyse, wird jedoch eine zweite, deutlich unauffälligere Form beschrieben. Sie entsteht, wenn eine bereits freigegebene Software nachträglich neue KI-Funktionen, Integrationen oder Datenzugriffe erhält, ohne dass diese Änderungen erneut geprüft werden.

Damit wird die Freigabe einer Software von einer dauerhaften Entscheidung zu einer Momentaufnahme. Sie kann bereits veraltet sein, sobald der Anbieter neue Funktionen aktiviert oder den Zugriff auf Daten erweitert.

Bei Rovo lässt sich dieser Mechanismus gut nachvollziehen. Die Freigabe für Jira und Confluence liegt in vielen Unternehmen Jahre zurück. Geprüft wurden damals vor allem Funktionen wie Ticketverwaltung und Wiki. Rovo kam erst später hinzu – per Update und damit innerhalb einer Software, die längst freigegeben war.

Genau darin liegt das Problem: Die ursprüngliche Freigabe bleibt bestehen, obwohl sich Funktionsumfang und Datenzugriff der Plattform verändert haben.

Wie gross dieser blinde Fleck werden kann, zeigt Obsidian Security. In einer Auswertung von Kundenumgebungen registrierte das Unternehmen innerhalb von nur 30 Tagen fast 70.000 Interaktionen zwischen Nutzer:innen, KI-Funktionen und Unternehmensdaten in bereits freigegebenen SaaS-Anwendungen. Rovo wird dabei ausdrücklich als Beispiel genannt – neben KI-Funktionen von Slack und Zendesk.

Was Rovo ist und wo es überall mitläuft

Rovo ist Atlassians KI-App, eingebaut in Jira, Confluence, Bitbucket und die übrigen Cloud-Apps. Jira Rovo und Confluence Rovo sind dasselbe Rovo, das an verschiedenen Stellen auftaucht.

Für die Governance zählen vier Teile davon:

Rovo Search durchsucht verbundene Systeme und liefert Ergebnisse, oft mit einer KI-generierten Antwort darüber.

In Rovo Chat stellen Nutzende ihre Fragen im Dialog.

In Rovo Studio bauen Teams eigene KI-Agenten, entweder Schritt für Schritt oder indem sie sie Rovo Chat beschreiben. Diese Agenten können Tickets erstellen, Confluence-Seiten zusammenfassen oder Workflows auslösen

Teamwork Graph bildet die Datenbasis im Hintergrund. Er verbindet Daten aus den Atlassian-Apps und aus externen Tools, die Admins anbinden, damit Search, Chat und Agenten eine Grundlage für ihre Antworten haben.

Genau dieser letzte Punkt macht Rovo zu mehr als einer reinen Suchfunktion. Über Connectors bindet der Teamwork Graph nicht nur Jira und Confluence ein, sondern auch externe Quellen wie Microsoft Teams.

Für IT-Verantwortliche bedeutet das: Welche Daten Rovo sehen und verarbeiten kann, wird nicht mehr allein durch die ursprüngliche Entscheidung für Jira und Confluence bestimmt. Der tatsächliche Datenzugriff ergibt sich aus der Summe aller Quellen und Connectors, die später zusätzlich angebunden werden.

Was sich abschalten lässt und was nicht

Lässt sich die KI in Jira und Confluence also wirklich abschalten? Nur teilweise. Laut Atlassians Support-Dokumentation zur Verwaltung des Rovo-Zugriffs wird Rovo pro App gesperrt: «Das Sperren einer App deaktiviert alle aktuellen und künftigen KI-Funktionen dieser App.» In Standard und Premium gibt es keine Option, eine einzelne KI-Funktion in einer App abzuschalten, die man weiter nutzt. Enterprise-Organisationen mit Atlassians neuer Zugriffsverwaltung können zusätzlich einzelne Funktionen wie Agents und Chat pro App und pro Benutzergruppe ein- oder ausschalten.

Selbst eine Sperre greift nicht zwangsläufig vollständig. Wird Rovo nur für eine von mehreren Jira-Apps deaktiviert, können die KI-gestützte Suche, Rovo Chat und „Create with Rovo“ weiterhin verfügbar bleiben – solange mindestens eine andere Jira-App auf derselben Site Rovo noch nutzt.

Atlassian bietet durchaus Kontrollen, die meisten davon allerdings nur auf der Enterprise-Stufe:

• App-Blocklisten (ab Standard) sowie App- und Gruppen-Allowlisten (Enterprise): Du legst fest, in welchen Apps Rovo überhaupt laufen darf, und im Enterprise-Plan, welche Benutzergruppen es nutzen dürfen.

• IP-Beschränkungen (ab Premium): Rovo ist nur aus Netzwerken erreichbar, die du freigibst. Das gilt auch für externe Tools, die sich über das Model Context Protocol (MCP) mit Rovo verbinden, den offenen Standard, über den externe Tools an ein KI-System andocken.

• Kundenverwaltete Schlüssel (Enterprise, kostenpflichtiges Add-on): Du verwaltest die Schlüssel, mit denen deine Daten verschlüsselt werden.

• Datenresidenz (ab Standard): Du wählst die Region, in der deine Daten gespeichert werden.

• Nur von Atlassian gehostete Modelle (Enterprise, auf Anfrage beim Atlassian-Support): Rovo nutzt dann nur Modelle, die Atlassian selbst betreibt, statt Modelle externer Anbieter.

• Kontrollen für Rovo-Agenten: Ab Standard legst du fest, wer Agenten erstellen darf. Im Enterprise-Plan kannst du Agenten zusätzlich pro App und Benutzergruppe ein- oder ausschalten.

Damit lässt sich Rovo sauber eingrenzen. Doch während Rovo selbst in Standard, Premium und Enterprise automatisch aktiviert ist, ist keine dieser Kontrollen ab dem ersten Tag aktiv. Bis jemand sie einrichtet, läuft Rovo im Standardzustand, den Atlassian gewählt hat.

Wie wenig sicher dieser Standardzustand sein kann, zeigt der Teams-Connector von Teamwork Graph. Laut Atlassians eigener Dokumentation indexiert er standardmässig jede Teams-Nachricht, private Chats und private Kanäle eingeschlossen. Bei der Einrichtung können Admins einschränken, welche Teams und Kanäle indexiert werden, und das später anpassen. Eine Möglichkeit, private Chats auszuschliessen, beschreibt die Dokumentation jedoch nicht. Wie weit zurück Nachrichten gelesen werden, lässt sich nur bei der Einrichtung festlegen. Jede Person sieht nur Ergebnisse, auf die sie in Teams ohnehin Zugriff hat, doch alles liegt in Atlassians Index.

Wo die Daten verarbeitet werden

Seit dem 17. August 2026 hat sich die Ausgangslage verschärft. Atlassian nutzt seither Metadaten und In-App-Daten, also die Inhalte die Ihre Nutzenden erstellen, aus Jira, Confluence, Jira Service Management und seinen Plattform-Apps einschliesslich Rovo, um seine Apps und KI-Funktionen zu verbessern.

Massgebend ist jeweils der höchste aktive Plan. Die Nutzung von Inhalten lässt sich in jedem Plan abschalten. Die Nutzung von Metadaten lässt sich nur im Enterprise-Plan abschalten; in Free, Standard und Premium ist sie immer aktiv. Einige Organisationen sind ganz ausgenommen, darunter solche in der Atlassian Government Cloud oder Isolated Cloud, solche mit kundenverwalteten Schlüsseln und solche mit konfigurierter HIPAA-Compliance.

Welche externen Anbieter dabei mit Ihren Daten arbeiten können, weist Atlassian in seiner Liste der Subunternehmen aus. Für Rovo nennt Atlassian unter anderem Databricks für die Entwicklung und das Training von Machine-Learning-Modellen sowie OpenAI und Google Vertex AI für generative KI.

Databricks und OpenAI sind dort mit Standort in den USA aufgeführt. Für Google Vertex AI nennt Atlassian Standorte in den USA, im EWR und in Asien.

Nach Angaben von Atlassian dürfen die externen Sprachmodell-Anbieter die verarbeiteten Daten nicht zum Training eigener Modelle verwenden. Zudem gelten Vereinbarungen, nach denen diese Anbieter die Daten nicht dauerhaft speichern.

Ob diese Form der Datennutzung mit der DSGVO vereinbar ist, wird von mehreren Datenschutzberatern als rechtlich nicht abschliessend geklärt eingeschätzt. Ein zentraler Punkt ist dabei die Frage, ob Atlassian für diese Verarbeitung weiterhin ausschliesslich als Auftragsverarbeiter handelt oder teilweise selbst zum Verantwortlichen wird.

Eine Stellungnahme einer deutschen oder Schweizer Datenschutzbehörde speziell zu Rovo liegt bislang nicht vor. Unternehmen müssen die rechtliche Bewertung daher derzeit selbst vornehmen – insbesondere auf Basis des Auftragsverarbeitungsvertrags mit Atlassian und der Data-Contribution-Einstellungen ihrer Organisation.

Hinzu kommt der EU AI Act. Seit dem 2. August 2026 gelten seine Transparenzpflichten aus Artikel 50. Vereinfacht gesagt: Menschen müssen erfahren, wenn sie mit einem KI-System interagieren, und Anbieter generativer KI müssen KI-generierte Audios, Bilder, Videos und Texte maschinenlesbar kennzeichnen, mit Ausnahmen etwa für rein unterstützende Bearbeitungsfunktionen.

Mit dem Digital Omnibus, der seit Juli 2026 in Kraft ist, haben Systeme, die schon vor dem 2. August auf dem Markt waren, bis zum 2. Dezember 2026 Zeit für diese Kennzeichnung. Die Pflichten treffen vor allem die Anbieter, hier also Atlassian, und könnten Rovo Chat und Rovo Agents betreffen. Unternehmen, die Rovo einsetzen, haben als Betreiber eigene Pflichten, etwa wenn sie KI-generierte Texte zu Themen von öffentlichem Interesse veröffentlichen. Die EU-Kommission hat allgemeine Leitlinien zu Artikel 50 veröffentlicht, doch keine Behörde hat bisher erklärt, wie sie auf Rovo anzuwenden sind.

Was das für Ihre KI-Governance bedeutet

Für jedes der beschriebenen Rovo-Risiken gibt es Kontrollmöglichkeiten. Aktiv werden sie jedoch nicht von selbst. Solange niemand in Ihrem Unternehmen die entsprechenden Einstellungen ändert, gelten die Voreinstellungen von Atlassian.

Genau darin liegt das Muster, das sich durch diesen Artikel zieht: In vielen Unternehmen wurden Jira und Confluence zuletzt geprüft, bevor Rovo überhaupt existierte. Die damalige Freigabe war eine Momentaufnahme. Die KI-Schicht kam später hinzu.

Prüfen Sie Rovo deshalb so, wie Sie jedes neue KI-Tool prüfen würden, das in Ihrem Unternehmen eingeführt werden soll:

1. Wo läuft Rovo? Erfassen Sie, in welchen Apps Rovo aktiv ist, und entscheiden Sie bewusst, wo es eingesetzt werden soll.

2. Was sieht Rovo? Prüfen Sie alle aktiven Connectors des Teamwork Graph und deren jeweiligen Umfang – insbesondere externe Quellen wie Microsoft Teams.

3. Was passiert mit Ihren Daten? Prüfen Sie die Data-Contribution-Einstellungen und Atlassians Liste der Subunternehmen. Lassen Sie beides durch Ihre Rechtsabteilung mit dem Auftragsverarbeitungsvertrag abgleichen.

4. Wer trägt die Verantwortung? Klären Sie mit Atlassian, wie Rovo die Anforderungen aus Artikel 50 des EU AI Act umsetzt, und dokumentieren Sie Zuständigkeiten und Entscheidungen in Ihrer KI-Governance.

Diese Prüfung zeigt auch, warum ein Vertrag allein nicht ausreicht. Ein Auftragsverarbeitungsvertrag regelt, unter welchen Bedingungen Atlassian Daten verarbeiten darf. Ob jemand vor einigen Monaten Microsoft Teams angebunden und dabei die voreingestellten Zugriffsrechte übernommen hat, steht dort nicht. Das entscheidet sich in der laufenden Konfiguration.

KI-Kontrolle entsteht deshalb nicht allein auf dem Papier, sondern im Betrieb – Einstellung für Einstellung.

Dasselbe Muster sehen wir bei rready in Gesprächen mit Unternehmen, die diese Fragen bereits für sich beantwortet haben. In den vergangenen zwei Monaten haben wir mit drei Großunternehmen gesprochen, deren Anforderungen nahezu identisch waren: KI-Verarbeitung soll möglichst innerhalb der eigenen Infrastruktur stattfinden, Daten sollen das Unternehmen nur über kontrollierte und überprüfbare Prozesse verlassen, und besonders sensible Informationen sollen vollständig im eigenen System verbleiben. In allen drei Fällen waren diese Anforderungen Teil der bestehenden IT-Governance.

Grundsätzlich führen von hier zwei Wege weiter.

Der erste: Sie bleiben bei Atlassian und schränken Rovo gezielt ein. Das ist möglich, allerdings setzen mehrere der beschriebenen Kontrollmechanismen die Enterprise-Stufe voraus. Für manche Unternehmen bedeutet KI-Governance bei Rovo deshalb zusätzliche Komplexität und höhere Lizenzkosten für Funktionen, die sie womöglich gar nicht einsetzen möchten.

Der zweite Weg ist eine Plattform, bei der KI nicht standardmäßig aktiviert ist.

Eine solche Option bietet sovara, die europäische Alternative zu Jira und Confluence, die wir bei rready entwickeln. Dort steht einem einmaligen Migrationsaufwand ein Lizenzmodell gegenüber, das je nach Konfiguration bis zu 30 Prozent günstiger sein kann als vergleichbare Atlassian-Setups. Ob sich ein Wechsel wirtschaftlich lohnt, hängt von Ihrer heutigen Lizenzstufe, Nutzerzahl und Infrastruktur ab.

Bei sovara ist keine Verbindung zu einem KI-Modell aktiv, solange Sie diese nicht selbst einrichten. Sie entscheiden, ob Anfragen an eine sichere Cloud, ein selbst gehostetes Modell oder einen europäischen Anbieter wie zum Beispiel Mistral AI gehen. Sie können KI auch vollständig deaktiviert lassen.

Der Zugriff externer KI-Systeme auf Daten in sovara kann über das Model Context Protocol gesteuert werden. Damit konfigurieren Sie bewusst eine klar definierte Schnittstelle, statt nachträglich zahlreiche KI-Funktionen in unterschiedlichen Anwendungen kontrollieren zu müssen.

Natürlich verschwindet damit nicht jede Governance-Frage. Wenn Sie beispielsweise ein Modell eines US-Anbieters anbinden, gelten weiterhin dessen technische und rechtliche Rahmenbedingungen. Der entscheidende Unterschied liegt in der Kontrolle: Sie treffen diese Entscheidung selbst, können sie dokumentieren und die Verbindung wieder entfernen.

Auch sovara sollte deshalb mit denselben Maßstäben geprüft werden, die dieser Artikel auf Atlassian anlegt. Die Plattform ist nach ISO/IEC 27001:2022 zertifiziert und wird extern geprüft. Das Zertifikat bezieht sich auf das Informationssicherheits-Managementsystem von rready und stellt keine separate Zertifizierung der KI-Funktionen dar. Ob die Architektur und die angebotenen Kontrollen für Ihren konkreten Anwendungsfall ausreichen, gehört in dieselbe Sicherheitsprüfung, die Sie bei jedem Anbieter vor Vertragsabschluss durchführen sollten.

Weitere Informationen dazu finden Sie im Digital Sovereignty Trust Center von rready.

Unabhängig davon, für welche Plattform Sie sich entscheiden, bleibt die wichtigste Frage dieselbe:

Was passiert, solange niemand die Voreinstellungen verändert?

Stellen Sie diese Frage jedem Anbieter. Auch uns.

FAQ

Lässt sich Rovo in Jira und Confluence vollständig deaktivieren?

Ja, indem Sie Rovo für alle Apps sperren. Unterhalb von Enterprise geht das nur pro App, nicht pro Funktion. Enterprise-Organisationen mit Atlassians neuer Zugriffsverwaltung können zusätzlich einzelne Funktionen wie Agents und Chat abschalten. Die KI-gestützten Funktionen Search, Chat und Create with Rovo bleiben verfügbar, solange irgendeine Jira-App auf derselben Site Rovo noch nutzt.

Trainiert Atlassian eigene Modelle mit unseren Jira- und Confluence-Daten?

Standardmässig ja, seit dem 17. August 2026: Metadaten in jedem Plan, Inhalte bei Free und Standard. Laut Atlassian dienen die Daten dazu, seine Apps und KI-Funktionen zu verbessern; bei Metadaten gehört dazu auch das Training eigener Suchmodelle und das Feintuning von Open-Source-Modellen, die Atlassian selbst betreibt.

Die Nutzung von Inhalten lässt sich in jedem Plan abschalten, die von Metadaten nur im Enterprise-Plan. Laut Atlassian erhalten externe Modellanbieter wie OpenAI und Google die Daten nicht, um eigene Modelle zu trainieren.

Fällt Atlassian Rovo unter den EU AI Act?

Möglicherweise, für Rovo Chat und Rovo Agents, über die Transparenzpflichten nach Artikel 50, die seit dem 2. August 2026 gelten. Für Systeme, die bereits auf dem Markt sind, läuft die Frist für die maschinenlesbare Kennzeichnung bis zum 2. Dezember 2026. Bisher hat keine Behörde diese Pflichten konkret auf Atlassian angewendet.