Atlassian Rovo ist endlich nützlich. Warum machst du die Routine noch selbst?

Der größte Unterschied liegt nicht im Chatfenster, sondern im Kontext dahinter. Während du einer allgemeinen KI viele Informationen erst manuell geben musst, kann Atlassian Rovo über den Teamwork Graph Zusammenhänge aus Jira, Confluence, Jira Service Management und angebundenen Systemen nutzen. Dabei bleiben die vorhandenen Berechtigungen maßgeblich: Ein Nutzer bekommt über Rovo grundsätzlich nicht plötzlich Zugriff auf Inhalte, die er im Quellsystem selbst nicht sehen darf.

Dazu kommt der Unterschied zwischen Antworten und echter Arbeit. In Rovo Search, Rovo Chat und Rovo Studio kannst du nicht nur suchen oder Inhalte zusammenfassen, sondern Rovo Agents mit konkreten Tools ausstatten. Solche Agent-Tools können zum Beispiel Jira Work Items anlegen, Status ändern, JQL ausführen, Confluence-Seiten erstellen oder Service Requests erfassen.

Das macht Rovo aber nicht automatisch zur besseren KI für jeden Zweck. Für freie Kreativarbeit, allgemeine Recherche oder Aufgaben ohne Bezug zu euren Unternehmensdaten kann ChatGPT oder ein anderes spezialisiertes Modell genauso sinnvoll sein. Rovos eigentliche Stärke ist die Verbindung aus Unternehmenswissen, Atlassian-Kontext, Berechtigungen und ausführbaren Aktionen – also genau dann, wenn aus einer Antwort anschließend echte Arbeit werden soll.

Jein. Wenn dein Unternehmen bereits einen berechtigten Standard-, Premium- oder Enterprise-Cloud-Tarif von Jira, Confluence oder Jira Service Management beziehungsweise eine passende Collection nutzt, ist Rovo grundsätzlich im Tarif enthalten und muss nicht als separates Kernprodukt gekauft werden. Die aktuellen Zugangs- und Lizenzregeln findest du direkt in den Rovo-Plänen und Lizenzinformationen.

Für die intensiveren AI-Funktionen arbeitet Atlassian inzwischen mit Rovo Credits. Wie viele Credits monatlich enthalten sind, hängt vom Produkt und Tarif ab; sie werden auf Organisationsebene gepoolt und jeden Monat neu bereitgestellt. Die aktuellen Kontingente und die Mechanik erklärt die Übersicht zu Rovo Credits und Usage Limits. Ab dem 3. Dezember 2026 greift für Mehrverbrauch das nutzungsbasierte Preismodell; zusätzliche Credits kosten nach aktueller Liste 0,01 US-Dollar pro Credit, sofern Extra Usage zugelassen ist.

Daneben gibt es aktuell Rovo Standard als Beta für Nutzer, die Rovo auch ohne bezahltes Jira-, Confluence- oder JSM-Abo als eigenständige App verwenden möchten. Während der Beta wird diese Subscription nicht berechnet; danach fällt die Organisation zunächst auf Rovo Free zurück, sofern sie nicht aktiv auf den kostenpflichtigen Standard-Tarif wechselt. Rovo Dev ist wiederum separat verpackt und bepreist – das sollte bei Developer-Use-Cases zusätzlich eingeplant werden.

Die technische Aktivierung ist der einfache Teil. Ein Organisationsadmin kann über Rovo Access steuern, in welchen Atlassian-Apps Rovo verfügbar ist; bei Bitbucket gelten zusätzlich eigene AI-Einstellungen im Workspace. Wichtiger ist die Frage, welche konkrete Arbeit Rovo überhaupt übernehmen soll.

Danach solltest du den Use Case bewusst klein schneiden: Welche Informationen braucht Rovo, welche Systeme darf es sehen und welche Aktionen darf es ausführen? Für eigene Agents werden diese Bausteine in Rovo Studio festgelegt. Die Wissensbasis sollte dabei nicht pauschal „alles“ sein: Über gezielt begrenzte Knowledge Sources lassen sich zum Beispiel einzelne Jira-Spaces, Confluence-Bereiche oder externe Quellen vorgeben.

