Nicht jede KI-Aufgabe braucht Rovo: So wird Jira-Automatisierung effizienter

Der Reflex, alles über Rovo laufen zu lassen

Das Problem liegt nicht grundsätzlich im Preis von Rovo, sondern darin, für welche Aufgaben dieser Preis anfällt. Ein großer Teil dessen, was in modernen Prozessen als „KI“ bezeichnet wird, ist technisch vergleichsweise einfach und wird gleichzeitig sehr häufig ausgeführt. Dazu gehören beispielsweise das Priorisieren einer eingehenden Jira-Service-Management-Anfrage, das Kategorisieren eines Tickets oder das Routing an das richtige Team. Solche Aufgaben mit dem gleichen Credit-Modell abzurechnen wie anspruchsvollere KI-Anwendungen, kann wirtschaftlich schnell unattraktiv werden.

Ein Rechenbeispiel zeigt die Größenordnung. Ein einfacher Rovo-Vorgang kostet nach aktuell veröffentlichter Preisliste 10 Credits, also rund 0,10 US-Dollar, sobald das enthaltene Kontingent aufgebraucht ist. Das ist bereits der günstigste Rovo-Fall. Bei 10.000 Priorisierungen im Monat entstehen damit etwa 1.000 US-Dollar. Wird dieselbe Aufgabe über ein günstiges externes Sprachmodell aus einer Klasse wie GPT-4o mini oder Gemini Flash verarbeitet, liegen die Kosten pro Vorgang häufig nur bei einem Bruchteil eines Cents. Der Unterschied kann damit zwei bis drei Größenordnungen betragen und entsteht ausgerechnet bei den Aufgaben, die nur wenig KI-Leistung benötigen.

Für jede Aufgabe das passende Modell

Atlassian Automation muss die eigentliche KI-Verarbeitung nicht zwingend selbst übernehmen. Eine Automationsregel kann ein Ticket über einen Outbound Request an ein externes Sprachmodell übergeben. Dieses Modell bewertet das Ticket nach klar definierten Vorgaben und gibt beispielsweise Priorität, Kategorie oder zuständiges Team an Jira zurück.

Das verwendete Modell kann dabei eine günstige externe API oder ein selbst betriebenes Sprachmodell sein. Rovo Credits lassen sich so gezielt für Aufgaben einsetzen, bei denen die native Atlassian-Integration tatsächlich einen Mehrwert bietet.

Diese Wahl ist außerdem nicht nur auf einfache Aufgaben beschränkt. Über Schnittstellen wie das Model Context Protocol von Atlassian kann auch ein eigenes Modell auf Atlassian-Kontext zugreifen. Dadurch können selbst kontextreiche Aufgaben außerhalb von Rovo verarbeitet werden. Wichtig bleibt jedoch: Ein Outbound Call verbraucht Automation Steps und kann Daten an einen externen Anbieter übertragen. Eine günstigere Lösung ist deshalb nicht automatisch auch die datenschutzrechtlich einfachere Lösung. Kosten, Datenschutz und Betriebsaufwand müssen getrennt bewertet werden.

Wiederkehrende Aufgaben brauchen oft gar keine Sprach-KI

Eine Automation setzt letztlich immer einen Prozess um. Deshalb lohnt es sich, einen Schritt zurückzugehen und nicht nur zu fragen, welches Sprachmodell eine Aufgabe übernehmen soll. Die wichtigere Frage lautet häufig: Ist das überhaupt ein Sprachproblem oder handelt es sich um eine wiederkehrende Entscheidung auf Basis stabiler Merkmale?

Auch eine Priorisierung muss nicht zwangsläufig durch ein Sprachmodell erfolgen. Wenn sich die Priorität beispielsweise regelmäßig aus Merkmalen wie dem Melder, dem betroffenen Service, der Kundenkategorie oder dem Tickettyp ableiten lässt, handelt es sich eher um einen klassischen Klassifikationsfall als um eine sprachliche Analyse.

Ein gutes Beispiel ist die Zuordnung eingehender Anfragen zum richtigen Team. Wenn bereits Tausende historisch gelöste Tickets vorhanden sind, kann ein darauf trainiertes Machine-Learning-Modell lernen, aus Merkmalen wie Betreff, betroffenem Service und Meldeweg das wahrscheinlich zuständige Team vorherzusagen. Ein solches Modell trifft eine Vorhersage auf Basis gelernter Muster, statt bei jedem neuen Vorgang erneut einen Text zu interpretieren.

