Tag 21: KVP - Warum Modelle nach dem Go-Live verstauben

Marc

Guten Abend und willkommen zum Update für Tag 21 im AI Business Specialist an der GAT in Zürich. Heute ist Dienstag, der 13. Oktober 2026. Um 17 Uhr öffnet der Zoom Raum, Thomas Wengi führt durch den Abend, und dieser Podcast ist der kurze Anlauf davor. Ich bin Marc, neben mir sitzt Stefan.

Stefan

Guten Abend. Heute schliessen wir Teil 5 ab, Go Live. Am Freitag ging es darum, den Go Live abzusichern. Am Samstag um das Monitoring, also darum, was gemessen wird, wer hinschaut und wer entscheidet. Heute kommt die Frage, die danach kommen muss: Was passiert eigentlich, wenn das Monitoring etwas zeigt? Das Thema heisst KVP, kontinuierlicher Verbesserungsprozess. Fast alle von euch kennen den Begriff aus dem klassischen Projekt und Change Management. Er gehört dort zum Standard. Neu ist, was die KI daran verändert.

Marc

Ich fange mit einer Zahl an, die ihr vom Samstag noch im Ohr habt. Beim Fall ISA Desk, dem Assistenten des Verbands, fiel die Quote der Anfragen, die ohne Rückfrage beantwortet werden, von 60 auf 48 Prozent. Zum 1. März 2027 war das. Und niemand hatte etwas angefasst. Das war die Diagnose von Tag 20: neues Reglement, verschobene Anfragen, ein Modellwechsel beim Anbieter. Heute macht der Fall den dritten Zeitsprung, in den Mai 2027. Der Verband hat auf die Diagnose reagiert, eine neue Prompt Version gebaut, die Version 4, und zwei Vergleiche mit der alten Version gemacht. Am 20. Mai soll entschieden werden. Das steht im Nachtrag 3 der Fallakte, vier Seiten, den die Kohorte am Montag bekommen hat.

Stefan

Und genau hier liegt die Kernbotschaft des Abends. Ich lese sie bewusst langsam vor: Eine KI Lösung wird nicht von selbst besser. Sie wird besser, wenn jemand Rückmeldungen sammelt, Änderungen prüft und vorher festlegt, was als Verbesserung gilt. Dahinter steckt ein Problem, das man das stille Verstauben nennen kann. Eine klassische Software stürzt ab, du siehst eine Fehlermeldung, und jemand kümmert sich. Eine KI Lösung liefert einfach weiter Antworten. Nur etwas schlechtere. Google hält das in den Regeln für maschinelles Lernen fest, die Martin Zinkevich zusammengestellt hat. Regel 8 sagt: Du musst wissen, wie schnell ein Modell an Qualität verliert, also den Frische Bedarf deines Systems kennen. Und Regel 10 warnt vor stillen Ausfällen, zum Beispiel wenn vorgelagerte Daten veralten, ohne dass irgendetwas abstürzt.

Marc

Das kenne ich aus einer ganz anderen Ecke, als Bild gesprochen. Ein Inserat läuft auch einfach weiter, selbst wenn die Stelle längst vergeben ist. Es gibt keine Fehlermeldung, nur ins Leere laufende Bewerbungen. Aber gut, bei einer KI Lösung ist der Schaden grösser, weil sie ja selber antwortet. Wie sieht denn der Kreislauf aus, der dagegen helfen soll?

Stefan

Der Kreislauf ist alt. Planen, Umsetzen, Prüfen, Handeln, auf Englisch PDCA. Walter Shewhart hat 1939 einen solchen Zyklus für die Qualitätskontrolle beschrieben, W. Edwards Deming hat ihn 1950 in Japan vorgestellt. Toyota hat daraus mit Kaizen eine Kultur gemacht: Alle verbessern täglich in kleinen Schritten. Und es gibt von Toyota ein zweites Prinzip, das zur KI erstaunlich gut passt, Jidoka. Bei einer Abweichung hält man die Linie sofort an, damit kein fehlerhaftes Teil weiterläuft. Übersetzt heisst das: Wer einen systematischen Fehler in der KI Lösung sieht, darf sie anhalten. Besonders wichtig ist bei KI der Schritt Umsetzen im Kleinen. Der Grund ist simpel: Eine Änderung am Prompt, am Wissen oder am Modell betrifft alle Antworten gleichzeitig. Wer sie ungeprüft einschaltet, testet an echten Nutzerinnen und Nutzern.

