On-Premise vs. Cloud-KI

Was „On-Premise“ heute wirklich bedeutet

„On-Premise“ meinte früher einen Server, der im eigenen Keller brummt. Für große Sprachmodelle ist das Bild heute vielschichtiger, und das Vermengen der Optionen ist die Quelle der meisten Missverständnisse. Es gibt im Grunde drei Aufstellungen, und es hilft, sie zu benennen, bevor man darüber streitet, welche richtig ist.

Die erste ist die Cloud-KI-API: Sie schicken Ihren Text an einen Anbieter wie OpenAI, Anthropic oder Google, und dessen Modell — betrieben auf dessen Infrastruktur, meist in den USA — schickt eine Antwort zurück. Das ist es, was die meisten heute mit „KI nutzen“ meinen. Es ist die leistungsfähigste Option und mit Abstand die einfachste, um loszulegen — und dafür verlassen Ihre Daten 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. Das kann ein Rack im eigenen Haus sein oder — genauso wichtig — dedizierte GPUs, die Sie in einem deutschen oder EU-Rechenzentrum unter deutschem Vertrag mieten. Die Modellgewichte und Ihre Daten verlassen nie eine Infrastruktur, die Sie kontrollieren. Die offenen Modelle haben in den vergangenen zwei Jahren einen bemerkenswerten Teil des Qualitätsrückstands aufgeholt — wenn auch nicht ganz bei den allerschwersten Denkaufgaben.

Die Unterscheidung, auf die es wirklich ankommt, ist nicht „Ihr Haus“ gegen „irgendjemandes Cloud“. Es ist 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 — ohne die Investition oder den Hardware-Ärger. 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“ — nicht zwingend Blech, das Ihnen gehört. Wenn Sie den tieferen technischen Blick darauf möchten, was der Betrieb eigener Modelle tatsächlich verlangt, geht der Hardware-Leitfaden das durch.

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

Nichts davon ist Mode oder Fahnenschwenken. Für ein deutsches mittelständisches Unternehmen gibt es zwei konkrete, harte Treiber, und sie sind nicht dasselbe Problem — was wichtig ist, denn sie drängen zu unterschiedlichen Antworten.

Die DSGVO und die Kette der Auftragsverarbeiter

In dem Moment, in dem Ihr Prompt personenbezogene Daten enthält — eine Kunden-E-Mail, eine Personalakte, einen Patientendatensatz —, wird der Anbieter, der ihn verarbeitet, zum Auftragsverarbeiter im Sinne der DSGVO. Das heißt: Sie brauchen einen Auftragsverarbeitungsvertrag, eine Rechtsgrundlage und, bei einem US-Anbieter, einen gültigen Transfermechanismus. All das ist machbar, und ich habe darüber geschrieben, wie man es in der Praxis richtig macht. Aber jeder Anbieter, den Sie der Kette hinzufügen, ist ein weiterer Vertrag, eine weitere Unterauftragsverarbeiter-Liste, eine weitere Sache, die zu prüfen, zu dokumentieren und einem Datenschutzbeauftragten oder Prüfer zu erklären ist. Selbsthosting lässt die Kette in sich zusammenfallen: Die Daten werden auf einer Infrastruktur verarbeitet, die Sie bereits kontrollieren, unter Verträgen, die Sie bereits haben. Das ist nicht automatisch „konform“ — die Arbeit müssen Sie trotzdem machen —, aber es entfernt sehr viele bewegliche Teile, und an den beweglichen Teilen bricht Compliance leise.

Geschäftsgeheimnisse und das GeschGehG

Die DSGVO bekommt die Schlagzeilen, aber für viele Mittelständler hat der größere Treiber nichts mit personenbezogenen Daten zu tun. Es ist das Geschäftsgeheimnis: die CAD-Dateien, die Prozessparameter, das Preismodell, die Lieferantenkonditionen, der Quellcode — die zwanzig Jahre Know-how, die das eigentliche Geschäft sind. Das deutsche Geschäftsgeheimnisgesetz schützt nur Informationen, für die Sie „angemessene Geheimhaltungsmaßnahmen“ getroffen haben. Das Durchleiten Ihres wertvollsten geistigen Eigentums durch eine fremde API kann diesen Schutz untergraben — und in manchen regulierten oder rüstungsnahen Lieferketten ist es schlicht vertraglich verboten. Für einen Maschinenbauer, dessen Vorsprung hart erarbeitetes Prozesswissen ist, ist „wohin gehen die Daten?“ eine existenzielle Frage, kein Compliance-Häkchen. Dieselbe Logik gilt für die Patientendaten einer Klinik oder die Aktennotizen einer Kanzlei: Manche Informationen sind nicht Ihre, um sie irgendwohin zu schicken — so bequem die API auch sein mag.

Die ehrlichen Kompromisse

Nichts davon macht On-Premise automatisch zur richtigen Antwort. Kontrolle ist nicht umsonst — sie kostet Geld, Leistung und Aufwand, und wer Ihnen etwas anderes erzählt, verkauft Ihnen etwas. Hier ist der Handel offen ausgelegt.

