AI Act kompakt E-Book

Peter Hense

• Herausgeber: Fachmedien Recht und Wirtschaft
• Kategorie: Fachliteratur
• Serie: InTeR-Schriftenreihe
• Sprache: Deutsch

Seitenzahl: 547

Veröffentlichungsjahr: 2024

Beschreibung

"If it's written in Python, it's probably machine learning. If it's written in PowerPoint, it's definitely AI".  Der AI Act stellt die Rechtspraxis vor erhebliche Herausforderungen, da er interdisziplinäres Wissen rund um Technologie, Normierung, Organisationsmanagement und Sozialwissenschaften voraussetzt. Naturwissenschaftlich geprägte Anwender:innen sehen sich mit einer Vielzahl unbestimmter Rechtsbegriffe und grundrechtlicher Postulate konfrontiert, was das Gesetz auch für sie zu einem "Buch mit sieben Siegeln" macht. Der AI Act ist ein weltweit einmaliges Frühwerk zur umfassenden Regulierung automatisierter Entscheidungssysteme, das den dynamischen technischen Entwicklungen rund um AI Grenzen setzen und neue rechtliche Verantwortlichkeiten begründen soll. Die Einteilung von AI-Systemen in verschiedene Risikokategorien, neue Konformitätsbewertungen und Prüfstandards, sowie Verpflichtungen zu Data Governance, Risk Management, Erklärbarkeit, Steuerung und Diskriminierungsfreiheit, Accountability und neue Haftungsregelungen erweitern die Herausforderungen für Anbieter und Nutzer von AI-Systemen. Das vorliegende Werk fungiert als Rechtshandbuch für die Unternehmenspraxis und vereint rechtliches, technisches und organisatorisches Wissen. Die Verfasser:innen stellen Schnittstellen und Reibungspunkte mit anderen europäischen Rechtsakten wie CDSMD, DSGVO, DGA, DA, DMA etc. dar, beziehen rechtsvergleichende Perspektiven ein und bieten mit einem umfangreichen, gut sortierten Literaturapparat eine Basis für vertiefende Studien.

Leseprobe

AI Act kompakt

Compliance, Management und Use Cases für die Unternehmenspraxis

von

Peter Hense

Rechtsanwalt, Leipzig

und

Tea Mustać

Mag. iur., Leipzig

Fachmedien Recht und Wirtschaft | dfv Mediengruppe | Frankfurt am Main

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.de abrufbar.

ISBN: 978-3-8005-1823-4

© 2025 Deutscher Fachverlag GmbH, Fachmedien Recht und Wirtschaft, Mainzer Landstr. 251, 60326 Frankfurt am Main, [email protected]

www.ruw.de

Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Bearbeitungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.

Druck: Beltz Grafische Betriebe GmbH, 99947 Bad Langensalza

Vorwort

„The first question you should ask yourself when building an AI system is; can we do it without AI?“

(Common Sense im Machine Learning)

Unser Buch ist ein Frühwerk und doch eines, das die Essenz von fast drei Jahren intensiver Auseinandersetzung mit dem AI Act in sich trägt. Die Erkenntnisse und Einsichten, die auf den folgenden Seiten von AI Act kompakt gesammelt sind, speisen sich aus unserer langjährigen Begleitung von Machine-Learning-Projekten in Forschung und Entwicklung. Von Dynamic Pricing über biometrische Identifikation bis hin zu Social CRMs und Systemen zur Sprach- und Emotionserkennung – wir haben all diese Technologien bereits auf unseren Tischen seziert. Das ist die technische Seite. Seit 2022 jedoch fokussieren wir uns auf die spezifische Regulierung von Machine Learning, also das, was heute als „künstliche Intelligenz“ die Runde macht.

Die frühzeitige Organisation von Compliance entlang der AI Supply Chain für Unternehmen und Organisationen weltweit zwang uns dazu, uns schon lange vor der offiziellen Einführung des AI Acts mit Themen wie Model Disgorgement durch die FTC, Bias Audits in New York und dem ersten umfassenden AI-Gesetz, dem Colorado AI Act, zu beschäftigen. Ohne unsere enge Vernetzung mit Kolleg:innen aus verschiedensten Fachdisziplinen weltweit wären wir nicht in der Lage gewesen, die Entwicklungen zu durchdringen und entsprechend zu handeln, besonders nicht angesichts des Booms generativer AI Systems. Doch wir hatten das Glück, auf gute Freunde zählen zu können.

Teils aus Neugier, teils im Auftrag, aber stets mit Begeisterung haben wir seit 2017 bei der IEEE an der Standardisierung von Algorithmic Bias Consideration (P7003) mitgewirkt, bereits 2018 Algorithmic Impact Assessments durchgeführt, 2020 unmittelbar vor der Pandemie die ersten Fundamental Rights Impact Assessments verfasst und Ende 2022 die ersten Bias Audits von Automated Employment Decision Tools nach dem New Yorker Local Law 144 begleitet. 2023 überprüften wir das automatisierte Kreditscoring von Banken nach der Schufa auf Diskriminierungsfreiheit und zählen heute zu den Vorreitern bei der Implementierung von AI-Managementsystemen nach ISO 42001. Und dennoch fühlen wir uns angesichts der schieren Menge und Vielfalt des Themas „künstliche Intelligenz“ immer wieder wie Anfänger. Mehr als einmal mussten wir unsere Annahmen revidieren und unsere Bewertungen anpassen – das Technologiefolgenrecht hinkt der Technologie selbst eben oft hinterher.

In diesem Buch geht es nicht um juristische Haarspalterei – dafür war uns die Zeit zu schade. Vielmehr wollen wir Verständnis schaffen und praxisnahe Lösungen präsentieren für all jene, die High-Risk AI Systeme designen, entwickeln, anbieten und einsetzen. Und das sind, entgegen manchen Wunschvorstellungen, recht viele Organisationen. Mit AI Act kompakt erhalten Sie einen kernigen, informativen und persönlich geprägten Einblick in das, was wir dem AI Act entnehmen. Eingeflossen sind tausende Stunden Arbeit und Austausch mit Kolleg:innen aus Data Science, Statistik, ML Engineering, Cybersicherheit, Soziologie, Standardisierung und Recht. Wir nehmen für uns nicht in Anspruch, in jedem Punkt alles zu wissen. Aber unsere Leser:innen können sich darauf verlassen, dass das, was wir schreiben, wohlüberlegt ist und oft in Diskussionen mit anderen Expert:innen gereift ist.

Der AI Act ist handwerklich kein gutes Gesetz. Er wimmelt von Eigentümlichkeiten, sprachlichen Verwirrungen, Wiederholungen, Lücken und Widersprüchen. Aber die großen Linien sind erkennbar, und wir haben uns alle Mühe gegeben, nicht aus jeder sprachlichen Mücke einen rechtlichen Elefanten zu machen, sondern der Praxis eine Handreichung zu bieten, mit der Provider und Deployer den richtigen Weg einschlagen können.

Und wir hatten Freude an der Arbeit – so wie auch an unserem Podcast „RegInt: Decoding AI Regulation“, in dem wir seit 2023 monatlich diejenigen informieren und unterhalten, die an Regulierung, Technologie und den Hintergründen von AI interessiert sind. Wir haben die verfügbare Literatur der letzten Jahre gesichtet und die aktuellen Forschungsergebnisse der Jahre 2020 bis 2024 dort einbezogen, wo sie uns zum Verständnis der gesetzgeberischen Begriffe und Intentionen relevant erschienen. Der AI Act fiel nicht vom Himmel; er basiert in wesentlichen Teilen auf genau diesen Forschungsergebnissen und gesellschaftlichen Entwicklungen – dem Lobbying von Unternehmen genauso wie dem Engagement zivilgesellschaftlicher NGOs.

Einen großen Mehrwert unseres Buches sehen wir in einem weiteren Schwerpunkt: den Standards, Berichten und Guidelines von ISO, IEC, IEEE sowie CEN/CENELEC. Wir geben sogar Einblicke in solche, die sich noch im nichtöffentlichen Entwurfsstadium befinden. Warum? Weil ohne das in diesen Standards verdichtete Fachwissen die Kernanforderungen des AI Acts nur schwer zu verstehen sind. Standardisierung hat den Vorteil, dass juristische, naturwissenschaftliche und geisteswissenschaftliche Stakeholder auf eine gemeinsame Terminologie und ein gemeinsames Verständnis zurückgreifen können. Glauben Sie uns: Das Wissen um und aus interdisziplinären Standards ist bei der praktischen Umsetzung von AI-Act-Compliance deutlich wichtiger als die Lektüre der neuesten juristischen Fachzeitschrift.

Und nun, viel Spaß beim Lesen!

Leipzig, im September 2024

Tea und Peter

Inhaltsverzeichnis

Vorwort

I. Zum Einstieg

1. Anwendungsbereich des AI Acts

a) AI Systems

(1) Einführung

(2) A Deeper Dive: Qualitative und quantitative Aspekte von AI Systems

(3) Kein Anfang und kein Ende? AI-Infrastruktur und AI Systems

(4) Lösungsansätze aus dem Bereich AI Safety, Computation und UML

b) Risikobasierter Ansatz

c) Persönlicher Anwendungsbereich

(1) Provider/Anbieter

(2) Product manufacturer/Hersteller

(3) Deployer/Betreiber

(4) Importer und Distributor/Einführer und Händler

d) Räumlicher Anwendungsbereich

e) AI Literacy (AI-Kompetenz)

(1) Operationalisierung von AI Literacy

i. Programmziele

ii. Schulungsbedarf, einschließlich Zielgruppen und Fachkenntnisniveaus

iii. Schulungsinhalte

iv. Schulungsmethoden

v. Schulungshäufigkeit

vi. Evaluierung

(2) Fazit

2. Gegenstand dieses Handbuchs

II. Design

1. Die Idee

2. Legal Requirements Engineering

3. Zweckbestimmung

a) Usability Engineering

b) Human Factors Engineering

4. Initiale Risikokategorisierung und -bewertung

III. Entwicklung

1. Anforderungen an ein AI System

a) Qualitätsmanagementsystem

(1) Arten des Qualitätsmanagements

(2) Struktur und Bestandteile

(3) Software- und AI-System-Qualitätsmodelle

(4) Operationalisierung der rechtlichen Anforderungen von Art. 17

i. Erste Linie

ii. Zweite Linie

iii. Dritte Linie

b) Risikomanagement

(1) Risikoidentifizierung

(2) Bewertung des Risikos

i. Faktoren für die Abschätzung der Eintrittswahrscheinlichkeit

ii. Faktoren zur Bewertung der Auswirkungen

