Digital Escrow im Zeitalter von Künstlicher Intelligenz

Künstliche Intelligenz („KI“) als Technologie gewinnt rasant an Bedeutung.¹ Laut Befragung des deutschen Branchenverbandes Bitkom ist KI bereits heute dem größten Teil der deutschen Bevölkerung – nämlich 92 % aller Menschen – ein Begriff.²

Obwohl der Begriff vielen geläufig ist, hinterlässt KI – insbesondere bei Anwenderunternehmen – grundsätzliche Fragen.³ Chancen und Risiken nicht nur beim Betrieb, sondern auch bei der Beschaffung KI-basierter Anwendungen beschäftigen Anwender und politische Entscheidungsträger zugleich. Angesichts dieser Bedeutung veröffentlichte jüngst das Weltwirtschaftsforum Orientierungshilfen für die Beschaffung von KI-Lösungen im privaten Sektor.⁴

Eines der wesentlichen Instrumente beim Risikomanagement im Rahmen der Beschaffung von informationstechnischen Systemen ist die Hinterlegung – bzw. „Escrow“. Gegenstand sind regelmäßig Software und andere digitale Güter.

Dieser Beitrag soll einen Überblick über gängige Escrow-Systeme geben und helfen, Escrow von digitalen Gütern im Zusammenhang mit der Beschaffung von KI-Anwendungen einzuordnen. Daneben werden einige mögliche Implikationen von Escrow aufgezeigt, die beim Umgang mit Beschaffungsrisiken von KI-Anwendungen eine Rolle spielen können. Allerdings wird insbesondere auf eine Besprechung von Vorhaben, etwa durch politische Institutionen, wie Gesetzesinitiativen, insbesondere auf EU-Ebene – so etwa zur KI-Verordnung⁵ oder zu dem kürzlich in Kraft getretenen Daten-Governance-Rechtsakt⁶ – im Umfang dieses Beitrages verzichtet.

Das Konzept von Escrow als spezialisierte technisch-kommerzielle Dienstleistung ist nicht neu; dieses gibt es bereits seit den frühen 1980er Jahren.⁷ Ursprüngliche Intention von Escrow als Konzept war es, im Rahmen der Beschaffung von Software – und später anderer digitaler Güter – Parteien zusammen zu bringen, die aufgrund eines der jeweiligen Transaktion innewohnenden Interessenskonfliktes wohl kaum oder nur unter wirtschaftlich komplexen Voraussetzungen hätten zueinander finden können.⁸

Sinn und Zweck des Escrows liegt damit vordergründig in der Lösung eines Interessenskonfliktes zwischen Technologieanbieter und -anwender: Der Anwender benötigt in bestimmten Fällen Zugriff auf vertrauliche Informationen im Zusammenhang mit der Technologie des Anbieters, etwa den Software Source Code,⁹ um die vom Anbieter bezogene Technologie zu nutzen. Der Anbieter wiederum hat ein berechtigtes wirtschaftliches Interesse daran, seine Technologie geheim zu halten und nicht offenzulegen.

Was dieser Interessenkonflikt im Einzelnen bedeutet, wird nachfolgend aufgezeigt, wobei aufgrund der Vielzahl an möglichen Fallgestaltungen im Rahmen dieses Beitrages nicht auf jede Konstellation eingegangen werden kann.

Um zu gewährleisten, dass der Anwender die vom Anbieter bezogene Technologie ohne wesentliche Unterbrechungen betreiben kann, benötigt der Anwender in gewissen Szenarien Zugriff auf die Kerntechnologie des Anbieters. Durch Verwendung der Technologie des Anbieters kann es zu einer faktischen Abhängigkeit des Anwenders kommen.¹⁰ Dies gilt insbesondere dann, wenn der Anwender die Technologie des Anbieters für eigene geschäftskritische Prozesse einsetzt – so etwa Software, die Prozesse des Anwenders steuert, ohne die der Anwender seinen Betrieb nicht fortführen kann. Ein Beispiel wäre individuell an die Bedürfnisse des Anwenders angepasste Software, die sämtliche Geschäfts- und Betriebsprozesse eines industriellen Großlagers steuert.

