Hyperscaler oder 'Made in Germany'? Ein ehrlicher Vergleich für KI-Workloads

Nicht AWS oder Azure sind das Problem. Das Fehlen einer Entscheidungslogik ist es.

Die falsche Frage und die richtige

Wenn das Thema KI-Hosting in Unternehmen diskutiert wird, läuft die Debatte häufig in eine von zwei Richtungen: Entweder wird reflexartig zu einem der großen Hyperscaler gegriffen – AWS, Azure oder Google Cloud –, weil man die Plattform schon kennt und das Momentum der bestehenden Cloud-Investitionen mitgenutzt werden soll. Oder es wird eine pauschale Ablehnung von Cloud-Infrastruktur formuliert, begleitet von Begriffen wie 'digitale Souveränität' und 'Datensicherheit', ohne dass klar wird, was das in der Praxis konkret bedeuten soll.

Beide Haltungen greifen zu kurz. Die eigentliche Frage ist nicht: 'Hyperscaler oder nicht?' Sie lautet: 'Welches Hosting-Modell passt zu welchem KI-Workload – und warum?' Das ist eine analytische Frage, keine ideologische. Sie erfordert ein klares Kriterienraster, eine ehrliche Bewertung der eigenen Situation und die Bereitschaft, verschiedene Modelle für verschiedene Anwendungsfälle zu kombinieren.

Genau das liefert dieser Artikel. Wir vergleichen die fünf relevanten Hosting-Modelle für KI-Workloads im Mittelstand – On-Premises, Private Cloud, Managed GPU-Hosting in Deutschland, Hyperscaler und Edge/On-Device – entlang konkreter Kriterien, ohne Schaum vor dem Mund und ohne blinde Flecken. Am Ende steht eine Entscheidungsmatrix und eine klare Empfehlung für die häufigsten Unternehmensprofile im deutschen Mittelstand.

Hinweis zur Einordnung: Dieser Artikel ist kein Produktvergleich einzelner Anbieter. Er vergleicht Hosting-Kategorien und -Modelle. Welcher konkrete Anbieter innerhalb einer Kategorie gewählt wird, hängt von spezifischen Anforderungen, Preisen und Vertragskonditionen ab – und erfordert eine eigene Due-Diligence-Prüfung.

1. Die fünf Hosting-Modelle: Was sie wirklich bedeuten

Bevor wir vergleichen, brauchen wir präzise Definitionen. In der Praxis werden die Begriffe oft unscharf verwendet, was Entscheidungen erschwert.

Modell 1: On-Premises

Beim On-Premises-Betrieb betreibt das Unternehmen die gesamte Infrastruktur selbst – Hardware, Netzwerk, Stromversorgung, Kühlsysteme – entweder im eigenen Gebäude oder in einem Colocation-Rechenzentrum, bei dem das Unternehmen die Hardware besitzt und dort aufstellt. Das Rechenzentrum stellt nur Strom, Netzwerk und physische Sicherheit bereit.

Was das für KI bedeutet: Das Unternehmen kauft oder least GPU-Server, konfiguriert sie selbst, betreibt die gesamte Software-Schicht (Betriebssystem, Treiber, Kubernetes, Serving-Frameworks) und ist für Wartung, Updates und Ausfallsicherheit vollständig selbst verantwortlich. Der Vorteil ist maximale Kontrolle – über Daten, Infrastruktur, Konfiguration und Kosten. Der Nachteil ist erheblicher interner Aufwand: GPU-Spezialisten, SRE-Know-how, Beschaffungszyklen und CAPEX-Investitionen in Hardware, die schnell veraltet.

Modell 2: Private Cloud (DE/EU)

Eine Private Cloud ist eine dedizierte, mandantenspezifische Cloud-Infrastruktur, die von einem Dienstleister betrieben wird – aber ausschließlich für ein Unternehmen. Es gibt keine gemeinsam genutzte Hardware mit anderen Kunden. Der Dienstleister übernimmt Betrieb, Wartung und Grundkonfiguration; das Unternehmen behält weitgehende Kontrolle über Software-Stack und Konfiguration.

