Teil 7: Der EU AI Act - und was er für die meisten Unternehmen bedeutet

In der Literatur wurde teilweise vertreten, dass der AIA jedes AIS reguliere, welches Personen in der EU betrifft, direkt oder indirekt. Dies trifft nach der hier vertretenen Ansicht nicht zu. Es ist zwar richtig, dass der AIA auf alle betroffenen Personen ("affected persons") in der EU ausdrücklich Anwendung findet. Das bedeutet jedoch nicht automatisch, dass er auch auf alle Provider, Deployer und weitere Personen Anwendung findet; ihr persönlicher und örtlicher Geltungsbereich ist vom AIA separat definiert. Wäre automatisch jedes AIS (mitsamt seinen Providern, Deployern und weiteren beteiligten Stellen) im Geltungsbereich des AIA, wären die vorstehend diskutierten differenzierten Regeln gar nicht nötig gewesen. Die Aufnahme der betroffenen Personen im Geltungsbereich des AIA ist vielmehr nötig, damit sie ihre (wenigen) Rechte unter dem AIA geltend machen können.

Nur für HRAIS und nur rudimentär geregelt sind die Fälle, in denen ein AIS von mehreren Stellen stammt bzw. wenn das AIS eines Providers ein AIS eines anderen Providers enthält. In diesen Fällen soll mit dem Sublieferanten ein Vertrag abgeschlossen werden, der seinem Kunden als Provider die Einhaltung des AIA ermöglicht; der Sublieferant wird vermutlich nach Massgabe seiner eigenen Markthandlungen selbstständig erfasst sein. Wer wiederum ein AIS in ein anderes Produkt verbaut, welches er dann unter eigenem Namen im EU-Markt anbietet oder in der EU in Verkehr bringt, gilt unter dem AIA als Produkthersteller ("Product Manufacturer") und – falls es sich um ein HRAIS handelt (z.B. weil es eine Sicherheitsfunktion eines regulierten Produkts übernimmt) – als dessen Provider im Sinne des AIA. Mit anderen Worten: Der Provider kann nicht nur derjenige sein, der ein AIS (i) als erstes entwickelt, sondern auch (ii) derjenige, der es weiterentwickelt und in ein übergeordnetes AIS oder sonstiges Produkt verbaut sowie (iii) wer sich gemäss (i) oder (ii) darstellt.

Was passiert, wenn jemand ein AIS (mit)entwickelt, es aber nicht unter seinem Namen oder seiner Marke, sondern derjenigen eines anderen in der EU in Verkehr bringt oder in Betrieb nimmt, ist ebenfalls nicht ganz klar. Ein Provider kann diese Stelle formal gesehen nicht sein, weil ein zwingendes Kriterium der Legaldefinition nicht erfüllt ist. Der AIA kennt zwar gewisse Formen der "gemeinsamen" Verantwortlichkeit, sie geht aber nicht so weit wie im Datenschutz, wo es auch möglich ist, dass zwei Stellen für eine Verarbeitungsaktivität gemeinsam verantwortlich sein können, obwohl sie arbeitsteilig zusammenwirken. Etwas ähnliches müsste an sich auch hier gelten, nur fehlt soweit ersichtlich die Rechtsgrundlage dafür; es ist nur das Zusammenwirken mehrerer Stellen geregelt, bei denen jeder auch für sich alleine als Provider gilt. Über Hilfskonstruktionen kann der Fall jedoch gelöst werden:

• Wer unbefugt den Namen oder die Marke eines anderen auf dem von ihm entwickelten AIS angibt und sich damit im Grunde anmasst, wird in Bezug auf die Verantwortlichkeit als Provider dementsprechend wohl so behandelt werden, als wäre es auch sein eigener Name oder seine eigene Marke. Er müsste als Provider betrachtet werden – schon nur aufgrund des Prinzips von Treu und Glauben.
• Wer hingegen an einem AIS (mit)entwickelt, jedoch befugt den Namen oder die Marke eines anderen anbringt, kann unseres Erachtens mit guten Gründen vertreten, dass er lediglich für den anderen gehandelt hat, der als Provider gilt; die Nennung seines Namens oder das Anbringen seiner Marke – oder die Erlaubnis an einen Dritten, dies zu tun – ist gewissermassen die Erklärung, die Verantwortung des Providers für das AIS zu übernehmen.

4. Geltungsbereich: Wer gilt als Deployer?

Anwender von AIS werden unter dem AIA als Deployer erfasst und mit einigen wenigen Pflichten belegt (dazu unten). Deployer ist, wer ein AIS in eigener Verantwortung ("under its authority") einsetzt. Ausgenommen sind jene Personen, die ein AIS (nur) für persönliche, nicht berufliche Aktivitäten einsetzen ("personal non-professional activity", wobei auch hier die Gesetzesredaktion unsorgfältig erfolgte – die Ausnahme existiert gleich auf zwei Ebenen und ist leicht verschieden formuliert).

Das Kriterium "under its authority" grenzt den blossen Genuss eines AIS bzw. dessen Output vom Einsatz eines AIS als eigenes Werkzeug ab. Hier wird eine gewisse Kontrolle erforderlich sein, damit das Kriterium erfüllt ist, denn Kontrolle führt zur Verantwortung. Wenn ein Benutzer auf einer Website einen Kundendienst-Chatbot benutzt, dann hat er diese Kontrolle nicht; jedenfalls ist dies nicht so vorgesehen. Er kann Fragen stellen und das Unternehmen steuert, wie der Chatbot sie beantwortet. Anders wäre es erst, wenn es dem Benutzer gelingt, den Chatbot zu "hacken" und zu nicht geplanten Äusserungen zu bringen. Stellt ein Unternehmen hingegen seinen Kunden im Rahmen einer Dienstleistung eine KI-Funktionalität zur Verfügung, die diese bestimmungsgemäss hinsichtlich ihres Einsatzes in gewissen Grenzen kontrollieren sollen und können, dann dürfte das Kriterium "under its authority" wohl erfüllt sein. Bietet eine Firma wie OpenAI ihren Kunden den Chatbot "ChatGPT" an, so unterscheidet sich dieser vom erwähnten Kundendienst-Chatbot dadurch, dass es der Kunde von OpenAI ist, der dem Chatbot die Anweisungen erteilen soll, worüber er sprechen soll – und nicht mehr das Unternehmen, das ihn betreibt. Wo genau die Grenze verläuft (z.B. bei themenspezifischen Chatbots), ist freilich auch hier noch nicht klar. Es bietet sich an, hier auf die Praxis zum vergleichbaren Konzept des "Verantwortlichen" bzw. "Controllers" im Datenschutz zurückzugreifen, das aus der Kontrolle über den Zweck und die (wesentlichen) sonstigen Parameter einer Datenbearbeitungsaktivität auch die diesbezügliche (alleinige oder gemeinsame) Verantwortung ableitet.

In den räumlichen Geltungsbereich fallen all jene Deployer, die entweder in der EU sind (ob mit einer Niederlassung oder weil sie sich als natürliche Personen dort aufhalten) oder, falls nicht, diejenigen, deren  Output der von ihnen betriebenen AIS in der EU "verwendet" wird. Letztere Regel soll gemäss den Erwägungen die Umgehung des AIA durch Anbieter in Drittländern (wie der Schweiz oder den USA) verhindern, die Daten in der EU sammeln oder von dort erhalten, sie mit AIS im EU-Ausland bearbeiten und das Ergebnis zur Nutzung in die EU zurücksenden, ohne, dass das AIS in der EU auf den Markt gebracht oder dort zum Einsatz gebracht wird. Das Beispiel wirft selbst Fragen auf, da ein Unternehmen mit Sitz in der EU, welches ein Unternehmen im EU-Ausland bittet, in seinem Auftrag Daten mit einem AIS zu bearbeiten, wohl trotzdem als dessen Deployer gelten wird, so wie im Datenschutz die Handlungen des Auftragsbearbeiters dem Verantwortlichen zugerechnet werden. Viel relevanter dürfte die Ausnahmeregelung für jene Unternehmen sein, die sich im EU-Ausland befinden (z.B. in der Schweiz oder in den USA) und AIS für sich selbst einsetzen. So oder so soll die Regelung vom Einsatz des AIS betroffene natürliche Personen auf dem Gebiet der EU schützen. Gemäss den Erwägungen ist es erforderlich, dass die Verwendung des KI-Outputs in der EU beabsichtigt ("intended to be used in the Union") und nicht bloss zufällig war.

Was genau als "Verwendung" von KI-Output in der EU gilt, wird nicht näher ausgeführt. Ob es hierzu bereits genügt, dass im EU-Ausland erzeugter KI-Output eine Wirkung auf Personen in der EU hat, ist denkbar, aber unseres Erachtens eher fraglich. Einige Beispiele:

• Wer im EU-Ausland auf seiner Website KI-generierte Inhalte publiziert und diese (auch) auf ein Publikum in der EU ausrichtet, dürfte erfasst sein. Dasselbe gilt für KI-generierte Inhalte auf Werbeunterlagen, die auch Kunden in der EU ansprechen sollen.
• Erfasst sein dürfte ebenso das Unternehmen, das seinen Kunden im EU-Raum durch ein AIS generierte Texte sendet.
• Findet ein von einem AIS im EU-Ausland erstelltes Dokument zufällig seinen Weg auch in die EU, dann ist der Deployer des AIS noch nicht erfasst.
• Nicht erfasst sein dürfte hingegen ein zwar von einem Computer, aber weder direkt noch indirekt von einer KI generierter Inhalt.
• Die Möglichkeit, dass KI-Output auf dem Weg des datenschutzrechtlichen Auskunftsrechts in die EU gelangen kann, genügt unseres Erachtens ebenfalls nicht zur Anknüpfung; dazu kann es zwar kommen, es wäre aber in der Regel keine bestimmungsgemässe Verwendung.
• Der Einsatz eines HRAIS oder die Durchführung einer nach AIA verbotenen Praktik durch einen Schweizer Arbeitgeber in Bezug auf seine Schweizer Mitarbeitenden dürfte selbst dann nicht dem AIA unterliegen, wenn er Mitarbeitende aus der EU beschäftigt, den Output der KI aber nur am Sitz des Unternehmens in der Schweiz verwendet.
• Setzt der Arbeitgeber dafür jedoch eine Cloud bzw. einen Cloud-Provider in der EU ein, sieht die Rechtslage allenfalls anders aus: Ob die Auslagerung des Betriebs eines AIS an einen Provider mit Sitz oder Rechenzentrum in der EU bedeutet, dass auch der Output der AIS als dort "verwendet" gilt, ist noch unklar. Wir glauben, dass dies nicht der Fall ist bzw. sein darf: Mit Blick auf den primären Schutzzweck, nämlich den Schutz der Gesundheit, der Sicherheit und der Grundrechte von natürlichen Personen in der EU, kann die Auslagerung des IT-Betriebs in die EU für sich noch nicht genügen, weil alleine dadurch diese in keiner Weise tangiert sind. Es gibt keinen Bezug zwischen dem Ort der Bearbeitung bzw. des Providers und der betroffenen Personen. Das Kriterium der Verwendung des Outputs in der EU soll seinem Zweck nach jene Fälle abdecken, in denen der Output zwar ausserhalb der EU erzeugt wird, in der EU aber auf betroffene Personen "trifft". Das ist hier nicht der Fall. Eine Niederlassung wird mit der blossen Beauftragung eines Dienstleisters in der EU erst recht nicht begründet (so auch nicht unter der DSGVO). In den sekundären Schutzzielen des AIA werden auch der Schutz der Demokratie, des Rechtssystems und der Umwelt genannt, aber auch diese rechtfertigen nicht wirklich die Erweiterung des Geltungsbereichs; sie käme noch am ehesten bezüglich dem Schutzziel des Umweltschutzes im Hinblick auf den Energieverbrauch der Rechenzentren für KI in Frage, aber diesbezüglich enthält der AIA selbst keine wirklich relevanten Regeln. Zu beachten ist immerhin, dass der Provider, der im Rahmen seiner Cloud-Dienste auch KI-Funktionalitäten anbietet, selbst dem AIA unterliegen kann, auch wenn sein Kunde als Deployer dies nicht tut. Diesen Fall haben wir im Bereich der DSGVO ebenfalls bei Providern mit Sitz im EWR; sie unterliegen der DSGVO, ihre Schweizer Kunden aber möglicherweise nicht.

