Any ERPRegionEuropean Union

European defence supply chain AI

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

Short answer

European defence suppliers ramping up for NATO and European Defence Fund programmes need AI that never routes technical data, BOMs, or supplier information through a public cloud model API, because much of that data sits under national classification rules, export control, and prime contractor security clauses a SaaS AI vendor cannot easily satisfy. This page covers how an on-prem or sovereign-cloud AI layer grounds on SAP, IFS Cloud, or Infor LN without crossing those lines.

ERP: SAP S/4HANA, IFS Cloud, Infor LN
Industries: Defense, Aerospace
Written for: CIO

Discuss your SAP S/4HANA environment See use cases

Europe's post-2022 rearmament drive, backed by national procurement agencies and the European Defence Fund, is pushing order books up faster than many Tier 2 and Tier 3 suppliers can staff for. A large share of that supply chain runs IFS Cloud, which carries genuine aerospace and defense heritage, SAP across larger primes and their supplier base, or Infor LN, with its project and engineer-to-order strength inherited from Baan in defense electronics and shipbuilding.

Data sensitivity in this supply chain is layered, not uniform. There is unclassified-but-controlled technical data, items subject to national dual-use export regimes and, in joint programmes, US ITAR content, and in some cases nationally classified material that is handled entirely outside the ERP's IT boundary under a separate accredited system. An AI layer has to respect that mix and stay inside whichever boundary each piece of data already belongs to, not create a new way around it.

This is exactly why public AI is the wrong default here. Standard SaaS AI vendor terms rarely name subprocessor jurisdiction precisely enough to survive a defence customer's security clause review, and a prompt containing a drawing description or BOM line can itself constitute an uncontrolled disclosure. Running the model on-prem or in a sovereign cloud matched to the same accreditation boundary as the ERP avoids that problem at the source rather than trying to manage it after the fact.

This page sets out the architecture, deployment options, and compliance mapping we use with European defence suppliers building an ERP AI layer, and closes with questions worth putting to any vendor, including us, before a pilot starts.

What usually gets in the way

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

Ramp-up pressure meets a workforce that can't grow as fast as demand

NATO and EDF-driven order books are growing faster than planners, quality engineers, and buyers can be hired, and AI is one of the few levers that scales without headcount.

Public AI tools are an uncontrolled disclosure risk for technical data

Pasting a drawing description, BOM line, or supplier capability into a public chatbot can constitute exactly the kind of disclosure your export control and security clauses were written to prevent.

Classification boundaries don't map cleanly onto ERP modules

A single BOM can mix unclassified commercial components with export-controlled or nationally sensitive line items, and an AI layer needs to respect that mix, not treat the whole BOM as one sensitivity level.

Every national customer wants its own answer on data location

A supplier working French, German, and UK primes at once faces different, and sometimes conflicting, expectations on where technical data and any AI processing of it can occur.

Vendor AI roadmaps assume commercial customers

SAP Joule, generic Copilot features, and similar vendor AI are built for the median commercial customer, not for an environment with export control markings and accreditation boundaries baked into daily work.

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.

Engineering change impact analysis

An agent traces which open orders, BOMs, and routings are affected by an incoming engineering change, distinguishing controlled from uncontrolled line items.

Touches: Engineering change records, BOM, routing, open order tables

Outcome: Cuts the manual cross-check time for an engineering change's downstream impact from days to hours on routine changes.

Export control screening support

An agent flags BOM lines or customer and country combinations that likely require an export licence check, based on classification fields already maintained in the ERP, for a compliance officer to confirm.

Touches: Item master export classification fields, customer/country master, sales order lines

Outcome: Surfaces likely licence requirements earlier in the order cycle instead of at shipment.

Programme status Q&A for project and engineer-to-order work

Programme managers ask plain-language status questions across a multi-year contract without building a new report for each customer review.

Touches: Project and contract module, milestone billing, work breakdown structure

Outcome: Prepares programme review material in a fraction of the manual time.

Supplier capability and capacity mapping

Procurement asks which qualified suppliers can take on additional capacity for a ramp-up order, grounded in supplier master and historical performance data.

Touches: Approved supplier list, purchase order history, quality performance records

Outcome: Speeds up sourcing decisions during rapid order book growth.

Serialisation and configuration traceability Q&A

Quality and programme staff ask for the as-built configuration or serial history of a delivered unit without manually joining multiple ERP tables.

Touches: Serial and lot tracking, configuration management records, as-built BOM

Outcome: Cuts the time to answer a customer or auditor traceability request from hours to minutes.

