Know-How

Lesedauer: 5 min

Simon Grabher

Simon Grabher, the CEO of craftworks GmbH

Eine KI-gestützte Qualitätskontrolle erkennt fehlerhafte Bauteile mit hoher Trefferquote. Nach mehreren erfolgreichen Testläufen wird das Modell an die Produktionslinie angebunden. Die manuelle Stichprobenprüfung kann reduziert werden, das Projekt gilt als Erfolg.

Ein halbes Jahr später führt das Unternehmen eine neue Produktvariante ein. Die Bauteile unterscheiden sich nur geringfügig von den bisherigen, haben aber eine andere Oberflächenbeschaffenheit. Das Modell wurde mit Bildern der alten Varianten trainiert und sortiert nun zunehmend einwandfreie Teile aus.

Technisch funktioniert alles. Die Kameras liefern Bilder, die Schnittstelle ist erreichbar und das Modell verarbeitet jede Anfrage. Dass die Ergebnisse schlechter geworden sind, fällt zunächst den Mitarbeitenden in der Qualitätssicherung auf.

Dieses fiktive Beispiel zeigt eine typische Herausforderung: Zwischen einem erfolgreichen KI-Piloten und einem dauerhaft zuverlässigen Produktivsystem liegen Aufgaben, die in der ursprünglichen Projektplanung häufig zu wenig Aufmerksamkeit bekommen.

Ein Modell arbeitet unter veränderlichen Bedingungen

Während der Entwicklung sind viele Einflussfaktoren kontrollierbar. Das Team kennt die verwendeten Daten, definiert Qualitätskriterien und prüft die Ergebnisse anhand eines festgelegten Testdatensatzes.

In der Produktion verändern sich diese Voraussetzungen.

Maschinen werden gewartet oder umgebaut. Sensoren werden ausgetauscht, Materialien wechseln und Softwareupdates verändern die verfügbaren Daten. Bei einer visuellen Qualitätsprüfung beeinflussen auch neue Lichtverhältnisse oder eine veränderte Kameraposition die Erkennung.

Solche Veränderungen können dazu führen, dass die Eingangsdaten zunehmend von den Trainingsdaten abweichen.

Im Machine Learning spricht man dabei von Data Drift. Verändert sich der Zusammenhang zwischen Eingabedaten und dem vorherzusagenden Ergebnis, handelt es sich um Concept Drift.

Für die Fachabteilung ist vor allem entscheidend, ob die Ergebnisse weiterhin zuverlässig sind.

Die technische Verfügbarkeit des Systems gibt darüber nur begrenzt Auskunft.

Warum herkömmliches IT-Monitoring nicht ausreicht

Klassisches Monitoring prüft beispielsweise, ob ein Dienst erreichbar ist, wie lange Anfragen dauern oder ob Fehler auftreten. Diese Informationen sind auch bei KI-Systemen wichtig. Die Qualität der Vorhersagen wird dadurch allerdings nicht erfasst.

Bei der Qualitätskontrolle aus dem Beispiel könnte das Modell über Wochen hinweg jede Anfrage innerhalb der vorgesehenen Zeit beantworten und trotzdem immer mehr Ausschuss verursachen.

Um solche Entwicklungen zu erkennen, müssen zusätzliche Informationen erfasst werden. Dazu gehören die Qualität und Verteilung der Eingangsdaten, Veränderungen der Vorhersagen sowie die Häufigkeit manueller Korrekturen.

Wo tatsächliche Prüfergebnisse verfügbar sind, können diese mit den Modellvorhersagen verglichen werden.

Welche Kennzahlen sinnvoll sind, hängt vom Einsatzgebiet ab.

Bei einer visuellen Qualitätskontrolle lassen sich Modellentscheidungen häufig mit manuellen Nachprüfungen vergleichen. Bei Predictive Maintenance ist das schwieriger. Wird eine Maschine nach einer Warnung vorsorglich gewartet, lässt sich oft nicht eindeutig feststellen, ob der vorhergesagte Ausfall tatsächlich eingetreten wäre.