Ungeachtet der noch bestehenden Unklarheiten führt die Regelung zur Verwendung von KI-Output in der EU zu einer erheblichen extraterritorialen Wirkung des AIA. Dies bedeutet, dass sich auch viele Schweizer Unternehmen mit den vom AIA den Deployern auferlegten Kennzeichnungspflichten befassen sollten. In Bezug auf eine etwaige Rolle als Provider können sie sich hingegen wie erwähnt jedenfalls einstellen auf den Standpunkt stellen, dass sie nicht erfasst sind, wenn sie das AIS nicht in der EU in Verkehr bringen oder dort in Betrieb nehmen.

5. Weitere Abgrenzungsfragen für Unternehmen

Weitere Abgrenzungsfragen werfen die Rollendefinitionen des AIA insbesondere dort auf, wo Unternehmen AIS selbst weiterentwickeln, im Verkehr mit Dritten einsetzen oder innerhalb einer Unternehmensgruppe weitergeben.

Unklar ist, was als "Entwickeln" eines AIS ("develop") gilt. Liegt ein solches beispielsweise bereits vor, wenn ein Unternehmen ein kommerzielles KI-Produkt für seine eigene Anwendung parametrisiert (z.B. mit entsprechenden Systemprompts ausstattet), ein Fine Tuning des Models vornimmt oder in eine weitere Anwendung integriert (z.B. Einbau einer im Markt angebotenen Chatbot-Software in die eigene Website oder App)? Wäre dem so, würden viele Anwender selbst zum Provider werden, da die Legaldefinition des Providers auch denjenigen erfasst, der AIS zum Eigengebrauch ("for own use") zum Einsatz bringt, falls dieser Einsatz bestimmungsgemäss in der EU und unter eigenem Namen erfolgt. Ein solch weites Verständnis ist nach der hier vertretenen Auffassung zwar abzulehnen, aber es ist zu befürchten, dass die Aufsichtsbehörden hier ein breites Verständnis an den Tag legen werden und mindestens jene Handlungen als Entwickeln betrachten, welche über Prompting, Parametrisierung und das Liefern von sonstigem Input hinausgehen. Demnach wäre ein Fine Tuning des Modells eines AIS erfasst (weil gewissermassen das Trainingswissen und damit die Programmierung verändert wird), die Verwendung von "Retrieval Augmented Generation" (RAG) hingegen nicht (weil hier lediglich der Input verändert wird). Denkbar wäre auch ein Ansatz, der sich an der Gefahr orientiert, der vom Beitrag im Einzelfall ausgeht, was allerdings zu einer erheblichen Rechtsunsicherheit führen würde, weil dieselbe Handlung je nach Systemzweck zu einer unterschiedlichen Qualifikation desjenigen führen würde, der sie vornimmt. Dabei ist zu berücksichtigen, dass auch der Deployer bis zu einem gewissen Mass in der Pflicht bleibt.

Bis zur Klärung der Rechtslage ist es Unternehmen als Vorsichtsmassnahme zu empfehlen, beim Einsatz solcher AIS auch gegen aussen den Namen des Technologielieferanten anzugeben (z.B. "Powered by …" bei einem Chatbot, der auf der Website den eigenen Kunden als Service angeboten wird). So kann vertreten werden, dass das AIS – selbst wenn die Implementierung oder Optimierung als Entwicklung gelten sollte – nicht als unter eigenem Namen oder den eigenen Handelsmarken bzw. Markenzeichen zum Einsatz gebracht gilt ("under its own name or trademark"). Dies sollte jedoch mit Erlaubnis des Technologielieferanten erfolgen, da er bereit sein muss, die Rolle des Providers und die damit verbundene Verantwortlichkeit zu übernehmen (d.h. die Anpassungen ihm alleine zugerechnet werden). Eine weitere mögliche Vorsichtsmassnahme ist die Einschränkung der erlaubten Verwendung eines AIS auf Personen ausserhalb der EU, weil die Legaldefinition des Providers dann mutmasslich nicht mehr greift.

Unklar ist auch, wie die Weitergabe von KI-Services oder KI-Technologie innerhalb einer Gruppe von Unternehmen zu werten ist. Es sind hier verschiedene heikle Szenarien denkbar. Ein Szenario ist der Fall, in welchem die Gruppengesellschaft X ausserhalb der EU ein AIS vom Anbieter Y ausserhalb der EU einkauft und es dann den anderen Gruppengesellschaften auch in der EU zur Verfügung stellt. Ist das AIS bis dahin noch nicht auf dem EU-Markt eingeführt oder in der EU in Einsatz gebracht worden, kann X selbst ohne es weiterentwickelt zu haben zu dessen Händler ("Distributor") oder allenfalls sogar Einführer ("Importer") werden. Dies würde eine Reihe von Sonderpflichten mit sich bringen. Während X die Qualifikation als Einführer (und Provider) wohl verhindern kann, indem nur AIS in die EU weitergegeben werden, die dort schon auf dem Markt sind, schützt dies X nicht vor der Qualifikation als Händler. Hier kann immerhin vertreten werden, dass der Begriff voraussetzt, dass das Unternehmen Teil der in der Definition erwähnten Lieferkette ("supply chain") von Y ist und dass diese einen konzerninternen Vertrieb eines AIS an Gruppengesellschaften von X vernünftigerweise nicht mehr umfasst. Sie machen das AIS auch nicht öffentlich zugänglich, wie dies ein Händler tut, sondern nur konzernintern.

Zur Frage, ob ein Schweizer Unternehmen schon deshalb unter den AIA fallen kann, weil es sein KIS in einem Rechenzentrum in der EU betreiben lässt oder den Betrieb zwar in der Schweiz vornimmt, das Rechenzentrum aber von einem Cloud-Anbieter in der EU bereitgestellt wird, haben wir schon vorne im Zusammenhang mit der Verwendung des Outputs in der EU erörtert (Rn. 32). Es kann sich in diesen Fällen aber auch die Frage stellen, ob eine Auslagerung in eine EU-Cloud nicht als "Inbetriebnahme" des betreffenden KIS in der EU zu gelten hat, weil es hierzu genügt, dass das KIS zum erstmaligen Eigengebrauch in der EU bereitgestellt wird. Hat das Unternehmen das KIS selbst entwickeln (oder entwickeln lassen) und bringt es das KIS unter eigenem Namen zum Einsatz, wären in diesem Fall die beiden weiteren Voraussetzungen erfüllt und es läuft Gefahr, unter dem AIA als Provider des KIS zu gelten, selbst wenn es dieses nur für sich nutzt und seinen Sitz in der Schweiz hat. Um dieses Risiko zu reduzieren, sollten Schweizer Unternehmen KIS somit vorzugsweise auf Rechenzentren ausserhalb der EU betreiben, selbst wenn die Betreibergesellschaft (z.B. der Cloud-Provider) seinen Sitz selbst in der EU hat. Und noch etwas sollten Schweizer Unternehmen bedenken: Mitarbeitende, die sich beim Einsatz von AIS in der EU aufhalten und so zur Anwendbarkeit des AIA führen können (z.B. im Home-Office oder auf Reisen).

Im Unternehmenskontext kann sich auch die Frage stellen, ab welchem Moment ein Unternehmen, das ein Produkt mit einer KI-gestützten Funktionalität seinen Kunden zur Verfügung stellt, selbst als Provider und die Kunden als dessen Deployer gelten. Die Hürden sind dabei nicht sehr hoch: Nehmen wir als Beispiel eine Bank ausserhalb der EU, die ihren EU-Geschäftskunden in ihrem Online-Banking und -Trading eine KI-gestützte Analyse ihrer Portfolios anbietet; dies ist Teil der kommerziellen Dienstleistung der Bank. Die Bank wird, wenn sie diese Funktionalität selbst entwickelt hat oder entwickeln lassen hat, aufgrund ihres eigenen Einsatzes bereits als Provider gelten, zumal sie es (jedenfalls nach einem weiten Begriffsverständnis) in der EU zum Einsatz bringt (siehe dazu aber Rz. 41) und dies unter ihrem eigenen Namen geschieht.

Die Kunden, die die KI-Analyse-Funktion einsetzen, können ihrerseits zu Deployern werden und dabei dem AIA unterstellt sein, selbst wenn sich die Bank nicht darum kümmern sollte. Hierbei sind zwei Voraussetzungen zu beachten: Die Kunden müssen sich erstens in der EU befinden oder der Output der KI-Analyse in der EU verwendet werden. Sie müssen die KI-Funktion zweitens in eigener Verantwortung ("under its authority") einsetzen (siehe dazu oben). Erhält der Bankkunde somit die nötige Kontrolle über die KI-Funktion, wird er (der als Geschäftskunde nicht unter die Ausnahme für persönliche, nicht berufliche Nutzungen fällt) aus eigener Verantwortung sicherstellen müssen und wollen, dass es sich um keine verbotene KI-Praktik handelt und allenfalls anwendbare Deployer-Pflichten eingehalten werden. Die Schwierigkeit in der Praxis kann dabei sein, dass es gerade bei Anbietern aus dem EU-Ausland für EU-Deployer möglicherweise gar nicht klar ist, wo und wann in den genutzten Produkten und Dienstleistungen AIS zum Einsatz kommen und was genau sie tun.

In diesem Zusammenhang kann sich auch die Frage stellen, ob ein Provider sachlogisch nur dann vorkommen kann, wenn es auch einen Deployer gibt, dem der Provider das AIS zur Verfügung stellt. Die Antwort hierauf dürfte ein "Nein" sein. Ansonsten wären alle Anbieter, die KI-Dienste nur an Verbraucherinnen und Verbraucher in der EU anbieten, nicht vom AIA erfasst, weil solche Nutzerinnen und Nutzer kraft einer Ausnahmeregelung nicht als Deployer gelten. Die Definition des Providers setzt keinen Deployer voraus: Es genügt zum einen die Bereitstellung in der EU für den Eigengebrauch in der EU ("for own use in the Union"); um das zu erfüllen, reicht es womöglich bereits aus, dass der Anbieter die Nutzerinnen und Nutzer in der EU anspricht und sie den Dienst dort nutzen lassen, da es weiterhin der Dienst des Anbieters und somit "seine" Verwendung des AIS ist (die Schlussfolgerung, dass dies bereits ein Eigengebrauch in der EU darstellt, ist unseres Erachtens zwar nicht zwingend, dürfte aber im Hinblick auf den Schutzzweck des AIA mitunter vertreten werden; dies würde dazu führen, dass der bloss via Website einem EU-Publikum angebotene Chatbot bereits zum Eigengebrauch in der EU führen würde, d.h. ein Fernzugriff aus der EU als Gebrauch vor Ort qualifiziert; dem könnte entgegengehalten werden, dass der Gesetzgeber gerade nicht davon ausging, dass dies zur Erfassung genügt, weshalb er die Verwendung von KIS-Output in der EU als separates Anknüpfungskriterium definierte, welches hier jedenfalls beim Deployer greifen würde). Zum anderen lässt es das alternative Kriterium zur Provider-Qualifikation des Inverkehrbringens ("placing on the market") genügen, dass ein AIS "zur Verwendung auf dem Unionsmarkt im Rahmen einer Geschäftstätigkeit" ("for … use on the Union market in the course of a commercial activity") geliefert worden ist. Dieser Fall liegt hier wohl vor. Abschliessend geklärt ist aber auch diese Frage nicht.

6. Verbotene KI-Anwendungen

Acht spezifische "KI-Praktiken" sind unter dem AIA ganz verboten. Vom Verbot erfasst sind in den meisten Fällen, sowohl jene, die betreffende AIS in der EU auf den Markt oder erstmals in der EU zum Einsatz bringen als auch jene, die ein AIS so verwenden wollen (was, wie gezeigt, auch jene umfasst, die sie im Ausland nutzen, soweit der Output der AIS bestimmungsgemäss auch in der EU verwendet wird).