Stellt der Anbieter beispielsweise die Wartung und Pflege des Technologieprodukts aus irgendeinem Grund – eventuell sogar noch kurzfristig – ein, so kann der Anwender in eine Zwickmühle geraten. Insbesondere bei komplexen und aufwändigen Systemen lässt sich Software nicht von heute auf morgen austauschen. Eine aufwändige Neuprogrammierung und -implementierung des Systems wäre ohne Gefährdung der Geschäftsprozesse des Anwenders kaum zu bewerkstelligen.¹¹ Als Ausweg müsste sich der Anwender zunächst selbst helfen oder von einem Dritten helfen lassen, um das bei dem Anwender implementierte System zu warten sowie weiterzuentwickeln und damit die Kontinuität des Betriebs sicherzustellen. Insbesondere aus IT-Sicherheitsgründen dürfte dies regelmäßig notwendig sein.

Um in diesem Fall die Kontinuität des Softwaresystems bewerkstelligen zu können, benötigt der Anwender jedoch in der Regel auch Zugriff auf den Source Code der Software des Anbieters, das Produkt Know-how, insbesondere in Form von technischer Dokumentation, auf Konfigurationsdaten sowie die Rechte zur Nutzung der Vorgenannten. Der Anbieter wird diese dem Anwender meistens nicht oder nicht vollständig zur Verfügung gestellt haben. In der Regel wird die Software dem Nutzer nur mit dem sogenannten Object Code, also dem maschinenlesbaren und ausführbaren Teil der Software, ausgeliefert.¹² Werden – je nach System- und Anwendungsmodell, z.B. bei Cloud-basierten Technologieprodukten und -dienstleistungen wie Software as a Service („SaaS“) – für den Betrieb des Systems benötigte Daten des Anwenders beim Anbieter vorgehalten, so wird der Anwender auch sicherstellen wollen, dass er Zugriff auf diese bekommt.

Mit den Hinterlegungsgegenständen soll aus Sicht des Anwenders eine technisch versierte Person in die Lage versetzt werden, das hinterlegte Technologieprodukt in vertretbarem Zeitumfang in ein lauffähiges Programm zurückzuversetzen.¹³ Insgesamt möchte der Anwender seine Investitionen in die eingekaufte Technologie absichern, aber auch langfristig sicherstellen, dass die technologische Infrastruktur stabil bleibt und an wechselnde Anforderungen sowie das Marktumfeld adaptiert werden kann.¹⁴

Demgegenüber steht das berechtigte Interesse des Anbieters, seine proprietäre Technologie insbesondere gegen die Weitergabe an Dritte zu schützen. Besonders der Source Code von nicht quelloffener¹⁵ Software und das dahinterstehende Know-how bilden regelmäßig einen bedeuten Teil der Vermögensgegenstände des Anbieters.¹⁶ Gibt der Anbieter den Source Code an den Anwender heraus, so besteht das Risiko, dass die Software ohne Kontrolle des Anbieters weiterverbreitet und gar von Mitbewerbern des Anbieters in den Markt getragen wird. Dies kann unter Umständen auch Tür und Tor für Nachahmungen öffnen. Dabei sind auch solche Nachahmungen denkbar, bei denen eine Übernahme der inneren Gestaltung einer Software und damit eine etwaige Urheberrechtsverletzung von außen nicht mehr nachvollziehbar wäre.¹⁷

Nachvollziehbarerweise möchte der Anbieter daher sein Know-how bzw. geistiges Eigentum – insbesondere den Source Code von Software – schützen, wenngleich der Anbieter auch bestrebt sein wird, seine Technologie oder Dienste erfolgreich am Markt bei Kunden zu platzieren.¹⁸

Am Markt findet sich eine Reihe verschiedener Anbieter von Escrow-Services für verschiedenartige Hinterlegungsgegenstände. Es finden sich auch in der juristischen Literatur teils Typisierungen von Escrow-Arten für digitale Güter,¹⁹ etwa mit Blick auf klassisches Source Code Escrow, Cloud Escrow, IP oder Data Escrow. Bei dem Versuch der Typisierung wird es regelmäßig Schnittmengen geben. Daher kommt es nach hiesiger Auffassung weniger auf die kommerzielle Bezeichnung des Escrow-Services als auf die Besonderheiten der Hinterlegungsgegenstände an. Im Nachfolgenden wird daher ohne Anspruch auf Vollständigkeit auf typische sowie mögliche Hinterlegungsgegenstände in der gebotenen Kürze eingegangen.

