Selbst gehostete KI für regulierte Branchen: Kosten + Architektur

Für einige Branchen ist die Wahl zwischen Cloud-LLM-APIs und selbst gehosteten Modellen eine regulatorische Festlegung, keine geschäftliche Präferenz. EU-DSGVO, die KRITIS-Leitlinien des deutschen BSI, US-ITAR für Defense-Auftragnehmer, HIPAA im Gesundheitswesen und mehrere Finanzdienstleistungs-Frameworks engen die Deployment-Optionen ein. Dieser Leitfaden behandelt, wann Self-Hosting verpflichtend ist, was Air-Gap für LLM-Deployments 2026 tatsächlich bedeutet, die Hardware-Ökonomie und das Betriebsmuster für die Produktion unter Audit.

Wann Self-Hosting nicht optional ist

Fünf regulatorische Kontexte engen den LLM-Einsatz auf Self-Hosting oder Sovereign-Cloud ein.

• EU-DSGVO + sensible Daten: Artikel 28 zur Auftragsverarbeitung und Beschränkungen für internationale Übermittlungen begrenzen, welche Cloud-LLM-Anbieter ein Verantwortlicher für besondere Datenkategorien (Gesundheit, Biometrie, ethnische Herkunft, sexuelle Orientierung) nutzen kann.
• Deutsches BSI / KRITIS: KRITIS-Betreiber sehen sich Erwartungen an Datenresidenz und Beschränkungen für die Nutzung von KI-Drittdiensten in operativen Systemen gegenüber.
• US-ITAR / EAR (kontrollierte Technologie): Exportkontrollierte Informationen können nicht von Cloud-Diensten verarbeitet werden, die ITAR-konforme Zugriffskontrollen nicht erfüllen.
• Healthcare HIPAA: Geschützte Gesundheitsinformationen erfordern Business Associate Agreements mit Auftragsverarbeitern. Die meisten Mehrzweck-LLM-APIs bieten keine HIPAA-BAAs an; spezialisierte Angebote existieren, aber zu Premium-Preisen.
• Finanzdienstleistungen (DORA, BaFin, FFIEC): Drittparteien-Risikomanagement für KI-Anbieter wird zunehmend strikt. Die Default-Option für regulierte Workloads bewegt sich zurück Richtung In-Tenant- oder On-Premise-Deployment.

Datensouveränitäts-Anforderungen nach Jurisdiktion

Souveränitäts-Anforderungen unterscheiden sich im Detail je Jurisdiktion, konvergieren aber auf drei Eigenschaften: wo Daten gespeichert werden, wer auf sie zugreifen kann und welches Rechtsregime gilt.

• EU (DSGVO, Schrems II): Verarbeitung im EWR bevorzugt; Verarbeitung außerhalb des EWR erfordert Angemessenheitsbeschluss oder Standardvertragsklauseln mit ergänzenden Maßnahmen. Die wiederkehrende Frage ist die Exposure gegenüber dem US Cloud Act.
• Deutschland (BSI C5, IT-Sicherheitsgesetz 2.0): Verarbeitung innerhalb Deutschlands für KRITIS-Workloads bevorzugt; BSI-zertifizierte Cloud-Dienste akzeptabel.
• UK (UK GDPR, NIS Regulations): Angemessenheit mit der EU intakt; internationale Übermittlungen erfordern äquivalente Schutzmaßnahmen.
• DACH (Schweiz, Österreich, Deutschland-Finanz): Per-Kanton- oder Per-Bundesland-Regeln können strenger sein als das nationale Recht. Vor Ort verifizieren, bevor man nationale Regeln annimmt.

Was Air-Gap für LLM-Deployments bedeutet

Air-Gap ist die stärkste Souveränitäts-Posture und die am häufigsten missverstandene. Drei Komponenten müssen air-gapped sein, damit der Begriff zutreffend ist.

• Modellgewichte: einmal auf einem Host mit erlaubtem Egress heruntergeladen, über kontrollierten Kanal in die air-gapped Umgebung übertragen. Provenienz und Integrität (Checksumme gegen die des Veröffentlichers verifiziert) gewahrt.
• Telemetrie: keine ausgehende Telemetrie aus dem Deployment. Die meisten Enterprise-Inference-Server starten mit Default-Telemetrie aktiv; das muss explizit deaktiviert und verifiziert werden.
• Updates: keine automatischen Updates. Modell- und Software-Updates folgen demselben Muster über kontrollierte Kanäle wie initiale Gewichte. Der Update-Review-Prozess wird Teil der operativen Disziplin.

Air-Gap mit aktiver Telemetrie ist kein Air-Gap. Air-Gap mit automatischen Update-Kanälen ist kein Air-Gap. Betreiber, die bei Netz-Isolation aufhören, ohne die anderen beiden Komponenten zu adressieren, haben einen Isolations-Perimeter, keinen Air-Gap.

Hardware-Ökonomie 2026

