Enterprise RAG: kaufen, bauen oder hybrid?

Die Frage „RAG kaufen oder selbst bauen?“ ist für Unternehmen meist zu grob gestellt.

Enterprise RAG ist kein einzelnes Produkt, sondern ein Stack aus Datenquellen, Ingestion, Parsing, Berechtigungen, Search, Modellen, Orchestrierung, Evaluation und Betrieb. Die bessere Entscheidung lautet deshalb:

Welche Schichten müssen wir selbst kontrollieren, welche können wir konfigurieren und welche können wir sinnvoll einkaufen?

Gartner behandelt Build-vs-Buy für RAG inzwischen ausdrücklich als Architektur- und Capability-Entscheidung: Vor einer Wahl sollten Unternehmen bewerten, wo echte Differenzierung liegt und welche Fähigkeiten intern vorhanden sind. Quelle: Gartner – Decide Between Build or Buy Solutions for RAG.

Für die technische Basis siehe RAG-System entwickeln & richtig aufbauen.

Die Kurzantwort

Für die meisten Mittelstands- und Enterprise-Szenarien ist ein Hybridmodell am sinnvollsten:

• selbst besitzen/kontrollieren: Datenlogik, Berechtigungen, Qualitätskriterien, kritische Integrationen, Governance und Exit-Plan,
• konfigurieren oder einkaufen: Vector-/Search-Infrastruktur, Modelle, Standard-Connectoren, Observability-Komponenten,
• gezielt selbst entwickeln: alles, was echten Prozess-, Daten- oder Integrationsvorteil schafft.

Der Fehler liegt meist nicht darin, zu viel oder zu wenig zu kaufen. Er liegt darin, die falschen Schichten aus der Hand zu geben.

Enterprise RAG besteht aus mehreren Entscheidungen

| Schicht | Typische Fragen | Build-/Buy-Relevanz | | --- | --- | --- | | Datenquellen | Wo liegen Dokumente und strukturierte Daten? | hoch | | Ingestion & Sync | Wie kommen Änderungen zuverlässig in den Index? | mittel–hoch | | Parsing & Chunking | Wie bleiben Struktur, Tabellen und Kontext erhalten? | mittel | | Berechtigungen | Wer darf welche Evidenz sehen? | sehr hoch | | Search | Vector, Keyword, Hybrid, Filter, Reranking? | mittel | | Modelle | Hosted, private, open source, mehrere Anbieter? | mittel | | Orchestrierung | RAG, Tools, Workflows, Agents? | hoch | | Evaluation | Was bedeutet „gut genug“? | sehr hoch | | Observability | Wie erkennt man Regressionen und Drift? | mittel | | UI / Workflow | Wo arbeitet der Nutzer tatsächlich? | hoch | | Betrieb | Incident, Kosten, Updates, Ownership? | sehr hoch |

Diese Schichten haben unterschiedliche Lock-in-, Risiko- und Differenzierungsprofile.

Was Unternehmen selbst besitzen sollten

1. Daten- und Dokumentidentität

Eine Plattform darf austauschbar sein. Die Logik, welches reale Objekt ein Dokument oder Datensatz repräsentiert, sollte es nicht sein.

Sie brauchen klare Antworten auf:

• Welche ID bleibt über Versionen stabil?
• Welche Quelle ist führend?
• Wie werden Änderungen erkannt?
• Wie werden Löschungen propagiert?
• Wie werden Metadaten erhalten?
• Welche Version darf als Evidenz verwendet werden?

Mehr dazu: RAG-Datenquellen anbinden.

2. Berechtigungsmodell

Ein RAG-System darf nicht nur relevante Dokumente finden. Es darf nur zulässige Dokumente finden.

ACLs, Gruppen, Mandanten und Rollen gehören deshalb zu den Kernarchitekturentscheidungen.

Wenn eine Plattform das Berechtigungsmodell nur teilweise abbilden kann, entsteht später häufig ein teurer Architekturbruch.

Deep Dive: RAG-Berechtigungen & Security Trimming.

3. Definition von Qualität

Kein Anbieter kann für Sie entscheiden, was eine akzeptable Antwort ist.

Sie sollten selbst besitzen:

• reale Testfragen,
• erwartete Quellen,
• kritische Fehler,
• Rechtefälle,
• No-Answer-Fälle,
• Business-Erfolgskriterien.

Dieses Golden Dataset ist strategischer als die konkrete Vector Database.

Siehe RAG Evaluation: Metriken, Golden Dataset & Regression Tests.

4. Integrationsgrenzen

Das Unternehmen sollte wissen, welche Systeme lesen oder schreiben dürfen:

