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
  • Formulierung von KIDD-KPIs im KIDD-Prozess
  • Begriffsdefinitionen
  • Formulierung von KIDD-KPIs (ex post)
  • Ticket-System mit Backlog
  • Literatur
Edit on GitHub
  1. Anhänge
  2. Tools und Handreichungen
  3. Abschnitt C: Adaption/Entwicklung

C2: Spezifische PdV-Anforderungsklärung

PreviousC1: Vorstellung der Software für das PdVNextC3: Testfall Definition

Last updated 1 year ago

Formulierung von KIDD-KPIs im KIDD-Prozess

Einordnung in den KIDD-Prozess Vor der Formulierung von KIDD-KPIs steht die Formulierung konkreter KIDD-Ziele bezüglich Diversität im .

Im (Adaption/Entwicklung) beginnt das PdV einen Aushandlungsprozess mit den Softwareentwicklern über ethische und diskriminierungssensible Gestaltungsoptionen der Software und formuliert konkrete, softwarebezogene Empfehlungen (). Dabei wird auch die Formulierung von KIDD-KPIs vorgenommen, die als Fairness-Kennzahlen dienen.

Anschließend erfolgt in die Definition von Testfällen, um die PdV-Anforderungen/Ziele sowie die formulierten KPIs und die am System vorgenommenen Anpassungen zu überprüfen.

Begriffsdefinitionen

KPI (Key Performance Indicator): Eine Leistungskennzahl, mit der der Fortschritt oder Erfüllungsgrad bezüglich einer Zielsetzung gemessen werden kann. Die Messung erfolgt im Betrieb, ex post.

Testfälle: Überprüfung der gewünschten Funktionsweise eines Systems in einem spezifischen Anwendungsfall. Ein Testfall definiert Inputs ins System, die erwartete Funktionsweise und die erwarteten Outputs des Systems. Während der Testphase wird die tatsächliche Funktionsweise mit der erwarteten verglichen.

Beispiel: „Wenn im Lebenslauf nur der Geburtsort geändert wird, sollte dies keinen Einfluss auf die Platzierung in einer Shortlist für eine Stelle haben.“

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

Formulierung von KIDD-KPIs (ex post)

Neben der Möglichkeit, die Fairness des AES bezüglich Diversität anhand konkreter KIDD-Ziele zu überprüfen, besteht die Option, relevante Daten im Betrieb zu erheben, in KPIs darzustellen und mit einem definierten Fairness-Zielkorridor zu vergleichen.

Die Fairness-Kennzahlen gehen nicht von Anfang an in die Zielvorgaben des AES ein. Sie werden im Nachhinein (ex post) erhoben und mit einem Zielkorridor verglichen. Bewegt sich ein KPI außerhalb dieses Korridors, müssen Maßnahmen diskutiert und ergriffen werden.

Das AES erhält eine Reihe von Zielvorgaben.

Beispiel:

„Eine Person sollte eher auf der Shortlist erscheinen, wenn sie mehr Erfahrung mit den geforderten Skills hat.“ oder „Eine Person sollte eher auf der Shortlist erscheinen, wenn sie bereits Erfahrung in der Branche hat.“

Zusätzlich werden KIDD-Ergebnis-KPIs definiert, die im Betrieb überwacht werden sollen. Beispiele hierfür sind:

  • „Anteil der Personen aus Gruppe Y auf der Shortlist“

  • „Anteil der Personen aus Gruppe Y auf der Shortlist im Verhältnis zum Anteil der Personen aus Gruppe Y unter den Bewerbern für diese Stelle“

  • „Anteil der Personen aus Gruppe Y auf der Shortlist im Verhältnis zum Anteil der Personen aus Gruppe Y in der Gesamtbevölkerung.“

Für jede KIDD-KPI wird zudem ein Zielkorridor definiert, beispielsweise: „Der Wert darf nicht mehr als 10 % nach oben oder nach unten abweichen.“

Sollte eine KPI im Betrieb einen Messwert außerhalb des Zielkorridors zeigen, wird eine Warnmeldung ausgegeben. Ein Beispiel hierfür wäre: „Der Anteil der Personen aus Gruppe Y auf der Shortlist ist zu niedrig.“

In einem solchen Fall werden von den zuständigen Stellen die Gründe analysiert und Maßnahmen ergriffen, um dies zu ändern. Beispielsweise:

  • Es gibt nicht genügend Bewerber aus Gruppe Y → Es sind bessere Werbemaßnahmen erforderlich.

  • Es gibt nicht genügend Bewerber mit Qualifikation Z in Gruppe Y → Es sollte diskutiert werden, ob Qualifikation Z tatsächlich für die Aufgabe erforderlich ist. Falls ja, könnten Schulungsmaßnahmen für Gruppe Y eingeführt werden. Falls nein, könnte die Bewertung von Qualifikation Z im AES herabgesetzt werden.

Es gibt zwei Ansätze, um Fairness-Kennzahlen im AES abzubilden, beide haben ihre Vor- und Nachteile:

Wenn Fairness-Kennzahlen als feste Zielvariablen verwendet werden, die die Funktionsweise des AES bestimmen, führen sie direkt zum festgelegten Ziel. Nachteil dabei ist, dass sich die Ergebnisse im Vergleich zu anderen Zielvariablen tendenziell verschlechtern.

Der zweite Ansatz verwendet Fairness-Kennzahlen als im Betrieb überwachte KPIs. Ihre Wirkung tritt indirekt ein und erfordert organisatorische Maßnahmen, die zuerst analysiert und dann umgesetzt werden müssen. Vorteil ist, dass er die Möglichkeit bietet, durch diese Maßnahmen und die Feinjustierung der Zielvariablen des AES eine qualitativ hochwertigere Gesamtlösung für das Unternehmen zu entwickeln.

Ticket-System mit Backlog

Die spezifischen Anforderungen werden in der Regel in einem Ticket-System als Features erfasst, um die Priorisierung und den Fortschritt der Umsetzung nachverfolgen zu können. Häufig werden Vorlagen für Features vorgegeben, die mehrere Felder beinhalten. Beispielhaft sind folgende Felder angegeben:

Feature Nummer:

(Eindeutige Nummer des Features)

Feature Name:

(Prägnanter Name des Features)

Problembeschreibung:

(welches Problem soll gelöst werden)

Hypothese:

(was wird sich ändern, wenn das Feature da ist)

Beschreibung des Features:

(Allgemeine Beschreibung des Features, evtl. mit Zeichnung von einzelnen Prozess-Schritten oder als konkrete UserStory: „Als ... möchte ich ..., damit ...“)

Abhängigkeiten und Risiken:

(Zu welchen anderen Features gibt es Abhängigkeiten und welche? Welche Risiken gibt es bei der Umsetzung dieses Features?)

Akzeptanzkriterien:

(welche Eigenschaften müssen erfüllt sein, damit dieses Feature abgenommen werden kann.)

Literatur

[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 B3
Abschnitt C
Schritt C2: spezifische Anforderungsklärung
C3
Link
Link