KI-Strategiegespräche im produzierenden Gewerbe beginnen oft an der falschen Stelle. Teams diskutieren Modellgenauigkeit, verfügbare Daten, den Einsatz eines Cloud-Modells oder eines Edge-Modells und darüber, welcher Pilot den Nutzen am schnellsten belegen könnte. Das sind berechtigte Fragen. Doch sobald KI Teil einer vernetzten Maschine, eines Inspektionsgeräts, einer Mensch-Maschine-Schnittstelle oder eines Wartungsprodukts wird, tritt eine grundlegendere Einschränkung in den Vordergrund: Kann die Organisation diese Fähigkeit über den gesamten Lebenszyklus hinweg als sicheres Produkt betreiben?

Der Cyber Resilience Act verändert die praktische Perspektive. Bei Produkten mit digitalen Elementen kann Cybersecurity nicht länger als spätes Review neben der Produktentwicklung stehen. Schwachstellenmanagement, sichere Konfiguration, Softwareupdates, technische Dokumentation und Incident-Prozesse werden zu Bestandteilen dessen, was es heißt, ein Produkt auf den Markt zu bringen und zu warten.

Für Hersteller ist das besonders relevant, weil KI selten isoliert eingesetzt wird. Sie ist in Anlagen eingebettet, die an Kunden verkauft werden, über Servicenetzwerke verbunden, in industrielle Steuerungsumgebungen integriert oder per Fernzugriff erreichbar. Eine nützliche KI-Funktion kann damit einen neuen Zugang zu einer Kundenumgebung schaffen, eine neue Abhängigkeit von externer Software begründen oder einen neuen operativen Ausfallmodus erzeugen. Die Frage lautet nicht nur, ob das Modell funktioniert. Entscheidend ist, ob das Produktteam das System erklären, absichern, aktualisieren und unterstützen kann, nachdem es das Werk verlassen hat.

KI macht aus einer Funktion eine Verpflichtung über den gesamten Lebenszyklus

Ein Prototyp kann mit einem eingefrorenen Modell, einem kontrollierten Datensatz und einer kleinen Gruppe interner Nutzer laufen. Ein Produkt kann sich auf diese Bedingungen nicht verlassen. Im Betrieb verändern sich Eingaben, Softwarebibliotheken erhalten Schwachstellen, Zugangsdaten laufen ab, Schnittstellen werden angepasst und Kunden erwarten, dass ihre Anlagen über Jahre nutzbar bleiben.

Dieser Unterschied ist bei KI-gestützten Produkten entscheidend, weil das Modell nur eine Komponente in einer größeren Kette ist. Ein bildbasiertes Inspektionsgerät kann Kameras, Firmware, ein Betriebssystem, eine Inference Runtime, Modelldateien, einen Workflow zur Datenaufbereitung, Software für Remote Support und ein Webinterface umfassen. Ein Maschinenassistent kann eine HMI, Benutzerkonten, Wissensabruf, Diagnosedaten und eine Verbindung zu einer Serviceplattform kombinieren. Jedes Element hat eine eigene Sicherheitslage, einen Wartungsbedarf und einen Verantwortlichen.

Das Modell definiert nicht die Produktgrenze. Ein Produktteam, das das Modell als einziges KI-Asset behandelt, übersieht die Komponenten, die am ehesten vermeidbare Risiken schaffen: unsignierte Update-Pakete, schlecht verwaltete Service-Zugangsdaten, nicht mehr unterstützte Bibliotheken, übermäßig weitreichenden Fernzugriff oder undokumentierte Abhängigkeiten von Drittanbietern.

Deshalb kann ein KI-Proof of Concept erfolgreich aussehen, während der Weg zur kommerziellen Freigabe unklar bleibt. Das Innovationsteam mag nachgewiesen haben, dass ein Vision-Modell einen Qualitätsfehler erkennt. Damit ist noch nicht belegt, dass die Organisation Modellupdates sicher verteilen, nachvollziehen kann, welche Version bei einem Kunden lief, auf eine entdeckte Schwachstelle reagieren oder manipulierte Eingaben daran hindern kann, unsicheres oder unzuverlässiges Verhalten auszulösen.

Anforderungen an die Produktsicherheit sollten die Architektur früh prägen

Der teure Fehler besteht darin, zunächst die KI-Funktion zu bauen und Compliance-Kontrollen erst kurz vor der Freigabe des Produkts hinzuzufügen. Dann sind Architekturentscheidungen bereits fest verankert. Die gewählte Inference Engine unterstützt möglicherweise nicht den erforderlichen Update-Ansatz. Dem Gerät fehlt eventuell ein vertrauenswürdiger Identitätsmechanismus. Das System kann unter Umständen keine aussagekräftigen Logs erzeugen, ohne mehr Kundendaten als vorgesehen zu erfassen. Oder das Team weiß nicht genau, welche Open-Source-Pakete in der ausgelieferten Software enthalten sind.

