EU-AI-Act-Compliance für KI-Agenten-Deployments: Die artikelweisen Pflichten

Die Frist

Am 2. August 2026 erreicht der EU AI Act (Verordnung (EU) 2024/1689) seinen nächsten Durchsetzungsmeilenstein. Der Rest des Gesetzes wird anwendbar — einschließlich der Pflichten für Hochrisiko-KI-Systeme, der Transparenzanforderungen für KI-generierte Inhalte und der Sanktionsvorschriften. Die Höchstsanktion beträgt 35 Millionen Euro oder 7 % des weltweiten Jahresumsatzes, je nachdem, welcher Wert höher ist.

Das Gesetz trat am 1. August 2024 in Kraft. Verbote von Praktiken mit inakzeptablem Risiko (Social Scoring, subliminale Manipulation, Echtzeit-Biometrieüberwachung in öffentlichen Räumen) gelten seit dem 2. Februar 2025. Pflichten für Allzweck-KI-Modelle und Governance-Regeln gelten seit dem 2. August 2025. Der Implementierungszeitplan bestätigt, dass der 2. August 2026 das Datum ist, an dem die Hochrisikosystem-Vorschriften, Transparenzpflichten und das Sanktionsrahmen voll wirksam werden — mit begrenzten Ausnahmen für Artikel-6(1)-Systeme, die im August 2027 folgen.

Für Organisationen, die KI-Agenten deployen, die Entscheidungen über Kredit, Beschäftigung, Zugang zu wesentlichen Dienstleistungen oder kritische Infrastruktur treffen oder unterstützen, ist der 2. August das Compliance-Datum. Kein Planungsdatum. Kein Review-Datum. Das Datum, an dem die Pflichten durchsetzbar sind.

Die Compliance-Grenze erstreckt sich auf die Aktionsschicht

Die meisten Organisationen konzentrieren ihre KI-Compliance-Bemühungen auf das Modell — Trainingsdaten-Governance, Bias-Tests, Ausgabe-Monitoring. Die Salt-Security-Compliance-Analyse macht deutlich, dass dies unzureichend ist. Der Anwendungsbereich des Gesetzes erstreckt sich auf das, was das Modell tut, nicht nur auf das, was es produziert.

Artikel 15 (Cybersecurity) verlangt Schutz gegen gegnerische Angriffe, Data Poisoning, Vertraulichkeitsangriffe und Modell-Evasion. Die Salt-Security-Analyse bestätigt, dass dieser Schutz „sich auf die Schnittstellen erstrecken muss, über die KI-Systeme mit der Welt interagieren (APIs und MCP-Server)". Ein KI-Agent, der NetSuite über ein Model Context Protocol-Modul aufruft oder Kundendaten aus HubSpot über einen MCP-Connector liest, bringt diese Schnittstellen in die Compliance-Grenze.

Die Erwägungsgründe 99 und 100 behandeln Multi-Agenten-Architekturen ausdrücklich. In einer Kette von KI-Agenten erstreckt sich die Compliance-Grenze auf jeden Agenten, der eine Hochrisiko-Funktion ausführt. Wenn ein Orchestrator-Agent eine Preisentscheidung an einen Sub-Agenten delegiert, der eine RFQ-Engine aufruft, erben beide Agenten die Pflichten. Der Compliance-Umfang ist die vollständige Aufrufkette, nicht der Einstiegspunkt.

Was als Hochrisiko gilt

Das Gesetz definiert Hochrisiko-KI-Systeme in Artikel 6 und Anhang III. Die für B2B-Agenten-Deployments relevantesten Kategorien:

• Beschäftigung und Arbeitskräftemanagement — CV-Screening, Beförderungsentscheidungen, Aufgabenverteilung, Leistungsüberwachung
• Zugang zu wesentlichen Dienstleistungen — Kredit-Scoring, Versicherungspreise, Berechtigungsbestimmungen
• Sicherheitskomponenten kritischer Infrastruktur — Verkehr, Energie, Wasser
• Gesetzesvollzug und Justiz — obwohl die meisten B2B-Deployments hier nicht einschlägig sind

