Wissen · Aktualisiert: 4. Juni 2026
RAG on-premise betreiben
Für sensible Daten und regulierte Branchen kann es sinnvoll sein, ein RAG-System vollständig in der eigenen Infrastruktur zu betreiben. Dieser Beitrag zeigt, wann sich On-Premise lohnt, welche Open-Weight-Modelle infrage kommen und welche Hardware-Realität dahintersteckt.
Von Slava Spitsyn · AI Builder · Redaktionelle Grundsätze (englisch)
Ein RAG-System on-premise zu betreiben bedeutet, alle Stufen — Vektor-Store, Embeddings und Sprachmodell — in der eigenen Infrastruktur laufen zu lassen, sodass keine Inhalte an externe Dienste abfließen. Für Organisationen mit besonders sensiblen Daten oder strengen regulatorischen Vorgaben ist das oft der entscheidende Schritt, um KI überhaupt einsetzen zu können. Für andere ist es Aufwand, der sich nicht zwingend lohnt. Dieser Beitrag hilft bei der ehrlichen Abwägung.
Wie sich der Datenfluss bei eigenen Daten grundsätzlich gestalten lässt, vertieft der Beitrag RAG mit eigenen Daten — datenschutzbewusst umgesetzt. Hier geht es um den vollständig lokalen Betrieb. Den Gesamtüberblick liefert der Leitfaden RAG für Unternehmenswissen.
Wann On-Premise sinnvoll ist
Ein lokal betriebenes RAG-System spielt seine Stärke dort aus, wo Datenhoheit nicht verhandelbar ist:
- Besonders sensible Daten. Patientendaten, Mandatsinformationen, Geschäftsgeheimnisse oder personenbezogene Daten in größerem Umfang — Inhalte, die das eigene Haus nach Möglichkeit nicht verlassen sollen.
- Regulierte Branchen. Im Gesundheitswesen, bei Finanzdienstleistern oder in der öffentlichen Verwaltung können Vorgaben die Verarbeitung in der eigenen Infrastruktur nahelegen.
- Maximale Kontrolle. Wer jede Station des Datenflusses selbst betreibt, weiß genau, wo welche Information liegt — ohne sich auf die Zusagen externer Dienste verlassen zu müssen.
Der Gewinn ist klar: Inhalte verlassen die eigene Umgebung nicht. Der Preis ebenso: Sie übernehmen Betrieb, Wartung, Updates und die Hardware-Verantwortung selbst.
Open-Weight-Modelle und Ollama
Lokaler Betrieb ist möglich, weil es leistungsfähige Open-Weight-Modelle gibt — Modelle, deren Gewichte frei verfügbar sind und die Sie auf eigener Hardware ausführen dürfen. Bekannte Familien sind Llama, Mistral und Qwen. Sie decken ein breites Spektrum von kompakten bis zu großen Modellen ab.
Für den praktischen Einstieg hat sich Ollama etabliert — ein Werkzeug, das Open-Weight-Modelle vergleichsweise unkompliziert lokal lauffähig macht. Damit lässt sich auf eigener Hardware ein Sprachmodell betreiben, das die Generierungsstufe eines RAG-Systems übernimmt, ohne dass Anfragen das Haus verlassen. Auch die Embeddings lassen sich lokal erzeugen, sodass der gesamte Datenfluss in der eigenen Infrastruktur bleibt.
Welches Modell passt, ist eine Abwägung aus Sprachqualität — gerade für Deutsch relevant —, Modellgröße und verfügbarer Hardware. Diese Wahl gehört an den konkreten Anwendungsfall, nicht an eine pauschale Empfehlung.
Die Hardware- und Kosten-Realität — ehrlich
Hier lohnt Klartext statt Marketing: Lokaler Betrieb verlagert Kosten, er beseitigt sie nicht. Statt Nutzungsgebühren an einen externen Anbieter tragen Sie Hardware, Strom, Betrieb und Wartung.
Wie viel Hardware nötig ist, hängt vor allem von der Modellgröße ab:
- Kleinere Modelle laufen auf vergleichsweise moderater Hardware und können für viele Aufgaben bereits ausreichen.
- Größere Modelle verlangen deutlich mehr Arbeitsspeicher und in der Regel eine leistungsfähige GPU — was Anschaffung und Betrieb spürbar verteuert.
Konkrete Eurozahlen wären an dieser Stelle unseriös, weil sie von Modell, Last, gewünschter Antwortgeschwindigkeit und vorhandener Infrastruktur abhängen. Die ehrliche Orientierung lautet: Größere, qualitativ stärkere Modelle bedeuten höhere Hardware-Anforderungen — und diese Kurve steigt steil. Wer lokal startet, sollte mit einem realistischen Anwendungsfall und einem passend dimensionierten Modell beginnen, statt das größte verfügbare Modell anzustreben.
On-Premise oder EU-Cloud? Der Trade-off
Zwischen vollständigem On-Premise-Betrieb und der Nutzung externer Dienste liegt ein wichtiger Mittelweg: die EU-Cloud. Hosting, Datenbank und Modell laufen dabei in EU-Infrastruktur, ohne dass Sie die Hardware selbst betreiben.
Die Abwägung lässt sich an drei Fragen festmachen:
- Datenhoheit: On-Premise bietet die maximale Kontrolle, weil Inhalte das eigene Haus nicht verlassen. Eine EU-Cloud reduziert das Datenabfluss-Risiko ebenfalls deutlich, verlagert aber den Betrieb zu einem Anbieter.
- Aufwand: On-Premise bedeutet eigene Verantwortung für Hardware, Updates und Verfügbarkeit. Eine EU-Cloud nimmt Ihnen diesen Betrieb ab.
- Kosten: On-Premise bindet Kapital in Hardware, eine Cloud verteilt Kosten über die Nutzung. Was günstiger ist, hängt von Last und Zeithorizont ab.
Für viele Organisationen ist die EU-Cloud der pragmatische Kompromiss: spürbar reduziertes Datenabfluss-Risiko ohne den vollen Betriebsaufwand. Wo regulatorische Vorgaben oder die Sensibilität der Daten den vollständig lokalen Betrieb verlangen, führt der Weg zu On-Premise.
Eine wichtige Einordnung gilt für beide Wege: Sie reduzieren Risiken auf technischer Ebene, ersetzen aber keine rechtliche Prüfung des Gesamtkonzepts.
Fazit
On-Premise-RAG ist kein Selbstzweck, sondern eine Antwort auf konkrete Anforderungen: maximale Datenhoheit für sensible Daten und regulierte Branchen. Open-Weight-Modelle aus den Familien Llama, Mistral oder Qwen machen den lokalen Betrieb mit Werkzeugen wie Ollama zugänglich — zum Preis von Hardware und Betriebsverantwortung, die ehrlich eingeplant werden müssen. Wo diese Anforderungen weniger streng sind, ist die EU-Cloud oft der bessere Kompromiss. Entscheidend ist, den Weg an den tatsächlichen Schutzbedarf zu knüpfen — nicht an das technisch Maximale.