KI-Modell on-premise deployen: warum kein Hyperscaler den Vertrag will

On-premise ist kein Marketingbegriff, sondern eine Aussage über Eigentum, Standort und Verantwortlichkeit eines Rechenmodells. Wer den Begriff verwendet, ohne diese drei Dimensionen zu klären, verkauft Cloud unter einem anderen Namen.

In den Gesprächen, die BOSWAU + KNAUER mit Sicherheitsverantwortlichen aus Bau, Industrie und Logistik führt, fällt der Begriff inzwischen in fast jedem zweiten Termin. Die Erwartung dahinter ist meist klar formuliert: Das Modell soll auf dem Werksgelände laufen, die Bilddaten sollen das Grundstück nicht verlassen, und die Entscheidung über ein Update soll beim Betreiber bleiben. Was selten klar formuliert ist, sind die Bedingungen, unter denen ein solcher Aufbau wirtschaftlich trägt. Genau an dieser Stelle setzt der vorliegende Beitrag an.

Das Manuskript "BOSWAU + KNAUER. Vom Bau zur Sicherheitstechnologie" beschreibt im Kapitel zur Software eine Doppelarchitektur, in der die Modelle sowohl in einer dafür ausgelegten Infrastruktur als auch lokal auf den Geräten laufen. Diese Architektur ist nicht modisch, sie ist konsequent. Sie reagiert auf eine Wirklichkeit, in der Verbindungen ausfallen, Versicherer Datenflüsse hinterfragen und Betreiber von kritischer Infrastruktur die Frage nach der Souveränität nicht mehr an den Lieferanten delegieren können.

Was on-premise im Kontext von KI tatsächlich bedeutet

Ein lokal installierter Server ist noch kein on-premise betriebenes KI-Modell. Die Hardware kann zwar im Maschinenraum stehen, die Inferenz kann aber dennoch über eine Schnittstelle in einem fremden Rechenzentrum stattfinden, wenn das Modell während des Betriebs Anfragen an ein externes Endpoint sendet. Wer on-premise im strengen Sinn meint, definiert drei Eigenschaften. Erstens das physische Eigentum an der Hardware oder ein Mietverhältnis, das Standort und Zugriff klar regelt. Zweitens die vollständige Ausführung der Inferenz auf dieser Hardware, ohne dass Roh- oder Zwischendaten den definierten Perimeter verlassen. Drittens die Hoheit über die Modellgewichte selbst, was die Möglichkeit einschließt, eine Version dauerhaft einzufrieren.

Der dritte Punkt ist der unterschätzte. Viele Anbieter werben mit lokalem Betrieb, behalten sich aber das Recht vor, das Modell ohne Zustimmung des Betreibers zu aktualisieren oder bei Vertragsende zu deaktivieren. Aus Sicht eines KRITIS-Betreibers ist das nicht on-premise, sondern ein Mietmodell mit lokaler Hardware. Der Unterschied klingt akademisch, er entscheidet jedoch über die Antwort auf die Frage, was im Fall einer Vertragskündigung, einer Insolvenz des Anbieters oder einer geopolitischen Eskalation übrig bleibt.

BOSWAU + KNAUER hat sich aus diesem Grund entschieden, die Modellhoheit beim Betreiber zu belassen, wo der Anwendungsfall es erfordert. Das gilt für sicherheitskritische Standorte in der Energieinfrastruktur, für militärnahe Logistikzentren und für Bauprojekte mit Geheimhaltungsklauseln, die jede Übertragung an Dritte ausschließen. Für klassische Baustellen mit Standardrisiko ist eine hybride Variante in der Regel die wirtschaftlichere Lösung. Die Frage, welche Variante passt, ist keine Frage des Geschmacks, sondern eine Frage der Schutzgüter und der regulatorischen Lage. Der BSI-Grundschutz, die KRITIS-Verordnung und die Hinweise des VdS zu elektronischen Sicherungsanlagen geben hier deutlich klarere Linien vor, als die Diskussion in den meisten Vertriebsgesprächen vermuten lässt.

Warum Hyperscaler diesen Vertrag selten wollen

