Der wichtigste Satz vorweg: Nuclino ist bewusst kein Alleskönner, und darin liegt sein Nutzen. Wer eine Plattform sucht, die zugleich Wiki, Datenbank, Projektsteuerung, Formularwerkzeug und Automatisierungsmotor ist, wird enttäuscht – und sollte in eine andere Produktkategorie schauen. Wer dagegen ein Werkzeug sucht, in dem Menschen ohne Einweisung schreiben, finden und verlinken, und das nach zwei Jahren noch benutzt wird, hat mit einem schlanken Wiki eine reelle Chance. Die häufigste Ursache für tote Wissensdatenbanken ist nicht fehlende Funktion, sondern zu hohe Einstiegshürde.
Drei Eigenschaften beschreiben Nuclino treffender als jede Funktionsliste:
Die Grundstruktur ist in wenigen Sätzen erklärt und genau deshalb tragfähig. Ein Item ist die kleinste Einheit: eine Seite mit Titel und Inhalt, die eine Sache erklärt. Items liegen in Workspaces – abgegrenzten Bereichen für ein Team, eine Abteilung, ein Projekt oder einen Themenkomplex, mit eigenen Mitgliedern und eigenen Rechten. Innerhalb eines Workspaces lassen sich Items in Sammlungen gruppieren, sodass eine überschaubare Hierarchie entsteht. Und quer über alles liegt die Verlinkung, die sich nicht an Sammlungsgrenzen hält.
Diese Zweiteilung aus Hierarchie und Netz ist wichtiger, als sie klingt. Reine Hierarchien scheitern in Organisationen regelmäßig daran, dass ein Thema an zwei Stellen hingehört: Die Regelung zur Arbeitszeiterfassung ist Personalthema und Prozessthema zugleich. In einem Ordnerbaum führt das zu Dubletten, die auseinanderlaufen. In einem verlinkten Netz führt es zu einem Item, auf das von zwei Seiten verwiesen wird. Wer diesen Unterschied im Kopf hat, richtet eine Wissensdatenbank anders ein – und spart sich die endlosen Diskussionen darüber, in welchen Ordner etwas gehört.
Praktisch bewährt hat sich in unseren Projekten eine einfache Faustregel für den Zuschnitt: Ein Item beantwortet eine Frage, die jemand tatsächlich stellt. Nicht „Qualitätsmanagement“, sondern „Wie melde ich einen Fehler aus der Fertigung?“. Nicht „Personalwesen“, sondern „Wie beantrage ich Urlaub?“. Diese Frageform hat zwei Wirkungen: Sie erzwingt eine sinnvolle Größe, und sie macht die Inhalte auffindbar, weil Menschen genau so suchen. Wissensdatenbanken scheitern selten am Werkzeug und häufig daran, dass Inhalte nach der Logik des Schreibenden statt nach der Logik des Suchenden abgelegt wurden.
Ergänzend gilt eine zweite Regel, die sich leicht sagen und schwer durchhalten lässt: Was in einem Item steht, ist aktuell oder es steht nicht dort. Ein Wiki mit veralteten Einträgen ist schlimmer als gar kein Wiki, weil es Vertrauen zerstört – und Vertrauen ist die einzige Währung, in der eine Wissensdatenbank bezahlt wird. Wir kommen im Betriebskapitel ausführlich darauf zurück, weil das der wirksamste Hebel überhaupt ist.
In Auswahlprojekten begegnet uns regelmäßig ein Denkfehler: Mehr Funktionen gelten als besser, und ein Produkt mit kürzerer Merkmalsliste gilt als unfertig. Bei Wissensdatenbanken ist dieser Schluss falsch, und zwar messbar. Der Engpass in Unternehmen ist nicht die Fähigkeit des Werkzeugs, sondern die Bereitschaft der Menschen, es zu benutzen. Jede zusätzliche Möglichkeit – Datenbankansichten, Formeln, Berechtigungsstufen, Automatisierungen, Vorlagenlogik – erhöht die kognitive Last beim Anlegen einer Seite. Und jede Erhöhung dieser Last senkt die Zahl der Menschen, die überhaupt etwas anlegen.
Ein schlankes Wiki dreht dieses Verhältnis um. Wer eine Seite anlegen will, klickt auf einen Knopf, schreibt und ist fertig. Es gibt keine Entscheidung über Seitentyp, Vorlage, Datenbankstruktur oder Eigenschaftsfelder, die vor dem ersten Satz getroffen werden müsste. In der Einführung bedeutet das, dass eine Schulung von zwanzig Minuten genügt statt eines halben Tages. Im Betrieb bedeutet es, dass auch Menschen schreiben, die sich sonst nicht als Dokumentationsverantwortliche verstehen – die Meisterin in der Fertigung, der Servicetechniker, die Buchhalterin. Genau diese Gruppe trägt das Wissen, das in Organisationen am schwersten zu heben ist.
Der Preis dieser Entscheidung ist real und gehört ehrlich benannt. Wer strukturierte Datenhaltung braucht – Tabellen mit typisierten Feldern, verknüpfte Datensätze, Rollups, gefilterte Sichten über hunderte Einträge –, bekommt sie in einem schlanken Wiki nicht in der Tiefe, die ein datenbankorientiertes Werkzeug bietet. Wer komplexe Freigabeworkflows mit mehrstufiger Genehmigung, Versionsfreigabe und revisionssicherer Lenkung von Dokumenten benötigt, ist bei einer Wiki-Plattform mit entsprechendem Erweiterungsökosystem oder bei einem Dokumentenmanagementsystem besser aufgehoben. Diese Grenzen sind keine Mängel, sondern Konsequenzen der Positionierung.
Für die Entscheidung heißt das: Fragen Sie nicht, welches Produkt mehr kann, sondern welches Verhalten Sie erzeugen wollen. Wenn Ihr Ziel lautet, dass fünfzig Menschen regelmäßig kurze Texte schreiben und pflegen, ist Schlankheit ein Vorteil. Wenn Ihr Ziel lautet, dass drei Menschen ein hochstrukturiertes System pflegen, das andere lesen, ist sie es nicht. Beide Ziele sind legitim, aber sie führen zu unterschiedlichen Produkten.
Aus unserer Beratungspraxis passt ein schlankes Team-Wiki dieser Art besonders gut zu vier Profilen. Erstens zu Organisationen zwischen etwa zehn und dreihundert Beschäftigten, die bisher mit Dateiablagen, E-Mail-Anhängen und Wissen in Köpfen arbeiten und einen ersten wirklich benutzten Ort für Dokumentation brauchen. Zweitens zu Teams mit hoher Fluktuation oder starkem Wachstum, für die Einarbeitung ein wiederkehrender Kraftakt ist – Onboarding ist das Szenario, in dem sich der Nutzen am schnellsten zeigt. Drittens zu Unternehmen, die schon einmal an einer schweren Plattform gescheitert sind und deshalb bewusst nach Einfachheit suchen. Viertens zu Organisationen, für die ein deutscher Anbieter mit europäischer Verarbeitung ein Auswahlkriterium ist – ein Punkt, den wir im Datenschutzkapitel differenziert betrachten.
Die Grundlogik ist ein Sitzplatzmodell: Abgerechnet wird pro Person, die Inhalte lesen und bearbeiten darf, in der Regel mit Nachlass bei jährlicher Zahlung. Zwischen den Ebenen unterscheiden sich vor allem der verfügbare Speicher, die Tiefe der Rechte- und Rollenverwaltung, die Anmeldung über einen zentralen Identitätsdienst, der Umfang der Versionshistorie, die Möglichkeiten für die Zusammenarbeit mit Externen sowie Umfang und Kontingente der KI-Funktionen. Die Funktionslogik des Editors und der Ansichten ist über die Ebenen hinweg weitgehend gleich – ein angenehmer Unterschied zu Plattformen, bei denen die eigentliche Arbeitsfähigkeit an der Lizenzstufe hängt.
Wenn Sie die Ebenen vergleichen, achten Sie nicht auf die Länge der Merkmalsliste, sondern auf drei Trennlinien, die in Projekten den Unterschied machen. Die erste ist die Anmeldung. Ob sich Beschäftigte über Ihren zentralen Identitätsdienst anmelden oder eigene Zugänge mit eigenen Passwörtern anlegen, entscheidet über Kontenhygiene, über den zuverlässigen Entzug von Zugriffen beim Austritt und über die Frage, ob die IT überhaupt weiß, wer im Unternehmen mit dem Werkzeug arbeitet. In vielen Organisationen ist genau dieser Punkt der Grund, eine Ebene höher zu gehen – nicht eine fehlende Editorfunktion.
Die zweite Trennlinie ist die Rechte- und Freigabesteuerung. Eine Wissensdatenbank lebt davon, dass Inhalte leicht geteilt werden, und genau darin liegt das Risiko. Prüfen Sie für Ihre Ebene, ob sich Inhalte öffentlich per Link freigeben lassen, ob diese Möglichkeit administrativ eingeschränkt werden kann, wie granular Rechte auf Workspace-Ebene vergeben werden und ob Gäste auf einzelne Bereiche begrenzt werden können. Auf Wiki-Seiten stehen Preislisten, Kundennamen, Prozessdetails und Zuständigkeiten – Steuerungsmöglichkeiten sind hier keine Komfortfunktion, sondern eine Anforderung.
Die dritte Trennlinie ist Nachvollziehbarkeit und Aufbewahrung: Wie weit reicht die Versionshistorie zurück, lässt sich nachvollziehen, wer wann was geändert hat, gibt es Protokolle über administrative Vorgänge, und in welchen Formaten lassen sich Inhalte exportieren. Diese Fragen interessieren im ersten Jahr niemanden und werden im dritten plötzlich zur Bedingung – etwa wenn eine Auskunft zu beantworten, ein Vorfall aufzuklären oder ein Nachweis zu erbringen ist. Wer die Ebene ausschließlich nach dem Schreibkomfort auswählt, kauft an dieser Stelle nach.
Ein Unterscheidungsmerkmal, das in DACH-Auswahlprojekten schwerer wiegt als in internationalen Vergleichen: Hinter Nuclino steht ein Unternehmen mit Sitz in München. Für Organisationen, die europäische Datenhaltung und einen Vertragspartner im europäischen Rechtsraum als Kriterium führen, ist das ein struktureller Vorteil gegenüber den großen US-amerikanischen Anbietern in derselben Kategorie. Die Argumentationskette gegenüber Datenschutzbeauftragten, Betriebsrat und Geschäftsführung ist kürzer, weil die Frage des Drittlandtransfers in der Grundkonstellation nicht dieselbe Rolle spielt.
Das ist ein echtes Argument – und es ist kein Freibrief. Auch bei einem deutschen Anbieter müssen Sie prüfen, wo die Daten tatsächlich verarbeitet werden, welche Unterauftragsverarbeiter eingesetzt sind, wo diese verarbeiten und welche Modellanbieter hinter den KI-Funktionen stehen. Ein Anbietersitz in Deutschland bedeutet nicht automatisch, dass jede Komponente der Kette in Deutschland läuft; Infrastruktur, Versand von Benachrichtigungen, Fehlerdiagnose und insbesondere KI-Dienste können bei Dritten liegen. Wir behandeln das im Datenschutzkapitel im Detail, weil hier der häufigste Kurzschluss in Beschaffungen entsteht.
Der Bezug erfolgt üblicherweise direkt beim Anbieter über Selbstbedienung mit Kreditkarte oder über ein Angebot mit Rechnungsstellung. Der Unterschied ist nicht nur kaufmännisch. Über ein Angebot lassen sich Zahlungsweise, Vertragslaufzeit, Datenschutzanlagen und teilweise Supportzusagen sauber regeln, während der Selbstbedienungsweg schnell ist und in Verwaltung, Beschaffungsrichtlinie und Datenschutzdokumentation regelmäßig Nacharbeit erzeugt. In Organisationen mit formaler Beschaffung empfehlen wir grundsätzlich den Angebotsweg, auch bei kleinen Volumina.
Fünf Fragen gehören in jedem Fall vor die Unterschrift. Erstens die Sitzplatzfrage: Wer braucht wirklich einen Zugang, und gibt es eine günstigere oder kostenfreie Form für Personen, die nur lesen sollen? Diese Frage bewegt in der Kalkulation mehr als jeder Rabatt. Zweitens die Gästefrage: Dürfen Externe – Kunden, Lieferanten, Beratungen – eingebunden werden, in welchem Umfang, und zählen sie lizenzseitig? Drittens die Verarbeitungsfrage: Wo werden Inhalte gespeichert und verarbeitet, welche Unterauftragsverarbeiter sind beteiligt, und gilt das auch für die KI-Funktionen? Viertens die KI-Frage: Welche Funktionen sind in Ihrer Ebene enthalten, gibt es Kontingente, lassen sie sich zentral abschalten? Fünftens die Ausstiegsfrage: In welchen Formaten lassen sich Inhalte exportieren, und bleiben dabei Struktur, Verlinkung und Anhänge erhalten?
Der letzte Punkt verdient besondere Aufmerksamkeit, weil er in Wiki-Projekten fast nie gestellt wird und im Ernstfall über Wochen Arbeit entscheidet. Ein Export in ein Textformat wie Markdown ist heute üblich und deckt den Inhalt gut ab. Was regelmäßig verloren geht oder aufwendig nachzuarbeiten ist, sind interne Verknüpfungen, Anhänge in ihrer Zuordnung, Kommentare und die Versionshistorie. Klären Sie deshalb konkret, was ein Export umfasst, und ziehen Sie einmal zu Beginn testweise einen – nicht, weil Sie den Anbieter wechseln wollen, sondern weil ein funktionierender Export die einzige belastbare Form von Unabhängigkeit ist.
Die folgenden Bausteine bestimmen den praktischen Alltag. Welche davon in Ihrer Ebene in welcher Ausprägung verfügbar sind, sollten Sie vor der Beschaffung abgleichen – der Funktionsumfang von Diensten dieser Art verändert sich laufend.
Der Editor arbeitet nach dem Prinzip der unmittelbaren Formatierung: Sie schreiben, und die Struktur entsteht während des Tippens – Überschriften, Listen, Zitate, Aufgabenkästchen, Tabellen, Codeblöcke. Vertraute Kurzschreibweisen aus Markdown funktionieren, ohne dass jemand Markdown können muss. Dateien und Bilder werden per Ablegen eingefügt, eingebettete Inhalte aus anderen Diensten erscheinen als Vorschau. Das ist keine spektakuläre Funktionsliste, aber sie ist vollständig genug für praktisch alles, was in einer betrieblichen Dokumentation vorkommt.
Der eigentlich prägende Mechanismus ist die interne Verlinkung. Während des Schreibens verweisen Sie mit einer kurzen Eingabe auf ein anderes Item, und wenn es noch nicht existiert, legen Sie es im selben Zug an. Dieser kleine Ablauf hat eine große Wirkung: Wissen wächst dort, wo es gebraucht wird, statt in einem Ordnerbaum, in dem jemand vorher eine Struktur erfinden musste. Nach einigen Wochen entsteht ein Netz, in dem sich häufig verwendete Items als Knoten mit vielen eingehenden Verweisen abzeichnen – und das sind fast immer genau die Inhalte, die besondere Pflege verdienen.
Ergänzt wird das durch Rückverweise: Zu jedem Item ist erkennbar, welche anderen Items darauf zeigen. Diese scheinbar kleine Anzeige ist im Betrieb eines der nützlichsten Werkzeuge überhaupt. Sie sehen vor einer Änderung, welche anderen Inhalte betroffen sind, Sie erkennen bei einer Zusammenführung, welche Verweise nachzuziehen sind, und Sie identifizieren verwaiste Inhalte – Items ohne einen einzigen eingehenden Verweis, die in aller Regel entweder überflüssig oder falsch eingeordnet sind.
Für die Praxis empfehlen wir drei Schreibkonventionen, die nichts kosten und die Qualität deutlich heben. Erstens: Der Titel eines Items ist die Frage, die es beantwortet, oder der Gegenstand, den es beschreibt – nicht eine Abteilungsbezeichnung. Zweitens: Jedes Item beginnt mit zwei Sätzen, die sagen, worum es geht und für wen es gilt; wer nur diese zwei Sätze liest, weiß, ob er weiterlesen muss. Drittens: Verlinken Sie beim ersten Auftreten eines Begriffs, der anderswo erklärt ist, statt ihn erneut zu erklären. Diese dritte Regel verhindert die Dublettenbildung, an der Wissensdatenbanken in der Regel zugrunde gehen.
Ein Unterscheidungsmerkmal gegenüber klassischen Wikis ist, dass sich derselbe Bestand in mehreren Darstellungen betrachten lässt, ohne dass Inhalte doppelt gepflegt werden. Die Listen- oder Baumansicht ist die vertraute Form: Sammlungen und Items in einer Hierarchie, gut für Nachschlagewerke und Handbücher. Die Board-Ansicht stellt Items als Karten in Spalten dar, sortiert nach einem Status oder einer Kategorie – nützlich für Inhalte, die einen Bearbeitungszustand haben, etwa eine Redaktionsplanung, eine Liste offener Prozessbeschreibungen oder ein Prüfstand für zu aktualisierende Seiten.
Die Tabellenansicht zeigt Items als Zeilen mit Feldern und eignet sich für Bestände, die man vergleichen will: Lieferanten mit Ansprechpartner und Vertragsende, Maschinen mit Wartungsintervall, Anwendungen mit Verantwortlichem. Hier ist eine ehrliche Einordnung wichtig: Das ist eine leichtgewichtige Tabellenfunktion, keine relationale Datenbank. Verknüpfte Datensätze über mehrere Tabellen, berechnete Felder mit Formeln, Aggregationen über Beziehungen und gefilterte Sichten mit komplexen Bedingungen sind Sache datenbankorientierter Werkzeuge. Wer das braucht, sollte es nicht durch kreative Nutzung einer Wiki-Tabelle nachbauen, sondern das passende Werkzeug wählen.
Die Graph-Ansicht schließlich stellt das Verweisnetz visuell dar. Sie ist das Merkmal, das in Vorführungen am meisten Eindruck macht und im Alltag am seltensten geöffnet wird – aber sie hat zwei sehr konkrete Anwendungen. Erstens bei der Bestandsaufnahme: Ein Blick auf den Graph zeigt Cluster gut vernetzten Wissens und einzelne Inseln, die niemand verlinkt hat. Zweitens beim Aufräumen: Isolierte Knoten sind Kandidaten für Zusammenführung, Verlinkung oder Löschung. Wir setzen die Graph-Ansicht in Projekten deshalb bewusst als halbjährliches Prüfinstrument ein, nicht als tägliches Arbeitsmittel.
Der praktische Wert dieser Mehrfachsicht liegt darin, dass Sie eine einzige Pflegequelle behalten. In Organisationen ohne dieses Prinzip entstehen typischerweise drei Bestände: das Wiki, eine Tabelle mit denselben Informationen und eine Präsentation für die Geschäftsführung. Alle drei laufen auseinander, und niemand weiß mehr, welcher Stand gilt. Ein Werkzeug, das dieselben Inhalte unterschiedlich darstellt, löst dieses Problem nicht von allein – aber es nimmt ihm den häufigsten Anlass.
Die gemeinsame Bearbeitung in Echtzeit ist der Punkt, an dem Beteiligte den Unterschied zur Dateiablage begreifen. Zwei Menschen schreiben im selben Item, sehen die Cursor der anderen und arbeiten ohne Sperre, ohne Konfliktfassung und ohne die Frage, wer gerade die aktuelle Version hat. Für die Einführung ist das das wirksamste Argument, weil es ein Problem löst, das jeder kennt: die drei Dateiversionen mit den Endungen final, final zwei und wirklich final.
Die Versionshistorie ist das notwendige Gegenstück. Sie zeigt, wer wann was geändert hat, erlaubt den Vergleich von Ständen und die Wiederherstellung. Für die betriebliche Praxis ist sie aus drei Gründen wichtig: Sie nimmt Menschen die Angst, etwas kaputt zu machen – der häufigste Grund, warum Kolleginnen nichts ändern, obwohl sie es besser wüssten. Sie erlaubt die Rekonstruktion, wenn eine Änderung Folgen hatte. Und sie ist bei Nachfragen zur Nachvollziehbarkeit das erste, wonach gefragt wird. Klären Sie für Ihre Ebene, wie weit die Historie zurückreicht.
Kommentare und Erwähnungen sind das Werkzeug der asynchronen Abstimmung. Eine Rückfrage steht an der Stelle im Text, auf die sie sich bezieht, statt in einer E-Mail ohne Kontext. Eine Erwähnung benachrichtigt die zuständige Person. In Kombination mit einer klaren Regel – Rückfragen zum Inhalt gehören als Kommentar ins Item, nicht in den Chat – verhindert das den typischen Wissensverlust, bei dem die entscheidende Klarstellung in einem Chatverlauf verschwindet, den in einem Jahr niemand mehr findet.
Die Suche ist die meistgenutzte Funktion jeder Wissensdatenbank und zugleich die, an der die Akzeptanz kippt. Eine Volltextsuche mit sofortigen Ergebnissen über Items, Anhänge und Kommentare ist die Basis. Entscheidend für die gefühlte Qualität ist aber weniger die Technik als die Inhaltspflege: Suchergebnisse sind nur so gut wie die Titel, die Einleitungssätze und die Freiheit von Dubletten. Wir sehen in Projekten regelmäßig, dass eine als schlecht empfundene Suche in Wahrheit ein Redaktionsproblem ist – drei Items zum selben Thema mit unterschiedlichem Stand, von denen die Suche zu Recht alle drei liefert.
Vorab eine notwendige Einordnung, die für alle Wissenswerkzeuge mit KI gilt. Der Wert generativer Funktionen in einer Wissensdatenbank liegt nicht im Erzeugen von Inhalten – Ihr Unternehmenswissen kann kein Modell erfinden. Er liegt in drei anderen Dingen: in der Überwindung der leeren Seite, im Verdichten vorhandener Inhalte und im Auffinden dessen, was schon geschrieben wurde. Wer KI in einem Wiki mit dieser Erwartung einsetzt, wird zufrieden sein. Wer erwartet, dass die Dokumentation sich selbst schreibt, wird es nicht.
Die sichtbarste Funktion ist die Textassistenz beim Schreiben. Sie fordert einen Entwurf zu einem Thema an, lassen einen vorhandenen Abschnitt umformulieren, kürzen, verlängern, in eine Liste überführen oder übersetzen. Für den betrieblichen Alltag ist der wichtigste Anwendungsfall unspektakulär: die Überwindung der leeren Seite. Viele Menschen dokumentieren nicht, weil ihnen der erste Satz fehlt, nicht weil ihnen das Wissen fehlt. Ein generierter Rohentwurf, der zu siebzig Prozent falsch ist, löst dieses Problem trotzdem – weil Korrigieren psychologisch leichter fällt als Anfangen.
Der zweite wertvolle Anwendungsfall ist die Vereinheitlichung von Sprache. In gewachsenen Wissensbeständen schreibt jede Abteilung anders: die einen in Stichpunkten, die anderen in verschachtelten Sätzen, wieder andere im Behördendeutsch. Eine Umformulierungsfunktion, angewendet mit einer klaren Vorgabe – kurze Sätze, direkte Ansprache, keine Substantivketten –, hebt die Lesbarkeit eines Bestands spürbar, ohne dass jemand alles neu schreiben muss. In Projekten setzen wir das gezielt bei der Migration von Altbeständen ein.
Zur Sprachqualität im Deutschen eine ehrliche Einordnung: Ergebnisse sind in der Regel verständlich und grammatikalisch sauber, aber nicht immer idiomatisch. Fachbegriffe aus dem Mittelstand, zusammengesetzte Substantive, Abteilungsbezeichnungen und branchentypische Kurzformen werden nicht zuverlässig getroffen. Für interne Rohfassungen genügt das gut. Für Inhalte, die Kunden, Prüfstellen oder Gremien erreichen, planen Sie eine redaktionelle Durchsicht ein. Und für alles, was Verbindlichkeit erzeugt – Arbeitsanweisungen, Sicherheitshinweise, vertragsrelevante Aussagen –, gilt ohne Ausnahme: Ein Mensch verantwortet den Text.
Die Zusammenfassungsfunktion verdichtet ein Item oder einen längeren Abschnitt auf wenige Sätze oder Stichpunkte. Ihr Nutzen hängt stark vom Ausgangsmaterial ab. Bei einem langen, gewachsenen Text, den niemand mehr liest, ist eine Zusammenfassung als Einleitung ein echter Gewinn – sie beantwortet die Frage, ob das Item das richtige ist, bevor jemand fünf Minuten investiert. Bei einem gut geschriebenen kurzen Item ist sie überflüssig. Als Faustregel: Zusammenfassungen sind ein Werkzeug für Altbestände und lange Protokolle, nicht für neue Inhalte.
Die interessantere Funktion ist die semantische Suche beziehungsweise das Beantworten von Fragen auf Basis des vorhandenen Bestands. Der Unterschied zur klassischen Volltextsuche ist grundlegend: Statt nach Wörtern zu suchen, sucht das System nach Bedeutung. Wer nach „Was mache ich, wenn ein Kunde die Rechnung nicht zahlt?“ fragt, findet das Item zum Mahnwesen auch dann, wenn dort das Wort Rechnung nicht vorkommt. Für Organisationen, in denen Beschäftigte und Suchende unterschiedliche Vokabulare verwenden – und das sind praktisch alle –, ist das der größte Einzelnutzen von KI in einer Wissensdatenbank.
Drei Praxishinweise machen dabei den Unterschied. Erstens: Die Antwortqualität hängt vollständig an der Qualität und Aktualität des Bestands. Eine semantische Suche über einen Bestand mit Dubletten und veralteten Ständen liefert überzeugend formulierte falsche Antworten – die gefährlichste aller Ausgabeformen. Zweitens: Achten Sie darauf, ob Antworten mit Quellenangabe auf die zugrunde liegenden Items versehen sind. Nur dann ist eine Antwort prüfbar, und nur dann ist sie im betrieblichen Kontext brauchbar. Drittens: Klären Sie, ob die Suche die Berechtigungen respektiert – ob also niemand über eine KI-Antwort Inhalte erfährt, für die er im Wiki keinen Zugriff hätte. Diese Frage ist bei jedem Werkzeug dieser Art zu stellen, unabhängig vom Anbieter.
Für die Erwartungshaltung im Unternehmen empfehlen wir eine klare Sprachregelung: Die semantische Suche ist ein besserer Wegweiser, kein Orakel. Sie führt Menschen schneller zu der Seite, auf der die Antwort steht. Sie ersetzt weder das Lesen dieser Seite noch die Verantwortung dessen, der die Auskunft weitergibt. Wo diese Regelung fehlt, entstehen im ersten Halbjahr fast zwangsläufig Vorfälle, bei denen eine KI-Antwort als verbindliche Auskunft behandelt wurde.
Fünf Grenzen sollten Sie kennen, bevor Sie KI-Funktionen zur Begründung einer Beschaffung machen.
Der letzte Punkt verdient besondere Aufmerksamkeit, gerade weil der Anbietersitz in Deutschland liegt. Ein deutscher Vertragspartner bedeutet nicht automatisch, dass die hinter den KI-Funktionen stehenden Sprachmodelle in Europa betrieben werden. Fragen Sie deshalb ausdrücklich: Welche Modellanbieter werden eingesetzt, wo verarbeiten sie, wie lange speichern sie Eingaben, und ist ein Training mit Ihren Inhalten vertraglich ausgeschlossen? Lassen Sie sich die Antwort schriftlich geben und nehmen Sie sie in Ihr Verarbeitungsverzeichnis auf. Diese Angaben ändern sich im Zeitverlauf – prüfen Sie sie beim Anbieter und wiederholen Sie die Prüfung bei Vertragsverlängerung.
Ebenso wichtig ist die Frage der Abschaltbarkeit. Prüfen Sie, ob KI-Funktionen zentral deaktiviert oder auf einzelne Workspaces begrenzt werden können. Diese Steuerungsmöglichkeit ist aus zwei Gründen wertvoll: Erstens datenschutzrechtlich, weil Sie damit bestimmen, welche Inhalte überhaupt an ein Modell gehen – etwa indem der Workspace mit Personalthemen ausgenommen wird. Zweitens praktisch, weil Sie eine Pilotphase mit einem Team fahren können, statt die Funktionen für alle gleichzeitig zu öffnen und die Erfahrungen dem Zufall zu überlassen.
Halten Sie schließlich an einem einfachen Prinzip fest, das sich in vielen Projekten bewährt hat: Die KI darf entwerfen, verdichten und finden – Menschen entscheiden, verantworten und veröffentlichen. Solange dieses Prinzip gilt, ist der Einsatz in einer Wissensdatenbank risikoarm und der Nutzen real. Sobald KI-Ergebnisse ungeprüft zur Arbeitsanweisung werden, kehrt sich das Verhältnis um – und der Zeitgewinn wird durch Korrekturaufwand und Vertrauensverlust mehr als aufgezehrt.
Eine Vorbemerkung zur Erwartung: Ein schlankes Wiki hat naturgemäß kein Ökosystem in der Größenordnung einer etablierten Plattform mit Marktplatz und tausenden Erweiterungen. Das ist die Kehrseite der Positionierung. Für den mittelständischen Alltag ist die entscheidende Frage aber nicht, wie viele Anbindungen existieren, sondern ob die drei bis fünf existieren, die Sie tatsächlich brauchen – und das sind fast immer dieselben.
Der praktische Effekt wird regelmäßig unterschätzt. Ein Wiki-Link, der im Chat als nackte Adresse erscheint, wird selten geöffnet. Derselbe Link mit Titel und ersten Zeilen wird geöffnet. Und eine Antwort im Chat, die aus einem Verweis auf ein Item statt aus einer erneuten Erklärung besteht, ist der Mechanismus, mit dem eine Wissensdatenbank überhaupt in Gebrauch kommt. Wir empfehlen deshalb in jeder Einführung eine ausdrückliche Verhaltensregel für Führungskräfte und erfahrene Kolleginnen: Beantworte wiederkehrende Fragen nicht im Chat, sondern schreibe die Antwort einmal ins Wiki und verlinke sie. Diese eine Regel wirkt mehr als jede Schulung.
Die zweite Gruppe betrifft die Büroumgebung. Dokumente, Tabellen und Präsentationen aus Microsoft 365 oder Google Workspace lassen sich verlinken oder als Vorschau einbetten, Dateien direkt anhängen, Inhalte aus anderen Diensten als Karte darstellen. Für die Praxis empfehlen wir eine klare Richtung, die viel Ärger erspart: Das Wiki trägt die Erklärung, die Dateiablage trägt die Datei. Ein Item beschreibt, wie ein Ablauf funktioniert und wozu ein Formular dient, und verlinkt auf das Formular. Es enthält nicht das Formular als Kopie.
Der Grund für diese Regel ist banal und wirksam: Kopien veralten. Ein Wiki, in das Dateien hochgeladen wurden, die parallel in der Ablage weitergepflegt werden, produziert innerhalb eines Jahres widersprüchliche Stände – und danach glaubt niemand mehr dem Wiki. Umgekehrt gilt: Wo die Datei ohnehin verwaltet wird, ist das Wiki der Ort, an dem steht, was mit ihr zu tun ist. Diese Arbeitsteilung ist auch der Grund, warum ein schlankes Wiki neben einer bestehenden Microsoft-Umgebung sinnvoll sein kann, statt mit ihr zu konkurrieren.
Für die Anmeldung gilt das im Editionenkapitel Gesagte: Die Anbindung an einen zentralen Identitätsdienst mit einheitlicher Authentifizierung ist die unspektakulärste und im Betrieb wichtigste Integration. Sie sorgt dafür, dass niemand ein weiteres Passwort verwaltet und dass Zugänge beim Austritt zuverlässig entfallen. Prüfen Sie, ab welcher Ebene das verfügbar ist und ob auch eine automatische Bereitstellung und Deaktivierung von Konten unterstützt wird.
Daraus folgt eine Empfehlung, die wir in jedem Migrationsprojekt geben und die zunächst unbequem klingt: Migrieren Sie nicht alles. Ein Import, der einen gewachsenen Bestand aus zwölf Jahren vollständig überträgt, erzeugt im neuen System dieselbe Unordnung wie im alten – plus die Enttäuschung, dass sich nichts gebessert hat. Der bessere Weg ist eine bewusste Auswahl: Was wird tatsächlich aufgerufen, was ist noch gültig, was ist die Antwort auf eine Frage, die jemand stellt? In unserer Erfahrung liegt der wirklich benötigte Anteil eines Altbestands regelmäßig deutlich unter der Hälfte, oft weit darunter.
Zum Export gilt spiegelbildlich: Prüfen Sie zu Beginn, in welchen Formaten Inhalte das System verlassen können und was dabei erhalten bleibt – Struktur, interne Verweise, Anhänge, Kommentare, Historie. Ein einmal getesteter Export ist die einzige belastbare Form von Unabhängigkeit und gehört in die Betriebsdokumentation, nicht in die Kategorie der Dinge, die man klärt, wenn man sie braucht.
Die Programmierschnittstelle richtet sich an Organisationen mit eigenem Entwicklungsbedarf. Damit lassen sich Inhalte programmgesteuert lesen und schreiben, Bestände auswerten oder Inhalte aus Fachsystemen einspielen. In der Praxis des Mittelstands sehen wir dafür drei sinnvolle Anwendungen: die automatische Erzeugung von Items aus Vorlagen für wiederkehrende Anlässe, die Übertragung von Stammdaten aus einem Fachsystem in eine gepflegte Übersicht und die Auswertung, welche Inhalte tatsächlich genutzt werden. Bei allen Automatisierungen gilt dieselbe Zurückhaltung: Jede Anbindung ist ein kleines Softwareprojekt mit Lebenszyklus. Starten Sie mit einer, die einen sichtbaren Nutzen hat, und ergänzen Sie weitere erst, wenn das Werkzeug angenommen ist.
Die Kehrseite ist ebenso klar. Die Einstiegshürde ist höher, die Oberfläche komplexer, der administrative Aufwand größer, und die Erfahrung vieler Mittelständler lautet, dass nach der Einführung zwanzig Prozent der Belegschaft schreiben und der Rest liest – wenn überhaupt. Wo Confluence-Installationen in mittelständischen Unternehmen scheitern, scheitern sie fast nie an fehlender Funktion, sondern an fehlender Nutzung. Wenn Sie diese Erfahrung bereits gemacht haben, ist das ein starkes Argument für ein bewusst schmales Werkzeug beim zweiten Anlauf.
SharePoint ist der zweite Schwergewichtsvergleich und in vielen Organisationen bereits lizenziert – weshalb die Geschäftsführung zu Recht fragt, warum ein zusätzliches Produkt bezahlt werden soll. Die Antwort sollte ehrlich ausfallen. SharePoint ist im Kern eine dateiorientierte Plattform mit Bibliotheken, Listen und Berechtigungsstrukturen und in dieser Rolle sehr stark. Als Ort für kurze, verlinkte, ständig aktualisierte Wissenstexte ist es weniger geeignet: Die Erstellung einer Seite ist aufwendiger, die Verlinkung weniger flüssig, die Suche über gewachsene Bestände oft unbefriedigend, und die Hürde für gelegentlich Schreibende ist hoch. Die tragfähige Antwort ist meist eine bewusste Arbeitsteilung – Dateien und formale Ablage bleiben, wo sie sind, Arbeitswissen bekommt einen eigenen, leichteren Ort.
Die Abwägung ist keine reine Datenschutzfrage, sondern eine Betriebsfrage. Selbstbetrieb bedeutet vollständige Kontrolle über Daten und Zugriffe – und vollständige Verantwortung für Aktualisierung, Sicherung, Verfügbarkeit, Sicherheitspatches und Betrieb. Für Organisationen mit einer eigenen IT-Mannschaft, die diese Verantwortung ohnehin trägt, ist das ein gangbarer Weg. Für ein Unternehmen mit fünfzig Beschäftigten und einem externen IT-Dienstleister ist der Selbstbetrieb eines Wikis in der Gesamtrechnung häufig teurer und riskanter als ein Dienst bei einem europäischen Anbieter.
Unsere Empfehlung für diese Entscheidung lautet, sie explizit zu treffen und zu begründen. Stellen Sie eine einfache Frage: Welche Anforderung genau verlangt den Selbstbetrieb – eine regulatorische Vorgabe, eine Konzernrichtlinie, eine Branchenanforderung, eine Ausschreibungsbedingung? Wenn eine solche Vorgabe existiert, ist die Sache entschieden, und die Produktauswahl beginnt bei den self-hostbaren Optionen. Wenn keine existiert und der Wunsch aus einem allgemeinen Unbehagen stammt, ist ein europäischer Dienst mit sauberer Vertragslage in aller Regel die wirtschaftlichere und betrieblich stabilere Wahl. Was Sie nicht tun sollten, ist diese Abwägung implizit lassen – sie muss später gegenüber Datenschutz, Betriebsrat und Geschäftsführung erklärt werden.
Das folgende Vorgehen hat sich in Mittelstandsprojekten bewährt. Es beginnt bewusst nicht mit der Technik, sondern mit dem Anlass, der die Wissensdatenbank tragen soll.
Die häufigste Fehlentscheidung am Anfang ist ein zu feiner Schnitt. Organisationen legen für jedes Projekt, jede Abteilung und jedes Thema einen eigenen Workspace an, mit eigenen Mitgliedern und eigenen Rechten – und stellen nach einem Jahr fest, dass niemand mehr weiß, wo etwas steht, dass Inhalte doppelt existieren und dass die Suche über Bereichsgrenzen hinweg an Berechtigungen scheitert. Unsere Empfehlung lautet deshalb: So wenige Workspaces wie möglich, so viele wie nötig. Ein gemeinsamer Bereich für alles, was alle betrifft, und abgetrennte Bereiche nur dort, wo es einen echten Vertraulichkeitsgrund gibt – typischerweise Personal, Geschäftsführung und einzelne Kundenprojekte.
Innerhalb eines Workspaces gilt das Gegenteil der klassischen Ordnerlogik: Bauen Sie keine tiefe Hierarchie, sondern eine flache Struktur mit starker Verlinkung. Drei Ebenen sind fast immer ausreichend. Der Grund ist praktisch: Menschen suchen, sie navigieren nicht. Wer eine sechsstufige Hierarchie baut, investiert Arbeit in einen Weg, den fast niemand geht – und erzeugt gleichzeitig die endlosen Diskussionen darüber, wohin ein Thema gehört, das an zwei Stellen passt.
Für die Benennung empfehlen wir drei Regeln. Erstens: Titel in der Sprache der Suchenden, möglichst als Frage oder als konkreter Gegenstand. Zweitens: Keine Abkürzungen im Titel, die nur eine Abteilung kennt – oder wenn doch, dann zusätzlich ausgeschrieben. Drittens: Ein Item pro Thema, konsequent. Wenn ein zweites Item zum selben Thema entsteht, wird es zusammengeführt, nicht parallel gepflegt. Diese dritte Regel ist die unbequemste und die wichtigste; Dubletten sind die häufigste Todesursache von Wissensdatenbanken.
Ein Hinweis zu Vorlagen: Auch ein schlankes Wiki profitiert von zwei oder drei eigenen Grundmustern – etwa einer Prozessbeschreibung mit Zweck, Geltungsbereich, Ablauf, Zuständigkeit und Ausnahmen, oder einer Einarbeitungsseite mit Woche eins bis vier. Diese Muster kosten wenig, machen Inhalte zwischen Bereichen vergleichbar und nehmen dem Schreibenden die Frage, wie er anfangen soll. Sie sollten allerdings Empfehlungen bleiben und nicht zur Pflicht werden – sonst kehrt genau die Hürde zurück, die man mit einem schlanken Werkzeug vermeiden wollte.
In fast jedem Projekt existiert ein Vorgänger: ein Confluence-Bereich, eine Notion-Sammlung, ein Netzlaufwerk mit Textdateien aus zwölf Jahren, ein SharePoint mit Bibliotheken. Die Versuchung, alles zu übernehmen, ist groß – schließlich hat es einmal jemand geschrieben. Die Erfahrung aus vielen Migrationen ist eindeutig: Ein vollständig übernommener Altbestand erzeugt im neuen System dieselbe Unordnung wie im alten, plus den Eindruck, dass sich nichts gebessert hat.
Wir empfehlen ein Vorgehen in vier Schritten. Erstens messen: Welche Inhalte wurden im letzten Jahr tatsächlich aufgerufen? Fast jedes System kann das beantworten, und die Antwort ist regelmäßig ernüchternd. Zweitens bewerten: Von den aufgerufenen Inhalten – welche gelten noch, welche sind überholt, welche widersprechen sich? Diese Bewertung machen Fachleute, nicht die IT. Drittens übertragen: nur das Bewertete, in der neuen Struktur, mit angepassten Titeln. Viertens abschalten: Das Altsystem geht zu einem festen Datum in den Lesemodus und wird danach archiviert. Ohne diesen vierten Schritt bleiben zwei Systeme parallel bestehen, und das ist der schlechteste aller Zustände.
Technisch gilt: Importwege funktionieren gut für Text, Überschriften, Listen und einfache Tabellen. Sie funktionieren schlechter für Makros, dynamische Elemente, verschachtelte Datenbanken, komplexe Tabellen, Berechtigungsstrukturen und teilweise Anhänge. Testen Sie deshalb mit einer kleinen, repräsentativen Menge, bevor Sie den Gesamtbestand ziehen, und planen Sie Nacharbeit ein. Rechnen Sie außerdem damit, dass interne Verweise nach der Migration teilweise neu gesetzt werden müssen – ein guter Anlass, den Bestand ohnehin durchzusehen.
Ein Wort zur Aufwandsschätzung, weil sie regelmäßig zu optimistisch ausfällt: Der technische Import ist Stunden, die inhaltliche Bewertung ist Tage bis Wochen, verteilt auf Fachleute, die daneben ihre eigentliche Arbeit machen. Planen Sie diese Kapazität ausdrücklich ein und benennen Sie je Themenbereich eine Person. Migrationsprojekte scheitern nicht an Technik, sondern an nicht eingeplanter Fachzeit.
Der laufende Betrieb umfasst fünf Aufgaben, die einer benannten Rolle zugeordnet sein sollten – in der Regel einer fachlichen Ansprechperson gemeinsam mit jemandem aus der IT.
Zum Thema Rollen eine organisatorische Empfehlung, die wir jeder Organisation geben: Benennen Sie eine Person als Eigentümerin des Systems – nicht als Vollzeitaufgabe, sondern als Zuständigkeit mit ein paar Stunden im Monat. Ohne benannten Eigentümer entstehen parallele Bereiche in verschiedenen Abteilungen, jede mit eigener Rechnung, eigenen Gästen und eigenen Regeln, und die Zusammenführung ist später ein eigenes Projekt. Wenn in Ihrer Organisation schon mehrere Teams eigenständig gestartet sind, ist die Konsolidierung auf einen Vertrag mit zentraler Verwaltung der erste sinnvolle Schritt, noch vor jeder Funktionsdiskussion.
Und schließlich der wirksamste Einzelhebel, den wir kennen: Die Führungskräfte müssen selbst verlinken statt zu erklären. Solange die erfahrene Kollegin dieselbe Frage zum zehnten Mal im Chat beantwortet, entsteht kein Wissensbestand. Sobald sie einmal ein Item schreibt und danach den Link schickt, entsteht einer. Diese Verhaltensänderung ist der eigentliche Inhalt einer Wiki-Einführung – alles andere ist Einrichtung.
Wenn wir gefragt werden, mit welchem Anwendungsfall eine Wissensdatenbank starten soll, lautet die Antwort in neun von zehn Fällen: mit der Einarbeitung. Der Grund ist nicht inhaltlicher, sondern struktureller Natur. Onboarding hat alle Eigenschaften, die ein guter Startfall braucht: Es ist wiederkehrend, es ist heute aufwendig, der Nutzen ist innerhalb weniger Wochen sichtbar, und es gibt eine natürliche Qualitätskontrolle – die neue Kollegin merkt sofort, wenn etwas fehlt oder falsch ist.
Der Aufbau ist unspektakulär und funktioniert. Ein Workspace oder eine Sammlung mit einem Startitem, das den Ablauf der ersten Woche beschreibt, dazu verlinkte Items für die einzelnen Themen: Zugänge und wer sie einrichtet, die eingesetzten Werkzeuge und wofür sie da sind, die wichtigsten Abläufe, die Ansprechpersonen mit Zuständigkeit, die ungeschriebenen Regeln des Hauses. Dazu eine einfache Aufgabenliste für die ersten vier Wochen. Mehr braucht es zu Beginn nicht.
Der eigentliche Kniff liegt in einer Regel, die wir jeder Organisation empfehlen: Jede neu eingearbeitete Person aktualisiert das Onboarding-Material für die nächste. Das kostet einen halben Tag am Ende der Einarbeitung, ist für die betreffende Person eine sinnvolle Abschlussaufgabe und hält den Bestand automatisch aktuell. Nach drei Einstellungen ist das Material besser, als es eine Führungskraft je geschrieben hätte – weil es die Fragen beantwortet, die tatsächlich aufkamen, und nicht die, die man erwartet hätte.
Der messbare Effekt ist in Projekten regelmäßig deutlich: weniger Rückfragen an erfahrene Kolleginnen in den ersten Wochen, schnellere Selbstständigkeit, und – der unterschätzte Punkt – eine bessere Erfahrung für die neue Person, die nicht ständig das Gefühl hat, zu stören. In Branchen mit angespanntem Arbeitsmarkt ist das kein weicher Nebeneffekt, sondern ein Argument in der Personalgewinnung.
Der zweite große Anwendungsfall ist die Beschreibung wiederkehrender Abläufe. Hier ist eine klare Abgrenzung wichtig, weil sie in Projekten sonst zu Missverständnissen führt. Ein Team-Wiki eignet sich hervorragend für Arbeitswissen: wie ein Ablauf praktisch funktioniert, wer was tut, welche Ausnahmen es gibt, welche Werkzeuge beteiligt sind. Es eignet sich nicht für die formale Dokumentenlenkung eines Qualitätsmanagementsystems – mit geprüften und freigegebenen Fassungen, Gültigkeitsdaten, Verteilernachweisen und Schulungsbestätigungen. Wer beides in einem Werkzeug erzwingen will, bekommt entweder ein zu schweres Wiki oder ein untaugliches QM-System.
Die praktikable Aufteilung, die sich in vielen Projekten bewährt hat, lautet: Das QM-System hält die wenigen Dokumente, die aus regulatorischen oder zertifizierungsbezogenen Gründen gelenkt werden müssen. Das Wiki hält alles andere – und das ist der weit größere Teil. Beide verweisen aufeinander: Das Wiki verlinkt auf das gelenkte Dokument, statt es zu kopieren. Diese Aufteilung entlastet das QM-System von Inhalten, die dort nur Pflegeaufwand erzeugen, und gibt dem Arbeitswissen einen Ort, an dem es tatsächlich aktualisiert wird.
Für den Aufbau einer Prozessbeschreibung empfehlen wir ein einfaches Muster mit fünf Abschnitten: Zweck in zwei Sätzen, Geltungsbereich, Ablauf in nummerierten Schritten, Zuständigkeiten, bekannte Ausnahmen und Sonderfälle. Der letzte Abschnitt ist der wertvollste und wird in offiziellen Prozessdokumenten fast immer weggelassen – dabei sind es genau die Ausnahmen, an denen neue Kolleginnen scheitern und wegen derer sie nachfragen müssen.
Ein praktischer Hinweis zur Erfassung: Prozessbeschreibungen entstehen am besten nicht am Schreibtisch, sondern im Gespräch. Setzen Sie sich mit der Person zusammen, die den Ablauf verantwortet, lassen Sie sie erzählen und schreiben Sie mit – idealerweise direkt im Wiki, gemeinsam, in derselben Stunde. Der Entwurf ist danach zu achtzig Prozent fertig, und die Beteiligung erzeugt die Bereitschaft, ihn später zu pflegen. Der umgekehrte Weg – jemand aus der Verwaltung schreibt einen Prozess auf und schickt ihn zur Prüfung – funktioniert erfahrungsgemäß schlecht.
Im Handwerk mit Montage- und Serviceteams liegt der Nutzen in zwei Bereichen. Erstens beim technischen Erfahrungswissen: Störungsbilder mit bewährten Lösungen, Besonderheiten einzelner Hersteller und Anlagen, Prüfschritte vor der Abnahme. Zweitens bei der Vereinheitlichung: wie ein Aufmaß dokumentiert wird, welche Fotos vor Ort entstehen müssen, wie ein Nachtrag begründet wird. Der entscheidende Punkt für die Praxis ist die Bedienung auf dem Telefon: Wenn ein Monteur eine Antwort im Fahrzeug nicht in zwanzig Sekunden findet, ruft er an – und dann ist der Bestand wertlos. Prüfen Sie die mobile Nutzung deshalb vor der Entscheidung mit echten Inhalten und echten Geräten.
In der Produktion geht es um Erfahrungswissen an Anlagen und um die Weitergabe zwischen Schichten. Ein Item je Maschine mit Einstellungen, wiederkehrenden Störungen und deren Behebung, dazu Hinweise für Rüstvorgänge, ist ein Bestand, dessen Wert sich schwer beziffern und leicht erleben lässt – spätestens dann, wenn die Person in Rente geht, die alles wusste. Hier ist die Erfassung die Hürde: Menschen in der Fertigung schreiben ungern lange Texte. Arbeiten Sie deshalb mit kurzen Items, mit Fotos und mit einer Person, die aufnimmt und aufschreibt, statt Formulare zu verteilen.
In der Agentur oder im Dienstleistungsbetrieb liegt der Nutzen im Kunden- und Projektwissen: Je Kunde ein Item mit Ansprechpersonen, Besonderheiten, getroffenen Vereinbarungen, Zugängen und Historie. Der Effekt zeigt sich bei Urlaub, Krankheit und Wechsel – der Unterschied zwischen einer Vertretung, die auskunftsfähig ist, und einer, die den Kunden erneut alles fragen muss. Ergänzend bewährt sich ein Bereich für die eigene Methodik: wie ein Angebot aufgebaut wird, wie ein Kickoff abläuft, welche Vorlagen es gibt. Das ist zugleich das Material, aus dem später die Einarbeitung entsteht.
Über alle drei Bilder hinweg gilt eine Beobachtung: Der Nutzen entsteht nicht durch Vollständigkeit, sondern durch Verlässlichkeit. Zwanzig Items, die stimmen und die man in Sekunden findet, sind wertvoller als dreihundert, bei denen unklar ist, welche noch gelten. Beginnen Sie deshalb klein und halten Sie den Bestand sauber, statt ein großes System zu bauen, das anschließend niemand pflegt.
Zunächst zu den Kosten. Die Gesamtkosten setzen sich aus fünf Blöcken zusammen, von denen nur der erste auf einem Angebot steht.
Diesen Kosten steht ein Nutzen gegenüber, der sich benennen lässt: kürzere Einarbeitungszeiten, weniger Rückfragen an erfahrene Kolleginnen, Auskunftsfähigkeit bei Urlaub und Krankheit, gesichertes Erfahrungswissen vor Renteneintritten und ein spürbar geringerer Anteil von Suchzeit an der Arbeitszeit. Wir empfehlen, diese Nutzenerwartung vor der Einführung schriftlich zu fixieren – mit zwei oder drei einfachen Messpunkten wie der Zahl aktiv Schreibender oder der Dauer der Einarbeitung –, damit nach zwölf Monaten überprüfbar ist, ob sie eingetreten ist.
Der Anbietersitz in Deutschland ist ein echter Vorteil, und er wird in Auswahlprojekten zu Recht gewichtet. Er bedeutet einen Vertragspartner im europäischen Rechtsraum, eine Auseinandersetzung mit europäischem Datenschutzrecht als Ausgangspunkt statt als nachträgliche Anpassung, und er nimmt der Diskussion über Drittlandtransfer in der Grundkonstellation die Schärfe. Für Organisationen mit einer Souveränitätsstrategie, im öffentlichen Umfeld, in regulierten Branchen oder mit Konzernvorgaben ist das häufig nicht ein Kriterium unter vielen, sondern das entscheidende.
Ebenso wichtig ist aber, was er nicht ersetzt. Drei Prüfungen müssen Sie unabhängig vom Anbietersitz durchführen. Erstens den tatsächlichen Verarbeitungsort: Ein deutsches Unternehmen kann Infrastruktur bei einem beliebigen Anbieter nutzen. Fragen Sie konkret, wo Inhalte, Sicherungen, Protokolle und Supportzugriffe liegen. Zweitens die Liste der Unterauftragsverarbeiter: Versanddienste für Benachrichtigungen, Werkzeuge zur Fehlerdiagnose, Analysedienste und insbesondere die KI-Dienste sind eigene Verarbeiter mit eigenem Standort. Drittens die vertragliche Basis: Ein Auftragsverarbeitungsvertrag nach Artikel 28 DSGVO mit allen Anlagen ist auch bei einem deutschen Anbieter erforderlich und gehört in Ihr Verarbeitungsverzeichnis.
Der häufigste Kurzschluss in Beschaffungen lautet: deutscher Anbieter, also DSGVO-konform, also keine weitere Prüfung nötig. Das ist falsch und in Prüfsituationen unangenehm. Die richtige Formulierung lautet: Ein europäischer Anbieter verkürzt die Prüfung erheblich, weil eine ganze Fragenkategorie entfällt – er ersetzt sie nicht. Dokumentieren Sie deshalb dieselben Punkte wie bei jedem anderen Dienst, nur mit weniger Aufwand bei der Transferfrage.
Hier liegt der Punkt, der bei modernen Wissenswerkzeugen neu hinzukommt und der in Datenschutzprüfungen am häufigsten übersehen wird. Wenn ein Anbieter KI-Funktionen anbietet, nutzt er dafür in aller Regel Modelle eines weiteren Anbieters. Damit erweitert sich die Verarbeitungskette um eine Stufe, mit eigenem Standort, eigenen Bedingungen und eigenen Aufbewahrungsfristen. Diese Stufe kann außerhalb Europas liegen, auch wenn der Vertragspartner in München sitzt.
Stellen Sie deshalb vier konkrete Fragen und lassen Sie sich die Antworten schriftlich geben. Erstens: Welche Modellanbieter werden für welche Funktionen eingesetzt? Zweitens: Wo findet die Verarbeitung statt, und gibt es eine Zusage zur Verarbeitung innerhalb der EU? Drittens: Wie lange werden Eingaben gespeichert, und zu welchem Zweck? Viertens: Ist ein Training mit Ihren Inhalten vertraglich ausgeschlossen? Ergänzend die betrieblich wichtigste Frage: Lassen sich die KI-Funktionen zentral abschalten oder auf einzelne Bereiche begrenzen? Die Antwort darauf entscheidet, ob Sie das Werkzeug auch mit strengen internen Vorgaben nutzen können – etwa indem der Personalbereich ausgenommen wird.
Beachten Sie außerdem die Berechtigungsfrage bei der semantischen Suche. Ein System, das Antworten aus dem Gesamtbestand erzeugt, muss die Zugriffsrechte der fragenden Person berücksichtigen. Andernfalls entsteht ein Weg, über eine KI-Antwort Inhalte zu erfahren, für die kein Zugriff besteht. Lassen Sie sich dieses Verhalten bestätigen und prüfen Sie es im Pilotbetrieb mit einem Testkonto mit eingeschränkten Rechten – das ist in einer halben Stunde erledigt und beantwortet eine Frage, die Ihnen sonst später gestellt wird.
Sechs Punkte gehören in jede Einführung, unabhängig vom gewählten Produkt. Erstens der Auftragsverarbeitungsvertrag mit allen Anlagen, abgeschlossen und im Verarbeitungsverzeichnis dokumentiert, mit geprüfter Subprozessorenliste. Zweitens ein Rechte- und Gästekonzept: Wer legt Workspaces an, wer darf nach außen freigeben, wie werden Gastzugänge terminiert und entzogen. Drittens eine dokumentierte Entscheidung über die KI-Funktionen: freigeben, begrenzen oder abschalten, mit Begründung und geprüfter Verarbeitungskette. Viertens Regeln zu Aufbewahrung, Archivierung und Löschung, insbesondere für Inhalte mit Personenbezug. Fünftens die Einbindung der Mitbestimmung zu Autorenkennzeichnung, Änderungsprotokollen und Nutzungsauswertung. Sechstens eine kurze Nutzungsrichtlinie, die sagt, welche Inhalte in die Wissensdatenbank gehören und welche ausdrücklich nicht.
Zum letzten Punkt eine konkrete Empfehlung: Legen Sie in zwei Sätzen fest, welche Datenkategorien niemals in ein Wiki gehören – Gesundheitsdaten, Leistungsbeurteilungen, Bewerbungsunterlagen, Personalvorgänge, Zugangsdaten und Passwörter. Der letzte Punkt klingt selbstverständlich und ist in der Praxis der häufigste Verstoß: Zugangsdaten landen in Wiki-Seiten, weil es bequem ist. Dafür gibt es Passwortverwaltungen, und die Regel gehört ausdrücklich ausgesprochen.
Ein Wort zur Mitbestimmung, weil sie in Wiki-Projekten oft übersehen wird: Werkzeuge dieser Art zeichnen auf, wer wann was geändert hat, und häufig auch, wer was gelesen hat. Diese Protokolle sind für Nachvollziehbarkeit sinnvoll und ermöglichen zugleich eine Verhaltens- und Leistungskontrolle. Sie gehören deshalb auf die Agenda, bevor das Werkzeug ausgerollt wird, nicht danach. Praktikabel ist meist eine Vereinbarung, die Auswertungen auf aggregierter Ebene und für Sicherheitszwecke erlaubt und personenbezogene Leistungsauswertungen ausschließt.
Diese sechs Punkte lassen sich in wenigen Seiten abbilden und sind in überschaubarer Zeit erledigt, wenn sie zu Projektbeginn angegangen werden. Nachträglich sind sie deutlich aufwendiger, weil dann bereits Inhalte existieren, Gäste Zugriff haben und Gewohnheiten entstanden sind. Der häufigste Fehler in Wiki-Projekten ist nicht die falsche Produktwahl, sondern der Start ohne Regeln – meist, weil das Werkzeug so unschuldig aussieht.