(3) Risikominderung

(4) Risikoakzeptanz

(5) Risikotoleranz

(6) Etablierung von Controlling-, Überwachungs- und Incident-Response-Prozessen

i. Controlling

ii. Monitoring

iii. Incident-Response-Prozesse

c) Modell-Anforderung: Menschliche Aufsicht

d) Genauigkeit, Robustheit und Cybersicherheit von AI Systems (Art. 15 AI Act)

(1) Überblick

i. Programmsatz für den AI System Life Cycle (Art. 15.1)

ii. Benchmarking und Normung (Art. 15.2)

iii. Dokumentationspflichten (Art. 15.3)

iv. Resilienz (Art. 15.4)

v. Cybersicherheit (Art. 15.5)

(2) Einzelerläuterungen

i. Bedeutung von harmonisierten Normen und Standards im AI Act

ii. Beständige Funktion („consistent performance“) während des gesamten AI System Life Cycles: Universal Lessons in Machine Learning

iii. Was sind Feedback Loops und wie sind sie zu behandeln?

iv. „Engineering Safety in Machine Learning“

(a) Standardisierung: Gewonnene Erfahrung

(b) AI Engineering Best Practices

(c) Praxisbeispiel: Sicherheit und Robustheit von AI Systems im Automotive-Bereich

(d) Inhärent sicheres Design im Machine Learning

(e) Ein Framework für das Testing von AI Systems

(f) AI Red Teaming

(g) NIST-Testplattform „Dioptra“

2. Überblick über Data Governance und Data Management (Art. 10)

a) Machine Learning und Trainingsdaten in a nutshell

b) Verpflichtende Qualitätskriterien für Training, Validierung und Testing von AI Systems (Art. 10.1)

c) Data Governance und Data Management (Art. 10.2)

d) Standardisierung von Data (Quality) Management

e) Definitionen und Metriken

(1) Trainingsdaten („training data“), Art. 3.29

(2) Validierungsdaten („validation data“), Art. 3.30

(3) Validierungsdatensatz („validation data set“), Art. 3.31

(4) Testdaten („testing data“), Art. 3.32

f) Die einzelnen Verfahren

(1) Relevant design choices (Art. 10.2.a)

(2) Data collection processes and the origin of data, and in the case of personal data, the original purpose of the data collection (Art. 10.2.b)

i. Datenquellen in der Machine-Learning-Praxis

ii. Datasheets for Datasets

iii. Datenschutzrecht

(3) Relevant data-preparation processing operations, such as annotation, labelling, cleaning, updating, enrichment and aggregation (Art. 10.2.c)

i. Annotation und Labelling

ii. Data Cleaning

iii. Updating

iv. Enrichment

v. Aggregation

(4) Formulation of assumptions, in particular with respect to the information that the data are supposed to measure and represent (Art. 10.2.d)

(5) Assessment of the availability, quantity and suitability of the data sets that are needed (Art. 10.2.e)

(6) Examination in view of possible biases that are likely to affect the health and safety of persons, have a negative impact on fundamental rights or lead to discrimination prohibited under Union law, especially where data outputs influence inputs for future operations (Art. 10.2.f) sowie Appropriate measures to detect, prevent and mitigate possible biases identified according to point (Art. 10.2.g)

(7) Identification of relevant data gaps or shortcomings that prevent compliance with this Regulation, and how those gaps and shortcomings can be addressed (Art. 10.2.h)

g) Der Kampf gegen Bias und Diskriminierung (Art. 10.3, 10.4 und 10.5)

(1) Erwägungsgründe und Ethics Guidelines for Trustworthy AI der High-Level Expert Group on Artificial Intelligence (HLEG AI, 2019)

(2) Die Fundamental Right Agency (FRA)

(3) Forschung und Wissenschaft: It’s not just the data, stupid!

(4) Internationale Standardisierung

(5) Hinreichend relevant, repräsentativ und so weit wie möglich fehlerfrei und vollständig in Hinblick auf die Zweckbestimmung

i. Die Zweckbestimmung des Systems

(a) Relevanz („relevance“)

(b) Repräsentativität („representative“)

(c) Fehlerfreiheit („error-free“)

(d) Vollständigkeit („complete“)

(6) Statistische Merkmale in Datensätzen, einzeln oder kombiniert

i. Statistische Merkmale (Statistical Characteristics)

ii. Kombination von Datensätzen (Combination of Datasets)

(7) Geografisch, kontextuell, verhaltensbezogen oder funktional typische Datensätze

i. Geografische Rahmenbedingungen

ii. Kontextuelle Rahmenbedingungen

iii. Verhaltensbezogene Rahmenbedingungen

iv. Funktionale Rahmenbedingungen

(8) Verarbeitung sensibler Daten zur Analyse und Mitigation von Verzerrungen (Bias)

(9) AI, Bias und europäisches Antidiskriminierungsrecht: ein Überblick

i. Rechtsnormen

ii. Anwendungsbereiche und geschützte Merkmale

iii. Direkte und indirekte Benachteiligung

iv. Rechtfertigung

v. Positive Maßnahmen

vi. Beweislastumkehr

vii. Rechtsfolgen

viii. Anspruchsgegner

3. Testing und Compliance

a) Sandboxes

(1) Sandboxen im AI Act

(2) Einrichtung und Betrieb von AI-Sandboxen

(3) Ein guter Grund für die Teilnahme an AI-Sandboxen

(4) Sandbox-Plan

(5) Exit-Berichte

(6) Konsequenzen

(7) Verarbeitung von Daten innerhalb der Sandbox

b) Testen unter realen Bedingungen außerhalb von AI-Regulatory-Sandboxen

c) Konformitätsbewertung

(1) Was?

(2) Wann?

(3) Wer und Wie?

(4) Keine Regel ohne Ausnahme

(5) Warum?

d) Harmonisierte Normen, gemeinsame Spezifikationen und Konformitätsvermutung

(1) Harmonisierte Standards

(2) Vermutung der Konformität

(3) Gemeinsame Spezifikationen

(4) Codes of Conduct and Guidelines

e) Inverkehrbringen

4. Technische Dokumentation

IV. Deployment

1. Provider

a) Das Offensichtliche

b) Dokumentation (Art. 18) und automatisch erzeugte Protokolle (Art. 19)

c) Risikomanagement

d) Menschliche Aufsicht

e) Transparenz und Bereitstellung von Informationen für Deployer und/oder Endnutzer

f) Post-Market Monitoring (Art. 72); Korrekturmaßnahmen und Informationspflicht (Art. 20); Meldung schwerwiegender Vorfälle (Art. 73) und Zusammenarbeit mit den Behörden

(1) Zielsetzung und Zweck

(2) Wichtige Merkmale

(3) Post-Market-Monitoring-Plan

(4) Abschlussbericht

(5) Zusammenspiel mit anderen Systemen und Prozessen

2. Deployer

a) Das Offensichtliche: Due Diligence, Verwendung nach Gebrauchsanweisung (Logs, menschliche Aufsicht), Transparenz, Überwachung und Informationspflicht, Berichterstattung

(1) Due Diligence: Die rechtliche Tiefenprüfung

(2) Verwendung gemäß der Betriebsanleitung (Protokolle, menschliche Aufsicht)

(3) Transparenz

(4) Monitoring und Informationspflichten

b) Data Governance

c) Grundrechte-Folgenabschätzung (FRIA)

(1) Wer?

(2) Was?

(3) Warum?

i. Vornahme von Anpassungen und Durchführung zusätzlicher Maßnahmen

ii. Bewertung der Akzeptanz von Restrisiken

(4) Endergebnis

d) Beratung des Betriebsrats

e) Datenschutz-Folgenabschätzung

f) Art. 25 Verpflichtungen entlang der KI-Wertschöpfungskette

V. Besonderheiten

1. Urheberrecht, TDM und Generative AI im AI Act

a) General Purpose AI im AI Act

(1) Anbieter von Modellen und Anbieter von Systemen

(2) Pflichten des Providers eines AI-Modells

(3) Verpflichtungen der Provider eines General Purpose AI Systems

(4) Urheberrecht und General Purpose AI Models

b) Training und Trainingsdaten

(1) Generative AI benötigt viele Daten

(2) Memorization und Overfitting

(3) Text- und Data-Mining

i. Richtlinie 2019/790 zum Urheberrecht im digitalen Binnenmarkt (CDSM-Richtlinie)

ii. TDM und Transformer-Modelle

iii. Drei-Stufen-Test

iv. Zusammenfassung

c) Nutzung, Inputs und Outputs

(1) Nutzung und Inputs

(2) Outputs

2. AI in Finanzdienstleistungen

a) Zwei Einschränkungen

b) Eine zusätzliche (wesentliche) Belastung

c) Wo es doch einfacher wird

3. Biometrische und Emotionserkennungssysteme

a) Biometrische Identifizierung

b) Biometrische Verifizierung

c) Biometrische Kategorisierung

d) Emotionserkennung

Literaturverzeichnis

I. Zum Einstieg

„For, usually and fitly, the presence of an introduction is held to imply that there is something of consequence and importance to be introduced.“

(Arthur Machen)

Bevor wir uns mit dem AI Act und den zu erwartenden praktischen Folgen für Entwickler und Anwender von „AI Systems“ befassen können, weisen wir auf folgendes hin: Dieses Buch ist ein Handbuch für Praktikerinnen und Praktiker, für Menschen jeder Profession, die sich mit Machine Learning und AI Systems auseinandersetzen müssen und wollen. Ein jedes Kapitel böte Stoff für das Verfassen ganzer Kommentare. Aus jedem Artikel des AI Acts könnten Dissertationen entstehen, welche die theoretischen und philosophischen Nuancen sowie die rechtlichen und technischen Diskussionen im Zusammenhang mit Machine Learning und künstlicher Intelligenz beleuchten. Das tun wir hier aber nicht. Wir versuchen vielmehr, etwas Abstraktes fassbar, verständlich und vor allem umsetzbar zu machen. Folglich sind die hier vorgestellten Ansichten subjektiv und erfahrungsgetrieben, aber nicht allumfassend. Das Buch soll ja lesbar bleiben. Los geht’s.

1. Anwendungsbereich des AI Acts

a) AI Systems

(1)Einführung

