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
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
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
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
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
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.
Where Netray fits
ERPray
Its read-only, query-shown design fits limited-risk transparency obligations naturally, since the underlying reasoning is visible rather than a black-box answer.
Custom build
Use cases closer to the high-risk boundary, anything touching employment decisions or safety-relevant sign-off, need bespoke human oversight design reviewed specifically against the Act's requirements for that category.
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.
- Can the vendor produce a written risk classification for our specific use case, not a generic claim of compliance?
- Is there a real, logged human approval step for anything that writes back to the ERP, or does the system act autonomously?
- Is AI-generated content clearly labeled to the person reviewing or receiving it?
- What model is actually used, and is its version and deployment method documented for us?
- How does the vendor handle the overlap between AI Act documentation and our existing GDPR records of processing?
- What is the process if a use case's risk classification needs to change as features are added later?
- 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.
Related guides
Building GDPR-Compliant AI on Top of Your ERP
Design AI on ERP data that satisfies GDPR: lawful basis, DPIA, data minimisation, and an on-prem architecture that avoids the Schrems II transfer problem.
SAP + private AI in GermanyAI for SAP in the German Mittelstand: On-Prem and DSGVO-Ready
On-prem AI for SAP S/4HANA and Business One built for German Mittelstand manufacturers: DSGVO-aligned, Betriebsrat-ready, data stays on your own servers.
Souverainete numerique + AI on ERPAI for ERP in France: Souverainete and SecNumCloud-Aligned Architecture
On-prem and sovereign AI for SAP, Infor LN, and Sage X3 in French manufacturing: SecNumCloud-aligned architecture, CNIL-compliant, data stays in France.
ERP + AI for the UK defence supply chainAI for ERP in UK Defence Manufacturing: On-Prem, DEFCON 658-Aware
On-prem AI for ERP built for UK defence suppliers: aligned to DEFCON 658, Cyber Essentials Plus, UK GDPR, and JOSCAR accreditation expectations.
RAG + SQL + permissionsA Private LLM Grounded on Your ERP Data
How a private LLM answers questions on your ERP data: RAG plus text-to-SQL, role-based permissions inherited from the ERP, and where each fits.
Agents + approval gatesAI Agents for ERP, Running On-Prem
A practical guide to on-prem AI agents for ERP: what they can safely automate, where human approval belongs, and how to design the guardrails.
Plan it with numbers
AI Governance Maturity Assessment
Score your AI governance across policy, inventory, risk classification, data handling, monitoring, and executive oversight, and get a banded improvement roadmap.
Free ToolAI Audit Trail Readiness Checklist
A practical control checklist for building AI audit trails that satisfy compliance assessors, covering request-level logging, log integrity, identity evidence, and model lineage.
Free ToolAI Vendor Evaluation Checklist
A structured checklist for evaluating AI vendors across technical fit, data security and compliance, commercial terms, viability, and implementation support.
GuideEU AI Act Implications for On-Prem AI Deployments
EU AI Act implications for on-prem deployments: risk tiers, high-risk obligations, and how self-hosted models simplify enterprise compliance.
GuideERP GDPR Data Protection Compliance Guide
Achieve GDPR compliance in ERP systems with data mapping, consent management, right-to-erasure implementation, and data protection impact assessments.
GuideHuman-in-the-Loop Design for ERP AI
Human-in-the-loop design for ERP AI: where to place approvals, confidence thresholds, and audit trails so agents act safely inside SyteLine, LN, and M3.
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.