Bei schreibenden Funktionen lohnt es sich außerdem, nicht nur mit natürlicher Sprache zu arbeiten. Für unterstützte Tools kannst du feste Tool-Parameter konfigurieren, etwa einen bestimmten Service Desk, Request Type oder Confluence-Space. Das reduziert Interpretationsspielraum und macht Agents im Alltag berechenbarer.

Vor einem breiteren Rollout sollte ein Agent mit echten Beispielen getestet werden. Rovo bietet dafür inzwischen eigene Evaluations mit Test-Datensätzen, sodass du Antwortqualität und Resolution Rate nicht nur nach Bauchgefühl beurteilen musst. Erst wenn ein Use Case stabil läuft, würden wir ihn auf weitere Teams oder autonome Aktionen ausweiten.

Bei Techanics unterstützen wir dich dabei, aus diesen Möglichkeiten ein sauberes Setup statt eines Agenten-Zoos zu machen: Wir analysieren zuerst eure Prozesse, grenzen sinnvolle Use Cases ein und konfigurieren anschließend Berechtigungen, Knowledge Sources, Tools, Agents und Automationen so, dass sie im Alltag wirklich zusammenpassen. Wenn du Rovo nicht nur ausprobieren, sondern strukturiert in eure Atlassian-Landschaft integrieren möchtest, begleiten wir dich im Rahmen unserer Atlassian-Beratung von der ersten Idee bis zum produktiven Einsatz.

Ein Rovo Agent bekommt nicht automatisch Adminrechte. Bei der Einrichtung legst du fest, ob er mit dem Konto des jeweiligen Nutzers oder mit einem eigenen Agent Account arbeitet. Beim User Account erbt er die Berechtigungen der Person, die ihn verwendet; beim Agent Account lassen sich App-, Space- und Inhaltsrechte separat vergeben. Gerade für Automationen ist ein eigener, bewusst eingeschränkter Agent Account meist die sauberere Variante.

Was der Agent tatsächlich tun kann, hängt zusätzlich von seinen Tools ab. Mit den verfügbaren Jira-Tools kann ein passend konfigurierter Agent unter anderem Work Items erstellen, Status aktualisieren oder per JQL suchen. Fehlt das Tool oder fehlt die Berechtigung im Zielprojekt, kann die Aktion nicht erfolgreich ausgeführt werden.

Ja, Work Items können auch ohne einzelne Bestätigung verändert werden – allerdings nur, wenn du den Agent bewusst in einen autonomen Ablauf einbaust. In Automation Flows kann die Bestätigung für einzelne Aktionen entfallen; gleichzeitig lässt sich die Nutzung auf reine Read-Aktionen begrenzen. Für produktive Automationen sollten deshalb Rechte, Tools und Zielbereiche so eng wie möglich gehalten werden.

Ein zusätzlicher Vorteil eigener Agent Accounts ist die Nachvollziehbarkeit: Änderungen erscheinen unter der Identität des Agents und lassen sich dadurch in Audit- und Verlaufskontexten besser von menschlichen Änderungen unterscheiden.

Die kurze Antwort lautet: Rovo kann in einem DSGVO-konformen Setup eingesetzt werden, ist aber nicht automatisch für jeden Prozess „DSGVO-konform“. Entscheidend sind unter anderem Rechtsgrundlage, Datenarten, Rollen, Berechtigungen und die Frage, welche Inhalte überhaupt in einen AI-Use-Case einfließen. Für die Cloud-Nutzung gelten unter anderem das Atlassian Data Processing Addendum und die darin geregelten Datenschutz- und Transfermechanismen.

Technisch unterstützt Rovo Data Residency sowie SOC 2 und ISO 27001. Gleichzeitig kann AI-Verarbeitung standardmäßig über externe LLM-Anbieter wie OpenAI, Google oder Anthropic auf AWS Bedrock laufen. Die jeweiligen Anbieter speichern die übermittelten Ein- und Ausgaben nicht für eigenes Modelltraining; für diese Verarbeitung gelten Zero-Data-Retention-Vereinbarungen. Die Details dazu sind im AI Trust Center und den Transparenzinformationen dokumentiert.

