Künstliche Intelligenz im Dienste der Diversität
  • Einführung
    • Was ist KIDD?
    • Was sind KI und AES?
    • Warum KIDD?
  • KIDD-Strukturen und Grundlagen
    • KIDD-Präambel
    • Rollen im KIDD-Prozess
      • Panel der Vielfalt (PdV)
      • KI-Modertator:in (KIM)
      • KI-Expert:in (KIX)
  • Der KIDD-Prozess
    • Was ist der KIDD-Prozess?
    • Ebene 1 - Strukturübersicht
    • Ebene 2 - Allgemeine Prozessübersicht
    • Ebene 3 - KIDD-Prozess im Detail
      • Abschnitt A: Vision
        • A1: Kenntnisnahme KIDD
        • ✅A2: Stakeholderanalyse und Einbindung relevanter innerbetrieblicher Akteur:innen
        • A3: Entscheidungsfindung KIDD
        • A4: Klärung der Rollen im KIDD-Prozess und Schulung der KIDD-Moderator:in
        • A5: Konkretisierung der Projektidee
        • A6: Allgemeine Rechtskonformitätsprüfung (Legal Compliance)
        • ✅A7: Kritikalitätsbewertung
        • ✅A8: Aufgabenklärung PdV
        • A9: Überprüfung der internen Regelkonformität
        • A10: Projektplanung KIDD-Prozess
        • A11: Information der Belegschaft
        • ✅A12: Einrichtung des PdV
        • ✅A13: Konkretisierung der Software-Anwendung
      • Abschnitt B: Anforderungsklärung
        • ✅B1: Konstituierung und Sensibilisierung des PdV
        • ✅B2: Partizipative Folgenabschätzung
        • ✅B3: Allgemeine PdV-Anforderungsklärung
        • B4: Austausch zu strategischen/organisationalen Anforderungen
        • ✅B5: Erstellung Ausschreibung (nur bei Einkauf)
        • ✅B6: Suche und Auswahl Software-Anbieter (nur bei Einkauf)
        • B7: Sensibilisierung Product-Owner:in
        • ✅B8: Herstellung von Transparenz über die Software
      • Abschnitt C: Adaption/Entwicklung
        • ✅C1: Vorstellung der Software für das PdV
        • ✅C2: Spezifische PdV-Anforderungsklärung
        • ✅C3: Testfall Definition
        • ✅C4: Backlog Priorisierung
        • C5: Refinement
        • C6: Adaption / Entwicklung
      • Abschnitt D: Test & Inbetriebnahme
        • ✅D1: Ausführung der Testfälle
        • ✅D2: Software-Demo (Review)
        • ✅D3: Bewertung der Software durch das PdV
        • ✅D4: Abnahme der Software durch das PdV und Absprache zum kontinuierlichen Monitoring
        • D5: Abnahme der Software durch weitere unternehmensinterne Akteur:innen
        • D6: Transparenzherstellung
        • D7: Inbetriebnahme der Software (Release)
        • ✅D8: Monitoring/Betriebsüberwachung
        • ✅D9: Fehlerbehebung/Change Request
  • KIDD in KMU
    • Was ist INQA-Coaching?
    • KIDD im INQA Coaching
      • Workshop KIDD im INQA Coaching
    • Diversity im INQA-Coaching
    • Die KI-Verordnung der EU - Handreichung für KMU
  • Schulungen
    • PdV Schulungen
      • Schulung - Partizipation
      • Schulung - Diversity und Ethik
      • Schulung - Algorithmen und KI
    • KIM Schulung
  • Qualitätskriterien und Selbstauditierung
    • Wozu Qualitätkriterien?
    • Selbstauditierung anhand der Qualitätskriterien
      • Qualitätskriterien zum Strukturaufbau (QS)
      • Qualitätskriterien zur Durchführung des KIDD-Prozesses (QP)
      • Ergebnisorientierte Qualitätskriterien (QE)
      • Rechtliche und ethische Qualitätskriterien (QRE)
  • Anhänge
    • Darstellung der Experimentierräume
      • Q_Perior und Chemistree
      • Heraeus Medical
      • msg Group
    • Tools und Handreichungen
      • Abschnitt A: Vision
        • A1: Kenntnisnahme KIDD
        • A2: Stakeholderanalyse und Einbindung relevanter innerbetrieblicher Akteur:innen
        • A4: Klärung der Rollen im KIDD-Prozess und Schulung der KIDD-Moderator:in
        • A6: Allgemeine Rechtskonformitätsprüfung (Legal Compliance)
        • A7: Kritikalitätsprüfung
        • A8: Aufgabenklärung PdV
        • A11: Information der Belegschaft
        • A12: Einrichtung des PdV
        • A13: Konkretisierung der Software-Anwendung
      • Abschnitt B: Anforderungsklärung
        • B1: Konstituierung und Sensibilisierung des PdV
        • B2: Partizipative Folgenabschätzung
        • B3: Allgemeine PdV-Anforderungsklärung
        • B5: Erstellung Ausschreibung (nur bei Einkauf)
        • B7: Sensibilisierung Product-Owner:in
        • B8: Herstellung von Transparenz über die Software
      • Abschnitt C: Adaption/Entwicklung
        • C1: Vorstellung der Software für das PdV
        • C2: Spezifische PdV-Anforderungsklärung
        • C3: Testfall Definition
        • C4: Backlog Priorisierung
        • C5: Refinement
        • C6: Adaption / Entwicklung
      • Abschnitt D: Test & Inbetriebnahme
        • D1: Ausführung der Testfälle
        • D3: Bewertung der Software durch das PdV
        • D8: Monitoring/Betriebsüberwachung
        • D9: Fehlerbehebung/Change Request
