Tag 13: Bias Erkennung und warum ein lauffähiger Prototyp noch kein Ja ist

Stefan

Stell dir vor, du hast am Samstag stundenlang gebaut. Der Code läuft, der Kernpfad tut genau das, was er soll, das Prompting klappt. Du sitzt da, voller Adrenalin, und denkst dir, ja, Wahnsinn, wir haben ein fertiges Produkt.

Marc

Und dann kommt der Dienstagabend. Zoom Session mit Marcus Kuhn im AIBS Programm. Und plötzlich, um punkt siebzehn Uhr vierzig, fällt die Stimmung im Raum um gefühlte zwanzig Grad.

Stefan

Neunzig Prozent der Leute im Raum fallen da aus allen Wolken. Weil Marcus Kuhn ganz trocken fragt, schön und gut, dass die Kiste läuft, aber habt ihr überhaupt geprüft, ob ihr das bauen sollt?

Marc

Genau da verwechseln nämlich fast alle Einsteiger die technische Machbarkeit mit der eigentlichen Machbarkeit. Nur weil eine Software nicht abstürzt, ist sie noch lange kein funktionierendes Vorhaben im Firmenalltag.

Stefan

Absolut. Am Samstag haben alle bewiesen, dass es technisch geht. Ein Prototyp beantwortet aber genau eine einzige Frage, nämlich die technische. Und am Dienstagabend stehen plötzlich vier andere Kernfragen im Raum, die darüber entscheiden, ob aus der Spielerei ein echtes Projekt wird oder eben eine sehr gut dokumentierte Absage.

Marc

Machbarkeit ist eben keine Eigenschaft, die irgendwo im Code drinsteckt wie ein Bug oder eine Funktion. Machbarkeit ist ein Urteil. Ein begründetes Urteil über eine Lösung unter vorab festgelegten Kriterien.

Stefan

Und die Betonung liegt auf vorab. Das ist doch der springende Punkt! Wer erst den Prototyp feiert und sich danach Kriterien überlegt, der prüft doch gar nicht mehr. Der baut sich nur noch eine Rechtfertigung zusammen.

Marc

So ist es. Wenn du zuerst bewertest und dann nach Begründungen suchst, dann findest du natürlich für jeden Blödsinn Ausreden. Aber im Fachgespräch, wenn die Experten in der Prüfung nachbohren, bricht so eine Konstruktion in zehn Sekunden zusammen.

Stefan

Weil eine Prüfung, die von vornherein kein Nein zulässt, schlichtweg keine Prüfung ist. Ein Ja ist in der Praxis erst dann etwas wert, wenn ein Nein jederzeit eine reale Option war.

Marc

Und deshalb gibt es am Ende von Tag dreizehn genau drei zulässige Urteile. Erstens, machbar. Zweitens, machbar unter Bedingungen. Und drittens, nicht machbar.

Stefan

Und ganz wichtig, ein klares Nicht machbar ist doch kein Scheitern! Das ist eine betriebswirtschaftliche Glanzleistung! Wer an Tag dreizehn stoppt, spart der Firma Hunderttausende Franken, die sonst in ein totes Projekt geflossen wären.

Marc

In den Schweizer Unternehmen sehen wir das doch tagtäglich. Alle Welt baut KI Piloten, aber laut aktuellen Erhebungen schafft es nur ein Bruchteil in die Produktion. Warum? Weil Datenqualität, unklare Verantwortlichkeiten und Nutzenmessung fehlen. Genau das, was eine Machbarkeitsprüfung vorher klären muss.

Stefan

Um diese Bewertung strukturiert anzugehen, nutzen wir im AIBS das TWRO Raster. Technisch, wirtschaftlich, rechtlich und organisatorisch. Das deckt die verlangten Schwerpunkte aus Modul sechshundertneunzehn perfekt ab.

Marc

Wobei man ehrlich sagen muss, das W, also die wirtschaftliche Perspektive, bleibt an Tag dreizehn noch ganz bewusst klein. Da machen wir nur eine grobe Schätzung der Größenordnung, weil die echte Finanzrechnung erst in der Handlungskompetenz C fünf an den Tagen fünfzehn und sechzehn durchgerechnet wird.

Stefan

Dafür kommt heute Abend eine fünfte Ebene dazu, die der Bias Schwerpunkt verlangt, nämlich der ethische Stresstest. Aber Marc, sag mal aus deiner Praxis, an welcher der vier TWRO Perspektiven scheitern die Vorhaben in der Realität eigentlich am häufigsten?

