AI Chatbot mit interner Wissensbasis: So wird Ihr Firmenwissen endlich nutzbar

Ein AI Chatbot mit interner Wissensbasis verbindet ein Sprachmodell mit Ihren eigenen Datenquellen — Tickets, Wikis, Dokumenten, Datenbanken — und antwortet quellenbasiert nur aus Ihrem Wissen. Der Unterschied zu ChatGPT: Er kennt Ihr Unternehmen, respektiert Ihre Zugriffsrechte und läuft auf Wunsch komplett intern.

Das Problem: Ihr Wissen existiert — aber niemand findet es

In fast jedem Unternehmen, mit dem wir arbeiten, ist das Wissen längst da. Es steckt in Confluence-Seiten, die seit zwei Jahren niemand geöffnet hat, in Tausenden gelösten Support-Tickets, in SharePoint-Ordnern mit kryptischen Namen und in den Köpfen von drei Kollegen, die man „mal eben kurz“ fragt. Das Ergebnis: Dieselben Fragen werden immer wieder neu beantwortet, und die Suche nach einer Antwort dauert oft länger, als die Antwort selbst braucht. Aus unseren Projekten kennen wir drei Muster, die sich fast überall wiederholen:

  • Die Ticket-Historie als Datenfriedhof: Jedes gelöste Ticket enthält eine dokumentierte Lösung — aber niemand durchsucht 20.000 alte Tickets, bevor er ein Problem zum fünften Mal von vorn löst.
  • Experten als Flaschenhals: Zwei, drei erfahrene Mitarbeiter beantworten täglich dieselben Fragen per Slack und Telefon, statt an den Aufgaben zu arbeiten, für die man sie eigentlich braucht.
  • Onboarding als Geduldsprobe: Neue Kollegen brauchen Monate, bis sie wissen, wo was steht und wen man was fragt — nicht weil das Wissen fehlt, sondern weil es verstreut ist.

Ein KI-Chatbot mit eigenen Daten löst genau dieses Auffindbarkeitsproblem: Er macht aus verstreutem Firmenwissen eine einzige Anlaufstelle, die in Sekunden antwortet — mit Quellenangabe. Wissensmanagement mit KI heißt dabei nicht, alles neu zu dokumentieren, sondern das Vorhandene endlich zugänglich zu machen.

Wie die Architektur funktioniert (ohne Ihr Wissen zu kopieren)

Die häufigste Sorge in Erstgesprächen: „Dann liegen unsere Daten also irgendwo doppelt — oder schlimmer, sie trainieren ein fremdes KI-Modell.“ Beides ist bei einer sauberen Architektur nicht der Fall. Eine KI-Wissensdatenbank für Unternehmen entsteht nicht dadurch, dass man Dokumente in ein System kippt — sondern dadurch, dass man das Sprachmodell kontrolliert mit den bestehenden Quellen verbindet. Drei Prinzipien machen den Unterschied.

Verknüpft statt kopiert

Der Chatbot bindet Ihre Quellsysteme direkt an — das Ticketsystem, das Wiki, die Dokumentenablage, die Datenbank. Es entsteht keine zweite Datenwelt, die gepflegt werden müsste und nach drei Monaten veraltet ist. Ändert sich ein Dokument im Quellsystem, arbeitet der Chatbot automatisch mit dem aktuellen Stand. Ihre bestehenden Systeme bleiben die einzige Wahrheit — der Chatbot ist die Zugangsschicht darüber, nicht ein weiterer Datensilo daneben.

RAG statt Training: Warum Ihr Wissen kein Modell trainiert

Der technische Kern heißt Retrieval-Augmented Generation, kurz RAG — und der Unterschied zum „Training“ ist für Entscheider der wichtigste Punkt der ganzen Architektur. Ihr Wissen wird nicht in ein Sprachmodell eingebaut oder dorthin hochgeladen, um es zu trainieren; das Modell bleibt unverändert und kennt Ihre Daten nicht. Stattdessen sucht das System bei jeder Frage zuerst die relevanten Passagen aus Ihren angebundenen Quellen heraus und gibt sie dem Modell als Kontext für genau diese eine Antwort mit. Das Modell formuliert also nur, was in Ihren Dokumenten steht — es „weiß“ nichts dauerhaft, und Ihr Wissen wandert in kein fremdes Modell. Der Nebeneffekt ist entscheidend für das Vertrauen: Weil jede Antwort auf konkreten Fundstellen basiert, kann der Chatbot zu jeder Antwort die Quelle mitliefern — ein Klick, und der Mitarbeiter sieht das Originaldokument.

