Die meisten agentischen KI-Implementierungen in der Fertigung, die über die Pilotphase hinaus bestehen, sind eng gefasst. Sie befinden sich oberhalb von MES und ERP, generieren Empfehlungen und Arbeitsaufträge zur menschlichen Genehmigung und schreiben niemals in Steuerungssysteme. Marktdaten zeigen, dass Predictive-Maintenance-Agents heute 38 % der agentischen KI-Implementierungen in der Fertigung ausmachen, und die Supply-Chain-Optimierung ist die am schnellsten wachsende Anwendung mit einer prognostizierten CAGR von 30 % bis 2030. Die Akzeptanz konzentriert sich auf spezifische Workflow-Typen, nicht auf breite Autonomie.

Diese Konzentration ist kein Übergangszustand auf dem Weg zu autonomen Fabriken. Es ist die produktionsreife Form der Technologie, und der größte Teil der Arbeit bei ihrer Einführung besteht darin, zu entscheiden, welche Workflows in dieses Muster passen. Die Entscheidung hängt davon ab, ob ein spezifischer Workflow systemübergreifend und ausnahmeintensiv genug ist, um die Integrations- und Überwachungskosten zu rechtfertigen, die ein Agent mit sich bringt. Die meisten Workflows sind es nicht. Die Verwechslung beider führt zu einer fragilen Architektur, Integrationsschulden, die das Operations-Team erbt, und einem probabilistischen System, das zu nah an deterministischer Sicherheitslogik sitzt.

Die Identifizierung, welche Workflows in den engen Bereich gehören, macht den größten Teil der Strategie aus. Der Rest ist Architektur, Governance und die operative Disziplin, den Agenten über der deterministischen Ebene zu halten, wo er hingehört.

Was agentische KI in der Fertigung bedeutet

Ein agentisches System in der Fertigung ist ein kontextsensitives KI-System, das Produktionssignale überwacht, Betriebsbedingungen interpretiert, den nächsten geeigneten Schritt entscheidet und über Fertigungssoftware-Systeme wie MES, CMMS, ERP, Qualitätsplattformen und Planungstools hinweg agiert.

Der Hauptunterschied zu einem Dashboard oder Analysetool ist die Bereitschaft, über Systeme hinweg zu agieren, die kein gemeinsames Datenmodell teilen, und Ausnahmen zu behandeln, die bei der Workflow-Gestaltung nicht aufgeführt wurden.

Für einen technischen Einkäufer, der bewertet, wo Agents passen, ist es notwendig, sie von bestehenden Technologien zu unterscheiden. Agentische KI ist nicht:

• Ein Dashboard: Es visualisiert nicht nur Daten; es initiiert Reaktionen darauf.
• Ein punktuelles prädiktives Modell: Während ein Modell einen Lagerausfall vorhersagen könnte, koordiniert ein Agent die Ersatzteilabfrage, die Technikerplanung und die Produktionsumleitung.
• Ein Standard-Chatbot: Es ruft nicht einfach Informationen aus Handbüchern ab; es interagiert mit System-APIs, um den Zustand des Workflows zu ändern.
• RPA (Robotic Process Automation): RPA folgt deterministischen "if-this-then-that"-Regeln. Agentische KI nutzt Reasoning, um operative Ausnahmen zu behandeln, bei denen Regeln nicht vordefiniert sind.

Der Wert eines Agenten liegt nicht in seiner Fähigkeit, Aktionen über isolierte Systeme hinweg zu koordinieren. In der Fertigung manifestiert sich dies typischerweise als Large Language Model (LLM)-basierte Agents, die natürlichsprachliche Ziele interpretieren, Legacy-Datenbanken abfragen und ausführbare Arbeitsaufträge oder Terminplanänderungen generieren.

Wann ein Fertigungs-Workflow einen Agenten verdient

