KI im Schattenbetrieb testen: kontrolliert lernen, bevor Ergebnisse den Betrieb steuern

Im Wareneingang ordnet ein neuer KI-Dienst eine Bestellung dem falschen Kunden zu. Im führenden System passiert trotzdem nichts: Die Sachbearbeiterin hat den Auftrag nach dem bisherigen Verfahren erfasst, während die KI denselben Fall nur im Hintergrund verarbeitet hat. Ihr Vorschlag, die Eingabedaten und die spätere Fachentscheidung landen in einem Prüfprotokoll. Genau dafür ist ein KI Schattenbetrieb gedacht.

Ein überzeugender Prototyp beantwortet noch nicht, wie ein Modell mit unvollständigen Aufträgen, ungewöhnlichen Bauteilen, undeutlichen Fotos oder Störungsmeldungen aus einer Nachtschicht umgeht. Im kontrollierten Parallelbetrieb trifft die KI auf die tatsächliche Variantenbreite. Sie darf daraus aber noch keine Buchung auslösen, kein Teil ausschleusen und keinen Einsatz priorisieren.

„Ohne Betriebsrisiko“ bedeutet dabei nicht risikofrei. Der Schattenbetrieb verhindert zunächst, dass ungeprüfte KI-Ausgaben den operativen Ablauf steuern. Datenschutz, Informationssicherheit, Infrastrukturkosten und der Umgang mit Beschäftigtendaten müssen bereits für den Test geklärt sein. Die fachliche Leitplanke lautet: reale Bedingungen, messbare Ergebnisse, keine operative Wirkung ohne Freigabe.

Ein KI Schattenbetrieb liegt zwischen Labortest und produktiver Nutzung

Ein Offline-Test arbeitet mit einem abgegrenzten Prüfdatensatz. Er ist unverzichtbar, bildet den laufenden Betrieb aber nur so gut ab, wie Auswahl und Kennzeichnung der Beispiele es erlauben. Ein Schattenbetrieb verarbeitet anschließend neue Fälle parallel zum bestehenden Verfahren. Das bisherige System und die zuständigen Beschäftigten bleiben führend.

Der Datenweg sieht vereinfacht so aus:

1. Ein Auftrag, Bild oder eine Störungsmeldung erreicht den etablierten Prozess.
2. Eine kontrollierte Kopie der erforderlichen Eingaben wird an die KI übergeben.
3. Die KI erzeugt Klassifikation, Prognose oder Vorschlag.
4. Das Ergebnis wird mit Modellversion, Zeitpunkt und Eingabe-Referenz protokolliert.
5. Die normale Fachbearbeitung läuft unverändert weiter.
6. Nach der tatsächlichen Entscheidung werden KI-Vorschlag und Referenzergebnis verglichen.

Das unterscheidet den Schattenbetrieb von einem A/B-Test. Bei einem A/B-Test erhalten verschiedene Nutzer oder Vorgänge unterschiedliche produktive Varianten. Im Schattenbetrieb wird nur das etablierte Ergebnis wirksam; die neue Variante bleibt unsichtbar oder wird ausschließlich in einer getrennten Prüfansicht gezeigt. Auch ein stufenweiser Produktivstart ist etwas anderes, weil dabei bereits ein begrenzter Anteil der KI-Ausgaben den Prozess beeinflusst.

AWS und Microsoft beschreiben Shadow Testing technisch nach demselben Grundprinzip: Produktionsanfragen werden gespiegelt, Antworten der Schattenvariante werden protokolliert, aber nicht an die aufrufende Anwendung zurückgegeben. Für einen klassischen Betrieb muss dieses Muster über einen Modellendpunkt hinausgedacht werden. Referenz ist nicht immer ein altes Modell, sondern häufig die bestätigte Buchung im ERP, die Entscheidung eines Qualitätsprüfers oder die tatsächlich gewählte Einsatzpriorität.

Der Go-/No-Go-Check kommt vor dem Parallelbetrieb

Ein Schattenbetrieb ist kein Ersatz für eine fehlende Prozessdefinition. Bevor reale Fälle gespiegelt werden, müssen Arbeitsschritt, Eingaben, Ziel, Fehlerfolgen und Verantwortlichkeit geklärt sein. Der Beitrag zum Go-/No-Go-Check für KI-Prozesse liefert dafür das vorgelagerte Prüfraster.

