KI in der Fertigung erfolgreich einsetzen: Vom Prototyp zum stabilen Produktivbetrieb

Warum scheitern so viele KI-Projekte in der Fertigung nach der erfolgreichen Prototypenphase?

Lukas Rauh: KI-Projekte in der Fertigung scheitern nach dem Prototyp meist an Betriebsstrukturen und an den Schnittstellen zwischen Abteilungen, nicht nur an der Technik.

Das bestätigt neben meiner eigenen Projekterfahrung auch eine explorative Expertenstudie am Fraunhofer IPA. Befragt wurden 16 Fachleute aus 16 Unternehmen: OEMs, Maschinenbauer, KI-Lösungsanbieter und Governance-Institutionen. Die genannten Hürden bei der Operationalisierung von KI wurden dabei systematisch erfasst und eingeordnet. Nur etwa ein Viertel der Nennungen betraf Technologie und Daten. Der deutlich größere Teil verteilte sich auf Organisation und Prozesse (den mit Abstand größten Block), auf Menschen und Kultur sowie auf das externe Umfeld wie Regulatorik und Wirtschaftlichkeit. Am häufigsten genannt wurden dabei das Prozessvakuum, also das Fehlen formalisierter Abläufe für den KI-Lebenszyklus, unrealistische Erwartungen an den Aufwand nach dem Piloten sowie regulatorische Unsicherheit. Ein Proof-of-Concept ist eben ein Versprechen, kein Erfolg.

Operationalisierungsprobleme sind damit systemische Fehlpassungen. Wer KI auf dem Shopfloor als reines IT-Thema behandelt, hat den größeren Teil der Hürden nicht adressiert. Die Forschung verortet diese Hürde recht genau im Bereich der Technologiereifegrade 5 bis 6: an der Pilotphase, also am Übergang vom Labornachweis zur Erprobung im realen Einsatzumfeld.

Das deckt sich mit Erfolgsquoten, die seit Jahren erstaunlich stabil sind: Eine Gartner-Erhebung ergab bereits 2019, dass rund 53 Prozent der KI-Projekte den Übergang in die Produktion schaffen. In einer S&P-Global-Befragung von über 1.000 Unternehmen wurden 2025 im Schnitt 46 Prozent der Proof-of-Concepts vor dem Produktivbetrieb verworfen. Das Problem ist also deutlich älter als die aktuelle Welle um generative KI und Agenten.

In der Praxis zeigt sich das an drei Bruchstellen:

• Prozessvakuum. Agile, iterative KI-Entwicklung trifft auf lineares, hardwarezentriertes Projektmanagement. Es gibt keinen definierten Übergabepunkt zwischen Entwicklung und Betrieb, also entstehen manuelle Workarounds und informelle Dokumentation.
• Abteilungssilos. Datenpfad und Verantwortung enden an Abteilungsgrenzen. Im Prototyp fällt das nicht auf, weil die Daten einmalig von Hand zusammengetragen wurden.
• Unterschätzter Betriebsaufwand. Wer nur die Modellentwicklung budgetiert, verhungert auf halber Strecke. Die Erwartung, dass nach dem funktionierenden Prototyp der schwierige Teil vorbei sei, war in den Interviews eine der häufigsten Fehlannahmen.

In den Projekten, die ich begleitet habe, geht häufig die Hälfte der Projektlaufzeit für die grundsätzliche Machbarkeit drauf. IT-Sicherheit, Betriebskonzept und Governance kommen erst danach in Fahrt und haben dann am wenigsten Zeit, obwohl sie über den Dauerbetrieb entscheiden.

Welche Voraussetzungen müssen Unternehmen für den erfolgreichen Einsatz von KI in der Produktion erfüllen?

Lukas Rauh: Vier Voraussetzungen entscheiden, ob KI in der Produktion über den Piloten hinauskommt:

1. Ein Anwendungsfall mit bezifferbarem Nutzen. Nicht „Wir wollen etwas mit KI machen“, sondern „Wir wollen den Ausschuss an Linie 3 um X Prozent senken“. Ohne Zielgröße weicht die Erwartung oft von realisierbaren Zielen ab.
2. Ein Datenzugang, der im Betrieb trägt. Die Daten müssen automatisiert, historisiert und mit stabilen Bezeichnern aus MES, SPS oder Prüfsystem kommen, nicht als CSV-Export oder auf einem USB-Stick der Schichtleitung.
3. Eine benannte fachliche Verantwortung. Jemand aus der Produktion, nicht aus der IT, muss für das Ergebnis geradestehen und über Eingriffe entscheiden.
4. Ein Betriebskonzept, das mit der Anzahl der Anwendungsfälle mitwächst. Diese Voraussetzung fehlt am häufigsten. Sie rächt sich erst beim dritten oder vierten Anwendungsfall.

