Wissensmanagement mit KI: Warum wir kenrAI gebaut haben

Nach einem größeren Hackathon bei einem Kunden saß ich im Auto, acht Stunden Heimfahrt vor mir und den Kopf voller Gedanken. Ich habe den Sprachmodus meiner KI eingeschaltet, freihändig, und einfach erzählt: was funktioniert hatte, was nicht, welche Ideen mir zwischen zwei Sessions gekommen waren. Die KI hat nachgefragt. Warum ich einen Ansatz verworfen hatte. Was der Kunde an einer bestimmten Stelle eigentlich gemeint hatte. Ein paar Fragen waren unbequem, und gerade die haben mich weitergebracht. So sieht Wissensmanagement mit KI bei uns heute aus. Es beginnt lange bevor irgendetwas abgelegt wird, nämlich in dem Moment, in dem das Wissen noch frisch ist.

Früher wäre dieser Abend anders gelaufen. Acht Stunden fahren, eine Nacht schlafen, am nächsten Morgen an den Rechner. Von dem, was im Auto noch glasklar war, wären Bruchstücke übrig geblieben, und selbst die hätten es selten ins Firmenwiki geschafft. Ich erinnere mich gut an den Jour fixe in früheren Firmen, montags oder freitags. Am Ende kam fast immer derselbe Satz: „Denkt bitte dran, das noch im Wiki zu hinterlegen.“ Oder: „Schreibt eure Erfahrungen aus dem Projekt bitte noch ins Wiki.“ Die Antwort kannst du dir denken. Es ist nie passiert. Und wenn doch, standen da zwei Zeilen, mit denen später niemand etwas anfangen konnte. Aus genau diesem Verlust ist kenrAI entstanden, die Wissensbasis, mit der wir bei aithoria arbeiten und die wir inzwischen auch Kunden anbieten. Der Name verbindet zwei japanische Schriftzeichen: „ken“ (賢) bedeutet weise, „rai“ (来) kommen. Frei übersetzt heißt kenrAI also etwa „Weisheit, die kommt“, und dass der Name auf AI endet, ist kein Zufall. Hier erzähle ich, warum wir sie gebaut haben.

‍

Wissen entsteht im Gespräch

In den letzten zwei Jahren haben wir viele Anwendungen gebaut, fast immer für Kunden. Irgendwann haben wir angefangen, auch unsere eigenen Abläufe umzubauen. Wir wollten schneller werden und mit weniger Leuten auskommen, ohne dass die Qualität leidet. Ausgelöst hat das eine Veränderung in unserer Arbeitsweise. Seit wir mit Diktier-Tools wie Superwhisper oder Wispr Flow arbeiten, sprechen wir mehr ein, als wir tippen.

Dabei ist uns aufgefallen, wo unser Wissen tatsächlich entsteht. In Kundengesprächen. In Brainstormings auf Offsites, aus denen neben To-dos immer auch Einsichten herausfallen, die zu keiner Aufgabe gehören. In Workshops. Und eben auf der Heimfahrt.

Und immer häufiger im Chat. Wir arbeiten verteilt, oft allein, und konzipieren vieles gemeinsam mit der KI. So ein Chat wächst mit der Zeit. (Ja, wir wissen, was ein Kontextfenster ist.) Am Ende steht ein fertiges Konzept, ein Vorgehen oder sogar ein Tool. Der Weg dorthin, mit allen verworfenen Varianten und Begründungen, steckt im Verlauf. Deshalb endet so ein Chat bei uns mit einem Satz: „Fasse das Wissen für kenrAI zusammen.“

Keiner dieser Orte ist ein Dokument. Ein Chatverlauf sieht zwar so aus, aber in drei Monaten findet ihn niemand mehr.

Vieles davon ist implizites Wissen, also Erfahrungswissen, das jemand hat und nie aufschreiben würde, weil sie ihm selbstverständlich vorkommt. Solange die Person im Unternehmen ist, fällt das nicht auf. Geht sie, geht das Wissen mit. Wie man das bei einem Generationswechsel auffängt, haben wir im Artikel zum Wissenstransfer bei der Unternehmensnachfolge beschrieben.

