Ein Lagebericht aus der Projektpraxis. Für Entscheider im DACH-Mittelstand, die KI einsetzen wollen, aber nicht riskieren möchten, in zwei Jahren die nächste Schrems-Debatte auf dem Schreibtisch zu haben.

📌 Die Ausgangslage

In vielen Mittelstandsunternehmen – besonders in Banken, Versicherungen, im Gesundheitswesen und der öffentlichen Verwaltung – wird KI bis heute nicht oder nur sehr zögerlich eingesetzt. Nicht, weil die Technologie nicht verfügbar wäre. Nicht, weil der Business-Nutzen unklar wäre. Sondern, weil niemand im Haus eine klare Antwort darauf geben kann, was datenschutzrechtlich überhaupt erlaubt ist.

Die kurze Antwort: Es geht heute deutlich mehr, als viele denken. Man muss nur wissen, wo man hinschauen muss – und welche Fragen man in welcher Reihenfolge beantwortet. Dieser Artikel ist ein Lagebericht. Welche Modelle und Anbieter sind 2026 tatsächlich DSGVO-konform einsetzbar? Wo liegen die Fallstricke? Und wie gehen Unternehmen in der Praxis damit um? Ohne Marketing-Claim, ohne Panik-Ton, ohne verkürzte Pauschalaussagen.

📌 Was sich 2025 und 2026 rechtlich verändert hat

Wer sich zuletzt 2023 oder 2024 intensiv mit dem Thema beschäftigt hat, arbeitet mit einem veralteten Bild. In den letzten 18 Monaten haben sich drei Dinge bewegt, die für jede Architekturentscheidung relevant sind.

Erstens: Der EU AI Act ist schrittweise in Kraft. Seit dem 2. Februar 2025 gelten die Verbote nach Art. 5 und die KI-Kompetenzpflicht nach Art. 4 – das betrifft jedes Unternehmen, nicht nur die Hochrisiko-Anwender. Seit dem 2. August 2025 sind die Pflichten für General-Purpose-AI-Modelle (Art. 53) anwendbar, flankiert durch den am 10. Juli 2025 veröffentlichten GPAI Code of Practice. Die Durchsetzung für die großen Modellanbieter beginnt am 2. August 2026.

Der Digital Omnibus on AI der Kommission vom 19. November 2025 hat dann die Hochrisiko-Fristen nach hinten verschoben: Anhang III auf den 2. Dezember 2027, Anhang I auf den 2. August 2028. Wichtig: Der Omnibus ist zum Zeitpunkt dieses Artikels noch nicht final durch. Formal gilt also weiterhin der 2. August 2026 als Hochrisiko-Frist. Wer auf die Verschiebung spekuliert, wettet – und wetten ist in regulierten Branchen keine belastbare Strategie. Die inhaltlichen Anforderungen ändern sich durch den Omnibus ohnehin nicht, nur die Fristen.

Zweitens: Die deutschen Aufsichtsbehörden haben nachgezogen. Die Datenschutzkonferenz – der Zusammenschluss aller Landes- und Bundesdatenschutzbeauftragten – hat in drei Tranchen orientiert: im Mai 2024 zur grundsätzlichen Auswahl und Nutzung von KI, im Juni 2025 zu den technischen und organisatorischen Maßnahmen entlang der sieben Gewährleistungsziele, und im Oktober 2025 erstmals spezifisch zu Retrieval-Augmented-Generation-Architekturen. Diese drei Dokumente sind inzwischen die praktische Arbeitsgrundlage für jeden Datenschutzbeauftragten im DACH-Raum. Wer sie nicht kennt, verhandelt mit dem eigenen DSB ohne gemeinsame Sprache.

Die wichtigsten Erkenntnisse daraus: Selbst pseudonymisierte Eingaben in ein LLM gelten in aller Regel als personenbezogen. Eine Datenschutz-Folgenabschätzung ist beim LLM-Einsatz fast immer einschlägig. RAG-Architekturen bieten strukturell Vorteile für Datenminimierung und Betroffenenrechte – lösen aber nicht das Problem eines rechtswidrig trainierten Basismodells, wenn eines zum Einsatz kommt.

Drittens: Die BaFin hat sich positioniert. Mit der Orientierungshilfe zu IKT-Risiken beim Einsatz von KI vom Dezember 2025 liegt für Banken und Versicherer faktisch eine Beweislastumkehr vor – formal nicht verpflichtend, in der Prüfungspraxis aber sehr wohl. Wer davon abweicht, muss ein gleichwertiges Schutzniveau nachweisen. Das ist etwas anderes als ein klassisches Rundschreiben, aber in der Wirkung kaum milder. Parallel dazu wurde der BSI C5 in der Version 2026 veröffentlicht, mit Post-Quanten-Kryptographie, Confidential Computing und erweitertem Supply-Chain-Risk-Management. Für Gesundheitsdienstleister und Finanzinstitute ist eine C5-Typ-2-Testierung inzwischen de facto Marktzutrittsvoraussetzung.

Fazit dieses Rechts-Updates: Die Fristen verschieben sich an einigen Stellen. Die architektonischen Entscheidungen, die heute getroffen werden, bestimmen aber die nächsten fünf Jahre. Und sie müssen vor den sich verschärfenden statt lockernden Aufsichtspraktiken bestehen.

