Datensouveränität in der Unternehmens-KI: Implementierung von On-Premise-LLMs und air-gapped RAG unter dem EU-KI-Gesetz

Ein Engineering-Leitfaden für deutsche Unternehmen, die Zero Data Leakage erfordern — mit detaillierter Bereitstellung von Open-Weights-Modellen (wie Llama-3 über vLLM) in air-gapped Infrastruktur, um vollständige DSGVO- und EU-KI-Gesetz-Konformität zu gewährleisten, ohne Retrieval-Performance zu opfern.

Einführung — Das deutsche Unternehmens-KI-Paradoxon

Deutsche Unternehmen stehen vor einem strukturellen Paradoxon im KI-Zeitalter:

• Sie verfügen über massive proprietäre Datensätze — der Rohstoff des Wettbewerbsvorteils

• Sie operieren unter dem strengsten Datenschutzregime der Welt — DSGVO, BDSG und jetzt das EU-KI-Gesetz

• Sie stehen unter Druck, KI einzuführen — von Vorständen, Wettbewerbern und Markterwartungen

• Doch die Standard-KI-Tooling erfordert das Senden von Daten an externe APIs — eine inakzeptable Übertragung von Souveränität

Das Ergebnis ist Lähmung, die als Vorsicht getarnt ist. Viele Organisationen setzen KI einfach nicht ein — nicht weil sie es nicht können, sondern weil sie es nicht legal tun können.

Dieser Artikel ist die technische Antwort auf diese Lähmung:

Wie man unternehmensgerechte LLM-Systeme vollständig vor Ort architektiert, bereitstellt und betreibt — mit Null-Datenleck, vollständiger EU-KI-Gesetz-Konformität und ohne Einbußen bei der Retrieval-Performance.

Dies ist keine Theorie. Dies sind Produktionsmuster für Organisationen, in denen Datensouveränität nicht verhandelbar ist.

Teil 1 — Die regulatorische Landschaft: Was deutsche Unternehmen tatsächlich betrifft

Bevor irgendetwas architektiert wird, müssen die Compliance-Grenzen explizit sein.

DSGVO + DSK-Leitlinien

Die Deutsche Datenschutzkonferenz (DSK) hat spezifische Leitlinien für KI-Systeme über ihren gesamten Lebenszyklus veröffentlicht:

EU-KI-Gesetz — Die neue Compliance-Ebene

Das EU-KI-Gesetz (Verordnung 2024/1689) führt Verpflichtungen ein, die speziell für den Unternehmens-KI-Einsatz relevant sind:

• General-Purpose AI Models (GPAI): Anbieter müssen technische Dokumentation führen, Urheberrechtsrichtlinien einhalten und Zusammenfassungen der Trainingsinhalte veröffentlichen

• Hochrisiko-KI-Systeme: Betreiber müssen Risikomanagement, Data Governance, technische Dokumentation und menschliche Aufsicht implementieren

• Open-Source-Ausnahme: Modelle, die unter freien und Open-Source-Lizenzen mit öffentlich verfügbaren Gewichten und Architektur veröffentlicht werden, sind von bestimmten Anbieterverpflichtungen ausgenommen — es sei denn, sie stellen ein systemisches Risiko dar

• Systemisches-Risiko-Schwellenwert: Modelle mit signifikantem Trainings-Compute (derzeit >10²⁵ FLOPs) lösen zusätzliche Verpflichtungen aus — Evaluation, adversariales Testen, Incident Reporting und Cybersicherheitsanforderungen

Die regulatorische Richtung ist klar: Das sicherste KI-System ist eines, das niemals Ihre Infrastruktur verlässt.

Teil 2 — Warum „Cloud-KI mit einem DPA” keine Datensouveränität ist

Viele Anbieter bieten „DSGVO-konforme” KI-Dienste mit Datenverarbeitungsverträgen an. Dies ist nicht dasselbe wie Souveränität.

Ein DPA ist ein rechtliches Versprechen. Eine air-gapped Architektur ist eine technische Tatsache. Im Unternehmens-KI-Bereich sind Fakten sicherer als Versprechen.

