Einen ML-Einsatz für ein Kundenproblem bewerten

Wenn “Wir brauchen KI” noch keine Aufgabenbeschreibung ist

Die Nordlicht Kältetechnik GmbH repariert Kühlanlagen in kleinen Lebensmittelbetrieben. Bei einigen Einsätzen muss eine Fachkraft ein zweites Mal anfahren, weil das passende Ersatzteil beim ersten Termin fehlt. Die Serviceleitung schlägt vor, mit maschinellem Lernen, kurz ML, vorherzusagen, welche Ersatzteilgruppe wahrscheinlich gebraucht wird.

Die Idee klingt zunächst passend. Im Ticketsystem stehen Gerätetyp, Fehlercode, Alter der Anlage, Wartungshistorie und der später tatsächlich verbaute Ersatzteilcode. Trotzdem ist noch offen, ob ein lernendes System besser hilft als eine feste Regel, eine überarbeitete Fehlerabfrage oder eine kurze Ferndiagnose.

Dein Auftrag lautet: Bewerte, ob ein ML-Einsatz fachlich sinnvoll, verantwortbar und wirtschaftlich prüfbar ist. Formuliere anschließend eine Go-, Pilot- oder No-Go-Empfehlung.

Die Grundidee dieser Lektion lautet: Ein ML-Modell ist erst dann eine Lösung, wenn seine Vorhersage eine konkrete Entscheidung verbessert und der Nutzen gegenüber einer einfachen Alternative unter realen Bedingungen nachweisbar ist.

Du brauchst keine Programmiererfahrung und trainierst hier kein Modell. Du solltest Anteile aus einer Tabelle lesen und Entscheidungen begründen können. Unternehmen, Daten und Kosten dieser Lektion sind neu erfunden.

Kläre zuerst Problem, Entscheidung und Zielgröße

“Weniger Zweitanfahrten” beschreibt den gewünschten Nutzen, aber noch keine messbare ML-Aufgabe. Für eine prüfbare Aufgabenbeschreibung brauchst du fünf Bausteine:

1. Beobachtungseinheit: Für welchen einzelnen Fall entsteht eine Vorhersage? Hier ist es ein geplanter Serviceeinsatz.
2. Zeitpunkt: Wann muss die Vorhersage vorliegen? Hier vor dem Beladen des Servicefahrzeugs.
3. Zielgröße: Welches später bekannte Ergebnis soll vorhergesagt werden? Hier: “Ersatzteilgruppe war beim ersten Termin nötig: ja oder nein”.
4. Handlung: Was geschieht mit der Vorhersage? Hier wird ein zusätzliches Ersatzteil eingeladen oder eine Ferndiagnose ausgelöst.
5. Erfolg: Welche betriebliche Wirkung soll sich verbessern? Hier sinken vermeidbare Zweitanfahrten, ohne Fahrzeuge unnötig stark zu beladen.

Das trennt eine Vorhersage von einer Entscheidung. Das Modell könnte eine Wahrscheinlichkeit von 70 Prozent ausgeben. Ob das Teil deshalb eingeladen wird, hängt zusätzlich von Platz, Wert, Kühlkette, Verfügbarkeit und Fehlerkosten ab.

Prüfe, ob das Ziel überhaupt beobachtbar ist

Die Zielgröße muss später verlässlich erfasst werden. “Techniker war zufrieden” wäre ohne einheitliche Erhebung zu unscharf. Auch der verbaute Ersatzteilcode kann irreführen: Vielleicht hatte die Fachkraft ein geeignetes Teil dabei, verbaute aber wegen einer zusätzlichen Störung ein anderes.

Für den Pilot definiert Nordlicht deshalb ein eindeutiges Label:

ersatzteilgruppe_k_noetig = ja,
wenn der freigegebene Servicebericht für den ersten Termin
ein Teil aus Gruppe K als erforderlich dokumentiert.

Diese Definition ist noch keine Garantie für gute Daten. Sie macht aber sichtbar, welcher Beleg benötigt wird und wer strittige Fälle fachlich klärt.

Vergleiche ML mit der einfachsten tragfähigen Alternative

Ein lernendes System ist sinnvoll, wenn viele wiederkehrende Fälle, ein aus historischen Beispielen lernbares Muster und eine nutzbare Folgehandlung zusammenkommen. Es ist nicht automatisch sinnvoll, nur weil Daten vorhanden sind.

Nordlicht prüft vier Varianten:

Die Varianten können sich ergänzen. Eine bessere Fehlerabfrage kann zum Beispiel die Datenqualität erhöhen. Ein späteres Modell nutzt dann diese Angaben. Deshalb lautet die Vergleichsfrage nicht “Regel oder ML für immer?”, sondern: Welche Kombination verbessert die Entscheidung jetzt mit vertretbarem Aufwand und Risiko?

Datenverfügbarkeit bedeutet mehr als eine volle Tabelle

Für jedes Merkmal stellst du vier Fragen:

1. War der Wert am Entscheidungszeitpunkt bereits bekannt?
2. Darf er für den festgelegten Zweck verarbeitet werden?
3. Ist er im späteren Betrieb in derselben Bedeutung verfügbar?
4. Kann er das Ergebnis unzulässig vorwegnehmen oder eine Benachteiligung verstärken?