Was das für KI bedeutet: Die Private Cloud bietet eine gute Balance zwischen Kontrolle und Managierbarkeit. GPU-Nodes können dediziert bereitgestellt werden. Der Anbieter kümmert sich um Hardware-Wartung und Grundbetrieb; das interne Team konzentriert sich auf KI-Plattform und Applikationsschicht. Typischerweise höhere Kosten als Shared Hosting, aber klare Datentrennung und einfachere Compliance-Nachweise.

Modell 3: Managed GPU-Hosting in Deutschland

Managed GPU-Hosting bezeichnet spezialisierte Dienste, bei denen ein Anbieter GPU-Infrastruktur in deutschen Rechenzentren als Managed Service bereitstellt. Im Gegensatz zur Private Cloud ist die Infrastruktur in der Regel geteilt (Multi-Tenancy), aber durch technische Maßnahmen (MIG-Partitionierung, Kubernetes-Namespaces, Netzwerk-Isolation) mandantensicher gestaltet. Der Anbieter übernimmt den vollständigen Infrastrukturbetrieb.

Was das für KI bedeutet: Für den Mittelstand ohne eigenes HPC-Betriebsteam ist Managed GPU-Hosting oft die pragmatischste Option: schneller Einstieg, kein CAPEX, geringer interner Betriebsaufwand, deutsche Rechtsgrundlage. Entscheidend ist die Qualität des Anbieters: Zertifizierungen (BSI C5, ISO 27001), Tenant-Isolation, Schlüsselmanagement und vertragliche Compliance-Garantien müssen sorgfältig geprüft werden.

Modell 4: Hyperscaler (AWS, Azure, GCP)

Die globalen Cloud-Anbieter bieten ein außergewöhnlich breites Portfolio an KI-Diensten – von verwalteten GPU-Instanzen über vollständige MLOps-Plattformen bis hin zu vortrainierten Modell-APIs. Die Stärken liegen in Skalierbarkeit, Geschwindigkeit und Ökosystem-Breite.

Was das für KI bedeutet: Hyperscaler sind hervorragend für schnelle Prototypen, globale Skalierung und Workloads, die keine besonderen Datenschutzanforderungen stellen. Die Herausforderungen liegen in der regulatorischen Komplexität (US CLOUD Act, Drittlandtransfer-Governance), in opaken Subunternehmerketten, in Vendor-Lock-in durch proprietäre APIs und Dienste sowie in teils schwer kalkulierbaren Kosten bei intensiver Nutzung.

Modell 5: Edge / On-Device

Edge-KI bezeichnet den Betrieb von KI-Modellen direkt auf Endgeräten oder dezentraler Infrastruktur – in der Produktion, im Fahrzeug, auf dem Kamerasystem oder auf spezialisierter Edge-Hardware am Standort. Keine oder minimale Cloud-Anbindung für die Inferenz selbst.

Was das für KI bedeutet: Edge-KI ist die richtige Wahl, wenn Echtzeit-Anforderungen (unter 10 Millisekunden Latenz), Offline-Betrieb oder Datenschutz am Verarbeitungsort zwingend erforderlich sind. Die Modelle müssen typischerweise komprimiert (Quantisierung, Pruning) und optimiert werden. Der operative Aufwand für Fleet-Management, Updates und Monitoring ist erheblich und wird häufig unterschätzt.

2. Der Vergleich: Sieben Kriterien, fünf Modelle

Die folgende Matrix vergleicht die fünf Hosting-Modelle entlang der Kriterien, die für mittelständische Unternehmen mit KI-Workloads und regulatorischen Anforderungen am stärksten ins Gewicht fallen. Die Bewertungen sind qualitative Einschätzungen – sie ersetzen keine individuelle Analyse, geben aber eine belastbare Orientierung.

Eine Lesehilfe zur Tabelle: 'Hoch' ist nicht automatisch besser als 'Gering' – das hängt vom Kriterium und der Unternehmenssituation ab. Hoher interner Betriebsaufwand ist bei einem Unternehmen mit starkem SRE-Team kein Problem; für einen Mittelständler ohne dediziertes IT-Operations-Team ist er ein Ausschlusskriterium. Die Tabelle ist ein Instrument, kein Urteil.

3. Wann welches Modell die richtige Wahl ist