Die Liste der verbotenen KI-Praktiken ist zwar sehr spezifisch, aber trotzdem nicht überall trennscharf abgegrenzt formuliert:

1. Verwendung von unterschwelligen, absichtlich manipulativen oder täuschenden Techniken, die darauf abzielen oder bewirken, dass das Verhalten wesentlich verzerrt wird oder die Fähigkeit der Person, eine informierte Entscheidung zu treffen, beeinträchtigt wird, falls dies zu einer Entscheidung führen kann, die mit hinreichender Wahrscheinlichkeit einen erheblichen Schaden verursacht oder verursachen kann. Keine Absicht muss hinsichtlich der Schadensverursachung vorhanden sein. Nicht erfasst sein sollen ansonsten zulässige Anwendungen im medizinischen Bereich.
2. Ausnutzen von Vulnerabilitäten oder der Schutzbedürftigkeit von Personen aufgrund ihres Alters, einer Behinderung oder einer besonderen sozialen oder wirtschaftlichen Situation, um ihr Verhalten in einer Weise zu beeinflussen, diewesentlich in einer Weise zu verändern, die mit hinreichender Wahrscheinlichkeit einen erheblichen Schaden verursacht oder verursachen kann.
3. Biometrische Kategorisierung, um Rückschlüsse auf die Rasse, die politische Meinung, die Gewerkschaftszugehörigkeit, die religiöse oder weltanschauliche Überzeugung, das Sexualleben oder die sexuelle Ausrichtung einer Person zu ziehen (d.h. auf der Grundlage biometrischer Daten). Es geht also darum, dass gewissermassen von "Äusserlichkeiten" auf (in diesem Fall sensible) "innere" Werte geschlossen wird, was insbesondere deshalb als verboten wird, weil es auch mit AIS unzuverlässig ist. Keine biometrische Kategorisierung ist beispielsweise die Analyse von Text einer Person, wohl aber deren Stimme. Nicht verboten ist auch der Einsatz von AIS, um biometrische Merkmale als solche zu erkennen, z.B. alle Personen mit grünen Augen.
4. Bewertung oder Kategorisierung von Personen (einzeln oder in Gruppen) über einen bestimmten Zeitraum hinweg auf der Grundlage ihres Sozialverhaltens oder bekannter, abgeleiteter oder vorhergesagter persönlicher Eigenschaften, falls diese soziale Bewertung zu einer nachteiligen oder ungünstigen Behandlung führt, die in keinem Zusammenhang mit dem ursprünglichen Kontext der Daten steht oder aber im Hinblick auf ihr soziales Verhalten oder dessen Tragweite ungerechtfertigt oder unverhältnismässig ist.
5. Biometrische Identifizierung aus der Ferne und in Echtzeit in öffentlich zugänglichen Räumen zum Zweck der Strafverfolgung, mit Ausnahme der gezielten Suche nach Opfern gewisser Straftaten, der Vorbeugung gewisser spezifischer Bedrohungen im Falle erheblicher und unmittelbar bevorstehender Bedrohungen oder der Lokalisierung oder Identifizierung von Verdächtigen bestimmter definierter Kategorien von Straftaten (Anhang II), vorbehaltlich zusätzlicher Bedingungen (z.B. gerichtliche Genehmigung, Erlaubnis nur für die Suche nach bestimmten Zielpersonen).
6. Erstellung von Profilen oder Bewertung von Persönlichkeitsmerkmalen oder Eigenschaften von Personen, um das Risiko der Begehung von Straftaten einzuschätzen oder vorherzusagen, ausser zur Unterstützung der Risikobewertung von Personen, die an einer Straftat beteiligt sind.
7. Aufbau oder Erweiterung einer Gesichtserkennungsdatenbank auf der Grundlage von ungezieltem Scraping im Internet oder CCTV-Aufnahmen (d.h. Überwachungskameras). Hier scheint der Gesetzgeber Anbieter wie "Clearview" und "PimEyes" im Blick gehabt zu haben.
8. Das Ziehen von Rückschlüssen auf Emotionen (einschliesslich Absichten) von Personen am Arbeitsplatz oder in Bildungseinrichtungen, es sei denn, dies soll medizinischen oder sicherheitstechnischen Gründen dienen. Hier kommt es jedenfalls gemäss dem Text nicht darauf an, ob die Emotionserkennung auf biometrischen Daten (z.B. Stimme, Gesichtsausdruck) oder anderen Daten (z.B. Inhalt von E-Mails oder anderen Texten) basiert. Dies ist jedoch nicht vollständig klar. Denn auch bei den HRAIS, wo Systeme zur Emotionserkennung ebenfalls erfasst sind, wird im Text nicht differenziert, jedoch geht aus den Erwägungen hervor, dass jedenfalls dort nur Emotionserkennung auf Basis biometrischer Daten gemeint ist.

Zu beachten ist, dass diese Praktiken nur dann verboten sind, wenn sie mittels eines AIS ausgeführt werden. Wer also etwa eine Emotionserkennung am Arbeitsplatz einzig anhand selbst, also von Menschenhand programmierter Wenn-Dann-Regeln durchführt (keine Mustererkennung), ist nicht erfasst. Die Tatbestände sind zudem oft sehr spezifisch formuliert, so dass sich rasch Ausnahmen ergeben. Der Einsatz von AIS zur Überführung von Schülerinnen und Schülern, die bei einer Prüfung tatsächlich schummeln, ist vom Verbot der Erkennung von Emotionen und Absichten beispielsweise nicht erfasst (allerdings eine Hoch-Risiko-Anwendung).; erfasst wäre aber ein AIS, das Schüler aufspüren soll, noch bevor sie schummeln. Detektiert eine AIS die Nervosität eines Schülers, damit die Lehrperson ihn besonders im Auge behalten kann, dann wäre dies eine verbotene Praktik, weil Nervosität eine Emotion darstellt. Erfasst wären auch Lügendetektoren. Grund für das Verbot ist übrigens auch hier die Unzuverlässigkeit der Erkennung und die damit verbundene Gefahr von Ungenauigkeiten und Diskriminierung.

Auch am Arbeitsplatz sind Beispiele im Bereich der Emotionserkennung denkbar, die in der Praxis vorkommen können und keineswegs ungewöhnlich sind. Ein Beispiel ist die Analyse von Gesprächen eines Call Centers. Zur Qualitätskontrolle und für Schulungszwecke werden z.B. gerne sog. Sentiment-Analysen durchgeführt, bei denen die Stimmung der Anrufer ermittelt wird (positiv, neutral, negativ). Geschieht dies nur anhand der Stimme des Anrufers (z.B. live), so sind die Call-Center-Mitarbeitenden nicht betroffen (die Anwendung würde jedoch anderweitig vom AIA erfasst). Erfolgt die Auswertung jedoch nachträglich anhand eines Transkripts des Dialogs, so kann es je nach Programmierung vorkommen, dass in der Zusammenfassung für den Supervisor auch die Stimmung bzw. die Emotion des Call-Center-Agent angegeben wird. Dies wäre unzulässig, jedenfalls wenn nicht danach differenziert wird, ob die Emotionserkennung auf Basis biometrischer Daten erfolgt.

Wer wiederum ein AIS benutzt, um "Data Loss Prevention" (DLP) zu betreiben, führt keine verbotene Praktik aus, auch wenn der Diebstahl von Daten eine Straftat sein kann und DLP daher im weitesten Sinne auch die Beurteilung des Risikos einer Straftat umfasst, aber dies eben nicht das Ziel ist, sondern die Verhinderung eines ungewollten Datenabflusses, ganz gleich, ob es sich um eine Straftat handelt (die verbotene Praktik Nr. 6 oben zielt auf das "predictive policing" ab und nicht auf die Verhinderung von Delikten, die im Gange sind). Das AIS muss aber so funktionieren, dass es Indizien auf Datendiebstahl aufspürt (z.B. Übermittlung bestimmter geschäftlicher Dateien an eine private E-Mail-Adresse) und nicht Hinweise auf Emotionen oder Absichten eines Mitarbeitenden, einen solchen zu begehen (z.B. Suche nach Mustern, wonach der Mitarbeitende eine Wut auf seinen Arbeitgeber hat, frustriert im Job ist oder innerlich gekündigt hat, also keine Loyalität mehr aufweist). Keine Emotion ist hingegen Müdigkeit. Wer also eine KI einsetzt, um übermüdete Mitarbeitende zu erkennen, darf das. Der Einsatz von KI zur Erkennung von Stress am Arbeitsplatz ist hingegen nicht erlaubt.

Ein weiteres Beispiel: Bei der verbotenen Praktik Nr. 1 genügt es nicht, dass Personen mittels KI manipuliert werden. Es muss dies auch zu dem Zweck erfolgen, sie wesentlich in ihrem Verhalten zu beeinflussen, sie daran zu hindern, informierte Entscheidungen zu treffen, und das muss zudem zu einem Entscheid führen, der wesentlichen Schaden für die Person verursachen kann. So halten sogar die Erwägungen fest, dass "übliche und rechtmäßige Geschäftspraktiken, beispielsweise im Bereich der Werbung" ("common and legitimate commercial practices") hier nicht erfasst sind.

Etwas weniger klar ist der Fall bei Praktik Nr. 4 (Scoring), welche recht breit verstanden werden kann, weil sie lediglich eine nachteilige Behandlung voraussetzt. Das Verbot greift aber nur und erst, wenn die Daten mit dieser Behandlung, um die es geht, nichts zu tun haben oder die Schlechterbehandlung unverhältnismässig oder unberechtigt ist. Spannend wird hier zu sehen sein, ob beispielsweise KI-gestützte Funktionen, die für jeden Besucher eines Online-Shops den aufgrund seines Verhaltens aus Sicht des Anbieters optimalen Preis berechnen, erfasst sein werden. Um dem Verbot entgegenzuwirken, müsste auch hier ein System eingesetzt werden, das nicht auf Basis eines Trainings urteilt, sondern regelbasiert agiert.

Bei Praktik Nr. 4 wird sich weiter die Frage stellen, ob und wann sie KI-basierte Bonitätsbeurteilungen meint und damit verbieten würde. Die Zahlungsfähigkeit einer Person ist zwar kein soziales Verhalten und auch keine persönliche Eigenschaft, die Zahlungswilligkeit kann es aber sein. Erfasst wäre also, wer ein AIS auf den Markt bringt, welches zwecks Kreditgewährung Korrelationen zwischen dem Verhalten einer Person und ihrer mutmasslichen Zahlungsunwilligkeit aufzeigt und hierbei Daten aus einem Kontext verwendet, der mit der Zahlungswilligkeit der Person nichts zu tun hat oder deren Beizug unverhältnismässig oder ungerechtfertigt wäre. Dem würde der Anbieter einer Lösung für ein Bonitäts-Scoring entgegenhalten, dass diese auch die Zahlungsfähigkeit abdeckt. Hierauf könnte geantwortet werden, dass die Beurteilung "Zahlt seine Rechnungen mit erhöhter Wahrscheinlichkeit nicht" durchaus als "Social Score" verstanden werden kann. Diesfalls müsste zur Verwendung des AIS aufgezeigt werden, dass nur Daten verwendet werden, die im Kontext des Bezahlens von Rechnungen erhoben wurden und die Bonitätsbeurteilung tatsächlich einigermassen die richtigen trifft und die Konsequenzen vertretbar sind. Als HRAIS wäre eine solche Anwendung freilich so oder so erfasst (siehe nachfolgend).

