Semantische Unternehmenssuche über Intranet, Laufwerke und Tools

Unternehmenswissen liegt in Dateiservern, SharePoint, Wikis, Ticketsystemen und Chats, jeweils mit einer eigenen, schwachen Suche. Die Unternehmenssuche verbindet diese Quellen zu einem Index, findet Treffer nach Bedeutung und nicht nur nach Schlagwörtern und zeigt jeder Person nur das, was sie ohnehin sehen darf. Das Ergebnis ist ein einziges Suchfeld (oft mit einer KI-Antwort samt Quellenangaben darüber), das die Zeit verkürzt, die Beschäftigte mit der Suche nach Informationen verlieren, und das die Grundlage für jeden internen Assistenten bildet.

Problem & Nutzen

• Heute: Beschäftigte suchen in fünf bis fünfzehn Tools, jedes mit eigener Schlagwortsuche und eigenem Berechtigungsmodell. Wissen wird neu erstellt, weil das alte Dokument nicht auffindbar ist; neue Mitarbeitende fragen Kolleginnen und Kollegen; der IT-Helpdesk beantwortet immer wieder dieselben Fragen.
• KI-Nutzen: Embeddings finden Dokumente nach Bedeutung („Homeoffice-Regeln" findet „Regelung zum mobilen Arbeiten"), Reranker schieben die besten Treffer nach oben, OCR macht Scans durchsuchbar, und ein LLM kann die besten Treffer mit Quellenangaben zusammenfassen. Sprachübergreifende Suche lässt eine deutsche Anfrage englische Dokumente finden.
• Nutzenzahlen: Anbieter veröffentlichen Zeitersparnis-Angaben, sie sind aber meist selbst berichtet und selten unabhängig gemessen. Behandeln Sie sie als Hypothesen und messen Sie vor und nach einem Pilot Ihre eigene Ausgangslage (Such-Erfolgsquote, Zeit bis zum Fund). Eine allgemeine Zahl wird hier nicht genannt.
• Der schwierige Teil: nicht das Modell, sondern Konnektoren, Aktualität und vor allem berechtigungskorrekte Ergebnisse.

Varianten

• KMU: Suche über Microsoft 365 oder Google Workspace plus einen Dateiserver; meist genügt die eingebaute Suche der Suite.
• Großunternehmen: systemübergreifende Suche über mehr als 20 Systeme mit Synchronisation des Identitätsanbieters, föderierten und indexierten Konnektoren, Analysen und Agentenzugriff (über MCP) auf denselben Index.
• Öffentlicher Sektor: Suche in Intranet und Dokumentenmanagement (DMS/E-Akte) mit strikter Datenhaltung im eigenen Rechtsraum, oft On-Premises.
• Entwicklung / IT: Suche in Code, Runbooks und Störungsmeldungen (für Handbücher der Techniker siehe KNOW-004).
• Privat: lokale semantische Suche über eigene Dateien und E-Mails (siehe KNOW-018).
• Nicht Gegenstand: dialogbasierte Fragen und Antworten als Hauptprodukt (KNOW-002), HR-Self-Service (KNOW-003), Produktsuche für Shops (KNOW-005), Bild-/Videoarchive (KNOW-016).

So funktioniert es

1. Konnektoren (Crawl / Webhook / föderiertes MCP) + ACL- & Gruppensync aus dem IdP (Entra ID, LDAP, Okta)
2. Textextraktion + OCR + layoutbewusste Aufteilung in Abschnitte (DOC-014)
3. Metadatenanreicherung (Quelle, Autor, Datum, Typ, Sprache, ACL)
4. hybrider Index: BM25-Schlagwortsuche + dichte (und optional dünnbesetzte) Vektoren
5. Anfrage: umformulieren / erweitern
6. hybride Suche mit ACL-Filter
7. Fusion (RRF)
8. Cross-Encoder-Reranking
9. Ergebnisse (Snippets, Facetten) [+ optional LLM-Antwort mit Quellenangaben]
10. Feedback & Auswertung (Klicks, Anfragen ohne Treffer)
11. Feinabstimmung

