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 Prozent der Unternehmen weltweit Sicherheits- oder Compliance-Vorfälle im Zusammenhang mit nicht autorisierten KI-Tools erleben.

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. Rovo lässt sich nicht auf Funktionsebene abschalten

   Administrator:innen können ganze Apps sperren. Einzelne KI-Funktionen lassen sich laut Atlassians Dokumentation jedoch nicht gezielt deaktivieren. Suche, Chat und „Create with Rovo“ bleiben verfügbar, solange mindestens eine Jira-App auf derselben Site Rovo nutzt.

3. Atlassian nutzt Kundendaten standardmäßig für seine KI

   Nur Kund:innen auf der Enterprise-Stufe können die Nutzung von Inhalten und Metadaten vollständig ausschließen. Für die Verarbeitung von Rovo nennt Atlassian unter anderem Databricks und OpenAI als Subunternehmen mit Standort in den USA.

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

   Der Teams-Connector des Teamwork Graph indexiert standardmäßig sämtliche Nachrichten, einschliesslich privater Direktnachrichten. Der Zugriff wird erst eingeschränkt, wenn Administrator den Umfang bei der Einrichtung aktiv begrenzen.

5. Enterprise-Kontrollen helfen; müssen aber konfiguriert werden

   App-Sperrlisten, IP-Beschränkungen, eigene Schlüsselverwaltung und die Wahl des Hosting-Standorts bieten Unternehmen reale Kontrollmöglichkeiten. Sie müssen aber aktiv konfiguriert werden. Bis dahin gelten die Voreinstellungen von Atlassian.

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. Laut dem AI Governance Benchmark 2026, werden nicht freigegebene KI-Tools in 42 Prozent der befragten Unternehmen gelegentlich und in weiteren 34 Prozent häufig genutzt. Nur 9 Prozent untersagen externe KI-Tools vollständig.

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.

Die Sicherheitsplattform Obsidian Security zählt diesen Mechanismus zu den unterschätzten Risiken von Schatten-KI. 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-Schicht für Jira, Confluence, Bitbucket und weitere Cloud-Produkte. Ob von Jira Rovo oder Confluence Rovo die Rede ist: Technisch handelt es sich um dieselbe KI-Schicht, die an unterschiedlichen Stellen innerhalb der Atlassian-Plattform sichtbar wird.

Für die Governance sind vor allem drei Bausteine relevant:

Rovo Search durchsucht Inhalte über verbundene Systeme hinweg und kann Fragen direkt beantworten, statt lediglich Suchtreffer aufzulisten.

Rovo Chat und Rovo Studio ermöglichen den Einsatz und die Erstellung von KI-Agenten. Diese können beispielsweise Tickets anlegen, Confluence-Seiten zusammenfassen oder automatisierte Workflows auslösen.

Teamwork Graph bildet die Datenbasis im Hintergrund. Er verknüpft Inhalte und Beziehungen aus den angebundenen Quellen und stellt damit den Kontext bereit, auf den Suche und Agenten zugreifen können.

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 Anleitung für Administrator:innen lässt sich Rovo nur für ganze Anwendungen sperren. Eine Sperre deaktiviert „alle aktuellen und zukünftigen KI-Funktionen für diese App“. Eine einzelne KI-Funktion innerhalb einer weiterhin genutzten App gezielt abzuschalten, sieht die Anleitung nicht vor.

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:

• Sperr- und Freigabelisten pro App: Sie legen fest, in welchen Anwendungen Rovo überhaupt laufen darf.

• IP-Beschränkungen: Rovo ist nur aus Netzen erreichbar, die Sie freigeben. Das gilt auch für externe Tools, die sich über das Model Context Protocol (MCP) mit Rovo verbinden.

• Eigene Schlüsselverwaltung: Sie verwalten die Schlüssel, mit denen Ihre Daten verschlüsselt werden, selbst.

• Wahl des Speicherorts: Sie bestimmen, in welcher Region Ihre Daten liegen.

• Nur von Atlassian gehostete Sprachmodelle: Rovo nutzt dann ausschließlich Modelle, die Atlassian selbst betreibt, statt die externer Anbieter.

• Kontrolle über Rovo-Agenten: Sie steuern, worauf einzelne Agenten zugreifen dürfen.

Mit diesen Kontrollen lässt sich Rovo tatsächlich einschränken. Sie greifen jedoch nicht automatisch. Solange Administrator:innen sie nicht aktiv konfigurieren, gilt der von Atlassian vorgegebene Standardzustand.

Wie wenig sicher dieser Standardzustand sein kann, zeigt der Teams-Connector von Teamwork Graph: Er indexiert laut Atlassians eigener Dokumentation standardmäßig sämtliche Teams-Nachrichten, private Direktnachrichten und private Kanäle eingeschlossen, sofern niemand den Umfang beim Einrichten einschränkt. Welche Teams und Kanäle eingelesen werden, lässt sich später noch ändern. Wie weit zurück Nachrichten eingelesen werden, legen Sie dagegen nur beim Einrichten fest.

Wo die Daten verarbeitet werden

Seit dem 17. August 2026 hat sich die Ausgangslage verschärft. Atlassian nutzt seither Metadaten und Inhalte aus Jira und Confluence, um seine Apps und KI-Funktionen wie Rovo zu verbessern. Auf den Stufen Free und Standard ist das für beide Datenarten standardmäßig eingeschaltet, auf Premium und Enterprise zunächst nur für Metadaten. Kund:innen auf den Stufen Free, Standard und Premium können die Nutzung von Metadaten für dieses Training nicht abbestellen, nur Enterprise-Kund:innen können sowohl Metadaten als auch Inhalte vollständig ausschließen.

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 erkennen können, dass sie mit einer KI sprechen, und KI-generierte Texte, Bilder oder Videos müssen maschinenlesbar als solche gekennzeichnet sein.

Diese Pflichten richten sich in erster Linie an die Anbieter der jeweiligen KI-Systeme – im Fall von Rovo also an Atlassian. Je nach konkreter Ausgestaltung könnten sie insbesondere für Rovo Chat und Rovo Agents relevant sein. Wie Artikel 50 im Detail auf Rovo anzuwenden ist, wurde bislang jedoch von keiner zuständigen Aufsichtsbehörde konkretisiert.

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 Aleph Alpha oder 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?

Nur pro App, nicht pro Funktion. Administrator:innen können ganze Apps sperren, aber laut Atlassians eigener Dokumentation keine einzelne KI-Funktion darin gezielt abschalten. Die KI-gestützte Suche, Rovo Chat und „Create with Rovo“ bleiben verfügbar, solange noch eine Jira-App auf derselben Site Rovo nutzt.

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

Seit dem 17. August 2026 standardmäßig ja: Metadaten auf allen Stufen, Inhalte auf den Stufen Free und Standard. Nur Kund:innen auf der Enterprise-Stufe können beides vollständig ausschließen. Externe Modellanbieter wie OpenAI und Google erhalten die Daten laut Atlassian nicht für das Training eigener Modelle.

Fällt Atlassian Rovo unter den EU AI Act?

Möglicherweise, für Rovo Chat und Rovo Agents, über die seit August 2026 geltenden Transparenzpflichten aus Artikel 50. Eine konkrete Anwendung dieser Pflicht auf Atlassian liegt bislang nicht vor.