Enterprise RAG: kaufen, bauen oder hybrid?

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

Nicht die Plattform ist die Entscheidungseinheit, sondern die Schicht. Entscheidend ist, was ein Unternehmen selbst besitzen, gezielt bauen, konfigurieren, einkaufen oder austauschbar halten muss.

Ein RAG-System verbindet Datenquellen, Parsing, Berechtigungen, Retrieval, Modelle, Evaluation und eine Anwendung. Diese Teile haben nicht dasselbe Risiko und schaffen nicht denselben Geschäftswert. Eine Plattform kann vieles beschleunigen. Sie sollte aber nicht unbemerkt Datenlogik, Rechte oder Qualitätsmaßstäbe übernehmen.

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

Die Architecture View

Business-Logik, Berechtigungsmodell und Evaluation sollten dem Unternehmen gehören. Sie entscheiden, welche Antworten im jeweiligen Prozess zulässig und nützlich sind.

Commodity-Infrastruktur muss dagegen nicht selbst entwickelt werden. Search, Observability, Standard-Connectoren oder Modellzugang können konfiguriert, eingekauft oder gemanagt werden. Die Architektur muss nur sicherstellen, dass sie wirklich austauschbar bleiben: mit portablen Daten, nachvollziehbaren Verträgen und eigenen Qualitätsprüfungen.

Ownership im Enterprise-RAG-System

• App- & Integrationsgrenze

  UI, Use Case, Freigaben, APIs und Fachlogik in bestehenden Systemen nicht an die Plattform koppeln

  Eigene Verantwortung

• Daten-Lifecycle & abgeleitete Verarbeitung

  Source IDs, Updates, Deletes und Archive führen; Parsing, Chunking und Indexing reproduzierbar und austauschbar halten

  Fachlich besitzen, Pipeline austauschbar halten

• Berechtigungsmodell

  ACLs, Rollen, Mandanten und Security Trimming aus den führenden Systemen

  Eigene Verantwortung

• Evaluation

  Golden Dataset, Rechtefälle, No-Answer-Fälle und Release-Gates

  Gezielt aufbauen

• Connectoren

  Standard-Connector konfigurieren; kritische Spezialintegration gezielt bauen

  Konfigurieren oder bauen

• Retrieval & Search

  Index, Filter, Hybrid Search und Reranking passend zum Use Case betreiben

  Managed oder OSS

• Operations & Observability

  Monitoring, Updates, Backups, Recovery, Skalierung und Runbooks bewusst kaufen, teilen oder selbst tragen

  Geteilte Betriebsverantwortung festlegen

• Foundation Model

  Modellzugang hinter einer klaren Grenze halten und vergleichbar machen

  Austauschbar

Warum die binäre Frage in die Irre führt

„Buy“ kann ein fertiges Produkt, einen Managed Service oder nur einen Connector bedeuten. „Build“ kann eine eigene Orchestrierungsschicht meinen, ohne eine Vector Database oder ein Modell selbst zu entwickeln. Beides wird unklar, sobald die Architektur nicht in Schichten zerlegt wird.

Eine tragfähige Entscheidung beantwortet für jede Schicht drei Fragen:

1. Ist sie spezifisch für unsere Daten, Prozesse oder Rechte?
2. Wie teuer wäre es, die Kontrolle darüber zu verlieren?
3. Können wir sie in zwei Jahren realistisch ersetzen oder betreiben?

Wenn die Antwort auf die ersten beiden Fragen „hoch“ ist, gehört die Verantwortung nicht in eine undurchsichtige Plattformkonfiguration.

Konkretes Enterprise-Szenario

Ein Support-Team soll in einer bestehenden Service-Anwendung freigegebene technische Dokumentation aus SharePoint und einem DMS mit Quellen durchsuchen. Die Antwort darf nur Dokumente berücksichtigen, die der jeweilige Mitarbeiter sehen darf.

Der fachliche Teil ist nicht die Wahl einer Chat-Oberfläche. Er umfasst stabile Dokument-IDs, Delta-Synchronisierung, Löschungen, Gruppen und ACLs, Quellennachweise sowie Testfragen aus echten Supportfällen. Diese Regeln und das Golden Dataset sollten beim Unternehmen liegen.

Für SharePoint oder das DMS kann ein Standard-Connector sinnvoll sein. Vor dem Kauf muss aber geklärt werden, ob er Rechte, Versionen und Löschungen korrekt abbildet. Wenn nicht, ist ein eigener Integrationsadapter oft kleiner und sicherer als ein späterer Plattformwechsel. Mehr dazu: RAG-Datenquellen anbinden und RAG-Berechtigungen & Security Trimming.

