Sovereign-Insight: On-Premises RAG-Plattform zur sicheren Wissenserschließung
Die dida Datenschmiede GmbH ist ein auf Künstliche Intelligenz spezialisiertes Unternehmen aus Berlin. Unsere Kernkompetenz liegt in der Entwicklung maßgeschneiderter algorithmischer Individual-Lösungen in den Bereichen Natural Language Processing (NLP), Large Language Models (LLMs) und Computer Vision. Mit einem Team aus Machine Learning Scientists überführen wir mathematische Methoden (Python, PyTorch) in produktionsreife, hochsichere Software-Infrastrukturen (Docker, Kubernetes).
Wir schlagen für die JEN eine modular anpassbare, rein lokale On-Premises RAG-Architektur zur sicheren Erschließung von bis zu 50 TB Datenbestand vor. Unser Ansatz verbindet zwei Kernkompetenzen:
Angewandte SaaS-Erfahrung im Dokumentenhandling: Über die Algorithmen zur KI-basierten Strukturanalyse unserer Software-Entwicklung smartextract beherrschen wir das präzise Parsing komplexer, heterogener Dokumente.
On-Premises-Infrastruktur-Erfahrung im Industrial Engineering: Wir operationalisieren aktuell im Rahmen eines Großprojekts einen containerisierten KI-Assistenten in einer geschützten On-Premises-Umgebung.
Dieses System befähigt die Mitarbeitenden der JEN, heterogene Dokumente, Scans und Tabellenstrukturen über ein Chat-Interface quellenbasiert und weitestgehend halluzinationsfrei zu analysieren. Da die gesamte Architektur inklusive der Open-Weights-Modelle lokal betrieben wird, bleibt die Datenhoheit vollständig im geschützten Netzwerk der JEN.
Technisches Fundament und Funktionsweise: Der vorgeschlagene Ansatz basiert auf einer modular erweiterbaren RAG-Architektur (Retrieval-Augmented Generation) für den On-Premises-Betrieb (via Docker/Kubernetes). Die Pipeline gliedert sich in drei Schritte:
Strukturiertes Parsing (Ingestion): Unter Nutzung unserer Algorithmen zur Layout-Analyse werden auch Scans mit Seitenanzahlen, Fileshares und Tabellen semantisch und relational erfasst.
Rechtebasiertes Retrieval: Die Textsegmente werden in einer lokalen Vektordatenbank indiziert. Ein effizientes Early Filtering (Pre-Query Filtering) gleicht die AD-/Fileshare-Rechte des Nutzers direkt mit den Dokumenten-Metadaten ab, noch bevor die Suche ausgeführt wird. Nur autorisierte Inhalte gelangen in den Kontext.
Lokale Inferenz: Ein Open-Weights-Sprachmodell (z. B. Llama- oder Mistral-Derivate) generiert isoliert auf lokalen GPUs die quellenbelegte Antwort. Ein Datenbank-Layer sichert die Verarbeitung paralleler Nutzeranfragen (Concurrent Requests).
Reifegrad und Erfahrung (Technology Readiness Level 7–8): Der Ansatz kombiniert erprobte Technologie-Bausteine mit einer auf die JEN zugeschnittenen Integrationsleistung:
Einsatzbereite Parsing-Algorithmen: Die Extraktions- und Dokumenten-Parsing-Komponenten stammen aus unserer SaaS-Entwicklung smartextract, die im produktiven Unternehmenseinsatz monatlich über 55.000 Dokumente verarbeitet.
Erfahrung in der System-Operationalisierung: Unsere Machine Learning Scientists verfügen über die Praxiserfahrung, komplexe Infrastruktur-Komponenten effektiv zu orchestrieren. Aktuell entwickeln wir in einem Großprojekt den containerisierten Chatbot für die Entwicklungsingenieure eines internationalen Energietechnologiekonzerns. Die dort gewonnenen Erkenntnisse bezüglich Inferenz-Pipelines, automatisiertem Deployment und Datenbank-Schnittstellen befähigen uns, die Teilkomponenten für die JEN zielgerichtet und rechtlich unabhängig neu aufzusetzen.
Die Eignung für das Szenario der JEN basiert auf der Kombination unserer Erfahrungen aus zwei Welten: dem datenzentrierten SaaS-Bereich und dem geschützten On-Premises-Infrastruktur-Engineering. Die Synergien teilen sich in drei Dimensionen auf:
Vollständige Datensouveränität (On-Premises-Fokus): Um den ungewollten Datenabfluss in hochregulierten Bereichen zu verhindern, sind unsere Machine Learning Scientists darauf spezialisiert, Open-Weights-Modelle lokal in isolierten Umgebungen (Docker, Kubernetes) zu betreiben. Dies garantiert der JEN den geforderten, vollständig autarken Betrieb.
Beherrschung komplexer Datenstrukturen und Großdokumente: Die Verarbeitung vierstelliger Seitenanzahlen und dichter Tabellen führt bei Standard-Systemen schnell zu Fehlern im Retrieval. Hier nutzen wir unsere angewandte SaaS-Erfahrung bei der automatisierten Dokumenten-Strukturanalyse sowie unsere datenwissenschaftliche Expertise aus Vorprojekten im Bereich Predictive Analytics. Durch die strukturierte Aufbereitung der Rohdaten vor der Indizierung wird die Suchgenauigkeit des lokalen Modells maßgeblich erhöht.
Sicherheitskonforme AD-Rechte-Integration: Durch die Implementierung eines Early Filterings auf Metadaten-Ebene stellen wir sicher, dass die Active-Directory- und Fileshare-Rechte nativ abgebildet werden.
Unsere Praxiserfahrung mit containerisierten Chatbots im Industrial Engineering minimiert das Implementierungsrisiko, stellt die Handhabung paralleler Nutzeranfragen sicher und gewährleistet einen schnellen Projektstart im Piloten.
Durch technologische Vorarbeiten und Software-Bausteine abgedeckt:
Modell-Hosting & Inferenz: Das On-Premises-Deployment von Open-Weights-Modellen sowie die Handhabung paralleler Nutzeranfragen basieren auf wiederverwendbaren Software-Blaupausen aus unseren Projekten.
Dokumenten-Parsing: Die Strukturierung layout-dichter Scans und Tabellen wird über die Algorithmen gelöst, die wir im Rahmen unserer SaaS-Plattform smartextract entwickelt haben.
Chat-Infrastruktur: Für die Speicherung von Konversationen (Session- und Turn-Handling in einer lokalen PostgreSQL-Datenbank) nutzen wir ein von uns entwickeltes, generisches Datenbankschema.
Offene Punkte (Spezifische Integrationsleistungen für die JEN):
Systemspezifische Konnektoren: Während Standard-Schnittstellen (wie das SharePoint-SDK) vorliegen, müssen die inkrementellen Update-Zyklen und die API-Gegenstellen der DMS-Systeme individuell angebunden werden.
AD-Rechte-Spiegelung: Das logische Konzept für das Early Filtering in der Vektordatenbank wurde bei dida intern entwickelt. Die automatisierte Auslesung geschachtelter, lokaler Active-Directory-Gruppenstrukturen erfordert eine spezifische Abstimmung mit dem Identitätsmanagement der JEN.
Voraussichtlicher Zeitplan bis zum produktiven Ausbau (Gesamtdauer: ca. 24 Wochen): Um das wirtschaftliche und technische Projektrisiko für die JEN zu minimieren, schlagen wir eine schrittweise Einführung vor, die mit einem schlanken Prototypen startet, bevor der volle 50-TB-Datenbestand ausgerollt wird.
Woche 1–4 (Konzeption & Analyse): Technischer Workshop zur Analyse der Quellsysteme (SharePoint, DMS, AD). Festlegung der Schnittstellen und der Logiken für den Dubletten-Check.
Woche 5–10 (Infrastruktur & Prototyp): Aufsetzen des lokalen Multi-Node-Setups. Aufbau der Daten-Pipeline für eine erste, repräsentative Teilmenge der Daten (Schmaler Prototyp).
Woche 11–16 (Rechteintegration & Pilotphase): Implementierung des Early Filterings für die Benutzerrechte und Bereitstellung des Chat-Frontends. Testbetrieb der 8- bis 12-wöchigen Pilotphase mit dem Test- und Expertenteam der JEN.
Woche 17–24 (Evaluation & schrittweiser Ausbau): Auswertung des Nutzer-Feedbacks der Pilotphase, Optimierung der lokalen Modell-Latenzen und Durchführung des stufenweisen Ausbaus auf den gesamten 50-TB-Datenraum. Sollte die Pilotphase nicht die gewünschten Kriterien erfüllen, existiert hier ein klarer Ausstiegspunkt (Exit-Szenarien) für die JEN.
Angestrebtes Betriebsmodell: Die vorgeschlagene Lösung wird als reines On-Premises-Modell realisiert. Die gesamte Software-Architektur – inklusive der Ingestion-Pipelines, der lokalen Vektordatenbank und der Open-Weights-Modelle – wird vollständig isoliert in der IT-Infrastruktur der JEN betrieben. Es fließen zu keinem Zeitpunkt Daten nach außen ab, und es bestehen keine Abhängigkeiten von externen Cloud-APIs.
Pilotvorgehen (Proof of Concept – PoC): Das Pilotvorgehen ist als geschlossene Phase (Woche 10–16 des Gesamtzeitplans) konzipiert. Ziel ist es, mit einem kleinen Test- und Expertenteam der JEN die Antwortqualität, das Early Filtering (AD-Rechte) sowie die Systemlatenzen auf Basis eines repräsentativen Test-Datensatzes (ausgewählte SharePoint-Ordner und File-Shares) lokal zu validieren, bevor die Skalierung auf den gesamten Datenraum erfolgt.
Geschätzter Integrationsaufwand und Budgetrahmen: Die Aufwände für die technische Implementierung und die schrittweise Einführung gliedern sich in zwei Stufen:
Stufe 1: Bereitstellung des Pilotsystems (ca. 45 Personentage)
Umfasst das lokale Basis-Infrastruktur-Setup, das Parsing des Test-Datensatzes, die grundlegende AD-Anbindung sowie das Bereitstellen des Chat-Frontends für die Testnutzer.
Unverbindlicher Budgetrahmen: ca. 49.000 € bis 59.000 €
Stufe 2: Ausbau zum voll funktionsfähigen Gesamtsystem (ca. 135 Personentage)
Umfasst die vollständige Anbindung der komplexen DMS-Systeme (nscale, windream) und relationalen Datenbanken, die tiefe Validierung geschachtelter AD-Rechtestrukturen, die Parallelisierung der Pipelines für das 50-TB-Datenvolumen sowie die finale Übergabe in den Eigenbetrieb der JEN.
Unverbindlicher Budgetrahmen: ca. 140.000 € bis 160.000 €.
Gesamtaufwand: Für das funktionsfähige Gesamtsystem inklusive Pilotierung kalkulieren wir mit einem Gesamtaufwand von ca. 180 Personentagen, was einem unverbindlichen Gesamtbudget von ca. 198.000 € bis 218.000 € entspricht.
Für die Verarbeitung von ca. 1 Million Dokumenten und 30 gleichzeitigen, interaktiven Anfragen empfehlen wir ein lokal getrenntes Multi-Node-Setup, um Suchanfragen (Retrieval) und Textgenerierung (Inferenz) unabhängig voneinander zu skalieren:
Vektor- und Datenbank-Knoten (Retrieval): Erfordert mindestens 32 CPU-Kerne und 128 GB bis 256 GB RAM. Der hohe Arbeitsspeicher ist notwendig, um den Vektorindex sowie die Metadaten für das vorgeschaltete Rechte-Filtering (AD-Abgleich) für schnelle Antwortzeiten direkt im RAM zu halten.
Modell-Knoten (Inferenz): Zur lokalen Ausführung eines Open-Weights-Modells (z. B. mit 70 Milliarden Parametern) werden Grafikprozessoren benötigt. Für die Ziel-Last empfehlen wir ein Setup von 2x NVIDIA A100 (80 GB VRAM) oder entsprechende Nachfolgemodelle. Für den Testbetrieb der Pilotphase reicht zunächst eine kleinere, einzelne Enterprise-GPU (z. B. 1x 48 GB VRAM) aus.
Speicherplatz (Storage): Es werden ca. 2 TB bis 4 TB schneller SSD/NVMe-Speicher für die lokalen Container-Images, Indizes und die Chat-Datenbank benötigt. Der primäre 50-TB-Dokumentenpool verbleibt auf den Quellsystemen der JEN und muss für das RAG-System nicht physisch dupliziert werden; die Ingestion-Pipeline benötigt lediglich Lesezugriff.
Netzwerk: Da das System vollständig On-Premises läuft, wird keine externe Internet-Bandbreite benötigt. Intern wird eine Standard-Netzwerkanbindung (1 Gbit/s, idealerweise 10 Gbit/s zu den Quellsystemen) für die inkrementellen Aktualisierungsläufe vorausgesetzt.
Die exakten Hardware-Ressourcen hängen vom final gewählten Modell und dessen Quantisierungsgrad ab. Die containerisierte Architektur ermöglicht es, die Auslastung während der Pilotphase präzise zu messen und die Hardware vor dem finalen Rollout exakt zu kalibrieren.
Unsere Expertise für die Anforderungen der JEN belegen wir durch den Transfer von Erfahrungen aus zwei komplementären Bereichen: Unserer cloudbasierten Dokumenten-SaaS-Plattform und unseren On-Premises-Infrastrukturprojekten im Industrial Engineering. Die Klarnamen der beteiligten Unternehmen haben wir im geschützten Bereich der Einreichung für Sie hinterlegt.
1. Technologie-Basis „smartextract“ (Angewandte SaaS-Erfahrung im Dokumentenhandling)
Einsatzszenario: Cloudbasierte KI-Plattform zur automatisierten Klassifikation, Layout-Analyse und Informationsextraktion aus hochgradig unstrukturierten B2B-Dokumenten (monatlich über 55.000 Dokumente im produktiven Enterprise-Einsatz).
Relevanz für die JEN: Durch diese SaaS-Erfahrung besitzen wir tiefgreifend validierte Algorithmen für das Dokumenten-Parsing. Diese Software-Bausteine nutzen wir, um die heterogenen Quellen der JEN (wie vierstellige Seitenanzahlen und Tabellen) präzise zu strukturieren, bevor sie in die Vektordatenbank fließen.
2. Infrastruktur-Projekt „Inbound-Data-Parsing“ (On-Premises-Erfahrung im Stahl- und Warenhandel)
Einsatzszenario: Entwicklung und lokales Deployment einer NLP-Pipeline zur automatisierten Extraktion hochspezifischer technischer Details (Abmessungen, Materialgüten, Freitexte) aus dem unstrukturierten Dokumenten- und Bestellwesen eines führenden europäischen Stahlhandelskonzerns.
Relevanz für die JEN: Dieses Projekt belegt unsere Kompetenz bei der lokalen Anbindung heterogener Datenströme in geschützten Firmennetzwerken. Die Erfahrung beim semantischen Aufbereiten (Chunking) technischer Freitexte sichert ein fehlerfreies Retrieval bei den Dokumenten der JEN.
3. Infrastruktur-Projekt „Engineering-Chatbot“ (On-Premises-Erfahrung in der Energietechnologie)
Einsatzszenario: Konzeption, softwareseitige Orchestrierung und produktiver On-Premises-Betrieb (Docker/Kubernetes) eines containerisierten KI-Assistenten zur Unterstützung von Entwicklungsingenieuren bei einem internationalen Energietechnologiekonzern.
Relevanz für die JEN: Dieses Projekt spiegelt die Systemarchitektur der JEN-Challenge direkt wider. Wir bringen hieraus die Praxiserfahrung mit, wie lokale Open-Weights-Modelle isoliert auf eigenen GPUs betrieben, Chat-Verläufe persistent in lokalen Datenbanken gespeichert und parallele Nutzeranfragen im industriellen Betrieb fehlerfrei verarbeitet werden.
Die vorgeschlagene Architektur ist auf technologische Offenheit und Modularität ausgelegt, um die Investitionen der JEN über die nächsten 5 bis 10 Jahre hinweg abzusichern und die Wartbarkeit zu garantieren.
Austauschbarkeit der Modelle (Kein Lock-In): Die Entwicklung im Bereich der Open-Weights-Modelle verläuft rasant. Da die RAG-Pipeline modular aufgebaut ist, können die eingesetzten Kernmodelle (z. B. der Wechsel auf eine zukünftige Modellgeneration) flexibel ausgetauscht werden. Die angebundenen Datenquellen und die Rechte-Infrastruktur bleiben davon unberührt.
Standardisierte Schnittstellen (API-First): Das System basiert auf einem API-First-Ansatz und containerisierten Komponenten (Docker/Kubernetes). Dies stellt sicher, dass die Plattform unabhängig von zukünftigen Infrastruktur-Wechseln lauffähig bleibt und an künftige IT-Systeme der JEN angebunden werden kann.
Wirtschaftlichkeit und Unabhängigkeit: Da wir auf Open-Source-Modelle und eine maßgeschneiderte On-Premises-Architektur setzen, fallen keine volumenabhängigen Lizenz- oder Abfragegebühren an externe Cloud-Anbieter an. Die Betriebskosten nach der initialen Hardware-Investition sind dadurch stabil und gut kalkulierbar.
Wartbarkeit durch Eigenpersonal: Durch den Verzicht auf proprietäre Software-Monolithen ist die Plattform so aufgebaut, dass der laufende Betrieb und das Monitoring nach der Projektübergabe durch das IT-Personal der JEN administriert werden können.
Damit bleibt die JEN unabhängig von einzelnen Software-Herstellern und behält die Kontrolle über den Lebenszyklus der Anwendung.
