Tag 6: Datenqualität - Warum KI-Piloten in der Produktion scheitern

Marc

Willkommen zu unserem vertieften KI Business Specialist Podcast für Tag sechs der Ausbildung an der Graduate School of Applied Technology and Management. Ich bin Marc, und an meiner Seite ist Stefan, unser Experte für KI und Datenarchitektur. Stefan, wenn du dir anschaust, was in Schweizer Unternehmen aktuell beim Thema KI passiert, gibt es ein Phänomen, das mir in Arbeitsmarktgesprächen ständig begegnet. Die Geschäftsleitung sitzt zusammen, sieht eine glänzende Prototyp Demonstration, alle klatschen und geben Budget frei. Doch drei bis sechs Monate später ist das Projekt klammheimlich wieder beerdigt worden. Warum scheitern so viele Vorhaben genau beim Übergang in den produktiven Alltag?

Stefan

Weil der Pilot auf einer perfekt geputzten Excel Tabelle lief, Marc. Das ist das klassische Pilot versus Produktion Paradoxon. Für den Piloten nimmt man einen einmaligen Export aus dem ERP System, vielleicht dreihundert Zeilen, und jemand schrubbt zwei Abende lang alle Tippfehler, Dubletten und leeren Felder von Hand raus. Die Demo überzeugt die Geschäftsleitung natürlich sofort. Aber sobald die Lösung produktiv geht und jede Nacht automatisch auf das operative Livesystem zugreifen muss, mit allen Sonderfällen, Altdaten aus zwanzig Jahren, fehlenden Schnittstellen und unklaren Zuständigkeiten, bricht die Anwendung zusammen. Der Unterschied kostet selten mehr KI Technik. Er kostet Aufbereitungsaufwand, den vorher niemand im Budget eingeplant hat.

Marc

Und das ist absolut kein Einzelfall. Die Zahlen für das Jahr zweitausendsechsundzwanzig sprechen da eine erschreckend deutliche Sprache. Schauen wir uns die aktuelle Studie von Nasuni an, für die eintausend Entscheidungsträger in den USA, Grossbritannien, Frankreich und im DACH Raum befragt wurden. Vierundneunzig Prozent aller Organisationen kämpfen massiv mit ihren unstrukturierten Daten. Und jetzt kommt die eigentlich schockierende Kennzahl: Sechsundvierzig Prozent gaben offen zu, dass erst der geplante KI Einsatz die tiefen Lücken in ihrer Datenqualität und Governance überhaupt sichtbar gemacht hat. Stefan, die Daten waren also schon jahrelang kaputt, aber die KI hat das Flutlicht darauf geworfen.

Stefan

Exakt. Die KI war nicht das Problem, sondern der Spiegel. Und genau das belegen auch andere aktuelle Erhebungen aus zweitausendsechsundzwanzig. Im Confluent Data Streaming Report mit über viertausendsechshundert Befragten nennen sechsundsechzig Prozent die Dateninfrastruktur und die Datenqualität als die Hauptbremse beim Skalieren von KI Agenten. Gleich daneben stehen Governance, Risiko und Compliance mit fünfundsechzig Prozent. Die Modellqualität steht nicht einmal auf der Liste der Hindernisse. Und die Cloudplattform Box zeigt in ihrer Enterprise Erhebung: Sechsundneunzig Prozent sagen, dass KI Agenten Zugriff auf firmeneigene Inhalte brauchen, aber nur sechsunddreissig Prozent haben ihre Agenten tatsächlich an vertrauenswürdige Inhalte angebunden. Die Daten existieren zwar irgendwo im Unternehmen, sie sind aber für die KI schlicht unerreichbar.

Marc

Das deckt sich genau mit dem, was Fraunhofer FIT und Celonis in ihrer Studie von Ende Juli zweitausendsechsundzwanzig festgestellt haben. Sie sprechen von einer echten Action Value Gap. Wegen fragmentierter Systeme und Datensilos sehen KI Anwendungen immer nur kleine Ausschnitte statt durchgängiger Prozessketten. Professor Röglinger hat das perfekt auf den Punkt gebracht: Es scheitert fast nie an der technischen Leistungsfähigkeit der Modelle, sondern am fehlenden Verständnis der realen betrieblichen Abläufe. Und genau deshalb verwandeln wir heute an Tag sechs den Schnelltest von Tag fünf in ein belegtes, belastbares Daten Audit. Wir hören auf zu glauben und fangen an zu messen.

Stefan