Sechs Bedingungen trennen Workflows, die einen Agenten rechtfertigen, von Workflows, die dies nicht tun. Ein Kandidaten-Workflow muss alle sechs bestehen. Das Scheitern an einer dieser Bedingungen bedeutet in der Regel, dass die Engineering-Kosten den operativen Nutzen übersteigen oder dass ein Skript, ein RPA-Bot oder ein Dashboard die Aufgabe besser erledigt.

1. Der Workflow überschreitet mehrere Systeme

Wenn die Entscheidung durch das Lesen eines Systems getroffen werden kann, ist ein Agent überdimensioniert. Der Fall für einen Agenten beginnt, wenn eine einzelne Entscheidung gleichzeitig vom Maschinenstatus aus dem MES, dem Produktionsplan, dem aktuellen Lagerbestand im ERP und der Lieferantenverfügbarkeit abhängt. Die Koordination über Systeme hinweg, die kein gemeinsames Datenmodell teilen, ist der Zweck eines Agenten.

2. Der Entscheidungsraum ist zu groß für statische Regeln 

Ein gutes Ergebnis muss definierbar sein: OEE maximieren bei Einhaltung einer Kundenfrist, Umrüstkosten minimieren bei Abbau eines Rückstands. Der Weg zu diesem Ergebnis sollte es nicht sein. Wenn sich die Constraints mit jeder Schicht ändern und die Kombinationen gültiger Aktionen nicht im Voraus aufgezählt werden können, werden statische Regeln entweder Fälle übersehen oder unpflegbar. Das ist die operative Lücke, die ein Agent füllt.

3. Die Kosten der Verzögerung sind messbar 

Die Integrationskosten eines Agenten sind gerechtfertigt, wenn eine langsame Reaktion einen realen Preis hat: ungeplante Ausfallzeiten, Ausschuss durch Qualitätsabweichungen und beschleunigter Versand, wenn ein Planer zu spät reagiert. Wenn der Workflow wöchentlich läuft und ein paar Stunden Latenz keine Rolle spielen, verdient der Agent seine Baukosten nicht zurück.

4. Der Workflow wiederholt sich oft 

Agents sind teuer in der Integration, beim Prompt Engineering und in der Governance. Diese Kosten amortisieren sich nur bei wiederkehrenden Ausnahmen. Einmalige strategische Entscheidungen werden immer noch besser von menschlichen Analysten gehandhabt. Wiederkehrende operative Ausnahmen wie Störungsreaktion, Wartungs-Triage und Qualitätsuntersuchung sind die Bereiche, in denen sich Agents auszahlen.

5. Die Daten sind bereits nutzbar 

"People Archaeology" ist die Praxis, den einen erfahrenen Ingenieur zu finden, der weiß, wo ein bestimmter Datensatz lebt; es ist der häufigste Grund, warum agentische Projekte ins Stocken geraten. Wenn das Werk keine standardisierten Asset IDs, sauberen Event Logs und digitalisierten Workflow-Systeme hat, ist das erste Projekt kein Agent. Es ist die Dateninfrastruktur, die einen Agenten ermöglicht.

6. Genehmigungsgrenzen sind klar 

Die Organisation muss in der Lage sein, vor Beginn des Pilotversuchs festzulegen, welche Aktionen der Agent autonom ausführt und welche eine menschliche Genehmigung erfordern. Pilotversuche geraten ins Stocken, wenn dies nicht im Voraus entschieden wird: Der Agent generiert Empfehlungen, niemand ist befugt, darauf zu reagieren, und das System produziert Volumen, ohne Entscheidungen zu produzieren.

Die sechs Tests sortieren Use Cases danach, wo Agents sauber passen, wo sie mit Einschränkungen passen und wo die Architektur gegen sie spricht.

Vier agentische KI-Anwendungsfälle in der Fertigung, die die Komplexität rechtfertigen

In Codebridges agentischer KI-Arbeit mit Fertigungskunden bestehen vier Workflows alle sechs Tests sauber. Dies sind die Use Cases, in denen die Technologie heute ihren Platz in Produktionsumgebungen verdient.

1. Reaktion auf Produktionsstörungen