Marc

Also nicht einfach die gute Idee einschalten.

Stefan

Genau. Und der Kreislauf ist nicht nur Folklore aus der Industrie. Die Norm ISO/IEC 42001 von 2023 übernimmt dieselbe Logik für ein KI Managementsystem. Das NIST AI Risk Management Framework verlangt unter MANAGE 4.2, dass messbare Aktivitäten zur kontinuierlichen Verbesserung in die Aktualisierungen eines KI Systems eingebaut werden. Das ist für die Prüfung wichtig. Kompetenz E4, Einsatz von KI Lösungen kontinuierlich verbessern, ist in Prüfungsteil 2 prüfbar, der Fallstudie am 30. Oktober, und in Prüfungsteil 3, den Critical Incidents zu den Bereichen D, E und F.

Marc

Dann gehen wir in den Fall hinein, und zwar zuerst zu den Menschen. Im Nachtrag 3 gibt es einen Abschnitt, der zeigt, wie es ohne Operating Modell aussieht. Beim Prompt entscheidet, ich zitiere, niemand ausdrücklich, faktisch Beat Hofstetter. Bei der Wissensbasis entscheidet niemand. Und Philipp Zemp hat für Rechtsfragen ein Veto, das nirgends steht. Für mich als jemand, der gern auf Strukturen schaut, ist das ein vertrautes Muster: Wenn Zuständigkeit nicht aufgeschrieben ist, entscheidet, wer zuerst handelt. Oder eben keiner.

Stefan

Das Mittel dagegen ist das KVP Operating Modell, und es ist die Übergabe des heutigen Abends. Eine Seite, fünf Teile. Erstens die Rollen: wer die Lösung verantwortet, wer Rückmeldungen zusammenführt, wer Wissen und Prüfset pflegt, wer mit dem Anbieter spricht, wer ein Veto hat. Zweitens der Rhythmus. Drittens die Feedback Quellen. Viertens der Änderungsweg. Fünftens die Kennzahlen, an denen man Wirkung misst. Der Kurs gibt ein Beispiel für ISA Desk, und ich sage dazu ausdrücklich: Das ist ein mögliches Modell, keine Vorgabe. Beat Hofstetter verantwortet, Nina Brunner führt Feedback und Prüfset, Tobias Kern spricht mit dem Anbieter, Philipp Zemp und Nadia Frei haben schriftliche Vetos. Wichtig ist: Die Rollen haben Namen und Vertretung, nicht Abteilungen.

Marc

Warum Namen statt Abteilungen? Das klingt nach Kleinigkeit.

Stefan

Eine Abteilung kann nicht anrufen. Eine Abteilung kann auch nicht im Urlaub sein, und trotzdem fehlt dann niemand, der entscheidet. Bei einem Namen weisst du, wer gemeint ist, und bei der Vertretung, wer einspringt. Das gilt auch für Vetos. Ein Veto gehört schriftlich aufgeschrieben: wer, für welche Art von Änderung, mit welcher Frist. Ein Veto, das nirgends steht, wird entweder übergangen oder es blockiert alles. Beides ist schlecht, und beides ist im Fall ISA Desk angelegt. Dazu kommt der Rhythmus. Das Modell schlägt vor: wöchentlich 15 Minuten Blick auf die Kennzahlen, monatlich 60 Minuten Verbesserungsrunde, quartalsweise ein Portfolio Entscheid, also weiterführen, nachbessern oder stilllegen. Ein Kreislauf ohne festen Takt dreht sich nur, wenn es brennt.