Powered by GitBook
On this page
  • Template für die Formulierung allgemeiner technischer bzw. strategisch/organisationaler Anforderungen
  • Einordnung in den KIDD-Prozess
  • Begriffsdefinitionen
  • Herleitung von KIDD-Zielen
  • Metafragen
  • Formulierung von Zielvorgaben für das System (ex ante)
  • Template
  • Literatur
Edit on GitHub
  1. Anhänge
  2. Tools und Handreichungen
  3. Abschnitt B: Anforderungsklärung

B3: Allgemeine PdV-Anforderungsklärung

Formulierung von KIDD-Zielen im KIDD-Prozess

PreviousB2: Partizipative FolgenabschätzungNextB5: Erstellung Ausschreibung (nur bei Einkauf)

Last updated 1 year ago

Template für die Formulierung allgemeiner technischer bzw. strategisch/organisationaler Anforderungen

Einordnung in den KIDD-Prozess

In des KIDD-Prozesses, Anforderungsklärung, findet eine erste Klärung der Anforderungen des PdV an das einzuführende algorithmische Entscheidungssystem (AES) im statt. An dieser Stelle geht es darum, Ziele zu formulieren, die das AES erfüllen soll, z.B. generell faire, diskriminierungsfreie Ergebnisse, oder auch die Erfüllung einer Quote.

Später dann in folgt die Formulierung von messbaren KIDD-KPIs sowie die Definition von Testfällen in , um die PdV-Anforderungen/Ziele, die mithilfe dieser Handreichung formuliert werden und entsprechend vorgenommene Anpassungen am System zu überprüfen. Für die Handreichung zu C2 siehe und für C3 .

Begriffsdefinitionen

Zielsetzung: Gewünschte Funktionsweise des Systems, die ex ante (dt. im Voraus) definiert wird. Das Panel der Vielfalt hat die Aufgabe, Zielvorgaben in Bezug auf und Diversität zu definieren. Diese Zielvorgaben können entweder dem System direkt als Zielvariablen mitgegeben werden oder als Zielkorridore definiert werden, mit denen dann ex post (dt. im Nachhinein) KPIs verglichen werden.

KPI (Key Performance Indicator): Leistungskennzahl, anhand derer der Fortschritt oder der Erfüllungsgrad hinsichtlich der Zielsetzung gemessen werden kann. Diese Messung erfolgt im Betrieb, ex post.

Testfälle: Überprüfung der gewünschten Funktionsweise des Systems in einem spezifischen Anwendungsfall. In einem Testfall werden Inputs ins System, erwartete Funktionsweise und erwartete Outputs des Systems definiert. In der Testphase wird dann für jeden Testfall die tatsächliche mit der erwarteten Funktionsweise verglichen.

Beispiel: Wenn in einem Lebenslauf nur der Geburtsort geändert wird, soll dies keinen Einfluss auf die Listung auf einer Shortlist für eine Stelle haben.

Um sicherzustellen, dass ein System aus Sicht des Panels der Vielfalt fair ist, müssen sowohl Zielsetzungen als auch KPIs und Testfälle definiert und überwacht werden (Monitoring).

Hierbei stellen sich folgende Fragen: wie entscheiden wir, was „fair“ ist aus der KIDD-Perspektive (ethisch und diversitätssensibel) und ob KIDD entsprechend wirksam ist?

Weiter konkretisiert:

  • Wie lassen sich die PdV-Anforderungen mit Zielen hinterlegen?

  • Wie lassen sich diese Ziele mit dem Ergebnis aus der Testung abgleichen?

  • Wie lässt sich bewerten, ob die Anpassungen am AES im KIDD-Sinne einer diversitätssensiblen Einführung erfolgreich waren?

