On-Premise-LLM vs. europäische Cloud-API: Speicherplanung, Datensouveränität, DSGVO und EU AI Act

Stand November 2026 · CODLAB Team

Kurzantwort: Ob ein Unternehmen Sprachmodelle auf eigenen Servern (On-Premise) oder über eine europäische Cloud-API betreibt, entscheidet sich an Schutzbedarf, Lastprofil und Betriebsfähigkeit. Echte Datensouveränität verlangt die Prüfung aller Datenwege vom Embedding bis zum Backup, realistische GPU-Speicherplanung inklusive KV-Cache sowie eine austauschbare Modellschnittstelle im Einklang mit DSGVO und EU AI Act.

1. Warum „Open Weights" allein noch keine Datensouveränität schaffen

Bei der Infrastrukturplanung für den Mittelstand stehen zwei gegensätzliche Kurzschlüsse im Weg: Sobald ein Sprachmodell mit offenen Modellgewichten (Open Weights, etwa aus der Llama- oder Mistral-Familie) gewählt wird, gilt das Thema Datenschutz vermeintlich als erledigt. Umgekehrt wird jede Nutzung einer externen Programmierschnittstelle pauschal als Kontrollverlust abgetan. Beide Annahmen greifen technisch zu kurz.

Datensouveränität ist keine Eigenschaft einer Modelldatei, sondern eine Eigenschaft des gesamten technischen und organisatorischen Datenpfads. In unserer angewandten Forschungs- und Architekturarbeit bei CODLAB für souveräne KI-Systeme zerlegen wir jedes Vorhaben zunächst in sieben konkrete Stationen, durch die vertrauliche Texte tatsächlich fließen:

1. Eingangs- und Transportweg: Terminiert die TLS-Verbindung direkt im eigenen Netz oder über externe Content-Delivery- und Proxy-Dienste Dritter?
2. Dokumentenaufbereitung und Embedding-Berechnung: Werden interne PDFs lokal zerlegt und vektorisiert — oder wandern Textabschnitte unbemerkt zu einem externen Embedding-Endpunkt, obwohl das Sprachmodell lokal läuft?
3. Vektorindex und Metadatenhaltung: Liegt die Vektordatenbank samt Berechtigungsfiltern auf kontrollierter Infrastruktur in Deutschland oder der EU (vgl. pgvector mit Django)?
4. Sprachmodell-Inferenz (Serving): Erfolgt die Token-Generierung im eigenen Rechenzentrum, auf dedizierten europäischen GPU-Instanzen oder über eine mandantengeteilte EU-API — und sind dort sowohl die Nutzung für Modelltraining vertraglich ausgeschlossen als auch (davon strikt getrennt) eine echte Zero-Data-Retention ohne anbieterseitige Zwischenspeicherung von Prompts und Ausgaben vereinbart?
5. Anwendungsprotokolle und Telemetrie: Werden vollständige Prompts, Antworten oder Fehlermeldungen in externen Monitoring-Diensten gespeichert?
6. Datensicherung (Backups): Wohin replizieren Datenbank-Snapshots der Vektor- und Gesprächsdatenbanken, und wie sind sie verschlüsselt?
7. Wartungs- und Administrationszugriffe: Wer besitzt Fernwartungsrechte auf dem Hostsystem, und aus welchen Rechtsräumen erfolgen Supportzugriffe?

Erst wenn alle sieben Stationen dokumentiert sind, lässt sich seriös beurteilen, welche Betriebsform dem Schutzbedarf gerecht wird — ohne unhaltbare Pauschalversprechen.

2. GPU-Speicherplanung jenseits naiver Faustformeln: Gewichte, Quantisierung und KV-Cache