Störungen sind von Natur aus systemübergreifend und zeitkritisch. Eine Verzögerung an einer einzelnen Montagelinie kann zu Fehlallokation von Arbeitskräften, verpassten Lieferfenstern und Lagerbestandsanhäufungen führen.

Die konkreteste Produktionsimplementierung in dieser Kategorie ist heute Boschs Shopfloor Agent, der in mehreren Bosch-Werken, einschließlich des Standorts Bamberg in Deutschland, läuft. Der Agent erfasst Produktions- und Maschinendaten, analysiert Fehlermuster und Protokolle bei Ausfällen, generiert Hypothesen über Ursachen, schlägt spezifische Korrekturmaßnahmen vor und unterstützt die Dokumentation der Fehlerbehebung.

Operatoren an der Linie führen die Aktionen aus; der Agent übernimmt die Reasoning-, Such- und Dokumentationsschritte, die zuvor Ingenieure Stunden manueller Arbeit kosteten. Bosch meldet jährliche Einsparungen von rund 850.000 € pro Werk durch reduzierte Ausfallzeiten und hat die Technologie seit Ende 2025 an externe Fertigungskunden kommerzialisiert – ein Glaubwürdigkeitssignal, dass die internen Ergebnisse der kommerziellen Prüfung standhielten.

Das Muster verallgemeinert sich über die Fehlerbehebung hinaus. Ein Agent, der Störungssignale aus Maschinendaten und Schichtberichten liest, den WIP-Status überprüft und alternative Routings bewertet, erstellt einen Wiederherstellungsplan in Minuten, anstatt der Stunden, die ein Planer manuell benötigt. Kundenlieferzusagen und alle sicherheitsrelevanten Anrufe gehen weiterhin an einen Menschen.

2. Predictive Maintenance und Arbeitsauftrags-Orchestrierung

Predictive Maintenance (PdM) identifiziert, wann ein Fehler auftreten könnte, verwaltet aber nicht die Reaktion. Der Arbeitsaufwand zwischen der Warnung und einer abgeschlossenen Reparatur ist der Ort, an dem der operative Wert liegt: Überprüfung des ERP auf das richtige Ersatzteil auf Lager, Finden eines Technikers mit der Zertifizierung und einem freien Schichtplatz, Planung des Linienstopps, sodass er bei einem Umbau und nicht mitten im Betrieb stattfindet. Das ist auch das, was oft untergeht, wenn die Warnung in einem Posteingang landet.

Siemens' Senseye Predictive Maintenance mit der Maintenance Copilot-Schnittstelle, die bei Sachsenmilch Leppersdorf in Deutschland läuft, schuf das System, das Maschinenzustandsdaten und Betriebslogs erfasst, aus Sensoreingaben lernt, um Ausfälle vorherzusagen, und Empfehlungen über eine generative KI-Schnittstelle bereitstellt, die Wartungsteams in natürlicher Sprache abfragen. Sachsenmilch erweitert die Implementierung nun, um direkt mit SAP Plant Maintenance zu integrieren, sodass vom AI generierte Wartungsbenachrichtigungen automatisch in das Arbeitsauftragssystem übertragen werden. Der Agent schreibt nicht ohne Genehmigung in SAP – die Integration erstellt Entwurfsbenachrichtigungen, die der Wartungsleiter überprüft und freigibt.

Siemens veröffentlicht keine finanziellen Einsparungen auf Werksebene, aber das operative Muster ist auf Branchenebene gut quantifiziert. Das Deloitte Analytics Institute berichtet, dass KI-gesteuerte Predictive Maintenance eine Reduzierung der Wartungskosten um bis zu 25 % und eine Verbesserung der Betriebszeit um 10–20 % ermöglicht, wenn die Alarm-Pipeline mit der Arbeitsauftragsgenerierung und nicht mit Dashboards verbunden ist. Die Verbindung ist das, was den Gewinn erzeugt. Warnungen ohne Orchestrierung sind nur schnellere Wege, um festzustellen, dass etwas kaputt ist.

