Tag 14: AIBS-Zertifizierung, KI-Risiken und der Two Pager

Marc

Es sind jetzt, um genau zu sein, noch knapp zwei Wochen. Am ersten Oktober zweitausendsechsundzwanzig muss dieser zwei seitige Projektbericht für die AIBS Zertifizierung stehen. Und, er, man merkt im Markt sofort, wie der Druck bei den Teilnehmenden steigt.

Stefan

Oh ja, der berühmte Two Pager! Da kommen bei vielen plötzlich Erinnerungen an alte Schulzeiten oder universitäre Prüfungen hoch, wo man Nachtschichten eingelegt hat. Aber, um, Marc, ist das im Grunde nicht der beste agile Test, den man sich überhaupt vorstellen kann?

Marc

Absolut. Ich sage den Leuten immer wieder, seht das nicht als bürokratische Schreckenskammer. Wer seit zehn oder fünfzehn Jahren im Projektmanagement arbeitet, fühlt sich durch so eine formale Prüfungssituation vielleicht erst mal verunsichert. Aber genau diese Erfahrung zwingt einen dazu, unter Zeitdruck extrem fokussiert und entscheidungsstark zu bleiben. Das ist reine agile Fitness.

Stefan

Und wie sieht das auf dem Schweizer Arbeitsmarkt aus? Du sprichst ja ständig mit Personalverantwortlichen und Headhuntern. Ist so ein Zertifikat im verdeckten Stellenmarkt wirklich ein Türöffner?

Marc

Und wie. Viele Stellen für Führungskräfte im Bereich KI werden vergeben, bevor sie überhaupt irgendwo auf einer Jobplattform auftauchen. Und was suchen Unternehmen heute verzweifelt? Nicht die Person, die Fünfundfünfzig Prompt Engineering Tricks kennt, sondern Projektleiter mit nachgewiesener Governance und Risikokompetenz. Wer zeigen kann, dass er Risiken nicht nur versteht, sondern auch führen und bepreisen kann, steht ganz oben auf den Listen.

Stefan

Aber lass uns mal direkt über den Prüfungsaufbau sprechen. Teil eins ist ja die mündliche Prüfung. Fünfundvierzig Minuten, und das macht ganze fünfzig Prozent der Gesamtnote aus. Das ist heftig.

Marc

Ja, genau. Und hier liegt der ganz grosse Stolperstein, an dem jedes Jahr Kandidaten scheitern. Die Leute gehen rein und fangen an, die Methodik der FMEA zu referieren. Sie erklären brav, was eine Fehlermöglichkeits und Einflussanalyse ist, wie man Tabellen ausfüllt und so weiter.

Stefan

Und die Experten im Raum schalten ab.

Marc

Genau! Wer die FMEA erklärt, hat referiert. Wer sagt, was er entschieden hat und warum, hat geführt. In den Prüfungsunterlagen der ICT Berufsbildung steht der Begriff FMEA oder Mitigation sogar null Mal drin. Gefragt ist nie das Lehrbuchwissen über die Methode, sondern deine konkrete Managemententscheidung.

Stefan

Verstehe. Die Prüfung verlangt das Können, nicht das Aufsagen der Fachbegriffe. Erst die Entscheidung nennen, und die Methode höchstens als Beleg hinterher schieben.

Marc

Ganz genau so ist es. Und das schauen wir uns an Tag vierzehn intensiv an.

Stefan

An Tag vierzehn geht es ja ans Eingemachte. Risiken bewerten, behandeln und bepreisen. Und das Erste, was wir streichen müssen, ist dieses schwammige Wunschdenken. Sätze wie, er, ich habe mir das so gewünscht, oder das Team wird schon darauf achten, sind absolut verboten.

Marc

Stimmt. Wenn du in der Bewertung eine Sieben oder eine Acht vergibst, fragt in der Prüfung niemand nach der Zahl selbst. Sie fragen, warum die Bedeutung so hoch ist. Du brauchst für jede Dimension, also Bedeutung, Auftreten und Entdeckung, mindestens einen sauberen, begründenden Halbsatz.

Stefan

Wobei wir hier zu einem mathematischen Klassiker kommen, den wahnsinnig viele Teams immer noch falsch machen. Die klassische Risikoprioritätszahl, wo man einfach Bedeutung mal Auftreten mal Entdeckung rechnet. Warum ist das eigentlich gefährlich?

Marc

