Amazon baute einen KI-Recruiter, der sich selbst beibrachte, Frauen zu hassen. Ich baute einen, der es nicht kann.

Im Jahr 2014 setzte sich ein Team von Machine-Learning-Ingenieuren in Edinburgh daran, das Recruiting im Amazon-Maßstab zu lösen. Man füttert das System mit 100 Lebensläufen und erhält die besten fünf zurück, bewertet mit einem bis fünf Sternen – wie beim Bewerten von Produkten. Elegant. Effizient. Und innerhalb von drei Jahren stellten sie fest, dass sich das System selbst beigebracht hatte, dass Weiblichsein ein disqualifizierendes Merkmal war.

Die KI bestrafte Lebensläufe, die das Wort "Frauen-" enthielten – wie in "Kapitänin des Frauen-Schachclubs". Sie stufte Absolventinnen zweier reiner Frauencolleges herab. Nicht, weil es ihr jemand gesagt hätte. Sondern weil, wenn man ein Modell mit zehn Jahren Einstellungsdaten aus einer männerdominierten Branche trainiert, "männlich sein" statistisch zu einem der stärksten Prädiktoren für "eingestellt werden" wird.

Ich erinnere mich, dass ich die Reuters-Enthüllung las, als sie herauskam. Ich steckte bei Veriprajna bereits tief im Aufbau von Knowledge-Graph-Systemen, und meine erste Reaktion war nicht Schock – es war Wiedererkennen. Ich hatte seit Monaten argumentiert, dass statistische Korrelationsmaschinen nichts damit zu tun haben sollten, Entscheidungen über menschliches Potenzial zu treffen. Die Amazon-Geschichte war keine Anomalie. Sie war eine mathematische Zwangsläufigkeit. Und sie radikalisierte mich zu der Überzeugung, dass der gesamte architektonische Ansatz für KI-gestütztes Recruiting kaputt war – nicht an den Rändern, sondern im Fundament.

Das Problem ist nicht die Voreingenommenheit. Es ist die Architektur.

Hier ist, was die meisten Menschen am Amazon-Debakel falsch verstehen: Sie glauben, die Ingenieure seien nachlässig gewesen. Waren sie nicht. Sie gehörten zu den besten ML-Ingenieuren der Welt. Als sie die Geschlechterdiskriminierung entdeckten, versuchten sie, sie zu beheben. Sie programmierten das Modell ausdrücklich so, dass es geschlechtsspezifische Begriffe ignorieren sollte. Und das Modell fand Umgehungswege.

Das ist das Konzept der Proxy-Variablen, und es ist die Sache, die mich nachts wachhält. Deep-Learning-Modelle sind unerbittliche Mustersucher. Entfernt man das Wort "Frau" aus der Eingabe, klammert sich das Modell an die Satzstruktur. Studien zeigen, dass männliche Lebensläufe eher Verben wie "umgesetzt" und "erobert" verwenden, während weibliche Lebensläufe zu eher gemeinschaftlicher Sprache neigen. Das Modell sieht, dass "umgesetzt" mit "eingestellt" korreliert, und rekonstruiert die Geschlechterdiskriminierung stillschweigend allein über die Linguistik.

Amazons Ingenieure konnten die Voreingenommenheit nicht chirurgisch entfernen, ohne die Vorhersagefähigkeit des Modells zu zerstören. Also legten sie das gesamte Projekt still.

Man kann kein System reparieren, das versehentlich diskriminiert. Man muss eines bauen, das per Design nicht diskriminieren kann.

Dieser Satz ist seit drei Jahren mein Nordstern. Und er ist der Grund, warum wir Veriprajnas Recruiting-Engine auf Knowledge Graphs statt auf neuronalen Netzen aufgebaut haben.

Warum lernt jeder KI-Recruiter irgendwann zu diskriminieren?

Ich muss dir etwas darüber vermitteln, wie Deep Learning im Recruiting funktioniert, denn der Fehlermodus ist kontraintuitiv.

Ein neuronales Netz versteht nicht, was "Python" bedeutet. Es weiß nicht, dass Python eine Programmiersprache ist, die für Data Science nützlich ist. Es weiß nur, dass die Zeichenkette "Python" häufig in den Lebensläufen von Menschen auftauchte, die eingestellt wurden. Wenn "Lacrosse" ebenfalls häufig auftauchte – vielleicht wegen sozioökonomischer Korrelationen zwischen bestimmten Sportarten und bestimmten Schulen, die bestimmten Unternehmen zuarbeiten –, könnte das Modell "Lacrosse" genauso stark gewichten wie "Python".

