Was der EU AI Act wirklich verlangt: KI-Systeme als Enterprise-Compliance-Pflicht

In vielen Vorstandsetagen herrscht beim Thema Künstliche Intelligenz noch immer ein gefährlicher Trugschluss. Weil das eigene Unternehmen keine Sprach- oder Prognosemodelle von Grund auf neu entwickelt, wähnt man sich auf der sicheren Seite eines bloßen Software-Anwenders. Man aktiviert KI-Assistenten im Büroalltag oder bindet externe Cloud-Schnittstellen in die Kundenkommunikation und Personalvorauswahl ein.

Mit der europäischen KI-Verordnung, der Regulation (EU) 2024/1689, erweist sich diese Annahme als kostspielige Fehleinschätzung. Der EU AI Act bewertet KI-Systeme nicht nach ihrem Einkaufsmodell, sondern nach ihrem Einsatzzweck und ihrer Einbettung in betriebliche Entscheidungen. Wie sich das Gesetz in die Architektur aus NIS-2, DORA und CRA einfügt, zeigt unser strategischer EU-Regulierungs-Überblick.

Für CIOs und Enterprise-Architekten wird aus einer juristischen Vorgabe eine konkrete Ingenieursaufgabe. Wer die Hoheit über Modellgewichte, System-Prompts, Vektordatenbanken und Laufzeit-Protokolle an intransparente Black-Box-Dienste abgibt, verliert genau jene Kontrollmechanismen, die das Gesetz unter Androhung von Bußgeldern bis zu 35 Millionen Euro oder sieben Prozent des weltweiten Jahresumsatzes verlangt.

Rollenarchitektur und Haftung: Wann Unternehmen vom Deployer zum Provider werden

Das Fundament der Verordnung (EU) 2024/1689 bildet die präzise Trennung der Marktakteure nach Artikel 3. Auf der einen Seite steht der Anbieter (Provider), der ein KI-System oder ein Modell mit allgemeinem Verwendungszweck (General-Purpose AI, GPAI) entwickelt oder entwickeln lässt und es unter eigenem Namen in Verkehr bringt.

Auf der anderen Seite steht der Betreiber (Deployer), der ein KI-System in eigener Verantwortung beruflich einsetzt. Während der Anbieter nach Artikel 16 die Konformitätsbewertung und die Dokumentation nach Anhang IV schuldet, konzentrieren sich die Betreiberpflichten nach Artikel 26 auf die menschliche Aufsicht, die Eingabedaten-Kontrolle und die sechsmonatige Aufbewahrung der Systemprotokolle.

In der Praxis verschwimmt diese Grenze jedoch rasch. Artikel 25 regelt unmissverständlich, wann ein Betreiber kraft Gesetzes in die Rolle eines Anbieters von Hochrisiko-KI-Systemen rückt und sämtliche Pflichten nach Artikel 16 übernehmen muss. Eine Einordnung der vier Risikoklassen bietet ergänzend unser Leitfaden zum EU-KI-Gesetz für Unternehmen.

Die drei Auslöser des Rollenwechsels nach Artikel 25 im Enterprise-Alltag

Der erste Auslöser greift, sobald ein Unternehmen seinen Namen oder seine Marke auf einem bereits in Verkehr gebrachten Hochrisiko-KI-System anbringt. Wer ein eingekauftes Scoring- oder Analysemodell als eigenes Portal unter eigener Produktmarke für Kunden oder Partner bereitstellt (White-Labeling), haftet aufsichtsrechtlich wie der ursprüngliche Hersteller.

Der zweite Auslöser betrifft die wesentliche Veränderung (Substantial Modification). Passt ein Technikteam ein bestehendes System durch nachträgliches Fine-Tuning der Gewichte, veränderte Entscheidungsschwellen oder Eingriffe in die Steuerungslogik so an, dass die ursprüngliche Konformitätsbewertung nicht mehr trägt, geht die Anbieterverantwortung vollständig auf das verändernde Unternehmen über.

Am häufigsten tritt in der Unternehmens-IT jedoch der dritte Fall ein: die Zweckänderung eines allgemeinen Modells zu einem Hochrisiko-System. Baut eine Fachabteilung um ein allgemeines Sprachmodell (GPAI) wie GPT-4, Claude oder Llama eine Pipeline zur Bewerbervorauswahl, Kreditwürdigkeitsprüfung oder KRITIS-Steuerung auf, wird das Unternehmen unmittelbar zum Hochrisiko-Anbieter.