📌 Die CLOUD-Act-Debatte: Vom Totschlagargument zum differenzierten Bild

In beinahe jeder Diskussion zu KI-Anbietern fällt an irgendeinem Punkt der Satz: „Aber die Server stehen doch in Frankfurt." Oder umgekehrt: „Das geht gar nicht, wegen des CLOUD Act." Beide Aussagen greifen zu kurz. Die juristische Lage ist komplexer – und die Argumentation geht in beide Richtungen.

Die kritische Position, die in der Praxis überwiegt, lautet: Der CLOUD Act von 2018 verpflichtet US-Unternehmen, auf Anfrage US-Behörden Daten auszuhändigen, unabhängig vom Serverstandort. Microsoft, Amazon und Google sind US-Unternehmen, auch ihre deutschen Töchter fallen unter diese Pflicht. Der EuGH hat in Schrems II exakt diese Konstellation – wenn auch technisch auf FISA 702 bezogen – als problematisch markiert. Der Europäische Datenschutzausschuss hat bereits 2019 festgestellt, dass eine reine CLOUD-Act-Anfrage in der Regel keine Rechtsgrundlage nach Art. 48 DSGVO liefert, weil der CLOUD Act kein Rechtshilfeabkommen ist. Und der EU Data Act verpflichtet europäische Cloud-Anbieter in Kapitel VII sogar aktiv, unrechtmäßigen Drittlandzugriff abzuwehren – was einen direkten Kollisionsfall mit dem CLOUD Act produziert.

Die differenziertere Gegenposition lautet: Der CLOUD Act wurde im Schrems-II-Urteil gar nicht behandelt. Das VG Wiesbaden – später aufgehoben – und die Landesregierung Nordrhein-Westfalen haben argumentiert, dass solange Daten im Europäischen Wirtschaftsraum bleiben, zunächst kein Drittlandtransfer vorliegt. Der CLOUD Act gebe den USA zwar das Recht, Herausgabe zu fordern, doch internationales Recht hebelt nicht automatisch nationales Recht aus – im Konfliktfall greifen Kollisionsrecht und, wenn Grundrechte betroffen sind, der ordre public.

Für die Projektpraxis bedeutet das: Der CLOUD Act ist kein automatischer Ausschlussgrund, aber er ist ein dokumentationspflichtiger Risikofaktor. Für Unternehmen außerhalb hochregulierter Branchen ist US-Cloud-Nutzung mit sauberem Transfer Impact Assessment und Standardvertragsklauseln nicht ausgeschlossen. Für Banken, Versicherer, Krankenkassen und Behörden ist er in der Praxis oft ein K.-o.-Kriterium, weil die Risikotoleranz extrem niedrig ist und die Aufsichtspraxis entsprechend strikt. Wer hier in einem Prüfgespräch das Argument „kein Drittlandtransfer nach NRW-Auslegung" vorträgt, bekommt freundliches Nicken und eine nachgeschobene Frage zur konkreten Risikobewertung.

Das ist der Kern der Sache: Die Frage ist nicht „CLOUD Act ja oder nein". Die Frage ist, welches Schutzniveau gefordert ist und welche Dokumentation die eigene Rechtsabteilung und der zuständige Aufseher erwarten.

📌 Was die Aufsichtspraxis 2024 und 2025 gezeigt hat

Rechtsabteilungen orientieren sich nicht primär am Gesetzestext, sondern an dem, was höchstrichterlich oder aufsichtsrechtlich Bestand hatte. Drei Entwicklungen sind für die aktuelle Architektur-Entscheidung besonders relevant.

Im Januar 2023 verhängte die irische Datenschutzkommission gegen Meta ein DSGVO-Bußgeld von 1,2 Milliarden Euro – wegen illegaler Datenübermittlungen in die USA. Die Botschaft für Rechtsabteilungen war eindeutig: Transferverstöße sind keine theoretische Bedrohung, sie kosten Milliarden.

Im Dezember 2024 verhängte die italienische Garante 15 Millionen Euro gegen OpenAI. Die Vorwürfe reichten von einer nicht gemeldeten Datenpanne über fehlende Rechtsgrundlage für das Training mit personenbezogenen Daten bis zu Verstößen gegen Transparenzpflichten und fehlender Altersverifikation. Zusätzlich wurde eine sechsmonatige Informationskampagne in italienischen Medien angeordnet – eine rechtliche Innovation. Besonders relevant ist die parallele Stellungnahme 28/2024 des EDSA: Ein KI-Modell, das zwar mit unrechtmäßig erhobenen Daten trainiert wurde, aber vor Bereitstellung effektiv anonymisiert wird, verletzt die DSGVO nicht. Das öffnet einen juristischen Ausweg, stellt aber hohe Nachweispflichten an die Anonymisierung.