Der Kerngedanke von Tag sechs lautet: Dateneignung ist keine Eigenschaft eines Datensatzes an sich. Sie ist immer eine Aussage über ein Paar, nämlich genau diesen Datenbestand für genau diese eine Fragestellung. Dieselbe Kundentabelle kann für ein simples Monatsreporting hervorragend sein, für ein automatisches KI Prognosemodell aber völlig unbrauchbar. Deshalb funktioniert die Reihenfolge nur in eine Richtung: Erst kommt der Anwendungsfall, dann der Blick auf die Daten, niemals umgekehrt. Wer zuerst nach Daten sucht und dann überlegt, was man damit machen könnte, sucht ein Problem zu seiner Lösung.

Marc

Das bringt uns direkt zu Block eins des heutigen Abends: Scope, Systemgrenzen und Auftragsklärung. Aus meiner Praxis auf dem Arbeitsmarkt weiss ich, wie schnell KI Projekte ausufern. Jemand sagt im Meeting, wir sollten unsere Kundendaten für KI aufbereiten. Und drei Wochen später versucht das Projektteam, die komplette IT Landschaft der letzten zwanzig Jahre zu sanieren. Stefan, wie verhindert man diese typische Falle?

Stefan

Indem man den Anwendungsfall konsequent als Filter nutzt. Tim Giger, Principal Data und AI Consultant bei Swisscom, hat das im Swisscom B2B Magazin im Juli zweitausendsechsundzwanzig sehr praxisnah erklärt. Er sagt: Bereinigt nicht die Datenlandschaft der ganzen Organisation, sondern nehmt den Use Case als Filter. Wenn du einen Marketing Chatbot baust, dann prüfst du die Marketingablagen und Wissensquellen, sonst absolut gar nichts. Du baust eine scharfe Systemgrenze. Und dazu gehört ein strukturierter Ablauf in fünf Schritten, der im Qualifikationsprofil für den AI Business Specialist gefordert wird. First Step: Auftrag klären. Wer entscheidet am Ende, welche Entscheidung soll dein Daten Audit ermöglichen, und bis wann brauchst du das Ergebnis? Second Step: Scope setzen. Geschäftstätigkeit, Organisationseinheiten, Zeitraum, Quellsysteme und ausdrückliche Ausschlüsse schriftlich festhalten. Dritter Schritt: IST Zustand erheben. Vierter Schritt: SOLL Zustand definieren. Und fünfter Schritt: Den Gap benennen, also die genaue Differenz zwischen IST und SOLL als Problemstellung mit KI Potenzial herausarbeiten.

Marc

Lass uns beim SOLL Zustand kurz verweilen, denn da machen in der Praxis viele den Fehler, schwammige Formulierungen zu wählen wie zum Beispiel, der Kundensupport soll besser oder schneller werden. Das ist kein SOLL Zustand, das ist ein Wunschtraum! Ein echter SOLL Zustand braucht immer drei Dinge: eine klare Kennzahl, eine Messmethode und einen Stichtag. Nehmen wir drei Beispiele aus dem Unterricht. Im Support: Die Erstantwort dauert heute im Schnitt neun Stunden, gemessen über viertausendzweihundert Tickets im letzten Quartal. Der SOLL Zustand lautet: Erstantwort unter zwei Stunden bei den sechzig Prozent Standardanfragen. In der Disposition: Heute werden vierzehn Prozent der Bestellvorschläge manuell korrigiert. Der SOLL Zustand: Unter fünf Prozent Korrekturquote ohne Anstieg der Fehlmengen. Im Offertwesen: Heute fünfundvierzig Minuten Aufwand je Offerte, davon zwanzig Minuten Suchen von Daten. Der SOLL Zustand: Suchen unter fünf Minuten, die inhaltliche Prüfung bleibt beim Menschen. So formulierst du ein SOLL, das du in drei Monaten nachmessen kannst.

Stefan

Und vor allem musst du die Ausschlüsse definieren. Im Unterricht gibt es dazu die Übung eins, das Scope Blatt. Da beantwortet jeder Teilnehmende sechs Fragen zu seinem eigenen Projekt. Welche Geschäftstätigkeit untersuchst du in einem Satz und ohne das Wort und? Was gehört ausdrücklich nicht dazu, nenne mindestens zwei Ausschlüsse. Wer unterschreibt diesen Scope? Welche SOLL Kennzahl nutzt du? Welchen Zeitraum deckst du ab? Und welche Standorte, Sprachen oder Kundensegmente lässt du bewusst weg? Die Ausschlüsse schützen dich vor dem Verzetteln. Wenn du bei einem Support Assistenten festlegst, dass französische und italienische Tickets in der ersten Phase ausdrücklich ausgeschlossen sind, musst du für diese Sprachen weder Daten prüfen noch Übersetzungspipelines aufbauen. Wer bei den Ausschlüssen ins Stocken gerät, hat seinen Scope noch nicht im Griff. Das ist der Moment, in dem Dozent Thomas Wengi im Plenum live nachschärft.

