Was „On-Premise“ heute wirklich bedeutet

„On-Premise“ meinte früher einen Server im eigenen Keller. Für große Sprachmodelle gibt es heute mehr Optionen, und die meisten Missverständnisse entstehen, weil man sie vermengt. Zu unterscheiden sind zwei Grundformen und ein Mittelweg zwischen ihnen.

Die erste ist die Cloud-KI-API: Sie schicken Ihren Text an einen Anbieter wie OpenAI, Anthropic oder Google, und dessen Modell schickt eine Antwort zurück. Der Anbieter betreibt es auf seiner Infrastruktur, bei einem US-Anbieter auch dann unter US-Recht, wenn das Rechenzentrum in der EU steht. Die meisten meinen das heute mit „KI nutzen“. Diese Option leistet am meisten und macht den Einstieg mit Abstand am leichtesten, aber Ihre Daten verlassen dafür Ihren Kontrollbereich.

Die zweite ist ein selbst gehostetes offenes Modell: ein Open-Weight-Modell wie Llama, Mistral oder Qwen, das auf GPUs läuft, über die Sie bestimmen. Die GPUs stehen als Rack im eigenen Haus, oder Sie mieten sie dediziert in einem deutschen oder EU-Rechenzentrum unter deutschem Vertrag. Modellgewichte und Daten verlassen nie eine Infrastruktur, die Sie kontrollieren. Offene Modelle haben in den vergangenen zwei Jahren einen großen Teil des Qualitätsrückstands aufgeholt, bei den allerschwersten Denkaufgaben allerdings nicht den ganzen.

Der Gegensatz zwischen „Ihrem Haus“ und „irgendjemandes Cloud“ zählt weniger als die Frage, wer die Maschine kontrolliert, auf der Ihre Daten verarbeitet werden, und unter welchem Rechtsregime. Eine dedizierte GPU in einem Frankfurter Rechenzentrum unter einem deutschen Verarbeitungsvertrag verschafft Ihnen die meisten Souveränitätsvorteile eines Kellerservers und erspart Ihnen die Investition und den Ärger mit der Hardware. In der Praxis heißt „On-Premise-fähig“ meist „läuft auf Infrastruktur, die Sie oder ein vertrauenswürdiger deutscher Anbieter vollständig kontrollieren“, und nicht zwingend auf Hardware, die Ihnen gehört. Der Hardware-Leitfaden beschreibt, was der Betrieb eigener Modelle technisch verlangt.

Die Frage lautet nicht abstrakt „Cloud oder On-Premise?“, sondern: Wer darf bei diesen Daten und diesem Anwendungsfall kontrollieren, wohin sie gehen, und was kostet es an Leistung und Geld, diese Kontrolle im Haus zu behalten?

Warum Datensouveränität für den Mittelstand zählt

Zwei Gründe treiben ein deutsches mittelständisches Unternehmen zur Datensouveränität, und weil sie verschiedene Probleme betreffen, führen sie zu unterschiedlichen Antworten.

Die DSGVO und die Kette der Auftragsverarbeiter

Sobald Ihr Prompt personenbezogene Daten enthält, etwa eine Kunden-E-Mail, eine Personalakte oder einen Patientendatensatz, wird der Anbieter, der ihn verarbeitet, zum Auftragsverarbeiter im Sinne der DSGVO. Sie brauchen dann einen Auftragsverarbeitungsvertrag, eine Rechtsgrundlage und bei einem US-Anbieter einen gültigen Transfermechanismus. All das ist machbar, und ich habe beschrieben, wie man es in der Praxis richtig macht. Jeder Anbieter, den Sie der Kette hinzufügen, bringt aber einen weiteren Vertrag und eine weitere Liste von Unterauftragsverarbeitern mit, die Sie prüfen, dokumentieren und einem Datenschutzbeauftragten oder Prüfer erklären müssen. Selbsthosting lässt diese Kette zusammenfallen, weil Sie die Daten auf einer Infrastruktur verarbeiten, die Sie bereits kontrollieren, unter Verträgen, die Sie bereits haben. Das macht Sie nicht automatisch „konform“, und die Arbeit bleibt Ihnen, aber es entfernt sehr viele bewegliche Teile, an denen Compliance unbemerkt bricht.

