Der EU AI Act trat im August 2024 in Kraft, wobei die Bestimmungen über einen Zeitraum von zwei bis drei Jahren schrittweise eingeführt werden [1][2]. Die meisten Compliance-Diskussionen in Unternehmen konzentrierten sich bisher darauf, ob ein Arbeitsablauf überhaupt in die Kategorie „hohes Risiko“ fällt. Bis Mitte 2026 verlagert sich die Diskussion auf eine praktischere Frage: Angesichts dessen, dass der Arbeitsablauf ist Im Anwendungsbereich: Welche Bereitstellungsarchitekturen erfüllen tatsächlich die Verpflichtungen des Bereitstellers, und welche tun dies stillschweigend nicht?

Bei der zweiten Frage hört die On-Premises-Bereitstellung auf, eine Stilfrage zu sein, und wird zu einer strukturellen Notwendigkeit.

Was der Gesetzgeber von Anwendern hochriskanter KI verlangt

Das Gesetz unterscheidet zwischen dem Anbieter eines KI-Systems und der Bereitsteller eines solchen [1]. Eine Bank, die eine Drittanbieter-LLM-API zur Bewertung von Kreditanträgen nutzt, ist der Betreiber, nicht der Anbieter. Betreiber von Hochrisikosystemen haben Verpflichtungen, darunter: Sicherstellung der menschlichen Aufsicht, Überwachung des Systembetriebs, Aufbewahrung von Protokollen für einen angemessenen Zeitraum, Aussetzung der Nutzung, wenn das System eine Gefahr für Grundrechte darstellt, und Nachweis dieser Fähigkeiten auf Anfrage.

Mehrere dieser Verpflichtungen sind unkompliziert, wenn der Betreiber die Laufzeitumgebung kontrolliert. Die Verpflichtung zum „Führen von Protokollen für einen angemessenen Zeitraum“ ist mechanisch einfach, wenn die Inferenz auf einem Server erfolgt, der dem Betreiber gehört, und die Protokolle im SIEM des Betreibers landen. Die Verpflichtung zum „Aussetzen der Nutzung“ ist ebenso trivial, wenn der Betreiber das Modell auf seiner eigenen Infrastruktur abschalten kann.

Die gleichen Verpflichtungen werden schwieriger, wenn die Inferenz über eine Cloud-LLM-API läuft, die der Bereitsteller nicht betreibt. Die Protokolle, die der Bereitsteller erstellen kann, sind auf das beschränkt, was der Anbieter bereitstellt. Die Aussetzung der Nutzung erfordert die Zusammenarbeit des Anbieters. Zeitgleich nachzuweisen, welche Daten durch das System geflossen sind, erfordert Vertrauen in die Pipeline des Anbieters.

Wo Cloud-LLM-APIs in der Regulierung stehen

Nichts davon macht Cloud-LLM-APIs nicht konform. Artikel für Artikel können Anbieter und Betreiber cloudbasierter KI die Verpflichtungen des Gesetzes erfüllen. Die Reibung ist operativ, nicht rechtlich: Der Betreiber muss über eine Anbietergrenze hinweg Compliance zusammenstellen, prüfen und nachweisen, oft für Workflows, die täglich Tausende von Inferenzvorgängen ausführen.

Der longitudinaler AI Index von Stanford HAI hat die entsprechende Verschiebung bei den Unternehmensausgaben verfolgt [3]: Das stärkste Wachstum von 2023 bis 2025 lag nicht bei generativer KI für allgemeine Zwecke, sondern bei den unterstützenden Werkzeugen – Beobachtbarkeit, Governance, Prompt-Protokollierung, Inhaltsklassifizierung, Jailbreak-Erkennung. Der Großteil dieser Ausgaben dient dazu, die Lücke zwischen dem, was Cloud-LLM-APIs nativ bereitstellen, und dem, was ein Betreiber im regulatorischen Kontext nachweisen muss, zu überbrücken.

Diese Lücke ist der strukturelle Vorteil, wenn die Inferenz auf Hardware läuft, die der Betreiber besitzt. Jede Frage „Ist das passiert?“ reduziert sich auf eine Frage, die der Betreiber aus seinen eigenen Protokollen beantworten kann.

Was On-Prem nicht kostenlos liefert

Drei Betreiberpflichten aus dem AI Act werden nicht automatisch durch eine On-Prem-Bereitstellung erfüllt, und es lohnt sich, sie explizit zu benennen:

  • Menschliche Aufsicht. Das Gesetz verlangt eine sinnvolle Aufsicht über Hochrisiko-KI, bei der Menschen Ausgaben interpretieren und eingreifen können. Das lokale Ausführen des Modells bringt keinen Menschen in den Prozess; das Workflow-Design tut das.
  • Überwachung von Drift und unsicherem Verhalten. Der Betreiber muss das System kontinuierlich überwachen. Die On-Prem-Bereitstellung macht die Technik einfach (die Daten sind lokal), aber die Richtlinie („Wie sieht Drift für diesen Workflow aus?“) muss trotzdem definiert werden.
  • Weitergabe von Anbieterpflichten. Wenn die On-Prem-Bereitstellung auf einem Drittanbietermodell basiert (z. B. ein Open-Weight-Modell unter einer nicht-kommerziellen Lizenz oder ein vom Anbieter als Binärdatei ausgeliefertes Modell), muss der Betreiber weiterhin die erforderlichen Offenlegungen des Anbieters bereitstellen.

