Ein Fertigungsunternehmen wählt eine KI-Plattform eines großen Cloud-Anbieters. Das Onboarding läuft reibungslos, die ersten Modelle trainieren schnell, und die frühen Ergebnisse sehen vielversprechend aus. Achtzehn Monate später hat sich das Bild verändert. Die Produktionsdaten des Unternehmens liegen ausschließlich in der Cloud dieses Anbieters. Die Modelle laufen auf proprietärer Infrastruktur. Die Datenpipelines nutzen anbieterspezifische Dienste, die anderswo kein Äquivalent haben. Als das Team ein spezialisiertes Computer-Vision-Tool evaluiert, das die eingebaute Lösung übertreffen würde, stellt es fest, dass der gesamte Datenfluss neu architekturiert werden müsste. Das Tool bleibt auf der Wunschliste. Der Anbieter ist zur Obergrenze geworden.
Dieses Muster ist nicht hypothetisch. Es ist das Standardergebnis, wenn Hersteller KI-Plattformen übernehmen, die um geschlossene Ökosysteme herum konzipiert sind. Die anfängliche Bequemlichkeit, alles von einem Anbieter zu haben, erzeugt eine Abhängigkeit, die sich mit der Zeit verstärkt. Jeder zusätzliche Anwendungsfall, jede neue Datenverbindung, jedes trainierte Modell vertieft die Verflechtung. Wechselkosten wachsen nicht linear, sondern exponentiell — und der Anbieter weiß das. Es folgt Preissetzungsmacht.
Wie Lock-In in der Fertigungs-KI entsteht
Lock-In in der Fertigungs-KI ist selten das Ergebnis einer einzelnen Entscheidung. Es akkumuliert sich durch eine Reihe vernünftiger Entscheidungen, die einzeln effizient erscheinen, aber zusammengenommen Optionalität eliminieren. Die Progression folgt einem vorhersehbaren Pfad.
- Datengravitation — Produktionsdaten werden in die Speicherschicht des Anbieters eingespeist. Terabytes an Zeitreihen-Sensordaten auf eine andere Plattform zu verschieben, wird selbst zum Migrationsprojekt
- Proprietäre Konnektoren — Maschinenintegrationen nutzen anbieterspezifische Treiber und Protokolle. Sie zu ersetzen bedeutet, die Konnektivität für jede SPS, jedes SCADA-System und jede Testmaschine von Grund auf neu aufzubauen
- Modellformat-Lock — trainierte Modelle werden in proprietären Formaten gespeichert oder hängen von anbieterspezifischen Laufzeitumgebungen ab. Der Export in Standardformate wie ONNX oder PMML wird entweder nicht unterstützt oder ist verlustbehaftet
- Workflow-Abhängigkeiten — Datenvorverarbeitung, Feature-Pipelines und Deployment-Logik werden mit anbieterspezifischen Tools gebaut, die keine Interoperabilitätsstandards haben
- Preiseskalation — sobald die Wechselkosten hoch genug sind, passt der Anbieter die Preise an, im Vertrauen darauf, dass Migration als Alternative zu teuer ist
Für Hersteller, die KI über mehrere Werke betreiben, multiplizieren sich die Risiken. Eine eingesperrte Architektur an einem Standort bedeutet, dass jeder nachfolgende Standort dieselben Einschränkungen erbt — unabhängig davon, ob die Tools des Anbieters die beste Wahl für die lokale Ausrüstung, Prozessanforderungen oder regionalen Datenvorschriften sind.
Das Argument für offene Architektur
Ein herstellerunabhängiger Ansatz bedeutet nicht, alles von Grund auf zu bauen. Er bedeutet, Plattformen zu wählen, die um offene Standards und Interoperabilität herum konzipiert sind, statt um proprietäres Lock-In. Das Prinzip ist klar: Der Hersteller sollte die Daten besitzen, die Modelle besitzen und die Freiheit behalten, jederzeit jedes Best-in-Class-Tool zu integrieren — ohne das Fundament neu zu konstruieren.
In der Praxis bedeutet das mehrere Dinge. Daten sollten in offenen Formaten gespeichert werden, die jedes System lesen kann. Maschinenkonnektivität sollte industrielle Standardprotokolle wie OPC UA und MQTT nutzen statt proprietärer Treiber. Trainierte Modelle sollten in Standardformaten exportierbar sein. APIs sollten dokumentierten Spezifikationen folgen, die es Drittanbieter-Tools ermöglichen, sich ohne Einbindung des Plattformanbieters zu verbinden. Die Plattform stellt die Orchestrierungsschicht bereit, errichtet aber keine Mauern um das, was sie orchestriert.
Freiheit zur Weiterentwicklung
Die KI-Landschaft entwickelt sich rasant. Die beste Computer-Vision-Bibliothek heute ist möglicherweise nicht die beste in zwei Jahren. Neue Edge-Computing-Hardware entsteht ständig. Regulatorische Anforderungen ändern sich, manchmal mit der Forderung, Daten lokal zu halten statt in einer bestimmten Cloud. Ein Hersteller, der in ein einzelnes Ökosystem eingesperrt ist, kann auf diese Veränderungen nicht ohne erheblichen Re-Platforming-Aufwand reagieren. Ein Hersteller auf einer offenen Architektur tauscht einfach die bessere Komponente ein und läuft weiter.
Bei RockQ haben wir die Plattform bewusst nach diesem Prinzip gebaut. Die Plattform verbindet sich mit jeder Maschine über industrielle Standardprotokolle. Daten bleiben unter der Kontrolle des Herstellers — on-premise, in seiner Cloud oder in einem hybriden Setup. Im ML Studio trainierte Modelle werden in Standardformate exportiert. Drittanbieter-KI-Services, eigene Python-Skripte und spezialisierte Tools integrieren sich über offene APIs. Wenn ein Kunde eine bessere Anomalie-Erkennungsbibliothek findet, bindet er sie ein. Wenn er von einem Cloud-Anbieter zu einem anderen wechseln muss, gehen seine Daten und Modelle mit. Der Wert der Plattform liegt in der Orchestrierung, nicht in der Gefangenschaft.
Vendor Lock-In ist keine technische Unvermeidbarkeit. Es ist eine Designentscheidung von Plattformanbietern, die von Abhängigkeit profitieren. Hersteller, die KI-Plattformen evaluieren, sollten eine direkte Frage stellen: Wenn wir in drei Jahren wechseln wollen, was genau wäre dafür nötig? Die Antwort offenbart, ob die Plattform ein Fundament für langfristige Innovation ist oder eine Falle, aus der das Entkommen mit jedem deployten Anwendungsfall teurer wird. KI-Investitionen in der Fertigung erstrecken sich über Jahrzehnte. Die Architektur sollte ebenso langlebig sein — ohne an die Roadmap eines einzelnen Anbieters gekettet zu sein.