Nach mehrfachen und grundlegenden konzeptionellen Änderungen der Definition eines AI Systems seit 2021 stützt sich der AI Act im Wesentlichen auf die von der OECD 2023 aktualisierte Definition von AI Systems. Dies ist aus mehreren Gründen bemerkenswert. Denn die – absichtlich oder unabsichtlich – ungenaue Übernahme der Definition erweitert den schon 2021 sehr weit gefassten Anwendungsbereich des Gesetzes. Zudem stammt die OECD-Definition aus der politischen Dimension des Rechts, ist eher ein Programmsatz aus dem Bereich Public Policymaking und keine trennscharfe Norm eines Gesetzgebers, die der Vivisektion durch juristische Kommentatoren standhalten soll. Für juristische Zwecke ist sie daher zu vage. Dessen ungeachtet definiert Art. 3.1 des AI Acts ein „AI System“ nun als:

– ein maschinengestütztes System,

– das für einen in unterschiedlichem Grade autonomen Betrieb ausgelegt ist und

– das nach seiner Betriebsaufnahme anpassungsfähig sein kann und

– das aus den erhaltenen Eingaben für explizite oder implizite Ziele ableitet, wie Ausgaben, wie etwa Vorhersagen, Inhalte, Empfehlungen oder Entscheidungen, erstellt werden,

– die physische oder virtuelle Umgebungen beeinflussen können.

Erwägungsgrund 12 soll dieser diffusen Definition Konturen verleihen und formuliert, unter Autonomie sei ein gewisser Grad an Unabhängigkeit des AI Systems vom menschlichen Zutun zu verstehen. Doch die meisten IT-Systeme und Applikationen verfügen heutzutage zumindest über dieses Mindestmaß an Unabhängigkeit, das mit dem Begriff „Automatisierung“ treffender beschrieben wäre. Denken Sie etwa an Ihren Spam-Filter: Natürlich können Sie den Spamfilter aufrufen und sehen, was der Algorithmus als „Spam“ aussortiert hat. Sie können die algorithmenbasierte Systementscheidung aber auch übergehen und die Kategorisierung als Spam aufheben. Der springende Punkt ist jedoch, dass der Algorithmus eine eingehende E-Mail zunächst unabhängig, also automatisch, in Ihren Spam-Ordner einsortiert hat und Sie die E-Mail daher erst Tage später wahrnehmen. Dennoch ist dies vorteilhafter, als alle Spam-Mails im regulären Posteingang zu erhalten und den gesamten Sortiervorgang manuell durchzuführen. Wenn also ein beliebiges Maß an Autonomie (bei wörtlicher Lesart auch gar keine Autonomie) ausreicht, um diesen Teil der Definition von AI Systems zu erfüllen, können demnach auch sehr einfache Programme davon erfasst sein.

Anpassungsfähigkeit wiederum bezieht sich nach Erwägungsgrund 12 auf die (Selbst-)Lernfähigkeit des AI Systems, die es dem System ermöglicht, sich während der Nutzung zu verändern. Man könnte hierin eine Einschränkung des Anwendungsbereichs sehen, denn viele Systeme verfügen nicht über selbstlernende Fähigkeiten. Allerdings weicht an dieser Stelle die Definition in Art. 3 (1) des AI Acts entscheidend von der OECD-Definition ab: Während die OECD-Definition von AI Systems verlangt, dass sie anpassungsfähig sind, verlangt der AI Act lediglich, dass die Systeme anpassungsfähig sein können, es folglich also nicht unbedingt sein müssen. Wenn die Anpassungsfähigkeit aber lediglich ein fakultatives Merkmal ist, hindert uns dieses Merkmal nicht daran, unseren altmodischen Spam-Filter, der sich mit der Zeit nicht verbessert, als ein AI System zu betrachten.

Das Merkmal der Fähigkeit zum „Ableiten“ wird ebenfalls in Erwägungsgrund 12 angesprochen, allerdings nur in Bezug auf den Einsatz von Technologien, die Ableitungen ermöglichen. Dazu gehören „Ansätze für maschinelles Lernen, wobei aus Daten gelernt wird, wie bestimmte Ziele erreicht werden können, sowie logik- und wissensgestützte Konzepte, wobei aus kodierten Informationen oder symbolischen Darstellungen der zu lösenden Aufgabe abgeleitet wird.“ Ableitungen sind kein spezifisches Merkmal künstlicher Intelligenz, sondern ein allgemeiner Prozess, der in vielen Bereichen der Wissenschaft, Philosophie und im täglichen Leben, z.B. im Rahmen statistischer Berechnungen oder medizinischer Diagnosen, verwendet wird. Inferences, so der international gängige Begriff,1 werden genutzt, um aus Daten und Modellen Schlussfolgerungen zu ziehen, etwa bei der Vorhersage von Ergebnissen oder der Klassifizierung von Daten. Im Machine Learning ist die Inference-Phase derjenige Teil des Prozesses, bei dem das trainierte Modell verwendet wird, um neue Vorhersagen oder Entscheidungen zu treffen. Dieser spezielle Einsatz ist technisch, aber der zugrunde liegende Prozess des Schlussfolgerns existiert in vielen anderen wissenschaftlichen und praktischen Disziplinen.

Das Merkmal der Beeinflussung der Umgebungen wird nirgendwo näher erläutert. Als Umgebungen sollen jedoch gemäß Erwägungsgrund 12 „Kontexte verstanden werden, in denen KI-Systeme betrieben werden, während die von einem KI-System erzeugten Ausgaben verschiedene Funktionen von KI-Systemen widerspiegeln, darunter Vorhersagen, Inhalte, Empfehlungen oder Entscheidungen.“

Eine Einschränkung oder auch nur Präzisierung der Definition von AI Systems durch dieses Merkmal ist indes nicht zu erwarten: Nicht nur beeinflusst die Integration jeder Art von System dessen Umgebung. Vielmehr implementiert man ein neues System in bestehende Prozesse gerade um diese Prozesse zu beeinflussen. Wenn also Menschen ein AI System für einen bestimmten Zweck einsetzen, leitet das AI System zumindest den menschlichen Denkprozess und beeinflusst ihn daher. Mangels einer Erheblichkeitsschwelle – etwa, dass der Einfluss entscheidend oder auch nur erheblich sein muss – kann dieses Merkmal schon dann als erfüllt angesehen werden, wenn ein beliebiges System einen beliebigen Teil eines Prozesses automatisiert, da es immer zumindest diesen Teil des Prozesses beeinflussen wird.

Der Versuch einer Konturierung könnte Erwägungsgrund 12 dennoch zu entnehmen sein. AI Systems sollen getrennt von einfacheren herkömmlichen Softwaresystemen oder Programmierungsansätzen betrachtet werden und sich nicht auf Systeme beziehen, die auf Regeln beruhen, die ausschließlich von natürlichen Personen zur automatischen Ausführung von Operationen definiert werden. An dieser Stelle fiele unser Spam-Filter aus der Definition eines AI Systems heraus – jedenfalls solange alle Begriffe, die zur Einstufung als „Spam“ führen, von einem Menschen explizit kodiert werden. Selbstredend tut dies niemand mehr.

Die gesetzgeberische Definition und ihre praktische Anwendung sind freilich umstritten, wobei sich der ungelöste Streit aus dem Gesetzgebungsprozess nunmehr in die Kommentarliteratur verlagert. Einige Stimmen zaubern neue, aus ihrer Sicht wünschenswerte Kriterien für die Bestimmung dessen, was AI Systems sein sollen, hervor. Andere interpretieren Teile der aktuellen Definition aus Unternehmensperspektive neu, um eine Abgrenzung zu künstlich intelligenten Fähigkeiten bislang unverdächtiger Standardsoftware zu ermöglichen, oder fügen Anwendungsbeispiele und ausführliche Erklärungen ihren Einschätzungen bei.2 Obwohl all dies nützlich sein kann, stellen wir einen eigenen, äußerst effizienten Ansatz vor:

Wann immer Sie sich darüber den Kopf zerbrechen müssen, ob Sie es mit einem AI System nach dem AI Act zu tun haben, lautet die Antwort: Ja!

Viele werden von der edlen Einfalt und stillen Größe dieser Daumenregel zunächst überrascht sein, wir halten sie aus mehreren Gründen für nützlich:

– Die Entwicklung von Leitlinien der Kommission auf Grundlage von Artikel 96 des AI Acts oder durch Aufsichtsbehörden zur genauen Klärung dessen, was als AI System gilt, wird noch Zeit in Anspruch nehmen.

– Nicht alle AI-Systeme unterliegen den gleichen Verpflichtungen des AI Acts, weshalb die Frage der Klassifizierung eines Systems als „AI System“ nicht überbewertet werden sollte. Entscheidend ist vielmehr die Bestimmung der Risikokategorie, da diese das zentrale Element des AI Acts darstellt.

– Wenn Sie Ihr IT-System als AI System kennzeichnen, können Sie es ohne Bedenken als solches vermarkten, ohne negative Folgen befürchten zu müssen.

– Darüber hinaus gibt es in der ingenieurstechnischen Praxis bereits weitere, sehr prägnante und standardisierte Definitionen dessen, was ein „AI System“ ist (mehr dazu im Folgenden).

Schließlich gibt es auch AI Systems, die, obwohl sie unter den Begriff eines AI Systems fallen, nicht unter dem AI Act reguliert sind. Diese Ausnahmen sind im Art. 2 erwähnt und enthalten:

– AI Systems, die nicht in der Union in Verkehr gebracht oder in Betrieb genommen werden, wenn die Ausgaben in der Union ausschließlich für militärische Zwecke, Verteidigungszwecke oder Zwecke der nationalen Sicherheit verwendet werden (Art. 2.3.),

– AI Systems, die Behörden in Drittländern oder internationalen Organisationen im Rahmen der internationalen Zusammenarbeit oder internationalen Übereinkünfte im Bereich der Strafverfolgung und justiziellen Zusammenarbeit mit der Union oder mit einem oder mehreren Mitgliedstaaten verwenden (Art. 2.4.),

– AI Systems oder AI-Modelle, einschließlich ihrer Ausgabe, die eigens für den alleinigen Zweck der wissenschaftlichen Forschung und Entwicklung entwickelt und in Betrieb genommen werden (Art. 2.6.).

(2)A Deeper Dive: Qualitative und quantitative Aspekte von AI Systems

Nach dem kurzen Einstieg in das Thema möchten wir der aktuellen Debatte einige aus unserer Sicht notwendige Impulse mitgeben, die sich aus Rechtssystematik, Technologie und Geschäftsprozessmodellierung speisen.

Den im Erwägungsgrund 12 gewünschten Einschränkungen des unklaren Wortlauts des Begriffs AI System muss man nicht nur aus zeitlicher Perspektive – sie lesen sich wie ein Appell an den Gesetzgeber, der jedoch im Normtext keinen Niederschlag gefunden hat – sondern auch angesichts der klaren Rechtsprechung des EuGH kritisch gegenüberstehen. Zuletzt stellte das Gericht in der Rechtssache C-307/22 (Urteil vom 26.10.2023 – DW v. FT, Rn. 44 m.w.N.) fest,