Entscheidet sich ein Betrieb für eigenes GPU-Serving im Serverraum oder auf dedizierten Miet-GPUs, beginnt die eigentliche Ingenieurarbeit bei der Speicher- und Lastplanung. In unserer Engineering-Übersicht und insbesondere in der technischen Notiz Llama auf GPU: Speicher planen, dann messen zeigen wir, warum die reine Dateigröße eines quantisierten Checkpoints keine hinreichende Planungsgrundlage ist.

Die idealisierte Untergrenze allein für die Modellgewichte berechnet sich aus Parameterzahl mal Bitbreite geteilt durch acht — bei einem Modell mit 70 Milliarden Parametern in 4-Bit-Darstellung also rund 32,6 GiB (wobei Dezimal-Gigabyte GB und Binär-Gibibyte GiB in Datenblättern keinesfalls verwechselt werden dürfen). Im realen Serverbetrieb belegen jedoch vier zusätzliche Posten erheblichen Grafikspeicher (VRAM):

• Quantisierungs-Metadaten und Skalierungsfaktoren: Verfahren wie AWQ oder GPTQ speichern Gruppen-Skalierungen und Nullpunkte, die über die ideale Bitbreite hinausgehen. Zudem sind Formate wie GGUF, AWQ und GPTQ technisch unterschiedlich aufgebaut; eine für lokale Desktop-Tests gedachte Konfiguration lässt sich nicht blind auf produktives Server-Serving übertragen.
• Laufzeitpuffer und CUDA-Graphen: Inferenzserver reservieren Arbeitsspeicher für Zwischenaktivierungen und Kernel-Ausführungen bereits beim Modellstart.
• Der dynamische Key-Value-Cache (KV-Cache): Während der autoregressiven Generierung muss das Modell für jedes verarbeitete und erzeugte Token die Aufmerksamkeitsvektoren (Keys und Values) über alle Schichten hinweg im Speicher vorhalten. Lange Dokumentkontexte im RAG-Betrieb und mehrere gleichzeitig aktive Anfragen lassen diesen Speicherbedarf linear mit Kontextlänge und Parallelität anwachsen.
• Speicherfragmentierung unter Parallellast: Klassische Server-Implementierungen reservierten zusammenhängende Speicherblöcke für die maximal mögliche Sequenzlänge und verschenkten dadurch große Teile des GPU-Speichers. Erst seitenbasierte Speicherverwaltung wie PagedAttention in vLLM teilt den KV-Cache in nicht zusammenhängende Blöcke auf, reduziert interne wie externe Fragmentierung drastisch und ermöglicht stabiles Continuous Batching (Kwon et al., SOSP 2023, arXiv:2309.06180).

Ebenso wichtig für die Betriebsplanung (vgl. Betrieb, Wartung & Weiterentwicklung): Eine zweite Grafikkarte im selben Gehäuse vergrößert zwar den verfügbaren Gesamtspeicher für Tensor-Parallelität, schafft aber noch keine Hochverfügbarkeit — fällt das gemeinsame Netzteil, Mainboard oder Host-Update aus, steht der Dienst dennoch still.

3. Architektur ohne Anbieter-Lock-in: Was für austauschbare Endpunkte wirklich nötig ist

Aus Forschungssicht ist es unklug, Geschäftslogik, Quellenzitate und Zugriffsfilter hart an das proprietäre SDK eines einzelnen Cloud-Anbieters zu ketten. In unseren Django-basierten RAG-Entwürfen trennen wir deshalb zwischen lokaler Wissenshaltung in PostgreSQL und entkoppelten Modellaufrufen — benennen dabei aber transparent den Unterschied zwischen unserem Referenz-Assistenten (ragbot) im Code von codlab.de (öffentliche Chat-Demo seit Oktober 2026 abgeschaltet; Code und Daten erhalten) und einem voll umschaltbaren Unternehmensaufbau.