Der strukturelle Vorteil von On-Prem liegt bei der Datenverarbeitung und Nachweisbarkeit, nicht bei der Richtlinie. Richtlinien müssen unabhängig vom Standort der GPU geschrieben und durchgesetzt werden.

Wie sich das mit den USA, Großbritannien und anderen Rechtsordnungen verträgt

Der EU AI Act ist der vorschriftsmäßigste der großen Rahmenwerke. Der US-amerikanische NIST AI RMF [4] verfolgt einen freiwilligen, rahmenbasierten Ansatz, und das OECD AI Policy Observatory [5] verfolgt, wie nationale Regierungen außerhalb der EU sich auf weitgehend ähnliche Prinzipien einigen (risikobasierte Aufsicht, Transparenzpflichten, Datenverarbeitungsregeln).

Für einen multinationalen Betreiber bedeutet das praktisch, dass die strengste Rechtsordnung die Architektur bestimmt. Wenn ein Workflow den EU AI Act für europäische Nutzer erfüllen muss, wird derselbe Workflow die Anforderungen der USA, Großbritanniens, Japans oder Singapurs nicht verletzen, wenn er nach dem EU-Standard gestaltet ist. Die Bereitstellung nach dem strengsten Standard zu gestalten – einschließlich der Fähigkeit des Betreibers, die Datenverarbeitung pro Anfrage nachzuweisen – macht On-Prem 2026 zur strukturell einfacheren Standardlösung für Unternehmens-KI.

Wie eine On-Prem-KI-Bereitstellung aussieht, die 2026 konform ist

Die Form, die wir ausliefern – und die Form, die Compliance-Prüfer von uns verlangen – ist:

  • Inference lokal beim Kunden. Entweder auf dem Gerät des Nutzers oder auf einem vom Kunden betriebenen Server. Keine Prompts verlassen den Perimeter.
  • Inhaltsfreie Prüfprotokolle. Jede administrative Aktion wird mit Zeitstempel + Akteur protokolliert; keine Prompts und keine Antworten erscheinen in der Prüfzeile. Die Prüfzeile ist der Beleg; der Inhalt verbleibt beim Bereitsteller und unterliegt dessen eigener Aufbewahrungsrichtlinie.
  • Identität über den IdP des Kunden. OIDC gegen Microsoft Entra ID oder Google Workspace, wobei die bestehenden Zugriffskontrollen des Bereitstellers unverändert gelten.
  • Kein vom Anbieter betriebener Inference-Tenant. Software Tailor betreibt die Modelllaufzeit nicht und erhält auf diesem Weg keine Prompts, Antworten oder Kundendokumente. Organisationsidentität, Lizenzierung, Richtlinien, Serverstatus, aggregierte Nutzung, Prüf- und Support-Daten können weiterhin eine Anbieter-Steuerungsebene nutzen und müssen als separate Abhängigkeit bewertet werden.

Diese letzte Eigenschaft der Inference kann von Cloud-LLM-APIs strukturell nicht nachgebildet werden. Sie macht ein On-Premises-Produkt nicht automatisch konform und beseitigt nicht die Notwendigkeit, dessen Steuerungsebene, Supportwege, Modell-Lieferkette und Kundenbetriebsverantwortlichkeiten zu bewerten.

Hintergrund dazu, wie wir das von Anfang an umgesetzt haben, finden Sie in Warum wir KI als installierbare Binärdateien ausliefern und nicht als Cloud-SaaS. Die Funktionen, die Audit, Identität und Richtlinienoberfläche implementieren, sind in AI Admin Console.

Quellen

  1. Europäische Kommission. „AI Act – Regulatorischer Rahmen für KI.“ https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai. Zugriff am 15.06.2026.
  2. Europäische Kommission. „AI Act tritt in Kraft.“ https://digital-strategy.ec.europa.eu/. Zugriff am 15.06.2026.
  3. Stanford HAI. „AI Index Report.“ https://aiindex.stanford.edu/. Zugriff am 15.06.2026.
  4. NIST. „AI Risk Management Framework (AI RMF 1.0).“ https://www.nist.gov/itl/ai-risk-management-framework. Zugriff am 15.06.2026.
  5. OECD AI Policy Observatory. „Nationale KI-Politiken.“ https://oecd.ai/. Zugriff am 15.06.2026.