„dass nach ständiger Rechtsprechung die Erwägungsgründe eines Unionsrechtsakts rechtlich nicht verbindlich sind und weder herangezogen werden können, um von den Bestimmungen des betreffenden Rechtsakts abzuweichen, noch, um diese Bestimmungen in einem Sinne auszulegen, der ihrem Wortlaut offensichtlich widerspricht.“

Angesichts dieser klaren Einhegung der normativen Kraft von Erwägungsgründen wirkt Erwägungsgrund 12 ambitioniert formuliert. Es drängt sich die Frage auf, ob die im Trilog erarbeiteten Wünsche, der von einigen Beteiligten als allzu weit empfundenen Definition des Begriffs eines AI-Systems entgegenzuwirken, irgendeine praktische Relevanz entfalten können. Denn gerade die negative Abgrenzung zu vermeintlich „herkömmlichen Systemen“, die in den Erwägungsgründen sprachlich unpräzise und fachlich zweifelhaft beschrieben ist, liefert ein starkes Indiz dafür, dass die Definition in Art. 3.1 bei näherer Betrachtung eine überraschend breite Palette von Bestandssystemen erfasst – darunter auch Applikationen und Verfahren, die, betrachtet man sie flüchtig, den in erster Linie schillernden Titel3 „Künstliche Intelligenz“ kaum für sich beanspruchen dürften. Anstatt sich jedoch den Kopf über das inkohärente verbale Resultat eines überhasteten Gesetzgebungsverfahrens zu zerbrechen, sollte man bei der Auslegung des Begriffs AI System vielmehr den systematischen Kontext der Norm in den Mittelpunkt stellen. Dieser wird, wie zuletzt durch den EuGH im Urteil vom 22.6.2023 (Rechtssache C-579/21 – Pankki S, Rn. 38) deutlich gemacht, regelmäßig herangezogen, um die Reichweite von Begriffen und Konzepten des Unionsrechts präzise zu bestimmen:

„Bei der Auslegung einer Vorschrift des Unionsrechts sind nicht nur deren Wortlaut, sondern auch der Zusammenhang, in dem sie steht, sowie die Zwecke und Ziele, die mit dem Rechtsakt, zu dem sie gehört, verfolgt werden, zu berücksichtigen.“

Auf Basis dieser Systematik war der EuGH in der Vergangenheit auch bereit, erkannte Rechtsschutzlücken zu schließen, um ein hohes Schutzniveau für die rechtsunterworfenen Bürgerinnen und Bürger zu erhalten (Urteil vom 7.12.2023 – C-634/21 – OQ v. Land Hessen und Schufa, Rn. 61):

„Hingegen bestünde unter Umständen wie jenen des Ausgangsverfahrens, an denen drei Akteure beteiligt sind, die Gefahr einer Umgehung von Art. 22 DSGVO und folglich eine Rechtsschutzlücke, wenn einer engen Auslegung dieser Bestimmung der Vorzug gegeben würde [...].“

Gerade die zitierte Entscheidung C-634/21 verdeutlicht, dass es sichtbare Parallelen gibt zwischen dem Schutz vor automatisierter Entscheidungsfindung, der sich stärker aus der Menschenwürdegarantie in Art. 1 der EU-Grundrechtecharta (EUGRCh) als aus dem Daten- und Privatsphärenschutz der Art. 7 und 8 EUGRCh speist, und den vielfältigen Schutzgedanken, die im Art. 1.1 des AI Act verankert sind. Der AI Act fordert in seiner Zweckbestimmung explizit ein hohes Schutzniveau für Sicherheit, Gesundheit und alle in der Charta verankerten Grundrechte. Dieses Ziel soll durch den Einsatz vertrauenswürdiger, „trustworthy“, AI erreicht werden, wie sie von der Independent High-Level Expert Group on Artificial Intelligence (HLEG AI) in den „Ethics Guidelines for Trustworthy AI“ aus dem Jahr 2019 beschrieben und, nota bene, in Erwägungsgrund 27 des AI Acts mit gesetzgeberischer Gravitas unterstrichen wurden.

Der Satz „The term ‚Artificial Intelligence‘ means many things to many people“ ist nicht ohne Grund ein weit verbreiteter Topos. Die HLEG AI veröffentlichte neben ihren Ethics Guidelines im April 2019 auch eine eigene Abhandlung mit dem Titel „A definition of AI: Main capabilities and disciplines“, die sich mit der Frage auseinandersetzt, was ein AI-System darstellen soll. Wenngleich diese Publikation im Kontext des späteren Gesetzgebungsverfahrens nur colorandi causa betrachtet werden mag, kann aufgrund des eindeutigen Verweises des Gesetzgebers in Erwägungsgrund 27 auf die Arbeit dieser Expertenkommission angenommen werden, dass deren Ergebnisse einen gewissen Einfluss auf die gerichtliche Auslegung des umstrittenen Begriffs der AI Systems haben werden, da die Systemdefinition der HLEG AI die Grundlage der vom Gesetzgeber in eben diesem Erwägungsgrund übernommenen „Principles for trustworthy and ethical AI“ ist.

Unspektakulär nimmt die Publikation auf die Wortwahl der Kommission in ihrer European Commission’s Communication on AI Bezug:4

„Artificial intelligence (AI) refers to systems that display intelligent behaviour by analysing their environment and taking actions – with some degree of autonomy – to achieve specific goals. AI-based systems can be purely software-based, acting in the virtual world (e.g. voice assistants, image analysis software, search engines, speech and face recognition systems) or AI can be embedded in hardware devices (e.g. advanced robots, autonomous cars, drones or Internet of Things applications).“

Für die Zwecke unseres Handbuchs verzichten wir auf eine detaillierte Analyse der psychologischen und kognitiven Grundlagen dessen, was „Intelligenz“ ausmacht, und überlassen derartige Erwägungen den Fachleuten auf diesem Gebiet.5 Stattdessen konzentrieren wir uns ausschließlich auf das Ergebnis, nämlich die aktualisierte Definition von Artificial Intelligence Systems durch die HLEG AI:

„Artificial intelligence (AI) systems are software (and possibly also hardware) systems designed by humans that, given a complex goal, act in the physical or digital dimension by perceiving their environment through data acquisition, interpreting the collected structured or unstructured data, reasoning on the knowledge, or processing the information, derived from this data and deciding the best action(s) to take to achieve the given goal. AI systems can either use symbolic rules or learn a numeric model, and they can also adapt their behaviour by analysing how the environment is affected by their previous actions. As a scientific discipline, AI includes several approaches and techniques, such as machine learning (of which deep learning and reinforcement learning are specific examples), machine reasoning (which includes planning, scheduling, knowledge representation and reasoning, search, and optimization), and robotics (which includes control, perception, sensors and actuators, as well as the integration of all other techniques into cyber -physical systems).“

Diese Definition entfaltet einen erzählerischen Charme, der in scharfem Kontrast zu der schwerfälligen, fast mechanischen Abfolge von unzugänglichen Schlagwörtern und bedeutungsschwangeren Halbsätzen in Art. 3.1 des AI Acts steht. Sie ist eine mehrdimensionale, interdisziplinäre Annäherung an den Begriff „Künstliche Intelligenz“ und weist dabei, anders als diejenige, die Gesetzestext geworden ist, auch eine logische und hierarchische Struktur auf. Die Zusammensetzung der High-Level Expert Group on AI garantierte offenbar eine fachliche Qualität, die im Rahmen des Gesetzgebungsprozesses trivialeren Interessen geopfert wurde.

Doch künstliche Intelligenz war lange vor dem Interesse der Juristinnen und Juristen bereits ein Thema für Ingenieurswissenschaften und Standardisierungsorganisationen wie ISO (International Organization for Standardization), IEC (International Electrotechnical Commission) und IEEE (Institute of Electrical and Electronics Engineers).

Mit der praktisch tätigen Naturwissenschaftlern eigenen Nüchternheit und Präzision definiert die von uns zur Lektüre nachdrücklich empfohlene ISO/IEC 22989:2022 (Information technology – Artificial intelligence – Artificial intelligence concepts and terminology) unter 3.1.4 den Begriff „AI System“ als:

„engineered system that generates outputs such as content, forecasts, recommendations or decisions for a given set of human-defined objectives“.

In der Kürze liegt die Würze, scheint der Konsens der an der Standardsetzung Beteiligten Experten gewesen zu sein. Fakt ist, der Fokus auf das Wesentliche, den technologischen Kern der Debatte, entfaltet in dieser Definition seine Stärke. Weitere, durchaus relevante aber nicht definitorisch essenzielle Erwägungen finden sich standardgemäß in den Anmerkungen zur Definition („notes to entry“):

Note 1 to entry:

„The engineered system can use various techniques and approaches related to artificial intelligence to develop a model to represent data, knowledge, processes, etc. which can be used to conduct tasks.“

Note 2 to entry:

„AI systems are designed to operate with varying levels of automation.“

An dieser Stelle stutzen aufmerksame Leserinnen und Leser und erinnern sich, dass dieser Satz so ähnlich sowohl in der OECD-Definition als auch Art. 3.1 AI Act auftaucht, jedoch mit einem entscheidenden Unterschied: Anstelle von „varying levels of autonomy“ spricht die Norm von „automation“. Warum? Eine mögliche und für die am Gesetzgebungsverfahren Beteiligten nicht unbedingt schmeichelhafte Antwort findet sich in der eben zitierten Norm ISO/IEC 22989 unter 5.13 „Autonomy, heteronomy and automation“ und der dortigen Note:

„In jurisprudence, autonomy refers to the capacity for self-governance. In this sense, also, ‚autonomous‘ is a misnomer as applied to automated AI systems, because even the most advanced AI systems are not self-governing. Rather, AI systems operate based on algorithms and otherwise obey the commands of operators. For these reasons, this document does not use the popular term autonomous to describe automation.“

Autonomie, wie sie in den Werken der Science Fiction als selbstbestimmtes Handeln technischer Systeme imaginiert wird, existiert in der technologischen Realität in dieser Form nicht. Es gibt indes verschiedene Abstufungen und Formen der Automatisierung, die Prozesse und Entscheidungen in unterschiedlichem Maße beeinflussen können. Angesichts dieser technologischen Gegebenheiten darf man mit Fug und Recht davon ausgehen, dass ein verantwortungsvoller Gesetzgeber nicht der Fiktion, sondern der Gestaltung der realen Welt verpflichtet ist. Es liegt daher nahe, den Begriff „Autonomie“ im Kontext des AI Acts im Sinne von „Automatisierung“ zu interpretieren.

