Omnifact Knowledge – On-Premises RAG für die JEN
Omnifact GmbH ist ein 2023 gegründetes Frankfurter Technologieunternehmen, das sich auf datenschutzkonforme KI-Lösungen für Unternehmen und Behörden spezialisiert hat. Die Plattform ist seit 2026 nach ISO/IEC 27001:2022 zertifiziert und wird bereits von öffentlichen Auftraggebern wie der Bundesrepublik Deutschland Finanzagentur, mehreren Stadt- und Kreisverwaltungen sowie Stadtwerken produktiv eingesetzt.
Die angebotene Lösung: Omnifact Knowledge
Omnifact bietet mit Omnifact Spaces eine produktionsreife RAG-Plattform (Retrieval Augmented Generation), die Mitarbeitende in die Lage versetzt, interne Dokumente und Wissensdatenbanken per natürlichsprachlicher Suche zu erschließen, mit klarem Quellenbezug, nachvollziehbaren Antworten und vollständiger Datensouveränität.
Für die JEN wird die Lösung als vollständig On-Premises betriebene Installation bereitgestellt: Alle Verarbeitungsstufen, Dokumentenextraktion, OCR, Chunking, Embedding, Vektorindizierung und Inferenz, laufen ausschließlich auf kundeneigener Infrastruktur. Es werden wenn gewünscht ausschließlich lokal betriebene Open-Source-Modelle eingesetzt und kein Unternehmensinhalt verlässt das interne Netzwerk.
Die Plattform unterstützt semantische und klassische Suche, verarbeitet textbasierte und gescannte PDFs, Office-Dokumente, Tabellen und Bilder, berücksichtigt AD-basierte Rollen- und Berechtigungsstrukturen und liefert quellenbasierte Antworten mit transparentem Umgang bei unzureichender Quellenlage.
Vision
Omnifact verfolgt das Ziel, KI im Unternehmensumfeld so zugänglich wie nötig und so datenschutzkonform wie möglich zu machen, ohne Vendor-Lock-in, mit modularer Architektur und einem klaren Pfad vom Pilotbetrieb zur unternehmensweiten Einführung.
Lösungsansatz: On-Premises RAG auf Basis von Omnifact Spaces
Omnifact Spaces ist eine vollständig produktionsreife RAG-Plattform (Retrieval Augmented Generation), die intern entwickelt und in einer modularen Microservice-Architektur bereitgestellt wird. Die Lösung wird für die JEN als vollständige On-Premises-Installation betrieben, ohne Abhängigkeit von externen Cloud-Diensten oder Drittanbietern für die Datenverarbeitung.
Technisches Funktionsprinzip
Die Verarbeitung erfolgt in einer mehrstufigen Pipeline:
Dokumentenaufnahme und -extraktion: Unterstützte Formate umfassen textbasierte und gescannte PDFs, Word-, PowerPoint- und OpenDocument-Formate, Tabellenformate (CSV, XLSX), Markdown, JSON sowie Bilddateien. Gescannte Dokumente werden über ein vollständig lokal betriebenes OCR-Modell erschlossen.
Chunking und Validierung: Extrahierte Inhalte werden in semantisch zusammenhängende Abschnitte aufgeteilt und validiert. Dabei werden Dokumentstruktur und Metadaten erhalten.
Embedding und Vektorindizierung: Die Textabschnitte werden durch ein lokal betriebenes Embedding-Modell in Vektorrepräsentationen überführt und in einem Vektorindex gespeichert. Ergänzend steht eine klassische Volltextsuche zur Verfügung; beide Suchverfahren werden hybrid kombiniert eingesetzt.
Retrieval und Antwortgenerierung: Eingehende Nutzeranfragen werden vektorisiert, semantisch relevante Dokumentenabschnitte werden abgerufen und als Kontext an das lokal betriebene LLM übergeben. Die Antwort enthält automatisch Quellenangaben mit Referenz auf das Ursprungsdokument und die betreffende Textstelle.
Transparenz bei fehlender Quellenlage: Das System ist so konfiguriert, dass Antworten ohne hinreichende Dokumentengrundlage nicht halluziniert, sondern explizit als nicht belegbar ausgewiesen werden.
Lokale Modelle und Infrastruktur
Für den On-Premises-Betrieb werden ausschließlich lokal betriebene Open-Source-Modelle eingesetzt, sowohl für Embedding (z. B. multilingual-e5, BGE-M3) als auch für Inferenz (z. B. Mistral, LLaMA-Familie, usw.). Die Auswahl der Modelle erfolgt gemeinsam mit der JEN im Rahmen des Pilots auf Basis von Leistungsanforderungen, Hardware-Ausstattung und Sprachqualität (Deutsch). Alle Modelle sind austauschbar, ohne die übrige Systemarchitektur zu verändern.
Berechtigungen und Zugriffskontrolle
Omnifact unterstützt SAML 2.0 einschließlich Azure Active Directory / Microsoft Entra ID. Spaces können so konfiguriert werden, dass der Zugriff auf Dokumentenbestände rollen- und gruppenbasiert gesteuert wird. Die Verknüpfung mit AD-seitigen Berechtigungsstrukturen wird im Rahmen der Integration konfiguriert.
Reifegrad
Omnifact Spaces ist ein marktreifes Standardprodukt, das sich seit 2023 im produktiven Einsatz bei mehreren Kunden befindet, darunter die S-Kreditpartner GmbH mit über 700 Nutzenden, die Bundesrepublik Deutschland Finanzagentur sowie mehrere kommunale Verwaltungen. Die Plattform ist ISO/IEC 27001:2022-zertifiziert (seit 2026) und verfügt über dokumentierte SLAs, Support-Prozesse und ein etabliertes Release-Management. Der On-Premises-Betrieb mit lokalen Modellen wird aktiv als Betriebsmodell unterstützt und befindet sich ebenfalls im produktiven Einsatz bei datenschutzsensitiven Kunden.
Omnifact Knowledge als passgenaue Antwort auf die JEN-Anforderungen
Die JEN beschreibt einen Einsatzfall, der in seiner Kombination aus Sicherheitsanforderungen, Quellenvielfalt und operativer Sensibilität zu den anspruchsvollsten Szenarien für eine KI-gestützte Wissenserschließung zählt. Omnifact Knowledge ist für genau diesen Typus von Einsatzfall konzipiert.
On-Premises und vollständige Datensouveränität
Die JEN-Anforderung nach lokalem Betrieb aller Verarbeitungsstufen ist für Omnifact ein etabliertes Betriebsmodell. Extraktion, OCR, Chunking, Embedding, Vektorindizierung und Inferenz laufen vollständig auf kundeneigener Infrastruktur. Kein Unternehmensinhalt verlässt das interne Netzwerk, auch nicht in anonymisierter oder aggregierter Form. Dies entspricht direkt der im Aufruf formulierten Anforderung, dass ein vorhandener Internetzugang die Vertraulichkeit der Unternehmensdaten nicht gefährden darf.
Reguliertes Umfeld als bekannte Größe
Omnifact ist in regulierten und datenschutzsensitiven Umgebungen zu Hause: öffentliche Verwaltungen, Finanzdienstleister, kommunale Unternehmen. Die ISO/IEC 27001:2022-Zertifizierung, dokumentierte TOMs, DSGVO-konforme Betriebsprozesse und ein etabliertes ISMS sind nachweisbar vorhanden. Für die JEN als kerntechnischen Betreiber mit entsprechenden Compliance-Anforderungen ist dies eine wesentliche Voraussetzung – die Omnifact ohne zusätzlichen Aufwand erfüllt.
AD-Integration und Berechtigungsberücksichtigung
Die bestehende Active-Directory-Infrastruktur der JEN wird nativ unterstützt. Über SAML 2.0 und Microsoft Entra ID / Azure AD werden Nutzergruppen und Rollen direkt übernommen. Die Zuordnung von Dokumentenbeständen zu Spaces und damit zu Nutzergruppen, bildet die vorhandenen Berechtigungsstrukturen technisch nach, ohne ein paralleles Berechtigungsmanagement aufbauen zu müssen.
Deutschsprachige Fachkompetenz im Fokus
Der Einsatzfall ist deutschsprachig, fachlich tief und terminologisch präzise. Omnifact setzt lokal betriebene Embedding-Modelle ein, die für mehrsprachige und deutschsprachige Fachtexte optimiert sind (z. B. BGE-M3, multilingual-e5-large). Die Kombination aus semantischer Vektorsuche und klassischer Volltextsuche stellt sicher, dass sowohl konzeptuell ähnliche Inhalte als auch exakte Fachbegriffe zuverlässig gefunden werden.
Skalierung auf den beschriebenen Datenraum
Mit rund 1 Million Dokumenten, bis zu 900 Seiten pro Dokument, hohem Versionierungs- und Dublettenanteil sowie Primärquellen aus SharePoint, SMB-Fileshares, DMS-Systemen (nscale, windream) und relationalen Datenbanken beschreibt die JEN einen Datenraum, der technisch handhabbar, aber nicht trivial ist. Omnifact adressiert dies durch inkrementelle Indizierungsläufe, dokumentenbasierte Deduplizierung und eine skalierbare Vektorindizierung, ohne dass bei jeder Aktualisierung ein Vollneuaufbau erforderlich wird.
Größte Synergien
Die stärkste Übereinstimmung besteht in drei folgenden Punkten: erstens im vollständig lokalen Betrieb ohne externe Modellanbindung, zweitens in der nachvollziehbaren, quellenbasierten Antworterzeugung mit transparentem Verhalten bei fehlender Dokumentenlage, was für ein Unternehmen mit sicherheitsrelevanten Wissensinhalten unverzichtbar ist und drittens in der modularen Architektur, die einen pragmatischen Piloteinstieg ermöglicht, ohne spätere Ausbaupfade zu verbauen.
Im Standard abgedeckte Anforderungen
Der folgende Umfang ist ohne zusätzliche Entwicklungsleistung produktiv einsetzbar:
Kernfunktionen RAG und Suche: Die vollständige RAG-Pipeline, Dokumentenextraktion, OCR gescannter Dokumente, Chunking, Embedding, hybride Vektor- und Volltextsuche sowie quellenbasierte Antwortgenerierung mit automatischen Quellenangaben, ist im Standard enthalten.
Gleiches gilt für das transparente Verhalten bei unzureichender Quellenlage: Das System weist explizit aus, wenn eine Anfrage nicht durch die vorliegenden Dokumente belegt werden kann.
Dokumentformate: Textbasierte und gescannte PDFs, Word, PowerPoint, OpenDocument, CSV, Markdown und JSON werden nativ verarbeitet. Bildformate werden per OCR erschlossen.
Zugriff und Berechtigungen: SAML 2.0 / Azure AD-Integration, rollenbasierte Zugriffskontrolle auf Space-Ebene sowie die Trennung von Dokumentenbeständen nach Nutzergruppen sind im Standard verfügbar.
Datenquellen: SharePoint Online und OneDrive sind als Konnektoren im Standard integriert. Dokumente können auch per REST-API und Direktupload eingebunden werden.
Betrieb und Compliance: On-Premises-Deployment mit lokalen Modellen, Audit-Logging (90 Tage, append-only), Monitoring, ISO/IEC 27001:2022-Zertifizierung, dokumentierte TOMs und DSGVO-konforme Betriebsprozesse sind vollständig vorhanden.
Versionierung und Deduplizierung: Dokumente werden pro Space versioniert verwaltet; bei inkrementellen Aktualisierungsläufen werden nur geänderte Dokumente neu indiziert. Grundlegende Dublettenprüfung auf Basis von Datei-Hashes ist im Standard enthalten.
Offene Punkte und Integrationsbedarf
Folgende Anforderungen erfordern erweiterte Konfiguration oder ergänzende Integrationsleistungen und sind im Pilotzeitraum realistisch umsetzbar:
SMB-Fileshares mit AD-Berechtigungsberücksichtigung: Ein generischer SMB-Konnektor existiert noch nicht als Standardprodukt. Die technische Grundlage (REST-API-basierte Dokumentenaufnahme, Metadaten-Mapping) ist vorhanden. Der Konnektor kann im Pilotprojekt als kundenspezifische Integration entwickelt und anschließend als wiederverwendbare Komponente in das Produktportfolio überführt werden. Realistischer Zeitrahmen: 3–5 Wochen Entwicklung und Test innerhalb des Piloten.
DMS-Systeme nscale und windream: Für beide Systeme existieren REST-APIs bzw. Exportschnittstellen, über die eine Anbindung technisch möglich ist. Omnifact wird die Konnektor-Entwicklung in Abstimmung mit der JEN umsetzen. Die konkrete Komplexität hängt von den verfügbaren API-Versionen und Exportmöglichkeiten ab und wird im Rahmen der Pilotplanung gemeinsam ermittelt. Realistischer Zeitrahmen: 4–6 Wochen je System.
Relationale Datenbanken (MS SQL Server): Die Anbindung strukturierter Daten erfordert eine Mapping-Konfiguration, die festlegt, welche Tabellen und Felder als durchsuchbare Textinhalte aufbereitet werden. Dieses Vorgehen ist erprobt; die konkrete Konfiguration ist projektspezifisch. Realistischer Zeitrahmen: 2–3 Wochen.
CMS-/Intranet-Anbindung: Abhängig vom eingesetzten System (z. B. Confluence, SharePoint-basiertes Intranet oder proprietäres CMS) variiert der Aufwand erheblich. Für gängige Systeme sind Konnektoren schnell realisierbar. Für proprietäre Lösungen ist eine Schnittstellenanalyse erforderlich.
Berechtigungsvererbung auf Dokumentenebene: Die aktuelle Architektur steuert Zugriff auf Space-Ebene. Eine feinkörnige Berechtigungsvererbung, bei der jedes Dokument die Zugriffsrechte aus dem Quellsystem übernimmt, ist technisch konzipiert und befindet sich auf der Produkt-Roadmap. Für den Piloten wird empfohlen, Berechtigungsgruppen auf Space-Ebene abzubilden, was für die meisten Anwendungsfälle ausreichend ist. Die dokumentengranulare Berechtigungssteuerung ist als Ausbaustufe für den Regelbetrieb vorgesehen.
Sehr große Dokumente (bis 900 Seiten): Die Standard-Pipeline verarbeitet solche Dokumente, jedoch ist eine projektspezifische Optimierung der Chunking-Strategie und der Kontextfensternutzung erforderlich, um Qualität und Performance sicherzustellen. Dies ist Bestandteil des Piloten.
Realistische Ausbaupfade
Zeithorizont & Umfang:
Pilot (Wochen 1–4): Kernsystem On-Premises, SharePoint-Anbindung, AD-Integration, erste Dokumentenbestände
Pilot (Wochen 5–8): SMB-Konnektor, DMS-Anbindung (nscale oder windream), SQL-Mapping
Pilot (Wochen 9–12): Intranet-Anbindung, Optimierung für große Dokumente, Qualitätsbewertung, Übergabe an Regelbetrieb
Regelbetrieb Ausbau: Dokumentengranulare Berechtigungen, zweites DMS-System, weitere Nutzergruppen, HA-Architektur bei Bedarf
Betriebsmodell
Für die JEN kommt ausschließlich das On-Premises-Betriebsmodell in Betracht. Omnifact wird vollständig auf kundeneigener Infrastruktur installiert und betrieben. Alle Komponenten, Applikationsserver, Vektordatenbank, Dokumentenverarbeitungs-Pipeline, OCR-Engine, Embedding-Modell und LLM-Inferenz, laufen innerhalb des JEN-Netzwerks. Es besteht keinerlei Abhängigkeit von externen Cloud-Diensten für die Datenverarbeitung. Updates, Konfigurationsänderungen und Modellwechsel erfolgen vollständig unter Kontrolle der JEN.
Für eine erste Ausbaustufe ist ein Single-Node oder einfacher Multi-Node Aufbau ausreichend. Eine Hochverfügbarkeitsarchitektur ist für den Piloten nicht erforderlich und kann bei Bedarf nachgerüstet werden.
Infrastruktur- und Sizing-Annahmen für den Piloten
Für einen Piloten mit einem kleinen Test- und Expertenteam (ca. 10–20 Personen, begrenzte Dokumentenmenge) ist folgende Mindestausstattung realistisch:
Applikationsserver: 1 Server mit 32–64 GB RAM, 16+ CPU-Kerne, 1–2 TB NVMe-Storage für Index und Dokumente
GPU für lokale Inferenz: 1× NVIDIA A10G oder vergleichbar (24 GB VRAM) für LLM und Embedding-Modell; alternativ CPU-Inferenz mit entsprechend höherer Latenz
Netzwerk: Anbindung an Active Directory, Zugriff auf SharePoint Online und SMB-Shares aus dem Servernetz
Für den späteren Regelbetrieb (350 Nutzer, 30 gleichzeitige Anfragen, 50 TB Datenraum) ist eine Skalierung auf mehrere Nodes mit dedizierter GPU-Kapazität erforderlich. Dies wird auf Basis der Piloterkenntnisse konkret dimensioniert.
Integrationsaufwand
Der technische Implementierungsaufwand gliedert sich in drei Bereiche:
Plattforminstallation und Grundkonfiguration (ca. 3–5 Tage): Installation der Omnifact-Plattform On-Premises, Konfiguration der Authentifizierung via Azure AD / SAML 2.0, Einrichtung erster Spaces und Benutzergruppen, Anbindung eines lokalen LLM und Embedding-Modells.
Datenquellenanbindung (ca. 3–6 Wochen je nach Quellenanzahl): SharePoint Online ist als Standardkonnektor verfügbar. SMB-Fileshares, DMS-Systeme (nscale, windream) und SQL Server erfordern jeweils individuelle Konnektor-Entwicklung und Konfiguration. Die Aufwände wurden im vorherigen Abschnitt bereits detailliert beschrieben.
Qualitätssicherung und Optimierung (laufend im Pilot): Chunking-Strategie für sehr große Dokumente, Retrieval-Qualität für deutschsprachige Fachterminologie, Feinabstimmung der Systemanweisungen für den JEN-spezifischen Kontext.
Mitwirkungsaufwand seitens JEN: Bereitstellung von Infrastruktur und Zugängen, fachliche Begleitung bei Testfragen, Rückmeldungen zur Antwortqualität sowie Koordination mit internen IT-Ansprechpartnern für AD, SharePoint und DMS.
Pilotplanung (8–12 Wochen)
Der Pilot ist in drei Phasen strukturiert:
Phase 1 – Aufbau und erste Nutzung (Wochen 1–4) Ziel ist ein lauffähiges System mit ersten realen Inhalten. Omnifact wird installiert, AD-Integration eingerichtet und SharePoint als erste Datenquelle angebunden. Ein kleines Testteam aus 5–10 Personen beginnt mit realen Suchanfragen aus dem Arbeitsalltag. Parallell wird die Anforderungsanalyse für SMB- und DMS-Anbindung abgeschlossen.
Phase 2 – Erweiterung der Datenquellen (Wochen 5–8) SMB-Fileshare-Konnektor und mindestens eine DMS-Anbindung werden integriert. Der Testkreis wird auf weitere Fachbereiche ausgedehnt. Retrieval-Qualität, Antwortrelevanz und Systemperformance werden systematisch bewertet und optimiert.
Phase 3 – Konsolidierung und Übergabe (Wochen 9–12) Restliche Datenquellen werden angebunden, Administrationsprozesse für den laufenden Betrieb durch JEN-Eigenpersonal werden dokumentiert und eingeübt. Abschluss mit einer strukturierten Qualitätsbewertung und einer Empfehlung für den Übergang in den Regelbetrieb inklusive Sizing-Anpassungen.
Am Ende des Pilots steht ein belastbares Bild zu Antwortqualität, technischer Stabilität, Betriebsaufwand und dem konkreten Ausbaupfad – als fundierte Grundlage für eine Entscheidung zum Regelbetrieb.
Grundannahmen
Die folgenden Angaben basieren auf dem beschriebenen Szenario:
350 Nutzer, 30 gleichzeitige interaktive Anfragen, ca. 1 Million Dokumente, 50 TB Datenraum, On-Premises, Primärsprache Deutsch, Dokumente bis 900 Seiten. Alle Komponenten laufen lokal. Externe Rechenkapazität wird nicht vorausgesetzt.
Pilotphase (8–12 Wochen, ca. 10–20 Testnutzer, begrenzter Dokumentenbestand)
Komponente & Spezifikation
Applikationsserver (CPU)1 Server, 16–32 CPU-Kerne, 64 GB RAM
GPU (LLM + Embedding)1× NVIDIA A10G (24 GB VRAM) oder vergleichbar; alternativ 2× RTX 4090
Lokales Storage (Index + Dokumente)2–5 TB NVMe/SSD (je nach Pilotdokumentenmenge)
BetriebssystemLinux (Ubuntu 22.04 LTS empfohlen)
Netzwerk1 GbE intern ausreichend; AD- und SharePoint-Erreichbarkeit
BackupLokales Backup-Target, min. 2× Pilotdatenvolumen
Ein einzelner, gut ausgestatteter Server genügt für den Piloten vollständig. GPU-Ressourcen können alternativ über einen vorhandenen KI-Workserver bereitgestellt werden, sofern vorhanden.
Regelbetrieb (350 Nutzer, 30 gleichzeitige Anfragen, ~1 Mio. Dokumente, 50 TB)
LLM-Inferenz ist die ressourcenintensivste Komponente. Für 30 gleichzeitige Anfragen mit einem qualitativ hochwertigen deutschsprachigen Modell (empfohlen: 13B–34B Parameter, quantisiert) wird folgende GPU-Kapazität benötigt:
Komponente & Spezifikation
GPU-Server (Inferenz)1–2 Server mit je 2–4× NVIDIA A100 (40/80 GB) oder äquivalent; alternativ 4–8× A10G (24 GB)
CPU-Server (Applikation, API, Vektordatenbank)2 Server, je 32 CPU-Kerne, 128–256 GB RAM
Vektorindex-Storage500 GB – 1 TB NVMe (bei ~100 Mio. Chunks à 1024-dimensionalen Vektoren)
Dokument-Storage (Rohdaten)50 TB (NAS/SAN mit ausreichender IOPS für Indexierungsläufe)
Verarbeitungs-Storage (OCR-Output, Extraktionsergebnisse)10–15 TB zusätzlich
Backup-KapazitätMin. 1× Gesamtvolumen (~65 TB)
Netzwerk10 GbE empfohlen zwischen Storage und Applikationsservern
Wesentliche Sizing-Treiber
Drei Faktoren bestimmen den Ressourcenbedarf maßgeblich:
Modellgröße vs. Antwortqualität: Ein 7B-Modell (z. B. Mistral 7B quantisiert, ~5 GB VRAM) läuft auf einem einzelnen Consumer-GPU, liefert aber für komplexe fachliche Anfragen auf Deutsch begrenzte Qualität. Ein 34B-Modell (quantisiert, ~20–25 GB VRAM) bietet deutlich bessere Ergebnisse, erfordert aber leistungsfähigere GPU-Hardware. Die konkrete Modellwahl wird im Piloten empirisch evaluiert.
Gleichzeitige Anfragen: Bei 30 parallelen Anfragen mit einem 13B-Modell (quantisiert) sind typischerweise 2–3 GPU-Instanzen erforderlich, um Antwortzeiten unter 10 Sekunden zu halten. Für einen Piloten mit deutlich geringerer Gleichzeitigkeit reicht eine GPU-Instanz.
Indexierungsgeschwindigkeit: Die initiale Indexierung von 1 Million Dokumenten (inklusive OCR-Verarbeitung gescannter PDFs) ist ein mehrwöchiger Prozess und keine Echtzeitoperation. Inkrementelle Updates einzelner Dokumente erfolgen hingegen innerhalb von Minuten. Die Indexierungskapazität kann bei Bedarf temporär durch zusätzliche CPU-Ressourcen beschleunigt werden.
Hinweis zu Sizing-Präzision
Die obigen Angaben sind Richtwerte für die Planungsphase. Eine belastbare Dimensionierung erfordert Kenntnisse über die tatsächliche Dokumentenstruktur (Anteil gescannter PDFs, durchschnittliche Seitenzahl, Bildanteil), die gewählten Modelle und die Concurrent-Load-Profile. Diese Faktoren werden im Rahmen der Pilotplanung gemeinsam mit der JEN konkretisiert.
Referenzprofil und Einsatzerfahrung
Omnifact ist seit 2023 produktiv im Einsatz bei einer wachsenden Zahl öffentlicher und regulierter Auftraggeber. Die nachfolgenden Referenzszenarien sind in Bezug auf Anforderungsprofil, Datensensibilität oder Organisationsstruktur mit dem JEN-Einsatzfall vergleichbar.
S-Kreditpartner GmbH (Sparkassen-Verbund) – über 700 Nutzende
S-Kreditpartner ist eine Tochtergesellschaft des Sparkassen-Verbunds mit strengen regulatorischen Anforderungen an Datenschutz, Auditierbarkeit und Informationssicherheit. Omnifact wird hier mit über 700 aktiven Nutzenden eingesetzt, als KI-Arbeitsplattform mit RAG-gestütztem Zugriff auf interne Wissensbestände. Der Einsatzfall ist durch hohe Compliance-Anforderungen, sensible Kundendaten und die Notwendigkeit nachvollziehbarer, quellenbasierter Antworten geprägt. Die Lösung läuft produktiv im EU-Hosting mit vollständiger Datensouveränität. Ein Wechsel auf On-Premises-Betrieb ist für einzelne Mandanten in Planung.
Relevanz für JEN: Vergleichbar hohe Anforderungen an Informationssicherheit und Compliance, großer Nutzerkreis, dokumentenzentrierte Wissensarbeit.
Bundesrepublik Deutschland Finanzagentur
Die Finanzagentur des Bundes setzt Omnifact zur internen Wissenserschließung ein. Der Einsatzfall umfasst die Erschließung regulatorischer Dokumente, interner Richtlinien und fachlicher Unterlagen mit hohem Aktualitätsanspruch. Besonderes Gewicht liegt auf der Nachvollziehbarkeit von Antworten und der klaren Quellenzuordnung. Anforderungen, die strukturell denen der JEN entsprechen.
Relevanz für JEN: Öffentlicher Auftraggeber, reguliertes Umfeld, Fokus auf Quellenbasierung und Auditierbarkeit.
Kommunale Verwaltungen und Stadtwerke
Mehrere Stadt- und Kreisverwaltungen (u. a. Dessau-Roßlau, Bad Kreuznach, Mülheim, Tübingen) sowie Stadtwerke (Mülheim, Essen, Wiesbaden, Erfurt) nutzen Omnifact zur Erschließung heterogener interner Dokumentenbestände. Diese Einsatzszenarien sind durch verteilte Ablagestrukturen, gewachsene Dokumentenlandschaften und begrenzte IT-Ressourcen für den laufenden Betrieb gekennzeichnet, mit dem Ziel, Recherche- und Auskunftsprozesse zu beschleunigen und Einzelwissensabhängigkeiten zu reduzieren.
Relevanz für JEN: Strukturell ähnlich gelagert: heterogene, historisch gewachsene Dokumentenbestände, öffentlicher Betreiber, Administrierbarkeit durch Eigenpersonal als Zielstellung.
Übergreifende Einsatzerfahrungen
Aus dem produktiven Betrieb bei diesen Kunden liegen Erfahrungen zu folgenden Aspekten vor, die für die JEN-Anforderungen unmittelbar relevant sind:
Deutschsprachige Fachtexte: Die überwiegende Mehrzahl der Kundenumgebungen ist deutschsprachig. Embedding-Modelle und Chunking-Strategien wurden auf dieser Basis kontinuierlich evaluiert und optimiert.
Heterogene Dokumentenbestände: Gescannte PDFs, Office-Dokumente, strukturierte und unstrukturierte Inhalte aus verschiedenen Quellsystemen sind der Regelfall, nicht die Ausnahme. Die Verarbeitungspipeline ist auf diese Heterogenität ausgelegt.
Quellenbasierung als zentrales Nutzerbedürfnis: In allen produktiven Einsatzfällen ist die Nachvollziehbarkeit von Antworten das meistgenannte Qualitätsmerkmal. Die automatische Quellenreferenzierung ist entsprechend eng in die Antwortgenerierung integriert.
Onboarding und Change Management: Die Erfahrung zeigt, dass technische Qualität allein keine Adoption erzeugt. Omnifact begleitet Einführungen daher regelmäßig mit Trainingsformaten (ab 90-minütigem Webinar aufwärts) und unterstützt Kunden dabei, eine organisationsinterne KI-Nutzungsrichtlinie zu entwickeln.
Hinweis zur Vertraulichkeit
Weitergehende Projektdetails, Ansprechpartner bei Referenzkunden sowie nicht-öffentliche Implementierungsdetails können auf Anfrage oder im Rahmen eines persönlichen Gesprächs mit der Jury geteilt werden.
Modulare Architektur als Grundprinzip
Zukunftssicherheit entsteht bei KI-Systemen nicht durch eine einzelne Technologieentscheidung, sondern durch eine Architektur, die Veränderungen zulässt.
Omnifact ist von Beginn an modular aufgebaut: LLM, Embedding-Modell, OCR-Engine, Vektordatenbank, Suchkomponenten und Konnektoren sind klar voneinander abgegrenzte, austauschbare Bestandteile.
Keine dieser Komponenten erzeugt eine Abhängigkeit, die einen späteren Wechsel technisch oder organisatorisch unverhältnismäßig erschwert.
Konkret bedeutet das für die JEN: Wird in zwei Jahren ein leistungsfähigeres deutschsprachiges Open-Source-Modell verfügbar, kann es ohne Änderung an der übrigen Architektur eingewechselt werden. Dasselbe gilt für Embedding-Modelle, OCR-Komponenten oder die Vektordatenbank.
Exportierbare Konfigurationen und dokumentierte REST-Schnittstellen stellen sicher, dass die JEN nicht in eine proprietäre Abhängigkeit gerät.
Kein Vendor-Lock-in
Omnifact setzt bewusst auf offene Standards und Open-Source-Komponente in der Verarbeitungspipeline. Es gibt keine proprietären Datenformate, keine herstellerspezifischen Indexstrukturen und keine Abhängigkeit von einem einzelnen Modellanbieter. Konfigurationen, Indexdaten und Dokumentenbestände bleiben jederzeit unter der Kontrolle der JEN und sind portierbar. Dies ist keine Marketingaussage, sondern strukturelle Eigenschaft eines Systems, das für regulierte Umgebungen mit langem Planungshorizont konzipiert wurde.
Produktroadmap und Entwicklungsrichtung
Die Omnifact-Plattform entwickelt sich in zwei strategischen Richtungen, die für die JEN mittel- und langfristig relevant sind:
Tiefere Prozessintegration: Über das Model Context Protocol (MCP) wird die Plattform mit operativen Systemen verbunden, ERP, DMS, Datenbanken und weitere Quellsysteme können nicht nur als Lesequellen erschlossen, sondern auch als Handlungsebene angesprochen werden.
Für die JEN eröffnet das perspektivisch die Möglichkeit, nicht nur Wissen abzurufen, sondern Workflows KI-gestützt anzustoßen.
Agentenautomatisierung: Die Agents-Runtime ermöglicht KI-Agenten, die eigenständig, kontrolliert und prozessbezogen Aufgaben ausführen, etwa die automatisierte Aufbereitung von Dokumenten, die Überwachung von Änderungen in Datenquellen oder die Erstellung strukturierter Zusammenfassungen. Diese Entwicklung ist pilotiert: Erste Test-Deployments laufen bereits bei bestehenden Kunden. Für die JEN bedeutet dies einen klaren Ausbaufad vom reinen Dokumenten-Retrieval hin zu einer umfassenderen KI-gestützten Wissens- und Prozessinfrastruktur.
Dokumentenerstellung und erweiterte Knowledge-Base-Funktionen: Die Plattform wird um die Möglichkeit erweitert, Word- und Excel-Dokumente direkt KI-gestützt zu erstellen, Dokumente gegen interne Checklisten zu prüfen und Versionsvergleiche durchzuführen. Funktionen, die für eine Organisation mit umfangreichem technischem Regelwerk wie der JEN unmittelbar nützlich sind.
Reaktion auf technologische Trends
Der KI-Markt entwickelt sich in einem Tempo, das feste Mehrjahrespläne schnell überholt. Omnifacts Antwort darauf ist struktureller Natur: Weil Modelle austauschbar sind, profitiert die JEN automatisch von Verbesserungen in der Open-Source-Modelllandschaft, ohne die Plattform neu einführen zu müssen. Neue Modelle, ob bessere Embedding-Modelle für deutschsprachige Fachtexte, leistungsfähigere LLMs mit größerem Kontextfenster oder spezialisierte OCR-Modelle, können innerhalb von Tagen bis wenigen Wochen integriert werden.
Die Hypothese, dass spezialisierte Open-Source-Modelle in Qualität und Effizienz weiter aufholen werden, ist für On-Premises-Betreiber wie die JEN besonders relevant: Was heute noch eine GPU-intensive Inferenz erfordert, wird in zwei/drei Jahren mit einem Bruchteil der Ressourcen leistbar sein. Eine Architektur, die Modelle einfach austauscht, ist dafür besser positioniert als eine, die tief auf ein bestimmtes Modell ausgelegt ist.
Langfristige Wirtschaftlichkeit
Das Lizenzmodell ist transparent: Omnifact berechnet nach Nutzerzahl (Seat-basiert), ohne versteckte Token-Kosten, Inferenzgebühren oder datenmengenabhängige Aufpreise.
On-Premises-Betrieb bedeutet, dass Rechenkosten vollständig unter Kontrolle der JEN liegen und mit der eigenen Infrastrukturentwicklung skalieren, nicht mit dem Preismodell eines externen Anbieters.
Für einen Nutzerkreis von 350 Personen gelten Rabattstufen. Eine unverbindliche Kostenindikation für Pilot und Regelbetrieb kann auf Anfrage vertraulich übermittelt werden.
Unternehmensausblick für langfristige Planbarkeit und Unabhängigkeit
Omnifact wurde 2023 gegründet, ist ISO/IEC 27001:2022-zertifiziert und wächst mit einem Kundenstamm, der überwiegend aus öffentlichen und regulierten Organisationen besteht. Die Produktentwicklung orientiert sich konsequent an den Anforderungen dieser Zielgruppe. Datensouveränität, Administrierbarkeit, Compliance und Zukunftsoffenheit sind keine Differenzierungsmerkmale für den Markt, sondern Grundbbedingungen.
