Any ERPRegionEuropean Union

NIS2 and ERP AI

NIS2 Compliance for AI on Your Manufacturing ERP

Short answer

NIS2 classifies most mid-size and large manufacturers as essential or important entities, which pulls any AI system reading from or writing to the ERP into the same risk-management and incident-reporting obligations as the ERP itself. The practical answer is to run that AI system inside your existing NIS2-scoped network boundary, on infrastructure you already report on, rather than routing ERP data through an external SaaS AI vendor that becomes a new, hard-to-audit link in your ICT supply chain. This page covers the specific Article 21 and 23 mechanics, and how an on-prem or private-cloud deployment keeps AI inside the boundary you already secure.

ERP: SAP S/4HANA, Infor LN, Infor M3, Oracle EBS
Industries: Manufacturing, Electronics, Automotive
Written for: CISO

Discuss your SAP S/4HANA environment See use cases

NIS2 is now transposed, with varying timelines, across EU member states, and it pulls a much wider set of manufacturers into scope than the original NIS directive did. Producers of machinery, electrical equipment, motor vehicles, and medical devices are typically classed as important entities once they pass the medium-enterprise threshold, with some larger or more critical operators classed as essential. Article 21 requires documented, risk-based technical and organisational measures across the entity's network and information systems, and manufacturing ERP sits at the center of that scope: it holds the BOMs, supplier data, and production schedules NIS2 risk management is built to protect.

A new generative AI layer changes the picture for a CISO who has already built an ERP risk assessment. Many manufacturers are piloting AI copilots against SAP, Infor, or Oracle ERP data through SaaS vendors or public LLM APIs, and each of those integrations is, in practice, a new ICT supply chain relationship under Article 21(2)(d). That means its own due diligence, its own contractual security requirements, and a share of the entity's own incident reporting exposure if something goes wrong downstream at the vendor.

In practical terms, 'in scope' means prompts and retrieved ERP records leaving the network or country, a new API key that is effectively a new credential surface, and a third party retaining logs you may not control access to during an investigation. That combination is why CISOs at NIS2-scoped manufacturers are increasingly asking for ERP-grounded AI to run where the ERP already runs, rather than accepting a SaaS default that was designed for a company with no comparable regulatory exposure.

This page sets out the architecture, deployment options, and compliance mapping we use with manufacturers building an ERP AI layer against Article 21 and Article 23 expectations, and closes with the questions worth asking any vendor, including us, before committing.

What usually gets in the way

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

NIS2 makes your AI vendor a supply chain risk

Adding a SaaS AI copilot on top of ERP data quietly creates a new third party under Article 21(2)(d), with its own due diligence, contract clauses, and incident-notification chain you now have to manage.

Incident reporting clocks start the moment ERP data leaves your boundary

If a breach touches an external AI vendor holding ERP extracts, the 24-hour early warning and 72-hour report timelines in Article 23 still apply to you, and you may not control the forensic detail you need in time.

Auditors want evidence, not intentions

National competent authorities will ask for documented risk assessments, access logs, and technical measures for any system touching operational data, including AI. A screenshot of a chat interface is not evidence.

Legal wants data residency answers before IT wants AI features

Compliance and legal teams increasingly stop ERP AI pilots that send production, supplier, or personnel data to non-EU hosted models before a data flow diagram exists.

Shadow AI is already inside the ERP workflow

Planners and buyers are pasting MRP exception lists or supplier emails into public chatbots to save time, creating exactly the uncontrolled AI supply chain link Article 21 risk management is meant to prevent.

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.

MRP exception triage with an auditable trail

An agent reads MRP-style exception lists and drafts a prioritized action list and supplier follow-up messages for the planner to approve.

Touches: MRP exception tables, planned orders, purchase requisitions, supplier master

Outcome: Cuts the manual sort-and-chase step for routine shortages from hours to minutes, with every suggested action logged against the planner's own credentials.

Incident-relevant change summarisation

When a security or operational incident touches ERP-adjacent systems, an agent pulls the relevant change history, user activity, and integration logs into a first-draft timeline for the 72-hour NIS2 report.

Touches: Change logs, audit tables, integration message queues, user session logs

Outcome: Turns a half-day of manual log correlation into a reviewed draft in under an hour, without exporting raw logs to a third party.

Supplier risk and dependency mapping

An agent cross-references supplier master data, open purchase order exposure, and single-source flags to give the CISO and procurement a shared view of concentration risk under Article 21(2)(d).

Touches: Supplier master, purchase order history, item-supplier cross reference

Outcome: Gives risk and procurement a current view of concentration risk instead of an annual spreadsheet exercise.

Access and privilege anomaly review

An agent periodically reviews ERP role assignments and recent transaction patterns against a baseline, flagging combinations, such as a user with both PO creation and approval rights, for the CISO to review.

Touches: Role and authorization tables, transaction logs, segregation-of-duties matrix

