This blog post is also available in English

TL;DR

  • Das Problem: Atlassians KI-Features (Sprachsuche, Issue-Erstellung aus Notizen) gibt’s nur in der Cloud – ein No-Go bei strengen Datenschutzanforderungen.
  • Die Idee: Dieselben Vorteile selbst bauen – komplett lokal, ohne Datenabfluss.
  • Die Zutaten: Jira Server/Data Center + lokales KI-Modell via LM Studio + Open-Source-MCP-Server „mcp-atlassian" als Brücke.
  • Das Ergebnis: Per Chat mit der lokalen KI direkt Jira-Issues suchen, zusammenfassen und erstellen – alles in natürlicher Sprache.
  • Ausblick: Erweiterbar z. B. um GitLab/GitHub-Anbindung. Mehr Aufwand, aber datenschutzkonform und preislich unabhängig.

Inspiriert vom Digital Independence Day, der zu Rezepten für digitale Souveränität aufruft, teilen wir hier regelmäßig eigene Lösungsansätze zu Themen, die unsere Kunden bewegen – ab sofort jeden ersten Sonntag im Monat.

Fachlichkeiten zu besprechen funktioniert am besten im Dialog im Team und mit dem Kunden. Nicht selten ist es dabei so, dass für die Umsetzung wichtige Informationen in Nebensätzen erwähnt werden oder zwischen den Zeilen fallen. Das ist alles weit weg von den Eingabemasken, die uns Jira bietet, um Issues anzulegen. In meinem Alltag hat sich ein Workflow als echter Gamechanger herausgestellt: Notizen und Mitschriften aus Calls oder Chat-Diskussionen direkt an eine KI übergeben, die daraus sauber formulierte Jira-Issues erstellt – inklusive sinnvoller Felder, Beschreibungen und Struktur.

Das hat auch Atlassian erkannt, und der Jira Cloud einige KI-Features spendiert, die dabei unterstützen:

  • Issues mit natürlicher Sprache zu suchen, z.B. „Welche Epics wurden im letzten Release umgesetzt?”, oder „Welche Tickets hatten wir schon zum Thema XYZ?”
  • Informationen sinnvoll zusammenzufassen, z.B. Kernpunkte aus Kommentaren an Issues herauskristallisieren, oder fachliche Zusammenfassungen eines Epics samt zugehöriger Issues erstellen.
  • Issue-Beschreibungen und Stories aus Gesprächsnotizen zu formulieren
  • Issues sinnvoll in Sub-Tasks zu unterteilen
  • uvm.

Gerade die Möglichkeit, aus einer unstrukturierten Diskussion direkt strukturierte Issues zu erzeugen, spart enorm viel Zeit.

Info:

Auch wenn für Atlassian der Weg eindeutig in Richtung Cloud zeigt - das on-premise Produkt Jira Data Center wird nur noch bis März 2029 supportet - so möchte nicht jeder die Atlassian Cloud verwenden, und damit sind sowohl Jira, als auch die in der Atlassian Cloud bereitgestellten KI-Features gemeint. Doch noch gibt es die Möglichkeit bestehende on-premise Installationen bis zum offiziellen Ende des Supports im März 2029 weiterzubetreiben. Und genau diesen Instanzen wollen wir mit diesem Artikel helfen, von ähnlichen KI-Hilfen zu profitieren.

Unser Ziel ist eine DSGVO-konforme und Cloud-Act-sichere Nutzung von Jira inklusive der erwähnten KI-Features.

Zutaten

Dazu brauchen wir:

  1. Eine selbst-betriebene Instanz von Jira Server oder Jira Data Center
  2. Zugang zu einer KI
  3. Einen MCP-Server (mcp-atlassian), um die KI mit Jira Server zu verbinden
  4. Ein Tool, in dem die „Diskussion” zwischen User und KI stattfinden kann

Die Jira Instanz

Wir gehen für Punkt 1 davon aus, dass eine funktionsfähige, lizenzierte Instanz von Jira Server oder Jira Data Center in der aktuellen Version 11 vorhanden ist. Die Möglichkeit, neue Lizenzen für die beiden Produkte zu bekommen, gibt es seit 30.03.2026 leider nicht mehr. Wir gehen aber davon aus, dass es einige Projekte geben wird, die den on-premise Betrieb noch bis zum Ende des Supports im März 2029 aufrecht erhalten wollen.

Die richtige KI

Interessanter wird es bei Punkt 2. Atlassian Cloud verwendet einen Mix an Open-Weights-Modellen und auch Frontier-Modelle von OpenAI und Anthropic. Eine Konformität mit der DSGVO mag hier noch gegeben sein. Das eigentliche Problem ist der Cloud Act: Durch die interne Nutzung von AWS – und bei OpenAI und Anthropic sowieso – unterliegen sämtliche Daten dem Cloud Act. Es ist uns also daran gelegen, eine Alternative zu finden.