Marc

Jetzt zu meinem Lieblingsteil, den Zahlen. Das Feedback bei ISA Desk kommt aus sieben Quellen, und niemand führt sie zusammen. Nehmen wir den April 2027. Von 202 Vorschlägen des Assistenten wurden 87 korrigiert oder mit Rückfrage freigegeben. Das ist eine ganze Menge, und in den Tickets stand der Grund als Freitext. Gelesen hat das niemand regelmässig. Erst als Sandra Keller die Gründe nachträglich von Hand ausgezählt hat, wurde etwas sichtbar: 24 Mal zu lang, 17 Mal falsche oder alte Beitragskategorie, 14 Mal fehlende Angabe.

Stefan

Das ist ein sehr schönes Beispiel für den Satz auf dem Cheat Sheet: gezählt, nicht gelesen. Ein gezählter Korrekturgrund ist mehr wert als zehn gelesene. Und die Korrektur durch die Menschen, die eine Ausgabe freigeben, ist meist die wertvollste Quelle, weil sie jeden Fall erfasst. Da schaut eine Fachperson auf hundert Prozent der Fälle. Aber sie ist nur etwas wert, wenn die Gründe als feste Kategorien erfasst werden. Im Ticket als Freitext versickert sie.

Marc

Und die Zufriedenheitsfrage im Webformular? Die wäre ja der bequeme Weg.

Stefan

Sie ist bequem, aber verzerrt. Im Webformular haben 19 von 78 Mitgliedern auf die Frage geantwortet, ob die Antwort hilfreich war. Das ist ein Signal, aber keine Messung. Man weiss nicht, wer nicht antwortet. Meist melden sich die sehr Zufriedenen und die sehr Frustrierten. Deshalb gehört zu jeder Quelle eine Frage: Erfasst sie alle Fälle oder nur einen Teil? Und dann: Wer sammelt, wie oft, und wohin fliesst das Ergebnis? In die Verbesserungsrunde, in einen Trigger, ins Portfolio. Und wiederkehrende Fehler wandern ins Prüfset, damit sie nach jeder Änderung wieder geprüft werden. Dazu kommt gleich noch mehr.

Marc

Jetzt kommt der Vorschlag, der in der Werkstatt für Diskussion sorgen dürfte. Reto Iten, den ihr aus den Tagen 18 bis 20 kennt, schlägt im Mai 2027 vor, jede freigegebene Antwort automatisch als Musterantwort in die Wissensbasis aufzunehmen. Sein Argument, wörtlich: Dann lernt der Assistent von uns. Ehrlich gesagt klingt das erst mal clever. Die Leute prüfen ja ohnehin jede Antwort. Warum soll man dieses Wissen nicht zurückfliessen lassen?

Stefan

Weil es eine versteckte Rückkopplung ist. Das ist ein Begriff, den man sich für die Prüfung merken sollte. Eine Rückkopplung entsteht, wenn die Ausgaben eines Systems später wieder seine Eingaben werden. Manchmal ist das gewollt, nämlich wenn geprüfte Korrekturen einfliessen. Gefährlich wird es, wenn es ungeprüft geschieht. Dann wird ein Fehler, der einmal durchgerutscht ist, zur Quelle. Er kommt wieder, und beim zweiten Mal sieht er wie eine Bestätigung aus. Sculley und Kolleginnen und Kollegen von Google haben das 2015 in ihrem Aufsatz über versteckte technische Schulden in ML Systemen beschrieben, und sie zählen solche Schleifen zu den teuersten Schulden. Der Fehler ist ja nicht einmal auffällig. Er verstärkt sich langsam.

Marc

Also einer unterschreibt abends müde eine Antwort mit einem veralteten Betrag, und plötzlich ist das die Musterantwort?

Stefan