Hinterlegungsgegenstand des klassischen Software Escrows bezieht sich primär auf klassische on-premise Software (sowie auch Embedded Software),²⁰ d.h. auf nicht in einer Cloud-Infrastruktur betriebene Software. Zum Hinterlegungsgegenstand gehört insbesondere der Software Source Code. Daneben beinhalten sogenannte Hinterlegungs- bzw. Escrow-Pakete weitere Hinterlegungsgegenstände, wie geistiges Eigentum, insbesondere in Form von Begleitmaterialien, die nicht immer direkt in der Software selbst verkörpert sind. Beispiele sind: Dokumentationsmaterial, sonstige technische Daten und Anleitungen, daneben aber auch kryptografische Schlüssel, Passwörter, allgemeine Zugangsdaten und manchmal Hash-Werte (diese manchmal auch Key Escrow bezeichnet).²¹ Vorstehende können allesamt Geschäftsgeheimnisse und Know-how des Anbieters darstellen.

Primärer Hinterlegungsgegenstand sind neben den Hinterlegungsgegenständen des klassischen Software Escrows auch sämtliche weiteren Komponenten, die für den Cloud-Service notwendig sind und regelmäßig vom Cloud-Anbieter kontrolliert werden.²² Diese können auch Software von Dritten beinhalten, die für die Sicherstellung der Lauffähigkeit des Cloud-Systems benötigt werden.²³ Hinterlegte Komponenten können beispielsweise auch etwaige Laufzeit- und Entwicklungsumgebungen beinhalten.²⁴ Als besonders wichtiges Element kommt beim Cloud Escrow ergänzend auch die Hinterlegung des individuellen Datenbestandes des Anwenders in der Cloud-Umgebung in Betracht.²⁵ Insoweit kann sich Escrow bei der Hinterlegung einer Cloud-Umgebung als technisch komplex sowie aufwändig gestalten,²⁶ was selbstverständlich auch kaufmännisch zu berücksichtigen ist.

Auch wenn Daten bereits als Gegensand der oben genannten Escrow-Varianten genannt wurden, sollen diese aufgrund der Bedeutung von Daten für die nachfolgenden Ausführungen besondere Erwähnung finden. Beim Hinterlegungsgegenstand Daten kann es sich um große Datenmengen wie Input- und Output-Daten oder Daten als Basis für statistische Auswertungen handeln; diese können strukturierte oder unstrukturierte Daten sein.²⁷ Dies schließt Daten im IoT/IioT-Umfeld, maschinengenerierte Daten im Umfeld von M2M-Kommunikation sowie grundsätzlich auch Trainingsdaten oder Daten aus dem Produktivbetrieb von KI-Anwendungen ein.²⁸ Bei den hinterlegten Daten kann es sich grundsätzlich sowohl um Daten mit als auch ohne Personenbezug handeln.

Zentraler Zweck des Escrows liegt in der Lösung des eingangs aufgezeigten Interessenkonfliktes, wozu sich in der Praxis verschiedene Modelle herausgebildet haben.²⁹ Diese reichen vom Modell der Hinterlegung von Escrow-Gegenständen beim Anwender selbst bis hin zur Hinterlegung bei Dritten, wie etwa bei einer professionellen Hinterlegungsstelle (einem sogenannten Escrow-Agenten). Die Darstellung der Implikationen der unterschiedlichen Typen von Hinterlegungsstellen fällt aus dem Rahmen dieses Beitrages, sodass nachfolgend nur auf zwei der nach hiesiger Auffassung relevantesten eingegangen wird.

Grundsätzlich möglich ist die Hinterlegung des Escrow-Paketes beim Anwender selbst. Eine solche Hinterlegung wird jedoch regelmäßig als problematisch angesehen, da sie – so wird vertreten – vertraglichen Regelungen zwischen den Hinterlegungsparteien zum Trotz, ein faktisch höheres Missbrauchsrisiko durch den Anwender mit sich bringt.³⁰ De facto erhält der Anwender in seiner eigenen Sphäre Zugriff auf den Source Code und die Geschäftsgeheimnisse des Anbieters.³¹ Die Parteien versuchen bei diesem Modell regelmäßig das faktische Risiko durch technische Lösungen zu minimieren. Beispielhaft zu nennen wären die Übergabe verschlüsselter Hinterlegungsgegenstände an den Anwender bei gesonderter Hinterlegung eines versiegelten Schlüssels bei einem Dritten (auch Key Escrow genannt).³² Das Risiko kann aber nach hiesiger Auffassung auch auf vertraglicher Ebene adressiert und ein versiegelter Schlüssel direkt beim Anwender hinterlegt werden. In dieser Konstellation kann sich auch die Vereinbarung von empfindlichen Vertragsstrafen³³ für den Fall als effektiv erweisen, dass der Anwender das bei ihm hinterlegte Escrow-Paket entgegen den Vereinbarungen mithilfe des bei ihm gesondert hinterlegten Schlüssels öffnet. Die Vertragsstrafe wäre etwa verwirkt, wenn eine Öffnung des Escrow-Paketes durch den Anwender erfolgt, ohne dass einer der etwa zwischen den Parteien vereinbarten und nachfolgend näher dargestellten Herausgabefälle eintritt.