• Hybride Suche ist der Standard im Produktivbetrieb: Die Schlagwortsuche erfasst exakte Begriffe (Teilenummern, Vertragsnummern, Namen), Vektoren erfassen Umschreibungen und sprachübergreifende Treffer, und Reciprocal Rank Fusion führt beides ohne Kalibrierung der Bewertungen zusammen [5].
• Berechtigungsfilterung muss innerhalb der Abfrage erfolgen (Filter auf ACL-Felder), nicht erst nachdem das LLM den Text gesehen hat. Indexieren Sie die ACL mit jedem Textabschnitt und synchronisieren Sie Gruppenänderungen regelmäßig [1][2].
• Föderierte Konnektoren (Live-Abfrage über MCP, ohne Indexierung) eignen sich für sensible oder sich schnell ändernde Quellen; synchronisierte Konnektoren liefern bessere Relevanz und Geschwindigkeit [2].
• Mensch-in-der-Schleife (Human-in-the-Loop): Suchadministratoren pflegen Synonyme, hervorgehobene Treffer und den Quellenumfang; Nutzer geben Rückmeldungen. Das System liest nur, Freigabeschritte sind daher nur wichtig, wenn Agenten auf Basis der Ergebnisse handeln.

Datenaufbereitung

Die Suche braucht keine neuen Daten, sie legt aber jeden Mangel der vorhandenen Daten offen. Quellen sind typischerweise der Dateiserver und SharePoint (Office, PDF, Scans), das DMS, Mailarchive, Wiki oder Intranet, das Ticketsystem und die ERP-Anhänge. Typische Lücken sind gescannte PDFs ohne Text, doppelte und veraltete Versionen, Ordnerstrukturen, die niemand versteht, fehlende Metadaten und vor allem gewachsene Zugriffsrechte: Ist ein Ordner für alle offen, zeigt die Suche ihn allen.

Schritte der Aufbereitung: - Quellen erfassen und für jede eine verantwortliche Person benennen (PREP-001, PREP-004). - Gescannte Archive mit Werkzeugen wie Paperless-ngx, OCRmyPDF oder Azure Document Intelligence per OCR erschließen (PREP-006, DOC-014). - Offensichtliche Dubletten entfernen und tote Ordner archivieren; grundlegende Metadaten wie Typ, Datum und Verantwortliche(r) ergänzen (PREP-009, PREP-010). - Berechtigungen vor der Indexierung bereinigen und mit einem normalen Nutzerkonto testen (PREP-023). - Einen kleinen Satz echter Testfragen aufbauen (PREP-018).

Rechnen Sie damit, dass etwa die Hälfte des Projektaufwands in die Bereinigung von Daten und Berechtigungen fließt, großenteils durch die Datenverantwortlichen und nicht durch die IT. Ein gestufter Start mit den Quellen einer Abteilung hält das beherrschbar. Siehe auch GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• KMU: Weg A, weil ausgereifte, in der EU hostbare Suchprodukte sowie die Suchfunktionen von Microsoft 365 oder Atlassian zu KMU-Preisen verfügbar sind und es fertige Konnektoren für Standardquellen gibt.
• Großunternehmen: Weg B, weil viele unterschiedliche Quellen, eigene Berechtigungsmodelle und ein hohes Anfragevolumen eine maßgeschneiderte Suchschicht auf Cloud-KI-Diensten rechtfertigen.
• Entwicklung: Weg C, weil Open-Source-Stacks (OpenSearch oder Qdrant mit offenen Embedding-Modellen) volle Kontrolle über Konnektoren und Ranking bieten.
• Öffentlicher Sektor: Weg C auf souveräner EU- oder deutscher Infrastruktur, weil Dokumentenbestände sensibel sind und das Vergaberecht kontrolliertes Hosting begünstigt.

Weg A — Kaufen (für die meisten KMU empfohlen)