Genau das. Und bei ISA Desk gibt es noch einen zweiten Haken, der fast noch tückischer ist. Der Verband hat eine Sperre für Quellen, die älter als sechs Monate sind. Eine Musterantwort trägt aber kein Gültigkeitsdatum. Damit würde Retos Vorschlag diese Sperre unterlaufen, ohne dass jemand es merkt. Eine Antwort, die im Januar richtig war, würde im Juli noch zitiert. Und das Reglement hatte sich ja gerade zum 1. Januar geändert. Die bessere Lösung, die das Themenpaper skizziert: Musterantworten nur nach Prüfung durch die Wissensmanagerin, mit Quelle und Gültigkeitsdatum. Der Mensch bleibt in der Schleife, und das Datum bleibt dran.

Marc

Es gibt noch eine zweite Form, oder? Eine, die nicht im eigenen System passiert, sondern über die Welt läuft.

Stefan

Ja, Sculley und Kollegen unterscheiden direkte und versteckte Rückkopplungen. Direkt: Ein Modell bestimmt mit, welche Daten es künftig zum Lernen bekommt. Versteckt: Zwei Systeme beeinflussen sich indirekt über die Welt. Ein bekanntes Beispiel aus der Forschung sind Systeme für vorausschauende Polizeiarbeit. Ensign und Kollegen haben 2018 mathematisch gezeigt, wie solche Systeme Patrouillen immer wieder in dieselben Quartiere schicken, weil die dort entdeckten Delikte als neue Daten zurückfliessen, unabhängig von der tatsächlichen Kriminalität. Das System verändert, was es später misst. Für uns heisst das praktisch drei Dinge. Erstens bei jedem Datenfluss fragen: Kann eine Ausgabe später zur Eingabe werden? Zweitens nichts automatisch zurückfliessen lassen, was nicht ein Mensch geprüft hat. Und drittens zurückfliessenden Inhalten eine Kennzeichnung geben: Herkunft, Datum, Prüfung.

Marc

Das ist für die Werkstatt 1 ein guter Prüfstein. Reto Iten hat ja nichts Böses im Sinn. Er will, dass die Lösung besser wird. Und die Antwort der Gruppe ist nicht nein, sondern ja, aber über einen geprüften Weg.

Stefan

Das ist die richtige Haltung. Kontinuierliche Verbesserung heisst nicht, dass man Ideen abwürgt. Es heisst, dass jede Idee einen Weg durchläuft, an dem sie sich beweisen muss.

Stefan

Der nächste Baustein beginnt mit einem Begriff, der bei den meisten für Verwirrung sorgt: Retraining. Ursprünglich heisst das, ein Modell mit neuen Daten neu zu trainieren. Das tun Organisationen, die ihre Modelle selbst bauen. Die meisten Organisationen in der Schweiz kaufen ihre Modelle aber als Dienst ein. Sie können nicht neu trainieren. Was sie können, ist nachführen, und dafür gibt es vier Hebel: die Wissensbasis aktualisieren, den Prompt überarbeiten, Regeln und Filter anpassen und auf eine andere Modellversion wechseln. Die Hebel sind schneller und billiger als ein Training. Aber jeder kann die Qualität verschlechtern, wenn man ihn ohne Prüfung zieht.

Marc

Und wann zieht man sie? Das ist ja die Frage der Retraining Trigger.

Stefan

Ein Retraining Trigger ist eine vorab festgelegte Bedingung, die ein Nachführen auslöst. Es gibt vier Arten. Nach Zeit: ein fester Termin, zum Beispiel vor jedem 1. Januar, wenn neue Beiträge gelten. Nach Ereignis: etwas geschieht, etwa eine Mitteilung des Anbieters oder ein neues Reglement. Nach Kennzahl: eine Schwelle aus dem Monitoring von Tag 20 reisst. Und nach Feedback: ein Korrekturgrund häuft sich über eine festgelegte Zahl, das Themenpaper nennt als Beispiel mehr als zehn gleiche Gründe im Monat. Zu jedem Trigger gehören vier Angaben: was nachgeführt wird, wer es tut, was vor dem Einschalten geprüft wird und wer freigibt. Das ist übrigens genau die Tabelle auf der zweiten Seite der Vorlage für den Projektauftrag, die Retraining Trigger Liste.

