On-Premise vs. Cloud vs. EU-Hosting (Souveränität)

Lernziele

Sie beschreiben die drei Hosting-Optionen für KI-Systeme (On-Premise, internationale Cloud, EU-Hosting) mit ihren wesentlichen Vor- und Nachteilen.

Sie erklären die rechtliche Bedeutung des Cloud Act (USA) und des FISA 702 für europäische Unternehmen, die US-Cloud-Dienste nutzen.

Sie ordnen konkrete KI-Use-Cases den geeigneten Hosting-Optionen zu — basierend auf Datenstufe (UE 100) und Risikobereitschaft.

Sie beschreiben die 2+1-Strategie (international + EU-Backup) als pragmatischen Ansatz für hybride Hosting-Architekturen.

Sie benennen mindestens drei europäische KI-Anbieter und erklären, in welchen Szenarien sie gegenüber internationalen Anbietern bevorzugt werden sollten.

Sie erklären, was das EU-US Data Privacy Framework leistet — und wo seine Grenzen liegen.

Auf einen Blick

Worum geht es? — Der didaktische Einstieg

„Unsere Daten liegen in der Cloud” — dieser Satz ist in Unternehmen allgegenwärtig. Aber welche Cloud? In welchem Land? Unter welchem Recht? Und: Was passiert mit den Daten, wenn die US-amerikanische Bundesbehörde FBI auf der Basis des Cloud Act bei Microsoft oder Google anfragt — auch wenn das Rechenzentrum physisch in Frankfurt steht?

Die Hosting-Entscheidung für KI-Systeme ist eine der wichtigsten Datenschutz-Architekturentscheidungen, die Organisationen treffen müssen. Sie bestimmt, welche Gesetze auf die verarbeiteten Daten anwendbar sind, wer theoretisch Zugriff auf die Daten hat, und welche Schutzmaßnahmen überhaupt sinnvoll sind.

Diese Unterrichtseinheit gibt keine absolute Antwort auf die Frage „Welches Hosting ist richtig?” — denn das hängt vom Use-Case, den Datenstufen und der organisatorischen Risikobereitschaft ab. Sie gibt aber das Wissen, um eine begründete Entscheidung zu treffen.

Lerntext — Theorie und Konzepte

Drei Hosting-Optionen im Überblick

Option 1 — On-Premise (Eigene Infrastruktur):

Das KI-System läuft vollständig auf eigenen Servern in eigenen Rechenzentren. Das Modell wird lokal betrieben — entweder als selbst-trainiertes Modell oder als Open-Source-Modell (Llama 3, Mistral, Qwen etc.), das lokal deployed wird.

Vorteile: Vollständige Datenkontrolle, kein Drittstaaten-Transfer-Risiko, keine externen API-Abhängigkeiten, maximale Sicherheit für Stufe-4-Daten.

Nachteile: Erheblicher Infrastruktur- und Wartungsaufwand, hohe Initialkosten (GPU-Server), Performance-Nachteile gegenüber spezialisierten Cloud-Modellen, kein Zugang zu neuesten Modell-Generationen ohne Update-Aufwand.

Geeignet für: Hochsensible Daten (Stufe 4), stark regulierte Branchen (Rüstung, Kernkraft, staatliche Sicherheit), Hochrisiko-KI-Systeme mit besonderen Datenschutzanforderungen.

Option 2 — Internationale Cloud (US-Anbieter mit EU-Rechenzentrum):

Die führenden KI-Dienste (OpenAI API, Microsoft Azure OpenAI, Google Vertex AI, Anthropic API) werden von US-amerikanischen Unternehmen betrieben — auch wenn physische Rechenzentren in Europa stehen.

Das Cloud-Act-Problem: Der US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) ermöglicht US-Strafverfolgungsbehörden, US-Unternehmen zu verpflichten, Daten herauszugeben — unabhängig davon, wo die Daten physisch gespeichert sind. Auch FISA Section 702 ermöglicht geheimdienstliche Datenzugriffe. Das bedeutet: Selbst wenn Ihre Daten in einem Frankfurter Rechenzentrum von Microsoft Azure liegen, kann die US-Regierung unter bestimmten Umständen darauf zugreifen — ohne dass Microsoft Sie informieren darf.

Das EU-US Data Privacy Framework (DPF): Das seit Juli 2023 gültige DPF bietet einen rechtlichen Rahmen für die Übertragung personenbezogener Daten aus der EU in die USA. Es ist der Nachfolger des gescheiterten Privacy Shield und enthält Datenschutzgarantien sowie einen Rechtsweg für EU-Bürger. Allerdings: Der DPF wurde bereits kritisch kommentiert — die CLOUD-Act-Problematik löst er nicht vollständig, und seine Bestandskraft ist politisch nicht garantiert.

Merksatz

Ein Rechenzentrum in Frankfurt unter Microsoft-Betrieb ist kein EU-Rechenzentrum im Sinne der DSGVO-Datensouveränität — es ist ein US-Unternehmen, das in Frankfurt Server betreibt. Der Unterschied ist rechtlich erheblich: US-Gesetze (Cloud Act, FISA) können auf diese Daten angewendet werden. Für Stufe-3- und Stufe-4-Daten muss das bei der Hosting-Entscheidung berücksichtigt werden.

Option 3 — EU-Hosting (Europäische Anbieter):

KI-Systeme werden auf Infrastruktur europäischer Anbieter betrieben, die ausschließlich europäischem Recht unterliegen.

