KI-Trends Veröffentlicht 2026-06-15 · 7 Min. Lesezeit

EU AI Act 2026: Was On-Premises-Bereitstellung an der Compliance ändert

Die Betreiberpflichten für Hochrisiko-Systeme des EU AI Act greifen schrittweise bis Ende 2026. On-Premises-Bereitstellung umgeht die Verordnung nicht – aber sie verändert, welche Pflichten praktikabel zu erfüllen sind und welche von Cloud-SaaS gar nicht erfüllt werden können.

Der EU AI Act ist im August 2024 in Kraft getreten, mit Bestimmungen, die innerhalb eines Zeitraums von zwei bis drei Jahren schrittweise greifen ^[1]^[2]. Die meisten Compliance-Gespräche im Unternehmensumfeld haben sich bislang darauf konzentriert, ob ein Workflow überhaupt in die Kategorie „hochriskant" fällt. Mitte 2026 verschiebt sich das Gespräch zu einer praktischeren Frage: Wenn der Workflow in den Anwendungsbereich fällt – welche Bereitstellungsarchitekturen erlauben Ihnen tatsächlich, die Betreiberpflichten zu erfüllen, und welche eben leise nicht?

Genau diese zweite Frage ist der Punkt, an dem On-Premises-Bereitstellung aufhört, eine stilistische Vorliebe zu sein, und zu einem strukturellen Fit wird.

Was die Verordnung von Betreibern hochriskanter KI verlangt

Die Verordnung unterscheidet zwischen dem Anbieter eines KI-Systems und dem Betreiber ^[1]. Eine Bank, die eine Drittanbieter-LLM-API zur Bewertung von Kreditanträgen einsetzt, ist der Betreiber, nicht der Anbieter. Betreiber von Hochrisiko-Systemen tragen Pflichten, darunter: Sicherstellung menschlicher Aufsicht, Monitoring des Systembetriebs, Aufbewahrung von Logs für einen angemessenen Zeitraum, Aussetzung der Nutzung bei Risiken für Grundrechte und Nachweis dieser Fähigkeiten auf Anfrage.

Mehrere dieser Pflichten sind unkompliziert, wenn der Betreiber die Laufzeit kontrolliert. Die Pflicht zur „Aufbewahrung von Logs für einen angemessenen Zeitraum" ist mechanisch einfach, wenn die Inferenz auf einem Server stattfindet, der dem Betreiber gehört, und die Logs im SIEM des Betreibers landen. Die Pflicht zur „Aussetzung der Nutzung" ist ähnlich trivial, wenn der Betreiber das Modell auf seiner eigenen Infrastruktur abschalten kann.

Dieselben Pflichten werden schwieriger, wenn die Inferenz auf einer Cloud-LLM-API läuft, die der Betreiber nicht betreibt. Die Logs, die der Betreiber erzeugen kann, sind auf das beschränkt, was der Anbieter offenlegt. Eine Aussetzung der Nutzung erfordert die Mitwirkung des Anbieters. Zeitnahe Nachweise darüber, welche Daten durch das System geflossen sind, erfordern Vertrauen in die Pipeline des Anbieters.

Wo Cloud-LLM-APIs in der Verordnung stehen

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

Der längsschnittliche AI Index von Stanford HAI hat die entsprechende Verschiebung in den Unternehmensausgaben dokumentiert ^[3]: Das stärkste Wachstum 2023–2025 lag nicht bei allgemeiner generativer KI, sondern bei den begleitenden Werkzeugen – Observability, Governance, Prompt-Logging, Inhaltsklassifikation, Jailbreak-Erkennung. Der Großteil dieser Ausgaben existiert, um die Lücke zwischen dem, was Cloud-LLM-APIs nativ offenlegen, und dem, was ein Betreiber in einem regulatorischen Kontext nachweisen muss, zu überbrücken.

Diese Lücke ist der strukturelle Vorteil, Inferenz auf Hardware laufen zu lassen, die dem Betreiber gehört. Jede „Ist das passiert?"-Frage reduziert sich auf eine Frage, die der Betreiber aus seinen eigenen Logs beantworten kann.

Was On-Premises Ihnen nicht geschenkt liefert

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

