Auf dieser Seite
Kurz gesagt: Ein KI-Pilotprojekt in einer Fabrik kann an den Schnittstellen scheitern, nicht nur am Modell. Klären Sie vor dem Training, ob die Daten verlässlich, die Maschinenschnittstellen dokumentiert und die erlaubten Aktionen begrenzt sind — und wer für Validierung und Wartung verantwortlich ist.
Warum gute Offline-Ergebnisse noch keine Produktionsreife bedeuten
Die Offline-Genauigkeit beantwortet eine Frage: Stimmten die Ausgaben des Modells mit den Labels eines bereits erfassten und bereinigten Datensatzes überein? In der Produktion stellen sich andere Fragen. Treffen die Daten rechtzeitig und im richtigen Format von Kamera, Sensor oder Betriebsdatenbank ein? Was tut die Anlage, wenn ein Ergebnis verspätet eintrifft oder fehlt? Wer wird nachts angerufen, wenn eine Entscheidung falsch erscheint? Ein Pilotprojekt ist ein Versuch mit begrenztem Umfang. Es scheitert häufig an der Integration, weil solche Fragen aufgeschoben wurden — nicht unbedingt an einem schwachen Modell.
Festlegen, was das Modell entscheiden darf
Schreiben Sie die Entscheidungsgrenzen vor Beginn des Pilotprojekts auf: ein Hinweis, eine Empfehlung zum Ausschleusen eines Teils, ein vorgeschlagener Prozessparameter oder eine freigegebene Aktion innerhalb fester Grenzen. Benennen Sie für jeden Schritt, der den Prozesszustand verändert, die letztlich entscheidende Instanz: SPS, Bedienperson oder übergeordnetes System. Das ist wichtig, weil der Funktionsumfang leicht schleichend wächst. Ein Pilot, der als Dashboard begann, darf nicht unbemerkt Sollwerte schreiben. Sicherheitsfunktionen bleiben außerhalb des Modells und richten sich nach der Risikobeurteilung der Maschine.

Unter repräsentativen Produktionsbedingungen messen
Eine Woche mit sauberen Daten kann genau die Bedingungen ausblenden, die den Produktionsalltag schwierig machen: andere Schichten, Produktwechsel, Nacharbeit, neue Materiallieferanten, veränderte Beleuchtung, Sensordrift und alternde Betriebsmittel. Wählen Sie einen ausreichend langen Bewertungszeitraum, der diese Bedingungen erfasst. Vergleichen Sie das Modell mit dem bisherigen Entscheidungsprozess anhand derselben Teile und Zeitfenster. Zählen Sie Fehlalarme ebenso wie übersehene Fehler und erfassen Sie die Dauer jedes Bedienereingriffs. Eine Meldung, die ignoriert wird oder die Linie zu oft anhält, verursacht Kosten, die Offline-Kennzahlen nicht zeigen.
Ausfälle und Zuständigkeiten mitentwickeln
Legen Sie fest, wie die Linie reagiert, wenn die Inferenz zu langsam ist, der Inferenzrechner neu startet, ein Eingangssignal fehlt oder das Modell etwas erhält, das seinen Trainingsdaten nicht ähnelt. Ein einfaches, klar begrenztes Rückfallverfahren — etwa die Weiterleitung zur manuellen Prüfung — und verständliche Protokolle sind oft wertvoller als der letzte Bruchteil zusätzlicher Genauigkeit. Machen Sie außerdem Zuständigkeiten zu einem Liefergegenstand: Wer betreut das Modell, genehmigt erneutes Training und Rollbacks, installiert Softwareupdates, verantwortet Netzwerksicherheit und Vorfallbearbeitung und bezahlt die Wartung? Die Schnittstelle zu MES oder ERP braucht dieselbe Spezifikation wie jede andere; die ISA-95-Reihe ist eine übliche Referenz für die Integration von Unternehmens- und Steuerungssystemen. Nehmen Sie den Piloten erst ab, wenn die benannten Personen erklären können, wie sie ihn nach dem Ausscheiden der ursprünglichen Entwickler weiterbetreiben.
Checkliste vor Budget- oder Auftragsfreigabe
- Abnahmekennzahlen vorab vereinbaren und über reale Schichten und Produktvarianten hinweg messen.
- Entscheidungsgrenzen schriftlich festhalten: Was darf das Modell empfehlen oder verändern, und wer entscheidet letztlich?
- Datenschnittstellen mit der tatsächlichen SPS, dem MES und den Sensoren spezifizieren und testen — nicht nur mit exportierten Dateien.
- Ein geprüftes Rückfallverfahren für verspätete, fehlende oder außerhalb der Grenzen liegende Ergebnisse vorsehen.
- Änderungen kontrollieren: Modellversionen verwalten, erneutes Training freigeben und einen Rollback planen.
- Verantwortliche für Daten, Modell, Softwareupdates, Cybersicherheit und Wartungsbudget benennen.
Was dieser Leitfaden nicht nachweist
Diese Checkliste ist eine Planungshilfe, kein Audit, Prüfbericht oder Versprechen, dass sich ein Pilot skalieren lässt. Sie nennt keine Genauigkeitsschwellen: Die vertretbare Fehlerquote hängt vom Prozess und den Kosten der jeweiligen Fehlerart ab. Das NIST AI Risk Management Framework und die nachfolgende ENISA-Leitlinie dienen als Referenzen. Ob daraus rechtliche Pflichten für Ihren Betrieb entstehen, hängt von Branche und Rechtsraum ab. Funktionale Sicherheit und Maschinenkonformität müssen Fachleute für das tatsächliche System beurteilen.
Quellen und weitere Prüfung
- NIST — AI Risk Management Framework (AI RMF 1.0), Core: Govern, Map, Measure, Manage (2023-01; abgerufen am 2026-10-12).
- ENISA — Technische Umsetzungshinweise für Maßnahmen zum Cybersicherheits-Risikomanagement, Version 1.0 (2025-06; abgerufen am 2026-10-12).
- ISA — ISA-95: Integration von Unternehmens- und Steuerungssystemen (ohne Datum; abgerufen am 2026-10-12).
Der nächste sinnvolle Schritt
Listen Sie die Entscheidungen Ihres heutigen Pilotmodells auf, einschließlich der jeweils verwendeten Schnittstelle und der verantwortlichen Person. Die Lücken in dieser Tabelle zeigen Ihre Integrationsarbeit. Geht es um eine Roboterzelle oder industrielle Bildverarbeitung, nutzen Sie die Tabelle als Grundlage für den Einstieg über die Seite Robotik und Automation. Daraus entstehende Projekte werden über Eurobots/ReBots abgegrenzt und umgesetzt. Am Anfang stehen Machbarkeit und klare Verantwortungsgrenzen, nicht eine vorausgesetzte schlüsselfertige Installation. Das AYXWORKS-Portfolio beschreibt den technischen Hintergrund dieser Leitfäden.
Bildnachweis: ayxworks — eigene Darstellung, Rechte beim Herausgeber.
