Open Source, kein Kompromiss — eine produktionsreife RAG-Plattform für die JEN
Über Beyonder
Beyonder ist ein 2010 in Köln gegründetes Full-Stack-Softwarehaus mit 85 Mitarbeitenden. Das Unternehmen entwickelt seit über einem Jahrzehnt maßgeschneiderte digitale Produkte und Plattformen — von datenintensiven Backend-Systemen über moderne Webanwendungen bis hin zu KI-gestützten Lösungen. In den vergangenen Jahren hat Beyonder einen klaren Schwerpunkt auf den Aufbau und Betrieb von KI-Systemen gelegt, insbesondere auf Retrieval-Augmented Generation (RAG), Large Language Models und semantische Suche.
Als Beleg für diese Kompetenz steht das L.O.Systems Portal, das Beyonder von Juli 2025 bis Januar 2026 für die L.O.S. Dienstleistungen GmbH (LOS) konzipiert und umgesetzt hat. Dabei handelt es sich um ein individuelles Dokumenten-managementsystem für die Landwirtschaft mit einem integrierten KI-RAG-System auf Basis von über einer Million Dokumenten — betrieben vollständig in Deutschland.
Seit dem Go-live im Januar 2026 verantwortet Beyonder den laufenden Betrieb und die Weiterentwicklung der Plattform. Das Projekt belegt die Fähigkeit des Teams, RAG-Architekturen in Produktionsqualität zu liefern und zu betreiben. Für die JEN wird dieselbe Architekturkompetenz in eine vollständig On-Premises-Umgebung übertragen — ohne Abhängigkeit von Cloud-Diensten.
Die Lösung auf einen Blick
Beyonder bietet der JEN eine modulare, vollständig lokal betreibbare RAG-Plattform unter dem Arbeitstitel „Sicherer Chat mit Dokumenten". Die Plattform ermöglicht es Mitarbeitenden, in natürlicher Sprache Fragen an den gesamten internen Wissensbestand der JEN zu stellen — und erhält als Antwort präzise, quellenbasierte Informationen aus den angebundenen Dokumentensystemen.
Die Lösung basiert ausschließlich auf etablierten Open-Source-Komponenten mit permissiven Lizenzen (Apache 2.0, MIT). Alle Verarbeitungsstufen — Dokumentenextraktion, Embedding, semantische Suche und Antwortgenerierung durch ein Large Language Model — laufen innerhalb der JEN-Infrastruktur. Es findet kein Datenabfluss an externe Cloud-Dienste statt.
Der Einstieg erfolgt über einen schlanken Pilot in wenigen Wochen, der mit zwei Datenquellen und einem kleinen Nutzerkreis von 10 bis 20 Personen startet. Der Pilot umfasst Phase 1 (~10–11 Wochen Meilenstein) und Phase 2 (+~7–8 Wochen Abschluss). Darauf aufbauend erweitert sich die Plattform in klar definierten Stufen bis zum Vollausbau mit 350 Nutzerinnen und Nutzern und dem gesamten Datenbestand der JEN.
Kernnutzen für die JEN
Die JEN verfügt über einen gewachsenen, heterogenen Wissensbestand aus mehr als fünf Jahrzehnten kerntechnischer Arbeit — verteilt über SharePoint, Fileshares, DMS-Systeme, Intranet und Datenbanken. Dieser Wissensbestand ist für Mitarbeitende heute nur schwer gezielt erschließbar: Relevante Dokumente müssen manuell gesucht, gefunden und ausgewertet werden — ein erheblicher Zeitaufwand, der insbesondere bei fachlichen Rechercheaufgaben und im Tagesgeschäft zu Buche schlägt.
Die RAG-Plattform von Beyonder adressiert genau diesen Engpass. Mitarbeitende stellen ihre Frage einmal — die Plattform durchsucht automatisch alle angebundenen, berechtigten Quellen, synthetisiert die relevanten Informationen und liefert eine nachvollziehbare Antwort mit direkten Quellenverweisen. Das spart Recherchezeit, reduziert Wissensverluste durch Fluktuation und macht das institutionelle Gedächtnis der JEN aktiv nutzbar.
Da die Plattform die bestehenden Active-Directory-Berechtigungen vollständig durchsetzt, erhalten Mitarbeitende ausschließlich Antworten auf Basis von Dokumenten, auf die sie ohnehin Zugriff haben. Datenschutz und Informationssicherheit sind damit strukturell verankert — nicht als nachgelagerte Maßnahme, sondern als integraler Bestandteil der Architektur.
Leitprinzipien
Die Plattform folgt vier Leitprinzipien, die alle Architektur- und Technologieentscheidungen prägen.
Datensouveränität: Sämtliche Verarbeitungsschritte — Dokumentenextraktion, Texterkennung, Embedding, semantische Suche und Antwortgenerierung — laufen ausschließlich innerhalb der JEN-Infrastruktur. Keine externen APIs, keine Cloud-Dienste, keine Modellanbieter von außen. Unternehmensdaten verlassen zu keinem Zeitpunkt das eigene Netz.
Open Source ohne Vendor-Lock-in: Alle Komponenten stehen unter permissiven Open-Source-Lizenzen (Apache 2.0 oder MIT). Es entstehen keine Lizenzkosten und keine Herstellerabhängigkeit. Jede Komponente — Sprachmodell, Embedding-Modell, Vektordatenbank, Dokumentenverarbeitungs-Framework — kann unabhängig ausgetauscht werden, ohne die Gesamtarchitektur zu verändern.
Modularität: Die Plattform ist in klar abgegrenzte Schichten und Services unterteilt, die über standardisierte Schnittstellen (REST/OpenAPI) kommunizieren. Neue Datenquellen, Nutzergruppen oder Use Cases lassen sich hinzufügen, ohne bestehende Teile anzufassen.
Kubernetes-native Betreibbarkeit: Das gesamte Deployment erfolgt über Helm-Charts. Updates, Skalierung und Rollbacks sind reproduzierbar und durch Eigenpersonal der JEN beherrschbar — ohne dauerhaftes Plattform-Know-how eines Dienstleisters.
Architekturüberblick und Komponenten
Die Plattform gliedert sich in fünf logische Schichten. Die Ingestion-Schicht verbindet die Quellsysteme über dedizierte Konnektoren; Dokumente werden extrahiert, per OCR aufbereitet, dedupliziert und in semantische Chunks zerlegt. Die Index- und Speicherschicht hält Vektoren, Metadaten und Zugriffsberechtigungen vor. Der RAG-Service orchestriert Suche, Reranking und Antwortgenerierung. Die Zugangsschicht stellt das Chat-Frontend bereit und bindet Active Directory an. Die Observability-Schicht überwacht alle Komponenten über einen einheitlichen Monitoring-Stack.
Die zentralen Komponenten: Kubernetes mit GitLab CI/CD für Deployment und Skalierung; vLLM mit Gemma 4 26B A4B (Apache 2.0) für die Antwortgenerierung; Microsoft Harrier-OSS-v1-0.6b (MIT) als Embedding-Modell; Qdrant (Apache 2.0) für semantische und klassische Suche; Unstructured.io und Apache Tika (Apache 2.0) für Parsing, OCR und Chunking; LlamaIndex (MIT) für Retrieval, Reranking und Quellenreferenzen; Keycloak (Apache 2.0) für SSO und AD-Federation; FastAPI (MIT) als API-Gateway; Nuxt 3 (MIT) als Chat-Oberfläche; Prometheus, Grafana und Loki (Apache 2.0) für Observability.
Datenfluss: Ingestion und Query
Ingestion (asynchron, kontinuierlich): Ein Konnektor liest Dokumente, Metadaten und Zugriffsberechtigungen aus dem Quellsystem. Unstructured.io und Apache Tika extrahieren Textinhalte, erkennen Tabellen und führen bei gescannten Dokumenten eine OCR durch. Ein Deduplizierungs-Schritt prüft anhand von Inhalts-Hashes, ob ein Dokument neu oder verändert ist. Neue Dokumente werden in semantische Chunks zerlegt, in Vektoren überführt und gemeinsam mit den Berechtigungsinformationen in Qdrant geschrieben.
Query (synchron, interaktiv): Eine Nutzeranfrage wird zusammen mit dem Authentifizierungs-Token ans Backend übergeben. Dieses validiert den Token, ermittelt AD-Gruppenzugehörigkeiten und überführt die Frage in einen Vektor. Qdrant durchsucht den Index per Hybrid Search und filtert strikt auf Dokumente, auf die der Nutzer berechtigt ist. Die priorisierten Treffer werden an das Sprachmodell übergeben, das eine kohärente Antwort mit direkten Quellenverweisen formuliert.
Reifegrad der eingesetzten Komponenten
Die Lösung ist kein Prototyp. Alle Kernkomponenten — vLLM, Qdrant, LlamaIndex, Keycloak, Unstructured.io — sind etablierte Open-Source-Projekte mit aktiven Communities, stabilen Release-Zyklen und nachgewiesener Produktionstauglichkeit.
Die Beyonder-Eigenleistung liegt in der Integration zu einer kohärenten Gesamtlösung: Entwicklung der Konnektoren für die JEN-spezifischen Quellsysteme, Konfiguration der RAG-Pipeline auf die Nukleardomäne, Aufbau des CI/CD-Deployments und Design des Chat-Frontends. Genau hier bringt Beyonder nachgewiesene Erfahrung aus produktiven Systemen ein.
Datensicherheit und Berechtigungskonzept
Die besondere Sensibilität der JEN-Dokumentenbestände — technische Unterlagen aus dem Rückbau kerntechnischer Anlagen, interne Prozessdokumentationen, behördliche Schriftwechsel — stellt hohe Anforderungen an Datensicherheit und Zugriffssteuerung.
Die Authentifizierung erfolgt über Single Sign-On via Keycloak, das direkt mit dem Active Directory der JEN föderiert ist. Mitarbeitende melden sich mit ihren gewohnten Windows-Zugangsdaten an. Die AD-Gruppenzugehörigkeiten werden zur Laufzeit ausgelesen und als JWT-Token an jede Anfrage angehängt.
Die Berechtigungsdurchsetzung findet auf Ebene der Vektordatenbank statt: Jeder indexierte Dokumenten-Chunk trägt die Zugriffsrechte des Quelldokuments als Metadaten-Payload. Bei jeder Suchanfrage filtert Qdrant strukturell auf Chunks, die der anfragende Nutzer sehen darf — bevor ein Ergebnis an das Sprachmodell übergeben wird. Es ist architektonisch ausgeschlossen, dass ein Nutzer Antworten erhält, die auf Dokumenten basieren, auf die er keinen Zugriff hat. Ändert sich eine Berechtigung im Active Directory, wirkt diese Änderung bei der nächsten Anfrage sofort. Alle Nutzeranfragen, Suchergebnisse und Antworten werden vollständig in PostgreSQL protokolliert und stehen für Audits zur Verfügung.
Alle Open-Source-Komponenten werden mit deaktivierter externer Telemetrie betrieben. Modell-Artefakte werden einmalig gespiegelt und ausschließlich aus der internen Container-Registry bezogen. Nach Go-live ist kein ausgehender Netzwerkverkehr zu externen Diensten erforderlich; im Kubernetes-Cluster greifen strikte Egress-Network-Policies (Default-Deny).
Umgang mit der Dokumentenlandschaft der JEN
Die JEN verfügt über einen Datenbestand, der zu den anspruchsvollsten Szenarien für dokumentenbasierte KI-Systeme gehört: bis zu 900 Seiten starke Dokumente, hohe Versionierungs- und Dublettenanteile, gescannte Altbestände, technische Zeichnungen sowie Inhalte aus sechs strukturell unterschiedlichen Quellsystemen.
Für jedes Quellsystem — SharePoint Online, SMB-Fileshares, nscale, windream, Intranet/Wiki und MS SQL Server — wird ein dedizierter Konnektor entwickelt, der Dokumente, Metadaten und Berechtigungen vollständig und inkrementell ausliest. Nur geänderte oder neue Dokumente durchlaufen die Verarbeitungspipeline.
Unstructured.io und Apache Tika übernehmen die Dokumentenverarbeitung gemeinsam: textbasierte PDFs und Office-Dokumente werden direkt geparst, gescannte Dokumente durchlaufen eine OCR-Pipeline, Tabellen werden strukturerhaltend extrahiert. Ein zweistufiger Deduplizierungsmechanismus — Content-Hash für identische Inhalte, SimHash für nahezu identische Versionen — verhindert, dass Dubletten und Dokumentversionen den Index verfälschen. Chunk-Größen und Überlappungen sind je Dokumenttyp konfigurierbar.
Antwortqualität in der Nuklearfachdomäne
Die Qualität der Antworten ist der entscheidende Akzeptanzfaktor — und zugleich die größte Herausforderung in einer Fachdomäne mit spezialisiertem Vokabular und hohen Präzisionsanforderungen.
Die LlamaIndex CitationQueryEngine liefert zu jeder Antwort direkte Quellenverweise, sodass Mitarbeitende jede Aussage sofort nachvollziehen können. Ist die Quellenlage unzureichend, gibt die Plattform dies transparent aus, anstatt eine spekulative Antwort zu formulieren.
Die Primärsprache Deutsch ist explizites Auswahlkriterium bei der Modellwahl. Das Embedding-Modell Microsoft Harrier-OSS-v1-0.6b belegt auf dem Multilingual MTEB v2-Benchmark führende Positionen für deutschsprachige Retrieval-Aufgaben und unterstützt Sequenzlängen von bis zu 32.768 Tokens. Der Reranker BAAI BGE-Reranker-v2-m3 ist multilingual mit starken Ergebnissen auf deutschen Texten. Gemma 4 26B A4B produziert stabile, grammatisch korrekte Antworten auf Deutsch.
Da Nuklear-Fachvokabular in allgemeinen Trainingskorpora unterrepräsentiert ist, wird im Pilotbetrieb anhand eines Goldsets mit JEN-spezifischen Testfragen systematisch evaluiert. Der System-Prompt wird mit Few-Shot-Beispielen und expliziten Anweisungen zu Fachbegriffen, Normen und Dokumenttypen auf den JEN-Kontext ausgerichtet. Als optionaler Ausbaupfad ist eine domänenspezifische Feinabstimmung des Embedding- und Sprachmodells auf JEN-Terminologie vorgesehen.
Nutzerfreundlichkeit
Die Plattform stellt ein modernes Chat-Interface bereit, das sich an bekannten KI-Assistenten orientiert und keine Einarbeitungszeit erfordert. Mitarbeitende formulieren ihre Frage in natürlicher Sprache — die gesamte Komplexität der Suche und Antwortgenerierung läuft im Hintergrund.
Quellenangaben erscheinen direkt unterhalb jeder Antwort als anklickbare Verweise auf das Originaldokument. Folgefragen im selben Gesprächskontext sind möglich, ohne dass der Nutzer seine Frage wiederholen muss. Der Zugang erfolgt per Single Sign-On mit den bestehenden Windows-Zugangsdaten.
Anforderungsabdeckung im Überblick
Alle funktionalen und nicht-funktionalen Anforderungen aus der Challenge-Ausschreibung werden durch die vorgeschlagene Lösung abgedeckt. Der Erfüllungsstand unterscheidet drei Stufen: Standard bedeutet, die Anforderung wird durch die eingesetzten Komponenten ohne projektspezifische Anpassung erfüllt. Projektkonfiguration bedeutet, die technische Basis ist vorhanden, erfordert aber eine projektspezifische Einrichtung. Im Pilot zu validieren bedeutet, die praktische Umsetzbarkeit hängt von Gegebenheiten ab, die erst im Betrieb vollständig geprüft werden können.
Als Standard erfüllt sind: lokaler Betrieb aller RAG-Verarbeitungsstufen, ausschließlich lokal betriebene Modelle (LLM, Embedding, OCR), AD-gestützte Berechtigungen, semantische Suche, klassische Stichwortsuche (BM25), Hybrid Retrieval, quellenbasierte Antworten mit Referenzen, Verarbeitung textbasierter und gescannter PDFs sowie Office-Dokumente, Versionierung, Dublettenbehandlung, vollständige Protokollierung und Audit-Trail, Monitoring, modulare Architektur sowie Skalierbarkeit für wachsende Datenmengen.
Per Projektkonfiguration werden abgedeckt: Anbindung SharePoint Online, SMB-Fileshares, Intranet/Wiki und MS SQL Server, transparenter Umgang bei unzureichender Quellenlage, Verarbeitung von Tabellen und Bildern, inkrementelle Aktualisierung sowie das Skalierungsziel von 350 Nutzenden und 30 gleichzeitigen Anfragen im Vollausbau.
Im Pilot zu validieren sind die Anbindungen von nscale und windream, da deren API-Dokumentation und Schnittstellenreife erst in der praktischen Integration abschließend bewertet werden können.
Ausbaustufen
Die Plattform wird in vier aufeinander aufbauenden Phasen eingeführt, die jeweils eigenständigen Mehrwert liefern.
Pilot Phase 1 (~10–11 Wochen) legt die vollständige technische Basis: Kubernetes-Cluster, Core-RAG-Stack und die erste Datenquelle (SharePoint Online) werden produktionsbereit aufgesetzt, AD-SSO ist von Anfang an aktiv. Am Ende können erste Pilotnutzende Fragen stellen und erhalten quellenbasierte Antworten.
Pilot Phase 2 (+~7–8 Wochen) vervollständigt den Pilotumfang: Die zweite Datenquelle (SMB-Fileshare) wird angebunden, OCR-Qualität geprüft, das ACL-Berechtigungskonzept gehärtet sowie Audit-Log, CI/CD-Pipeline und Monitoring produktionsreif abgeschlossen. 10 bis 20 Pilotnutzende geben strukturiertes Feedback.
MVP (+~8 Wochen) bindet die verbleibenden Quellen — nscale, windream, Intranet/Wiki — an und aktiviert inkrementellen Sync, Versionsverfolgung und Dublettenbehandlung. Der Nutzerkreis wächst auf rund 100 Personen, der Datenbestand auf bis zu 20 TB.
V1 / Vollausbau (+~7 Wochen) schließt die SQL-Anbindung ab, ergänzt Tabellen- und Bildverarbeitung und aktiviert die vollständige klassische Suche. Die Plattform ist für alle 350 Mitarbeitenden zugänglich und deckt den Gesamtdatenbestand von 50 TB ab.
Optionale Erweiterungen
Über den Pflichtumfang hinaus sind folgende Erweiterungen modular realisierbar: Hochverfügbarkeit und Multi-Site-Betrieb mit automatischem Failover über zwei Standorte; multimodale Eingabe, die die native Vision-Fähigkeit von Gemma 4 nutzt, um technische Zeichnungen und Grafiken inhaltlich erschließbar zu machen; Agentic Workflows, die der Plattform erlauben, nicht nur Informationen zu liefern, sondern auch Aktionen anzustoßen (Tickets, Benachrichtigungen, Genehmigungsprozesse); Domain-Adaptation durch Feinabstimmung des Sprachmodells auf JEN-spezifisches Fachvokabular sowie ein strukturierter Qualitätszyklus mit Goldset und A/B-Testing zur kontinuierlichen Bewertung von Modell- und Prompt-Änderungen.
Risiken und Mitigationen
Die wesentlichen Risiken und ihre Gegenmaßnahmen im Überblick: Das größte inhaltliche Risiko ist eine unzureichende Antwortqualität in der Nuklearfachdomäne (Einschätzung: mittel/hoch); es wird durch Goldset-Evaluation im Pilot, Few-Shot-Prompting und ggf. Wechsel auf ein größeres Modell mitigiert. Unzureichende OCR-Qualität bei alten Scans (mittel/mittel) begegnet die Plattform durch kombinierbare OCR-Engines und Konfidenz-Tracking. Eingeschränkte oder unzureichend dokumentierte APIs von nscale oder windream (mittel/mittel) werden durch frühe technische Validierung als erstes Pilotkriterium adressiert, mit dateibasiertem Export als Fallback. Einem GPU-Engpass bei Spitzenlast (mittel/mittel) begegnet die Architektur mit Request-Queue, Backpressure und Auto-Scaling.
Das Risiko einer Modell-Lizenzänderung (niedrig/hoch) ist durch die unwiderruflichen Apache-2.0- und MIT-Lizenzen und die modulare Austauschbarkeit strukturell ausgeschlossen. Prompt Injection oder unbeabsichtigter Informationsabfluss (niedrig/hoch) wird durch Input-/Output-Filter, strikten ACL-Filter und vollständigen Audit-Trail verhindert. Sollte der Wartungsaufwand die Kapazitäten des JEN-Eigenpersonals übersteigen (mittel/mittel), greifen Helm-basiertes Update-Management, klare Betriebsdokumentation und ein Support-Vertrag mit Beyonder.
Pilotzuschnitt: Umfang, Dauer und Ziele
Der Pilot gliedert sich in zwei aufeinander aufbauende Phasen mit einem Gesamtumfang von 225 Story Points und einer Laufzeit von rund 18 Wochen.
Phase 1 (~10–11 Wochen) verfolgt ein klar umrissenes Ziel: Am Ende können erste Pilotnutzende der JEN die Plattform produktiv nutzen — sie melden sich per Windows-SSO an, stellen Fragen in natürlicher Sprache und erhalten quellenbasierte Antworten aus dem SharePoint-Bestand. Dafür wird die vollständige technische Basis aufgesetzt: Kubernetes-Cluster, Helm-Deployment, Core-RAG-Stack, SharePoint-Konnektor, Initial-Indexierung und AD-Authentifizierung.
Phase 2 (+~7–8 Wochen) vervollständigt den Pilotumfang: SMB-Fileshare-Anbindung, ACL-Härtung, OCR-Qualitätsprüfung, Aktivierung von Quellenreferenzen und Gesprächsverlauf sowie produktionsreifer Abschluss von CI/CD-Pipeline, Audit-Log und Monitoring. 10 bis 20 Pilotnutzende aus verschiedenen Fachbereichen erhalten vollständigen Zugang und geben strukturiertes Feedback.
Am Ende des Pilots liegen vor: ein produktiv betriebener RAG-Stack mit zwei angebundenen Quellen, eine Goldset-Auswertung zur Antwortqualität, ein Feedback-Bericht der Pilotnutzenden sowie ein Betriebsübergabe-Plan für den weiteren Ausbau.
Mitwirkungsaufwände der JEN
Der Erfolg des Pilots setzt eine strukturierte, aber bewusst schlank gehaltene Mitwirkung der JEN in drei Bereichen voraus.
Infrastruktur und Zugänge: Die JEN stellt einen GPU-fähigen Server sowie ein Kubernetes-Cluster oder eine geeignete VM-Basis bereit und richtet die erforderlichen Zugänge ein: SharePoint-API-Credentials (Microsoft Graph), SMB-Zugangsdaten sowie Lesezugriff auf das Active Directory für die Keycloak-Federation.
Fachliche Begleitung: Ein Fach-Champion mit breitem Überblick über die Dokumentenlandschaft begleitet die Qualitätsbewertung, wirkt am Aufbau des Goldsets mit und gibt Rückmeldung zum Prompt-Design. Ein Plattform-Administrator wird von Beyonder in den Betrieb eingeführt und übernimmt schrittweise die Routinetätigkeiten.
Testnutzende: 10 bis 20 Mitarbeitende aus verschiedenen Fachbereichen nutzen die Plattform im Tagesgeschäft und nehmen an ein bis zwei strukturierten Feedback-Runden teil.
Backup und Restore
Ein grundlegendes Backup-Konzept ist ab Pilot Phase 2 aktiv. Die Plattform sichert drei voneinander unabhängige Datenschichten: den Vektorindex in Qdrant über native Snapshots (täglich, 14 Tage Aufbewahrung), die Metadaten- und Audit-Datenbank in PostgreSQL über WAL-basierte Sicherung mit Point-in-Time-Recovery sowie die Originaldokumente im Object Storage (MinIO) über Bucket-Versionierung und tägliche Replikation. Eine vollständige Wiederherstellung wird am Ende von Pilot Phase 2 erprobt und dokumentiert.
Wichtig für die Risikobewertung: Der Vektorindex ist kein primärer Datenspeicher — alle Originaldokumente verbleiben in den Quellsystemen der JEN und ermöglichen im Extremfall einen vollständigen Neuaufbau des Index. Die Audit-Logs werden daher mit erhöhter Redundanz auf JEN-eigenem Storage abgelegt.
Betriebsmodell: Schrittweise Eigenverantwortung
Das Betriebsmodell folgt dem Prinzip der schrittweisen Eigenverantwortung. Im Pilot führt Beyonder den Betrieb und schult den JEN-Plattform-Administrator in alle Routinetätigkeiten ein. Ab MVP übernimmt die JEN die täglichen und wöchentlichen Aufgaben eigenständig — Monitoring-Check, Backup-Verifikation, Konnektor-Review; Beyonder steht im 2nd- und 3rd-Level-Support zur Verfügung und verantwortet quartalsweise Komponenten-Updates. Im Vollausbau ist die JEN vollständig eigenverantwortlich im Tagesbetrieb.
Die Rollenverteilung im Vollausbau: Der Plattform-Administrator (JEN) verantwortet K8s-Betrieb, Monitoring und Backup-Verifikation. Der Daten-Verantwortliche (JEN) konfiguriert Konnektoren und gibt Datenquellen frei. Der Fach-Champion (JEN) bewertet Antwortqualität und gibt Prompt-Feedback. Beyonder übernimmt 2nd-/3rd-Level-Support, Modell-Updates und Release-Management.
Hardware-Anforderungen im Pilot
Der Pilotbetrieb erfordert eine überschaubare, aber GPU-fähige Serverinfrastruktur. Die zentrale Anforderung ergibt sich aus dem LLM-Inferenz-Stack: Gemma 4 26B A4B ist ein Mixture-of-Experts-Modell, das trotz 26 Milliarden Gesamtparametern pro Inferenzschritt nur rund 4 Milliarden Parameter aktiviert und sich dadurch auf einer einzelnen NVIDIA A100 80 GB betreiben lässt — mit ausreichend Headroom für gleichzeitige Anfragen im Pilotbetrieb. Alternativ sind zwei NVIDIA RTX 4090 mit je 24 GB möglich.
Darüber hinaus werden benötigt: zwei Server-CPUs mit mindestens 32 Kernen gesamt für Ingestion, Qdrant, API und Frontend; 256 GB RAM für Vektordatenbank, Modell-Loading und Betriebssystem; 4 TB NVMe-Storage für Vektordatenbank, Modelle und OS; 10 TB Netzwerkspeicher für Originaldokumente (MinIO) und Backup; ein 3-Node-Kubernetes-Cluster (Control Plane, Worker, GPU-Node) sowie 10-GbE-Netzwerk für Ingestion-Throughput und Cluster-Kommunikation. Sofern bei der JEN bereits eine Kubernetes-Infrastruktur betrieben wird, kann der GPU-Node als dedizierter Worker integriert werden — eine eigenständige Kubernetes-Installation ist nicht zwingend erforderlich.
Skalierungspfad zum Vollausbau
Die Hardware-Anforderungen wachsen beim Übergang vom Pilot zum Vollausbau vor allem in zwei Dimensionen: Concurrency und Dokumentenmenge. Wichtig dabei: Qdrant skaliert nahezu linear mit der Dokumentenmenge ohne GPU-Anforderungen — der GPU-Bedarf wächst ausschließlich mit der Inferenz-Last.
Im Vollausbau (350 Nutzer, 50 TB) werden empfohlen: 4 GPUs auf zwei Servern (je 2× A100/H100 80 GB) für Concurrency und Redundanz; 512 GB RAM gesamt; 20 TB NVMe-Storage für den größeren Vektorindex; rund 100 TB Netzwerkspeicher für den vollständigen Dokumentenbestand; ein 3-Node-Qdrant-Cluster für Hochverfügbarkeit sowie 5 bis 7 Kubernetes-Nodes für separierte Workloads und Auto-Scaling.
Für ~30 gleichzeitige Anfragen empfiehlt sich der Ausbau auf mindestens 4 GPUs, um bei Spitzenlast eine Antwortzeit unter 10 Sekunden zu gewährleisten. Das finale GPU-Sizing sollte nach dem Pilotbetrieb auf Basis gemessener Lastprofile festgelegt werden.
Das engste Referenzprojekt für die JEN ist das L.O.Systems Portal, das Beyonder von Juli 2025 bis Januar 2026 für die L.O.S. Dienstleistungen GmbH konzipiert, entwickelt und in Betrieb genommen hat. Es handelt sich um ein individuelles Dokumentenmanagementsystem für die Landwirtschaft mit einem integrierten KI-RAG-System — betrieben vollständig in Deutschland, ohne Abhängigkeit von Cloud-Diensten.
Die Parallelen zur JEN-Anforderung sind direkt: Auch das L.O.Systems Portal musste einen gewachsenen, heterogenen Dokumentenbestand von über einer Million Dokumenten erschließbar machen, für den eine klassische Suche nicht ausreichte. Das Projekt belegt damit keine theoretische Konzeptkompetenz, sondern nachgewiesene Produktionstauglichkeit: Die Architektur hat den Go-live bestanden, wird aktiv genutzt und von Beyonder im laufenden Betrieb weiterentwickelt.
Architekturtransfer und übertragbare Erfahrungen
Beyonder ist seit über einem Jahrzehnt als Full-Stack-Softwarehaus tätig und hat in dieser Zeit eine Reihe datenintensiver Backend-Systeme und Plattformen für Unternehmen verschiedener Branchen entwickelt und betrieben. Die für die JEN relevante Erfahrungstiefe konzentriert sich dabei auf drei Bereiche:
Berechtigungsgesteuerte Informationssysteme: Mehrere Kundenprojekte haben Systeme erfordert, bei denen verschiedene Nutzergruppen auf denselben Datenbestand zugreifen, aber strukturell unterschiedliche Sichtbarkeiten erhalten. Die für die JEN vorgesehene ACL-Durchsetzung auf Ebene der Vektordatenbank wurde aus diesen Erfahrungen heraus konzipiert — sie ist kein Designansatz auf dem Reißbrett, sondern eine erprobte Architekturentscheidung.
Verarbeitung komplexer Dokumentenlandschaften: Die Erfahrung mit heterogenen Quelldaten — unterschiedliche Formate, Qualitätsniveaus, Versionsstände, gescannte Altbestände — ist in der Dokumentenverarbeitungs-Pipeline direkt eingeflossen. Die Kombination aus Unstructured.io und Apache Tika sowie das zweistufige Deduplizierungsverfahren entstammen konkreter Auseinandersetzung mit realen Datenqualitätsproblemen.
Übergabefähiger Betrieb: Beyonder hat wiederholt Systeme übergeben, die von kundenseitigem Personal ohne dauerhaften Dienstleister-Einsatz betrieben werden. Das daraus entwickelte Prinzip — vollständig deklaratives Helm-Deployment, klare Betriebsdokumentation, schrittweise Einarbeitung des Eigenpersonals — ist im Betriebsmodell für die JEN strukturell verankert.
Einschränkung und Transparenz
Beyonder benennt explizit, dass ein Referenzprojekt mit der spezifischen Kombination aus kerntechnischer Fachdomäne, On-Premises-Anforderung und dem vorliegenden Quellsystem-Mix (nscale, windream) bisher nicht realisiert wurde. Genau deshalb ist der Pilotansatz bewusst so gestaltet, dass die domänenspezifische Antwortqualität frühzeitig messbar wird — und Anpassungen auf Basis realer JEN-Daten vorgenommen werden können, bevor die Plattform in den Vollausbau geht.
Das eigentliche Zukunftsrisiko bei KI-Systemen
Die größte Gefahr für die langfristige Relevanz eines KI-Systems ist nicht technologische Stagnation, sondern das Gegenteil: Der Bereich der Large Language Models entwickelt sich so schnell, dass eine Lösung, die heute auf ein bestimmtes Modell oder einen bestimmten Anbieter zugeschnitten ist, in zwei bis drei Jahren strukturell veraltet sein kann — nicht weil die Technologie aufgehört hat zu funktionieren, sondern weil bessere Modelle verfügbar sind, die sich nicht einfach einsetzen lassen.
Die vorgeschlagene Architektur begegnet diesem Risiko durch eine klare Designentscheidung: Kein Teil der Plattform ist fest an ein spezifisches Modell, einen Anbieter oder eine proprietäre Schnittstelle gebunden.
Modulare Austauschbarkeit als Strukturprinzip
Alle KI-relevanten Komponenten — Sprachmodell, Embedding-Modell, Reranker — sind über standardisierte Schnittstellen eingebunden und können unabhängig voneinander ausgetauscht werden, ohne die übrigen Teile der Plattform zu verändern. vLLM als Inferenz-Server unterstützt heute bereits mehrere hundert Modellarchitekturen; ein Wechsel von Gemma 4 auf ein leistungsfähigeres Nachfolgemodell erfordert keine Architekturänderung, sondern einen Konfigurationswechsel. Dasselbe gilt für das Embedding-Modell: Sobald ein Modell mit besserer Retrievalqualität für deutschsprachige Texte verfügbar ist, kann es ohne Pipeline-Umbau eingespielt werden.
Diese Austauschbarkeit ist kein theoretisches Versprechen, sondern strukturell erzwungen: Die Komponenten kennen einander nicht direkt — sie kommunizieren ausschließlich über REST/OpenAPI-Schnittstellen. Ein Modellwechsel ist damit ein Deployment-Vorgang, kein Entwicklungsvorgang.
Open-Source-Lizenzen als Langzeitgarantie
Alle eingesetzten Kernkomponenten stehen unter Apache-2.0- oder MIT-Lizenzen. Diese Lizenzen sind unwiderruflich — kein Hersteller kann nachträglich auf ein proprietäres Modell wechseln oder Nutzungsrechte einschränken. Die JEN kann die heute eingespielten Versionen dauerhaft betreiben, unabhängig davon, was in den jeweiligen Projekten zukünftig geschieht.
Gleichzeitig sind alle eingesetzten Projekte — Qdrant, LlamaIndex, vLLM, Keycloak, Unstructured.io — keine Nischenprodukte, sondern aktiv gepflegte Open-Source-Projekte mit großen Communities, regelmäßigen Releases und breiter produktiver Nutzung weltweit. Das Risiko, dass ein einzelnes dieser Projekte aufgegeben wird und keine Nachfolgelösung existiert, ist strukturell gering — und selbst in diesem Fall erlaubt die Modularchitektur einen Komponentenwechsel ohne Gesamtumbau.
Kubernetes als Betriebsfundament der nächsten Dekade
Kubernetes hat sich als Industriestandard für den Betrieb containerisierter Workloads etabliert und wird es auf absehbare Zeit bleiben. Das gesamte Deployment der Plattform über Helm-Charts bedeutet, dass sämtliche Betriebsabläufe — Updates, Skalierung, Rollbacks, Monitoring — auf einem Fundament aufsetzen, für das es breites Wissen, Werkzeuge und Support gibt. Die JEN ist damit nicht auf spezialisiertes Plattform-Know-how eines einzelnen Dienstleisters angewiesen, sondern auf allgemein verfügbare Kubernetes-Kompetenz.
Reaktionsfähigkeit auf technologische Trends
Drei Entwicklungen, die den RAG-Bereich in den kommenden Jahren prägen werden, sind in der Architektur bereits vorgedacht:
Multimodalität: Gemma 4 verfügt nativ über Vision-Fähigkeiten. Sobald die Verarbeitung technischer Zeichnungen und Grafiken über reine OCR hinaus relevant wird, ist diese Erweiterung kein Architekturprojekt, sondern eine Konfigurationserweiterung der bestehenden Ingestion-Pipeline.
Agentic Workflows: Der Schritt von reiner Informationslieferung zu aktionsfähigen Workflows — Tickets erstellen, Genehmigungen anstoßen, Benachrichtigungen versenden — ist als optionaler Ausbaupfad bereits konzipiert und lässt sich auf der bestehenden Basis ergänzen, ohne die Kern-RAG-Pipeline anzufassen.
Kontinuierliche Modellverbesserung: Die KI-Forschung produziert im Halbjahrestakt neue Modellgenerationen mit messbaren Qualitätsverbesserungen. Der etablierte Goldset-Evaluierungsprozess ermöglicht es der JEN, Modellwechsel objektiv zu bewerten — nicht anhand von Benchmark-Versprechen, sondern anhand eigener Testfragen mit definierten Erwartungsantworten.
Langfristige Wartbarkeit
Die vorgeschlagene Lösung ist keine Eigenentwicklung mit proprietärem Kern, die dauerhaft von Beyonder gewartet werden muss. Der Großteil der Plattform besteht aus konfigurierten und integrierten Standardkomponenten, für die externe Kompetenz breit verfügbar ist. Beyonder liefert den Integrationsrahmen, die Konnektoren und die Betriebsdokumentation — aber die JEN erwirbt damit eine Plattform, die sie perspektivisch mit eigenem Personal oder einem anderen Dienstleister weiterentwickeln kann. Vendor-Lock-in ist strukturell ausgeschlossen.
