KI-Systeme vs. KI-Modelle im AI Act – Wie viel „mehr“ ist notwendig, damit ein KI-Modell zum KI-System wird?

Ein Softwareanbieter stellt seinen Kunden über eine Schnittstelle Zugang zu großen Sprachmodellen bereit – “LLM as a Service”. Kein Frontend, keine Filter, keine eigene Logik: Der Prompt geht rein, der Output geht raus, alles Weitere entscheidet der Kunde. Ist das schon ein KI-System, das die Anforderungen des AI Act einhalten muss?

Zwei Regime, zwei Kostenstellen

Anbieter eines GPAI-Modells müssen nach Art. 53 KI-VO technische Dokumentation, Informationen für nachgelagerte Anbieter, eine Urheberrechts-Policy und eine Zusammenfassung der Trainingsdaten sicherstellen; bei systemischem Risiko kommen nach Art. 55 KI-VO Modellbewertungen und Vorfallmeldungen hinzu. Anbieter eines KI-Systems landen im Risikoklassen-Regime – bei Hochrisiko mit Risikomanagement, Konformitätsbewertung, CE-Kennzeichnung, QM-System und Registrierung. Wer sich in der falschen Kategorie wähnt, übersieht entweder erhebliche Pflichten oder setzt gar überflüssige Maßnahmen um.

Das Modell ist ein GPAI-Modell – und für sich genommen noch kein KI-System

Der unstrittige Teil: Marktübliche LLMs sind GPAI-Modelle. Erwägungsgrund 99 nennt große generative KI-Modelle ausdrücklich als “typisches Beispiel”; Erwägungsgrund 98 arbeitet mit einer Quasi-Fiktion ab einer Milliarde Parametern.

Ebenso klar ist die Gegenrichtung. Erwägungsgrund 97 stellt fest, dass KI-Modelle für sich genommen keine KI-Systeme darstellen – und formuliert dann den Satz, an dem sich alles Weitere entscheidet: “Damit KI-Modelle zu KI-Systemen werden, ist die Hinzufügung weiterer Komponenten, zum Beispiel einer Nutzerschnittstelle, erforderlich.”

Ist die API schon dieses “Mehr”?

Ob eine API schon dieses “mehr” sein kann, schweigt der Verordnungstext. Für ein KI-System spricht immerhin Anhang IV Nr. 1 lit. d KI-VO, der APIs als Form nennt, in der ein KI-System in Verkehr gebracht wird. Dagegen lassen sich aber drei tragende Argumente anführen:

• Wortlaut und Systematik. Erwägungsgrund 97 S. 4 zählt auf, wie GPAI-Modelle in Verkehr gebracht werden: über Bibliotheken, Anwendungsprogrammierschnittstellen (API), Download oder physische Kopie. Die GPAI-Leitlinien der Kommission nennen die Bereitstellung über eine API ebenfalls als Beispiel für das Inverkehrbringen eines Modells. Und Art. 92 Abs. 3 KI-VO erlaubt der Kommission, “über API […] Zugang zu dem betreffenden KI-Modell mit allgemeinem Verwendungszweck” anzufordern – der Gesetzgeber geht dort also selbstverständlich davon aus, dass hinter einer API ein Modell liegt.
• Nutzerschnittstelle ist nicht Anwendungsprogrammierschnittstelle. Der deutsche Begriff in Erwägungsgrund 97 ist eine unglückliche Übersetzung; gemeint ist die Benutzeroberfläche, was z.B. die italienische Fassung (“un’interfaccia utente”) bestätigt. Nach ständiger EuGH-Rechtsprechung ist ohnehin keine Sprachfassung allein maßgeblich. Erwägungsgrund 97 verlangt also ein User Interface – und grenzt sich damit gerade von der API ab, die derselbe Erwägungsgrund drei Sätze zuvor beim Modell verortet.
• Die Funktion. 3 Nr. 1 KI-VO verlangt Ausgaben, die “physische oder virtuelle Umgebungen beeinflussen können”. Die Kommissionsleitlinien lesen das so, dass KI-Systeme nicht passiv sind, sondern aktiv auf ihre Einsatzumgebung wirken. Eine reine Inferenz-API tut genau das nicht: Sie rechnet und gibt zurück. Ob der Output angezeigt, gespeichert oder verworfen wird, entscheidet allein der Aufrufer. Hinzu kommt, dass erst die Integration in ein System eine Zweckbestimmung nach Art. 3 Nr. 12 KI-VO begründet – ein Modell hinter einer API ist so zweckoffen wie eines ohne.

Die überwiegende Literatur geht in eine ähnliche Richtung – meist ohne echte Argumentation. Der reine API-Zugang zu einem LLM ist mit guten Argumenten also kein KI-System. Anhang IV Nr. 1 lit. d KI-VO steht dem nicht entgegen – dort ist die API nur ein Beispiel, und selbstverständlich kann auch ein System über eine API vertrieben werden.

Der Kipppunkt: Weitere Elemente

Die Einordnung trägt nur so lange, wie sich der Dienst auf eine technische Betriebsleistung reduzieren lässt. Jede Funktion darüber hinaus ist ein Kandidat für die “weiteren Komponenten” aus Erwägungsgrund 97:

• Input-/Output-Filtering, Guardrails, Content-Moderation
• Security-Features, die Prompt oder Antwort verändern
• Model Routing, vorgelagerte System-Prompts, Retrieval, Tool-Calling-Orchestrierung

Jede dieser Funktionen ist zunächst eine Produktentscheidung, keine juristische. Genau das ist das Risiko: Der Sprung ins Systemregime passiert im Sprint-Planning, nicht in der Rechtsabteilung.