Im Code des Referenz-Assistenten (ragbot) erfolgt die Kosinus-Vektorsuche in PostgreSQL mit pgvector, Sicherheitsgrenzen und Quellennummerierung (vgl. Quellengrenzen für RAG) liegen im Anwendungscode, und ragbot/services.py liest bereits getattr(settings, "RAG_OPENAI_BASE_URL", "") als vorbereiteten Erweiterungspunkt. In der ausgelieferten Konfiguration von codlab.de verdrahtet codlab_site/settings.py diese Umgebungsvariable jedoch bewusst noch nicht standardmäßig, und derselbe Client bedient dort sowohl Chat-Generierung als auch Embeddings. Für echte Endpunkt-Portabilität im Unternehmensbetrieb sind daher drei explizite Schritte erforderlich: Erstens das aktive Durchreichen der Settings aus der Umgebung, zweitens geprüfte API- und Modellkompatibilität und drittens die Trennung von Chat- und Embedding-Endpunkt samt vollständiger Neuindexierung, sobald sich Embedding-Modell oder Vektordimension (1536) ändern:

# Enterprise-Konfigurationsmuster (erweitert den vorbereiteten Hook aus ragbot/services.py):
# 1. In settings.py explizit verdrahten: RAG_CHAT_BASE_URL = os.environ.get("RAG_CHAT_BASE_URL", "")
# 2. Chat- und Embedding-Client getrennt steuern; Embedding-Wechsel erfordert Re-Indexierung!
from django.conf import settings
from openai import OpenAI

def build_chat_client():
    base_url = getattr(settings, "RAG_CHAT_BASE_URL", "") or None
    api_key = getattr(settings, "RAG_CHAT_API_KEY", "")
    kwargs = {"api_key": api_key}
    if base_url:
        # Beispiel On-Premise: "https://llm-intern.firma.lan/v1" (vLLM)
        kwargs["base_url"] = base_url
    return OpenAI(**kwargs)

Erst mit dieser sauberen Trennung entstehen zwei belastbare Vorteile: Ein Fachpilot lässt sich auf einer vertraglich geprüften europäischen API erproben und später für die Antwortgenerierung ohne Umbau der Fachlogik auf eigene vLLM-Server umstellen — während das Embedding-Modell entweder beibehalten oder kontrolliert neu indexiert wird. Ebenso können neue offene Modellgenerationen reproduzierbar gegen denselben Evaluierungssatz gemessen werden.

4. Sachliche Entscheidungsmatrix für Mittelstand und Berufsgeheimnisträger

Weder „immer On-Premise" noch „immer Cloud-API" hält einer ehrlichen Wirtschaftlichkeits- und Sicherheitsprüfung stand. Für Vorhaben im industriellen und dienstleistenden Mittelstand sowie in vertraulichen Bereichen wie Rechtsanwaltskanzleien bewerten wir vier Dimensionen gemeinsam mit IT-Leitung und Fachverantwortlichen:

• Vertraulichkeitsstufe und Berufsrecht: Werden unveröffentlichte Konstruktionsdaten, Rezepturen, Personalunterlagen oder Mandatsgeheimnisse verarbeitet, die besonderen gesetzlichen Verschwiegenheitspflichten unterliegen, spricht technisch vieles für eine vollständig abgeschottete On-Premise- oder dedizierte Single-Tenant-Umgebung ohne Drittzugriff — stets flankiert durch die berufs- und datenschutzrechtliche Prüfung der zuständigen Kanzlei- oder Unternehmensjuristen.
• Lastprofil über den Arbeitstag: Eine gleichmäßig ausgelastete Dokumentenverarbeitung über viele Arbeitsplätze hinweg nutzt eigene GPU-Kapazität sinnvoll aus. Treten dagegen nur wenige, stark schwankende Spitzen pro Woche auf, steht teure eigene Hardware die meiste Zeit ungenutzt im Rack, während gleichzeitig Strom-, Kühlungs- und Wartungsaufwand anfallen.
• Eigene Betriebskompetenz: Ein lokaler vLLM-Server benötigt wie jeder produktive Infrastrukturdienst Sicherheitsupdates für Betriebssystem, Container-Laufzeit und Treiber, Überwachung von Speicherauslastung und Antwortzeiten sowie geregelte Backup- und Wiederanlaufprozesse.
• Qualitäts- und Kontextanforderungen: Kleinere und mittlere offene Sprachmodelle leisten bei sauber abgegrenztem RAG-Kontext hervorragende Dienste, stoßen aber bei sehr komplexer mehrsprachiger Synthese schneller an Grenzen als große Spitzenmodelle. Ob ein konkretes offenes Modell in 4-Bit- oder 8-Bit-Quantisierung für die Fachaufgabe ausreicht, klären wir nicht per Bauchgefühl, sondern über vergleichende Messläufe auf demselben Prüfdatensatz.

