PARAT KnowledgeChat
Die PARAT Projektmanagement und Informationssysteme GmbH ist ein inhabergeführtes IT-Unternehmen mit Sitz in Braunschweig. Das 1992 gegründete Unternehmen beschäftigt 31 Mitarbeitende und realisiert seit über drei Jahrzehnten anspruchsvolle Digitalisierungs- und Integrationsprojekte für mittelständische und große Unternehmen. PARAT ist zertifiziert nach ISO27001, ISO9001 und TISAX-zertifiziert in den höchsten Stufen (Information High und Data High) und verfügt über einen Informationssicherheitsbeauftragten sowie einen Datenschutzbeauftragten im eigenen Haus. Diese im KMU-Segment unübliche Kombination schafft gerade in sicherheitssensitiven Umfeldern Vertrauen.
Vorgeschlagen wird die Lösung „PARAT KnowledgeChat" - eine standardnahe, modulare RAGPlattform für den sicheren „Chat mit Dokumenten" in geschützter Unternehmensumgebung. Sämtliche Verarbeitungsstufen laufen vollständig on-premise, einschließlich der lokal betriebenen LLM- und Embedding-Modelle. Den Kern bildet ein dreischichtiger Aufbau: eine gehärtete Inferenz und Sicherheitsplattform mit RBAC, manipulationssicherem Audit-Log und AD-Integration; ein Universal MCP Connector Layer, der heterogene Quellsysteme wie SharePoint, SMB-Fileshares, DMS (nscale, windream), Intranet/Wiki und relationale Datenbanken über ein einheitliches Protokoll anbindet; sowie eine RAG-Anwendungsschicht mit Qdrant-Vektordatenbank, hybrider Suche und strikt protokollierter Antwortgenerierung mit Inline-Zitaten.
Die Lösung baut auf zwei unmittelbaren Erfahrungsankern auf: einer geförderten F&E-Initiative „Lokales LLM mit MCP-Integration”, in deren Rahmen PARAT die vollständige Plattform aufgebaut hat, und einer aktuellen Pilotkunden-Partnerschaft mit einem mittelständischen Unternehmen, in der mehrere MCP-Server produktiv als Connector-Schicht gegen heterogene Quellsysteme im Einsatz sind.
Die Vision für JEN: lokale KI-Souveränität ohne Demo-Charakter - Enterprise-Betriebsstand, vollständige Datenhoheit, ein offenes Connector-Protokoll als nachhaltige Investitionsbasis und ein realistischer Pilotpfad in 8 bis 12 Wochen, der eine schrittweise Erweiterung auf den vollen JEN-Datenraum (50 TB, 350 Nutzer) ermöglicht.
PARAT KnowledgeChat folgt einer klar geschnittenen dreischichtigen Architektur, die jede Komponente austauschbar hält und einen pragmatischen Pilotbetrieb mit anschließendem stufenweisem Ausbau erlaubt.
Schicht 1 - Inferenz- und Sicherheitsplattform. Lokale GPU-Inferenz auf Open-Weight-LLMs (Llama 3.x, Mistral oder Qwen, quantisiert in 4- oder 8-Bit per GPTQ/AWQ) wird über vLLM oder TGI bereitgestellt. Ein lokales Embedding-Modell (BGE-M3 oder e5-multilingual, deutsch-optimiert) erzeugt die Vektorrepräsentationen. Die Plattform läuft auf gehärtetem Linux unter Docker- bzw. Kubernetes-Orchestrierung, durchgängig TLS-1.3-verschlüsselt, mit rollenbasierter Zugriffskontrolle (RBAC) gegen das bestehende Active Directory, manipulationssicherem Audit-Log und Prometheus/Grafana-Monitoring. Dabei werden weder externe Telemetriedaten übertragen noch besteht eine Abhängigkeit von Cloud-Diensten.
Schicht 2 - Universal MCP Connector Layer. Heterogene Quellsysteme werden nicht über fragmentierte Punkt-zu-Punkt-Konnektoren angebunden, sondern über eine einheitliche Connector-Schicht auf Basis des Model Context Protocol. Jeder Quellconnector ist ein eigenständiger MCP-Server mit standardisiertem Tool-Set: Suchen, Abrufen, Änderungen lesen, ACLs auslesen. SharePoint Online wird über die Graph API einschließlich Delta-Endpoint angebunden, SMB-Fileshares über einen lokalen Crawler unter AD-Identität mit Übernahme der NTFS-ACLs, nscale und windream über deren REST/SOAP-APIs, das Intranet/Wiki über CMS-API oder HTMLCrawl, MS SQL über direkte DB-Anbindung mit Read-Only-Views. Daraus ergibt sich eine konsistente Connector-Semantik über alle Quellen hinweg.
Schicht 3 - RAG-Anwendungsschicht. Qdrant als On-Premises-Vektordatenbank, hybride Suche (BM25 plus semantisch), Re-Ranker (z. B. bge-reranker) und LLM-gestützte Antwortgenerierung mit strikt protokollierten Prompts und Antworten. Jede Antwort enthält Inline-Zitate und eine Quellenliste mit Verweis auf Dokument, Versionsstand und, wo verfügbar, Direktlink in das Quellsystem. Bei unzureichender Quellenlage liefert das System keine spekulative Antwort, sondern eine explizite Rückmeldung („Zu Ihrer Frage liegen keine belastbaren Quellen vor"). Dieses Verhalten wird durch automatisierte Citation-Verification überprüft.
Berechtigungen (Permission-aware Retrieval). Die ACLs aus den führenden Quellsystemen werden pro Dokument-Chunk in einem strukturierten Metadaten-Feld mit-indexiert. Bei jeder Anfrage wird die AD-Gruppenmitgliedschaft des anfragenden Nutzers ausgewertet und als Pre-Filter an die Retrieval-Stufe gegeben. Eine eigene Schatten-Berechtigungsstruktur wird dadurch vermieden: Jeder Nutzer sieht ausschließlich Inhalte, für die er auch im jeweiligen Quellsystem berechtigt ist.
Dokumentenverarbeitung. Textbasierte Dokumente werden direkt extrahiert, gescannte PDFs durchlaufen eine OCR-Pipeline aus docTR, PaddleOCR und Tesseract (qualitätsabhängig automatisch gewählt). Tabellen werden mit table-transformer bzw. Camelot strukturerhaltend indexiert, Bilder und technische Zeichnungen optional über ein lokales Vision-LLM beschrieben. Sehr große Dokumente (bis ~900 Seiten) werden semantisch gechunkt mit kontextuellem Overlap und Dokumentstruktur-Erkennung. Versions-Metadaten und Content-Hashing erkennen Dubletten und steuern Aktualisierungsläufe; inkrementelle Updates erfolgen über quellsystem-spezifische Change-Feeds (SharePoint Delta, DMS-Eventlogs, SQL CDC) oder Polling.
Reifegrad. Die Lösung ist ein individuelles, konfigurierbares und modular aufgebautes Framework auf Basis produktiv erprobter Komponenten (siehe Abschnitt 1). Darunter fallen die folgenden Punkte:
Marktreif/ produktiv im Einsatz: Die Inferenz- und Sicherheitsplattform sowie der MCPConnector-Layer sind in einer aktuellen Pilotkunden-Partnerschaft mit einem mittelständischen Unternehmen produktiv im Einsatz. Dort betreibt PARAT mehrere MCP-Server parallel als Connector-Schicht gegen heterogene Quellsysteme einschließlich Qdrant-Vektordatenbank und semantischer Suche.
MVP-Reife: Das gesamte Plattform-Framework wurde im Rahmen einer geförderten F&EnInitiative „Lokales LLM mit MCP-Integration" konsolidiert und gehärtet. Die Sicherheits-, IAM- und Audit-Komponenten sind dort umfassend implementiert und dokumentiert.
Konfigurations- und Integrationsleistung: Die JEN-spezifischen Adapter (insbesondere nscale, windream, JEN-Intranet) sowie das Feintuning der OCR-Pipeline und der Prompt-Strategie auf den JEN-Domänenwortschatz sind klassische Integrationsaufwände auf vorhandener Connector-Infrastruktur und somit kein Neubau „von null".
Die Lösung ist damit produktionsreif für einen Pilotbetrieb in 8 bis 12 Wochen. Erste Markterfahrungen liegen aus dem genannten Pilotkunden-Projekt vor, das die Tragfähigkeit der Architektur unter produktiven Bedingungen bestätigt hat.
Die Architektur von PARAT KnowledgeChat deckt die in der Ausschreibung formulierten Anforderungen, wie im Folgenden dargestellt, punktgenau ab.
Lokaler Betrieb aller Verarbeitungsstufen. Sämtliche Verarbeitungsstufen, d.h. LLM-Inferenz, Embedding-Erzeugung, Vektorsuche, Re-Ranking und OCR laufen ausschließlich on-premise. Es werden keine Cloud-LLMs und keine externe Telemetrie verwendet, wodurch sämtliche Dokumentinhalte nach dem Abruf vollständig im JEN-Netz verbleiben. Einzige Ausnahme mit Internetbezug ist der lesende Zugriff auf SharePoint Online/OneDrive, der naturgemäß über die Microsoft Graph API erfolgt. Die anschließende Verarbeitung der abgerufenen Inhalte findet ausschließlich lokal statt. Für alle übrigen Quellsysteme und den gesamten Betrieb ist kein Internetzugang erforderlich.
Anbindung der konkreten JEN-Quellsysteme. Alle fünf in der Challenge genannten Startquellen werden über den MCP-Connector-Layer adressiert: SharePoint Online/OneDrive über die Graph-Delta-API mit Berechtigungs-Auflösung, SMB-Fileshares mit AD-Identität und NTFS-ACL Übernahme, nscale und windream über deren REST/SOAP-APIs unter Übernahme der dortigen Rechte- und Versionsstruktur, Intranet/Wiki über CMS-API oder HTML-Crawl, MS SQL über direkte DB-Anbindung mit Read-Only-Views. Das Anbindungsmuster ist bei einem aktuellen Pilotkunden mit mehreren parallel betriebenen MCP-Servern bereits produktiv erprobt.
AD-basierte Berechtigungs-Berücksichtigung. Die geforderte „rollen- und berechtigungsbasierte Zugriffskontrolle auf Basis vorhandener AD-Strukturen" ist als „Permission-aware Retrieval" realisiert: ACLs werden pro Dokument-Chunk aus den Quellsystemen als Metadaten mit-indexiert und bei jeder Anfrage gegen die AD-Gruppenmitgliedschaft des Nutzers unter Verwendung des nativen Payload Filters von Qdrant pre-gefiltert. D.h., die Filterung erfolgt vor dem Vektor-Retrieval, so dass keine unzulässigen Daten an das LLM gehen. Somit stellt das LLM nie die Sicherheitsgrenze dar. Durch die Mit-Indexierung der ACLs entstehen keine Schatten-Berechtigungsstrukturen. Die bestehenden Daten-Quellsysteme stellen die Single Source of Truth dar. Änderungen an Dokument-Berechtigungen in den Quellsystemen werden über die Change-Feeds zeitnah in den Index übernommen (typisch innerhalb weniger Stunden, konfigurierbar bis hin zu nächtlichen Voll-Abgleichen der ACL-Metadaten). Der Entzug einer AD-Gruppenmitgliedschaft wirkt dagegen unmittelbar bei der nächsten Anfrage, da die Gruppenauflösung zur Laufzeit erfolgt. Für besonders sensible Quellbereiche kann optional eine Live-Verifikation gegen das Quellsystem vor der Antwortausgabe aktiviert werden.
Heterogene Dokumenttypen und große Dokumente. Die benannten Dokumenttypen (textbasierte und gescannte PDFs, Office, Tabellen, Bilder, Zeichnungen) werden über eine differenzierte Pipeline abgedeckt (OCR-Stack docTR/PaddleOCR/Tesseract, table-transformer, optional Vision-LLM). Die explizit erwähnten Dokumente bis ca. 900 Seiten werden über semantisches Chunking mit Dokumentstruktur-Erkennung handhabbar gemacht.
Versionierung, Dubletten, Inkrementalität. Die hervorgehobenen hohen Versionierungs- und Dublettenanteile werden durch Content-Hashing und Versions-Metadaten mit Aktualitäts-Boost abgebildet. Inkrementelle Updates erfolgen über Change-Feeds (SharePoint Delta, DMS-Eventlogs, SQL CDC).
Quellenbasierte, nachvollziehbare Antworten. Die protokollierten Prompts und Antworten mit automatisierter Citation-Verification adressiert die zentral geforderte transparente Reaktion bei unzureichender Quellenlage. Ob eine unzureichende Quellenlage vorliegt, kann z.B. mit Hilfe des „semantic similarity scores“ ermittelt werden. In diesem Fall meldet das System explizit zurück, dass keine belastbaren Quellen vorliegen. Halluzinationen werden dadurch minimiert.
Modulare, austauschbare Architektur. Die betonte Zukunftsfähigkeit ist Architekturprinzip: LLM, Embedding-Modell, Re-Ranker, OCR-Engine, Vektor-DB und Connectoren sind unabhängig austauschbar. Das offen dokumentierte Model Context Protocol verhindert Vendor-Lock-in auch auf Protokoll-Ebene.
Skalierbarkeit auf den JEN-Datenraum. Vom Pilot-Single-Node über Multi-Node-Cluster mit Qdrant-Sharding und mehreren Inferenz-Replikas. Die Zielwerte (350 Nutzer, 30 parallele Anfragen, 50 TB, 1 Mio. Dokumente) sind mit zwei bis drei GPU-Inferenz-Knoten realistisch zu bedienen.
Pilotpfad in 8-12 Wochen. Der gewünschte Zeitrahmen passt genau zum Vorgehensmodell mit Setup (Wo. 1-2), Aufbau (Wo. 3-6), Pilotbetrieb (Wo. 7-10) und Auswertung (Wo. 11-12). Spätere stufenweise Ausbaufähigkeit ist Teil des Architekturentwurfs.
Sicherheit und Governance. Manipulationssicheres Audit-Log, Backup/Restore, Prompt-Injection-Härtung, Output-Filter und Defense-in-Depth adressieren die ausdrücklich genannten Themen Logging, Auditierbarkeit, Datenabfluss, Prompt Injection und unberechtigte Ausgabe sensibler Inhalte vollständig.
Im Standard abgedeckt (produktiv aus Pilotbetrieb)
Folgende Bausteine sind aus dem Pilotkunden-Projekt und der F&E-Initiative produktionsreif vorhanden und werden ohne Neuentwicklung übernommen:
Lokale GPU-Inferenz mit Open-Weight-LLMs (Llama 3.x, Mistral, Qwen) über vLLM/TGI inkl. Quantisierung
Lokales Embedding-Modell (BGE-M3 o. vergl.), deutschoptimiert
Qdrant-Vektordatenbank mit Sharding-Option, hybride Suche (BM25 plus semantisch), Re-Ranker
MCP-Connector-Framework mit standardisiertem Tool-Set (Suchen, Abrufen, Änderungen lesen, ACLs auslesen)
Belegpflichtige Antwortgenerierung mit Inline-Zitaten und automatisierter Citation-Verification
Transparente Rückmeldung bei unzureichender Quellenlage
Permission-aware Retrieval mit ACL-Mit-Indexierung und AD-Gruppenauflösung
Sicherheits-Stack: TLS-1.3, RBAC, manipulationssicheres Audit-Log, Prompt-Injection-Härtung, Backup/Restore
Monitoring (Prometheus/Grafana), Container-Orchestrierung (Docker/Kubernetes)
MS-SQL-Connector aus Pilotkunden-Projekt direkt übernehmbar
Erweiterte Konfiguration (Standard vorhanden, JEN-spezifisches Mapping)
SharePoint Online / OneDrive - generischer Graph-API-Connector inkl. Delta-Endpoint vorhanden; JEN-Tenant-App-Registrierung und ACL-Mapping in Pilot-Woche 3-4
SMB-Fileshares - Crawler mit NTFS-ACL-Übernahme vorhanden; JEN-Share-Layout und ADGruppen-Mapping in Pilot-Woche 4-5
Intranet/Wiki - HTML-Crawl-Framework vorhanden; CMS-spezifische Anpassung in Pilot-Woche 5-6
Integrationsleistung (echte Neuentwicklung)
Transparenz: Für folgende Punkte ist neuer Code zu schreiben - aber als API-Adapter auf vorhandener Connector-Infrastruktur, kein konzeptioneller Neubau.
nscale-Adapter über nscale REST-API - ca. 3-4 PW, Pilot-Woche 4-7
windream-Adapter über windream Webservices - ca. 3-4 PW, parallel Pilot-Woche 4-7
OCR-Tuning auf JEN-Dokumentenbestand (alte Strahlenschutzunterlagen, technische Zeichnungen) - iterativ Pilot-Woche 6-9
Domänenspezifisches Prompt- und Chunking-Tuning auf JEN-Wortschatz (Strahlenschutz, Rückbau, Dekontamination) - laufend Pilot-Woche 6-10
Offene Punkte mit klarem Ausbaupfad
Bewusst nicht im Pilot, sondern in Ausbaustufen vorgesehen:
Hochverfügbarkeit / Multi-Node-Cluster - im Pilot Single-Node mit Backup. Multi-Node mit Qdrant-Sharding und Inferenz-Replikas in erster Ausbaustufe (Monate 4-7 nach Pilotende)
Vollausbau auf 50 TB / 1 Mio. Dokumente - Pilot ca. 1 TB / 1-2 Quellsysteme. Stufen: 10 TB / 3 Quellsysteme / 100 User (Monate 4-9), Vollausbau 50 TB / 350 User (Monate 10-18). Architektur erlaubt Skalierung ohne Re-Engineering.
Vision-LLM für Bilder/Zeichnungen - optionale Komponente (Qwen-VL, LLaVA lokal), Aktivierung nach Pilot-Bedarfsanalyse
PII-Erkennung und Redaktion - optional verfügbar, Aktivierung nach JEN-Datenkategorien-Bewertung
Automatisches Prompt Rewriting – optional verfügbar, um unabhängiger von den Prompt-Kenntnissen des Fragenstellers zu sein. Unter Einbezug von „context engineering“ durch z.B. Frageverlauf des Nutzers und Rolle des Nutzers, etc.
Agentic RAG Workflows -Ausbau nach Pilot bedarfsabhängig: Durchführung von Mehrschritt-RAG-Anfragen, automatisch eingeleitet bei unzureichender Antwortqualität. Dies ist besonders bei komplexen und für klassische RAG-Systeme schwer zu beantwortende Fragen wie „Zusammenfassung von Dokument abc“, oder „was ist nicht in Dokument xyz enthalten?“ relevant. Abhängig von der Frage kann der Agent durch die vorgesehene universelle MCP-Schnittstelle zu den Datenquellen bei Bedarf mehr Kontext suchen, um die Frage korrekt zu beantworten.
Zeitplan
Setup (Pilot-Woche 1–2): Scoping, Aufbau des Test-Korpus und Priorisierung der Quellsysteme.
Aufbau (Pilot-Woche 3–6): Anbindung von 1–2 Quellsystem-Connectoren, parallel dazu Entwicklung der nscale-/windream-Adapter.
Pilotbetrieb (Pilot-Woche 7–10): OCR- und Prompt-Tuning sowie Test mit 10–20 Anwendern.
Auswertung (Pilot-Woche 11–12): Verfeinerung des Sizings und Erstellung der Ausbau-Roadmap.
Erste Ausbaustufe (Monate 4–9): Anbindung von 3 Quellsystemen, Vorbereitung des Multi-Node-Betriebs und Roll-out auf 100 User.
Vollausbau (Monate 10–18): 50 TB Datenvolumen, 350 User, 30 parallele Anfragen und Multi-Node-Cluster.
Kritische Risiken und Gegenmaßnahmen
DMS-API-Reife (nscale/windream) - Qualität variiert je Version. Mitigation: technische Klärung der API-Version in Pilot-Woche 1-2 vor Adapter-Entwicklung
OCR-Qualität auf historischen Unterlagen - Mitigation: gestufter OCR-Stack mit Qualitäts-Scoring und Fallback; Pilot-Korpus enthält anspruchsvolle Samples
Antwortqualität im Nukleartechnik-Wortschatz - Mitigation: domänenspezifisches Prompt-Engineering, Fachexperten-Feedback als Optimierungssignal; bei Bedarf Wechsel auf größeres Modell (LLama 70B) oder domänenspezifisches Fine-Tuning - ohne Architekturänderung
Betriebsmodell: On-Premises
Die Lösung wird ausschließlich on-premises in der JEN-Umgebung betrieben - SaaS und Hybrid scheiden konzeptionell aus. Sämtliche Komponenten (LLM-Inferenz, Embedding, Vektorsuche, Re-Ranking, OCR) laufen vollständig im JEN-Netz. Ein Internetzugang kann technisch vorhanden sein, ist für den Betrieb aber nicht erforderlich. Hosting wahlweise auf JEN-eigener Hardware oder optional in einer von PARAT bereitgestellten Single-Tenant-Umgebung in einem zertifizierten deutschen Rechenzentrum.
Integrationsaufwand
Der PARAT-seitige Pilot-Aufwand liegt bei rund 70 bis 110 Personentagen, eingebettet in das 8- bis 12-wöchige Pilotfenster mit paralleler Arbeit mehrerer Rollen. Kernblöcke: Infrastruktur-Setup und Härtung (5-8 PT), LLM-Plattform-Installation (3-5 PT), AD- und IAM-Anbindung (2-4 PT), Connector-Konfiguration für Standardquellen wie SharePoint, SMB und MS SQL (3-5 PT je Quelle), Adapter-Entwicklung für nscale und windream (jeweils 15-20 PT), Initial-Ingest und Indexierung * (5-10 PT), OCR-Pipeline-Tuning und domänenspezifisches Prompt-Tuning (jeweils 5-10 PT iterativ), Pilotbetrieb-Begleitung und Auswertung (10-15 PT). JEN-seitige Mitwirkung: ein technischer Single Point of Contact (ca. 1 Tag pro Woche), 4 bis 6 Fachexperten für Qualitätsbewertung (je 3-5 Tage über die Pilotlaufzeit, konzentriert in Woche 2 und Woche 7-10), AD-Berechtigung für PARAT-Personal oder eine gespiegelte Testumgebung, Bereitstellung der Pilot-Hardware und API-Zugänge mit lesendem Zugriff auf den Pilot-Korpus.
*Der Initial-Ingest des vollen JEN-Datenraums ist ein einmaliger, im Hintergrund laufender Vorgang: Bei 1 Mio. Dokumenten mit durchschnittlich 15–25 Seiten (ca. 20 Mio. Seiten) und einer Indexierungsleistung von rund 200.000 Seiten pro Tag auf einem dedizierten Ingest-Knoten ergibt sich eine Laufzeit von etwa 3–4 Monaten; durch Parallelisierung über mehrere Ingest-Knoten ist diese Dauer nahezu linear verkürzbar. Der interaktive Betrieb auf bereits indexierten Beständen ist davon unberührt. Neue Inhalte werden fortlaufend nutzbar, sobald sie indexiert sind.
Pilotvorgehen (Proof of Concept in 8-12 Wochen)
Der Pilot ist als strukturierter Proof of Concept aufgesetzt, der am Ende belastbare Aussagen für die JEN-Entscheidung über einen Vollausbau erlaubt - kein unverbindlicher Showcase.
Woche 1 - Setup-Workshop. Auftakt mit JEN-Fachverantwortlichen und JEN-IT: Festlegung des Pilot-Korpus (Empfehlung: ein abgegrenzter Themenbereich aus dem Strahlenschutz- oder Rückbau-Umfeld mit ca. 1 TB aus 1-2 Quellsystemen), Auswahl der priorisierten Quellsysteme, Definition eines Qualitäts-Fragenkatalogs mit 50-100 typischen Fragen aus dem JEN-Alltag, Festlegung der Erfolgskriterien.
Woche 2 - Scoping und Hardware. Klärung der konkreten Quellsystem-API-Versionen (insbesondere nscale, windream), Hardware-Bereitstellung, AD- und Berechtigungs-Setup, Auswahl des LLM für die erste Iteration. Hardware muss bis Ende Woche 2 betriebsbereit sein.
Woche 3-6 - Aufbau. Parallele Arbeitsströme: Infrastruktur-Installation, Connector-Konfiguration für Standardquellen, Entwicklung der DMS-Adapter (nscale, windream), AD-Anbindung, Initial-Ingest des Pilot-Korpus. Erste Ende-zu-Ende-Testläufe ab Woche 5.
Woche 7-10 - Pilotbetrieb. Begleiteter Testbetrieb mit 10 bis 20 JEN-Anwendern aus dem Expertenkreis. Wöchentliche Iteration: Auswertung gegen den Fragenkatalog, OCR- und Prompt Tuning, Feedback-Integration. Daumen-hoch/-runter-Feedback pro Antwort fließt in das Qualitäts-Monitoring. Wöchentliche Status-Termine mit dem JEN-SPOC.
Woche 11-12 - Auswertung und Roadmap. Quantitative und qualitative Auswertung gegen die Erfolgskriterien: Antwortqualität, Latenz und Durchsatz, Berechtigungs-Korrektheit (Stichprobenprüfung), Indexierungsleistung und Ressourcenauslastung. Ergebnis: Pilot-Abschlussbericht mit Sizing-Verfeinerung für den Vollausbau und Empfehlung für die nächsten Ausbaustufen.
Erfolgskriterien (Vorschlag, im Setup-Workshop zu schärfen): ≥ 80 % korrekt belegte Antworten laut JEN-Fachexperten-Bewertung; < 5 % Halluzinationen; 100 % Berechtigungs-Korrektheit in der Stichprobenprüfung; durchschnittliche Antwortlatenz < 10 Sekunden; Indexierungsleistung ≥ 100.000 Seiten pro Tag auf Pilot-Hardware.
Übergang in den Regelbetrieb
Nach erfolgreicher Pilotabnahme stehen zwei kombinierbare Anschluss-Modelle zur Wahl: vollständige Plattform-Pflege durch PARAT (Modell-Updates, Komponenten-Pflege, Sicherheits-Updates, Connector-Wartung mit optionalen SLAs) oder eigenständiger Betrieb durch die JEN-IT mit PARAT als Second-Level-Support. Im zweiten Fall stellt PARAT ein Knowledge-Transfer-Paket bereit, das die JEN-IT in die Lage versetzt, Routine-Tätigkeiten (Connector-Status, Re-Indexierung, Modell-Update) eigenständig zu übernehmen. Die Entscheidung kann nach dem Pilot ohne Architektur-Änderung getroffen werden.
Vorbemerkung
Die folgenden Werte sind grobe Architektur-Hausnummern, basierend auf Erfahrungswerten aus dem laufenden Pilotkunden-Projekt und dem F&E-Vorhaben. Eine belastbare Detail-Dimensionierung erfolgt im Pilot-Setup auf Basis der konkreten Korpus-Eigenschaften (Dokumentanteile, OCR-Bedarf, durchschnittliche Dokumentgröße, Abfragehäufigkeit). Wo Spannen genannt sind, entscheidet die Modellwahl (Llama 8B vs. 70B) bzw. der Redundanzanspruch über die obere Grenze.
Drei Ausbaustufen
Die Lösung skaliert in klar abgegrenzten Stufen. Cloud-Ressourcen sind nicht vorgesehen - sämtliche Werte beziehen sich auf On-Premises-Hardware in der JEN-Umgebung.
Stufe 1 - Pilot (10-20 User, 1-2 Quellsysteme, ca. 1 TB Korpus)
1x GPU-Server
für lokale Inferenz eines Llama 3.1 8B bzw. Mistral-Modells in Quantisierung 4-/8-Bit mit ausreichender Reserve für Embedding-Erzeugung und Re-Ranker.
Stufe 2 - Erste Ausbaustufe (ca. 100 User, 3 Quellsysteme, ca. 10 TB Korpus)
2x GPU-Server
Separater Storage-Knoten für Dokumenten- und Index-Daten, ausgelegt auf 15-20 TB Nutzkapazität (Rohbedarf inkl. Index, Embeddings, Versionsstände und Reserve).
Separater Qdrant-Knoten oder Container für die Vektor-Datenbank.
Stufe 3 - Vollausbau (350 User, 30 parallele Anfragen, 50 TB, 1 Mio. Dokumente)
2–3x GPU-Server (3–4 GPUs der H200-Klasse bzw. 6–8 GPUs älterer Generationen, abhängig von Modellwahl und gewünschter Antwortlatenz). Bei Einsatz eines Llama 3.3 70B empfiehlt sich die H200-Klasse (141 GB HBM3e), da das Modell in FP8 auf einer einzelnen Karte läuft. Qdrant-Cluster mit Sharding über 2-3 Knoten für Skalierung der Vektorsuche.
Dedizierter Ingest- und Indexierungs-Knoten für inkrementelle Aktualisierungsläufe ohne Belastung der Inferenz-Knoten.
Storage-Pool für 50 TB Nutzkapazität - Brutto-Bedarfe nach RAID/Replikations-Setup ca. 70-90 TB. Empfehlung: NVMe für Index- und Hot-Daten, SATA/SAS für Kalt-Daten.
Backup-Knoten für tägliche Sicherung von Vektor-DB, Konfiguration und Audit-Log.
Die Pilot-Hardware (Stufe 1) ist mit ca. 25.000 bis 50.000 € anzusetzen und im Vollausbau weiterverwendbar. Indikatives Hardware-Budget für den Vollausbau: je nach Modellwahl und Redundanzanspruch im Bereich von ca. 200.000 bis 450.000 € netto. Die untere Grenze entspricht einer Konfiguration mit GPUs der L40S-/RTX-Pro-Klasse für Modelle bis 8B–14B Parameter; die obere Grenze einer Ausstattung mit 3–4 GPUs der H200-Klasse (141 GB HBM3e), die den Betrieb eines Llama 3.3 70B in FP8 auf einer einzelnen Karte erlaubt.
Darin enthalten sind GPU-Inferenz-Server, Qdrant-Cluster, dedizierter Ingest-Knoten, Storage-Pool (70–90 TB brutto, NVMe/SAS gemischt), Backup-Knoten und 10-GBit-Netzwerkinfrastruktur. Die Schätzung basiert auf Richtwerten mit Stand Anfang Juni 2026. Eine belastbare Detailkalkulation erfolgt nach der Sizing-Verfeinerung am Ende des Pilots.
Speicherplatz - Rechengrundlage
Der Speicherbedarf setzt sich aus mehreren Komponenten zusammen, die typischerweise wie folgt skalieren:
Roh-Dokumente: 50 TB im Vollausbau (laut Challenge).
Extrahierte Text-Repräsentation und Metadaten: ca. 5-8 % des Roh-Volumens, also rund 2,5-4 TB.
Vektor-Embeddings (BGE-M3 mit 1024 Dimensionen): grob 5-10 GB pro Million Chunks; bei 1 Mio. Dokumenten und durchschnittlich 10-20 Chunks pro Dokument ergibt das 50-200 GB Vektor-Index.
OCR-Cache (zur Vermeidung wiederholter OCR-Läufe): 5-10 % des Roh-Volumens für gescannte Anteile, ca. 1-3 TB.
Audit-Log, Konfiguration, Backup-Stände: zusätzlich ca. 2-5 TB. In Summe liegt der reine Nutzdaten-Bedarf bei rund 55-65 TB; das oben genannte Brutto-Sizing von 70-90 TB berücksichtigt Redundanz und Wachstumsreserve.
Bandbreite und Netz
Innerhalb des JEN-Netzes zwischen Inferenz-, Storage- und Vektor-DB-Knoten: 10-GBit-Verbindungen empfohlen, insbesondere für Index-Aufbau und Multi-Node-Betrieb.
Anbindung an die Quellsysteme (SharePoint, SMB, DMS, MS SQL): Standard-LAN ausreichend; Last entsteht primär beim Initial-Ingest und bei inkrementellen Update-Läufen, nicht im interaktiven Betrieb.
Anbindung der Endnutzer: keine besonderen Anforderungen, klassische Web-Last (HTTPS) im Bereich weniger MBit/s pro aktiver Anfrage.
Externe Bandbreite: nicht erforderlich; das System arbeitet ohne Internetzugang. Optional kann ein gesicherter Update-Pfad für Modell- und Komponenten-Updates eingerichtet werden.
Lastannahmen für die Sizing-Logik
Die obigen Werte basieren auf folgenden typischen Lastannahmen, die im Pilot-Setup mit JEN konkretisiert werden:
30 parallele interaktive An
fragen im Vollausbau.
Durchschnittliche Anfragedauer Ende-zu-Ende: 5-10 Sekunden auf konfiguriertem Stack.
Indexierungsleistung: 100.000-300.000 Seiten pro Tag auf einem dedizierten Ingest-Knoten.
Inkrementelle Aktualisierungsläufe: nächtlich bzw. ereignisgetrieben über Change-Feeds, geringe Tageslast.
OCR-Last konzentriert beim Initial-Ingest gescannter Bestände; danach nur für neu hinzukommende Scans.
Praxisanker 1 - Laufende Pilotkunden-Partnerschaft (Mittelstand, e-Commerce)
PARAT realisiert aktuell ein KI-gestütztes Lagerverwaltungs- und Prognosesystem mit intelligenter Alternativempfehlung im Onlineshop bei einem mittelständischen Unternehmen mit Sitz in Braunschweig. Dieses Projekt ist die direkteste technische Vorlage für die JEN-Challenge, weil dort genau die Architekturschichten produktiv aufgebaut sind, die auch für JEN den Kern bilden:
Mehrere produktive MCP-Server als Connector-Schicht gegen heterogene Quellsysteme - konkret gegen MS SQL Server, e-Commerce-Plattform sowie Data-Prep- und ML-Pipelines. Damit ist genau der Architekturkern „Universal MCP Connector Layer”, den wir für JEN vorschlagen, kein Konzept, sondern laufender Betrieb.
Lokaler LLM-Stack mit On-Premises-Inferenz und Qdrant-Vektordatenbank inklusive semantischer Suche.
Belastbare Betriebs-Eigenschaften: erweitertes Monitoring mit Accuracy-Dashboard, Testsuite mit ≥ 80 % Code Coverage, Last- und Performance-Tests sowie finales Security-Audit.
Praxisanker 2 - Geförderte F&E-Initiative „Lokales LLM mit MCP-Integration"
Innerhalb dieses laufenden, öffentlich geförderten Vorhabens hat PARAT die vollständige Plattformschicht aufgebaut, die für die JEN-Lösung den sicherheits- und betriebsseitigen Unterbau bildet:
Lokale GPU-Inferenz auf Open-Weight-Modellen mit Quantisierung und Optimierung.
Sicherheits- und Compliance-Layer: RBAC, manipulationssicheres Audit-Log, IAM-Integration, DSGVO-Konformitätsmodell.
MCP-Schnittstellenentwicklung als wiederverwendbares Framework.
Penetrationstest-Erfahrung und gehärtete Container-Orchestrierung.
Einordnung
Eine 1:1 Referenz für die Lösung der Challenge haben wir, wie auch aktuell kein Anbieter im Markt der lokal betriebenen, sicherheitsgehärteten Lösungen, nicht vorliegen. Wir bieten eine in den Kernkomponenten produktiv erprobte Plattform plus ergänzende dreißigjährige Erfahrung in Integration, AD-Anbindung und sicherheitskritischem Betrieb unter TISAX-Vorgaben. Der Pilotbetrieb dient genau dem Zweck, die Übertragbarkeit auf die JEN-spezifischen Bedingungen unter realen Lastbedingungen zu validieren - mit klar definierten Erfolgskriterien und ohne Versprechen, die wir nicht durch laufende Praxis belegen können.
Architekturprinzipien als Zukunftssicherheits-Fundament
Die Zukunftssicherheit von PARAT KnowledgeChat ist durch drei Architekturprinzipien abgesichert:
Strikte Modularität. Jede Schicht (Inferenz, MCP-Connector-Layer, RAG-Anwendung) und jede Komponente innerhalb der Schichten (LLM, Embedding-Modell, Re-Ranker, OCR-Engine, Vektor-Datenbank, Connectoren) ist über dokumentierte Schnittstellen abgegrenzt und unabhängig austauschbar. Ein neueres LLM ersetzt das vorherige, ohne Eingriff in die Connector-Schicht; ein zusätzliches Quellsystem wird durch einen weiteren MCP-Server angeschlossen, ohne dass Anwendungs- oder Sicherheitsschicht angepasst werden müssen.
Open-Source-Fundament. Sämtliche Kernkomponenten sind Open Source bzw. Open-Weight mit kommerziell nutzbaren Lizenzen, inklusive aktiver Community und langer Release-Historie. Es besteht keine Abhängigkeit von proprietären Cloud-APIs oder lizenzpflichtigen Modellen. Konfiguration und Daten bleiben jederzeit exportierbar.
Offener Connector-Standard. Das Model Context Protocol ist offen dokumentiert und gewinnt branchenweit zunehmend an Adoption. Damit besteht auch auf Protokoll-Ebene kein Vendor-Lock-in weder auf PARAT noch auf eine spezifische LLM-Familie.
Umgang mit technologischen Trends
LLMs entwickeln sich derzeit etwa im Quartalsrhythmus weiter. Diese Geschwindigkeit ist für die Lösung kein Risiko, sondern eingeplant:
Modell-Refresh als Routine-Tätigkeit. Ein Modell-Tausch erfolgt innerhalb weniger Personentage, inklusive A/B-Validierung gegen den bestehenden Test-Korpus. Das Verfahren ist Teil der dokumentierten Routine-Tätigkeiten.
Architektur-Sprünge bleiben möglich. Größere Wechsel - etwa zu Mixture-of-Experts-Modellen, Long-Context-Modellen mit deutlich höheren Kontextfenstern, multimodalen Modellen oder spezialisierten Reasoning-Modellen - sind ohne Architekturänderung integrierbar, weil die Anwendungsschicht vom konkreten Modell entkoppelt ist.
Connector-Standard wächst mit dem Ökosystem. MCP entwickelt sich aktuell zum etablierten Connector-Protokoll für KI-Systeme. Sollte sich die Standardisierungslandschaft verändern, ist der MCP-Layer als Adapter-Schicht selbst kapselbar und ersetzbar.
Roadmap der nächsten Jahre
Die Weiterentwicklung der Plattform folgt drei aufeinander aufbauenden Linien:
Jahr 1 - Konsolidierung. Vertiefung der DMS-Connectoren, Multi-Node-Cluster-Reife, Härtung der Permission-aware-Retrieval-Logik gegen Edge-Cases, erweiterte Audit- und Compliance-Funktionen, multimodale Verarbeitung (Bilder, technische Zeichnungen) als Standardkomponente.
Jahr 2-3 - Agentic RAG Workflows und strukturierte Ausgaben. Mehrschritt-Anfragen über mehrere Quellsysteme, strukturierte Antworten (z. B. tabellarische oder formularbasierte Ausgaben), aktive Benachrichtigungen bei Änderungen im Datenbestand, optionale domänenspezifische Fine-Tunings.
Jahr 4-5 und darüber hinaus. Integration neuerer Architekturparadigmen (z. B. langkontextfähige oder kompositorische Modelle), erweiterte Wissensgraph-Anreicherung des RAG-Layers, vertiefte Self-Service-Funktionen für JEN-IT (Connector-Templates, Modell-Marketplace, automatisierte Qualitätsregression).
Bestandsschutz und Wartbarkeit über 5-10 Jahre
Vier Faktoren sichern die Wartbarkeit über einen langen Zeitraum:
Versionierte und dokumentierte Konfiguration. Sämtliche Einstellungen, Prompt-Vorlagen, Connector-Konfigurationen und Berechtigungs-Mappings sind in versionierbaren Files abgelegt. Ein Wechsel der Ansprechpersonen, auf JEN- wie auf PARAT-Seite, führt nicht zum Verlust impliziten Wissens.
Optionaler Knowledge-Transfer an JEN-IT. Ein Knowledge-Transfer-Paket versetzt die JEN-IT in die Lage, Routine-Tätigkeiten (Connector-Status, Re-Indexierung, Modell-Update) eigenständig zu übernehmen. Pflegevertrag-Abhängigkeit lässt sich damit gezielt minimieren.
Anbieterwechsel ohne Wegwerfen. Da Konfiguration und Daten exportierbar sind und das Fundament aus Open-Source-Komponenten und offenen Standards besteht, wäre selbst ein vollständiger Anbieterwechsel ohne Verlust der bisherigen Investition möglich.
PARAT als langfristiger Partner. PARAT ist seit 1992 als inhabergeführtes IT-Unternehmen fest etabliert am Markt und beständig in einem sich durch KI rapide wechselndem Anbietermarkt, Pflege und Weiterentwicklung erfolgen mit Bestandsschutz für JEN-spezifische Konfigurationen.
Wirtschaftliche Zukunftssicherheit
Die Kostenstruktur ist nutzerzahl-unabhängig: keine Pro-User-Lizenzkosten, Kosten skalieren mit Infrastruktur und Anzahl der angebundenen Quellsysteme. Jeder zusätzliche Anwendungsfall auf der bestehenden Plattform (sei es ein weiteres Quellsystem, ein neuer Use-Case oder ein anderes Frontend) verursacht marginale Mehrkosten, weil die Connector- und Plattformschicht wiederverwendet wird. Das macht die Plattform über die Jahre nicht teurer, sondern relativ günstiger pro Anwendungsfall.