• ERP,
• CRM,
• DMS,
• SharePoint,
• APIs,
• interne Anwendungen.

Auch wenn ein Anbieter die technische Integration liefert, sollten API-Verträge und Systemgrenzen nachvollziehbar bleiben.

Was häufig nicht selbst gebaut werden muss

Vector Database

Eine eigene Vektordatenbank-Engine zu entwickeln erzeugt für normale Unternehmen kaum Differenzierung.

Relevant ist eher:

• Datenresidenz,
• Filterfunktionen,
• Hybrid Search,
• Skalierung,
• Backup,
• Exportierbarkeit,
• Betriebsmodell.

Embedding- und Foundation-Modelle

Die meisten Unternehmen brauchen kein eigenes Foundation Model.

Wichtiger ist eine Modellabstraktion, damit Sie:

• Modelle vergleichen,
• Anbieter wechseln,
• Kosten kontrollieren,
• lokale/private Modelle einsetzen,
• spezielle Modelle für einzelne Aufgaben verwenden können.

Standard-Connectoren

Wenn ein stabiler Connector für SharePoint, Confluence oder eine verbreitete Datenquelle existiert, sollte man ihn nicht aus Prinzip neu entwickeln.

Aber: Connector vorhanden bedeutet noch nicht produktive Integration gelöst.

Synchronisierung, Delete Propagation, ACLs, Versionierung und Fehlerhandling bleiben Architekturthemen.

Wann Buy sinnvoll ist

Eine Plattform oder Managed Service ist besonders attraktiv, wenn:

• das interne KI-/Platform-Team klein ist,
• Time-to-Value wichtig ist,
• Standarddatenquellen dominieren,
• keine stark proprietäre Retrieval-Logik nötig ist,
• Betrieb und Updates nicht selbst übernommen werden sollen,
• Security-/Enterprise-Funktionen bereits passend vorhanden sind.

Gartner weist bei RAG explizit darauf hin, dass die Komplexität von Enterprise RAG verpackte Lösungen attraktiv macht – gleichzeitig müssen Capability und Differenzierungsbedarf vor der Entscheidung bewertet werden. Quelle: Gartner.

Wann Build sinnvoll ist

Eigenentwicklung wird interessanter, wenn:

• Datenmodelle ungewöhnlich sind,
• Berechtigungen komplex sind,
• proprietäre Workflows entscheidend sind,
• Retrieval selbst einen Wettbewerbsvorteil darstellt,
• sehr spezifische Compliance-/Hosting-Anforderungen bestehen,
• Plattformgrenzen mit bestehenden Unternehmenssystemen kollidieren.

„Build“ heißt dabei nicht, jede Infrastrukturkomponente selbst zu programmieren.

Ein sinnvolles Build kann beispielsweise heißen:

eigene API-/Orchestrierungsschicht + eigener Permission Layer + eigene Evaluation + gemanagte Search-/Model-Komponenten.

Wann Hybrid meist gewinnt

Aktuelle Build-vs-Buy-Frameworks für Enterprise AI gehen zunehmend weg von einer monolithischen Entscheidung. Gartner beschreibt für Enterprise Applications allgemein ein Buy, Build and Blend-Modell; ein aktueller RAG-Vergleich von Sphere argumentiert ebenfalls für eine Layer-by-Layer-Allokation statt einer einzigen Plattformentscheidung. Quellen: Gartner – Build vs. Buy Strategy, Sphere – Enterprise RAG Platforms: Build vs. Buy vs. Partner.

Für Unternehmen ist das praktisch:

| Layer | Häufig sinnvolle Tendenz | | --- | --- | | Datenmodell | selbst kontrollieren | | ACL / Permissions | selbst kontrollieren | | Business-Evaluation | selbst kontrollieren | | Search Engine | kaufen / managed / OSS betreiben | | LLMs | Provider oder private Modelle austauschbar nutzen | | Standard-Connector | kaufen / OSS / Partner | | Spezialintegration | selbst / Partner | | Workflow-Logik | selbst kontrollieren | | Observability | kaufen oder integrieren | | UI | bestehende Anwendung integrieren oder gezielt bauen |

Das ist kein Dogma. Es ist ein Startpunkt für eine Architekturentscheidung.

Die wichtigste Build-vs-Buy-Frage: Wo liegt Ihre Differenzierung?

Ein Unternehmen sollte nicht selbst bauen, nur weil es technisch möglich ist.

Fragen Sie:

1. Erzeugt diese Schicht einen echten Wettbewerbsvorteil?
2. Ist sie spezifisch für unsere Daten, Prozesse oder Rechte?
3. Können wir sie langfristig betreiben?
4. Ist ein Anbieterwechsel realistisch?
5. Wie teuer ist ein Fehler oder Ausfall?
6. Wie schnell muss der erste produktive Nutzen entstehen?