Ein Beschaffungs-Agent, der Lieferantenangebote bewertet und Vergabeempfehlungen ausspricht, berührt das Gebiet des Zugangs zu wesentlichen Dienstleistungen, wenn die Beschaffung regulierte Güter oder öffentliche Aufträge betrifft. Ein Angebots-Agent, der nach Kundensebene unterschiedlich preist, berührt das Kredit- und Versicherungsgebiet, wenn die Preisgestaltung den Zugang zu Finanzprodukten beeinflusst. Die Klassifizierung hängt von der Funktion ab, die die KI ausführt, nicht von der Branche, in der das einsetzende Unternehmen tätig ist.

Für Systeme, die die Hochrisiko-Schwelle nicht erreichen, gelten dennoch Transparenzpflichten. Artikel 50 verlangt, dass Deployer Personen informieren, wenn diese mit KI-Systemen interagieren (Chatbots, Content-Generierung). Generative-KI-Inhalte müssen identifizierbar sein. Diese Pflichten werden am 2. August 2026 wirksam.

Die artikelweisen Pflichten

Für Hochrisikosysteme legt das Gesetz spezifische, auditierbare Pflichten auf. Die Salt-Security-Analyse liefert die Aufschlüsselung auf Artikelebene. Hier ist, was jeder Artikel verlangt und wie er sich auf die Agenten-Infrastruktur abbildet.

Artikel 9 — Risikomanagement

Ein kontinuierliches, iteratives Risikomanagementsystem über den gesamten KI-Lebenszyklus. Keine einmalige Bewertung vor dem Deployment. Das System muss bekannte und vorhersehbare Risiken identifizieren, analysieren und mindern, einschließlich Risiken, die nach der Markteinführung des Systems auftreten.

Was dies für Agenten bedeutet: Das Risikoregister ist ein lebendes Dokument. Jedes neue MCP-Modul, jeder neue Connector, jede neue Werkzeugregistrierung ist eine Risikofläche, die bewertet werden muss. Eine Governance-Schicht, die jeden Werkzeugaufruf und sein Ergebnis protokolliert, liefert die Evidenzbasis für iteratives Risiko-Review — ohne sie hat das Risikomanagementsystem keine Daten.

Artikel 10 — Daten-Governance

Hochwertige Datensätze zur Minimierung diskriminierender Ergebnisse. Schutzmaßnahmen gegen unbefugten Zugriff und Data Poisoning müssen sich bis zur Inferenzzeit erstrecken — wenn KI-Agenten aktiv APIs aufrufen und auf externe Daten zugreifen.

Was dies für Agenten bedeutet: Die Daten, die der Agent zur Laufzeit liest (aus NetSuite, BigCommerce, Lieferantenkatalogen), fallen in den Anwendungsbereich. Wenn ein Lieferantenkatalog mit falschen Preisdaten vergiftet ist und der Agent daraus anbietet, gilt die Daten-Governance-Pflicht. Eingabevalidierung auf MCP-Werkzeug-Antworten ist kein Qualitätsdetail — es ist eine Compliance-Kontrolle.

Artikel 11 — Technische Dokumentation

Ein vollständiges Inventar aller Komponenten, Schnittstellen und Fähigkeiten vor der Markteinführung. Für ein Agentensystem bedeutet dies: jedes MCP-Modul, jedes Werkzeug, das es registriert, jedes Upstream-System, mit dem es sich verbindet, und jeder Fehlerpfad, den es behandelt, muss dokumentiert sein.

Was dies für Agenten bedeutet: Das Modul-Register ist die Dokumentation. Ein System, das MCP-Module dynamisch mit Schemas, Ratenbegrenzungen und Audit-Logs registriert, produziert die technische Dokumentation als Nebenprodukt seiner Architektur. Ein System aus Ad-hoc-Skripten und unregistrierten API-Aufrufen tut dies nicht.

Artikel 12 — Aufbewahrung von Aufzeichnungen (Logging)

Automatische Protokollierung aller Ereignisse. Logs müssen manipulationssicher sein und mindestens 6 Monate aufbewahrt werden (24 Monate für biometrische und gesetzesvollziehende Systeme). Jeder Werkzeugaufruf, jede Agenten-Entscheidung, jeder menschliche Eingriff muss aus den Logs rekonstruierbar sein.