Ein geeigneter Testauftrag lautet beispielsweise: „Aus eingehenden Bestellungen sollen Kundennummer, Liefertermin und Auftragspositionen extrahiert und mit der finalen Fachbuchung verglichen werden.“ Nicht prüfbar wäre: „Die KI soll den Innendienst entlasten.“ Erst die konkrete Formulierung bestimmt, welche Fälle protokolliert, welche Abweichungen gezählt und welche Grenzen später freigegeben werden können.

Vor dem Start werden mindestens diese Voraussetzungen belegt:

• Die Eingaben lassen sich rechtmäßig und technisch kontrolliert bereitstellen.
• Jeder Testfall besitzt eine stabile Referenz zwischen Quelle, KI-Ausgabe und Fachentscheidung.
• Das erwartete Ergebnis kann fachlich bestätigt oder verworfen werden.
• Fehlerarten und ihre betriebliche Bedeutung sind beschrieben.
• Die KI besitzt im Schattenmodus keinen unkontrollierten Schreibweg zum führenden System.
• Verantwortliche können den Test unterbrechen und Datenflüsse nachvollziehen.
• Testdauer und Fallauswahl decken die relevanten Betriebsvarianten ab.

Fehlt die stabile Zuordnung, produziert der Test zwar viele Protokolle, aber keine belastbare Aussage. Genau deshalb muss die Datenbasis für KI im Unternehmen vor dem Start auf IDs, Zeitbezug, Quellen und fachliche Zielwerte geprüft werden.

Die Hypothese verbindet Technik und Betriebsnutzen

„Das Modell erreicht eine gute Genauigkeit“ reicht als Testhypothese nicht. Eine hohe Gesamtquote kann einen wichtigen, aber seltenen Fehlertyp verdecken. Ein System könnte Standardaufträge korrekt erkennen und gerade bei Expresslieferungen, Gefahrguthinweisen oder gesperrten Kunden versagen.

Eine brauchbare Hypothese benennt deshalb:

• den abgegrenzten Arbeitsschritt
• die relevanten Fallklassen
• die heutige Vergleichsgröße
• zulässige und unzulässige Fehler
• technische Anforderungen wie Laufzeit und Verfügbarkeit
• erwartete Auswirkung auf Prüfung, Durchlaufzeit oder Nacharbeit
• die Entscheidung, die nach dem Test getroffen werden soll

Die Baseline stammt aus dem bestehenden Verfahren. Bei einer Auftragsklassifikation können Bearbeitungszeit, Rückfragen, Korrekturen und nicht eindeutig zuordenbare Vorgänge erfasst werden. Bei einer Sichtprüfung zählen bestätigte Fehlerarten, Nachprüfungen und Fälle ohne eindeutige Fachentscheidung. Die Werte müssen im Betrieb erhoben werden; pauschale Branchenzahlen wären für eine Freigabe ungeeignet.

Der Schattenbetrieb vergleicht somit nicht „KI gegen Perfektion“, sondern eine neue Lösung mit dem tatsächlich verfügbaren Verfahren. Dabei darf die menschliche Referenz nicht automatisch als fehlerfrei gelten. Bei widersprüchlichen Entscheidungen braucht es eine fachliche Klärung, sonst lernt das Projekt lediglich, wie uneinheitlich der Betrieb heute entscheidet.

Die Stichprobe muss Standards, Ausnahmen und Belastungsspitzen enthalten

Ein Parallelbetrieb über die nächsten beliebigen Vorgänge kann ein geschöntes Bild liefern. In vielen Betrieben unterscheiden sich Wochentage, Schichten, Saisonphasen, Lieferanten, Produktgruppen und Kundenkanäle. Ein Test am ruhigen Vormittag sagt wenig über einen E-Mail-Stapel nach einem Feiertag oder Bilder bei veränderter Hallenbeleuchtung aus.

Der Prüfplan bildet deshalb Fallgruppen. Dazu gehören häufige Standardfälle, bekannte Ausnahmefälle, neue oder seltene Varianten sowie Eingaben mit schlechter Qualität. Zusätzlich werden betriebliche Situationen berücksichtigt: Spitzenlast, Vertretung, geänderte Stammdaten, Netzunterbrechung oder ein vorübergehend nicht erreichbarer KI-Dienst.