Weitaus gängiger – wenn auch kostspieliger – scheint in der Praxis die Hinterlegung der Escrow-Gegenstände bei einem Dritten zu sein. Als solche kommen grundsätzlich Notare, Banken oder sonstige vertrauenswürdige Personen in Betracht.³⁴ Häufig sind diese Personen jedoch nur in der Lage, den Hinterlegungsgegenstand entgegenzunehmen und aufzubewahren. Daher bieten professionelle, auf Escrow spezialisierte Dienstleister an die Bedürfnisse der Escrow-Parteien angepasste Escrow-Dienste an. Neben der sicheren Aufbewahrung der Escrow-Gegenstände bieten diese Escrow-Agenten beispielsweise auch an, die hinterlegten Gegenstände technisch auf ihre Integrität hin zu prüfen oder aber auch informationssicherheitstechnische Untersuchungen durchzuführen (z.B. Virenprüfungen). Bei den Integritätstests wird insbesondere geprüft, ob es sich bei dem hinterlegten Source Code um den von den Parteien zu hinterlegenden Source Code handelt, ferner ob sich dieser öffnen und grundsätzlich auch ablaufen lässt.³⁵

Der eingangs aufgezeichnete Interessenkonflikt zwischen Anwender und Anbieter lässt sich durch Escrow lösen, wobei für die Zwecke dieses Beitrages der Fokus auf die Hinterlegung bei einem Escrow-Agenten gelegt werden soll.

Rechtlich umgesetzt wird diese Hinterlegung in der Regel durch den Abschluss eines Dreiparteienvertrages zwischen dem Anbieter, dem Anwender und dem Escrow-Agenten. Hierzu gibt es allerdings auch eine Vielzahl von anderen und unterschiedlichen Gestaltungsmöglichkeiten. Sinn und Zweck des Escrows sowie die Art und Weise, mit welcher die gegenläufigen Interessen in Einklang gebracht werden können, lässt sich am besten anhand der im Escrow-Vertrag zu regelnden Herausgabefälle ablesen. Darauf beschränken sich auch die nachfolgenden Darstellungen. Im Übrigen werden die weiteren Gestaltungsmöglichkeiten von Escrow-Verträgen im Rahmen dieses Beitrages nicht weiter vertieft.

Durch die Hinterlegung bei einem professionellen Escrow-Dienstleister erhält der Anwender die Gewissheit, dass der Zugriff auf den Source Code und auf weitere zur Sicherstellung der Kontinuität des Betriebes der Software notwendigen Komponenten gewährleistet ist, wenn die im Escrow-Vertrag festgeschriebenen Anwendungs- und Herausgabefälle eintreten. Durch die Integritätsprüfung des Escrow-Agenten soll zudem sichergestellt werden können, dass der Anwender die Hinterlegungsgegenstände im Herausgabefall tatsächlich auch nutzen kann.

Der Anbieter hat dagegen die Sicherheit, dass das Escrow-Paket nur im Falle des Eintritts des Herausgabefalles tatsächlich herausgegeben wird. Denn der Escrow-Agent würde sich dem Anbieter gegenüber direkt haftbar machen, wenn er unbefugt die Escrow-Gegenstände an den Anwender herausgeben würde. Durch Beschränkung besonders der urheberrechtlichen Nutzungs- und Verwertungsrechte am Source Code kann der Anbieter zudem sicherstellen, dass sowohl der Source Code als auch das Know-how des Anbieters von dem Anwender nur für die Zwecke des Herausgabefalles verwendet werden.³⁶ Insgesamt werden also der Anbieter und seine Technologie sowie seine Betriebsgeheimnisse geschützt.

Neben den oben dargestellten liegt der zentrale Zweck des Escrows in den folgenden Anwendungsfeldern.³⁷ Diese werden regelmäßig im Rahmen der Ausgestaltung der Herausgabeszenarien im Escrow-Vertrag berücksichtigt:

