Atlassian Rovo Alternative self-hosted: Wiki und KI-Suche im eigenen Betrieb

Hinweis zum Inhalt: Die Informationen in diesem Artikel wurden nach bestem Wissen zum Zeitpunkt der Veröffentlichung zusammengestellt. Technische Details, Preise, Versionen, Lizenzmodelle und externe Inhalte können sich ändern. Bitte prüfen Sie die genannten Angaben eigenständig, insbesondere vor geschäftskritischen oder sicherheitsrelevanten Entscheidungen. Dieser Artikel ersetzt keine individuelle Fach-, Rechts- oder Steuerberatung.

KI-Suche über das eigene Wiki, ohne Atlassian Cloud? WZ-IT baut interne KI-Assistenten mit Quellenangabe und Rechteprüfung auf XWiki, BookStack, Docmost oder Wiki.js und betreibt sie auf Wunsch im Managed-Open-Source-Betrieb. Termin vereinbaren
Atlassian Rovo verbindet Suche, Chat und Agenten über Confluence, Jira und angebundene Drittanwendungen. Rovo gibt es nur in der Atlassian Cloud. Für Organisationen, die Confluence auf eigenen Servern betreiben, ist das eine doppelte Frage: Confluence Data Center endet am 28. März 2029, und die KI-Funktion, die Atlassian als Nachfolger der klassischen Suche positioniert, setzt den Weg in die Cloud voraus.
Wer Wissen und Dokumente im eigenen Betrieb halten will, braucht deshalb zwei Dinge: ein Wiki, das Confluence ersetzt, und eine KI-Schicht, die über dieses Wiki sucht und antwortet, ohne Berechtigungen zu umgehen. Der Vergleich der Wikis selbst steht in den Beiträgen zu Open-Source-Alternativen zu Confluence und BookStack, Wiki.js, XWiki und Docmost. Dieser Beitrag behandelt die KI-Schicht: was Rovo leistet und kostet, welche Wikis eigene KI-Funktionen mitbringen und welche Kombinationen die Rechte tatsächlich einhalten. Stand September 2026.
Inhaltsverzeichnis
- Was Atlassian Rovo ist
- Was Rovo kostet
- Rovo und Confluence Data Center
- Wo Rovo die Daten verarbeitet
- Die self-hosted Alternative besteht aus zwei Schichten
- KI-Funktionen der Wikis im Vergleich
- Die KI-Schicht: Open WebUI, Onyx oder eigener RAG-Stack
- Berechtigungen entscheiden über die Auswahl
- Kombinationen, die sich bewährt haben
- Wo das Sprachmodell läuft
- Rovo und self-hosted im direkten Vergleich
- Unser Vorgehen bei WZ-IT
- Weiterführende Guides
Was Atlassian Rovo ist
Rovo ist die KI-Schicht der Atlassian Cloud. Sie baut auf dem Teamwork Graph auf, der Inhalte, Personen und Vorgänge aus Atlassian-Produkten und angebundenen Drittanwendungen verknüpft (Atlassian Support, What is Rovo).
| Bestandteil | Funktion |
|---|---|
| Search | Suche über Atlassian-Produkte, angebundene Drittanwendungen wie Google Drive oder Slack und eigene Websites |
| Chat | Dialog auf Basis von Unternehmensdaten aus Atlassian-Produkten und angebundenen Anwendungen |
| Agents | KI-Agenten, die Inhalte erstellen, Fragen beantworten und Abläufe ausführen |
| Studio | Oberfläche zum Bauen von Automatisierungen, Agenten und Company Hubs |
| Definitions | Erklärung firmeninterner Begriffe und Projektnamen im Kontext |
Rovo zeigt laut Atlassian nur Inhalte, auf die der Nutzer in der Quelle bereits Zugriff hat. Ab April 2025 wurde Rovo in den Premium- und Enterprise-Plänen ausgerollt, im Laufe des Jahres 2025 folgten die Standard-Pläne (Atlassian Community, Rollout für Standard).
Was Rovo kostet
Rovo wird nicht als eigenes Produkt pro Nutzer lizenziert. Die Nutzung wird über Credits abgerechnet, die in den bezahlten Cloud-Abonnements enthalten sind. Alle Kontingente einer Organisation fließen in einen gemeinsamen Pool (Atlassian Support, How Rovo credits work).
| Plan | Jira oder Confluence | Service Collection oder Teamwork Collection |
|---|---|---|
| Standard | 25 Credits pro Nutzer und Monat | 250 Credits pro Nutzer und Monat |
| Premium | 70 Credits pro Nutzer und Monat | 700 Credits pro Nutzer und Monat |
| Enterprise | 150 Credits pro Nutzer und Monat | 1.500 Credits pro Nutzer und Monat |
| Aktion | Verbrauch |
|---|---|
| Rovo Search in Atlassian-Apps, Definitionen, Zusammenfassungen | keine Credits |
| Rovo Chat (Quick answers), Basis-Agenten ohne Modellwahl | 10 Credits pro Vorgang |
| Think Deeper, Agenten mit Modellwahl, Folien, Jira-Agenten | variabel |
| produktübergreifende Abfragen im Teamwork Graph | typischerweise 1 bis 10 Credits pro Aufruf |
| Mehrnutzung über das Kontingent | 0,01 US-Dollar pro Credit (10 US-Dollar pro 1.000), gültig seit 31.08.2026 |
Die Mehrnutzung ist standardmäßig eingeschaltet. Administratoren können eine Obergrenze setzen oder sie abschalten; dann pausieren kostenpflichtige Interaktionen, sobald der Pool leer ist. Ein Confluence-Standard-Plan deckt mit 25 Credits pro Nutzer rechnerisch zwei Chat-Antworten pro Nutzer und Monat ab, die Suche ausgenommen. Wer Rovo als tägliches Werkzeug einführt, plant die Mehrnutzung deshalb von Anfang an mit ein.
Rovo und Confluence Data Center
Für Data Center gibt es kein Rovo. Es gibt einen Konnektor, der Inhalte aus Confluence Data Center in den Teamwork Graph der Cloud überträgt (Atlassian Support, Connect Confluence Data Center).
| Punkt | Stand September 2026 |
|---|---|
| Unterstützte Versionen | Confluence 9.4 und neuer, 9.2.6 LTS und neuer |
| Indexierte Inhalte | Seiten, Blogposts, Kommentare, Anhänge sowie Metadaten wie Ersteller, Bereiche, Labels und Aufrufzahlen |
| Ort der Indexierung | Atlassian Cloud (Teamwork Graph) |
| Voraussetzung | Atlassian-Cloud-Abonnement mit Rovo |
| Berechtigungen | Nutzer sehen laut Atlassian nur Inhalte, auf die sie in der Quelle Zugriff haben |
Der Konnektor ist damit kein On-Premises-Rovo, sondern eine Brücke in die Cloud. Wer Confluence Data Center gerade deshalb betreibt, weil Inhalte das eigene Rechenzentrum nicht verlassen sollen, erreicht mit dem Konnektor das Gegenteil.
Dazu kommt der Zeitplan für Data Center selbst (Atlassian, Data Center End of Life):
| Datum | Was passiert |
|---|---|
| 15.02.2024 | Ende des Supports für Confluence Server (vermerkt in der Onyx-Dokumentation) |
| 30.03.2026 | Keine neuen Data-Center-Abonnements und Marketplace-Apps für Neukunden |
| 30.03.2028 | Letzter Termin für Bestandskunden, neue Abonnements, Apps und Erweiterungen zu kaufen |
| 28.03.2029 | End of Life: Abonnements und Marketplace-Apps laufen aus, Instanzen werden schreibgeschützt |
Betroffen sind Jira Software, Jira Service Management, Confluence, Bamboo und Crowd Data Center. Bitbucket Data Center ist ausgenommen und erhält eine hybride Lizenz. Atlassian stellt eine verlängerte Wartung über 2029 hinaus nur im Einzelfall in Aussicht.
Wo Rovo die Daten verarbeitet
Rovo nutzt nach Angaben von Atlassian offene Modelle, unter anderem aus den Reihen Gemma, GPT-oss, Llama und Nemotron, sowie über Drittanbieter gehostete Modelle von OpenAI, Anthropic und Google (Atlassian, Rovo security, privacy and data use). Die Drittanbieter speichern Ein- und Ausgaben laut Atlassian nicht und nutzen sie nicht zur Verbesserung ihrer Dienste.
Die Daten-Residenz von Rovo erlaubt, Rovo-Daten in derselben Region zu speichern wie die Jira- oder Confluence-Daten. Sie regelt den Speicherort. Die Seite legt nicht offen, in welcher Region die Modelle eine Anfrage verarbeiten. Für Organisationen mit Vorgaben zu Auftragsverarbeitung und Drittlandübermittlung bleibt damit eine Prüfaufgabe, die bei einem selbst betriebenen Modell entfällt.
Die self-hosted Alternative besteht aus zwei Schichten
Rovo ist Wiki-Suche, Chat und Agentenplattform in einem Produkt. Im eigenen Betrieb verteilt sich das auf getrennte Bausteine:
| Schicht | Aufgabe | Beispiele |
|---|---|---|
| Wiki | Inhalte erstellen, strukturieren, versionieren, Rechte verwalten | XWiki, BookStack, Docmost, Wiki.js |
| Identitäten | Nutzer und Gruppen zentral verwalten, SSO | Keycloak oder das vorhandene Verzeichnis |
| Index und Retrieval | Inhalte zerlegen, einbetten, suchen, Rechte filtern | integriert im Wiki, Onyx oder Qdrant mit eigener Pipeline |
| Oberfläche | Chat mit Quellenangabe | Open WebUI, Onyx, Chat im Wiki |
| Modell | Antworten formulieren | lokal mit vLLM oder Ollama, europäische Modell-API, beides hinter LiteLLM |
Die Trennung hat einen Preis: Jemand muss die Teile zusammenfügen und die Rechte über alle Schichten hinweg konsistent halten. Sie hat einen Vorteil: Jede Schicht ist austauschbar, und das Modell lässt sich wechseln, ohne das Wiki anzufassen. Wie Retrieval-Augmented Generation technisch funktioniert, erklärt der Knowledge-Artikel Was ist RAG?.
KI-Funktionen der Wikis im Vergleich
Zwei der vier verbreiteten Open-Source-Wikis bringen eine eigene KI-Funktion mit. Stand September 2026:
| Wiki | Eigene KI-Funktion | Lizenz der KI-Funktion | Modellanbindung | Rechte bei KI-Antworten |
|---|---|---|---|---|
| XWiki | LLM Application mit Chat und Index für RAG | LGPL 2.1+, ab XWiki 17.4.0 | jeder OpenAI-kompatible Endpunkt | Rechteprüfung beim Abruf konfigurierbar, Index-Einträge selbst sind laut Forum für alle sichtbar |
| Docmost | Ask AI im Editor, AI Answers in der Suche | nur Business- und Enterprise-Edition | OpenAI, Google Gemini, Ollama | AI Answers durchsucht nur Inhalte, die der Nutzer sehen darf |
| BookStack | keine offizielle | - | - | - |
| Wiki.js | keine | - | - | - |
XWiki. Die LLM Application wird im Projekt xwiki-contrib entwickelt, der Versionsstand im Repository ist 0.10 (Tag vom 18.09.2026). Der Index für die LLM Application ist als Beta gekennzeichnet. In einer Diskussion im XWiki-Forum vom September 2025 wird beschrieben, dass die Antworten nach Leserechten gefiltert werden können, die indexierten Sammlungen und ihre Einträge aber für alle Nutzer einsehbar sind. Das ist vor dem Einsatz mit unterschiedlich berechtigten Bereichen zu prüfen. Die Einrichtung beschreibt der Beitrag XWiki mit KI einrichten.
Docmost. Die KI-Funktionen setzen eine gültige Business- oder Enterprise-Lizenz voraus (Docmost, AI). Welche weiteren Funktionen hinter der Lizenzgrenze liegen, zeigt der Beitrag Docmost Community gegen Enterprise Edition.
BookStack. Der BookStack-Entwickler stellt mit BookStack Query eine Erweiterung für Fragen an den Bestand bereit, mit Chroma als Vektordatenbank und einem OpenAI-kompatiblen Modell. Sie ist ausdrücklich als inoffizielle Anpassung gekennzeichnet und setzt laut Dokumentation noch keine Rechteprüfung durch: Ergebnisse können Inhalte enthalten, die der Nutzer nicht sehen darf. Für den produktiven Einsatz mit Rechten ist das kein Weg.
Wiki.js hat keine KI-Funktion. Hier kommt die KI-Schicht immer von außen.
Die KI-Schicht: Open WebUI, Onyx oder eigener RAG-Stack
Wo das Wiki keine passende KI-Funktion hat oder mehrere Quellen zusammen durchsucht werden sollen, kommt eine eigene KI-Schicht dazu. Drei Wege sind verbreitet.
| Kriterium | Open WebUI | Onyx | Eigener RAG-Stack |
|---|---|---|---|
| Lizenz | Open WebUI License (BSD-3 mit Branding-Klausel ab 50 Nutzern) | MIT, Verzeichnisse ee unter Onyx Enterprise License |
je nach Komponente, etwa Qdrant unter Apache 2.0 |
| Versionsstand | v0.11.4 vom 21.09.2026 | v4.8.0 vom 23.09.2026 | - |
| Wiki-Konnektoren | keine eingebauten, Befüllung per Upload, API oder Verzeichnis-Sync | Confluence (Cloud und Data Center), BookStack, MediaWiki, Outline u. a. | eigener Synchronisierungsdienst je Quelle |
| Rechte aus der Quelle | nein, Zugriff je Wissenssammlung | Rechte-Sync für Confluence nur in Enterprise Edition oder Onyx Cloud | beim Indexieren übernommen und vor der Suche angewendet |
| Stärke | verbreitete Chat-Oberfläche, viele Modelle | Konnektoren, Enterprise-Suche über viele Quellen | Rechte, Retrieval und Qualität frei gestaltbar |
Open WebUI ist die verbreitetste selbst betriebene Chat-Oberfläche. Wissenssammlungen werden per Upload, über die API oder durch Spiegelung eines Verzeichnisses befüllt; für entfernte Quellen wie Confluence verweist die Dokumentation auf das separate Werkzeug oikb. Die Branding-Klausel der Lizenz verbietet, den Namen und das Logo zu entfernen, sobald mehr als 50 Endnutzer in 30 Tagen zugreifen, außer mit Enterprise-Lizenz. Den Vergleich mit AnythingLLM beschreibt der Beitrag Open WebUI vs. AnythingLLM, die Anbindung an Nextcloud mit Rechten der Knowledge-Artikel Open WebUI an Nextcloud anbinden.
Onyx (früher Danswer) kommt dem Rovo-Ansatz am nächsten: Suche und Chat über viele angebundene Quellen. Die Lizenz trennt einen MIT-Teil von Enterprise-Verzeichnissen. Der Confluence-Konnektor unterstützt Data Center und Server; die Übernahme von Space-Rechten und Seitenbeschränkungen setzt aber die Enterprise Edition oder Onyx Cloud voraus (Onyx, Confluence Connector). Installation und Abgrenzung stehen im Beitrag Onyx self-hosted.
Ein eigener RAG-Stack besteht aus Synchronisierung, Vektordatenbank, Retrieval, Modell-Gateway und Oberfläche. Er ist der aufwendigere Weg und der einzige, bei dem Rechteprüfung, Suchverfahren und Qualitätsmessung vollständig in eigener Hand liegen. Für deutsche Fachtexte gehören dazu Hybrid Search und Reranking und eine saubere Aufteilung der Dokumente.
Berechtigungen entscheiden über die Auswahl
Ein Confluence-Bestand mit Space-Rechten und Seitenbeschränkungen hat meist gewachsene Bereiche, die nicht alle sehen dürfen: Personal, Geschäftsführung, Verträge, Kundenprojekte. Eine KI-Suche, die diese Grenzen ignoriert, zitiert im ersten Monat etwas, das sie nicht zitieren darf. Die Varianten unterscheiden sich genau hier:
| Variante | Wie Rechte gehandhabt werden | Folge |
|---|---|---|
| Onyx Community mit BookStack-Konnektor | Sichtbarkeit richtet sich nach dem API-Benutzer (Onyx, BookStack Connector) | alle Nutzer sehen, was der API-Benutzer sieht |
| Onyx Enterprise mit Confluence-Konnektor | Space-Rechte, Seitenbeschränkungen und vererbte Beschränkungen werden gespiegelt | Rechte der Quelle bleiben erhalten |
| Open WebUI Wissenssammlung | Zugriff je Sammlung, nicht je Dokument | Bereiche müssen als getrennte Sammlungen angelegt werden |
| XWiki LLM Application | Filterung der Antworten nach Leserechten konfigurierbar, Index-Einträge sichtbar | vor Einsatz mit geschützten Bereichen prüfen |
| Docmost AI Answers | Suche nur in sichtbaren Bereichen und Seiten | Rechte des Wikis gelten, Lizenz erforderlich |
| Eigener RAG-Stack | Rechte je Dokument im Index, Gruppen zur Laufzeit aus dem Verzeichnis | Aufwand in der Umsetzung, dafür prüfbar |
Die Grundsätze dazu beschreibt der Knowledge-Artikel RAG mit Berechtigungen: Rechte werden vor der Suche angewendet, nicht als Filter auf dem Ergebnis, und Gruppenzugehörigkeiten kommen aus dem Verzeichnisdienst statt aus einer Kopie beim Indexieren.
Kombinationen, die sich bewährt haben
Aus Wiki, KI-Schicht und Rechtemodell ergeben sich wenige sinnvolle Kombinationen:
| Ausgangslage | Wiki | KI-Schicht | Anmerkung |
|---|---|---|---|
| Ein Wiki, einheitliche Leserechte für alle Mitarbeitenden | BookStack oder Wiki.js | Open WebUI mit einer Wissenssammlung | geringster Aufwand, Rechte spielen keine Rolle |
| Moderner Editor, KI-Suche im Wiki gewünscht | Docmost | Docmost AI Answers | Business- oder Enterprise-Lizenz, lokales Modell über Ollama möglich |
| Große Installation, strukturierte Daten, Übergang von Confluence | XWiki | XWiki LLM Application | Rechteverhalten des Index vorher prüfen |
| Confluence Data Center bleibt bis 2029, später Wechsel | Confluence Data Center | Onyx Enterprise oder eigener RAG-Stack | Rechte-Sync nur mit Enterprise Edition |
| Wiki plus Dateiablage, Tickets und DMS, getrennte Bereiche | beliebig | eigener RAG-Stack mit Open WebUI als Oberfläche | Rechte je Dokument, mehrere Quellen |
Die letzte Zeile ist die Situation, für die Rovo gebaut ist: ein Suchzugang über mehrere Systeme. Im eigenen Betrieb ist sie auch die anspruchsvollste. Wie weitere Quellen wie Nextcloud, SharePoint oder ein DMS angebunden werden, beschreibt der Knowledge-Artikel RAG mit Nextcloud, SharePoint und DMS. Ob statt eines offenen Chats ein geführter Zugang auf kuratierte Inhalte besser passt, ordnet der Artikel Chatbot oder Wissens-Navigator? ein.
Wo das Sprachmodell läuft
Die Wiki-Inhalte bleiben im eigenen Betrieb. Offen ist, wohin eine Anfrage samt der gefundenen Textabschnitte zur Antwortformulierung geht. Drei Betriebswege:
| Betriebsweg | Daten verlassen das eigene Netz | Geeignet für |
|---|---|---|
| Lokales Modell auf eigener Hardware, etwa dem AI Cube im eigenen Netzwerk | nein | vertrauliche Bestände, Netze ohne Internetzugang |
| Managed GPU-Server von WZ-IT mit NVIDIA RTX PRO 4000 Blackwell (24 GB) oder RTX PRO 6000 Blackwell (96 GB) | an den Betreiber in Deutschland, nicht an einen Modellanbieter | Organisationen ohne eigenen Serverraum |
| Europäische Modell-API | an den API-Anbieter | geringe Anfragemengen, Einstieg |
Welche europäischen APIs es gibt und wie sie sich bei Standort, Vertrag und Modellauswahl unterscheiden, vergleicht der Beitrag Europäische LLM-APIs im Vergleich. Wie viel Grafikspeicher ein Modell braucht, erklärt der Artikel zum VRAM-Bedarf von LLMs. Ein Modell-Gateway wie LiteLLM erlaubt, zwischen diesen Wegen zu wechseln, ohne die Oberfläche anzupassen.
Rovo und self-hosted im direkten Vergleich
| Kriterium | Atlassian Rovo | Self-hosted Kombination |
|---|---|---|
| Betrieb | nur Atlassian Cloud | eigene Infrastruktur, Rechenzentrum in Deutschland oder eigenes Netz |
| Abrechnung | Credits im Cloud-Abonnement, Mehrnutzung 0,01 US-Dollar pro Credit | Betrieb, Hardware oder Modell-API, keine Abrechnung pro Anfrage bei lokalem Modell |
| Modelle | Auswahl durch Atlassian, darunter OpenAI, Anthropic, Google | frei wählbar, lokal oder europäische API |
| Quellen | Atlassian-Produkte und Rovo-Konnektoren | was per Konnektor oder eigener Synchronisierung angebunden wird |
| Rechte | aus den angebundenen Quellen | je nach Variante, siehe oben |
| Agenten und Automatisierung | Rovo Agents und Studio integriert | getrennte Werkzeuge, eigener Aufbau |
| Integrationsaufwand | gering innerhalb der Atlassian-Welt | Zusammenbau und Pflege mehrerer Komponenten |
Rovo ist innerhalb einer vollständig in der Atlassian Cloud arbeitenden Organisation der naheliegende Weg. Die self-hosted Kombination ist der Weg für Organisationen, die Confluence gerade wegen des Datenstandorts on-premises betreiben und diese Entscheidung für die KI-Suche nicht rückgängig machen wollen.
Unser Vorgehen bei WZ-IT
Wir beginnen bei den Inhalten und den Rechten, nicht beim Werkzeug.
- Bestandsaufnahme. Welches Wiki mit welcher Version, welche Spaces mit welchen Beschränkungen, welche weiteren Quellen, welches Verzeichnis für Nutzer und Gruppen.
- Zielbild festlegen. Bleibt das Wiki, wird es abgelöst, und welche KI-Schicht passt zum Rechtemodell. Liegen die gebrauchten Funktionen in einer freien oder einer lizenzpflichtigen Edition.
- Wiki bereitstellen oder migrieren. XWiki, BookStack, Docmost oder Wiki.js, angebunden an die vorhandenen Identitäten.
- KI-Schicht aufbauen. Als interner KI-Assistent mit Qdrant, LiteLLM und Open WebUI, Rechte vor der Suche angewendet, jede Antwort mit Dokument und Fundstelle.
- Qualität messen. Mit Testfragen aus dem eigenen Bestand, bevor der Assistent freigegeben wird. Wie das abläuft, beschreibt der Artikel RAG-Qualität messen. Für einen abgegrenzten ersten Bestand gibt es den RAG Proof of Value.
- Betrieb. Updates, Sicherung und Überwachung von Wiki, Index und Modell, auf Ihrer Hardware, auf dem AI Cube oder auf einem Managed GPU-Server. Support, Beratung und Implementierung durch WZ-IT.
Weiterführende Guides
- Open-Source-Alternativen zu Confluence, Docmost, BookStack und Wiki.js als Ersatz für das Wiki selbst.
- BookStack, Wiki.js, XWiki oder Docmost, Lizenzen, Struktur und Funktionsgrenzen im Vergleich.
- XWiki mit KI einrichten, die LLM Application an ein lokales Modell anbinden.
- Onyx self-hosted, Installation und Vergleich mit Open WebUI.
- Europäische LLM-APIs im Vergleich, wenn das Modell nicht lokal laufen soll.
- KI-Lösungen von WZ-IT, Hardware, Modellbetrieb und Assistenten im Überblick.
Confluence on-premises und trotzdem KI-Suche? Wir ordnen Wiki, KI-Schicht und Rechtemodell ein und bauen die Kombination auf Ihrer Infrastruktur oder in unserem Betrieb auf. Termin vereinbaren
Quellen
- Atlassian, Data Center End of Life
- Atlassian Support, How Rovo credits work
- Atlassian Support, What is Rovo
- Atlassian Support, Connect Confluence Data Center to Teamwork Graph
- Atlassian, Rovo security, privacy and data use
- Atlassian Community, Rovo is now rolling out for Standard customers
- XWiki LLM Application auf GitHub
- XWiki-Forum, Rechte der Index-Einträge der LLM Application
- Docmost, AI
- BookStack Query auf Codeberg
- Open WebUI, Knowledge
- Open WebUI, Lizenz
- Onyx, Lizenz
- Onyx, Confluence Connector
- Onyx, BookStack Connector
KI-Suche über das eigene Wiki, ohne Atlassian Cloud
Wir ordnen ein, welche Kombination aus Wiki, KI-Schicht und Modell zu Ihrem Bestand und Ihren Berechtigungen passt, und setzen sie auf Ihrer Infrastruktur oder in unserem Betrieb um.
Häufig gestellte Fragen
Antworten auf wichtige Fragen zu diesem Thema
Nein, Rovo selbst ist ein Cloud-Dienst. Für Confluence Data Center gibt es einen Rovo-Konnektor ab Confluence 9.4 sowie 9.2.6 LTS. Er indexiert Seiten, Blogposts, Kommentare und Anhänge in den Teamwork Graph der Atlassian Cloud und setzt ein Atlassian-Cloud-Abonnement voraus. Die Inhalte werden damit in der Cloud verarbeitet, auch wenn das Wiki selbst on-premises läuft.
Rovo ist in allen bezahlten Cloud-Plänen enthalten, aber mit einem Kontingent. Pro Nutzer und Monat sind es in Jira und Confluence 25 Credits im Standard-, 70 im Premium- und 150 im Enterprise-Plan. Die Suche kostet keine Credits, eine Chat-Antwort 10 Credits. Darüber hinaus berechnet Atlassian seit dem 31. August 2026 0,01 US-Dollar pro Credit. Die Mehrnutzung ist standardmäßig aktiviert und lässt sich deckeln oder abschalten.
Am 28. März 2029. Dann laufen Data-Center-Abonnements und zugehörige Marketplace-Apps aus, die Instanzen werden schreibgeschützt. Neukunden können seit dem 30. März 2026 kein Data Center mehr kaufen, Bestandskunden können bis zum 30. März 2028 erweitern. Bis zum Ende gibt es technischen Support und Sicherheitskorrekturen für kritische Lücken.
Laut Atlassian eine Mischung aus offenen Modellen (unter anderem Gemma, GPT-oss, Llama und Nemotron) und über Drittanbieter gehosteten Modellen von OpenAI, Anthropic und Google. Die Drittanbieter speichern Ein- und Ausgaben nach Atlassian-Angaben nicht und nutzen sie nicht zum Training. Die Daten-Residenz von Rovo bezieht sich auf die Region, in der Rovo-Daten gespeichert werden.
Nein, nicht im offiziellen Funktionsumfang. Es gibt eine Erweiterung namens BookStack Query vom BookStack-Entwickler, die ausdrücklich als inoffizielle Anpassung gekennzeichnet ist und laut Dokumentation noch keine Rechteprüfung durchsetzt. Für eine KI-Suche mit Berechtigungen braucht BookStack eine separate KI-Schicht.
Nicht in jedem Fall. Die Rechte-Synchronisierung für Confluence setzt die Onyx Enterprise Edition oder Onyx Cloud voraus. Der BookStack-Konnektor indexiert alles, was der API-Benutzer sehen darf, und bildet die Rechte einzelner Nutzer nicht ab. Wer unterschiedlich berechtigte Bereiche hat, muss das vor der Auswahl prüfen.
Docmost bietet Ask AI im Editor und AI Answers in der Suche, beides nur in der Business- und Enterprise-Edition; AI Answers durchsucht nur Inhalte, die der Nutzer sehen darf. XWiki hat die LLM Application unter LGPL 2.1, mit Chat, einem Index für RAG und Anbindung an OpenAI-kompatible Endpunkte. BookStack und Wiki.js haben keine offizielle KI-Funktion.
Nicht eingebaut. Wissenssammlungen in Open WebUI werden per Upload, API oder Verzeichnis-Synchronisierung befüllt. Für entfernte Quellen wie Confluence verweist die Dokumentation auf das separate Werkzeug oikb. In der Praxis übernimmt ein eigener Synchronisierungsdienst den Abgleich zwischen Wiki und Wissenssammlung.
Nicht zwingend. Wiki und Suchindex laufen auf normaler Hardware. Das Sprachmodell kann lokal auf einer GPU laufen, etwa auf einer KI-Appliance im eigenen Netzwerk oder einem verwalteten GPU-Server, oder über eine europäische Modell-API angebunden werden. Die Wahl hängt davon ab, ob Inhalte das eigene Netz verlassen dürfen.

Geschrieben von
Timo Wevelsiep
Co-Founder & CEO
Co-Founder von WZ-IT. Spezialisiert auf Cloud-Infrastruktur, Open-Source-Plattformen und Managed Services für KMUs und Enterprise-Kunden weltweit.
LinkedInLassen Sie uns über Ihre Idee sprechen
Ob konkrete IT-Herausforderung oder einfach eine Idee - wir freuen uns auf den Austausch. In einem kurzen Gespräch prüfen wir gemeinsam, ob und wie Ihr Projekt zu WZ-IT passt.





