ERP AI for DISP members
AI for ERP in the Australian Defence Industry: DISP-Aligned and On-Prem
Short answer
Australian defence suppliers add AI to SAP, IFS Cloud, or Infor LN by keeping the model and the ERP data it reads inside their own network or an Australian-controlled boundary, so the deployment maps cleanly to Defence Industry Security Program membership evidence, the Information Security Manual, and Essential Eight maturity targets. Grounded, read-only question answering and drafting assistants speed up planning, quality, and configuration work without adding a data path a DISP assessor or a prime's supplier audit would need to query.
- ERP
- SAP S/4HANA, IFS Cloud, Infor LN
- Industries
- Defence, Aerospace, Manufacturing
- Written for
- CIO
Companies holding Defence Industry Security Program membership already carry a documented security posture that a new tool has to fit inside, not sit beside. DISP requirements scale with membership level, from Entry through Level 3, and cover governance, personnel, physical, and cyber security together, which means an AI layer touching ERP data is naturally in scope for the same evidence trail the company already maintains for everything else in its environment.
The cyber security component leans heavily on the Australian Signals Directorate's Information Security Manual and the Essential Eight mitigation strategies, and most DISP members are already working toward a target Essential Eight maturity level. A cloud AI tool that calls an offshore model API sits awkwardly against that target: it is a new, often opaque data path that has to be justified from scratch in the next assessment cycle, whereas a locally controlled deployment slots into controls the company has already built and documented.
AUKUS Pillar II adds a further layer that a CIO in this sector cannot ignore. The advanced capability work under Pillar II, spanning AI, autonomy, and related technologies, comes with export control obligations that interact with both Australian law and, for companies handling US-origin technical data, the US International Traffic in Arms Regulations and the licensing exemptions introduced for the AUKUS partners. An AI system that might process that technical data has to respect the same access boundaries the company already applies to it under existing export control procedures, not create a new one.
None of this is a reason to avoid AI, it is a reason to be specific about where the model runs and what it can see. The practical pattern that holds up under a DISP assessment or a prime's supplier review is an on-prem or Australian-controlled deployment, read-only by default, with every query and response logged against the user's existing ERP role, so the evidence a CIO needs for the next security review already exists by the time the review happens.
What usually gets in the way
The problems we hear most from cio teams running SAP S/4HANA.
DISP evidence has to extend to any new tool
A new AI system touching ERP data is squarely inside the governance, personnel, and cyber security domains DISP membership already assesses, so it needs the same documented controls and evidence trail as everything else in the environment, not a separate exemption.
Essential Eight maturity targets complicate a cloud LLM API
Most DISP members are tracking toward a specific Essential Eight maturity level under the ASD framework, and a tool that sends ERP data to an offshore API is a new, hard-to-control data path that works against that target rather than for it.
AUKUS Pillar II and ITAR overlay export control on the data itself
Where the ERP holds US-origin technical data covered by ITAR, or Pillar II advanced capability work, the AI layer has to respect the same access segregation the company already applies under its export control procedures, and getting that wrong is a compliance issue independent of general cyber security posture.
Mixed ERP estate across a multi-site defence supplier
Australian defence manufacturers frequently run SAP at one site and IFS Cloud or Infor LN at another after an acquisition or a program-specific implementation, which makes a single AI approach to planning and quality harder to design than a single-ERP business.
Small IT teams carrying the full DISP compliance load
A mid-size Australian defence supplier's IT function is often a handful of people covering ISM control implementation, Essential Eight evidence gathering, and day-to-day ERP administration, with little spare capacity to evaluate an AI vendor's security claims line by line.
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.
Production and MRP exception triage
Surfaces the planning exceptions that need a planner's attention today across SAP MD04, IFS Cloud supply and demand projections, or Infor LN work order sessions, instead of a manual scan of the full exception list.
Touches: SAP MD04, IFS Cloud projections, Infor LN whinh work order sessions
Outcome: planners work the genuine daily exception list in a fraction of the time a full manual scan takes
Quality notification and NCR/CAPA drafting
Drafts a nonconformance report and CAPA structure from a quality engineer's description of a defect, pulling the relevant part, batch, and supplier history already recorded in the ERP.
Touches: SAP QM notifications, IFS Cloud quality projections, part and batch master data
Outcome: cuts the time to a usable first CAPA draft from most of a day to well under an hour for routine defects
Configuration management and serialisation queries
Answers direct questions about a specific serial number's current configuration, build status, and open engineering changes, pulling from configuration control records instead of a manual cross-reference across modules.
Touches: serial and lot records, engineering change history, work order and routing status
Outcome: replaces a manual configuration trace with a direct answer that shows the underlying records used
Purchase order and approved supplier follow-up
Handles routine confirmation and delivery follow-up with suppliers, escalating only genuine exceptions such as a missed confirmation date or an approved supplier list discrepancy to the buyer.
Touches: open PO reports, vendor confirmations, approved supplier list status
Outcome: buyers spend follow-up effort on the exceptions that actually threaten a delivery milestone
Engineering change impact assessment
Lists the open orders, affected bills of material, and routings an engineering change notice touches across the ERP, so production and quality can sequence the change without a manual cross-check.
Touches: 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 milestone tracking
Answers status questions on contract deliverables and program milestones against ERP project data, reducing the parallel spreadsheet tracking many program offices maintain alongside the ERP itself.
Touches: project or program module milestones, work breakdown structure, deliverable tracking fields
Outcome: fewer status requests require the program office to update a manual tracker by hand
Natural-language reporting across the ERP estate
Lets a program or plant manager ask a question once and get an answer grounded in whichever ERP their site runs, without needing to know the underlying table names or transaction codes.
Touches: SAP CDS views, IFS Cloud data lake and projections, Infor LN BODs and reporting tables
Outcome: fewer one-off report requests land on a stretched central reporting or program management office
Reference architecture
The architecture keeps every part of the AI system inside a boundary the CIO already controls and can document as evidence for a DISP assessment, with read-only access by default and a defined escalation path for anything that would write back to the ERP.
- 1
ERP connectors
OData/BAPI/IDoc for SAP, projections for IFS Cloud, and ION API/BODs for Infor LN, each read-only by default and mapped to the user's existing ERP role.
- 2
Data and semantic layer
A normalised semantic layer over whichever ERP a given site runs, plus a document index over quality manuals, work instructions, and configuration records kept inside the same boundary.
- 3
Model serving
An open-weight model served with vLLM or Ollama on GPUs the company owns, on-premises or in an Australian-controlled private hosting arrangement, with no default outbound path to an offshore API.
- 4
Retrieval and agents
Retrieval-augmented generation grounds answers in current ERP and document data; any agent proposing a write, such as a supplier follow-up email, waits for human confirmation before it touches the ERP.
- 5
Governance and audit
Query and response logs mapped to ERP roles produce the evidence trail a DISP assessment, an Essential Eight maturity review, or a prime's supplier audit would ask to see.
Integration notes for your ERP team
- 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 integrations.
- A shared identity layer maps each user's existing ERP role to what the assistant can see, so access through the AI layer never exceeds what the user could already see 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 outside DISP scope.
- All model inference and retrieval run on infrastructure inside Australia, or fully on-prem, with no default outbound call to a non-Australian API.
- Export-control-sensitive fields can be excluded from the retrieval index entirely at the connector level, rather than relying on the model to withhold them after the fact.
Deployment options
Air-gapped on-prem
Sites handling ITAR-controlled technical data or AUKUS Pillar II advanced capability work
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 DISP assessment or an export control review.
Private Australian-hosted cloud
Manufacturers without in-house GPU operations who still need Australian data residency
A dedicated instance hosted in an Australian data centre region, kept outside multi-tenant shared infrastructure, for companies that want to avoid the capital cost of GPU hardware while keeping data onshore and under Australian jurisdiction.
Hybrid across sites
Multi-site groups with a mix of program sensitivity levels across divisions
The most sensitive sites run air-gapped on-prem while lower-sensitivity sites share a private Australian-hosted instance, with one consistent governance and audit layer covering both.
Compliance and data control
How the architecture supports your obligations. Certification and accountability stay with your organisation; the design keeps the evidence straightforward.
Defence Industry Security Program (DISP)
The deployment's data flow diagram, access controls, and audit logging are documented in the same terms DISP membership already assesses, so the AI layer strengthens rather than complicates the next review.
Information Security Manual (ISM) and Essential Eight
On-prem or Australian-only hosting with no default outbound path to an offshore model API keeps the AI system aligned with the company's Essential Eight maturity target rather than introducing a new control gap to close.
AUKUS Pillar II / ITAR-related export control
Access to ITAR-controlled or Pillar II advanced capability technical data through the AI layer mirrors the ERP's own role-based restrictions rather than creating a new, broader access path around them.
Privacy Act 1988 / Australian Privacy Principles
Personal data in the ERP, employee, customer, and supplier contacts, stays inside the company's own boundary or an Australian-based processor, with logged access supporting the company's existing privacy obligations.
Protective Security Policy Framework (PSPF)
Where the company handles Australian Government information as part of a defence contract, the same on-prem architecture and audit trail are designed to be presentable against PSPF information security expectations without relying solely on a vendor's own claims.
Where Netray fits
ERPray
For a group running SAP at one site and IFS Cloud or Infor LN at another, ERPray's connector-based, read-only question-answering approach gives a consistent AI experience across the estate without a single-ERP product forcing a common platform.
Custom build
Program-specific work such as configuration management queries or contract milestone tracking usually needs logic tailored to how a given site's project module and engineering change process are configured.
How an engagement runs
Phase 1 . 2-3 weeks
Discovery
- -Inventory of ERP systems in use across sites and how each exposes data today
- -Review against current DISP membership evidence, Essential Eight maturity target, and any AUKUS/ITAR access segregation already in place
- -Use case shortlist ranked by effort and impact
- -On-prem GPU or Australian private hosting sizing estimate
Phase 2 . 6-8 weeks
Pilot
- -One use case live in read-only mode with a defined user group
- -Model evaluation against real ERP and document data from that site
- -Data flow diagram prepared for internal review or a prime's supplier assessment
- -User feedback loop and adoption metrics reviewed with IT and the pilot group
Phase 3 . 6-10 weeks
Production
- -Hardened deployment with role-based access tied to existing ERP roles
- -Full audit logging integrated with existing security monitoring
- -Documentation prepared to support the next DISP assessment cycle
- -Runbook covering model updates and incident response
Phase 4 . Ongoing
Scale
- -Rollout to additional sites, including different ERPs under the shared governance layer
- -Additional use cases added from the original shortlist based on pilot results
- -Refresher briefings for security and compliance stakeholders
- -Quarterly review of model options and performance
Questions to ask any vendor, including us
A short list that separates real SAP S/4HANA AI work from a chatbot demo.
- Where does the model physically run, and does the data flow diagram hold up under a DISP assessment or a prime's supplier review?
- Does any part of the pipeline call an offshore API by default, including for a secondary function like embeddings?
- Does the tool respect our existing export control access segregation for ITAR or Pillar II data, or does it need a separate, broader service account?
- Can we export the full query and response log as evidence for our next Essential Eight maturity self-assessment?
- If we run this across SAP, IFS Cloud, and Infor LN sites, is the governance and audit experience consistent across all three?
- What is the fallback if the on-prem GPU or Australian-hosted instance is unavailable for a day?
- What happens to our data, models, and configuration if we end the engagement?
- Has the vendor made any claim of DISP membership, security clearance, or a specific prime relationship that we should verify independently?
Frequently asked questions
Does DISP membership require our AI tools to be assessed specifically?
DISP assesses the company's governance, personnel, physical, and cyber security posture as a whole, and a new tool touching ERP data is naturally in scope for that assessment rather than exempt from it. The practical approach is to design the AI deployment so its data flows, access controls, and logging are documented in the same terms the rest of the DISP evidence base already uses.
Can a cloud LLM API meet our Essential Eight maturity target?
It depends on the specific maturity level being targeted, but an offshore API call is a new outbound data path that most Essential Eight strategies, particularly application control and restricting administrative privileges, were not designed around. An on-prem or Australian-only deployment with no default outbound path is simpler to align with an existing Essential Eight uplift plan than adding a new external dependency.
How does AUKUS Pillar II affect an AI project on our ERP?
Pillar II covers advanced capability collaboration between Australia, the UK, and the US, and where a company's ERP holds technical data connected to that work, including US-origin data subject to ITAR, the AI layer has to respect the same access segregation already applied to it. This is an access control design question, not a reason to avoid AI, and it is handled the same way the ERP itself already handles it: role-based restriction, not a blanket exclusion.
Can this work if we run SAP at one site and IFS Cloud or Infor LN at another?
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 forcing a single ERP-specific product on the whole group.
Is this realistic for a small or mid-size DISP member, not just a Level 3 prime?
Yes, and the deployment scales down cleanly. A single-site, single-ERP DISP Entry or Level 1 member can run a modest on-prem GPU setup or a small Australian-hosted private instance, with the same design principles, on-prem or Australian-only, read-only by default, human approval on writes, applying regardless of company size.
How is this different from the AI features already built into SAP or Microsoft's Australian cloud regions?
Vendor-embedded copilots are a reasonable option if the company is comfortable with data processed in that vendor's cloud, including an Australian region, and does not need model choice or offshore-independence beyond what the vendor offers. An on-prem or self-hosted private model becomes the better fit when the company wants full control over where inference happens, needs to extend AI to non-ERP sources like a document store, or is working toward a specific Essential Eight or DISP posture that an external SaaS dependency complicates.
What happens to data connected to Australian Government or Defence information under PSPF?
It should be scoped explicitly rather than left to fall inside a general-purpose AI deployment by default. Where PSPF information security expectations apply, the same on-prem architecture and access-role mapping used for ITAR and Pillar II data extends naturally to PSPF-governed information, keeping one consistent control model rather than a separate system for each regime.
Related guides
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.
ITAR + on-prem AIITAR-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.
MRO ERP + AI in SingaporeAI for ERP in Singapore Aerospace MRO: On-Prem and PDPA-Ready
On-prem AI for IFS, SAP, and AMOS-type MRO systems in Singapore aerospace: PDPA-aligned, CAAS-ready, built for the Seletar Aerospace Park hub.
ERP + AI for Korean manufacturingAI for ERP in South Korea: On-Prem AI for Electronics and Battery Manufacturers
On-prem AI for SAP, Oracle, and domestic ERPs in South Korean manufacturing: PIPA-aligned, built for electronics, battery, and defence supply chains.
IFS Cloud + on-prem AIAI 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.
ERP AI Cost GuideWhat ERP AI Actually Costs: A CFO's Guide
A CFO's guide to what ERP AI actually costs: GPU hardware, model licensing, integration and connector work, and realistic ongoing run-rate ranges.
Plan it with numbers
Defense Contractor AI Readiness Assessment
A 9-question assessment measuring whether your defense manufacturing business can adopt AI productively and compliantly - across governance, data, infrastructure, and skills.
Free ToolAir-Gapped AI Readiness Assessment
A 10-question assessment that scores how prepared your organization is to deploy and operate LLMs inside an air-gapped or classified enclave.
Free ToolSovereign AI Readiness Assessment
Score your organization across eleven dimensions of sovereign AI readiness, from data residency and model provenance to cleared personnel and air-gapped operations.
GuideAI Governance for Export-Controlled Data (ITAR/EAR)
AI governance for export-controlled data: policies, access controls, and audit trails that keep ITAR and EAR data out of public LLMs and off foreign servers.
GuideOn-Prem AI for Defense Contractors: The Complete Guide
On-prem AI for defense contractors: deploy LLMs and AI agents inside your CMMC and ITAR boundary. Architecture, hardware costs, timelines, and vendor options.
GuideHow the Defense Industry Procures AI: A Practical Guide
A practical guide to how the defense industry procures AI: OTAs, SBIR, CDAO pathways, DFARS and CMMC requirements, and timelines for primes and subs.
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.