Für die Reihenfolge heißt das: erst Verantwortung klären, dann Werkzeuge auswählen. Interdisziplinäre Teams sollten stehen, bevor über eine KI-Plattform entschieden wird.

Zum Betriebskonzept: Solange die iterativen Arbeiten an KI-Systemen manuell erledigt werden, wächst der Betreuungsaufwand nicht mit der Zahl der Anwendungsfälle, sondern schneller als diese. Der Grund sind die Fachkräfte: Fachkräfte für Daten, für KI, für Operationalisierung und Systemdesign sind knapp. Genau sie sind durch wiederkehrende Routinetätigkeiten gebunden. Mit MLOps, also standardisierten und automatisierten Abläufen für Bereitstellung, Überwachung und Nachtraining, lässt sich die Kurve drücken, weil den Fachkräften die nicht wertschöpfenden Tätigkeiten abgenommen werden. Der Hebel liegt damit in der notwendigen Handarbeit pro KI-Modell.

Investiert wird jedoch meist zuerst in KI-Modelle und erst danach in Datengrundlage und Betrieb.

Wie beeinflussen Datenqualität und Datenverfügbarkeit den Erfolg industrieller KI-Anwendungen?

Lukas Rauh: Noch vor der Frage nach der Datenmenge steht die Frage, ob das zu erkennende Problem in den Daten überhaupt sichtbar ist.

Konkret: Eine Bildverarbeitungs-KI findet einen Defekt nur, wenn er im Bild robust erkennbar ist, etwa  unter reproduzierbarer Beleuchtung. Die praktische Prüfung ist einfach: Wenn ein erfahrener Mensch den Fehler in den vorliegenden Daten nicht zuverlässig labeln kann, wird ein KI-Modell ihn auch nicht zuverlässig finden. In der Studie wurden dazu passend vor allem unzureichende Datengranularität und fehlender Maschinenkontext als technische Hürden angeführt.

Die zweite Hürde ist organisatorisch und in großen Fertigungen die schwerere: Datensilos. Jede Abteilung führt ihren eigenen Datentopf, mit eigenen IDs. Die Daten wandern nicht mit dem Produkt mit. Werte aus der Schweißzelle, aus der Lackstraße und aus der Qualitätsprüfung lassen sich hinterher nicht ohne Weiteres demselben Bauteil zuordnen, und beim Zusammenführen von Teilkomponenten wird es schnell unübersichtlich. Ohne diese Zuordnung lassen sich Ursache und Wirkung aber nicht zusammenbringen. Genau darum geht es bei den meisten industriellen KI-Anwendungen.

Der Versuch, vorab einen allumfassenden Datenmonolithen für die gesamte Fabrik zu bauen, scheitert meist an Komplexität und Laufzeit. Pragmatischer ist eine zentrale Integrationsschicht, die stabil läuft und aus allen Werksbereichen erreichbar ist. Ihr eigentlicher Zweck ist, einzelne Datenstrecken schnell aufbauen zu können: Historisch gewachsene Systeme wie SPS, SCADA oder MES lassen sich so einzeln anbinden, auch wenn es für sie keine einheitliche Schnittstelle gibt. Darauf entstehen kleine, gekapselte KI-Anwendungen statt eines Monolithen, und IT-Sicherheit und Zugriffskontrolle liegen an einer Stelle statt in jedem Projekt neu.

Erst danach greifen die klassischen Qualitätsdimensionen: Verfügbarkeit, Vollständigkeit, Konsistenz, Aktualität, Korrektheit. Nach meiner Erfahrung entfällt mindestens die Hälfte des Projektaufwands auf Datenbeschaffung und -aufbereitung; wo noch keine Dateninfrastruktur existiert, deutlich mehr.

Ein häufiger Sonderfall ist in der Fertigung sind sehr seltene Defekte, für die kaum Fehlerbeispiele vorliegen. Hier lässt sich mit synthetischer Datengenerierung arbeiten, dem gezielten virtuellen Erzeugen möglichst realistischer Defekte, um die Datenbasis auszugleichen. Für seltene Fehlerbilder ist das oft der einzige gangbare Weg.

Welche Rollen und Verantwortlichkeiten braucht ein erfolgreiches KI-Projekt in der Fertigung?

Lukas Rauh: In KI-Projekten entscheidet weniger, wer mitarbeitet, als wer zum richtigen Zeitpunkt entscheidungsfähig am Tisch sitzt.

In der Praxis ist das der häufigste Grund für Verzögerungen. Ein typisches Muster: Die Notwendigkeit kommt aus der Produktion oder einer Fachabteilung, dort ist der Anwendungsfall klar und der Leidensdruck hoch. Die IT und die weiteren Verantwortlichen kommen aber nicht in gleichem Tempo hinterher: Sie werden zu spät eingebunden oder nicht sauber eingearbeitet. Die Folge sind schwerfällige, langwierige Entscheidungen genau an den Stellen, die ohnehin die sensibelsten sind: Datenbeschaffung, Datenbereitstellung und die Frage, wer wofür verantwortlich ist.

Die Studie stützt das: Unklare Verantwortlichkeiten und ungeklärte Haftungsfragen wurden ebenso regelmäßig genannt wie unsystematisches Projektmanagement und langsame Entscheidungshierarchien. Alle vier Aspekte gehören zur Dimension Organisation und Prozesse gehören zur Dimension Organisation und Prozesse, die insgesamt den größten Block der genannten Hürden ausmachte.

In einem der letzten Projekte, die ich begleitet habe, ist genau das zum Scheitergrund geworden: Es waren nicht alle notwendigen Entscheider zum richtigen Zeitpunkt eingebunden. Die Hürden bei der Datenbereitstellung traten erst auf, als der fachliche Teil längst lief, und ließen sich dann nicht mehr rechtzeitig ausräumen.

Fünf Rollen sollten deshalb vom ersten Tag an besetzt sein und auch nach dem Go-live besetzt bleiben:

• Fachlicher Auftraggeber (Produktion): definiert den Nutzen, trägt die Kennzahl, entscheidet über Skalierung.
• Domänenexpert*in: liefert das Prozesswissen und bewertet, ob Modellausgaben plausibel sind. Dieser Beitrag wird regelmäßig unterschätzt.
• Dateneigner*in: entscheidet verbindlich über Zugriff und Bereitstellung. Diese Rolle fehlt am häufigsten und blockiert dann am längsten.
• Data und ML Engineering: baut den Datenpfad von der Anlage bis zum KI-Modell und verantwortet Entwicklung, Validierung und Nachtraining.
• Betriebsverantwortliche Person (IT/OT): verantwortet Verfügbarkeit, Zugriffe, IT-Sicherheit und die Einbettung in die Systemlandschaft.

Die Leitlinie lautet deshalb: Rollenklarheit geht vor Toolauswahl. Das interdisziplinäre Team muss handlungsfähig sein, bevor Lizenzen beschafft oder eine KI-Plattform implementiert wird. Entscheidend ist dabei weniger die Teamgröße als die Zuordnung: In kleineren Unternehmen kann eine Person mehrere Rollen übernehmen, aber jede Rolle muss einen Namen haben, und dieser Name muss zum Projektstart feststehen. Wer die IT erst dann einbindet, wenn die Machbarkeit bereits gezeigt ist, hat die schwierigsten Entscheidungen an das Projektende verschoben, wo am wenigsten Zeit dafür bleibt.

Was ist MLOps, und warum ist es für den dauerhaften Betrieb industrieller KI-Systeme wichtig?

Lukas Rauh: MLOps bezeichnet die Gesamtheit der Verfahren, Methoden und Werkzeuge, mit denen Machine-Learning-Modelle automatisiert bereitgestellt, überwacht und nachtrainiert werden, also das, was DevOps für Software ist, erweitert um Daten und KI-Modelle.

Der konkrete Nutzen zeigt sich an zwei Hebeln:

• Verkürzte Durchlaufzeiten. Ohne passende Infrastruktur erfordert jeder Schritt Wochen an manueller Arbeit: vom Prototyp in den Betrieb, von einem aufgetretenen Fehler der KI-Anwendung zur „Version 2“. Mit eingerichteter MLOps-Umgebung schrumpft derselbe Durchlauf auf wenige Klicks plus die reine Laufzeit der Pipelines. Ein Modellupdate ist damit kein Projekt mehr, sondern ein Vorgang.
• Beherrschbarkeit paralleler KI-Anwendungen. Laufen alle Anwendungsfälle über dasselbe Standardvorgehen und denselben Plattform-Stack, bleibt jederzeit sichtbar, welches KI-Modell in welchem Zustand ist, worauf es trainiert wurde und wer es freigegeben hat. Ohne diese gemeinsame Basis wird jedes Projekt ein Einzelfall mit eigener Werkzeugkette. Genau daran scheitert die Skalierung über den zweiten oder dritten Anwendungsfall hinaus.