• Anbieterinsolvenz: Besonders bei den nach deutschem Recht strukturierten Escrow-Vereinbarungen³⁸ wird sich vorwiegend der Anwender durch Escrow auch gegen die Insolvenz des Anbieters absichern wollen. Dabei geht es insbesondere darum, den Anwender gegen eine etwaige Erfüllungsverweigerung durch den Insolvenzverwalter abzusichern, damit der Insolvenzverwalter den Escrow-Vertrag nicht im Wege der Ausübung seines Wahlrechts nach § 103 InsO (welches nach § 119 InsO nicht durch Vereinbarung ausgeschlossen werden kann) beenden kann.³⁹
• Schutz vor sonstiger Einstellung des Geschäftsbetriebes oder Erfüllungsverweigerung des Anbieters bzw. Schutz vor der Einstellung der Produktlinie (End of Life),⁴⁰ womit auch die Einstellung der Pflege, Wartung sowie Weiterentwicklung der Software bzw. Technologie durch den Anbieter einhergeht. Als Anwendungsfall der Erfüllungsverweigerung – sofern im Escrow-Vertrag vereinbart – wäre grundsätzlich in der Praxis auch die Konstellation denkbar, dass dem Anwender die notwendigen Pflege- und Wartungsdienste nicht zu zumutbaren Konditionen angeboten werden können.
• Absicherung für den Fall des Projektabbruchs bei der Erstellung individueller Software.⁴¹ Ferner kann Escrow auch dem Schutz vor Schlechterfüllung bei Mängelbehebung bzw. - beseitigung und Softwarepflege dienen.⁴² Insbesondere soll dadurch der Betrieb des Anwenders bei geschäftskritischen Systemen vor weiterem Schaden, etwa durch den Verzug des Anbieters bei der Leistungserfüllung geschützt werden.⁴³ Zudem kann Escrow auch der Beweissicherung dienen.⁴⁴
• Absicherung der Wahl des Dienstleisters bei der Behebung von Programmierfehlern oder Durchführung erforderlicher Funktionsänderungen oder -erweiterungen.⁴⁵

Der Einsatz von KI bietet zahlreiche Chancen für Anwender. Nutzung von KI-Technologie birgt aber auch ebenso Risiken, die allerdings bereits im Rahmen des Beschaffungsprozesses berücksichtigt werden können. Im Rahmen dieses Beitrages soll nachfolgend der Fokus auf der Darstellung derjenigen ausgewählten Risiken des KI-Einsatzes liegen, die nach hiesiger Auffassung durch die Verwendung von Escrow adressiert werden können.

Risiken beim Einsatz von KI können einerseits rein technisch bedingt sein, wie beispielsweise der nachfolgend dargestellte sogenannte Black-Box-Effekt, andererseits aber auch nichttechnische Folge technischer Risiken sein, wie etwa durch Ergebnisse der KI verursachte Diskriminierungen und der sogenannte Automation Bias. Mit letzterem ist das Phänomen gemeint, bei dem Menschen maschinelle bzw. KI-generierte Entscheidungen entweder weitgehend ungeprüft übernehmen oder sogar bei nach ihrer Auffassung unrichtigen Entscheidungsvorschlägen der KI dennoch Schwierigkeiten haben, sich für davon abweichende Handlungsalternativen zu entscheiden.⁴⁶

Technisch bedingte Risiken können bereits im Rahmen des Beschaffungsprozesses adressiert werden. Solche Risiken werden regelmäßig systemseitige unerwünschte Verhaltensweisen des KI-Systems umfassen, von denen Beispiele nachfolgend dargestellt werden.

Wesentliches technisch bedingtes Risiko von KI-Anwendungen ist die schwere Nachvollziehbarkeit der systemseitigen Entscheidungsprozesse. Es herrscht regelmäßig Intransparenz bezüglich der KI-eigenen Entscheidungsfindung, insbesondere was den Prozess der Ermittlung des Ergebnisses durch die KI betrifft.⁴⁷ Die KI fällt auf Basis der ihr zur Verfügung gestellten Daten Entscheidungen und kann sich technisch als selbstlernender Algorithmus weiterentwickeln.⁴⁸ Das KI-System baut damit seine Kenntnisse einerseits auf Trainingsdaten, andererseits auf weiteren durch die Nutzung des Systems selbst entstehenden Informationen auf. KI-Systeme – beispielsweise in der Form von sogenannten Machine Learning-Systemen – lernen und optimieren sich selbst durch ihre Erfahrungen.⁴⁹ Diese Funktionsweise von KI-Systemen führt dazu, dass das System nur auf Basis der ihm zur Verfügung stehenden Daten selbstständig lernen kann.⁵⁰ Nicht auszuschließen ist das damit entstehende Risiko nicht nachvollziehbarer oder gar unerwünschter Ergebnisse, wie im Nachfolgenden aufgezeigt wird.