Marc

Kommen wir zu Block zwei des Abends: Der Erhebung und der Datenlandkarte. Das Qualifikationsprofil nennt vier klassische Erhebungsmethoden für den IST Zustand: Dokumentenanalyse, Befragung, Beobachtung und Messung. Aus der Praxis weiss ich, dass die ersten drei Methoden oft die Wunscherzählung der Organisation zeigen. Der Prozessverantwortliche erzählt im Interview stolz, wie der Ablauf im Handbuch vorgegeben ist. Aber wenn du dann die vierte Methode nutzt, die Messung über Logfiles und Eventdaten, also Process Mining, siehst du die tatsächliche Systemspur. Du siehst Abweichungen, Workarounds und manuelle Zwischenschritte, von denen in den Dokumenten kein Wort steht. Genau diese Differenz zwischen der Erzählung der Mitarbeitenden und der echten Systemspur ist der wertvollste Fund des ganzen Audits! Dort liegen die Schattenprozesse und Excel Inseln. Und genau hier kommt ein zentrales Konzept ins Spiel, das im Unterricht neu aufgebaut wird: Die Kontextschicht. Ein Zitat von Tim Giger bringt das hervorragend auf den Punkt: Wer im Support ein Ticket nur mit Problem gelöst abschliesst, liefert für einen künftigen Support Chatbot wenig verwertbares Wissen. Datenqualität entsteht nämlich nicht in der IT Abteilung, sondern in dem Moment, in dem eine Person am Arbeitsplatz etwas ins System eintippt.

Stefan

Was gehört zwingend in so eine Kontextschicht hinein? Erstens: Die Objekte, also welche fachlichen Gegenstände bewegen sich durch den Prozess, zum Beispiel Bestellung, Lieferschein, Rechnung oder Supportfall. Zweitens: Die Begriffe mit einer eindeutigen Definition. Was genau heisst bei euch im Unternehmen aktiver Kunde? Wenn das Marketing aktiv anders definiert als das Controlling, halluziniert die KI später Widersprüche. Drittens: Die Regeln, Schwellenwerte und Freigabegrenzen, die bisher nur erfahrene Mitarbeitende im Kopf haben. Viertens: Die Verantwortung, namentlich benannte Personen je Objekt, nicht eine anonyme Abteilung. Und fünftens: Die Maschinenlesbarkeit. Ein schönes Glossar als PDF Dokument nützt einem KI Agenten überhaupt nichts, es muss strukturiert abfragbar sein. Und auf dieser Basis bauen wir die Datenlandkarte. Für die meisten KMU reicht dafür eine simple Tabelle mit fünf Spalten: Information, Quellsystem, Entität, führendes System und Zugriffsweg. Nehmen wir ein konkretes Beispiel aus dem Kundensupport. Information: Ticketverlauf, Quellsystem Zendesk, Entität Supportfall, führendes System Zendesk, Zugriff über API freigegeben. Nächste Zeile: Produktstammdaten, Quellsystem SAP ERP, Entität Produkt, führendes System SAP ERP, Zugriff über nächtlichen Export. Dritte Zeile: Preisliste, Quellsystem SharePoint Excel Datei, Entität Produkt, führendes System strittig, Zugriff nur manuell. Und genau diese rot oder türkis markierten Zeilen mit strittigen Systemen oder manuellen Zugriffen werden später zu deinen Risiko Flags.

Marc

Warum ist die Frage nach dem System of Record, also dem führenden System, bei KI Projekten so enorm kritisch? Ein Mensch im Support merkt, wenn das CRM sagt, der Kunde ist aktiv, das ERP System aber meldet, der Kunde ist wegen Zahlungsrückständen gesperrt. Der Mensch greift zum Telefon und fragt nach. Ein KI Agent kann das nicht! Der Agent nimmt den ersten Wert, den er in der Datenbank findet, und antwortet dem Kunden. Wenn sich die Systeme widersprechen, liefert die KI zwei völlig unterschiedliche, aber plausibel klingende Antworten. Und nach dem ersten Widerspruch beim Kunden ist das Vertrauen in die KI Lösung für immer weg.

Stefan