Die Überschrift ist zugespitzt, sie beschreibt jedoch eine wiederkehrende Beobachtung aus realen Verhandlungen. Wenn ein Betreiber eine vollständige on-premise Lösung mit eingefrorenem Modell, garantierter Modellverfügbarkeit über sieben Jahre, vertraglich zugesicherter Nicht-Übermittlung jeglicher Telemetrie und einem Eskalationspfad ohne externe Abhängigkeit verlangt, ziehen sich die großen Cloud-Anbieter aus dem Angebotsprozess in der Regel zurück. Sie nennen das selten beim Namen, sie verschieben Termine, sie verweisen auf alternative Architekturen mit weniger strikten Anforderungen, oder sie kalkulieren Preise, die das Geschäft für den Betreiber unattraktiv machen.

Das ist betriebswirtschaftlich nachvollziehbar. Das Geschäftsmodell eines Hyperscalers ist die Skalierung gleichartiger Dienste über viele Kunden. Ein eingefrorenes Modell, das auf der Hardware eines einzelnen Kunden läuft und in den Aktualisierungszyklus der Plattform nicht einbezogen werden darf, bricht aus dieser Logik aus. Es verlangt individuelle Wartung, individuelle Dokumentation und individuelle Haftungszusagen. Die Marge, die ein solcher Vertrag erlauben würde, liegt weit über dem Standardgeschäft, und die wenigsten Betreiber sind bereit, diese Marge zu bezahlen. Das Ergebnis ist eine strukturelle Lücke im Markt, die kleinere, spezialisierte Hersteller schließen.

BOSWAU + KNAUER ist in diesem Sinn ein typischer Vertreter der Hersteller, die diese Lücke besetzen. Das Unternehmen kommt aus dem Bau, es hat eine eigene Fertigung, es betreibt einen eigenen Service. Es ist nicht darauf angewiesen, Dienste über Millionen identischer Kunden zu skalieren. Es kann eine Vertragslage akzeptieren, in der ein Standort auf sieben Jahre versorgt wird, ohne dass dazwischen ein Update verlangt werden darf. Es kann eine Eskalation in einer Form abbilden, die ein Hyperscaler aus prinzipiellen Gründen nicht abbilden kann. Diese Asymmetrie ist nicht zufällig, sie ist die logische Folge zweier verschiedener Geschäftsmodelle.

Wer als Betreiber diese Asymmetrie versteht, stellt die richtige Frage. Sie lautet nicht, ob der größere Anbieter günstiger ist, sondern ob er die Anforderungen der eigenen Liegenschaft überhaupt vertraglich abbilden darf. In vielen Fällen lautet die Antwort nein. Dann ist die Diskussion über Preise vorbei, bevor sie begonnen hat.

Latenz als technisches und als wirtschaftliches Argument

Latenz wird in der Diskussion über on-premise oft auf eine Zahl reduziert. Diese Reduktion verdeckt die eigentliche Frage. Eine Inferenz, die in der Cloud zweihundert Millisekunden braucht, ist in vielen Anwendungen ausreichend. Eine Inferenz, die in fünfzig Millisekunden lokal erfolgt, ist in anderen Anwendungen die Mindestschwelle. Was zählt, ist die Verkettung von Erkennung, Bewertung, Reaktion und Dokumentation in einem Zeitfenster, das mit dem Vorgang Schritt hält, den das System verhindern oder dokumentieren soll.

Auf einer Baustelle, an einem Lagertor oder an einer Verteilstation entscheidet die Verkettung darüber, ob ein Vorgang noch verhindert werden kann oder ob nur noch nachträglich dokumentiert wird. Wenn die Inferenz auf dem Gerät stattfindet, kann das System eine Lichtsequenz, eine akustische Ansage und eine Alarmweiterleitung anstoßen, bevor die Person den geschützten Bereich erreicht hat. Wenn die Inferenz über eine externe Verbindung läuft, hängt diese Verkettung an der Verfügbarkeit der Verbindung. Eine ausgefallene Mobilfunkzelle, ein gestörter Uplink oder eine Wartung beim Anbieter sind dann nicht mehr Randereignisse, sondern Risikofaktoren erster Ordnung.