Non-conformance and CAPA drafting to AS9100 structure

Quality engineers get a first-draft non-conformance report or corrective action, referencing prior similar findings in the ERP.

Touches: Quality module NCR and CAPA records, inspection results

Outcome: Reduces drafting time on routine non-conformities while keeping engineering review in the loop.

Multi-programme document search

Engineers and quality staff search across specifications, drawings, and contract clauses tied to a specific programme, respecting each programme's own access restrictions.

Touches: Linked PLM or document records, contract and specification files

Outcome: Cuts document search time without merging access across programmes that must stay separate.

Reference architecture

The architecture is scoped to the accreditation boundary the ERP already sits inside, with classification-aware filtering so a mixed-sensitivity BOM or document set is only shown at the level each user and each query is cleared for.

1
ERP connectors
Connects to SAP, IFS Cloud, or Infor LN via their standard APIs, such as OData/BAPI, projections, or BODs/ION, inheriting each system's own project- and programme-level access restrictions rather than creating a flat data pool.
2
Data and semantic layer
Applies classification-aware filtering so a single BOM or document set with mixed sensitivity levels is only shown to the model, and to the user, at the level each is cleared to see.
3
Model serving
Open-weight models served on GPUs inside the supplier's own accredited network boundary, matching the same physical and network security controls already in place for the ERP itself.
4
Retrieval and agents
Retrieval-augmented generation grounds answers in current ERP and linked PLM or document data; agents proposing write-back actions route through the ERP's own approval workflow, with no standing write access.
5
Governance and audit
Every query and retrieved record is logged with user identity, feeding the same audit trail your security accreditation already requires for the ERP.

Integration notes for your ERP team

Connects to SAP via OData, BAPI, or IDoc, to IFS Cloud via projections, and to Infor LN via BODs and ION API, without direct database access.
Classification and export-control fields already maintained on item, BOM, and customer records are read and enforced by the retrieval layer, not just displayed.
Service accounts are scoped per programme or contract where the ERP itself separates data that way, preserving programme-level access boundaries.
Model serving has no outbound path to public model APIs by default; any exception is explicit and logged.
Document grounding indexes PLM and contract documents from existing systems, respecting programme-level folder or system permissions.
Write-back actions use the ERP's own workflow objects, preserving the same approval chain and audit trail as a human-entered transaction.
A single kill switch disables agent write-back without affecting read-only Q&A, for use during an active security or compliance review.

Deployment options

Air-gapped on-prem

Suppliers handling nationally classified work or the most sensitive export-controlled programmes

Model serving sits inside the same accredited, physically isolated network as the ERP, with no path to the public internet for inference.

Private / sovereign cloud

Suppliers whose work is controlled but not nationally classified, wanting dedicated infrastructure without owning hardware

Dedicated GPU capacity in a specific country's data center, under a contract that names the jurisdiction and subprocessors precisely enough to satisfy a prime's security clause review.

Hybrid

Groups running both classified or controlled programmes and general commercial work

Programme-specific data and models stay on the accredited on-prem boundary; general commercial reporting uses shared private cloud capacity, with a documented split 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.

National dual-use and arms export control regimes, plus ITAR where US content or joint programmes are involved

Classification-aware filtering keeps export-controlled data out of any component that hasn't been assessed for it, and the on-prem or accredited-boundary deployment avoids sending controlled technical data to any external processor.

National security accreditation frameworks for defence suppliers, which vary by country and programme

The AI deployment is scoped to fit inside the same accreditation boundary the ERP already sits in, rather than requesting a separate exception.

EU AI Act

Most ERP-grounded question answering and drafting assistance sits in the Act's lower-risk categories; where an agent's output could affect a safety-relevant decision, the human approval step already built into the workflow keeps a person in the loop, which the Act's obligations for higher-risk use cases expect.

GDPR and national data protection law

Personnel data touched incidentally, such as timesheets on a project, stays inside the same access controls as the rest of the ERP; the AI layer does not create a separate copy outside that boundary.

Customer-specific security clauses (prime contractor flow-downs)

A documented architecture naming the jurisdiction, any subprocessors, and the access model gives you a direct answer to a prime's supplier security questionnaire instead of a generic assurance.

Where Netray fits

ERPray

Grounded, read-only question answering with a visible underlying query fits the audit and access-control expectations defence suppliers already work under, across SAP, IFS Cloud, or Infor LN.

Custom build

Export-control screening support, classification-aware filtering, and programme-scoped access are specific enough to defence supply chains to warrant a tailored build on the same private deployment.

How an engagement runs