Teil 3 — Architektur: On-Premise-LLM + Air-Gapped RAG

Die Referenzarchitektur für souveräne Unternehmens-KI:

┌─────────────────────────────────────────────────────────────────────┐
│                    AIR-GAPPED UNTERNEHMENSNETZWERK                  │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │                    ANWENDUNGS-EBENE                           │  │
│  │  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────┐   │  │
│  │  │  Chat-UI    │  │  API-Gateway│  │  Business-Apps      │   │  │
│  │  └──────┬──────┘  └──────┬──────┘  └──────────┬──────────┘   │  │
│  └─────────┼────────────────┼────────────────────┼──────────────┘  │
│            │                │                    │                  │
│  ┌─────────▼────────────────▼────────────────────▼──────────────┐  │
│  │                   ORCHESTRIERUNGS-EBENE                      │  │
│  │              (LangGraph / Agent Framework)                   │  │
│  └─────────────────────────────┬────────────────────────────────┘  │
│                                │                                    │
│  ┌─────────────────────────────▼────────────────────────────────┐  │
│  │                    RETRIEVAL-EBENE (RAG)                     │  │
│  │  ┌─────────────────┐  ┌─────────────────┐  ┌──────────────┐  │  │
│  │  │  Lokaler        │  │  Vektor-Store   │  │  Re-Ranker   │  │  │
│  │  │  Embedder       │  │  (Lokal)        │  │  (Optional)  │  │  │
│  │  │  (GPU/CPU)      │  │                 │  │              │  │  │
│  │  └─────────────────┘  └─────────────────┘  └──────────────┘  │  │
│  └─────────────────────────────┬────────────────────────────────┘  │
│                                │                                    │
│  ┌─────────────────────────────▼────────────────────────────────┐  │
│  │                    INFERENZ-EBENE                            │  │
│  │  ┌─────────────────────────────────────────────────────────┐ │  │
│  │  │           vLLM / TGI Inference Server                   │ │  │
│  │  │      (Open-Weights-Modell: Llama, Qwen, Mistral)        │ │  │
│  │  └─────────────────────────────────────────────────────────┘ │  │
│  └──────────────────────────────────────────────────────────────┘  │
│                                                                     │
│  ┌──────────────────────────────────────────────────────────────┐  │
│  │                    DATEN-EBENE (ISOLIERT)                    │  │
│  │  Knowledge Base  │  Document Store  │  Vector Index          │  │
│  └──────────────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────────────┘
                              │
                              ▼
                    ┌─────────────────┐
                    │  KEINE INTERNET-│
                    │  VERBINDUNG     │
                    │  (Air-Gapped)   │
                    └─────────────────┘

Jede Komponente läuft auf Infrastruktur, die Sie kontrollieren. Keine Daten überqueren die Netzwerkgrenze. Keine API-Aufrufe verlassen das Gebäude.

Teil 4 — Open-Weights-Modellauswahl: Die Lizenz ist entscheidend

Nicht alle „offenen” Modelle sind gleich. Für den kommerziellen Unternehmenseinsatz ist Lizenzklarheit ebenso wichtig wie Modellqualität.

Lizenzrisiko-Matrix für Unternehmensbereitstellung

Engineering-Entscheidung: Für die deutsche Unternehmensbereitstellung eliminieren Apache-2.0- und MIT-lizenzierte Modelle das Lizenzrisiko vollständig. Qwen3 und Mistral Small 3.1 sind die empfohlenen Standards für die meisten Enterprise-RAG-Workloads.

Hardware-Anforderungen (Q4_K_M-Quantisierung)

Praktischer Hinweis: Q4_K_M-Quantisierung bewahrt 95-98 % der Vollpräzisionsqualität bei 4-facher VRAM-Reduktion. Für die meisten Enterprise-RAG-Anwendungen ist dies der optimale Kosten-/Qualitätskompromiss.

Teil 5 — vLLM in air-gapped Umgebungen: Der Deployment-Leitfaden

vLLM ist der Produktionsstandard für Hochdurchsatz-Inferenz vor Ort. Air-gapped Bereitstellung erfordert spezifische Konfiguration.

