EU AI Act: Wie Sie Ihre KI-Anwendungsfälle einordnen, bevor Sie einen Juristen fragen.

Kein Rechtsrat. Dieser Beitrag ist eine technische Arbeitsanleitung, keine Rechtsberatung. Wir sind Softwareentwickler, keine Juristen. Alles, was hier steht, dient dazu, Ihre eigenen Anwendungsfälle so zu sortieren und zu dokumentieren, dass eine anschließende rechtliche Bewertung schnell und günstig wird. Für die verbindliche Einordnung Ihres Falls brauchen Sie eine Rechtsanwältin oder einen Rechtsanwalt mit Schwerpunkt IT- und Datenschutzrecht. Verbindlich ist ausschließlich der Text der Verordnung (EU) 2024/1689 in der jeweils geltenden Fassung.

Das Grundprinzip: reguliert wird der Anwendungsfall, nicht die Technologie

Die häufigste Fehlannahme, die uns in Gesprächen begegnet, lautet: „Wir setzen KI ein, also sind wir betroffen.“ So funktioniert die Verordnung nicht.

Der EU AI Act verfolgt einen risikobasierten Ansatz. Nicht das Modell entscheidet über die Pflichten, sondern das, wofür Sie es einsetzen. Dasselbe Sprachmodell kann in einem Anwendungsfall praktisch pflichtfrei sein und in einem anderen einen umfangreichen Pflichtenkatalog auslösen. Wer nach Technologie fragt, bekommt keine brauchbare Antwort. Wer nach Anwendungsfall fragt, schon.

Daraus folgt eine für die Praxis sehr angenehme Konsequenz: Die erste Arbeit ist keine juristische, sondern eine handwerkliche. Sie besteht darin, überhaupt erst einmal aufzuschreiben, welche KI-Anwendungsfälle es in Ihrem Unternehmen gibt — und dazu braucht es keine Kanzlei, sondern zwei Nachmittage und jemanden, der die Systeme kennt.

Die vier Risikoklassen, kurz erklärt

Die Verordnung ordnet Anwendungsfälle in vier Stufen ein.

Unannehmbares Risiko. Bestimmte Praktiken sind untersagt. Landet ein Vorhaben hier, gibt es nichts zu dokumentieren und nichts abzusichern — es darf schlicht nicht umgesetzt werden. Die genaue Aufzählung steht im Verordnungstext. [ZU PRÜFEN: abschließende Liste der verbotenen Praktiken.]

Hohes Risiko. Erlaubt, aber mit einem umfangreichen Pflichtenkatalog verbunden: Risikomanagement über den Lebenszyklus, Anforderungen an Daten und Datenqualität, technische Dokumentation, Protokollierung, wirksame menschliche Aufsicht sowie Anforderungen an Genauigkeit, Robustheit und Sicherheit. Für Softwareprojekte ist das der praktisch relevanteste Fall, weil er die Architektur beeinflusst — nachträglich lässt sich Protokollierung oder menschliche Aufsicht nur teuer einbauen. [ZU PRÜFEN: welche Anwendungsbereiche als hochriskant gelten und welche Pflichten im Einzelnen zugeordnet sind.]

Begrenztes Risiko. Hier greifen vor allem Transparenzpflichten. Der Grundgedanke: Menschen sollen erkennen können, dass sie es mit einem KI-System zu tun haben oder dass ein Inhalt maschinell erzeugt oder bearbeitet wurde. Ein Chatbot im Kundendienst und maschinell erzeugte Inhalte fallen typischerweise in diese Denkrichtung.

Minimales Risiko. Der weitaus größte Teil dessen, was Unternehmen tatsächlich mit KI machen — Textentwürfe, Klassifikation eingehender Dokumente, Suchunterstützung über interne Unterlagen, Zusammenfassungen. Aus der Verordnung folgen hier keine besonderen Pflichten. Das heißt ausdrücklich nicht, dass keine anderen Regeln gelten: Datenschutzrecht, Urheberrecht, Arbeitsrecht und Ihre eigenen vertraglichen Zusagen gegenüber Kunden bleiben davon unberührt.

