KI in der Cloud vs. On-Premise.

Wenn der Geschäftsführer eines mittelständischen Maschinenbauers seine IT-Leitung fragt, wo die geplante KI eigentlich laufen soll, kommen zwei mögliche Antworten. „In der Cloud, dann sind wir schnell“ — oder „On-Premise, dann sind die Daten sicher“. Beide Antworten sind nicht falsch, beide sind aber unvollständig. Die Realität ist differenzierter und hängt von einer Reihe konkreter Faktoren ab: welche Daten verarbeitet werden, welche Antwortzeiten gebraucht werden, welche Investitionsbereitschaft vorhanden ist, welches IT-Personal zur Verfügung steht. Cloud ist nicht automatisch unsicher, On-Premise ist nicht automatisch teurer, und in vielen Mittelständlern ist die ehrlichste Antwort heute ein Hybrid: bestimmte Anwendungen in der Cloud, bestimmte vor Ort. Dieser Artikel ordnet die Entscheidung nüchtern ein — mit Kostenmodellen, Sicherheitsaspekten und einer Matrix, die auch ein Nicht-IT-Geschäftsführer mitlesen kann.

Was Cloud und On-Premise im KI-Kontext eigentlich meinen.

Die Begriffe werden im Gespräch oft unscharf verwendet. Im KI-Kontext bedeutet Cloud: Das KI-Modell läuft auf der Infrastruktur eines externen Anbieters — typischerweise OpenAI, Anthropic, Google, Microsoft Azure, AWS, oder europäische Anbieter wie Aleph Alpha oder Mistral. Der Zugriff erfolgt über eine API oder eine Weboberfläche. Die eigene Hardware-Investition ist null, gezahlt wird pro Nutzung oder als Abonnement.

On-Premise bedeutet: Das Modell läuft auf eigener Hardware im eigenen Rechenzentrum oder einer eigenen, dedizierten Hosting-Umgebung. Die Daten verlassen das Unternehmen nie, die volle Kontrolle bleibt im Haus. Investiert wird in Server, GPUs, IT-Personal — laufende Kosten sind dann hauptsächlich Strom, Wartung und Personal.

Dazwischen gibt es relevante Mischformen. Private Cloud: Ein dedizierter Bereich bei einem Cloud-Anbieter, der vertraglich abgeschottet wird. Sovereign Cloud: Eine europäische oder deutsche Cloud-Lösung, oft mit speziellen rechtlichen Garantien. Hosted On-Premise: Eigene Modelle, aber auf gemieteter Hardware bei einem Rechenzentrumsbetreiber. Diese Varianten sind wichtig, weil sie die binäre Cloud-vs-On-Premise-Diskussion auflösen. Die richtige Frage ist meist nicht „Cloud oder nicht“, sondern „welche Variante in welcher Tiefe für welchen Anwendungsfall“.

Kostenrechnung — was die beiden Wege wirklich kosten.

Die Kostenfrage ist die am häufigsten missverstandene. Cloud wird gerne als „billig in der Anschaffung, teuer im Verbrauch“ beschrieben, On-Premise umgekehrt. Beides stimmt halb. Die ehrliche Rechnung sieht anders aus.

Cloud-API-Nutzung kostet bei größeren Sprachmodellen typischerweise zwischen 0,50 und 15 Euro pro Million Tokens. Ein durchschnittlicher Mitarbeiter, der KI intensiv im Arbeitsalltag nutzt, kommt auf etwa 50 bis 200 Euro pro Monat. Bei 100 Mitarbeitenden sind das zwischen 60.000 und 240.000 Euro im Jahr — ohne weitere Investitionen, ohne IT-Personal.

On-Premise startet mit einer Investition zwischen 80.000 und 400.000 Euro für ein produktiv nutzbares Setup mit GPU-Servern. Hinzu kommen jährliche Kosten für Strom (8.000 bis 25.000 Euro), Wartung (15.000 bis 40.000 Euro) und mindestens eine halbe IT-Personalstelle (40.000 bis 70.000 Euro). Gesamt: 63.000 bis 135.000 Euro jährlich nach der Initialinvestition.

Was diese Rechnung zeigt: Bei etwa 100 intensiv nutzenden Mitarbeitenden liegen die laufenden Kosten in vergleichbarer Größenordnung. Unter 50 Mitarbeitenden ist Cloud fast immer billiger. Über 300 Mitarbeitenden mit hoher KI-Nutzung kippt die Rechnung zugunsten von On-Premise. Dazwischen kommt es auf den konkreten Anwendungsfall an. Wer behauptet, das eine sei pauschal billiger als das andere, hat die Rechnung nicht gemacht.