Die technischen Datenverarbeitungs- und Entscheidungsvorgänge der KI sind vielfach komplex und intransparent; daraus folgt auch der sogenannte Black-Box-Effekt. Darunter versteht man den komplexen und undurchsichtigen Entscheidungsfindungsprozess einer KI-Anwendung, in den der Mensch keinen Einblick mehr hat.⁵¹ Häufig ist selbst für den Hersteller die transparente Nachvollziehung der involvierten Logik nahezu oder gar gänzlich unmöglich;⁵² einzelne entscheidungsrelevante Prozesse sind nicht mehr erklärbar.⁵³ Erkennbar ist meistens nur das Ergebnis der Entscheidungsfindung der KI, nicht jedoch etwa, welche Daten zur Herbeiführung des Ergebnisses genutzt wurden.

Die dem KI-System zur Verfügung gestellten Daten bilden die Grundlage der Funktion der KI, unabhängig davon, ob diese Trainingsdaten oder Daten im Livebetrieb sind. Bei unzureichenden oder einseitigen und somit voreingenommenen – d.h. mit „bias“ belasteten – Daten kann das KI-System die Generierung voreingenommener und unerwünschter Ergebnisse erlernen.⁵⁴ Die Folge können insbesondere im weiteren Livebetrieb fortgetragene und möglicherweise unerkannte Folgefehler sein, die sich aus den Verarbeitungsvorgängen ergeben können, die auf der KI-Entscheidung basieren.⁵⁵

Die mit „bias“ belasteten Daten erzeugten unerwünschten Ergebnisse können etwa direkt oder indirekt diskriminierende Wirkung haben, die sich etwa beim Einsatz im HR-Bereich (etwa in Recruitment-Systemen) manifestieren können. Solche diskriminierenden Tendenzen können insbesondere von nicht sorgfältig ausgewählten Trainingsdaten hervorgerufen werden, die im Voraus jedoch oft nicht ohne Weiteres erkennbar sind; dies gilt besonders, wenn es um mittelbare Diskriminierungen geht.⁵⁶ Konkret können auf solchen Daten basierende vorherige Entscheidungen als Datengrundlage für das weitere Training der KI genutzt und bereits existierende Diskriminierungen damit perpetuiert bzw. sogar verstärkt werden.⁵⁷

Neben inhaltlich korrekten und möglichst unvoreingenommenen Daten benötigt die KI aber auch große Datenmengen (d.h. Big-Data), um autonome Entscheidungen zu generieren.⁵⁸ Sind ausreichende Datenmengen nicht vorhanden, wird die KI regelmäßig dennoch antworten, d.h. „halluzinieren“ (auch „confabulation“ oder „delusion“ genannt). Mit der Halluzination der KI sind überzeugend formulierte Resultate gemeint, die insbesondere nicht durch Trainingsdaten gerechtfertigt sind und damit objektiv falsch sein können.⁵⁹ Dies ist insbesondere Resultat des systemseitigen Antwort- bzw. Ergebnisgenerierungszwangs von KI-Anwendungen: Diese sind häufig so konstruiert, dass sie stets eine Antwort liefern.⁶⁰ Vielfach weisen KI-Anwendungen allerdings nicht darauf hin, dass die Antwort auf Basis unzureichender (Trainings-)Daten erstellt worden ist. Dies ist heutzutage etwa bei Large Language Model-KI-Systemen wie ChatGPT zu beobachten.

Die oben aufgezeigten Phänomene und Risiken können darüber hinaus durch mögliche Cyberattacken verstärkt werden. Diese könnten die Integrität des KI-Systems beeinflussen, indem Angreifer etwa Kontrolle über das KI-System erlangen oder manipulierte bzw. schädliche Datensätze in das KI-System einpflegen und den KI-Algorithmus damit sozusagen „vergiften“ könnten.⁶¹ Die Folge könnten etwa insbesondere unkorrekte und etwa mit „bias“ belastete Ergebnisse sein, sofern das System noch grundsätzlich funktionsfähig bliebe. Wie aufgezeigt, könnten die von der KI gelieferten möglicherweise inkorrekten Ergebnisse zudem – in letzter Konsequenz – auch menschlich bedingte Folgerisiken bei der Verwertung der KI-Ergebnisse mit sich bringen, wie beispielsweise den beschriebenen Automation Bias.