Das ist Korrelation, die sich als Intelligenz ausgibt. Das Modell denkt nicht über Ursache und Wirkung nach. Es findet Muster und optimiert auf sie hin. Und hier ist der heimtückische Teil: Bias-Verstärkung bedeutet, dass diese Modelle historische Voreingenommenheiten nicht bloß replizieren – sie übertreiben sie. Wenn Männer in den Trainingsdaten 60 % der Belegschaft ausmachten, könnte das Modell dazu drängen, 80 % oder 90 % Männer einzustellen, um seinen Genauigkeitswert zu maximieren.

Ich hatte früh ein Gespräch mit einem potenziellen Investor, der mir sagte: "Nutzt einfach GPT-4 für das Screening von Lebensläufen. Alle anderen machen das auch." Ich fragte ihn: Wenn man denselben Lebenslauf zweimal in GPT-4 eingibt, bekommt man denselben Wert? Er hielt inne. Die Antwort ist nein – LLMs sind stochastisch. Sie sind nicht-deterministisch. Führe dieselbe Eingabe zweimal aus, und du bekommst zwei verschiedene Ausgaben. In einem Audit-Szenario ist das keine Marotte. Das ist ein Compliance-Versagen.

Die regulatorischen Mauern rücken näher

Das ist nicht mehr theoretisch. Regierungen haben die Amazon-Geschichte gesehen und sie erlassen Gesetze.

Das NYC Local Law 144, in Kraft seit Juli 2023, verlangt, dass jeder Arbeitgeber, der ein automatisiertes Werkzeug zur Beschäftigungsentscheidung einsetzt, sich einem jährlichen unabhängigen Bias-Audit unterzieht. Kein vages "wir haben auf Fairness geprüft"-Audit – ein spezifisches, quantitatives. Das Gesetz schreibt die Berechnung von Auswahlraten und Impact Ratios für jede Kategorie von Rasse, Ethnizität und Geschlecht vor. Wenn die Auswahlrate einer geschützten Gruppe geteilt durch die Rate der am häufigsten ausgewählten Gruppe unter 0,8 fällt – die "Vier-Fünftel-Regel" –, ist das ein Anscheinsbeweis für Disparate Impact.

Der EU AI Act geht weiter. Er stuft KI-Systeme, die für das Recruiting eingesetzt werden, als Hochrisiko ein – dieselbe Kategorie wie Medizinprodukte und kritische Infrastruktur. Artikel 13 verlangt, dass diese Systeme "hinreichend transparent" sind, "damit die Nutzer die Ergebnisse des Systems interpretieren können". Artikel 14 fordert menschliche Aufsicht – die Fähigkeit, KI-Entscheidungen zu übersteuern. Aber man kann eine Entscheidung nicht sinnvoll übersteuern, die man nicht versteht.

Und nach der DSGVO gewährt Artikel 15 Absatz 1 Buchstabe h betroffenen Personen das Recht auf Zugang zu "aussagekräftigen Informationen über die involvierte Logik" bei automatisierten Entscheidungen. Erwägungsgrund 71 erwähnt ausdrücklich das Recht, "eine Erläuterung der getroffenen Entscheidung zu erhalten".

Versuche, die Entscheidung eines neuronalen Netzes zu erklären. Nur zu. "Neuron 4.502 feuerte mit einer Intensität von 0,8" ist keine aussagekräftige Erklärung. Und "das Modell hat festgestellt, dass Sie zu 73 % passen" ohne weitere Details ebenso wenig.

Die Kluft zwischen technischer Komplexität und der gesetzlichen Anforderung einer einfachen Erklärung ist die zentrale Krise der modernen HR-Tech.

Ich habe über diese regulatorische Landschaft ausführlicher geschrieben, in der interaktiven Version unseres Whitepapers, die genau durchgeht, wie jede einzelne Regulierung auf verschiedene KI-Architekturen zutrifft.

Was wäre, wenn die KI das Geschlecht überhaupt nicht sehen könnte?

Hier muss ich dir von der Nacht erzählen, in der für mich alles einrastete.

