Was ist der KIDD-Prozess?
Einführung
Last updated
Einführung
Last updated
Der KIDD-Prozess zielt darauf ab, Unternehmen und ihre Beschäftigen zu befähigen, die Ausgestaltung und Einführung von KI-Anwendungen und AES partizipativ mitzugestalten und dabei sicherzustellen, dass neu eingeführte Systeme gemeinsam ausgehandelter ethischer Anforderungen entsprechen. Der KIDD-Prozess beruht dabei auf der Annahme, dass die Entwicklung von Softwareanwendungen, die weitreichende Implikationen für Unternehmen und Beschäftige haben, nicht alleine in der Hand von Entwickler:innen oder unternehmensinternen Entscheidungsträger:innen liegen sollen, sondern die Nutzer:innen und Betroffenen selbst bei der Ausgestaltung des digitalen Systems umfänglich einzubinden sind.
Diese Einbindung wird im KIDD-Prozess durch die Einrichtung und Arbeit eines Gremiums ermöglicht, das im Projekt als konzipiert wurde. Das PdV ist ein primär innerbetriebliches Gremium, das in seiner Zusammensetzung ein möglichst breites Spektrum an Perspektiven unterschiedlicher Akteur:innen abbildet und frühzeitig und kontinuierlich im Softwareentwicklungs- bzw. Einführungsprozess beteiligt wird. Wie im deutlich wird, sind die zentralen KIDD-Prozessschritte, die das PdV durchführt oder begleitet, als Teilschritte eines klassischen Softwareentwicklungs- bzw. Softwareeinführungsprozesses mit den Phasen der Vision, Anforderungsklärung, Adaption bzw. Entwicklung, dem Test und der Inbetriebnahme der Software zu verstehen.
Zu einem frühen Zeitpunkt im Prozess der Softwareentwicklung bzw. -anschaffung wird das PdV hinsichtlich der rechtlichen, ethischen und diversitätsbezogenen Aspekte, die bei der Softwareeinführung relevant sein können, geschult und sensibilisiert (). Anschließend unternimmt das PdV eine , in der die Mitglieder des Gremiums auf Basis von persönlichen und technisch-organisationalen Erfahrungen und Werten „Hoffnungen und Befürchtungen“ bezüglich der Einführung der Softwareanwendung formulieren. Dabei werden sowohl Chancen und Risiken bei der Einführung der Anwendung für die Organisation als Ganzes als auch für die Betroffenen erhoben und diskutiert. Durch die diverse Zusammensetzung des Gremiums soll sichergestellt werden, dass eine möglichst große Bandbreite an Verzerrungen und Diskriminierungspotenzialen in der Anwendung bereits im Vorfeld der Entwicklung und Einführung identifiziert und minimiert werden.
Aufbauend auf den Ergebnissen aus der Folgenabschätzung formuliert das PdV anschließend erste allgemeine Anforderungen, wie die Software ausgestaltet sein soll und welche organisationalen und strategischen Aspekte bei der Einführung der Anwendung berücksichtigt werden müssen („“). Im Rahmen des Adaptions- bzw. Entwicklungsprozesses der Anwendung tritt das PdV in einem nächsten Schritt in einen iterativen Aushandlungsprozess mit den Softwareentwickelnden hinsichtlich der ethischen und diskriminierungssensiblen Gestaltungsoptionen („Stellschrauben“) der Software und formuliert konkrete softwarebezogene Empfehlungen („“). Grundlage dafür ist die transparente und verständliche Darstellung dieser Gestaltungsoptionen durch die Softwareexpert:innen in einem detaillierten Transparenzkatalog, in dem zentrale Fragen zu den in der KI-Anwendung genutzten (Trainings-)Daten, ihren Regeln und ihrer Softwarearchitektur beantwortet werden. Darüber hinaus entwickelt das PdV und Bewertungskriterien zur Prüfung der Umsetzung der Anpassungswünsche.
Schließlich werden vor Inbetriebnahme der Anwendung gemeinsam mit dem PdV abgestimmt, auf welche Weise die kontinuierliche Einhaltung der ethischen und diskriminierungssensiblen Anforderungen sichergestellt werden kann und die dafür nötigen Monitoringmaßnahmen definiert („“).
Unterstützt wird das PdV im gesamten Prozess durch eine geschulte , die den Aushandlungsprozess zwischen dem PdV und den Software-Entwickelnden moderiert und operativ durchführt. Darüber hinaus kann der Einbezug einer sinnvoll sein, die technisch komplexe Sachverhalte für das PdV allgemeinverständlich darstellt, bei der Formulierung softwarebezogener Empfehlungen und der Entwicklung von Testfällen unterstützt, aber auch kritische Nachfragen hinsichtlich der Daten, Regeln und Architektur der Software stellen kann.