Relevante europäische Anbieter: - Mistral AI (Frankreich): Bietet Open-Source-Modelle (Mistral 7B, Mistral Large, Mistral NeMo) und eine API mit EU-Datensouveränitätsoption. Die Modelle konkurrieren in vielen Bereichen mit GPT-4. - Aleph Alpha (Deutschland / Heidelberg): Entwickelt das Luminous-Modell-Family mit Fokus auf europäische Datensouveränität. Besonders relevant für regulierte Branchen und Behörden. - IONOS (Deutschland): Cloud-Infrastruktur mit deutschem Serverstandort und Hosting-Optionen für selbst deployte Open-Source-Modelle. - OVHcloud (Frankreich): Europäischer Cloud-Anbieter, auf dem Open-Source-LLMs deployt werden können.

Vorteile: Kein US-Rechtszugriff, klare DSGVO-Compliance, keine DPF-Abhängigkeit.

Nachteile: Oft geringere Modell-Performance als OpenAI/Anthropic/Google bei allgemeinen Aufgaben, kleineres Ökosystem, höhere Kosten (weniger Skaleneffekte).

Die 2+1-Strategie: Pragmatischer Hybridansatz

Für die meisten Organisationen ist weder reines On-Premise noch reines EU-Hosting die optimale Lösung. Die 2+1-Strategie bietet einen pragmatischen Mittelweg:

Position 1 (Primär): Internationaler Cloud-Anbieter (OpenAI API, Microsoft Azure OpenAI) für den Großteil der Aufgaben mit Stufe-1- und Stufe-2-Daten. Höchste Performance und größtes Ökosystem.

Position 2 (Reguliert): EU-Anbieter (Mistral, Aleph Alpha, IONOS-hosted Open Source) für Aufgaben mit Stufe-3-Daten, bei denen US-Rechtszugriff nicht akzeptabel ist.

+1 (Souverän): On-Premise-Lösung für einen definierten Set von Stufe-4-Aufgaben, bei denen maximale Kontrolle unumgänglich ist.

Diese Dreiteilung ermöglicht eine nuancierte Risikoabwägung, ohne auf die Vorteile der besten verfügbaren Modelle vollständig zu verzichten.

Merksatz

Die Hosting-Entscheidung ist keine einmalige Wahl — sie ist eine Architektur. Unterschiedliche Use-Cases mit unterschiedlichen Datenstufen können und sollten unterschiedliche Hosting-Optionen nutzen. Eine Organisation, die für alle Use-Cases dieselbe Infrastruktur wählt, optimiert entweder nicht (zu restriktiv) oder riskiert zu viel (zu permissiv).

Hybride Architekturen und praktische Umsetzung

Die Integration mehrerer Hosting-Optionen in eine kohärente Architektur erfordert klare Routing-Regeln: Welcher Use-Case kommt zu welchem Anbieter? Automatisches Routing auf Basis der Datenstufenklassifizierung (aus UE 100) ist der eleganteste Ansatz:

Eingabe mit Stufe-1-Daten → Internationaler Anbieter (beste Performance)

Eingabe mit Stufe-2-Daten → Internationaler Anbieter mit EU-Rechenzentrum + AVV

Eingabe mit Stufe-3-Daten → EU-Anbieter (Mistral/Aleph Alpha) oder Self-Hosted

Eingabe mit Stufe-4-Daten → On-Premise

Diese Architektur erfordert Implementierungsaufwand — aber sie ist die technische Umsetzung eines risikobasierten Datenschutzkonzepts.

Kostenmodelle im Vergleich

Die Hosting-Entscheidung hat auch eine Kostendimension:

Token-basierte API-Kosten: Internationale Cloud (OpenAI GPT-4o: ~$2,50/M Input-Token, ~$10/M Output-Token), EU-Anbieter (Mistral Large: €2/M Input-Token, €6/M Output-Token), Self-Hosted Open Source: Infrastrukturkosten (GPU-Server) statt Token-Kosten.

Total Cost of Ownership: On-Premise hat hohe Initialkosten (GPU-Server $10.000–100.000+), aber nahezu keine variablen Kosten. Cloud-Dienste haben keine Initialkosten, aber lineare Kostenentwicklung mit Nutzungsvolumen. Ab ca. 500–1.000 täglichen Anfragen kann Self-Hosting wirtschaftlich attraktiver werden.

Datenschutzkosten: EU-Hosting kostet typischerweise 20–40 % mehr als internationale Cloud-Dienste. Diese Mehrkosten sind der „Preis für Datensouveränität” — und müssen gegen das Risiko fehlender Souveränität abgewogen werden.

Vertiefung — FISA 702, Cloud Act und die Grenzen des EU-US Data Privacy Framework

Die rechtliche Tiefe der Hosting-Frage geht über die übliche Datenschutzdiskussion hinaus. Für Organisationen, die sensible Daten (Stufe 3–4) in US-Cloud-Diensten verarbeiten, sind drei Rechtsbereiche relevant:

Cloud Act (2018): Ermöglicht US-Strafverfolgungsbehörden (FBI, DOJ), US-Unternehmen zu verpflichten, Kundendaten herauszugeben — auch wenn die Daten außerhalb der USA gespeichert sind. Microsoft kann von einem US-Gericht verpflichtet werden, Daten aus dem Frankfurter Rechenzentrum herauszugeben, ohne den deutschen Kunden zu informieren. Der Widerspruch zwischen Cloud Act und DSGVO ist real und bisher nicht rechtlich aufgelöst.