Wenn eine Komponente austauschbar und nicht differenzierend ist, spricht viel gegen eine Eigenentwicklung.

Lock-in prüfen, bevor er entsteht

Vendor Lock-in ist nicht nur ein Vertragsproblem.

Er kann entstehen durch:

• proprietäre Chunk-/Indexformate,
• nicht exportierbare Evaluationsdaten,
• proprietäre Workflow-Definitionen,
• Modellabhängigkeit,
• nicht portable ACL-Logik,
• undokumentierte Connector-Zustände,
• fehlende APIs.

Eine gute Plattformstrategie beantwortet deshalb schon vor dem Kauf:

Was müssen wir exportieren können, damit wir in 12 Monaten wechseln könnten?

Exit-Plan-Checkliste

Mindestens diese Assets sollten portabel bleiben:

• Originaldaten,
• Dokument-IDs und Metadaten,
• ACL-/Permission-Mapping,
• Golden Dataset,
• Evaluationsresultate,
• Prompt-/Workflow-Versionen,
• API-Verträge,
• Konfiguration der Integrationen,
• Betriebs- und Incident-Dokumentation.

Nicht alles muss in einem offenen Standard vorliegen. Aber nichts Kritisches sollte nur als unsichtbarer Zustand in einer Black Box existieren.

12 Fragen vor einer Plattformentscheidung

1. Welche Datenquellen müssen angebunden werden?
2. Wie komplex sind Berechtigungen und Mandanten?
3. Wie schnell ändern sich die Daten?
4. Welche Dokumenttypen sind schwierig?
5. Brauchen wir Keyword + Vector + Reranking?
6. Welche Modelle müssen unterstützt werden?
7. Müssen Modelle austauschbar sein?
8. Welche Actions/APIs werden später integriert?
9. Wie evaluieren wir Qualität?
10. Welche Betriebs-/Observability-Funktionen brauchen wir?
11. Was müssen wir exportieren können?
12. Welche Schicht erzeugt tatsächlich unsere Differenzierung?

Wenn diese Fragen vor der Produktauswahl nicht beantwortet sind, wird häufig eine Plattform gewählt, bevor die Architektur verstanden ist.

Anti-Patterns

Alles selbst bauen

Das bindet knappe AI-/Engineering-Kapazität an Infrastruktur, die keinen Geschäftsvorteil erzeugt.

Alles einkaufen

Dann werden Datenmodell, Rechte, Evaluation oder Workflow-Logik leicht Teil einer proprietären Black Box.

Anbieter zuerst, Architektur später

Dann wird die Zielarchitektur rückwärts aus dem gekauften Produkt abgeleitet.

Lock-in nur über Vertragslaufzeit bewerten

Technischer Lock-in ist oft schwieriger zu lösen als ein Vertrag.

Demo-Speed mit Production Readiness verwechseln

Eine Plattform kann eine Demo in Tagen ermöglichen und trotzdem bei ACLs, Regressionstests, Updates oder Betriebsverantwortung später Probleme erzeugen.

Ein pragmatischer Entscheidungsprozess

Schritt 1 – Business Task definieren

Nicht „wir brauchen eine RAG-Plattform“, sondern beispielsweise:

„Support-Mitarbeiter sollen freigegebene technische Dokumentation zuverlässig mit Quellen durchsuchen können.“

Schritt 2 – kritische Architekturtreiber bestimmen

• Daten,
• Rechte,
• Aktualität,
• Integrationen,
• Hosting,
• Modellanforderungen,
• Latenz,
• Qualität.

Schritt 3 – Layer Ownership festlegen

Für jede Schicht:

Own / Configure / Buy / Partner

Schritt 4 – 2–3 Optionen gegen dieselben Testfälle prüfen

Nicht Featurelisten vergleichen, sondern reale Aufgaben.

Schritt 5 – Exit-Fähigkeit prüfen

Was passiert, wenn Anbieter, Modell oder Search Layer gewechselt werden?

Nächster Schritt

Wenn Sie vor einer RAG-Plattformentscheidung stehen, würde ich nicht mit einer Anbieter-Shortlist beginnen.

Zuerst sollte feststehen:

• welche Layer strategisch kontrolliert werden müssen,
• welche austauschbar sind,
• welche Anforderungen wirklich kaufentscheidend sind.

Dafür ist KI-Beratung & AI Solution Architecture der passende Einstieg.

Wenn die Architektur bereits entschieden ist und Datenquellen, Retrieval und Integrationen umgesetzt werden sollen, geht es weiter mit RAG-Implementierung & KI-Integration.