Ob der Gesetzgeber bei Praktik Nr. 4 tatsächlich so weit gehen wollte, wie dies aus der weit gefassten Regelung wie gezeigt geschlossen werden könnte, ist nicht klar. In den Erwägungsgründen hält er jedenfalls fest, dass das Verbot "nicht die rechtmäßigen Praktiken zur Bewertung natürlicher Personen berühren [sollte], die im Einklang mit dem Unionsrecht und dem nationalen Recht zu einem bestimmten Zweck durchgeführt werden." Die kryptische Formulierung, die im Englischen nicht klarer ist, ist wohl dahingehend zu verstehen, dass er nur extreme Fälle untersagen wollte – wie sie etwa in China praktiziert werden. Die Aussage könnte so verstanden werden, dass immer dann, wenn eine Beurteilung bzw. ein Profiling einer natürlichen Person erstens datenschutz- und auch sonst rechtskonform ist (nach dem Recht der EU) und zweitens die Daten erklärtermassen (auch) zu dem spezifisch Zweck erhoben worden sind, für den sie verarbeitet werden, der AIA die Bewertung nicht verbieten will. Gibt also der erwähnte Online-Shop in seiner Datenschutzerklärung an, was er mit den Daten der betroffenen Personen tun will, auch wenn diese inhaltlich damit auf den ersten Blick nichts zu tun haben, und erfüllt er auch sonst die Vorgaben der DSGVO (soweit sie anwendbar ist), dann wäre der Einsatz eines AIS hierfür demnach nicht verboten.

7. Hoch-Risiko KI-Systeme

Als "Hoch-Risiko KI-System" (HRAIS) gelten zwei Arten von AIS. Zunächst sind es grundsätzlich jene AIS, welche nach den im Anhang I zum AIA aufgeführten EU-Regularien sind, für welche vor dem Vertrieb oder Einsatz eine Konformitätsbewertung durch einen Dritten erforderlich sind, sowie jene AIS, die als Sicherheitskomponente in solchen regulierten Produkten eingesetzt werden (als Sicherheitskomponente gelten auch solche AIS, deren Ausfall zu einer Gefährdung der Gesundheit oder Sicherheit von Mensch oder Besitz führen). Die Anforderungen des AIA ergänzen in diesen Fällen die Regeln, die für diese Produkte ohnehin gelten. Beispiele für solche Produkte sind Medizinprodukte, Spielzeug, Funkgeräte, Sportboote, Flugzeuge, Fahrzeuge, Eisenbahnen oder Aufzüge.

Weiter gelten als HRAIS all jene AIS, die in einem weiteren Anhang des AIA aufgeführt sind. Wie schon bei den verbotenen Praktiken sind auch diese AIS sehr spezifisch definiert, weshalb die Liste regelmässig überprüft und nötigenfalls angepasst werden sollte. Derzeit umfasst die Liste folgende Anwendungen.  Entscheidend ist jeweils, ob ein AIS bestimmungsgemäss für den betreffenden Zweck eingesetzt werden soll. Es werden im betreffenden Annex meist die Anwendungsgebiete definiert, und dann die einzelnen, erfassten Fälle hohen Risikos näher beschrieben:

1. Biometrische Fernidentifizierung mittels KI, die über die blosse Authentifizierung hinausgeht, oder biometrische Kategorisierung mittels KI, welche sensible oder geschützte Merkmale oder Eigenschaften verwenden, die aus solchen abgeleitet wurden. Gemeint sind insbesondere Anwendungen zur Gesichtserkennung über Kamerabilder, die in einer Zentrale verarbeitet werden, aber nicht Systeme zur biometrischen Zugangskontrolle oder Systeme, die sicherstellen sollen, dass nur autorisierte Personen Zugriff auf ein Computersystem erhalten.
2. Erkennung von Emotionen oder Absichten auf der Grundlage biometrischer Daten mittels KI. Anhang III erwähnt nur "Emotionen", nicht Absichten ("intentions"), aber letztere werden in der Begriffsdefinition und in den Erwägungen immer mitgenannt. Es spielt keine Rolle, ob Personendaten bearbeitet werden oder nicht. Beispiele könnten sein, die Emotionserkennung bei einem Verkaufsautomaten, einem Videospiel oder einem System zur medizinischen Diagnose. Als Emotionen gelten beispielsweise Glück, Trauer, Wut, Überraschung, Ekel, Verlegenheit, Aufregung, Scham, Verachtung, Zufriedenheit und Vergnügen. Die Erkennung von Schmerzen und Müdigkeit ist hingegen nicht erfasst, ebenso nicht das Erkennen von Gesten und Bewegungen, beispielsweise zur Steuerung eines Systems. Die Erwägungen halten ausserdem fest, dass biometrische Systeme, die ausschließlich dazu bestimmt sind, um Massnahmen zur Cybersicherheit und zum Schutz personenbezogener Daten durchführen zu können, nie als HRAIS gelten sollen. Die Regelung zur Emotionserkennung ist insofern missverständlich, als dass in Anhang III von "KI-Systemen, die bestimmungsgemäß zur Emotionserkennung verwendet werden sollen" die Rede ist und nicht vom definierten Begriff "Emotionserkennungssystem". Das ist insofern von Belang, als letzterer Begriff zwingend voraussetzt, dass die Erkennung der Emotion auf der Grundlage von biometrischen Daten einer Person erfolgt, also beispielsweise aufgrund ihres Gesichtsausdrucks, ihrer Stimme oder ihrer Bewegungen. Gemeint ist aber in beiden Fällen dasselbe, d.h. auch die Regelung zu den HRAIS meint Emotionserkennung nur auf Basis biometrischer Daten, wie aus den Erwägungsgründen hervorgeht. Das kann von erheblicher praktischer Relevanz sein, wenn es um eine Emotionserkennung auf der Basis des allgemeinen, nicht personenbezogenen Bedeutungsgehalts von Texten einer Person geht. Wenn also im oben erwähnten Call-Center-Beispiel für eine Sentiment-Analyse eine Unterhaltung zunächst transkribiert und erst in dieser Form von einem AIS analysiert wird, wäre dies kein HRAIS, wenn der Inhalt dessen, was jemand sagt, nicht mehr als ein biometrisches Datum gilt. Als ein solches gelten personenbezogene Daten zu den physischen, physiologischen oder verhaltenstypischen Merkmalen einer natürlichen Person. Um eine Text-basierte Sentiment-Analyse als Emotionserkennung zu erfassen, müsste gezeigt werden, dass die von einer Person verwendeten Aussagen und Formulierungen "verhaltenstypische" Merkmale sind und für die Sentiment-Analyse ausgewertet werden. Dem wird normalerweise nicht so sein. Gemeint sind hier unseres Erachtens konstante, individuelle, messbare und bei jeder Person vorkommende Merkmale dieser Person wie ihre Stimme (d.h. bestimmte Aspekte davon, wie Akzent oder Betonungen), Unterschrift und Lippenbewegungen, ihr Tippverhalten auf Tastaturen oder ihre Gangdynamik. Bei Text wäre ein solches Merkmal eine für eine bestimmte Person charakteristische Formulierung wie z.B. eine bestimmte Art und Weise, wie sie ihre E-Mails "unterzeichnet" (in Analogie zur Unterschrift als verhaltenstypisches Merkmal). Der auf Basis allgemeiner, nicht personenbezogener Erfahrungswerte ermittelte Bedeutungsgehalt von geschriebenem Text ist unserer Ansicht nach jedoch kein solches Merkmal einer bestimmten Person und darf daher für eine Emotionserkennung wie im Beispiel der Sentiment-Analyse verwendet werden (z.B. Verärgerung, wenn die Person sagt, sie sei verärgert oder Formulierungen verwendet, die dies nach allgemeinem Sprachgebrauch ausdrücken, wie z.B. "Das kann doch nicht Ihr Ernst sein!"). Würde hingegen ein KI-Modell auf Texten einer bestimmten Person trainiert, die nach ihrem jeweiligen Gemütszustand bezeichnet sind, und würde dieses Modell später eingesetzt, um die Emotionen eben dieser Person anhand von weiteren Texten dieser Person zu ermitteln, quasi indem es aufgrund seines personenbezogenen Trainings "zwischen den Zeilen" lesen kann, läge eine Emotionserkennung im Sinne des AIA vor. Wo genau die Grenze verläuft, bleibt freilich auch damit nicht ganz klar.
3. KI soll als Sicherheitsbauteil bei der Verwaltung und dem Betrieb kritischer digitaler Infrastrukturen (wie z.B. gewisse Internet-, Telekom-, Kommunikations-, Cloud-Computing- und Rechenzentrums-Dienste), im Strassenverkehr oder bei der Versorgung mit Wasser, Gas usw. eingesetzt werden (nicht aber KI einzig zur Cybersicherheit).
4. Einsatz in der allgemeinen und beruflichen Bildung, sofern (i) der Zugang, die Zulassung oder die Zuweisung zu Bildungsangeboten durch KI bestimmt werden soll, (ii) KI zur Bewertung der Lernergebnisse oder des (für den Zugang zur Bildung nötigen) Bildungsniveaus von Personen eingesetzt werden soll oder (iii) KI zur Überwachung oder Erkennung von verbotenem Verhalten bei Prüfungen eingesetzt werden soll.
5. Einsatz im Bereich Beschäftigung und Arbeitnehmer, soweit (i) KI für die Einstellung oder Auswahl von sich auf eine Stelle bewerbenden Personen oder für die Platzierung von Stellenangeboten verwendet wird oder (ii) KI verwendet wird, um Entscheidungen zu treffen, die sich auf die Beschäftigungsbedingungen auswirken oder Beförderungen oder die Beendigung des Arbeitsverhältnisses betreffen, um Arbeit zuzuweisen auf der Grundlage von Verhalten oder anderen persönlichen Merkmalen und um Leistung und Verhalten zu beobachten und zu bewerten.
6. KI wird verwendet, um (für oder als Behörde) zu beurteilen, ob einer bestimmten Person wesentliche öffentliche Unterstützungsleistungen und Dienste, einschliesslich der Gesundheitsversorgung, zur Verfügung stehen oder weiterhin zur Verfügung stehen werden.
7. KI wird zur Bewertung der Kreditwürdigkeit einer Person oder Bestimmung ihres Bonitäts-Scores verwendet werden, jeweils ausser zur Aufdeckung von Finanzbetrug.
8. KI wird verwendet, um Notrufe von Personen zu bewerten und zu klassifizieren, oder um Notrufe oder Notfalldienste oder die medizinische Versorgung zuzuweisen oder zu triagieren. Die Verwendung von KI für medizinische Zwecke (wie z.B. die Beurteilung von Patienten) ist als solche nicht ausdrücklich als Anwendungsfall aufgeführt. Wer jedoch eine Software oder ein Gerät anbietet, welches KI beispielsweise für Diagnosezwecke verwendet oder zur Behandlung, wird typischerweise über die Regulierung von Medizinprodukten erfasst sein. Nicht ganz klar ist, ob die Regelung, wonach derjenige zum Provider wird, der ein "normales" AIS zu einem HRAIS umfunktioniert, im Fall greift, in welchem beispielsweise ein Arzt "ChatGPT" benutzt, um z.B. Aufzeichnungen seiner Patienten zu analysieren.
9. KI wird für Risikobewertungen und die Preisgestaltung von Lebens- oder Krankenversicherungen verwendet.
10. Verwendung zu Strafverfolgungszwecken, wenn (i) KI zur Bewertung des Risikos einer Person, Opfer einer Straftat zu werden, verwendet werden soll, (ii) KI als Lügendetektor oder ähnliches Instrument verwendet werden soll oder (iii) KI zur Feststellung der Zuverlässigkeit von Beweismitteln verwendet werden soll (in jedem Fall mit Ausnahme der oben genannten verbotenen Praktiken).
11. Verwendung zu Strafverfolgungszwecken, wenn (i) KI dazu dient, das Risiko einer Straftat oder einer erneuten Straftat einer Person nicht nur auf der Grundlage eines (automatisierten) Profils zu bewerten, (ii) KI dazu dient, persönliche Merkmale oder Eigenschaften oder frühere kriminelle Verhaltensweisen von Personen oder Gruppen zu bewerten, oder (iii) KI zur Erstellung von Profilen von Personen im Rahmen der Aufdeckung, Untersuchung oder Verfolgung von Straftaten verwendet werden soll.
12. Im Migrations-, Asyl- und Grenzkontrollwesen, soweit (i) KI als Lügendetektor oder ähnliches Werkzeug verwendet werden soll, (ii) KI zur Bewertung des Risikos von Personen, die in die EU einreisen oder dies tun wollen, verwendet werden soll, (iii) KI zur Unterstützung der Prüfung von Anträgen auf Asyl, Visa, Aufenthaltsgenehmigungen und damit zusammenhängenden Beschwerden sowie zur Bewertung der damit zusammenhängenden Beweise verwendet werden soll, (iv) KI zum Aufdeckung, Anerkennung oder Identifizierung von Personen verwendet werden soll, ausser zur Überprüfung von Reisedokumenten.
13. KI wird von einer Justizbehörde oder in deren Auftrag oder im Rahmen einer alternativen Streitbeilegung verwendet, um die Justizbehörde bei der Ermittlung und Auslegung von Sachverhalten und Rechtsvorschriften und deren Anwendung auf einen bestimmten Fall zu unterstützen.
14. KI wird zur Beeinflussung des Ergebnisses einer Wahl oder einer Abstimmung eingesetzt, jedoch nicht, wenn Personen dem Ergebnis der KI nicht unmittelbar ausgesetzt sind (z.B. KI-Systeme, die zur Organisation, Optimierung und Strukturierung der Verwaltung oder Logistik politischer Kampagnen eingesetzt werden).