Einige der oben aufgezeigten Risiken können bereits im Beschaffungsvorgang durch Escrow adressiert werden. Insofern werden zunächst die Besonderheiten bei der Hinterlegung von KI-Anwendungen und sodann mögliche Lösungsansätze aufgezeigt.

Auf technischer Ebene dürften sich auf den ersten Blick die grundsätzlichen Hinterlegungsgegenstände von KI-Anwendungen nicht fundamental von denen klassischer Escrow-Modelle (inkl. Escrow von SaaS-Anwendungen) unterscheiden. Hinterlegungsgegenstände zu KI-Anwendungen dürften neben der Software in Object- bzw. Source Code-Format, Dokumentation sowie sonstiges geistiges Eigentum, auch Daten enthalten.

Allerdings bestehen hinsichtlich der möglichen Hinterlegungsgegenstände von KI-Systemen auch Besonderheiten, die sich aus dem besonderen Wesen der KI ergeben. Zu bedenken gilt dabei, dass eine KI-Anwendung sowohl als eigenständige Softwarelösung als auch als Teil anderer Technologieprodukte entwickelt werden kann. Insoweit dürfte im ersten Schritt die KI-Anwendung als späteres „Gerüst“ entwickelt werden, das in der Regel aus dem KI-Modell, sowie dem der späteren Aufgabenlösung dienenden Algorithmus bzw. dem neuronalem Netzwerk bestehen wird.⁶² Prominentes Beispiel eines KI-Modells ist das Large Language Model, auf dem auch beispielsweise ChatGPT basiert.

Im weiteren Schritt wird die KI-Anwendung mit Daten, d.h. mit speziell zusammengestellten Trainingsdaten oder auch Live-Daten trainiert bzw. „angelernt“.⁶³ Insbesondere die Trainingsdaten können entweder fiktive Daten oder aber auch Echtdaten sein, die etwa von Kunden bzw. dem Anwender zum Zweck des Trainings der KI dem Anbieter zur Verfügung gestellt werden.

Schließlich wird die fertig trainierte KI-Anwendung nach der „Anlernphase“ genutzt, und zwar entweder in anderer Software für die Umsetzung von KI-Aufgaben oder aber als Basis für in sich abgeschlossene Software.⁶⁴ Die KI-Anwendung wird in ihrem Produktivbetrieb – wie bereits aufgezeigt – stetig „weiterlernen“.

Aus der Besonderheit der KI folgen damit insbesondere die nachfolgenden zusätzlich möglichen Hinterlegungsgegenstände in Escrow-Paketen einer KI-Anwendung, die neben den bereits vorgenannten klassischen Hinterlegungsgegenständen (z.B. Source Code, usw.) u.a. sein können:

• Dokumentierte KI-Algorithmen bzw. neuronale Netzwerke des „leeren“ untrainierten KI-Modells.⁶⁵
• Trainingsdaten, d.h. entweder speziell für das Anlernen der KI zusammengestellte fiktive Daten oder Echtdaten, mit denen die KI angelernt werden soll.⁶⁶ Hierzu können insbesondere auch etwa sogenannte Prompts (d.h. Eingaben bzw. Aufforderungen/Anweisungen des Nutzers an die KI) gehören, auf deren Basis die KI ihren Output zu verfeinern lernt.
• Die trainierten KI-Modelle, in der Form, wie sie eigenständig oder etwa in anderer Software eingesetzt werden.⁶⁷
• In gewissem Umfang auch Live-Daten aus dem Produktivbetrieb der KI-Anwendung, mit denen sich die KI fortentwickelt sowie die fortentwickelte Version der Live-KI-Anwendung.⁶⁸ Unter anderem könnte das diesbezügliche Hinterlegungspaket etwa auch Prompts enthalten, die Nutzer im Produktivbetrieb in die KI-Anwendung eingegeben haben.

Im Rahmen der Hinterlegung von KI-Anwendungen sollen einerseits die durch übliche Formen von Software Escrow anvisierten Risiken adressiert werden. Mögliche weitere Anwendungsgebiete von Escrow im KI-Umfeld wären andererseits aber auch solche, die besonders der Beweissicherung dienen. So etwa für eventuelle Schadensersatzansprüche, Gewährleistungen aller Art oder für den Nachweis der Einhaltung von Sorgfalts- und gesetzlichen sowie sonstigen Pflichten im Zusammenhang mit dem Einsatz des KI-Systems; hierzu zählen auch IT-Sicherheitsrisiken und der etwaige Nachweis des Umgangs mit dem System und dessen Fortentwicklung nach dem neuesten bzw. dem aktuellen „Stand der Technik“.⁶⁹