Wichtig ist die Unterscheidung zwischen LLM-Verarbeitung und Data Contribution. Über die Data-Contribution-Einstellungen lässt sich steuern, ob In-App-Daten zur Verbesserung von Atlassian-Produkten und AI-Erlebnissen beigetragen werden. Je nach Tarif unterscheiden sich die Defaults und die verfügbaren Steuerungsmöglichkeiten. Das ist etwas anderes als die Frage, ob ein externer LLM-Provider eure Prompts zum Training seines eigenen Modells verwenden darf.

Für Unternehmen mit besonders strengen Anforderungen gibt es auf Enterprise-Ebene außerdem Atlassian-hosted LLMs. In diesem Modus bleibt die LLM-Verarbeitung innerhalb der Atlassian-Cloud-Grenze und Prompts beziehungsweise Kontext werden nicht an externe LLM-Anbieter gesendet. Diese Option ist derzeit auf Anfrage für Cloud Enterprise verfügbar.

Für sensible Kunden-, Personal-, Gesundheits- oder Vertragsdaten würden wir trotzdem nicht allein auf Produktzertifizierungen vertrauen. Hier sollte vorab geprüft werden, ob Rovo für diesen Prozess überhaupt notwendig ist, welche Daten wirklich gebraucht werden und ob sich der Use Case mit weniger sensiblen Informationen lösen lässt.

Für uns bei Techanics gehört deshalb mehr dazu als die technische Aktivierung von Rovo: Wir helfen dir auch bei der praktischen Einordnung: Welche Prozesse eignen sich für AI, wo sollten sensible Daten bewusst außen vor bleiben, welche Berechtigungen braucht ein Agent wirklich und welche Data-Contribution-, Knowledge- oder Zugriffseinstellungen sind sinnvoll? Gerade bei produktiven Rovo-Use-Cases prüfen wir gemeinsam mit dir, wie sich Nutzen, Datenschutz und möglichst geringe Datenfreigabe sinnvoll miteinander verbinden lassen.

Ja, grundsätzlich schon – sobald ein Agent schreibende Tools bekommt und autonom handeln darf. Deshalb sollten produktive Agents wie eine ernsthafte Automation behandelt werden und nicht wie ein harmloser Chatbot. Die Sicherheitsleitlinien für autonome Rovo Agents weisen ausdrücklich darauf hin, dass Agents Instructions falsch interpretieren oder durch Prompt Injection beeinflusst werden können.

Im interaktiven Einsatz bleibt bei folgenreichen Aktionen normalerweise ein Mensch im Loop. Kritischer wird es in Automationen, wenn ein Agent ohne Bestätigung schreiben darf. Dort würden wir immer mit Least Privilege, kleinen Zielbereichen und möglichst wenig schreibenden Tools arbeiten. Ein eigener Agent Account mit begrenzten Rechten reduziert den möglichen Schaden zusätzlich.

Vorsicht ist auch bei Inhalten unbekannter Herkunft sinnvoll. Indirekte Prompt Injections können in Work-Item-Feldern, Webseiten oder Dateien stecken, die der Agent als Kontext liest. Für Agents mit kritischen Aktionen sollten externe Dokumente – insbesondere unbekannte PDFs oder Webinhalte – deshalb nicht ungeprüft als Steuerungsgrundlage dienen. Wo möglich, können fest konfigurierte Tool-Ziele den Aktionsradius zusätzlich begrenzen.

Genau an dieser Stelle lohnt sich ein erfahrener Partner besonders. Techanics unterstützt dich dabei, schreibende Rovo Agents bewusst zu begrenzen, dass Rechte, Tools, Zielprojekte und Automationen zum tatsächlichen Use Case passen, testen kritische Szenarien vor dem Rollout und bauen dort menschliche Freigaben ein, wo sie sinnvoll sind. So wird aus einem mächtigen Agenten kein unnötiges Risiko, sondern eine kontrollierbare Erweiterung eurer Atlassian-Prozesse.

Besonders gut eignet sich Rovo für Aufgaben, die regelmäßig wiederkehren, viel Kontext benötigen und trotzdem nach einem relativ klaren Muster ablaufen. In den vorhandenen Rovo Skills stecken dafür bereits sehr konkrete Bausteine: Status-Updates schreiben, Jira Work Items aus Beschreibungen erzeugen, Meeting-Notizen in Action Plans verwandeln, How-to-Artikel erstellen, Incidents zusammenfassen oder Release Notes aus einer Jira-Version vorbereiten.