Kommen wir zu Teil drei: Dateneignung messbar machen, Datenschutz und Repräsentativität. Marc, wie oft hörst du den Satz: Unsere Datenqualität ist leider schlecht? Das ist eine typische Stammtischbehauptung. Im KI Business Specialist Training lernen wir, Qualität in sechs konkrete Dimensionen nach DAMA UK zu zerlegen, jeweils mit einer harten Kennzahl und einer Schwelle. Dimension eins: Vollständigkeit, also der Anteil belegter Pflichtfelder. Dimension zwei: Eindeutigkeit, die Dublettenquote. Dimension drei: Aktualität, die Zeit vom Ereignis bis zur Erfassung. Dimension vier: Gültigkeit, das korrekte Format. Dimension fünf: Genauigkeit oder Accuracy, die Trefferquote gegen eine Stichprobe. Und Dimension sechs: Konsistenz, die Abweichung über Systeme hinweg.

Marc

Und der Unterschied in der Kommunikation ist gewaltig! Statt zu sagen, unsere Artikeldaten sind schlecht, sagst du in der Geschäftsleitungssitzung: Zwölf Prozent unserer Artikelstammdaten haben kein Gewicht hinterlegt. Damit ist die geplante automatische Frachtkostenprognose in dieser Form nicht machbar. Das ist eine Aussage, auf deren Basis man Entscheidungen treffen kann! Es macht den Aufbereitungsaufwand schätzbar, die Lücke behebbar und gibt dir eine Baseline, um in sechs Monaten die echte Verbesserung vorzuweisen. Dazukommen bei KI noch zwei Spezialfragen: Ist die Granularität, also die zeitliche und fachliche Auflösung fein genug? Und gibt es bekannte Labels, also historische richtige Antworten, an denen das Modell lernen oder geprüft werden kann?

Stefan

Zur Einordnung der Datenreife nutzen wir die Data Readiness Levels nach Neil Lawrence in drei Bändern. Band C bedeutet zugänglich: Die Daten existieren, sind auffindbar und lesbar. Band B bedeutet glaubwürdig: Fehlwerte, Ausreisser und Erhebungslogik sind geprüft. Und erst Band A bedeutet nutzbar: Die Daten beantworten die konkrete Frage des Anwendungsfalls in der nötigen Auflösung. Wenn die IT Abteilung sagt, die Daten sind da, meint sie fast immer Band C. Der Fachbereich braucht für eine funktionierende KI aber Band A. Dieser Unterschied erklärt viele Missverständnisse in Projekten.

Marc

Ein ganz wesentlicher Block betrifft das Recht und die Compliance. In der Schweiz gilt seit September zweitausenddreiundzwanzig das revidierte Datenschutzgesetz mit den klaren Grundsätzen der Zweckbindung, der Datenminimierung und der Transparenz. Und der Bundesrat arbeitet an der KI Regulierung bis Ende zweitausendsechsundzwanzig. Stefan, welche rechtlichen Prüfschritte muss jeder AI Business Specialist vorab durchlaufen? Sechs Schritte: Erste Frage: Sind Personendaten oder besonders schützenswerte Personendaten im Spiel? Zweitens: War die geplante KI Nutzung bei der ursprünglichen Beschaffung der Daten erkennbar, oder liegt eine unzulässige Zweckänderung vor? Drittens: Datenminimierung, welche Felder brauchst du wirklich? Viertens: Geht der Anwendungsfall auch ohne Personenbezug, also aggregiert oder anonymisiert? Ein sehr schönes Beispiel aus den Medien von Juni zweitausendsechsundzwanzig ist das Swisscom System Kira in Verkaufsfilialen oder Vorabklärungen des EDÖB zu Coop Kamerasystemen. Der Eidgenössische Datenschutzbeauftragte hielt fest: Werden Informationen ohne Personenbezug erfasst, kann der Einsatz datenschutzkonform qualifiziert werden. Das ist ein klarer Gestaltungsauftrag an uns! Fünftens: Verträge und Nutzungsbedingungen prüfen. Und sechstens: Aufbewahrungs und Löschkonzepte festlegen.

Stefan

Auch der internationale Blick auf die Regulierung ist extrem spannend. Der EU AI Act verlangt in Artikel zehn umfassende Daten Governance für Hochrisiko Systeme. Und mit dem Verordnungspaket Digital Omnibus on AI, der Verordnung EU zweitausendsechshundertsechsundsiebzig aus siebzehnundvierzig, veröffentlich am vierundzwanzigsten Juli zweitausendsechsundzwanzig und in Kraft seit siebenundzwanzigsten Juli zweitausendsechsundzwanzig, wurden die Fristen für Anhang drei auf den zweiten Dezember zweitausendsiebenundzwanzig angepasst. Aber Achtung: Die Transparenzpflichten nach Artikel fünfzig gelten seit dem zweiten August zweitausendsechsundzwanzig unverändert! Auch wenn man kein Hochrisiko System baut, ist Artikel zehn der beste Leitfaden für ein Audit.