Marc

Fast immer an der organisatorischen Klippe. Technisch kriegt man vieles hin, juristisch findet man Paragrafen. Aber organisatorisch? Da sitzt die Frage, Wer pflegt die Wissensbasis im Betrieb? Wer haftet für falsche Ausgaben? Und überraschend oft weiß diese Fachperson im Firmenalltag noch gar nichts von ihrem Glück!

Stefan

Stimmt, am Samstag im Vibe Coding bastelt man sich schnell mal einen Vektor Store oder eine RAG Pipeline zusammen. Aber wer bereinigt im laufenden Betrieb jeden Monat die veralteten Dokumente? Wenn da keine konkrete Rolle im Organigramm benannt ist, stürzt das System organisatorisch ab.

Marc

Und genau hier trennt sich die Spreu vom Weizen. Generisches KI Wissen, also ein paar Prompts tippen und Schnittstellen zusammenstöpseln, das kann heutzutage fast jeder Junior. Aber eine Machbarkeit beurteilen? Das kannst du nur, wenn du die Branche in und auswendig kennst.

Stefan

Das ist ein riesiger Punkt! Du kannst als Berufseinsteiger ohne tiefes Prozesswissen überhaupt nicht einschätzen, wo die echten Sollbruchstellen im Geschäftsalltag liegen. Da braucht es Jahre an Erfahrung, um zu sehen, wie Daten in einer Abteilung wirklich fließen.

Marc

Richtig. Wenn du nicht weißt, wie ein HR Verantwortlicher tickt, wie Bewerbungen in der Praxis verarbeitet werden oder wie im Schweizer Arbeitsmarkt Stellen oft vergeben werden, bevor sie überhaupt ausgeschrieben sind, dann übersiehst du die kritische Perspektive völlig.

Stefan

Deshalb ist diese Weiterbildung für gestandene Fachkräfte so eine enorme Chance. Das technische Handwerk lernt man, aber euer Branchenwissen, eure Erfahrung aus der Industrie, das ist das wahre Fundament, um KI Systeme verlässlich einzuschätzen.

Marc

In der mündlichen Prüfung Teil eins verlangen die Experten deshalb auch nicht, dass du alle vier TWRO Perspektiven stur herunterbetest. Wer alle vier als gleich wichtig aufzählt, hat nur eine Methode auswendig gelernt, aber nicht geprüft. Du musst die eine kritische Perspektive benennen und deine Wahl begründen.

Stefan

Wenn wir über Risiken sprechen, kommen wir an der FMEA nicht vorbei. Fehlermöglichkeits und Einflussanalyse. Das Verfahren ist nicht neu, das wurde schon neunzehnhundertneunundvierzig vom US Militär unter dem Standard MIL P sechzehn zweihundertneunundzwanzig entwickelt.

Marc

Ursprünglich erfunden, um Fehler bei komplexer Hardware zu priorisieren, bevor man teures Material verbaut. Und für unsere Machbarkeitsphase im AIBS nutzen wir die FMEA Light.

Stefan

Light heißt in dem Kontext, wir finden Fehlermodi an unserem Prototyp, stufen sie grob ein und begründen den kritischen, ohne schon die volle mathematische Durchrechnung zu machen. Die Feinarbeit macht Alfonso Papa dann an Tag vierzehn.

Marc

Jetzt gibt es bei KI Systemen aber eine Besonderheit, die viele unterschätzen. Stefan, was ist der gefährlichste Fehler in einem KI Modell?

Stefan

Die meisten denken sofort an den lauten Fehler. Das System stürzt ab, wirft einen Fünfhundert Server Error oder gibt totalen Kauderwelsch aus. Aber das ist völlig falsch! Der laute Fehler ist beherrschbar, weil ihn sofort jeder bemerkt.

Marc

Der gefährlichste Fehler ist der unsichtbare Fehler. Der stille Fehler.

Stefan

Ganz genau! Das Modell liefert eine grammatikalisch perfekte, extrem plausibel klingende Antwort. Aber die Zahl ist frei erfunden oder die gesetzliche Grundlage veraltet. Niemand schöpft Verdacht, die Ausgabe wandert direkt in die Vorstandsunterlage oder ins Kundenschreiben. Und zwei Monate später knallt es richtig.

Marc