Und dann ist da die Microsoft-365-Geschichte, die lehrreich ist, weil sie zeigt, wie sehr sich Positionen bewegen können. Die DSK hatte 2022 Microsoft 365 noch für nicht datenschutzkonform einsetzbar erklärt – mit einer denkbar knappen Mehrheit von 9:8. Nach drei Jahren, umfangreichen Microsoft-Anpassungen (EU Data Boundary, angepasste Auftragsverarbeitungsverträge, Advanced Data Residency, Customer Lockbox) und intensiven Verhandlungen veröffentlichte der Hessische Beauftragte für Datenschutz und Informationsfreiheit im November 2025 einen Bericht mit dem Kernfazit: Microsoft 365 ist grundsätzlich datenschutzkonform nutzbar, wenn bestimmte Voraussetzungen erfüllt sind. Das war die erste behördliche Kursänderung in dieser Frage seit drei Jahren. Für Copilot bleibt die Lage komplexer – die Verknüpfung mit Bing-Suche erzeugt eine eigene Verantwortlichkeit außerhalb der Auftragsverarbeitung, und eine DSFA ist praktisch immer erforderlich.

Ein weiteres Signal: Die Vergabekammer Baden-Württemberg erklärte im Juli 2022 den Einsatz amerikanischer Cloud-Anbieter in einem konkreten Vergabeverfahren wegen Art. 44 ff. DSGVO für rechtswidrig. Der Beschluss wurde später vom OLG Karlsruhe aus prozessualen Gründen aufgehoben. Die materielle Begründung hat dennoch Gewicht in Diskussionen mit öffentlichen Auftraggebern behalten.

Und – als Negativbeispiel für Kontraste: DeepSeek wurde von der LfD Niedersachsen und mehreren anderen Aufsichtsbehörden als nicht DSGVO-konform bewertet. Speicherung von IP-Adressen, Tastatureingaben und Dokumenten ohne Transparenz, potenzieller Zugriff chinesischer Behörden, fehlender Auftragsverarbeitungsvertrag, kein Angemessenheitsbeschluss EU-China. Für regulierte Branchen ist das aktuell nicht einsetzbar. Ein nützlicher Kontrast, wenn man intern die Unterschiede zwischen Anbietern erklären muss.

❓ Die drei Klassen von Anbietern – und warum die Trennung entscheidend ist

Wer am Markt nach „DSGVO-konformen KI-Anbietern" sucht, findet drei Klassen, die oft in einen Topf geworfen werden. Sie unterscheiden sich fundamental.

🔹 Klasse 1 – Echte EU-Anbieter

Hauptsitz in der EU, Server in der EU, Unternehmen unterliegt ausschließlich EU-Recht. Kein US-Drittlandproblem. Kein CLOUD Act. Keine Schrems-Debatte. Für regulierte Branchen ist das die Kategorie, die am einfachsten durch den Datenschutzbeauftragten und das Auditkomitee geht.

Mistral AI aus Paris ist 2026 der Allrounder der europäischen Szene. Das Unternehmen bietet mit Mistral Large 3, Mistral Small 4 (eine Sparse-MoE-Architektur mit 119 Milliarden Parametern, davon nur rund 6 Milliarden aktiv), Codestral, Voxtral, Magistral und Ministral eine komplette Modellfamilie – von Frontier-Chat über Code und Audio bis Edge. Mistral Small 4 ist unter Apache 2.0 verfügbar, kann also auch selbst gehostet werden. Der Training-Opt-Out ist bei „La Plateforme" und bei den Le-Chat-Pro-/Teams-Produkten standardmäßig gesetzt. Mistral ist Unterzeichner des GPAI Code of Practice. Das Unternehmen unterliegt französischem und EU-Recht; dass für das Modell-Training teilweise auch Azure-GPU-Infrastruktur genutzt wird, ist für die Inferenz-DSGVO-Bewertung irrelevant – trainiert werden Modellgewichte, nicht Kundendaten.

Aleph Alpha aus Heidelberg hat sich Ende 2024 grundlegend neu aufgestellt. Das Unternehmen hat die Entwicklung eigener Frontier-Sprachmodelle eingestellt und sich komplett auf PhariaAI konzentriert – ein „Operating System für generative KI" für Enterprise und Public Sector. PhariaAI läuft on-premise, in privater Cloud oder als SaaS über STACKIT, die Cloud-Tochter der Schwarz-Gruppe. Die im Januar 2025 vorgestellte T-Free-Architektur zeigt messbare Überlegenheit bei deutschsprachigen Verwaltungstexten. Referenzkunden sind Behörden, globale Chip-Hersteller, Automobilzulieferer. Die angekündigte Fusion mit dem kanadischen Anbieter Cohere, unterstützt von beiden Regierungen, soll die technologische Lücke zu den US-Frontier-Modellen schließen. Aleph Alpha ist frühzeitig Unterzeichner des EU Code of Practice für General-Purpose-AI und positioniert sich explizit über Compliance-Qualität statt Benchmark-Spitze. Für Behörden, KRITIS, Banken und Versicherungen mit eigenem Rechenzentrum und Full-Stack-Integrations-Budget ist das aktuell das kohärenteste Angebot. Für den typischen 50-Mitarbeiter-Mittelständler ist es oft zu schwergewichtig.

Black Forest Labs aus Freiburg im Breisgau ist Europas wertvollstes KI-Start-up mit einer Bewertung von 3,25 Milliarden US-Dollar – und Weltklasse bei der Bildgenerierung. Die FLUX-Modellfamilie ist in ComfyUI, Hugging Face, Replicate und inzwischen auch in Mistrals Le Chat als Bildgenerator integriert. FLUX.2 [klein] 4B läuft lokal mit rund 13 GB VRAM. Ein Punkt, den man für regulierte Szenarien genauer prüfen muss: Black Forest Labs betreibt parallel einen Standort in San Francisco. Die reine EU-Jurisdiktions-Argumentation funktioniert hier nicht so sauber wie bei Mistral oder Aleph Alpha.