Das sind keine Dokumentationsprobleme. Es sind Engineering-Entscheidungen.

Sichere Updates sind eine Designfähigkeit. KI-gestützte Anlagen benötigen einen bewussten Prozess für die Freigabe von Software-, Konfigurations- und Modelländerungen. Dieser Prozess sollte festlegen, was geändert wird, wer dies autorisiert hat, wie die Integrität geprüft wird, wie die Änderung in die Kundenumgebung gelangt und was geschieht, wenn die Installation fehlschlägt. Modellupdates verdienen dieselbe Disziplin wie Firmware- oder Anwendungsupdates. Ein neues Modell kann das Produktverhalten wesentlich verändern, selbst wenn der Anwendungscode unverändert bleibt.

Für viele mittelständische Hersteller erfordert das kein riesiges Plattformprogramm. Notwendig ist eine belastbare Grundlage: ein kontrollierter Release-Prozess, ein klar verantworteter Update-Mechanismus, ein Inventar der ausgerollten Versionen und ein Eskalationsweg, wenn ein Problem Kunden betrifft. Das Ziel ist nicht, jede Maschine dauerhaft zu vernetzen. In industriellen Umgebungen kann Konnektivität aus guten betrieblichen Gründen eingeschränkt sein. Ziel ist vielmehr, dass die Organisation über eine realistische und sichere Methode verfügt, das zu warten, was sie verkauft.

Transparenz über Abhängigkeiten muss KI-Komponenten einschließen. Eine Software Bill of Materials wird häufig als Compliance-Artefakt diskutiert. Richtig genutzt, ist sie ein operatives Werkzeug. Sie hilft Produktsicherheit, Engineering und Support dabei, zu verstehen, was in einem Gerät oder einem Produkt-Release vorhanden ist, sobald eine Schwachstelle auftaucht. Bei KI-Produkten sollte dieses Inventar über klassische Softwarepakete hinausgehen. Teams müssen wissen, welche Model Runtime, Datenverarbeitungsbibliotheken, Modellartefakte und extern betriebenen Services Teil der ausgelieferten Fähigkeit sind.

Eine KI-Funktion, die von einer externen API abhängt, wirft andere Fragen auf als eine Funktion, die lokal am Edge läuft. Keine der beiden Varianten ist automatisch überlegen. Der externe Service kann den Modellbetrieb vereinfachen, wirft jedoch Fragen zu Servicekontinuität, Datenflüssen und Change Management auf. Ein Edge-Deployment kann die lokale Kontrolle und Resilienz verbessern, erhöht aber den Aufwand, Updates über eine Flotte zu verteilen und zu überwachen. Die richtige Entscheidung ergibt sich aus dem Risiko des Produkts, seiner Betriebsumgebung und dem Supportmodell – nicht aus einer pauschalen Präferenz für Cloud oder Edge.

Im Schwachstellenmanagement werden organisatorische Lücken sichtbar

Viele Maschinenbauer verfügen über robuste Qualitätsprozesse, aber fragmentierte Prozesse für den Umgang mit Schwachstellen. Das Engineering weiß, wie ein Produktfehler behandelt wird. Die IT weiß, wie interne Systeme gepatcht werden. Der Kundenservice weiß, wie ein Einsatz im Feld koordiniert wird. Ein vernetztes KI-Produkt kann verlangen, dass alle drei Funktionen zusammenarbeiten – oft unter Zeitdruck.

Ein glaubwürdiger Prozess für das Schwachstellenmanagement beantwortet praktische Fragen, bevor ein Incident eintritt. Wo können Forschende oder Kunden ein Problem melden? Wer bewertet, ob die Meldung glaubwürdig ist? Wer kann ermitteln, welche Produktversionen betroffen sind? Wie entscheidet das Unternehmen, ob eine Mitigation, ein Update oder eine Kundenkommunikation erforderlich ist? Wer verantwortet die Beziehung zu einem Komponentenlieferanten, wenn das Problem in einer Abhängigkeit und nicht im eigenen Code liegt?

Verantwortung lässt sich nicht mit der Komponente auslagern. Ein Lieferant kann ein Modell, ein Gateway, ein Betriebssystem-Image oder einen gemanagten KI-Service bereitstellen. Diese Lieferantenbeziehung ist wichtig, entbindet den Hersteller aber nicht von der Pflicht, das daraus entstehende Produktrisiko zu verstehen. Einkaufsbedingungen, technische Schnittstellen und Supportvereinbarungen müssen mit den Sicherheitsverpflichtungen abgestimmt sein, die das Produktteam trägt.

Hier geraten innovationsgetriebene KI-Programme häufig ins Stocken. Sie verfügen vielleicht über eine überzeugende Vendor-Demonstration, einen vielversprechenden Prototypen und einen Business Sponsor, aber nicht über eine Einigung dazu, wer das Produkt nach dem Deployment verantwortet. Wenn kein Team für Softwarewartung, Schwachstellen-Triage und Kundenkommunikation zuständig ist, verfügt die Organisation noch nicht über eine KI-Produktfähigkeit. Sie hat ein Experiment mit einem Go-to-Market-Problem.