Datenschutz — was wirklich auf dem Spiel steht.

Der häufigste Grund für On-Premise-Entscheidungen ist der Datenschutz. Die Sorge ist nachvollziehbar: Wenn Geschäftsgeheimnisse, Personalakten oder Vertragsentwürfe an einen US-Cloud-Anbieter geschickt werden, ist das ein Risiko. Aber: Es ist ein kalkulierbares Risiko, das je nach Vertrag und Anbieter unterschiedlich groß ausfällt.

Wer einen Enterprise-Vertrag mit Microsoft Azure OpenAI oder Anthropic abschließt, bekommt vertragliche Zusicherungen, die das Risiko substanziell reduzieren: keine Modelltrainings-Nutzung der eigenen Daten, EU-Datenresidenz, dokumentierte Sicherheitsmaßnahmen, Auftragsverarbeitung nach DSGVO. Das ist nicht gleichbedeutend mit On-Premise, aber es ist auch nicht das Risiko, das viele befürchten.

Auf der anderen Seite ist On-Premise nicht automatisch sicherer. Ein schlecht gewarteter eigener Server mit veralteten Betriebssystem-Patches ist gefährlicher als ein professionell betriebener Cloud-Dienst. Die Frage ist nicht, wo die Daten liegen, sondern wer sie wie schützt. In den meisten mittelständischen IT-Abteilungen ist die ehrliche Antwort: Ein gut konfigurierter Cloud-Dienst ist sicherer als ein schlecht betriebenes eigenes System. Die DSGVO verlangt angemessenen Schutz — nicht zwingend lokale Datenhaltung.

Latenz, Verfügbarkeit, Abhängigkeit.

Drei operative Aspekte unterscheiden die beiden Architekturen jenseits von Kosten und Datenschutz.

Latenz: Wenn KI in Echtzeit-Workflows eingebunden ist — etwa eine Spracherkennung im Kundengespräch oder eine sofortige Antwortgenerierung in einem Chat —, spielt die Antwortzeit eine Rolle. Cloud-APIs liefern typische Antwortzeiten von 200 Millisekunden bis 5 Sekunden. On-Premise-Systeme können je nach Hardware schneller sein, sind aber bei sehr großen Modellen oft langsamer, weil die Hardware nicht so leistungsfähig ist wie bei Hyperscalern.

Verfügbarkeit: Cloud-Anbieter garantieren typischerweise 99,9 % Verfügbarkeit. Das bedeutet im Jahr etwa 9 Stunden Ausfall. On-Premise-Systeme schwanken stärker — von 95 % bei kleinen Setups bis 99,99 % bei aufwendiger Redundanz. Wer einen geschäftskritischen Workflow auf KI legt, muss überlegen, welche Ausfallzeit akzeptabel ist.

Abhängigkeit: Wer Cloud nutzt, ist abhängig vom Anbieter — und vom Vertrag, von Preisanpassungen, von Produktentscheidungen des Hyperscalers. Wer On-Premise betreibt, ist von der eigenen IT abhängig — von Personal, von Hardware-Lieferungen, von Patch-Management. Beides ist Abhängigkeit, nur in unterschiedliche Richtungen. Wer beide Risiken minimieren will, baut Hybrid-Strukturen mit Wahlmöglichkeit.

Eine ehrliche Entscheidungsmatrix.

Welche Architektur für welchen Anwendungsfall — eine Praxis-Matrix:

Diese Matrix ist ein Ausgangspunkt, kein Dogma. In jedem Unternehmen gibt es Besonderheiten — branchenspezifische Regulierung, individuelle Risikoeinschätzung, vertragliche Verpflichtungen gegenüber Kunden. Die Matrix ersetzt diese Prüfung nicht, aber sie bietet eine erste Sortierung.

Die Hybrid-Architektur — was sich in der Praxis durchsetzt.

In Beratungsprojekten zeigt sich zunehmend: Reine Cloud- und reine On-Premise-Setups sind die Ausnahme. Die meisten mittelständischen Unternehmen landen bei einer Hybrid-Architektur. Das hat einen Grund.