Schritt 1: Modellvorbereitung (Verbundene Phase)

Laden Sie das Modell und alle erforderlichen Dateien in ein lokales Verzeichnis herunter, bevor Sie air-gappen:

# Auf einer verbundenen Maschine (einmalig)
huggingface-cli download Qwen/Qwen3-32B --local-dir /path/to/models/qwen3-32b
# Stellen Sie sicher, dass ALLE Dateien vorhanden sind: config.json, tokenizer-Dateien, Modellgewichte

Kritisch: Bei gated Modellen stellen Sie sicher, dass jede erforderliche Datei heruntergeladen ist. vLLM ruft nicht immer alle Dateien automatisch ab.

Schritt 2: Air-Gapped Bereitstellung

# Auf dem air-gapped Server
export HF_HUB_OFFLINE=1

# Modell aus lokalem Pfad bereitstellen
vllm serve /path/to/models/qwen3-32b \
  --tensor-parallel-size 2 \
  --gpu-memory-utilization 0.90 \
  --max-model-len 8192 \
  --quantization awq \
  --disable-log-stats

Die Umgebungsvariable HF_HUB_OFFLINE=1 verhindert jegliche Netzwerkversuche. Wenn das Modell im lokalen HuggingFace-Cache liegt, kann vLLM es über den Modellnamen ohne Netzwerkzugriff auflösen.

Schritt 3: Verifikation

Bestätigen Sie, dass der Server vollständig offline läuft:

curl http://localhost:8000/v1/models
# Sollte das Modell ohne externe Aufrufe zurückgeben

Teil 6 — Air-Gapped RAG: Embeddings und Vektor-Store

RAG erfordert Embeddings. In einer air-gapped Umgebung müssen Embeddings ebenfalls lokal sein.

Lokale Embedding-Modellauswahl

Engineering-Empfehlung: Für maximale Retrieval-Qualität in air-gapped Umgebungen verwenden Sie mxbai-embed-large (über Ollama) für GPU-beschleunigtes Embedding oder bge-base-en-v1.5 für CPU-only-Bereitstellungen.

Vektor-Store-Optionen (Lokal)

Für die meisten Unternehmensbereitstellungen bieten FAISS oder ChromaDB das beste Gleichgewicht zwischen Einfachheit und Performance in air-gapped Kontexten.

Vollständige Air-Gapped RAG-Pipeline

# Air-gapped RAG-Pipeline (konzeptionell)
import chromadb
import ollama

# Lokales Embedding über Ollama
def embed(text):
    return ollama.embeddings(model="mxbai-embed-large", prompt=text)["embedding"]

# Lokaler Vektor-Store
client = chromadb.PersistentClient(path="/air-gapped/vector-store")
collection = client.get_or_create_collection(
    name="enterprise_knowledge",
    metadata={"hnsw:space": "cosine"}
)

# Lokales LLM über vLLM (OpenAI-kompatibler Endpunkt)
from openai import OpenAI
client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="not-needed"  # Air-gapped, keine externe Authentifizierung
)

# RAG-Abfrage
def query(question):
    # 1. Abfrage lokal einbetten
    query_embedding = embed(question)
    
    # 2. Aus lokalem Vektor-Store abrufen
    results = collection.query(
        query_embeddings=[query_embedding],
        n_results=5
    )
    
    # 3. Mit lokalem LLM generieren
    context = "\n".join(results["documents"][0])
    response = client.chat.completions.create(
        model="Qwen/Qwen3-32B",
        messages=[
            {"role": "system", "content": "Antworten Sie nur basierend auf dem bereitgestellten Kontext."},
            {"role": "user", "content": f"Kontext:\n{context}\n\nFrage: {question}"}
        ]
    )
    
    return response.choices[0].message.content

Engineering-Auswirkung: Vollständige RAG-Pipeline — Embedding, Retrieval und Generierung — mit null externen Netzwerkaufrufen.

Teil 7 — Retrieval-Performance: Kostet Air-Gapping Qualität?