Grundsätzlich bieten sich zwei Möglichkeiten: Die Nutzung einer durch einen europäischen Anbieter betriebenen Inferenz-API, oder lokale Inferenz auf dem eigenen Computer. Europäische Anbieter wie StackIt, IONOS oder Scaleway bieten zwar pay-as-you-go Inferenz-APIs an, allerdings ist die Auswahl an aktuellen, leistungsfähigen Modellen dort teilweise begrenzt.

Für dieses Rezept konzentrieren wir uns daher auf die Verwendung von lokalen Modellen. Wir setzen dafür LM Studio als Inferenz-Engine und Chat-Tool ein. LM Studio ist für macOS, Linux und Windows verfügbar und kann auf der verlinkten Seite heruntergeladen werden. Sobald es erfolgreich installiert ist, gilt es noch das passende Modell auszusuchen.

Info:

Lokale Inferenz benötigt Hardware mit viel und schnellem Speicher. Das kann entweder eine GPU mit entsprechendem VRAM sein, oder Systeme mit starker integrierter GPU und ausreichend gemeinsamen RAM, z.B. Apple Silicon oder AMD Strix Halo Systeme.

Mit der Anzahl der Parameter des gewählten Modells skalieren auch die Hardware-Anforderungen. Eine ganz grobe Daumenregel ist: Pro einer Milliarde Parameter werden 1GB RAM benötigt. Ein gpt-oss:20b sollte also 20GB (V)RAM zur Verfügung haben, meist reicht auch ein bisschen weniger.

Für unseren Fall benötigen wir ein Modell, welches auf Tool Use ausgelegt ist. Als guten Kompromiss zwischen Fähigkeit für unseren Anwendungszweck, Geschwindigkeit und Hardware-Anforderungen hat sich gpt-oss:20b herausgestellt – ein Open-Source-Modell mit starker Tool-Use-Unterstützung. Wer ein bisschen mehr RAM zur Verfügung hat, startet mit qwen3.5:35b-a3b. Diese Modelle können in LM Studio im Bereich Model Search gesucht und heruntergeladen werden.

LM Studio screenshot showing “GPT-OSS 20B” selected and details for “openai/gpt-oss-20b” in the model library.
Auswahl des gewünschten Large Language Models

Es bietet sich definitiv an, hier ein wenig experimentierfreudig zu sein. Es gibt mittlerweile eine Hülle und Fülle an Modellen, die alle ihre Stärken und Schwächen haben. Aber die beiden genannten sind auf jeden Fall ein guter Startpunkt.

Der KI das Sprechen mit Jira beibringen (MCP)

An dieser Stelle angekommen ist es möglich, mit der lokalen KI innerhalb von LM Studio zu chatten. Sämtliches Wissen der KI ist dabei in ihren trainierten Parametern (den sogenannten „Weights”) enthalten. Es gibt noch keine Verbindung zur „Außenwelt”. Für unser gestecktes Ziel fehlt der KI also noch die Fähigkeit, mit unserer Anwendung – dem Jira – zu sprechen. Darum kümmern wir uns hier in Punkt 3.

Dafür nutzen wir einen passenden MCP-Server. Wir entscheiden uns für mcp-atlassian. mcp-atlassian ist ein Open-Source-Projekt, wird aktiv weiterentwickelt und erfreut sich auf GitHub schon vieler Sterne. Auch unsere persönlichen Tests mit mcp-atlassian liefen erfolgreich.

Damit wir mcp-atlassian benutzen können, ohne uns großartig mit Python und VirtualEnv auseinandersetzen zu müssen, installieren wir ein Tool namens uv. Dieses nimmt uns das Beziehen und Installieren der aktuellen Version von mcp-atlassian ab. Alle Informationen dazu finden sich hier.

Damit LM Studio mcp-atlassian benutzen kann, müssen wir es dort in die Konfiguration der MCP-Server aufnehmen, das geht hier:

Developer UI showing “Local Server” and “Loaded Models” (READY, openai/gpt-oss-20b); red arrow points to “mcp.json”.
Einbinden des MCP-Servers

So sieht dann eine mcp.json aus, mit der ihr einen mit der oben gezeigten compose.yml lokal gestarteten Jira Server ansprechen könnt:

{
  "mcpServers": {
    "mcp-atlassian": {
      "command": "uvx",
      "args": [
        "mcp-atlassian"
      ],
      "env": {
        "JIRA_URL": "https://meine-jira-instanz.org",
        "JIRA_PERSONAL_TOKEN": "<dein-jira-personal-access-token>"
      }
    }
  }
}

Wir konfigurieren LM Studio so, dass es den MCP-Server mit uvx mcp-atlassian aufrufen kann, und geben im Environment die benötigten Variablen zur URL und dem Personal Access Token (PAT) mit.