Zugriffskontrolle vor Kontext

Unser Grundprinzip heißt Zugriffskontrolle vor Kontext: Bevor das System auch nur eine Passage als Antwortgrundlage heranzieht, prüft es, ob der fragende Mitarbeiter das Quelldokument überhaupt sehen dürfte. Jeder bekommt Antworten ausschließlich aus seinem Berechtigungsraum — die Rechte aus Ihren Quellsystemen werden übernommen, nicht neu erfunden. Ein Beispiel: Fragt ein Werkstudent nach Gehaltsbändern, findet der Chatbot schlicht nichts — dieselbe Frage aus der HR-Abteilung liefert die Antwort samt Quelle, weil dort die Berechtigung vorliegt.

[HTML-Visualisierung: Quellsysteme (Tickets · Wiki · Dokumente · Datenbank) → Wissensebene mit Rechte-Prüfung → Chatbot → Slack / Teams / WhatsApp]

Was ein interner Chatbot können muss (Checkliste)

Ob Eigenbau, Plattform oder Dienstleister: Wenn Sie Ansätze für einen internen Chatbot mit Firmenwissen vergleichen, prüfen Sie diese Punkte — sie trennen ein belastbares System von einer Spielerei:

  • Quellenbasierte Antworten mit Beleg: Jede Antwort verweist auf das Dokument oder Ticket, aus dem sie stammt — nachprüfbar mit einem Klick.
  • Rechte-System: Der Chatbot übernimmt die Berechtigungen Ihrer Quellsysteme; niemand sieht per KI, was er direkt auch nicht sehen dürfte.
  • Anbindung Ihrer echten Quellen: Ticketsystem, Wiki, Dateiablage, SQL-Datenbanken, CRM — nicht nur ein PDF-Upload.
  • Arbeitet dort, wo Ihr Team arbeitet: In Slack, Microsoft Teams oder WhatsApp — nicht in einem weiteren Tool, das sich niemand angewöhnt.
  • Voice-Option: Für Werkstatt, Lager oder Außendienst, wo niemand tippt, sollte der Assistent auch per Sprache erreichbar sein.
  • Lernt mit: Neue Dokumente und gelöste Tickets fließen automatisch ein; Feedback zu schlechten Antworten verbessert das System.
  • Audit-Log: Wer hat wann was gefragt, welche Quellen wurden verwendet — wichtig für Betriebsrat, Datenschutz und die Transparenzpflichten des EU AI Act.

Die Praxis: 80 % schnellere Ticket-Lösung bei Rock IT

Wie das konkret aussieht, zeigt unser Projekt mit dem IT-Dienstleister Rock IT. Ausgangslage: Tausende historischer Support-Tickets voller dokumentierter Lösungen, die im Alltag niemand fand — plus Systemdaten, die nur per SQL-Abfrage erreichbar waren. Wir haben die Ticket-Historie als Wissensbasis angebunden und zusätzlich eine direkte SQL-Anbindung gebaut, sodass der Assistent nicht nur Vergangenheitswissen zitiert, sondern auch aktuelle Daten abfragen kann. Nach zwei Wochen war das System produktiv im Einsatz. Das Ergebnis: rund 80 % schnellere Ticket-Lösung und über 40 eingesparte Stunden pro Woche im Team. „Der Assistent findet in Sekunden die Lösung, für die wir früher alte Tickets durchsucht oder Kollegen unterbrochen haben“, sagt Geschäftsführer Mesrop. Die Details zum Aufbau lesen Sie in der Case Study Rock IT.

Was kostet ein Chatbot mit eigener Wissensbasis?