Die Auswahl darf nicht nachträglich nur auf erfolgreiche Beispiele reduziert werden. Jeder ausgeschlossene Fall benötigt einen dokumentierten Grund. Wenn personenbezogene oder vertrauliche Daten für die fachliche Aussage nicht erforderlich sind, werden sie vor der Übergabe minimiert oder pseudonymisiert. Synthetische Beispiele können gezielte Grenzfälle ergänzen, ersetzen aber nicht die Prüfung unter den vorgesehenen Einsatzbedingungen.

Das NIST AI Risk Management Framework empfiehlt, Leistung und Vertrauenswürdigkeit unter Bedingungen zu messen, die dem späteren Einsatzkontext entsprechen. Es fordert dokumentierte Testdaten, Metriken und Methoden sowie die Einbindung von Fachleuten und Nutzern. Für den Betrieb folgt daraus: Die IT kann Laufzeit und Fehlercodes beurteilen, die fachliche Abnahme eines Werkstattbefunds oder Qualitätsfehlers bleibt jedoch bei der zuständigen Rolle.

Referenzentscheidungen brauchen Herkunft und Verantwortung

Jede KI-Ausgabe wird gegen ein Referenzergebnis geprüft. Dieses kann aus einer finalen ERP-Buchung, einem bestätigten Prüfentscheid, einer später festgestellten Störungsursache oder einem fachlich nachbewerteten Vorgang stammen. Wichtig ist, dass Zeitpunkt und Herkunft feststehen.

Bei der Referenz entstehen typische Fallen:

• Die spätere Buchung wurde aus Zeitdruck vereinfacht und bildet nicht die korrekte Fachlogik ab.
• Zwei Prüfer bewerten denselben Grenzfall unterschiedlich.
• Die tatsächliche Störungsursache wird nach Abschluss nicht zurückgemeldet.
• Ein Auftrag wurde manuell korrigiert, ohne den Korrekturgrund zu dokumentieren.
• Mitarbeitende sehen bereits den KI-Vorschlag und übernehmen ihn unbewusst als Referenz.

Im reinen Schattenmodus sollte die Fachentscheidung möglichst ohne Einfluss der KI entstehen. Uneinige Fälle werden nicht zwangsweise einer Klasse zugeordnet, sondern als eigener Befund dokumentiert. Solche Fälle können zeigen, dass zuerst Arbeitsanweisung oder Stammdaten präzisiert werden müssen.

Fehlerklassen sind aussagekräftiger als eine Gesamtquote

Für eine Freigabe zählt nicht nur, wie häufig KI und Referenz übereinstimmen. Entscheidend ist, wie sie voneinander abweichen. Bei einer binären Prüfung werden häufig falsch positive und falsch negative Ergebnisse getrennt. Im Betriebsprozess sind meist weitere Klassen nötig.

Fehlerkosten bestimmen die spätere Automatisierungsgrenze. Ein System darf möglicherweise harmlose Dokumente vorsortieren, während gesperrte Kunden, sicherheitsrelevante Bauteile oder unklare Störungen stets fachlich geprüft werden. Ein einzelner Durchschnittswert darf diese Unterschiede nicht verdecken.

Drei Praxisabläufe zeigen unterschiedliche Freigabewege

Auftragsklassifikation im Lager

Ein Großhändler erhält Bestellungen als E-Mail und PDF. Die KI extrahiert Absender, Kundennummer, gewünschtes Lieferdatum und Positionen. Ein Lesekonnektor stellt die Eingaben bereit; ein separater Protokollspeicher nimmt Vorschläge auf. Der Schreibzugriff auf ERP-Aufträge bleibt deaktiviert.

Referenz ist die final freigegebene Auftragserfassung. Abweichungen werden nach Kunde, Dokumentlayout, Artikelart und Feldtyp ausgewertet. Besonders kritisch sind falsche Kundenzuordnung und fehlende Positionen. Ein vertauschtes Freitextmerkmal kann dagegen in einer späteren Freigabestufe weiterhin zur manuellen Prüfung vorgelegt werden.

Der Test betrachtet zusätzlich Laufzeit und Kosten je Vorgang. Wenn die KI zwar fachlich geeignet ist, aber bei Lastspitzen zu spät antwortet, kann sie den vorgesehenen Prozess nicht unterstützen. Der Beitrag zu KI in Lager und Großhandel ordnet diesen Datenweg in Wareneingang, Bestand und Auftragsbearbeitung ein.

Bildprüfung in der Produktion