Der nach dem Einsatz eingetragene Ersatzteilcode wäre ein Datenleck, wenn er als Eingabe für die Vorhersage desselben Einsatzes verwendet würde. Das Modell sähe dann während der Auswertung Informationen aus der Zukunft. Ein sehr gutes Testergebnis wäre wertlos für den späteren Betrieb.

Die Postleitzahl ist schon vor dem Termin verfügbar. Sie könnte Fahrzeit erklären, kann aber zugleich Wohnlage und Kundengruppen indirekt abbilden. Für die Frage, welches Ersatzteil technisch nötig ist, fehlt zunächst eine fachliche Begründung. Nordlicht lässt sie deshalb aus dem ersten Pilot heraus und prüft getrennt, ob der Standort für die Zielgröße überhaupt sachlich erforderlich ist.

Lege Baseline, Fehlerkosten und Metriken vor dem Test fest

Eine Baseline ist der nachvollziehbare Vergleich, den ein neuer Ansatz schlagen soll. Nordlicht nutzt die bestehende Regel: “Bei Fehlercode K17 Teil K einladen.” Das ist kein perfekter Gegner, sondern der tatsächliche heutige Ablauf.

Auf 100 zurückliegenden, getrennt geprüften Einsätzen ergibt sich folgende Beispielauswertung. Die Werte gehören zum erfundenen Szenario:

Der ML-Kandidat hat mit 72 Prozent eine geringere Accuracy, also einen kleineren Anteil insgesamt richtiger Entscheidungen. Trotzdem erkennt er 16 von 20 tatsächlich nötigen Teilen. Sein Recall für “Teil K nötig” beträgt damit 80 Prozent. Die Baseline erkennt 12 von 20 und erreicht 60 Prozent Recall.

Warum kann das relevant sein? Nordlicht bewertet einen unnötigen Transport im Pilot mit 6 Euro internem Aufwand. Eine vermeidbare Zweitanfahrt setzt das Unternehmen mit 85 Euro an. Das sind dokumentierte Planannahmen, keine allgemeinen Marktwerte.

Fehlerkosten Baseline = 18 × 6 € + 8 × 85 € = 788 €
Fehlerkosten ML       = 24 × 6 € + 4 × 85 € = 484 €

Die geringere Accuracy macht den ML-Kandidaten nicht automatisch schlechter. Unter diesen Annahmen reduziert er den teuren Fehlertyp. Die Empfehlung darf trotzdem nicht nur auf einer Summe beruhen. Ein schweres Ersatzteil, ein sicherheitskritischer Einsatz oder eine benachteiligte Kundengruppe kann andere Grenzen verlangen.

Prüfe Verantwortung vor dem produktiven Einsatz

Das NIST AI Risk Management Framework ordnet vertrauenswürdige KI als Zusammenspiel mehrerer Eigenschaften ein. Dazu gehören unter anderem Gültigkeit und Zuverlässigkeit, Transparenz und Verantwortlichkeit, Erklärbarkeit, Datenschutz sowie der Umgang mit schädlicher Verzerrung. Keine einzelne Metrik deckt diese Punkte ab.

Für Nordlicht entstehen daraus konkrete Prüffragen:

• Datenschutz: Welche Rechtsgrundlage und welcher Zweck tragen die Datenverarbeitung? Welche Merkmale sind wirklich nötig? Wie lange bleiben Ein- und Ausgaben gespeichert?
• Fairness: Unterscheiden sich Fehlerraten zwischen sachlich relevanten Betriebs- oder Kundengruppen? Entsteht eine schlechtere Versorgung bestimmter Regionen, obwohl die Zielgröße nur den technischen Teilebedarf betrifft?
• Erklärbarkeit: Kann die Fachkraft verstehen, welche dokumentierten technischen Angaben die Empfehlung tragen und wann sie ihr nicht folgen sollte?
• Verantwortung: Wer darf eine Empfehlung übersteuern? Wer bearbeitet Beschwerden und fehlerhafte Fälle? Wer darf den Einsatz stoppen?
• Sicherheit: Wer kann Eingabedaten oder Schwellenwerte verändern? Werden Zugriffe und Änderungen protokolliert?

Artikel 5 der Datenschutz-Grundverordnung nennt unter anderem Zweckbindung, Datenminimierung, Richtigkeit, Speicherbegrenzung sowie Integrität und Vertraulichkeit. Artikel 22 setzt zusätzliche Grenzen für ausschließlich automatisierte Entscheidungen mit rechtlicher oder ähnlich erheblicher Wirkung. Ob ein konkreter Einsatz darunter fällt, muss die verantwortliche Stelle mit Datenschutz- und gegebenenfalls Rechtskompetenz prüfen. Diese Lektion ersetzt keine Rechtsberatung.

Nordlicht lässt die Fachkraft im Pilot entscheiden. Das System empfiehlt nur eine Ersatzteilgruppe und protokolliert Empfehlung, Entscheidung sowie späteres Ergebnis. Kundinnen und Kunden werden nicht automatisch schlechter priorisiert. Diese Begrenzung reduziert Folgen, beseitigt aber nicht die Pflicht zur Datenschutz- und Fairnessprüfung.

