Wie Sie KI in der Fabrik nutzen, ohne Ihr Budget zu sprengen

Willkommen bei IT for Business. Ich bin Mirko Peters. Wir arbeiten als IT-Dienstleister für den Mittelstand und hier geht es nicht um Marketing-Hype, sondern um echte Entscheidungen in der IT. Wir sprechen über Infrastruktur, Cloud-Migrationen und Security aus der Praxis. Wenn Sie Verantwortung für die IT tragen oder Dienstleister bewerten müssen, sind Sie hier genau richtig. Vernetzen Sie sich auch gerne mit mir auf LinkedIn, denn ich schätze den direkten Austausch über reale Projekte sehr.

Lassen Sie uns kurz das Rauschen ausblenden. Wenn wir über KI in der Fertigung sprechen, reden fast alle über Modelle oder Copiloten. Erstaunlich wenige sprechen dagegen über Ausschuss, Stillstand und den massiven Aufwand im Betrieb, der nach dem Pilotprojekt erst richtig anfängt. Genau dort versteckt sich aber das eigentliche Risiko für Ihr Budget.

In dieser Folge schauen wir uns an, wo KI in der Fabrik wirklich Geld verdient und wo sie nur Kapital bindet. Wir blicken dabei bewusst auf die Realität im Mittelstand, also auf Brownfield-Anlagen, knappe Personalressourcen und eine laufende Produktion ohne Spielraum für Experimente. Bleiben Sie kurz dran, denn der teuerste Fehler passiert oft schon, bevor Sie überhaupt ein Tool auswählen.

Warum KI-Projekte in der Fertigung oft am Budget scheitern

Seien wir ehrlich: In den meisten Fällen sprengt nicht die KI-Technik an sich das Budget. Die Rechnung beginnt viel früher bei einer schlechten Ausgangslage, die man beim Projektstart gerne ignoriert, weil die Demo auf den Folien so sauber wirkt. Was dann in der Realität fehlt, ist selten nur ein schlaues Modell. Es fehlt am sauberen Datenzugriff und an einer klaren Architekturverantwortung. Wenn Maschinendaten lokal liegen und Prozessdaten in einem anderen System stecken, während wichtige Infos in Excel gepflegt werden, bauen Sie kein tragfähiges Vorhaben. Sie bauen stattdessen teure Umwege, die später jeden kleinen Schritt im Betrieb massiv erschweren.

Das sehen wir in Fertigungsumgebungen ständig. Eine Anlage liefert Werte in einem speziellen Format, das MES nutzt eine eigene Logik und das ERP kennt zwar den Auftrag, aber nicht den technischen Zustand der Maschine. Dazwischen sitzen dann manuelle Schnittstellen und Skripte, die auf Einzelwissen basieren. Auf dem Papier wirkt das alles verbunden, aber im täglichen Betrieb ist diese Konstruktion extrem brüchig.

Jetzt wird es interessant, denn hier liegt der Unterschied, über den Anbieter ungern sprechen. Im Labor funktioniert fast alles reibungslos, weil die Bedingungen dort künstlich sauber gehalten werden. Es gibt definierte Datensätze, keine Schichtwechsel und keine Störungen aus dem echten Werkalltag. In der Fabrik sieht die Welt anders aus, da Kameras verschmutzen, Teile variieren und Anlagen nicht exakt so stehen wie im Testaufbau. Entscheidungen müssen hier in einen laufenden Prozess passen und nicht in eine schicke Präsentation.

Damit wird aus einer technischen Idee sehr schnell ein handfestes Betriebsproblem. Es geht plötzlich nicht mehr darum, ob ein Modell grundsätzlich etwas erkennt, sondern ob das Ergebnis in der Frühschicht genauso brauchbar ist wie nachts um zwei Uhr. Sie müssen wissen, ob ein Anlagenstillstand korrekt erfasst wird und ob Ihre Mitarbeiter verstehen, warum das System heute anders entscheidet als noch letzte Woche.

Klartext: Das ist keine Technik-Frage, das ist eine Architekturfrage. Wenn zwischen Maschine, ERP und diversen Schattenlisten eine Frankenstein-Integration entsteht, zahlen Sie nicht nur bei der Einführung drauf. Sie zahlen jeden Monat im Betrieb weiter, weil jede kleine Änderung sofort hohen Folgeaufwand nach sich zieht. Jede neue Linie braucht dann wieder eine eigene Sonderlogik und jeder Standort kocht sein eigenes Süppchen.