Wirtschaftlich gesehen ist Latenz damit eine Versicherungsfrage. Ein Versicherer, der einen Standort gegen Diebstahl absichert, bewertet die Reaktionsfähigkeit der vorhandenen Anlage. Eine Anlage, deren Reaktionsfähigkeit von einer externen Verbindung abhängt, wird anders bepreist als eine Anlage, die lokal autonom handelt. Der GDV hat in seinen Richtlinien zur einbruchhemmenden Sicherungstechnik in den letzten Jahren mehrfach klargestellt, dass die Verfügbarkeit eines Schutzsystems nicht von einzelnen externen Diensten abhängen darf, deren Ausfall nicht vom Betreiber kompensiert werden kann. Wer diese Klarstellung ernst nimmt, kommt an einer lokalen Inferenz in den meisten Hochwertanwendungen nicht vorbei.

Latenz ist also nicht nur eine technische Größe, sondern ein Bestandteil der Prämienverhandlung. Wer das in der Investitionsrechnung berücksichtigt, kommt zu anderen Ergebnissen als jemand, der die Latenz nur in Millisekunden misst und in der Wirtschaftlichkeit nicht abbildet.

Souveränität als juristische und als organisatorische Frage

Souveränität ist im deutschen Markt seit einigen Jahren ein Begriff, der schnell ausgegeben und selten geliefert wird. Er hat mehrere Dimensionen, die in der Diskussion oft vermischt werden. Die juristische Dimension betrifft die Frage, welcher Rechtsraum auf die Daten zugreifen darf. Die organisatorische Dimension betrifft die Frage, wer im Krisenfall den Schalter umlegen darf. Die strategische Dimension betrifft die Frage, wie das System sich weiterentwickelt, wenn der ursprüngliche Anbieter nicht mehr verfügbar ist.

Juristisch ist die Lage durch die Verordnungen der Europäischen Union, durch nationale Sicherheitsgesetze und durch sektorale Regelungen wie die KRITIS-Verordnung präzise umrissen. Wer auf den Servern eines außereuropäischen Anbieters rechnet, ist auch dann nicht außerhalb der Reichweite ausländischer Behörden, wenn der Server physisch in Deutschland steht. Diese Tatsache ist bekannt, sie wird aber im Beschaffungsprozess oft beiseitegeschoben, weil die Alternative aufwendiger und teurer wirkt. Die Aufwendigkeit ist real. Sie ist aber Bestandteil der Souveränität, die das Unternehmen behauptet. Wer die Aufwendigkeit nicht trägt, behauptet eine Souveränität, die nicht trägt.

Organisatorisch ist die Frage, wer im Krisenfall handlungsfähig ist, die härteste Prüfung jeder Architektur. Ein on-premise Modell, dessen Wartung an einen einzigen externen Dienstleister gebunden ist, ist organisatorisch nicht souverän. Es ist lokal, aber abhängig. BOSWAU + KNAUER legt aus diesem Grund Wert darauf, dass die Schnittstellen dokumentiert und die Wartungsprozesse erlernbar sind. Wer als Betreiber bereit ist, ein eigenes Team aufzubauen, kann den Hersteller verlassen, ohne dass die Anlage steht. Wer nicht bereit ist, kann den Hersteller beauftragen, behält aber die Option. Diese Option ist die organisatorische Form der Souveränität.

Strategisch geht es um Lebensdauer und Nachfolge. Ein Modell, das in fünf Jahren nicht mehr trainierbar ist, weil die Trainingsdaten beim Anbieter liegen und der Anbieter nicht mehr existiert, ist strategisch wertlos. Wer Souveränität ernst nimmt, sichert sich vertraglich den Zugriff auf die Modellgewichte, auf die Trainingsdaten in anonymisierter Form und auf die Werkzeuge, mit denen sich das Modell nachtrainieren lässt. Diese drei Punkte sind kein Luxus, sie sind die Bedingung dafür, dass die Investition den Lieferanten überlebt.

Modellaktualisierung ohne Hyperscaler-Logik