• Suite-nativ: Microsoft 365 Copilot Search und Copilot-Konnektoren (über 100 vorgefertigte Konnektoren, synchronisiert oder föderiert über MCP, Quellberechtigungen werden beachtet) [2]; Google Workspace / Gemini Enterprise Search; Atlassian Rovo für Jira/Confluence.
• Spezialisierte Plattformen: Glean, Coveo (CA), Elastic-Enterprise-Search-Komponenten, Sinequa (FR, EU), IntraFind iFinder (DE, EU), Mistral Le Chat Enterprise mit Konnektoren (FR, EU), Onyx Managed Cloud. Prüfen Sie: tatsächlich genutzte Konnektoren, ACL-Treue (einschließlich verschachtelter Gruppen), EU-Hosting oder On-Premises-Option, Antworten mit Quellenangaben, Admin-Analysen, Preis pro Nutzer.
• Wählen Sie A, wenn: der Großteil der Inhalte bereits in einer Suite oder in wenigen verbreiteten SaaS-Tools liegt.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Verwaltete Suche: Azure AI Search (hybride und semantische Rangfolge, EU-Regionen) mit Zugriffskontrolle auf Dokumentebene: Sicherheitsfilter (allgemein verfügbar) oder native ACL, SharePoint-ACL und Durchsetzung von Purview-Labels (Vorschau in der geprüften Dokumentationsversion, prüfen Sie den Status daher vor dem Produktivbetrieb) [1]; Elastic Cloud oder OpenSearch Service (EU-Regionen) mit hybriden Abfragen [5][6].
• Modelle: Embedding- und Rerank-APIs von Cohere, Voyage, Mistral (EU) oder OpenAI/Google; ein LLM für die optionale Antwortschicht (Claude, Gemini, GPT, Mistral). Nutzen Sie für die DSGVO EU-Regionen oder EU-Anbieter.
• Orchestrierung: eigene Ingestion-Dienste oder n8n; Konnektor-SDKs der Quellen selbst (Microsoft Graph, Confluence, Google-Drive-APIs).
• Wählen Sie B, wenn: Sie eigene Quellen, ein eigenes Ranking oder die Einbettung der Suche in Ihr eigenes Produkt benötigen.

Weg C — Selbst betreiben (Open Source)

• Plattformen: Onyx (MIT Community Edition, über 50 Konnektoren, Betrieb ohne Netzanbindung möglich) [4]; OpenSearch oder Elasticsearch, Apache Solr, Vespa, Qdrant, Weaviate, pgvector für den Index.
• Modelle: BGE-M3 (MIT, dicht + spärlich + Multi-Vektor, über 100 Sprachen, 8192 Token) [3]; Qwen3-Embedding-8B und Qwen3-Reranker-8B (Apache 2.0, über 100 Sprachen) [7]; multilingual-e5 als leichtere Option. Extraktion mit Docling, Apache Tika, Unstructured.
• Hardware: HW2 genügt für Embedding und Reranking von einigen Millionen Textabschnitten und ein Antwortmodell mit 7–30 Mrd. Parametern; ein kleinerer Index läuft mit einem kleinen Embedding-Modell auf der CPU (HW1). HW3 ist nur für ein starkes lokales Antwort-LLM nötig. Planen Sie den Arbeitsspeicher für den Index ein, nicht nur die GPU.
• Betriebsaufwand: Konnektoren und ACL-Synchronisation sind die dauerhafte Arbeitslast, nicht das Modell.

Weg D — Eigenes Training

Meist nicht nötig. Ein Embedding-Modell oder einen Reranker per Feintuning anzupassen lohnt sich nur, wenn Fachjargon (chemische Nomenklatur, interne Codes, juristisches Deutsch) von allgemeinen Modellen schlecht gefunden wird. Es braucht einige tausend Paare aus Anfrage und Dokument, die aus Klick-Protokollen und aus vom LLM erzeugten synthetischen Anfragen gewonnen und an einem zurückgehaltenen Testsatz validiert werden können. Messen Sie immer zuerst gegen eine abgestimmte hybride Ausgangsbasis.

Stand der Technik (2026)

• Hybride Suche plus Reranking schlägt reine Vektorsuche in der Praxis; offene mehrsprachige Embedding-Modelle wie Qwen3-Embedding-8B (bei Veröffentlichung im Juni 2025 an erster Stelle der mehrsprachigen MTEB-Rangliste) und BGE-M3 sind starke, selbst betreibbare Ausgangsbasen [3][7][8]. Ranglisten-Werte sind allgemein und ersetzen keinen Test an Ihren eigenen deutschen Unternehmensdokumenten.
• Agentische Suche: Assistenten zerlegen eine Frage in Teilanfragen, durchsuchen mehrere Quellen und führen die Ergebnisse zusammen; Azure AI Search liefert dies als agentische Suche und verwaltete Wissensschicht [1]. Suchindizes werden zunehmend über MCP für Agenten bereitgestellt, einschließlich föderierter Live-Konnektoren [2].
• Berechtigungsbewusste Indizes sind inzwischen eine eingebaute Funktion großer Plattformen, doch die Synchronisationsverzögerung (Berechtigungen werden erst nach der nächsten Synchronisation übernommen) bleibt eine bekannte Lücke [1].
• Grenzen und Fehlerbilder: veraltete oder doppelte Dokumente; ACL-Lecks durch zu weit gefasste Gruppenzuordnung oder Synchronisationsverzögerung; OCR-Fehler bei Scans; Tabellen und Folien, die beim Zerlegen ihre Struktur verlieren; KI-Antworten, die richtig klingen, aber eine Richtlinienversion falsch lesen; in indexierte Dokumente eingeschleuste Prompt-Injection; schlechte Ergebnisse bei kurzen, mehrdeutigen Anfragen ohne Klick-Rückmeldung.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack (embedding-text + reranker + vector-db + search-engine): KNOW-002 RAG-Assistenten, KNOW-003 HR-/Richtlinien-Assistent, KNOW-004 technische Dokumentation, KNOW-009 Fragen zu Normen und Standards, KNOW-013 GraphRAG. Ein gemeinsamer hybrider Index mit ACL-Schicht kann alle bedienen; bauen Sie ihn einmal.
• Ingestion: DOC-014 (Dokumentenverarbeitung für RAG) und DOC-008 (Klassifikation der Eingangspost) speisen dieselbe Extraktionsstrecke; KNOW-025 (Klassifikation von Akten, Bereinigung von ROT-Daten) entfernt veraltete Inhalte und liefert Aufbewahrungslabels, die als Filter dienen.
• Nachbarn: KNOW-016 multimodale Archive (CLIP-/Vision-Embeddings im selben Index ergänzen), KNOW-012 Expertensuche (Personen als indexierter Entitätstyp).
• Hardware: Ein HW2-GPU-Server kann Embedding-Modell, Reranker und ein kleines LLM zusammen mit den oben genannten Anwendungsfällen betreiben.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage bis Wochen für suite-native Suche; spezialisierte Plattformen Wochen, Preis pro Nutzer.
• Weg B: 1–3 Monate für einen produktiven Index mit 3–5 Konnektoren und ACL-Synchronisation.
• Weg C: 2–4 Monate plus laufende Konnektorpflege; ein Server und Betriebszeit.
• Kostentreiber: Anzahl und Qualität der Konnektoren, ACL-Komplexität, Umfang der Neuindexierung, Token-Kosten der Antwortschicht, Lizenzen pro Nutzer.
• Kennzahlen: Such-Erfolgsquote (Klick- oder „gefunden"-Rückmeldung), Quote der Anfragen ohne Treffer, Zeit bis zum Fund, nDCG oder Recall@10 an einem Referenzsatz aus 100–300 echten Anfragen, Aktualitätsverzug des Index, Bestehensquote der Berechtigungstests, Nutzung (wöchentlich aktive Suchende), Ticketaufkommen für wiederkehrende Fragen.

Menschen & Veränderung

Beginnen Sie mit der Geschäftsführung und den Abteilungsleitungen: Sie entscheiden, welche Quellen aufgenommen werden und wer sie verantwortet. Beziehen Sie die Datenverantwortlichen und die IT früh ein, denn Konnektoren, Konten und Berechtigungen liegen auf dem kritischen Pfad. Die IT-Sicherheitsbeauftragte bzw. der IT-Sicherheitsbeauftragte und die/der Datenschutzbeauftragte prüfen vor dem Pilot Zugriffskontrolle und Protokollierung; eine Datenschutz-Folgenabschätzung (DSFA) ist ratsam, weil personenbezogene Daten in Dokumenten und E-Mails durchsuchbar werden (GUIDE-005).

Betriebsrat: kommt darauf an. Falls ein Betriebsrat besteht: Suchprotokolle und Anfrageanalysen sind technisch geeignet, das Verhalten zu überwachen, daher ist die Mitbestimmung nach §87 Abs. 1 Nr. 6 BetrVG wahrscheinlich; §90 Abs. 1 Nr. 3 verlangt ohnehin eine rechtzeitige Unterrichtung. Schließen Sie eine Betriebsvereinbarung, die eine individuelle Leistungsbewertung anhand von Suchprotokollen ausschließt (GUIDE-004). Im öffentlichen Dienst übernimmt der Personalrat diese Rolle.

Wählen Sie als Pilotgruppe ein bis zwei Abteilungen mit sichtbarem Suchproblem. Typische Bedenken sind „Alle können meine Dateien sehen" (Antwort: Berechtigungen werden durchgesetzt und getestet; zu weit geöffnete Freigaben werden vorher bereinigt) und „Die KI antwortet falsch" (Antwort: Ergebnisse verweisen immer auf die Quelle, die Antwort ist eine Hilfe). Maßnahmen zur Förderung der KI-Kompetenz nach Art. 4 KI-Verordnung (AI Act) können kurze Einführungen zum Formulieren von Anfragen und zum Prüfen von Quellen sein (GUIDE-006, GUIDE-008).

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): im typischen Fall minimales Risiko; Suche und Retrieval ist kein Anwendungsfall nach Anhang III. Die Pflicht zur KI-Kompetenz (Art. 4) gilt [9]. Ist die Antwortschicht ein Chatbot, informieren Sie die Nutzer, dass sie mit KI interagieren (Transparenz nach Art. 50). Ein höheres Risiko entsteht nur, wenn der Index für Personalentscheidungen, Mitarbeiterüberwachung oder ähnliche Zwecke nach Anhang III genutzt wird (z. B. Durchsuchen der Kommunikation von Beschäftigten zur Bewertung des Personals).
• DSGVO: Der Index enthält personenbezogene Daten (E-Mails, Chats, Personalakten); erforderlich sind Rechtsgrundlage, Auftragsverarbeitungsvertrag (AVV) mit Anbietern, EU-Region oder On-Premises, Löschung, die von der Quelle in den Index durchschlägt, DSFA empfohlen. Die Mitbestimmung des Betriebsrats (BetrVG §87) gilt in Deutschland, wenn die Kommunikation von Beschäftigten durchsucht wird.
• Sicherheit: Crawler-Konten mit minimalen Rechten, Durchsetzung der ACL zum Abfragezeitpunkt, Ausschluss sensibler Quellen (Personal, Legal Hold), sofern nicht gesondert geregelt, Audit-Protokolle, Schutz der Antwortschicht gegen Prompt-Injection.
• Gegenmaßnahmen: Berechtigungstests mit echten Konten vor der Einführung, Positivliste der Quellen, Vertraulichkeitslabels als Filter, Quellenangaben bei jeder generierten Antwort.