Genau hier zeigt sich, warum pauschale Werbeversprechen („Unser Modell ist AI-Act-zertifiziert“) in die Irre führen. Sobald Ihre Architektur ein Basismodell mit Unternehmensdaten verknüpft und in einen der acht Hochrisiko-Bereiche des Anhangs III führt, liegt die Nachweispflicht bei Ihrer Organisation. Welche persönlichen Konsequenzen daraus erwachsen, beleuchten wir in der Analyse zur Geschäftsführer-Haftung unter NIS-2 und EU AI Act.

Technischer Deep-Dive: Die Engineering-Pflichten der Artikel 9 bis 15 und Anhang IV

Um die konkreten Anforderungen an die IT-Architektur zu erfassen, müssen die Artikel 9 bis 15 gemeinsam mit Anhang IV als technisches Pflichtenheft gelesen werden. Der Gesetzgeber verlangt überprüfbare Systemeigenschaften, die tief in den MLOps-Lebenszyklus und den Infrastrukturbetrieb eingreifen.

Den Rahmen bildet das kontinuierliche Risikomanagementsystem nach Artikel 9. Anders als eine einmalige Vorabprüfung verlangt Artikel 9 einen iterativen Regelkreis über die gesamte Betriebsdauer. Vorhersehbare Risiken für Sicherheit und Grundrechte müssen systematisch identifiziert, durch architektonische Schutzgrenzen minimiert und im laufenden Betrieb anhand definierter Metriken überwacht werden.

Daten-Governance nach Artikel 10 und lückenlose Dokumentation nach Anhang IV

Für alle Systeme, die mittels Trainings-, Validierungs- und Testdatensätzen entwickelt oder per Fine-Tuning und Retrieval-Augmented Generation (RAG) spezialisiert werden, formuliert Artikel 10 strenge Daten-Governance-Vorgaben. Unternehmen müssen dokumentieren, aus welchen Quellen die Daten stammen, wie sie kuratiert wurden und durch welche statistischen Verfahren mögliche Verzerrungen (Biases) bereinigt wurden.

Noch konkreter wird Anhang IV bei der technischen Dokumentation vor der Inbetriebnahme. Gefordert sind eine detaillierte Beschreibung der Systemarchitektur, der algorithmischen Logik und der Modellparameter, Angaben zu den Rechenressourcen und verwendeten Bibliotheken sowie vollständige Validierungsprotokolle samt Metriken für Genauigkeit und Fehlerraten.

„Unter dem EU AI Act ist Digitale Souveränität kein politisches Ideal mehr, sondern eine harte technische Vorbedingung: Wer weder die Modellversionen einfrieren noch die Inferenz-Telemetrie im eigenen Rechtsraum protokollieren kann, baut auf einem regulatorisch nicht prüffähigen Fundament.“

Wer auf einen externen Cloud-Endpunkt setzt, dessen Anbieter im Hintergrund stillschweigend Modell-Gewichte aktualisiert, verliert über Nacht die Gültigkeit seiner Validierungsmetriken. Nur wenn das getestete Modell-Artefakt (etwa als kryptografisch signiertes Open-Weight-Modell wie Mistral oder Llama) mit fixierter Versionsnummer betrieben wird, bleibt die Dokumentation nach Anhang IV konsistent und reproduzierbar.

Manipulationssicheres Logging (Art. 12), Human Oversight (Art. 14) und Robustheit (Art. 15)

Auf der Laufzeitebene schreibt Artikel 12 eine automatische Protokollierung (Logging by Design) vor, die Betreiber nach Artikel 26 Absatz 6 für mindestens sechs Monate aufbewahren müssen. Die Logs müssen belegen, wann das System lief, gegen welche Referenzdatenbanken (etwa Vektor-Indizes) eine Abfrage erfolgte, welche Eingabedaten vorlagen und welche Personen das Ergebnis geprüft haben.

Eng damit verzahnt ist die menschliche Aufsicht nach Artikel 14. Das Gesetz fordert wirksame technische Maßnahmen gegen den Automation Bias, also das ungeprüfte Übernehmen automatisierter Vorschläge. Architektonisch bedingt dies Benutzerschnittstellen mit Konfidenz-Indikatoren, Quellen-Belegen auf Dokumentenebene sowie einer jederzeit greifenden Stop-Taste zum sicheren Anhalten des Systems.

Schließlich verlangt Artikel 15 nachweisbare Genauigkeit, Robustheit und Cybersicherheit. Das System muss technisch gegen spezifische KI-Angriffsvektoren gehärtet sein, die auch die OWASP LLM Top 10 und die ENISA adressieren: Dazu zählen Data Poisoning in RAG-Quellen, Model Evasion sowie direkte und indirekte Prompt-Injection-Angriffe über eingeschleuste Fremddokumente.