FISA Section 702 (Foreign Intelligence Surveillance Act): Ermöglicht US-Nachrichtendiensten (NSA, CIA, FBI) den Zugriff auf Daten „non-US persons” bei US-Unternehmen — ohne Gerichtsbeschluss, unter geheimem FISA-Court-Verfahren. Es gibt keine effektive Möglichkeit für europäische Unternehmen oder Einzelpersonen zu erfahren, ob ihre Daten betroffen waren.

EU-US Data Privacy Framework (DPF): Das DPF (Juli 2023) schafft einen Rechtsrahmen für Drittstaaten-Transfers und enthält Datenschutzgarantien sowie ein Data Protection Review Court (DPRC) als Rechtsweg für EU-Bürger. Kritiker sehen im DPF jedoch einen erneut angreifbaren Rechtsrahmen (ähnlich wie die gescheiterten Vorgänger Safe Harbor 2000 und Privacy Shield 2016, die beide vom EuGH für ungültig erklärt wurden).

Praktische Konsequenz: Für Stufe-3- und Stufe-4-Daten ist die Nutzung europäischer Anbieter oder On-Premise-Lösungen die rechtlich sicherere Wahl — auch wenn das DPF aktuell Bestandskraft hat. Für Stufe-1- und Stufe-2-Daten ist die Risikoexposition durch Cloud Act und FISA 702 typischerweise akzeptabel.

Branchen-Anwendungen

IT-Dienstleistung & Beratung

Ein Berliner IT-Beratungshaus betreibt mehrere KI-Systeme für interne und kundenorientierte Aufgaben. Die Hosting-Strategie folgt der 2+1-Logik: Für die interne Recherche und allgemeine Produktivitätsaufgaben wird OpenAI API (EU-Rechenzentrum, AVV) verwendet. Für kundenbezogene Analysen mit Vertragsdetails und Personaldaten wird Mistral Large über die Mistral-API (französisches Unternehmen, EU-Hosting) verwendet. Für einen spezifischen Hochrisiko-Use-Case (Bewerbungsscreening für einen Kunden im öffentlichen Sektor) wird ein selbst-gehostetes Llama-3-Modell auf einem dedizierten Server eingesetzt. Diese differenzierte Architektur kostet mehr in der Wartung, gibt dem Unternehmen aber die Möglichkeit, Kunden aus regulierten Branchen (öffentliche Verwaltung, Gesundheitssektor) zu bedienen, die On-Premise-Anforderungen haben.

Industrie & Fertigung

Ein Maschinenbauunternehmen mit starker Exportorientierung entscheidet sich nach einem internen Risikoworkshop für eine konservative Hosting-Strategie: Alle Produktionsdaten und F&E-Informationen (Stufe 3–4) werden ausschließlich On-Premise auf eigenen GPU-Servern verarbeitet. Das Self-Hosted-Modell ist Llama 3 70B — leistungsstark genug für die internen Aufgaben. Für Marketing- und Kommunikationsaufgaben wird Microsoft 365 Copilot verwendet. Die Begründung für die konservative Entscheidung: Das Unternehmen hat laufende Patentanmeldungen und befürchtet, dass Produktionsgeheimnisse in einem US-Cloud-System für US-Geheimdienste zugänglich werden könnten — ein Risiko, das in einer globalisierten Wettbewerbsumgebung inakzeptabel ist.

Finanzdienstleistung & Versicherung

Eine große Versicherungsgesellschaft hat nach einer ausführlichen Risikoanalyse entschieden, für Kundenanfragen und Schadensbearbeitung (Stufe 3, DSGVO Art. 9 Gesundheitsdaten) ausschließlich einen europäischen Anbieter zu nutzen. Die Entscheidungskriterien: Sitz in Europa, vollständig DSGVO-konformer AVV, ISO 27001-Zertifizierung, und keine Abhängigkeit von US-Gesetzgebung. Für interne Kommunikation und allgemeine Produktivitätsaufgaben wird Microsoft 365 Copilot eingesetzt (Datenlokation Deutschland, Microsoft-AVV). Die jährlichen Mehrkosten für den EU-Anbieter gegenüber einem US-Anbieter betragen ca. 35 % — kalkuliert als vertretbarer Preis für das reduzierte Compliance-Risiko.

Öffentliche Verwaltung

Ein Bundesministerium evaluiert den Einsatz von KI-Assistenten für interne Bearbeitung von Dokumenten aus laufenden Gesetzgebungsvorhaben. Die Anforderungen sind klar: Alle Daten müssen auf deutschen Servern bleiben, kein Zugriff durch Drittstaaten-Behörden akzeptabel, vollständige Auditierfähigkeit durch den Bundesrechnungshof. Die Lösung: Ein Self-Hosted Open-Source-Modell (Mistral, Llama 3) auf Bundesrechenzentrum-Infrastruktur. Der Implementierungsaufwand ist erheblich — aber er ist die einzige Option, die alle Anforderungen erfüllt. Ergänzend plant das Ministerium die Nutzung der Deutschen Verwaltungscloud (DVS) als gemeinsame Infrastruktur für Bundesbehörden — eine Skalierung des On-Premise-Ansatzes auf nationaler Ebene.

Übung 1 — Hosting-Entscheidung für fünf Use-Cases treffen

Aufgabe: Sie treffen für fünf KI-Use-Cases eine begründete Hosting-Entscheidung basierend auf Datenstufe und Risikobereitschaft.

Use-Cases: (A) Interne FAQ-Bot für allgemeine HR-Fragen (keine personenbezogenen Daten). (B) KI-Assistent, der Bewerbungsunterlagen analysiert und HR-Empfehlungen erstellt. (C) Chatbot für öffentliche Kundenkommunikation (keine vertraulichen Daten). (D) Analysetool für Produktionsdaten mit Angaben zu Fertigungsmethoden (unveröffentlicht). (E) Meeting-Zusammenfassungs-Assistent für interne Meetings ohne Kundenbeteiligung.