Die Erfahrung zeigt: oft sind keine weiteren Deployment-Werkzeuge gesucht, sondern systemische Fähigkeiten. Daraus folgt ein anderes Verständnis von MLOps in der Fertigung: weg vom passiven Code-Repository, hin zu einer aktiven Infrastruktur, die Standardabläufe, semantischen Datenkontext und Qualitätsgates über die IT/OT-Grenze hinweg tatsächlich durchsetzt. Das hat eine Grenze. Software ersetzt keine organisatorische Abstimmung; sie kann sie an den Integrationspunkten erzwingen und ermöglichen.

Der technische Grund, warum das überhaupt nötig ist, heißt Drift: Ein KI-Modell altert, sobald sich die Realität ändert, etwa durch Werkzeugverschleiß, einen neuen Materiallieferanten oder einen geänderten Produktmix. Software verhält sich morgen so wie heute, ein KI-Modell nicht.

Wie können Unternehmen KI-Governance praxisnah umsetzen und zugleich die Anforderungen des EU AI Acts berücksichtigen?

Lukas Rauh: Praxisnahe KI-Governance beginnt mit einem Verzeichnis: Wer nicht weiß, welche KI-Systeme im Unternehmen laufen, kann weder steuern noch nachweisen.

Vier Schritte, die sich in der Fertigung bewährt haben:

1. Inventar anlegen. Jedes KI-System mit Zweck, Datenquellen, Verantwortlichem und betroffenen Personen erfassen.
2. Risiko einstufen. Die gute Nachricht für die Fertigung: Die meisten Anwendungen wie Qualitätsprüfung, Prognose und Instandhaltungsassistenz fallen nicht unter „Hochrisiko“. Kritisch wird es dort, wo KI eine Sicherheitsfunktion einer Maschine übernimmt oder in der Personalauswahl eingesetzt wird.
3. Freigabeprozess definieren. Wer darf ein KI-Modell in den Betrieb geben, auf welcher Grundlage, mit welcher Dokumentation.
4. Menschliche Aufsicht festlegen. Konkret: Bei welchem Konfidenzwert entscheidet das System, ab wann der Mensch.

Dass dieses Thema drückt, war in der Studie deutlich: Regulatorische und Compliance-Unsicherheit war die meistgenannte Hürde im externen Umfeld, vor allem Konflikte mit dem Datenschutz und unklare Dokumentationsanforderungen. Bemerkenswert ist, dass die Unsicherheit über die Anforderungen dabei schwerer wog als die Anforderungen selbst.

Genau das beschreibt die Lage beim EU AI Act treffend. Ein Teil der Pflichten gilt bereits, etwa das Verbot bestimmter Praktiken, die Förderung von KI-Kompetenz und Transparenzpflichten beim Einsatz von KI. Die Anforderungen an Hochrisiko-Systeme, die für die Fertigung vor allem bei sicherheitsrelevanten Maschinenfunktionen und bei Personalanwendungen greifen, sind dagegen erst in Zukunft verbindlich und werden derzeit noch konkretisiert. Für die Praxis heißt das: jetzt anfangen. Inventar, Risikoeinstufung und Dokumentation sind ohnehin nötig und lassen sich in Ruhe aufbauen. Wer sie erst unter Fristendruck nachzieht, zahlt doppelt.

Governance gehört dabei in den Arbeitsablauf und nicht nachträglich darüber. Wer sie über eine KI-Plattform abbildet, bekommt den Nachweis weitgehend nebenbei: Versionierung, Freigaben und Trainingsstände sind dann dokumentiert und müssen nicht rekonstruiert werden. Governance und MLOps gehören deshalb in dasselbe Projekt.

Wie lassen sich KI-Systeme nach dem Go-live zuverlässig überwachen, warten und kontinuierlich verbessern?

Lukas Rauh: Wirksames Monitoring von KI-Systemen setzt an der Umgebung an: an Material, Produkt, Anlage und Prozess. Vier Mechanismen greifen dabei ineinander:

• Anlassbezogene Prüfung bei Umgebungsänderungen. Neues Material, geändertes Produkt, Umbau an der Anlage, getauschte Kamera oder Beleuchtung: Jede dieser Änderungen ist ein Prüfanlass, unabhängig vom Kalender. Ein starrer Monatsrhythmus greift zu kurz.
• Modellinterne Konfidenzwerte. Viele KI-Modelle geben zu jeder Ausgabe einen Konfidenzwert an. Dessen Verlauf lässt sich automatisiert überwachen und ist oft das früheste verfügbare Signal.
• Rückmeldung aus dem Werk. Die Möglichkeit, direkt im System eine Auffälligkeit zu melden, wird als Monitoring-Kanal regelmäßig übersehen. Wer an der Anlage steht, merkt Fehlverhalten vor jeder Kennzahl, vorausgesetzt, es gibt einen Weg, das ohne Umweg zu hinterlegen.
• Kontextabgleich mit Produktionsdaten. In einer weitgehend digitalisierten Fabrik lässt sich vieles aus dem Zusammenhang ableiten. Springt die Quote des von der KI markierten Ausschusses, muss dieser Sprung gegen den Fabrikkontext geprüft werden. Neue Charge, anderer Lieferant, Werkzeugwechsel? Erst dieser Abgleich zeigt, ob das KI-Modell falsch liegt oder die Produktion.

Dazu kommt eine organisatorische Festlegung: ein definierter Rückfallmodus. Ein KI-System ohne geklärte Antwort auf die Frage, was passiert, wenn es abgeschaltet wird, gehört nicht in die Produktion.

Mit welchen konkreten Schritten können Unternehmen einen KI-Anwendungsfall innerhalb der nächsten drei Monate in Richtung Produktivbetrieb bringen?

Lukas Rauh: Drei Monate reichen nicht für ein fertiges Produktivsystem, aber sie reichen, um einen Anwendungsfall entscheidungsreif zu machen, also die Frage „Tragen Daten und Nutzen?“ belastbar zu beantworten.

Wochen 1–2: Fall, Messgröße und Verantwortung festlegen. Anwendungsfall auswählen, bei dem die Daten bereits anfallen und der Nutzen bezifferbar ist. Zielgröße und Abbruchkriterium schriftlich festhalten. Und die Runde vollständig besetzen: Produktion, Dateneigner und IT von Anfang an, nicht erst nach der Machbarkeit.

Wochen 3–6: Sichtbarkeit und Datenrealität prüfen. Zuerst: Ist das Problem in den Daten überhaupt erkennbar? Kann ein erfahrener Mensch den Fehler zuverlässig labeln? Parallel die Daten automatisiert erfassen statt zu exportieren, und die Zuordnung über Abteilungsgrenzen hinweg klären. Am Ende steht eine ehrliche Aussage darüber, was tatsächlich ankommt.

Wochen 7–10: KI-Modell und Einbindung parallel. Modell-Prototyp entwickeln und gleichzeitig klären, wo die Ausgabe landet: Anlagensteuerung, Werkerterminal, Dashboard. Ein Ergebnis, das niemand an seinem Arbeitsplatz sieht, verändert nichts.

Wochen 11–12: Schattenbetrieb. Das System läuft mit, entscheidet aber nicht. Vorhersagen werden gegen die Realität protokolliert. Am Ende steht eine belastbare Zahl statt einer Demo.

Nach drei Monaten ist die Machbarkeit geklärt, nicht der Betrieb. Der Übergang in den Produktivbetrieb mit IT-Sicherheit, Betriebskonzept und Governance ist ein eigener Abschnitt und dauert erfahrungsgemäß länger als die Machbarkeit. Wer das von Anfang an einplant, vermeidet den häufigsten Projektverlauf: einen überzeugenden Prototyp, der nie in Betrieb geht.

Quellen zu den genannten Zahlen

• Rauh, L.; Schel, D.; Bauernhansl, T.: „Industry Voices on AI Operationalization: Uncovering Socio-Technical Barriers and Implications in Manufacturing“, APMS 2026, Bergamo (Veröffentlichung in Vorbereitung). Explorative qualitative Expertenstudie, N = 16; die genannten Verhältnisse beziehen sich auf codierte Sinneinheiten, nicht auf Effektstärken.
• Gartner, AI in Organizations Survey (2019): rund 53 % der KI-Projekte schaffen den Übergang in die Produktion.
• S&P Global Market Intelligence, Voice of the Enterprise: AI & Machine Learning (2025), Befragung von über 1.000 Unternehmen: im Schnitt 46 % der Proof-of-Concepts vor dem Produktivbetrieb verworfen.
• R. Peres et al., „Industrial Artificial Intelligence in Industry 4.0 - Systematic Review, Challenges and Outlook“, IEEE Access, 2020 (Einordnung der Hürde bei TRL 5–6).
• Verordnung (EU) 2026/1744 (Digital Omnibus), in Kraft seit 27. Juli 2026: Verschiebung der Hochrisiko-Pflichten auf den 2. Dezember 2027 (Anhang III) bzw. 2. August 2028 (Anhang I).