Architektur- und Compliance-Matrix: Proprietäre Cloud-APIs versus Souveräner Enterprise-KI-Stack

Für den IT-Lenkungsausschuss stellt sich die Kernfrage, mit welchem Betriebsmodell sich die Vorgaben der Verordnung (EU) 2024/1689 und der DSGVO dauerhaft abbilden lassen. Wie eine tragfähige Plattformarchitektur für Unternehmens-KI aufgebaut wird, erläutern wir vertiefend in unserem Leitfaden zur Enterprise-KI-Strategie.

Die folgende Bloomberg-Radar-Matrix vergleicht den Bezug über proprietäre Public-Cloud-APIs mit einem souveränen Enterprise-KI-Stack auf Basis von Open-Weight-Modellen, dedizierter Inferenz-Laufzeit (vLLM) und revisionssicherem Audit-Gateway anhand der fünf wichtigsten AI-Act-Prüfdimensionen:

Ein Blick auf Punkt 3 der Matrix offenbart einen kritischen Zielkonflikt vieler aktueller Cloud-Verträge. Um die DSGVO (Verordnung (EU) 2016/679) beim Einsatz US-amerikanischer KI-Dienste einzuhalten, vereinbaren Datenschutzbeauftragte oft Zero-Data-Retention-Klauseln, bei denen der Cloud-Anbieter sämtliche Prompts und Antworten sofort nach der Berechnung verwirft.

Was datenschutzrechtlich sinnvoll klingt, führt unter dem EU AI Act bei Hochrisiko-Systemen direkt in den Rechtsverstoß, falls keine eigene Protokollierungsschicht vorgeschaltet ist. Denn Artikel 12 und Artikel 26 Absatz 6 verlangen zwingend sechsmonatige Ereignis- und Referenzdaten-Logs, die nur ein souveränes KI-Gateway innerhalb der eigenen europäischen Infrastruktur rechtssicher bereitstellt.

Vollkostenrechnung über 60 Monate: Warum API-Token-Mieten und Nachrüst-Audits teurer sind

Neben der rechtlichen Belastbarkeit entscheidet die langfristige Wirtschaftlichkeit über die Plattformwahl. Als Referenz dient ein mittelständisches Unternehmen mit 1.200 Wissensarbeitern sowie drei spezialisierten Fachanwendungen (darunter ein KI-gestütztes Bewerber-Matching im Personalwesen sowie eine automatisierte Vertrags- und Kreditvorprüfung), die teilweise unter Anhang III fallen.

Im ersten Szenario (Proprietäre Cloud-SaaS- und API-Landschaft) summieren sich nutzungsabhängige Sitzplatz-Abonnements (30 Euro pro Nutzer und Monat) auf 432.000 Euro jährlich. Hinzu kommen separate API-Token-Volumina für Dokumenten-Pipelines (95.000 Euro pro Jahr) sowie externe Re-Audit-Kosten von jährlich 110.000 Euro nach unangekündigten Cloud-Modellwechseln, was über 60 Monate 3,185 Millionen Euro ergibt.

Im zweiten Szenario (Souveräner Enterprise-KI-Stack) investiert das Unternehmen in einen dedizierten Inferenz-Cluster (On-Premises oder als dedizierte Bare-Metal-Instanz im europäischen Rechenzentrum mit vier bis acht Enterprise-GPUs vom Typ NVIDIA L40S oder H100), betrieben mit Open-Weight-Modellen unter Apache-2.0-Lizenz, vLLM-Serving, Qdrant-Vektordatenbank und einem zentralen AI-Act-Compliance-Gateway.

Einschließlich Hardware-Abschreibung bzw. Hosting-Miete (145.000 Euro jährlich), MLOps-Plattform-Support (65.000 Euro jährlich) und dem Aufbau des KI-Risikomanagements im bestehenden ISO-27001-ISMS (einmalig 180.000 Euro, laufend 45.000 Euro jährlich) liegen die Fünfjahresgesamtkosten bei 1,455 Millionen Euro. Das Unternehmen spart über 60 Monate rund 1,73 Millionen Euro (54 Prozent TCO-Reduktion) bei voller Revisionssicherheit.

Die Make-or-Buy Sourcing-Weiche für AI-Act-konforme Unternehmensarchitekturen

Nicht jede Organisation verfügt über eigene Machine-Learning-Ingenieure, um GPU-Cluster und Modell-Pipelines auf tiefster Systemebene selbst zu warten. In der Praxis hat sich deshalb eine dreistufige Sourcing-Systematik bewährt, die den Reifegrad der internen IT mit den strengen Anforderungen von Artikel 16, 25 und 26 verbindet.