In der Praxis privater Unternehmen von Relevanz sein werden vor allem die Fälle 2, 3, 4, 5, 7, 8 und 9 sein. Die meisten Anwendungsfälle haben wir bisher im Arbeitsbereich und Bildungssektor gesehen. Die Vorselektion oder Bewertung von Stellenbewerbern (z.B. wie gut sie in das gesuchte Profil passen oder welche Erkenntnisse sich aus dem Lebenslauf ziehen lassen) ist eine solche Anwendung, selbst wenn letztlich Menschen die Entscheidung treffen. Extremere Anwendungsfälle haben wir im Sportbereich gesehen, wo bereits heute AIS zur Beurteilung und Ausbildung von Profi- und teilweise auch Amateur-Athleten eingesetzt werden, zu denen die betreffenden Vereine und Organisationen nicht selten ein Arbeits- oder Ausbildungsverhältnis stehen. Fragen stellen sich in der Praxis immer wieder auch in Bezug auf Systeme, welche Unternehmen zur Cybersicherheit (z.B. "Endpoint Detection and Response", EDR) und "Data Loss Prevention" (DLP) einsetzen: Sie überwachen den Netzwerkverkehr und das Verhalten der Mitarbeitenden und schlagen Alarm, wenn ungewöhnliche Vorkommnisse beobachtet werden, die auf Eindringlinge, Datendiebstahl oder sonstige Regelverstösse beobachtet werden. Als Erkennung von Emotionen und Absicht gelten Massnahmen zur Cybersicherheit zwar wie erwähnt nicht, jedoch ist fraglich, ob solche Systeme nicht der "Beobachtung … des Verhaltens von Personen in … Beschäftigungsverhältnissen" dienen. Dies dürfte tendenziell der Fall sein, jedenfalls wenn die Ausrichtung dieser Systeme primär nach innen gerichtet ist, wie dies beispielsweise bei einem DLP ist, welches den unerwünschten Datenabfluss durch Mitarbeitende erkennen und unterbinden soll (während z.B. EDR-Systeme primär auf Anzeichen von externen Bedrohungen wie Ransomware-Angriffe und Malware achten). Den Erwägungen zufolge erfolgt die Klassifizierung als HRAIS, weil die Überwachung der Leistung und des Verhaltens von Beschäftigten "deren Grundrechte auf Datenschutz und Privatsphäre" untergraben kann, was bei DLP-Systemen sein kann. Gegen die Klassifizierung als HRAIS könnte eingewendet werden, dass mit Verhalten die Beobachtung des regulären Verhaltens eines Beschäftigten gemeint ist, nicht das Aufspüren eines ganz ausnahmsweise vorkommenden Fehlverhaltens, jedenfalls wenn der Alarm nur dann anschlägt, wenn bestimmte (nicht mittels KI-ermittelte) Schwellenwerte oder Trigger überschritten sind. Zu erwähnen ist schliesslich noch, dass der AIA auch eine «de minimis»-Regelung für HRAIS kennt. Sie kommt dann zum Tragen, wenn gezeigt werden kann, dass ein AIS kein erhebliches Risiko der Beeinträchtigung in Bezug auf die Gesundheit, Sicherheit oder Grundrechte natürlicher Personen birgt, indem es unter anderem das Ergebnis einer Entscheidungsfindung nicht wesentlich beeinflusst. Dann liegt kein HRAIS vor. Art. 6(3) AIA zählt hierzu einige Fälle auf, in welchen das so sein soll, etwa wenn ein KI-System nur eine eng gefasste Aufgabe durchführt oder bestimmte abgeschlossene Tätigkeiten betrifft. Will ein Anbieter diese Regelung beanspruchen, muss er dies vor Inverkehrbringen und Inbetriebnahme dokumentieren. Der Registrierungspflicht für HRAIS unterliegt er trotzdem.

Der folgende One-Pager gibt einen Überblick über diese und die weiteren Anwendungsfälle und bisher diskutierten Definitionen des AIA (nur auf Englisch):

Hier anklicken für die Grafik (nur auf Englisch verfügbar)

Liegt ein solches HRAIS vor, hat vor allem der Provider eine ganze Reihe von Aufgaben zu erfüllen, da primär er dafür verantwortlich ist, dass die Vorgaben aus Kapitel 2 der Regelungen zu den HRAIS in Bezug auf diese erfüllt werden. Diese Vorgaben für HRAIS sind:

• Es muss ein eingehendes Risikomanagement betrieben werden, d.h. insbesondere Risikobeurteilungen, die über den gesamten Lebenszyklus des HRAIS wiederholt werden, mit entsprechenden Tests des HRAIS und Massnahmen, um die identifizierten Risiken zu kontrollieren (vgl. hierzu das Open-Source-Werkzeug GAIRA);
• Die Daten, die für Training, Validierung und Tests verwendet werden, müssen bestimmten Qualitätskriterien genügen und müssen Gegenstand einer weitreichenden Data Governance sein, um beispielweise Bias, Fehler und Lücken zu erkennen;
• Es muss eine detaillierte technische Dokumentation zum HRAIS erstellt und nachgeführt werden, die auch die Erfüllung der Vorgaben belegt;
• Das HRAIS muss das, was es tut, automatisch in Logs angemessen protokollieren, damit sein korrektes Funktionieren über Zeit überwacht werden kann;
• Das HRAIS muss so ausgestaltet sein und mit Nutzungsanweisungen und weiteren Hinweisen geliefert werden, dass seine Anwender es richtig handhaben, seinen Output richtig verstehen und einschätzen können sowie vom Menschen überwacht und kontrolliert werden kann (was u.a. umfasst, dass das HRAIS jederzeit sicher gestoppt werden kann und in einer Weise zur Verfügung gestellt wird, dass Menschen dem HRAIS nicht einfach vertrauen);
• Das HRAIS muss angemessen genau und zuverlässig arbeiten (wobei vorgesehen ist, dass die Europäische Kommission die Entwicklung entsprechender Standards fördern soll), und es muss angemessen fehlertolerant sein;
• Das HRAIS muss über eine angemessene Sicherheit verfügen, insbesondere, um es gegen Angriffe von Dritten zu schützen, sowohl im Bereich der klassischen Informationssicherheit als auch bei KI-spezifischen Angriffen (siehe Teil 6 unserer Blogs-Serie).

Um die Einhaltung dieser Anforderungen nachzuweisen und sicherzustellen und die Aufsicht zu ermöglichen, müssen Provider:

• Eine entsprechende Dokumentation führen (bis zehn Jahre nach Inverkehrbringen oder Inbetriebnahme); den zuständigen Behörden sind auf Anfrage die nötigen Nachweise zu erbringen;
• Ein Qualitätsmanagementsystem vorweisen; hat der Provider Grund zur Annahme, dass das HRAIS nicht den Anforderungen entspricht, sind unverzüglich die nötigen Korrekturmassnahmen zu treffen (einschliesslich Rückrufe) und darüber zu informieren;
• Die von ihren HRAIS im Einsatz generierten Logs aufbewahren (soweit sie sie haben, und zwar mindestens sechs Monate);
• Das HRAIS in einer EU-Datenbank registrieren (ausser jene, die im Rahmen von kritischen Infrastrukturen eingesetzt werden);
• Eine Konformitätsbeurteilung durch einen entsprechenden Dritten vornehmen lassen;
• Das HRAIS mit einem Konformitätszeichen ("CE") und ihren Kontaktangaben versehen;
• Ein System betreiben, mit welchem sie das HRAIS nach dem Inverkehrbringen in Bezug auf technische Entwicklungen und Risiken beobachten können (sog. Post-Market Monitoring-System); und
• Eine Untersuchung sowie eine Meldung an die Aufsichtsbehörden vornehmen, wenn von einem HRAIS ein Risiko für die Gesundheit, die Sicherheit oder die grundlegenden Rechte von betroffenen Personen ausgeht oder es zu einem ernsthaften Zwischenfall kommt.

Ein Provider, der selbst nicht in der EU ansässig ist, dort aber ein HRAIS anbietet, muss einen Vertreter in der EU bezeichnen ("Bevollmächtigter"), der über die nötigen Unterlagen verfügt, damit die EU-Behörden darauf zugreifen können. Speziell daran: Er ist selbstständig verpflichtet, das Mandat niederzulegen und die Aufsichtsbehörde zu informieren, falls er Grund zur Annahme hat, dass der Provider seinen Pflichten nach dem AIA nicht nachkommt. Auch den Importeuren und Distributoren von HRAIS kommen bestimmte Pflichten zu.

Auch jene, die ein HRAIS "nur" in eigener Verantwortung einsetzen, also die Deployer, haben Pflichten unter dem AIA. Sie müssen insbesondere sicherstellen, dass:

• Das HRAIS gemäss der Nutzungsanweisungen verwendet wird;
• Das HRAIS von qualifizierten Menschen überwacht wird;
• Die Logs, die das HRAIS automatisch erstellt, mindestens sechs Monate aufbewahrt werden;
• Etwaiger Input für das HRAIS im Hinblick auf den Zweck geeignet und repräsentativ ist;
• Der Provider im Rahmen von dessen Post-Market-Monitoring-Systems über den Betrieb des HRAIS informiert;
• Die Aufsichtsbehörde und der Provider (und ggf. seinen Händler) informiert wird, wenn Grund zur Annahme besteht, dass von einem HRAIS ein Risiko für die Gesundheit, die Sicherheit oder die grundlegenden Rechte von betroffenen Personen ausgeht; – hierzu ist das HRAIS im Betrieb zu überwachen; es muss mit der Aufsichtsbehörde zusammengearbeitet werden;
• Beim Einsatz von HRAIS am Arbeitsplatz die betroffenen Mitarbeitenden darüber informiert sind;
• Betroffene Personen informiert sind, wenn ein HRAIS für sie betreffende Entscheidungen verwendet wird, selbst wenn das HRAIS nur unterstützend zum Einsatz kommt (dies geht somit weiter als unter der DSGVO).; und
• Eine Grundrechte-Folgenabschätzung durchgeführt (allenfalls in Kombination mit einer Datenschutz-Folgenabschätzung) und der Aufsichtsbehörde mitgeteilt worden ist, sofern es sich beim Deployer um eine Stelle des öffentlichen Rechts, um eine private Stelle, die "öffentliche Dienste" erbringt, oder um den Betrieb eines HRAIS zur Kreditwürdigkeitsprüfung, der Berechnung eines Bonitätsscores oder der Risikobewertung oder Preisbildung im Bereich von Lebens- und Krankenversicherungen handelt; ob "öffentliche Dienste" auch rein privatrechtliche Tätigkeiten meint, ist nicht völlig klar, aber es ist aufgrund der Erwägungen davon auszugehen; erwähnt werden Dienste, die im öffentlichen Interesse, etwa in den Bereichen Bildung, Gesundheitsversorgung, Sozialdienste, Wohnungswesen und Justizverwaltung erbracht werden.

