# AI for ERP in UK Defence Manufacturing: On-Prem, DEFCON 658-Aware > Source: https://netray.co/erp-ai/ai-for-erp-uk-defence-manufacturers > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: AI for ERP ## Short answer UK defence manufacturers add AI to SAP, IFS, Infor LN, or Epicor by keeping the model and the ERP data it reads inside their own network, avoiding the cloud LLM APIs that sit awkwardly against DEFCON 658 and Cyber Essentials Plus requirements. Grounded, read-only question answering and drafting assistants speed up planning, quality, and procurement work without creating a new data path a customer's supplier security review would flag. ## Kind region ## Erp Family multi-erp ## Erp Products - SAP S/4HANA - Infor LN - IFS Cloud - Epicor Kinetic ## Industries - Defence - Aerospace - Manufacturing ## Region United Kingdom ## Persona IT Director ## Eyebrow ERP + AI for the UK defence supply chain ## Intro Suppliers into the UK Ministry of Defence supply chain already operate under a heavier security regime than most manufacturers their size: DEFCON 658 flows down cyber risk requirements based on the sensitivity of the contract, Def Stan 05-138 sets specific technical controls, and JOSCAR accreditation is often a precondition just to be considered by a prime. Adding an AI layer on top of the ERP that runs those programmes has to fit inside that regime, not create a new gap in it. The most common mistake an IT director sees pitched by AI vendors is a cloud copilot that calls a US-hosted API with ERP data attached. That is a difficult position to defend in a supplier security questionnaire, because it introduces a data path outside the company's own network and outside the jurisdiction the rest of the security programme was built around, even when the underlying contract data is not itself classified. The practical answer that holds up under review is the same one used for other sensitive tooling in this sector: run the model on infrastructure the company controls, in the UK, with no default outbound path, and treat the ERP connectors the AI uses the same way any other integration is treated, reviewed, logged, and scoped to read access unless a write-back is explicitly justified. UK GDPR (the retained EU GDPR under the Data Protection Act 2018) adds a second, related layer: personal data in the ERP, HR records, customer and supplier contacts, still needs a lawful basis and appropriate technical measures regardless of the defence context, and an on-prem architecture answers both the security and the data protection question with the same design choice. ## Pain Points ### Cloud LLM APIs conflict with DEFCON 658 posture **Detail:** A tool that sends ERP data to a US-hosted API is difficult to justify in a supplier security assessment once the contract flows down DEFCON 658 risk requirements, even where the specific data involved is not classified. ### JOSCAR and prime supplier assessments scrutinise new tooling **Detail:** Adding a new SaaS AI tool to the environment is exactly the kind of change that shows up in a JOSCAR renewal or a prime's own supplier audit, and an on-prem tool with a documented data flow diagram is a much easier conversation than a SaaS subscription with an opaque backend. ### Cyber Essentials Plus scope creep **Detail:** Any new system that touches ERP data potentially expands the Cyber Essentials Plus assessment scope, so IT directors need the AI layer's boundary and data flows documented clearly before it goes anywhere near production. ### Mixed ERP estate across a multi-site group **Detail:** UK defence manufacturers frequently run different ERPs across divisions, SAP at one site, IFS or Infor LN at another after an acquisition, which makes a single AI approach harder to design than a single-ERP business. ### Small IT teams carrying disproportionate compliance load **Detail:** A mid-size UK defence supplier's IT function is often five to fifteen people covering everything from Cyber Essentials Plus evidence gathering to ERP administration, with little spare capacity to evaluate a new AI vendor's security claims in depth. ## Use Cases ### MRP and production order exception triage **Description:** Surfaces the planning exceptions that actually need a planner's attention today, across SAP MD04, IFS Cloud projections, or Infor LN work order sessions, instead of a manual scan of the full list. **Erp Objects:** SAP MD04, IFS Cloud supply/demand projections, Infor LN whinh work order sessions **Outcome:** planners resolve the daily exception list in a fraction of the time spent scanning it manually ### Quality notification and NCR/CAPA drafting **Description:** Drafts a nonconformance report and CAPA structure from a quality engineer's description, referencing the relevant part, batch, and supplier history already in the ERP. **Erp Objects:** SAP QM notifications, IFS Cloud quality projections, part/batch and vendor master data **Outcome:** cuts the time to a usable first CAPA draft from most of a day to under an hour for routine issues ### Configuration management and serialisation queries **Description:** Answers questions about a specific serial number's current configuration, build status, and open work, pulling from ERP configuration control records instead of a manual cross-reference. **Erp Objects:** serial/lot records, engineering change history, work order status **Outcome:** cuts configuration status research from a manual trace to a direct answer with the underlying records shown ### Purchase order and supplier follow-up **Description:** Handles routine confirmation and delivery follow-up with suppliers, escalating only genuine exceptions like a missed confirmation or a flagged approved supplier list issue. **Erp Objects:** open PO reports, vendor confirmations, approved supplier list status **Outcome:** buyers spend follow-up effort on the exceptions that actually threaten a delivery date ### Engineering change impact assessment **Description:** Lists the open orders, affected BOMs, and routings an ECN touches across the ERP, so production and quality can sequence the change without a manual cross-check. **Erp Objects:** BOM and routing tables, open production and sales orders, ECN records **Outcome:** cuts the manual impact-check time for a routine engineering change from hours to minutes ### Contract deliverable and CDRL tracking **Description:** Answers status questions on contract deliverables against ERP project or programme data, reducing the manual spreadsheet tracking many programme offices still maintain alongside the ERP. **Erp Objects:** project/programme module milestones, deliverable tracking fields, work breakdown structure **Outcome:** fewer status questions require the programme office to update a parallel spreadsheet by hand ### Natural-language reporting across the ERP estate **Description:** Lets a plant or programme manager ask a question once and get an answer grounded in whichever ERP their site runs, without knowing the underlying transaction codes or table names. **Erp Objects:** SAP CDS views, IFS Cloud data lake/projections, Infor LN BODs and reporting tables **Outcome:** fewer one-off report requests reach a stretched central reporting or BI function ## Architecture **Overview:** The architecture keeps everything the AI touches inside a boundary the IT director already controls and can document for a supplier security review, with read-only access by default and a clear escalation path for anything that would write back to the ERP. **Layers:** #### ERP connectors **Detail:** OData/BAPI/IDoc for SAP, ION API and BODs for Infor LN, projections for IFS Cloud, and BAQs/REST v2 for Epicor Kinetic, each read-only by default. #### Data and semantic layer **Detail:** A normalised semantic layer over whichever ERP a given site runs, plus a document index over quality manuals, work instructions, and configuration records kept in the same boundary. #### Model serving **Detail:** An open-weight model served with vLLM or Ollama on GPUs the company owns, on-premises or in a UK-based private hosting arrangement, with no default outbound path to any external API. #### Retrieval and agents **Detail:** RAG grounds answers in current ERP and document data; any agent proposing a write, such as a PO follow-up message, stops for human confirmation before touching the ERP. #### Governance and audit **Detail:** Query and response logs mapped to ERP roles produce the evidence trail a Cyber Essentials Plus assessment, a prime's supplier audit, or an internal security review would ask to see. ## Deployment Options ### Air-gapped on-prem **Fit:** Sites handling controlled or contractually sensitive technical data under DEFCON 658 flow-down requirements **Detail:** The model, retrieval index, and ERP connectors run entirely inside the company's own network with no outbound internet path, giving the clearest possible answer in a supplier security questionnaire. ### Private UK-hosted cloud **Fit:** Manufacturers without in-house GPU operations who still need UK data residency **Detail:** A dedicated instance hosted in the UK, kept outside any multi-tenant shared infrastructure, for companies that want to avoid the capital cost of GPU hardware while keeping data onshore. ### Hybrid across sites **Fit:** Multi-site groups with a mix of contract sensitivity levels across divisions **Detail:** The most sensitive sites run air-gapped on-prem while lower-sensitivity sites share a private UK-hosted instance, with one consistent governance and audit layer across both. ## Compliance ### On-prem or UK-only private hosting with no outbound path to a non-UK model API gives a direct, defensible answer to the cyber risk flow-down requirements these contracts impose, without relying on a third-party vendor's own claims. **Framework:** DEFCON 658 / Def Stan 05-138 ### The AI layer's boundary and data flows are documented clearly so it can be included in, rather than complicate, the annual Cyber Essentials Plus assessment scope. **Framework:** Cyber Essentials Plus ### Personal data in the ERP (HR, customer, supplier contacts) stays inside the company's own boundary or a UK-based processor, with logged access supporting the company's existing records of processing. **Framework:** UK GDPR / Data Protection Act 2018 ### A documented, on-prem AI architecture with clear data flow diagrams is straightforward to present as evidence during JOSCAR renewal or a prime's own supplier assurance review. **Framework:** JOSCAR supplier accreditation ### Faster, more consistent planning and quality drafting support the delivery performance and continuous improvement expectations that SC21-aligned customers look for from their suppliers. **Framework:** SC21 supply chain excellence principles ## Integration Notes - SAP: OData services via SAP Gateway, BAPI/RFC, and IDoc, read-only by default with write-back requiring explicit human confirmation per transaction. - IFS Cloud: read access through IFS's projections (the OData-based API layer), avoiding the need for direct database access. - Infor LN: ION API and Business Object Documents for transactional and event data, consistent with how LN already exposes data to other systems. - Epicor Kinetic: BAQs for reporting-style access and REST v2 for transactional integration, using the same authentication model as existing Epicor integrations. - A shared identity layer maps each user's existing ERP role to what the assistant can see, so access never exceeds what the user could already see in the ERP directly. - Document sources such as quality manuals and configuration control records are indexed inside the same network boundary as the ERP data, not in an external SaaS tool. - All model inference and retrieval run on infrastructure inside the UK with no default outbound call to a non-UK or non-EU API. ## Product Fit ### ERPray **Why:** For a group running SAP at one site and IFS Cloud or Infor LN at another, ERPray's connector-based approach gives a consistent, read-only question-answering experience across the estate. ### Custom build **Why:** Programme-specific work like CDRL tracking or configuration management queries usually needs logic tailored to how a given site's project module and engineering change process are configured. ## Engagement ### Discovery **Duration:** 2-3 weeks **Deliverables:** - Inventory of ERP systems in use across sites and how each exposes data today - Review against current DEFCON 658, Cyber Essentials Plus, and JOSCAR evidence requirements - Use case shortlist ranked by effort and impact - On-prem GPU or private UK hosting sizing estimate ### Pilot **Duration:** 6-8 weeks **Deliverables:** - One use case live in read-only mode at a single site - Model evaluation against real ERP and document data - Data flow diagram and security documentation for internal or customer review - User feedback loop and adoption metrics ### Production **Duration:** 6-10 weeks **Deliverables:** - Hardened deployment with role-based access tied to existing ERP roles - Full audit logging integrated into existing security monitoring - Documentation prepared for Cyber Essentials Plus renewal or JOSCAR review - Runbook covering model updates and incident response ### Scale **Duration:** Ongoing **Deliverables:** - Rollout to additional sites, including different ERPs under the shared governance layer - Additional use cases added from the original shortlist - Refresher briefings for security and compliance stakeholders - Quarterly review of model options and performance ## Buyer Questions - Where does the model run, and does the data flow diagram hold up under a JOSCAR or prime supplier review? - Does any part of the pipeline call a non-UK or non-EU API by default, including for a secondary function like embeddings? - Can Cyber Essentials Plus assessors be given a clear boundary diagram for the AI system in under an hour? - How does the tool respect our existing ERP role-based access rather than creating a broader access path? - If we run this across SAP, IFS, and Infor LN sites, is the governance and audit experience consistent across all three? - What is the fallback if the on-prem GPU or private UK hosting is unavailable for a day? - What happens to our data, models, and configuration if we end the engagement? ## Faq ### Does DEFCON 658 specifically prohibit AI tools? **Answer:** No, DEFCON 658 does not name AI specifically, it flows down cyber risk profile requirements based on contract sensitivity that any new tool touching contract data has to satisfy. A cloud LLM API that sends ERP data outside the company's network is a difficult fit for a higher-risk-profile contract, while an on-prem AI layer with no outbound data path is straightforward to map against the same requirements. ### Will an on-prem AI tool expand our Cyber Essentials Plus assessment scope? **Answer:** It will be in scope, since it touches ERP data, but a well-documented on-prem system with a clear boundary is usually easier to assess than a SaaS subscription with an external backend the assessor cannot inspect. Having the data flow diagram and access model ready before the assessment keeps this from becoming a blocker. ### Can this work if we run SAP at one site and IFS Cloud or Infor LN at another? **Answer:** Yes. Each ERP is read through its own native interface, SAP via OData/BAPI, IFS Cloud via projections, Infor LN via ION API and BODs, with a shared governance and audit layer on top so users across sites get a consistent AI experience without a single ERP-specific product forcing a common platform. ### Do we need JOSCAR accreditation for the AI vendor itself? **Answer:** JOSCAR accredits suppliers into the defence supply chain generally, not specific software vendors, so the more relevant question is whether your own use of the AI tool is defensible in your JOSCAR renewal or a prime's supplier assessment. A documented, on-prem architecture with no external data path is the evidence that conversation needs. ### How is UK GDPR different from EU GDPR for this? **Answer:** UK GDPR, under the Data Protection Act 2018, is substantively similar to EU GDPR post-Brexit, so the same design principles apply: a documented lawful basis for processing personal data, data minimisation, and appropriate technical measures. Keeping the AI system's processing inside the UK simplifies the international transfer question the same way EU-only processing does for an EU company. ### Is this realistic for a mid-size tier-2 or tier-3 defence supplier, not just a prime? **Answer:** Yes, and the deployment scales down cleanly: a single-site, single-ERP supplier can run a modest on-prem GPU setup or a small private UK-hosted instance, with the same architecture principles, on-prem or UK-only, read-only by default, human approval on writes, applying regardless of company size. ### What is SC21 and why does it matter for an AI project? **Answer:** SC21 was a UK aerospace and defence supply chain excellence initiative focused on delivery performance and continuous improvement. Even where a specific SC21 programme is not active for a given relationship, customers in this sector still evaluate suppliers on the same underlying themes, and faster, more consistent planning and quality processes support that evaluation regardless of what it is formally called. ## Search terms AI for ERP UK defence, on-prem AI defence manufacturing, DEFCON 658 AI, Cyber Essentials Plus AI ERP, AI for SAP UK defence, AI for IFS Cloud defence, AI for Infor LN UK, JOSCAR AI supplier, UK GDPR AI ERP, private LLM UK defence manufacturing, AI ERP aerospace supply chain UK, AI copilot UK defence supplier --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json