Diese rationale Auslegung findet ihren Rückhalt insbesondere in der Tatsache, dass der Gesetzgeber ein hohes Maß an Schutz bei jeder Form der Automatisierung von Entscheidungen über Menschen fordert, sobald diese eine bestimmte praktische Relevanz erreichen. Der Europäische Gerichtshof hat dies in der bereits zitierten Rechtssache C-634/21 ausführlich erörtert und dabei den Anwendungsbereich des Verbots automatisierter Entscheidungsfindung gemäß Artikel 22 DSGVO wesentlich erweitert. Besonders im Fokus stehen hier gestreckte und gestufte Sachverhalte, bei denen mehrere Teilprozesse zu einer finalen Entscheidung führen6, und in denen sich einzelne Teilscores sequenziell und/oder kaskadenartig gegenseitig beeinflussen. Dies gilt etwa für die automatisierte Kreditwürdigkeitsprüfung, die Performanceoptimierung und das Load Balancing von Cloud-basierten Anwendungen durch Microservices, oder auch Recommendation-Engines von Streaming-Diensten und sozialen Netzwerken.

Sobald die durch diese automatisierten (Einzel-)Systeme gefällten Entscheidungen in Bezug auf natürliche Personen eine gewisse Erheblichkeitsschwelle überschreiten und dadurch in den Anwendungsbereich des Artikels 22 DSGVO geraten, entfaltet sich ein Entscheidungsprozess, der nicht passiv integriert wird, sondern seinerseits integrativ auf sämtliche Elemente einwirkt, die im Rahmen dieses Prozesses Relevanz erlangen. Rechtsanwender des AI Acts sehen sich hier vor erhebliche Herausforderungen gestellt, nicht nur logischer, sondern auch praktischer Natur, da insbesondere Kreditwürdigkeitsbewertungen in der Regel als „High-Risk AI Systems“ klassifiziert werden und somit besonders sorgfältig entwickelt, implementiert und überwacht werden müssen.

Inmitten dieser komplexen Gemengelage erhebt sich eine zentrale Frage, die für die betroffenen Akteure von größter Tragweite ist: Muss jedes Teilsystem, das durch automatisierte Vorarbeiten zur finalen Entscheidung beiträgt, ja, diese womöglich „maßgeblich leitet“ (vgl. EuGH – C-634/21, Rn. 62), als eigenständiges „AI System“ gewertet werden? Oder vielmehr handelt es sich bei der Vor-, Haupt- und Nachverarbeitung um ein einheitliches, übergeordnetes Gesamtsystem, das die verschiedenen Teilsysteme zu einem organischen Ganzen verbindet, gleichsam ein technisches Kollektiv, dessen Einzelteile nur im Zusammenspiel die finale Entscheidung erzeugen, die dann im Sinne der gewählten Definition von Art. 3.1 physische oder virtuelle Umgebungen beeinflussen kann?

Die Konsequenzen einer solchen Entscheidung sind von erheblicher Tragweite. Sollte jedes Teilsystem als eigenständiges AI System klassifiziert werden, so fällt es unter die umfassenden Verpflichtungen des Kapitels 3 des AI Acts, einschließlich der strengen Konformitätsprüfungen. Dies würde bedeuten, dass jedes dieser Systeme einer individuellen Prüfung unterzogen werden müsste, was Compliance-Aufwand und Kosten erheblich steigern würde.

Legt man hingegen ein funktionales Verständnis des Begriffs „AI System“ im Sinne der finalen Zweckbestimmung zugrunde, könnte eine einzige, übergreifende Konformitätsprüfung ausreichend sein. Allerdings ergäben sich in diesem Fall, besonders bei arbeitsteilig organisierten Prozessen – wie sie in der Rechtssache C-634/21 vom EuGH erörtert wurden – erhebliche Anforderungen an die technische, organisatorische und rechtliche Koordination zwischen den beteiligten Akteuren. Diese müssten ihre Handlungen und Systeme nicht nur harmonisieren, sondern auch gemeinsam Verantwortung tragen, um sicherzustellen, dass der Entscheidungsprozess als einheitliches, integriertes System den Anforderungen des AI Acts genügt. Wissenschaft, Rechtsprechung und Praxis sind gefordert, eine sinnvolle Balance zwischen einer zu stark fragmentierten und einer allzu weiten funktionalen Sichtweise zu schaffen. Im Sinne des Telos des AI Acts spielt es keine Rolle, wie ausgeklügelt oder raffiniert ein System technisch gestaltet ist; entscheidend ist der Zweck, zu dem es eingesetzt wird. Die Einstufung als AI System bedeutet dabei weder per se einen Verlust noch ein Risiko, sondern stellt lediglich die Eintrittskarte zu weiteren, durch den AI Act vorgeschriebenen Klassifikationsrunden dar. Von besonderer Bedeutung ist hierbei Artikel 6, der „High-Risk AI Systems“ strenge Qualitätsanforderungen auferlegt. Diese strikten Vorgaben sollen gewährleisten, dass solche Systeme dem übergeordneten Ziel dienen: die Etablierung einer vertrauenswürdigen KI „made in Europe“. Gegen diese Zielsetzung ist wenig einzuwenden.

Praxisbeispiel: Microservice Architecture

Um zu verdeutlichen, welche Dimensionen der Komplexität von IT-Systemen in der praktischen Anwendung erreicht werden, lohnt sich ein Blick auf die unter dem Namen „Death Stars of Microservices“ bekannten Visualisierungen der Architekturen von Amazon und Netflix. Doch was verbirgt sich hinter diesem bezeichnenden Bild?

Diese beiden mittlerweile historischen (Stand: 2015), im Internet jedoch weit verbreiteten Darstellungen illustrieren die ungeheure Dichte und Verflechtung der Microservices-Architekturen, die von beiden Unternehmen eingesetzt werden. Der Begriff „Death Star“ verweist dabei auf die unüberschaubare Anzahl von miteinander verknüpften Diensten, die in einem engmaschigen Netz von Abhängigkeiten zueinander stehen. Der Blick auf diese Architekturen offenbart die immense Herausforderung, die in der Steuerung und Überwachung solcher Systeme liegt. Jeder Service kommuniziert mit vielen anderen und trägt zum Gesamterfolg einer Organisation oder zumindest eines Geschäftsprozesses bei. Doch gerade diese Vielzahl an Interaktionen bringt auch die Notwendigkeit mit sich, die Prozesse innerhalb dieser Netzwerke genauestens zu orchestrieren und zu überwachen, um ihre Effizienz und Stabilität zu gewährleisten. Was auf den ersten Blick als unübersichtliches Gewirr erscheint, ist in Wirklichkeit der Ausdruck eines fortschrittlichen Ansatzes, der es Organisationen ermöglicht, Millionen von Kunden zeitgleich zu bedienen und dabei kontinuierlich Innovationen in ihre Systeme zu integrieren. Microservice Architecture (oder kurz: Microservices) ist ein modernes Paradigma in der Softwareentwicklung, das darauf abzielt, bislang monolithische Anwendungen in kleinere, unabhängige Dienste zu zerlegen7. Diese Microservices sind lose gekoppelt, agieren selbstständig, automatisiert und erfüllen jeweils eine spezifische, abgegrenzte Funktion. Sie kommunizieren über definierte Application Programming Interfaces (APIs) und können unabhängig voneinander entwickelt, bereitgestellt und skaliert werden. Diese moderne Softwarearchitektur hat sich insbesondere in groß angelegten, verteilten Systemen etabliert, da sie Flexibilität, Skalierbarkeit und Agilität fördert.

Ein wesentlicher Vorteil der Microservices-Architektur liegt in ihrer Fähigkeit, einzelne Dienste unabhängig voneinander zu aktualisieren oder zu skalieren, ohne das gesamte System beeinflussen zu müssen. Dies ermöglicht eine kontinuierliche Bereitstellung und erleichtert die Einführung neuer Funktionen. Die Dezentralisierung der Anwendungslogik führt zu einer erhöhten Fehlertoleranz, da Ausfälle einzelner Dienste in der Regel keine gravierenden Auswirkungen auf das Gesamtsystem haben. Grundsätzlich sind dies Funktionalitäten, denen auch im Rahmen des AI Acts für AI Systems unter dem Stichwort „Robustness“ eine relevante Rolle zugewiesen ist (vgl. Art. 15). Gleichzeitig bringt diese Architektur Herausforderungen mit sich, insbesondere bei der Nachverfolgung von Geschäfts- und Entscheidungsprozessen, die über zahlreiche, voneinander abhängige Microservices hinweg ablaufen. Die komplexen Interaktionen und Abhängigkeiten der Dienste erschweren es, den genauen Pfad eines Prozesses und damit auch einer Entscheidungsfindung durch das System nachzuvollziehen und zu steuern. Die im Hintergrund mitschwingende Frage lautet: Was, wenn eines, mehrere oder alle dieser Microservices für sich betrachtet oder in ihrer Gesamtheit oder Teilgesamtheit ein AI System sind? Wie kann man überhaupt feststellen, ob ein bestimmter Microservice einen relevanten Einfluss hat auf Datenflüsse oder Gesamtfunktion?

Kein Grund zur Verzweiflung meinen wir nach einigen Jahren der Erfahrung in diesem Bereich. Um den Einfluss einzelner Microservices und den Entscheidungsprozess bei ihrer Ausführung planmäßig festzustellen, kommt in der Praxis häufig ein sogenanntes Business Process Modeling (BPM) zum Einsatz. Business Process Modeling im Kontext der IT fokussiert sich auf die Darstellung und Optimierung von Datenflüssen und automatisierten Prozessen innerhalb eines Systems. Es hilft dabei, IT-gestützte Geschäftsprozesse zu visualisieren, zu analysieren und effizienter zu gestalten. BPM ermöglicht es, die Interaktionen zwischen verschiedenen Systemkomponenten, Datenquellen und Anwendungen transparent abzubilden und zu orchestrieren.

Softwarebasierte BPM-Lösungen ermöglichen es, den Ablauf von Prozessen sowie deren Fluss durch verschiedene Microservices eines Unternehmens zu verfolgen. Auf diese Weise wird die Geschäftslogik, die sich über zahlreiche Dienste erstreckt, transparent und nachvollziehbar. Unternehmen können dadurch erkennen, wie ihre Prozesse in einer verteilten Architektur ablaufen und bei Bedarf in Echtzeit Anpassungen oder Optimierungen vornehmen. Diese Überwachung und Steuerung sind besonders in komplexen Systemen, die auf Microservices basieren, von großer Bedeutung, da die zahlreichen Interaktionen und Abhängigkeiten effizient koordiniert werden müssen.