Marc

Ich versuche, das am Winter von ISA Desk durchzuspielen. Das Beitragsreglement galt ab 1. Januar, in der Wissensbasis stand es aber erst am 15. Januar. Ein Zeit Trigger am 1. Dezember hätte diese zwei Wochen verhindert.

Stefan

Richtig, so steht es auch im Paper. Und der zweite Fall: Am 9. Februar 2027 stellte der Anbieter auf ein neues Sprachmodell um. Die Antworten wurden länger, die Antwortzeit stieg von 34 auf 47 Sekunden, und mehr Anfragen liefen in die Abbruchgrenze von 180 Sekunden. Gemerkt hat es im Verband zuerst niemand, weil die Mitteilung in einem Sammelpostfach landete. Ein Ereignis Trigger, der Mitteilungen des Anbieters an Personen leitet, hätte den Wechsel vor dem Einschalten am Prüfset gezeigt. Und im April hätte ein Feedback Trigger gemeldet, dass zu lang der häufigste Korrekturgrund ist, 24 Mal. Drei Trigger, drei verschiedene Lücken, die jeweils ein anderer Trigger geschlossen hätte.

Marc

Jetzt bin ich skeptisch. Das mit dem unangekündigten Modellwechsel klingt nach Einzelfall. Ist es das?

Stefan

Nein, und dafür gibt es eine Studie, die auch heute im Kurs vorkommt. Lingjiao Chen, Matei Zaharia und James Zou, Stanford und Berkeley, verglichen 2023 die März und die Juni Version von GPT 3.5 und GPT 4 mit denselben Aufgaben. Ein Beispiel: Bei GPT 4 sank die Genauigkeit beim Erkennen von Primzahlen von 84 auf 51 Prozent. Beim selben Dienst, bei gleicher Aufgabe, nur drei Monate später. Der Anteil direkt ausführbaren Codes fiel von 52 auf 10 Prozent, vor allem wegen zusätzlichem Text und anderer Formatierung. Und GPT 4 beantwortete heikle Fragen im Juni seltener. Aber ich möchte fair bleiben: GPT 3.5 wurde bei den Primzahlen gleichzeitig besser, von 49,6 auf 76,2 Prozent. Die Autoren erklären den Einbruch zum Teil damit, dass GPT 4 Anweisungen zum schrittweisen Denken im Juni weniger folgte. Das ist ihre Interpretation, die Studie liefert dafür Hinweise. Fest steht die Beobachtung: Das Verhalten desselben Dienstes kann sich in kurzer Zeit stark ändern, und sie folgern, es müsse laufend überwacht werden.

Marc

Also das gleiche Modell dem Namen nach, aber nicht dem Verhalten nach.

Stefan

So ist es. Dazu kommt, dass Anbieter Versionen zurückziehen. Anthropic dokumentiert einen Lebenszyklus mit den Stufen aktiv, Legacy, abgekündigt und zurückgezogen, mit mindestens 60 Tagen Vorankündigung. Microsoft nennt für allgemein verfügbare Modelle auf seiner Plattform in der Regel 18 Monate. Für Betreiber heisst das: Ein Modellwechsel kommt, ob man ihn plant oder nicht. Deshalb gehört ein Verzeichnis der Modellversionen mit Rückzugsdatum ins Operating Modell. Und ein Erinnerungsstück zum Schluss dieses Teils: Auch das Prüfset braucht einen Trigger. Bei ISA Desk sind die Fragen zu den alten Beitragskategorien seit Januar veraltet, und die Person, die das Prüfset gepflegt hat, ist Ende Februar gegangen. Ein Prüfset ohne Zuständige prüft irgendwann mit veralteten Fällen.

Marc

Jetzt kommen wir zum Herzstück, zum Entscheid vom 20. Mai. Version 4 gegen Version 3. Im Fachjargon: Champion Challenger. Stefan, erklär das bitte so, dass es auch jemand versteht, der nie ein Experiment gemacht hat.