Eine Kamera erfasst Bauteile an einem definierten Prüfpunkt. Im Schattenbetrieb erhält das Modell Bild, Bauteil-ID, Variante und Aufnahmebedingungen. Es kennzeichnet mögliche Fehler, löst aber weder Ausschleusung noch Maschinenstopp aus. Ein Qualitätsprüfer entscheidet nach dem bestehenden Verfahren.

Die Auswertung trennt Fehlerarten und Produktionsbedingungen. Eine gute Leistung bei einer Bauteilvariante darf nicht auf andere Oberflächen übertragen werden. Änderungen an Beleuchtung, Kamera, Material oder Liefercharge werden im Protokoll sichtbar gemacht. Sonst kann eine verschobene Eingabeverteilung unbemerkt die Modellleistung verändern.

Bei sicherheitsrelevanten Fehlern kann der Schattenbetrieb zeigen, dass das Modell als zusätzliche Prüfhilfe taugt, aber nicht autonom entscheiden darf. Das ist kein gescheiterter Pilot. Die zulässige Rolle wurde präzisiert. Mehr zum fachlichen Zusammenhang steht im Beitrag KI in der Produktion.

Störungsmeldungen in Werkstatt und Gebäudeservice

Eine Meldung erreicht den Betrieb per Formular, E-Mail oder Telefonnotiz. Die KI schlägt Anlage, Störungsart, Dringlichkeit und zuständige Qualifikation vor. Der vorhandene Disponent priorisiert und weist den Auftrag weiterhin selbst zu. Referenz sind seine bestätigte Entscheidung und – sofern später verfügbar – die dokumentierte Ursache.

Die Fehleranalyse unterscheidet eine unnötige Hochstufung von einer übersehenen kritischen Meldung. Außerdem wird geprüft, ob fehlende Anlagennummern, regional unterschiedliche Begriffe oder knappe Nachtschichtnotizen die Zuordnung verschlechtern. Mitarbeiterfeedback ist hier besonders wertvoll: Ein formal korrekter Vorschlag kann praktisch unbrauchbar sein, wenn die Begründung fehlt oder die relevante Textstelle nicht angezeigt wird.

Für Gebäudeservices beschreibt KI im Facility Management den vollständigen Ablauf von der Meldung bis zum Leistungsnachweis. Im Schattenbetrieb bleibt der Fokus enger: Kann genau die vorgesehene Klassifikation unter realen Bedingungen verlässlich vorbereitet werden?

Mitarbeiterfeedback gehört in die Messung, nicht nur in den Projektabschluss

Beschäftigte erkennen Fehler, die in einem technischen Dashboard nicht sichtbar werden. Eine vorgeschlagene Kategorie kann korrekt sein, aber die falsche Folgefrage auslösen. Eine Prüfansicht kann den Originalbeleg zu klein darstellen. Ein Modell kann bei internen Abkürzungen funktionieren, aber bei Urlaubsvertretung unverständlich bleiben.

Feedback wird strukturiert erfasst: Fall-ID, beobachtetes Problem, fachliche Folge, gewünschte Information und Dringlichkeit. Freitext ohne Fallbezug ist schwer auswertbar. Gleichzeitig darf der Test nicht zur verdeckten Leistungs- oder Verhaltenskontrolle werden. Zweck, ausgewertete Daten, Zugriffsrechte und Aufbewahrung müssen klar feststehen; betriebliche Mitbestimmung und Datenschutzprüfung sind je nach Konstellation einzubeziehen.

Das BSI stellt mit QUAIDAL Kriterien und Methoden für die Qualität von KI-Daten bereit, darunter Vollständigkeit, Konsistenz und die anwendungsbezogene Auswahl von Metriken. Der Katalog ersetzt keine konkrete Rechtsprüfung, unterstützt aber ein dokumentiertes Qualitätsverfahren. Der Schattenbetrieb sollte deshalb nicht nur Modellwerte speichern, sondern auch Datenqualität und bekannte Einschränkungen nachvollziehbar machen.

Drift zeigt sich erst über neue Fälle und veränderte Bedingungen

Ein Modell kann während des Tests stabil beginnen und später nachlassen. Ursachen sind nicht zwingend Änderungen am Modell. Neue Lieferanten verwenden andere Dokumentlayouts, eine Kamera wird neu ausgerichtet, Produktvarianten wechseln oder Beschäftigte formulieren Störungen anders. Diese Veränderung der Eingaben wird häufig als Datendrift bezeichnet.

