Any ERPRegionEuropean Union

EU AI Act + ERP AI systems

EU AI Act Compliance for AI Built on Your ERP

Short answer

Most AI assistants and agents built on ERP data fall into the EU AI Act's limited-risk or minimal-risk category, carrying transparency obligations rather than the conformity assessment burden of high-risk systems, but that classification depends on exactly what the system does, particularly if it influences employment, credit, or safety-relevant decisions. Compliance officers need a documented risk classification, a record of what data the system touches, and a human-in-the-loop design for anything that writes back to the ERP.

ERP
SAP S/4HANA, Infor LN, Oracle EBS, Dynamics 365
Industries
Manufacturing, Aerospace, Defense, Electronics
Written for
Compliance Officer

The EU AI Act entered into force in August 2024 with obligations phasing in over roughly two years: prohibited-practice rules and AI literacy obligations came first, general-purpose AI model obligations followed in mid-2025, and the bulk of high-risk system obligations apply from August 2026, with some sector-specific extensions running to 2027. A compliance officer evaluating an AI project on the company's ERP needs to know which of these timelines actually applies to what is being built, not treat the whole Act as one undifferentiated deadline.

The Act classifies AI systems by risk: unacceptable-risk practices are banned outright (things like social scoring, which have no relevance to ERP AI); high-risk systems, mostly tied to specific listed use cases such as employment decisions, credit scoring, or safety components of regulated products, carry the heaviest obligations, including conformity assessment, technical documentation, and human oversight design; limited-risk systems, largely chatbots and generative AI that interacts directly with people, carry transparency obligations (the user must know they are interacting with AI); and minimal-risk systems carry no specific obligations beyond general best practice.

Most of the AI-on-ERP use cases a manufacturer actually builds, MRP exception triage, quality notification drafting, purchase order follow-up, natural-language reporting, land in limited-risk or minimal-risk territory: they inform a human who makes the decision, they do not decide on their own. The classification changes if the same architecture is extended into something like automated employment screening from HR data, or a fully autonomous write-back that commits the company to a purchase or a shipment without human review, both of which start to look like the high-risk categories the Act specifically calls out.

This is why the practical compliance work is less about a single Act-wide checklist and more about classifying each use case honestly as it is designed, documenting that classification and the reasoning behind it, and building the human oversight point into the architecture rather than bolting it on afterward when an auditor asks where it is.

What usually gets in the way

The problems we hear most from compliance officer teams running SAP S/4HANA.

Uncertainty over which use cases are actually high-risk

Compliance officers often do not have visibility into exactly what a new AI-on-ERP project does until it is already built, making it hard to classify risk early enough to influence the design.

Vendor claims that are hard to verify

AI vendors frequently assert their own tool is 'EU AI Act compliant' without specifying which risk class they are claiming or providing documentation a compliance officer can actually audit.

General-purpose AI model transparency obligations

Where the underlying model is a general-purpose AI model under the Act's definition, additional documentation obligations apply to whoever operates it, which shifts depending on whether the company self-hosts an open-weight model or consumes a provider's API.

Overlap with GDPR and sector rules

An AI system on ERP data usually triggers GDPR obligations (DPIA, lawful basis) at the same time as AI Act obligations, and treating them as separate compliance tracks duplicates effort and risks inconsistent conclusions about the same system.

Documentation burden without an existing template

Many manufacturers do not yet have a standard technical documentation template for an AI system, unlike the well-worn templates that exist for quality management system documentation, leaving compliance officers building the format from scratch for the first project.

Where AI earns its place in SAP S/4HANA

Each use case names the ERP objects it reads or writes, so your ERP team can judge the integration effort before anyone commits budget.

Risk classification workstream for a new AI-on-ERP project

Before build, walks through the Act's Annex III high-risk use case list against the proposed AI feature, documenting why it falls where it falls.

Touches: use case scope document, data flow diagram, decision-authority mapping (human vs system)

Outcome: a defensible, written risk classification exists before the project reaches production, not after an audit asks for one

Transparency labeling for generative AI features

Ensures every AI-generated draft (an 8D report, a variance commentary, a supplier email) is clearly labeled as AI-assisted to the human who reviews or sends it, satisfying limited-risk transparency obligations.

Touches: UI labeling on drafted content, audit metadata tagging AI-generated text

Outcome: clear evidence of transparency compliance without a separate disclosure process bolted onto every workflow

Human oversight design for write-back agents

Any agent capable of posting a transaction, confirming an order, or sending a supplier communication is designed with an explicit human approval step, keeping decision authority with a person.

Touches: approval workflow logs, agent action queue, ERP transaction posting records

Outcome: the system's actual behavior matches the human-in-the-loop design on paper, verifiable from the logs