Hier beginnt das, was viele in der Kalkulation schlicht unterschätzen: die Day-2-Operations. Das ist alles, was nach dem Go-Live niemand mehr spannend findet, aber zuverlässig Geld kostet. Modelle müssen überwacht und die Datenqualität muss permanent geprüft werden. Wenn sich Produkte oder Prozesse ändern, kann das ein komplettes Retraining nötig machen. Dazu kommen Support, Security und die Dokumentation, die oft sträflich vernachlässigt wird.

Überlegen Sie mal: Ein KI-System ist kein klassisches Stück Software, das man einmal installiert und dann einfach vergisst. Wenn sich die Datenbasis verändert, sinkt auch die Güte Ihres Modells. Wenn niemand diesen Betrieb sauber organisiert, läuft das Projekt nur scheinbar stabil, bis die Fachbereiche anfangen, eigene Workarounds zu bauen. Dann bricht das Vertrauen in die Lösung langsam aber sicher weg.

Besonders teuer wird es in der typischen PoC-Falle. Ein kleiner Pilot an einer einzelnen Linie liefert einen guten Effekt und alle sind erst einmal zufrieden. Wenn Sie dann aber skalieren wollen, zeigt sich das Problem: Die Schnittstellen wurden nur lokal gebaut und die Datenbegriffe sind zwischen den Werken überhaupt nicht einheitlich. Der Pilot war also kein Einstieg in eine echte Lösung, sondern nur ein teurer Sonderfall ohne Zukunft.

Wenn Sie Ihr Budget schützen wollen, reicht technische Begeisterung allein nicht aus. Sie müssen Anwendungsfälle wählen, bei denen der wirtschaftliche Schmerz real ist und die technische Grundlage nicht schon beim ersten Rollout auseinanderfällt. Architektur schlägt Tools – stellen Sie deshalb zuerst die harten Fragen, bevor Sie den nächsten Vertrag unterschreiben.

Wo die niedrigen Früchte wirklich hängen

Wenn Sie mit KI in der Fertigung starten wollen, dann bitte nicht dort, wo das Projekt intern am modernsten klingt. Gehen Sie dorthin, wo heute schon jeden Monat Geld verloren geht, weil Fehler zu spät erkannt werden, Abläufe unnötig manuell sind oder Wissen im Betrieb zu lange gesucht werden muss. Seien wir ehrlich – die meisten Unternehmen suchen zuerst die große Vision und übersehen dabei die sauberen, kleinen Hebel direkt vor der eigenen Nase.

Der erste Bereich liegt meist sehr nah: die visuelle Qualitätsprüfung. Das ist nicht interessant, weil Kameras neu wären, sondern weil der wirtschaftliche Schmerz hier absolut klar ist. Ausschuss kostet Material, Maschinenzeit und am Ende oft auch das Vertrauen beim Kunden. Da Nacharbeit Personal bindet, das an anderer Stelle fehlt, entstehen schnell Engpässe in der gesamten Linie. Reklamationen kommen zudem gern erst dann zurück, wenn der eigentliche Verursacher im Prozess längst nicht mehr sauber nachvollziehbar ist. Eine KI-gestützte Sichtprüfung kann hier stabil helfen, sofern Sie ein klar abgegrenztes Merkmal prüfen und das Ergebnis nahtlos in den Ablauf passt. Der Vorteil ist banal, aber wirksam: Das System prüft gleichförmig, es kennt keine müde Spätschicht und keinen hektischen Schichtwechsel. Genau das macht solche Fälle oft wirtschaftlich.

Direkt daneben liegt ein zweites Feld, das gern zu groß gedacht wird: Predictive Maintenance. Viele starten gedanklich sofort bei der komplett vorausschauenden Instandhaltung über das ganze Werk, was im Strategiepapier zwar ordentlich klingt, für den Einstieg aber oft der falsche Weg ist. Sinnvoller ist hier eine „Predictive Maintenance light“. Nehmen Sie wenige kritische Anlagen, bei denen ein ungeplanter Ausfall wirklich weh tut, und arbeiten Sie dort gezielt mit Anomalieerkennung. Also nicht gleich die perfekte Ausfallvorhersage für das nächste Jahr anstreben, sondern erst einmal die saubere Frage klären: Verhalten sich Schwingung, Temperatur, Stromaufnahme oder Laufzeit gerade ungewöhnlich? Das ist deutlich pragmatischer, technisch einfacher umzusetzen und im harten Betriebsalltag meist belastbarer.

