Faire KI bezeichnet die Anforderung, dass KI-Systeme nachweislich nicht diskriminieren und gesellschaftlich akzeptierte Werte erfüllen. Weil sich Fairness-Maße mathematisch widersprechen können, lässt sich Fairness nicht rein technisch lösen. Stattdessen strukturiert ein Assurance Case Framework die Anforderungen: von einer Hauptbehauptung über testbare Teilbehauptungen bis zu belegbaren Beweisen wie Testergebnissen oder Funktionalitäten.
Das Wichtigste in Kürze
- Fairness-Maße in der KI widersprechen sich mathematisch: wer eines optimiert, verschlechtert zwangsläufig ein anderes, weshalb Informatiker diese Entscheidung nicht allein treffen dürfen.
- Der Assurance-Case-Ansatz aus dem Safety Engineering lässt sich auf Fairness übertragen: eine Hauptbehauptung wird schrittweise in testbare Teilbehauptungen und belegbare Beweise zerlegt.
- In einem realen Industrieprojekt mit einem medizinischen Rotationsplaner zeigte das Framework, dass rund ein Viertel der nötigen Fairness-Maßnahmen noch nicht einmal im Entwicklungsplan stand.
- Stakeholder-Befragungen fördern Fairness-Anforderungen zutage, die über Nichtdiskriminierung weit hinausgehen, darunter Transparenz, Autonomie und praktische Aspekte wie geringe Wartezeiten zwischen Abteilungen.
- Eine strukturierte Argumentation über den Assurance Case schützt Entwickler rechtlich, weil sie bei Diskriminierungsvorwürfen nachweisen können, nach bestem Wissen und State of the Art vorgegangen zu sein.
Faire KI heißt zuerst: festlegen, was fair bedeuten soll
Fairness lässt sich in der Informatik nicht von Entwicklern allein definieren. Sie ist eine gesellschaftliche Anforderung, die in testbare Kriterien übersetzt werden muss, und dieser Übersetzungsschritt gehört nicht in die Hände der Programmierer.
Der Grund liegt in der Verbreitung der Technologie. Software war schon immer in soziale Prozesse eingebettet, doch KI wird in so vielen Bereichen eingesetzt, dass plötzlich Anforderungen auftauchen, über die vorher niemand nachgedacht hat. Wer KI baut, hat ein Informatikstudium von fünf bis sieben Jahren hinter sich, aber keine ethische oder soziale Ausbildung und kein Domänenwissen etwa in der Medizin.
Marc Hauer beschreibt das Kernproblem am Beispiel der Personalauswahl. Früher hat niemand den Personalern bei jeder einzelnen Entscheidung auf die Finger geschaut, und das war auch nicht nötig: Ein Mensch trifft im Monat vielleicht zehn oder zwanzig solcher Entscheidungen. Eine KI skaliert dieselbe Logik auf eine ganz andere Menge. Genau dieser Skalierungseffekt zwingt dazu, den Begriff Fairness vorab zu klären.
Warum es keine objektive Fairness gibt
Fairness ist mathematisch nicht eindeutig auflösbar, weil sich verschiedene Fairness-Vorstellungen gegenseitig widersprechen können. Wer ein Maß optimiert, läuft gegen ein anderes.
Ein einfaches Beispiel macht das deutlich. Beim Kindergeld gilt eine Verteilung als fair, wenn alle dieselbe Menge an Ressourcen bekommen. In der Sozialhilfe gilt sie als fair, wenn nach der Vergabe ein Mindestmaß für alle erreicht ist. Beides wirkt intuitiv gerecht, doch beide Prinzipien lassen sich nicht gleichzeitig erfüllen.
Der Informatiker Kleinberg hat dieses Spannungsverhältnis für drei klar definierte Fairness-Maße gezeigt: Sie widersprechen sich. Genau deshalb darf die Entscheidung, was im konkreten Fall fair ist, nicht bei den Informatikern liegen.
Es gibt einen weiteren Fallstrick. Wer einfach den Auftrag bekommt, ein faires System zu bauen, kann am Ende alle verfügbaren Fairness-Maße durchrechnen und wird mit hoher Sicherheit eines finden, das einen guten Wert liefert. Eine belastbare Aussage über Fairness ist das nicht.
Wie der Assurance Case Fairness in testbare Anforderungen zerlegt
Der Ansatz stammt aus dem Safety Engineering und heißt Assurance Case Framework. Er macht aus einer abstrakten Behauptung eine strukturierte Argumentation, die sich belegen und anfechten lässt.
Am Anfang steht eine Hauptbehauptung. Im Safety Engineering lautet sie “Mein System ist sicher”, im Fairness-Kontext “Unser System ist fair”. Darunter folgt eine Argumentationsebene, die fragt: Welche Teilbehauptungen müssen erfüllt sein, damit die Hauptbehauptung gilt?
Diese Teilbehauptungen werden so lange weiter zerlegt, bis sie klein genug sind, um sie konkret zu belegen. Als Beleg dienen je nach Fall:
- eine vorhandene Funktionalität der Software,
- Testergebnisse und nachvollziehbare Testprozesse,
- Referenzen auf wissenschaftliche Veröffentlichungen,
- vorhandene fachliche Prozesse, etwa eine Kontaktmöglichkeit zum verantwortlichen Planer.
Zur Struktur gehören auch offen ausgewiesene Annahmen. Eine Annahme kann sein, dass man ausschließlich mit Fairness-Maßen arbeitet und nichts anderes betrachtet. Wird so eine Annahme offen notiert, kann ein Gutachter sie anfechten. Das ist der eigentliche Wert: Die Argumentation lässt sich von außen prüfen, kritisieren und nachschärfen.
Stakeholder-Befragung statt Maßzahl-Optimierung
Fairness wird konkret, sobald man die Betroffenen und Anwender fragt, was sie überhaupt als fair anerkennen würden. Das Ergebnis geht meist weit über Nichtdiskriminierung hinaus.
Tobias Krafft hat das Framework außerhalb der Safety-Welt erprobt, in einem Industrieprojekt für einen Medical Rotation Planner. Medizinstudenten durchlaufen für festgelegte Zeiträume verschiedene Krankenhäuser und Abteilungen. Eine KI-Komponente sollte die Pläne für diese Rotationen erstellen.
Die Befragung der Stakeholder ergab mehrere Anforderungen, die für sie zu Fairness gehören:
- Nichtdiskriminierung
- Transparenz
- Autonomie und Kontrolle über den eigenen Plan
- geringe Wartezeiten zwischen den Abteilungen
- möglichst selten umziehen zu müssen
Aus jeder dieser Anforderungen wurde eine Teilbehauptung unter der Hauptbehauptung “Unser System ist fair”. Für die Anforderung Transparenz und Kontrolle bedeutete das konkret: Der Student kann seinen Plan einsehen, sieht KPIs wie durchschnittliche Wartezeiten, kann seinen Plan anfechten und Kritik äußern, und es gibt Kontaktmöglichkeiten zum Planer, der am Ende über den Plan entscheidet.
Der Assurance Case deckt Lücken auf, bevor das System fertig ist
Der größte praktische Nutzen zeigte sich entwicklungsbegleitend: Der Assurance Case macht sichtbar, welche Anforderungen noch gar nicht eingeplant sind.
Im Rotationsprojekt war die Stakeholder-Akzeptanz das wichtigste Ziel, deshalb wurde Fairness während der Entwicklung abgesichert, nicht erst danach. Beim Stand der Veröffentlichung vor rund neun Monaten konnte etwa die Hälfte der Beweise noch nicht erbracht werden, weil die Software noch nicht so weit war.
Auffälliger war der zweite Befund: Rund ein Viertel der nötigen Beweise stand nicht einmal im Entwicklungsplan. Über den Assurance Case wurden also neue Anforderungen und Funktionalitäten identifiziert, die anschließend in den Plan aufgenommen wurden. Ein Beispiel war die Möglichkeit, zwei alternativ erzeugte Pläne parallel zu vergleichen und direkt zu sehen, an welchen Stellen der eine besser ist als der andere.
KI macht Diskriminierung sichtbar, die vorher schon da war
Die Debatte über faire KI übersieht oft, dass menschliche Entscheidungen vorher selten besser waren. Der Mensch hatte seinen Bias und seinen Denktunnel, nur hat niemand systematisch hingeschaut.
Beim Einsatz von KI wird genauer geprüft, ob ein Ergebnis fair oder diskriminierend ist. Dieser Blick fördert Probleme zutage, die im rein menschlichen Prozess schlicht unbemerkt blieben. Der entscheidende Unterschied: Bei der KI kann man die Stellschrauben benennen, sie verstehen und das Ergebnis anfechten.
Die mediale Debatte zeichnet dabei ein einseitiges Bild. Berichtet wird über Diskriminierungsfälle, verweigerte Sozialhilfe, zurückgeforderte Gelder. Wo KI nützt, taucht selten auf. Diese Schieflage kann zu wirtschaftlichen Einbußen führen, sobald sich die Aufmerksamkeit auf einen Vorfall stürzt.
Eine dokumentierte Argumentation schützt die Entwickler
Ein nach State of the Art ausgearbeiteter Assurance Case dient als Argumentationsgrundlage, wenn ein Diskriminierungsvorwurf auftaucht. Er verlagert Verantwortung von den Schultern der Entwickler an die Stelle, an der sie hingehört.
Bisher heißt es: Du bist verantwortlich für dein Produkt. Aber ich als Informatiker habe entwickeln gelernt, ich habe keine ethische Ausbildung und kein Domänenwissen in der Medizin und weiß gar nicht, was für Folgen das haben kann. Marc Hauer
Mit der dokumentierten Variante des Assurance Case und allen Belegen und Annahmen lässt sich bei einem Vorfall sagen: Hier wurde nach bestem Wissen und Gewissen gearbeitet, das und das wurde getan, und nach heutigem Stand ist kein besserer Weg bekannt. Das senkt die Hürde, KI auch in Bereichen einzusetzen, in denen Fairness eine Rolle spielt.
Nicht jeder Einsatz braucht diesen Aufwand. Prüft eine KI am Fließband, ob eine Schraube der Norm entspricht, sind nichtfunktionale Anforderungen wie Fairness irrelevant. Genau dort soll schnell und agil gearbeitet werden.
Regulierung nach Risiko statt nach Gießkanne
Der europäische Ansatz reguliert KI risikobasiert und nicht alles gleich. Damit verlagert sich der Aufwand dorthin, wo eine Entscheidung kritisch wird.
Der AI Act sieht Risikoklassen vor. Genauer hingeschaut wird dort, wo eine KI über Menschenrechte oder Grundsatzfragen mitentscheidet. Wo der Mehrwert ohne kritische Folgen überwiegt, bleibt Raum für schnelles Arbeiten.
KI agiert ohnehin nie im rechtsfreien Raum. Unterstützt eine KI eine Ärztin, gilt der bestehende Regelkatalog ärztlichen Handelns weiter. Insofern führt die Risikobewertung nicht zwingend zu Überregulierung, sondern überträgt vorhandene Rechtskataster auf ein neues Werkzeug.
Templates und Open Source als Weg in die Breite
Ein Assurance Case lässt sich nicht eins zu eins von einem Projekt aufs nächste übertragen, aber für bestimmte Einsatzgebiete lassen sich brauchbare Templates vorbereiten. Darin liegt der Hebel, um die Methode über Einzelprojekte hinaus nutzbar zu machen.
Zum Stand der Verbreitung gibt es zwei wissenschaftliche Veröffentlichungen und ein Guidebook, das den Ansatz massentauglicher erklärt. In der Normungsroadmap KI ist das Verfahren als Vorschlag verankert. In einer Arbeitsgruppe zu Fairness von KI in Finanzdienstleistungen entsteht ein Template für Fairness-Aspekte bei Kreditvergabesystemen.
Die größte praktische Hürde ist, die richtigen Stakeholder an einen Tisch zu bekommen. Im engen Projektrahmen ist das schwierig, im offenen Aufruf an die Community kommen viele konkurrierende Ideen zusammen.
Als Fernziel skizziert Tobias ein Common-Task-Framework nach dem Vorbild der Bilderkennung: Die Community bekommt einen ausreichend spezifizierten Use Case, baut dazu Assurance Cases, teilt und verbessert sie und kürt nach ein, zwei Jahren den besten. Aus dem Safety-Bereich ist bekannt, dass die Methode trägt, und in einem Open-Source-Modell ließe sich genau diese Erfahrung breit teilen.