Herleitung von KIDD-Zielen

Um die Wirksamkeit der KIDD-spezifischen Anpassungen an das AES zu überprüfen, ist die Formulierung KIDD spezifischer Ziele ratsam.

Hierbei knüpfen wir an die Algo.Rule Nr. 3 an, die vom iRightsLab und der Bertelsmann Stiftung in 2020 formuliert wurde. Diese empfiehlt „messbare Indikatoren auswählen und klar definieren, damit die beabsichtigte Wirkung und Erreichung der Ziele in der Praxis getestet werden können“ [].

Algo.Rule Nr. 3: Ziele und erwartete Wirkung dokumentieren

„Bei den Algo.Rules handelt es sich um einen Katalog an formalen Regeln, die beachtet werden müssen, um eine gesellschaftlich förderliche Gestaltung und Überprüfung von algorithmischen Systemen zu ermöglichen und zu erleichtern. Sie legen eine Grundlage für ethische Erwägungen und für die Um- und Durchsetzung rechtlicher Rahmenbedingungen.“ [, S. 13]

Bei der Formulierung dieser messbaren Indikatoren ist zu beachten, dass diese von der übergeordneten strategischen Zielsetzung des jeweiligen Unternehmens sowie dem Einsatzgebiet des AES abhängen und daher keine allgemeingültigen Zielgrößen vorgegeben werden können. Vielmehr geben wir in dieser Handreichung eine Hilfestellung zur Herleitung von KIDD-Zielen sowie weiterführende Literaturempfehlungen.

Metafragen

Um eine Bewertung des algorithmischen Entscheidungssystems (AES) in Bezug auf Diversität vornehmen zu können, ist die Auseinandersetzung mit einer Reihe von Metafragen notwendig. Diese sind im gegebenen betrieblichen Kontext und dem spezifischen Anwendungsfall zu beantworten.

Zur Veranschaulichung nehmen wir das Beispiel eines AES, das für das Recruiting im Unternehmen zur Anwendung kommt.

Hier könnten Sie sich folgende Fragen stellen:

  • Wie sieht der Status Quo bei den Beschäftigten in den Diversitätskategorien aus?

    • Persönliche Merkmale: Alter, Geschlecht, Herkunft

    • Weitere Merkmale: Arbeitserfahrung (in Jahren bzw. Senioritätslevel: Einstieg / Professional / Führungsrolle), fachliche Expertise, akademischer Grad / Ausbildung, Führungserfahrung

  • Welche Bezugsgröße wird zur Bewertung der Fairness der Ergebnisse gewählt?

    • Unternehmen (z.B. Recruiting Ergebnisse soll internen Status Quo abbilden)

    • Gesamtgesellschaft (z.B. Recruiting Ergebnisse sollen Diversität in ganz Deutschland repräsentieren)

  • Gibt es ein Recruiting-Ziel oder eine Diversitätsstrategie?

    • nach der die verschiedenen Diversitätskategorien im Recruiting gewichtet/priorisiert werden sollten (z.B. Füllen einer Vakanz mit spezifischen fachlichen Anforderungen, Fokus auf Fachkräftemangel, Steigerung des Frauenanteils in Fach- und Führungspositionen)

  • Welche Gewichtung / Priorisierung der einzelnen Kategorien wird daraufhin vorgenommen?

Formulierung von Zielvorgaben für das System (ex ante)

Die vom Panel der Vielfalt definierten Kennzahlen für Fairness können auf zwei ganz unterschiedlichen Wegen im algorithmischen Entscheidungssystem (AES) abgebildet werden.

Ist von vorne herein eine ganz bestimmte Funktionsweise des Systems gefordert, ist dies eine Zielvorgabe für das System. Je nachdem, ob das AES mit regelbasierten Algorithmen oder Machine Learning arbeitet, wird eine solche Zielvorgabe im System unterschiedlich umgesetzt.

Bei allen AES führt eine solche Zielvorgabe aber dazu, dass insgesamt weniger Freiheitsgrade bestehen und andere definierte Zielvorgaben an Gewicht verlieren. Daher sollte eine solche Zielvorgabe sehr genau durchdacht und in Bezug auf die anderen Zielvorgaben ans System gewichtet werden.

Am Beispiel des AES-gestützten Recruitings lassen sich einige Varianten von Zielvorgaben wie folgt formulieren.

Zielt man auf Fairness in Bezug auf die Gesamtgesellschaft bzw. den Bewerber:innen-Pool ab, so ergibt sich folgende Zielsetzung:

  • Repräsentativ: prozentualer Anteil auf der Shortlist entspricht dem Anteil im Bewerber:innen-Pool (z.B. Anteil von 10% Bewerber:innen mit Merkmal Y im Pool = 10% auf der Shortlist)

