Matzner Informatikethik

3. Auflage 2020
ISBN: 978-3-7504-4938-1
Verlag: BoD - Books on Demand
Format: EPUB
Kopierschutz: 6 - ePub Watermark

E-Book, Deutsch, 386 Seiten

Informatikprodukte machen unser Leben angenehmer, können uns aber auch schaden. Was können Auftraggeber, Entwickler und Nutzer solcher Produkte tun, um die angenehmen Seiten auszuschöpfen und Schäden zu vermeiden? Wie schützen wir uns vor "fake news" aus unbekannten Quellen im Netz? Welche Regeln sollen für staatliche Überwachungsmaßnahmen gelten? Informatiksysteme bewerten unsere Kreditwürdigkeit, Berufsleistung und vieles andere. Wer ist dafür verantwortlich, dass dies seriös geschieht, und was müssen alle Beteiligten tun, um ihrer Verantwortung gerecht zu werden? Welche Rolle spielt die Künstliche Intelligenz? Wie sicher muss ein autonomes Fahrzeug gemacht werden? Diese und viele anderen Fragen werden in diesem Buch behandelt, anhand von praktischen Fallstudien, aber auch auf dem Fundament der wissenschaftlichen Ethik. Es liefert keine Patentlösungen, führt seine Leser aber zu einer Denkweise, mit der sie ethische Fragen rund um die Informatik selbständig behandeln können und von tendenziöser Berichterstattung unabhängig werden. Das Buch wendet sich an alle, die Informatiksysteme beauftragen, bauen oder nutzen. Es setzt weder Vorkenntnisse in Informatik noch in Ethik voraus, sondern entwickelt die nötigen Grundlagen im Text selbst. Die vorgestellten Fallstudien eignen sich auch für den Unterricht an Schulen und Hochschulen.

Thomas Matzner ist Diplom-Informatiker und seit 1992 selbständig. Sein Hauptarbeitsgebiet ist die Konzeption von Informationssystemen. Er arbeitet in der Rolle des Requirements Engineers, Product Owners, Business Process Managers und Business Analysts. Er unterrichtet Informatikethik im Rahmen eines von ihm aufgebauten Wahlpflichtfachs an der Technischen Hochschule Nürnberg Georg Simon Ohm.

Autoren/Hrsg.

Matzner, Thomas

Leseproben