Schritt-für-Schritt: 1. Bestimmen Sie für jeden Use-Case die Datenstufe. 2. Wählen Sie die geeignete Hosting-Option (On-Premise / EU-Hosting / Internationale Cloud). 3. Begründen Sie Ihre Entscheidung in einem Satz. 4. Identifizieren Sie: Welcher Use-Case ist am einfachsten zu entscheiden — welcher ist der Grenzfall?

Erwartetes Ergebnis: Fünf begründete Hosting-Entscheidungen.

Musterlösung:

Übung 2 — 2+1-Strategie entwickeln

Aufgabe: Sie entwickeln eine konkrete 2+1-Hosting-Strategie für eine Organisation mit fünf aktiven KI-Use-Cases.

Use-Case-Portfolio: (1) Allgemeiner Wissensassistent für Mitarbeitende (Stufe 2). (2) Angebots-Assistent mit Kundendetails (Stufe 3). (3) Recruiting-Screener (Stufe 3–4, Hochrisiko AI Act). (4) Marketing-Texterstellung (Stufe 1). (5) F&E-Analyse mit unveröffentlichten Produktdaten (Stufe 4).

Schritt-für-Schritt: 1. Ordnen Sie jeden Use-Case einer der drei Hosting-Positionen zu (Primär international / EU-Anbieter / On-Premise). 2. Nennen Sie für jede Position einen konkreten Anbieter. 3. Schätzen Sie den relativen Kostenmehraufwand für EU-Hosting und On-Premise gegenüber reiner internationaler Cloud. 4. Formulieren Sie die Routing-Regel, die automatisch entscheidet, welcher Use-Case welche Infrastruktur nutzt.

Erwartetes Ergebnis: Eine 2+1-Strategie-Skizze mit Anbieter-Zuordnung und Routing-Regel.

Musterlösung:

Position 1 (International): Use-Cases 1 und 4 → OpenAI API mit EU-RZ + AVV, beste Performance für Stufe-1/2-Aufgaben. Position 2 (EU): Use-Case 2 → Mistral Large (französisches Unternehmen, EU-Hosting, AVV), geeignet für Stufe-3-Kundendaten. +1 (On-Premise): Use-Cases 3 und 5 → Self-Hosted Llama 3 70B auf eigenem GPU-Server, für Stufe-4-Daten und Hochrisiko-KI.

Routing-Regel: Datenstufenklassifizierung (aus UE 100) bestimmt automatisch das Ziel-System. Technische Umsetzung: Wenn Eingabedaten mit Stufe ≤ 2 getaggt → API 1 (International). Wenn Stufe = 3 → API 2 (EU-Mistral). Wenn Stufe = 4 oder Hochrisiko-Flag gesetzt → On-Premise-Endpunkt.

Warnung — Cloud Act, FISA 702 und DSGVO-Compliance

Risiko: Der US CLOUD Act (2018) und FISA Section 702 ermöglichen US-Behörden den Zugriff auf Daten bei US-Unternehmen — auch wenn diese in Europa gespeichert sind. Das bedeutet: Personenbezogene Daten, die in Microsoft Azure (Rechenzentrum Frankfurt), OpenAI API oder Google Cloud verarbeitet werden, können potenziell von US-Behörden abgerufen werden, ohne dass das betroffene europäische Unternehmen informiert wird. Das EU-US Data Privacy Framework reduziert dieses Risiko, eliminiert es aber nicht vollständig — und seine Bestandskraft ist politisch unsicher (Vorgänger Safe Harbor und Privacy Shield wurden vom EuGH gekippt).

OWASP LLM-Risiko: Neben dem regulatorischen Risiko schafft die Nutzung externer Cloud-Dienste auch ein OWASP LLM02-Risiko (Insecure Output Handling) und LLM06 (Sensitive Information Disclosure): Eingaben in Cloud-KI-Systeme verlassen die Kontrolle der Organisation.

Handlungsempfehlung: Für Daten der Stufe 3 und 4 empfiehlt sich unabhängig von der aktuellen DPF-Gültigkeit die Nutzung europäischer Anbieter oder On-Premise-Lösungen — als Risiko-Hedge gegen eine mögliche zukünftige DPF-Ungültigkeit.

Cheatsheet — Die wichtigsten Punkte

Drei Optionen: On-Premise (maximale Kontrolle) → EU-Hosting (Souveränität) → Internationale Cloud (maximale Performance)

Cloud Act: US-Unternehmen müssen US-Behörden Daten herausgeben — auch aus EU-Rechenzentren

FISA 702: Geheimdienstliche Datenzugriffe ohne Gerichtsbeschluss für Nicht-US-Personen bei US-Unternehmen

EU-US DPF: Rechtsrahmen für Drittstaaten-Transfer seit Juli 2023 — aber politisch unsicher

Europäische Anbieter: Mistral AI (FR), Aleph Alpha (DE), IONOS (DE), OVHcloud (FR)

2+1-Strategie: Primär international + EU für sensible Daten + On-Premise für Hochsensibles

Kostenregel: EU-Hosting ~20–40 % teurer als internationale Cloud

Routing-Regel: Datenstufe (UE 100) bestimmt Hosting-Ziel — automatisch, nicht situativ

Prompt-Vorlage — Hosting-Entscheidungsanalyse für eine konkrete KI-Lösung durchführen

Prompt für einen KI-Assistenten:

„Ich bewerte gerade die Hosting-Optionen für einen KI-gestützten Dokumentenanalyse-Assistenten in unserem Unternehmen. Der Assistent soll Verträge, Angebote und interne Projektdokumente analysieren und zusammenfassen. Wir sind ein Beratungsunternehmen mit einigen Kunden aus dem öffentlichen Sektor.

Analysiere bitte die drei Hosting-Optionen für diesen Anwendungsfall:

Option A: Microsoft Azure OpenAI Service (Rechenzentrum in der EU, AVV vorhanden) Option B: OpenAI API direkt (US-amerikanische Infrastruktur, Standard-Nutzungsbedingungen) Option C: Open-Source-Modell (z. B. Llama 3) auf eigenem Server (On-Premise)

Für jede Option analysiere: 1. Datenschutz-Compliance (DSGVO, insb. Art. 28, Art. 46 – Drittlandübermittlung) 2. Datensouveränität (Wer hat Zugriff auf die Daten? Welche US-Gesetze können greifen?) 3. KI-spezifische Sicherheitsanforderungen (Logging, Zugriffskontrolle, Audit-Trail) 4. Wirtschaftlichkeit (grobe Einschätzung: Aufwand vs. Kosten) 5. Eignung für Kunden aus dem öffentlichen Sektor

Empfehle am Ende die beste Option für unseren Kontext und begründe sie in 4–5 Sätzen.”

Erwartetes Ergebnis: Eine strukturierte Entscheidungsvorlage, die in einer Management-Präsentation verwendet werden kann — als Grundlage für eine fundierte Make-or-Buy-Entscheidung.

Reflexionsfragen

Warum reicht ein EU-Rechenzentrum-Label eines US-Unternehmens nicht als DSGVO-Schutz für Stufe-3-Daten?

Ihr CFO fragt, warum On-Premise 40 % teurer ist als Cloud und ob das gerechtfertigt ist. Wie argumentieren Sie?

Das EU-US Data Privacy Framework wird vom EuGH für ungültig erklärt (Szenario). Welche sofortigen Konsequenzen hätte das für eine Organisation, die nur internationale Cloud-Dienste nutzt?

Für welche Use-Cases in Ihrer Organisation würden Sie EU-Hosting oder On-Premise bevorzugen — und warum?

Mistral AI ist ein junges französisches Unternehmen. Wie bewerten Sie das Risiko, einen KI-Kernanbieter zu wählen, der kleiner ist als OpenAI oder Microsoft?

Quellen & Weiterlesen

Hinweise für AI Champions — So vermitteln Sie das Thema — UE 101

Timing (45 Min): 5 Min Einstieg (Frankfurter Rechenzentrum-Paradox), 15 Min Lerntext (Drei Optionen + Cloud Act + 2+1), 18 Min Übungen (10 Min Übung 1, 8 Min Übung 2), 5 Min Reflexion + Cheatsheet, 2 Min Übergang.

Methodische Empfehlung: Das Cloud-Act-Paradox ist der stärkste Aha-Moment dieser UE: „Das Rechenzentrum steht in Frankfurt — und trotzdem kann das FBI die Daten abrufen.” Diesen Moment bewusst inszenieren. Übung 1 (Use-Case-Zuordnung) funktioniert gut in der Gruppe oder allein mit kurzer Abstimmung — zeigt, dass die Entscheidungen nicht immer offensichtlich sind.

Häufige Stolpersteine: (a) Teilnehmende glauben, das EU-US DPF löse alle Probleme. Klärung: DPF schafft Rechtmäßigkeit für den Transfer, eliminiert aber nicht das Cloud-Act-Zugriffsrisiko und ist politisch unsicher. (b) „On-Premise ist zu teuer” — Gegenrechnung: Bei 1.000+ täglichen Anfragen und sensiblen Daten amortisiert sich die Investition. Der richtige Vergleich ist nicht On-Premise vs. Cloud-Kosten, sondern On-Premise vs. Cloud + Risikokosten. (c) Europäische Anbieter werden als minderwertig wahrgenommen. Aktuelle Modell-Benchmarks zeigen: Mistral Large und ähnliche EU-Modelle liegen bei vielen Business-Aufgaben nahe an GPT-4o.

Diskussionsfragen für Plenum: (1) Wenn Sie heute eine Hosting-Entscheidung für Ihr sensibelstes KI-System treffen müssten — wohin würde sie fallen? (2) Was bräuchte europäische KI-Infrastruktur, um gegenüber US-Anbietern vollständig wettbewerbsfähig zu werden?

Tafelbild-Vorschlag: Drei-Spalten-Schema: On-Premise | EU-Hosting | Internationale Cloud — mit Vor-/Nachteilen und den zulässigen Datenstufen. Visuell verbunden mit der Datenstufenpyramide aus UE 100.

Differenzierung Power-User ↔ Einsteiger: Power-User recherchieren den aktuellen Verarbeitungsstandort und AVV-Status von Mistral AI und Aleph Alpha und vergleichen sie mit OpenAI Enterprise. Einsteiger fokussieren auf die praktischen Use-Case-Zuordnungen (Übung 1) und nutzen die Routing-Regel als Entscheidungshilfe.

Materialliste: Datenstufen-Übersicht aus UE 100 (als Referenz), Hosting-Matrix ausgedruckt, Laptop für Recherche (Übung 2).

Übergang zur nächsten UE: „Wir wissen jetzt, WO Daten verarbeitet werden dürfen. Die nächste Frage ist: Wie prüfen wir, ob ein konkreter Anbieter tatsächlich hält, was er verspricht? UE 102 gibt die strukturierte Antwort: der Vendor-Assessment-Prozess.”