Herausholen lässt es sich trotzdem, das haben wir an unserem eigenen Messeauftritt gelernt. Den haben wir über längere Zeit geplant, mit vielen Abstimmungen, Listen und Chats. Im Nachgang haben wir die KI herausarbeiten lassen, welche Vorbereitungen wirklich zählen, welche To-dos anfallen und woran man vor einer Messe denken muss. Heute haben wir dafür ein komplettes Handbuch. Geschrieben hat es niemand am Schreibtisch, es ist aus unserem Tun entstanden.

‍

Wissen geht verloren, bevor es jemand aufschreibt

Ein Beispiel aus unserem Alltag ist der Requirements-Engineering-Workshop. Am Ende steht dort ein Konzept mit einer belastbaren Aufwandsschätzung, und dafür muss jede einzelne Anforderung erfasst sein. Fehlt eine, fehlt sie auch in der Schätzung.

Früher war das ein Workshop, den jemand nebenbei protokolliert hat. Wer mitschreibt, verliert aber den Faden im Gespräch, und wer im Gespräch bleibt, schreibt nicht mit. Nebensätze und das kurze „ach, und übrigens“ am Ende einer Antwort gingen verloren. Es sei denn, jemand konnte Steno.

Heute zeichnen wir die Sessions auf, nachdem alle zugestimmt haben, und lassen sie transkribieren. Parallel machen wir weiter unsere eigenen Notizen. Nach dem Termin liegen beide nebeneinander: das Transkript mit jedem Wort und die Notizen mit unserer Einschätzung. Zusammen ergibt das einen Kontext, den kein Protokoll je hatte.

Wie viel das ausmacht, zeigt ein Fall, dessen Details wir hier bewusst verändert haben. Offiziell erfassten die Instandhalter jede Störung im Wartungssystem. In der Session mit dem Schichtleiter kam dann heraus, wie es wirklich läuft: Die Kollegen schicken sich Fotos und Sprachnachrichten in einer WhatsApp-Gruppe, und am Monatsende überträgt jemand das Nötigste ins System. Das war der eigentliche Use Case, und er stand in keinem Handbuch. Mitgeschrieben hätten wir an dieser Stelle wahrscheinlich nur „Störungserfassung im Wartungssystem“.

Selbst unsere eigenen Konzepte hat das schon gerettet. In einem ersten Entwurf fehlte uns einmal ein Mechanismus, den der Kunde im Termin ausdrücklich als sein zentrales Problem bezeichnet hatte. Erst der Abgleich mit dem Transkript hat ihn zurückgeholt.

Warum hat das früher kaum jemand gemacht? Am nächsten Tag fehlte der Kontext, und alles abzutippen war so mühsam, dass es nur sehr wenige getan haben. Wissensmanagement ist selten an der Ablage gescheitert. Es ist am Festhalten gescheitert.

‍

Wir zeichnen Gespräche auf und lassen sie transkribieren

Für Online-Meetings nutzen wir die Teams Transkription [1]. Vor Ort haben wir Teams ebenfalls ausprobiert, das hat bei uns aber nicht gut funktioniert. Deutlich besser läuft die Aufnahme mit dem iPhone. Getestet haben wir auch die Aufnahmegeräte von Plaud. Als Hardware sind sie richtig gut. Bevor du sie bei Kunden einsetzt, solltest du aber prüfen, wo die Transkription verarbeitet wird und ob das zu deinen Datenschutzvorgaben passt. Nach eigenen Angaben speichert Plaud die Daten von EU-Konten in Frankfurt, für die KI-Auswertung setzt das Unternehmen aber Subdienstleister ein [2].

Zwei Regeln gelten bei uns unabhängig vom Gerät. Aufgezeichnet wird nur mit ausdrücklicher Zustimmung aller Teilnehmenden, und die Zustimmung steht in der Meetingnotiz. Außerdem prüfen wir Namen, Zahlen und Abkürzungen aus dem Transkript gegen, denn die Spracherkennung verdreht sie zuverlässig.

