Minerva - Nutzung von LLMs mit Noreja

Optionen für die Nutzung von Large Language Models in Noreja

Noreja bietet mehrere klar abgegrenzte Optionen für den Einsatz von Large Language Models, um unterschiedlichen Anforderungen an Datenschutz, Kontrolle, Qualität und Betriebsverantwortung gerecht zu werden. Grundsätzlich lassen sich diese Optionen entlang der Frage strukturieren, wer das Modell betreibt und verwaltet: ein externer Anbieter, Noreja selbst oder der Kunde.

Bei cloud-basierten, öffentlich verfügbaren LLMs erfolgt der Betrieb vollständig durch den jeweiligen Modellanbieter. Noreja greift in diesem Fall über standardisierte Schnittstellen auf diese Modelle zu und nutzt deren hohe Modellreife, Skalierbarkeit und kontinuierliche Weiterentwicklung.

Alternativ stellt Noreja eigene, durch Noreja verwaltete LLM-Setups bereit. Dazu zählen sowohl Noreja-Application-LLMs als auch dedizierte, kundenindividuelle LLM-Instanzen, die von Noreja betrieben und über das Noreja AI Center orchestriert werden. Diese Variante verbindet eine zentrale Modellsteuerung und -auswahl mit klar definierten Datenschutz- und Integrationsmechanismen und erlaubt den gezielten Einsatz verschiedener Modellanbieter.

Für maximale Kontrolle besteht zudem die Möglichkeit, ein kundeneigenes LLM in die Noreja-Plattform einzubinden („Bring Your Own LLM“). In diesem Szenario liegt der Betrieb vollständig beim Kunden. Noreja fungiert hier als Integrations- und Orchestrierungsschicht und ermöglicht die Anbindung weiterer Systeme, Agenten oder APIs, ohne selbst Modell- oder Inferenzverantwortung zu übernehmen.

Diese drei Optionen bilden die Grundlage für den flexiblen Umgang mit LLMs in Noreja. Unabhängig vom gewählten Betriebsmodell stellt sich dabei häufig die Frage nach den technischen Unterschieden zwischen lokal betriebenen und cloud-basierten Modellen.

Lokale LLMs (On-Premise) vs. Cloud-basierte Modelle

Noreja unterstützt sowohl lokal betriebene Large Language Models als auch cloud-gehostete Modelle und ermöglicht damit eine flexible Wahl je nach Anforderungen an Datenschutz, Ergebnisqualität und Einsatzszenario.

Qualität

Der größte qualitative Unterschied zeigt sich bei reinen LLM-Interaktionen ohne Tool Calling oder externe Systemanbindung. Cloud-basierte Modelle verfügen in der Regel über deutlich größere Trainingsdaten, leistungsfähigere Architekturvarianten und kontinuierliche Optimierungen. Das führt zu höherer Sprachqualität, stabilerem Reasoning, besserem Umgang mit Mehrdeutigkeiten und konsistenteren Antworten bei komplexen oder offenen Fragestellungen.

Lokale LLMs erreichen in klar abgegrenzten, strukturierten Anwendungsfällen ebenfalls gute Ergebnisse, zeigen jedoch ohne zusätzliche Steuerungsmechanismen schneller qualitative Grenzen. Insbesondere bei längeren Kontexten, offenen Prompts oder implizitem logischem Schlussfolgern hängt die Antwortqualität stark von Modellgröße, verfügbarer Hardware und individueller Konfiguration ab.

Datenkontrolle

Lokale Modelle bieten maximale Kontrolle über Daten und Ausführung. Sämtliche Eingaben, Kontextinformationen und Modellantworten verbleiben vollständig innerhalb der eigenen Infrastruktur. Es findet keine externe Übertragung statt, wodurch lokale LLMs besonders für datenschutzkritische Prozess-, Personen- und Unternehmensdaten geeignet sind und interne Compliance-, Security- und Governance-Anforderungen zuverlässig unterstützen.