Wir hatten mit verschiedenen Ansätzen zur Entzerrung von Voreingenommenheit experimentiert – adversariales Training, kontrafaktische Augmentierung, das übliche Werkzeugset. Und ich saß um 23 Uhr in unserem Büro und starrte auf eine Graphvisualisierung auf meinem Bildschirm, als ich eine dieser im Nachhinein offensichtlichen Erkenntnisse hatte: Wir versuchten, dem Modell beizubringen, Voreingenommenheit zu ignorieren. Was, wenn wir eine Architektur bauten, in der Voreingenommenheit buchstäblich gar nicht erst in die Reasoning-Engine gelangen konnte?

In einem Knowledge Graph werden Daten als Knoten (Entitäten) und Kanten (Beziehungen) gespeichert. Ein Personen-Knoten verbindet sich mit Skill-Knoten. Skill-Knoten verbinden sich über semantische Beziehungen mit anderen Skill-Knoten. Der Graph weiß, dass "PyTorch" eine Bibliothek für "Deep Learning" ist, was wiederum eine Teilmenge von "Künstlicher Intelligenz" ist. Wenn also eine Stelle "KI-Erfahrung" erfordert und eine Kandidatin "PyTorch" angibt, verfolgt der Graph den Pfad und findet eine Übereinstimmung – selbst wenn das Schlüsselwort "KI" nirgendwo im Lebenslauf auftaucht.

Hier ist die entscheidende architektonische Entscheidung: Wenn unser Matching-Algorithmus läuft, arbeitet er auf einem eingeschränkten Teilgraphen. Dieser Inferenzgraph enthält Skills, Rollen, Erfahrungsstufen und Zertifizierungen. Er schließt Knoten für Name, Geschlecht, Ethnizität, Adresse und Abschlussdaten ausdrücklich aus.

Die Voreingenommenheit wird nicht unterdrückt. Sie wird strukturell durchtrennt. Es gibt keinen Pfad von "Kandidat" zu "Geschlecht" zu "Rolle", weil der Geschlechts-Knoten in dem Graphen, den der Algorithmus sehen kann, nicht existiert.

Vergleiche das mit einem Deep-Learning-Modell, das den gesamten Rohtext aufnimmt. Selbst wenn man das Feld "Geschlecht" entfernt, liest das Modell "Frauen-Schachclub" und schließt auf das Geschlecht. In unserem System ordnet das LLM, das den Lebenslauf parst, "Frauen-Schachclub" einem neutralisierten Knoten zu: (:Activity {type: "Strategy Club", role: "Leadership"}). Der geschlechtsspezifische Zusatz wird entfernt, bevor er in die Reasoning-Engine gelangt.

Ich erinnere mich an die Diskussion im Team darüber. Einer meiner Ingenieure wehrte sich heftig – er meinte, wir würden wertvolles Signal verlieren, indem wir Kontext entfernten. "Was, wenn der Frauen-Schachclub tatsächlich wettbewerbsintensiver ist als der reguläre?" Berechtigter Einwand. Aber wir optimierten nicht auf maximale Informationsextraktion. Wir optimierten auf Fairness unter rechtlicher Prüfung. Und ich würde lieber ein marginales Signal verpassen, als ein System bauen, das lernt, die Hälfte der Bevölkerung zu bestrafen.

Wie misst man Talent tatsächlich ohne Voreingenommenheit?

Wir sagen nicht voraus, wer Erfolg haben wird. Wir messen die Skill-Distanz – die geometrische Lücke zwischen dem, was eine Kandidatin mitbringt, und dem, was eine Stelle erfordert. Das bewegt das Recruiting von subjektiver Wahrscheinlichkeit hin zu objektiver Messung.

Herkömmliche Bewerbermanagementsysteme verwenden boolesche Logik: Enthält der Lebenslauf das Schlüsselwort "Java"? Ja oder nein. Das ist brüchig und dumm. Es übersieht jeden, der eine andere Terminologie für dieselbe Kompetenz verwendet.

Wir verwenden Graph-Embeddings – Algorithmen wie Node2Vec, die eine Vektordarstellung für jeden Skill in unserer Ontologie lernen. Skills, die im Graphen häufig gemeinsam auftreten (wie "Python" und "Pandas"), landen im Vektorraum nahe beieinander. Skills, die nicht zusammenhängen (wie "Python" und "Phlebotomie"), landen weit voneinander entfernt.

