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
  • Bewertungstool für das PdV
  • Verständlich
  • Transparent
  • Zieldienlich
  • Fair
Edit on GitHub
  1. Anhänge
  2. Tools und Handreichungen
  3. Abschnitt D: Test & Inbetriebnahme

D3: Bewertung der Software durch das PdV

PreviousD1: Ausführung der TestfälleNextD8: Monitoring/Betriebsüberwachung

Last updated 1 year ago

Bewertungstool für das PdV

Nachdem das PdV im Rahmen des KIDD-Prozess-Schritts D2 in Kenntnis gesetzt wurde, ob und wie die PdV-Anforderungen in der Adaption bzw. Entwicklung der Software umgesetzt wurden bzw. wie der aktuelle Stand der Software ist, bewertet das PdV im Schritt D3 die Softwareanwendung in Bezug auf die Aspekte Transparenz, Verständlichkeit, Zieldienlichkeit und Fairness. Um sicherzustellen, dass das PdV die Software möglichst einfach, webbasiert und wenn nötig asynchron bewerten kann, wurde als Prototyp ein webbasiertes Bewertungstool mit dem Titel „Stellschrauben-Matrix“ entwickelt. Dieser Vorschlag dient als Orientierungshilfe und lässt sich auch durch individuelle Lösungen ersetzten.

Zu erreichen ist dieser Prototyp unter der Adresse:

Zusätzlich gibt es unter der Stellschrauben-Matrix die Möglichkeit, allgemeine offene Fragen zu formulieren sowie Anregungen zu den Qualitätskriterien/Stellschrauben abzusenden. Die ganze Bewertung kann anonym oder optional auch namentlich stattfinden.

Verständlich

Transparent

Transparenz liegt vor, wenn die Bestandteile, Vor- und Nachteile, sowie die kritischen Punkte des AES/KI-Systems offen dargelegt sind. Nachdem die Bestandteile der Software, die Stellschrauben und eventuell nicht vorhandene Stellschrauben des Systems verständlich gemacht wurden, geht es in dieser Kategorie darum, wie transparent das System ist. Fehlen in manchen Kategorien die richtigen Stellschrauben bzw. gibt es Limitationen, muss hier diskutiert werden, ob dies die Transparenz beeinflusst und wenn ja wie sehr. Wurde sich z.B. bei der Algorithmenauswahl für ein „Black-Box“-Model entschieden, muss hier bewertet werden, inwiefern die Methoden zur Interpretierbarkeit, die für solche Modelle zur Verfügung stehen, hinsichtlich deren Funktionsweise ausreichend Transparenz gewährleisten.

Zieldienlich

Zieldienlichkeit erfasst, ob die jeweilige Stellschraube und deren Einstellung bzw. Einstellungsmöglichkeiten angemessen und ausreichend in Bezug auf das Ziel des einzuführenden AES/KI-Systems sind. Ausreichend beschreibt hier die Vollständigkeit, die vorliegen muss, um das gesetzte Ziel des Systems umsetzen zu können.

Beispiel: Es kann vorkommen, dass ein regelbasierter Algorithmus keine zufriedenstellenden Resultate liefert, sondern ein ML-Algorithmus verwendet werden muss. Dieser ist möglicherweise weniger transparent, bietet aber dafür die notwendige Performance. Ein Beispiel für fehlende Angemessenheit wäre hingegen der falsche Umgang mit Datenquellen. Werden unnötig viele Daten, vielleicht sogar personenbezogene Daten extrahiert, ohne dass sie signifikante Performanceverbesserungen des Systems mit sich bringen, kann die Verwendungsart der Datenquelle im Rahmen des Systems nicht mehr als zieldienlich angesehen werden.

Fair

Ziel des Bewertungstools ist es, dass jede Stellschraube mit den Unterpunkten aus dem jeweils aktuellen (Ziele, Daten, Regeln, Architektur) sichtbar ist und bei einem MouseOver eine kurze Erläuterung der einzelnen Unterpunkten eingeblendet wird. Die Aspekte Transparenz, Verständlichkeit, Zieldienlichkeit und Fairness, Steuerbarkeit werden dann auf die Stellschraubenkategorien abgebildet, sodass jede Stellschraube mit ihnen bewertet werden kann. Diese fünf Aspekte sind wiederum verschiedenen übergeordneten Qualitätskriterien zugeordnet. Als Bewertungsmöglichkeit gibt es einen Kreis als Steuer- und Anzeigeelement, der in 25%-Schritten ausgefüllt werden kann, um die passende Bewertung zu geben. Darüber hinaus gibt es ein Kommentarfeld pro Matrixfeld, in dem jede einzelne Bewertung der Stellschraube für ein Qualitätskriterium zusätzlich kommentiert oder Fragen hinterlassen werden können.

Qualitätskriterien: ,

Verständlichkeit ist maßgeblich für die darauf folgenden Kriterien der Transparenz und Fairness. Das muss das AES/KI-System, mögliche übergeordnete Stellschrauben und beim einzuführenden System vorhandene Stellschrauben auf eine allgemeine Weise verstanden haben. Es ist hierbei kein vollständiges technisches Wissen nötig, um im Anschluss Fairness, Zieldienlichkeit und Transparenz zu bewerten. Zusätzliche Unterstützung in technischer Hinsicht kann ein:e bieten, der/die kritischen Punkte, die bis dato unter den Tisch gefallen sind, gezielt anspricht und so ein ganzheitliches Verständnis des Systems garantiert. Auch weitere Spezialist:innen wie DSGVO-Beauftragte können diesen Prozess unterstützen.

Qualitätskriterien:

Qualitätskriterien:

Qualitätskriterien: , ,

Der Begriff (algorithmische) beschreibt die Idee, dass sich algorithmische Systeme fair verhalten oder Menschen fair behandeln sollten, d. h. ohne Diskriminierung aufgrund von sensiblen Merkmalen wie Alter, Geschlecht, Behinderung, ethnischer Herkunft, Religion, Weltanschauung oder sexueller Orientierung (Definition angelehnt an [1, S. 16]). Fairness in diesem Sinne umfasst also, inwieweit das AES/KI-System dieser Idee Rechnung trägt oder ihr entgegensteht. Gibt es Biases und wenn ja auf welchen Ebenen? Von welcher Art und von welcher Schwere sind sie? Diese Art von Fragen müssen hinsichtlich der Stellschrauben in den Kategorien Daten, Regeln und Architektur erörtert und beurteilt werden.

[1] Weerts, Hilde J. P. (2021): An Introduction to Algorithmic Fairness. (, 10.07.2023)

Transparenzkatalog
Link
qperior.hypsi.de/dev/kidd
QP 2
PdV
KIX
QE 3
QRE 2
QRE 3
QRE 1
QRE 2
QRE 3
Screenshot des Berwertungstoolprototyps
Fairness