5. DSGVO und EU AI Act im Stand November 2026: Was technisch belegt sein muss

Auch ein komplett im eigenen Keller betriebener KI-Server ist kein rechtsfreier Raum. Zwei europäische Regelwerke bestimmen im November 2026 die technische Dokumentation:

1. Datenschutz-Grundverordnung (DSGVO): Sobald personenbezogene Daten in Prompts, Dokumenten oder Gesprächslogs vorkommen, gelten die Grundsätze aus Artikel 5 und 6 DSGVO unabhängig davon, ob der Server im Nachbarraum oder in einem europäischen Rechenzentrum steht (Verordnung (EU) 2016/679). Bei externen API- oder Hosting-Dienstleistern sind Auftragsverarbeitungsverträge (Artikel 28 DSGVO), technisch-organisatorische Maßnahmen (Artikel 32 DSGVO) und etwaige Drittlandbezüge einschließlich Support-Unterauftragnehmern (Kapitel V DSGVO) im Detail zu prüfen; bei hohem Risiko ist vorab eine Datenschutz-Folgenabschätzung nach Artikel 35 DSGVO durchzuführen.
2. Gestaffelte Pflichten des EU AI Act (konsolidierter Stand 27.07.2026): Die europäische KI-Verordnung (Verordnung (EU) 2024/1689, konsolidierte Fassung vom 27.07.2026 einschließlich der Änderungsverordnung (EU) 2026/1744 vom 08.07.2026) knüpft Pflichten primär an den Verwendungszweck und die Rolle (Anbieter oder Betreiber), nicht allein an den Serverstandort. Gemäß Artikel 113 gelten Kapitel I und II (verbotene Praktiken und Förderung der KI-Kompetenz nach Artikel 4) seit dem 2. Februar 2025 — mit Ausnahme der neu eingefügten Verbote in Artikel 5 Absatz 1 Unterabsatz 1 Buchstaben ba und bb sowie Artikel 5 Absätze 1a und 1b, die ab dem 2. Dezember 2026 gelten. Seit dem 2. August 2026 gelten die allgemeinen Bestimmungen einschließlich Artikel 50 (vorbehaltlich spezifischer Übergangsregeln in Artikel 111). Der durch Verordnung (EU) 2026/1744 angepasste Aufschub auf den 2. Dezember 2027 (Artikel 6 Absatz 2 und Anhang III) beziehungsweise 2. August 2028 (Artikel 6 Absatz 1 und Anhang I) betrifft in Artikel 113 Buchstabe c gezielt Kapitel III Abschnitte 1, 2 und 3 mit Ausnahme von Artikel 6 Absatz 5 — nicht pauschal jede Vorschrift mit Hochrisikobezug.