Weil man Rangzahlen schlicht nicht multiplizieren darf! Es gab zweitausendundacht diese berühmte Studie von Tony Cox in der Fachzeitschrift Risk Analysis. Er hat nachgewiesen, dass typische Risikomatrizen unter zehn Prozent aller Risikopaare eindeutig ordnen können. In ungünstigen Fällen führen solche Multiplikationen zu Entscheidungen, die schlechter sind als der pure Zufall.

Stefan

Weil zehn mal zwei mal fünf rechnungsrelevant genau dasselbe Ergebnis liefert wie zwei mal zehn mal fünf! Nämlich einhundert. Aber im ersten Fall ist die Schadensfolge extrem schwer und der Fehler tritt selten auf, während im zweiten Fall die Schadensfolge minimal ist, aber der Fehler ständig passiert.

Marc

Genau das ist der Punkt! Deshalb haben der amerikanische Automobilverband AIAG und der deutsche VDA bereits zweitausendneunzehn im harmonisierten Standard die Risikoprioritätszahl komplett abgeschafft und durch die sogenannte Aufgabenpriorität ersetzt.

Stefan

Weil die Aufgabenpriorität der Schadensbedeutung, also der Severity, den klaren Vorrang gibt, anstatt alles in ein Produkt zu werfen.

Marc

Richtig. Wenn ein KI System eine potenziell ruinöse Falschantwort liefert, dann hilft es dir überhaupt nichts, wenn das statistisch gesehen nur in null komma ein Prozent der Fälle vorkommt. Eine mathematische Grünfärbung durch eine niedrige Eintrittswahrscheinlichkeit ist fahrlässig.

Stefan

Wir müssen unbedingt über den Fall Deloitte Australien sprechen. Das ist das perfekte Lehrbeispiel aus dem Oktober zweitausendfünfundzwanzig für das, was bei KI Systemen schiefgeht.

Marc

Erzähl mal genau, was da passiert ist. Die Zahlen klingen ja spektakulär.

Stefan

Deloitte hatte von der australischen Regierung einen Beratungssprachauftrag über rund vierhundertvierzigtausend australische Dollar. Der Bericht wurde abgeliefert, intern gegengelesen, vom Auftraggeber bezahlt. Und dann stellt sich heraus: Der Bericht enthielt von der KI erfundene Quellenangaben und ein komplett falsch zugeschriebenes Gerichtszitat! Deloitte musste am Ende die Schlussrate von siebenundneunzigtausend Dollar zurückerstatten.

Marc

Und wer hat den Fehler bemerkt? Eine interne Qualitätskontrolle? Ein automatischer Check?

Stefan

Nein! Das ist ja der Skandal. Aufgefallen ist das erst einer externen Rechtswissenschaftlerin, die die Fussnoten zufällig nachgeschlagen hat. Weder intern bei Deloitte noch im Ministerium hat das vorher jemand gemerkt.

Marc

Und genau das zeigt die riesige Schwachstelle von Generativer KI. Bei einer klassischen Maschine bricht ein Teil ab, der Prozess stoppt, der Sensor schreit. Bei einem Sprachmodell wie unserem Mustercase ISA Desk sieht die Antwort perfekt aus, sie klingt plausibel, ist grammatikalisch makellos formuliert und zitiert sogar eine Quelle.

Stefan

Ganz genau. Deshalb ist bei KI Lösungen die Entdeckbarkeit, also das E in der FMEA, fast immer die gefährlichste Dimension. Ein gefährlicher Fehler ist nicht der, der oft passiert, sondern der, den niemand bemerkt.

Marc

Ich sehe das ständig in Schweizer Unternehmen. Da herrscht oft ein blindes Vertrauen in flüssig formulierte KI Antworten. Man liest einen Fliesstext, er klingt schlau, und schwupps wandert er in ein Management Board Paper. Das ist organisatorische Betriebsblindheit mit Ansage.

Stefan

Wenn Kursteilnehmende sagen, er, wir würden das im Betrieb schon merken, dann antworte ich immer: Das ist kein Kontrollmechanismus, das ist reine Hoffnung! Eine echte Kontrolle ist eine automatisierte Prüfregel, ein Abgleich gegen eine Datenbank oder eine verbindliche Stichprobe mit definierter Quote.

Marc

Wenn wir die Risiken identifiziert haben, stellt sich die Frage: Was tun wir dagegen? ISO dreitausendundzehn und der NIST AI Framework nennen exakt vier Wege der Risikobehandlung: Vermeiden, vermindern, übertragen oder bewusst tragen.

Stefan

Risikovermeidung klingt ja auf den ersten Blick super verlockend. Warum machen wir das nicht einfach immer?

Marc