Zusätzlich gibt es Regelungen für Modelle mit allgemeinem Verwendungszweck, die vor allem die Anbieter solcher Modelle adressieren, mit Auswirkungen auf die Informationen, die Sie als Einsetzer erhalten. [ZU PRÜFEN: Umfang der Pflichten für Modelle mit allgemeinem Verwendungszweck und was davon an einsetzende Unternehmen durchschlägt.]

Warum die Fristen hier nicht stehen

Die Verordnung tritt gestaffelt in Kraft: Unterschiedliche Pflichtenbündel werden zu unterschiedlichen Zeitpunkten wirksam. In Umlauf sind dazu viele Datumsangaben, die sich teilweise widersprechen, weil sie aus unterschiedlichen Entwurfsständen und Sekundärquellen stammen.

Wir schreiben deshalb keine Termine in diesen Beitrag. Eine falsche Frist auf einer Website, die für Verlässlichkeit steht, ist schlimmer als gar keine Frist. [ZU PRÜFEN: verbindliche Geltungszeitpunkte je Pflichtenbündel sowie Stand der österreichischen Begleitgesetzgebung und der zuständigen Aufsichtsstelle.]

Für die Planung ist das weniger dramatisch, als es klingt. Die Arbeit, die Sie ohnehin machen müssen — Bestandsaufnahme, Einordnung, Dokumentation — ist unabhängig vom Datum sinnvoll und lässt sich sofort beginnen.

Arbeitsanleitung: So ordnen Sie Ihre Anwendungsfälle ein

Schritt 1: Inventar erstellen

Schreiben Sie jeden Anwendungsfall auf, bei dem in Ihrem Unternehmen ein KI-System beteiligt ist. Denken Sie dabei breiter als an das offizielle KI-Projekt: Auch die Zusammenfassungsfunktion im Ticketsystem, die Textvorschläge im Vertriebswerkzeug und das Übersetzungsmodul im Onlineshop gehören dazu. Erfahrungsgemäß findet die zweite Runde dieses Inventars mehr als die erste.

Halten Sie je Fall fest: Wer nutzt es? Auf welche Daten greift es zu? Was passiert mit dem Ergebnis?

Schritt 2: Die Entscheidungsfrage stellen

Für jeden Fall gilt eine einzige Leitfrage: Welche Wirkung hat das Ergebnis auf Menschen?

Beantworten Sie diese Frage in drei Abstufungen:

• Das Ergebnis ist ein Vorschlag, den ein Mensch prüft und verantwortet. Der Vorschlag wird routinemäßig geprüft, nicht nur formal abgenickt.
• Das Ergebnis wirkt unmittelbar, ohne dass jemand dazwischensteht.
• Das Ergebnis betrifft Rechte, Chancen oder Zugang von Menschen — etwa bei Auswahlentscheidungen, Zuteilungen oder Bewertungen von Personen.

Je weiter unten Sie landen, desto wahrscheinlicher ist eine höhere Risikoklasse und desto dringender die rechtliche Prüfung.

Schritt 3: Rollen klären

Bauen Sie das System selbst, oder setzen Sie ein zugekauftes ein? Die Verordnung ordnet unterschiedlichen Rollen unterschiedliche Pflichten zu. Wichtig für die Praxis: Wer ein zugekauftes System unter eigenem Namen und für eigene Zwecke betreibt, ist nicht automatisch aus der Verantwortung. [ZU PRÜFEN: exakte Rollendefinitionen und Zuordnung der Pflichten.]

Prüfen Sie außerdem, was Ihr Anbieter Ihnen vertraglich zusichert und welche Unterlagen er bereitstellt. Wenn ein Anbieter dazu nichts sagen kann, ist das eine Information über den Anbieter.

Schritt 4: Transparenz zuerst umsetzen

Transparenz ist der Teil, der fast immer zutrifft, wenig kostet und sofort umsetzbar ist. Konkret:

• Kennzeichnen Sie erkennbar, wenn Nutzer mit einem KI-System interagieren.
• Kennzeichnen Sie maschinell erzeugte oder wesentlich bearbeitete Inhalte.
• Schreiben Sie intern auf, welches Modell in welchem Anwendungsfall verwendet wird und welche Daten es sieht.