Um eine Kandidatin zu bewerten, berechnen wir die Kosinus-Ähnlichkeit zwischen der Skill-Vektormenge der Kandidatin und der Anforderungs-Vektormenge der Stelle. Das gibt uns Teilpunkte. Eine Kandidatin, der "Tableau" fehlt, die aber "Power BI" hat, erhält einen hohen Ähnlichkeitswert, weil diese Knoten semantische Nachbarn im Cluster "Business Intelligence" sind. Eine Schlüsselwortsuche würde ihr eine Null geben.

Wir legen Jaccard-Ähnlichkeit für die reine Skill-Überschneidung obendrauf und geodätische Distanz – Kürzeste-Pfad-Berechnungen durch den Graphen – für die Lückenanalyse. Wenn eine Stelle Kubernetes erfordert und eine Kandidatin Docker hat, findet der Graph den Pfad: Docker → Containerisierung → Orchestrierung → Kubernetes. Distanz: 3 Sprünge. Interpretation: erlernbar. Wenn die Distanz 6 oder mehr Sprünge beträgt, ist es eine harte Lücke.

Der finale Skill-Distanz-Wert ist eine rein kompetenzbasierte Kennzahl, völlig blind gegenüber demografischen Merkmalen. Wir raten nicht, wer gut ist. Wir messen, wie nah sie dran sind.

Für die vollständige technische Aufschlüsselung dieser Algorithmen – einschließlich der Mathematik hinter der Kosinus-Ähnlichkeit und unserem zusammengesetzten Scoring-Modell – siehe unser Research-Paper.

Der "Fehlendes SQL"-Moment

Lass mich das mit etwas konkret machen, das während des Testens geschah.

Wir ließen ein Kandidatenprofil sowohl durch einen standardmäßigen Blackbox-Recruiter als auch durch unser System laufen. Die Blackbox lehnte den Kandidaten ab. Kein Grund angegeben. (Wir stellten später fest, dass der Kandidat ein kleines, weniger bekanntes College besucht hatte – eine klassische Herkunftsstrafe.)

Unser System gab Folgendes zurück: "Dem Kandidaten fehlt explizite SQL-Erfahrung. Die Graphanalyse zeigt jedoch umfangreiche Erfahrung mit Pandas DataFrames und R dplyr. Die Graphdistanz zwischen DataFrames und SQL ist kurz (gemeinsames Konzept: Datenmanipulation). Empfehlung: Interview. Hohe Übertragbarkeit."

Dieser Kandidat – derjenige, den die Blackbox weggeworfen hatte – hatte jeden Skill, den die Stelle brauchte. Er verwendete nur andere Wörter dafür. Und er hatte eine Schule besucht, von der die Blackbox in ihren Trainingsdaten nicht genug gesehen hatte, um sie als "erfolgreich" einzustufen.

Das meine ich, wenn ich sage, dass Knowledge Graphs den Talentpool erweitern. Sie finden Menschen, die die Kompetenzen haben, aber nicht die Herkunft oder das exakte Vokabular. Und das verbessert auf natürliche Weise die Diversität – nicht durch Quoten oder Anpassungen, sondern durch bessere Messung.

Was passiert, wenn das System ein Problem markiert?

Leute fragen mich: "Was, wenn Ihr System trotzdem voreingenommene Ergebnisse produziert?" Das ist eine berechtigte Frage, und ich wäre misstrauisch gegenüber jedem, der behauptete, sein System sei perfekt.

Hier ist der Unterschied: Wenn eine Blackbox voreingenommene Ergebnisse produziert, sitzt man fest. Man kann den Disparate Impact in den Zahlen sehen, aber man kann nicht sehen, warum. Sind es die Namen der Universitäten? Die Postleitzahlen? Der Schreibstil? Man debuggt ein System mit Millionen von Parametern und ohne lesbare Logik.

Wenn unser System eine statistische Anomalie produziert – sagen wir, eine Impact Ratio unter 0,8 für eine bestimmte demografische Gruppe –, können wir sie zurückverfolgen. Wir können die konkreten Graphknoten identifizieren, die die Diskrepanz verursachen. Vielleicht erfordert eine Stellenbeschreibung eine bestimmte teure Zertifizierung, die mit dem sozioökonomischen Status korreliert. Wir können das sehen, es markieren, und das Einstellungsteam kann entscheiden, ob diese Zertifizierung wirklich notwendig ist oder nur eine Altlast-Anforderung, die niemand hinterfragt hat.