Darum wird nicht nur ein Gesamtwert am Testende berechnet. Die Auswertung betrachtet Zeitabschnitte, Fallgruppen und relevante Eingabemerkmale. Auffällige Verschiebungen lösen eine fachliche Prüfung aus. Ein kurzfristiger Rückgang kann eine erklärbare Sonderlage sein; eine dauerhafte Veränderung kann neue Testdaten, angepasste Regeln oder eine erneute Freigabe verlangen.

NIST nennt das fortlaufende Beobachten von Funktion, Leistung und neu auftretenden Risiken ausdrücklich als Teil des KI-Risikomanagements. Der Schattenbetrieb ist damit kein einmaliger Haken vor dem Produktivstart, sondern die Vorlage für das spätere Monitoring: Welche Werte werden beobachtet, wer reagiert und wann wird auf das etablierte Verfahren zurückgeschaltet?

Stop-Regeln schützen Budget, Daten und Akzeptanz

Ein Paralleltest wird nicht nur beendet, wenn die geplante Laufzeit erreicht ist. Vor dem Start werden Ereignisse definiert, die eine Unterbrechung oder Neubewertung auslösen. Dazu können gehören:

• unzulässige oder unerwartete Daten gelangen in den KI-Dienst
• Referenzfälle lassen sich nicht mehr eindeutig zuordnen
• ein kritischer Fehlertyp tritt entgegen der Freigabeannahme auf
• Modell- oder Schnittstellenänderungen machen Ergebnisse unvergleichbar
• technische Last beeinträchtigt das führende System
• Testkosten überschreiten den vereinbarten Rahmen
• Beschäftigtenfeedback weist auf eine nicht berücksichtigte Prozessfolge hin
• die Stichprobe bildet den vorgesehenen Einsatz nicht ausreichend ab

Eine Unterbrechung ist kein automatisches Projektende. Sie verhindert, dass ein nicht mehr aussagekräftiger Test weiter Daten und Budget verbraucht. Die bereits geplante Folgeidee zu Abbruchkriterien vertieft diese Entscheidung separat; sie wird durch diesen Artikel nicht als zweites Thema neu angelegt.

Freigabestufen ersetzen den Sprung in die Vollautomatisierung

Nach einem erfolgreichen Schattenbetrieb muss die KI nicht sofort selbstständig handeln. Eine sinnvolle Freigabekette kann so aussehen:

Jede Stufe besitzt eigene Abnahmekriterien. Ein gutes Ergebnis im unsichtbaren Parallelbetrieb belegt noch nicht, dass Menschen Vorschläge effizient prüfen oder Automation Bias vermeiden. Die Assistenzstufe testet deshalb auch Oberfläche, Erklärbarkeit, Arbeitslast und tatsächliche Korrekturen.

Die technische Architektur verhindert versehentliche Wirkung

Ein bloßes Versprechen, Ergebnisse „noch nicht zu verwenden“, ist zu schwach. Die Architektur sollte den Schattenstatus erzwingen. Der KI-Dienst erhält einen kontrollierten Leseweg oder eine Ereigniskopie. Ergebnisse landen in einem getrennten Evaluationsspeicher. Ein produktiver Schreibadapter ist entweder nicht vorhanden oder technisch gesperrt.

Zu protokollieren sind mindestens Fallreferenz, Modell- und Promptversion, erforderliche Eingabemerkmale, Ausgabe, Laufzeit, Fehlerstatus und spätere Referenzentscheidung. Vollständige Inhalte werden nur gespeichert, wenn sie für Prüfung und Rechtsgrundlage nötig sind. Berechtigungen trennen Fachprüfung, technische Administration und Auswertung.

Bei alter Fachsoftware kann ein Export, eine Datenbankansicht, ein überwacht abgelegtes Dokument oder ein individueller Konnektor den Leseweg bilden. Die API-Entwicklung von SW Business Solutions umfasst bei Bedarf solche kundenspezifischen Adapter. Das nächste Serienthema behandelt die Integration in ältere Fachsysteme ausführlich; hier ist entscheidend, dass der Testweg reproduzierbar und vom späteren Schreibweg getrennt bleibt.

Datenschutz und Sicherheit beginnen vor dem ersten gespiegelten Fall