Outcome: Surfaces segregation-of-duties drift between formal access reviews rather than only at the annual audit.

Natural-language question answering for internal audit

Internal audit or the compliance team asks plain-language questions about production, quality, or supplier data and gets an answer with the underlying query shown, rather than waiting on a report request to IT.

Touches: Read-only views across finance, procurement, and quality modules

Outcome: Reduces routine report requests to the ERP team by a meaningful share, freeing capacity for the reporting NIS2 itself demands.

Vendor and patch exposure tracking

An agent keeps a running view of ERP-adjacent software versions, connectors, and known vulnerabilities relevant to the environment, summarised for the CISO's risk register.

Touches: System configuration tables, integration middleware inventory, patch logs

Outcome: Keeps the technical vulnerability management register under Article 21(2)(b) current without a manual quarterly pull.

Business continuity drill support

During tabletop exercises for Article 21(2)(c) business continuity, the agent simulates how ERP-dependent processes such as order-to-cash or procure-to-pay would be affected by an outage, using real process data.

Touches: Order, production, and procurement transaction tables

Outcome: Makes continuity plans specific to actual transaction volumes and dependencies rather than generic templates.

Reference architecture

The architecture is built around one rule: nothing about the AI layer should widen the boundary your existing NIS2 risk assessment already draws around the ERP. Access, logging, and network placement inherit from the ERP rather than introducing a parallel set of controls.

1
ERP connectors
Read-only connectors into the ERP's own APIs (OData, BAPI/RFC, IDO, ION API) so the AI layer never touches the database directly and inherits the ERP's own role-based access.
2
Data and semantic layer
A mapping layer that translates ERP tables and transaction codes into business terms the model can reason over, with row-level filters applied before any data reaches the model.
3
Model serving
Open-weight models such as Llama, Qwen, or Mistral served with vLLM or Ollama on infrastructure inside the entity's own NIS2-scoped network, so no prompt or retrieved record leaves the boundary already covered by the existing risk assessment.
4
Retrieval and agents
Retrieval-augmented generation grounds answers in current ERP and document data; agents that can write back operate through the same approval workflow a human would use, with no standing write access.
5
Governance and audit
Every query, retrieved record, and generated action is logged with user identity and timestamp, feeding the same audit trail used for the entity's existing NIS2 evidence package.

Integration notes for your ERP team

Connects to SAP via OData/CDS views or to Infor via ION API and IDOs, never direct SQL against production tables, so ERP-side authorization stays authoritative.
Service accounts used for read access are scoped and named per integration, so activity is attributable in the same logs used for NIS2 incident forensics.
Write-back actions, such as releasing a planned order, go through the ERP's own workflow or approval object rather than a direct table update, preserving the ERP's own change history.
Model inference endpoints are deployed inside the same network segment or VPC as the ERP, with no outbound calls to public model APIs by default.
Document sources such as SOPs, supplier contracts, and quality procedures are indexed from the existing document management system, respecting existing folder permissions.
Logging integrates with the existing SIEM so AI query and action logs sit alongside ERP and network logs for a single incident timeline.
A central kill switch disables agent write-back without affecting read-only Q&A, useful during an active incident.

Deployment options

Air-gapped on-prem

Entities with the tightest boundary requirements, or an ERP already run on-prem

Model serving and the ERP sit on the same internal network with no outbound internet path for inference, suited to sites with export-controlled or otherwise sensitive production lines.

Private / sovereign cloud

Entities that want to avoid new hardware but still need EU-only, dedicated infrastructure

Models run on dedicated GPU instances inside a named EU region, under a contract that spells out the data processing terms your Article 21(2)(d) supplier due diligence expects.

Hybrid

Entities running ERP on-prem but comfortable using cloud capacity for lower-sensitivity workloads

Sensitive modules such as production, supplier, and quality data stay on-prem; internal documentation search or similar lower-sensitivity use cases use private cloud capacity, with a documented boundary between the two.

Compliance and data control

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

NIS2 Directive, Article 21 risk management

The AI layer is documented as part of the existing ICT risk assessment, not run as a separate exception; the access control, encryption, and logging measures already applied to the ERP extend to the AI components running beside it.

NIS2 Directive, Article 23 incident reporting

Because inference runs inside the entity's own network, incident detection and evidence collection use the same monitoring the SOC already has, rather than depending on an external vendor's cooperation inside the 24-hour window.

GDPR / national data protection law

Row-level and role-based filters applied in the data layer mean the model only ever sees the records the requesting user is already entitled to see in the ERP.

ISO/IEC 27001, held or pursued by many NIS2-scoped entities

AI components are added to the existing ISMS asset inventory and risk treatment plan rather than run as an unmanaged system outside it.

Sector-specific rules layered on top of NIS2 in some industries