Marc

Und zum Abschluss von Teil vier müssen wir unbedingt über Repräsentativität und Bias sprechen. Da gab es Ende Juni zweitausendsechsundzwanzig eine spektakuläre Studie der Stanford University gemeinsam mit Chapman und Northeastern. Sie untersuchten über vier Millionen Bewerbungen von drei Komma vier Millionen Personen bei einhundertsechsundfünfzig Arbeitgebern auf einer KI Plattform. Der Plattformanbieter hatte vorher aggregiert über alle Daten ausgewertet und keine Benachteiligung gefunden. Als die Forschenden aber die Daten je einzelnen Job ausgewertet haben, kam heraus, dass sechsundanzanzig Prozent der Bewerbungen Schwarzer Kandidaten in Verfahren mit benachteiligender Wirkung landeten! Marc, was lernen wir daraus für unsere Audits? Dass aggregierte Durchschnitte lügen! Wer nur auf der Gesamtebene prüft, glättet genau die Verzerrungen raus, die Schaden anrichten. Du musst die Prüfebene festlegen, bevor du mit der Analyse fängst. Sonst suchst du dir unbewusst die Ebene aus, auf der nichts auffällt. Das ist ein enorm wichtiger Punkt für die Praxis und für die Prüfung.

Stefan

Genau. Und wie fassen wir all diese Erkenntnisse am Ende des Abends zusammen? Mit der Entscheidungsmatrix der Fünf Ampeln. Jeder Anwendungsfall kriegt fünf Ampeln: Verfügbarkeit, Qualität, Repräsentativität, Recht und Aufwand. Und hier unterscheiden wir ganz genau: Ein fehlender technischer Zugang ist eine Aufwandfrage und durch ein Vorprojekt lösbar. Eine Verletzung der rechtlichen Zweckbindung ist keine Risikofrage, sondern ein absolutes Ausschlusskriterium. Rot bei Recht heisst Stopp. Und wir formulieren vorab klare Abbruchkriterien, damit nicht nachträglich im Projekt verhandelt wird.

Marc

Das bringt uns direkt zur Projektwerkstatt von zwanzig bis einundzwanzig Uhr. Dozent Thomas Wengi gibt der Klasse keine künstliche Zusatzaufgabe, sondern stellt den Abend direkt in den Dienst der laufenden Wochenaufgabe zwei. Konkret geht es um Frage drei der Aufgabenstellung: Welche Daten braucht dein Anwendungsfall und wo liegen sie heute? In den ersten fünfzehn Minuten sammeln die Teilnehmenden im Hauptraum oder in Zweiergruppen die Datenquellen in den fünf Spalten der Datenlandkarte. Und in den folgenden zwanzig Minuten bewerten sie diese Daten anhand der vier Punkte Qualität, Verfügbarkeit, Rechtsgrundlage und Risiken. AI Coachin Mary steht auf der Plattform als Sparringspartnerin zur Verfügung.

Stefan

Lass uns zum Schluss noch die drei Kerngedanken für den Heimweg zusammenfassen, die den roten Faden von Tag sechs bilden. Erstens: Dateneignung ist keine absolute Eigenschaft von Daten, sondern immer eine Aussage über die Beziehung zwischen einem Datenbestand und einer konkreten Aufgabenstellung. Zweitens: Der Anwendungsfall setzt den Scope, der Scope macht die Erhebung überhaupt erst machbar, die Erhebung liefert die Datenlandkarte, und erst darauf lässt sich Eignung messen statt nur behaupten. Und drittens: Ein ehrliches Nein aus dem Daten Audit ist keine Niederlage, sondern ein gewaltiger Erfolg! Es verhindert eine kostspielige Investition in ein Projekt, das auf sandigem Fundament gebaut gewesen wäre, und zwar zu einem Zeitpunkt, an dem der Stopp noch fast nichts kostet.

Marc

Ein hervorragendes Schlusswort für den heutigen Tag sechs! Am kommenden Freitag an Tag sieben geht es weiter mit Plattformen, Datenlandschaft und Total Cost of Ownership, bevor an Tag acht die Priorisierung ansteht. Allen Teilnehmenden der Graduate School of Applied Technology and Management wünschen wir viel Erfolg beim Erarbeiten des Daten Audits für die Wochenaufgabe bis Sonntag um achtzehn Uhr. Bis zum nächsten Mal!