Wann industrielle AI nicht in Produktion gehen sollte
These
Ein AI-Modell kann ein brauchbares Ergebnis liefern und trotzdem die falsche Produktionsentscheidung sein.
Entscheidend ist, ob die Fähigkeit innerhalb eines bestehenden Produkts und Unternehmenssystems zuverlässig, wirtschaftlich und verantwortbar betrieben werden kann. Ein erfolgreicher Prototyp sagt wenig über Berechtigungen, ungültige Eingaben, deterministische Grenzen, nachgelagerte Ausführung, langfristige Kosten oder die Verantwortung im Fehlerfall aus.
Für ein Industrie- oder B2B-Softwareunternehmen verlangt Produktionsreife deshalb mehr als Modellqualität. Executives müssen entscheiden, welche Ergebnisse probabilistisch bleiben dürfen, ob die Daten entscheidungsfähig sind, ob die Lösung Berechtigungs- und Prozessgrenzen einhält, ob Fehlerpfade konstruiert sind, ob die Wirtschaftlichkeit trägt und ob klare Verantwortliche existieren. Fehlen diese Voraussetzungen, sollte AI noch nicht produktiv gehen.
Am Anfang steht der Preis eines Fehlers
Die erste Produktionsfrage lautet nicht: Wie genau ist das Modell? Sie lautet: Was geschieht, wenn es falsch liegt?
Eine Empfehlung, die einem Nutzer einige Minuten spart und folgenlos verworfen werden kann, darf Unsicherheit enthalten. Ein Ergebnis, das physische Kompatibilität, einen verbindlichen Preis, eine Finanzbuchung, eine Qualitätsfreigabe oder eine Compliance-Schranke beeinflusst, besitzt eine andere Fehlerökonomie. Kostet ein falsches Ergebnis ein Vielfaches der fachlichen Prüfung, muss die Automatisierung vor der letzten Entscheidung enden.
Durchschnittliche Accuracy-Werte verdecken diesen Unterschied. Ein System kann über ein Testset hinweg gut abschneiden und gerade an jenem seltenen Sonderfall scheitern, der den größten Schaden verursacht. Für die Executive-Entscheidung zählt daher nicht nur die Verteilung der Prognosen, sondern die Verteilung ihrer Konsequenzen.
Daraus folgt eine praktische Grenze: Probabilistische Ergebnisse sind sinnvoll, wenn sie Optionen erzeugen, Aufmerksamkeit priorisieren oder Suchaufwand reduzieren. Sie sind nicht automatisch geeignet, wenn Korrektheit nicht verhandelbar ist.
Manche Entscheidungen müssen deterministisch bleiben
AI-Empfehlung und deterministische Validierung sind keine konkurrierenden Philosophien. In vielen Industrieprodukten entsteht die stärkste Architektur aus beidem.
Produktkonfiguration
In einer komplexen Produktkonfiguration kann AI eine unvollständige Anfrage interpretieren, Varianten vorschlagen und durch einen großen Optionsraum führen. Mechanische, elektrische oder thermische Kompatibilität folgt jedoch Produktregeln und physikalischen Grenzen. AI darf eine Möglichkeit erzeugen; ein deterministisches System muss weiterhin entscheiden, ob diese Möglichkeit gültig ist.
Diese Aufteilung schafft eine klare Produktgrenze. Die probabilistische Ebene erleichtert den Zugang zur Komplexität. Die deterministische Ebene schützt die Gültigkeit. Vom Modell beide Aufgaben übernehmen zu lassen, macht häufig die Demonstration einfacher und das Produktionsprodukt schwächer.
Pricing, Finanzen und harte Geschäftsregeln
Dasselbe Prinzip gilt für Pricing. AI kann eine Anfrage klassifizieren, kommerziellen Kontext extrahieren oder Eingaben strukturieren. Sie darf keinen rechtlich bindenden Preis, Rabatt, Währungswert oder keine Margenkalkulation erfinden. Die abschließende Berechnung gehört in deterministische Pricing- und Geschäftslogik.
Auch Buchhaltung, steuerliche Behandlung, Buchungslogik und vergleichbare Compliance-Entscheidungen brauchen harte Validierung. AI kann Menschen beim Finden und Einordnen relevanter Informationen unterstützen. Aus Assistenz entsteht jedoch keine letzte Entscheidungsbefugnis für einen probabilistischen Output.
Die Executive-Frage lautet damit nicht AI oder Regeln, sondern: Wo gehört was hin? Hybride Systeme sind häufig leistungsfähiger als ideologische „AI everywhere“-Architekturen, weil sie Unsicherheit dort nutzen, wo sie Wert schafft, und Determinismus dort einsetzen, wo er das Unternehmen schützt.
Erklärbarkeit ist nicht dasselbe wie Modelltransparenz
Erklärbarkeit wird oft als Forderung verstanden, das Innere eines Modells offenzulegen. Das ist selten das, was ein B2B-Nutzer benötigt.
Bei einer Empfehlung mit geringem Risiko kann Vertrauen aus Kontext entstehen: Welche Ausgangsinformationen wurden verwendet, warum ist der Vorschlag plausibel, wie sicher ist das System? Bei Qualitäts-, Freigabe- oder Compliance-Entscheidungen reicht kontextuelle Plausibilität nicht. Das Produkt muss die tatsächlich verletzte Bedingung, Regel oder Grenze sichtbar machen.
Diese Unterscheidung ist wichtig, weil der Nutzer nicht das AI-System verstehen soll. Ein gutes Produkt reduziert die Komplexität, die er verstehen muss. Müssen Menschen zunächst lernen, wie sie das Modell prompten, befragen und kontrollieren, bevor sie handeln können, wurde Arbeit möglicherweise nur verschoben statt beseitigt.
Eine dialogorientierte Oberfläche kann nützlich sein. Dialog allein ist jedoch noch kein Produktwert. Das System muss den Nutzer weiterhin zu einer gültigen Entscheidung führen—mit den richtigen Nachweisen und einer klaren Grenze zwischen Empfehlung und Freigabe.
Schlechte Daten lassen sich nicht durch Modellwahl retten
Viele AI-Initiativen sollten enden, bevor Teams Modelle vergleichen. Zuerst ist zu klären, ob die Organisation überhaupt Daten besitzt, aus denen sich eine belastbare Entscheidung ableiten lässt.
Keine verlässliche Ground Truth
Historische Datensätze sind nicht automatisch Trainingswahrheit. Sie können alte Entscheidungen enthalten, ohne verlässlich zu zeigen, ob diese Entscheidungen richtig waren. Ein größerer Datensatz skaliert dann bestehende Inkonsistenz, statt die Urteilskraft zu verbessern.
Gebrochene Entitätsidentität
ERP, CRM und Legacy-Systeme beschreiben denselben Kunden, dasselbe Produkt oder dieselbe Anlage häufig unterschiedlich. Fehlen stabile Identifikatoren zwischen diesen Datensätzen, liegt vor dem AI-Problem ein Entity-Resolution-Problem. Ein Modell kann nicht zuverlässig kompensieren, dass eine Organisation selbst nicht bestimmen kann, ob zwei Datensätze dieselbe Sache beschreiben.
Prozessänderung ohne strukturierte Historie
Produkte, kommerzielle Regeln und Betriebsprozesse verändern sich. Werden diese Änderungen nicht als strukturierte Metadaten erfasst, führen historische Beziehungen in die Irre. Das Modell lernt einen Prozess, der nicht mehr existiert, und präsentiert überholte Muster mit neuer Sicherheit.
Daten, die nicht gemeinsam genutzt werden dürfen
Auch technisch verfügbare Daten dürfen möglicherweise rechtlich, vertraglich oder operativ nicht für den vorgesehenen Zweck zusammengeführt werden. Zugriffsrechte, Zweckbindungen und organisatorische Ownership können verhindern, dass ein theoretisch attraktiver Datenbestand zu einem legitimen Produktionsinput wird.
Eine unstrukturierte Tabelle mit handschriftlichen Kommentaren ist deshalb nicht automatisch ein AI-fähiges Forecasting-System. Die Informationen müssen zunächst strukturiert, abgeglichen, validiert und entscheidungsfähig gemacht werden. Diese Arbeit kann mehr Wert schaffen als eine verfrühte Modellwahl.
Das Modell ist oft der kleinere Teil der Arbeit
In der Produktion ist die Modellentwicklung häufig einfacher als die Integration der Fähigkeit in das bestehende Unternehmenssystem.
Berechtigungsbewusste Retrieval-Systeme
Ein Retrieval-System mit ERP-, PDM- oder PLM-Inhalten zu verbinden, kann technisch überschaubar sein. Die schwierige Frage lautet: Darf der anfragende Nutzer jede Information sehen, die in der generierten Antwort enthalten ist?
Berechtigungen dürfen nicht nur beim Einlesen eines Dokuments in einen Index geprüft werden. Zugriffsrechte können sich nach Nutzer, Rolle, Projekt, Kunde oder Lebenszyklusstatus verändern. Die AI-Ebene muss diese Grenzen dynamisch bewahren. Eine fachlich richtige RAG-Antwort ist dennoch ein Produktfehler, wenn der Nutzer die zugrunde liegende Information nicht sehen durfte.
Das ist zugleich ein Integrations- und Governance-Problem. Ein Disclaimer unter der Antwort löst es nicht.
Legacy-Systeme und durchgängige Ausführung
Älteren Systemen fehlen häufig Events, moderne APIs oder geeignete Integrationssemantiken für nahezu echtzeitfähige Abläufe. Polling und fragile Schnittstellen können zum eigentlichen Engpass werden, selbst wenn die Modelllatenz hervorragend ist.
Dieselbe Grenze gilt nachgelagert. Eine AI-generierte „optimale Konfiguration“ besitzt wenig operativen Wert, wenn aus ihr keine gültige Stückliste, Bestellung, Produktionsanweisung oder ein anderes ausführbares Geschäftsobjekt entstehen kann. Der AI-Wert endet dort, wo das umgebende System das Ergebnis nicht sicher verarbeiten kann.
Executives sollten deshalb den vollständigen Entscheidungspfad bewerten: Quelldaten, Identität, Berechtigungen, Modellverhalten, Validierung und nachgelagerte Ausführung. Nur das Modell zu optimieren verbessert eine Komponente und lässt das Produkt unfertig.
Eine Demo beweist nur den Idealpfad
Eine Demonstration wird um günstige Eingaben und sichtbaren Erfolg gebaut. Produktionsfähigkeit zeigt sich in Ausnahmezuständen: fehlenden Daten, mehrdeutiger Absicht, nicht verfügbaren Abhängigkeiten, veränderten Berechtigungen, missbräuchlichem Verhalten und Ergebnissen, die niemals akzeptiert werden dürfen.
Vier Kriterien machen den Unterschied sichtbar.
Kontrollierte Degradation und Fallback
Was geschieht bei ungültigen, unvollständigen oder unerwarteten Eingaben? Was passiert, wenn Modell oder Quellsystem nicht verfügbar sind? Ein Produktionsdesign braucht einen sicheren Weg zu deterministischen Regeln, fachlicher Prüfung oder einem kontrollierten Fehlerzustand. Schweigen, erfundene Sicherheit und ein unbehandelter Fehler sind keine akzeptablen Fallbacks.
Deterministische Sicherheitsnetze
Kritische Ergebnisse sollten gegen harte Grenzen geprüft werden, bevor sie Kunden oder nachgelagerte Systeme erreichen. Das Modell darf vorschlagen; das Sicherheitsnetz entscheidet, ob der Vorschlag weiterlaufen darf.
End-to-End Observability
Das Betriebsteam braucht Sicht auf Latenz, Fehler, Kosten und jene Qualitätssignale, die für den konkreten Anwendungsfall relevant sind. Nur den Modellendpunkt zu überwachen reicht nicht, wenn der Fehler in Entitätsauflösung, Retrieval, Berechtigung, Validierung oder nachgelagerter Integration entsteht.
Integrität von Kontext und Berechtigung
Die Fähigkeit muss innerhalb des Daten-, Berechtigungs- und Domänenkontexts des Nutzers bleiben. Produktionssysteme müssen außerdem berücksichtigen, wie Menschen sich tatsächlich verhalten—einschließlich Fehlern, Abkürzungen und Manipulationsversuchen—und nicht nur den vorgesehenen Ablauf einer Demonstration.
Produktionsreife zeigt sich deshalb in der Fehlerbehandlung, nicht in der Präsentationsqualität. Je schwerer die Konsequenz eines Ergebnisses, desto wichtiger werden die Ausnahmezustände.
Modellqualität ist nur ein Teil der Gesamtkosten
Ein probabilistisches System kann technisch machbar und wirtschaftlich falsch sein.
API-, Token-, Compute- und GPU-Kosten können mit der Nutzung wachsen. Inference ist jedoch nur ein Teil der Gesamtkosten. Eine produktive Fähigkeit benötigt außerdem Monitoring, Evaluation, gegebenenfalls erneutes Labeling, Fehlerbehandlung, Integrationspflege, Support und klare operative Ownership. Diese Kosten bestehen weiter, nachdem das ursprüngliche Projektteam längst andere Aufgaben übernommen hat.
Der relevante Vergleich lautet nicht AI oder Nichtstun. Er kann AI versus ein einfacheres deterministisches Design lauten, das den größten Teil des Geschäftsproblems mit weniger Betriebskomplexität löst. Das einfachere System ist nicht automatisch weniger ambitioniert. Es kann die bessere Produktentscheidung sein, wenn die zusätzliche probabilistische Fähigkeit ihre Lebenszykluskosten nicht rechtfertigt.
Executives sollten Architektur mit Unit Economics verbinden. Wie entwickeln sich die Kosten mit dem Transaktionsvolumen? Welche Schritte benötigen fachliche Prüfung? Was geschieht, wenn sich Quellsysteme oder Modelle ändern? Welche dauerhafte Fähigkeit muss die Organisation finanzieren? Ein attraktiver Prototyp kann zu einem unattraktiven Produkt werden, sobald diese Fragen ehrlich bepreist werden.
Wartbarkeit und Betriebswirtschaftlichkeit können ebenso wichtig sein wie Modellqualität. Ein System, dessen Evaluation, Support und Weiterentwicklung sich das Unternehmen nicht leisten kann, sollte nicht produktiv gehen, nur weil es heute gut funktioniert.
Das Produktionstor hat drei Dimensionen
Vor einer Freigabe würde ich Evidenz in drei Dimensionen verlangen: technisch, wirtschaftlich und organisatorisch.
Technische Evidenz
Die Fähigkeit muss realistische Sonderfälle bestehen, Berechtigungsgrenzen bewahren, kontrolliert degradieren und unter repräsentativer Last vorhersehbar arbeiten. Kritische Ergebnisse brauchen deterministische Validierung oder einen expliziten menschlichen Freigabepfad. Der vollständige Ablauf—nicht nur das Modell—muss testbar und beobachtbar sein.
Wirtschaftliche Evidenz
Das Unternehmen muss den Nutzen auf Prozessebene und realistische Gesamtkosten verstehen: Infrastruktur- und API-Nutzung, Monitoring, Evaluation, Integration, Support und dauerhafte Ownership. Machbarkeit ohne tragfähige Wirtschaftlichkeit ist keine Produktionsreife.
Organisatorische Evidenz
Das Betriebsmodell braucht benannte Verantwortliche für Prozess, Produkt und Daten, erforderliche Freigaben aus Datenschutz, Security oder Compliance sowie einen Eskalationsweg für AI-Fehler. Das sind keine administrativen Aufgaben nach dem Deployment, sondern Produktionsabhängigkeiten.
Kein System kann vollständig sicher gemacht werden. Technische Kontrollen reduzieren Risiken, doch Verantwortung lässt sich nicht an ein Modell delegieren. Jemand muss Domäne, Daten, Entscheidungsgrenze und Konsequenzen besitzen.
Die stärkste Architektur ist häufig hybrid
Die Schlussfolgerung lautet nicht, dass Industrieunternehmen AI vermeiden sollten. AI sollte dort eingesetzt werden, wo probabilistische Schlussfolgerungen echten Produktwert schaffen.
AI darf Mehrdeutigkeit interpretieren, Möglichkeiten ordnen und den Aufwand zur Navigation durch Komplexität reduzieren. Deterministische Systeme bleiben dort, wo physische, rechtliche, finanzielle oder produktbezogene Korrektheit nicht verhandelbar ist. Menschen bleiben dort, wo Urteil und Verantwortung nicht delegiert werden können.
Diese Architektur ist weniger ideologisch rein als „AI everywhere“. Dafür übersteht sie mit höherer Wahrscheinlichkeit den Kontakt mit realen Produkten, realen Nutzern und realer Wirtschaftlichkeit.
Fazit
AI sollte nicht produktiv gehen, weil die Demonstration beeindruckt. Sie sollte produktiv gehen, wenn das Unternehmen Ergebnis, Fehlerpfad, Wirtschaftlichkeit, Daten und operative Verantwortung tragen kann.
Bis dahin ist eine verschobene Produktionsfreigabe kein Scheitern von Innovation. Sie ist Executive-Urteilskraft: Kunden und Unternehmen schützen und zugleich jene Arbeit leisten, die aus probabilistischer Fähigkeit ein belastbares Produkt macht.
Über Andrei Lisikov · Zugehörige Erfahrung in Industriesoftware und angewandter AI