3. Untersuchung von Qualitätsabweichungen

Qualitätsabweichungen sind kostenintensiv und evidenzlastig. Eine einzelne Fehleruntersuchung zieht Maschinenparameter aus dem Produktionsfenster, Bedienernotizen aus den Schichtprotokollen, Lieferantenlos-Historien aus dem Einkauf und Inspektionsaufzeichnungen aus dem QMS zusammen. Ein erfahrener Qualitätsingenieur verbringt die meiste Triage-Zeit damit, dieses Bild zusammenzustellen, bevor er es analysieren kann.

Ein Agent stellt das Evidenzpaket zusammen: zieht die relevanten Inspektionsaufzeichnungen, zeigt frühere Defekte mit ähnlichen Batch-Parametern oder Lieferantenlosen auf und entwirft eine strukturierte CAPA-Gliederung, die der Ingenieur überprüfen und bearbeiten kann. Dies führt dazu, dass der Triage-Schritt komprimiert wird und der Analyseschritt nicht, was der Punkt ist.

Dies ist das Muster mit den am strengsten dokumentierten Ergebnissen. In der pharmazeutischen Fertigung, wo das Abweichungsmanagement unter GMP reguliert und genau auditiert wird, wurde gezeigt, dass KI-gesteuerte Abweichungs-Workflows die Untersuchungszeit um 50 bis 70 % reduzieren. Die European Federation of Pharmaceutical Industries and Associations identifizierte diese Kategorie in ihrer Position zu KI im Abweichungs- und CAPA-Management 2024 als eine der Anwendungen mit dem höchsten Hebel von LLM-basierten Systemen in der regulierten Fertigung. Der Gewinn ergibt sich aus demselben Mechanismus, der in der diskreten Fertigung funktioniert: Der Agent komprimiert die Evidenzsammlung, nicht die Analyse- oder Freigabeentscheidungen.

In Codebridges Engagements zur Qualitätsuntersuchung bleibt die Architektur diesem Muster treu. Der Agent liest von MES, QMS und dem Lieferantenaufzeichnungssystem, entwirft eine CAPA-Gliederung, die auf der historischen Aufzeichnung ähnlicher Abweichungen basiert, und übergibt das Paket dem Qualitätsleiter mit dem angehängten Reasoning-Trail. Produktfreigabeentscheidungen bleiben beim Qualitätsleiter. Der Agent übernimmt die Zusammenstellungsarbeit, die davor anfällt.

4. Lieferanten- und Produktionsplanungs-Ausnahmenmanagement

Lieferantenstörungen zeigen sich nicht sauber in einem einzigen System. Eine verspätete Lieferbenachrichtigung kommt per E-Mail an. Die nachgelagerten Auswirkungen leben im Produktionsplan. Die Liste der Ersatzmaterialien lebt im ERP. Die Entscheidung, ob man die Güteklasse wechselt und Qualifikationen erneut durchführt, liegt bei der Planung und Qualität.

IBMs kognitive Supply Chain, die in IBMs eigenen globalen Fertigungsbetrieben eingesetzt wird, ist die am gründlichsten dokumentierte Produktionsimplementierung dieses Musters. Das System verbindet Beschaffungs-, Planungs-, Fertigungs- und Logistikdaten nahezu in Echtzeit, integriert ein cloud-basiertes Lieferantenrisikotool, das das Web nach Störungssignalen durchsucht, und reduziert die Zeit, die zur Minderung eines Teilemangels erforderlich ist, von vier bis sechs Stunden pro Teilenummer auf Minuten. Für die Analyse größerer Störungen, wie eines geschlossenen Flughafens oder eines eingeschränkten Lieferanten, hat sich die Reaktionszeit durch Was-wäre-wenn-Simulationen von Tagen auf Minuten verkürzt.

IBM berichtet über kumulierte Einsparungen von 160 Millionen USD aus der Implementierung, die auf reduzierte Lagerkosten, optimierten Versand, Zeitersparnisse und bessere Entscheidungsfindung in der gesamten Supply Chain zurückzuführen sind.

Die Architektur entspricht dem in diesem Artikel beschriebenen Muster. Die Agents erkennen Störungssignale, modellieren die nachgelagerten Auswirkungen und zeigen Minderungsoptionen auf. Beschaffungsteams genehmigen die Aktionen. Microsofts Procurement Agent in Dynamics 365 Supply Chain Management folgt demselben Schema: Lieferantenkommunikation entschlüsseln, identifizieren, welche Produktionsaufträge und Kundenverpflichtungen gefährdet sind, Minderungsmaßnahmen empfehlen, Menschen die Kontrolle über die Entscheidung überlassen.

Die Kategorie bewegt sich schnell von kundenspezifischen Builds zu produktisierten Agents. Die architektonischen Fragen bleiben dieselben.

Wo agentische KI in der Fertigung meist überdimensioniert ist

Dieselbe sechs Tests sortieren die negativen Fälle. Vier erweisen sich konsequent als unpassend:

• Statisches Reporting. Wenn das Ziel Sichtbarkeit ist, sind konventionelle BI und Dashboarding billiger, schneller zu erstellen und zuverlässiger als ein Agent. Agents verdienen ihre Kosten, wenn Entscheidungen getroffen werden müssen, nicht wenn Daten angezeigt werden müssen.
• Single-System-Automatisierung. Wenn eine Aufgabe vollständig innerhalb eines Systems mit klaren Regeln abläuft, erledigen traditionelle Skripte oder RPA die Arbeit besser. Das automatische Ausfüllen einer Rechnung aus einem Bestellauftrag benötigt keinen Planer. Es benötigt ein Skript.
• Einmalige Analyse. Nicht wiederkehrende Entscheidungen wiederholen sich nicht oft genug, um die Integrationskosten zu amortisieren. Ein erfahrener Analyst mit dem richtigen Datenzugang ist das richtige Werkzeug für eine strategische Frage, die einmal gestellt wird.
• Sicherheitskritische Regelkreise. Einen LLM-basierten Planer in einen deterministischen Sicherheitsregelkreis zu setzen, ist ein Kategorienfehler, keine Kostenfrage. Diese Regelkreise bleiben durch zertifizierte Hardware und Standards wie IEC 61508 geregelt. Die enge RL-Ausnahme aus Abschnitt 3 ändert nichts am Verbot für die in diesem Artikel behandelten Planer-Agents.

Das Architektur- und Governance-Muster, das Fertigungs-Agents praktikabel macht

In der Produktionsfertigung ist der Agent selten das gesamte System. Das produktionsreife System ist die Architektur um den Agenten herum, und in dieser Architektur ist auch die Governance angesiedelt.

Das Muster, das unter operativem und regulatorischem Druck standhält, hat fünf Komponenten. Jede leistet architektonische Arbeit, und die meisten erfüllen auch eine spezifische Governance-Verpflichtung.

1. Die Integrationsschicht

Kontrollierter, sicherer Zugriff auf den OT/IT-Stack über APIs oder Middleware. Die Integrationsschicht ist der Ort, an dem das Problem des heterogenen Stacks aus dem früheren Artikel im Code gelöst wird: Protokollübersetzung, Authentifizierung, Ratenbegrenzung und Schema-Validierung. Diese Anforderung ist rein architektonisch. Es gibt keinen direkten regulatorischen Bezug, aber die Auditierbarkeit jeder anderen Komponente hängt davon ab, dass diese Schicht sauber ist.

2. Deterministische Ausführungsdienste

‍Der Agent generiert Absichten ("Wartung für Asset 4471 innerhalb von 72 Stunden planen, Ersatzteile auf Lager priorisieren"). Ein fest codierter Dienst validiert die Geschäftsregeln, Schemata und Sicherheits-Constraints, bevor die Aktion ausgeführt wird. Dies ist die architektonische Antwort auf die Determinismuslücke aus Abschnitt 3 – das LLM übernimmt das Reasoning, deterministischer Code die Aktion. Es ist auch die Grenze, die probabilistische Systeme davon abhält, in den Bereich von IEC 61508 abzudriften. Ein LLM End-to-End-Fehler orchestrieren und instabile Systeme produzieren zu lassen. Das hybride Muster macht das System produktionsfähig.

3. Menschliche Genehmigungsschranken

Obligatorische Schranken für jede Aktion mit erheblichen finanziellen, sicherheitsrelevanten oder qualitätsbezogenen Auswirkungen. Der Schwellenwert für "erheblich" wird von der Organisation festgelegt, nicht vom Agenten. Diese Anforderung erfüllt eine Doppelfunktion: Architektonisch ist sie der Failsafe, der einen probabilistischen Planer davon abhält, Entscheidungen zu treffen, die er nicht treffen sollte; in regulatorischer Hinsicht ist sie die Art und Weise, wie die menschlichen Aufsichtspflichten der EU-KI-Verordnung für Hochrisiko-KI-Systeme im Code umgesetzt werden. Ein Fertigungs-Agent, der sicherheitsrelevante Komponenten regulierter Maschinen berührt, fällt unter die Hochrisikoklassifizierung der KI-Verordnung, die eine dokumentierte menschliche Aufsicht vorschreibt, nicht nur eine beratende Aufsicht. Genehmigungsschranken sind die Art und Weise, wie diese Verpflichtung in der Architektur verankert wird.

4. Wiederholbare, auditierbare Protokolle

Jede Empfehlung, jeder Reasoning-Schritt, jeder Tool-Aufruf, jede Genehmigung, jede endgültige Aktion – protokolliert in einer Form, die eine forensische Rekonstruktion bei einem Fehler unterstützt. Architektonisch ermöglicht dies die Ursachenanalyse, wenn eine Empfehlung eines Agenten zu einem schlechten Ergebnis führt. In regulatorischer Hinsicht entspricht dies der NIST AI RMF "Measure"-Funktion und den Anforderungen der EU-KI-Verordnung an technische Dokumentation und Post-Market-Monitoring. Es ermöglicht der Organisation auch, nach einem Vorfall zu demonstrieren, dass das Verhalten des Agenten innerhalb seiner autorisierten Grenzen lag.

5. Fail-Closed-Verhalten

Wenn dem Agenten der ausreichende Kontext fehlt, wenn sein Vertrauen unter den Schwellenwert fällt oder wenn ein vorgelagertes System unerreichbar ist, stoppt der Agent und eskaliert an einen Menschen. Er improvisiert nicht. Fail-Closed ist das architektonische Gegenstück zur NIST AI RMF "Manage"-Funktion: Das System hat eine definierte Reaktion auf seine eigene Unsicherheit, und diese Reaktion besteht darin, die Kontrolle zurückzugeben, nicht zu raten.

Wie man ohne Überdimensionierung beginnt

Die erste agentische KI-Implementierung in einem Fertigungsunternehmen sollte eng gefasst, beobachtbar und reversibel sein. Read-only-Modus für die ersten Wochen, Workflow mit geringer Kritikalität, höchstens zwei integrierte Systeme, obligatorischer Human-in-the-Loop für jede Ausführung. Das Ziel des Pilotversuchs ist nicht, die Technologie zu demonstrieren – es ist herauszufinden, welche der architektonischen und Governance-Annahmen aus dem vorherigen Abschnitt tatsächlich den Kontakt mit dem Werk überleben.

Konkret sieht ein praktikabler erster Pilotversuch so aus:

• Arbeitet in den ersten Wochen im Read-only- oder Monitor-only-Modus. Der Agent beobachtet, führt Reasoning durch und erstellt Empfehlungen. Er schreibt in kein System. Dies ist ein Fail-Closed-Verhalten, das in der Pilotphase angewendet wird, bevor das Team dem Agenten genug vertraut, um ihm Schreibzugriff zu gewähren.
• Zielt auf einen Workflow mit geringer Kritikalität ab – Wartungs-Triage, Qualitätsdatenerfassung, Überwachung von Lieferantenstörungen. Störungsreaktion und PdM-Orchestrierung sind die richtigen Endzustände, aber nicht die richtigen Startpunkte.
• Integriert höchstens zwei Systeme. MES und CMMS für einen Wartungs-Pilotversuch. ERP und Lieferanten-E-Mail für einen Ausnahmenmanagement-Pilotversuch. Jedes zusätzliche System vervielfacht die Integrationsschuld; die Disziplin im Pilotumfang hält die Architektur sauber.
• Hält einen Menschen in jedem Ausführungspfad involviert. Keine Ausnahmen, keine automatischen Genehmigungen für Edge Cases. Die Aufgabe des Pilotversuchs ist es, aufzuzeigen, wo das Reasoning des Agenten fundiert ist und wo nicht, was nur geschieht, wenn ein Mensch jede Aktion überprüft, die er ausgeführt hätte.

Verfolgen Sie operative Metriken, nicht KI-Metriken. Die vier wichtigsten:

• Mittlere Diagnosezeit (MTTD) — wie lange es dauert, die Grundursache einer Qualitätsabweichung oder eines Wartungsausfalls zu identifizieren. Der Agent komprimiert den Triage-Schritt; diese Metrik misst, ob die Komprimierung real ist.
• Reduzierung der Planer-Arbeitslast — welchen Prozentsatz wiederkehrender Ausnahmen der Agent in Entwurfsqualität bearbeitet, bevor ein Mensch sie überprüft. Wenn der Planer jede Empfehlung umschreibt, erzeugt der Agent keinen Mehrwert.
• Qualität des Arbeitsauftrags beim ersten Versuch — wie oft ein vom Agenten generierter Wartungsauftrag ohne Änderungen genehmigt wird. Dies ist die aussagekräftigste Metrik für die Frage: „Ist der Agent in der Produktion nützlich?“
• Wiederherstellungszeit des Zeitplans — wie schnell das System nach einem Störungssignal einen Wiederherstellungsplan erstellt. Der Bosch Shopfloor Agent und der Anwendungsfall für die Störungsreaktion aus Abschnitt 5 sind hier angesiedelt.

Die KI-Genauigkeit als übergeordnete Metrik ist in diesem Kontext ein Kategorienfehler. Ein Agent, der zu 95 % genaue Empfehlungen erstellt, auf die niemand reagiert, ist schlechter als ein Agent, der zu 85 % genaue Empfehlungen erstellt, die umgesetzt werden. Verfolgen Sie, was in die Produktion gelangt.

Fazit

Agentische KI in der Fertigung ist eine eng gefasste Technologie mit einer breiten Fehleranfälligkeit. Der enge Bereich, der funktioniert, ist: Planer-ähnliche Agents oberhalb von MES und ERP, die über Systeme hinweg koordinieren, die kein gemeinsames Datenmodell haben, und Ausnahmen behandeln, die statische Regeln nicht aufzählen können. Alles andere ist der Bereich, in dem Fehler auftreten.

Das Framework in diesem Artikel ist kein Leitfaden dafür, welche agentische KI die beste ist. Es ist ein Filter dafür, welche Workflows überhaupt einen Agenten haben sollten. Sechs Tests, ehrlich angewendet, eliminieren die meisten Kandidaten-Workflows. Die vier, die bestehen: Störungsreaktion, prädiktive Wartungs-Orchestrierung, Qualitätsuntersuchung und Lieferanten-Ausnahmenmanagement. Wählen Sie einen aus, behandeln Sie den Pilotversuch als Falsifizierbarkeitstest der Architektur und messen Sie das Ergebnis in operativen Metriken.

Bei den Fertigungsprojekten von Codebridge ist das Muster konsistent: Planer oberhalb der Steuerungsebene, deterministische Ausführung darunter, menschliche Genehmigung an jedem wichtigen Entscheidungspunkt, vollständiger Audit-Trail jeder Entscheidung. Der Anwendungsfall ändert sich. Das Muster nicht.