
Governance für KI-Apps im Shopfloor: freigegeben, versioniert, reversibel
Artikel teilen
Kurze Antwort: Eine KI-generierte Shopfloor-App wird erst dann produktionssicher, wenn sie zwei getrennte Kontrollebenen durchläuft: die üblichen Software-Lifecycle-Prüfungen, die jede Produktivänderung benötigt (Versionierung, Audit-Trail, rollenbasierter Zugriff), und die KI-spezifischen Prüfungen, die nur deshalb gelten, weil eine KI die Logik zusammengesetzt hat (Freigabe, bevor irgendetwas läuft, sofortiges Rollback, ein namentlich benannter Mensch, der für die Entscheidung verantwortlich ist). Die meisten Hersteller haben die erste Ebene über Jahrzehnte MES- und QMS-Disziplin aufgebaut. Fast keiner hat die zweite aufgebaut, und genau deshalb bleiben KI-Prototypen vor der Linie stecken.
Warum das wichtig ist
Jedes Werk, mit dem wir sprechen, erzählt dieselbe Geschichte. Ein Ingenieur oder ein Prozessexperte hat an einem Nachmittag mit einem KI-Tool etwas Nützliches gebaut: ein Skript zur Fehlererkennung, einen Generator für Rüst-Checklisten, einen Chatbot, der Fragen zu Drehmomentvorgaben beantwortet. Es funktioniert in der Demo und bleibt dann stecken, bevor es je die Linie erreicht.
Der Grund ist eine einzige unbeantwortete Frage, nicht die Genauigkeit des Modells: Wenn diese KI-gebaute Logik ein Förderband steuert, eine Qualitätssperre auslöst oder einen Arbeitsauftrag weiterleitet, wer hat sie freigegeben, wer kann sie zurückrollen, und wer ist verantwortlich, wenn sie falschliegt? Auf einem Büro-Laptop spielt diese Frage kaum eine Rolle. Auf einer Produktionslinie, wo eine fehlerhafte Änderung einen Ausstoß im Wert von mehreren Hunderttausend Euro pro Stunde stoppen kann, ist sie die einzige Frage, die zählt.
Hersteller wissen längst, wie sie diese Frage für gewöhnliche Software-Änderungen beantworten. Jahrzehnte an MES- und QMS-Disziplin haben Change Control, Zugriffsrollen und Audit-Trails zum Standard gemacht. Was fehlt, ist die zweite Hälfte der Antwort: die Kontrollen, die speziell für KI-generierte Logik gelten, denn ein KI-Modell, das einen Workflow zusammensetzt, ist kein vergleichbares Risiko zu einem Ingenieur, der eine einzige Konfigurationszeile schreibt. Produktionssichere KI für die Fertigung zu bauen bedeutet, beide Hälften zu bauen, nicht anzunehmen, dass die erste Hälfte die zweite abdeckt.
Was Governed App Execution ist
Governed App Execution lebt in der Schicht rund um das Modell, nicht in ihm selbst: ein Freigabeschritt, bevor irgendetwas live geht, eine Versionshistorie für jede Änderung, ein sofortiger Rollback-Pfad und eine vollständige Aufzeichnung, was lief, wann und wer es autorisiert hat.
Diese Unterscheidung ist wichtig, weil die beiden Risikoebenen tatsächlich unterschiedliche Probleme sind. Die erste Ebene verwaltet schon jedes Software-Deployment: Hat jemand diese Änderung geprüft, können wir sie später auditieren, können wir sie rückgängig machen, wenn sie falsch ist. Die zweite Ebene existiert nur, weil eine KI die Logik zusammengesetzt hat statt eines Menschen, der sie direkt eingegeben hat: Verhält sich die Ausgabe der KI vorhersehbar, ist sie aus Bausteinen zusammengesetzt, die bereits als sicher erwiesen sind, und trifft weiterhin ein Mensch die Entscheidung, bevor sie einen laufenden Prozess berührt. Ein Werk, das nur die erste Ebene gelöst hat, trägt weiterhin ein ungesteuertes Risiko, sobald jemand ein KI-Tool auf ein Shopfloor-Problem ansetzt.
Was macht eine KI-generierte App auf einer Fertigungslinie produktionssicher?
Eine KI-generierte App ist produktionssicher, wenn sie eine laufende Linie nur nach einer menschlichen Freigabe erreichen kann, wenn jede Version, die je gelaufen ist, aufgezeichnet und wiederherstellbar ist, und wenn das Zurücksetzen auf den letzten funktionierenden Stand Sekunden dauert statt eines Wartungsfensters. Diese drei Eigenschaften entscheiden, ob ein KI-gebauter Workflow auf einen Shopfloor gehört, weit mehr als die Komplexität des Modells.
Diese Hürde ist höher, als es klingt, denn das übliche KI-Deployment-Muster behandelt „das Modell hat ein korrektes Ergebnis geliefert“ als Ziellinie. Auf einem Shopfloor ist ein korrektes Ergebnis erst der Ausgangspunkt. Die folgende Frage ist, ob sich dieses Ergebnis stoppen, umkehren oder auditieren lässt, nachdem es bereits begonnen hat zu verändern, was eine Maschine oder ein Mitarbeiter tut. Ein Qualitätsprüf-Skript, das zu 98 % korrekt arbeitet, aber keinen Rollback-Pfad hat, ist ein größeres Produktionsrisiko als eines mit 90 % Trefferquote, das sich in Sekunden zurücksetzen lässt, denn gemessen werden die Kosten des seltenen Fehlentscheids, nicht der Durchschnittsfall.
Wie funktionieren Versionierung und Rollback bei KI-gebauten Shopfloor-Apps?
Versionierung funktioniert bei einer KI-gebauten App genauso wie bei jeder anderen Produktivsoftware: Jede Änderung wird als eigene, zeitgestempelte Version gespeichert, und die Rückkehr zu einer früheren Version ist ein einzelner Klick statt eines Neuaufbaus. Der Unterschied bei KI-generierter Logik liegt darin, wie oft diese Fähigkeit genutzt wird, denn ein KI-Tool macht es trivial einfach, eine neue Version zu erzeugen, wodurch der Rollback-Pfad deutlich häufiger beansprucht wird als in einem klassischen Change-Management-Zyklus.
In der Praxis bedeutet das: Ein Werk benötigt dieselbe Disziplin, die MES-Anbieter seit Jahren auf Firmware- und Rezeptmanagement anwenden, jetzt angewendet auf KI-generierte Workflows: jede veröffentlichte Version aufbewahrt, abrufbar und ohne Support-Ticket wiederherstellbar. Wenn eine KI-generierte Qualitätsprüfung in der Nachtschicht um 2 Uhr beginnt, gute Teile als defekt zu markieren, ist die Lösung kein unter Druck ausgerollter Hotfix. Es ist die Rückkehr zu der Version, die eine Stunde zuvor lief und nachweislich korrekt funktionierte, während jemand die neue Version in Ruhe untersucht.
Wer gibt einen KI-generierten Workflow frei, bevor er live geht?
Ein Mensch, der für die Linie verantwortlich ist, gibt ihn jedes Mal frei, ohne Ausnahme dafür, wie der Workflow entstanden ist. Der Freigabeschritt existiert genau deshalb, weil eine KI die Logik zusammengesetzt hat statt eines Menschen, der sie direkt geschrieben hat, und eine menschliche Entscheidung aus diesem Schritt zu entfernen ist die eine Abkürzung, die den gesamten Governance-Fall zunichtemacht.
Hier kommt auch der stärkste Widerstand gegen KI-generierte Shopfloor-Tools her, und das aus gutem Grund: Wer für die Verfügbarkeit einer Linie verantwortlich ist, hat schon genug „innovative“ Software ausrollen sehen, um zu wissen, dass das Vertrauen eines Anbieters in ein Modell nicht dasselbe ist wie das eigene Vertrauen in einen Prozess. Ein Freigabe-Gate, das sich nicht umgehen lässt und protokolliert, wer was wann freigegeben hat, beantwortet diesen Einwand direkt. Statt den Linienverantwortlichen zu bitten, der KI zu vertrauen, bittet es ihn, eine Änderung nach der anderen zu prüfen, genau wie er es bei jeder anderen Änderung an seinem Prozess bereits tut.
Wie passt das in den Zeitplan des EU AI Act?
Der EU AI Act gilt weiterhin für KI, die auf einer Fertigungslinie Produktions-, Qualitäts- oder Sicherheitsentscheidungen trifft, aber der Durchsetzungskalender hat sich verschoben. Verordnung (EU) 2026/1744, der Digital Omnibus on AI, der am 27. Juli 2026 in Kraft trat, hat die Hochrisiko-Pflichten für eigenständige Annex-III-Systeme (das betrifft die meisten Fertigungsanwendungen, die Aufgaben verteilen, Leistung überwachen oder die Fähigkeiten von Mitarbeitern bewerten) auf den 2. Dezember 2027 verschoben, und die Pflichten für KI, die in bereits regulierte Produkte eingebettet ist, auf den 2. August 2028. Die Transparenzpflichten nach Artikel 50 wurden dagegen nicht verschoben und gelten bereits seit dem 2. August 2026.
Der Aufschub ist kein Grund zu warten. Die Konformitätsbewertung erfolgt vor dem Einsatz, das heißt: Alles, was ein Hersteller Ende 2027 für einen Hochrisiko-Anwendungsfall live schalten will, muss schon lange vorher konform gebaut sein, statt es nachträglich an eine Frist anzupassen, die schneller kommt, als sich ein Compliance-Programm von Grund auf aufbauen lässt. Die Governance-Kontrollen, die dieser Beitrag beschreibt, menschliche Freigabe bei jeder folgenreichen Entscheidung, ein vollständiger Audit-Trail, versionierte und reversible Änderungen, sind zugleich die zentralen Hochrisiko-Anforderungen des EU AI Act. Diese Arbeit fällt so oder so an. Der einzige Unterschied ist, ob sie unter Zeitdruck passiert oder davor.
Verändert gesteuertes KI-App-Building die Rolle der IT, oder ersetzt es sie?
Gesteuertes KI-App-Building verändert die Rolle der IT: weg vom Bau jeder einzelnen Shopfloor-Lösung, hin zur Freigabe und Steuerung der Lösungen, die von den Teams gebaut werden, die dem Problem am nächsten sind. In einem gesteuerten Prozess verschiebt sich die Position der IT vom Engpass zum Kontrollpunkt: Sie prüft, was ein KI-Tool erzeugt, bevor es eine Linie erreicht, statt das einzige Team zu sein, das überhaupt etwas erzeugen kann.
Diese Umdeutung beantwortet den Einwand, KI-natives App-Building sei eine Umgehung der IT, die ein Schatten-IT-Risiko schafft. In einem gesteuerten Setup ist eher das Gegenteil der Fall: Ohne Governance erzeugt bereits jeder Ingenieur mit einem KI-Tool informell Shopfloor-Logik, ohne Prüfung und ohne Aufzeichnung, und genau das ist das eigentliche Schatten-IT-Risiko. Ein formaler Build-und-Freigabe-Prozess gibt der IT Sichtbarkeit auf etwas, das ohnehin passiert ist, nur bisher undokumentiert.
Zwei Governance-Ebenen, nicht eine
| Ebene | Was sie prüft | Wogegen sie schützt |
|---|---|---|
| Software-Lifecycle-Kontrollen | Versionshistorie, Audit-Trail, rollenbasierter Zugriff, Rollback | Eine schlecht geprüfte Änderung, unabhängig davon, wer oder was sie verfasst hat |
| KI-spezifische Kontrollen | Menschliche Freigabe, bevor irgendetwas läuft, deterministische und auditierbare Ausgabe, ein namentlich benannter verantwortlicher Freigeber | Einen KI-komponierten Workflow, der sich im Live-Betrieb unvorhersehbar verhält |
Ein Werk, das nur die erste Ebene gelöst hat, hat das Problem gelöst, das Softwareanbieter schon lösen, seit KI überhaupt ein Thema war. Die zweite Ebene ist die neue, und genau sie überspringen die meisten KI-Piloten, weshalb sie im Sandkasten stecken bleiben, statt die Linie zu erreichen.
Kundenreferenzen
Das Governance-Argument trägt nur, wenn die zugrunde liegende Execution Layer bereits im Produktivbetrieb läuft, unter echtem Audit- und Compliance-Druck, bei Herstellern, die sich keinen Stillstand leisten können. Die Plattform von Workerbase läuft heute bei Kunden wie Bosch, Porsche, Siemens und thyssenkrupp, in denselben IATF- und ISO-gesteuerten Umgebungen, in denen jede KI-gebaute Anwendung operieren müsste.
Bei Porsche, wo digitale Workflows die manuelle Koordination über Produktion und Logistik hinweg abgelöst haben, beschreibt Dr. Jochen Breckner, Mitglied des Vorstands für Finanzen und IT, das Ergebnis auf Vorstandsebene: „Our collaboration with Workerbase is the perfect example of this journey: Digital workflows replace manual processes. Orchestrating employees, processes, and vehicles in real time. Seamlessly integrating IT without costly migration. Seven-figure annual savings and fewer line downtimes. Complete transparency across the entire value chain.“
Bei thyssenkrupp Rasselstein, wo eine einheitliche Oberfläche mehrere Legacy-Systemoberflächen abgelöst hat, berichtet CTO Oliver Hoffmann von einer Produktivitätssteigerung der Mitarbeiter um 12–15 % und einem Sog nach weiteren Use Cases, der vom Shopfloor selbst kam, nicht von oben verordnet: „Ich erlebe selten digitale Lösungen mit so starkem Pull vom Shopfloor. Unsere Teams fragen aktiv danach, Workerbase umzusetzen, weil sie sehen, dass es funktioniert.“ Genau diese interne Nachfrage ist das Muster, für dessen sicheren Umgang ein gesteuerter KI-Build-Prozess gebaut ist: mehr Anfragen für neue Workflows, geleitet durch ein einziges Freigabe-Gate statt durch einen wachsenden IT-Rückstau.
Häufig gestellte Fragen
Ist KI-generierter Code sicher für den Einsatz auf einer Fertigungslinie?
Nicht für sich allein. KI-generierte Logik wird erst dann sicher für eine Linie, wenn sie dieselben Kontrollen durchläuft, die jede Produktivänderung erfordert, Versionshistorie, Audit-Trail, Zugriffsrollen, plus einen menschlichen Freigabeschritt speziell für KI-Ausgaben. Generischer KI-generierter Code ohne Governance-Schicht drumherum ist genau das Muster, das Prototypen im Sandkasten festhält.
Was verlangt der EU AI Act von KI, die in der Fertigung eingesetzt wird?
Für KI-Systeme, die nach Annex III als Hochrisiko eingestuft sind, wozu die meisten KI-Anwendungen zählen, die Aufgaben verteilen, die Leistung von Mitarbeitern überwachen oder Fähigkeiten bewerten, gelten die zentralen Pflichten (Risikomanagement, technische Dokumentation, Protokollierung, menschliche Aufsicht, Konformitätsbewertung, Registrierung) ab dem 2. Dezember 2027, gemäß Verordnung (EU) 2026/1744. Die Transparenzpflichten nach Artikel 50 galten bereits früher, ab dem 2. August 2026. Die Konformitätsbewertung erfolgt vor dem Einsatz, konforme Systeme müssen also deutlich vor dem Termin 2027 gebaut werden.
Wer ist verantwortlich, wenn ein KI-gebauter Workflow einen Fehler verursacht?
Der Mensch, der den Workflow vor dem Livegang freigegeben hat, weshalb das Entfernen dieses Freigabeschritts die eine Änderung ist, die das gesamte Governance-Modell zunichtemacht. Ein gesteuerter Prozess protokolliert, wer jede Version freigegeben hat, sodass Verantwortlichkeit nachvollziehbar ist statt angenommen.
Lässt sich eine KI-gebaute Shopfloor-App zurückrollen, wenn sie falsch liegt?
Ja, wenn von Anfang an Versionierung eingebaut wurde. Jede veröffentlichte Version sollte abrufbar sein, und die Rückkehr zum letzten funktionierenden Stand sollte Sekunden dauern, nicht ein Wartungsfenster oder ein Support-Ticket. Ohne gespeicherte Versionshistorie gibt es nichts, zu dem man zurückkehren könnte.
Benötigt der Bau von Shopfloor-Apps mit KI Data Scientists im Operations-Team?
Nein. Die Prozessexperten, die den Workflow bereits verstehen, beschreiben in einfacher Sprache, was sie benötigen, und die entstehende Anwendung durchläuft denselben Prüf- und Freigabeprozess wie jede andere Änderung. 85 % der Workerbase-Deployments werden direkt von Operations-Teams konfiguriert, ohne Entwickler im Prozess.
Was unterscheidet das von einem Ingenieur, der mit ChatGPT oder Copilot prototypt?
Ein Prototyp, der mit einem generischen KI-Tool gebaut wurde, hat keinen Weg auf eine laufende Linie: kein Freigabe-Gate, keine Versionshistorie, kein Audit-Trail, und nichts, das ihn vor dem Einsatz gegen eine zertifizierte Menge fertigungstauglicher Bausteine prüft. Gesteuertes KI-App-Building ergänzt genau diese Schicht, sodass dieselbe prompt-getriebene Geschwindigkeit die Linie erreicht, statt im Sandkasten zu bleiben.
Was ist laut Herstellern die größte Hürde, um KI über ein Pilotprojekt hinaus zu skalieren?
Qualifikationslücken, Datenqualität und regulatorische Komplexität sind die am häufigsten genannten Hindernisse, laut dem OECD-Bericht 2026 zu KI in der Fertigung. Ein gesteuerter Build-Prozess löst die Qualifikationslücke direkt, denn dadurch entfällt die Notwendigkeit eines Data-Science-Teams auf der operativen Ebene. Er ersetzt jedoch keine sauberen Quelldaten oder einen klaren Compliance-Verantwortlichen.
Wächst die KI-Einführung in der Fertigung tatsächlich, oder bleibt es bei Pilotprojekten?
Sie wächst über die Pilotphase hinaus. 47 % der Hersteller setzen inzwischen KI im Produktivbetrieb ein, im Vergleich zu 33 % im Vorjahr, laut der Octave-Umfrage „Pulse of Quality in Manufacturing 2026“. Der Markt zeigt denselben Trend: KI in der Fertigung wird 2025 auf rund 34 Mrd. USD geschätzt und soll bis 2030 auf 155 Mrd. USD wachsen, eine jährliche Wachstumsrate von 35 %, laut MarketsandMarkets.
Drei Fähigkeiten machen das in der Praxis konkret. Das Bauen der Anwendung selbst ist der Teil, den die meisten KI-Tools bereits gut beherrschen. Die Governance-Schicht darum herum ist das, was die meisten davon auslassen. Die Workflow-Logik, die die Anwendung antreibt, Freigaben, Eskalationen, Aufgabenverteilung, ist genau die Ebene, die versioniert und auditierbar sein muss, wenn eine KI sie generiert hat. Und für einen genaueren Blick darauf, wie sich eine prompt-gebaute App von beliebigem KI-generiertem Code auf einer laufenden Linie unterscheidet, siehe warum Vibe-Coding-Anwendungen Governance benötigen, bevor sie einen Shopfloor erreichen und das größere Bild zu KI-Governance in der Fertigung.
Für Hersteller, die schon weiter sind, zeigen fünf konkrete KI-Agenten, die heute bereits auf Shopfloors laufen und eine Übersicht generativer KI-Anwendungsfälle in der Fertigung, wie gesteuertes KI-Building nach der Pilotphase aussieht, zusammen mit dem breiteren Wandel hin zur KI-gestützten Shopfloor-Digitalisierung und dem Argument für gesteuerte Shopfloor-Apps auf einer Execution Layer, der Hersteller bereits vertrauen.
Wenn die Frage im Raum steht, wie Sie Ihre eigenen KI-generierten Prototypen über den Sandkasten hinausbringen und sie für eine Fertigungslinie wirklich produktionssicher machen, reicht ein 30-minütiges Gespräch, um zu verorten, wo Ihre aktuellen Freigabe- und Versionskontroll-Lücken im Vergleich zu dem liegen, was eine laufende Linie tatsächlich verlangt.