Die ehrliche Antwort: Es hängt an der Zahl und Art der Quellsysteme, nicht an der Zahl der Nutzer. Ein Assistent mit zwei, drei Standardquellen (Wiki, Ticketsystem, Dateiablage) bewegt sich in einem anderen Rahmen als eine Lösung mit Legacy-Datenbanken und On-Premise-Betrieb — die Logik dahinter haben wir auf der Seite zum KI-Team-Assistenten beschrieben, konkrete Zahlen im Kosten-Artikel. Wichtig für die Rechnung: Auf der Nutzenseite stehen nicht nur eingesparte Suchzeiten, sondern auch entlastete Experten und kürzeres Onboarding — bei Rock IT amortisierte sich das System innerhalb weniger Wochen. Der risikofreie Einstieg ist in jedem Fall der Pilot: eine erste Version mit Ihren echten Daten und einer begrenzten Nutzergruppe, an der Sie den Nutzen messen, bevor Sie breit ausrollen.

FAQ

Was ist der Unterschied zu ChatGPT Enterprise?

ChatGPT Enterprise ist ein hervorragendes Allzweckwerkzeug — aber es kennt Ihre Prozesse, Ihre Tickets und Ihr Wiki nicht und beantwortet Firmenfragen deshalb allgemein oder gar nicht. Es fehlt außerdem das Mapping auf Ihre bestehenden Berechtigungen: Was ein Mitarbeiter fragen darf, unterscheidet sich dort nicht nach Rolle. Und die Hosting-Frage bleibt offen — wer seine Daten vollständig im eigenen Haus halten will, braucht eine Architektur, die das vorsieht.

Halluziniert der Chatbot?

Deutlich seltener als ein frei antwortendes Sprachmodell — aber die ehrliche Antwort ist: Kein System ist zu 100 % davor gefeit. Deshalb bauen wir drei Sicherungen ein: Der Chatbot darf nur aus den gefundenen Quellen antworten (Grounding), er muss zu jeder Antwort die Fundstelle angeben, und wenn die Wissensbasis nichts hergibt, sagt er „Dazu finde ich in unseren Unterlagen nichts“ statt zu raten. Falsche Antworten fallen so sofort auf — und lassen sich über die Quelle in Sekunden prüfen.

Welche Datenquellen lassen sich anbinden?

Praktisch alles, was strukturiert oder als Dokument vorliegt: Ticketsysteme (z. B. Zendesk, Jira, OTRS), Wikis wie Confluence oder Notion, SharePoint und andere Dateiablagen, SQL-Datenbanken, CRM-Systeme, E-Mail-Postfächer, PDFs und Office-Dokumente. Auch Spezialsysteme mit API oder Datenbankzugriff sind anbindbar — das klären wir im Einzelfall in der Discovery.

Müssen unsere Daten in die Cloud?

Nein. Wir arbeiten mit drei Schutzstufen: EU-Cloud mit Auftragsverarbeitung für unkritische Daten, dedizierte Umgebungen für sensible Daten und vollständiger On-Premise-Betrieb, bei dem weder Dokumente noch Fragen Ihr Haus verlassen. Welche Stufe zu welchen Daten passt, haben wir im Artikel zu privater KI aufgeschlüsselt.

Wie lange dauert die Einführung?

Die erste produktive Version steht typischerweise nach ein bis zwei Wochen — mit Ihren echten Daten, nicht mit einer Demo. Danach folgt die Pilotphase: eine begrenzte Nutzergruppe arbeitet damit, wir messen Antwortqualität und Zeitersparnis und erweitern die Wissensbasis Schritt für Schritt. Wie so ein Pilot abläuft, beschreiben wir in AI Agents einführen: der 2-Monats-Pilot.


Zwei Wege, um zu starten: Wenn Sie es konkret sehen wollen, bauen wir im Pilotprojekt in zwei Wochen eine erste Version mit Ihren echten Daten. Wenn Sie erst Fragen klären möchten, nehmen Sie sich 30 Minuten für ein kostenloses Discovery-Gespräch — wir schauen gemeinsam, welche Ihrer Wissensquellen sich für den Einstieg lohnen.

Write a comment

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert