Enterprise Search

Enterprise Search bezeichnet eine unternehmensweite Suche, die interne Quellen wie Wikis, Dokumenten-Ablagen, E-Mails, Tickets, Code-Verzeichnisse und Datenbanken über einen gemeinsamen Suchindex (ein zentrales Inhalts-Verzeichnis) erreichbar macht und dabei pro Anfrage die Zugriffsrechte der Ursprungs-Systeme (ACL, Access Control List) wahrt. Ziel ist ein einheitlicher Sucheinstieg über den gesamten internen Wissensbestand einer Organisation, ohne die Rechte-Logik der Ursprungs-Systeme zu umgehen.

Was ist Enterprise Search?

Enterprise Search ist die Anwendungsklasse für Suche über interne, nicht-öffentliche Inhalte eines Unternehmens. Sie unterscheidet sich in drei Punkten von einer normalen Web-Suche. Erstens liegen die Quellen hinter einer Anmeldung (Authentifizierung), sind also nur mit gültigem Login erreichbar. Zweitens sind die Inhalte gemischt: strukturierte Daten wie Datenbank-Tabellen und unstrukturierte Daten wie PDFs, E-Mails oder Chat-Verläufe. Drittens muss die Trefferliste die Zugriffsrechte der Ursprungs-Systeme spiegeln. Ein Treffer darf nur dann erscheinen, wenn die anfragende Person ihn auch direkt im Ursprungs-System lesen dürfte.

Die typische Architektur besteht aus mehreren Schichten. Ein Konnektor-Layer zieht Inhalte aus Quellsystemen wie Confluence, SharePoint, Google Drive, Jira, Slack, Mail-Servern, Code-Repositories und Datenbank-Katalogen. Ein Permissions-Layer spiegelt die Zugriffskontrollen der Quelle und wendet sie pro Anfrage als Filter (ACL-Filter) auf den Index an. Der Index selbst kombiniert heute klassische lexikalische Suche (BM25) mit semantischem Retrieval über Vektor-Embeddings. Eine Reranker-Stufe (oft ein Cross-Encoder) sortiert die Kandidaten nach Relevanz für die konkrete Frage. Optional übergibt ein Antwort-Layer die besten Treffer an ein Sprachmodell, das eine formulierte Antwort mit Quellen-Zitat erzeugt. Ein Audit-Log hält Query, Treffer und Antwort für Governance und Fehler-Analyse fest.

Der Begriff stammt aus den frühen 2000er Jahren. Damals prägten Anbieter wie Autonomy (Cambridge, ab 1996), FAST (Norwegen, an Microsoft 2008), Endeca (an Oracle 2011) und die Google Search Appliance (eingestellt 2016) die Kategorie. Gartner führt die heutige Klasse als „Insight Engines". Aktuelle Vertreter sind Elastic (Search AI), Glean, Coveo, Microsoft Search mit Copilot-Integration, Lucidworks, Sinequa und IntraFind. Der Bedeutungswandel seit 2023 verschiebt die Kategorie: statt einer Trefferliste liefert eine moderne Enterprise-Search-Schicht die Retrieval-Grundlage für KI-Assistenten und Agenten. Damit wird die Such-Schicht zur Voraussetzung für belegte KI-Antworten im Unternehmenskontext.

Abgrenzung zu RAG, AI Search, Vector Search und Web Search

Der Begriff wird in KI-Projekten häufig mit angrenzenden Konzepten vermischt.

Die Trennung zu [Retrieval-Augmented Generation](/insights/glossar/rag/) ist die häufigste Verwechslung: RAG ist ein Muster, Enterprise Search eine Produkt- und Plattform-Klasse. Eine RAG-Pipeline kann eine Enterprise-Search-Schicht als Retriever nutzen; umgekehrt kann eine Enterprise Search auch ohne Sprachmodell-Antwort funktionieren und nur eine sortierte Trefferliste zurückgeben. AI Search und Semantic Search bezeichnen dagegen die Retrieval-Technik, nicht die Anwendung. Ein Vergleichspunkt aus einer konkreten Plattform findet sich in [AI Search auf Databricks](/insights/databricks/artificial-intelligence/ai-search/), das den Retrieval-Baustein für RAG-Anwendungen bereitstellt. Vector Search ist damit ein Baustein moderner Enterprise Search, aber kein Ersatz: Konnektor-Pflege, ACL-Filter und Audit-Log gehören nicht zum reinen Vektor-Index. Web-Suche unterscheidet sich strukturell, weil sie öffentliche Inhalte ohne Berechtigungsfilter indiziert.

Beispiel: ACL-treue Anfrage aus einem internen KI-Assistenten

Ein Mitarbeitender fragt einen internen KI-Assistenten: „Welcher Wartungsvertrag gilt für Kunde X?". Die Enterprise-Search-Schicht führt die Anfrage in drei Schritten aus. Zuerst prüft der Permissions-Layer, welche Objekte die anfragende Identität in CRM, Vertragsablage und SharePoint sehen darf, und baut daraus einen ACL-Filter für den Index. Dann läuft eine Hybrid-Abfrage über den gefilterten Index: BM25 findet den Kundennamen als Token-Treffer in Vertrags-Kopfzeilen, Vektor-Retrieval findet semantisch ähnliche Passagen zu „Wartung" und „Service-Level". Ein Reranker sortiert die Kandidaten gegen die volle Frage. Die drei besten Passagen und deren Quellen übergibt die Such-Schicht an das Sprachmodell, das eine Antwort mit Zitat der Vertragsstelle formuliert. Ein Audit-Eintrag hält Query, Treffer und Antwort fest. Ohne die Such-Schicht müsste der Assistent pro Quellsystem einen eigenen Retriever betreiben und die Berechtigungen selbst rekonstruieren, was in produktiven Umgebungen zu Datenschutz-Vorfällen führt.