Ein drittes Feld wird oft unterschätzt, weil es nicht nach klassischer Fabrik-KI aussieht: Assistenz am Shopfloor. Dabei liegt hier erstaunlich viel Potenzial, gerade in Werken mit hoher Variantenvielfalt, Schichtbetrieb und knappen Fachkräften. Überlegen Sie mal, wie viel Zeit verloren geht, wenn ein Mitarbeiter erst fünf Ordner, alte Tickets und PDF-Dateien durchsuchen muss, um ein wiederkehrendes Fehlerbild einzuordnen. Digitale Arbeitsanweisungen, die kontextbezogen die richtige Information zeigen, oder Schichtprotokolle, die nicht nur abgelegt, sondern auswertbar werden, lösen dieses Problem. Das spart vielleicht nicht spektakulär in einer einzelnen Minute, aber im laufenden Betrieb summiert sich genau dieser Reibungsverlust massiv. Und noch wichtiger: Sie machen sich ein Stück unabhängiger von individuellem Einzelwissen.

Auch in der Logistik und im Materialfluss hängen einige der niedrigsten Früchte. Die Etikettenerkennung ist dafür ein gutes Beispiel. Das klingt unspektakulär, hat aber oft eine sehr klare Wirkung, weil Prozesse im Wareneingang, bei der Zuordnung oder bei internen Umläufen dadurch sauberer und schneller laufen. Dazu kommen Vollständigkeitsprüfungen und einfache Klassifikationen, etwa bei Behältern, Teilen oder Dokumenten. Solche Anwendungen sind selten Prestigeprojekte, aber genau deshalb sind sie interessant. Sie berühren einen eng umrissenen Prozess, liefern schnell messbare Ergebnisse und greifen meist weniger tief in die Produktionssteuerung ein als große Automatisierungsvorhaben.

Ein weiterer Bereich ist die Planung, aber bitte im kleinen Rahmen. Rechnen Sie nicht sofort die komplette Fabrik neu und kaufen Sie nicht direkt den größten Optimierer am Markt ein. Schauen Sie lieber auf Ihre Engpassanlagen und fragen Sie sich, ob einfache Reihenfolgevorschläge helfen können, Rüstwechsel zu senken oder Störungen besser abzufedern. Wenn eine KI-Logik an einer Engpassstelle bessere Vorschläge liefert, dann sehen Sie den Effekt relativ direkt in den Zahlen. Das ist etwas ganz anderes als der Versuch, auf einen Schlag die gesamte Produktionsplanung intelligenter zu machen, da sich dort sonst schnell mehr Komplexität als echter Nutzen versteckt.

Die eigentliche Auswahl ist am Ende ziemlich nüchtern. Gute Einstiegsfälle haben fünf klare Eigenschaften. Erstens: hohe Wiederholung. Wenn ein Vorgang ständig vorkommt, lohnt sich die Verbesserung fast immer. Zweitens: messbare Kosten. Wenn Sie Ausschuss, Prüfzeit oder Störungsfolgen nicht beziffern können, wird der Nutzen schnell zur reinen Glaubensfrage. Drittens: vorhandene Daten oder zumindest Daten, die sich ohne Großumbau erfassen lassen. Viertens: ein begrenzter Prozess, der nicht sofort das halbe Werk berührt. Und fünftens: ein möglichst geringer Eingriff in die OT. Sie wollen schließlich nicht schon im ersten Pilotprojekt an Freigaben, Netzgrenzen und der Maschinenlogik scheitern.

Wenn Ihnen das bekannt vorkommt: Sie sind nicht allein – und es ist lösbar. Genau dort, bei den greifbaren Problemen, würde ich beginnen. Aber ein brauchbarer Use Case allein löst das Problem noch nicht. Sobald zwischen Shopfloor und IT die Grundlage wackelt, wird selbst die sinnvollste Idee unnötig teuer.

Die Architekturfrage, die vor jedem KI-Projekt geklärt sein muss