Erste Schritte

1. Listen Sie die 5–10 Systeme auf, in denen das meiste Wissen liegt; ordnen Sie sie nach Nutzung und nach Sensibilität.
2. Prüfen Sie vor einem Kauf, was die Suite bietet, für die Sie ohnehin bezahlen (Copilot Search, Google, Atlassian).
3. Sammeln Sie 100 echte Suchanfragen aus Helpdesk-Tickets und Interviews mit den erwarteten Ergebnissen; das ist Ihr Bewertungssatz.
4. Testen Sie ein Produkt oder einen Stack im Pilot mit 2–3 Quellen und prüfen Sie die Berechtigungen mit Konten unterschiedlicher Rollen.
5. Ergänzen Sie die Antwortschicht erst, wenn die Suchqualität gut ist; verfolgen Sie die Kennzahlen monatlich.

Quellen

1. Microsoft Learn — Document-level access control in Azure AI Search — https://learn.microsoft.com/en-us/azure/search/search-document-level-access-overview
2. Microsoft Learn — Microsoft 365 Copilot connectors overview — https://learn.microsoft.com/en-us/microsoft-365/copilot/connectors/overview
3. BAAI — BGE-M3 model card — https://huggingface.co/BAAI/bge-m3
4. Onyx — open-source repository — https://github.com/onyx-dot-app/onyx
5. Elastic — Hybrid search and RRF — https://www.elastic.co/search-labs/blog/hybrid-search-elasticsearch
6. OpenSearch documentation — vector and hybrid search — https://docs.opensearch.org/latest/vector-search/
7. Qwen — Qwen3-Embedding-8B model card — https://huggingface.co/Qwen/Qwen3-Embedding-8B
8. MTEB / MMTEB embedding benchmark — https://github.com/embeddings-benchmark/mteb
9. AI Act Art. 4 (AI literacy) — https://artificialintelligenceact.eu/article/4/