Geschäftsgeheimnisse und das GeschGehG

Für viele Mittelständler wiegt ein anderer Grund schwerer als die DSGVO, und er betrifft keine personenbezogenen Daten. Er heißt Geschäftsgeheimnis und umfasst die CAD-Dateien, die Prozessparameter, das Preismodell, die Lieferantenkonditionen und den Quellcode, also die zwanzig Jahre Know-how, die das Geschäft ausmachen. Das deutsche Geschäftsgeheimnisgesetz schützt nur Informationen, für die Sie „angemessene Geheimhaltungsmaßnahmen“ getroffen haben. Wer sein wertvollstes geistiges Eigentum durch eine fremde API leitet, kann diesen Schutz untergraben, und manche regulierten oder rüstungsnahen Lieferketten verbieten es vertraglich. Für einen Maschinenbauer, dessen Vorsprung in erarbeitetem Prozesswissen liegt, ist „wohin gehen die Daten?“ eine Existenzfrage und kein Compliance-Häkchen. Dasselbe gilt für die Patientendaten einer Klinik oder die Aktennotizen einer Kanzlei, denn manche Informationen gehören nicht Ihnen, und Sie dürfen sie nirgendwohin schicken, so bequem die API auch ist.

Die Kompromisse

On-Premise wird dadurch nicht automatisch zur richtigen Antwort, denn Kontrolle kostet Geld, Leistung und Aufwand.

Selbst gehostet Eigene / deutsche GPUs, offene Modelle, volle Kontrolle EU-gehostet / Hybrid Deutsches Rechenzentrum oder nach Sensibilität Cloud-KI-API Spitzenmodelle, meist US-Anbieter Mehr Kontrolle & Souveränität Mehr Leistung, weniger Aufwand
Die Entscheidung verläuft entlang eines Spektrums, und die meisten Unternehmen landen in der Mitte statt an einem der Extreme.

Der Leistungsabstand. Die Spitzenmodelle der APIs liegen bei den schwersten Denk-, Programmier- und Long-Context-Aufgaben noch vorn. Offene Modelle reichen für die meisten geschäftlichen Anwendungsfälle wie Entwürfe, Extraktion, Klassifikation und retrieval-gestützte Antworten aus. Braucht Ihr Anwendungsfall aber das beste Modell am Markt, bezahlen Sie mit Treffergenauigkeit dafür, dass die Daten im Haus bleiben.

Die Form der Kosten. Cloud ist Betriebsaufwand: Sie zahlen pro Token, starten günstig, und die Rechnung wächst gleichmäßig mit der Nutzung. Selbsthosting ist Investition oder reservierte GPU-Miete und damit teuer im Leerlauf und günstig bei hohem Volumen. Eine GPU, die die meiste Zeit leer läuft, kostet pro Anfrage ein Vielfaches der Cloud. Der Break-even hängt fast vollständig davon ab, wie stark und wie planbar Sie sie nutzen.

Der Betriebsaufwand. Jemand muss das System betreiben, also Patches einspielen, Modelle aktualisieren, überwachen, GPU-Ausfälle beheben und unter Last skalieren. Eine Cloud-API verbirgt all das hinter einer URL, beim Selbsthosting übernehmen Sie es. Kein Posten wird häufiger unterschätzt, und er erklärt zu einem großen Teil, warum der Weg von der funktionierenden Demo zum verlässlichen Produktivsystem die schwerere Hälfte jedes Projekts ist.

Der Vorteil, den Sie kaufen: Kontrolle und Auditierbarkeit. Auf eigener Infrastruktur wissen Sie, wohin jedes Byte gegangen ist. Sie können alles protokollieren und nachweisen, dass Daten das Land nie verlassen haben, und kein Anbieter ändert oder kündigt stillschweigend das Modell ab, auf dem Ihr Prozess beruht. In einer regulierten Prüfung ist dieser Nachweis viel wert, und eine Black-Box-API liefert ihn nicht.