Die Search-Infrastruktur kann ein Managed Service oder betriebenes Open Source sein. Das Modell kann von einem Provider kommen oder privat laufen. Beides ist vertretbar, solange die Anwendung weder ACL-Logik noch Evaluationsdaten in ein proprietäres Format einsperrt.

Wo der Workload läuft und wer Infrastruktur oder Modellruntime betreibt, ist die vorgelagerte Entscheidung aus Private AI vs. Public Cloud. Hier geht es darum, die Ownership innerhalb des RAG-Systems passend zu verteilen.

Die Entscheidungslogik

Beginnen Sie nicht mit einer Anbieter-Shortlist. Beschreiben Sie zuerst eine reale Aufgabe, ihre Datenquellen, Rechte, Aktualität und den Schaden einer falschen Antwort. Legen Sie dann die Ownership pro Schicht fest und prüfen Sie zwei oder drei Optionen gegen dieselben Testfälle.

Eine Plattform gewinnt nicht, weil ihre Feature-Liste länger ist. Sie gewinnt, wenn sie den definierten Prozess mit den korrekten Quellen, Rechten, Kosten und Betriebsgrenzen zuverlässig erfüllt.

Eine Komponente ist nur dann austauschbar, wenn Daten, Konfiguration und Qualitätsnachweise den Anbieter überleben. Dazu gehören mindestens Originaldaten, Dokument-IDs und Metadaten, ACL-Mapping, Golden Dataset, Evaluationsresultate sowie API- und Integrationsverträge.

Layer-Entscheidungen sichtbar dokumentieren

Für jede relevante Capability genügt ein kurzes Decision Memo. Es ersetzt keine Scorecard, macht Ownership und Exit aber überprüfbar. Hybrid ist nur dann strategisch sauber, wenn Ownership und Exit nicht implizit bleiben.

Nach der Entscheidung muss die konkrete Architektur vor dem Go-live noch auf Daten, Identity, Security, Evaluation, Failure Modes, Kosten und Betrieb geprüft werden. Dafür dient die KI-Architektur-Checkliste für Unternehmen.

Wann Build sinnvoll ist

Build ist sinnvoll, wenn die RAG-Schicht selbst einen Unterschied im Produkt oder Prozess macht: etwa bei ungewöhnlichen Datenmodellen, komplexen Berechtigungen, kritischen Spezialintegrationen oder einer proprietären Workflow-Logik.

Das bedeutet nicht, Infrastruktur neu zu erfinden. Ein schlankes Build kann eine eigene API- und Orchestrierungsschicht, ein verlässliches Permission Mapping und eine eigene Evaluation über gekaufter Search- und Modellinfrastruktur sein.

Wann Buy sinnvoll ist

Buy ist sinnvoll, wenn Time-to-Value zählt, Standarddatenquellen dominieren und das Team Betrieb, Updates oder Commodity-Funktionen nicht selbst tragen soll.

Die Prüfung gilt trotzdem: Kann die Lösung Rechte korrekt darstellen? Sind Quellen, Export und Schnittstellen transparent? Lässt sich der Modellzugang wechseln? Eine schnelle Demo ist kein Beleg für Production Readiness.

Warum Hybrid meist der bessere Default ist

Hybrid trennt fachliche Kontrolle von Commodity-Infrastruktur. Das Unternehmen besitzt den Prozess, die Berechtigungsregeln und die Definition von Qualität. Es kombiniert sie mit Komponenten, die operativ sinnvoll eingekauft, gemanagt oder selbst betrieben werden.

Das reduziert nicht jede Abhängigkeit. Es macht Abhängigkeiten sichtbar und begrenzt sie auf Schichten, deren Austausch wirtschaftlich vertretbar ist.

Konkrete Empfehlung

Für die meisten Enterprise-RAG-Initiativen ist eine eigene, schlanke Verantwortungsgrenze sinnvoll: Die bestehende Anwendung und ihre Business-Logik bleiben führend. Rechte werden aus den Quellsystemen abgeleitet und vor dem Retrieval durchgesetzt. Evaluation läuft unabhängig von Modell und Search-Anbieter. Connector, Search, Observability und Modellzugang werden danach nach Betriebs- und Kostenanforderungen gewählt.

So entsteht keine künstliche „Build oder Buy“-Entscheidung, sondern eine Architektur, die auf reale Daten, Risiken und Wechselkosten reagiert. Wie Qualität unabhängig geprüft wird, zeigt RAG Evaluation: Metriken, Golden Dataset & Regression Tests.

Wenn Sie vor einer RAG-Plattformentscheidung stehen, ist KI-Beratung & AI Solution Architecture der passende Einstieg. Wenn die Architektur steht und Datenquellen, Retrieval und Integrationen umgesetzt werden sollen, geht es weiter mit RAG-Implementierung & KI-Integration.