Bei euch sind die Antworten irgendwo da — in SharePoint, in alten Mails, im Wiki, in der Mappe von der Kollegin, die in zwei Wochen Urlaub hat. Aber gefragt wird trotzdem in WhatsApp, weil das schneller geht. Diese Seite beschreibt, wie aus eurem verteilten Firmenwissen eine durchsuchbare Antwort-Quelle in Teams wird — mit zitierten Originalquellen, nicht mit einer halluzinierenden Black Box.
Hast du diese Situation?
- Mitarbeitende fragen Fachfragen in WhatsApp-Gruppen, weil sie wissen, dass dort jemand schnell antwortet — und nicht, weil die offizielle Doku schlecht ist, sondern weil sie unauffindbar ist.
- Das Onboarding neuer Kolleg:innen besteht zu großen Teilen aus „Frag mal Frank” — und Frank wiederholt zum siebten Mal dieselbe Erklärung, weil sie nirgendwo zentral abrufbar steht.
- Es gibt ein Wiki, ein SharePoint, einen Netzlaufwerk-Ordner, eine Confluence-Instanz, die jemand mal eingerichtet hat, und in jedem davon liegen Bruchstücke der Wahrheit — manche aktuell, manche von 2019.
- Wenn jemand fragt „Wie war nochmal die Vorgehensweise bei Reklamationen über 5.000 Euro?”, googelt zuerst jemand intern (vergeblich), dann wird telefoniert, und am Ende landet die Antwort vielleicht in einer Mail, die niemand wiederfindet.
- Die Vertriebsleitung will einen Chatbot, der „endlich mal Antworten gibt”. Die IT-Leitung will keinen weiteren Datenfriedhof. Die Geschäftsführung will, dass das Wissen die Firma nicht verlässt, wenn Mitarbeitende gehen.
Warum das jetzt löst statt verschoben wird
- Wissen verlässt das Haus. Ältere Kolleg:innen gehen in Ruhestand, junge wechseln den Arbeitgeber im Schnitt alle 3–5 Jahre. Was nicht zentral abgelegt und auffindbar ist, ist beim Ausscheiden weg.
- KI-Tools sind im Mittelstand angekommen — meistens unkontrolliert. Mitarbeitende kopieren längst Firmen-Dokumente in private ChatGPT-Konten, weil sie schnell Antworten brauchen. Eine geordnete interne Lösung ist die Antwort auf eine Realität, die schon passiert.
- Microsoft 365 bringt die Bausteine bereits mit. Wenn ihr ohnehin in Microsoft 365 arbeitet, ist die technische Distanz zu einem Teams-Bot mit Suche über euer SharePoint nicht riesig — aber sie ist auch nicht null. Spätestens beim Lizenz-Renewal oder bei der Frage „Brauchen wir Copilot?” wird die Diskussion ohnehin geführt. Dann besser einmal sauber.
So sähe das bei dir aus
Schritt 1 — Wissens-Bestand sichten und sortieren (Woche 1–2)
Bevor wir irgendetwas indexieren, klären wir gemeinsam: Wo liegt was, was ist offiziell, was ist veraltet, was darf jede:r sehen und was nicht. Das ist die unbequeme Phase — sie ist aber auch die wichtigste. Eine KI-Suche über eine schlecht sortierte Datenbasis liefert schlechte Antworten, egal wie gut das Modell ist.
Stack: SharePoint Admin Center, Microsoft Graph, Berechtigungs-Audit. Ergebnis: eine Liste von Quellen, die in die Suche aufgenommen werden, plus eine Liste von Quellen, die vorher aufgeräumt werden müssen.
Schritt 2 — RAG-Architektur aufsetzen (Woche 3–5)
Das Muster heißt Retrieval-Augmented Generation: Bei jeder Frage durchsucht das System euer Firmenwissen, holt die relevantesten Passagen, und ein Sprachmodell formuliert daraus eine Antwort — mit Verweis auf die Originalquelle, sodass die fragende Person nachlesen kann. Kein „die KI hat sich das ausgedacht”, sondern „Antwort kommt aus diesem konkreten SharePoint-Dokument, Stand letzter Update”.
Stack: Azure AI Search als Index, Microsoft Graph API als Zugriff auf SharePoint und OneDrive, Azure OpenAI Service oder Foundry für das Sprachmodell, alles in eurem eigenen Azure-Tenant — eure Daten verlassen nicht euer Microsoft-Umfeld.
Schritt 3 — Teams-Bot als Eingang (Woche 5–6)
Mitarbeitende fragen nicht in einer neuen App, die sie installieren müssen. Sie fragen, wo sie ohnehin sind — in Teams. Wir bauen einen Bot, den man wie jede andere Person ansprechen kann: „Wie war nochmal die Reklamations-Vorgehensweise über 5.000 Euro?” Antwort kommt in zwei bis fünf Sekunden, mit Link zur Originalquelle. Wenn die KI keine sichere Antwort hat, sagt sie das — statt zu raten.
Stack: Microsoft Bot Framework, Teams-App-Manifest, optional Power Platform für einfache Anbindungen.
Schritt 4 — Berechtigungen respektieren (Woche 4–6, parallel)
Das ist der Punkt, an dem viele KI-Projekte scheitern: Die Suche darf nur Antworten geben aus Dokumenten, die die fragende Person tatsächlich sehen darf. Wer keinen Zugriff auf den Geschäftsführungs-Ordner hat, soll auch keine Antworten daraus bekommen — auch nicht zusammengefasst. Wir setzen die Suche so auf, dass sie eure SharePoint-Berechtigungen ehrt, nicht umgeht.
Stack: Microsoft Graph mit Delegated Permissions, Azure AI Search mit Security Trimming.
Schritt 5 — Pilot, Feedback, Ausweitung (Woche 6–10)
Wir starten mit einer Pilotgruppe von 10–20 Leuten aus zwei oder drei Abteilungen. Sie nutzen den Bot drei bis vier Wochen, geben Feedback, markieren schlechte Antworten. Daraus passen wir Quellen-Auswahl, Prompts und Antwort-Format an. Erst wenn die Antworten in 80 % der Fälle nützlich sind, rollen wir breiter aus.
Worauf du dabei achten solltest
- Wenn jemand euch eine KI-Suche verkauft, ohne vorher eure SharePoint-Berechtigungen geprüft zu haben — Vorsicht. Genau das ist der Fehler, der dazu führt, dass plötzlich „der Bonus der Geschäftsführung” als Suchergebnis bei jeder Person aufpoppt. Das ist kein Modell-Problem. Das ist ein Berechtigungs-Problem.
- Frag nach Zitaten in den Antworten. Eine seriöse interne KI-Suche zeigt immer, aus welcher Quelle eine Antwort stammt. Eine Lösung, die nur Text ausspuckt ohne Verweis, ist nicht überprüfbar — und damit nicht vertrauenswürdig.
- Klärt, wo die Daten landen. Ein „On-Prem-LLM” klingt sicher, ist aber im Mittelstand selten realistisch zu betreiben. Azure OpenAI in eurem eigenen Azure-Tenant in einer EU-Region ist meist der pragmatische Kompromiss: eure Daten bleiben in eurem Microsoft-Umfeld, das Modell ist nicht zum Trainieren von Drittanbieter-Modellen freigegeben.
- Prüft, ob es wirklich ein eigener Bot sein muss — oder ob Copilot reicht. Microsoft Copilot for Microsoft 365 kann viel von dem, was hier beschrieben ist, bereits out-of-the-box. Wenn euer Wissens-Bestand sauber in SharePoint liegt und eure Berechtigungen stimmen, ist Copilot oft die ehrlichere Antwort als ein Eigenbau. Wenn ihr aber spezifische Quellen außerhalb von M365 einbinden müsst (Ticketsysteme, ERP, Branchen-Wikis), wird ein eigener Bot interessant.
Was sich danach realistisch ändert
- Mitarbeitende finden Antworten auf wiederkehrende Fachfragen in Teams, statt in WhatsApp-Gruppen oder bei Kolleg:innen, die ohnehin schon im Stress sind.
- Onboarding wird leichter: Neue können nachfragen, ohne sich „dumm” zu fühlen, und bekommen Antworten mit Verweis auf die Originalquelle — die sie dann selbst weiterlesen können.
- Wissen, das vorher nur im Kopf einzelner Personen lag, wird zunehmend dokumentiert, weil sichtbar wird, wo die KI keine Antwort findet — und genau da entsteht der Anreiz, etwas niederzuschreiben.
- Die unkontrollierte Nutzung von privaten ChatGPT-Accounts mit Firmen-Daten wird weniger, weil es eine bequemere und legitime Alternative gibt.
- Die Geschäftsführung bekommt eine ehrliche Sicht darauf, welche Themen am häufigsten gefragt werden — und damit einen Indikator, wo Prozess- oder Dokumentations-Lücken liegen.
Was du beisteuerst
- Zugriff: Ein:e Admin in eurem Azure- und Microsoft-365-Tenant, der/die uns gezielt Berechtigungen einräumt. Wir arbeiten mit Service-Prinzipalen, nicht mit dauerhaften persönlichen Admin-Konten.
- Stakeholder-Zeit: Eine fachlich erfahrene Person pro relevante Abteilung, die einschätzen kann, welche Quellen autoritativ sind und welche veraltet — typischerweise 2–3 Stunden pro Abteilung in der Sichtungsphase, danach punktuell beim Pilot-Feedback.
- Datenschutz-Beauftragte:r und Betriebsrat: Eine KI-Lösung, die Mitarbeitenden-Fragen analysieren kann, braucht eine saubere Vereinbarung. Wir liefern die technische Beschreibung, ihr bringt das in eure Mitbestimmungs- und Datenschutz-Prozesse ein.
- Pilot-Gruppe: 10–20 Personen, die bereit sind, drei bis vier Wochen ehrlich Feedback zu geben — und nicht nur „funktioniert” oder „funktioniert nicht” zu melden.
Risiken & wann es NICHT passt
- Wenn euer SharePoint ein Wildwuchs ist und Berechtigungen unklar, dann ist das hier der falsche Erstschritt. Erst aufräumen, dann durchsuchbar machen. Sonst baut ihr eine schnelle Suche über chaotische Daten — und das Chaos wird schneller findbar, nicht kleiner.
- Wenn die Erwartung ist, dass eine KI Prozess-Wissen ersetzt, das nirgends niedergeschrieben ist. Eine RAG-Suche kann nur finden, was existiert. Wenn euer relevantes Wissen nur in Köpfen lebt, ist die Erst-Aufgabe Dokumentation, nicht KI.
- Wenn der Datenschutz-Rahmen nicht geklärt werden kann. In Branchen mit besonderen Geheimhaltungs-Anforderungen (Steuerkanzlei, Arztpraxen-Verbund, kritische Infrastruktur) ist die Frage, was eine KI in welcher Region sehen darf, nicht trivial. Das gehört vorab geklärt, nicht im Pilot.
- Wenn ihr ohnehin demnächst Copilot ausrollen wollt. Dann ist die ehrliche Empfehlung manchmal: Copilot zuerst, Eigenbau erst dann, wenn Copilot nachweislich nicht reicht. Wir empfehlen Copilot nicht reflexartig, aber wir empfehlen ihn auch nicht reflexartig weg.
So fängt das Gespräch an
30 Minuten Erstgespräch, kostenfrei, per Video oder Telefon. Was wir klären: Wo liegt euer Wissen heute überwiegend (SharePoint, Wiki, Tickets, Mails)? Welche Fragen werden bei euch besonders oft wiederholt gestellt? Habt ihr Copilot schon getestet oder bewusst nicht? Wie ist die Datenschutz- und Mitbestimmungs-Lage bei euch? Daraus ergibt sich, ob ein Eigenbau-RAG, Copilot oder eine kleinere Lösung der richtige Weg ist.
Reaktion remote sofort zu Service-Zeiten, Erstgespräch typischerweise in 3–5 Werktagen einrichtbar — ehrlich gesagt im Solo-Betrieb von meinem Kalender abhängig.
Häufige Fragen
Halluziniert die KI dann nicht trotzdem? Halluzinationen entstehen vor allem, wenn ein Sprachmodell „aus dem Kopf” antwortet, ohne Quelle. Im RAG-Pattern wird die Antwort aus euren konkreten Dokumenten heraus formuliert, mit Verweis auf die Quelle. Bei guter Umsetzung sagt die KI „Dazu finde ich nichts in euren Quellen”, statt zu raten. Vollständig ausschließen lässt sich das nie, aber das Risiko sinkt deutlich.
Sehen Microsoft oder OpenAI dann unsere Firmendaten? Bei Nutzung von Azure OpenAI in eurem eigenen Azure-Tenant gelten die Microsoft-Enterprise-Bedingungen: eure Daten werden nicht für das Trainieren von Modellen verwendet, sie bleiben in der gewählten Azure-Region. Das ist nicht dasselbe wie ein privates ChatGPT-Konto eines Mitarbeitenden — und genau deswegen ist die Eigenbau-Variante datenschutzrechtlich klarer aufzusetzen.
Was kostet der Betrieb laufend? Nicht der Bot selbst ist der Kostentreiber, sondern die Modell-Aufrufe und der Suchindex in Azure. Bei einer 80-Personen-Firma mit moderater Nutzung bewegt sich der laufende Azure-Verbrauch typischerweise im niedrigen drei- bis vierstelligen Bereich pro Monat — abhängig stark von Modellwahl und Nutzungsintensität. Wir zeigen euch vor dem Rollout, wie ihr das selbst überwacht und deckelt.
Können wir das später auf andere Quellen erweitern — Tickets, ERP, CRM? Ja, und das ist einer der Gründe, einen Eigenbau-Ansatz statt rein Copilot zu wählen. Über Konnektoren oder eigene Adapter lassen sich auch Quellen außerhalb von SharePoint einbinden. Das macht aber erst Sinn, wenn der Erst-Bereich stabil läuft — sonst baut ihr Komplexität, bevor ihr den ersten Wert seht.