DeepL aus Köln ist für Übersetzung und textuelle Bearbeitung der de facto europäische Standard, ISO 27001 und SOC 2 zertifiziert. Teile der Infrastruktur wurden in der Vergangenheit auf Azure-Basis betrieben – wer DeepL für besonders sensitive Inhalte einsetzt, sollte das im konkreten Vertrag explizit klären.

Daneben gibt es LightOn aus Paris (energieeffiziente Enterprise-Modelle), Neuroflash für Content-Marketing, Mindverse als generische Plattform und das deepset/Haystack-Framework aus Berlin für RAG-Architekturen. Für spezifische Anwendungsfälle lohnt der Blick, für den Grundstock genügen meist die ersten vier Namen.

Zum Self-Hosting und Betrieb kommen die europäischen Cloud-Infrastrukturen hinzu: STACKIT (Schwarz-Gruppe) mit C5 und ISAE-3000-/3402-Testaten, Rechenzentren in Deutschland und Österreich; IONOS Cloud; OVHcloud mit französischem SecNumCloud-Standard und 43 Rechenzentren in 9 Ländern; Open Telekom Cloud von T-Systems auf OpenStack-Basis; Scaleway aus Frankreich mit Managed-AI-Angebot (mit Einschränkung: Die Management-Konsole nutzt teilweise US-Services); und Hetzner als günstige, solide Basis für Self-Hosting ohne Enterprise-Services.

🔹 Klasse 2 – US-Modelle in EU-Rechenzentren

Das ist die Klasse, die in der Mehrheit der aktuellen Diskussionen gemeint ist, wenn jemand sagt „wir nutzen das natürlich DSGVO-konform". OpenAI über Azure Frankfurt, Anthropic Claude über AWS Bedrock Frankfurt, Gemini über Google Cloud Vertex AI in der EU-Region.

Das verbreitete Missverständnis: Viele halten das für äquivalent zu Klasse 1. Ist es nicht. Die Daten werden zwar physisch in der EU verarbeitet, aber das Unternehmen, das den Dienst erbringt, ist ein US-Unternehmen. Die CLOUD-Act-Problematik bleibt bestehen. Die EU-Data-Boundary von Microsoft ist technisch sauber umgesetzt, lässt aber in Support-Fällen Restzugriffe von US-Mitarbeitern offen. Bei Azure OpenAI ist der Training-Opt-Out standardmäßig gesetzt. Bei Anthropic über Bedrock läuft ein 7-Tage-Abuse-Monitoring, das nicht für Training verwendet wird – dokumentationspflichtig, aber in aller Regel akzeptabel.

Für Unternehmen außerhalb hochregulierter Branchen ist Klasse 2 mit sauberem Transfer Impact Assessment, Standardvertragsklauseln und dokumentierter Risikoabwägung machbar. Für Banken, Versicherer und Behörden wird es schwierig – nicht weil es rechtlich per se unmöglich wäre, sondern weil § 25a KWG, DORA und die BaFin-Orientierungshilfe faktisch eine Nachweisschwelle definieren, die mit reinen US-Angeboten schwer zu überspringen ist.

🔹 Klasse 3 – Selbst gehostete Open-Source-Modelle

Die Goldvariante für Unternehmen, die eigene Infrastruktur, Know-how und entsprechende Volumina haben. Stand Frühjahr 2026 sind praktisch einsetzbar: Mistral Small 4 (MoE, 119 Milliarden Parameter, Apache 2.0), GPT-OSS-120b, Gemma 4 in verschiedenen Größen, Qwen 3.5 von 4B bis 27B, Llama 3.3.

In der Praxis lassen sich damit Setups bauen, die in einer deutlichen Überraschung für die klassische „aber das läuft doch nur in der Cloud"-Fraktion enden. Ein konkretes Beispiel aus der Praxis, das exemplarisch für die Realität vieler kleinerer Büros steht: Ein 15-köpfiges Steuerbüro betreibt Qwen 3.5 9B auf einem Mac mini M4 Pro mit 48 GB Unified Memory zur Mandantendokument-Klassifikation. Zwei Tage Setup mit Ollama und n8n. Keine Daten verlassen das Haus. Keine API-Kosten. Keine DSGVO-Diskussion mit dem Datenschutzbeauftragten.

Wichtig – und das wird gerne übersehen: „Open Source" ist nicht gleich „für alles kommerziell nutzbar". FLUX.2 [klein] 9B ist für kommerzielle Nutzung ausschließlich über die API verfügbar; das 4B-Modell dagegen unter Apache 2.0. Bei Llama-Lizenzen gibt es Nutzungsbeschränkungen jenseits einer bestimmten Unternehmensgröße. Vor jedem Produktiveinsatz gehört die Lizenzprüfung ins Deployment-Playbook.

📌 Die fünf Schichten, die stimmen müssen

Die Frage „ist dieser KI-Anbieter DSGVO-konform" lässt sich nicht pauschal beantworten. Sie zerfällt in fünf Schichten, die einzeln geprüft werden müssen. Das ist der Grund, warum Formulierungen wie „Azure in Frankfurt ist sicher" in ernsthaften Prüfungen nicht weiterhelfen.