Die Vergleichsmatrix liefert das Datenmaterial. Die eigentliche Entscheidung ergibt sich aus der Kombination von drei Faktoren: dem Datenprofil der KI-Workloads, den regulatorischen Anforderungen des Unternehmens und der internen Betriebsfähigkeit. Im Folgenden skizzieren wir die typischen Entscheidungsszenarien im deutschen Mittelstand.

Szenario A: Regulierte Branche, sensible Daten, kein HPC-Team

Unternehmensprofil: Produzierendes Unternehmen (500-2.000 Mitarbeiter), Gesundheitsdienstleister, Steuerberatung oder Finanzdienstleister. KI-Anwendungsfall: Internes RAG-System auf Vertragsdaten, KI-gestützter Kundensupport, automatisierte Dokumentenanalyse. Keine eigenen GPU-Spezialisten oder SRE-Expertise.

Empfehlung: Managed GPU-Hosting in Deutschland mit strengem Vertragsrahmen (BSI C5-Testat, vollständiger AVV, Customer Managed Keys). Time-to-Value ist gut, interner Aufwand bleibt handhabbar, Compliance-Anforderungen sind erfüllt. Hybridoption: Experimentierphase und nicht-sensible Workloads können auf Hyperscaler laufen; produktive Inferenz mit Unternehmensdaten gehört in die DE-Umgebung.

Szenario B: KRITIS-Unternehmen oder höchste Sensibilitätsanforderungen

Unternehmensprofil: Energieversorger, kritische Infrastruktur, Verteidigungszulieferer, Pharmaunternehmen mit besonders schutzbedürftigem IP. KI-Anwendungsfall: Integration von KI in betriebskritische Prozesse, Verarbeitung von Informationen mit höchster Sensibilität.

Empfehlung: On-Premises oder dedizierte Private Cloud in deutschen Rechenzentren mit BSI-zertifizierter Sicherheitsarchitektur, Georedundanz innerhalb Deutschlands und 24/7 Security Operations Center. Der höhere CAPEX und operative Aufwand ist in diesem Segment gerechtfertigt und typischerweise auch regulatorisch gefordert (KRITIS-Anforderungen, BSI-Grundschutz). Kein Hyperscaler für produktive Workloads mit hochsensiblen Daten.

Szenario C: Technologieunternehmen mit eigenem Entwicklungsteam

Unternehmensprofil: Software-Unternehmen, IT-Dienstleister oder technologiegetriebener Mittelständler mit eigenem Entwicklungs- und Betriebsteam. KI wird sowohl intern genutzt als auch in Produkte integriert. Schnelle Innovationszyklen sind wichtig.

Empfehlung: Hybridstrategie: Entwicklung und Experimentierphase auf Hyperscaler (Geschwindigkeit, Ökosystem-Breite), produktive Kundendaten-Workloads in Managed GPU-Hosting DE oder Private Cloud. Die Trennung zwischen 'Entwicklungsinfrastruktur' und 'Produktionsinfrastruktur mit Kundendaten' ist hier der Schlüsselbegriff. Exit-Strategie aus Hyperscaler-spezifischen APIs von Anfang an mitplanen (Container-basierte Deployments, offene Serving-Standards).

Szenario D: Globale Skalierung, nicht-sensitive Workloads

Unternehmensprofil: E-Commerce, internationale Plattform oder Unternehmen, dessen KI-Workloads primär auf öffentlichen Daten oder anonymisierten Daten basieren und keine besonderen regulatorischen Anforderungen stellen. Globale Nutzer, hohe Last-Peaks, Skalierbarkeit als primäres Kriterium.

Empfehlung: Hyperscaler sind hier die naheliegende Wahl – und das ist vollkommen legitim. Wenn keine personenbezogenen Daten in KI-Workloads einfließen, keine Branchenregulierung greift und maximale Skalierbarkeit entscheidend ist, spielen die Hyperscaler ihre Stärken aus. Achten Sie dennoch auf Exit-Fähigkeit und vermeiden Sie tiefen Lock-in in proprietäre KI-Managed-Services.

Szenario E: Echtzeit-Anforderungen in der Produktion

