Was dieses Pattern adressiert
Interne Wissensbasen sind heute in vielen Silos: SharePoint, OneDrive, Teams, Confluence, geteilten Laufwerken. Mitarbeitende verbringen geschaetzt 20-30 Minuten pro Tag mit "wo finde ich das"-Suchen. Intranet Chat beantwortet diese Fragen in einer Konversation — aber im Gegensatz zum Website Chat per-User-differenziert: jede:r sieht nur Antworten, die aus Quellen kommen, auf die sie/er wirklich Zugriff hat.
Was Intranet Chat anders macht als Website Chat
| Aspekt | Website Chat | Intranet Chat |
|---|---|---|
| Zielgruppe | Anonyme Besucher | Authentifizierte Mitarbeiter |
| Wissensbasis | Public Website-Inhalte | M365-Tenant, Confluence, Laufwerke |
| Differenzierung | Alle sehen dasselbe | Per-User nach Berechtigungen |
| Identity | Keine | SSO via Entra ID |
| Audit-Trail | Aggregierte Stats | Pseudonymer Audit-Log pro Anfrage |
Permission-Aware Retrieval — drei Schichten
- Identity-Mapping: Beim Login (SSO via Entra ID) erhaelt die User-Session ein Token mit Group-Memberships und Site-Rights.
- Permission-Check vor Retrieval: Der RAG-Adapter filtert vor dem Embedding-Lookup alle Quellen aus, fuer die der User kein Lese-Recht hat. Das LLM sieht damit nie unauthorized Inhalte.
- Source-Display + Defense-in-Depth: Jede zitierte Quelle ist mit Link + Snippet dargestellt. Klick auf den Link oeffnet die Original- Seite in SharePoint/Confluence — wo die Permission nochmal durchgesetzt wird.
Selbst wenn der RAG-Adapter einen Fehler haette, faellt die Berechtigung beim Original-System immer noch durch.
Unterstuetzte Quellen
| Quelle | Status | Anbindung |
|---|---|---|
| SharePoint Online | live | Graph-API (Sites.Read.All) |
| OneDrive for Business | live | Graph-API (Files.Read.All) |
| Microsoft Teams (Channel-Messages, Files) | live | Graph-API |
| Confluence Cloud | live | Atlassian-API |
| Confluence DC | geplant Q3 2026 | REST-API |
| Geteilte Laufwerke (NTFS/SMB) | live | Filesystem-Adapter |
| Wiki.js / Outline | auf Anfrage | REST-API |
Pro Quelle wird beim Setup definiert, was indexiert wird und in welchem Intervall (typisch: alle 5 Minuten Incremental, taeglich Vollindex).
Was es nicht macht
- Keine Aktionen ausloesen — nur Lese-Antworten. Wenn z.B. Tickets erstellt oder Dokumente erzeugt werden sollen → Custom-Pattern (Workflow-Agent) noetig.
- Keine personenbezogene Korrelation — Antworten sind faktisch, der Bot leitet keine HR-Bewertungen oder Personalvergleiche ab.
Setup-Aufwand fuer dieses Pattern
| Phase | Inhalt | Dauer |
|---|---|---|
| 1 | SSO-Anbindung, M365-App-Registrierung, initialer Index 1-2 Pilot-Sites | Woche 1 |
| 2 | Quality-Tuning, weitere Quellen, Audit-Trail-Test | Woche 2 |
| 3-4 | Rollout an Pilot-Gruppe (10-50 User), Feedback | Woche 3-4 |
| 5+ | Stufenweiser Rollout an die Organisation | Woche 5+ |
4-6 Wochen vom Briefing bis breite Verfuegbarkeit.
Wann passt das Pattern
Gut geeignet, wenn mehrere hundert bis tausende interne Wissensdokumente in M365 liegen, User regelmaessig "wo finde ich…" oder "wie macht man…" fragen, und Compliance nachweisbare Permission-Awareness verlangt.
Eher nicht, wenn die Wissensbasis ueberwiegend in Drittsystemen ohne API liegt (z.B. klassisches Lotus-Notes ohne Anbindung), oder nur Public-Knowledge geteilt wird (dann Website Chat).
Allgemeine Themen (Compliance, Audit-Konzept, Pricing, Demo-Anfrage) findest du auf der Sovaia Chat Companions Uebersichtsseite.