Technical documentation for general-purpose model use

Documents which model is used, how it is served (self-hosted vs provider API), and what data it was grounded on for a given deployment, in a format that can be handed to an auditor.

Touches: model version and deployment records, RAG source inventory

Outcome: a documentation package that answers the Act's transparency requirements without a scramble each time a regulator or customer asks

GDPR and AI Act joint assessment

Runs the DPIA and the AI Act risk classification for the same use case together, since they largely examine the same system and the same data.

Touches: DPIA output, AI Act risk classification memo

Outcome: one consistent compliance conclusion instead of two documents that might quietly disagree with each other

AI literacy training rollout

Supports the Act's AI literacy obligation by giving staff who use the assistant clear, practical training on what it can and cannot be trusted to do, tied to the actual use cases deployed.

Touches: training completion records, use-case-specific guidance materials

Outcome: documented AI literacy training that maps to real system usage, not a generic slide deck nobody remembers

Ongoing monitoring for scope creep

Periodically reviews whether a use case that started as limited-risk (a drafting assistant) has, through incremental feature additions, drifted toward higher-risk territory (autonomous decision-making) without a re-classification.

Touches: feature change log, periodic classification review

Outcome: risk classification stays current as the system evolves instead of being a one-time exercise that goes stale

Reference architecture

Compliance with the AI Act is less about a specific technical stack and more about the system being designed so its actual behavior, human oversight, transparency, logged decisions, matches what the risk classification says it should be, and the architecture makes that verifiable.

  1. 1

    ERP connectors

    Read-only by default connectors (OData, BAPI/RFC, ION API, REST) with any write-back explicitly gated, giving a clean line between 'the system suggested' and 'a human decided'.

  2. 2

    Data and semantic layer

    A documented inventory of exactly which ERP objects and documents ground the system's answers, needed for both the AI Act's technical documentation and GDPR's records of processing.

  3. 3

    Model serving

    Self-hosted, open-weight models on customer-controlled infrastructure, with the specific model and version recorded for the general-purpose AI model documentation obligation.

  4. 4

    Retrieval and agents

    RAG grounds answers in current data; agents that could take a high-risk action stop for human approval, with the approval step logged as evidence of the human oversight design.

  5. 5

    Governance and audit

    A log of every AI-assisted decision, what was suggested, who approved it, and what changed, that serves as the audit trail for both the AI Act and internal quality processes.

Integration notes for your ERP team

  • ERP connectors are read-only by default (OData/BAPI/RFC for SAP, ION API/BODs for Infor, REST/data entities for Dynamics 365, interface tables/APIs for Oracle EBS), with write-back explicitly scoped per use case.
  • Every AI-generated draft or suggestion is tagged in metadata as AI-generated, feeding both the transparency obligation and internal audit needs.
  • Human approval steps for any write-back are implemented as a real blocking step in the workflow, not a notification the system proceeds without waiting for.
  • Model version and deployment configuration are versioned and retained, so a specific answer can be traced back to the exact model and data snapshot that produced it.
  • A single data flow diagram per use case is maintained and kept current, serving both AI Act technical documentation and GDPR records of processing.
  • Access to the AI system mirrors existing ERP role-based access, so the AI layer does not become a way to see data a user could not already see directly.

Deployment options

Air-gapped on-prem

Manufacturers in aerospace, defense, or electronics supply chains with the strictest data control requirements

The self-hosted model and full audit log make the technical documentation and human oversight evidence straightforward to assemble, since nothing runs outside the company's own visibility.

Private or sovereign EU cloud

Manufacturers without in-house GPU capacity who still need EU-only processing

A dedicated EU-hosted instance keeps the same documentation and oversight design while removing the need to operate GPU hardware directly.

Hybrid

Multi-site or multi-ERP groups with varying risk tolerance by site

Higher-sensitivity use cases run on-prem while lower-sensitivity ones share a private cloud instance, with one consistent compliance documentation process across both.

Compliance and data control

How the architecture supports your obligations. Certification and accountability stay with your organisation; the design keeps the evidence straightforward.

EU AI Act - risk classification

Each use case is classified against the Act's categories before build, with the reasoning documented and revisited if the feature set changes materially.

EU AI Act - transparency obligations

AI-generated content (drafts, suggestions) is labeled as such in the interface, and users are informed they are interacting with an AI system where relevant.

EU AI Act - general-purpose AI model documentation

The specific model, version, and deployment method (self-hosted vs API) are recorded and available for the documentation this obligation requires.

GDPR / RGPD

DPIA and AI Act risk classification are run as a joint assessment for the same system, since they examine largely the same data flows and decisions.

NIS2 (where applicable)