Phase 1 . 2-3 weeks

Discovery

-Mapping of ERP data sensitivity levels and the accreditation boundary
-Priority use case shortlist with programme owners
-Draft architecture diagram for security review

Phase 2 . 6-8 weeks

Pilot

-Working read-only Q&A or agent for one programme
-Deployment inside the accredited on-prem or approved cloud boundary
-Access control mapped to programme structure

Phase 3 . 4-6 weeks

Production

-Security review and sign-off from your accreditation authority or internal security team
-Monitoring and audit logging in production
-Runbook for incident response covering the AI component

Phase 4 . ongoing

Scale

-Additional programmes onboarded with their own access scoping
-Quarterly review of usage and access logs
-New use cases prioritised as ramp-up continues

Questions to ask any vendor, including us

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

Does any prompt or retrieved data ever leave our accredited network boundary, even for support or logging?
How does the system enforce export-control classification on individual BOM lines, not just at the document level?
Can you show a concrete example of how a prime's supplier security questionnaire would be answered for this deployment?
How does access stay separated between programmes that must not share data internally?
What is your position, in writing, on subprocessors and where they are located?
Can write-back actions be disabled instantly, and is that under our own control or a vendor support call?
What happens to the deployment, model weights, and data if your company changes ownership?
How do you handle a scenario where a document or BOM contains both unclassified and export-controlled content?

Frequently asked questions

Can we use a public LLM API if we redact technical data first?

Redaction is hard to do reliably at scale for BOMs, drawings, and technical descriptions, and a single missed field can constitute a disclosure. Most defence suppliers find it simpler and more defensible to keep the model itself inside the accredited boundary than to rely on redaction before an external call.

Does this replace our security accreditation process?

No. The AI deployment is designed to sit inside the same accreditation boundary and access controls your ERP already operates under, and it should go through the same security review process as any other new system touching that data, not a separate lighter-weight one.

How does an AI layer handle ITAR-relevant content in a joint European-US programme?

The safest default is to treat any ITAR-controlled technical data with the same handling rules as the rest of your ITAR-controlled information: keep it inside the accredited, access-controlled boundary you already maintain, and do not route it through any AI component outside that boundary, including ones run by non-US subsidiaries.

What is the difference between this and IFS.ai or SAP Joule for a defence supplier?

Vendor AI features are built for the vendor's own commercial cloud model, which most defence-accredited environments cannot use as-is because of where the vendor's model processing happens. A private deployment running inside your own accredited network gives similar day-to-day AI capability without that dependency.

Can the AI help with export licence determinations?

It can surface likely export-control flags based on classification fields already in the ERP, which helps a compliance officer prioritise review, but the actual licence determination should stay a human, documented decision, not an automated one.

How long does a pilot take given the extra security review?

Expect the discovery phase to run closer to three weeks to properly map the accreditation boundary and data sensitivity levels; the pilot build itself is similar to other on-prem deployments, around six to eight weeks, but your internal security sign-off timeline will usually be the actual pacing factor.

Do we need new hardware, or can this run on our existing ERP infrastructure?

It depends on your existing server capacity and GPU availability; many suppliers add a dedicated inference server alongside the existing ERP application servers rather than trying to share compute with production systems.

Related guides

IFS Cloud + on-prem AI

AI for IFS Cloud in aerospace and defense manufacturing

Add AI to IFS Cloud for aerospace and defense: projections, Aurena UX, Lobby, and engineer-to-order data, deployed on-prem or in your private cloud.

Infor LN + on-prem AI for A&D

AI for Infor LN in Aerospace and Defense Manufacturing

AI grounded on Infor LN project, contract, and configuration management data for aerospace and defense manufacturers, with on-prem deployment for ITAR.

SAP + on-prem AI for A&D

AI on SAP for Aerospace and Defense Manufacturers, Without the ITAR Exposure

AI on SAP S/4HANA or ECC for aerospace and defense manufacturers: serial genealogy, configuration control, and quoting, without technical data leaving your boundary.

ITAR + on-prem AI

ITAR-Compliant AI for ERP Technical Data

How to add generative AI to your ERP without creating a deemed export under ITAR. On-prem architecture patterns an Empowered Official can sign off on.

On-prem AI, any ERP, A&D

On-Prem AI for ERP in Aerospace, Defense, and Electronics Manufacturing

A hub guide to on-prem AI across SAP, Infor LN, Costpoint, IFS, and Oracle EBS for aerospace, defense, and electronics manufacturers under ITAR, CMMC, and AS9100.

ERP + AI for the UK defence supply chain

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

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