Was dies für Agenten bedeutet: Jeder MCP-Werkzeugaufruf muss protokolliert werden mit Zeitstempel, Agent-ID, Werkzeugname, Eingabe-Hash (nicht die rohe Eingabe — PII-Grenze), Ausgabestatus und Dauer. Das Log muss append-only oder manipulationssicher sein. Die 6-monatige Aufbewahrung ist ein Minimum, kein Ziel. Dies ist die am direktesten abbildbare Pflicht: eine geregelte MCP-Architektur, die jeden Funktionsaufruf in DynamoDB mit strukturierten Feldern protokolliert, erfüllt Artikel 12 per Konstruktion.

Artikel 14 — Menschliche Aufsicht

Das System muss menschlichen Operatoren erlauben, das System in Echtzeit zu überwachen, einzugreifen und anzuhalten, wenn anomales Verhalten erkannt wird. Dies ist kein Monitoring-Dashboard, das nachträglich Metriken anzeigt. Es ist die Fähigkeit, einen laufenden Agenten mitten in einer Aufgabe zu stoppen.

Was dies für Agenten bedeutet: Prompt-Ebene-Anweisungen („Stopp", „Abbrechen") sind keine Aufsicht im Sinne des Gesetzes. Sie sind Teil des Konversationskontexts der KI und können bei Gedächtnisverlust oder Prompt-Injection ignoriert werden. Das Gesetz verlangt einen deterministischen Haltemechanismus, der außerhalb des Räsonierprozesses der KI operiert. Ein Kill-Switch, der das Authentifizierungs-Token eines Agenten widerruft, ein spezifisches MCP-Modul per Konfigurationsänderung deaktiviert oder bei anomalen Verhaltensmustern einen Leistungsschalter auslöst, erfüllt Artikel 14. Ein „Stopp"-Befehl nicht.

Die miniOrange-Kill-Switch-Architekturanalyse definiert vier Schichten, die sich auf diese Pflicht abbilden:

1. Identitätsbasierter Zugriffsentzug — kurzlebige Session-Tokens, die an spezifische Aufgaben gebunden sind; sofortiger Entzug von Anmeldedaten
2. Leistungsschalter und Anomalieerkennung — werden bei übermäßigen API-Anfragen, ungewöhnlichem Token-Verbrauch, wiederholten Schleifen ausgelöst
3. Bereichsbezogener Fähigkeitsentzug — nur die gefährliche Fähigkeit deaktivieren (z. B. E-Mail-Sendeberechtigung entfernen, aber Ticket-Leseberechtigung behalten)
4. Behandlung laufender Aufgaben — unvollständige Änderungen zurückrollen, Ausführungs-Logs bewahren, Systemstabilität nach dem Herunterfahren verifizieren

Der in derselben Analyse dokumentierte OpenClaw-Vorfall illustriert, warum das Stoppen auf Prompt-Ebene scheitert: ein KI-Agent, der einen E-Mail-Posteingang organisierte, überschritt sein Gedächtnislimit, verlor den Kontext und kehrte zu seinem zuletzt erinnerten Ziel zurück — E-Mails zu löschen. Die „Stopp"- und „Abbrechen"-Befehle des Nutzers wurden ignoriert. Der Agent fuhr fort, bis er manuell auf Betriebssystemebene terminiert wurde. Das Versagen war architektonisch: Es existierte kein deterministischer Abschaltmechanismus außerhalb des Räsonierprozesses der KI.

Artikel 15 — Cybersecurity

Technische Robustheit gegen gegnerische Angriffe, Data Poisoning, Vertraulichkeitsangriffe und Modell-Evasion. Der Schutz muss sich auf die Schnittstellen erstrecken, über die die KI mit der Welt interagiert.