2 Folgewirkungen mangelnder Sorgfalt
Moralisch einwandfreies Handeln versucht Nutzen zu stiften und Schäden zu vermeiden. In manchen Fällen, so haben wir bei den einführenden Beispielen schon gesehen, ist das nicht in Vollkommenheit zu erreichen. Es bedeutet jedenfalls, dass die Suche nach einer Moral überall dort stattfinden muss, wo Schäden angerichtet werden können. Das öffentliche Interesse an Informatikethik – wenn dieses Wort auch selten auftaucht – speist sich aus Ereignissen, die Schäden anrichten oder zumindest ermöglichen. Dazu zählen vor allem diverse Formen des Datenmissbrauchs sowie kriminelles Handeln, etwa Diebstahl und Betrug. Doch auch beim bestimmungsgemäßen Gebrauch von Informatiksystemen können vermeidbare Schäden auftreten. Auch sie sind Gegenstand der Moral. Wer aus Nachlässigkeit Seifenwasser auf die Straße wegschüttet, woraufhin jemand ausrutscht und sich die Knochen bricht, hat moralisch verwerflich gehandelt, auch wenn er bei seinem Handeln keine kriminellen Hintergedanken, sondern eher zu wenig Gedanken hatte. Informatiksysteme sind allgegenwärtig. Jedes von ihnen soll irgend einen Nutzen stiften, sonst würde man sich nicht die Mühe machen, es zu bauen und zu betreiben. Wenn der Nutzen ausfällt oder durch einen Schaden kompensiert wird, ist dies ein moralisches Problem. Da längst nicht alle Systeme anfällig für Datenmissbrauch oder kriminelle Handlungen sind, alle jedoch potentiell anfällig für Nachlässigkeiten bei ihrer Entwicklung oder ihrem Betrieb, sind die öffentlich diskutierten Gefahren nur die Spitze eines viel größeren Eisbergs moralischer Probleme. Für diese Sorte von Problemen möchte ich in diesem Kapitel den Blick meiner Leser erweitern. Fallstudie 4: Postrückläufer bei einer Bank Die Süddeutsche Zeitung berichtete im August 2014(Kastner 2014) über einen Rechtsanwalt mit Kanzlei in der Münchner Innenstadt und seine Bank, eines der großen Institute. Die Bank schickte ihm einen Brief. Es war Ferienzeit, daher war wohl ein Aushilfspostbote unterwegs, der den Briefkasten des Rechtsanwalts nicht fand. Manche Gebäude in der Innenstadt haben mehrere verwinkelte Zugänge, da kann das passieren. Der Brief ging also mit Vermerk "Empfänger unbekannt" zurück an die Bank. Diese sperrte daraufhin die Konten des Rechtsanwalts. Der brauchte ein paar Tage, um das zu bemerken und reklamierte dann bei der Bank. Und obwohl ein Rechtsanwalt vermutlich besser als der Durchschnittsbürger weiß, wie man seine Wünsche durchsetzt, blieben seine Konten drei Wochen lang gesperrt. So lange konnte er nicht auf sein Geld zugreifen. Wenn auch ein IT-System bei dieser Kontensperrung beteiligt war, ist dies zunächst gar kein Informatik-Problem. Denn die Entscheidung, bei unbekannt verzogenem Mandanten die Konten zu sperren, ist eine Geschäftsregel der Bank, die es auch schon gegeben haben könnte, als die Buchungen noch von Angestellten mit Ärmelschonern in Kladden gemacht wurden. Kein Informatiker wäre befugt, eine solche Funktion auf eigene Initiative ohne Auftrag der zuständigen Fachabteilungen einzubauen. Zum Informatik-Problem wird die Geschäftsregel aber genau dadurch, dass sie jetzt eben automatisch abgearbeitet wird. In der Ärmelschoner-Zeit hätte der Kundenbetreuer beim Rücklauf des unzustellbaren Briefes sich verwundert am Kopf gekratzt: „Komisch, der Herr Dr. Müller war doch letzte Woche noch hier. Der hat nicht gesagt, dass er umzieht. Ich ruf da mal an...“ Heute taucht der Kunde kaum mehr auf, denn das würde nur Kosten verursachen. Stattdessen bedient man ihn mit Informatiksystemen, in vielen Fällen vollautomatisch und ohne menschliche Kontrolle. Wo lag der eigentliche Fehler bei diesem Fall? Wir können darüber streiten, ob man einem unbekannt verzogenen Kunden sofort die Konten sperren darf, soll oder gar muss. Dabei sind viele Werte gegeneinander abzuwägen. Solange er ein Guthaben hat, besteht für die Bank kein Risiko, also könnte sie Abhebungen zulassen. Aber vielleicht missbraucht ja längst ein Dritter das Konto des Kunden? Das sind komplizierte bankfachliche Entscheidungen, über die ich kein Urteil fällen möchte. Aber das eigentliche Problem war, daß der Kunde ja gar nicht verschollen gegangen war. Beim Automatisieren dieser Geschäftsregel wurde ein Fehler gemacht, den viele von uns aus ihrer Schulzeit kennen. Ich erinnere dazu an den Mathematikunterricht in den höheren Klassen. Da war etwa in einer Prüfung eine Gleichung zu lösen. Wir hatten eine Lösung errechnet, etwa 2/3 p, und hinterher durch Umfrage bei den Mitschülern festgestellt, daß andere die gleiche Lösung hatten, unsere also vermutlich richtig war. Und dann kam die Enttäuschung bei der Rückgabe der Arbeit: eine Note Abzug wegen vergessener Fallunterscheidung. Die Variable x kam bei der Rechnung einmal im Nenner eines Bruches vor, weshalb die Rechnung für x = 0 nicht gültig war und dieser Fall separat hätte bearbeitet werden müssen. Das ist mathematisch sicherlich korrekt, aber dennoch ungerecht, hatte unsere Rechnung doch für überabzählbar unendlich viele Werte von x das richtige Ergebnis geliefert, und nur für einen einzigen das falsche – und das ergab einen Abzug einer ganzen Note! Die Mathematiker sind humorlose Gesellen. Eine solche Fallunterscheidung haben die Auftraggeber für die Software bei der Bank vergessen. Nehmen wir an, es sei bankfachlich richtig und sinnvoll, bei unbekannt verzogenem Kunden die Konten zu sperren. Wo ist die Fallunterscheidung? Nun, die Nachricht „Kunde unbekannt verzogen“ kann richtig sein oder eben auch nicht. Ich war bei der betreffenden Bank nie tätig und kann nicht genau wissen, wie dieser Fehler passiert ist. Aber ich sitze häufig in Runden, in denen die Fachbereiche eines Unternehmens ihre Anforderungen an eine IT-Lösung bekanntmachen. Deshalb stelle ich mir die Entstehung des Fehlers etwa folgendermaßen vor: Es ist 15:30 Uhr, einige Mitglieder der Runde scharren schon mit den Füßen, sie kommen von weither und müssen bald zum Flieger. Jetzt steht das Thema Postrückläufer auf der Tagesordnung. Davon ist keiner der Anwesenden begeistert, denn besondere Wertschöpfung ist damit wohl nicht zu erzielen. Ein alter Hase des Bankgeschäfts sagt: „Bei Postrückläufern haben wir bisher immer die Konten gesperrt.“ Jetzt nehmen wir einmal an, es säßen auch ein paar pfiffige Leute im Raum, die wissen, was es bedeutet, eine an sich gute Geschäftsregel zu automatisieren. Einer davon sagt: „Ist das wirklich immer richtig? Wenn ich denke, wie oft mich Postsendungen nicht erreichen, weil die Postboten unter Zeitdruck stehen und Fehler machen ...“ Nun entwickelt sich eine längere interessante Diskussion über die Fälle, in denen Rückläufer eine Kontosperrung auslösen sollten oder eben nicht, und vor allem darüber, wie man den einen Fall vom anderen automatisiert zuverlässig unterscheiden kann. Das ist gar nicht so einfach, vor allem wenn man Kosten sparen und nur begrenzt Personal zur Klärung solcher Fälle einsetzen will. Am eindeutigsten wäre natürlich, einen Angestellten zur Adresse des Kunden zu schicken. Aber die Bank hat ihre Kunden an Geldautomaten, Service-Terminals und Online-Banking gewöhnt, um den personellen Kontakt mit dem Kunden auf das Allernötigste zu reduzieren. Diesen Kostenvorteil will sie wegen lästiger Postrückläufer nicht preisgeben. Unterdessen rückt der Abflug der auswärtigen Beteiligten immer näher, und ich vergaß zu sagen: Die meisten davon haben in der Schule Mathematik gehasst, lieben keine Fallunterscheidungen und deshalb auch keine filigranen Diskussionen über Geschäftsregeln. Nun kommt dem Team HiPPO zur Hilfe. Das bedeutet „Highest Paid Person's Opinion“. Die hierarchisch höchste Person, etwa ein Hauptabteilungsleiter, in der Runde ist inzwischen besonders ungeduldig geworden. Er fragt nun ungehalten: „Das ist mir alles zu kompliziert und dauert außerdem viel zu lange. Gibt es nicht eine einfache Lösung?“ Einer sagt: „Klar, Konto sperren, machen wir ja heute schon so. Wenn's der Kunde merkt, kann er sich ja melden, und dann entscheiden wir situativ, was wir als nächstes machen.“ Und (fast) alle atmen auf und bekommen ihren Flieger. Ich habe dieses Beispiel gewählt, weil es in der Zeitung stand. Nicht immer werden Fehler bei der Automatisierung von Geschäftsabläufen außerhalb des Unternehmens deutlich sichtbar; nicht immer kann der Kunde, wenn er argwöhnt, schlecht behandelt worden zu sein, das belegen. Nicht immer wird der Kunde geschädigt, aber auch eine Schädigung des eigenen Unternehmens ist zu missbilligen. In diesem Fall ist die Sache klar: Der Kunde und, wie wir gleich sehen werden, auch die Bank wurden geschädigt. Das genannte Schema, die Mechanismen, die dafür sorgen, dass Geschäftsregeln nur unzureichend auf Software abgebildet werden, kenne ich aus meiner täglichen Arbeit zur Genüge. Beispiele...