Die Glassbox bedeutet nicht, dass das System immer recht hat. Sie bedeutet, dass man, wenn es sich irrt, herausfinden kann, warum, und es beheben kann.

Das LLM hat weiterhin eine Aufgabe – nur nicht die wichtige

Ich sollte klarstellen: Wir verwenden LLMs. Wir sind keine Maschinenstürmer. Aber wir verwenden sie so, wie man einen Übersetzer verwenden würde – zum Lesen und Schreiben, nicht zum Urteilen.

Unsere Architektur erzwingt eine strikte Trennung der Zuständigkeiten. Das LLM übernimmt die Wahrnehmung: Es liest unstrukturierten Lebenslauftext und extrahiert Entitäten. "Ich habe ein Team von 5 Entwicklern orchestriert, um eine React-Native-App zu bauen" wird zu strukturierten Daten – Skill: React Native, Skill: Teamführung, Kontext: Mobile Development. Das LLM normalisiert Synonyme: "ReactJS" und "React.js" werden beide demselben Knoten zugeordnet.

Aber das LLM trifft niemals eine Einstellungsentscheidung. Sämtliches Matching, Scoring und Ranking geschieht durch deterministische Graphtraversierung. Derselbe Graph plus dieselbe Abfrage ergibt jedes Mal dasselbe Ergebnis. Wir verwenden das LLM auch am Ausgabeende – es erzeugt für Menschen lesbare Erklärungen, aber nur aus graphverifizierten Fakten. Es kann keine Skill-Übereinstimmung halluzinieren, die der Graph nicht stützt.

Ich stelle es mir so vor, dass das LLM die Augen und der Mund des Systems ist, während der Knowledge Graph das Gehirn ist. Man würde seinen Mund nicht Entscheidungen für sich treffen lassen. (Nun ja, die meisten von uns würden das nicht.)

Wozwischen wählen wir eigentlich?

So wie ich es sehe, steht die Branche an einer Weggabelung. Der eine Weg führt zu größeren Modellen, mehr Parametern, mehr Undurchsichtigkeit – und einem endlosen Whack-a-Mole-Spiel mit Voreingenommenheit, die immer neue Proxy-Variablen zum Ausnutzen findet. Der andere Weg führt zu strukturiertem Reasoning, semantischer Messung und Systemen, die sich einem Regulierer, einem Recruiter oder einer abgelehnten Kandidatin erklären können.

Ich habe mit HR-Führungskräften bei Unternehmen gesprochen, die noch immer Blackbox-Screening-Werkzeuge verwenden. Sie kennen das Risiko. Sie haben über Amazon gelesen. Aber ein Architekturwechsel fühlt sich teuer und ungewiss an, also flicken sie weiter. Sie setzen "Bias-Minderungsschichten" auf grundlegend voreingenommene Systeme obendrauf. Sie engagieren Berater, die jährliche Audits durchführen, die ihnen sagen, was kaputt ist, ohne ihnen die Werkzeuge zu geben, es zu reparieren.

Daten sind ein Spiegel. Wenn man ein Modell auf der Vergangenheit trainiert, repliziert man die Vergangenheit. In einer Welt, die nach Gerechtigkeit strebt, ist das Replizieren der Vergangenheit eine Fehlerbedingung.

Ich werde das nicht mit einer Absicherung beenden. Ich habe Jahre damit verbracht, das aufzubauen, ich habe die Alternative spektakulär scheitern sehen, und ich bin von der Schlussfolgerung überzeugt: Die Zukunft der Recruiting-KI besteht nicht darin, vorherzusagen, wer Erfolg haben wird, basierend darauf, wer zuvor Erfolg hatte. Sie besteht darin, die tatsächliche Distanz zwischen dem, was jemand kann, und dem, was eine Stelle erfordert, zu messen – und diese Messung transparent, deterministisch und strukturell unfähig zur Diskriminierung zu machen.

Du kannst weiterhin die Vergangenheit vorhersagen. Oder du kannst anfangen, die Zukunft zu messen.