For manufacturers that fall into scope as important or essential entities, the same audit logging supporting AI Act documentation contributes evidence for NIS2 incident reporting and supply chain security requirements.

How an engagement runs

Phase 1 . 2-3 weeks

Discovery

  • -Inventory of proposed and existing AI-on-ERP use cases
  • -Draft risk classification for each against the AI Act's categories
  • -Data flow diagrams for the highest-priority use cases
  • -Gap list against current documentation and oversight practices

Phase 2 . 6-8 weeks

Pilot

  • -One use case live with transparency labeling and human oversight implemented
  • -Joint DPIA and AI Act classification memo for the pilot use case
  • -Audit log review confirming actual system behavior matches the documented design
  • -Draft technical documentation template for reuse on future use cases

Phase 3 . 6-10 weeks

Production

  • -Finalized technical documentation and risk classification for the production use case
  • -AI literacy training delivered to the user group
  • -Audit logging integrated with existing compliance monitoring
  • -Sign-off from compliance and, where relevant, the works council or equivalent body

Phase 4 . Ongoing

Scale

  • -Risk classification and documentation extended to additional use cases as they are built
  • -Periodic review for scope creep on existing use cases
  • -Updated AI literacy training as new features are added
  • -Tracking of Act timeline milestones relevant to the company's specific use cases

Questions to ask any vendor, including us

A short list that separates real SAP S/4HANA AI work from a chatbot demo.

  1. Can the vendor produce a written risk classification for our specific use case, not a generic claim of compliance?
  2. Is there a real, logged human approval step for anything that writes back to the ERP, or does the system act autonomously?
  3. Is AI-generated content clearly labeled to the person reviewing or receiving it?
  4. What model is actually used, and is its version and deployment method documented for us?
  5. How does the vendor handle the overlap between AI Act documentation and our existing GDPR records of processing?
  6. What is the process if a use case's risk classification needs to change as features are added later?
  7. Does the vendor provide AI literacy training materials tied to the specific use cases deployed, not a generic AI overview?

Frequently asked questions

Is an AI copilot on our ERP automatically a high-risk system under the EU AI Act?

No. Most AI-on-ERP assistants, drafting help, exception triage, natural-language reporting, are limited-risk or minimal-risk because they inform a human decision rather than making one autonomously in a listed high-risk category. The classification changes if the system is extended into areas like automated employment decisions or safety-critical sign-off without human review, which is why each use case needs its own classification rather than a blanket assumption.

What obligations apply to a limited-risk AI system like a drafting assistant?

The main obligation is transparency: the person interacting with the system needs to know they are dealing with AI, and AI-generated content should be identifiable as such. This is a straightforward design requirement, labeling drafts clearly and not presenting AI output as if a person wrote it, rather than a heavy documentation or conformity assessment burden.

When do the EU AI Act's obligations actually take effect?

The Act entered into force in August 2024. Prohibited-practice rules and AI literacy obligations applied first, general-purpose AI model obligations followed from mid-2025, and most high-risk system obligations apply from August 2026, with some sector-specific extensions running to 2027. The exact date that matters for a given project depends on which category its use case falls into, so it is worth confirming against the current text rather than treating one date as universal.

Does self-hosting an open-weight model change our obligations compared to using a provider's API?

It changes who holds which obligations. When you self-host, you control and can document the model version, training data provenance to the extent the provider discloses it, and deployment configuration directly, which makes it easier to produce the documentation the Act expects. Using a provider's API shifts some documentation obligations to that provider, but you still need to understand and be able to describe what you are using.

How does the AI Act interact with GDPR for an AI system on ERP data?

They overlap significantly but are not the same assessment: GDPR asks whether processing personal data is lawful and proportionate (via a DPIA where required), while the AI Act asks about the risk the AI system itself poses and what obligations attach to that risk level. Running both assessments together on the same use case, rather than as separate workstreams, produces a more consistent and defensible conclusion.

What is the AI literacy obligation and who does it apply to?

The Act requires organizations deploying AI systems to ensure staff who operate or are affected by them have a sufficient level of understanding of how the system works and its limitations. In practice, this means real, use-case-specific training, what the assistant can and cannot be trusted to do, not a generic slide deck about artificial intelligence in general.

Do we need to reclassify a use case if we add a new feature to it later?

Yes, in principle. A drafting assistant that starts as limited-risk can drift toward higher-risk territory if a later feature gives it more autonomous decision authority, for example letting it approve a transaction without review. Building a periodic review of existing use cases into the governance process catches this kind of scope creep before it becomes a compliance gap discovered during an audit.

Talk it through with an engineer who knows SAP S/4HANA

Bring one real question your team cannot answer from the ERP today. We will map the data path, the model, and where it runs, and tell you honestly if AI is the wrong tool for it.