Tipp zur Branchenauswahl: In IT-Dienstleistungs-Trainings ist die 2+1-Strategie direkt als Beratungsprodukt für eigene Kunden relevant. In Industrie-Trainings ist das On-Premise-Szenario mit GPU-Servern für F&E-Daten besonders greifbar. Im öffentlichen Sektor ist die Deutsche Verwaltungscloud (DVS) und die Bundescloud als konkrete Alternativen zu nennen.

Vertiefung II — Hosting-Entscheidungen in der Praxis: Wirtschaftlichkeit und Rechtssicherheit

Total Cost of Ownership: Hosting-Optionen im Kostenvergleich

Die Wahl der Hosting-Option ist nicht nur eine Frage der Datensouveränität — sie hat erhebliche wirtschaftliche Konsequenzen. Eine vollständige Total-Cost-of-Ownership (TCO)-Analyse muss berücksichtigen:

Cloud-SaaS (Stufe 1–2): - Keine Infrastrukturkosten - Nutzungsbasierte Abrechnung (Token-basiert) - Keine Wartungskosten (außer Promptoptimierung und Systemanweisungs-Pflege) - Versteckte Kosten: Token-Volumina skalieren mit Nutzung, ohne Deckel

EU-Cloud (Stufe 2–3): - Höhere Nutzungskosten als US-Cloud (Aufschlag 20–50% typisch) - Größere Gewissheit über Datenlokation - Komplexere Vertragsgestaltung (Datenlokations-Klauseln aushandeln) - Eingeschränkte Modellauswahl (nicht alle Modelle in EU-Region verfügbar)

Private Cloud / Self-Hosted (Stufe 3–4): - Hohe Initialinvestition (Hardware oder dedizierte Cloud-Infrastruktur) - Betriebskosten für IT-Team (Wartung, Updates, Monitoring) - Volle Kontrolle über Modellversionen (kein erzwungenes Update) - Langfristig wirtschaftlich bei hohem Token-Volumen

On-Premise (Stufe 4): - Höchste Initialinvestition (GPU-Hardware: 30.000–200.000 EUR für Enterprise-Grade) - Keine nutzungsbasierten Kosten - Vollständige Datensouveränität - Technische Anforderungen: spezialisiertes MLOps-Team

Der Break-Even-Punkt zwischen Cloud-SaaS und Self-Hosted liegt typischerweise bei einem monatlichen Token-Verbrauch von etwa 5–10 Millionen Tokens — das entspricht circa 5.000–10.000 mittelkomplexen Anfragen pro Monat.

EU-Datenlokationsoptionen im Marktüberblick

Der Markt für EU-konforme KI-Hosting-Optionen hat sich seit 2024 erheblich weiterentwickelt:

Europäische Modell-Provider: - Mistral AI (Frankreich): Le Chat und Mistral-API mit EU-Datenlokation. Le Plateforme (cloud.mistral.ai) bietet GDPR-konforme Verarbeitung in französischen Rechenzentren. - Aleph Alpha (Deutschland): Luminous-Modelle, DSGVO-konform, deutsches Hosting. Fokus auf europäischen Enterprise-Markt. - BLOOM / Hugging Face: Offene Modelle, die auf eigener EU-Infrastruktur betrieben werden können.

US-Anbieter mit EU-Option: - Microsoft Azure OpenAI Service: EU-Rechenzentren in Deutschland (Frankfurt, Berlin), Frankreich und anderen EU-Standorten. Datenlokationsgarantie vertraglich fixierbar. - Google Vertex AI: EU-Region-Option für Gemini-Modelle. - AWS Bedrock: EU-Region-Instanzen verfügbar.

Hinweis: Die Verfügbarkeit und Vertragskonditionen für EU-Datenlokation ändern sich häufig. Aktuelle Konditionen immer direkt mit dem Anbieter klären und vertraglich fixieren.

Regulatorischer Ausblick: Europäische Datensouveränität

Die politische und regulatorische Entwicklung in Europa stärkt tendenziell die Anforderungen an Datensouveränität:

EUCS — EU Cybersecurity Certification Scheme for Cloud Services: Das BSI und ENISA arbeiten an einem europäischen Zertifizierungsrahmen für Cloud-Dienste, der explizit Datenlokations- und Souveränitätsanforderungen für bestimmte Kritikalitätsstufen vorsieht. Wenn dieser Rahmen in Kraft tritt, werden bestimmte Behörden und kritische Infrastrukturen gezwungen sein, EUCS-zertifizierte Cloud-Dienste zu nutzen.

Gaia-X: Die europäische Cloud-Infrastrukturinitiative schafft einen Rahmen für souveräne, interoperable Cloud-Dienste. Gaia-X-konforme KI-Dienste sind eine wachsende Kategorie — insbesondere für öffentliche Auftraggeber relevant.

Diese regulatorischen Entwicklungen sprechen dafür, Hosting-Entscheidungen nicht nur für heute zu treffen, sondern auch die Richtung der regulatorischen Entwicklung zu antizipieren.

Vertiefung II — Strategische Ebene — Make-or-Buy in der strategischen Entscheidungspraxis

Der Total Cost of Ownership (TCO) im Detail

Die Make-or-Buy-Entscheidung wird in der Praxis zu oft auf die Lizenzkosten reduziert. Ein vollständiger TCO-Vergleich über drei Jahre macht den wahren Kostenvorteil oder -nachteil sichtbar:

Buy-Szenario: SaaS-KI-Tool (Beispiel Copilot for Microsoft 365)