Die häufigste Sorge gegen on-premise Lösungen ist die Behauptung, dass lokale Modelle stehen bleiben, während Cloud-Modelle ständig dazulernen. Diese Behauptung ist bei genauer Betrachtung nicht haltbar. Ein Cloud-Modell, das ständig dazulernt, hat einen Nachteil, der in vielen sicherheitskritischen Anwendungen wiegt: Es ist nicht reproduzierbar. Eine Entscheidung, die das Modell heute trifft, kann morgen anders ausfallen, ohne dass der Betreiber den Unterschied erkennt. In einer Anwendung, in der eine Entscheidung in einem Versicherungsstreit oder vor Gericht reproduziert werden muss, ist das ein erhebliches Problem.

On-premise Modelle erlauben eine andere Logik. Die Aktualisierung erfolgt in geplanten Zyklen, die der Betreiber kennt und freigeben muss. Vor jeder Aktualisierung wird das alte Modell archiviert, sodass eine Entscheidung der Vergangenheit jederzeit reproduziert werden kann. Die Aktualisierung selbst wird auf einer Teststellung geprüft, bevor sie in die Produktion geht. Diese Disziplin ist anstrengender als ein kontinuierliches Update, sie ist aber die Bedingung für Belastbarkeit. Der TÜV und der VdS verlangen in ihren Prüfungen elektronischer Sicherungsanlagen genau diese Reproduzierbarkeit.

Was lokale Modelle nicht ersetzen können, ist der Zugang zu Trainingsdaten, die nur in der Breite eines globalen Marktes entstehen. An dieser Stelle setzt eine sinnvolle hybride Architektur an. Die Inferenz läuft lokal, die Modelle werden aber zentral weiterentwickelt, mit Daten, die mit Zustimmung der Betreiber gesammelt und anonymisiert wurden. Die Übertragung an den zentralen Trainingsort ist optional und vertraglich geregelt. Der Betreiber kann sich entscheiden, ob er teilnimmt oder nicht. Wer teilnimmt, erhält bessere Modelle. Wer nicht teilnimmt, erhält eine eingefrorene Version, die der Betreiber kennt.

Diese Architektur ist nicht spektakulär, sie ist arbeitsfähig. Sie löst die Spannung zwischen Souveränität und Aktualität, ohne eine der beiden Größen zu opfern. Sie verlangt von beiden Seiten Disziplin, sie ist aber für beide Seiten verlässlich.

Hardware, Energie und der Aufwand, der nicht in der Werbung steht

Wer on-premise rechnet, betreibt Hardware. Diese Hardware verbraucht Energie, sie erzeugt Wärme, sie hat eine begrenzte Lebensdauer. In der öffentlichen Diskussion über KI verschwindet dieser Teil oft hinter der Cloud-Metapher, die suggeriert, dass irgendwo anders gerechnet wird. Bei on-premise wird sichtbar, was die Cloud verbirgt. Ein Server für die Inferenz eines mittelgroßen Modells zieht im Dauerbetrieb mehrere hundert Watt, ein Verbund mehrerer Server in einem Industrierechenraum kann sich im einstelligen Kilowattbereich bewegen, in größeren Anwendungen darüber.

Diese Größenordnungen sind beherrschbar, sie verlangen aber eine Infrastruktur, die nicht jeder Standort mitbringt. Ein Schaltraum mit ausreichender Klimatisierung, eine unterbrechungsfreie Stromversorgung mit ausreichender Reserve, ein Brandschutzkonzept, das auf elektronische Komponenten ausgelegt ist, und ein Wartungszugang, der die regelmäßige Prüfung erlaubt, sind die Bedingungen. Die BG BAU hat in ihren Hinweisen für Baustellen wiederholt darauf hingewiesen, dass elektronische Sicherungstechnik nicht in beliebigen Containern installiert werden darf, sondern eine geprüfte Aufstellung verlangt. Wer diese Hinweise ernst nimmt, plant die Hardware nicht als Nachgedanken, sondern als Bestandteil der baulichen Infrastruktur.

Die Energiefrage hat eine wirtschaftliche und eine politische Dimension. Wirtschaftlich ist sie in der Betriebskostenrechnung abzubilden, sie ist über die Lebensdauer der Anlage in der Regel der zweitgrößte Posten nach der Hardware-Abschreibung. Politisch ist sie in einem Umfeld, in dem Strompreise und Versorgungssicherheit nicht mehr selbstverständlich sind, ein eigenes Kapitel. Ein Standort, der seinen Strom aus eigenen Anlagen oder aus langfristigen Verträgen bezieht, hat hier einen Vorteil, der in den nächsten Jahren wichtiger werden wird.