Erstens (Eigenbetrieb): Regulierte Unternehmen, Banken, Versicherungen und kritische Infrastrukturen (KRITIS) mit eigenem MLOps-Team betreiben ihren Inferenz- und Vektor-Stack auf eigener Hardware oder in europäischen Colocation-Racks. Durch geprüfte Open-Weight-Modelle und lokale Observability-Suiten behalten sie die volle Hoheit über Gewichte, Trainingsdaten und Sechs-Monats-Logs nach Artikel 12.

Zweitens (Co-Managed): Gehobene Mittelständler nutzen souveräne europäische GPU-aaS-Plattformen (nach Sovereign Cloud Stack oder BSI C5), während die eigene IT-Abteilung die Applikationslogik, das zentrale KI-Gateway, die Rollenzugriffe (RBAC) und das Risikomanagement nach Artikel 9 steuert. So entfällt die Hardware-Wartung, ohne dass Daten den europäischen Rechtsraum verlassen.

Drittens (Managed Service): Organisationen mit kleiner IT-Mannschaft beziehen schlüsselfertige, AI-Act-vorbereitete Fachanwendungen über spezialisierte europäische Systemhäuser. Entscheidend ist hierbei die vertragliche Pflicht des Dienstleisters, sämtliche Konformitätsnachweise nach Anhang IV, Modell-Karten, Bias-Testprotokolle und eine exportierbare Protokollschnittstelle nach Artikel 26 bereitzustellen.

Unabhängig vom gewählten Betriebsmodell gilt der Grundsatz, die KI-Prüfschicht niemals in monolithische Einzelanwendungen zu vergraben. Ein zentrales AI-Gateway, das alle Modellaufrufe bündelt, Authentifizierung erzwingt, personenbezogene Daten maskiert und das gesetzliche Audit-Log schreibt, reduziert den Compliance-Aufwand für jedes neue Fachprojekt um bis zu 80 Prozent.

Der 4-Phasen-Umsetzungsfahrplan: In zwölf Monaten zur prüffähigen KI-Governance

Da die Verbote nach Artikel 5 und die KI-Kompetenzpflicht nach Artikel 4 bereits seit Februar 2025 greifen, die GPAI-Pflichten seit August 2025 gelten und die Durchsetzung für Hochrisiko-Systeme nach Anhang III im August 2026 wirksam wird, benötigen CIOs einen klar getakteten Fahrplan.

Phase 1 (Monat 1 bis 2): Technische KI-Inventur, Schatten-IT-Screening und Rollen-Triage

Im ersten Schritt erfasst die IT-Architektur gemeinsam mit Einkauf und Fachbereichen sämtliche produktiven und geplanten KI-Systeme inklusive versteckter Module in bestehenden ERP-, CRM- und HR-Suiten. Für jedes System wird dokumentiert, ob das Unternehmen als Deployer (Art. 26) agiert oder durch Anpassungen nach Artikel 25 in die Provider-Rolle (Art. 16) fällt.

Phase 2 (Monat 3 bis 5): Aufbau des zentralen AI-Gateways und Logging-Architektur

Statt einzelne Fachabteilungen unkontrolliert direkt mit externen Cloud-APIs kommunizieren zu lassen, errichtet das Infrastruktur-Team ein zentrales Enterprise-AI-Gateway. Diese Zwischenschicht übernimmt das Version-Pinning der Modelle, erzwingt Filter gegen Prompt Injection nach Artikel 15 und schreibt alle Transaktionen samt RAG-Quellen revisionssicher in einen sechsmonatigen WORM-Protokollspeicher nach Artikel 12.

Phase 3 (Monat 6 bis 9): Integration von Artikel 9 in das ISMS und Anhang-IV-Dossiers

Anstatt ein isoliertes Parallel-Managementsystem aufzubauen, wird das kontinuierliche KI-Risikomanagement nach Artikel 9 direkt in das bestehende ISMS nach ISO/IEC 27001 oder BSI IT-Grundschutz integriert. Für alle Hochrisiko-Anwendungen erstellen Architektur- und Fachteams die technischen Nachweisdossiers nach Anhang IV und implementieren die Human-in-the-Loop-Masken samt Stop-Funktion nach Artikel 14.

Phase 4 (Monat 10 bis 12): Konformitätsbewertung, Red-Teaming und Artikel-4-Kompetenznachweis

