Wenn Software gebaut, betrieben und verwendet wird, stellt sich die Frage, wer für potenzielle negative Folgen verantwortlich ist. Hier geht es nicht so sehr um Haftung: Uns geht es darum, vorab das Richtige zu tun, das Richtige in einem ethischen Sinn. Dieser Text ist Teil eines Vortrags bei der Bayerischen Vertretung in Brüssel am 24. März 2021.
Prof. Dr. Alexander Pretschner
Vorsitzender im bidt-Direktorium und Mitglied im Geschäftsleitenden Ausschuss | Professor für Software & Systems Engineering, Technische Universität München & Vorsitzender des wissenschaftlichen Direktoriums, fortiss
Eine offensichtliche Frage ist, wer Entscheidungen fällt und dementsprechend verantwortlich ist. Die Gesellschaft kann sich dafür entscheiden, Technologie zur Gesichtserkennung zu verwenden. Eine Organisation kann sich für einen bestimmten technologiegestützten Bewerbungsprozess entscheiden. Eine Firma kann sich entscheiden, Waffen zu bauen – und die Software, die heute gebaut wird, kann als Waffe verwendet werden, natürlich in einem ganz anderen Sinn. Wenn einem Mitarbeiter das nicht liegt, er also die Zielsetzung aus ethischen Gründen nicht unterstützen kann, muss er letztlich die Firma verlassen. Love it or leave it. Ein Entwickler kann sich aber innerhalb bestimmter Rahmenbedingungen entscheiden, wie er eine bestimmte Funktionalität implementiert. Ein Ingenieur für Qualitätssicherung kann sich entscheiden, welche Prüfmaßnahmen er anwendet. Und ein Benutzer des Systems kann sich entscheiden, bestimmte Funktionen des Systems zu verwenden oder nicht zu verwenden. Vielleicht erinnern Sie sich an den zynischen Slogan der National Rifle Association: Guns don’t kill people, people with guns kill people.
Ich will mich hier auf den Entwickler von Software konzentrieren. Das heißt nicht, dass die anderen Akteure nicht ebenfalls verantwortlich wären. Es heißt aber auch nicht, dass sich die Verantwortung dadurch verflüchtigt, dass sie auf zu vielen Schultern ruht. Ich glaube überhaupt nicht, dass es akzeptabel ist, „nur getan zu haben, was mir gesagt wurde“. Mir ist aber klar, dass ein einzelner Entwickler nicht für alles verantwortlich ist, was ein System potentiell anrichtet, an dem er mitgearbeitet hat. Wir müssen im Hinterkopf behalten, dass die geschäftlichen Ziele oder die Mission einer Organisation im Normalfall nicht vom Entwickler definiert werden. Mir geht es hier um die spezifische, individuelle Verantwortung des Ingenieurs. Dabei ist klar, dass entsprechende ethische Erwägungen nicht im luftleeren Raum stattfinden können, sondern immer in der Abwägung mit anderen Zielsetzungen.
Was uns hier interessiert, ist eine spezielle Qualität von Systemen: Qualität in dem Sinn, dass keine unethischen Konsequenzen entstehen. Mir ist selbst nicht ganz klar, wie weitreichende, schwer zu überblickende Konsequenzen hier zu berücksichtigen sind. Als die Software für AirBnB geschrieben wurde, hätte man da berücksichtigen müssen, dass Wohnungen in Innenstädten möglicherweise in zehn Jahren zu großen Teilen von Touristen anstatt von Mietern bewohnt werden? Hätte man vorhersehen müssen, dass Uber so erfolgreich ist, dass mehr Individualverkehr dadurch entsteht, dass die Menschen vom öffentlichen Transport auf Uber-Autos ausweichen? Hätte man vorhersehen müssen, dass Bitcoin irgendwann mehr Strom verbraucht als Argentinien? Ich glaube das nicht. Insbesondere in Deutschland dürfen wir vielleicht manchmal etwas zuversichtlicher sein, dass wir Probleme in der Zukunft schon in den Griff bekommen werden. Umgekehrt aber sollten Ingenieure vielleicht nicht Software schreiben, die Uiguren auf Bildern erkennt. Abschaltsoftware in Dieselmotoren. Oder Software, die die sexuelle Orientierung eines Menschen vermeintlich erkennt. Das hat es alles gegeben.
Ein interessanter und vielleicht überraschender Aspekt der Qualität von Softwareprodukten ist, dass diese Qualität sehr schwer zu bemessen ist. Ob ein solches Produkt immer korrekt funktioniert, können wir eigentlich gar nicht so genau sagen. Das heißt nicht, dass Software immer schlechte Qualität hat – denn das ist ja nicht der Fall. Natürlich ärgern wir uns ab und zu über Softwarefehler. Wenn Sie aber überlegen, wie oft im Vergleich Software dazu geräuschlos und wunschgemäß funktioniert, werden Sie zugeben, dass Fehler die absolute Ausnahme sind. Die Sicherheit von Systemen können wir zwar ebenfalls analysieren und bewerten – aber aus ganz unterschiedlichen Gründen können wir im Normalfall keine Qualitätsgarantien geben. Gleiches gilt übrigens auch für die Antwortgeschwindigkeit eines Systems, für seine Wartbarkeit, usw.
Ein Grund, warum die Qualität eines softwarebasierten Produkts schwierig zu bemessen ist, ist der Folgende: Es gibt dieses Produkt eigentlich nicht. Damit meine ich, dass sich Softwareprodukte heute in der Regel ununterbrochen ändern. Es finden Software-Updates statt, die Fehler beheben und neue Funktionalität hinzufügen. Im Fall von maschinenlernbasierter KI kommt dazu, dass sich die Datengrundlage, auf der gelernt wird, ständig weiterentwickelt: Weil neue, aktuellere Daten gesammelt werden; weil wir besser verstehen, was die relevanten Daten sind; und auch weil sich die Welt, die sie abbildet, weiterentwickelt. Es ergibt heute deswegen wenig Sinn, ein einzelnes fertiges Produkt zertifizieren, insbesondere dann, wenn Maschinenlernen involviert ist.
Ich will darauf hinaus, dass wir die Qualität eines Softwareprodukts nur schwer bemessen können. Deswegen beziehen sich Zertifizierungen für software-intensive Systeme üblicherweise auch auf den Entwicklungsprozess, etwa im Bereich der funktionalen Sicherheit. Ich glaube, das ist auch der richtige Ansatzpunkt für Anforderungen im ethischen Bereich. Es gibt bereits Ansätze, die in diese Richtung gehen, etwa den u.a. bei fortiss entwickelten Entwicklungsstandard VDE-AR-E 2842-61 oder das P7000-Prozessmodell der IEEE, das ethische Aspekte in den Vordergrund stellt. Man kann in der Fortsetzung so auch ganze Organisationen zertifizieren, wenn diese alle ihre Projekte immer auf eine bestimmte für gut befundene Art und Weise organisieren. Sie alle kennen ISO9000.
Ich halte es für außerordentlich wichtig, sich klarzumachen, dass ein Softwareprodukt nie nur alleine für sich existiert. Seine Verwendung ist eingebettet in die Geschäftsprozesse einer Organisation. Es wird möglicherweise von einer anderen Organisation betrieben. Und es wird von ganz unterschiedlichen Menschen genutzt. Software ist immer nur ein Teil soziotechnischer Systeme. So, wie Sicherheits- oder Privatheitsprobleme niemals mit rein technischen Ansätzen gelöst werden können, können ethische Werte nicht allein durch Technik implementiert werden. Dazu sind immer flankierende Maßnahmen notwendig: Entwicklungsmaßnahmen, organisatorische Maßnahmen, Ausbildungsmaßnahmen, Haftungsmaßnahmen, gesetzliche Maßnahmen – und natürlich im Extremfall die Entscheidung, etwas nicht zu tun. Der Einsatzkontext von Software wird während der Entwicklung immer bereits antizipiert. Eine in meinen Augen in gute Vorschläge mündende Übersicht entsprechender Maßnahmen unter dem Stichwort der „operational AI“ findet sich hier.
Eine Alternative zur Zertifizierung von Produkten wäre hypothetisch, Softwareingenieure zu zertifizieren, so wie es approbierte Ärzte gibt, die eine entsprechende Ausbildung absolviert haben und sich fortbilden müssen. Christopher Wylie, wohl einer der entscheidenden Programmierer im Cambridge Analytica-Skandal, hat so etwas vorgeschlagen. Ich habe keine aktuellen Zahlen gefunden, aber aus meinem Umfeld würde ich davon ausgehen, dass weniger als 30% der Programmierer, die ich kenne, ausgebildete Informatiker sind. Angesichts der Tatsache, dass es ohnehin zu wenige Software-Ingenieure gibt, ist dieser Vorschlag allein deswegen vielleicht doch noch einmal zu überdenken.
Im Bereich der Informationssicherheit gibt es entsprechende individuelle Zertifizierungen, die in meinen Augen insbesondere den Geldbeuteln der Zertifizierungsorganisationen zuträglich sind. Insgesamt denke ich, dass Zertifizierungen von einzelnen Projekten oder möglicherweise ganzen Organisationen die bessere Variante sind als die Zertifizierung von Ingenieuren. Vielleicht muss man aber auch gar nicht immer „zertifizieren“. Im Fall der Luftfahrt beispielsweise wird zertifiziert. Man kann sich auch darauf einigen, dass ein Hersteller im Schadensfall nachweisen muss, dass er gemäß den Vorgaben eines Standards entwickelt hat, der die aktuell besten akzeptierten Entwicklungsschritte definiert. Wenn der Hersteller das nicht kann, haftet er. So macht das etwa die Automobilindustrie mit dem relevanten Standard zur funktionalen Sicherheit. Dieser Standard kommt übrigens aus der Automobilindustrie selbst und nicht von außen und ist insgesamt ziemlich erfolgreich.
Mein Kenntnisstand ist, dass der EU für besonders kritische KI-Anwendungen eine Art externer Zertifizierung vorschwebt und für weniger kritische Anwendungen eine Art Selbstbewertung. Vielleicht ist das eine gute Idee, wenn man die Grenze zwischen „kritisch“ und „nicht kritisch“ definieren kann. Festzuhalten ist aber, dass sich aus den genannten Gründen die erzwungene oder freiwillige „Zertifizierung“ auf den – nicht unbedingt endenden – Entwicklungsprozess und ggf. flankierende nichttechnische Maßnahmen beziehen muss und nicht auf das Produkt!
Es gibt verschiedene Arten, wie man den Entwicklungsprozess für Software organisiert. Eine Idee sind sogenannte agile Prozesse – wie etwa Scrum, das haben Sie vielleicht schon einmal gehört. Tatsächlich ist Agilität viel mehr als ein Entwicklungsprozess für Software: Es ist eine Kultur. Eine Kultur, in der man sehr intensiv kurzfristig für die nächsten zwei Wochen plant, den sogenannten Sprints. Man plant hier eher nicht langfristig, weil die Erfahrung zeigt, dass sich doch immer alles ändert! Agilität ist eine Kultur, in der man zu jedem Zeitpunkt über ein funktionsfähiges Teilsystem verfügt, mit dem neu erstellte Funktionalitäten sofort integriert und sorgfältig getestet werden. Eine Kultur, in der Mitarbeiter ermächtigt werden, oder wie es so schön heißt: „empowered“, selbst Entscheidungen zu treffen und eigenständig Verantwortung zu übernehmen. Eine Kultur, in der das Lernen aus Fehlern ein zentraler Bestandteil ist.
Für diese Art von Softwareentwicklung haben wir uns am bidt überlegt, wie ethische Überlegungen einfließen können. Die Idee ist die folgende. Es gibt ca. 120 Codizes, die beschreiben, welche Werte bei der Entwicklung softwareintensiver Systeme berücksichtigt werden sollen. Das sind Werte wie Transparenz, Fairness, Nachhaltigkeit usw. Diese Werte sind alle wichtig, aber für den Ingenieur nicht immer hilfreich, weil diese Werte eben sehr abstrakt sind. Wie wollen Sie „Fairness“ in ein Gesichtserkennungssystem einbauen?
Ich glaube nun, dass die Codizes gezwungenermaßen nur abstrakte Werte formulieren können, weil Software extrem heterogen und kontextabhängig ist. Denken Sie an die Software, die in unserer Interaktion jetzt gerade eine Rolle spielt: Zoom; Mikrofon- und Lautsprechersteuerungen; Steuerungssoftware für den Transport von Video- und Audiostreams; die mobilen Telefone auf Ihrem Schreibtisch; ggf. Ihre Hörgeräte oder Herzschrittmacher oder Insulinpumpen. Die unterliegen alle völlig unterschiedlichen ethischen Anforderungen. Deswegen sollten wir ethische Erwägungen in den einzelnen Entwicklungsprozess einbeziehen.
Wir machen das in unserem interdisziplinär erarbeiteten Ansatz mit dem EDAP-Schema, das für Ethical Deliberation in Agile Processes steht, einmal am Anfang, wenn wir ungefähr wissen, was das System tun soll. Dabei denken wir zu Beginn der Entwicklung eines Softwareprodukts über Werte nach und darüber, was für Konsequenzen entstehen, wenn wir uns für bestimmte Implementierungen entscheiden, und ob und wie diese Werte mit anderen Zielen kollidieren. Wir wägen also ab. Diese Werte dienen als Leitlinien. Und dann überlegen wir in jeder Zwei-Wochen-Phase, diesen sogenannten Sprints, immer wieder, ob und wie wir für den aktuellen konkreten Stand des Systems diese Werte implementieren, ggf. durch Anwendung entsprechender Mechanismen. Grob gesagt: Wenn ein wichtiger Wert Transparenz ist, dann kann ausgefeilte Protokollierungstechnologie verwendet werden. Wenn der Wert „Fairness“ ist, kann eine von heute 25 Definitionen ausgewählt werden und die für das Maschinenlernen relevanten Daten entsprechend untersucht werden. Wenn es um Vorgänge geht, die massiv in das Leben von Individuen eingreifen können, möchten wir vielleicht ein Vier-Augen-Prinzip installieren. Und ganz konkret vielleicht: Nehmen wir an, unser Ziel ist ein ein System, das Bewerber automatisch vorsortiert. Dann überlegen wir am Anfang, dass wir u.a. nicht diskriminieren und fair sein wollen. In Sprint 25 soll eine Entwicklerin dann die Anmeldemaske implementieren. Jetzt stellt sich die Frage, wie man das Geschlecht repräsentiert. Mann/Frau? Mann/Frau/Divers? Geht es vielleicht auch ohne Anrede? Alle Lösungen haben Vor- und Nachteile. Die Mechanismen liegen jedenfalls zwischen einem vielleicht unkritischen „ja“ und einem übervorsichtigen „nein“.
Diesen Prozess des Nachdenkens, der sog. Deliberation, und der Identifikation von Werten und Mechanismen zu ihrer Implementierung haben wir sehr sorgfältig strukturiert und heruntergebrochen. Der Grund, warum ich Agilität überhaupt erwähnt habe, ist der folgende: Sie passt perfekt zu dieser Idee von Ethik in der Softwareentwicklung! Kurzfristplanung ermöglicht es, immer wieder über ethische Aspekte nachzudenken. Inkrementelle Entwicklung ermöglicht es, beim Hinzufügen neuer Funktionalität Widersprüche aufzudecken, die behoben werden können. Und Empowerment ist ganz wichtig: In der Agilität arbeiten Entwickler hochkreativ und selbstbestimmt und entwickeln nicht genau das, was man ihnen sagt. Sie bekommen stattdessen ein grobes Problem geliefert, das sie lösen sollen – und innerhalb der ermöglichten Freiheiten können adäquate ethische Mechanismen entwickelt werden.
Dieser Ansatz hat den Vorteil, dass er sowohl für die Zertifizierung von Projekten und Organisationen in kritischen Fällen, als auch für eine informelle Selbstbewertung in weniger kritischen Fällen funktioniert: Dazu müssen einfach nur die Deliberationsschritte protokolliert werden. Für eine Zertifizierung muss vorab eine Grundlinie für Kriterien und vielleicht Wertestrukturen festgelegt werden. Ein weiterer Vorteil dieses Ansatzes ist, dass er sowohl für Software im Allgemeinen, als auch für KI funktioniert: Denn die zentrale Herausforderung ist in meinen Augen nicht KI und Ethik, sondern Software und Ethik! Für diesen Ansatz spricht, dass er leichtgewichtig ist. Ich – und übrigens viele andere auch – sind nicht sicher, ob verpflichtende Ethikvorlesungen für Ingenieure ausreichen, um die Welt wirklich besser zu machen. In unserem Ansatz lebt man Ethik konkret und lernt sie nicht abstrakt. (Damit wende ich mich natürlich nicht gegen Ethikvorlesungen und Seminare für Software-Ingenieure, an denen ich auch selbst zusammen mit Philosophen gelegentlich mitwirke.) Schön finde ich schließlich, dass unser Ansatz die Innovationsfähigkeit nicht übermäßig einschränkt. Würden wir vorher festlegen, was genau aus ethischen Gründen getan werden muss oder nicht getan werden darf, dann würden wir immer stärkere Rahmenbedingungen definieren, die der Ingenieur schnell als Korsett empfinden wird und die der Innovationskraft abträglich sind. Mir gefällt der Ansatz, weil er Ethik als Value Proposition definiert und nicht als ein Katalog von Verboten: Wir können im Einzelfall entscheiden, welche Werte wir implementieren möchten und so unsere Europäische Identität implementieren. Und, so schließt sich der Bogen zum Anfang, gibt er dem Ingenieur genau die Verantwortung, die er in einer ganzen Verantwortungskette wahrnehmen kann und muss.
Am Anfang habe ich darüber gesprochen, dass die Entscheidungen natürlich im Rahmen dessen gefällt werden, was in der jeweiligen Organisation und Gesellschaft entschieden wurde bzw. Konsens ist. Ob und welche Form von automatischer Gesichtserkennung wir zulassen, ist zunächst eine gesellschaftliche Fragestellung! (Interessanterweise wird auf die ethischen Aspekte der Gesichtserkennung international heute noch mehr Wert gelegt als auf die Erkennung und Synthese von Sprache und Text.) Falls so ein Konsens noch nicht besteht, gelten wahrscheinlich die Maßgaben einer Organisation und die der einzelnen Entwicklungsteams – aber diese Maßgaben werden wahrscheinlich häufig nicht explizit formuliert sein. IT-Ingenieure können hier in Abwägung aller relevanten Faktoren das Richtige tun. Sie sind ihrem Arbeitgeber gegenüber in einer durchaus machtvollen Position, weil sie angesichts des Fachkräftemangels in unserer Branche nicht beliebig erpressbar sind. Und umgekehrt verpflichtet diese Macht zur Übernahme von Verantwortung und zur Wahrnehmung dessen, was als Accountability erstaunlicherweise keine deutsche Übersetzung besitzt.
Wenn wir staatliche Regulierung für notwendig erachten, sollten wir die Kraft der Selbstregulierung nicht unterschätzen, wenn sie diese Accountability erzwingt. Und wir sollten sicherlich auch in Europa versuchen, die Software und KI beschränkenden Gesetze mit sie fördernden Gesetzen zu komplementieren – eine Überlegung, die sich unmittelbar aus der Lektüre einer Übersicht US-amerikanischer Gesetzesvorhaben zum Thema ergibt.
Die vom bidt veröffentlichten Gastbeiträge geben die Ansichten der Autorinnen und Autoren wieder; sie spiegeln nicht die Haltung des Instituts als Ganzes wider.