Erste Schicht: Serverstandort. Wo werden die Daten physisch während der Inferenz verarbeitet? Das ist die einfachste Frage und oft die einzige, die in oberflächlichen Diskussionen überhaupt gestellt wird. Sie ist notwendig, aber nicht hinreichend.

Zweite Schicht: Anbietersitz. Welchem Rechtsraum unterliegt das Unternehmen, das den Dienst vertraglich erbringt? Das ist der kritische Punkt beim CLOUD Act, bei FISA 702 und bei EO 12333. Ein US-Unternehmen mit Server in Frankfurt ist nicht gleich ein EU-Unternehmen mit Server in Frankfurt. Die Jurisdiktion entscheidet, wer im Konfliktfall Herausgabeansprüche auf welcher Rechtsgrundlage geltend machen kann.

Dritte Schicht: Trainings-Policy. Werden Eingaben für Modelltraining verwendet? Bei ChatGPT in der Consumer-Version: Standardmäßig ja. Bei der API: Standardmäßig nein, aber nur mit korrekt konfiguriertem Account und dokumentiertem AVV. Bei Mistral La Plateforme und Le Chat Pro: Standardmäßig nein. Bei OpenRouter: Konfigurierbar pro Request. Diese Schicht wird oft vergessen, weil sie nicht sichtbar ist, bis ein Datenschutzvorfall auftritt.

Vierte Schicht: Retention-Policy. Wie lange werden Daten aufbewahrt? OpenAI API: 30 Tage Abuse-Monitoring. Anthropic: 7 Tage. OpenRouter im ZDR-Modus: keine. Normalerweise akzeptabel, aber dokumentationspflichtig und für bestimmte Szenarien (etwa Kanzleien mit Mandantendaten) eine bewusste Entscheidung.

Fünfte Schicht: Sub-Prozessor-Kette. Viele vermeintliche „EU-Anbieter" nutzen im Hintergrund OpenAI oder andere US-Dienstleister. Der Transfer findet dann trotzdem statt – nur eine Ebene tiefer, und oft ohne dass der Kunde das sieht. Das ist die Schicht, die erfahrene Datenschutzbeauftragte zuerst prüfen: Nicht den Anbieter, sondern seine Sub-Prozessoren.

Erst wenn alle fünf Schichten sauber beantwortet sind, ist die Frage beantwortet. Und das ist genau die strukturierte Prüfung, die Datenschutzbeauftragte und Auditoren sehen wollen. Eine einseitige „wir haben Server in Frankfurt"-Antwort führt in regulierten Branchen verlässlich zur Nachforderung weiterer Unterlagen.

📌 Gateways und Orchestrierung: Zugang zu vielen Modellen ohne Kontrollverlust

In der Praxis braucht man meist Zugang zu mehreren Modellen. Ein Modell für Deutsch-Dialoge, ein anderes für Code, ein drittes für lange Kontexte oder spezifische Reasoning-Tasks. Eine reine Single-Provider-Strategie ist selten praktikabel – und erzeugt zugleich eine Vendor-Lock-in-Abhängigkeit, die unter DORA und § 25a KWG problematisch werden kann.

Hier kommen Gateway-Lösungen ins Spiel, die als Abstraktionsschicht über mehreren Anbietern sitzen.

OpenRouter aus Delaware bietet Zugriff auf rund 300 Modelle über einen einzigen Endpoint. Die entscheidenden Compliance-Features sind weniger bekannt, als sie sein sollten. Zero Data Retention lässt sich pro Request über einen zdr-Parameter oder account-weit aktivieren – dann werden Requests nur noch an Endpoints geroutet, die garantiert nichts speichern. Der Training-Opt-Out schließt explizit alle Provider aus, die auf Eingaben trainieren, mit getrennter Einstellung für bezahlte und kostenlose Modelle. Das EU-In-Region-Routing über die Basis-URL eu.openrouter.ai verarbeitet Prompts und Completions ausschließlich innerhalb der EU – dieses Feature muss allerdings für Enterprise beantragt werden. Eine Provider-Whitelist lässt explizit festlegen, welche Anbieter überhaupt in Frage kommen – etwa nur Mistral, DeepInfra EU und Fireworks.

Damit lässt sich ein Setup bauen, das flexibel mehrere Modelle nutzt, aber garantiert nur EU-Provider mit No-Training-Policy bedient. Das ist der praktische Mittelweg zwischen „wir nehmen nur Mistral" und „wir nehmen alles, was läuft". Wichtig zu wissen: OpenRouter selbst ist ein US-Unternehmen. Datentransfers laufen über Standardvertragsklauseln nach Art. 46 DSGVO. Für Banken, Versicherer und Behörden mit niedriger Risikotoleranz braucht es entweder das EU-In-Region-Routing oder eine andere Lösung.

Requesty aus Frankfurt positioniert sich genau als diese Alternative. Volles EU-Hosting auf AWS in eu-central-1, SOC 2 Type II, Auftragsverarbeitungsvertrag auf Anfrage, Unterstützung für Anthropic, Azure OpenAI, Google Vertex AI, AWS Bedrock, Mistral und Nebius – alle ausschließlich über EU-Endpoints. Zero Data Retention, keine Trainingsnutzung, kein Caching. Das OpenAI-SDK ist als Drop-in-Ersatz kompatibel. Für Unternehmen, die aus guten Gründen keinen US-Gateway-Anbieter wollen, ist das aktuell die sauberste Option.