Diese Pflichten sind nicht abschliessend. Der AIA gibt in einer Art Generalklausel selbst bei rechtskonform eingesetzten HRAIS der Marktaufsicht die Kompetenz, weitere Massnahmen anzuordnen, falls dies zum Schutz der Gesundheit oder Sicherheit der Personen, deren grundlegender Rechte oder anderer öffentlicher Interessen erforderlich sein sollte.

Ferner sieht der AIA analog zur DSGVO eine Art Auskunftsrecht für betroffene Personen in der EU (nicht aber der Schweiz) vor, wenn ein Deployer auf Basis des Outputs eines HRAIS eine Entscheidung trifft, die auf die Person rechtliche oder vergleichbar wesentliche, für ihre Gesundheit, Sicherheit oder grundlegende Rechte nachteilige Auswirkungen hat. Sie kann dann verlangen, dass der Deployer ihr erklärt, welche Rolle dem HRAIS im Entscheid zugekommen ist und was die wesentlichen Elemente des Entscheids waren. Das gilt für alle HRAIS der oben aufgezählten 15 Kategorien, ausgenommen Nr. 2. Die Ansprüche gemäss DSGVO bleiben vorbehalten; sie sind insofern enger, als sie sich auf vollständig automatisierte Entscheide beziehen.

Diese Pflichten können aufgrund der extraterritorialen Geltung des AIA für Deployer von HRAIS auch für Unternehmen ausserhalb der EU von Bedeutung sein, selbst wenn der Provider sich nicht in der EU befindet, der Output des HRAIS aber in der EU verwendet wird (siehe oben). Ob und wie gut diese Pflichten beispielsweise gegen Unternehmen in der Schweiz durchgesetzt werden können und werden, ist eine andere Frage. Es ist – wie schon im Falle der DSGVO – eher nicht damit zu rechnen, da dem auch rechtliche Schranken im Schweizer Recht entgegenstehen. Stellvertretende Sanktionen gegen den korrekt handelnden EU-Vertreter dürften dagegen nicht möglich sein.

8. Regelungen für KI-Modelle

Erst spät im Gesetzgebungsprozess wurde der AIA auch um Regelungen für Provider bestimmter KI-Modelle erweitert (die Rolle des Deployers gibt es hier nicht). Allerdings sind nur für unterschiedlichste Zwecke einsetzbare Modelle ("general purpose", "KI-Modelle mit allgemeinem Verwendungszweck") erfasst (GPAIM). Wie genau sich diese gegenüber anderen Modellen abgrenzen, ist allerdings nicht klar. So könnte vertreten werden, dass ein Modell nur zur Transkription wie "Whisper" oder eines nur für Übersetzungen kein GPAIM ist. Ist ein GPAIM durch Fine-Tuning auf bestimmte Themen wie z.B. rechtliche Fragen "spezialisiert" worden, wird es aber vermutlich weiterhin als GPAIM gelten, weil es sich nach wie vor für viele unterschiedliche Anwendungen einsetzen lässt.

Aus den Erwägungsgründen geht hervor, dass GPAIM nicht nur in ihrer eigentlichen Form, d.h. als Dateien, erfasst sind, sondern auch dort, wo sie über eine API (Anwendungsprogrammierschnittstelle) quasi als "Model-as-a-Service" angeboten werden. Sie gelten gemäss den Erwägungen zudem nicht als AIS, d.h. auch die entsprechenden Pflichten greifen ins Leere, weil ihnen eine Benutzerschnittstelle fehlt (warum ein API nicht als solche gelten soll, wird nicht erklärt). Wenn also OpenAI nebst "ChatGPT" den Zugang zu GPT4 auch über ein API anbietet, muss sie die AIA-Vorgaben für AIS im Rahmen dieses API nicht beachten, während "ChatGPT" als AIS gilt und die Vorgaben zu beachten sind. Den Vorgaben für AIS ist dann derjenige unterworfen, der das Modell in seiner Anwendung nutzt (soweit sie als AIS gilt); er wird dann zu deren Provider, weil er die Anwendung entwickelt hat und er sie für sich einsetzt. Bringt er diese Anwendung im EU-Markt in Verkehr oder nimmt er sie bei sich in der EU in Betrieb, dürfte allerdings wohl auch das Modell als in Verkehr gebracht gelten.

Wer ein GPAIM erstellt, aber nur intern nutzt, ist von den Vorgaben für GPAIM nicht erfasst, weil er erst dann als Provider gilt, wenn er das GPAIM in Verkehr bringt; das Kriterium der Inbetriebnahme für eigene Zwecke ("putting into service") greift wohl wegen eines gesetzgeberischen Versehens nur bei AIS. Die Ausnahmen hätten gemäss den Erwägungsgründen enger gefasst sein sollen.

Provider von GPAIM haben insbesondere folgende Pflichten:

• Sie müssen zu Händen der Aufsichtsbehörden eine detaillierte technische Dokumentation des Modells führen und nachführen.;
• Sie müssen zu Händen der Nutzer des GPAIM (d.h. den Providern von AIS) eine weitaus weniger detaillierte Dokumentation des Modells führen und nachführen;
• Sie müssen, falls sie sich ausserhalb der EU befinden, einen Vertreter in der EU benennen ("Bevollmächtigter");
• Sie müssen interne Regeln (d.h. eine "Strategie") zur Einhaltung des EU-Urheberrechts einführen, einschliesslich der dessen sog. Text- and Data-Mining-Regelung (TDM) und deren Opt-out-Recht. Die TDM-Regelung erlaubt Dritten im Sinne einer Schrankenbestimmung die Entnahme und Nutzung von Inhalten aus Datenbanken, zu denen sie rechtmässig Zugang haben, gibt den Inhabern der Rechte der darin enthaltenen Werke jedoch ein "opt-out"-Recht in Bezug auf Anwendungen ausserhalb der wissenschaftlichen Forschung. Es ist schon unabhängig vom AIA nicht völlig klar, wie wichtig die TDM-Regelung für das Trainieren von KI-Modelle tatsächlich ist und wie genau sie operativ umzusetzen ist, insbesondere vor dem Hintergrund der Tatsache, dass sie national unterschiedlich umgesetzt ist. Die Tragweite der Vorgabe des AIA ist ebenfalls nicht völlig klar.

Nach einer strengen Lesart könnte es mit der neuen Bestimmung noch schwieriger werden, KI-Modelle zu trainieren, denn wer später ein GPAIM in der EU anbieten will, müsste das EU-Urheberrecht beim Training seines Modells auch dann einhalten bzw. entsprechende Weisungen vorsehen, wenn er diesem Recht gar nicht unterliegt (so kann beispielsweise das Schweizer Urheberrecht oder das US-Recht mehr oder andere Schutzaufnahmen bieten, die ein Training von KI-Modellen gegenüber dem EU-Recht leichter möglich macht). Es würde verhindert werden, dass z.B. ein US-Anbieter sein Modell unter einem weniger strengen ausländischen Recht aufbaut und dann in der EU auf den Markt bringt. Dem EU-Urheberrecht würde damit für die Zwecke von GPAIM mit anderen Worten faktisch weltweite Geltung verschafft, da die meisten Anbieter von GPAIM diese auch in der EU anbieten wollen. Die Regelung würde somit EU-Anbieter von Allzweck-KI-Modellen vor einer Benachteiligung durch ausländische Anbieter schützen.

Nach einer weniger strengen Lesart wäre genau das Gegenteil der Fall. Das EU-Urheberrecht müsste demnach nur insoweit eingehalten werden, als es auch tatsächlich angewandt werden will. Nach dem sog. Schutzlandprinzip wäre dies nur dann der Fall, wenn das Training des KI-Modells in der EU erfolgt, nicht aber beispielsweise in der Schweiz oder in den USA, wo für die lokal erfolgten Verwendungen von Werken das lokale Recht zur Anwendung käme, das weniger streng ist als in der EU. Das EU-Urheberrecht käme nur aber immerhin dann zur Anwendung, wenn das KI-Modell später in der EU eingesetzt wird und dort einen Output generiert (der dann das EU-Urheberrecht nicht verletzen darf, wobei sich die Frage stellt, ob dies nicht einzig Sache des Verwenders des Modells ist). Diese Lesart überzeugt: Sie kann aus dem Text des AIA abgeleitet werden, der nur eine Strategie zur Einhaltung des EU-Urheberrechts verlangt, und nicht dessen sinngemässe Einhaltung ausserhalb der EU. Diese Lesart respektiert auch das international anerkannte Schutzlandprinzip. Die geforderte Strategie bestünde somit darin sicherzustellen, dass kein Training des KI-Modells in der EU erfolgt und so das dortige Urheberrecht auch nicht verletzt wird. Die Erwägungen machen jedenfalls den Eindruck, dass es vor allem darum ging, die Stellen, die in der EU trainieren und sich dabei auf die TDM-Schrankenbestimmung stützen, angemessene Massnahmen zur Berücksichtigung von Opt-outs vornehmen.

So oder so ist allerdings nicht ganz klar, was mit der etwas ungewöhnlichen Regelung auf sich hat, eine "Strategie … für die Einhaltung … auf den Weg" zu bringen. Dies kann so verstanden werden, dass zwar Bemühungen unternommen werden müssen, das (anwendbare oder nicht anwendbare) EU-Urheberrecht einzuhalten, diese Strategie aber nicht zwingend erfolgreich sein muss. Naheliegend wäre gewesen, eine Vorgabe zu formulieren, wonach ein Nachweis zu erbringen ist, dass das EU-Urheberrecht eingehalten worden ist. Das geschah nicht. Erste Rechteinhaber haben übrigens bereits Opt-out-Erklärungen öffentlich abgegeben;

• Sie müssen öffentlich in summarischer Form ("hinreichend detaillierte Zusammenfassung") darlegen, welche Inhalte sie für das Training ihrer Modelle benutzt haben. Es muss somit nicht im Einzelnen belegt werden, welche Inhalte für das Training verwendet worden sind; und
• Sie müssen mit der Europäischen Kommission und den nationalen Aufsichtsbehörden zusammenarbeiten.

Der AIA entbindet zwar GPAIM unter einer freien, offenen Lizenz von den ersten drei Pflichten, nicht aber von den beiden letzten. Zudem wird der Begriff "Open Source" eng angelegt.

Für Provider von GPAIM, die ein "systemisches Risiko" mit sich bringen, gelten noch zusätzliche Vorgaben. Aus Sicht des Gesetzgebers bringt ein GPAIM dann ein systemisches Risiko mit sich, wenn es auf die öffentliche Gesundheit, die Sicherheit, die Grundrechte oder sonst die Gesellschaft in der EU erhebliche Auswirkungen haben kann. Das soll dann der Fall sein, wenn es als solches etwa von der Europäischen Kommission eingestuft wird oder sich der hohe Wirkungsgrad z.B. über entsprechende Benchmarks oder dergleichen zeigt. Letzteres wird dann angenommen, wenn für dessen Erstellung eine Rechenleistung von 10 hoch 25 FLOPS (= "Rechenoperationen mit Bruchzahlen") oder mehr zum Einsatz gekommen ist. Die grossen LLM wie etwa GPT4 von OpenAI dürften zwar nach verbreiteter Annahme als solche GPAIM mit systemischen Risiken gelten , doch die genauen Zahlen sind nicht bekannt. Wir schätzen, dass sie noch knapp unter der genannten rechnerischen Grenze liegen. Der AIA ist in dieser Hinsicht allerdings so oder so offen formuliert; auch "kleinere" GPAIM können wie erwähnt zu GPAIM mit systemischem Risiko erklärt werden. Deren Provider müssen dann zusätzlich ihre Modelle im Hinblick auf die damit verbundenen Risiken evaluieren, entsprechende Massnahmen zur Behandlung der Risiken treffen und ernsthafte Zwischenfälle ("serious incidents") erheben, dokumentieren und den Aufsichtsbehörden melden, einschliesslich der diesbezüglich möglichen Massnahmen. Ferner haben sie für eine angemessene Cybersicherheit der GPAIM zu sorgen.

9. Weitere Pflichten für Provider und Deployer

Der AIA definiert auch einige fallspezifische Transparenzpflichten, die für alle AIS gelten sollen, auch solche die keine HRAIS sind. Insbesondere werden Pflichten zur Markierung und Kennzeichnung bestimmter KI-generierter Inhalte eingeführt.