Unternehmensprofil: Fertigungsunternehmen mit Industrie-4.0-Anwendungen, Logistik mit automatisierter Fahrzeugerkennung, Qualitätskontrolle direkt an der Linie. Latenz unter 10 Millisekunden, Offline-Betrieb zwingend erforderlich.

Empfehlung: Edge-KI am Produktionsstandort für die zeitkritische Inferenz, kombiniert mit zentralem Managed GPU-Hosting DE für Training, Fine-Tuning und Modell-Management. Das Edge-Deployment muss gut geplant sein: Modell-Komprimierung (Quantisierung), Update-Prozesse, Monitoring und Sicherheitspatches für dezentrale Hardware sind operative Herausforderungen, die häufig unterschätzt werden.

4. Hybridstrategien: Warum 'entweder oder' oft die falsche Frage ist

In der Praxis ist die Entscheidung selten binär. Die meisten mittelständischen Unternehmen, die KI ernsthaft betreiben, kommen zu einer Hybridarchitektur – nicht als Kompromiss, sondern als bewusste Strategie, die verschiedene Anforderungen verschiedenen Infrastrukturen zuweist.

Drei Hybridmuster sind besonders verbreitet und haben sich als funktionsfähig erwiesen:

Hybridmuster 1: Daten in DE/EU, Compute elastisch

Sensible Daten, Vektorindizes und Audit-Logs verbleiben ausschließlich in deutschen oder europäischen Rechenzentren. Die KI-Modelle werden dort betrieben. Für kurzfristige Compute-Spitzen – etwa beim Training oder Fine-Tuning mit anonymisierten oder synthetischen Datensätzen – kann externe Infrastruktur zugezogen werden.

Was das erfordert: Klare Datenklassifizierung (welche Daten dürfen wohin?), verschlüsselte Transfer-Mechanismen, dokumentierte Governance und technische Durchsetzung der Klassifizierungsregeln. Das ist kein triviales Unterfangen, aber in vielen Organisationen realisierbar.

Hybridmuster 2: Experimentierphase extern, Produktion intern

PoCs, Experimente und Modell-Evaluierungen werden in flexiblen, günstigen Umgebungen durchgeführt – häufig auf Hyperscalern oder in spezialisierten KI-Entwicklungsumgebungen. Wenn ein Use Case produktionsreif ist und mit echten Unternehmensdaten arbeitet, erfolgt der Wechsel in die kontrollierte DE-Infrastruktur.

Was das erfordert: Von Anfang an portable Architekturen (Container-basierte Deployments, Standard-Serving-Interfaces wie KServe oder OpenAI-kompatible APIs), Trennung von Entwicklungs- und Produktionsdaten, klare Übergabekriterien für den Wechsel in die Produktionsumgebung.

Hybridmuster 3: Fine-Tuning mit öffentlichen Daten extern, Inferenz intern

Das Basis-Modell oder das Fine-Tuning auf öffentlich verfügbaren oder synthetischen Datensätzen kann extern erfolgen – der Compute-Aufwand ist dort oft günstiger und skalierbarer. Das fertig trainierte Modell wird dann in die interne Infrastruktur transferiert, wo die Inferenz mit echten Unternehmensdaten stattfindet.

Was das erfordert: Sorgfältige Prüfung, welche Daten für das Training genutzt werden (keine Lecks von produktiven Daten in externe Trainingsumgebungen), klare Modell-Governance und Provenance-Dokumentation (woher kommt das Modell, mit welchen Daten wurde es trainiert?), technische Validierung des Modells vor dem Produktions-Deployment.

Wichtige Erkenntnis: Hybridstrategien sind kein Widerspruch zum Anspruch auf Datensouveränität – sie sind oft die intelligenteste Art, diesen Anspruch mit wirtschaftlichen und technischen Realitäten in Einklang zu bringen. Entscheidend ist, dass die Regeln klar definiert, technisch durchgesetzt und dokumentiert sind.

5. Mindestanforderungen an 'Made in Germany': Was wirklich geprüft werden muss

'In Deutschland gehostet' ist eine notwendige, aber nicht hinreichende Bedingung. Viele Anbieter kommunizieren deutschen Rechenzentrumsstandort als Alleinstellungsmerkmal – aber ohne die darunter liegenden Eigenschaften zu prüfen, kauft man eine leere Behauptung.