Bevor Sie über Modelltypen, Anbieter oder Plattformen sprechen, gehört eine andere Frage auf den Tisch: Wo entstehen die Daten eigentlich, wem gehören sie im Betrieb und wer darf sie für welchen Zweck nutzen? Das klingt zunächst nach Governance und damit nach einem trockenen Nebenkriegsschauplatz. In der Praxis entscheidet aber genau das darüber, ob ein KI-Vorhaben sauber läuft oder schon bei der ersten Abstimmung zwischen Produktion, IT und Dienstleister hängen bleibt. Klartext: Architektur schlägt Tools.

Denn Shopfloor und klassische IT folgen nicht denselben Regeln. In der OT zählt zuerst die Verfügbarkeit, die Anlage soll stabil und ohne unnötige Eingriffe laufen. In der IT hingegen ist Veränderung völlig normal, sei es durch Updates, neue Schnittstellen oder neue Auswertungen. Dazu kommt ein zweiter Konflikt: Safety gegen Änderungsdruck. In der Produktion kann eine unbedachte Anpassung reale, physische Folgen haben, während dieselbe Anpassung in der IT oft als Routine gilt. Wenn diese beiden Welten ohne klares Betriebsmodell aufeinandertreffen, entsteht Reibung statt Fortschritt.

Im Mittelstand verschärft sich das durch das Thema Brownfield. Wir reden hier von Anlagen, die über Jahre gewachsen sind, mit alten Steuerungen, proprietären Protokollen und lokalen Sonderwegen. Diese sind oft aus einer pragmatischen Entscheidung heraus entstanden und dann einfach geblieben. Das ist kein Ausnahmefall, sondern vielerorts der Normalbetrieb. Nur wird daraus schnell ein Problem, wenn ein KI-Projekt plötzlich durchgängige Datenflüsse erwartet, die es real so nie gegeben hat. Da versteckt sich das Risiko für jedes Budget.

Was sich in solchen Umgebungen bewährt, ist kein großes Zukunftsbild mit maximaler Zentralisierung. Tragfähig ist meist ein einfaches Muster: Maschine, Kopplungsschicht, Datenplattform. Die Maschine bleibt dort, wo sie hingehört, während die Kopplungsschicht sammelt, puffert, übersetzt und sauber trennt. Erst danach landen die Daten auf einer Plattform, auf der Sie sie auswerten, verknüpfen und für KI nutzen können. Das ist deutlich vernünftiger, als jede Quelle direkt an irgendeinen Cloud-Dienst zu hängen und später überrascht festzustellen, dass man weder Übersicht noch Kontrolle hat.

Lassen Sie uns das kurz zerlegen. Die Kopplungsschicht ist nicht nur Technik zum Verbinden, sie ist auch ein Schutzmechanismus. Dort legen Sie fest, welche Daten überhaupt herausdürfen, in welchem Takt, in welchem Format und mit welcher Absicherung. Gerade bei älteren Anlagen ist das Gold wert, weil Sie die Produktionswelt nicht jedes Mal umbauen müssen, nur weil auf der IT-Seite ein neuer Anwendungsfall auftaucht. Betrachten Sie es wie ein Haus, das renoviert wird: Sie wollen nicht bei jedem neuen Lichtschalter die gesamte Statik angreifen müssen.

Genau an dieser Stelle sitzt auch das Sicherheitsthema. KI darf keine Seitentür ins Produktionsnetz werden. Wenn Sie neue Sensorik, Gateways oder externe Dienste einführen, öffnen Sie potenziell neue Angriffsflächen für Schadsoftware. Das lässt sich beherrschen, aber nicht mit dem Reflex, einfach alles blind zu verbinden, was irgendwie Daten liefert. Sie brauchen Segmentierung, klare Netzgrenzen und saubere Rechte. Anders gesagt: Der Wunsch nach mehr Datenzugriff darf nie wichtiger werden als die Stabilität des Werks.

Dazu kommt ein Punkt, der oft unterschätzt wird: Rohdaten allein haben wenig Wert. Ein Stromwert, ein Kamerabild oder eine Temperaturkurve ist ohne Kontext nur ein Signal im Rauschen. Erst wenn Sie diese Daten mit dem Auftrag, der Charge, der Maschine oder einer konkreten Störung zusammenbringen, entsteht etwas Nutzbares. Sonst trainieren Sie bestenfalls auf Mustern, die technisch interessant wirken, fachlich aber keine belastbare Aussage liefern. Genau deshalb scheitern viele Vorhaben nicht an zu wenig Daten, sondern an zu wenig Kontext.

Darum würde ich die Architektur immer vor die Tool-Auswahl stellen. Nicht, weil Tools unwichtig wären, sondern weil einfache, wiederholbare Bausteine auf Dauer mehr tragen als fünf Speziallösungen. Wenn diese jeweils nur für einen Einzelfall optimiert wurden, ergeben sie zusammen kein Gesamtbild, sondern eine Frankenstein-Integration. Wenn Sie heute schon wissen, dass ein erfolgreicher Pilot später auf weitere Linien oder Standorte ausgerollt werden soll, dann bauen Sie von Anfang an mit derselben Logik: gleiche Schnittstellen, gleiche Datenbegriffe, gleiche Verantwortlichkeiten.

Sobald diese Grundlage steht, wird die Diskussion sachlicher. Dann reden Sie nicht mehr über KI als vages Schlagwort, sondern über einen konkreten Nutzen auf einer belastbaren Basis. Und genau dann lohnt es sich, den nächsten Schritt sauber zu rechnen und klein zu starten, statt groß zu versprechen. Sprechen Sie mit Ihrem Team, bevor Sie unterschreiben – stellen Sie zuerst die harten Fragen, nicht die bequemen.

So rechnen Sie ROI, ohne sich selbst etwas vorzumachen

Sobald die Architekturfrage halbwegs sauber beantwortet ist, kommen wir zu dem Punkt, an dem sich die Spreu vom Weizen trennt. Hier entscheidet sich, ob Ihr Projekt auf einem soliden Fundament steht oder ob Sie sich in die eigene Tasche lügen. Wir reden über die Wirtschaftlichkeit. Und die beginnt eben nicht mit den bunten Hochrechnungen aus einem Anbieter-Deck, sondern mit einer knallharten Baseline aus Ihrem eigenen Betrieb.

Sie müssen zuerst einmal wissen, was der Ist-Zustand Sie heute wirklich kostet. Wie viel Zeit fließt in manuelle Prüfungen, wie hoch ist die Ausschussquote tatsächlich, und wie oft müssen Teile in die Nacharbeit? Überlegen Sie mal, welche Stillstandszeiten Sie so richtig Geld kosten und was Reklamationen am Ende der Kette für Ihren Ruf und Ihr Budget bedeuten. Ohne diese nackten Ausgangswerte lässt sich jeder Pilotversuch wunderbar schönrechnen, weil am Ende niemand belegen kann, ob die Verbesserung real ist oder nur gut präsentiert wurde.

Genau deshalb ist es ein Fehler, den Nutzen abstrakt für das ganze Werk zu kalkulieren. Rechnen Sie lieber pro Linie, pro Engpass oder pro Fehlerklasse. Wenn eine ganz bestimmte Fehlerart regelmäßig die Nacharbeit befeuert, dann ist das Ihr Bezugspunkt. Wenn eine einzelne Anlage bei jeder kleinen Störung den gesamten Materialfluss ausbremst, dann setzen Sie dort an. Alles andere klingt zwar auf dem Papier strategisch wertvoll, hilft Ihnen bei einer harten Investitionsentscheidung aber kein Stück weiter.

Dann gibt es noch einen zweiten Teil, den Sie sauber trennen müssen: CAPEX und OPEX. Also die einmaligen Investitionen gegen die laufenden Kosten. Zur ersten Gruppe gehören typischerweise die Hardware, Kameras, Edge-Geräte und die Integration in Ihre bestehenden Systeme. Auch Anpassungen an Schnittstellen oder externe Berater fallen hierunter. Zur zweiten Gruppe zählen Lizenzen, der laufende Support, das Monitoring und die Wartung der Modelle. Vergessen Sie dabei nicht den internen Aufwand, der im Alltag gerne mal unter den Tisch fällt. Wenn diese beiden Blöcke in einer einzigen Sammelzahl verschwinden, fehlt Ihnen später jede Grundlage, um den Betrieb ehrlich zu bewerten.

Klartext: Gerade bei KI-Projekten liegen die verdeckten Kosten selten dort, wo man zuerst hinschaut. Ein klassischer Kostentreiber ist das Labeling. Jemand muss die Daten sichten, markieren und für das Training überhaupt erst brauchbar machen. Dazu kommt die Datenaufbereitung, denn Rohdaten aus der Fertigung kommen selten fertig sortiert aus der Maschine. Sie müssen bereinigt, zugeordnet und fachlich eingeordnet werden, bevor sie einen Wert haben. Dann folgen noch Freigabeprozesse, Schulungen und Security-Prüfungen. Oft kommen noch Abstimmungen mit der Qualitätssicherung oder dem Betriebsrat dazu. Das ist kein lästiges Beiwerk, sondern das gehört fest in die Kalkulation.

Ein weiterer Denkfehler sitzt oft bei den Personalkosten. Viele Business Cases tun so, als würden eingesparte Minuten automatisch zu einem echten Personalabbau führen. In der Praxis passiert meistens etwas ganz anderes. Die Mitarbeiter werden verlagert, fangen Ausnahmen ab oder übernehmen die Kontrolle des neuen Systems. Oft arbeiten sie auch einfach Rückstände auf, die vorher liegen geblieben sind. Das kann wirtschaftlich absolut sinnvoll sein, nur eben anders, als es auf der bunten Marketing-Folie stand. Wenn Sie diese Verschiebung als volle Einsparung ansetzen, bauen Sie sich die Enttäuschung für das nächste Jahr direkt mit ein.

Viel belastbarer wird Ihre Rechnung, wenn Sie auf die vermiedenen Kosten schauen. Weniger Ausschuss, weniger Nacharbeit und stabilere Prozesse sind harte Währungen. Wenn an einer kritischen Stelle weniger Störungen auftreten, lässt sich das im Fertigungsumfeld meist deutlich ehrlicher greifen als pauschale Aussagen über die allgemeine Produktivität. Das gilt besonders dann, wenn Sie den Nutzen über einige Monate gegen den echten Ausgangswert halten und nicht gegen eine optimistische Erwartungshaltung.

Dazu gehört auch, dass Sie einen Piloten nicht als Prestigeprojekt aufsetzen, sondern als echte Entscheidungsvorlage. Das bedeutet: ein kurzer Zeitraum, ein klar begrenzter Scope und eindeutige KPIs. Legen Sie vorab eine Abbruchregel fest. Wenn der Effekt unter einer bestimmten Schwelle bleibt, stoppen Sie das Ganze. Wenn die Datenqualität nicht ausreicht oder der Eingriff in den Betrieb größer wird als geplant, ziehen Sie die Reißleine oder verkleinern den Scope. Das klingt vielleicht unspektakulär, schützt aber Ihr Budget und vor allem Ihre Glaubwürdigkeit im Unternehmen.

Am Ende des Tages brauchen Sie keine große KI-Erzählung für den Geschäftsbericht. Sie brauchen eine nüchterne Rechnung, die dem harten Alltag im Werk standhält. Und genau daraus ergibt sich dann fast von selbst die nächste Frage: Wie setzen Sie so ein Vorhaben praktisch auf, ohne dass aus einem sauberen Pilotprojekt wieder ein loses Sammelsurium aus teuren Sonderwegen wird?

Ein pragmatischer Fahrplan für den Mittelstand

Wenn Sie das Thema jetzt angehen wollen, brauchen Sie keinen Masterplan mit zwanzig Arbeitspaketen, sondern eine vernünftige Reihenfolge. Erstens: Wählen Sie einen Prozess mit echtem Schmerzfaktor, einem klaren Verantwortlichen und einem begrenzten Umfang. Schreiben Sie nicht „Qualität verbessern“ über das Projekt, sondern suchen Sie sich eine konkrete Prüfstelle oder eine Anlage aus, deren Ausfall regelmäßig hohe Folgekosten verursacht. Solange niemand fachlich wirklich den Hut aufhat, wird das Vorhaben in endlosen Abstimmungsrunden versanden.

Der zweite Schritt ist deutlich nüchterner, als viele IT-Begeisterte hoffen. Prüfen Sie die Datenlage, bevor Sie überhaupt über Lösungen sprechen. Welche Daten gibt es wirklich, wie steht es um die Qualität und wer hat technisch oder rechtlich Zugriff darauf? Zwischen der Aussage „die Daten liegen theoretisch vor“ und „sie sind produktiv nutzbar“ liegt in vielen Werken eine erstaunlich große Lücke. Wenn Zeitstempel nicht zusammenpassen oder Verantwortlichkeiten für die Datenquelle unklar sind, wird aus einem kleinen Piloten ganz schnell ein riesiges Aufräumprojekt.

Danach sollten Sie das Zielbild festlegen und dieses bewusst eng stecken. Wollen Sie ein Assistenzsystem, das den Menschen besser informiert? Geht es um die reine Erkennung von Fehlern oder Abweichungen? Wollen Sie eine Prognose für die Zukunft erstellen oder geht es tatsächlich um die volle Automatisierung? Alles gleichzeitig zu wollen, ist meistens der Anfang vom Ende. Jede dieser Richtungen bringt völlig andere Anforderungen an den Betrieb, das Risiko und die Eingriffstiefe mit sich.

Im vierten Schritt setzen Sie den Piloten so auf, dass Ihr Betrieb nicht zum Versuchslabor wird. Eine Linie, ein Merkmal, ein KPI. Und ganz wichtig: Planen Sie einen Fallback ein, falls das Ergebnis im Alltag nicht trägt. Dieser Plan B ist in der Fertigung lebensnotwendig. Wenn die KI-Unterstützung ausfällt oder unsauber arbeitet, muss der Prozess trotzdem sicher weiterlaufen können. Sonst erzeugen Sie intern genau das Misstrauen, das Ihnen spätere Rollouts komplett blockiert.

Richtig interessant wird es beim fünften Punkt, den viele Teams viel zu spät klären: Wer betreibt das Ganze eigentlich nach dem Piloten? Jemand muss die Ergebnisse überwachen, Qualitätsverluste erkennen und Änderungen am Modell oder am Prozess dokumentieren. Wenn diese Fragen erst nach dem Go-Live auftauchen, landet das Thema irgendwo im Niemandsland zwischen Fachbereich, IT und dem externen Dienstleister. Dann fühlt sich jeder nur noch halb zuständig, und genau an diesem Punkt wird es richtig teuer.

Der sechste Schritt betrifft die Skalierung, aber eben erst, wenn das Fundament steht. Rollen Sie die Lösung nicht aus, nur weil der Pilot technisch irgendwie funktioniert hat. Skalieren Sie nur dann, wenn die Architektur das auch sauber hergibt. Das bedeutet: gleiche Schnittstellen, gleiche Datenlogik und eine einheitliche Governance. Sobald jede weitere Linie wieder zu einem Sonderfall wird, haben Sie keine Lösung gebaut, sondern eine Sammlung lokaler Ausnahmen mit einem gemeinsamen Etikett.

Lassen Sie mich zum Schluss dieses Fahrplans noch einen ganz nüchternen Punkt ansprechen: Manche Prozesse sind für KI schlichtweg noch nicht reif. Das liegt oft nicht an der fehlenden Technologie, sondern daran, dass der Prozess selbst zu uneinheitlich oder schlecht dokumentiert ist. In solchen Fällen bringt eine saubere Standardisierung erst einmal deutlich mehr als jedes neuronale Netz. Das wirkt zwar weniger modern, ist aber oft der ehrlichere und wirtschaftlichere nächste Schritt.

Genau daran entscheidet sich am Ende der Wert eines Vorhabens. Es geht nicht darum, ob das Kürzel KI im Projektplan steht. Es geht darum, ob die Lösung im Werk unter realen Bedingungen zuverlässig ihren Nutzen bringt. Sprechen Sie mit Ihrem Team und stellen Sie diese harten Fragen, bevor Sie den nächsten Vertrag unterschreiben.

Schluss: Gute KI beginnt nicht beim Modell

Das war IT for Business für heute.

Wenn Sie aus diesem Gespräch einen Gedanken mitnehmen, dann hoffentlich diesen: Echte KI-Erfolge in der Fertigung hängen nicht am neuesten Modell. Es geht vielmehr um saubere Prozesse, belastbare Daten und eine Architektur, die auch morgen noch trägt.

Suchen Sie sich mit Ihren Leuten einen konkreten Prozess aus, bei dem Ausschuss oder Stillstand heute schon echtes Geld verbrennen. Bevor Sie starten, müssen Sie die harten Fragen stellen. Klären Sie genau, woher die Daten kommen, wer später den Betrieb verantwortet und wo Ihre Sicherheitsgrenzen verlaufen. Rechnen Sie den ROI nüchtern durch und legen Sie fest, wann Sie einen Piloten auch mal konsequent abbrechen.

Falls Sie gerade eine Modernisierung oder die Kopplung von OT und IT planen, sprechen Sie zuerst über die Architektur. Der teuerste Fehler versteckt sich fast nie im KI-Projekt selbst, sondern in der Infrastruktur, die darunter liegt.