Provider müssen sicherstellen, dass:

• Personen, die mit einem AIS interagieren und dieses dafür vorgesehen ist, über eben diesen Umstand informiert werden, ausser es ist dies aus Sicht eines verständigen Anwenders offenkundig. Ein typischer Verstoss gegen diese Regel können Chatbots sein, welche z.B. durch entsprechende Namen und Bilder den Eindruck erwecken, die Personen würden sich mit einem realen Menschen unterhalten. Relevant sein kann die Vorgabe aber auch bei Offline-Kommunikation, wie etwa bei Bots, welche automatische E-Mail-Antworten generieren, die nicht als solche gekennzeichnet sind.
• die von einem AIS synthetisch generierten Text-, Ton-, Video- und Bildinhalte als KI-generiert oder KI-manipuliert markiert sind.  Diese Markierung muss maschinenlesbar sein (aber nicht zwingend auch vom Menschen ohne Hilfsmittel erkennbar). Es ist noch nicht klar, wie solche Markierungen bei Textinhalten erfolgen sollen (während es sehr viel einfacher ist, Bilder mit entsprechenden "Wasserzeichen" zu versehen). Das Anbieten von passenden "KI-Content-Detektoren" ist zwar keine Pflicht, aber solche werden sicher bald angeboten werden zur Identifizierung solcher Wasserzeichen bzw. "Watermarkings", die hoffentlich zuverlässiger sind als das, was heute auf dem Markt ist. Da sich der Gesetzgeber offenbar der Tatsache bewusst war, dass seine Definition von AIS sehr breit ist, hat er eine Ausnahme für AIS formuliert, wonach AIS, welche lediglich eine "unterstützende Funktion" bei normalen Bearbeitungsvorgängen haben, den Input oder seine Bedeutung nicht wesentlich verändern oder sie zur Aufdeckung, Verhütung, Ermittlung oder Verfolgung von Straftaten gesetzlich zugelassen sind. Anbieter von automatischen Übersetzungsdiensten wie "DeepL" werden von dieser Ausnahme zu profitieren versuchen; sie basieren vollständig auf generativer KI. Ein weiteres Beispiel wäre ein Werkzeug, dass die Auflösung von Bildern mittels KI erhöht. Genau genommen ist die Pflicht zur Markierung von KI-Output aber so formuliert, dass sie auf fast jedes AIS zur Anwendung gebracht werden müsste, da fast jedes AIS in irgendeiner Form Text, Ton oder Bilder ausgibt (z.B. ein Text- oder Spracherkennungsprogramm, eine KI, welche Defekte an Fabrikaten aufspürt oder ein Recommender-System, das einem Käufer in einem Online-Shop weitere Produkte empfiehlt). Das war natürlich nicht die Absicht des Gesetzgebers, der klar Output generativer KI im Blick hatte, und zwar Inhalte, bei welchen der Mensch sonst möglicherweise nicht erkennen würde, dass sie von einer Maschine stammen. In diesem Sinne sollte die Bedingung, dass die Inhalte "synthetisch" sein müssen, nach dem Sinn und Zweck der Regelung dahingehend zu verstehen ist, dass sie den Inhalten eines Menschen nachempfunden sind (also nicht "menschlich"); gemeint ist also der Output generativer KI. Der von einem AIS berechnete Bonitätsscore eines Kunden wäre zwar auch ein Textinhalt, aber kein "synthetischer" im Sinne dieser Bestimmung. Schliesslich sei noch der Hinweis angebracht, dass die Pflicht zum Watermarking nur den Provider betrifft: Anwender (und Deployer) sind frei, solche Wasserzeichen zu entfernen.

Deployer müssen sicherstellen, dass:

• betroffene Personen informiert werden, wenn sie bei diesen AIS zur Erkennung von Emotionen oder Absichten oder zur Kategorisierung anhand biometrischer Merkmale eingesetzt werden und dabei Personendaten bearbeitet werden. Weil die Emotionserkennung auch hier auf Basis biometrischer Daten erfolgen muss (dies ergibt sich aus der Defition des Begriffs des Emotionserkennungssystems), ist das in der Praxis häufige Anwendungsbeispiel der Sentiments-Analyse, die auf Text statt Stimme basiert, nicht erfasst.
• von ihnen generierte "Deep Fakes" als solche erkennbar sind; für Kreativschaffende gibt es allerdings eine Ausnahme: Wenn Deep Fakes offenkundig Teil von Kunst, Literatur, Satire und dergleichen sind, darf der Hinweis so eingeschränkt werden, dass die Darstellung und der Genuss des Werks nicht beinträchtigt wird. Es wird spannend zu sehen sein, inwiefern diese Ausnahme auch auf Werbung angewendet wird. Die Bestimmung soll übrigens nicht jene schützen, über die ein Deep Fake hergestellt wird (diese können sich gestützt auf das Datenschutzrecht oder Spezialbestimmungen wehren), sondern jene, die damit getäuscht werden könnten: Deep Fakes werden nämlich nicht verboten, sondern müssen nur als solche ausgewiesen werden.
• in publizierten Texten, die Themen von öffentlichem Interesse betreffen, darauf hingewiesen wird, dass diese KI-generiert oder manipuliert worden sind – es sei denn, der Text wurde von einem Menschen geprüft und ein Mensch oder eine juristische Person hat für dessen Publikation die redaktionelle Verantwortung übernommen.

Die vorstehenden Pflichten gelten nur für AIS, nicht für GPAIM. Wenn also ein Unternehmen wie OpenAI ein AIS wie "ChatGPT" anbietet, dann muss sie dafür sorgen, dass KI-Inhalte als solche maschinenlesbar markiert sind. Bietet sie den Zugang zu ihren Modellen via API (d.h. über eine Schnittstelle für Computerprogramme) an, so muss sie dies nicht tun. Die Pflicht obliegt dann dem Unternehmen, das dieses API in einer eigenen Anwendung nutzt und dadurch zu einem AIS wird – falls dieses Unternehmen als Provider im Sinne des AIA gilt und in dessen Geltungsbereich fällt, weil es sein AIS in der EU in Verkehr bringt oder in Betrieb nimmt.

Fällt ein AIS nicht unter diese Bestimmungen, ist es auch kein HRAIS und geht es nicht um eine verbotene Praktik, dann bestehen unter dem AIA grundsätzlich keine Pflichten für Provider, Deployer und die weiteren beteiligten Stellen bezüglich des Betriebs dieses AIS. Sie werden im AIA jedoch grundsätzlich ermuntert, sich freiwillig an Verhaltenskodizes zu halten, die dereinst im Bereich von AIS entstehen sollen, um ethische Grundsätze, einen sorgsamen Umgang mit der Umwelt, die Medienkompetenz im Umgang mit KI, Diversität und Inklusion sowie die Vermeidung negativer Auswirkungen auf vulnerable Personen sicherzustellen. Ferner sieht ein erst im Laufe der Beratungen eingefügter Artikel eine Art KI-Ausbildungspflicht für Provider und Deployer vor, d.h. sie müssen nach besten Kräften dafür sorgen, dass die Personen, die mit AIS umgehen, angemessen darin ausgebildet, über die anwendbaren Pflichten gemäss AIA informiert sind und den Personen die Chancen und Risiken von AIS bewusst sind ("AI literacy"). Dies gilt für alle AIS, nicht nur HRAIS. Ob und inwieweit diese Vorgabe durchgesetzt wird, wird sich zeigen.

Damit geht der AIA für den einen oder anderen wohl erstaunlich wenig weit in der Regulierung des Einsatzes von AIS, die weder ein HRAIS sind, noch eine verbotene Praktik betreffen – also in der Praxis in der Mehrheit der Fälle. Dies, obwohl in zahlreichen internationalen Initiativen, Erklärungen und sogar in der KI-Konvention des Europarats immer wieder Vorgaben formuliert worden sind, die als wichtig für den verantwortungsvollen Einsatz von KI bezeichnet wurden, wie etwa den Grundsatz der Transparenz, der Nichtdiskriminierung, der Selbstbestimmung, der Fairness, der Verhinderung von Schaden, der Robustheit und Zuverlässigkeit von AIS, der Erklärbarkeit von KI und der menschlichen Aufsicht (siehe dazu auch unsere 11 Grundsätze). Bis auf ausgewählte Aspekte der Transparenz verlangt der AIA ihre Einhaltung zwingend nur im Bereich der HRAIS, und auch dort nicht wirklich konsequent und primär von Providern; er erlaubt wie gezeigt nicht einmal die Verarbeitung von besonderen Kategorien von personenbezogenen Daten, um ein "normales" AIS auf Bias zu testen und solchen zu eliminieren (zumal der AIA dies auch nicht verlangt). Es wird sich zeigen, ob die Durchsetzung dieser Grundsätze auf anderem Wege erfolgen (beispielsweise über das Datenschutz- oder Lauterkeitsrecht), über Leitlinien, die sich Organisationen freiwillig auferlegen, oder gar nicht.

10. Anwendungsbeispiele

In der Folge haben wir einige praktische Anwendungsbeispiele aufgeführt, um zu zeigen, auf wen welche Bestimmungen des AIA im Alltag zur Anwendung gelangen können:

Bemerkungen:

1. Der Wortlaut der Definitionen spricht gegen eine Qualifikation als Provider, aber der Gesetzgeber wollte das Unternehmen in diesem Fall als Provider, für den der AIA gilt, erfassen, weil der Output in der EU genutzt wird.
2. Es kommt hier die Spezialregelung zum Tragen, wonach ein AIS so genutzt wird, dass es zu einem HRAIS wird; in diesem Fall wird der Anwender zum Provider.
3. Es liegt keine Verwendung der Outputs der KI in der EU vor, da es um Stellen in der Schweiz geht; die Nationalität oder Herkunft der Stellenbewerbenden darf richtigerweise keine Rolle spielen. Die Herkunft der Stellenbewerber (nicht die Nationalität) wäre nur dann relevant, wenn ihnen die Outputs der KI zugesandt werden (was hier nicht der Fall ist).
4. Der Chatbot ist ein AIS, das auch von Personen genutzt werden soll, die sich in der EU befinden. Damit könnte vertreten werden, dass das AIS auch in der EU benutzt bzw. wird hierfür bereitgestellt wird (zum Eigengebrauch, weil die Personen in der Regel keine Deployer sein werden) und somit eine Inbetriebnahme vorliegt.
5. Die Parametrisierung, Anbindung einer Datenbank und das Einbinden des AIS in die Website sollte richtigerweise noch nicht als Entwicklung gelten; klar ist die Rechtslage allerdings noch nicht. Das AIS wird allerdings unter dem eigenen Namen des Unternehmens in Betrieb genommen.
6. Es lässt sich vertreten, dass die Übernahme des Skripts dem Installieren einer schon fertig entwickelten Software gleichkommt und daher kein Entwickeln darstellt; zudem wird das Unternehmen es nicht unter dem eigenen Namen implementieren. Wird das Skript geändert, könnte die Qualifikation anders sein.

11. Durchsetzung

Der AIA setzt zur Durchsetzung seiner Vorgaben diverse Behörden auf Ebene der einzelnen Mitgliedsstaaten und der EU ein. So sollen GPAIM von der Europäischen Kommission beaufsichtigt werden, während die Aufsicht in Bezug auf AIS bei den Mitgliedstaaten liegt. Dabei wird wiederum zwischen dem System der Konformitätsbeurteilungen und -erklärungen und der eigentlichen Marktaufsicht unterschieden. Das System wird noch komplizierter durch den Umstand, dass dort, wo bereits eine Marktaufsicht besteht (bei regulierten Produkten und der Finanzindustrie), die Aufsicht grundsätzlich weiterhin durch die bisherigen Behörden erfolgen soll. Basiert ein AIS wiederum auf einem GPAIM desselben Providers (z.B. "ChatGPT"), so ist das neu zu schaffende, zentrale "AI Office" für die Marktaufsicht zuständig (es ist Teil der Europäischen Kommission). Wird ein solches AIS wiederum in einer Weise eingesetzt, dass es als HRAIS gelten muss, sind die nationalen Marktaufsichtsbehörden zuständig.

