Sovereign RAG für technische Dokumente: Wann On-Premise wirklich sinnvoll ist

Ein Lastenheft mit kundenspezifischen Toleranzen, eine RFQ mit Zielpreisen oder ein Servicebericht aus einer Produktionslinie ist kein gewöhnlicher Prompt. Solche Dokumente können personenbezogene Daten enthalten. Häufig wertvoller ist jedoch das darin gebundene Betriebswissen: Konstruktion, Kalkulation, Lieferantenbeziehungen und vertragliche Pflichten.

Deshalb greift die Frage „Dürfen wir dafür eine Cloud nutzen?“ zu kurz. Entscheidend ist, wer jede Station der Verarbeitung kontrolliert: Dateiablage, Parser, Embedding-Modell, Vektordatenbank, Sprachmodell, Protokolle, Backups, Supportzugriffe und Update-Kanäle.

Datensouveränität ist keine Produkteigenschaft. Sie ist das Ergebnis einer überprüfbaren Architektur und eines passenden Betriebsmodells.

Eine gut konfigurierte Private Cloud kann für viele Unternehmen die richtige Lösung sein. In besonders sensiblen Umgebungen kann eine lokale oder vollständig isolierte Bereitstellung erforderlich sein. On-Premise ist aber nicht automatisch sicherer: Ohne Patch-Prozess, Rollenmodell, Monitoring und klare Verantwortlichkeiten verlagert es Risiken lediglich in das eigene Rechenzentrum.

Retrieval-Augmented Generation, kurz RAG, verbindet ein Sprachmodell mit einer kontrollierten Wissensbasis. Bei einer Anfrage sucht das System zunächst passende Dokumentausschnitte und stellt sie dem Modell als Kontext bereit. So kann eine Antwort enger an freigegebenen Quellen ausgerichtet werden, ohne das Basismodell mit den Unternehmensdokumenten neu zu trainieren.

Für eine belastbare Sicherheitsbewertung muss der vollständige Datenfluss betrachtet werden:

• Originaldateien und daraus extrahierter Text
• Dokumentsegmente, Metadaten und erzeugte Embeddings
• Suchanfrage, abgerufene Textstellen und Gesprächskontext
• Modellantworten, Quellenverweise und Nutzerfeedback
• Anwendungs-, Sicherheits- und Fehlerprotokolle
• Backups, Replikate, Telemetrie und temporäre Verarbeitungspuffer

Ein System ist daher nicht allein deshalb souverän, weil die PDF-Datei auf einem deutschen Server liegt. Wenn Embeddings extern erzeugt, relevante Textpassagen an eine öffentliche API gesendet oder Logs in einen fremden Mandanten geschrieben werden, überschreiten Teile des Inhalts weiterhin die gewünschte Vertrauensgrenze.

Die passende Architektur folgt der Schutzklasse der Dokumente und dem realen Anwendungsfall. In der Praxis lassen sich vier Modelle unterscheiden:

• Öffentlicher KI-Dienst: schnell verfügbar und für freigegebene, wenig sensible Inhalte oft ausreichend. Für NDA-gebundene Konstruktions- oder Kundendaten ist eine ungeprüfte Nutzung meist nicht angemessen.
• Managed Enterprise Cloud: bietet Verträge, administrative Kontrollen und definierte Datenverarbeitung. Entscheidend bleiben Subprozessoren, Region, Aufbewahrung, Telemetrie und vertragliche Zusagen.
• Kundeneigene Private Cloud: Anwendung, Vektordatenbank und Modelle laufen in einem vom Kunden kontrollierten Cloud-Tenant. Das verbindet Skalierbarkeit mit stärkerer technischer und organisatorischer Kontrolle.
• On-Premise oder Air-Gapped: Daten und Modelle bleiben in der lokalen Infrastruktur; externe Inferenz ist ausgeschlossen. Das eignet sich für besonders schützenswerte IP oder abgeschottete Netze, verlangt aber eigene Betriebs-, Update- und Sicherheitskompetenz.

Die teuerste oder isolierteste Variante ist nicht automatisch die beste. Ein unnötig komplexes Air-Gap kann einen Pilot blockieren, während ein zu offenes API-Design ein vermeidbares Risiko schafft. Gute Architektur wählt den geringsten technischen Aufwand, der die tatsächlichen Schutzanforderungen nachweisbar erfüllt.

Für technische Dokumente sollte die Vertrauensgrenze nicht erst am Chatfenster beginnen. Sie umfasst die gesamte Verarbeitungskette vom Import bis zum Audit-Log.

• Dokumente werden aus freigegebenen Quellen wie DMS, SharePoint-Export oder Dateisystem übernommen.
• Parser, OCR und Normalisierung laufen innerhalb der festgelegten Umgebung.
• Embeddings werden lokal oder in einem kontrollierten Tenant erzeugt und getrennt nach Mandant, Projekt und Berechtigung gespeichert.
• Die Suche berücksichtigt Zugriffsrechte, Dokumentversionen und Metadaten – nicht nur semantische Ähnlichkeit.
• Ein privat betriebenes oder vertraglich kontrolliertes Modell erhält ausschließlich die für die konkrete Anfrage freigegebenen Ausschnitte.
• Antworten enthalten Quellen, Dokumentversionen und – wo möglich – konkrete Seiten oder Abschnitte.
• Zugriffe, Änderungen und Löschvorgänge werden nachvollziehbar protokolliert.

Das BSI empfiehlt bei generativen KI-Modellen eine systematische Betrachtung von Chancen, Risiken und Schutzmaßnahmen. Für Unternehmen bedeutet das: Nicht nur das Modell bewerten, sondern die Anwendung, ihre Datenquellen und die Einbindung in bestehende Prozesse als Gesamtsystem behandeln.