Monitoring sollte deshalb bereits bei der Konzeption der Anwendung berücksichtigt werden. Fehlen die notwendigen Daten, lässt sich die Modellqualität später nur mit zusätzlichem Aufwand beurteilen.

Zu einem funktionierenden Monitoring gehören außerdem definierte Zuständigkeiten und Abläufe für den Umgang mit auffälligen Ergebnissen.

Zwischen IT, Data Science und Produktion

Wenn die Qualitätskontrolle aus dem Beispiel plötzlich zu viele Bauteile aussortiert, werden mehrere Abteilungen involviert.

Die Produktion bemerkt den erhöhten Ausschuss. Die IT überprüft die Infrastruktur und findet keinen Fehler. Das Data-Science-Team stellt schließlich fest, dass die neue Produktvariante in den Trainingsdaten nicht ausreichend abgebildet ist.

Damit ist die Ursache gefunden. Für die Behebung werden zusätzliche Trainingsdaten benötigt, das Modell muss überprüft und eine neue Version freigegeben werden. Gleichzeitig muss entschieden werden, wie die Qualitätsprüfung während dieser Arbeiten weiterläuft.

Diese Aufgaben betreffen unterschiedliche Verantwortungsbereiche.

Die Fachabteilung beurteilt die Auswirkungen auf den Produktionsprozess. Data Science kümmert sich um die Modellqualität und entwickelt Verbesserungen. IT beziehungsweise Plattformteams verantworten die Infrastruktur und das Deployment.

Wie die Aufgaben organisatorisch verteilt werden, hängt vom Unternehmen ab. Entscheidend sind dokumentierte Zuständigkeiten, klare Entscheidungswege und eine Gesamtverantwortung, die über den Abschluss des Entwicklungsprojekts hinaus besteht.

Modellupdates kontrolliert in Betrieb nehmen

Angenommen, das Modell wurde mit Bildern der neuen Produktvariante nachtrainiert. Die Erkennungsrate im Test hat sich verbessert.

Bevor die neue Version produktiv eingesetzt wird, muss geprüft werden, wie sie mit den bisherigen Produktvarianten zurechtkommt. Ein aktualisiertes Modell kann bei neuen Daten bessere Ergebnisse liefern und gleichzeitig bei älteren Bauteilen an Zuverlässigkeit verlieren.

Für solche Fälle braucht es geeignete Testdaten und einen kontrollierten Freigabeprozess.

Auch nach dem Deployment sollte nachvollziehbar bleiben, welche Modellversion zu welchem Zeitpunkt verwendet wurde. Bei Problemen muss sich eine zuvor freigegebene Version wiederherstellen lassen.

Hier setzt Machine Learning Operations, kurz MLOps, an.

MLOps umfasst Verfahren und Werkzeuge, um Machine-Learning-Modelle über ihren Lebenszyklus zu verwalten. Dazu gehören Versionierung, reproduzierbare Trainingsprozesse, automatisierte Tests, Monitoring und kontrollierte Deployments.

Der notwendige Umfang richtet sich nach der jeweiligen Anwendung. Ein Modell, das monatlich interne Prognosen erstellt, stellt andere Anforderungen als mehrere KI-Systeme, die unmittelbar in Produktionsabläufe eingebunden sind.

Der EU AI Act betrifft auch den laufenden Betrieb

Neben der technischen Zuverlässigkeit müssen Unternehmen regulatorische Anforderungen berücksichtigen.

Der EU AI Act unterscheidet KI-Systeme anhand ihres Verwendungszwecks und ihrer Risiken. Für bestimmte Hochrisiko-Anwendungen gelten besondere Vorgaben, etwa in Bezug auf technische Dokumentation, Protokollierung, menschliche Aufsicht und Überwachung nach dem Inverkehrbringen.