Den Marktaufsichtsbehörden werden durch den AIA weitreichende Untersuchungs- und Eingriffsbefugnisse eingeräumt. Das geht soweit, dass sie auch die Herausgabe des Source-Codes von AIS verlangen können. Sie müssen ein AIS jedenfalls dann untersuchen, wenn sie Grund zur Annahme haben, dass ein Risiko für die Gesundheit, die Sicherheit oder die grundlegenden Rechte der betroffenen Personen besteht oder ein AIS fälschlicherweise nicht als HRAIS klassifiziert ist. Auch formelle Verstösse (fehlende Deklaration etc.) müssen verfolgt werden, und selbstverständlich können beliebige betroffene Personen in der EU einen Verstoss gegen den AIA ihnen zur Anzeige bringen.

Die nationalen Marktaufsichtsbehörden sind naturgemäss auf ihr Territorium beschränkt. Unklar ist, welche Zuständigkeiten sie in Bezug auf Provider und Deployer in EU-Drittländern wie der Schweiz und den USA haben. Geraten die Marktaufsichtsbehörden der einzelnen Mitgliedstaaten in Bezug auf die zu treffenden Massnahmen miteinander in den Clinch, entscheidet die Europäische Kommission.

Der AIA sieht selbstverständlich auch administrative Bussen vor. Wie unter der DSGVO sollen sie "wirksam, verhältnismässig und abschreckend" sein. Insgesamt wirkt der Strafrahmen etwas milder als jener der DSGVO. Lediglich der Strafrahmen für verbotene KI-Praktiken geht mit 7% des weltweiten jährlichen Umsatzes oder, falls höher, EUR 35 Millionen deutlich darüber hinaus. Ansonsten liegt er bei maximal 3% oder EUR 15 Millionen oder in gewissen Fällen noch tiefer. Anders als unter der DSGVO wird betont, dass sie die Interessen von KMU einschliesslich Start-ups berücksichtigen sollen, was sich unter anderem daran zeigt, dass bei diesen der Strafrahmen am jeweils niedrigeren Wert ermittelt werden soll, wenn es um AIS geht. Wie unter der DSGVO kann und soll auch die fahrlässige Verletzung des AIA gebüsst werden.

12. Übergangsbestimmungen

Der AIA trat am 20. Tag nach seiner Publikation im Amtsblatt in Kraft, also am 1. August 2024. Seine Regelungen gelten grundsätzlich nach einer Übergangsfrist von 24 Monaten, d.h. ab dem 2. August 2026. Es sind jedoch folgende Ausnahmen vorgesehen:

• Die verbotenen KI-Praktiken sind bereits nach sechs Monaten verboten und ab diesem Zeitpunkt gilt auch die Pflicht zur Ausbildung von Mitarbeitenden ("AI Literacy"), d.h. ab dem 2. Februar 2025;
• Die Regelungen zu GPAIM und den Stellen, die Konformitätserklärungen ausstellen können, gelten bereits nach zwölf Monaten, d.h. ab dem 2. August 2025, ebenso die Regelungen zur Schaffung der im AIA Act vorgesehenen Behörden und Gremien (wie z.B. das AI Office) sowie die Sanktionsbestimmungen;
• Die Regelungen zu HRAIS aufgrund bestehender EU-Produkteregulierungen gelten für diese erst nach 36 Monaten, d.h. ab dem 2. August 2027.

Die Europäische Kommission hat im Rahmen des "AI Pact" die Wirtschaft aufgerufen, den AIA bereits vorgängig umzusetzen. Wir haben den Eindruck, dass etliche Unternehmen diesem Aufruf durchaus auch nachkommen möchten.

In übergangsrechtlicher Hinsicht gilt für verbotene KI-Praktiken, die zum Zeitpunkt des Inkrafttretens des AIA bestanden haben, keine Ausnahme.

Für HRAIS, die schon vor dem AIA auf den Markt gebracht wurden, gelten die neuen Regelungen nur und erst, wenn diese in wesentlicher Weise angepasst werden. Für GPAIM, die schon vor dem AIA auf den Markt gebracht wurden, müssen die Vorgaben des AIA innert zwei Jahren nach Inkrafttreten der jeweiligen Regeln erfüllt werden.

13. Schlussbemerkungen und Handlungsempfehlung

Ob der AI Act die hohen Erwartungen, die an diese KI-Regulierung gestellt werden, gerecht werden wird, muss sich noch zeigen. Der Erlass macht den Eindruck, dass der Gesetzgeber versucht hat, ein Arsenal an Abwehrmitteln gegen einen Feind in Position zu bringen, den er noch gar nicht wirklich kennt und von dem er auch nicht weiss, ob und wie er mit welcher Wirkung zuschlägt.

Es wird betont, dass der AI Act risikobasiert ausgestaltet ist. Dies scheint in der Tat der Fall zu sein, zumindest wenn man bedenkt, dass die Regulierung des Einsatzes "normaler" KI-Anwendungen (vielleicht überraschenderweise) sehr zahm bleibt und nur sehr wenige und spezifische "harte" Bestimmungen vorsieht. Wenn es aber um die als besonders riskant erachteten Anwendungen geht, wird aus dem Vollen geschöpft und den Anbietern viel zugemutet – und manches, für das noch gar keine anerkannten "best practices" bestehen, etwa im Bereich des Umgangs mit Daten für KI-Modelle. Diese Hoch-Risiko-Anwendungen sind zum Glück vergleichsweise eng und vor allem abschliessend definiert, auch wenn die Liste im Laufe der Zeit angepasst werden kann. Immerhin: Anbieter von bereits regulierten Produkten gemäss Anhang I und im Bereich von kritischen Infrastrukturen werden sich besonders intensiv mit ihnen auseinandersetzen müssen.

Für die meisten Unternehmen in der EU und zu einem geringeren Teil in der Schweiz wird der AI Act zwar Arbeit mit sich bringen, aber diese dürfte nicht ausufernd werden, wenn sie einigermassen im Griff haben, wo bei ihnen im Hause in eigenen und von Dritten genutzten Produkten und Dienstleistungen AIS zum Einsatz kommen. Sie werden dabei vor allem sicherstellen wollen, dass sie nicht in die "Minenfelder" der verbotenen oder als besonders riskant erachteten KI-Anwendungen geraten. Halten sie sich davon fern, dürften sie mit den wenigen verbleibenden Pflichten (vorwiegend zur Transparenz) aber vergleichsweise einfach zurechtkommen, und zwar selbst dann, wenn sie als "Provider" gelten, weil sie eine Anwendung selbst entwickelt oder weiterentwickelt haben. Eine Ausnahme mag die Pflicht zur Markierung von KI-generierten Inhalten sein; hier fehlen derzeit offenbar noch passende Standards und einsatzbereite Lösungen. Es darf gespannt erwartet werden, was die Marktführer hier anbieten werden, insbesondere für KI-generierte Texte.

Schweizer Unternehmen kommen um den AI Act ebenfalls nicht herum, auch wenn er für sie nur in reduziertem Masse gilt und wie im Falle der DSGVO nicht davon auszugehen ist, dass sie im Fokus der EU-Aufsichtsbehörden sein werden (allerdings hat beispielsweise die Schweizer Finanzmarktaufsicht FINMA bereits informell erläutert, dass sie von Schweizer Finanzinstituten die Einhaltung des AI Act erwartet, soweit er selbst auf sie Anwendung finden will). Zwar ist noch nicht in allen Fällen klar ist, ob der AI Act auf sie zur Anwendung kommt, weil bei seiner Formulierung Fehler gemacht worden sind. Es muss jedoch damit gerechnet werden, dass die Nutzung von AIS dann erfasst ist, wenn der Output bestimmungsgemäss an Empfänger in die EU geht oder sonst in der EU zum Einsatz kommt. Bietet ein Schweizer Unternehmen seinen Kunden im EU-Markt im Rahmen seiner Produkte, Dienstleistungen oder Website unter dem eigenen Namen KI-Funktionen an, die es mindestens teilweise selbst entwickelt hat, ist es ebenfalls erfasst. Solange es sich nicht um eine Hoch-Risiko-Anwendung handelt, sind die Pflichten allerdings wiederum moderat.

Daraus ergibt sich, dass für die meisten Unternehmen der Aufwand vor allem darin bestehen wird, zu verstehen, was in welcher Form an KI im eigenen Unternehmen zum Einsatz kommt, um rechtzeitig reagieren zu können, falls sich ein Projekt in Richtung eines der genannten Minenfelder bewegt. Geht es um eine Hoch-Risiko-Anwendung, werden Unternehmen vor allem gut beraten sein, die Rolle des Providers und daher Eigenentwicklungen eher zu vermeiden, weil dem Provider ungleich mehr Pflichten auferlegt sind als dem reinen Deployer. Ganz so einfach ist das allerdings nicht, weil davon auszugehen ist, dass bereits Massnahmen wie etwa ein Fine-Tuning als "Entwickeln" gilt. Hier wird sich zeigen, inwiefern die Herausforderung so gelöst werden kann, dass Technologie-Lieferanten und -Integratoren diese Pflichten als "Provider" übernehmen und dies von ihren Kunden so auch kommuniziert werden darf.

Das führt zu unserer Handlungsempfehlung: Unternehmen sollten alle eigenen und fremdgenutzten KI-Anwendungen erfassen und danach beurteilen, ob und in welcher Rolle (Provider, Deployer, Händler etc.) sie unter den AI Act fallen werden. Hierzu können im Markt verfügbare Hilfsmittel helfen. Dabei ist auch zu berücksichtigen, dass die Anwendung auf Schweizer Unternehmen beschränkt ist; es genügt z.B. nicht, dass ein Produkt oder Service aus der EU zum Einsatz kommt oder mit Daten von Personen aus der EU gefüttert wird. Wir empfehlen Unternehmen nicht nur im Hinblick auf den AI Act, ein Verzeichnis ihrer KI-Anwendungen zu führen. Hier können auch die Ergebnisse in Bezug auf den AI Act eingetragen werden.

Sind diese Abklärungen erfolgt, sind zum einen entsprechende Vorgaben zu erlassen, um sicherzustellen, dass diese KI-Anwendungen nicht ohne vorherige Prüfung in einer Weise genutzt werden, die zu einer anderen Qualifikation führt. Zum anderen sind in den Fällen, in denen der AI Act zur Anwendung kommt, die daraus resultierenden Pflichten zu ermitteln und ein Plan zu erstellen, wie diese in den vorgesehenen Fristen umgesetzt werden können. Für neue Vorhaben gilt diese Handlungsempfehlung analog. Bei vielen Schweizer Unternehmen hat sich zudem die Regelung eingebürgert, dass verbotene KI-Praktiken auch dann mittels Weisung im eigenen Unternehmen untersagt werden, wenn der AI Act formal nicht zur Anwendung gelangt.

Zum Schluss: Wird die Schweiz einen eigenen "AI Act" erlassen? Der Bundesrat will bis Ende 2024 verlautbaren, wo er gesetzgeberischen Handlungsbedarf im Bereich der künstlichen Intelligenz sieht. Mit einem Schweizer "AI Act" ist vorderhand aber nicht zu rechnen; eine direkte Übernahme erscheint nicht opportun, und für eine Schweizer Abwandlung dürfte der Aufwand für Verwaltung und Wirtschaft den Nutzen bei weitem übersteigen, ist doch damit zu rechnen, dass auch viele Schweizer Anbieter von relevanten Produkten den AI Act einhalten werden – die grossen internationalen Anbieter sowieso. Sinnvoll erscheinen jedoch die Anpassungen, die nötig sind, um den freien Warenverkehr mit der EU weiterhin sicherzustellen und Handelshemmnisse zu vermeiden, einschliesslich der gegenseitigen Anerkennung von Produktezulassungen.

David Rosenthal

Wir unterstützen Sie bei allen Fragen zu Recht und Ethik beim Einsatz von künstlicher Intelligenz. Wir reden nicht nur über KI, sondern setzen sie auch selbst ein. Weitere Hilfsmittel und Publikationen von uns zum Thema finden Sie hier.