Daneben gibt es weitere KI-spezifische Risiken, denen durch vorzeitige Adressierung im Beschaffungsprozess mithilfe einer eventuellen Hinterlegung der KI-Anwendung begegnet werden könnte. Besonders hervorzuheben wären insoweit die folgenden:

• Nachweisfunktion: Durch eine Hinterlegung der „fertig“ trainierten, sich jedoch noch nicht im Produktivbetrieb befindlichen KI-Anwendung (einschließlich Trainingsdaten) könnte der Ist-Zustand der KI-Anwendung bei der Übergabe an einen neutralen Dritten (z.B. Escrow-Agent) zugunsten von Anwender und Anbieter dokumentiert werden. Sollte ein „fertig“ trainiertes KI-System vor seinem erstmaligen produktiven Einsatz hinterlegt werden, könnten später beliebige Tests und Untersuchungen am Ursprungszustand durchgeführt werden.⁷⁰ Durch eine eventuell in Betracht zu ziehende periodische oder Live-Hinterlegung des sich fortentwickelnden KI-Systems könnte zudem der weitere Entwicklungsfortschritt neutral dokumentiert und beobachtet werden. Dies könnte schließlich für Anwender und Anbieter nicht nur die Identifizierung und Behebung eventueller unerwünschter Verhaltensweisen der KI-Anwendung erleichtern, sondern auch – soweit technisch möglich – die Ermittlung des Zeitpunkts ihrer Entstehung fördern. Es könnte damit bereits vorgelagert auch eine Beweissicherung der unterwünschten Funktionsweisen der KI durch einen neutralen sachverständigen Dritten sichergestellt werden. Dies könnte etwaig einen Rückschluss auf die Entwicklung der KI zulassen und damit allen Beteiligten bei einer zügigeren Adressierung technischer Herausforderungen helfen. Insbesondere könnten dadurch unnötige Auseinandersetzungen über mögliche Fehlerquellen vermieden werden.

• Informationssicherheit: Durch die Hinterlegung des KI-Systems, einschließlich Trainings- und Produktivdaten, könnte darüber hinaus eine zusätzliche Redundanzschicht für das Produktivsystem bei einem neutralen Dritten geschaffen werden. Anders als bei üblichen Formen von Cyber-Angriffen, bei denen Systeme in der Regel spürbar außer Betrieb gesetzt werden, dürften bei einer etwaigen „Vergiftung“ der für die Entscheidung der KI genutzten Daten, z.B. durch Einspielen von weiteren, mit „bias“ belasteten Daten, die Auswirkungen des Cyber-Angriffs nicht zwangsläufig sofort erkennbar sein. Insbesondere bei geschäftskritischen Anwendungen – soweit KI für solche bereits genutzt wird und werden kann – könnte Escrow daher bei der zügigen Wiederherstellung des vor dem Angriff bestehenden Systemstands förderlich sein.

Ähnlich wie sich KI-Anwendungen und deren Einsatz noch in Entwicklung befinden, steckt auch KI-Escrow als Produkt noch in seinen Anfängen. Spezifische Escrow-Dienstleistungen für KI-Systeme scheinen im Markt daher noch nicht weit verbreitet zu sein.⁷¹

Eines zeigt sich aber bereits jetzt: Identifizierbare Risiken von KI-Systemen können schon im Beschaffungsprozess adressiert werden. Insoweit sollten sowohl Anwender als auch Anbieter den Escrow von KI-Systemen und deren spezifischen Hinterlegungsgegenständen in Betracht ziehen.

Die aufgezeigten Lösungsansätze werden Anwender und Anbieter jedoch insgesamt einer regelmäßigen Kosten- und Nutzenprüfung unterziehen müssen. Insbesondere aufgrund der etwaig zu hinterlegenden Datenmengen sowohl frisch „fertig“ trainierter als auch sich bereits im Produktivbetrieb befindlicher und dynamisch lernender KI-Systeme, dürfte sich die Hinterlegung in technischer und operativer Hinsicht als aufwändig erweisen. Ob sich KI-Escrow daher unter Kosten- und Nutzenrelation als sinnvoll erweisen wird, dürfte von den operativen und kaufmännischen Entscheidungen von Anwendern wie auch Anbietern im Einzelfall abhängen. Es bleibt weiter zu beobachten, wie sich der Escrow-Markt – auch im Hinblick auf die Hinterlegung von KI-Systemen – weiterentwickeln wird.