KI-Anbieter und Piloten bewerten, bevor Sie skalieren

# KI-Anbieter und Piloten bewerten, bevor Sie skalieren

Drei Anbieter haben gerade denselben Use Case präsentiert: Computer Vision, um falsch etikettierte Packungen auf einer Abfülllinie zu erkennen. Anbieter A zeigte eine Demo mit 99,7 % Accuracy. Anbieter B nannte zwei Wochen Installationszeit. Anbieter C bot den niedrigsten Preis pro Kamera. Sechs Monate später würde nur eines dieser Deployments noch laufen. Diese Lektion gibt Ihnen die Scorecard, mit der Sie schon vor der Unterschrift wissen, welches.

Warum Demos (ein wenig) lügen

Jede Anbieter-Demo funktioniert. Genau das ist der Sinn einer Demo. Das Modell wurde auf kuratiertem Material trainiert und getunt, häufig aufgenommen im Labor des Anbieters oder an einem Best-Case-Produktionstag bei einem Kunden.

Die eigentliche Frage ist nicht „funktioniert es auf der Bühne“. Sie lautet: „funktioniert es auf Ihrer Linie, mit Ihrem Licht, Ihrem Etikettenmaterial, Ihrer Rüstfrequenz, in drei Monaten, um 2 Uhr nachts in der Nachtschicht.“

Diese Lücke zwischen Demo-Performance und Produktions-Performance wird manchmal „Demo-ware“ genannt: ein System, das produktionsreif aussieht, aber nie gegen das Chaos eines echten Werks stressgetestet wurde. Die Fertigung ist dafür besonders anfällig, weil die Bedingungen von Linie zu Linie variieren: Vibration, Staub, Reflexionen, SKU-Wechsel (Stock Keeping Unit, eine eigenständige Produkt-/Verpackungsvariante) und Bedienerverhalten unterscheiden sich alle von der Referenzanlage des Anbieters.

Die dreiteilige Scorecard

Bewerten Sie jedes Anbieter-Pitch auf drei Dimensionen, bevor Sie einen Piloten starten.

1. Data readiness

Fragen Sie: welche Daten braucht dieses Modell, und haben Sie sie tatsächlich, im richtigen Format, in der richtigen Menge?

• Für Computer Vision (Defekterkennung, Etikettenprüfung): Wie viele gelabelte Bilder von Defekten braucht der Anbieter? Seltene Defekte (ein zerkratzter Verschluss, der 1-mal pro 20.000 Einheiten auftritt) sind schwer zu trainieren. Fragen Sie, wie der Anbieter mit Class Imbalance umgeht (wenn ein Ergebnis, etwa „gutes Teil“, das andere, etwa „Defekt“, in den Trainingsdaten massiv überwiegt).
• Für Predictive Maintenance: Haben Sie historische Sensordaten (Vibration, Temperatur, Stromaufnahme), die mit tatsächlichen Ausfallereignissen getaggt sind? Ohne Ausfall-Labels hat das Modell nichts, woraus es lernen kann. Viele Werke haben Sensorlogs, aber keine saubere Wartungsdokumentation, die sie mit Störungen verknüpft.
• Für Qualitäts-/Prozessoptimierung: Sind Ihre Historian-Daten (Zeitreihen aus Ihrem SCADA- oder MES-System, also Supervisory Control and Data Acquisition / Manufacturing Execution System) sauber, konsistent mit Zeitstempeln versehen und frei von Sensordrift?

Ein Anbieter, der sagt „die Datenfrage klären wir während des Piloten“, sagt Ihnen damit, dass der Pilot eigentlich ein verkappter Datenaudit ist. Das ist in Ordnung, aber dann kalkulieren und scopen Sie ihn auch so.

2. Integrationsaufwand

Hier brechen Budgets und Zeitpläne meist ein.

Fragen Sie konkret:

