Drei Wege, wie KI in Jira kommt

Drei Wege, derselbe Backlog

An KI herrscht 2026 kein Mangel. Der Mangel liegt eher darin, zu wissen, wo sie sinnvoll eingesetzt werden sollte.

Wenn dein Team mit Jira arbeitet, hast du diesen Sog längst gespürt. Atlassian hat Rovo direkt in die Plattform eingebaut. OpenAI und Anthropic haben Konnektoren geöffnet, über die ChatGPT und Claude den Backlog lesen können. Und eine neue Klasse Forge-nativer Apps, darunter Just, verankert KI direkt im Vorgangspanel und behandelt das Jira-Ticket zugleich als Ausgangspunkt und Ziel.

Drei Wege. Derselbe Backlog. Sehr unterschiedliche Erlebnisse.

Naheliegend ist die Frage, was davon am besten ist. Meist ist das aber die falsche Frage. Ehrlicher ist oft: Was passt tatsächlich zu der Art, wie unser Team arbeitet?

Für manche Teams geht es vor allem um kontrollierte Reichweite. Für andere um die Freiheit, das stärkste Modell zu wählen. Und für wieder andere um einen klaren Ablauf in Jira, der mehrere Anbieter nutzen kann, ohne dass man den Vorgang verlassen muss.

Weg eins: Rovo

Rovo ist Atlassians eigene KI-Schicht, eingebettet in Jira Cloud, Confluence und Jira Service Management. Grundlage ist ein Teamwork Graph, der Beziehungen zwischen Menschen, Projekten und Inhalten im Atlassian-Ökosystem abbildet. Gestartet ist Rovo rund um drei Säulen: Search, Chat und Agents.

• Stärke: Reichweite. Rovo Search durchsucht Jira, Confluence und viele Drittanbieter-Apps unter Beachtung bestehender Berechtigungen. Das ist besonders hilfreich für Teams, deren Wissen über viele Orte verstreut ist.
• Stärke: der einfachste Freigabeweg. Es gibt keine Provider-Schlüssel, keine Modellauswahl und keine Token-Budgets, die gepflegt werden müssen. Governance bleibt innerhalb des bekannten Berechtigungs- und Audit-Modells von Atlassian. Auch die Preislogik ist heute einfacher: 2026 ist Rovo Teil der Atlassian-Cloud-Pläne, mit Zugriff und Nutzung je nach Tarif und Freikontingenten.
• Nachteil: weniger Kontrolle und weniger Tiefe im Vorgang. Die Modellauswahl ist festgelegt, und die KI sitzt neben der Arbeit statt innerhalb eines strukturierten Planungsablaufs im Vorgangspanel.

Rovo ist der richtige Weg, wenn das Kernproblem darin besteht, Informationen produktübergreifend zu finden und der Schwerpunkt auf geregeltem Zugang ohne Einrichtungsaufwand liegt.

Weg zwei: Konnektoren

Konnektoren verfolgen den entgegengesetzten Ansatz. Statt KI in Atlassian einzuschließen, bringen sie Jira-Daten dorthin, wo die KI ohnehin schon lebt: in ChatGPT, Claude Desktop, Cursor oder in jeden Client, der das Model Context Protocol (MCP) unterstützt.

• Stärke: Modellfreiheit. Du bekommst Zugriff auf das, was der externe Client anbietet. Heute sind das Claude Opus 4.6, GPT-5.4, Gemini 3.0 Pro und alles, was morgen noch erscheint.
• Stärke: vertraute Arbeitsumgebung. Genau das macht Konnektoren attraktiv für Power-User, die ohnehin in Claude, ChatGPT oder Cursor arbeiten und Spitzenmodelle nutzen wollen, ohne eine neue Oberfläche zu lernen. Die moderne Form dieser Brücke läuft immer häufiger über MCP: Der Client verbindet sich mit einem Atlassian- oder Drittanbieter-MCP-Server, entdeckt Jira-Werkzeuge und nutzt sie direkt im Gespräch.
• Nachteil: der Nutzer wird selbst zur Integrationsschicht. Der Kontext bleibt flach, solange ihn nicht jemand immer wieder manuell ergänzt, das Zurückschreiben nach Jira ist zwar möglich, aber selten sauber strukturiert, und jede Unterhaltung bleibt meist in einem einzelnen Client eingeschlossen. Auch die Anmeldung kann hakelig sein: Atlassians offizieller MCP-Server nutzt OAuth, und viele Teams ergänzen deshalb einen gemanagten Drittanbieter-Konnektor, um die Nutzung zu glätten.

Konnektoren sind der richtige Weg, wenn Jira-Kontext in eine starke externe KI gebracht werden soll und dem einzelnen Nutzer Modellfreiheit wichtiger ist als ein gemeinsamer Teamablauf.

Weg drei: Just