Das macht solche Modelle für wiederkehrende Aufgaben interessant. Die Ergebnisse sind reproduzierbar und die Kosten pro zusätzlicher Vorhersage nach dem Training sehr gering. Dieselben Daten können außerdem genutzt werden, um beispielsweise frühzeitig zu erkennen, bei welchen Tickets eine SLA-Verletzung wahrscheinlich wird. Für stabile, häufig wiederkehrende Entscheidungen kann klassisches Machine Learning deshalb günstiger und teilweise zuverlässiger sein als ein Sprachmodell. Welche Aufgabe welche Form von KI tatsächlich benötigt, prüfen wir mit einem eigenen Team, das sich ausschließlich mit KI-Themen beschäftigt.

Wenn Rovo aus Datenschutzgründen ausfällt

Manche Kunden können oder wollen Rovo aufgrund interner oder regulatorischer Anforderungen nicht einsetzen. Gründe können interne Richtlinien, Vorgaben zum Datenstandort, Anforderungen des Betriebsrats oder besondere Vorgaben in regulierten Branchen sein. Das bedeutet allerdings nicht automatisch, dass KI in Jira oder Jira Service Management ausgeschlossen ist.

Eine mögliche Alternative besteht darin, ein Modell unter Kontrolle des Kunden zu betreiben. Das kann beispielsweise ein lokal betriebenes oder innerhalb der EU gehostetes Sprachmodell sein. Dadurch lässt sich technisch sicherstellen, dass Ticketdaten eine zuvor definierte Umgebung nicht verlassen.

Dieser Ansatz bringt jedoch zusätzliche Verantwortung mit sich. Ein eigenes Modell ist kein Plug-in, das lediglich aktiviert werden muss. Prompts, Versionierung, Security Reviews und der technische Betrieb müssen sauber geregelt werden. Bei extern betriebenen Modellen können zusätzlich vertragliche und datenschutzrechtliche Prüfungen notwendig sein.

Bis hin zu einer möglichen Datenschutz-Folgenabschätzung können wir die technischen Grundlagen aufbereiten, etwa Datenflüsse, Verarbeitungszwecke und die Grenzen des eingesetzten Modells. Die eigentliche rechtliche Bewertung bleibt jedoch Aufgabe der zuständigen internen oder externen Datenschutzeinheiten. Aus der Aussage „KI fällt aus Compliance-Gründen aus“ wird damit eine andere Fragestellung: „Unter welchen Bedingungen kann KI innerhalb unserer Vorgaben eingesetzt werden?“

Wann Rovo die richtige Wahl ist

Rovo wird durch diese Alternativen nicht überflüssig. Im Gegenteil: Rovo ist der native und von Atlassian verwaltete Weg, KI direkt innerhalb der Atlassian-Plattform einzusetzen. Besonders dort, wo agentische Oberflächen, umfangreicher Atlassian-Kontext oder mehrstufige Workflows ohne eigene technische Orchestrierung benötigt werden, spielt Rovo seine Stärke aus.

Genau für solche Aufgaben können auch die Credits sinnvoll eingesetzt werden, die zuvor bei einfacheren und häufig ausgeführten Prozessen eingespart wurden. Die Entscheidung lautet deshalb nicht „externes Modell gegen Rovo“. Sie lautet vielmehr: Jede Aufgabe sollte auf der technischen Ebene ausgeführt werden, die Anforderungen, Kosten und Datenschutz sinnvoll miteinander verbindet. Das kann klassisches Machine Learning, ein eigenes Sprachmodell oder Atlassian Rovo sein.

Diese Bandbreite entspricht auch unserem Beratungsansatz. Wir betrachten sowohl die native KI von Atlassian als auch individuell aufgebaute Lösungen mit eigenen Modellen. Welcher Ansatz für einen konkreten Prozess sinnvoll ist, ist aus unserer Sicht keine reine Produktfrage. Es ist eine Architektur- und Beratungsfrage, die beim eigentlichen Prozess hinter der Automation beginnt.

 Lassen Sie uns gemeinsam herausfinden, was für Ihren Anwendungsfall die beste Lösung ist:  Kontakt