• Braucht es eine neue Kamera, eine PLC-Anbindung (Programmable Logic Controller, der Industrierechner, der die Maschinen steuert) oder ein Edge-Device, oder liest das System aus der bestehenden Infrastruktur?
• Wer verantwortet das OT-Netz (Operational Technology, die industriellen Steuerungssysteme), und hat die IT/OT-Security zugestimmt? Fertigungswerke trennen OT- und IT-Netze aus Cybersecurity-Gründen zunehmend, und jedes KI-System, das beide berührt, ist ein Review-Fall, kein Plug-in.
• Wie groß ist die tatsächliche Auswirkung auf die Taktzeit? Ein Vision-System, das 200 Millisekunden pro Einheit hinzufügt, kann unsichtbar oder katastrophal sein, je nach Ihrer Liniengeschwindigkeit.
• Muss die Linie für die Installation gestoppt werden, und wie lange?

Ein brauchbarer Bauchtest: Wenn der Anbieter diese Fragen nicht konkret beantworten kann (nicht „üblicherweise“, sondern „auf Ihrer Linie bedeutet das X“), hat ererThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → nicht Ihr Werk gescopt, sondern nur sein Produkt.

3. Design des Proof of Concept (PoC)

Ein PoC (Proof of Concept, ein kleiner Test zur Machbarkeitsprüfung vor größerer Investition) ist nur dann nützlich, wenn ererThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → so angelegt ist, dass ein Scheitern Erkenntnisse bringt. Schwache PoCs sind darauf angelegt, zu gelingen.

Ein glaubwürdiger PoC sollte vor dem Start schriftlich festlegen:

• Erfolgsmetrik mit einer Zahl. Nicht „bessere Defekterkennung“, sondern „Reduktion der False-Negative-Rate bei Verschlussdefekten von der aktuellen Baseline auf unter 0,5 %, gemessen über 10.000 Einheiten“.
• Eine Dauer, die lang genug ist, um echte Variabilität zu erfassen. Ein einwöchiger Pilot während eines stabilen Produktionslaufs sagt wenig über die Performance in einer Rüstwoche oder bei einem Materialwechsel des Lieferanten.
• Eine definierte Baseline. Wie hoch ist die tatsächliche Fehlerrate des heutigen menschlichen Prüfers oder des bestehenden Systems? Viele Werke kennen sie nicht genau, was „KI verbessert die Accuracy“ unfalsifizierbar macht.
• Eine Exit-Klausel. Was passiert vertraglich, wenn der PoC die Metrik verfehlt? Gute Anbieter stimmen dem zu. Anbieter, die sich einer harten Scheiterns-Schwelle widersetzen, signalisieren geringes Vertrauen.

Für eine brauchbare Einführung in Evaluationsmetriken für Klassifikationssysteme (die Logik hinter den meisten Tools zur Defekterkennung) siehe diese zugängliche Erklärung aus Googles eigenem Machine Learning Crash Course: Classification: Accuracy, recall, precision.

Ein durchgerechnetes Mini-Beispiel

Nehmen wir an, die Demo von Anbieter A beansprucht 99,7 % Accuracy bei der Defekterkennung. Ihre Linie liefert derzeit 500.000 Einheiten pro Monat aus, mit einer intern geschätzten Defect-Escape-Rate der menschlichen Prüfung (Defekte, die durchkommen) von 0,3 %, also rund 1.500 defekte Einheiten, die monatlich zu Kunden gelangen.

Accuracy allein ist hier irreführend, weil die meisten Einheiten „gut“ sind: Ein faules Modell, das immer „gut“ vorhersagt, kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnte bei der Accuracy hoch punkten und dabei null Defekte finden. Was zählt, ist der Recall speziell auf der Defektklasse: von allen tatsächlichen Defekten, welchen Prozentsatz hat das Modell erkannt?