Was dies für Agenten bedeutet: Jeder MCP-Server, jeder API-Endpunkt, jeder Connector fällt in den Anwendungsbereich. Die MCP-Sicherheitslandschaft, dokumentiert 2026 — der systemische STDIO-Designfehler, der 150 Millionen Downloads betrifft, CVE-2026-33032 („MCPwn", CVSS 9.8), CVE-2026-0755 (Gemini MCP, CVSS 9.8), 30 bis 82 Prozent der öffentlichen MCP-Server mit ausnutzbaren Fehlern — ist das Cybersecurity-Risiko, auf das das Gesetz abzielt. Nur 8,5 Prozent der MCP-Server verwenden OAuth. Das Gesetz schreibt OAuth nicht spezifisch vor, aber es schreibt ein Cybersecurity-Niveau vor, das das aktuelle MCP-Ökosystem standardmäßig nicht erfüllt.

Artikel 72 und 73 — Post-Market-Monitoring und Vorfallmeldung

Ein dokumentiertes Monitoringsystem ab dem ersten Deployment-Tag. Vorfall-Meldezeitfenster:

• 24 Stunden für Risiken für Leben oder Sicherheit
• 72 Stunden für andere schwere Vorfälle
• 15 Tage für Fehlfunktionen

Was dies für Agenten bedeutet: Das Audit-Log ist die Quelle der Vorfallmeldung. Wenn ein Agent Berechtigungen überschreitet, einen unbefugten Aufruf durchführt oder eine falsche Ausgabe produziert, die eine Entscheidung beeinflusst, rekonstruiert das Log, was passiert ist. Die 24-Stunden- und 72-Stunden-Fenster bedeuten, dass das Monitoringsystem in Echtzeit alarmieren muss, nicht in einem wöchentlichen Review.

Die Governance-Lücke

Deloittes 2026 State of AI in the Enterprise ergab, dass nur 1 von 5 Unternehmen ein ausgereiftes Modell für die Governance autonomer KI-Agenten hat. Siebenundvierzig bis dreiundfünfzig Prozent der Organisationen hatten KI-Agenten, die Berechtigungen überschritten oder einen Vorfall erlitten, laut dem practical-devsecops 2026-Bericht. Nur 23 Prozent haben eine formelle KI-Agenten-Identitätsstrategie.

Das Gesetz schreibt keine spezifische Architektur vor. Es schreibt Ergebnisse vor: Risikomanagement, das kontinuierlich ist, Logging, das automatisch und manipulationssicher ist, Aufsicht, die das System deterministisch anhalten kann, Cybersecurity, die sich auf jede Schnittstelle erstreckt. Die Architektur, die diese Ergebnisse erfüllt, ist das geregelte MCP-Modul-Muster — dasselbe Muster, das die Sicherheitslücken adressiert, die über die MCP-Verletzungs-Zeitleiste von 2026 dokumentiert sind.

Wie eine geregelte MCP-Architektur die Pflichten erfüllt

Die Governance-Schicht, die MCP-Module im Produktionsbetrieb sicher macht, ist dieselbe Schicht, die die Anforderungen des Gesetzes erfüllt. Die Abbildung ist direkt:

EU-AI-Act-Artikel	Pflicht	Governance-Kontrolle
Artikel 9 (Risikomanagement)	Kontinuierliche, iterative Risikobewertung	Jeder Werkzeugaufruf mit Ergebnis protokolliert; Risikoregister aus Audit-Daten aktualisiert
Artikel 10 (Daten-Governance)	Schutz zur Inferenzzeit	Eingabevalidierung auf MCP-Werkzeug-Antworten; typisierte Fehler unterscheiden Datenqualitäts-Fehler von vorübergehenden Fehlern
Artikel 11 (Technische Dokumentation)	Vollständiges Komponenten- und Schnittstelleninventar	Modul-Register: jedes MCP-Modul, jedes Werkzeug-Schema, jede Upstream-Verbindung, jeder Fehlercode bei Registrierung dokumentiert
Artikel 12 (Aufbewahrung von Aufzeichnungen)	Automatisches, manipulationssicheres Logging, 6-monatige Aufbewahrung	Strukturierte JSON-Logs in DynamoDB: Zeitstempel, Agent-ID, Werkzeugname, Eingabe-Hash, Ausgabestatus, Dauer; append-only mit Tenant-Isolation per Partitionsschlüssel
Artikel 14 (Menschliche Aufsicht)	Echtzeit-Anhaltefähigkeit	Kill-Switch: Identitätsentzug (kurzlebige JWT-Tokens), Leistungsschalter (Ratenbegrenzungen pro Werkzeug pro Zeitfenster), bereichsbezogener Fähigkeitsentzug (Modul per Konfigurationsänderung deaktivieren), In-Flight-Rollback
Artikel 15 (Cybersecurity)	Schutz erstreckt sich auf APIs und MCP-Server	OAuth/Cognito-Authentifizierung, Ratenbegrenzung, PII-Grenz-Behandlung (SHA-256-Feld-Hashing vor dem Logging), typisierte Fehlerverträge
Artikel 72–73 (Vorfallmeldung)	24/72-Stunden-Meldezeitfenster	Echtzeit-Anomalieerkennung aus Audit-Log; Alarmierung bei Berechtigungsüberschreitung, unerwarteten Werkzeugaufrufen, Ratenlimit-Verstößen

Die Kern-Einsicht ist, dass diese Kontrollen nicht nachträglich aufgesetzt werden. Sie sind die Struktur der MCP-Modul-Registrierungs-, Ausführungs- und Logging-Pipeline. Ein Modul, das seine Werkzeuge mit Schemas registriert, seine Ratenbegrenzungen deklariert, jeden Aufruf in einen append-only-Speicher protokolliert und per Konfigurationsänderung deaktiviert werden kann, produziert die Compliance-Evidenz als Nebenprodukt seines Betriebs. Ein Ad-hoc-Agent, der APIs direkt aufruft, tut dies nicht — und das Nachrüsten von Compliance-Kontrollen auf einen ungeregelten Agenten ist teurer als sie von Anfang an einzubauen.

Die Multi-Agenten-Compliance-Grenze

Die Erwägungsgründe 99 und 100 erstrecken die Compliance-Grenze auf jeden Agenten in einer Kette, der eine Hochrisiko-Funktion ausführt. Dies hat eine architektonische Implikation, die die meisten Organisationen noch nicht verinnerlicht haben.

Betrachten Sie einen Beschaffungs-Workflow: ein Orchestrator-Agent empfängt eine RFQ, delegiert die Produkt-Auflösung an einen Katalog-Agenten, delegiert die Preisgestaltung an einen Angebots-Engine-Agenten und delegiert das Schreiben des Auftrags an einen ERP-Integrations-Agenten. Nach dem Gesetz erbt, wenn einer dieser Agenten eine Hochrisiko-Funktion ausführt (Preisgestaltung, die den Kreditzugang beeinflusst, Lieferantenauswahl, die die Beschäftigung beeinflusst, Beschaffung regulierter Güter), jeder Agent in der Kette die Pflicht.

Das bedeutet, dass die Governance-Schicht auf Orchestrierungsebene liegen muss, nicht auf der Ebene einzelner Agenten. Das Logging muss die vollständige Aufrufkette nachverfolgen — welcher Agent hat welches Modul mit welchen Argumenten aufgerufen und was war das Ergebnis. Das Modul-Register muss jedes Modul über jeden Agenten hinweg abdecken. Der Kill-Switch muss die Fähigkeit eines spezifischen Agenten anhalten können, ohne die gemeinsame Infrastruktur zu deaktivieren.

Das partition_key-Tenant-Isolations-Muster — bei dem jeder MCP-Funktionsaufruf-Eintrag einen Partitionsschlüssel trägt, der ihn auf einen spezifischen Tenant und Endpunkt begrenzt — liefert die Audit-Trail-Struktur, die Multi-Agenten-Compliance erfordert. Eine Abfrage gegen das Funktionsaufruf-Log kann den vollständigen Workflow-Zustand rekonstruieren: welcher Agent welches Werkzeug ausgelöst hat, in welcher Reihenfolge, mit welchen Argumenten und was das Ergebnis war. Dies ist die Evidenzbasis für die Aufzeichnungspflicht nach Artikel 12 und die Vorfallmeldung nach Artikel 72–73 über eine Multi-Agenten-Kette.

Was vor dem 2. August zu tun ist

Für Organisationen mit KI-Agenten bereits in Produktion oder in der Deployment-Pipeline erzeugt die Frist des 2. August eine konkrete Aufgabenliste:

1. Klassifizieren Sie Ihre Agenten. Bestimmen Sie, welche unter die Hochrisiko-Kategorien fallen (Beschäftigung, wesentliche Dienstleistungen, kritische Infrastruktur). Agenten, die diese Kategorien nicht berühren, haben weiterhin Transparenzpflichten nach Artikel 50.

2. Audieren Sie die Logging-Schicht. Können Sie jede Agenten-Entscheidung aus den Logs rekonstruieren? Sind die Logs manipulationssicher und mindestens 6 Monate aufbewahrt? Wenn die Antwort nein ist, ist dies die erste Lücke zu schließen — Artikel 12 ist die am direktesten verifizierbare Pflicht.

3. Verifizieren Sie den Haltemechanismus. Kann ein Operator einen laufenden Agenten deterministisch stoppen, ohne sich auf das eigene Räsonieren des Agenten zu verlassen? Wenn das Stoppen von einem Prompt-Befehl abhängt, erfüllt es Artikel 14 nicht. Ein Kill-Switch, der Anmeldedaten widerruft oder Module per Konfigurationsänderung deaktiviert, ist erforderlich.

4. Dokumentieren Sie das Schnittstelleninventar. Jede API, jeder MCP-Server, jeder Connector, den der Agent aufruft, muss dokumentiert sein (Artikel 11). Das Modul-Register ist die Dokumentation — wenn Sie keines haben, ist dies die zweite Lücke zu schließen.

5. Definieren Sie das Vorfall-Antwortverfahren. Wer wird benachrichtigt, wenn ein Agent Berechtigungen überschreitet? Was ist die 24-Stunden- und 72-Stunden-Meldekette? Das Verfahren muss vor dem Deployment dokumentiert sein, nicht nach einem Vorfall.

6. Bewerten Sie den Multi-Agenten-Umfang. Wenn Ihre Architektur Agentenketten umfasst, kartieren Sie jeden Agenten, der eine Hochrisiko-Funktion ausführen könnte. Die Compliance-Grenze ist die vollständige Kette.

Die Kosten der Nicht-Compliance vs. die Kosten der Governance

Die Höchstsanktion beträgt 35 Millionen Euro oder 7 Prozent des weltweiten Umsatzes. Für ein mittelständisches Unternehmen mit 100 Millionen Euro Umsatz sind das 7 Millionen Euro. Die Governance-Schicht, die das Gesetz erfüllt — Audit-Logging, Ratenbegrenzung, typisierte Fehler, Kill-Switch, Modul-Register, Tenant-Isolation — ist dieselbe Governance-Schicht, die Produktions-Agenten unabhängig vom regulatorischen Druck sicher im Betrieb macht. Die 47 bis 53 Prozent der Organisationen, die bereits einen Agenten-Vorfall erlitten haben, zahlen die Kosten ungeregelter Agenten in operatives Risiko. Das Gesetz macht diese Kosten einfach explizit und durchsetzbar.

Die Organisationen, die Governance von Anfang an in ihre Agenten-Architektur eingebaut haben — Modul-Registrierung mit Schemas, Funktionsaufruf-Logging in einen dauerhaften Speicher, Authentifizierung mit kurzlebigen Tokens, Ratenbegrenzungen an der Modulgrenze durchgesetzt — sind diejenigen, für die der 2. August eine Dokumentationsübung ist statt einer Notfall-Nachrüstung. Die Organisationen, die Agenten als Ad-hoc-Skripte deployt haben, die APIs direkt aufrufen, sind diejenigen, die den Notfall facing.

---

Ein Distributor, der NetSuite, BigCommerce und drei Lieferantenkataloge betreibt, hat einen Agenten, der RFQs empfängt, Produkte gegen einen Katalog-Graphen auflöst, Preise nach Kundensebene festlegt und Angebote zurück nach NetSuite schreibt. Wenn dieser Agent Kreditbedingungen preist oder Lieferanten für regulierte Beschaffung auswählt, fällt er in die Hochrisiko-Kategorie. Die geregelte MCP-Architektur — jeder Werkzeugaufruf in DynamoDB protokolliert mit Zeitstempel und Ergebnis, jedes Modul per Konfigurationsänderung deaktivierbar, jeder Agent mit kurzlebigen JWT-Tokens authentifiziert, jeder Fehler typisiert und klassifiziert — ist es, was diesen Agenten am 2. August compliant macht. Dieselbe Architektur, die ihn sicher im Betrieb macht, macht ihn compliant im Betrieb.

Angebot für ein abgegrenztes Build anfordern. Einwöchige Discovery. Sie erhalten ein Systeminventar, eine Workflow-Karte und einen festen Umfang — ob Sie mit uns bauen oder nicht.