Vor dem produktiven Stichtag durchlaufen die kritischen KI-Pipelines ein strukturiertes Red-Teaming auf Robustheit, Halluzinationsraten und Bias-Freiheit. Parallel schließt das Unternehmen die rollenspezifischen Schulungen zur KI-Kompetenz nach Artikel 4 für Entwickler, Administratoren und Entscheider ab und verankert automatisierte Drift-Alarme im laufenden MLOps-Monitoring.

Fünf Kontrollfragen für Vorstand und IT-Leitung zur AI-Act-Architektur

1. Wissen wir bei jedem KI-System zweifelsfrei, ob wir Deployer (Art. 26) oder durch Artikel 25 zum Provider (Art. 16) geworden sind?

Prüfen Sie insbesondere alle Eigenentwicklungen, RAG-Pipelines und feinjustierten Modelle in den Bereichen Personalwesen, Bonitätsprüfung, Bildung oder kritische Infrastruktur. Sobald ein allgemeines Sprachmodell für einen solchen Hochrisiko-Zweck nach Anhang III konfiguriert wird, reicht das Vertrauen auf den Basismodell-Hersteller rechtlich nicht mehr aus.

2. Können wir für produktive KI-Anwendungen die Modellversion einfrieren und ein sechsmonatiges Audit-Log nach Artikel 12 vorweisen?

Hinterfragen Sie kritisch, ob Ihre aktuellen Cloud-Verträge eine automatische, unveränderbare Protokollierung aller Ein- und Ausgaben sowie der herangezogenen Referenzdaten im eigenen Rechtsraum erlauben. Wenn aus Datenschutzgründen jegliches Logging beim US-Anbieter deaktiviert wurde, ohne ein eigenes internes Gateway vorzuschalten, klafft eine unmittelbare Nachweislücke im Audit.

3. Wie verhindern unsere Benutzeroberflächen technisch den Automation Bias nach Artikel 14?

Eine formale Dienstanweisung, dass Mitarbeitende KI-Ergebnisse vor der Verwendung prüfen sollen, genügt den Anforderungen an eine wirksame menschliche Aufsicht nicht. Stellen Sie sicher, dass die Software selbst Konfidenzwerte und Originalquellen direkt neben dem Ergebnis anzeigt und eine technische Überstimmungs- sowie Not-Aus-Funktion bereitstellt.

4. Sind unsere Lieferantenverträge um verbindliche Mitwirkungspflichten für Anhang-IV-Dokumentationen ergänzt?

Verpflichten Sie externe Softwareanbieter und Systemintegratoren vertraglich dazu, sämtliche für Artikel 11 und Artikel 26 notwendigen Systembeschreibungen, Evaluationsmetriken, Trainingsdaten-Zusammenfassungen und Sicherheitszertifikate maschinenlesbar bereitzustellen. Anbieter, die sich hierbei auf pauschale Betriebsgeheimnisse berufen, stellen für Hochrisiko-Prozesse ein unkalkulierbares Haftungsrisiko dar.

5. Ist das KI-Risikomanagement nach Artikel 9 direkt in unser bestehendes ISO-27001- oder BSI-Grundschutz-ISMS eingebettet?

Vermeiden Sie den teuren Fehler, für den EU AI Act eine isolierte Schattenbürokratie neben der bestehenden Informationssicherheit und dem Datenschutz aufzubauen. Wer Risikoregister, Berechtigungskonzepte, Vorfallsmeldungen und Lieferanten-Audits in seinem etablierten ISMS zusammenführt, halbiert den laufenden Dokumentationsaufwand.

Strategisches Fazit: Warum der EU AI Act souveräne Open-Weight-Architekturen zum Standard macht

Die Verordnung (EU) 2024/1689 beendet die Ära des unkontrollierten Experimentierens mit geschlossenen Black-Box-KI-Diensten in europäischen Unternehmen. Wer die gesetzlichen Anforderungen an Risikomanagement, Daten-Governance, technische Dokumentation nach Anhang IV und revisionssichere Protokollierung bis auf die Ebene der Systemarchitektur durchdenkt, erkennt schnell, dass echte Compliance technische Transparenz voraussetzt.

Für CIOs und IT-Architekten liegt in dieser Regulierung zugleich ein starker Hebel zur Konsolidierung und Kostenreduktion. Unternehmen, die ihre KI-Workloads über ein zentrales, souveränes Gateway bündeln und auf transparente Open-Weight-Modelle in europäischer Infrastruktur setzen, vermeiden das Haftungsrisiko des Artikels 25 und senken ihre Fünfjahresgesamtkosten um mehr als die Hälfte.

Häufig gestellte Fragen (FAQ) zum EU AI Act in der Unternehmens-IT