Der häufige Einwand: „Lokale Modelle können Cloud-API-Qualität nicht erreichen.”

Das war 2023 wahr. Es ist 2025 nicht mehr wahr.

Qualitätsvergleich: Lokal vs. Cloud

Kern-Erkenntnis: Für RAG-gestützte Anwendungen — wo die Rolle des Modells darin besteht, abgerufenen Kontext zu synthetisieren, nicht aus reinem parametrischem Wissen zu schließen — ist die Qualitätslücke zwischen lokalen und Cloud-Modellen vernachlässigbar. Die Retrieval-Ebene trägt die Genauigkeitslast, und diese Ebene ist ohnehin vollständig lokal.

Performance-Optimierung für Air-Gapped RAG

Fazit: Air-Gapping opfert keine Retrieval-Performance. Es verlagert sie auf Infrastruktur, die Sie kontrollieren.

Teil 8 — EU-KI-Gesetz-Compliance: Engineering-Checkliste

Für deutsche Unternehmen, die KI-Systeme bereitstellen, ist Compliance ein architektonisches Anliegen. Diese Checkliste ordnet regulatorische Anforderungen Engineering-Implementierungen zu.

Architekturprinzip: Compliance ist kein Feature, das hinzugefügt wird. Sie ist eine Eigenschaft der Architektur selbst.

Teil 9 — Wann diese Architektur verwendet werden sollte (und wann nicht)

On-Premise, air-gapped LLM + RAG verwenden, wenn:

• ✅ Datenleck ein regulatorisches oder existenzielles Risiko ist

• ✅ Die Organisation unter DSGVO-, BDSG- oder EU-KI-Gesetz-Verpflichtungen operiert

• ✅ Die Wissensbasis proprietär und hochwertig ist

• ✅ Der Anwendungsfall RAG-gestützt ist (Q&A, Dokumentenanalyse, Entscheidungsunterstützung)

• ✅ Vorhersehbare Latenz und Durchsatz erforderlich sind

• ✅ Audit und Nachverfolgbarkeit vorgeschrieben sind

NICHT verwenden, wenn:

• ❌ Die Aufgabe rein kreativ ohne sensible Daten ist

• ❌ Der Organisation GPU-Infrastruktur fehlt (Managed Private Cloud erwägen)

• ❌ Frontier-Level-Reasoning bei neuartigen Problemen die primäre Anforderung ist

• ❌ Das Latenzbudget lokale Inferenz nicht zulässt (in der Praxis selten)

Fazit — Souveränität ist eine Engineering-Entscheidung

Die KI-Industrie hat zwei Jahre damit verbracht, zu debattieren, was Modelle können. Die Unternehmensfrage ist anders:

Was können wir einsetzen, ohne die Kontrolle über unsere Daten zu verlieren?

Für deutsche Unternehmen — und jede Organisation unter strengen Datenschutzregimen — ist die Antwort klar:

On-Premise-LLMs. Air-gapped RAG. Open-Weights-Modelle mit klaren Lizenzen. vLLM für Inferenz. Lokale Embeddings. Auditierbare Orchestrierung.

Dies ist kein Kompromiss bei der Qualität. Es ist eine bewusste architektonische Entscheidung, die KI-Fähigkeit mit Datensouveränität, regulatorischer Compliance und langfristiger operativer Kontrolle in Einklang bringt.

Die Technologie existiert. Die Muster sind bewiesen. Die einzige Frage ist, ob die Architektur mit Souveränität als erstklassige Anforderung entworfen wird — oder nach einer Compliance-Prüfung angeflanscht wird.

Im Unternehmens-KI-Bereich ist Datensouveränität kein Feature. Sie ist das Fundament.

Hinweis des Autors

Dieser Artikel spiegelt architektonische Muster wider, die bei der Entwicklung von Binesh AI — einem benutzerdefinierten trainierbaren LLM-Framework mit On-Premise-Bereitstellung, RAG-Pipelines und Multi-Agenten-Orchestrierung — entwickelt wurden. Für die Zusammenarbeit an souveräner Enterprise-KI-Architektur erreichen Sie mich über die Kontaktseite.