Typische Aufteilung: 70 bis 80 Prozent der KI-Anwendungen laufen in einer professionell konfigurierten Cloud — Mailbearbeitung, Recherche, Übersetzungen, Kundenservice, Marketingtexte. Diese Anwendungen profitieren von Cloud-Vorteilen (geringe Initialinvestition, schnelle Anpassung an neue Modelle, einfache Skalierung) und ihre Datensensitivität ist beherrschbar.

Die übrigen 20 bis 30 Prozent — typischerweise alles, was wirklich vertraulich ist oder regulatorisch sensibel — laufen On-Premise oder auf einer Sovereign Cloud. Das sind oft Anwendungen rund um Forschung, Entwicklung, Personal, Strategie, oder branchenspezifische sensible Daten (z. B. Patientendaten im Gesundheitsbereich).

Diese Aufteilung hat einen weiteren Vorteil: Sie reduziert die Abhängigkeit von einem Anbieter, ohne in die Komplexität einer vollständigen Eigenlösung zu kippen. Der zusätzliche Architekturaufwand ist überschaubar — wenn er von Anfang an mitgedacht wird. Wer dagegen erst rein Cloud aufbaut und später die sensiblen Workloads herausziehen will, hat höhere Migrations- und Architekturkosten.

Grenzen, die nicht verschwinden werden.

Drei Realitäten bleiben, gleich welche Architektur gewählt wird. Erstens: Personalfrage. On-Premise erfordert IT-Personal mit GPU-Erfahrung — eine Ressource, die im Mittelstand schwer zu finden und zu halten ist. Wer ein On-Premise-Setup plant, ohne dieses Personal aufzubauen oder einzukaufen, plant für die Schublade. Cloud entlastet diese Frage nicht vollständig — auch Cloud-Architekturen brauchen kompetente Betreiber —, aber sie verlangt weniger Spezialwissen.

Zweitens: Modell-Aktualität. Cloud-Anbieter aktualisieren ihre Modelle alle paar Monate — neue Versionen, neue Fähigkeiten. On-Premise-Setups hinken hier strukturell hinterher: Ein lokales Modell, das vor 18 Monaten installiert wurde, ist heute oft messbar schwächer als ein aktuelles Cloud-Modell. Wer dauerhaft On-Premise fährt, muss eine Update-Strategie haben — und Kapazität, sie umzusetzen.

Drittens: Vendor-Lock-in. Cloud-Architekturen, die spezifische Features eines Anbieters nutzen (etwa proprietäre Funktionen von OpenAI oder Anthropic), erzeugen Abhängigkeit. Wer das vermeiden will, baut auf Standardisierung — was Cloud-spezifische Funktionen kostet. Auch hier gibt es kein freies Mittagessen.

Was Sie als Geschäftsführung konkret prüfen sollten.

Drei Schritte, die in der Praxis tragen:

1. Anwendungsfälle nach Datensensitivität sortieren. Listen Sie die geplanten KI-Anwendungen auf und ordnen Sie jede einer Sensitivitätsstufe zu. Diese Sortierung ist die Vorentscheidung für die Architektur.
2. Eigene IT-Kapazität ehrlich einschätzen. Hat Ihre IT-Abteilung die Ressourcen und das Know-how, ein On-Premise-KI-Setup zu betreiben? Wenn nicht: Welcher Aufbau wäre realistisch — und welche Anwendungen sind so wichtig, dass dieser Aufbau gerechtfertigt ist?
3. Hybrid-Architektur als Ausgangsannahme. Beginnen Sie nicht mit der Frage „Cloud oder On-Premise“, sondern „Welche Anwendungen wohin?“. Diese Perspektive führt fast immer zu pragmatischeren Entscheidungen.

Die Architekturentscheidung ist nicht endgültig. Sie können beginnen mit Cloud-Lösungen, später sensible Workloads herausziehen, in einem dritten Schritt eine eigene Sovereign-Cloud nutzen. Wichtig ist, die Entwicklung von Anfang an mitzudenken — nicht jede heute eingegangene Verpflichtung lässt sich später kostengünstig revidieren. Wer die Datenschutzfrage bei selbst gehosteten Modellen sauber durchgearbeitet hat, hat eine fundierte Basis für die nächsten Schritte.

Sie stehen vor der Architekturentscheidung und wollen die richtige Balance zwischen Cloud und On-Premise finden? Unverbindlich anfragen — wir gehen Ihre konkreten Anwendungsfälle, Datensensitivitäten und IT-Kapazitäten gemeinsam durch.