Portkey ist HIPAA- und ISO-27001-zertifiziert und für spezielle Compliance-Szenarien relevant, im DACH-Raum aber weniger verbreitet.

Eine vierte Variante, die in größeren Organisationen zunehmend Sinn ergibt: das interne AI-Gateway selbst bauen. Keycloak für Authentifizierung, LiteLLM oder Open WebUI als Gateway-Layer, dahinter die freigegebenen Provider. Mehr Aufwand, aber vollständige Kontrolle über Logging, Routing, Budget-Limits und Compliance-Policies. Für Unternehmen mit eigenem Plattform-Team und mehreren LLM-Use-Cases ist das nach zwölf bis 18 Monaten meist der wirtschaftlichere Weg.

📌 Branchenperspektiven – was im Bankensetup richtig ist, wäre im Marketing-Mittelstand übertrieben

Die Compliance-Ebene hängt stark von der Branche ab. Pauschalaussagen wie „der Mittelstand braucht Setup X" führen in der Praxis zu Fehlinvestitionen in beide Richtungen – entweder wird unternötig viel Compliance-Overhead gebaut, oder die regulatorische Messlatte wird unterschritten.

Banken arbeiten in einem harten regulatorischen Umfeld aus § 25a KWG, DORA und BaFin-Orientierungshilfe. Typische Hochrisiko-Anwendungen sind Kreditwürdigkeitsprüfung, Scoring, Fraud Detection und AML. Die BaFin erwartet Explainable AI (SHAP, LIME), lückenlose Dokumentation, Segmentierung von Trainings- und Produktionsumgebungen, Confidential Computing und Schutz vor Model-Extraction- und Inversion-Angriffen. Praktische Konsequenz: Externe US-Cloud-basierte LLMs ohne tiefe Integration sind aufsichtsrechtlich schwer zu rechtfertigen. Die aktuell beste Kombination ist EU-Setup (Mistral, Aleph Alpha/PhariaAI über STACKIT) plus selbst gehostete Open-Source-Modelle für sensitive Bereiche. Kreditentscheidungen mit intransparenten generativen Modellen sind ein absoluter No-Go-Bereich.

Versicherungen unterliegen § 23 VAG, DORA, IDD, dem Entwurf der MaGo und den EIOPA-Guidelines. Typische Use-Cases sind Inputmanagement (Schriftgut-Klassifikation), Schadenautomatisierung, Pricing und Underwriting-Support. Besondere Herausforderungen entstehen bei Fairness und Antidiskriminierung – Art. 9 DSGVO bei sensiblen Merkmalen kombiniert mit dem AGG erzeugt eine komplexe Prüflage. Die BaFin hat mehrfach betont, dass Hochrisiko-KI hier aktiv überwacht wird. Intransparente generative Modelle sind aufsichtsrechtlich besonders problematisch, und automatisierte Leistungsbearbeitung muss protokolliert, nachvollziehbar und durch menschliche Eskalationspfade abgesichert sein.

Gesundheitswesen. Hier ist die C5-Typ-2-Zertifizierung faktisch Marktzutrittskriterium. Der besondere Schutz nach Art. 9 DSGVO für Gesundheitsdaten, das Berufsgeheimnis nach § 203 StGB und das SGB V erzeugen die höchste Hürde im deutschen Regulierungsraum. Konsequenz: Cloud-basierte LLMs nur mit extrem sauberem AVV, DSFA und Ende-zu-Ende-Verschlüsselung oder – häufiger – selbst gehostet im Krankenhaus-Rechenzentrum. Microsoft Dragon Copilot, seit 2025 in Deutschland verfügbar, ist ein interessanter Grenzfall für den klinischen Einsatz, unterliegt aber weiterhin dem CLOUD Act.

Öffentliche Verwaltung. Das F13-Projekt der Landesregierung Baden-Württemberg setzt seit Mitte 2024 auf Aleph-Alpha-basierte KI-Systeme. STACKIT plus PhariaAI ist de facto der deutsche Public-Sector-Standard. Zuständige Aufsicht ist der BfDI für Bundesbehörden und die jeweilige Landesdatenschutzbehörde für Länder. Art. 3 Abs. 3 GG (Diskriminierungsverbot) und die Grundrechte-Folgenabschätzung nach Art. 27 AI Act greifen hier besonders stark.

Mittelstand außerhalb regulierter Branchen. Hier ist der pragmatische Mittelweg realistisch und wirtschaftlich. Mistral Le Chat Teams zu rund 24,99 Euro pro Nutzer und Monat als Standardwerkzeug. OpenRouter mit EU-In-Region und ZDR für Modellvielfalt, wenn mehrere Modelle gebraucht werden. Lokales Qwen 3.5 oder Gemma 4 für sensible Dokumentenarbeit. AVV-Pflicht nach Art. 28 DSGVO für jedes eingesetzte Tool, Training-Opt-Out verifiziert. Und: Die Schulungspflicht aus Art. 4 AI Act seit Februar 2025 ist für jedes Unternehmen relevant, nicht nur für die Hochrisiko-Anwender.

📌 Drei konkrete Setups – und ein Beispielrechnung

In der Praxis haben sich drei Setups herausgebildet, die für unterschiedliche Reifegrade und Branchen funktionieren.