Cloud-basierte Modelle werden über APIs angesprochen, wobei die übermittelten Daten in der Infrastruktur des jeweiligen Anbieters verarbeitet werden. Führende Anbieter treffen umfangreiche technische und organisatorische Sicherheitsmaßnahmen, darunter verschlüsselte Übertragung, isolierte Verarbeitung und vertragliche Zusicherungen zur Nicht-Verwendung von Kundendaten für Training oder Weiterentwicklung. Auch bei Enterprise- oder Zero-Retention-Optionen bleibt die Datenverarbeitung an externe Systeme sowie deren technische und rechtliche Rahmenbedingungen gebunden.

In der Praxis erlaubt Noreja den gezielten Einsatz beider Ansätze: lokale LLMs für kontrollierte, datensensible und klar strukturierte Szenarien, cloud-basierte Modelle dort, wo maximale Sprachqualität, Robustheit und tiefgehendes Reasoning – insbesondere in reinen LLM-Interaktionen – im Vordergrund stehen.

OpenAI Datenkontrolle

Die nachfolgenden Informationen basieren auf offiziellen Angaben von OpenAI, die man auch hier finden kann.

Verwendung der Daten durch OpenAI

• Seit dem 1. März 2023 werden über die OpenAI API übermittelte Daten nicht zum Training oder zur Verbesserung von Modellen verwendet, es sei denn, es erfolgt eine ausdrückliche Zustimmung (Opt-in).
• Kundendaten bleiben Eigentum des Kunden.

Arten gespeicherter Daten

Bei der Nutzung der API können folgende Datenkategorien anfallen:

a) Abuse Monitoring Logs

• Dienen der Missbrauchserkennung und Durchsetzung von Nutzungsrichtlinien.
• Können Prompts, Antworten sowie abgeleitete Metadaten enthalten.
• Standard-Speicherdauer: bis zu 30 Tage, sofern keine längere gesetzliche Aufbewahrungspflicht besteht.

b) Application State

• Technisch notwendige Zwischenspeicherung zur Erfüllung bestimmter Funktionen (z. B. Konversationen, Audioausgaben, Hintergrundverarbeitung).
• Speicherdauer abhängig vom verwendeten Endpoint.

Erweiterte Datenkontrollen

OpenAI bietet – nach Genehmigung – folgende Optionen:

Modified Abuse Monitoring (MAM)

• Kundendaten werden nicht in Abuse-Logs gespeichert (mit seltenen Ausnahmen bei Bild-/Datei-Uploads).
• Volle API-Funktionalität bleibt erhalten.
• Verantwortung für Richtlinienkonformität liegt stärker beim Kunden.

Zero Data Retention (ZDR)

• Keine Speicherung von Kundendaten in Abuse-Logs.
• store-Parameter wird technisch immer als false behandelt.
• Bestimmte Funktionen sind eingeschränkt oder nicht kompatibel (z. B. Background Mode, Extended Prompt Caching, OpenAI-hosted Container).

Endpoint-spezifische Speicherregeln (Auszug)

Bild- und Datei-Uploads

• Bilder und Dateien werden automatisiert auf illegale Inhalte (z. B. CSAM) geprüft.
• Bei Verdachtsfällen kann eine Speicherung zur manuellen Prüfung erfolgen – auch bei aktivierter ZDR/MAM-Option.

Data Residency (Datenstandort)

• Projektbezogene Konfiguration möglich (z. B. EU oder USA).
• Kundendaten werden – sofern technisch erforderlich – in der gewählten Region gespeichert.
• Systemdaten (z. B. Abrechnung, Metadaten, Nutzungsstatistiken) sind nicht Bestandteil der Data Residency.
• Nicht alle Endpoints unterstützen regionale Verarbeitung.

Enterprise Key Management (EKM)

• Kundendaten können mit kundeneigenen Schlüsseln verschlüsselt werden (BYOK).
• Unterstützt: AWS KMS, Google Cloud KMS, Azure Key Vault.
• Nicht kompatibel mit bestimmten Funktionen (z. B. Assistants API).

Zusammenfassung

• Kein Training mit API-Daten ohne Opt-in
• Standardmäßige Log-Aufbewahrung: max. 30 Tage
• Optionale Zero Data Retention möglich (mit Funktionseinschränkungen)
• Regionale Datenspeicherung konfigurierbar
• Enterprise-Verschlüsselung (BYOK) verfügbar