JEN Wissensplattform
rechenwerk ist ein in Essen ansässiges Softwareunternehmen mit langjähriger Erfahrung in der Entwicklung, dem Betrieb und der Weiterentwicklung sicherer Fachverfahren für öffentliche Auftraggeber. Unser Schwerpunkt liegt auf der Digitalisierung komplexer Verwaltungs- und Fachprozesse, der Integration heterogener Datenquellen, dem Betrieb geschützter Anwendungen sowie der nutzerfreundlichen Bereitstellung strukturierter Informationen für Fachanwenderinnen und Fachanwender.
Für die JEN schlagen wir eine modulare, on-premises betreibbare RAG-Plattform für den sicheren „Chat mit Dokumenten“ vor. Die Lösung kombiniert klassische Suche, semantische Suche, lokale Sprachmodelle, lokale Embedding-Modelle, OCR-/Dokumentenextraktion, rollenbasierte Zugriffskontrolle und nachvollziehbare Quellenreferenzen. Ziel ist ein pragmatischer Einstieg über einen fachlich klar abgegrenzten Pilotbetrieb mit anschließendem stufenweisen Ausbau.
Der Kern unseres Angebots ist eine JEN Wissensplattform, der vorhandene Wissensbestände aus SharePoint Online/OneDrive, SMB-Fileshares, DMS-Systemen, Intranet-/Wiki-Strukturen und relationalen Datenbanken auffindbar und quellenbezogen nutzbar macht. Die bestehenden Systeme bleiben dabei führend. Unsere Lösung ergänzt sie um eine sichere, on-premises betriebene Recherche- und Antwortschicht auf Basis einer modularen RAG-Architektur.
Der Kern des Angebots ist eine durchgängige Pipeline:
Bestehende Quellsysteme werden über Konnektoren und Delta-Sync angebunden.
Dokumente und Inhalte werden lokal extrahiert, per OCR verarbeitet, normalisiert und in suchbare
Wissenseinheiten zerlegt.
Berechtigungen aus AD-Gruppen und Quellsystemen werden in ein zentrales Zugriffskonzept überführt.
OpenSearch kombiniert klassische Volltextsuche, Vektorsuche und Metadatenfilter.
Ein LLM erzeugt Antworten ausschließlich auf Basis der berechtigten Fundstellen.
Jede Antwort enthält Quellenbezug auf Dokument, Seite, Abschnitt oder Datensatz.
Monitoring, Audit, Backup und Admin-Konsole machen den Betrieb durch Eigenpersonal nachvollziehbar.
Die Vision ist ein sicherer und überprüfbarer Wissenszugang für Mitarbeitende der JEN: Fachwissen soll schneller auffindbar werden, ohne Unternehmensdaten unkontrolliert an externe KI-Dienste zu übertragen. Die Lösung ist ein quellengebundener Rechercheassistent, wenn keine ausreichenden Quellen vorliegen, wird dies transparent angezeigt.
Damit entsteht ein pragmatischer Einstieg in KI-gestützte Wissensarbeit: klein genug für einen Pilotbetrieb, aber architektonisch so angelegt, dass weitere Quellen, Nutzergruppen, Modelle und Anwendungsfälle schrittweise ergänzt werden können.
Der vorgeschlagene Lösungsansatz ist eine standardnahe, modular aufgebaute On-Premises-RAG-Lösung. Die Architektur besteht aus den folgenden fachlich und technisch getrennten Schichten (siehe Architekturübersicht).
In der Schicht „Quellsysteme“ bleiben die bestehenden Systeme unverändert führend. SharePoint Online/OneDrive, SMB-Fileshares, DMS-Systeme wie nscale oder windream, Intranet-/Wiki-/CMS-Inhalte sowie MS SQL Server werden lesend angebunden. Die Lösung schreibt nicht in diese Systeme zurück und verändert keine fachlichen Ablage-, Freigabe- oder Aufbewahrungsprozesse.
In der Schicht „Ingestion und Governance“ übernehmen Konnektoren die laufende Aktualisierung. Neue, geänderte und gelöschte Inhalte werden erkannt und entsprechend verarbeitet. Für die Dokumentenextraktion werden etablierte Komponenten wie beispielsweise Apache Tika für Office-, PDF- und Textformate oder OCRmyPDF für gescannte PDFs vorgeschlagen. Anschließend werden Inhalte normalisiert, in fachlich sinnvolle Chunks zerlegt und mit Fingerprints versehen. Diese Fingerprints dienen zur Erkennung technischer Dubletten, zur Versionserkennung und zur Reduktion redundanter Indexinhalte.
Parallel dazu verarbeitet ein ACL-Resolver die Berechtigungsinformationen. AD-Gruppen, Rollen und quellsystemspezifische Rechte werden in ein einheitliches Berechtigungsmodell überführt. Ziel ist nicht, Berechtigungen neu zu definieren, sondern bestehende Rechte beim Retrieval wirksam durchzusetzen.
In der Schicht „Hybrid Retrieval“ wird OpenSearch als kombinierter Such- und Vektorindex eingesetzt. Die Lösung nutzt BM25 für klassische Volltextsuche, Vektoren für semantische Ähnlichkeit und Metadaten für Filter wie Quelle, Dokumenttyp, Version, Datum, Fachbereich oder Berechtigungsbereich. Vor der Antwortgenerierung greift ein Policy-Filter, der Dokument- und Feldrechte des angemeldeten Nutzers prüft. Ein Reranker priorisiert anschließend die relevantesten Fundstellen und baut daraus einen begrenzten, nachvollziehbaren Kontext für das LLM.
In der „Antwortschicht“ erfolgt die Inferenz lokal, z. B. über vLLM oder Hugging Face Text Generation Inference. Das LLM erhält nur bereits berechtigte und gerankte Kontextstellen. Guardrails prüfen u. a. auf Prompt-Injection-Muster, personenbezogene oder besonders schützenswerte Inhalte, Quellenbezug und Abstention-Fälle. Die Antwort wird nur dann generiert, wenn die Quellenlage ausreichend ist. Andernfalls wird transparent ausgegeben, dass keine belastbare Antwort aus den vorhandenen Quellen ableitbar ist. Die Antwortschicht wird sprachmodellagnostisch umgesetzt. Dadurch kann wahlweise ein lokal betriebenes Sprachmodell oder auch ein in der Cloud betriebenes, DSGVO‑konformes Sprachmodell verwendet werden.
In der „Betriebsschicht“ stehen eine Web-UI mit SSO, eine Admin-Konsole sowie Monitoring, Audit-Logging und Backup zur Verfügung. Administratoren können Quellenstatus, Indexläufe, Fehlerfälle, Modellstatus und Systemmetriken nachvollziehen.
Der Reifegrad ist als pilotfähige, standardnahe Lösung mit produktionsnahen Kernkomponenten einzuordnen. Die verwendeten Bausteine wie OpenSearch, Apache Tika, OCRmyPDF, rollenbasierte Webanwendungen, Monitoring und containerisierter Betrieb sind technisch etabliert.
Projektspezifisch sind vor allem die Konfiguration der JEN-Quellen, das Mapping der Berechtigungen, die Auswahl und Kalibrierung der verwendeten Modelle sowie die Qualitätsprüfung für besondere Dokumentklassen wie sehr große PDFs, gescannte Altunterlagen, Tabellen, Zeichnungen und stark versionierte Inhalte.
Die Lösung passt besonders gut zur JEN-Challenge, weil sie exakt auf die beschriebene Ausgangslage heterogener Wissensbestände ausgelegt ist. Die JEN muss relevante Informationen aus mehreren Quellsystemen recherchieren. Unser Ansatz schafft darüber eine einheitliche, sichere und quellenbasierte Zugriffsschicht.
Die Eignung ergibt sich aus fünf konkreten Eigenschaften der Architektur.
Erstens ist der Ansatz on-premises-fähig. Alle wesentlichen Verarbeitungsstufen laufen lokal: Dokumentextraktion, OCR, Chunking, Embedding-Erzeugung, Suchindex, Vektorindex, Reranking und LLM-Inferenz. Unternehmensdaten werden nicht zur Verarbeitung an externe KI-Dienste übertragen.
Zweitens bleibt der Zugriff berechtigungsbewusst. Die Lösung übernimmt vorhandene AD-Gruppen und Rollenstrukturen und erzwingt diese nicht nur in der Oberfläche, sondern bereits beim Retrieval. Das LLM kann nur mit Fundstellen arbeiten, für die der angemeldete Nutzer berechtigt ist. Dadurch wird verhindert, dass sensible Inhalte über generierte Antworten indirekt sichtbar werden.
Drittens ist die Suche für den Fachkontext geeignet. Eine reine semantische Suche wäre für technische, regulatorische und dokumentenlastige Umgebungen zu ungenau. Deshalb kombiniert die Lösung BM25-Volltextsuche, Vektorsuche, Metadatenfilter und Reranking. Exakte Suchbegriffe, Aktenzeichen, Dokumentnummern, technische Bezeichnungen und Abkürzungen bleiben auffindbar; gleichzeitig können semantisch ähnliche Formulierungen erkannt werden.
Viertens ist die Antwortqualität nachvollziehbar. Antworten werden nicht als freie KI-Aussagen präsentiert, sondern mit Quellen auf Dokument, Seite und Abschnitt. Bei fehlender oder widersprüchlicher Quellenlage erfolgt eine Abstention, also eine transparente Nicht-Antwort. Damit unterstützt die Lösung Recherche, Zusammenfassung und Orientierung, ersetzt aber keine fachliche Prüfung oder Freigabe.
Fünftens ist der Ausbau realistisch steuerbar. Die Architektur erlaubt einen Pilot mit begrenztem Datenraum, ausgewählten Quellen und einem Expertenteam. Danach können weitere Quellen, Datenmengen, Nutzergruppen und Anwendungsfälle inkrementell ergänzt werden.
Die größten Synergien liegen in der Kombination aus vorhandener Systemlandschaft, AD-gestützter Organisation und hohem Bedarf an belastbarer Wissensrecherche. Die Lösung nutzt bestehende Strukturen weiter, macht sie aber über eine moderne RAG-Schicht wesentlich besser zugänglich.
Im Standard bzw. standardnah abgedeckt sind folgende Bestandteile der vorgeschlagenen Architektur (Eine Architekturübersicht ist als Anlage hochgeladen worden):
Die Quellsystem-Schicht deckt SharePoint Online/OneDrive, SMB-Fileshares, DMS-Anbindungen, Intranet-/Wiki-/CMS-Quellen und relationale Datenbanken grundsätzlich ab. SharePoint und SMB eignen sich als erste Pilotquellen, weil Berechtigungen und Änderungsinformationen typischerweise gut auswertbar sind. DMS, Wiki/CMS und MS SQL Server sind ebenfalls integrierbar, erfordern aber je nach konkreter Systemkonfiguration eine Schnittstellen- und Metadatenanalyse.
Die Ingestion- und Governance-Schicht deckt Delta-Sync, Dokumentextraktion, OCR, Normalisierung, Chunking, Fingerprinting, Metadatenaufbau und ACL-Auflösung ab. Fingerprints ermöglichen technische Dublettenerkennung und unterstützen die Versionserkennung. Der ACL-Resolver übernimmt AD-Gruppen und Rolleninformationen und überführt sie in ein Retrieval-fähiges Berechtigungsmodell.
Die Hybrid-Retrieval-Schicht deckt klassische Suche, semantische Suche, Metadatenfilter, Berechtigungsfilter und Reranking ab. OpenSearch kann dabei sowohl Volltextsuche als auch Vektorindexierung und Metadatenfilter abbilden. Der Policy-Filter stellt sicher, dass nur berechtigte Treffer in den Kontextbau gelangen.
Die Antwortschicht deckt lokales LLM-Serving, Guardrails, Prompt-Injection-Prüfungen, PII-Filter, quellenbasierte Antwortgenerierung und Abstention bei unzureichender Quellenlage ab. Die Antwort wird mit Quellenangaben auf Dokument, Seite und Abschnitt versehen.
Die Betriebsschicht deckt Web-UI mit SSO, Monitoring, Audit-Logging, Backup und Admin-Konsole ab. Dadurch können Indexläufe, Fehlerfälle, Systemzustände, Modellverfügbarkeit und Nutzungsmetriken nachvollzogen werden.
Offene Punkte liegen nicht im Grundprinzip, sondern in der JEN-spezifischen Ausprägung. Dazu gehören die konkrete Schnittstellenlage von nscale und windream, die Struktur des Intranets/Wikis, die gewünschte Datenbankanbindung, die Qualität gescannter Altunterlagen, die Behandlung sehr großer Dokumente, der Umgang mit Zeichnungen und Bildern sowie die finale Auswahl geeigneter deutscher Embedding- und LLM-Modelle.
Der realistische Ausbaupfad sollte in vier Phasen erfolgen:
Phase 1: Architektur- und Quellenschnitt, ca. 4 Wochen. Festlegung von Pilotquellen, Nutzergruppen, Berechtigungsmodell, Dokumentklassen, Qualitätskriterien und Betriebsumgebung.
Phase 2: Technischer Pilotaufbau, ca. 4 bis 6 Wochen. Aufbau von Web-UI/SSO, OpenSearch, lokaler LLM-Inferenz, Tika/OCR-Pipeline, Delta-Sync für erste Quellen, Monitoring und Backup.
Phase 3: Qualitäts- und Governance-Kalibrierung, ca. 5 bis 7 Wochen. Optimierung von Chunking, Reranking, Quellenanzeige, Abstention-Verhalten, ACL-Mapping, Prompt-Injection-Schutz und OCR-Verarbeitung anhand realer JEN-Dokumente.
Phase 4: Pilotabschluss und Ausbauentscheidung, ca. 3 bis 5 Wochen. Fachliche Evaluation, Fehleranalyse, Betriebsdokumentation, Sizing-Nachschärfung und Roadmap für weitere Quellen.
Nach dem Pilot kann die Lösung schrittweise erweitert werden: zusätzliche DMS-Quellen, breiterer SharePoint-/Fileshare-Scope, relationale Datenquellen über kuratierte Views, verbesserte Dubletten- und Versionierungslogik, domänenspezifische Synonyme, Evaluations-Dashboards, feinere Admin-Funktionen und später Multi-Node-Skalierung. Die vorhandenen Systeme werden so sicher und lokal erschlossen.
Für den Einstieg empfehlen wir einen Proof of Concept über 8 bis 12 Wochen, idealerweise als 10-Wochen-Pilot. Ziel ist nicht die sofortige Erschließung des gesamten Langfristbestands, sondern der Nachweis einer sicheren, berechtigungsrichtigen und quellenbasierten Recherche mit realen JEN-Dokumenten. Der Pilot sollte zwei bis drei repräsentative Quelltypen enthalten, z. B. SharePoint Online/OneDrive, einen SMB-Fileshare und optional eine DMS-, Wiki- oder SQL-Pilotquelle.
Der Pilotdatenraum sollte fachlich relevant, aber bewusst begrenzt in kritischen Testfällen, hohe Quellenabdeckung bei beantworteten Fragen, nachvollziehbare Seiten-/Abschnittsreferenzen, dokumentierte Nichtbeantwortung bei fehlender Evidenz, akzeptable Antwortlatenz, reproduzierbare Indexläufe, sichtbare Fehler-/Statusinformationen und positives Feedback des Expertenteams.
Das Betriebsmodell ist stufenweise angelegt. In der Pilotphase übernehmen wir Aufbau, Konfiguration, technische Begleitung und Qualitätsschärfung gemeinsam mit der JEN-IT. Für den Regelbetrieb werden Admin-Konsole, Monitoring-Dashboards, Runbooks, Backup-/Restore-Vorgehen, Update-Prozess, Quellenregister, Rollenmatrix und Betriebsdokumentation bereitgestellt.
Ziel ist ein Eigenbetrieb durch JEN-Personal, während externe Unterstützung vor allem für neue Integrationen, größere Updates, Modellwechsel und Weiterentwicklung benötigt wird.
sein. Er sollte textbasierte PDFs, Office-Dokumente, gescannte PDFs, größere Dokumente, Dubletten, Versionen und unterschiedliche Berechtigungsstufen enthalten.
Der technische Aufwand liegt nicht primär im Chat-Frontend, sondern in Quellenschnitt, Rechteabbildung, Dokumentverarbeitung, Qualitätssicherung und Betriebsübergabe. Als realistische Größenordnung für einen belastbaren Pilot sehen wir ca. 220 bis 270 externe Personentage sowie ca. 50 bis 80 interne Personentage auf Seiten der JEN. Diese Werte sind keine Preisangabe, sondern eine Aufwandsindikation. Der interne Aufwand entsteht vor allem durch Infrastrukturfreigaben, Quellenauswahl, Servicekonten, Berechtigungsanalyse, Datenschutz-/Informationssicherheitsabstimmung und fachliche Qualitätstests.
Das Pilotvorgehen gliedert sich in sechs Arbeitspakete:
Erstens Governance und Scope: Use-Cases priorisieren, Quellenregister anlegen, Schutzbedarf je Quelle festlegen, Datenschutz-/Informationssicherheitsprüfung anstoßen und Abnahmekriterien festlegen.
Zweitens Basisplattform: Netzwerkzonen, Server/VMs, SSO/AD, Secret-Management, Deployment, Monitoring und Backup vorbereiten.
Drittens Quellen und Ingestion: SharePoint/OneDrive-Delta-Läufe, SMB-Crawler, optional DMS-/Wiki-/SQL-Adapter, Extraktion, OCR, Fingerprints und ACL-Resolver aufbauen.
Viertens Retrieval und Antwortschicht: OpenSearch-Hybrid-Suche, Policy-Filter, Reranking, Citation Builder, Guardrails, Abstention-Policy und Web-UI konfigurieren.
Fünftens Härtung und Evaluation: Gold-Set-Tests, Rechte-Tests, Performance-Messung, Logging-/Löschkonzept und Betriebsrunbooks.
Sechstens Enablement: Admin-Einweisung, Testnutzer-Schulung, Pilot-Support, Rollout-Backlog und Entscheidungsvorlage für den Ausbau.
Für die Pilotbewertung empfehlen wir messbare Kriterien: keine Berechtigungsleckage
Das finale Sizing sollte im Pilot belastbar gemessen werden, da Speicher- und Rechenbedarf stark von Datenumfang, OCR-Anteil, Dokumentstruktur, Chunking, Vektordimension, Modellwahl und Antwortlatenz abhängen. Grundsätzlich soll die Lösung jedoch nicht den gesamten langfristigen Datenraum von ca. 50 TB vollständig duplizieren. Rohdaten bleiben in den führenden Quellsystemen; gespeichert werden vor allem extrahierte Texte, Chunks, Metadaten, ACL-Informationen, Vektoren, Fingerprints, Indexdaten, Logs und Backups.
Für den Pilotbetrieb empfehlen wir eine kompakte On-Premises-Umgebung mit getrennten Ressourcen für Anwendung/Ingestion, Suche/Index und lokale LLM-Inferenz. Als grobe Startannahme:
ein App-/Ingestion-Knoten mit ca. 8–16 vCPU, 32–64 GB RAM und 0,5–1 TB SSD
ein OpenSearch-Knoten bzw. kleiner Suchcluster mit ca. 16–32 vCPU, 64–128 GB RAM und schneller SSD/NVMe
ein GPU-Knoten für lokales LLM-Serving mit mindestens ca. 24 GB VRAM, bei größeren Modellen oder höherer Parallelität eher 48–80 GB VRAM.
Für Pilotdaten, OCR-Zwischenergebnisse, Indexdaten, Logs und Snapshots sollte ein niedriger einstelliger TB-Bereich eingeplant werden.
Für den späteren Zielbetrieb mit ca. 350 Nutzern, ca. 30 parallelen interaktiven Anfragen und bis zu ca. 1 Mio. Dokumenten empfehlen wir einen Multi-Node-Aufbau:
getrennte API/Web-Komponenten
mehrere OpenSearch-Datenknoten
separate Ingestion-/OCR-Worker
ein oder mehrere GPU-Inferenzknoten
Monitoring- und Backup-Komponenten.
Wirtschaftlich sinnvoll ist eine zweistufige Modellstrategie: ein kleineres, schnelles Modell für Standardfragen und ein stärkeres Modell für komplexere Synthesen.
Die höchste Last entsteht voraussichtlich nicht durch einzelne Chat-Anfragen, sondern durch Crawling, OCR, Extraktion, Embedding-Erzeugung und Indexierung. Deshalb sollte die Ingestion asynchron, drosselbar und zeitgesteuert erfolgen. Große Erstindexierungen sollten außerhalb kritischer Betriebszeiten laufen; im Regelbetrieb reduziert Delta-Sync die Last deutlich.
Netzwerkseitig sind stabile Verbindungen zu SharePoint Online/OneDrive, SMB-Fileshares, DMS, Wiki/CMS, AD/Entra-ID und Datenbanken erforderlich. Externe Verbindungen, Telemetrie und Modell-/Paketupdates sollten restriktiv kontrolliert werden. Backup-seitig sollten mindestens Konfigurationen, Quellenregister, ACL-Mappings, Metadaten, Indexstände, Modell-/Prompt-Konfigurationen, Audit-Logs und Betriebsdaten gesichert werden. Für die erste Ausbaustufe reicht ein Single-/Multi-Node-Betrieb mit Backup; Hochverfügbarkeit kann später ergänzt werden.
rechenwerk verfügt über langjährige Erfahrung in der Entwicklung und im Betrieb sicherer, langlebiger Fachanwendungen für öffentliche Auftraggeber und verwaltungsnahe Organisationen. Unsere Projekte zeichnen sich regelmäßig durch komplexe Rollen- und Rechtestrukturen, hohe Anforderungen an Nachvollziehbarkeit, strukturierte Datenhaltung, Dokumentenbezug, Supportprozesse und geschützten Betrieb aus.
Darüber hinaus haben wir bereits für die Landesgesellschaft ZENIT GmbH in Nordrhein-Westfalen ein RAG-System aufgebaut. Dabei wurden interne Wissensbestände technisch erschlossen und über eine KI-gestützte Recherche- und Antwortkomponente nutzbar gemacht.
Beispiele für relevante Erfahrungsschwerpunkte:
Entwicklung und Betrieb von Monitoring- und Fachverfahren für EU-Förderprogramme
Aufbau und Umsetzung von RAG-basierten Wissenssystemen im öffentlichen bzw. verwaltungsnahen Umfeld
Digitalisierung von Antrags-, Prüf-, Bewertungs- und Verwaltungsprozessen
Umsetzung rollenbasierter Nutzer- und Berechtigungskonzepte
Betrieb produktiver Anwendungen mit Staging-/Produktionsumgebungen, Monitoring, Backup und Release-Prozessen
Integration strukturierter Datenbestände, Dokumente und Fachprozesse
Zusammenarbeit mit öffentlichen Auftraggebern, Programmstellen und fachlichen Expertengruppen
Aufbau nutzerfreundlicher Anwendungen für komplexe Fachinhalte
Auch wenn der nukleartechnische Kontext der JEN fachlich spezifisch ist, sind die technischen und organisatorischen Grundanforderungen mit unseren bisherigen Projekterfahrungen gut vergleichbar: sichere Informationsverarbeitung, strukturierte Nachvollziehbarkeit, belastbare Rechtekonzepte, langfristiger Betrieb und pragmatische Einführung gemeinsam mit Fachanwenderinnen und Fachanwendern.
Für das hier vorgeschlagene RAG-Szenario bringen wir insbesondere unsere Erfahrung aus sicherem Softwarebetrieb, Datenintegration, Fachverfahrensentwicklung, nutzerzentrierter Einführung, öffentlichem Sektor und dem bereits umgesetzten RAG-System für die ZENIT GmbH ein. Unser Ansatz ist bewusst so gewählt, dass die fachliche Spezifik der JEN nicht durch ein starres Standardprodukt überdeckt wird, sondern in Pilotierung, Testfragen, Metadatenmodell, Quellenanbindung und Berechtigungskonzept sauber berücksichtigt werden kann.
Die langfristige Zukunftssicherheit der Lösung ergibt sich vor allem aus der modularen Architektur. Quellsysteme, Konnektoren, Ingestion, OCR, Normalisierung, Berechtigungsauflösung, Suchindex, Vektorindex, Reranking, lokales LLM-Serving, Guardrails, Web-UI, Monitoring und Admin-Konsole sind bewusst als getrennte Komponenten vorgesehen. Dadurch ist die Lösung nicht von einem einzelnen Modell, einer einzelnen Vektordatenbank oder einem einzelnen Hersteller abhängig. Einzelne Bausteine können ausgetauscht oder erweitert werden, ohne die gesamte Plattform neu aufzubauen.
Ein zentrales Zukunftsprinzip ist, dass die bestehenden Quellsysteme führend bleiben. SharePoint, Fileshares, DMS, Wiki/CMS und Datenbanken werden nicht ersetzt, sondern über lesende Konnektoren erschlossen. Damit bleibt die Lösung auch dann tragfähig, wenn sich einzelne Quellsysteme ändern oder weitere Systeme hinzukommen. Neue Quellen können über zusätzliche Konnektoren, APIs, Exportformate oder kuratierte Views angebunden werden. Die Plattform speichert primär abgeleitete Such- und Antwortartefakte wie extrahierte Texte, Chunks, Metadaten, ACLs, Vektoren und Fingerprints; die fachliche Wahrheit verbleibt in den Primärsystemen.
Auch auf Modellebene ist der Ansatz zukunftsfähig. Das lokale LLM-Serving kann über standardisierte interne Schnittstellen, z. B. eine OpenAI-kompatible API, angebunden werden. Dadurch können UI, Retrieval-Orchestrierung und Antwortlogik stabil bleiben, während LLMs, Embedding-Modelle oder Reranker später ausgetauscht werden. Das ist besonders wichtig, weil sich Modellqualität, Hardwareanforderungen, Kontextlängen und Kosten in den kommenden Jahren weiter verändern werden. Die Lösung ist daher nicht auf ein bestimmtes Modell festgelegt, sondern unterstützt einen kontrollierten Modell-Lifecycle: evaluieren, testen, freigeben, betreiben, überwachen und bei Bedarf ersetzen.
In der ersten Stufe steht ein sicherer Pilot im Vordergrund: begrenzter Datenraum, ausgewählte Quellen, lokale Modelle, berechtigungsrichtiges Retrieval, Quellenreferenzen, Monitoring, Backup und fachliche Evaluation.
In der zweiten Stufe wird der produktionsnahe Ausbau vorbereitet: weitere SharePoint-/Fileshare-Bereiche, zusätzliche DMS- oder Wiki-Quellen, verbesserte Dubletten- und Versionierungslogik, fachliche Synonyme, kuratierte SQL-Views und verfeinerte Admin-Funktionen.
In der dritten Stufe kann die Plattform skaliert werden: Multi-Node-Betrieb, leistungsfähigere Index- und GPU-Knoten, stärker automatisierte Ingestion, Evaluation-Dashboards und optimierte Betriebsprozesse. In späteren Ausbaustufen können multimodale Verfahren für Zeichnungen, Grafiken und Bilder sowie domänenspezifische Assistenzfunktionen ergänzt werden.
Die Wartbarkeit wird durch klare Schnittstellen, exportierbare Konfigurationen und nachvollziehbare Betriebsartefakte abgesichert. Dazu gehören Quellenregister, Rollen- und Rechte-Mapping, Indexschemas, Prompt- und Modellkonfigurationen, Evaluationssets, Runbooks, Backup-/Restore-Verfahren und Monitoring-Dashboards. Änderungen an Modellen, Konnektoren oder Dokumentverarbeitung können dadurch kontrolliert versioniert und getestet werden. Für den langfristigen Betrieb ist außerdem vorgesehen, dass JEN-Eigenpersonal zentrale Aufgaben wie Quellenverwaltung, Statusprüfung, Fehleranalyse, Nutzerverwaltung und einfache Konfigurationsanpassungen selbst übernehmen kann.
Ein weiterer Zukunftsaspekt ist die bewusste Trennung zwischen Retrieval und Antwortgenerierung. Die Lösung versucht nicht, Wissen dauerhaft in einem Modell zu speichern oder durch Fine-Tuning schwer nachvollziehbar zu verändern. Stattdessen werden aktuelle, berechtigte und quellenbasierte Inhalte zur Laufzeit recherchiert und als Kontext verwendet. Dadurch bleiben Antworten näher an den aktuellen Dokumenten, und Änderungen in Quellsystemen können über Delta-Sync und Re-Indexierung nachvollziehbar in den Wissenszugang übernommen werden.
Auch wirtschaftlich ist der Ansatz langfristig tragfähig, weil er einen schrittweisen Ausbau erlaubt. Es ist nicht erforderlich, den gesamten Datenbestand sofort tief zu indexieren oder alle Dokumentklassen im ersten Schritt vollständig semantisch zu erschließen. Stattdessen kann mit priorisierten Quellen und Anwendungsfällen begonnen werden. Häufig genutzte und fachlich wertvolle Bestände werden intensiver verarbeitet; weniger relevante oder schwer verarbeitbare Bestände können später ergänzt werden. Dadurch bleiben Aufwand, Infrastrukturbedarf und Betriebsrisiken kontrollierbar.
