KI On-Premise oder Cloud: Welches Betriebsmodell passt zu Ihnen?

Die Frage „KI On-Premise oder Cloud" fällt in fast jedem Projektstart, und dahinter stehen drei Sorgen: Datenzugriff, Betriebskosten über Jahre und Tempo bis zur Arbeitsfähigkeit. Die Antwort hängt weniger am Bauchgefühl als an vier nüchternen Kriterien: Datenklassen, regulatorische Anforderungen, vorhandene Betriebskapazität und die Frage, welche Modelle Sie überhaupt einsetzen wollen.

Dieser Artikel sortiert die Betriebsmodelle, die 2026 real verfügbar sind, trennt den Betrieb der Plattform vom Betrieb der Modelle und zeigt, welche Kostenarten in welchem Modell tatsächlich anfallen. Ohne Pauschalzahlen, die in Ihrem Haus ohnehin anders aussehen.

Für eine KI-Plattform gibt es fünf Betriebsmodelle: geteiltes SaaS, eine dedizierte Instanz beim Anbieter, eine Private Cloud, den eigenen Cloud-Tenant und das eigene Rechenzentrum. Sie unterscheiden sich darin, wem die Umgebung gehört und wer sie betreibt.

Ein geteiltes SaaS-Angebot ist der schnellste, aber unflexibelste Weg. Eine dedizierte Instanz bedeutet, dass Ihr Unternehmen eine eigene Umgebung samt eigener Datenbank bekommt, die der Anbieter betreibt. Private Cloud und eigener Tenant verschieben den Betriebsort in Ihre Verantwortungssphäre. Der Betrieb im eigenen Rechenzentrum gibt die volle Kontrolle und verlangt die volle Betriebsleistung.

Für die meisten Mittelständler ist die dedizierte Instanz der pragmatische Mittelweg: eigene Umgebung, eigene Zugangskontrolle, eigene Datenbank, aber kein eigener Betriebsaufwand. Wer bereits einen Cloud-Standard im Haus hat, verlegt die Instanz in den eigenen Tenant und bleibt damit in den eigenen Sicherheits- und Netzwerkregeln.

Plattformbetrieb und Modellbetrieb sind zwei getrennte Entscheidungen. Selbst wenn die Plattform im eigenen Tenant läuft, rechnet das Modell meist woanders, denn die Gewichte der proprietären Spitzenmodelle von OpenAI, Anthropic oder Google stehen nicht zum Download bereit.

Damit ergeben sich drei Wege, die sich kombinieren lassen:

• Modell-API in einer EU-Region. Die großen Cloud-Anbieter steuern den Verarbeitungsort über den Bereitstellungstyp. Bei Microsoft Foundry beispielsweise verarbeiten „Data Zone"-Bereitstellungen Anfragen ausschließlich innerhalb der EU-Datengrenze, globale Bereitstellungen dagegen in jeder Region. Wer EU-Verarbeitung braucht, muss den Bereitstellungstyp aktiv wählen.
• Offene Modelle bei einem europäischen Anbieter. IONOS, OVHcloud oder STACKIT betreiben offene Modelle als API in europäischen Rechenzentren, mit Zusagen zur Datenspeicherung. STACKIT etwa nennt dafür die Region Germany South und sagt zu, dass Daten und Abfragen weder gespeichert noch zum Training verwendet werden.
• Offene Modelle selbst betreiben. Auf eigener GPU-Infrastruktur, im eigenen Tenant oder im eigenen Rechenzentrum. Das ist der einzige Weg zu echter Air-Gap-Fähigkeit und gleichzeitig der aufwendigste. Welche offenen Modelle dafür lizenzrechtlich infrage kommen, steht im Leitfaden zu Open-Source-LLMs und Self-Hosting.

Praktische Konsequenz: Die Frage „läuft alles bei uns?" beantwortet sich nur dann mit Ja, wenn Sie auch die Modelle selbst betreiben. Alles andere ist eine Kombination aus eigenem Plattformbetrieb und fremder Modellverarbeitung, die vertraglich und technisch sauber geregelt sein will.

Was ein KI-Betrieb kostet, hängt vor allem von Nutzerzahl, Token-Verbrauch und vorhandener Infrastruktur ab, eine seriöse Pauschalzahl gibt es deshalb nicht. Vergleichbar sind die Kostenarten, und an ihnen zeigt sich, wo der eigene Betrieb teurer wird als erwartet.

Die beiden Posten, die in Eigenbetriebs-Rechnungen am häufigsten fehlen, sind Personal und Leerlauf. Eine GPU-Instanz kostet auch dann, wenn niemand fragt, und ein produktiver Modellbetrieb braucht dauerhaft Menschen, die Aktualisierungen prüfen, Qualität messen und Störungen beheben. Eine vollständige Kostenaufstellung inklusive Einführung, Schulung und Betrieb finden Sie im Artikel zu den Gesamtkosten einer KI-Plattform.

Der eigene Betrieb lohnt sich, wenn eine Anforderung ihn erzwingt, nicht weil er günstiger wäre. Drei Konstellationen rechtfertigen ihn regelmäßig:

• Abgeschottete Umgebungen. Produktionsnetze, Geheimschutz oder Verteidigungsprojekte, in denen kein Verkehr nach außen zulässig ist.
• Besonders schutzwürdiges geistiges Eigentum. Konstruktionsdaten, Rezepturen oder Quelltexte aus Auftragsentwicklung, bei denen die Risikoabwägung gegen jede externe Verarbeitung ausfällt.
• Sehr hohe, gleichmäßige Last. Wenn dauerhaft große Mengen an Anfragen anfallen, kann eigene Inferenz wirtschaftlich werden. Der Preisverfall bei der Inferenz spricht allerdings gegen frühe Festlegungen: Die a16z-Analyse „LLMflation" misst für vergleichbare Modellqualität einen Preisrückgang um etwa den Faktor zehn pro Jahr.

Was in stark regulierten Branchen zusätzlich zu beachten ist, etwa Auslagerungsanzeigen und Prüfrechte, behandelt der Artikel zu KI im Finanzwesen.

Gegen den Eigenbetrieb spricht selten die Technik, sondern fast immer die Dauerverpflichtung: Modellwechsel, Sicherheitsupdates, Qualitätsmessung und Bereitschaft enden nie. Wer diese Kapazität nicht fest einplant, betreibt nach einem Jahr ein veraltetes Modell auf teurer Hardware.

Sensible Daten bleiben im Haus, wenn die Quellsysteme lokal bleiben und nur der für eine Antwort nötige Ausschnitt an das Modell geht. Welche Daten das sind, steuern Berechtigungen, Filter und Protokollierung.

Der verbreitete Hybrid-Gedanke „Plattform in der Cloud, Daten bleiben lokal" funktioniert also, aber anders, als es oft verkauft wird: Aggregiert oder anonymisiert ist der übergebene Ausschnitt nur, wenn die Anbindung genau so gebaut wurde.

Was den Unterschied macht, sind vier Stellschrauben:

1. Zugriffsrechte an der Quelle. Die Anbindung sieht nur, was das technische Konto sehen darf, und idealerweise nur, was die fragende Person sehen darf.
2. Filter und Feldauswahl. Nicht die ganze Tabelle, sondern die benötigten Felder. Personenbezug wird entfernt, wo er für die Aufgabe nicht gebraucht wird.
3. Protokollierung. Nachvollziehbar, welche Abfrage welche Daten berührt hat, mit Aufbewahrung nach Ihren Vorgaben.
4. Modellfreigabe je Team. Für den sensiblen Bereich nur Modelle mit geprüfter Verarbeitung, für den Rest die volle Auswahl.

Technisch führt der Weg über Konnektoren zu ERP, Fileserver, Ticket-System oder älteren Datenbanken. Wie so eine Anbindung in gewachsenen Landschaften aussieht, beschreibt der Leitfaden zur Integration bestehender Systeme. Welche rechtlichen Anforderungen daran hängen, steht im Artikel zu KI und DSGVO.

Die Betriebsentscheidung folgt aus Datenklassen, Regulierung und Betriebskapazität, nicht aus Grundsatzpositionen. Diese fünf Schritte führen zu einer begründeten Wahl.

Plotdesk verbindet eine KI-Plattform mit einem Umsetzungsteam für den Mittelstand und betreibt jede Kundeninstanz dediziert: als Plotdesk Cloud, von Plotdesk betrieben und in der EU gehostet, als Private Cloud oder direkt im eigenen Tenant, zum Beispiel in Azure. Die Betriebsentscheidung ist damit keine Produktentscheidung mehr, sondern eine Frage der Anforderungen.

Lokale Systeme bleiben, wo sie sind. ERP, Fileserver, Ticket-System oder alte Datenbanken werden über Plotdesk Connect angebunden, statt Daten in eine neue Umgebung zu kopieren. Für die Modellseite stehen mehr als 100 Modellvarianten aus zehn Provider-Typen zur Verfügung, steuerbar pro Team, Gruppe und Anwendung, einschließlich offener Modelle über EU-Inferenz.

Governance bringt die Plattform mit: Anmeldung über Single Sign-On, Rollen und mehr als 40 Berechtigungen, verschlüsselte Zugangsdaten, Audit-Logs sowie Nutzungs- und Kostenanalysen je Bereich. Vertraglich gehören ein DSGVO-konformer Auftragsverarbeitungsvertrag und EU-Datenresidenz dazu.

Der Weg dorthin läuft in vier Schritten: KI-Potenzialanalyse, Proof of Value, produktive Lösung, systematischer Ausbau. Das Betriebsmodell wird dabei früh festgelegt, weil es Anbindung, Berechtigungen und Modellfreigaben bestimmt.

Die ehrliche Antwort auf „On-Premise oder Cloud" lautet für die meisten Mittelständler: eine dedizierte Instanz in der EU oder im eigenen Tenant, kombiniert mit Modellen, die je Team freigegeben werden, und lokalen Systemen, die angebunden statt kopiert werden. Der Betrieb im eigenen Rechenzentrum bleibt die richtige Antwort für abgeschottete Umgebungen und besonders schutzwürdige Daten.

Wer die Entscheidung entlang von Datenklassen, Regulierung, Betriebskapazität und Portabilität trifft, kommt zu einem Setup, das auch in drei Jahren noch trägt. Wer sie entlang von Grundsatzpositionen trifft, zahlt entweder mit Tempo oder mit Risiko.