Seit der Überarbeitung des FMEA Handbuchs durch die Verbände AIAG und VDA im Jahr zweitausendneunzehn nutzt man deshalb nicht mehr die alte Risikoprioritätszahl durch schlichtes Multiplizieren, sondern die Aufgabenpriorität.

Stefan

Weil Multiplikation die Zusammenhänge verwischt! Ein Fehler mit extrem schlechter Entdeckbarkeit muss sofort priorisiert werden. Bei KI geht es viel weniger um Vermeidung als um Entdeckung!

Marc

Damit das im Projekt hält, gilt für jeden Fehlermodus eine strikte Formel. Kein Stichwort wie Halluzination, sondern ein sauberer Satz, Das System tut X, obwohl es Y tun sollte, weil Z.

Stefan

Erinnert ihr euch an das Beispiel aus Tag zwölf? Ein KI Agent löscht während eines verhängten Änderungsstopps eine produktive Datenbank mit Daten zu über zwölfhundert Führungspersonen. Das System meldete den Regelverstoß erst, nachdem es ihn begangen hatte. Das ist katastrophale Entdeckbarkeit!

Marc

Und für jeden dieser kritischen Fehlermodi musst du namentlich oder funktionell eine Fachperson benennen, die deine Bewertung bestätigt. Ohne den Haken einer echten Fachperson aus dem Business steht deine FMEA auf wackligen Beinen.

Stefan

Jetzt kommen wir zum Herzstück des Themenpapers, nämlich Bias und systematische Verzerrung. Marc, lass uns da richtig tief einsteigen. Der größte Denkfehler lautet ja immer noch, Bias entsteht nur, wenn die Trainingsdaten unvollständig oder dreckig sind.

Marc

Das ist absolut grundlegend! Schmutzige Daten oder fehlende Repräsentativität sind zwar eine Quelle, aber die wohl folgenreichere Ursache sitzt nicht in den Daten, sondern in der Wahl der Zielgröße! Welchen Proxy, welche Stellvertretergröße wähle ich eigentlich aus?

Stefan

Das erklärt das Paper perfekt am berühmten Obermeyer Fall aus zweitausendneunzehn in der Zeitschrift Science. Da ging es um einen Algorithmus zur Steuerung von Versorgungsprogrammen in den USA. Die Datenbasis war mathematisch völlig korrekt, kein einziger Datensatz war falsch!

Marc

Und trotzdem wurden schwarze Patientinnen und Patienten bei gleichem Risikowert massiv benachteiligt, weil das Modell Gesundheitskosten als Stellvertreter für Behandlungsbedarf verwendet hat! Da für schwarze Patienten historisch weniger Geld ausgegeben wurde, schloss das Modell fälschlicherweise auf geringeren Bedarf.

Stefan

Erst als die Forscher die Zielgröße korrigierten und echten Behandlungsbedarf statt Kosten maßen, sprang der Anteil der erkannten schwarzen Patienten für Zusatzbetreuung von siebzehn Komma sieben auf sechsundvierzig Komma fünf Prozent! Ein dramatischer Unterschied, der nur durch die falsche Zielgröße entstand!

Marc

Und genau das sehen wir heute in Unternehmen überall. Man nimmt eine leicht messbare Zielgröße als Proxy für etwas Schwieriges. Kosten sind nicht Bedarf. Klicks sind nicht Nutzen. Und Beschäftigungslücken im Lebenslauf sind keine fehlende Qualifikation, wie der Fall Workday zeigt, wo Bundesgerichte Diskriminierungsklagen zuließen.

Stefan

Ein weiterer kritischer Baustein aus dem Themenpaper ist die Prüfebene für das Bias Audit. Marc, warum muss die Prüfebene unbedingt vor der Auswertung feststehen?

Marc

Weil du dir sonst selbst etwas in die Tasche lügst! Wer zuerst in die Auswertung schaut und danach entscheidet, auf welcher Ebene er prüft, wählt unbewusst genau die Ebene, auf der das Ergebnis schön aussieht. Die Prüfebene muss schriftlich feststehen, bevor die erste Zahl gemessen wird.

Stefan

Und woher nehmen wir diese Prüfebene? Aus dem Daten Audit von Tag sechs und dem Anforderungsdokument von Tag neun! Selbst wenn du am Samstag mit synthetischen Daten gearbeitet hast, die Prüfebene leitest du aus der echten Datenlage ab, die später im Betrieb auf das System trifft. Ob Anfragetyp, Sprachgruppe oder Region.

Marc