Make-Szenario: Selbst entwickelter RAG-Assistent (API-basiert)

In diesem Beispiel ist der Buy-Ansatz (SaaS) im Drei-Jahres-Vergleich günstiger — aber das Make-Szenario bietet mehr Kontrolle über Daten und Funktionalität. Der TCO-Vergleich macht diese Abwägung transparent.

Vendor Lock-in als strategisches Risiko managen

Vendor Lock-in ist bei KI-Tools ausgeprägter als bei vielen anderen SaaS-Diensten, weil der Wechsel nicht nur Daten-Migration, sondern auch Re-Training von Mitarbeitenden und Anpassung aller Workflows umfasst.

Strategien zur Lock-in-Reduzierung:

API-Abstraktionsschicht: Wenn das eigene System über eine Abstraktionsschicht auf verschiedene KI-Anbieter zugreifen kann (z. B. LiteLLM, OpenRouter), ist ein Anbieterwechsel technisch einfacher. Diese Architektur kostet initial mehr, zahlt sich aber bei Anbieter-Preiserhöhungen oder Qualitätsproblemen aus.

Daten-Portabilität vertraglich sichern: Im AVV und Service-Vertrag explizit klären: Wie werden eigene Daten (Fine-Tuning-Daten, Systemkonfigurationen, Usage-Logs) bei Vertragsende exportiert? In welchem Format? Innerhalb welcher Frist?

Paralleltest-Strategie: Bevor ein Hauptanbieter vollständig integriert wird, lohnt ein Paralleltest mit einem alternativen Anbieter für einen Teilbereich. Das schafft Erfahrung mit Alternativen und verhindert ausschließliche Abhängigkeit.

Die Hosting-Entscheidung in der Post-Schrems-II-Ära

Das Schrems-II-Urteil des EuGH (2020) hat den Privacy Shield für Datenübertragungen in die USA für ungültig erklärt. Das EU-US Data Privacy Framework (2023) hat eine neue Rechtsgrundlage geschaffen — aber die regulatorische Unsicherheit bleibt, da neue Klagen möglich sind.

Für die Hosting-Entscheidung bedeutet das: - EU-Hosting oder Hosting in einem Land mit Angemessenheitsbeschluss (Großbritannien, Japan, Kanada, Schweiz, Israel u. a.) ist die datenschutzrechtlich robusteste Wahl. - US-Hosting auf Basis des EU-US Data Privacy Framework ist aktuell rechtlich zulässig — aber das Risiko einer erneuten Annullierung besteht. - Für sensible Daten (Stufe 3–4): EU-Hosting als strategische Entscheidung, unabhängig von der regulatorischen Lage.

Merksatz

Die Hosting-Entscheidung ist nicht nur eine Kostenfrage — sie ist eine strategische Risikoentscheidung. EU-Hosting schützt vor regulatorischen Unsicherheiten im transatlantischen Datentransfer und ist für vertrauliche Daten die empfohlene Standardoption.

Neue Entwicklung: Sovereign AI Cloud als Option

Seit 2024 bieten mehrere europäische Hyperscaler und nationale Cloud-Anbieter sogenannte Sovereign AI Clouds an — Infrastruktur, die vollständig unter europäischer Datensouveränität betrieben wird:

Google Sovereign Cloud (Europa): EUCS-konform, EU-Personal für den Betrieb, keine US-Behördenzugriffe

Microsoft Eu Data Boundary: Alle Kundendaten in EU/EWR gespeichert und verarbeitet

Deutsche Telekom / Open Telekom Cloud: Vollständig deutsches Unternehmen, BSI-Zertifizierung

Hetzner (Deutschland): Kostengünstige Option für kleinere KI-Deployments, vollständig DSGVO-konform

Diese Optionen sind in den letzten zwei Jahren erheblich ausgereifter und attraktiver geworden — sowohl preislich als auch in der Verfügbarkeit spezifischer KI-Dienste. Eine Sovereign-Cloud-Strategie ist heute auch für mittelständische Unternehmen realistisch.

Open-Source-Modelle als Make-Variante: Chancen und Grenzen

Die Open-Source-KI-Landschaft hat sich seit 2023 dramatisch verändert. Modelle wie Llama 3 (Meta), Mistral 7B/8x7B, Gemma (Google) und Phi-3 (Microsoft) bieten Qualitätsniveaus, die für viele Unternehmensanwendungen ausreichend sind — ohne API-Kosten und mit vollständiger Datensouveränität.

Vorteile von Open-Source-Modellen: - Keine API-Kosten (nur Hosting-Kosten) - Vollständige Datensouveränität — keine Daten verlassen die eigene Infrastruktur - Anpassungsmöglichkeiten (Fine-Tuning auf eigene Daten) - Keine Abhängigkeit von Anbieter-Entscheidungen (Model Deprecation, Preiserhöhungen)

Grenzen von Open-Source-Modellen: - Technischer Betriebsaufwand (GPU-Infrastruktur, Modell-Management) - Qualitätsnachteile gegenüber Frontier-Modellen bei komplexen Reasoning-Aufgaben - Kein Herstellersupport, eigene Verantwortung für Modell-Governance - Provider-Pflichten nach EU AI Act — wer ein Open-Source-Modell betreibt und intern einsetzt, ist Provider und Deployer in einer Person

Für Organisationen mit IT-Kompetenz und sensiblen Daten (Stufe 3–4) kann ein selbst betriebenes Open-Source-Modell die datenschutzrechtlich sauberste Lösung sein. Die Betriebskosten und technischen Anforderungen müssen dabei realistisch eingekalkuliert werden.