Der Leistungsabstand. Die Spitzenmodelle der APIs liegen bei den schwersten Denk-, Programmier- und Long-Context-Aufgaben noch vorn. Offene Modelle sind wirklich hervorragend und für die meisten geschäftlichen Anwendungsfälle — Entwürfe, Extraktion, Klassifikation, retrieval-gestützte Antworten — mehr als gut genug. Aber wenn Ihr Anwendungsfall tatsächlich das allerbeste Modell am Markt braucht, zahlen Sie das Behalten der Daten im Haus in der Währung der Treffergenauigkeit.

Die Form der Kosten. Cloud ist Betriebsaufwand: Sie zahlen pro Token, der Start ist günstig, und die Rechnung skaliert glatt mit der Nutzung. Selbsthosting ist Investition oder reservierte GPU-Miete: teuer im Leerlauf, günstig bei hohem Volumen. Eine GPU, die bei fünf Prozent Auslastung steht, ist die teuerste Art, KI zu betreiben, die es gibt. Der Break-even hängt fast vollständig davon ab, wie stark und wie planbar Sie sie nutzen.

Der Betriebsaufwand. Irgendjemand muss das Ding tatsächlich betreiben — Patches, Modell-Updates, Monitoring, GPU-Ausfälle, Skalierung unter Last. Eine Cloud-API verbirgt all das hinter einer URL; Selbsthosting übergibt es Ihnen. Das ist der Posten, den man am häufigsten unterschätzt, und ein großer Teil des Grundes, 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 genau, wohin jedes Byte gegangen ist. Sie können alles protokollieren, nachweisen, dass Daten das Land nie verlassen haben, und die Überraschung vermeiden, dass ein Anbieter das Modell, auf dem Ihr Prozess beruht, stillschweigend ändert oder abkündigt. Für eine regulierte Prüfung ist diese Herkunftssicherheit viel wert — und genau das können Sie von einer Black-Box-API nicht bekommen.

Was passt — und wann

Die gute Nachricht ist: Das ist selten ein Entweder-oder, und es als eines zu behandeln, ist ein Fehler. Die meisten sinnvollen Architekturen leben in der Mitte, und dorthin setze ich die meisten Kunden.

Der Mittelweg: EU-gehostet und hybrid

Zwischen den beiden Extremen liegen die Optionen, die die meisten Mittelständler tatsächlich wollen. EU-gehostete verwaltete Inferenz betreibt ein offenes Modell für Sie innerhalb eines deutschen oder EU-Rechenzentrums unter einem ordentlichen Auftragsverarbeitungsvertrag — Sie bekommen die meiste Souveränität, ohne die Hardware oder die Rufbereitschaft zu besitzen. Eine hybride Architektur steuert nach Sensibilität: nicht sensibler, öffentlicher Text geht für maximale Qualität an eine Spitzen-API, während alles mit personenbezogenen Daten oder Geschäftsgeheimnissen auf einem selbst gehosteten Modell verarbeitet wird. Ein verwandtes Muster ist es, die sensiblen Teile zu schwärzen oder zu tokenisieren, bevor überhaupt etwas eine externe API erreicht. Das sind weniger Kompromisse als die Einsicht, dass nicht alle Ihre Daten dasselbe Risiko tragen.

Damit auf dem Tisch löst sich die Entscheidung meist sauber auf. Tendieren Sie zu selbst gehostet, wenn die Daten wirklich sensibel sind — regulierte personenbezogene Daten, Kern-IP oder ein vertragliches Verbot externer Verarbeitung —, das Volumen hoch genug ist, um die Hardware zu amortisieren, und die Qualität offener Modelle Ihre Latte reißt. 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 keinen Appetit auf den Betriebsaufwand haben. Gehen Sie hybrid, wenn ein Teil Ihrer Arbeitslasten sensibel ist und ein Teil nicht — was, sobald Sie ehrlich hinsehen, die wahre Lage der meisten Unternehmen ist.

Der rote Faden durch all das: Es ist eine Geschäfts- und Risikoentscheidung im technischen Kostüm. Die nützliche Frage lautet nicht abstrakt „was ist sicherer?“, sondern „was kosten uns diese konkreten Daten, wenn sie abfließen oder wir die Kontrolle verlieren — und was kauft uns der Leistungs- und Betriebsaufschlag, sie im Haus zu halten, tatsächlich?“. Das ist eine Frage, die Ihre Geschäftsführung besitzen sollte, nicht nur Ihre IT.

Das ist ein großer Teil dessen, was ich tue. Ich baue beides — selbst gehostete Systeme mit offenen Modellen auf Ihren eigenen oder den GPUs eines deutschen Anbieters sowie Cloud- und Hybrid-Architekturen —, und das Erste, wobei ich Ihnen helfe, ist die Entscheidung, was Ihre Daten und Ihr Anwendungsfall tatsächlich rechtfertigen, statt Ihnen standardmäßig die teuerste Antwort zu verkaufen. Wenn Sie sehen möchten, wie das auf einen konkreten Bau abbildet, legt die Leistungsseite es dar; wenn Sie Ihre konkrete Situation lieber durchsprechen, nehmen Sie Kontakt auf.