In regulierten Branchen enden die meisten Gespräche über KI-Einführung bei derselben Frage: „Und wo liegen unsere Daten?" Wenn ein Chefarzt, ein Compliance Officer einer Bank oder ein Partner einer Anwaltskanzlei das fragt, ist das keine rhetorische Frage — hinter der falschen Antwort stehen Bußgeld, Lizenzentzug oder strafrechtliche Haftung.
Dieser Artikel handelt nicht davon, *ob* man on-prem gehen soll — das haben wir im Vergleich von lokalem LLM und Cloud behandelt. Hier geht es darum, *wie* man eine On-Prem-LLM-Infrastruktur aufbaut, die vor dem Regulierer, dem IT-Audit und dem Tagesbetrieb besteht.
Warum Cloud nicht ausreicht — auch wenn der Provider DSGVO verspricht
Cloud-Provider verfügen über ausgezeichnete Sicherheitszertifizierungen. Das Problem liegt nicht in ihrer Technologie — das Problem ist die rechtliche Konstruktion und die Architektur der Datenflüsse.
Wenn Sie einen Prompt an eine externe API senden, verlassen die Daten physisch Ihre Infrastruktur. Auch wenn der Provider Ihre Requests nicht persistiert (und die meisten Enterprise-Tiers behaupten das heute), haben Sie aus Sicht von DSGVO Art. 28 eine Auftragsverarbeitungsbeziehung begründet. Das erfordert einen unterzeichneten Auftragsverarbeitungsvertrag (AVV), die Überprüfung des Drittanbieters und ein Verzeichnis der Verarbeitungstätigkeiten.
Für Gesundheitseinrichtungen kommt in den USA HIPAA hinzu, in der EU die lokale Umsetzung der EDPB-Empfehlungen. Für Banken gelten EBA ICT Risk und das DORA-Framework. Für Anwaltskanzleien ist die Frage noch einfacher: Das Anwaltsgeheimnis unterscheidet nicht zwischen Papier und einem API-Request.
On-Prem eliminiert das Data-Egress-Risiko im Grundsatz. Kein einziges Token Ihrer Patienten, Mandanten oder Transaktionen verlässt Ihr Netzwerk. Das ist ein Unterschied, der kein Marketing-Framing braucht — er ist ein auditierbarer technischer Fakt.
Seien wir dabei ehrlich: On-Prem allein reicht für Compliance nicht aus. Der Regulierer möchte Audit-Logs, Zugriffskontrollen, Verschlüsselung der Daten im Ruhezustand und in der Übertragung, einen dokumentierten Incident-Response-Prozess und regelmäßige Risikoanalysen sehen. „Das läuft bei uns auf dem Server" ist ein Anfang, kein Ziel.
Was eine On-Prem-LLM-Architektur enthalten muss
Vor der Auswahl von GPU und Modell muss definiert werden, was eigentlich gebaut wird. Eine funktionsfähige On-Prem-LLM-Architektur für regulierte Branchen besteht aus fünf Schichten:
1. Serving-Engine und Inferenzschicht
Für den produktiven Multi-User-Betrieb sind zwei Hauptframeworks relevant:
- `vLLM` — Industriestandard für High-Throughput-Serving. PagedAttention reduziert die KV-Cache-Fragmentierung drastisch, Continuous Batching eliminiert das Warten auf den langsamsten Request im Batch. Breiteste Hardware-Unterstützung (NVIDIA, AMD, Gaudi).
- `SGLang` — vorteilhaft bei RAG-Workloads und mehrstufigen Dialogen dank RadixAttention, das den KV-Cache gemeinsamer Präfixe zwischenspeichert. Bei prefix-lastigen Workloads erreicht es höheren Throughput und niedrigere Latenz des ersten Tokens (TTFT) als vLLM.
Für Einzelentwickler-Experimente und Piloten ist Ollama in Ordnung. Für ein Produktivsystem mit Dutzenden gleichzeitiger Nutzer ist es unterdimensioniert — darunter läuft llama.cpp, das nicht für concurrent Requests ausgelegt ist, und der Throughput-Unterschied ist bei mehreren parallelen Anfragen erheblich.
2. Modell — was Sie sich leisten können und was es leistet
Die Modellauswahl für On-Prem ist primär eine Hardware-Frage. Die VRAM-Kapazität bestimmt, was betrieben werden kann.
Orientierungswerte für den VRAM-Bedarf bei der Inferenz (für on-prem übliche Formate):
- 7–9B-Modell: ~5–7 GB VRAM bei Q4_K_M-Quantisierung, ~8–13 GB bei Q8_0
- 13B-Modell: ~8 GB bei Q4_K_M, ~14 GB bei Q8_0
- 34B-Modell: ~17–20 GB bei Q4_K_M, ~30–34 GB bei Q8_0
- 70B-Modell: ~35–40 GB bei Q4_K_M, ~70–75 GB bei Q8_0
Dazu kommt der KV-Cache — bei langen Kontexten kann er genauso groß sein wie die Modellgewichte selbst. Für den Produktivbetrieb mit mehreren gleichzeitigen Requests und mittellangen Kontexten sollten deutliche Reserven über dem VRAM für die reinen Gewichte eingeplant werden.
Aus den Open-Weight-Modellen, die für regulierte Branchen im Jahr 2026 sinnvoll sind:
- Llama 4 Maverick und Scout (Meta, eigene Lizenz) — MoE-Architektur, starke Leistung, 1M+ Kontext. Die Meta-Custom-Lizenz ist für die meisten Enterprise-internen Deployments ausreichend.
- Qwen 3 Familie (Alibaba, Apache 2.0) — ausgezeichnete Leistung bei dokumentenlastigen Aufgaben, mehrsprachige Unterstützung inklusive europäischer Sprachen, permissive Lizenz.
- Mistral Small (Apache 2.0) — europäischer Anbieter (Plus-Punkt für DSGVO-Argumentation), permissive Lizenz. Das größere Mistral Large hat eine eigene Mistral-Lizenz — für kommerzielle On-Prem-Deployments sollte diese geprüft werden.
- Phi-4 (Microsoft, MIT) — für Use-Cases, bei denen 7–14B Parameter ausreichen; geringer Hardware-Bedarf, gutes Instruktions-Following.
Für regulierte Branchen empfehlen wir Modelle mit permissiver Lizenz (Apache 2.0, MIT) — die kommerzielle Nutzung ist eindeutig, und ein Lizenz-Audit ist unkompliziert.
3. Quantisierung — ein Kompromiss, der meist akzeptabel ist
Quantisierung reduziert den VRAM-Footprint und erhöht den Throughput, auf Kosten leicht geringerer Genauigkeit. Für regulierte Branchen ist die entscheidende Frage: Welcher Kompromiss ist für die jeweilige Aufgabe akzeptabel?
Praktischer Überblick der Formate:
- Q8_0 (GGUF): erhält ~98–99 % der Qualität gegenüber FP16, minimaler Verlust. Für kritische Aufgaben (Rechtsanalyse, medizinische Dokumentation) ist das die sichere Wahl.
- Q4_K_M (GGUF): ~92–95 % Qualität, deutlich geringere VRAM-Anforderungen. Sweet Spot für die meisten Dokumentations- und RAG-Use-Cases. Der Unterschied zu Q8 ist im normalen Gesprächsfluss kaum wahrnehmbar.
- AWQ 4-bit: geeignet für NVIDIA-GPUs, bessere Kohärenz bei langen Ausgaben als GPTQ.
- Q2 und darunter: deutliche Qualitätsdegradation — für regulierte Branchen nicht empfohlen.
Wichtiger Hinweis: Die Perplexitätsunterschiede zwischen Q4_K_M und BF16 liegen in den meisten Benchmarks unter 6 %. Das bedeutet nicht, dass jede Aufgabe gleich robust ist — komplexes mehrstufiges Schlussfolgern und präzise Extraktion strukturierter Informationen können empfindlicher sein. Validieren Sie das Modell vor dem Produktivbetrieb immer anhand einer Stichprobe realer Daten aus Ihrer Domäne.
4. Datenschicht und RAG
Für die meisten regulierten Use-Cases reicht das Modell allein nicht aus — es muss an interne Dokumentation, Vorschriften und Fallhistorie angebunden werden. Hier kommt RAG (Retrieval-Augmented Generation) ins Spiel.
Schlüsselkomponenten:
- Vektordatenbank lokal deployed:
Qdrant(Open-Source, Rust-Backend, DSGVO-freundliches europäisches Unternehmen),pgvector(PostgreSQL-Erweiterung, einfach wenn PG bereits vorhanden), oderMilvus. - Embedding-Modell lokal:
BGE-M3(BAAI) deckt mehrere europäische Sprachen und Retrieval-Typen in einem Modell ab. Läuft lokal, kein Cloud-Kontakt. - Chunking und Metadaten: Für Krankenakten oder Rechtsdokumente ist strukturiertes Chunking nach logischen Einheiten (Artikel, Absatz, Fall) deutlich besser als naives Aufteilen nach N Tokens.
Die Größe des Kontextfensters moderner Modelle (1M+ Tokens) ist verlockend, aber kein Ersatz für RAG in einem Produktivsystem. Der KV-Cache für 1M Kontext belegt zusätzlich Dutzende GB VRAM, die TTFT-Latenz steigt drastisch. Für die meisten Dokumentations-Use-Cases ist der hybride Ansatz (Retrieval + kürzerer Kontext) wirtschaftlich und leistungstechnisch überlegen.
5. Audit, Zugriffskontrollen und Monitoring
Das ist die Schicht, die technische Teams am häufigsten aufschieben — und auf der Regulierer am meisten bestehen.
Mindestanforderungen für On-Prem LLM in regulierten Umgebungen:
- Audit-Log jedes Requests: wer hat gefragt, wann, wie lautete der Prompt (oder sein Hash), wie lautete die Ausgabe (oder ihr Hash), welche Modellversion hat geantwortet. Logs müssen tamper-evident sein (Write-Once-Speicher oder Signierung).
- Rollenbasierter Zugriff: Ein Arzt sieht die Akten seiner Patienten, nicht das gesamte Krankenhaus. Der LLM-Endpoint muss dieselben ACL-Regeln respektieren wie der Rest des Systems.
- Verschlüsselung at-rest und in-transit: Modellgewichte, Vektordatenbank, Logs — alles verschlüsselt. TLS für die gesamte interne Kommunikation.
- Netzwerkisolierung: Der LLM-Inference-Server sollte keinen direkten Internetzugang haben. Air-Gap oder minimale Outbound-Firewall für den Serving-Knoten.
- Model Version Pinning: In regulierten Branchen müssen Sie belegen können, mit welchem Modell eine Entscheidung getroffen wurde — auch ein Jahr später. Versionierung der Gewichte und deterministische Reproduzierbarkeit sind Audit-Anforderungen.
Hardware — was Sie tatsächlich brauchen
On-Prem LLM ist keine günstige Lösung. Es ist eine Investition, die dort Sinn ergibt, wo die Alternative (Cloud-Compliance-Overhead, Risikoversicherung für Datenlecks, Bußgeld) teurer ist.
Orientierungswerte für 2026:
- Entry Level (7–13B-Modell, 1–5 gleichzeitige Nutzer): eine NVIDIA RTX 4090 (24 GB VRAM) oder A4000 (16 GB VRAM). Für 13B in Q4_K_M reicht das, für 13B in Q8_0 benötigen Sie entweder Dual-GPU oder eine 4090.
- Mid Tier (34B-Modell oder 70B in Q4_K_M, 5–20 gleichzeitige Nutzer): zwei A5000 (24 GB × 2 = 48 GB), A6000 (48 GB), oder der Consumer-Weg — zwei RTX 4090 in Tensor-Parallelismus über NVLink/PCIe.
- Production Tier (70B in Q8_0 oder höher, 20+ gleichzeitige Nutzer): A100 80 GB oder H100 80 GB. Auf einer einzelnen H100 können Sie 70B Q8_0 mit vertretbarer Latenz komfortabel betreiben.
- Apple-Silicon-Alternative: M4 Ultra / M5 Ultra mit vereinheitlichtem Arbeitsspeicher von 128–192 GB ist eine sinnvolle On-Prem-Option für 70B FP16, wenn stiller Serverraum und niedriger Stromverbrauch Priorität haben. Der Throughput liegt unter dem einer H100, kann aber für interne Deployments mit geringem Concurrency ausreichen.
Vergessen Sie nicht den CPU-Arbeitsspeicher — beim CPU-Offloading (wenn GPU-VRAM nicht ausreicht) läuft ein Teil des Modells im RAM. Für einen Produktivbetrieb mit Offloading benötigen Sie mindestens 128 GB RAM.
Was On-Prem LLM nicht ist
Vermutlich der häufigste Irrtum im Entscheidungsprozess: On-Prem LLM bedeutet nicht automatisch Compliance. Wir haben Organisationen erlebt, die Ollama auf einer Workstation installierten und mit Überzeugung behaupteten, DSGVO-konform zu sein, weil „die KI lokal läuft".
Compliance ist ein Prozess, kein Installationsstatus. Zur On-Prem-Infrastruktur müssen Sie hinzufügen:
- Eine formale Risikoanalyse und DSFA (Datenschutz-Folgenabschätzung), wenn Sie sensible personenbezogene Daten verarbeiten
- Einträge im Verzeichnis der Verarbeitungstätigkeiten, die das LLM-System umfassen
- Aufbewahrungsregeln — wie lange werden Audit-Logs aufbewahrt, wer hat Zugriff
- Einen Incident-Response-Plan — was passiert mit den Logs bei einem Sicherheitsvorfall, wer meldet dem Regulierer
- Regelmäßige Penetrationstests der Inference-Endpoints
Technische Teams, die das ohne rechtlichen Input lösen, produzieren meist ein System, das technisch funktioniert, aber beim Compliance-Audit an der Prozessdokumentation scheitert.
Vergleich: On-Prem vs. Sovereign Cloud vs. klassische Cloud
Für regulierte Branchen gibt es tatsächlich drei Varianten, nicht zwei:
- Klassische Cloud-API (OpenAI, Anthropic, Google): geringster Overhead, höchste Leistung, aber Data Egress ist real. Geeignet für Use-Cases ohne sensible PII oder durch Branchenvorschriften geschützte Daten.
- Sovereign Cloud / EU-Region (Azure OpenAI EU, Anthropic Sovereign EU, OVH AI): Daten bleiben in der EU, der Provider ist an EU-Verträge gebunden, Preisliste höher. Für viele Organisationen ist das ein besserer Kompromiss als Full-On-Prem — geringere Hardware-Investition, höhere Modellleistung, bei Wahrung des DSGVO-Rahmens.
- Full-On-Prem / Air-Gap: kein Data Egress, volle Kontrolle, Auditierbarkeit im strengsten Sinne. Erfordert Hardware-Investition, eigenen Betrieb, eigenen Security-Stack. Die einzige Wahl bei den strengsten Regulierungen (z. B. Verarbeiter klassifizierter Informationen, bestimmte Arten von Gesundheitsdaten).
Für die meisten SK/EU-Unternehmen in regulierten Branchen ist Sovereign Cloud kombiniert mit selektivem On-Prem für die sensibelsten Workloads der pragmatische Weg. Nicht alle LLM-Aufgaben müssen on-prem laufen — nur jene, bei denen die Daten es erfordern.
Guardrails und Modellsicherheit
On-Prem-Deployment löst das externe Data-Egress-Risiko, aber nicht interne Risiken. Das Modell kann halluzinieren, irreführende medizinische oder rechtliche Inhalte produzieren oder durch Prompt Injection missbraucht werden.
Für regulierte Branchen sind folgende Maßnahmen unabdingbar:
- Output-Validierung: LLM-Ausgaben sollten vor der Anzeige oder Weiterverarbeitung eine Validierungsschicht durchlaufen. Für strukturierte Ausgaben (Datenextraktion aus Dokumenten, Klassifikation) verwenden Sie Constrained Decoding (
XGrammar-Backend invLLModerSGLang). - Human-in-the-Loop für kritische Entscheidungen: Kein On-Prem-Modell sollte automatisch Gesundheitsempfehlungen unterzeichnen, Kredite genehmigen oder rechtlich bindende Dokumente ohne menschliche Kontrolle erzeugen. Mehr dazu in Human-in-the-Loop für Agenten.
- Output-Monitoring: Überwachung von Ablehnungen, ungewöhnlichen Mustern in Prompts sowie Versuchen, den System-Prompt oder Kontext zu extrahieren.
Häufige Fragen
Ist On-Prem LLM immer teurer als Cloud?
Bei niedrigem Anfragevolumen (bis zu einigen Tausend Requests täglich) ist die Cloud-API günstiger — Sie müssen nicht in GPUs investieren. Bei hohem Volumen schneiden sich die Kurven: Ein eigener GPU-Server amortisiert sich typischerweise in 1–2 Jahren bei mittlerer Last. Für regulierte Branchen geht es aber primär nicht um den Preis — es geht darum, was Ihre Organisation aus Compliance-Sicht verantworten kann.
Wie viel VRAM brauche ich für typische Unternehmensanwendungen?
Für die meisten Unternehmens-Use-Cases (Dokumentenanalyse, interner Copilot, Klassifikation) reicht ein 7–13B-Modell in Q4_K_M-Quantisierung. Dafür genügt eine NVIDIA RTX 4090 (24 GB) oder A5000 (24 GB). Wenn Sie ein größeres Modell (34B oder 70B) für anspruchsvollere Rechts- oder Medizinanalysen benötigen, planen Sie Dual-GPU oder eine Profikarte mit 48–80 GB VRAM ein.
Muss ich ISO 27001 oder eine andere Zertifizierung haben, damit On-Prem LLM legal ist?
Nicht direkt — weder die DSGVO noch Branchenvorschriften verlangen konkrete Zertifizierungen, aber sie fordern „angemessene technische und organisatorische Maßnahmen". ISO 27001 ist die Praxis, die belegt, dass Sie Risiken systematisch gemanagt haben — sie vereinfacht den Compliance-Audit erheblich und wird von Geschäftspartnern zunehmend eingefordert.
Kann ich ein Open-Weight-Modell kommerziell ohne rechtliche Risiken nutzen?
Das hängt von der Lizenz ab. Apache 2.0 und MIT sind vollständig kommerziell nutzbar ohne Einschränkungen. Die Meta-Llama-Lizenz erlaubt kommerzielle Nutzung, erfordert aber bei mehr als 700 Millionen aktiven Nutzern eine Sondergenehmigung — für enterprise-interne Deployments ist das nicht relevant. Prüfen Sie immer den aktuellen Lizenztext bei der Modellauswahl.
Wie stelle ich sicher, dass das Modell keine Unternehmensdaten speichert oder überträgt?
Bei lokalem Deployment persistiert das Modell selbst keine Daten — ein LLM ist ein statischer Satz von Gewichten, keine Datenbank. Das Risiko liegt in den peripheren Schichten: Logs des Serving-Frameworks, KV-Cache auf der Festplatte (wenn aktiviert), Kontextfenster, das bei Fehlkonfiguration zwischen Sessions geteilt wird. Stellen Sie sicher, dass die Serving-Engine ohne Cross-Session-Kontextteilung konfiguriert ist, Logs entweder deaktiviert oder verschlüsselt sind und KV-Cache-Offload auf die Festplatte entweder deaktiviert oder auf einem verschlüsselten Volume liegt.
*Wenn Sie On-Prem LLM für das Gesundheitswesen, Finanzen oder Recht erwägen und nicht wissen, wo Sie anfangen sollen — wir schauen uns Ihre Situation gerne konkret an. Wir helfen bei der Hardware-Auswahl, der Architektur des Serving-Stacks und dem, was Sie dem Compliance-Team vorlegen müssen. Kontaktieren Sie uns, und wir beginnen mit einer Einschätzung Ihrer tatsächlichen Anforderungen.*