Vertiefung IV — Fallstudien: Hosting-Entscheidungen in der Praxis

Fallstudie: Ein mittelständisches Beratungsunternehmen (150 Mitarbeitende)

Ausgangslage: Das Unternehmen betreibt einen internen Wissensassistenten auf Basis von OpenAI GPT-4o (API). Datenkategorien: überwiegend Stufe 2 (interne Projektunterlagen), gelegentlich Stufe 3 (Kundendaten in Beratungskontext). AVV mit OpenAI ist vorhanden. EU Data Boundary ist aktiviert — alle Daten werden in der EU verarbeitet.

Herausforderung: Ein Key-Account-Kunde fragt im Due-Diligence-Gespräch, ob Kundendaten, die das Beratungsunternehmen in den Assistenten eingibt, für OpenAI-Training genutzt werden können.

Antwort: Nein — der Enterprise API Plan schließt Training-Nutzung explizit aus. Die EU-Data-Boundary-Dokumentation wird vorgelegt.

Ergebnis: Hosting-Entscheidung (EU Data Boundary + Enterprise API) erzeugt im Kundengespräch konkrete Compliance-Nachweise. Das ist ein messbarer Geschäftswert.

Fallstudie: Ein Fertigungsunternehmen mit OT-Infrastruktur

Ausgangslage: Ein Maschinenbauunternehmen möchte KI für die Auswertung von Maschinensensordaten einsetzen (Predictive Maintenance). Datenkategorie: proprietäre Maschinendaten, die Rückschlüsse auf Fertigungskapazitäten ermöglichen — Wettbewerbssensitiv, Stufe 3.

Hosting-Entscheidung: On-Premises (lokale Infrastruktur, kein Cloud-Zugriff). Modell: Open-Source-Modell (Llama 3, lokal deployed). Begründung: Die Maschinendaten dürfen das Unternehmens-Netzwerk unter keinen Umständen verlassen — weder an US-Anbieter noch an europäische Cloud-Anbieter.

Aufwand: Erheblicher initialer Aufwand für GPU-Infrastruktur und Modell-Management. Laufende Kosten: Strom und IT-Administration. Kein API-Key-Risiko, kein Datentransfer-Risiko.

Lehre: Für Produktionsdaten mit hoher Wettbewerbssensitivität ist On-Premises-Hosting trotz höherer Initialkosten die strategisch richtige Wahl.

Fallstudie: Eine Versicherungsgesellschaft unter DORA

Ausgangslage: Die Versicherungsgesellschaft möchte einen KI-Assistenten für Sachbearbeiter einführen (Unterstützung bei der Schadenbewertung). Unter DORA sind Drittanbieter-Abhängigkeiten detailliert zu dokumentieren und kritische Systeme regelmäßig zu auditieren.

Hosting-Entscheidung: Microsoft Azure OpenAI Service — EU-Region, mit Datenresidenz in Deutschland. Microsoft ist als Cloud-Anbieter bereits unter DORA registriert und ermöglicht Auditrechte gemäß DORA Art. 30.

Besonderheit: Der KI-Assistent für die Schadenbewertung wird als IKT-Drittanbieter-Dienst in das DORA-Drittanbieter-Register eingetragen. Das halbjährliche DORA-Assessment schließt die KI-Dienste explizit ein.

Lehre: In regulierten Branchen muss die Hosting-Entscheidung von Anfang an mit der Compliance-Abteilung abgestimmt werden — weil die regulatorischen Anforderungen (DORA-Auditrechte, DORA-Register) die Anbieterwahl mitbestimmen.

Vertiefung V — Entscheidungsbaum für die Make-or-Buy-Entscheidung

Praktischer Entscheidungsbaum

Die Make-or-Buy-Entscheidung wird in der Praxis oft durch Intuition oder verfügbare Budgets getrieben, statt durch eine strukturierte Analyse. Der folgende Entscheidungsbaum bietet eine systematische Alternative:

Frage 1: Haben Sie hochsensible proprietäre Daten (Stufe 3–4), die das Unternehmen unter keinen Umständen verlassen dürfen? - Ja → Prüfen Sie On-Premises-Optionen oder EU-souveräne Cloud mit strikter Datenresidenz. - Nein → Weiter zu Frage 2.

Frage 2: Ist Ihre Kernanforderung durch ein verfügbares SaaS-Tool gut abgedeckt? - Ja → SaaS (Buy) ist wahrscheinlich die effizientere Wahl. Weiter zum Vendor Assessment. - Nein → Weiter zu Frage 3.

Frage 3: Haben Sie interne technische Kompetenz für Entwicklung und Betrieb? - Ja → Evaluieren Sie einen API-basierten Eigenentwicklungsansatz. - Nein → Externer Implementierungspartner + eigener Betrieb, oder Full-SaaS-Lösungen mit Custom-Optionen.

Frage 4: Wie wichtig ist Differenzierung durch das KI-System für Ihr Kerngeschäft? - Sehr wichtig (Wettbewerbsvorteil) → Eigenentwicklung als strategische Investition. - Produktivitätswerkzeug ohne Differenzierungs-Ambitionen → Bewährtes SaaS-Tool.

Dieser Entscheidungsbaum ist kein Algorithmus, der automatisch die richtige Antwort liefert — aber er strukturiert die relevanten Fragen und verhindert, dass wesentliche Aspekte übersehen werden.

Quelle: KI-Wissensbasis von MindsMachines, Edition Juni 2026. Vollständige Fassung mit Anhängen und Musterlösungen: als PDF anfordern.