Setup A – Maximale Souveränität. Direktvertrag mit Mistral oder Aleph Alpha/PhariaAI über STACKIT. Bilder über FLUX (EU-API oder lokal in der 4B-Variante). Dokumentenarbeit als RAG on-premise mit Qwen 3.5 oder Gemma 4. Übersetzung mit DeepL Pro im EU-Hosting. Gateway intern gebaut oder über Requesty. Zusätzliche Controls über BYOK, Confidential Computing und Ende-zu-Ende-Verschlüsselung. Die richtige Wahl für Banken, Versicherungen, Gesundheitswesen und Behörden. Eingeschränkter Modellzugang, dafür einfache Freigabe durch die Rechtsabteilung und das Auditkomitee.

Setup B – Flexibilität mit Guardrails. OpenRouter mit striktem Filter: EU-In-Region, Zero Data Retention, Training-Opt-Out, Provider-Whitelist auf EU-Häuser. Alternative: Requesty für strenge EU-only-Anforderungen. Die Vertragslage dokumentiert mit AVV, SCCs und TIA. Abdeckung umfasst Mistral, Aleph Alpha, FLUX, Claude (über Bedrock Frankfurt mit ZDR) und Llama über DeepInfra EU. Zugriff auf viele Modelle, aber nur auf die, die den eigenen Anforderungen genügen. Für die meisten Mittelstandsunternehmen außerhalb hochregulierter Branchen der sinnvolle Mittelweg.

Setup C – Self-hosted Open Source. Eigene Kubernetes-Umgebung oder bei einem EU-Hoster wie STACKIT, OVHcloud oder Hetzner. Modelle: Mistral Small 4, Gemma 4, Qwen 3.5, Llama 3.3, GPT-OSS-120b. Hardware je nach Use-Case: vom Mac mini M4 Pro im kleinen Büro bis zum GPU-Cluster im Großunternehmen. Maximaler Aufwand, maximale Kontrolle. Wirtschaftlich meist erst ab bestimmten Volumina sinnvoll, oder bei besonders schutzbedürftigen Daten.

Für die meisten wachsenden Organisationen ist in der Realität eine Hybridvariante die beste Antwort. Eine Beispielrechnung für ein 15-Personen-Unternehmen: Zehn Claude-Team-Lizenzen zu 25 US-Dollar pro Nutzer (ab fünf Sitzen, via Bedrock Frankfurt mit ZDR) für Mitarbeiter mit anspruchsvollen Reasoning-Tasks. Fünf Mistral-Le-Chat-Pro-Lizenzen zu 14,99 Euro pro Nutzer für Standard-Office-Workflows. Ein kleiner Server mit Gemma 4 lokal (einmalig rund 500 Euro) für sensible Dokumentenarbeit. FLUX-API für Bildgenerierung. Die Gesamtrechnung liegt oft niedriger als 15 mal ChatGPT Plus zum Vergleichszeitpunkt, mit deutlich besserer Compliance-Position.

Die genaue Zusammensetzung variiert. Aber das Prinzip trägt: Nicht ein Anbieter für alles, sondern Anbieter passend zum Schutzbedarf und zur Aufgabe. Das ist weniger elegant in der Präsentation, aber belastbarer in der Prüfung.

🛠️ Was nicht funktioniert und wo die ehrlichen Grenzen liegen

Erstens: EU-Modelle haben in bestimmten Frontier-Benchmarks nach wie vor einen Rückstand zu GPT-5 und Claude Opus. Für komplexe Reasoning-Aufgaben, für sehr lange Kontexte, für exotische Programmiersprachen ist der Unterschied spürbar. Für 80 bis 90 Prozent der typischen Mittelstands-Use-Cases – Zusammenfassung, Dokumentenanalyse, Standardcode, E-Mail-Drafts, Übersetzung – ist der Unterschied in der Praxis kaum relevant. Wer aber den State-of-the-Art für Research- und Engineering-Tasks braucht, kauft sich mit einem reinen EU-Setup heute noch eine Leistungsbegrenzung ein.

Zweitens: Die Kosten- und Aufwands-Abwägung ist real. Ein voll souveränes Setup mit Aleph Alpha PhariaAI, eigenem Rechenzentrum und internem Gateway kostet in Initialaufwand und Betrieb ein Mehrfaches von „OpenAI API mit TIA". Für das Steuerbüro mit 15 Mitarbeitern kann das die falsche Investition sein – auch wenn es das regulatorisch sauberste Setup wäre. Die Kunst ist, das Schutzniveau zu erreichen, das die eigene Branche erfordert, und nicht das theoretisch maximale.

Drittens: Self-Hosting ist nicht „gratis", nur weil keine API-Gebühren anfallen. Personal, Hardware-Abschreibung, Wartung, Sicherheitspatches, Modell-Updates und das Know-how, das nötig ist, um einen produktiven LLM-Stack zu betreiben – all das hat einen Preis. Wir sehen in Projekten immer wieder, dass Self-Hosting-Business-Cases zu optimistisch gerechnet werden, weil der laufende Betriebsaufwand unterschätzt wird. In kleineren Organisationen fehlt oft die zweite Person, die einspringen kann, wenn der Verantwortliche krank oder im Urlaub ist.