Plane den Betrieb schon in der Eignungsentscheidung

Ein einmaliger Test beantwortet nicht, ob das System im Alltag verlässlich bleibt. Gerätetypen, Fehlercodes, Ersatzteilsortiment und Dokumentationsgewohnheiten können sich ändern. Dieser Wandel heißt Drift, wenn sich Daten oder ihre Beziehung zum Ziel gegenüber der geprüften Ausgangslage verschieben.

Der Pilot braucht deshalb vorab:

• eine verantwortliche Person für Freigabe und Stopp,
• eine feste Baseline und unveränderte Bewertungsdefinitionen,
• getrennte Kennzahlen für beide Fehlertypen und relevante Gruppen,
• Protokolle für Eingabe, Empfehlung, menschliche Entscheidung und Ergebnis,
• Warnschwellen für fehlende oder unbekannte Eingabewerte,
• einen Rückfall auf Regel oder Ferndiagnose,
• einen Termin zur fachlichen Neubewertung.

Formuliere eine Empfehlung, die überprüfbar bleibt

Eine belastbare Empfehlung enthält Entscheidung, Geltungsbereich, Begründung, Bedingungen und Abbruchkriterien. Für Nordlicht könnte sie so lauten:

Empfehlung: begrenztes Go für einen Pilot. Der ML-Kandidat wird vier Wochen lang nur als Empfehlung für Ersatzteilgruppe K eingesetzt. Er muss auf einer zeitlich getrennten Auswertung geringere dokumentierte Fehlerkosten als die K17-Regel erreichen und mindestens 75 Prozent der tatsächlich nötigen K-Teile erkennen. Postleitzahl und freie Kundennotizen bleiben ausgeschlossen. Die Fachkraft trifft die letzte Entscheidung. Der Pilot stoppt, wenn Eingabedaten nicht vollständig protokolliert werden, eine geprüfte Gruppe deutlich schlechter versorgt wird oder die Fehlkosten in zwei aufeinanderfolgenden Wochen über der Baseline liegen.

Die Grenzwerte sind Festlegungen des erfundenen Szenarios. In einem echten Auftrag müssen Verantwortliche sie aus Risikotoleranz, Kosten, Datenlage und gesetzlichen Anforderungen ableiten. Sie dürfen nicht erst nach Sichtung eines günstigen Ergebnisses passend gemacht werden.

Was du aus der Eignungsprüfung mitnimmst

• Übersetze einen Wunsch nach ML zuerst in Zielgröße, Zeitpunkt, Folgehandlung und Erfolg.
• Vergleiche einen ML-Ansatz mit Regeln, Prozessänderungen und organisatorischen Maßnahmen.
• Prüfe, ob Eingaben am Entscheidungszeitpunkt verfügbar, zweckmäßig und zulässig sind.
• Bewerte beide Fehlertypen gegen eine dokumentierte Baseline. Accuracy allein reicht selten.
• Behandle Datenschutz, Fairness, Erklärbarkeit, Verantwortung und Betrieb als Entscheidungskriterien.
• Empfiehl ein Go nur mit messbaren Gates, Rückfallweg und Überwachung.

Damit kannst du eine ML-Idee einordnen, bevor Modellwahl und Training Zeit und Daten binden.

Quellenbasis und Abgrenzung

Der Lernfeldbezug folgt Lernfeld 10c des KMK-Rahmenlehrplans. Die Lektion greift die berufliche Handlung auf, maschinelles Lernen für eine betriebliche Aufgabenstellung auszuwählen und seinen Einsatz zu bewerten. Die Fachinformatikerausbildungsverordnung trägt den Bezug zum Planen und Durchführen eines Datenanalyseprojektes sowie zu den Berufsbildpositionen D3 und D4. Der interne AP2-Lernguide konkretisiert wiederkehrende Teilkompetenzen wie Klassifikation, Modellbewertung und ML-Prozess, ohne einen konkreten Prüfungstermin vorherzusagen.

Das NIST AI RMF 1.0 stützt die mehrdimensionale Risikobetrachtung und den Lebenszyklus aus Einordnen, Messen und Steuern. Die Datenschutz-Grundverordnung trägt die genannten Datenschutzgrundsätze und den Hinweis auf automatisierte Entscheidungen. Rechtliche Zulässigkeit hängt vom konkreten Einsatz ab und ist nicht Gegenstand einer automatischen Selbstprüfung in dieser Lektion.

Diese Lektion endet bei der begründeten Eignungs- und Pilotentscheidung. Sie behandelt weder Datenbereinigung und Train-Test-Trennung im Detail noch Merkmalskonstruktion, Algorithmenauswahl, Training oder technische Bereitstellung. Diese Schritte gehören in die anschließende Lektion “Daten für ein lernendes System auswählen und vorbereiten”. Szenario, Zahlen, Kostenannahmen, Aufgaben und Lösungen wurden neu erstellt. Es wurde keine Prüfungsaufgabe übernommen.

Belegmatrix