Artikel 26 der Verordnung (EU) 2024/1689 legt die operativen Pflichten von Deployern (Anwendern) hochrisikobehafteter KI-Systeme fest. Ein Deployer ist eine natürliche oder juristische Person, die ein KI-System unter eigener Verantwortung einsetzt, ohne es selbst entwickelt oder in Verkehr gebracht zu haben.
Die Trennung von Provider-Pflichten (Artikel 16, Hersteller-Sicht) und Deployer-Pflichten (Artikel 26, Anwender-Sicht) ist die zentrale Rollenarchitektur des AI Act. SAP positioniert sich nach eigener Darstellung über die ISO 42001 Zertifizierung als Provider für SAP Business AI Produkte. Die Deployer-Pflichten bleiben beim einsetzenden Unternehmen und sind weder über Vertrag noch über Vendor-Zusicherung auf SAP übertragbar.
Der Digital Omnibus on AI (vorläufige Einigung 7. Mai 2026) verschiebt die Pflichten für Annex III Hochrisiko-Systeme auf 2. Dezember 2027. Artikel 26 ist davon nicht betroffen. Die Deployer-Pflichten gelten ab 2. August 2026 wie ursprünglich vorgesehen.
Für SAP-Anwender entsteht damit eine doppelte Lesart der Regulierung: Wer SAP-Systeme einsetzt, in denen KI Entscheidungen über Bewerberauswahl trifft, Kredit-Scoring durchführt oder finanzielle Predictive Analytics liefert, ist ab August 2026 Deployer eines Hochrisiko-Systems. Die Verschiebung der schwersten Provider-Pflichten ändert daran nichts. Die operative Last der Aufsicht, Dokumentation und Vorfallmeldung verbleibt beim Anwender.
Die operativen Pflichten aus Artikel 26 für SAP-Deployer:
| Pflicht | Konkrete Umsetzung im SAP-Kontext |
|---|---|
| Nutzung gemäß Hersteller-Anweisungen | SAP Joule und Business-AI-Komponenten ausschließlich in den dokumentierten Use Cases einsetzen, dokumentierte Einsatzgrenzen einhalten |
| Menschliche Aufsicht (Art. 14) | Benannte, fachlich kompetente Personen für jeden Hochrisiko-Use-Case, mit Entscheidungsbefugnis vor produktiver Wirkung |
| Eingangsdaten-Relevanz | Eingabedaten in SAP-KI-Komponenten auf Eignung für den vorgesehenen Zweck prüfen, Trainings- vs. Produktivdatenpfade trennen |
| Monitoring und Logging | Betriebsereignisse automatisch erfassen, mindestens 6 Monate aufbewahren, Verknüpfung mit dem SAP Audit Trail |
| Vorfallmeldung | Schwerwiegende Vorfälle an SAP als Provider und an die zuständige Marktaufsichtsbehörde melden (in Deutschland: BSI im Zusammenspiel mit BNetzA und BfJ je nach Risikoklasse) |
| Datenschutz-Folgenabschätzung | DPIA nach DSGVO durchführen, wo personenbezogene Daten verarbeitet werden, mit Kopplung an FRIA |
Vertragliche Risikoverlagerung funktioniert nicht. Artikel 26 ist eine direkte Verpflichtung des Deployers. Klauseln, die SAP oder einem anderen Anbieter die Verantwortung zuschreiben, haben keine entlastende Wirkung gegenüber der Aufsichtsbehörde. Das ist in der Anbieter-Sicht von Uniorg (März 2026) und Advisori DE (Februar 2026) konsistent dokumentiert.
Logging-Pflicht trifft auf SAP-Architekturlücken. SAP Cloud ALM erfasst Transport-Telemetrie, aber kein vollständiges KI-Anwendungslogging auf Objektebene. SAP Solution Manager läuft mit ChaRM 2027 aus. Wer KI in SAP-Prozessen einsetzt und die 6-Monats-Aufbewahrung erfüllen muss, braucht eine Logging-Strategie, die über native SAP-Tools hinausgeht.
Menschliche Aufsicht ist nicht delegierbar. Artikel 14 verlangt natürliche Personen mit Kompetenz und Eingriffsbefugnis. Eine KI-Komponente, die ohne dokumentierte menschliche Freigabe produktiv eingreift, kann den Aufsichtsanforderungen nicht genügen. Im SAP-Transport-Kontext bedeutet das: Autonome Agenten, die Changes ohne 4-Augen-Prinzip einspielen, geraten in regulatorische Schieflage, sobald der zugrunde liegende Use Case Hochrisiko-Charakter hat.
Die entscheidende Frage ist nicht, ob das System funktioniert, sondern ob der Mensch noch die Wahl hat, es abzulehnen. Wer diese Wahl architektonisch ausschließt, verstößt nicht erst gegen den AI Act, sondern bereits gegen die Anforderungen des Vorsorgeprinzips.
Provider-Rolle ist nicht statisch. Wer SAP-Standardmodelle fine-tuned, mit eigenen Trainingsdaten anpasst oder substantielle Modifikationen vornimmt, kann selbst zum Provider werden (Art. 25). Die ISO 42001 Zertifizierung von SAP greift in diesem Fall nicht. Konkrete Schwellenwerte für die Wechselzone sind in der Verordnung nicht definiert, was eine eigene Risikoeinschätzung erfordert.
Eine umsetzbare Deployer-Roadmap für SAP-Anwender bis August 2026:
Artikel 26 ist der unverschobene Kern des AI Act für SAP-Anwender. Die Verschiebung der Annex III Pflichten auf 2. Dezember 2027 ändert daran nichts, ebenso wenig die ISO 42001 Zertifizierung des Anbieters. Wer SAP-KI in regulierten Prozessen einsetzt, trägt ab 2. August 2026 die Pflichten zur menschlichen Aufsicht, zum Logging, zur Vorfallmeldung und zur DPIA. Die operative Schwäche der SAP-nativen Tools auf der Audit-Trail-Seite macht die Deployer-Rolle technisch anspruchsvoller als die Vertragsformulierungen suggerieren. Autonome Systeme, die schneller lernen als ihre Governance-Rahmen wachsen, sind kein Zukunftsszenario mehr, sondern eine bilanzierungsrelevante Realität ab August 2026.