Die Business Process Model and Notation (BPMN™) ist eine grafische Notation zur Spezifikation von Geschäftsprozessen in einem Business Process Diagram. Der Begriff „Notation“ bezeichnet in diesem Zusammenhang ein standardisiertes System von Symbolen und Regeln, das verwendet wird, um Geschäftsprozesse klar und einheitlich darzustellen. Ziel der BPMN ist es, eine Notation bereitzustellen, die für Entscheidungsebenen in Organisationen verständlich ist, gleichzeitig aber die komplexen technischen Details für Entwickler abbilden kann.

BPMN hat sich als De-facto-Standard für Geschäftsprozessdiagramme etabliert und wird von denjenigen Stakeholdern genutzt, die Geschäftsprozesse entwerfen, verwalten und umsetzen. Sie ermöglicht es, Diagramme präzise genug zu gestalten, um sie in Softwarekomponenten zu übersetzen. Die flussdiagrammartige Notation ist leicht zu verwenden und unabhängig von spezifischen Implementierungsumgebungen.

Das Hauptziel von BPMN ist, eine Notation zu unterhalten, die für alle Anwender verständlich ist: von den Business Analysts, die die Prozesse entwerfen, über die Entwickler, die sie in Technologie umsetzen, bis hin zu den Personen, die diese Prozesse überwachen und steuern oder eben rechtlich bewerten. BPMN schafft somit eine Brücke zwischen dem Prozessdesign und der Prozessimplementierung. Die ISO/IEC 19510:2013 (Information technology – Object Management Group Business Process Model and Notation) hingegen geht einen Schritt weiter: Sie ist die internationale Norm, die BPMN weltweit formell standardisiert. Sie definiert nicht nur die Notation selbst, sondern auch die zugrunde liegenden Semantiken und Best Practices, welche sicherstellen, dass BPMN-Diagramme einheitlich und korrekt angewendet werden. Diese Norm garantiert, dass die Darstellung und Interpretation von Geschäftsprozessen auf der Grundlage von BPMN in verschiedenen Branchen, Professionen und Ländern konsistent bleibt und somit eine gemeinsame Sprache zur Prozessmodellierung entsteht.

Nachstehend steht beispielhaft die Modellierung des Prozesses einer Vendor Application, der teils automatisiert, teils manuell abläuft, wobei an verschiedenen Stellen Drittanbieter-Tools eingesetzt werden. So etwa GPT von OpenAI zur Extraktion von Stammdaten und die Durchführung einer Sentiment-Analyse, ebenso wie Verifikationsservices des Google Maps Connectors oder eine Schnittstelle zu einer Kommunikationsanwendung wie Slack.

Selbst bei dieser oberflächlichen Betrachtung wird deutlich, wie komplex selbst vermeintlich einfache automatisierte Workflows sein können und wie wichtig es ist, nach einer ersten Übersichtsebene tiefer in die Struktur und Dynamik solcher Prozesse einzudringen. Und noch etwas wird klar: Die Frage nach der Verantwortung für die systemübergreifende, alle Komponenten verbindende Entscheidung rückt unweigerlich näher und verlangt nach einer präzisen Antwort.

Business Process Modelling hat einen weiteren nicht zu unterschätzenden Vorteil: Neben der entscheidungsbezogenen Analyse der IT-Infrastruktur zur Festlegung der Grenzen und Funktionsweise von AI Systems ermöglicht es die Erfüllung der Transparenzverpflichtungen für High-Risk AI Systems nach Art. 86.1, also des subjektiven Right to explanation of individual decision-making in Bezug auf die „wichtigsten Elemente der getroffenen Entscheidung“, sowie im Falle von Entscheidungen in Bezug auf natürliche Personen im Anwendungsbereich von Art. 22 DSGVO, die Bereitstellung von aussagekräftigen Informationen über die involvierte Logik und die Tragweite der Auswirkungen einer solchen Verarbeitung nach Art. 13.2.f, 14.2.g sowie 15.1.h DSGVO. In die Vorbereitung dieser Prozesse sollten ab sofort die Schlussanträge des Generalanwalts Richard de la Tour in der Rechtssache C-203/22 – CK v. Dun & Bradstreet Austria GmbH/Magistrat der Stadt Wien mit einfließen. Demnach sind folgende Anforderungen zu erfüllen, damit Informationen über die automatisierte Entscheidungsfindung als aussagekräftig im Sinne des Gesetzes gelten können: (1) Die Auskunft muss alle verwendeten Methoden und Kriterien umfassen, (2) die mitgeteilten Informationen müssen präzise, leicht zugänglich sowie in klarer und einfacher Sprache angeboten werden, dabei (3) vollständig und kontextbezogen sowie (4) auf den Verständnishorizont des jeweiligen Individuums zugeschnitten sein, damit diese Person (5) die Übereinstimmung der mitgeteilten Informationen nebst eines (6) objektiv nachprüfbarer Kausalzusammenhangs zwischen Methoden, Kriterien und Ergebnis nachprüfen kann. Da dem Geschäftsgeheimnisschutz bereits unter der DSGVO nur eine untergeordnete Bedeutung zukommt, ist auch unter dem AI Act mit seinen teilidentischen Schutzzielen nicht zu erwarten, dass Black Boxes vor Gericht Bestand haben werden. Im Gegenteil, Richard de la Tour öffnet Aufsichtsbehörden und Gerichten Wege, auch Geschäftsgeheimnisse zu prüfen und zu entscheiden, inwieweit diese den vorrangigen Auskunftsanspruch überhaupt beschränken können.

(3)Kein Anfang und kein Ende? AI-Infrastruktur und AI Systems

Praktisch relevanter als die oft lebhafte, jedoch häufig ziellose Debatte über die rechtliche Qualifikation der Fähigkeiten bestehender IT-Systeme und Anwendungen als AI System im Sinne des AI Acts erscheint uns die ingenieurstechnische Identifikation und präzise Abgrenzung dieser Systeme insbesondere dort, wo sie integrativer Teil einer größeren Gesamtarchitektur sind, wie bei embedded AI, auf die Erwägungsgrund 12 am Ende explizit Bezug nimmt. Eine fundierte und belastbare Beurteilung erfordert tiefgehendes technisches Fachwissen, insbesondere hinsichtlich der Systemarchitektur, der Struktur und Funktionsweise der Algorithmen, der zugrunde liegenden Datenverarbeitungspipeline sowie der Modellierungslogik, die im Inneren des Systems angewandt wird.

Nur durch eine detaillierte Analyse der Kernkomponenten – etwa der Implementierung von Machine-Learning-Modellen –, der spezifischen Art und Weise, wie Entscheidungsfindungsprozesse automatisiert werden, und der Integration des Systems in übergeordnete IT-Infrastrukturen kann eine klare und fundierte Abgrenzung erfolgen. Hingegen führt eine oberflächliche Bewertung, sei es anhand von Werbeunterlagen, Bedienungsanleitungen oder einem schnellen Blick auf Datenflüsse, wie er im Datenschutz- und IT-Sicherheitsrecht gelegentlich geschieht, kaum zu einer zufriedenstellenden Antwort auf die komplexe Frage der Systemklassifikation. Eine tragfähige Beurteilung erfordert vielmehr eine detaillierte Prüfung der technischen Spezifikationen sowie des gesamten Entwicklungsprozesses des Systems. Nur auf dieser Grundlage lässt sich verlässlich feststellen, was technisch zu einem AI System im Sinne des AI Acts gehört und was nicht.

Als Ausgangspunkt für eine Analyse bietet sich auch hier – besonders für Quereinsteiger – ein Blick in die Welt der technischen Standards an. Das ISO/IEC 23053:2022 Framework (Framework for Artificial Intelligence [AI] Systems Using Machine Learning) liefert einen umfassenden Überblick darüber, was ein Machine-Learning-System (ML System) ausmacht. Dabei wird deutlich, dass solche Systeme sehr variabel gestaltet sein können. Dieses Framework bietet eine strukturierte Herangehensweise an die Entwicklung und Implementierung von ML-Systemen als Teil von AI Systems und unterstützt dabei, die wesentlichen Komponenten und Prozesse klar zu definieren. Es hilft insbesondere, die Komplexität der verschiedenen Anforderungen und Einsatzmöglichkeiten eines ML-Systems zu verstehen, was besonders für Einsteiger von Vorteil ist:

Elemente eines ML-Systems als Teil eines AI Systems

Die Darstellung beschreibt prägnant die zentralen Elemente eines ML-Systems als Teil eines umfassenderen AI Systems. Im ersten Schritt wird die Aufgabenstellung (Task) definiert, welche das spezifische Problem umreißt, das das System lösen soll. Typische Aufgabenstellungen in diesem Kontext umfassen Regression, Klassifikation, Clustering oder Anomalieerkennung. Diese Problemdefinition bildet die Grundlage für alle weiteren Schritte im Systemdesign.

Im Anschluss daran erfolgt die Entwicklung und das Training des Modells, das auf die jeweilige Aufgabenstellung zugeschnitten ist. In diesem Prozess werden Machine-Learning-Modelle trainiert, getestet und bei Bedarf kontinuierlich mit neuen Daten oder für spezielle Anwendungsfälle nachtrainiert. Hierbei sind Daten von entscheidender Bedeutung, und es wird zwischen verschiedenen Datentypen unterschieden: Trainingsdaten, Validierungsdaten, Testdaten und schließlich Produktionsdaten, die in den verschiedenen Phasen des Modelltrainings und der Modellbereitstellung zum Einsatz kommen.

Um das Modell zu entwickeln und seine Leistung zu optimieren, kommen diverse Werkzeuge und Techniken zur Anwendung. Diese umfassen Verfahren zur Datenvorbereitung, zur Auswahl und Optimierung der Algorithmen sowie zur umfassenden Modellbewertung. Zu den wesentlichen Technikenzählen neuronale Netze, Entscheidungsbäume, der Gradientenabstieg als Optimierungsverfahren und Evaluationsmetriken wie Precision und der F1-Score, die zur Beurteilung der Modellgüte herangezogen werden. Diese vier Kernbereiche – Aufgabenstellung, Modell, Daten und Werkzeuge – sind eng miteinander verzahnt und bedingen sich gegenseitig. Nur durch ihr Zusammenspiel entsteht ein funktionsfähiges ML-System, das in der Lage ist, komplexe Probleme zu lösen und in die größere Architektur eines AI Systems integriert zu werden.

