Ein Procurement-Komitee entscheidet im März, dass Cloud nicht infrage kommt. Im April rechnet der Engineering Lead zum ersten Mal: acht H100-GPUs, 250.000 bis 420.000 Euro, plus Strom, Kühlung, Betrieb. Im Mai ruft die Rechtsabteilung an und fragt, was ein VPC ist.
Die Frage „On-Premise oder Cloud" wird oft gestellt, als gäbe es nur zwei Optionen. Gibt es nicht. Welche Daten fließen wohin? Wer sieht sie? Was verlangt der Regulator tatsächlich? Das sind die Fragen, die zählen.
Die vier Stufen
Zwischen öffentlichem SaaS und vollständig air-gapped liegen zwei Zwischenstufen. Sie tauchen in Beschaffungsdiskussionen selten auf, obwohl sie oft die praktikablere Lösung sind.
Stufe 1: Public SaaS. Claude.ai Consumer, ChatGPT Free/Plus, Cursor ohne Enterprise-Vertrag. Bei Public-SaaS muss pro Anbieter und Tarif geprüft werden, ob Eingaben für Training genutzt werden, wie lange Daten gespeichert werden, welche Telemetrie anfällt und welche Datenresidenz zugesichert wird. Enterprise- und Team-Produkte unterscheiden sich hier teils erheblich von Consumer-Tarifen. Für regulierte Codebasen ist diese Stufe meist nur nach enger Prüfung geeignet.
Stufe 2: Zero-Data-Retention-SaaS. Anthropic Enterprise mit ZDR-Modus, OpenAI Enterprise mit vergleichbarer Konfiguration. Prompts und Antworten werden nicht dauerhaft gespeichert und nicht für Training verwendet, soweit der jeweilige ZDR-Modus korrekt aktiviert ist. Vertraglich zugesichert und durch Anbieter-Kontrollen technisch abgesichert. Regulatorisch oft ausreichend. Die Nuance: Anthropics ZDR gilt auf deren eigener Plattform. Wer über Bedrock routet, verhandelt mit AWS, nicht mit Anthropic.
Stufe 3: VPC-isoliertes Hyperscaler-Deployment. Claude Code über AWS Bedrock mit VPC-Endpunkten und PrivateLink, Azure OpenAI, Google Vertex AI. Der Datenverkehr bleibt innerhalb der Sicherheitsgrenzen des Cloud-Anbieters. Bei Bedrock konkret: Kundendaten bleiben in der AWS-Infrastruktur, werden nicht an Anthropic weitergegeben und nicht für Training verwendet. Dazu IAM, CloudWatch-Logging, CloudTrail und die Möglichkeit, C5-attestierte Hyperscaler-Services in die Zielarchitektur einzubinden. Für viele DACH-Engineering-Teams dürfte das der praktikable Startpunkt sein, sofern Datenklassifizierung, Drittparteienprüfung und Logging sauber umgesetzt sind.
Stufe 4: Echtes On-Premise oder Air-Gapped. Open-Weight-Modelle aus Familien wie Qwen, DeepSeek, GLM oder MiniMax auf eigener GPU-Infrastruktur, keine Internetverbindung. Wer ein On-Premise LLM selbst hosten will, braucht nicht nur Hardware, sondern auch MLOps-Kompetenz für Modellbetrieb, Updates und Monitoring. Notwendig für klassifizierte Umgebungen, einige Pharma-R&D-Kontexte, kritische Infrastrukturen. Selten notwendig, wenn das Team ehrlich über seine tatsächlichen regulatorischen Anforderungen nachdenkt.
Die meisten DACH-Unternehmen, die „On-Prem" verlangen, meinen Stufe 2 oder 3. Diese Unterscheidung früh zu klären, vermeidet teure Fehlallokationen. Der Leitfaden für Engineering-Leads hilft, die richtige Stufe systematisch zu identifizieren.
Orientierung: Welche Stufe passt?
| Situation | Eher geeignet |
|---|---|
| Keine Kundendaten im Code, normale Repos | Stufe 2 oder 3 |
| Strenge Datenresidenz, Audit-Anforderungen, zentrales IAM | Stufe 3 |
| Klassifizierte Umgebungen, Defense, isolierte R&D | Stufe 4 |
| Experimentelle Nutzung, keine sensiblen Daten | Stufe 1 oder 2 |
| Agent darf Builds ausführen, aber keine Secrets lesen | Stufe 3 mit stark begrenzten Worker-Rechten |
Die Stufe beantwortet nur die Frage, wo Inferenz und Datenfluss stattfinden. Sie beantwortet nicht, welche Rechte der Agent im Repository, Terminal, CI-System oder Cloud-Account erhält. Für Coding-Agents sind Least Privilege, getrennte Service Accounts, Secret-Scoping, Audit Logs und Approval Gates für destruktive Aktionen mindestens so wichtig wie die Hosting-Frage.
Was die Aufsicht wirklich verlangt
Die BaFin hat am 18. Dezember 2025 eine Orientierungshilfe zu IKT-Risiken beim Einsatz von KI veröffentlicht. Die Aufsicht verlangt kein Air-Gap. Sie verlangt Kontrolle über den Datenfluss, Dokumentation, Monitoring, robustes Drittparteienrisikomanagement. Für Finanzdienstleister mit konkreten MaRisk- und DORA-Anforderungen bietet die detaillierte BaFin/MaRisk-Analyse einen tieferen Einstieg.
Cloud-basierte KI-Coding-Werkzeuge dürften in den meisten Konstellationen als IKT-Drittparteienleistung im Sinne von DORA Art. 28 einzuordnen sein. Ob zusätzlich eine Auslagerung nach MaRisk AT 9 vorliegt, hängt von Funktion, Kritikalität und Einbindung in Geschäftsprozesse ab. Das sind juristische Einschätzungen, keine pauschalen Rechtsfeststellungen.
Der KPMG Cloud-Monitor 2025 Financial Services zeigt: 95 Prozent der befragten Finanzunternehmen nutzen bereits LLMs. Die BaFin hat das zur Kenntnis genommen. Die Fokusrisiken 2026 adressieren Konzentrationsrisiko bei wenigen großen Cloud-Anbietern, nicht Cloud an sich.
In vielen internen Coding-Assistant-Konstellationen wird eher die Nutzung eines GPAI-basierten Systems relevant sein als eine eigene Hochrisiko-Einstufung. Das ändert sich, wenn der Agent in HR-Bewertung, sicherheitskritische Produktentwicklung oder regulierte Entscheidungsprozesse eingebunden wird. Ein interner Coding-Assistent für das Platform-Team hat ein anderes Risikoprofil als ein KI-System für Kreditentscheidungen.
Allerdings gibt es zwei Sonderfälle: Wenn der Coding-Agent Telemetrie zu Performance-Bewertung von Entwicklern liefert, greift Anhang III Punkt 4. Und Coding-Agents in regulierter sicherheitskritischer Software erben die Hochrisiko-Klassifikation des Endprodukts. Nach dem ursprünglichen Zeitplan greifen wesentliche Hochrisiko-Pflichten ab August 2026. Wegen der laufenden Digital-Omnibus-Debatte sollten Unternehmen den finalen Anwendungszeitpunkt vor Projektstart prüfen. Das Europäische Parlament hat im April 2026 eine Verschiebung auf Dezember 2027 unterstützt, der Trilogue läuft noch.
Das BSI hat am 27. April 2026 mit C3A einen eigenständigen Souveränitätskatalog komplementär zu C5 publiziert. C5:2026 liefert den aktuellen Kriterienkatalog, C3A den zusätzlichen Souveränitätsrahmen. Ob ein konkreter Hyperscaler-Service darunter attestiert ist, muss im Einzelfall geprüft werden. Für private DACH-Unternehmen ohne Staats-Kontext ändert C3A operativ wenig. Für Behörden, Defence-Auftragnehmer und KRITIS-Betreiber mit hohen Souveränitätsanforderungen wird C3A hingegen zur Pflichtlektüre.
Sprechen Sie mit Ihrer Rechtsabteilung, bevor Sie mit dem Procurement sprechen. Viele „das geht nicht"-Entscheidungen basieren auf Vermutungen, nicht auf Gesetzestexten. In der Praxis zeigt sich häufig: Ein pauschales „Cloud geht bei uns nicht" hält einer Prüfung der tatsächlichen regulatorischen Anforderungen selten stand.
Warum das Modell nicht mehr die ganze Antwort ist
Die Modell-Lücke ist bei Coding-Benchmarks deutlich kleiner geworden. Auf SWE-bench Verified und verwandten Benchmarks liegen starke Open-Weight-Modelle inzwischen in Reichweite proprietärer Frontier-Modelle. Stand Abruf Anfang Mai 2026 liegen führende proprietäre Modelle auf SWE-bench Verified im oberen 80er-Bereich; mehrere starke Open-Weight-Modelle erreichen Werte um 80 Prozent. Die exakten Werte ändern sich laufend mit Harness, Filter und Modellversion. Der genaue Spitzenwert ist weniger wichtig als die Größenordnung: Die Lücke zwischen Open-Weight- und Frontier-Modellen ist bei Coding-Benchmarks deutlich kleiner als 2024.
Das Modell ist nicht mehr der einzige Engpass. Das Scaffold – die Orchestrierungsschicht, die Kontext, Tools und Planungslogik zusammenhält – entscheidet mit.
Augment Code hat auf SWE-bench Pro mit demselben Claude-Opus-4.5-Modell vier verschiedene Agent-Harnesses getestet (Zahlen aus Augments eigenem Benchmark-Report): SWE-Agent 45,9 Prozent, Claude Code 49,8 Prozent, Cursor 50,2 Prozent, Auggie 51,8 Prozent. Sechs Prozentpunkte Unterschied, identische Gewichte. Endor Labs misst auf der Agent Security League noch größere Spannweiten: Cursor mit GPT-5.5 erreicht 87,2 Prozent Functional Correctness und 23,5 Prozent Security Correctness. Codex mit GPT-5.5 liegt bei 61,5 Prozent Functional Correctness. Derselbe Modell-Snapshot, derselbe Tag, 25,7 Punkte Unterschied bei Functional Correctness.
Claude Code, Codex, Cursor und OpenHands sind keine Chat-Interfaces. Sie sind Orchestrierungsschichten mit Tool-Calling, Kontext-Management, Planungs-Loops und Sub-Agents. Ein selbst gehostetes GLM-5 auf eigenen GPUs ohne diese Schicht ist kein On-Prem-Coding-Agent. Es ist ein Chatbot mit Coding-Fokus.
Warum echtes On-Prem trotzdem teuer bleibt
Die Hardware-Realität: Acht H100 kosten in der PCIe-Variante 25.000 bis 35.000 Euro pro Karte. Ein 8×H100-System liegt zwischen 250.000 und 420.000 Euro, abhängig von PCIe versus SXM, neu versus generalüberholt, Integrator versus Eigenbau. GMI Cloud veranschlagt operativen Betriebsaufwand von 30 bis 40 Prozent der Hardwarekosten jährlich.
Im ersten Jahr sieht die Rechnung so aus (100 Entwickler, produktionstauglich):
- Anschaffung 8×H100-System: 250.000–420.000 €
- Strom und Kühlung: 40.000–60.000 €
- Rack-Fläche oder Housing: 20.000–40.000 €
- MLOps/Infra-Personal (0,5–1 FTE): 80.000–120.000 €
- Wartung, Redundanz, Security Review: 30.000–50.000 €
- Modellbetrieb, Monitoring, Updates: 20.000–40.000 €
Gesamtbelastung im ersten Jahr: 440.000–730.000 €. Ab Jahr zwei, bei fünfjähriger Abschreibung der Hardware, liegt der jährliche Aufwand eher bei 240.000–400.000 Euro. Der Cash-Out im ersten Jahr ist der relevante Entscheidungspunkt.
Gleichzeitig läuft Claude Code über Bedrock mit VPC-Isolation ab dem ersten Tag, mit vorhersagbaren Tokenkosten und ohne Kapitalbindung.
On-Premise ist kein technisches Problem mehr. Es ist ein Kosten-Nutzen-Problem. Die Nutzenseite muss die Kostenseite rechtfertigen. Das Gefühl „die Daten bleiben im Haus" reicht dafür nicht.
Was geht, was nicht, was kommt
Claude Code kann über AWS Bedrock mit VPC-Endpunkten laufen. Die AWS Solutions Library dokumentiert Enterprise-Deployment-Patterns mit OIDC-Federation zu Okta, Entra ID, Auth0 oder Cognito, CloudWatch-Metriken und CloudTrail-Logs.
GitHub Copilot CLI unterstützt seit dem 7. April 2026 BYOK und lokale Modelle über OpenAI-kompatible Endpunkte, Azure OpenAI oder lokal laufende Modelle wie Ollama. Mit lokaler Modellkonfiguration und Offline-Modus (z.B. COPILOT_OFFLINE=true) kann die CLI für stark abgeschottete Umgebungen betrieben werden; die genaue Netzwerkkonfiguration sollte technisch verifiziert werden. Wichtig: CLI ist nicht gleich IDE-Integration. Die IDE-Authentifizierung läuft weiter über github.com.
Cursor bietet seit dem 25. März 2026 Self-Hosted Cloud Agents. Die Architektur: Cursors Agent-Harness übernimmt Inferenz und Planning, sendet dann Tool Calls an Worker zur Ausführung auf Kundeninfrastruktur. Die Ergebnisse fließen zurück zu Cursor für die nächste Inferenz-Runde. Code und Tool-Execution bleiben lokal. Welche Control-Plane- und Modellaufrufe weiterhin über Cursor laufen, muss vertraglich und technisch geprüft werden.
Was nicht geht: Viele kleinere Anbieter werben mit „On-Prem", liefern aber de facto ein VPC-Deployment mit Control-Plane beim Anbieter. Keine Täuschung, aber auch kein echtes Air-Gap. Und die besten Agenten-Harnesses sind auf die Trainingsdaten und Tool-Profile bestimmter Frontier-Modelle getuned. OpenHands mit GLM-5 funktioniert, aber nicht mit derselben Zuverlässigkeit wie Claude Code mit Opus.
Was kommt: Der Cloud and AI Development Act (CAIDA), ein EU-Gesetzesvorschlag zu Cloud-Infrastruktur und KI-Entwicklung, ist im Arbeitsprogramm für 2026 vorgesehen, möglicherweise mit Fokus auf Cloud-Souveränität und EU-Recheninfrastruktur; der genaue Umfang wird erst mit dem Kommissionsentwurf klar. Open-Weight-Modelle holen schneller auf als 2024 erwartet. Wenn der Trend anhält, dürften neue Generationen aus den GLM-, DeepSeek-, Qwen- und Kimi-Familien die Lücke weiter verkleinern. Wer heute für 2027 plant: In zwei Jahren ist „Frontier oder selbst gehostet" weniger eine Qualitätsfrage. Eher Kosten und Kontrolle.
Die richtigen Fragen
Nicht „On-Premise oder nicht". Sondern: Welche Daten verlassen welche Kontrollgrenze? Welcher Anbieter betreibt welche Komponente? Welches Budget rechtfertigt der Anwendungsfall?
Die pragmatische Antwort liegt 2026 für die wenigsten Teams im Air-Gap. Eher in einem VPC-isolierten Hyperscaler-Deployment mit dokumentierter Governance. Echtes Air-Gap ist ein spezialisiertes Werkzeug, kein Standard. Wer es wählt, sollte es aus einem klaren regulatorischen Grund tun. Nicht aus einem diffusen Unbehagen.
Wenn diese Architekturentscheidung strategisch auf Ihr Unternehmen wirkt, lohnt sich ein genauerer Blick. Die Gesamtübersicht zu Coding Agents führt durch die Abwägungen.
Weiterführende Quellen
- BaFin: Orientierungshilfe zu IKT-Risiken beim Einsatz von KI (18. Dezember 2025) · Fokusrisiken 2026
- BSI: C3A Souveränitätskatalog · C5:2026
- EU: Digital Omnibus on AI · CAIDA Legislative Train
- KPMG: Cloud-Monitor 2025 Financial Services
- AWS: Guidance for Claude Code with Amazon Bedrock · Bedrock Security and Privacy
- GitHub: Copilot CLI BYOK und Offline-Mode
- Cursor: Self-Hosted Cloud Agents
- Augment Code: Auggie tops SWE-Bench Pro
- Endor Labs: GPT-5.5 in Agent Security League
- GMI Cloud: H100 GPU Cost Guide 2026
