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 "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.

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 unter seiner Aufsicht ("under its authority") einsetzt. Ausgenommen sind jene Personen, die ein AIS nur für persönliche, nicht berufliche Zwecke einsetzen (wobei auch hier die Gesetzesredaktion unsorgfältig erfolgte – die Ausnahme existiert gleich auf zwei Ebenen, ist aber (zumindest noch) 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. 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.

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, sobald der 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 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.
• 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.
• 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 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: 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. Es gibt keinen Bezug zwischen dem Ort der Bearbeitung bzw. des Providers und der betroffenen Personen. 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 wird auch der Schutz der Demokratie, des Rechtssystems und der Umwelt, aber auch diese rechtfertigen nicht wirklich 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.

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 auf den Standpunkt stellen, dass sie nicht erfasst sind, wenn sie das AIS nicht in der EU auf den Markt oder dort zum Einsatz bringen.

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 zur Eigennutzung ("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 Finetuning des Modells eines AIS erfasst, die Verwendung von "Retrieval Augmented Generation" (RAG) hingegen nicht. 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 Markenzeichen zum Einsatz gebracht gilt ("under its own name or trademark"). 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 "Distributor" oder allenfalls sogar "Importer" werden. Dies würde eine Reihe von Sonderpflichten mit sich bringen. Während X die Qualifikation als Importer (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 Distributor. Hier kann immerhin vertreten werden, dass der Begriff voraussetzt, dass das Unternehmen Teil der in der Definition erwähnten "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 Distributor tut.

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 in der EU zum Einsatz bringt 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 unter ihrer Aufsicht ("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 zum Einsatz für eigene Zwecke in der EU ("for own use in the Union"); um das zu erfüllen, wird es vermutlich genügen, 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. Zum anderen lässt es das alternative Kriterium zur Provider-Qualifikation "making available on the market" genügen, dass ein AIS "for … use on the Union market in the course of a commercial activity" geliefert worden ist. Dieser Fall liegthier 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 sehr spezifisch:

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 einen erheblichen Schaden verursacht oder verursachen kann
2. Ausnutzen von Schwächen von Personen aufgrund ihres Alters, einer Behinderung oder einer besonderen sozialen oder wirtschaftlichen Situation, um ihr Verhalten in einer Weise zu beeinflussen, die einen erheblichen Schaden verursacht oder verursachen kann
3. Biometrische Klassifizierung, um Rückschlüsse auf die Rasse, die politische Meinung, die Gewerkschaftszugehörigkeit, die religiöse oder philosophische Überzeugung, das Sexualleben oder die sexuelle Ausrichtung einer Person zu ziehen (d. h. auf der Grundlage biometrischer Daten)
4. Bewertung oder Klassifizierung von Personen über einen bestimmten Zeitraum hinweg auf der Grundlage ihres Sozialverhaltens oder bekannter, abgeleiteter oder vorhergesagter Persönlichkeitsmerkmale, falls diese soziale Bewertung zu einer nachteiligen oder ungünstigen Behandlung führt, die in keinem Zusammenhang mit dem Kontext der Daten steht oder aber 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, der Vorbeugung spezifischer Bedrohungen im Falle erheblicher und unmittelbar bevorstehender Bedrohungen oder der Lokalisierung oder Identifizierung von Verdächtigen bestimmter definierter Kategorien von Straftaten, 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
8. Das Ziehen von Rückschlüssen auf Emotionen (einschliesslich Absichten) von Personen am Arbeitsplatz oder in Bildungseinrichtungen, es sei denn, dies geschieht aus medizinischen oder sicherheitstechnischen Gründen

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 schummeln, ist vom Verbot der Erkennung von Emotionen und Absichten nicht erfasst (allerdings eine Hoch-Risiko-Anwendung).

Wer also beispielsweise 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).

Ein weiteres Beispiel: Bei der verbotenen Praktik Nr. 1 genügt es nicht, dass Personen mittels KI manipuliert werden. Es muss dies auch zum 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 die "üblichen und legitimen kommerziellen Praktiken" im Bereich der Werbung, die auch sonst rechtmässig sind, 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 zu entgegenzuwirken, müsste auch hier ein System eingesetzt werden, dass nicht autonom urteilt, sondern nach klar vordefinierten Regeln 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).

7. Hoch-Risiko KI-Systeme

Als "Hoch-Risiko KI-System" (HRAIS) gelten zwei Arten von AIS. Zunächst sind es alle im Prinzip jene AIS, welche ein Produkt nach EU-Recht sind, für welche vor dem Vertrieb oder Einsatz eine Konformitätsbewertung durch einen Dritten erforderlich sind, oder aber als Sicherheitskomponente in diesen eingesetzt werden (als Sicherheitskomponente gelten auch solche AIS, deren Ausfall zu einer Gefährdung der Gesundheit oder Sicherheit von Mensch oder Besitz führen). Das hierfür relevante EU-Recht ist in einem Anhang des AIA aufgeführt. Die Anforderungen des AIA ergänzen in diesen Fällen die Regeln, die für diese Produkte ohnehin gelten.

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 und biometrische Kategorisierung hinausgeht und sensible oder geschützte Merkmale verwendet oder daraus ableitet
2. Erkennung von Emotionen oder Absichten auf der Grundlage biometrischer Daten mittels KI
3. KI soll als Sicherheitskomponente bei der Verwaltung und dem Betrieb kritischer Infrastrukturen, im Strassenverkehr oder bei der Versorgung mit Wasser, Gas usw. eingesetzt werden
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 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 Personen verwendet wird oder (ii) KI verwendet wird, um Entscheidungen zu treffen, die sich auf die Beschäftigungsbedingungen auswirken (z.B. Entscheidungen über Beförderungen oder die Beendigung des Arbeitsverhältnisses), die Leistung zu bewerten oder Arbeit auf der Grundlage von Verhalten oder anderen persönlichen Merkmalen zuzuweisen
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, 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
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önlichkeitsmerkmale, Charakteristika oder frühere kriminelle Verhaltensweisen einer Person 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, verwendet werden soll, (iii) KI zur 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 Aufspüren, Erkennen oder Identifizieren 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 Erforschung und Auslegung von Fakten und Gesetzen 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.

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 unser Werkzeug GAIRA);
• Die Daten, die für Training, Überprüfung und Tests verwendet werden, müssen bestimmten Qualitätskriterien genügen;
• Es muss eine detaillierte technische Dokumentation zum HRAIS erstellt und nachgeführt werden;
• 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 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;
• 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, müssen Provider:

• Eine entsprechende Dokumentation führen;
• Ein Qualitätsmanagementsystem vorweisen;
• Die von ihren HRAIS im Einsatz generierten Logs aufbewahren (soweit sie sie haben);
• 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; und
• 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, der über die nötigen Unterlagen verfügt, damit die EU-Behörden darauf zugreifen können. Pikant: 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" 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 Distributor) 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;
• Beim Einsatz von HRAIS am Arbeitsplatz die betroffenen Mitarbeitenden darüber informiert sind; und
• 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).

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 grundlegenden Rechte oder andere öffentliche 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 grundlegenden 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 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") 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", 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 (Programmierschnittstelle) 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 auf den EU-Markt oder setzt er sie bei sich ein, gilt allerdings auch das Modell auf den EU-Markt gebracht.

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 auf den Markt bringen würde; das Kriterium des Einsatzes 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 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.
• Sie müssen interne Regeln 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 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. Es ist schon unabhängig vom AIA nicht völlig klar, was die TDM-Regelung für das Trainieren von KI-Modellen bedeutet. Mit der neuen Bestimmung des AIA wird es noch schwieriger, KI-Modelle zu trainieren, denn wer später ein GPAIM in der EU anbieten will, muss das EU-Urheberrecht beim Training seines Modells auch dann einhalten, wenn es diesem Recht gar nicht unterliegt. Es soll also 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 wird 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.
• Sie müssen öffentlich in summarischer Form darlegen, welche Inhalte sie für das Training ihrer Modelle benutzt haben.

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 "systemische Risiken" mit sich bringen, gelten noch zusätzliche Vorgaben. Aus Sicht des Gesetzgebers bringt ein GPAIM dann systemische Risiken mit sich, wenn es besonders mächtig ist, was wiederum daran gemessen wird, welche Rechenleistung für dessen Erstellung zum Einsatz gekommen ist (10 hoch 25 FLOPS also "Rechenoperationen mit Bruchzahlen"). Die grossen LLM wie etwa GPT4 von OpenAI dürften nach verbreiteter Annahme als solche GPAIM mit systemischen Risiken gelten (die genauen Zahlen sind allerdings nicht bekannt; es wird sich noch zeigen müssen, welche genau darunter fallen werden). Der AIA ist allerdings offen formuliert; auch andere GPAIM können zu GPAIM mit systemischen Risiken 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, über eben diesen Umstand informiert werden, ausser es ist dies aus Sicht eines verständigen Anwenders offenkundig.
• die von einem AIS generierten Text-, Ton-, Video- und Bildinhalte als KI-generiert oder KI-manipuliert markiert sind. Diese Markierung muss maschinenlesbar sein. 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, 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, die lediglich beim "normalen" Bearbeiten von Inhalten unterstützen, sofern diese Tools die Inhalte nicht wesentlich verändern. Anbieter von automatischen Übersetzungsdiensten wie "DeepL" werden von dieser Ausnahme zu profitieren versuchen; sie basieren vollständig auf generativer KI.

Deployer müssen sicherstellen, dass:

• betroffene Personen informiert werden, wenn sie bei diesen AIS zur Erkennung von Emotionen oder Absichten oder zur Klassifizierung anhand biometrischer Merkmale eingesetzt werden und dabei Personendaten bearbeitet werden.
• 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.
• 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 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 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 auf den Markt bringt oder zum Einsatz bringt.

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").  

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 Mehrheit der Fälle in der Praxis. Dies, obwohl in zahlreichen internationalen Initiativen, Erklärungen und sogar im Entwurf 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.
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, jedenfalls solange die Outputs der KI ihnen nicht, wie hier, zugesandt werden.
4. Der Chatbot ist ein AIS, der auch von Personen genutzt werden soll, die sich in der EU befinden. Damit wird das AIS auch in der EU benutzt bzw. wird hierfür bereitgestellt.
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.
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.

*Die Beispiele sind als generalisierte, simplifizierte Illustration des Konzepts zu verstehen, d.h. im konkreten Einzelfall kann die Beurteilung eine andere 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. 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 Mitgliedsstaaten 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 tritt am 20. Tag nach seiner Publikation im Amtsblatt in Kraft. Seine Regelungen gelten jedoch grundsätzlich erst 24 Monate später, dies mit folgenden Ausnahmen:

• Die verbotenen KI-Praktiken sind bereits nach sechs Monaten verboten;
• Die Regelungen zu GPAIM und den Stellen, die Konformitätserklärungen ausstellen können, gelten bereits nach zwölf Monaten;
• Die Regelungen zu HRAIS aufgrund bestehender EU-Produkteregulierungen, gelten erst nach 36 Monaten.

Die Europäische Kommission hat im Rahmen des "AI Pact" die Wirtschaft aufgerufen, den AIA bereits vorgängig umzusetzen.

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 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. 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.

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, Distributor etc.) sie unter den AI Act fallen werden. Ist das getan, 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.

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.