Self-Hosting von LLMs ist für viele regulierte Workloads ökonomisch tragfähig geworden. Drei Referenzpunkte basierend auf öffentlich verfügbarer 2026er-Hardware-Bepreisung:

• 7B–13B-Parameter-Modelle (Llama, Mistral, Qwen in dieser Größenklasse): Single-GPU-Server (RTX 4090 oder partielle H100-Allokation) bewältigen typische Enterprise-Inference-Lasten. Investitionskosten im niedrigen fünfstelligen USD-Bereich; läuft innerhalb der Standard-Rechenzentrumsleistung und -kühlung.
• 30B–70B-Parameter-Modelle (Llama-70B, Mixtral, Qwen-72B): Multi-GPU-Server erforderlich. Investitionskosten im mittleren bis hohen fünfstelligen USD-Bereich. Performance vergleichbar mit Mid-Tier-Cloud-APIs bei deutlich höherer Latenz-Obergrenze, aber vorhersehbaren Kosten.
• 100B+-Parameter-Modelle: erfordern Acht-GPU-Server (DGX-Klasse) oder verteilte Inferenz. Investitionskosten im niedrigen bis mittleren sechsstelligen USD-Bereich. Frontier-Modell-Parität ist nicht erreichbar; die meisten regulierten Deployments nutzen die 70B-Klasse und akzeptieren die Fähigkeitslücke.

Der Break-Even gegenüber Cloud-APIs hängt vom Inferenz-Volumen ab. Für Workloads über etwa 10 Mio. Tokens pro Tag wird Self-Hosting in der 13B-Klasse innerhalb von 18 Monaten günstiger als Cloud-APIs. Unterhalb dieser Schwelle bleiben Cloud-APIs günstiger, sofern nicht Souveränitäts-Anforderungen die Entscheidung erzwingen.

Betriebsmuster: Ollama + vLLM + Observability

Ein dreischichtiger Stack deckt die meisten Regulated-Deployment-Anforderungen ab:

• Ollama für Entwicklung und kleine Deployments. Einfaches Modell-Management, leicht zu deployen und air-gapped zu betreiben — passend für den Long Tail kleinvolumiger Workloads, bei denen Einfachheit wichtiger ist als Performance.
• vLLM für Produktiv-Inferenz mit hohem Durchsatz. Continuous Batching, PagedAttention, OpenAI-kompatible API. Wird zur richtigen Wahl, sobald der Durchsatz das übersteigt, was Ollama komfortabel bedient.
• Observability-Schicht: Pro-Inferenz-Logging (Input-Hash, Output, Modellversion, Latenz), Trace-ID-Propagation aus vorgelagerten Anwendungen, Metrik-Export (Prometheus oder Äquivalent). Das ist die KI-VO-Artikel-12-Pflicht in operativer Form.

Audit- und Zertifizierungs-Posture

Selbst gehostete KI-Deployments in regulierten Umgebungen passen sich typischerweise in bestehende Zertifizierungsbereiche ein, statt neue Zertifizierungen zu erfordern.

• ISO 27001: Das LLM-Deployment wird Teil des ISMS-Scopes. Annex-A-Kontrollen gelten (Logging, Zugriffskontrolle, Lieferantenbeziehungen, falls ein Drittmodell verwendet wird).
• SOC 2 Type II: Die Trust-Service-Kriterien gelten für das LLM-Deployment wie für jedes andere Informationssystem. Logging- und Monitoring-Kontrollen sind der hebelstärkste Bereich.
• HITRUST: Für Healthcare-Deployments mappen die HITRUST-CSF-Referenzen auf das KI-System.
• ISO 42001: KI-spezifisches Managementsystem. In den meisten Jurisdiktionen optional, aber zunehmend von Beschaffungsteams erwartet.

Kostenvergleich: Sovereign Cloud vs. Self-Hosting

Für Organisationen mit Souveränitäts-Anforderungen ist der Vergleich zwischen souveränitätskonformer Cloud (typischerweise zum 2- bis 3-fachen Preis von Standard-Cloud) und Self-Hosting (Investitionsausgaben plus Betriebskosten).

Bei niedrigem Volumen (unter 1 Mio. Tokens pro Tag) gewinnt Sovereign Cloud beim Total Cost of Ownership inklusive operativem Aufwand. Bei mittlerem Volumen (1–10 Mio. Tokens pro Tag) ist der Vergleich workload-abhängig und hängt stark von der Toleranz gegenüber operativem Overhead ab. Bei hohem Volumen (über 10 Mio. Tokens pro Tag) gewinnt Self-Hosting verlässlich innerhalb von 18 Monaten.

Der operative Overhead ist die Variable, die die meisten Betreiber unterschätzen. Self-Hosted-LLM-Operationen erfordern GPU-Kapazitätsplanung, Inferenz-Performance-Tuning, Modell-Upgrade-Testing und Bereitschaftsdienst für Inferenz-Latenz-Vorfälle. Die Investitionskosten sind sichtbar; die Betriebskosten sind es nicht.