Die folgende Prüfpflicht-Liste sollte bei jedem Anbieter-Screening eingesetzt werden:

Physische und rechtliche Verortung

• Physischer Rechenzentrumsstandort (Stadt, Bundesland) vertraglich garantiert – nicht nur 'Deutschland' als Region
• Betreibergesellschaft dem deutschen oder EU-Recht unterworfen – keine US-amerikanische oder chinesische Muttergesellschaft mit Drittstaaten-Rechtsbindung
• Vollständige und aktuelle Liste aller Sub-Auftragsverarbeiter mit deren Standorten
• Remote-Administratorzugriff aus Drittstaaten: vertraglich ausgeschlossen oder nur mit dokumentierter Genehmigung im Einzelfall

Zertifizierungen und Audits

• BSI C5-Testat (Cloud Computing Compliance Criteria Catalogue): Scope des Testats prüfen – welche Dienste sind eingeschlossen, welcher Zeitraum?
• ISO 27001-Zertifizierung: aktuell und durch akkreditierte Stelle ausgestellt
• Penetrationstest-Ergebnisse oder -zusammenfassungen einsehbar
• Kundenauditrecht vertraglich verankert: Recht auf eigene Prüfung oder Einsicht in Prüfergebnisse

Technische Souveränität

• Customer Managed Keys (CMK): Möglichkeit, eigene kryptographische Schlüssel in einem HSM oder KMS zu halten, das der Anbieter nicht kontrolliert
• Key Access Logging: jeder Schlüsselzugriff unveränderlich und tamper-evident protokolliert
• Mandanten-Isolation bei GPU-Hosting: MIG-Konfiguration oder dedizierte Nodes – kein reines Time-Slicing für sensitive Workloads
• RDMA-Netzwerk verfügbar für Training-Workloads (InfiniBand oder RoCE)
• S3-kompatibler Objektspeicher mit dokumentierter API-Kompatibilität und KMS-Integration

Exit und Portabilität

• Datenexport-Prozess und -fristen vertraglich definiert
• Löschbestätigung am Vertragsende (Daten, Modelle, Logs, Backups)
• Portabilität: Workloads als standard-konforme Container deploybar – kein proprietary Locking
• Exit-Kosten transparent und im Vertrag geregelt

Diese Prüfpflicht-Liste ist auch im Whitepaper 'KI-Hosting Made in Germany' als vollständige Checkliste enthalten – zusammen mit einem strukturierten Fragenkatalog für das Erstgespräch mit potenziellen Hosting-Anbietern.

6. Die Entscheidungsmatrix: Wo stehen Sie?

Abschließend fassen wir die Entscheidungslogik in einem praxistauglichen Scoring-Modell zusammen. Bewerten Sie Ihr Unternehmen für jedes der sieben Kriterien und addieren Sie die Punkte. Die Summe gibt eine erste Orientierung.

Auswertung der Punktzahl:

• 7-11 Punkte: Hyperscaler sind eine valide Option. Prüfe dennoch Drittlandtransfer-Fragen und plane Exit-Fähigkeit ein.
• 12-16 Punkte: Managed GPU-Hosting in Deutschland ist die empfohlene Kernstrategie. Hyperscaler können für nicht-sensitive Teilworkloads ergänzt werden.
• 17-21 Punkte: Private Cloud (DE) oder On-Premises sind die geeigneten Modelle. Managed Hosting als Ergänzung für Peaks möglich, aber mit strikter Governance.

Hinweis: Dieses Scoring ist eine Orientierungshilfe, kein Ersatz für eine individuelle Architektur- und Compliance-Beratung. Insbesondere bei hohen Punktzahlen und regulierten Branchen empfehlen wir eine strukturierte Bedarfsanalyse als nächsten Schritt.

7. Die häufigsten Fehler bei der Hosting-Entscheidung

Aus der Beratungspraxis kennen wir die Fallstricke, die die Hosting-Entscheidung nachträglich teuer machen. Die drei häufigsten:

Fehler 1: Die Infrastruktur zuerst, die Anforderungen danach