Where a sector regulator adds requirements beyond NIS2, the on-prem deployment model keeps evidence and data inside the same boundary already assessed for that regime.

Where Netray fits

ERPray

Grounded question answering and agents over live ERP data, with a visible underlying query, fit the audit-trail expectations NIS2 risk management creates, across SAP, Infor, Oracle, or Microsoft ERPs.

Custom build

Incident-timeline drafting, supplier concentration mapping, and continuity-drill simulation are specific enough to warrant a purpose-built agent on top of the same private model deployment.

How an engagement runs

Phase 1 . 2-3 weeks

Discovery

-Data flow diagram of proposed AI use cases against the existing NIS2 risk assessment
-List of ERP objects and document sources in scope
-Draft risk treatment note for the AI component

Phase 2 . 6-8 weeks

Pilot

-Working read-only Q&A or agent for one or two priority use cases
-Access control and logging wired into the existing SIEM
-Evidence pack showing the AI component inside the existing ISMS boundary

Phase 3 . 4-6 weeks

Production

-Hardened deployment with monitoring and alerting
-Runbook for incident response covering the AI component
-Sign-off from security and compliance stakeholders

Phase 4 . ongoing

Scale

-Additional use cases onboarded against the same governed platform
-Quarterly review of model and access logs against the risk register
-Capacity planning as usage grows

Questions to ask any vendor, including us

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

Where does inference actually run, and can you show me the network diagram?
Does any prompt or retrieved ERP record leave our network or region, even for logging or support purposes?
How does the AI layer inherit our existing ERP role-based access, rather than creating a new permission model?
What logs do you produce, and do they integrate with our SIEM, or is that extra work?
If we need to produce evidence for a NIS2 audit or incident report, what does that request look like and how fast can you turn it around?
What happens to the deployment if your company is acquired or shuts down - do we retain the model weights and code?
Can write-back actions be disabled instantly without breaking read-only use cases?
What is your subprocessor list, and does it change if we later add a feature?

Frequently asked questions

Does NIS2 apply to AI systems specifically, or just to the ERP?

NIS2 does not name AI as a separate category; it applies to the essential or important entity's risk management obligations across its network and information systems. If an AI system reads from or writes to in-scope ERP data, or is provided by a third party, it falls inside the same Article 21 risk management and Article 21(2)(d) supply chain requirements as any other ICT component.

Are we an essential or important entity under NIS2 if we are a mid-size manufacturer?

NIS2 broadly captures manufacturers of medical devices, machinery, electrical equipment, and motor vehicles as important entities once they pass the medium-enterprise size threshold, with some larger or critical operators classed as essential. Member state transposition varies, so confirm classification with your national competent authority or legal counsel rather than assuming.

Can we use a public LLM API and still be NIS2 compliant?

Yes, if the risk assessment, contractual terms, and monitoring around that API meet Article 21 and 21(2)(d) requirements. In practice many CISOs find it simpler to keep ERP-grounded AI inside the existing network boundary than to extend due diligence and incident reporting cooperation to an external model API provider.

Does on-prem AI mean buying GPUs upfront?

Not necessarily. A private or sovereign cloud deployment inside an EU region gives you dedicated, non-shared infrastructure and a clear data processing agreement without capital spend, and can be a reasonable first step before deciding whether to bring inference on-prem.

How does this affect our 72-hour incident reporting deadline?

Keeping the AI component inside the network you already monitor means your SOC already has the logs it needs for the initial assessment, rather than waiting on an external vendor's incident response process to hand over evidence within your reporting window.

Do we need to update our ISMS documentation for an ERP AI project?

Yes. Add the AI component to the asset inventory, extend the risk assessment to cover model, data, and access flows, and update the supplier due diligence record if any part of the stack is externally hosted or managed.

What is the realistic timeline to get a NIS2-defensible ERP AI pilot running?

A focused pilot on one or two use cases, with logging and access control wired into existing security tooling, typically takes six to eight weeks after a two to three week discovery phase to document the risk assessment and data flows.

Related guides

European defence supply chain AI

On-Prem AI for European Defence and NATO Supply Chain Manufacturers

AI grounded on SAP, IFS, or Infor LN for NATO and EDF supply chain manufacturers, kept inside the accredited network boundary your ERP already sits in.

EU AI Act + ERP AI systems

EU AI Act Compliance for AI Built on Your ERP

How the EU AI Act's risk classes, documentation, and timeline apply to AI copilots and agents on ERP systems, and what compliance officers need in place.

GDPR + AI on ERP data

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 Germany

AI 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.

Agents + approval gates

AI 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.

Digital thread + AI

AI Across PLM and ERP: Teamcenter, Windchill, and Your ERP

AI that reads Teamcenter or Windchill alongside your ERP to trace engineering change impact, BOM sync gaps, and where-used questions, on-prem.

Plan it with numbers

Free Tool

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.

Start the conversation See ERPray

All AI for ERP guides