Weil Risikovermeidung bedeutet, dass du die riskante Funktion schlicht nicht baust. Wenn der ISA Desk keine Rechtsauskünfte geben darf, schalten wir das Modul ab. Das eliminiert das Risiko zu einhundert Prozent, vernichtet aber gleichzeitig den gesamten geschäftlichen Nutzen der Funktion.

Stefan

Und was ist mit dem Übertragen von Risiken? Früher hat man doch gesagt, ach, im Zweifel greift unsere Betriebshaftpflichtversicherung.

Marc

Vergiss es! Seit Januar zweitausendsechsundzwanzig ist das Thema Silent AI endgültig Geschichte. Das Insurance Services Office hat die Standardformulare für Betriebshaftpflichtversicherungen angepasst. Generative KI Risiken sind da jetzt explizit ausgeschlossen.

Stefan

Das heisst, man kann KI Risiken heute nicht mehr einfach so an eine Versicherung abwälzen?

Marc

Korrekt. Übertragen funktioniert zweitausendsechsundzwanzig primär über knallharte Verträge mit den Softwareanbietern, nicht über Standard Versicherungen. Wer eine Versicherung in den Business Case schreibt, ohne die aktuelle KI Klausel der Police zu kennen, fällt in der Prüfung sofort durch.

Stefan

Lass uns noch über die operative Abnahme von Massnahmen sprechen. Hier gibt es die goldene Regel: Ohne Namen keine Massnahme!

Marc

Ein ganz wichtiger Punkt. Formulierungen wie, er, das Projektteam achtet auf die Quellengüte, sind wertlose Absichtserklärungen. Jede Massnahme braucht ein konkretes Verb, eine verantwortliche Person oder Rolle, einen Termin und die Verankerung im Betriebshandbuch.

Stefan

Genau. In Schweizer HR und Governance Strukturen sehen wir oft, dass Verantwortlichkeiten schwammig zwischen IT, Fachbereich und externen Dienstleistern hin und her geschoben werden. Wenn am Ende niemand namentlich geradesteht, existiert die Massnahme schlichtweg nicht.

Marc

Was passiert aber mit Risiken, die wir nicht vollständig beseitigen oder vermindern können? Hier hilft ein Blick in Artikel neun des Europäischen AI Acts. Das Restrisiko muss bewusst beurteilt, dokumentiert und den Betroffenen mitgeteilt werden.

Stefan

Ein Restrisiko ist keine ungewollte Restmenge, die halt so übrig bleibt, sondern eine explizite Managemententscheidung einer benannten Führungskraft mit einem festen Datum zur Wiedervorlage.

Marc

Und genau hier schlagen wir die Brücke zu Tag fünfzehn und dem Business Case! Jede Massnahme aus deinem Mitigationsplan hat ein Preisschild. Und wir müssen strikt trennen zwischen einmaligen Implementierungskosten und laufendem Betriebsaufwand über die Nutzungsdauer.

Stefan

Kannst du ein Beispiel machen?

Marc

Gerne. Beim ISA Desk kostet uns das Entwickeln von Prüfregeln und Sperrlisten einmalig vielleicht zwanzig Personentage. Aber das laufende Sichten und Pflegen der Wissensbasis durch den Fachbereich kostet monatlich einen halben Personentag. Hochgerechnet auf drei Jahre Nutzungsdauer ist der laufende Aufwand für die menschliche Kontrolle oft viermal so hoch wie der Bau der Software!

Stefan

Und das ist die fundamentale Hürde, wenn die kalkulierten Risikokosten als erste gefüllte Zeile ins Kostenmodell wandern. Plötzlich gerät der ganze Business Case ins Wackeln, weil die Kosten für Human in the Loop die Einsparungen auffressen.

Marc

Aber genau das ist ehrliche Projektführung. Um das in der mündlichen Prüfung perfekt vorzutragen, empfehlen wir den Fünf Sätze Leitfaden.

Stefan

Erstens: Das Risiko als ganzer Satz. Zweitens: Die Priorität begründet über Bedeutung und Entdeckung. Drittens: Die Massnahme mit Rolle, Termin und verworfener Alternative. Viertens: Das Restrisiko mit der entscheidenden Person. Und Fünftens: Der Aufwand, getrennt nach einmalig und laufend.

Marc

Wer diese fünf Sätze beherrscht, hat die Handlungskompetenzen C vier und C fünf perfekt abgedeckt und liefert am ersten Oktober eine makellose Arbeit ab.

Stefan

Besser kann man es nicht auf den Punkt bringen. Viel Erfolg beim Ausarbeiten!