# On-Prem AI for European Defence and NATO Supply Chain Manufacturers > Source: https://netray.co/erp-ai/ai-for-erp-european-defence-suppliers > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: AI for ERP ## 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. ## Kind region ## Erp Family multi-erp ## Erp Products - SAP S/4HANA - IFS Cloud - Infor LN ## Industries - Defense - Aerospace ## Region European Union ## Persona CIO ## Eyebrow European defence supply chain AI ## Intro 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. ## Pain Points ### Ramp-up pressure meets a workforce that can't grow as fast as demand **Detail:** 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 **Detail:** 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 **Detail:** 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 **Detail:** 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 **Detail:** 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. ## Use Cases ### Engineering change impact analysis **Description:** An agent traces which open orders, BOMs, and routings are affected by an incoming engineering change, distinguishing controlled from uncontrolled line items. **Erp Objects:** 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 **Description:** 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. **Erp Objects:** 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 **Description:** Programme managers ask plain-language status questions across a multi-year contract without building a new report for each customer review. **Erp Objects:** 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 **Description:** Procurement asks which qualified suppliers can take on additional capacity for a ramp-up order, grounded in supplier master and historical performance data. **Erp Objects:** 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 **Description:** Quality and programme staff ask for the as-built configuration or serial history of a delivered unit without manually joining multiple ERP tables. **Erp Objects:** 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 **Description:** Quality engineers get a first-draft non-conformance report or corrective action, referencing prior similar findings in the ERP. **Erp Objects:** 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 **Description:** Engineers and quality staff search across specifications, drawings, and contract clauses tied to a specific programme, respecting each programme's own access restrictions. **Erp Objects:** Linked PLM or document records, contract and specification files **Outcome:** Cuts document search time without merging access across programmes that must stay separate. ## Architecture **Overview:** 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. **Layers:** #### ERP connectors **Detail:** 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. #### Data and semantic layer **Detail:** 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. #### Model serving **Detail:** 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. #### Retrieval and agents **Detail:** 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. #### Governance and audit **Detail:** Every query and retrieved record is logged with user identity, feeding the same audit trail your security accreditation already requires for the ERP. ## Deployment Options ### Air-gapped on-prem **Fit:** Suppliers handling nationally classified work or the most sensitive export-controlled programmes **Detail:** 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 **Fit:** Suppliers whose work is controlled but not nationally classified, wanting dedicated infrastructure without owning hardware **Detail:** 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 **Fit:** Groups running both classified or controlled programmes and general commercial work **Detail:** 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 ### 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. **Framework:** National dual-use and arms export control regimes, plus ITAR where US content or joint programmes are involved ### The AI deployment is scoped to fit inside the same accreditation boundary the ERP already sits in, rather than requesting a separate exception. **Framework:** National security accreditation frameworks for defence suppliers, which vary by country and programme ### 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. **Framework:** EU AI Act ### 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. **Framework:** GDPR and national data protection law ### 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. **Framework:** Customer-specific security clauses (prime contractor flow-downs) ## Integration Notes - 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. ## Product Fit ### ERPray **Why:** 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 **Why:** 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. ## Engagement ### Discovery **Duration:** 2-3 weeks **Deliverables:** - Mapping of ERP data sensitivity levels and the accreditation boundary - Priority use case shortlist with programme owners - Draft architecture diagram for security review ### Pilot **Duration:** 6-8 weeks **Deliverables:** - 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 ### Production **Duration:** 4-6 weeks **Deliverables:** - 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 ### Scale **Duration:** ongoing **Deliverables:** - Additional programmes onboarded with their own access scoping - Quarterly review of usage and access logs - New use cases prioritised as ramp-up continues ## Buyer Questions - 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? ## Faq ### Can we use a public LLM API if we redact technical data first? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms AI for European defence suppliers, on-prem AI defence manufacturing, NATO supply chain AI, EDF AI ERP, AI for IFS Cloud defence, export control AI ERP, sovereign AI defence manufacturing, AI for SAP defence suppliers, AI for Infor LN defence, classified data AI ERP, European defence AI compliance, air-gapped AI defence contractor --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json