Menschliche Aufsicht. Die Verordnung verlangt eine sinnvolle Aufsicht über Hochrisiko-KI, bei der Menschen Ergebnisse interpretieren und eingreifen können. Das Modell lokal laufen zu lassen, setzt keinen Menschen in die Schleife; das tut das Workflow-Design.
Monitoring auf Drift und unsicheres Verhalten. Der Betreiber muss das System kontinuierlich überwachen. On-Premises-Bereitstellung macht die Verrohrung trivial (die Daten sind lokal), aber die Richtlinie („Wie sieht Drift für diesen Workflow aus?") muss weiterhin definiert werden.
Durchgereichte Anbieterpflichten. Wenn die On-Premises-Bereitstellung auf einem Drittanbieter-Modell aufgebaut ist (z. B. ein Open-Weight-Modell unter einer nicht-kommerziellen Lizenz oder ein als Binärdatei ausgeliefertes Anbietermodell), muss der Betreiber dennoch die vom Anbieter geforderten Offenlegungen sichtbar machen.

Der strukturelle Vorteil von On-Premises liegt auf der Datenverarbeitungs- und Nachweisbarkeitsachse, nicht in der Richtlinie. Richtlinien müssen geschrieben und durchgesetzt werden, unabhängig davon, wo die GPU steht.

Wie das mit den USA, dem UK und anderen Jurisdiktionen zusammenspielt

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

Für einen multinationalen Betreiber bedeutet das praktisch: Die strengste Jurisdiktion bestimmt die Architektur. Wenn ein Workflow für europäische Nutzer den EU AI Act erfüllen muss, scheitert derselbe Workflow nicht an US-amerikanischen, britischen, japanischen oder singapurischen Pflichten, wenn er gegen die EU-Latte konzipiert ist. Die Bereitstellung gegen die strengste Latte zu konzipieren – einschließlich der Fähigkeit des Betreibers, die Datenverarbeitung pro Anfrage nachzuweisen – ist das, was On-Premises 2026 zum strukturell einfacheren Standard in der Unternehmens-KI macht.

Wie eine für 2026-konforme Compliance bereite On-Premises-KI-Bereitstellung aussieht

Die Form, die wir ausliefern – und die Form, nach der die Compliance-Prüfer fragen, mit denen wir arbeiten – ist:

Inferenz lokal beim Kunden. Entweder auf dem Gerät der Anwenderin oder auf einem vom Kunden betriebenen Server. Keine Prompts verlassen den Perimeter.
Inhaltsfreie Audit-Logs. Jede administrative Aktion wird mit Zeitstempel und Akteur protokolliert; im Audit-Eintrag erscheinen keine Prompts und keine Antworten. Der Audit-Eintrag ist der Nachweis; der Inhalt verbleibt beim Betreiber 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 Betreibers unverändert gelten.
Kein anbieterseitiger Tenant. Der Anbieter (wir) betreibt die Laufzeit nicht, sieht die Daten nicht und ist kein Ausfallpunkt für die Compliance-Position des Betreibers.

Diese letzte Eigenschaft ist diejenige, die Cloud-LLM-APIs strukturell nicht replizieren können – und sie ist der Grund, warum On-Premises-Bereitstellung 2026 das dominierende Muster in der regulierten Unternehmensecke des Marktes ist.

Hintergrund dazu, wie wir dies von Anfang an strukturiert haben, finden Sie in Warum wir KI als installierbare Binärdateien ausliefern, nicht als Cloud-SaaS. Die Funktionen, die die Audit-, Identitäts- und Richtlinienoberfläche umsetzen, liegen in AI Admin Console.

Quellen

Europäische Kommission. „AI Act — Regulatory framework on AI." digital-strategy.ec.europa.eu. Abgerufen am 2026-06-15.
Europäische Kommission. „AI Act enters into force." digital-strategy.ec.europa.eu. Abgerufen am 2026-06-15.
Stanford HAI. „AI Index Report." aiindex.stanford.edu. Abgerufen am 2026-06-15.
NIST. „AI Risk Management Framework (AI RMF 1.0)." nist.gov/itl/ai-risk-management-framework. Abgerufen am 2026-06-15.
OECD AI Policy Observatory. „National AI policies." oecd.ai. Abgerufen am 2026-06-15.

Spielen Sie Betreiberpflichten an einer realen Arbeitslast durch.

Ein kostenloser 1-wöchiger Pilot führt das Compliance-Team des Kunden durch die Betreiberpflichten anhand eines realen Stücks Arbeit, auf lokaler Inferenz, mit dem IdP und dem Audit-Pfad des Kunden.

Kostenlosen 1-wöchigen Piloten starten