Stefan

Der Champion ist die Version, die heute läuft, bei ISA Desk also Version 3. Der Challenger ist die neue Version, hier Version 4. Der Challenger muss zeigen, dass er besser ist, nicht nur, dass er anders ist. Üblich ist ein Ablauf in Stufen: zuerst am Prüfset, dann im Schattenbetrieb, wo der Challenger echte Fälle bearbeitet, seine Ausgaben aber niemanden erreichen, dann mit einem Teil der Fälle. Erst wenn er überzeugt, wird er zum neuen Champion. Der alte Champion bleibt als Rückweg verfügbar. Und vor jedem Vergleich braucht es fünf Angaben: eine Hypothese, eine Hauptkennzahl, Leitplanken, den Umfang und eine Entscheidregel. Kohavi und Kolleginnen und Kollegen, die das Experimentieren bei Microsoft aufgebaut haben, nennen die Hauptkennzahl das Overall Evaluation Criterion. Und sie warnen davor, der Meinung der bestbezahlten Person im Raum zu folgen statt den Daten.

Marc

Und was ist mit den Leitplanken? Das Wort höre ich heute zum ersten Mal in diesem Kurs.

Stefan

Eine Leitplanke ist eine Kennzahl, die sich nicht verschlechtern darf, auch wenn die Hauptkennzahl steigt. Dmitriev und Kollegen von Microsoft nennen sie guardrail metrics. Sie verhindern, dass man eine Verbesserung an einer Stelle mit einem Schaden an einer anderen bezahlt. Mehr Tempo, aber eine übersehene Rechtsfrage. Genau das ist der Streitpunkt bei ISA Desk, wie wir gleich sehen.

Marc

Dann die Zahlen. Im Betrieb, mit 104 und 98 zufällig verteilten Anfragen, kamen Version 3 mit 53 Prozent und Version 4 mit 61 Prozent ohne Rückfrage aus. Acht Punkte Vorsprung. Das sieht für jedes Management gut aus. Und doch sagt die Faustregel des Kurses: Bei je 100 Fällen sind Unterschiede bis etwa 14 Punkte noch Zufall. Ich als Zahlenmensch sage dazu: Das ist unangenehm, aber ehrlich. Wer bei 100 Fällen acht Punkte feiert, feiert womöglich einen guten Tag. Um die acht Punkte sicher zu zeigen, bräuchte es nach dem Paper rund 600 Anfragen je Version. Bei ISA Desk wäre das ein halbes Jahr Warten.

Stefan

Dahinter steckt eine Faustformel von Kohavi und Kollegen aus dem Jahr 2009. Die nötige Fallzahl wächst mit dem Quadrat der Streuung und sinkt mit dem Quadrat des Unterschieds, den man erkennen will. Ein halb so grosser Unterschied braucht viermal so viele Fälle. Das ist der Grund, warum eine Suchmaschine mit Millionen Besuchen anders arbeiten kann als ein Verband mit Dutzenden Anfragen pro Woche. Die Lösung bei wenig Verkehr heisst: gepaarter Vergleich. Beide Versionen bearbeiten dieselben Fälle, hier die 60 Fragen des Prüfsets. Und es zählen nur die Fälle, bei denen sich die Versionen unterscheiden. Das war bei 14 Fragen so. Davon gingen 12 an Version 4 und 2 an Version 3. Zwölf zu zwei.

Marc

Das leuchtet mir ein. Als Bild: Wenn eine Münze bei 14 Würfen zwölf Mal auf dieselbe Seite fällt, würde ich ihr nicht mehr trauen.

Stefan

Das Bild trägt, und das Paper sagt es vorsichtiger: Das ist mit Zufall kaum zu erklären. Der Grund, warum der gepaarte Vergleich so viel schärfer ist: Die Streuung zwischen den Fällen fällt weg, weil jede Frage beiden Versionen gestellt wird. Der Test im Betrieb bestätigt danach, er entscheidet nicht. Und trotzdem: Die Antwort ist nicht einfach, Version 4 gewinnt, also einschalten.