Im Jira-Alltag ist auch die Suche ein guter Kandidat. Statt komplexe Abfragen von Hand zu schreiben, kann Rovo natürliche Sprache in JQL für die Work-Item-Suche übersetzen – zum Beispiel für offene, überfällige oder nicht zugewiesene Aufgaben.

Über Agent-Tools kommen echte Aktionen hinzu: Jira Work Items erstellen oder aktualisieren, Confluence-Seiten anlegen, JSM-Requests erfassen oder externe Tools wie Gmail und Google Calendar ansteuern. Entscheidend ist aber nicht die Menge an Funktionen, sondern die Auswahl der Aufgaben, die dein Team heute tatsächlich Zeit kosten.

Gute Kandidaten sind deshalb oft Informationssuche, Triage, Dokumentationspflege, Statuskommunikation, Vorbereitung von Tickets und wiederkehrende Backend-Schritte. Entscheidungen mit hoher fachlicher Verantwortung oder sensiblen Auswirkungen würden wir dagegen nicht vollständig an einen autonomen Agent auslagern.

Im Helpdesk hängt die Qualität weniger von einem einzelnen „magischen“ Modell ab als von eurer Wissensbasis und den Prozessen dahinter. Ein Rovo Agent im JSM Help Center kann Kunden schon auf der Startseite helfen, Inhalte aus verknüpften Knowledge Bases verwenden und gezielt Skills ausführen. Je sauberer die Artikel und Instructions sind, desto stabiler sind typischerweise die Antworten.

Besonders praktisch ist die Request-Erstellung. Mit dem Raise-a-Request-Skill kann ein Agent Informationen im Gespräch einsammeln, passende Request Types berücksichtigen und Pflichtfelder für einen neuen Jira-Service-Management-Request befüllen. Für wiederkehrende IT-, Zugriffs-, Onboarding- oder interne Servicefälle ist das deutlich hilfreicher als ein Chatbot, der nur Antworten ausgibt.

Für die Triage gibt es ebenfalls spezialisierte Möglichkeiten. Der Triage Assistant kann eingehende Tickets analysieren und beispielsweise Zusammenfassung, Priorität, Dringlichkeit oder Request Type vorbereiten beziehungsweise aktualisieren.

Noch weiter geht der Request Resolver: Er kann für Service Requests einen Lösungsplan erstellen und diesen überwacht oder autonom ausführen. Im autonomen Modus pausiert er bei niedriger Sicherheit und wartet auf einen Menschen; die Execution Modes lassen sich pro Request Type festlegen. Genau deshalb würden wir zunächst wenige, gut verstandene Request Types produktiv testen und erst danach breiter automatisieren.

Im Helpdesk denken wir bei Techanics Rovo deshalb immer als Teil des gesamten Serviceprozesses – zusammen mit einer sauberen Knowledge Base, passenden Request Types, klaren Agent-Instructions und sinnvoll gewählten Eskalationspunkten. Bei Bedarf optimieren wir gleichzeitig euren Service Desk mit Jira Service Management, damit Rovo nicht nur gute Antworten erzeugt, sondern wirklich in einen verlässlichen Serviceprozess eingebettet ist.

Ja – wenn es einen klaren Engpass löst. Gerade kleinere Teams profitieren oft überproportional von einem Agent, der regelmäßig Statusberichte vorbereitet, interne Fragen beantwortet oder Service Requests vorsortiert, weil solche Nebenaufgaben sonst bei wenigen Personen hängen bleiben. Ein flächendeckender Rollout mit vielen komplexen Agents ist dafür nicht nötig.

Entscheidend ist die Wirtschaftlichkeit. Die im Tarif enthaltenen Rovo Credits werden organisationsweit gepoolt; mit tieferem Reasoning steigt der Verbrauch. Für KMUs würden wir deshalb mit einem oder zwei messbaren Use Cases starten und Nutzung gegen eingesparte Arbeitszeit halten. Wenn der Bedarf deutlich wächst, bietet die Rovo-Lizenzierung verschiedene Wege über bestehende App-Tarife, Collections und zusätzliche Credits.