Reale Eingaben können Kunden-, Beschäftigten-, Vertrags- oder Maschinendaten enthalten. Auch wenn die KI-Ausgabe nicht produktiv genutzt wird, findet eine Verarbeitung statt. Verantwortliche klären Zweck, Datenumfang, Rechtsgrundlage, Empfänger, Speicherort, Löschung, Zugriffsrechte und vertragliche Rollen vor dem Test.

Ein Schattenbetrieb darf nicht mit dem regulatorischen „Testen unter Realbedingungen“ der EU-KI-Verordnung gleichgesetzt werden. Letzteres ist ein eigener Rechtsbegriff für bestimmte Konstellationen und kann besondere Anforderungen auslösen. Die konkrete Einordnung hängt von System, Rolle, Zweck und Risikoklasse ab. Der kontrollierte interne Parallelbetrieb ist eine technische und organisatorische Testmethode, keine pauschale rechtliche Ausnahme.

Sicherheitsseitig werden Zugangsdaten, Protokolle, Schnittstellen, Modellanbieter und Ausfallverhalten geprüft. Ein gespiegelter Datenstrom darf das führende System nicht verlangsamen. Rate Limits, Warteschlangen und Timeouts verhindern, dass ein nicht kritischer Test produktive Ressourcen bindet.

Der Ergebnisbericht führt zu einer klaren Entscheidung

Am Ende stehen nicht nur Diagramme. Ein belastbarer Bericht enthält Prozessgrenze, Testversion, Fallgruppen, Ausschlüsse, Baseline, Referenzverfahren, Fehlerklassen, technische Messwerte, Driftbefunde, Mitarbeiterfeedback, Kosten und offene Risiken. Änderungen während des Tests werden mit Zeitpunkt dokumentiert, damit Ergebnisse vergleichbar bleiben.

Die Entscheidung lautet anschließend beispielsweise:

• Assistenz freigeben: definierte Fallgruppen können mit sichtbarer Fachprüfung unterstützt werden.
• Schattenbetrieb verlängern: eine wichtige Saison-, Schicht- oder Produktvariante fehlt noch.
• Zur Datenarbeit zurückkehren: Referenzen oder IDs reichen für eine belastbare Bewertung nicht aus.
• Zuschnitt verkleinern: nur risikoarme Felder oder Klassen sind geeignet.
• Pilot stoppen: Nutzen, Qualität oder Betriebskosten rechtfertigen keine weitere Umsetzung.

Die allgemeine Einführung von Auswahl und Prozessaufnahme bis Betrieb wird im geplanten Leitfaden Künstliche Intelligenz im Unternehmen einführen behandelt. Dieser Beitrag bleibt bewusst bei der Übergangsphase zwischen Prototyp und erster operativer Freigabe.

SW Business Solutions entwickelt den Schattenbetrieb passend zum vorhandenen Prozess

SW Business Solutions bringt kein universelles Testprodukt in Werkstatt, Lager oder Produktion. Das Team grenzt mit Fachbereich und IT einen realen Arbeitsschritt ab, übernimmt vorhandene Systeme als fachliche Quelle und entwickelt die fehlenden Bestandteile kundenspezifisch.

Je nach Betrieb umfasst die Umsetzung:

• Ereignis- oder Leseschnittstelle zum ERP, WMS, DMS, Ticketsystem oder zur Maschine
• Datenminimierung und kontrollierte Aufbereitung
• Einbindung eines geeigneten Standardmodells oder individuellen Verfahrens
• versionsfestes Protokoll für Eingaben, Ausgaben und Referenzentscheidungen
• Prüfansicht für Fachverantwortliche
• Dashboard für Fehlerklassen, Laufzeit, Kosten und Drift
• Stop-Schalter, Berechtigungen und Rückfallkonzept
• Freigabestufen vom Schattenmodus bis zur begrenzten Automation

Die KI-Integration von SW Business Solutions verbindet dabei Standarddienste, individuelle Software, Datenmodelle und bestehende Fachsysteme. Wo eine feste Regel den Anwendungsfall zuverlässiger löst, wird sie der KI vorgezogen.

Für die Planung genügt ein konkreter Vorgang mit Eingabe, heutiger Fachentscheidung und tatsächlichem Ergebnis. SW Business Solutions plant daraus einen messbaren Schattenbetrieb mit Abnahmekriterien. Das Ziel ist keine eindrucksvolle Demonstration, sondern eine dokumentierte Entscheidung darüber, welche Rolle die KI im echten Betrieb verantwortbar übernehmen darf.