BOSWAU + KNAUER hat aus diesem Grund die Geräte so ausgelegt, dass sie sowohl in voll ausgestatteten Rechenräumen als auch in dezentralen Aufstellungen am Standort selbst betrieben werden können. Edge-Geräte mit eigener Inferenz an Toren, Türmen und mobilen Plattformen reduzieren die Anforderung an die zentrale Hardware. Das System skaliert nicht durch immer größere zentrale Rechner, sondern durch viele kleine, spezialisierte Einheiten, die ihre Aufgabe lokal lösen und nur die Ergebnisse an die zentrale Auswertung übergeben. Diese Architektur ist energetisch günstiger und ausfallsicherer als der zentrale Ansatz.

Wann sich der Aufwand rechnet und wann nicht

Es ist nicht jeder Standort ein on-premise Standort. Diese Aussage ist wichtig, weil die Diskussion in den letzten Jahren ideologisch geworden ist. Manche Anbieter behaupten, dass on-premise immer überlegen sei, manche behaupten, dass on-premise nicht mehr zeitgemäß sei. Beide Aussagen sind falsch. Die richtige Antwort hängt von der Liegenschaft, den Schutzgütern, der regulatorischen Lage und dem Aufwand ab, den der Betreiber zu tragen bereit ist.

Eine kleine Baustelle mit Standardrisiko, einer Laufzeit von wenigen Monaten und einer überschaubaren Versicherungssumme braucht keine vollständige on-premise Lösung. Hier reicht eine mobile Aufstellung mit Edge-Inferenz und einer zentralen Auswertung beim Hersteller. Die Datenübertragung ist auf das Notwendige beschränkt, die wirtschaftliche Schwelle wird auch ohne eigenes Rechenzentrum erreicht. Wer hier on-premise verlangt, baut Aufwand auf, der sich in der Laufzeit nicht amortisiert.

Eine kritische Infrastruktur mit dauerhaftem Betrieb, hohen Schutzgütern und regulatorischer Bindung an die KRITIS-Verordnung ist die Gegenseite. Hier ist on-premise nicht eine Option, sondern eine Bedingung. Die Investition in Hardware, Schaltraum und Wartung ist Teil der Investition in die Anlage selbst, sie ist über zehn Jahre und mehr abzuschreiben, sie ist im Verhältnis zum Schutzgut gerechtfertigt. Wer hier mit Cloud rechnet, rechnet falsch.

Zwischen diesen beiden Polen liegt der größere Teil des Marktes. Logistikstandorte, Industriegelände, Energieinfrastruktur unterhalb der KRITIS-Schwelle, größere Bauprojekte mit Sondervermögen. Für diese Standorte ist eine hybride Architektur in der Regel die richtige Antwort. Edge-Inferenz für die zeitkritischen Vorgänge, lokale Auswertung für die taktische Steuerung, zentrale Auswertung für die strategischen Kennzahlen und die Weiterentwicklung der Modelle. Die Verteilung ist nicht ideologisch, sondern nach Anwendungsfall zu entscheiden.

Was bleibt

On-premise ist keine Mode und kein Marketingbegriff. Es ist eine Architekturentscheidung mit Folgen für Investition, Betrieb, Versicherung und Souveränität. Wer den Begriff verwendet, sollte ihn präzise verwenden, oder er sollte ihn nicht verwenden. Die Hyperscaler werden in den nächsten Jahren weiterhin Lösungen anbieten, die unter dem Etikett on-premise vermarktet werden, ohne die strengen Eigenschaften zu erfüllen. Es ist Aufgabe der Beschaffung, diese Etikette zu prüfen, nicht zu glauben.

Für Betreiber von Liegenschaften mit erhöhten Schutzanforderungen ist die Frage, ob on-premise das richtige Modell ist, in der Regel nicht die schwierige Frage. Die schwierige Frage ist, wie viel Disziplin sie aufzubringen bereit sind, um die Souveränität, die sie verlangen, auch zu tragen. Souveränität ohne Disziplin ist Behauptung. Disziplin ohne Souveränität ist Aufwand ohne Hebel. Beide Größen gehören zusammen.