Wenn die 99,7 % von Anbieter A die Gesamt-Accuracy sind, der offengelegte Defekt-Recall aber nur 80 % beträgt, dann rutschen 20 % der echten Defekte weiterhin durch, in diesem Fall rund 300 Einheiten pro Monat. Das kann Ihre aktuelle menschliche Baseline schlagen oder auch nicht, aber Sie kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen es nicht wissen, ohne den Anbieter zu bitten, Recall und Precision (von allem, was als defekt markiert wurde, welcher Prozentsatz war es wirklich) separat offenzulegen, nicht nur eine gemischte Accuracy.

Red-Flags-Checkliste

• Accuracy genannt ohne angegebene Baseline oder Aufschlüsselung nach Klassen
• Kein Hinweis darauf, wie das Modell mit Edge Cases umgeht (neue SKU, neues Etikettendesign, Lichtwechsel)
• Preismodell nach Anzahl Kameras/Sensoren ohne Erwähnung von Data Engineering oder Integrationsaufwand
• PoC-Vorschlag ohne harte Scheiterns-Kriterien
• Der Anbieter kann kein vergleichbares Produktions-Deployment nennen (keine Demo, ein real laufendes Werk), das Sie als Referenz prüfen kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen

🎬 [VIDEO: "How to Evaluate AI Vendors" - youtube.com/results?search_query=how+to+evaluate+ai+vendors+manufacturing - suchen Sie nach aktuellen fertigungsbezogenen Vorträgen zur Anbieterbewertung von Branchenkonferenzen wie der Hannover Messe oder MODEX, die regelmäßig Session-Aufzeichnungen veröffentlichen]

Adoptionsrealität nach dem erfolgreichen Piloten

Einen PoC zu bestehen ist nicht dasselbe wie skalierbereit zu sein. Zwei weitere Prüfungen zählen vor dem Rollout über mehrere Linien oder Werke:

Generalisiert es? Ein Modell, das auf Licht und Kamerawinkel von Linie 3 getunt ist, braucht für Linie 7 möglicherweise ein Retraining, nicht nur ein erneutes Deployment. Fragen Sie den Anbieter, was „Skalierung“ tatsächlich kostet: ist es Copy-Paste, oder ein neues Mini-Projekt pro Linie?

Wer pflegt es? Modelle driften (die Performance verschlechtert sich, wenn sich die realen Bedingungen von den Trainingsbedingungen entfernen). Fragen Sie, wer die Modell-Performance in Produktion überwacht, wie oft Retraining stattfindet und was das jährlich kostet. Diese laufenden Kosten fehlen häufig im ursprünglichen Pitch und kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen über zwei bis drei Jahre die Höhe der Implementierungskosten erreichen (das ist ein allgemeines Muster, das über Enterprise-KI-Deployments hinweg berichtet wird, keine feste Branchenkennzahl, prüfen Sie es also gegen Ihren konkreten Vertrag).

Wichtigste Erkenntnisse

• Bewerten Sie jedes Anbieter-Pitch auf drei Dimensionen: Data readiness (haben Sie die gelabelten Daten, die das Modell braucht), Integrationsaufwand (was die Anbindung an Ihre reale OT/IT-Umgebung erfordert) und PoC-Design (ob Erfolg/Scheitern vorab mit Zahlen definiert ist).
• Fordern Sie klassenspezifische Metriken (Recall, Precision) für unbalancierte Probleme wie Defekterkennung, nicht eine gemischte Accuracy, die schlechte Real-World-Performance verdecken kann.
• Ein glaubwürdiger PoC hat eine numerische Erfolgsschwelle, eine realistische Dauer, die Produktionsvariabilität erfasst, eine benannte Baseline und einen vertraglichen Exit im Fall des Scheiterns.
• Ein bestandener Pilot auf einer Linie garantiert nicht, dass es günstig über andere skaliert; fragen Sie nach Retraining-Kosten pro Linie und laufender Modellpflege, bevor Sie Budget freigeben.
• Prüfen Sie Referenzen zu echten Produktions-Deployments, nicht zu Demos, und seien Sie skeptisch bei Anbietern, die sich nicht auf harte Scheiterns-Kriterien festlegen wollen.