An initiative by Solutive AG
solutive.ag
AI Governance

EU AI Act Article 26 for SAP users: Deployer obligations effective August 2, 2026, not postponed

Article 26 of Regulation (EU) 2024/1689 defines the operational obligations for deployers of high-risk AI systems. For SAP users, these obligations remain unchanged as of August 2, 2026.
May 18, 2026
min Lesezeit
6

Article 26 and the AI Act’s role architecture

Article 26 of Regulation (EU) 2024/1689 defines the operational obligations of deployers (users) of high-risk AI systems. A deployer is any natural or legal person who uses an AI system under their own authority, without having developed or placed it on the market themselves.

The distinction between provider obligations (Article 16, manufacturer perspective) and deployer obligations (Article 26, user perspective) is the core of the AI Act’s role architecture. SAP positions itself as a provider for SAP Business AI products through its ISO 42001 certification. However, deployer obligations remain with the company using the system and cannot be transferred to SAP via contract or vendor assurance.

Why the postponement of Annex III obligations does not affect Article 26

The Digital Omnibus on AI (provisional agreement May 7, 2026) postpones obligations for Annex III high-risk systems until December 2, 2027. Article 26 is not affected by this. Deployer obligations remain in effect from August 2, 2026, as originally planned.

For SAP users, this creates a dual interpretation of the regulation: anyone using SAP systems where AI makes decisions on candidate selection, performs credit scoring, or provides financial predictive analytics is considered a deployer of a high-risk system as of August 2026. The postponement of the most stringent provider obligations does not change this. The operational burden of oversight, documentation, and incident reporting remains with the user.

Operational obligations for SAP deployers

The operational obligations under Article 26 for SAP deployers:

ObligationConcrete implementation in the SAP contextUsage according to manufacturer instructionsUse SAP Joule and Business AI components exclusively for documented use cases and adhere to defined operational limitsHuman oversight (Art. 14)Appoint technically competent personnel for each high-risk use case with decision-making authority prior to productive impactInput data relevanceVerify that input data for SAP AI components is suitable for the intended purpose; separate training and production data pathsMonitoring and loggingAutomatically record operational events, retain for at least 6 months, and link to the SAP Audit TrailIncident reportingReport serious incidents to SAP as the provider and to the relevant market surveillance authority (in Germany: BSI in coordination with BNetzA and BfJ, depending on risk class)Data Protection Impact AssessmentConduct a DPIA under GDPR where personal data is processed, linked to FRIA

Architectural gaps, liability, and non-delegable oversight

Contractual risk shifting does not work. Article 26 is a direct obligation for the deployer. Clauses that assign responsibility to SAP or any other provider have no exculpatory effect in the eyes of regulatory authorities. This is consistently documented in the provider perspectives from Uniorg (March 2026) and Advisori DE (February 2026).

Logging obligations encounter SAP architectural gaps. SAP Cloud ALM captures transport telemetry but does not provide comprehensive AI application logging at the object level. SAP Solution Manager with ChaRM is being phased out in 2027. Organizations using AI in SAP processes that must meet the 6-month retention requirement need a logging strategy that extends beyond native SAP tools.

Human oversight cannot be delegated. Article 14 requires natural persons with the competence and authority to intervene. An AI component that intervenes in production without documented human approval cannot meet oversight requirements. In the context of SAP transports, this means that autonomous agents that implement changes without a four-eyes principle fall into regulatory non-compliance as soon as the underlying use case is classified as high-risk.

The crucial question is not whether the system works, but whether the human still has the choice to reject it. Anyone who architecturally excludes this choice is not only violating the AI Act, but also the requirements of the precautionary principle.

The provider role is not static. Anyone who fine-tunes standard SAP models, adapts them with their own training data, or makes substantial modifications can become a provider themselves (Art. 25). In this case, SAP's ISO 42001 certification does not apply. The regulation does not define concrete thresholds for this transition zone, which necessitates an independent risk assessment.

Deployer roadmap for SAP users by August 2026

An actionable deployer roadmap for SAP users by August 2026:

  1. AI inventory with role clarification: Record all SAP AI components, document the SAP provider role for each component, mark custom tuning separately, and record an internal provider role if applicable.
  2. Use case classification: Classify every productive AI application according to its AI Act risk category. Personnel decisions and credit scoring are high-risk, while Joule chat is limited risk with transparency obligations.
  3. Appoint oversight personnel: For each high-risk use case, designate at least one human responsible party with documented authority to intervene and demonstrable competence (Art. 4 AI literacy).
  4. Logging strategy: Couple SAP-native logging (application logs, change documents) with extended auditing mechanisms. Minimum retention period is 6 months, or longer in regulated industries (pharma, finance) in accordance with sector-specific requirements.
  5. Incident reporting channels: Define escalation paths to SAP as the provider and to the market surveillance authority. Clarify responsibilities between IT, compliance, and data protection in writing.
  6. DPIA-FRIA integration: Set up the Data Protection Impact Assessment and Fundamental Rights Impact Assessment as a linked process, rather than as separate obligations.
  7. Contract review with SAP: Review SAP contracts for provider obligations under Art. 16 and request written supplier assurances, without treating your own Art. 26 obligations as delegated.

Sources

  • Regulation (EU) 2024/1689, in particular Articles 26, 16, 14, 12, 25, 50 (EUR-Lex)
  • SAP Responsible AI Page Q1 2026 (sap.com/products/artificial-intelligence/ai-ethics.html)
  • AI Act Service Desk FAQ Q1 2026 (ai-act-service-desk.ec.europa.eu)
  • Uniorg, March 2026: SAP and the EU AI Act (uniorg.de)
  • Advisori DE, February 28, 2026: EU AI Act High-Risk Obligations August 2026 (advisori.de)
  • Innobu, April 2026: SAP Joule Promise vs Reality (innobu.com)
  • Council of the EU, Press Release May 7, 2026 (consilium.europa.eu)
  • CodeSlick, April 2026: AI-Generated Code Audit Trail Gap (codeslick.dev)
Tool Landscape

Article 26 is the non-deferred core of the AI Act for SAP users. The postponement of Annex III obligations to December 2, 2027, does not change this, nor does the provider's ISO 42001 certification. Anyone using SAP AI in regulated processes will be subject to requirements for human oversight, logging, incident reporting, and DPIAs starting August 2, 2026. The operational weakness of SAP-native tools regarding audit trails makes the deployer role technically more demanding than the contractual language suggests. Autonomous systems that learn faster than their governance frameworks can evolve are no longer a future scenario, but a balance-sheet-relevant reality as of August 2026.

Autor:
Christian Steiger
Sarah Connor