‍

Wissensmanagement mit KI macht aus Transkripten geprüftes Wissen

Ein Transkript ist Rohstoff. Auch ein KI-Meeting-Protokoll ist noch kein Wissen, es fasst ein einzelnes Gespräch zusammen. Wissen wird daraus erst, wenn jemand einordnet, was davon über den Termin hinaus gilt.

Diesen Schritt übernimmt bei uns kenrAI. Du gibst deinem KI-Assistenten das Transkript oder erzählst ihm, was du gelernt hast, und sagst am Ende „schreib das in kenrAI“. Die KI formuliert daraus einen Eintrag, und kenrAI ordnet ihn ein: zu welchem Thema er gehört und mit welchen bestehenden Seiten er zusammenhängt.

Dann kommt der Teil, der uns am meisten Arbeit abnimmt. kenrAI vergleicht das Neue mit dem, was schon da ist. Findet es einen Widerspruch, fragt es nach: Was ist neu? Soll der alte Stand ersetzt werden? Im Nachgang prüfen Agents, ob verknüpfte Einträge angepasst werden müssen oder noch stimmen.

Jeder Eintrag hat eine verantwortliche Person und ein Datum, bis zu dem er wieder geprüft wird. Ein Vorschlag gilt erst, wenn er geprüft ist. Warum gerade das über die Qualität der KI-Antworten entscheidet, steht im Artikel zur KI-Wissensdatenbank im Unternehmen.

‍

‍

Was das außerhalb eines Beratungshauses bedeutet, zeigt ein Beispiel aus der Produktion. Stell dir vor, an einer Spritzgießmaschine erscheint ein Fehlercode, den du noch nie gesehen hast. Du schwingst dich aufs Fahrrad, fährst rüber in die Halle und rufst den Service des Herstellers an. Der lotst dich durch: dieses Menü öffnen, jenen Wert eingeben, den Hebel an der Seite ziehen. Die Maschine läuft wieder. Bevor du zurückfährst, sprichst du in dein Handy, was du gerade gemacht hast, und dein Assistent legt es als Vorschlag in kenrAI ab.

Eine Woche später hat dein Kollege in der Nachtschicht denselben Fehler. Du schläfst längst. Er nimmt sein Telefon und fragt Copilot, was bei diesem Fehlercode zu tun ist. Der Eintrag ist da schon geprüft, und die Antwort kommt Schritt für Schritt daraus, mit deinem Namen als Quelle. Das ist Wissensmanagement.

Wer sich mit Obsidian oder Notion ein Second Brain baut, kennt das Prinzip. Nur hilft ein Second Brain dir allein. kenrAI macht daraus geprüftes Wissen für das ganze Team.

Trotzdem braucht jeder auch einen Ort für eigenes Wissen, davon sind wir überzeugt. Deshalb hat kenrAI einen privaten Bereich. Dort legst du Erfahrungen, Notizen und Entwürfe ab, getrennt vom Firmenwissen, das alle sehen. Für Kolleginnen und Kollegen, die sonst im Unternehmen zu Obsidian oder Notion greifen würden, ist das ein Segen. Welches Wissen auf welche Ebene gehört, haben wir im Beitrag zu Wissensmanagement in drei Ebenen beschrieben.

‍

Eine Wissensbasis für Copilot, Claude und ChatGPT

Unser Beratungsfokus liegt bewusst auf Microsoft. Deshalb war uns von Anfang an wichtig, dass kenrAI im Microsoft-Ökosystem funktioniert, ohne darauf festgelegt zu sein. Bei uns läuft es in Azure, angemeldet wird mit dem Firmenkonto über Entra ID, und in Microsoft 365 Copilot steht kenrAI als eigener Agent bereit.

Möglich macht das MCP, das Model Context Protocol. Das ist eine offene Schnittstelle, über die KI-Assistenten auf externe Werkzeuge und Datenquellen zugreifen [3]. Microsoft 365 Copilot bindet MCP-Server über Agents ein [4]. Für uns heißt das: Dieselbe Wissensbasis steht in jedem MCP-fähigen System zur Verfügung. Produktiv nutzen wir sie in Copilot, Claude, ChatGPT und Cursor. Ein eigenes Unternehmens-GPT lässt sich auf demselben Weg anbinden.