Der Handel im Überblick. Cloud gibt Ihnen die beste Leistung bei geringstem Aufwand und geringster Kontrolle. Selbsthosting gibt Ihnen die meiste Kontrolle und kostet dafür Leistung, Kapital und laufenden Betrieb. Keines ist abstrakt „sicherer“, denn die richtige Antwort hängt davon ab, was Ihre Daten wert sind, wenn Sie die Kontrolle darüber verlieren.

Was passt, und wann

Die Entscheidung ist selten ein Entweder-oder, und tragfähige Architekturen liegen meist in der Mitte.

Der Mittelweg: EU-gehostet und hybrid

Zwischen den beiden Extremen liegen die Optionen, die die meisten Mittelständler wollen. Bei EU-gehosteter verwalteter Inferenz betreibt ein Anbieter ein offenes Modell für Sie in einem deutschen oder EU-Rechenzentrum unter einem ordentlichen Auftragsverarbeitungsvertrag, sodass Sie die meiste Souveränität bekommen, ohne die Hardware zu besitzen oder die Rufbereitschaft zu stellen. Eine hybride Architektur steuert nach Sensibilität: Nicht sensibler, öffentlicher Text geht für maximale Qualität an eine Spitzen-API, während ein selbst gehostetes Modell alles verarbeitet, was personenbezogene Daten oder Geschäftsgeheimnisse enthält. Ein verwandtes Muster schwärzt oder tokenisiert die sensiblen Teile, bevor etwas eine externe API erreicht. Diese Optionen folgen daraus, dass nicht alle Ihre Daten dasselbe Risiko tragen.

Mit diesen Optionen lässt sich die Entscheidung meist treffen. Tendieren Sie zu selbst gehostet, wenn die Daten sensibel sind, also regulierte personenbezogene Daten, Kern-IP oder ein vertragliches Verbot externer Verarbeitung vorliegen, wenn das Volumen hoch genug ist, um die Hardware zu amortisieren, und wenn die Qualität offener Modelle für Ihre Aufgabe ausreicht. Bleiben Sie bei einer Cloud-API, wenn die Daten nicht sensibel sind, Sie die stärkstmögliche Leistung brauchen, die Nutzung sprunghaft oder gering ist und Sie den Betriebsaufwand nicht tragen wollen. Gehen Sie hybrid, wenn ein Teil Ihrer Arbeitslasten sensibel ist und ein Teil nicht, und das trifft auf die meisten Unternehmen zu.

Die Wahl ist eine Geschäfts- und Risikoentscheidung, auch wenn sie technisch aussieht. Fragen Sie deshalb nicht abstrakt, was sicherer ist, sondern was diese Daten Sie kosten, wenn sie abfließen oder Sie die Kontrolle verlieren, und was Ihnen der Leistungs- und Betriebsaufschlag kauft, mit dem Sie sie im Haus halten. Ihre Geschäftsführung sollte diese Frage verantworten und nicht nur Ihre IT.

Aus dem eigenen Bau: Die Entscheidung umkehrbar halten

In unseren eigenen Systemen ist der Betriebsweg eine Einstellung. TippelPi, unser Wissenssystem, läuft auf einem Raspberry Pi mit Ollama und unverändert auf einem GPU-Server mit vLLM. Beim Start prüft die Anwendung, ob ein vLLM-Server antwortet, und nimmt sonst Ollama. Die Prüfschicht für Sentinel-Regeln wechselt mit zwei Umgebungsvariablen zwischen Cloud-Dienst und lokalem Modell. Wer so baut, kann mit der Cloud beginnen und später ins eigene Netz umziehen, ohne die Anwendung neu zu schreiben.

Für die Cloud-Variante haben wir außerdem gemessen, was das Netz verlässt. Ein vollständiger Lauf der Prüfschicht besteht aus zwei HTTP-Aufrufen mit zusammen 29.032 Bytes: dem Anforderungstext und den Spaltennamen. Logdaten, IP-Adressen und Ereigniszeitstempel sind nicht darunter. Eine solche Messung beantwortet die Frage nach dem Datenabfluss genauer als eine Architekturskizze, und sie lässt sich vor Ort wiederholen. Das Messprotokoll steht auf der Seite zur Prüfschicht.