Neben Jira, Confluence, Jira Service Management und weiteren Atlassian-Apps kann Rovo Wissen aus vielen Drittsystemen einbeziehen. Der aktuelle Connector-Katalog umfasst unter anderem Google Drive, SharePoint, Slack, Gmail, GitHub, GitLab, Figma, Dropbox, Box, Notion, Azure DevOps, HubSpot und weitere Dienste.

Dabei ist Connector nicht gleich Connector. Atlassian unterscheidet Synced, Direct und Smart Link Connectors. Synced Connectors indexieren Inhalte und liefern den vollständigsten Suchkontext; Direct Connectors holen Daten zur Laufzeit über die API des Anbieters; Smart Links stellen nur begrenzteren Kontext aus bereits verwendeten Links zur Verfügung. Das ist für Suchqualität, Data Residency und Governance relevant.

Bevor eine externe Quelle angebunden wird, sollte deshalb geprüft werden, welche Daten darin liegen und ob sie überhaupt in Rovo gebraucht werden. Die Connector-Verwaltung berücksichtigt dafür Berechtigungen und unterschiedliche Authentifizierungsmodelle. Mehr Daten sind nicht automatisch besser – gezielter Kontext liefert häufig die verlässlichere Antwort.

Sehr viele. Ein eigener Agent besteht nicht nur aus einem Prompt, sondern aus mehreren Ebenen: Identität, Verhalten, Wissen, Subagents, Tools und Skills. Die Agent-Struktur in Rovo Studio erlaubt es dadurch, sehr spezialisierte Assistenten für Support, Projektarbeit, Dokumentation oder interne Prozesse aufzubauen.

Die Instructions definieren Aufgabe, Tonalität und Guardrails. Bei komplexen Agents würden wir die Regeln nicht endlos in einen einzigen Prompt packen, sondern mit Subagents für einzelne Szenarien arbeiten. Jeder Subagent kann eigene Instructions, Knowledge Sources und Tools erhalten und dadurch einen klar abgegrenzten Teil der Aufgabe übernehmen.

Auch Wissen und Aktionen lassen sich gezielt zuschneiden. Über Custom Knowledge kann ein Agent auf bestimmte Jira-Spaces, Confluence-Bereiche oder externe Quellen begrenzt werden; über Tool Configuration lassen sich für unterstützte Aktionen feste Zielwerte wie Space oder Request Type vorgeben.

Schließlich kannst du sogar beeinflussen, wie tief der Agent denkt. Für Rovo Agents gibt es Quick Answers und Think deeper als Reasoning-Tiers. Die richtige Wahl ist ein Kompromiss aus Geschwindigkeit, Qualität und Credits. Für produktive Agents lohnt sich anschließend eine Evaluation mit realistischen Testfällen, statt die Qualität nur anhand einzelner Demo-Prompts zu beurteilen.

Aus unseren bisherigen Rovo-Projekten bei Techanics bringen wir bereits praktische Erfahrung mit Agents, Knowledge Sources, Tools, Reasoning und Automationen praktisch getestet und unterstützen dich dabei, daraus ein möglichst schlankes, belastbares Setup nach aktuellem Stand der Atlassian-Plattform zu bauen. Statt möglichst viele Funktionen zu aktivieren, setzen wir auf klare Zuständigkeiten, kleine Agenten-Aufgaben und Best Practices, die sich im echten Arbeitsalltag bewähren.

Ja. Schon innerhalb von Rovo Studio lassen sich eigene Apps bauen, etwa Formulare, Dashboards, Approval Workflows oder interne Tools für Jira und Confluence. Unter der Oberfläche entstehen dabei echte Forge-Apps mit Atlassian-Hosting, Berechtigungen und Produktintegration.

Wenn No-Code nicht reicht, kann die Erweiterung direkt über Forge erfolgen. Die Forge-Module für Rovo ermöglichen eigene Agents, Skills und Actions; mit Rovo MCP können selbst entwickelte Actions als Tools in Rovo Studio und – nach Admin-Freigabe – auch in externen MCP-kompatiblen AI-Clients bereitgestellt werden.

Zusätzlich können Admins Rovo Agents aus dem Atlassian Marketplace installieren. Für einige externe Dienste gibt es außerdem fertige MCP-basierte Third-Party-Agents. Bei solchen Integrationen sollte allerdings separat geprüft werden, welche Daten Atlassian verlassen und welche Datenschutzbedingungen des Drittanbieters gelten.