Marc

Wegen der Rechtsfrage.

Stefan

Version 4 hat im Betrieb eine von vier Rechtsfragen übersehen, und die Mitglieder fragen öfter nach. Niemand hat vor dem Test festgelegt, ob das ein Ausschlussgrund ist. Philipp Zemp hat ein Veto, das nirgends steht. Der Erwartungshorizont des Kurses ist deshalb nicht sofort übernehmen. Sondern nachbessern, am Prüfset gepaart neu vergleichen und die Entscheidregel vorher festlegen, mit Leitplanke für Rechtsfragen und schriftlichem Veto. Das ist die Aussage des Kurses, es ist eine begründete Empfehlung und kein Naturgesetz. Aber der Satz, der es zusammenfasst, passt gut zur Prüfung: Eine Verbesserung, die man nicht messen kann, ist eine Vermutung. Und was erst nach dem Vergleich festgelegt wird, ist keine Messung, sondern eine Begründung.

Marc

Dann zum Schluss noch das, was in der Praxis am meisten wehtut: der Schritt zurück. Beim Paketdienst DPD brachte im Januar 2024 ein Kunde den Chatbot dazu, zu fluchen, sich selbst als nutzlos zu bezeichnen und über DPD zu lästern, und er teilte den Dialog öffentlich. DPD erklärte, nach einem Systemupdate am Vortag sei ein Fehler aufgetreten, und schaltete den KI Teil ab. In der Logik des heutigen Abends: Ein Challenger wurde ohne Prüfung zum Champion.

Stefan

Ein Prüfset mit schwierigen und provozierenden Fragen hätte das Verhalten vor dem Einschalten gezeigt. Das zweite Beispiel ist Klarna. Im Februar 2024 meldete das Unternehmen, sein KI Assistent bearbeite im ersten Monat zwei Drittel der Kundenservice Chats, 2,3 Millionen Gespräche, mit der Arbeit von 700 Vollzeitstellen. Im Mai 2025 sagte der CEO laut Fortune gegenüber Bloomberg, der Fokus auf Kosten habe zu tieferer Qualität geführt, und man investiere wieder in menschlichen Kundendienst. Klarna selbst spricht von einem zweigleisigen Ansatz und nicht von einer Abkehr von der Automatisierung. Das gehört zur Fairness dazu. Die Lehre fürs Operating Modell: Führt die Qualität aus Sicht der Kundschaft als Leitplanke, nicht nur Effizienz. Haltet den Rückweg bereit. Und legt fest, wer zurückgehen darf, ohne vorher eine Sitzung einzuberufen. Auch ein Rückschritt kann eine Verbesserung sein.

Marc

Dann fassen wir den Abend in der Reihenfolge zusammen, in der ihr ihn erleben werdet. Der Zeitsprung in den Mai 2027, dann Feedback mit System, dann Retraining Trigger, dann Champion oder Challenger mit Abstimmung im Plenum. Und ab 20 Uhr gehört die Projektwerkstatt euch, an eurem eigenen Projekt. Der Projektauftrag lautet: ein KVP Operating Modell und eine Retraining Trigger Liste. Die Vorlage im Querformat ist ein Angebot, keine Pflicht. Abgabetermin für die Wochenaufgabe 5 ist Sonntag, der 18. Oktober, 18 Uhr.

Stefan

Und noch ein Hinweis auf Freitag. Dann folgt Tag 22, online, mit Marc Ruef zur Cyber Security für KI Systeme. Euer Operating Modell ist dafür der Anschluss. Wer weiss, wer was verantwortet und wer ein Veto hat, kann auch beantworten, wer reagiert, wenn jemand das System angreift. Ich wünsche euch einen guten Abend, bis zum Kreislauf, der sich dreht.

Marc

Viel Erfolg bei der Werkstatt, und bis zum nächsten Update.