Diese drei Punkte sind ohnehin gute Praxis. Sie machen Sie unabhängig von der Klassifizierung besser prüfbar.

Schritt 5: Dokumentation als Dauerzustand anlegen

Was Sie in Schritt 1 bis 4 erarbeitet haben, gehört in ein Dokument, das gepflegt wird — nicht in eine einmalige Präsentation. Sinnvoller Mindestinhalt je Anwendungsfall: Zweck, verwendetes Modell, Datenquellen, wer das Ergebnis prüft, welche Protokolle mitlaufen, wer fachlich verantwortlich ist, wann zuletzt überprüft.

Wenn Sie diese Tabelle haben, wird die anschließende juristische Bewertung deutlich kürzer und damit günstiger. Ohne sie beginnt jede Beratung mit derselben Bestandsaufnahme — nur zum Stundensatz einer Kanzlei.

Drei Fehleinschätzungen, die uns regelmäßig begegnen

„Wir haben gar keine KI im Einsatz.“ In fast jedem Unternehmen, das uns das sagt, findet sich beim zweiten Hinsehen mindestens eine eingekaufte Funktion, die auf einem Modell beruht — eingebettet in ein Ticketsystem, ein Dokumentenarchiv oder ein Vertriebswerkzeug. Der Anwendungsfall ist dann meist harmlos. Er gehört trotzdem ins Inventar, denn eine Bestandsaufnahme, die nur das offizielle KI-Projekt kennt, ist keine.

„Wir kaufen ein, also haftet der Anbieter.“ Der Anbieter trägt bestimmte Pflichten. Wer ein zugekauftes System in eigenem Namen einsetzt, trägt aber ebenfalls Verantwortung — insbesondere für den Zweck, für die Datenauswahl und für die Frage, ob Ergebnisse tatsächlich von Menschen geprüft werden. Vertraglich lässt sich einiges regeln, aber nicht alles wegdelegieren.

„Das machen wir, wenn die Fristen näher rücken.“ Die Bestandsaufnahme ist der zeitaufwendige Teil, und sie hängt nicht am Termin. Wer sie vorzieht, hat bei jeder späteren Anforderung — regulatorisch, vertraglich oder im Rahmen einer Kundenprüfung — bereits die Grundlage. Wer sie aufschiebt, macht sie später unter Zeitdruck.

Was das technisch bedeutet

Aus der Verordnung lassen sich einige Anforderungen ableiten, die man in der Architektur berücksichtigen sollte, weil sie nachträglich teuer werden:

Protokollierung von Anfang an. Welche Eingabe führte zu welcher Ausgabe, mit welchem Modell, zu welchem Zeitpunkt? Wer das erst nachrüstet, wenn es verlangt wird, hat für die Vergangenheit keine Daten.

Menschliche Aufsicht als Funktion, nicht als Absichtserklärung. Eine Prüfschleife, die im System nicht vorgesehen ist, findet nicht statt. Eine Prüfschleife, die einen Menschen zwingt, hundert Vorschläge pro Stunde durchzuwinken, ist ebenfalls keine.

Modellaustausch ohne Umbau. Wenn ein Modell wechselt, ändert sich das Verhalten. Ein System, das an genau ein Modell gebunden ist, ist regulatorisch und wirtschaftlich unbeweglich.

Datenherkunft nachvollziehbar halten. Welche Daten fließen in welchen Anwendungsfall, mit welcher Rechtsgrundlage, mit welcher Löschfrist? Das ist ohnehin eine Datenschutzfrage — hier fallen beide Themen zusammen.

Wie das konkret aussieht und welche Betriebsmodelle wir dafür anbieten, steht auf unserer Seite zur KI-Integration. Wenn Sie mit einer geordneten Bestandsaufnahme starten wollen, ist die KI-Potenzialanalyse der passende Einstieg: eine Woche, Festpreis, mit einer priorisierten Liste am Ende — einschließlich der Anwendungsfälle, von denen wir abraten.