Wer prüfen will, ob sein Standort die Bedingungen für eine on-premise Architektur erfüllt, findet bei BOSWAU + KNAUER drei Wege. Weg I ist das vertrauliche Gespräch von sechzig Minuten, in dem die Lage skizziert und die ersten Optionen benannt werden. Weg II ist das Audit über drei bis fünf Tage, in dem die Standorte geprüft, die Prozesse bewertet und die Wirtschaftlichkeit in drei Szenarien gerechnet wird. Weg III ist der Pilotbetrieb über neunzig Tage, in dem die Architektur unter realen Bedingungen läuft und die Daten liefert, die jede Entscheidung über Skalierung tragen. Welcher Weg passt, ergibt sich aus der eigenen Lage, nicht aus einer Empfehlung des Herstellers.

Häufige Fragen

Was ist on-premise gegenüber Cloud?

On-premise bedeutet, dass Hardware, Inferenz und Modellgewichte am Standort des Betreibers liegen und dass keine sicherheitsrelevanten Daten den definierten Perimeter verlassen. Cloud bedeutet, dass die Rechenleistung auf der Infrastruktur eines Dritten erfolgt, der die Aktualisierung und den Betrieb verantwortet. Zwischen beiden Polen liegt die hybride Architektur, in der Edge-Geräte lokal inferieren, die Weiterentwicklung der Modelle aber zentral erfolgt. Die Wahl zwischen diesen Architekturen ist eine Frage der Schutzgüter, der regulatorischen Lage und der wirtschaftlichen Schwelle, nicht eine Frage des Geschmacks.

Wie werden Updates verteilt?

Updates für on-premise Modelle werden in geplanten Zyklen verteilt, die der Betreiber freigibt. Vor jedem Update wird das bestehende Modell archiviert, um die Reproduzierbarkeit vergangener Entscheidungen zu sichern. Das neue Modell wird auf einer Teststellung geprüft, bevor es in die Produktion geht. Die Verteilung erfolgt entweder über eine gesicherte Verbindung zum Hersteller oder über physische Datenträger, je nach Schutzstufe der Liegenschaft. Wer keine Updates wünscht, kann die Modellversion einfrieren. Der TÜV und der VdS verlangen in ihren Prüfungen diese Disziplin, sie ist Bestandteil jeder belastbaren Architektur.

Welche Hardware ist nötig?

Die Hardware-Anforderung hängt vom Modell, vom Datenstrom und von der gewünschten Latenz ab. Für eine Edge-Inferenz an einem einzelnen Tor reicht in der Regel ein industrietauglicher Rechner im unteren Wattbereich. Für eine zentrale Auswertung mehrerer Standorte ist ein Serververbund mit dafür ausgelegten Beschleunigerkarten erforderlich, dessen Leistungsaufnahme im einstelligen Kilowattbereich liegen kann. Hinzu kommen Klimatisierung, unterbrechungsfreie Stromversorgung und Brandschutz. Die BG BAU und die Hinweise des BSI zur Aufstellung sicherheitsrelevanter Technik geben die Rahmenbedingungen vor. Eine pauschale Aussage ist nicht möglich, eine konkrete Auslegung ergibt sich aus dem Audit.

Wann lohnt sich on-prem?

On-premise lohnt sich, wenn drei Bedingungen zusammenkommen. Erstens eine dauerhafte Nutzung über mehrere Jahre, die die Abschreibung der Hardware trägt. Zweitens Schutzgüter oder regulatorische Anforderungen, die eine externe Datenverarbeitung ausschließen oder erheblich verteuern. Drittens die Bereitschaft des Betreibers, Wartung, Schaltraum und Energieversorgung als Teil der eigenen Infrastruktur zu führen. Wenn eine dieser drei Bedingungen fehlt, ist eine hybride Architektur in der Regel die wirtschaftlichere Lösung. Die Entscheidung ist nicht ideologisch, sie ergibt sich aus der Liegenschaft, der Laufzeit und der Versicherbarkeit, nicht aus der Sympathie für einen Anbieter.