Das Bundesamt für Sicherheit in der Informationstechnik beschreibt im Leitfaden zu generativen KI-Modellen den Abfluss bzw. Zugriff auf Ein- und Ausgaben bei über das Internet angebotenen Diensten als eigenes Risiko (R2); Angriffs- und Betriebsrisiken wie Indirect Prompt Injection (R28) oder fehlerhafte Reaktionen auf Eingaben (R3) bestehen davon unabhängig vom Bereitstellungsort und erfordern eigene Schutzmaßnahmen (BSI, Version 2.0, 2025). Als strukturierte Vorbereitung für Ihr Gespräch mit Datenschutz- und Rechtsfachleuten dient unser EU-AI-Act-Leitfaden (eine technische Arbeitshilfe, keine Rechtsberatung oder Konformitätsbescheinigung).

6. Synthetisches Prüfprotokoll vor einer Hardware- oder API-Entscheidung

Hinweis zur Einordnung: Das folgende Vorgehen beschreibt unsere reproduzierbare Entscheidungsmethodik; es enthält keine erfundenen Kundenkennzahlen, Preisversprechen oder Hardware-Benchmarks.

Bevor ein Unternehmen Server-GPUs beschafft oder sich langfristig an einen API-Vertrag bindet, durchlaufen wir vier überprüfbare Schritte:

1. Datenpfad-Inventar zeichnen: Erfassung aller sieben Stationen vom Nutzereingang über Embeddings und pgvector bis zu Logs und Backups.
2. Speicher- und Parallelitätsgrenzen rechnen: Bestimmung der Gewichtsuntergrenze, der maximalen Kontextlänge und des KV-Cache-Budgets für die realistische Spitzenparallelität gemäß unserer GPU-Planungsnotiz.
3. Vergleichslauf über dieselbe Schnittstelle: Ausführung identischer Fach- und Ablehnungsfragen in mehreren Durchläufen sowohl gegen das Kandidaten-Modell im Ziel-Quantisierungsformat als auch gegen eine Referenz-API.
4. Betriebs- und Notfallkonzept festlegen: Klärung von Patch-Zyklen, Überwachung, Ausfallverhalten und internen Zuständigkeiten vor dem Produktivstart.

Wenn Sie für Ihr Vorhaben nüchtern abwägen möchten, ob lokales Serving, dediziertes EU-Hosting oder eine hybride Architektur technisch und wirtschaftlich trägt, unterstützen wir Sie herstellerunabhängig — mehr dazu unter Souveräne KI & Daten sowie direkt unter Kontakt & Erstgespräch.

Weiterführend in dieser Forschungsreihe: Wie die konkrete Index- und Sucharchitektur auf PostgreSQL und pgvector aufgebaut wird, erläutert unser Beitrag zu Hybrid Retrieval, Chunking und Reranking; welche Schutzmaßnahmen gegen standortunabhängige Risiken wie R28 (Indirect Prompt Injection) erforderlich sind, vertieft die Analyse zu RAG-Sicherheit und Quellengrenzen.

Verifizierte Primärquellen

• Kwon, W., Li, Z., Zhuang, S., Sheng, Y., Zheng, L. et al. (2023): Efficient Memory Management for Large Language Model Serving with PagedAttention (SOSP 2023, arXiv:2309.06180).
• Amt für Veröffentlichungen der EU (Cellar): Verordnung (EU) 2024/1689 (AI Act), konsolidierte Fassung vom 27.07.2026, insbesondere Artikel 4, 50, 111 und 113.
• Amt für Veröffentlichungen der EU (Cellar): Verordnung (EU) 2026/1744 vom 08.07.2026 (Digital-Omnibus-Verordnung zur KI).
• Amt für Veröffentlichungen der EU (Cellar): Verordnung (EU) 2016/679 (Datenschutz-Grundverordnung / DSGVO), insbesondere Artikel 5, 6, 9, 28, 32, 35 und Kapitel V.
• Bundesamt für Sicherheit in der Informationstechnik / BSI (2025): Generative KI-Modelle — Chancen und Risiken für Industrie und Behörden, Version 2.0 vom 17.01.2025.

Ergänzender Praxisleitfaden im Blog: KI im Unternehmen einführen: Vom Arbeitsauftrag zur überprüfbaren Freigabe.