In kaum einem Unternehmen arbeiten alle im selben Assistenten. Bei uns schreibt die Entwicklung in Cursor, der Vertrieb fragt in Copilot, und ich erzähle Claude im Auto, was ich gelernt habe. Alle greifen auf dasselbe Wissen zu, und alle können es ergänzen. kenrAI ist deshalb kein weiteres Wissensmanagement-Tool, das jemand zusätzlich öffnen muss. Wie kenrAI aussieht, zeigen wir auf der kenrAI-Seite.

Ganz ohne Aufwand ist das nicht: Die Anbindung an Microsoft 365 Copilot richtet die IT einmal im Admin Center ein. Danach steht das Wissen allen zur Verfügung, die Zugriff haben.

Den naheliegenden Einwand hören wir oft: „Teams transkribiert doch längst, und Copilot fasst das Meeting zusammen.“ Stimmt, und wir nutzen das auch [5]. Die Zusammenfassung gehört aber zu genau diesem einen Meeting. Drei Monate später sucht niemand mehr in einem alten Meeting-Recap nach der Entscheidung von damals. Und ob die neue Erkenntnis einer älteren widerspricht, prüft dort niemand. Copilot findet in SharePoint und Teams viel, auch das Veraltete. Warum mehr Material nicht automatisch bessere Antworten bringt, haben wir am Beispiel alter Fileshares im Artikel zur Data Readiness erklärt.

‍

Als Viva Topics endete, kam kenrAI

Wissensmanagement begleitet mich, seit ich arbeite. Nach dem Studium bin ich als Softwareentwickler in die SharePoint-Entwicklung eingestiegen und über das Consulting schnell dahin gekommen, SharePoint für Unternehmen als Wissensplattform aufzubauen. Später kam ein größeres Projekt mit Viva Topics. Ich habe Viva Topics geliebt. Die Idee, dass das System Themen und die Menschen dahinter selbst erkennt, war großartig. Im Februar 2025 hat Microsoft es abgeschaltet und angekündigt, Wissensmanagement künftig in Copilot zu bauen [6]. Für uns hat das nicht funktioniert. Deshalb gibt es kenrAI.

Neu war für mich nach all den Jahren etwas anderes: Es macht Spaß. Wahrscheinlich, weil man zusieht, wie das Wissen wächst. Wir haben das sogar sichtbar gemacht. In kenrAI dreht sich ein Globus, im Grunde ein Wissensgraph: Jeder Eintrag ist ein Punkt, jede Verknüpfung eine Linie. Einen echten Nutzen hat er, ehrlich gesagt, kaum. Aber ich ertappe mich regelmäßig dabei, wie ich ihn drehe und schaue, wo sich Themen verdichten und welcher neue Eintrag plötzlich drei Bereiche miteinander verbindet, die vorher nichts voneinander wussten.

‍

‍

Innerhalb eines Monats sind in kenrAI 144 Einträge entstanden, vom Ablauf eines Requirements-Workshops bis zur Frage, wie man Reisezeit beim Kunden kontiert. Wer eine Frage hat, bekommt die Antwort mit Quelle, und zwar in dem Assistenten, den er ohnehin offen hat.

‍

Ein Berg Transkripte ist noch keine Wissensbasis

Gelernt haben wir auch, wo die Grenzen liegen. Ein Berg Transkripte ist noch keine Wissensbasis. Ohne verantwortliche Person veraltet auch kenrAI. Kundendaten gehören nicht hinein, auch nicht diktiert: Aus einem Kundentermin wandert die Erkenntnis in die Wissensbasis, nicht der Kunde. Und die Spracherkennung macht Fehler, die man erst beim Gegenlesen findet.

Wissen festzuhalten, solange es frisch ist, kostet heute ein paar Minuten Reden. Früher hat es einen Nachmittag gekostet, und deshalb ist es meistens nicht passiert.