Die Bestimmungen werden schrittweise angewendet. Einige Verpflichtungen gelten bereits. Durch die Verordnung (EU) 2026/1744 wurden die Anwendungstermine bestimmter Hochrisiko-Anforderungen verschoben.

Für Industrieunternehmen ist die konkrete Einordnung ihrer Systeme entscheidend. Eine KI zur internen Produktionsplanung unterliegt nicht automatisch denselben Vorgaben wie eine sicherheitsrelevante KI-Komponente einer regulierten Maschine.

Unabhängig von der rechtlichen Einstufung sind nachvollziehbare Modelländerungen, dokumentierte Entscheidungen und eine angemessene Überwachung auch für den technischen Betrieb hilfreich.

Was vor dem Go-live geklärt sein sollte

Viele spätere Betriebsprobleme lassen sich vermeiden, wenn die Anforderungen an den laufenden Betrieb bereits während des Pilotprojekts berücksichtigt werden.

  • Modellqualität: Das Entwicklungsteam und die Fachabteilung definieren Kennzahlen, anhand derer sich Veränderungen der Modellleistung erkennen lassen. Die dafür notwendigen Informationen müssen dauerhaft verfügbar sein.

  • Monitoring: Auffällige Daten oder Vorhersagen werden erfasst und an die zuständigen Personen weitergeleitet. Für die Untersuchung und Behebung gibt es festgelegte Abläufe.

  • Änderungen: Neue Datenquellen, veränderte Produktionsbedingungen und Modellupdates durchlaufen geeignete Test- und Freigabeprozesse.

  • Ausfallkonzept: Für Zeiten, in denen das KI-System keine zuverlässigen Ergebnisse liefert, steht ein definierter Ersatzprozess bereit. Bei einer Qualitätsprüfung kann das eine verstärkte manuelle Kontrolle sein. In anderen Anwendungen ist ein bestehendes regelbasiertes Verfahren geeignet.

Diese Abläufe sollten gemeinsam mit den Mitarbeitenden entwickelt werden, die später täglich mit dem System arbeiten. Sie kennen die praktischen Einschränkungen und Ausnahmen des Produktionsprozesses.

Der Betrieb gehört zur Projektplanung

KI-Projekte werden häufig anhand ihrer Modellgüte und ihres wirtschaftlichen Potenzials bewertet. Für eine Investitionsentscheidung müssen auch die späteren Betriebskosten berücksichtigt werden.

Dazu gehören die Pflege der Datenpipelines, die regelmäßige Überprüfung der Modellqualität, die Bereitstellung neuer Versionen und die langfristig benötigten personellen Ressourcen.

Der Aufwand hängt von der Anwendung ab. Ein Modell für monatliche Prognosen benötigt eine andere Betreuung als ein System, das rund um die Uhr Entscheidungen in einer Produktionsanlage unterstützt.

Bei craftworks berücksichtigen wir diese Anforderungen bereits bei der Entwicklung industrieller KI-Anwendungen. Dazu gehören die Integration in bestehende Systemlandschaften, ein angemessenes Monitoring und die Möglichkeit, Modelle später kontrolliert anzupassen.

Ein erfolgreicher Pilot zeigt, dass ein Modell unter bestimmten Bedingungen funktioniert. Die Qualität des späteren Betriebs entscheidet darüber, ob die Lösung langfristig ihren Nutzen erfüllt.

Sie planen, ein KI-Modell in den Produktivbetrieb zu überführen?

Wir unterstützen Unternehmen bei der Entwicklung, Integration und dem Betrieb industrieller KI-Lösungen. Gerne besprechen wir, welche technischen und organisatorischen Voraussetzungen Ihr Anwendungsfall benötigt.

EINBLICKE

Diese Artikel könnten für Sie interessant sein.

three male team members of craftworks at a meeting table looking at laptops and working

Successful growth is a decision. Driven by data.

Wie können wir Ihnen weiterhelfen?