Solche Erweiterungen entwickeln wir bei Techanics auch maßgeschneidert für dich – von eigenen Rovo Agents und Forge-Actions bis zu Apps, die genau auf eure Jira-, Confluence- oder JSM-Prozesse zugeschnitten sind. Mehr zu unserer technischen Umsetzung findest du auf unserer Atlassian-Forge-Seite; Beispiele für eigene Erweiterungen findest du außerdem bei Techanics Labs im Atlassian Marketplace. Gerade wenn Standardfunktionen nicht exakt zu eurem Prozess passen, ist eine kleine, gezielte Erweiterung oft sinnvoller als ein unnötig kompliziertes Workaround-Setup.

Die wichtigste Grenze ist dieselbe wie bei anderen generativen KI-Systemen: Antworten und Entscheidungen sind probabilistisch. Bei langen Instructions, vielen Abhängigkeiten und großen Kontextmengen kann Rovo einzelne Vorgaben schwächer gewichten, Zusammenhänge übersehen oder denselben Auftrag bei mehreren Durchläufen etwas anders lösen. Für einfache Fragen ist Basic Chat gedacht; komplexere Aufgaben profitieren von Think deeper oder Deep research.

Auch ein stärkeres Modell ist keine Garantie für identische Ergebnisse. Die aktuellen Model-Behavior-Guidelines für Rovo Agents beschreiben ausdrücklich, dass sich Modelle bei Tool-Auswahl, Format-Treue, Planung, Antwortlänge und Kontextverarbeitung unterscheiden können. Deshalb sollten produktive Agents immer gegen konkrete Akzeptanzkriterien getestet werden.

Eine weitere Grenze entsteht, sobald Agents autonom handeln. Guardrails helfen, sind aber keine harte technische Garantie. Die Best Practices für autonome Agents empfehlen deshalb menschliche Kontrolle bei kritischen Aktionen, begrenzte Rechte und Schutz vor Prompt Injection. Besonders Inhalte unbekannter Herkunft sollten nicht unkritisch als Handlungsanweisung dienen.

Schließlich spielt auch Wirtschaftlichkeit eine Rolle. Tiefes Reasoning, Agent-Orchestrierung und umfangreicher Kontext können mehr Rovo Credits verbrauchen als einfache Antworten. Die beste Rovo-Lösung ist deshalb nicht die mit den meisten AI-Funktionen, sondern die, die für den jeweiligen Prozess zuverlässig genug ist und ihren zusätzlichen Aufwand tatsächlich rechtfertigt.

Einen ersten Agent kannst du ohne Partner selbst bauen – und für einfache persönliche Helfer ist das oft auch sinnvoll. Komplex wird es, sobald der Agent produktiv in Jira, Confluence, Jira Service Management oder Bitbucket eingreift und dabei Berechtigungen, Wissen, Automationen, Datenschutz und laufende Kosten zusammenspielen. Genau für solche Umsetzungen sind Atlassian Solution Partner auf Beratung, Konfiguration, Customizing und Implementierung ausgerichtet.

Der Vorteil liegt weniger darin, dass jemand für dich auf „Agent erstellen“ klickt. Ein Partner sollte zuerst die Prozesse identifizieren, bei denen Rovo wirklich Arbeit abnimmt, danach Knowledge Sources und Berechtigungen sauber begrenzen, Agents testen und Nutzungskosten im Blick behalten. Gerade bei JSM-Triage, autonomen Agents, Forge-Erweiterungen oder mehreren verbundenen Datenquellen spart ein sauberer Aufbau später deutlich mehr Aufwand als eine schnelle Demo-Konfiguration.

Unser Ansatz bei Techanics: Wir verbinden die Rovo-Konfiguration mit eurem bestehenden Atlassian-Setup und denken die Umsetzung vom Rovo-Studio-Backend bis zur täglichen Nutzung in Jira, Confluence, JSM und Bitbucket durch. Als Atlassian Gold Solution Partner arbeiten wir dabei mit dem Ziel, möglichst viel echte Entlastung bei möglichst wenig unnötiger Komplexität und Folgekosten zu schaffen. Wenn du erst prüfen möchtest, wo Rovo bei euch sinnvoll wäre, kannst du über unsere Kontaktseite direkt mit uns sprechen.