KI-spezifische Risiken sollten ohne Theater behandelt werden

KI bringt reale Sicherheits- und Zuverlässigkeitsrisiken mit sich, zieht aber auch überzogene Behauptungen an. Ein sinnvoller Ansatz für Produktsicherheit unterscheidet zwischen herkömmlichen Softwarerisiken und Risiken, die durch die KI-Funktion selbst entstehen.

Zu den klassischen Risiken gehören exponierte APIs, schwache Authentifizierung, unsicherer Fernzugriff, verwundbare Pakete und ungeschützte Update-Kanäle. Sie bleiben hochrelevant, weil KI-Komponenten die Softwarekomplexität erhöhen. KI-spezifische Aspekte umfassen manipulierte Eingaben, unerwartete Modellausgaben, nachlassende Leistung bei veränderten realen Bedingungen sowie unbeabsichtigte Offenlegung über Prompts oder abgerufene Informationen, wenn generative Schnittstellen eingesetzt werden.

Die Antwort besteht nicht darin zu versprechen, dass das Modell niemals versagt. Es geht darum zu definieren, wo KI-Ausgaben beratend sind, wo sie Handlungen auslösen dürfen, welche Grenzen gelten und wie sich das Produkt verhält, wenn die Zuverlässigkeit gering ist oder ein unterstützender Service nicht verfügbar ist. Ein visuelles Inspektionssystem kann unsichere Fälle zur menschlichen Prüfung markieren. Ein Wartungsassistent kann das verwendete Quelldokument nennen, statt eine nicht nachvollziehbare Anweisung auszugeben. Einer Maschinensteuerungsfunktion sollte nicht allein deshalb Autorität eingeräumt werden, weil eine Demonstration überzeugend wirkt.

Sicherheit, Cybersecurity und Produktqualität müssen in einer Release-Entscheidung zusammenkommen. In vielen Herstellern haben diese Disziplinen getrennte Governance-Strukturen. Embedded AI macht die Kosten dieser Trennung sichtbar. Eine Release-Entscheidung sollte nicht nur bestätigen, dass eine Funktion die erwartete Leistung erfüllt. Sie sollte auch sicherstellen, dass ihre Abhängigkeiten bekannt sind, ihr Update-Weg tragfähig ist, ihr Verhalten im Fehlerfall verstanden wurde und ihr operativer Verantwortlicher vorbereitet ist.

Machen Sie Compliance zum Vorteil in der Umsetzung, nicht zum späten Gate

Die kontraintuitive Sicht lautet: Verpflichtungen zur Produktsicherheit können die Umsetzung von KI verbessern. Sie erzwingen Entscheidungen, die Pilotprogramme sonst aufschieben: Welche Use Cases verdienen eine Produktisierung? Welche Datenflüsse sind akzeptabel? Auf welche Lieferanten ist Verlass? Und welche Teams werden die Fähigkeit dauerhaft betreiben?

Diese Disziplin hilft der Geschäftsführung, zwischen einer überzeugenden Demonstration und einem tragfähigen Angebot zu unterscheiden. Eine kundennahe KI-Funktion, die nicht sicher aktualisiert werden kann, ist nicht bereit. Eine vernetzte Diagnosefunktion ohne klaren Prozess zur Reaktion auf Schwachstellen ist kein fertiges Produkt. Ein Modell, das auf undokumentierten Abhängigkeiten beruht, hat noch keine kommerzielle Grundlage, die sich nachhaltig unterstützen lässt.

Für DACH-Hersteller besteht der praktische Schritt darin, Produktsicherheit, Software Engineering, Service und kommerzielle Führung frühzeitig in die KI-Entscheidung einzubinden – bevor die Architektur festgelegt ist. Beginnen Sie mit dem vorgesehenen Produktlebenszyklus, nicht mit der Shortlist der Modelle. Entscheiden Sie, wie die Funktion gewartet, unterstützt und außer Betrieb genommen wird. Gestalten Sie die KI-Fähigkeit anschließend innerhalb dieser Rahmenbedingungen.

Das ist keine Bremse für Innovation. So wird aus einer KI-Funktion etwas, das Kunden mit Vertrauen kaufen können und das die Organisation warten kann, ohne unsichtbare operative Schulden anzuhäufen.

Ein Fit Call hilft Ihnen zu prüfen, ob ein KI-gestütztes Produkt einen glaubwürdigen Weg vom Prototypen zu einem sicheren, wartbaren Release hat – bevor Sicherheitsverpflichtungen zu einer teuren Überarbeitung in letzter Minute führen.

Fit Call buchen →

Hinweis zum Kontext: Dieser Artikel behandelt praktische Aspekte des Produktlebenszyklus und stellt keine Rechtsberatung dar.