Der häufigste Fehler ist die umgekehrte Reihenfolge: Zuerst wird der bevorzugte Anbieter oder das bevorzugte Modell festgelegt – oft weil bereits ein Cloud-Vertrag besteht oder weil jemand im Team Erfahrung mit einer bestimmten Plattform hat –, und erst danach werden die Compliance- und Sicherheitsanforderungen auf die gewählte Infrastruktur gemappt. Das führt zu teuren Nachrüst-Maßnahmen, unnötig komplexen Architekturen oder – im schlimmsten Fall – zum Neuaufbau, wenn sich herausstellt, dass das gewählte Modell wesentliche Anforderungen strukturell nicht erfüllen kann.

Die richtige Reihenfolge: Erst Anforderungen (Daten, Regulatorik, Betriebsfähigkeit, Skalierung), dann Architektur, dann Anbieter.

Fehler 2: 'Made in Germany' als Label, nicht als Eigenschaftsprofil

Wie in Artikel 1 beschrieben: Der Standort des Rechenzentrums ist ein notwendiges, aber kein hinreichendes Kriterium für Datensouveränität. Wer sich mit 'Daten liegen in Frankfurt' zufriedengibt, ohne Subunternehmerketten, Schlüsselmanagement und Remote-Zugriffsrechte geprüft zu haben, hat eine leere Compliance-Behauptung eingekauft. Die Datenschutzkonferenz hat in ihrer Entschließung zu Confidential Cloud Computing (Juni 2025) ausdrücklich darauf hingewiesen, dass Marketingbegriffe kritisch geprüft werden müssen.

Fehler 3: Lock-in unterschätzt

Der Wechsel von einem Hyperscaler zu einem anderen Hosting-Modell ist technisch aufwändiger als oft angenommen – besonders wenn über Jahre proprietary Managed Services (z.B. AWS SageMaker, Azure ML Studio oder Google Vertex AI) genutzt wurden. Datentransfer-Kosten (Egress-Fees), Migrationsaufwand für Datenpipelines und das Neuaufsetzen von MLOps-Workflows sind erhebliche versteckte Kosten. Wer heute mit einer Open-Source-basierten, container-nativen Architektur beginnt (Kubernetes, KServe, MLflow, offene Serving-APIs), hält seine Optionen offen.

Fazit: Die Entscheidungslogik zählt mehr als das Modell

Am Ende dieses Artikels steht eine Erkenntnis, die weniger dramatisch klingt, als die Debatte manchmal suggeriert: Es gibt kein generell richtiges oder falsches Hosting-Modell für KI. Es gibt das richtige Modell für das jeweilige Unternehmen, den jeweiligen Workload und die jeweilige Situation – und das wird durch eine strukturierte Entscheidungslogik ermittelt, nicht durch Präferenzen oder Gewohnheiten.

Für die Mehrheit der mittelständischen Unternehmen in Deutschland, die KI mit echten Unternehmensdaten und in regulierten Kontexten betreiben wollen, ist Managed GPU-Hosting in Deutschland der funktional sinnvollste Ausgangspunkt: gute Compliance-Positionierung, handhabbare Betriebsanforderungen und ausreichende Flexibilität für die meisten Anwendungsfälle. Aber diese Empfehlung gilt nicht pauschal – sie gilt nach systematischer Prüfung der eigenen Anforderungen.

Im nächsten Artikel dieser Serie wenden wir uns einem Thema zu, das in der Hosting-Debatte oft zu kurz kommt: der KI-spezifischen Security-Landschaft. Prompt Injection, Data Poisoning, Model Extraction – das sind keine abstrakten Bedrohungen, sondern reale Angriffsvektoren, für die klassische IT-Security-Konzepte nicht ausreichen.

Die beste Hosting-Entscheidung ist die, die auf vollständiger Kenntnis der eigenen Anforderungen basiert – und nicht auf der Trägheit bestehender Verträge.

Nächster Artikel der Serie:

KI-Security ist nicht Cloud-Security: Die neuen Angriffsvektoren und wie man ihnen begegnet

Prompt Injection, Data Poisoning, Model Extraction – und was BSI IT-Grundschutz und C5 dazu sagen.