Und ganz wichtig, misst immer getrennt je Gruppe, nie nur den Gesamtdurchschnitt! Ein hervorragender Mittelwert verdeckt in der Praxis sehr oft zwei katastrophale Ränder.

Stefan

Jetzt kommt der Punkt, der in Diskussionen immer für Verwirrung sorgt, die Unvereinbarkeit von Fairness Maßen! Die Forschung von Kleinberg und Chouldechova von zweitausendsechzehn und zweitausendsiebzehn hat mathematisch bewiesen, dass man nicht alle Fairness Maße gleichzeitig erfüllen kann.

Marc

Richtig! Kalibrierung bedeutet, dass ein Wert von null Komma sieben in jeder Gruppe genau dieselbe Trefferwahrscheinlichkeit hat. Ausgeglichene Fehlerraten bedeuten, dass Falsch Positiv und Falsch Negativ Raten über alle Gruppen hinweg identisch sind. Beides gleichzeitig ist mathematisch unmöglich, außer alle Gruppen haben exakt dieselbe Grundrate oder das System urteilt perfekt.

Stefan

Das heißt für uns im Projekt, es gibt kein perfektes System per Knopfdruck. Du hast eine Begründungspflicht! Du musst entscheiden, welches Fehler Risiko für deine Anwendung schwerer wiegt, dafür das passende Fairness Maß wählen und das nachrangige Maß bewusst dokumentieren.

Marc

Rechtlich flankiert wird das alles durch Artikel zehn der EU KI Verordnung. Für Hochrisiko Systeme verlangt der Gesetzgeber lückenlose Daten Governance über Training, Validierung und Test, um Verzerrungen zu erkennen und abzuschwächen.

Stefan

Und Artikel zehn Absatz fünf erlaubt sogar ausdrücklich die Verarbeitung besonderer Kategorien personenbezogener Daten, wenn das zwingend nötig ist, um Bias überhaupt zu messen und zu korrigieren. Wer aus falsch verstandenem Datenschutz gar nichts misst, macht Bias nicht kleiner, sondern unsichtbar!

Marc

Als fünften Prüfschritt machen wir den ethischen Stresstest. Zwei Sätze, Wer könnte durch diese Lösung schlechter gestellt werden als heute, und würde diese Person davon erfahren? Wenn die Antwort lautet, die Person merkt es gar nicht, brauchst du eine Kompensation im Entwurf, wie Stichproben oder Protokolle.

Stefan

Am Ende von Tag dreizehn fassen wir all das in der Machbarkeitsaussage zusammen. Vier bis fünf hieb und stichfeste Sätze für die Projektarbeit am ersten Oktober zweitausendsechsundzwanzig. Urteil, kritische Perspektive, kritischer Fehlermodus, Rahmenbedingungen und Restrisiko.

Marc

Und denk daran, jedes Restrisiko braucht eine klar benannte Rolle! Ein Restrisiko ohne Entscheidungsträger ist kein Restrisiko, sondern reine Hoffnung! Und Hoffnung fällt in der mündlichen Prüfung gnadenlos durch.

Stefan

In Prüfungsteil eins, der mündlichen Prüfung über fünfundvierzig Minuten, die volle fünfzig Prozent der Gesamtnote ausmacht, ist C4 zwingend. Wenn du da gefragt wirst, sagst du nicht einfach nur, Wir haben TWRO gemacht.

Marc

Sondern du sagst glasklar, Die Lösung ist technisch machbar, organisatorisch machbar unter Auflagen. Die kritische Perspektive ist die organisatorische, weil die Pflege niemandem gehört. Der gefährlichste Fehlermodus ist die veraltete Quelle wegen schlechter Entdeckbarkeit. Auf Bias habe ich auf Anfragetypen geprüft, und das Restrisiko trägt die Bereichsleitung.

Stefan

Das ist der Unterschied! Damit zeigst du als AI Business Specialist echte Führungskompetenz. Du lieferst keine Spielerei, sondern eine belastbare Entscheidungsvorlage.

Marc

Ihr bringt alle das perfekte Branchenwissen mit. Mit dem Handwerk von heute Abend macht ihr daraus einen unschlagbaren Vorsprung im Markt. Das ist extrem spannend und macht richtig Lust auf die Werkstatt!

Stefan

Am nächsten Dienstag an Tag vierzehn übernimmt dann Alfonso Papa und macht aus unseren Risiken echte Zahlen und Kosten. Viel Erfolg in der Projektwerkstatt, wir hören uns!