Just wählt einen dritten Weg. Es ist eine Forge-native Jira-App, die das KI-Erlebnis direkt im Vorgangspanel verankert, nicht als Chat-Seitenleiste, sondern als strukturierten Ablauf: Erkenntnisse gewinnen, klären, planen, ausführen und Ergebnisse zurück in Jira-Felder schreiben.

• Stärke: Tiefe im Ablauf. Die KI lebt im Ticket selbst, nicht in einem separaten Client, und der Vorgang ist sowohl Eingabe als auch Ziel.
• Stärke: ein Jira-natives System, das mehrere Anbieter verbinden kann. Statt nur eine Eingabe und eine Antwort zu liefern, läuft Just einen strukturierten Ablauf ab: Analyse, Klärung, Planung, Web-Recherche, Bildarbeit, Ausführung und Rückübertragung nach Jira. Jeder Schritt kann aktiviert, übersprungen oder geprüft werden, bevor Jira geändert wird. Weil Just von Anfang an für mehrere Anbieter ausgelegt ist, kann das Team einzelne Schritte an verschiedene Modelle geben und wiederverwendbaren Projektkontext mit sichtbarer Ausführung, Token-Verbrauch, Kosten und Rückmeldeschleifen in einem System zusammenführen.
• Nachteil: mehr Einrichtung und Plattformgrenzen. Just enthält zwar Testschlüssel für den Einstieg, langfristig basiert das Modell aber auf nutzungsabhängiger Abrechnung mit eigenen Provider-Schlüsseln. Das verlangt etwas mehr Vorbereitung: Jemand im Team muss API-Schlüssel für die Organisation anbinden, anlegen und verwalten. Es passt außerdem besonders dann gut, wenn die KI-Nutzung im Team stark schwankt, weil nicht allen derselbe pauschale Sitzpreis auferlegt wird. Den Budget-Aspekt erkläre ich ausführlicher in Das KI-Budget, über das kaum jemand spricht. Als Forge-App bewegt sich Just zusätzlich innerhalb der Laufzeitgrenzen von Atlassian.

Just ist der richtige Weg, wenn du die Stärken mehrerer KI-Anbieter in einem überprüfbaren Jira-Ablauf bündeln willst und bereit bist, für diese Kontrolle etwas mehr einzurichten.

Der eigentliche Unterschied: Wo die KI lebt

Wenn man die Funktionslisten beiseitelässt und jeden Weg auf seinen Kern reduziert, ist der Unterschied architektonisch.

Rovo ist die U-Bahn. Sie deckt die ganze Stadt ab. Du kommst mit einer Fahrt von Jira zu Confluence und weiter zu Google Drive. Die Linien sind festgelegt, der Fahrplan wird zentral gesteuert, und du vertraust dem Betreiber.

Konnektoren sind Fahrdienste. Du wählst das Fahrzeug, du wählst den Fahrer und fährst genau dorthin, wo du hinwillst. Dafür gibst du selbst die Richtung vor, die Fahrt bleibt privat, und der Rest des Teams sieht den ganzen Verlauf meist nicht.

Just ist ein eigener Shuttle-Service. Er bedient nur einen Korridor, den Jira-Vorgang, aber mit Zwischenhalten, Prüfpunkten und Transparenz. Außerdem kann der Anbieter entlang der Strecke wechseln, ohne dass das Team Jira verlassen muss. Alle sehen, wo das Shuttle gerade ist, was es transportiert und wann es ankommt.

Die Karte in Kurzform

Wenn man den gesamten Vergleich auf das Wesentliche verdichtet, wird der Unterschied schnell klar.

Darauf läuft die Entscheidung in ihrer klarsten Form hinaus: kontrollierte Reichweite, persönliche Modellfreiheit oder ein strukturierter Jira-Ablauf, der die besten Seiten mehrerer Anbieter vereint.

Den passenden Weg wählen

Kein Weg ist für alle gleichermaßen richtig. Ein Team, das Informationen über sechs SaaS-Produkte hinweg finden muss und keinerlei Infrastrukturaufwand will, sollte mit Rovo anfangen.

Ein Entwickler, der den Backlog mit Claude Opus 4.6, GPT-5.4 oder Gemini 3.0 Pro im eigenen Client durchdenken will, greift eher zu einem Konnektor.

Ein Produkt- oder Delivery-Team, das einen überprüfbaren Jira-Ablauf möchte, bei dem verschiedene Schritte unterschiedliche Anbieter nutzen können und bei dem Kosten, Qualität und Ergebnisse für das ganze Team sichtbar bleiben, sollte sich Just im Atlassian Marketplace ansehen.

Viele Teams werden mehr als einen Weg nutzen. Diese Routen schließen sich nicht gegenseitig aus. Wichtig ist, bewusst zu wählen, auf Basis der tatsächlichen Arbeitsweise des Teams und dort, wo die Reibung wirklich entsteht, nicht auf Grundlage der beeindruckendsten KI-Demo der letzten Woche.