Werden wir praktischer: Der Deutschen liebstes Kind ist das Auto. Daher bietet es sich an, die Dynamik von AI Systemarchitekturen unter dem Gesichtspunkt des „autonomen Fahrens“ genauer zu betrachten. In einem solchen Kontext spielen Machine-Learning-Systeme eine zentrale Rolle, da sie die Grundlage für entscheidende Funktionen wie die Objekterkennung, Fahrwegplanung und Entscheidungsfindung bilden. Die Architektur eines „autonomen“ Fahrzeugs umfasst dabei verschiedene Sensoren (z.B. Kameras, LIDAR, Radar), die kontinuierlich Daten sammeln. Diese Daten werden in Echtzeit verarbeitet, um die Umgebung zu analysieren, Verkehrssituationen zu verstehen und entsprechende Entscheidungen zu treffen. Hierbei greifen verschiedene Komponenten wie Sensordatenverarbeitung, Modelltraining, Echtzeit-Datenbewertung und Entscheidungsalgorithmen ineinander, um sicherzustellen, dass das Fahrzeug sicher und präzise navigiert. Die Anforderungen an die Systemarchitektur sind hochgradig dynamisch und variabel, da das System unter wechselnden Umweltbedingungen und in komplexen Verkehrssituationen zuverlässig funktionieren muss. Ein standardisiertes Framework wie das ISO/IEC 23053:2022 hilft dabei, diese komplexe Architektur zu strukturieren.

Abbildung 1: Entnommen aus Stolte et al., Towards Automated Driving: Unmanned Protective Vehicle for Highway Hard Shoulder Road Works, 2020, mit freundlicher Genehmigung der Autoren.

Die Beschreibung der Autoren wirkt auf den technisch nicht vorgebildeten Leser zunächst schwer zugänglich (Übersetzung):

„Für die Umgebungswahrnehmung wird ein Sensorset eingesetzt, das aus Lang- und Mittelstreckenradar sowie einem Kamerasystem besteht. Die Rohdaten werden in modellbasierte Filterprozesse eingespeist, die parallel die Fahrbahngrenzen und Objekte erkennen und verfolgen. Anschließend werden diese Informationen genutzt, um das Umgebungsmodell zu erstellen und zu aktualisieren, das die Grenzen des befahrbaren Bereichs sowie die Objekte vor dem Schutzfahrzeug enthält. Gleichzeitig zum Umgebungsmodell wird ein Selbstmodell des Systems generiert. Das Selbstmodell ist das Ergebnis der Selbstwahrnehmung, die Sensorwerte zu einer modellbasierten Darstellung des Fahrzeuglenkungssystems kombiniert. Alle verfügbaren Fahrzeugsensoren werden genutzt, um die Selbstrepräsentation zu verbessern. Dazu gehören unter anderem Gyroskope und Beschleunigungsmesser sowie Kraftstoffstand- und Reifendrucksensoren. Aus den Rohdaten der Sensoren abgeleitet, werden die Bewegungsschätzung und die Generierung zusätzlicher Zustandsvariablen durchgeführt. Die Bewegungsschätzung wird zudem zur Erkennung anderer Fahrzeuge verwendet, die von hinten mit dem Schutzfahrzeug kollidieren. Durch die Verbindung der Selbstwahrnehmung mit der Umgebungswahrnehmung ist die Bewegungsschätzung auch relevant für das Verfolgen von Fahrbahngrenzen und Objekten. Basierend auf beiden Wahrnehmungsarten wird die aktuelle Mission erfüllt. Auf der taktischen Ebene bestimmt eine Entscheidungslogik, welche diskrete Aktion ausgeführt werden soll. Neben den durch beide Wahrnehmungsarten gewonnenen Informationen werden Befehle aus der Mensch-Maschine-Schnittstelle im Straßeninstandhaltungsfahrzeug berücksichtigt. Insbesondere betrifft dies Zustandsänderungen, die durch den menschlichen Bediener ausgelöst werden, sowie die Änderung von Parametern der Betriebsmodi, wie Distanzen oder Höchstgeschwindigkeiten. Die diskrete Aktion umfasst einerseits die Bewegung des Fahrzeugs, andererseits die Nutzung von Blinkern, Scheibenwischern etc. Anschließend wird die diskrete Aktion auf die Stabilisierungsebene übertragen, wo eine Zieltrajektorie erzeugt wird. Diese Zieltrajektorie wird dann in den Fahrzeugdynamikregler eingespeist, der schließlich die Aktoren des Fahrzeugs steuert.“

Der zitierte Fachtext beschreibt, vereinfacht gesagt, wie ein Fahrzeug seine Umgebung mithilfe von Radar- und Kamerasensoren wahrnimmt. Die erfassten Daten werden verarbeitet, um ein Modell der Straße und der umliegenden Objekte zu erstellen sowie ein Selbstmodell des Fahrzeugs zu generieren. Auf Basis dieser Modelle trifft das System Entscheidungen und steuert das Fahrzeug, indem es beispielsweise die Fahrbahn verfolgt oder Blinksignale aktiviert.

Lehrreich an der obigen Darstellung ist, dass die Architektur des Systems hierarchisch in verschiedene Ebenen gegliedert ist, die aufeinander aufbauen und unterschiedliche Funktionen erfüllen, um dem übergeordneten Ziel einer autonomen Steuerung zu dienen. Jede Ebene hat dabei eine spezifische Aufgabe und der Informationsfluss verläuft von der untersten Ebene, den Sensoren, bis hin zur Steuerungsebene, wobei die Daten in jeder Stufe weiter verfeinert und verarbeitet werden.

– Die unterste Ebene, der System Context in Relation to the Vehicle, bildet die Grundlage der Architektur und umfasst alle Sensoren, die Daten über die Umgebung und den Zustand des Fahrzeugs erfassen. Zu diesen Sensoren gehören unter anderem Kameras, Radarsysteme und Beschleunigungsmesser, die Rohdaten liefern, die die Basis für alle nachfolgenden Verarbeitungsschritte darstellen.

– Auf dem Operational Level werden diese Sensordaten verarbeitet. Hier kommen Algorithmen zur Filterung und Modellierung zum Einsatz, die die Rohdaten in nutzbare Informationen umwandeln. Dazu gehört die Erkennung und Verfolgung von Fahrspurgrenzen und Objekten sowie die Zustandsschätzung und Bewegungsvorhersage. Diese Ebene schafft eine detaillierte Wahrnehmung der Umgebung und des Fahrzeugzustands, die für die weitere Entscheidungsfindung erforderlich ist.

– Auf dem Tactical Level erfolgt die eigentliche Entscheidungsfindung. Die aus den Sensordaten gewonnenen Modelle werden genutzt, um Kollisionen zu vermeiden und optimale Fahrtrouten zu berechnen. Basierend auf dieser Analyse steuert das System das Fahrzeug, indem es die Fahrzeugdynamik kontrolliert und Entscheidungen über Beschleunigung, Bremsen und Lenkung trifft.

– Das Strategical Level überwacht die übergeordnete Zielerreichung. Hier wird sichergestellt, dass das System seine langfristigen Ziele, wie das Erreichen eines Zielorts, unter Berücksichtigung aller relevanten Umwelteinflüsse und Fahrzeugparameter erfüllt. Diese strategischen Entscheidungen liefern die Richtlinien, denen das System folgen muss, und leiten die taktischen Entscheidungen an.

– Schließlich gibt es das Communication Level, das den Informationsaustausch sicherstellt. Dies geschieht einerseits über die Mensch-Maschine-Interaktion (HMI), bei der das System Rückmeldungen und Warnungen an den Fahrer weitergibt. Andererseits ermöglicht die Vehicle-to-Vehicle-Kommunikation (V2V) den Austausch von Informationen zwischen Fahrzeugen, um eine koordinierte und sichere Fortbewegung im Verkehr zu gewährleisten.

Der Zusammenhang der Ebenen folgt einer logischen Reihenfolge: Die Sensordaten werden auf der operativen Ebene gefiltert und modelliert, um auf der taktischen Ebene für die Entscheidungsfindung genutzt zu werden. Die strategische Ebene gibt übergeordnete Richtlinien vor, während die Kommunikationsebene sowohl den internen als auch externen Informationsaustausch sicherstellt. Der Informationsfluss verläuft dabei klar strukturiert von den Sensoren über die verschiedenen Verarbeitungsschritte, bis die Entscheidungen schließlich in physische Steuerungsaktionen umgesetzt werden, die das Fahrzeug autonom und sicher steuern.

Die Strukturierung in Ebenen ermöglicht eine klare Trennung der verschiedenen Funktionen eines AI Systems, was deren Entwicklung, Wartung und Skalierung vereinfacht. Durch diese modulare Architektur können einzelne Komponenten unabhängig voneinander verbessert oder angepasst werden, ohne das gesamte System zu beeinträchtigen. Zudem sorgt sie für eine logische Abfolge der Verarbeitungsschritte – von der Datenerfassung über die Entscheidungsfindung bis hin zur Kommunikation –, was die Effizienz und Flexibilität des Systems steigert. Diese Struktur eignet sich generell für eine Vielzahl von AI Use Cases, nicht nur im Bereich der Assistenzsysteme und Robotik, da sie sowohl Echtzeit-Entscheidungen als auch langfristige Zielverfolgung unterstützt.

Damit ist die Funktionsweise des Systems etwa auf Abiturniveau erläutert, es bleibt jedoch leider immer noch unklar, ob und falls ja, wie viele AI Systems in der obigen Abbildung dargestellt sind. Dies erfordert nicht nur die Durchdringung der technischen Dokumentation, sondern auch eine intensive Kommunikation mit allen Projektbeteiligten, insbesondere mit denjenigen, die für die Gesamtarchitektur des Systems verantwortlich sind. Ohne diese umfassende Zusammenarbeit ist es schwierig, ein klares Bild der Integration und Anzahl der AI Systems zu erhalten und darauf basierend die Erfüllung der gesetzlichen Pflichtaufgaben anzugehen.

Eine Systemdarstellung auf Abiturniveau ist in der Praxis zudem der Ausnahmefall, wesentlich häufiger werden Organisationen mit werblichen Aussagen von Dienstleistern konfrontiert, die es sodann auf ihren (Wahrheits-) Gehalt hin zu validieren gilt. Beispielhaft umformuliert, könnte die Werbung für obige Systemlandschaft wie folgt lauten:

Erleben Sie intelligenten Fahrkomfort der nächsten Generation! Unser Fahrzeug nutzt hochmoderne Radar- und Kamerasensoren, um seine Umgebung präzise zu erfassen. Durch die fortschrittliche Verarbeitung dieser Daten erstellt es ein detailliertes Straßenmodell und erkennt sofort alle umliegenden Objekte. Auf Basis dieser Informationen trifft unser innovatives System kluge Entscheidungen und steuert Ihr Fahrzeug sicher und zuverlässig – sei es durch das sanfte Folgen der Fahrspur oder das automatische Aktivieren der Blinker.Mit unserer Technologie genießen Sie maximale Sicherheit, Komfort und eine unvergleichliche Fahrerfahrung. Steigen Sie ein und entdecken Sie die Zukunft des autonomen Fahrens!

An dieser Stelle sollte klar werden, dass interdisziplinäre Teams und kritische Nachfragen im Detail bereits dann gefordert sind, wenn es um die Definition des Untersuchungsgegenstandes geht, also die Bestimmung, welche Elemente zu einem AI System gehören und welche für die rechtliche Bewertung gegebenenfalls außer Acht gelassen werden können. Das ist nicht trivial, und unsere Erfahrung aus den letzten Monaten der Analyse komplexer Systeme im Hinblick auf die Anwendbarkeit des AI Acts zeigt, dass an dieser Stelle äußerst sorgfältig und ergebnisoffen gearbeitet werden muss. Vergleichbare Anforderungen stellen sich bei der Frage, was die etwas kryptische Formulierung „im Zusammenhang mit Produkten“ bedeuten soll, die in Art. 2.2 im Hinblick auf den Anwendungsbereich des AI Acts verwendet wird. Ohne interdisziplinäre fachliche Expertise sind derartige Fragen schwer mit hinreichender Sicherheit zu beantworten. Für rechtsberatende Berufe erfolgt an dieser Stelle der Hinweis, dass auch aus haftungsrechtlichen Gründen von einer vorschnellen eigenständigen Festlegung des Untersuchungsgegenstandes Abstand genommen werden sollte.

(4)Lösungsansätze aus dem Bereich AI Safety, Computation und UML

Um auf der Ebene der technischen Details den Boden für eine belastbare Analyse zu bereiten, bietet sich ein Blick in die in Form und Inhalt beeindruckende ISO/DPAS 8800 („Road vehicles – Safety and artificial intelligence“) zu werfen, die sich, wie der Name „Draft Publicly Available Specification (DPAS)“ nahelegt, derzeit noch im Stadium des finalen Entwurfs befindet, über den in Kürze votiert wird. Auf rund 180 Seiten legt die ISO ein Standardwerk zu AI und Safety vor, das als Musterbeispiel für andere Branchen dienen kann.

Dem Thema „AI System“ widmet sich das Dokument in auch für interessierte Laien lehrreicher und strukturierter Weise, wobei eine gewisse Kenntnis informationstechnischer Grundlagen nicht schaden kann, die wir bei den Leserinnen und Lesern, die es bis zu diesem Punkt unserer Ausführungen geschafft haben, höflich unterstellen.

Erhellend ist bereits ein Blick auf die initiale Darstellung und Gliederung eines typischen AI Systems, das aus zumindest einem AI Model sowie weiteren AI Elements besteht, womit die grundlegenden Komponenten eines AI Systems bereits eingeführt werden. In der nachfolgenden Abbildung befindet sich das AI System im grau unterlegten Bereich. Die dunkel hinterlegten Komponenten sind als AI components definiert (ISO/DPAS 8800, 6.4 Example Architecture for an AI system):

Das abgebildete Beispiel eines AI Systems erhält seine Input-Daten von der Quelle, führt seine Aufgaben basierend auf den Eingaben und den Control Signals aus und stellt dann seine Output-Daten dem Verbraucher zur Verfügung. Das AI System selbst besteht aus den drei AI Components (1) AI Pre-Processing, (2) AI Model und (3) AI Post-Processing. Das AI Post-Processing nutzt hierbei die Daten aus den vorherigen Prozessschritten (d.h. AI Pre-Processing und AI Model) in Kombination mit den ursprünglichen Input-Daten zu Monitoring-Zwecken.

Das übergeordnete Control Element ist in vielen Architekturen nicht Teil des eigentlichen AI Systems und wird in der Abbildung daher als externes Element betrachtet, da es eine separate Rolle erfüllt. Während das AI System auf Datenverarbeitung, Entscheidungsfindung und Vorhersagen fokussiert ist, übernimmt das Control Element die Steuerung und Koordination des Gesamtprozesses. Es regelt den Datenfluss, aktiviert das AI System bei Bedarf und integriert dessen Ergebnisse in das Gesamtsystem. Diese funktionale Trennung ermöglicht eine flexible Anpassung des AI Systems und gewährleistet, dass es in Echtzeit gesteuert und sicher betrieben wird. Das Control Element ist somit für die Systemlogik und die Überwachung verantwortlich, während das AI System die eigentlichen datengetriebenen Aufgaben übernimmt. Auch wenn das Control Element technisch nicht zum AI System gerechnet werden muss, kann es dennoch sein, dass es von der Definition des AI Acts mit umfasst ist. Hier müssen die Umstände des Einzelfalls sowie die konkreten Funktionsweisen des jeweiligen Control Elements oder anderer Infrastrukturelemente genau untersucht werden, um zu einem rechtlich fundierten und nachhaltigen Ergebnis zu gelangen. Dabei ist es wichtig, sowohl die technische Interaktion zwischen dem jeweiligen Element und anderen Infrastrukturelementen als auch die Schutzrichtung des AI Acts zu berücksichtigen. Je nach Anwendungsbereich und Systemarchitektur kann z.B. auch ein Control Element unterschiedliche Aufgaben übernehmen, was die Bewertung seiner Relevanz und rechtlichen Implikationen im Gesamtsystem beeinflusst. Hilfreich zur Strukturierung technischer Details ist der Ansatz der ISO DPAS 8800 dahingehend, dass sie eine Logik bietet, anhand derer Systemlandschaften bewertet werden können.

Das nachfolgende Chart beschreibt den Aufbau und die Logik eines AI-Systems basierend auf dem Ansatz der ISO DPAS 8800. Ein AI System besteht nur, wenn es eine konkrete Aufgabe, den sogenannten AI-Task, erfüllt. Das AI System ist ein technisches Element, das ein oder mehrere AI Models nutzt, um diese Aufgabe zu bewältigen. Dabei kann ein AI System verschiedene AI Components enthalten, die gemäß der ISO/IEC 22989:2022 als funktionale Bausteine definiert sind. Diese Komponenten umfassen nicht nur die AI-Modelle, die für die eigentliche Verarbeitung der Daten verantwortlich sind, sondern auch Vorverarbeitungs- und Nachverarbeitungskomponenten. Die Vorverarbeitungs-Komponenten bereiten die Daten für das Modell auf, während die Nachverarbeitungskomponenten die Ergebnisse weiterverarbeiten oder für spezifische Zwecke aufbereiten.

Die Struktur des folgenden Charts zeigt somit eine klare Trennung der einzelnen Funktionselemente eines AI-Systems und verdeutlicht, wie diese zusammenwirken, um einen bestimmten AI-Task zu erfüllen:

Diese Strukturierung erscheint auch für die rechtsberatenden Berufe im ersten Schritt sinnvoll, obwohl sie nur einen kleinen Ausschnitt dessen darstellt, was bereits in technischen Standards festgelegt ist. In Bezug auf AI spezifische Hardware empfiehlt sich ein Blick in den neuesten Technical Report ISO/IEC TR 17903:2024 (Information technology – Artificial intelligence – Overview of machine learning computing devices), der auf der ISO/IEC 19505-1:2012 (Information technology – Object Management Group Unified Modeling Language (OMG UML) – Part 1: Infrastructure) basiert. Dieser Bericht ermöglicht eine Schritt-für-Schritt-Darstellung von AI Systems, die klar definiert ist und den Einstieg in die technische Analyse der Infrastruktur erleichtert. Die Object Management Group haben wir im Praxisbeispiel der Microservices bereits als Urheberin des Business Process Model and Notation (BPMN) kennengelernt und hier begegnet uns der gleiche Ansatz, eine standardisierte Sprache für alle Stakeholder zu finden, wieder. Nur eben für Hard- und Software.

Das nachfolgende Chart zeigt die im ISO/IEC TR 17903:2024 in Annex A vorgeschlagene Hierarchie der Komponenten von AI Systems, wobei die jeweiligen Begriffe (device, entity, unit etc.) vollständig definiert sind, zum großen Teil seit Jahren:

–ML computing device: computing device that can be used for accelerating machine learning computing)

–Al computing device: computing device that can be used for accelerating some or all of artificial intelligence computing)

–Computing device: functional unit that can perform substantial computations, including numerous arithmetic operations and logic operations with or without human intervention

–Functional unit: entity of hardware or software, or both, capable of accomplishing a specific purpose

–Unit: lowest level of hardware assembly for which acceptance and qualification tests are required.

–Software: all or part of the programs, procedures, rules, and associated documentation of an information processing system

–Entity: any concrete or abstract thing that exists, did exist, or might exist, including associations among these things

–Hardware: all or part of the physical components of an information processing system

–Component: entity with discrete structure, such as an assembly or software module, within a system considered at a particular level of analysis

Kombiniert man die im obigen Praxisbeispiel Microservices eingeführte ISO/IEC 19510:2013 – die detaillierte und präzise Norm zur Modellierung von Geschäftsprozessen – mit der ebenso umfassenden ISO/IEC 19505-1:2012, welche die Infrastruktur in der eleganten Strenge der Unified Modeling Language beschreibt, so formt sich in den Händen einer fachkundigen Anwendergruppe ein Werkzeug von geradezu verblüffender Leistungsfähigkeit. Denn es ist mit diesem hybriden Ansatz möglich, die vielfältigen rechtlichen Anforderungen an Struktur, Erklärbarkeit und Transparenz von AI Systems, unabhängig von ihrer gesetzlichen Herkunft nicht nur irgendwie, sondern nachvollziehbar und effizient zu erfüllen.

Fazit: Um eine fundierte rechtliche Bewertung eines AI Systems, seiner Grenzen, Interdependenzen und Überschneidungen vorzunehmen, bedarf es einer detaillierten technischen Analyse auf höchstem Niveau. Diese Art der Untersuchung geht weit über die bisherigen, eher oberflächlichen Ansätze der Rechtsberatung hinaus, wie sie etwa im Datenschutzrecht üblich sind, wo oftmals lediglich Datenflüsse betrachtet werden. AI Systems jedoch zeichnen sich durch eine hochkomplexe technische Struktur aus, die es erfordert, sämtliche relevanten Komponenten und deren Zusammenspiel zu berücksichtigen.