Gibt es dagegen eine spezifische Zielsetzung im Rahmen einer Diversitätsstrategie (z.B. Frauenanteil in technischen Berufsfeldern erhöhen bzw. konstant halten) so können die Ziele wie folgt formuliert werden:

  • Gewünschter Mehranteil: prozentualer Anteil auf der Shortlist liegt über tatsächlichem Anteil im Bewerber:innen-Pool (z.B. 10% Frauen im Bewerber:innen-Pool = 10% + x% auf der Shortlist)

  • Gleichverteilung: gleicher Anteil (50/50) aller Geschlechter auf der Shortlist unabhängig vom Bewerber:innen-Pool

  • Quote: Mind. x% eines bestimmten Geschlechts auf der Shortlist

  • Konkrete Kennzahl: Beispiel siehe unten

Beispiel: Das Unternehmen hat die Zielsetzung, Menschen aus Gruppe Y zu fördern. Um dies zu erreichen, wurde festgelegt, dass auf jeder Shortlist für jede Stelle stets mindestens ein Mitglied aus Gruppe Y erscheint.

Das AES erhält neben einer Reihe von anderen Zielvorgaben (z.B. „Eine Person soll eher auf der Shortlist erscheinen, wenn sie mehr Erfahrung mit den geforderten Skills besitzt.“ oder „Eine Person soll eher auf der Shortlist erscheinen, wenn sie bereits Erfahrung in der Branche hat.“ ) auch diese Zielvorgabe:

„Auf jeder Shortlist soll mindestens eine Person aus Gruppe Y erscheinen“.

Dies führt dazu, dass die Person aus Gruppe Y möglicherweise andere Personen, die aufgrund der anderen Zielsetzungen höher gelistet wäre, auf der Shortlist ersetzt. Dies kann im Sinne der Gesamt-Zielsetzung des Unternehmens sinnvoll sein, sollte aber gut überlegt sein.

Template

Konkret lässt sich das oben erwähnt im „Anforderungen-Annahmen“-Format festhalten.

Dadurch soll sichergestellt werden, dass die Annahmen hinter den Anforderungen transparent gemacht werden und diese in späteren Schritten des KIDD-Prozesses hilfreich sein können, um konkrete Messwerte und Testfälle abzuleiten. Ebenso können auch strategische und organisationale Anforderungen und Annahmen aufgelistet werden, die in nachfolgenden Schritten berücksichtigt werden sollen.

Anforderungen
Annahmen

Beispiel: Die Verteilung der Geschlechter bei den Ergebnissen einer Personalauswahl-Software sollte im Verhältnis zur Geschlechterverteilung bei den Bewerbungen spezifisch gesetzt und transparent gemacht werden.

Beispiel: Wenn die Geschlechter-Verteilung bei Input- und Output-Daten transparent ist, lässt sich leichter überprüfen, ob es unerwünschte Verzerrungen gibt.

Literatur

Die Formulierung von KIDD-KPIs, welche dann in relevant sind, wird in einer separaten Handreichung thematisiert. Ebenso finden Sie eine Handreichung für KIDD-Testfälle (C3) .

Eine ausführliche Auseinandersetzung zur Bedeutung von Diversity und Ethik und den relevanten Diversitätskategorien im Kontext des KIDD-Prozesses finden Sie in der .

Der zweite Weg, um mit Fairness-Kennzahlen in einem AES umzugehen, ist, relevante Daten im Betrieb zu erheben, in KPIs darzustellen und mit einem definierten Fairness-Zielkorridor zu vergleichen. Diese Formulierung von KIDD-KPIs wird in der zugehörigen Handreichung von thematisiert.

[1] Puntschuh, Michael; Fetic, Lajla (2020), Praxisleitfaden zu den Algo.Rules. Orientierungshilfen für Entwickler:innen und ihre Führungskräfte. iRights.Lab; Bertelsmann Stiftung. (, 17.08.2023)

[2] Hallensleben, Sebastian; Hustedt, Carla; Fetic, Lajla; Fleischer, Torsten; Grünke, Paul; Hagendorff, Thilo et al. (2020), From Principles to Practice. An interdisciplinary framework to operationalise AI ethics. AI Ethics Impact Group. (, 17.08.2023).

Prozessschritt C2
hier
hier
KIDD Präambel
Prozessschritt C2
Link
Link
Abschnitt B
Prozessschritt B3
Prozessschritt C2: spezifische Anforderungsklärung
Prozessschritt C3
hier
hier
Fairness