Viertens: Das Data Privacy Framework ist rechtlich gültig, aber politisch-strukturell fragil. Das Europäische Gericht hat es im September 2025 im Latombe-Verfahren bestätigt, aber die Rechtsmittel zum EuGH laufen. Die Trump-Administration hat im Januar 2025 drei von fünf demokratischen Mitgliedern des Privacy and Civil Liberties Oversight Board entlassen – genau jenes Gremiums, das zentrale Aufgaben im DPF-Redress-Mechanismus hat. Der EDSA hatte bereits im November 2024 eine Neubewertung innerhalb von drei Jahren gefordert. Max Schrems hat eine Schrems-III-Klage angekündigt. Wer sich ausschließlich auf das DPF stützt, baut auf nachweislich instabilem Fundament. Standardvertragsklauseln plus Transfer Impact Assessment sind als zweites Netz weiterhin Pflicht.

Und fünftens, am wichtigsten: Die Rechtsprechung und Aufsichtspraxis entwickeln sich weiter. Was heute „grundsätzlich machbar" ist, kann in 18 Monaten anders bewertet werden – siehe Microsoft 365. Wer eine KI-Architektur baut, die nur mit einem einzigen Anbieter funktioniert, macht sich von politischen Entscheidungen in Brüssel, Washington und Luxemburg abhängig, die niemand präzise vorhersagen kann. Austauschbarkeit der Modellschicht sollte von Anfang an Designprinzip sein.

📌 Was 2026 wirklich zählt

Die gute Nachricht aus der aktuellen Lage: Wer 2026 KI einsetzen will, steht nicht mehr vor einer binären Wahl zwischen „Compliance-Risiko in Kauf nehmen" und „Verzichten". Die EU-Anbieter sind erwachsen geworden. Mistral zieht im Enterprise-Verkauf an den US-Riesen auf – nicht im Frontier-Benchmark, aber im ausgerollten Unternehmenseinsatz. Aleph Alpha hat sich neu erfunden und ist über die STACKIT-Partnerschaft bundesweit in der Fläche. Der EU AI Act liefert einen Rahmen, der trotz aller Kritik an Details Rechtssicherheit schafft. Die DSK hat dreimal orientiert, die BaFin hat sich positioniert. Man muss nicht mehr vermuten, was gilt.

Die entscheidende Botschaft für Unternehmen, die KI bisher aus Datenschutzgründen zurückgehalten haben: Der Weg ist da. Man muss ihn nur sauber gehen.

Und die strategisch wichtigste Erkenntnis für jeden, der gerade Architekturentscheidungen trifft: Compliance darf kein Nachgedanke sein. Die Modellschicht lässt sich austauschen. Rechtsgrundlagen nicht. Wer heute in einem KI-Setup die fünf Schichten sauber beantwortet hat, das Austauschen von Modellen als Designprinzip versteht und das Schutzniveau der eigenen Branche kennt, hat eine Architektur, die die nächsten fünf Jahre trägt. Wer sich auf einen einzigen Anbieter und ein einziges Rechtsregime verlässt, hat ein Architekturversprechen abgegeben, das niemand halten kann.

Die Frage ist nicht mehr, ob der DACH-Mittelstand KI einsetzen sollte. Die Frage ist, mit welcher Architektur. Und da haben wir 2026 deutlich mehr Optionen, als die Diskussion im Markt vermuten lässt.

---

Wenn Sie gerade KI-Projekte in Ihrem Unternehmen planen oder ein laufendes Setup einer Compliance-Prüfung unterziehen wollen: Die fünf Schichten sind ein guter Ausgangspunkt für die interne Diskussion. Wer dabei auf konkrete Fragen stößt – insbesondere zur branchenspezifischen Einordnung – kann gerne auf mich zukommen.

---

💡 Hinweis zum Charakter dieses Artikels

Dieser Beitrag ist ein technisch-strategischer Lagebericht aus der Projektpraxis, keine Rechtsberatung. Die dargestellten Einordnungen zu DSGVO, EU AI Act, CLOUD Act, BaFin-Orientierungshilfen und Aufsichtspraxis sind das Ergebnis einer Recherche mit Stand April 2026. Die Rechtslage entwickelt sich schnell weiter – sowohl durch neue Urteile (Schrems-III-Verfahren, DPF-Rechtsmittel zum EuGH, weitere DSK-Orientierungshilfen) als auch durch sich ändernde Aufsichtspraxis. Einzelfälle können rechtlich anders zu bewerten sein als die hier beschriebenen Regelkonstellationen.

Bevor Sie auf Basis dieses Artikels konkrete Architektur-, Vertrags- oder Beschaffungsentscheidungen treffen, stimmen Sie sich bitte dringend mit Ihrem Datenschutzbeauftragten und Ihrer Rechtsabteilung ab – und in regulierten Branchen zusätzlich mit Compliance und gegebenenfalls externem Fachanwalt für IT-Recht. Für Banken, Versicherungen und Gesundheitsdienstleister kommen neben der DSGVO weitere Regelwerke (§ 25a KWG, § 23 VAG, DORA, § 203 StGB, BSI-IT-Grundschutz, C5) zur Anwendung, deren Zusammenspiel im Einzelfall geprüft werden muss. Dieser Artikel kann diese Prüfung nicht ersetzen und soll sie nicht ersetzen. Er soll sie besser vorbereiten.