Eine ehrliche Bestandsaufnahme nach vielen Kundengesprächen – und ein Plädoyer für Pragmatismus.

---

In den letzten Monaten höre ich diesen Satz immer öfter:

„Wir können kein ChatGPT, kein Claude, kein Copilot nutzen. DSGVO. Wir müssen das selbst hosten.“

Und dann beginnt das große Projekt: GPU-Server bei einem deutschen Anbieter mieten, DeepSeek oder Llama lokal installieren, vLLM konfigurieren, Tooling drumherum bauen, Monitoring aufsetzen, DevOps-Kapazität reservieren. Budget: fünfstellig pro Monat. Zeitrahmen: zwei bis drei Monate Setup. Ergebnis: ein Modell, das gegen Claude Opus oder GPT-5 spürbar abfällt, mit einem Tool-Ökosystem, das man sich größtenteils selbst zusammenbasteln muss.

Meine These nach mehreren solcher Diskussionen: In etwa 90 % der Fälle ist das komplett unnötig.

Die Zahl ist meine Schätzung, kein Studienergebnis. Aber sie kommt aus echten Projekten, und ich erkläre gerne, warum ich sie für realistisch halte.

Worum es bei DSGVO eigentlich geht

DSGVO regelt die Verarbeitung personenbezogener Daten. Also: Namen, E-Mail-Adressen, IP-Adressen, alles, was auf eine identifizierbare Person zurückgeführt werden kann.

Was machen wir in der klassischen Projektentwicklung den ganzen Tag?

• Wir schreiben React-Komponenten
• Wir bauen API-Endpoints
• Wir refaktorieren Legacy-Code
• Wir debuggen Tests mit user_42 und lorem@example.com
• Wir generieren Boilerplate, Migrations, Tailwind-Klassen
• Wir diskutieren Architektur-Entscheidungen

In welchem dieser Tasks verarbeiten wir personenbezogene Daten? In keinem.

Wir entwickeln den Code, der später – in Produktion, beim Kunden, in einem ganz anderen Setup – mit personenbezogenen Daten umgehen wird. Aber während der Entwicklung selbst bewegen sich Claude, Copilot oder ChatGPT in einem Raum aus TypeScript, SQL-Schemata und Test-Fixtures.

Und genau hier liegt der erste Denkfehler vieler „Wir-müssen-selbst-hosten“-Diskussionen: Sie verwechseln Code-Entwicklung mit Daten-Verarbeitung.

„Aber unser Code ist doch geheim!“

Der zweite Reflex. Auch verständlich. Aber bei ehrlicher Betrachtung:

• 80 % unseres Codes ist Boilerplate, Framework-Konventionen, etablierte Patterns. Nichts davon ist geheim. Das steht in tausend GitHub-Repos.
• 15 % ist Business-Logik, die für den Kontext des Unternehmens relevant ist, aber kaum jemand außerhalb der Firma überhaupt verstehen würde.
• 5 % sind tatsächliche Differenzierungsmerkmale – Algorithmen, Geschäftsregeln, Architekturen, die Wert haben.

Selbst von diesen 5 % gilt: Wer ist hier eigentlich die Bedrohung? Anthropic, ein Unternehmen mit klaren vertraglichen Verpflichtungen, ISO 27001, SOC 2 und einem Geschäftsmodell, das genau auf Vertrauen aufbaut? Oder die viel wahrscheinlicheren Lecks – durchgereichte Repos an Ex-Mitarbeiter, schlecht geschützte CI-Pipelines, Laptops in Cafés?

Die Risikodiskussion wird selten ehrlich geführt.

Was reicht wirklich?

Die meisten Kunden brauchen drei Zusagen:

1. Die Daten werden nicht zum Training verwendet.
2. Es gibt einen Auftragsverarbeitungsvertrag.
3. Es ist nachvollziehbar, wer wann was tut.

Genau das bekommst du mit einer normalen kommerziellen Claude-Lizenz (Team oder Enterprise). Anthropic hat in den Commercial Terms vertraglich zugesichert, keine Kundendaten für Modelltraining zu verwenden. Der DPA ist automatisch in den Enterprise-Bedingungen enthalten. Audit-Logs gibt es. Zertifizierungen ebenfalls.

Kosten: rund 100 € pro Entwickler und Monat im Team-Tarif.

Vergleich: Eigene GPU-Infrastruktur für ein vergleichbar gutes Modell beginnt bei 5.000 € im Monat – ohne den DevOps-Aufwand, ohne Setup-Zeit, ohne das schwächere Tool-Ökosystem.

Wann Self-Hosting tatsächlich Sinn macht

Es gibt diese 10 %. Sie sind real, und für sie ist Self-Hosting absolut richtig:

• Echte Air-Gap-Anforderungen – Defense, Behörden mit Sicherheitseinstufung, Forschung an klassifizierten Themen.
• Stark regulierte Branchen mit harten Auflagen – manche Bereiche im Banken-, Versicherungs- und Gesundheitswesen, wo es nicht um „wir hätten gern“ geht, sondern um konkrete aufsichtsrechtliche Vorgaben.
• Verarbeitung sehr großer Mengen tatsächlich personenbezogener Daten durch die KI – nicht das Schreiben des Codes, sondern produktiver Einsatz auf echten Bestandsdaten.
• Vertragliche Kundenanforderungen, die explizit On-Premise oder EU-only fordern und nicht verhandelbar sind.

In all diesen Fällen ist ein eigenes Setup gerechtfertigt. In allen anderen Fällen ist es eine teure Antwort auf eine Frage, die nie gestellt wurde.

Der Mittelweg, der oft vergessen wird

Zwischen „Claude Pro auf dem Privatlaptop“ und „eigene GPU-Farm“ gibt es eine sinnvolle Mitte: Claude über AWS Bedrock in Frankfurt oder Vertex AI in Belgien.

Damit hast du:

• Inferenz physisch in der EU
• Vollständiger Funktionsumfang von Claude Opus und Sonnet
• Etablierte DPAs vom Hyperscaler und von Anthropic
• Audit-Trails über CloudWatch oder Cloud Logging
• Zero Data Retention auf Wunsch

Kosten: rund 2.500–4.500 € pro Monat für ein zehnköpfiges Team. Setup: zwei Wochen. Frontier-Qualität. Keine eigene Hardware.

Wenn ein Kunde wirklich auf EU-Datenresidenz besteht, ist das die ehrliche Antwort. Nicht „wir bauen ein eigenes Rechenzentrum“.

Was ich Kunden meistens sage

„Wir entwickeln Code mit Hilfe von Claude. Anthropic hat vertraglich zugesichert, dass unsere Daten nicht für Training verwendet werden. Wir haben einen Auftragsverarbeitungsvertrag. In der Entwicklung verarbeiten wir keine personenbezogenen Daten, sondern wir bauen die Anwendung, die das später tun wird. Wenn das für ein spezifisches Projekt nicht ausreicht, wechseln wir auf das Bedrock-Setup in Frankfurt.“

Damit sind 90 % der Diskussionen vorbei. Und für die anderen 10 % gibt es saubere, definierbare Eskalationspfade.

Die unbequeme Wahrheit

Self-Hosting-Projekte entstehen häufig nicht aus echter Compliance-Notwendigkeit, sondern aus einer Mischung aus diffusem Unbehagen, Vorsichtsreflexen, IT-Politik und manchmal auch dem Wunsch, ein cooles Infrastruktur-Projekt zu machen. Das ist menschlich verständlich, aber es kostet Geld und Geschwindigkeit – und am Ende oft auch Qualität, weil die Open-Source-Modelle bei aller Stärke immer noch hinter den Frontier-Modellen liegen.

Mein Vorschlag: Bevor das nächste „wir müssen selbst hosten“-Projekt startet, einmal ehrlich fragen:

• Was genau ist das konkrete Compliance-Risiko?
• Werden in der Code-Entwicklung tatsächlich personenbezogene Daten verarbeitet?
• Reicht ein kommerzieller Vertrag mit klaren Zusagen?
• Was würde der Datenschutzbeauftragte sagen, wenn man ihm die Optionen ehrlich vorlegt?

Meistens stellt sich heraus: Eine normale Claude-Team-Lizenz mit aktivierter Training-Opt-Out-Klausel ist die richtige Antwort. Schnell, günstig, qualitativ stark, juristisch sauber.

Manchmal braucht es Bedrock EU. Selten braucht es Self-Hosting.

Und in keinem dieser Fälle macht es Sinn, mit der teuersten und aufwendigsten Lösung anzufangen, nur weil sie sich am sichersten anfühlt.

---

PS: Wer den Bedrock-Weg konkret durchrechnen will, findet die Details in meinem Konzeptpapier „DSGVO-konforme AI-Coding-Umgebung“. Drin steht eine Architektur für zwei Entwickler-Teams mit fünf bis fünfzehn Entwicklern, Modell-Mix aus Sonnet und Opus, realistische Token-Schätzungen, ein Umsetzungsplan über vier Wochen und ein ehrlicher Vergleich gegen ein Self-Hosting-Szenario mit DeepSeek auf eigener GPU-Infrastruktur. Die Eckdaten: rund 2.700 Euro pro Monat für zehn Entwickler, Frontier-Qualität, EU-Datenresidenz in Frankfurt oder Belgien, DPA inklusive. Hier zum Download: https://mwolff.org/whitepapers/Konzeptpapier_AI-Coding-Umgebung.pdf