Eine Quellenanbindung macht Antworten besser prüfbar. Sie garantiert jedoch keine korrekten Ergebnisse. Das Retrieval kann den falschen Abschnitt auswählen, Tabellen können beim Parsing Struktur verlieren und ein Sprachmodell kann aus richtigem Kontext eine falsche Schlussfolgerung ziehen. NIST führt solche überzeugend formulierten, aber fehlerhaften Inhalte als wesentliches Risiko generativer KI auf.

Ein produktionsreifes System benötigt deshalb zusätzliche Kontrollen:

• Quellenbelege, die der Nutzer ohne Umweg öffnen und prüfen kann
• Mindestschwellen für Retrieval-Qualität und eine definierte „Keine belastbare Antwort“-Option
• Testsets mit echten Fachfragen, erwarteten Quellen und messbaren Akzeptanzkriterien
• Strukturierte Ausgaben und Validierungsregeln für nachgelagerte Prozesse
• Menschliche Freigabe bei rechtlichen, sicherheitskritischen oder finanziell relevanten Entscheidungen

Das Ziel ist nicht, menschliche Prüfung unsichtbar zu machen. Das Ziel ist, die richtige Textstelle schneller zu finden, einen nachvollziehbaren Entwurf zu erzeugen und Unsicherheit sichtbar zu behandeln.

Die DSGVO schützt personenbezogene Daten. Ein technisches Dokument kann zusätzlich hochvertrauliches geistiges Eigentum enthalten, auch wenn darin keine personenbezogenen Daten vorkommen. Verträge, Geschäftsgeheimnisse, Exportkontrollen, Kundenvorgaben und interne Informationsklassen können daher strengere Grenzen setzen als der Datenschutz allein.

Aus Datenschutzsicht bleiben unter anderem Zweck, Rechtsgrundlage, Datenminimierung, Löschung, Auftragsverarbeitung und mögliche Drittlandtransfers zu klären. Der EDPB betont zudem, dass die datenschutzrechtliche Bewertung von KI-Modellen einzelfallbezogen erfolgen muss. Eine pauschale Aussage wie „DSGVO-konform durch On-Premise“ wäre deshalb unseriös.

Aus IP- und Sicherheitssicht kommen andere Fragen hinzu: Darf dieses Lastenheft die Systemgrenze verlassen? Können Administratoren oder Hersteller-Support Inhalte sehen? Werden Fragmente in Logs, Backups oder Telemetrie reproduziert? Wie werden Berechtigungen aus dem Quellsystem übernommen? Erst beide Prüfungen zusammen ergeben ein belastbares Betriebsmodell.

• Welche konkreten Dokumenttypen und Informationsklassen sollen verarbeitet werden?
• Welche Personen, Rollen und Standorte dürfen auf welche Inhalte zugreifen?
• Müssen externe Modell-APIs technisch ausgeschlossen werden oder genügen vertraglich und technisch kontrollierte Dienste?
• Welche Systeme sind führend – DMS, ERP, PLM, Fileshare oder ein isolierter Datenraum?
• Wie werden Versionen, Löschfristen, Berechtigungsänderungen und Backups synchronisiert?
• Welche fachlichen Fehler sind akzeptabel und wann muss das System eine Antwort verweigern?
• Wer betreibt Modelle, Infrastruktur, Updates, Monitoring und Incident Response nach dem Pilot?

Wenn diese Fragen nicht beantwortet sind, ist eine Modell- oder Anbieterentscheidung verfrüht. Ein Sovereign AI Assessment sollte daher zuerst Datenfluss, Schutzbedarf, Zielprozess und Betriebsverantwortung klären – und erst danach die konkrete Technologie auswählen.

Ein guter RAG-Pilot beginnt nicht mit dem gesamten Unternehmenswissen. Er verwendet einen begrenzten, repräsentativen Datensatz und eine messbare Aufgabe – etwa Anforderungen aus ausgewählten RFQs extrahieren, eine Service-Dokumentation durchsuchen oder Abweichungen zwischen zwei Spezifikationsständen markieren.

• Eine klar abgegrenzte Dokumentklasse und definierte Nutzergruppe
• 20 bis 50 reale Fachfragen mit erwarteten Quellen
• Vereinbarte Kriterien für Retrieval, Antwortqualität, Latenz und Verweigerung
• Ein dokumentierter Datenfluss und ein geprüftes Berechtigungsmodell
• Eine Entscheidungsvorlage für Betrieb, Integration und nächste Ausbaustufe

Damit beantwortet der Pilot nicht nur, ob ein Modell eine beeindruckende Demo liefern kann. Er zeigt, ob der gesamte Prozess unter realen Sicherheits-, Qualitäts- und Betriebsbedingungen tragfähig ist.

Für technische Dokumente ist RAG besonders wertvoll, wenn Antworten auf konkrete Quellen zurückgeführt werden müssen. Der entscheidende Vorteil einer souveränen Implementierung ist jedoch nicht das Label „On-Premise“. Es ist die Fähigkeit, Datenflüsse, Zugriffe, Modelle und Betrieb an den eigenen Schutzbedarf anzupassen und diese Entscheidungen nachzuweisen.

FileGPT.dev konzipiert und implementiert solche Systeme für technische Dokumentenprozesse – in der Private Cloud, On-Premise oder in isolierten Umgebungen. Wenn Sie zunächst klären möchten, welches Modell zu Ihrer Infrastruktur passt, können Sie ein Sovereign AI Assessment anfragen.