Das PAT bekommt ihr in Jira in eurem Profil. Dort kann ein PAT erstellt werden, welches ihr im MCP-Server verwenden könnt. Das bedeutet natürlich implizit, dass alle Aktionen, die ihr per MCP im Jira vornehmt, mit eurem User verbunden sind.

Als letzten Schritt starten wir einen neuen Chat und wählen mcp-atlassian aus. Ab jetzt kann die KI die Werkzeuge, die mcp-atlassian zur Verfügung stellt, benutzen und damit auf unser Jira zugreifen.

Integrations panel listing plugins; “mcp/mcp-atlassian” enabled, others off; search field “Type to filter plugins…”
Aktivieren des MCP Servers

Damit ist der schwierigste Teil geschafft – Jetzt geht es ans Fine-Tuning.

Der Chat

Ab hier - in Punkt 4 - fängt es an, richtig Spaß zu machen! LM Studio ist nicht nur unsere KI-Inferenz-Engine, sondern auch unser Chat-Tool, in dem unsere Nutzerinteraktion stattfindet. In einem LM Studio-Chat mit aktiviertem mcp-atlassian können wir uns über alles unterhalten, was in unserem Jira-Projekt enthalten ist. Die KI nutzt selbstständig Werkzeuge, um Issues zu bestimmten Themen, aus bestimmten Zeiträumen oder von bestimmten Nutzern zu finden. Außerdem können auch Issues erstellt werden. Hier ein paar Prompts zur Inspiration:

Beispiel-Prompts:

  • Welche Epics wurden im letzten Release behandelt?
  • Erstelle mir aus diesen Informationen fachliche Release-Notes
  • Welche offenen Bugs sind mir zugewiesen?

Um das Erstellen von Issues zu testen, sind auch Prompts hilfreich wie

Beispiel-Prompt:

  • Denke dir ein Feature aus und erstelle dazu ein Epic mit drei zugehörigen Stories

Wer hier schon weiterdenkt: Über zusätzliche MCP-Server lassen sich auch andere Systeme wie GitLab oder GitHub anbinden – dazu mehr im Fazit.

Dabei fallen aber direkt ein paar Kleinigkeiten auf – zumindest bei mir:

  • es gibt hin und wieder Probleme mit Umlauten in Beschreibungstexten
  • die KI verwendet gerne Markdown in Issue-Beschreibungen, was allerdings Jira nicht gerne mag

Aber auch dafür gibt es zum Glück eine (nicht deterministische) Lösung: Die Anpassung des System-Prompts. Hier können solche Verhaltensweisen der KI effektiv angepasst werden – z.B. auch, dass die KI jedes Mal samt Vorschau fragen soll, bevor sie ein Issue wirklich im Jira anlegt.

UI screenshot showing preset “Product Issue Assistant” and a “System Prompt” field with German text for Jira issue drafting.
Fine-Tuning im System Prompt

Mein aktueller System-Prompt sieht so aus:

Du bist kompetenter Product Owner und hast fundiertes Wissen im Formulieren und Schneiden von Aufgaben. Du unterstützt den Nutzer bei der Erstellung von Jira Issues indem du ihm hilfst Beschreibungen zu formulieren und Issue Felder korrekt zu setzen.

Wenn es aus dem Input ersichtlich ist, schlägst du sinnvolle Werte für diese Felder vor:

  • Type
  • Components

Antworte bitte auf Deutsch.

Wenn du Issues erstellst, zeige eine Vorschau und frage nach einer Bestätigung bevor du das Issue wirklich per Tool anlegst.

Verwende Umlaute direkt (ä, ö, ü, ß) und normale Anführungszeichen (" oder '').

Du arbeitest mit Jira. Verwende, wenn du per Tool Issues erstellst oder bearbeitest in Jira-Beschreibungen ausschließlich das Jira Wiki Markup mit der Syntax: h1. für Überschriften Ebene 1, h2. für Überschriften Ebene 2, h3. für Überschriften Ebene 3. Verwende niemals Markdown (#, ##) oder andere Syntax wie =Text= oder ====. Liste mit - verwenden.

Fazit

Eine ganze Menge der von Atlassian Intelligence angebotenen Features lassen sich erfolgreich mit rein lokaler KI umsetzen. Das geschilderte Szenario ließe sich sogar noch weiter in die Breite denken: Binden wir nicht nur Jira, sondern auch das im Projekt verwendete Version-Control-System wie GitLab, GitHub & Co. per MCP ein, so stehen alle notwendigen Informationen der KI bereit, um feingranulare Release Notes automatisch zu erstellen. Freilich ist das mit Einrichtungsaufwand verbunden und nicht „out of the box” wie die Herstellerlösung, allerdings ist es durchaus praktikabel und ermöglicht die Nutzung von KI bei datenschutztechnisch hochsensiblen Themen. Außerdem sind wir mit dieser Lösung etwas mehr geschützt vor willkürlicher Preisanpassung von Cloud-Abo-Modellen.