On-prem AI, any ERP, A&D
On-Prem AI for ERP in Aerospace, Defense, and Electronics Manufacturing
Short answer
Aerospace, defense, and electronics manufacturers typically cannot send ERP data to a public cloud AI service without risking a deemed export under ITAR/EAR or expanding their CMMC assessment boundary. On-prem AI, an open-weight model served on customer-owned GPUs inside the existing network boundary, avoids that risk by keeping data, prompts, and model weights inside the facility, whether the underlying ERP is SAP, Infor LN, Costpoint, IFS, or Oracle EBS.
- ERP
- SAP S/4HANA, SAP ECC, Infor LN, Infor SyteLine, IFS Cloud, Deltek Costpoint, Oracle EBS
- Industries
- Aerospace, Defense, Electronics
- Written for
- CIO
Aerospace, defense, and electronics manufacturers are usually running more than one ERP, SAP for corporate finance, Infor LN or SyteLine for engineer-to-order manufacturing, Costpoint for government contract accounting, IFS or Maintenix for MRO, and every one of those systems holds data that a public cloud AI service is, at minimum, a compliance question mark for. ITAR technical data, CUI under a DFARS clause, AS9100 traceability records, and customer-confidential BOMs all carry restrictions that most SaaS AI terms of service were not written with in mind.
This is the reason on-prem AI comes up constantly in this sector specifically, not because air-gapped deployment is inherently better technology, but because it is often the only deployment model that a facility security officer, an empowered official, or a CMMC assessor can actually sign off on. A vendor's answer that data 'may be processed in the United States' is not the same as a documented, auditable boundary that a compliance program can defend.
The practical challenge is that 'on-prem AI for our ERP' means something different depending on which ERP, and often several ERPs, you actually run. A private LLM grounded on SAP's CDS views looks different in its connector layer than one grounded on Infor LN sessions and BODs or Costpoint's project and timesheet tables, even though the underlying model-serving and governance layers can be shared across all of them.
This page is the hub for that broader problem: what on-prem AI means architecturally across the ERPs common in this sector, which compliance frameworks actually drive the on-prem requirement, and where to go deeper on a specific ERP, region, or regulation. It links out to the ERP-specific and regulation-specific pages below rather than duplicating their depth here.
What usually gets in the way
The problems we hear most from cio teams running SAP S/4HANA.
Public cloud AI creates a deemed export risk
Sending ITAR-controlled technical data to a cloud AI API can constitute a release to foreign-national personnel operating or having access to that service, regardless of intent, which is a serious and often underappreciated compliance exposure for engineering and program teams experimenting with AI tools informally.
CUI scope creep from an unscoped AI tool
Adding a SaaS AI assistant that touches CUI without formally scoping it into your System Security Plan and CMMC assessment boundary creates an unmanaged asset that shows up as a finding in your next assessment, or worse, in an incident review.
Multiple ERPs mean multiple, inconsistent AI answers
Corporate finance in SAP, engineering and manufacturing in Infor LN, and government contract accounting in Costpoint each get evaluated for AI separately, often by different vendors, resulting in three inconsistent governance models instead of one coherent architecture.
Air-gapped networks cannot reach any SaaS copilot
Sites on a closed or classified network cannot use SAP Joule, Copilot for Dynamics 365, or any other cloud-dependent vendor AI feature at all, regardless of licensing, because there is no network path to the vendor's cloud.
Primes and customers ask hard questions IT cannot yet answer
A prime's supplier quality or cybersecurity team increasingly asks directly whether AI tools touch program data and how, and a vague or evolving answer can affect a supplier's standing on a bid.
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.
First article inspection and FAI drafting
Drafting AS9102 first article inspection report sections from inspection data and drawing callouts.
Touches: Quality module inspection records, drawing/document references, characteristic accountability tables
Outcome: Cuts routine FAI documentation drafting time while keeping the underlying data, often drawing-level technical detail, entirely inside the facility.
NCR/CAPA drafting across quality and engineering
Turning inspector and engineer notes into structured NCR/CAPA records with linked prior similar findings.
Touches: QM notifications or the equivalent NCR/CAPA tables in SAP, LN, or IFS, plus historical defect records
Outcome: Improves CAPA consistency and reduces drafting time without exporting quality escape details to a third-party cloud service.
Configuration and BOM impact analysis
Summarizing which serialized units, open orders, and as-built configurations an engineering change affects.
Touches: ECO/ECN records, serialized configuration management tables, BOM/routing data, project structure in LN or IFS
Outcome: Reduces the manual cross-referencing burden on configuration management engineers on programs with strict as-designed-versus-as-built traceability requirements.
ITAR-segregated project cost and status reporting
Answering program manager questions about cost, schedule, and status without exposing segregated project data outside its access boundary.
Touches: Project accounting tables in Costpoint or LN, timesheet and indirect rate data, WBS structures
Outcome: Keeps the same role-based access controls already governing who can see a given ITAR-segregated project, since the AI layer inherits the ERP's own permissions rather than creating a new access path.
MRO technical records and AD/SB compliance tracking
Summarizing maintenance history and flagging airworthiness directive or service bulletin compliance status.
Touches: Maintenance and inspection records in Maintenix, IFS, or an ERP's PM module, AD/SB reference data
Outcome: Speeds up technical records review while keeping aircraft and component records, which often carry their own confidentiality requirements, inside the operator's or MRO's own network.
EMS/electronics quote-to-cash from historical data
Drafting a quote for a new RFQ using pricing and lead-time patterns from similar historical jobs.
Touches: Historical quote, job cost, and routing data, BOM cost rollups, component pricing history
Outcome: Shortens quote turnaround on repeat-like RFQs while keeping cost structure and margin data, which is commercially sensitive, out of any third-party service.
Shop-floor traveler and work instruction assistant
Operators ask routing and work-instruction questions at the terminal, including for multi-language shop floors.
Touches: Work order/traveler records, routing steps, linked controlled documents
Outcome: Reduces interruptions to supervisors and engineers for routine status and instruction questions, with controlled document content never leaving the local network.
Reference architecture
The same five-layer reference architecture applies whether the ERP underneath is SAP, Infor LN, Costpoint, IFS, or Oracle EBS; what differs by ERP is the connector layer, and what differs by regulation is how strictly the boundary around the model-serving and governance layers is drawn.
- 1
ERP connectors
SAP via OData/CDS or BAPI/RFC, Infor LN via BODs and sessions through ION, Costpoint via its published APIs or a read replica, IFS via projections, Oracle EBS via interface tables and concurrent programs; each ERP's own official integration path, kept read-only by default.
- 2
Data and semantic layer
A documented mapping of each ERP's schema, including customizations, to business terms, built separately per ERP but sharing a common documentation format and governance process across the landscape.
- 3
Model serving
An open-weight model (Llama, Qwen, Mistral, Gemma, gpt-oss class) served with vLLM or Ollama on GPU hardware physically inside the facility or enclave, with no outbound path to any public API, this layer can be genuinely shared across all the ERPs in the landscape.
- 4
Retrieval and agents
Retrieval indexes scoped and access-controlled per program or project, inheriting the same segregation already enforced in the ERP, with any write-back action gated behind human approval.
- 5
Governance and audit
A single audit and logging framework across all connected ERPs, giving security and compliance one place to review AI activity instead of a different log format per system.
Integration notes for your ERP team
- Treat each ERP's connector as a separate integration effort, but design the semantic layer's documentation format and the governance/audit layer's logging schema to be common across all of them from the start.
- For SAP-side data, prefer OData services and CDS views over direct table access where available; for LN, use ION and BODs rather than direct database queries against sessions where possible.
- For Costpoint, scope any AI connector strictly to the specific contracts and WBS elements a given user or agent is authorized to see, mirroring the project-level access segregation Costpoint already enforces.
- Keep a single, physically or logically separate deployment for any ITAR/CUI-touching enclave rather than trying to retrofit access controls onto a shared multi-tenant deployment after the fact.
- Coordinate with your facility security officer or empowered official before the first pilot, not after, so the deployment model is reviewed against your specific technology control plan from the outset.
- Where multiple sites run different ERPs, prioritize a shared governance and audit framework over a shared model deployment, the compliance benefit of consistent logging and approval workflows matters more than infrastructure consolidation.
- Budget for offline model and software update processes if the deployment is genuinely air-gapped, this operational overhead is real and should be planned for, not discovered at the first patch cycle.
Deployment options
Air-gapped on-prem, classified or ITAR enclave
Programs with technical data subject to ITAR, or systems handling CUI inside a scoped CMMC enclave
GPU hardware, model, and retrieval index all run with no path to any external network; model and software updates apply through an approved offline transfer process.
Private or sovereign cloud, single tenant
Organizations that need elastic capacity across a distributed footprint but still require contractual and technical guarantees on data residency and access
Requires explicit contractual terms on data location, personnel access (including any foreign-national support staff), and audit rights, verified against your specific program's requirements before selecting a provider.
Hybrid, segmented by program
Organizations with a mix of unrestricted commercial data and ITAR/CUI-restricted program data under one corporate IT umbrella
Commercial-side ERPs and use cases can use a lighter-weight cloud or on-prem deployment while restricted programs stay in a dedicated air-gapped enclave, sharing the same architecture pattern but not the same physical infrastructure.
Compliance and data control
How the architecture supports your obligations. Certification and accountability stay with your organisation; the design keeps the evidence straightforward.
ITAR / EAR (deemed export)
Design the retrieval index and model deployment so ITAR-controlled technical data never leaves the facility or transits any service where non-U.S.-person personnel could access it, and document access controls by U.S. person status where the underlying program requires it.
CMMC 2.0 / DFARS 252.204-7012 / NIST SP 800-171
Scope the AI system into your existing System Security Plan and assessment boundary from day one rather than adding it as an unscoped tool; this is usually the deciding factor in whether an assessor treats the deployment as a strength or a finding.
AS9100D
Where AI drafts quality records (NCR, CAPA, FAI), maintain human review and sign-off as the record of authority, and keep full traceability of what the AI proposed versus what a qualified person approved.
Export-controlled document handling
Apply the same marking and access-control discipline to any document indexed for retrieval, drawings, specifications, test reports, as already applies to those documents on paper or in your document management system; an AI index is not exempt from existing handling rules.
Customer and prime flow-down requirements
Review specific contract clauses on AI or third-party tool use before assuming a given deployment model is acceptable for a particular program; some primes have begun adding explicit AI data-handling requirements to flow-down clauses.
Where Netray fits
ERPray
For natural-language question answering and read-only agents across SAP, Infor LN, Costpoint, IFS, or Oracle EBS, ERPray's connector architecture and role-aware access model are built for exactly this multi-ERP, on-prem A&D context.
Custom build
For deeply program-specific use cases, configuration management impact analysis, FAI drafting, or MRO technical records tied to specialized systems, a custom build scoped to the specific ERP and program constraints is typically the right approach.
How an engagement runs
Phase 1 . 2-4 weeks
Discovery
- -ERP and data landscape map with ITAR/CUI classification by system and program
- -Facility security officer or empowered official review of the proposed deployment model
- -Use case shortlist scored by compliance sensitivity and value
Phase 2 . 8-10 weeks
Pilot
- -Air-gapped or enclave deployment for the pilot use case
- -Working prototype against one ERP and one program's data
- -Compliance review of the deployment against ITAR/CMMC requirements
Phase 3 . 10-14 weeks
Production
- -Hardened deployment with full audit logging integrated into the security program's existing tooling
- -Approval workflows for any write-back actions
- -Documentation for the next CMMC assessment or ITAR compliance review
Phase 4 . Ongoing
Scale
- -Additional ERPs or sites onboarded onto the shared governance framework
- -Periodic compliance re-review as programs or classifications change
- -Model refresh plan compatible with offline update processes
Questions to ask any vendor, including us
A short list that separates real SAP S/4HANA AI work from a chatbot demo.
- Has our facility security officer or empowered official reviewed this specific deployment model in writing?
- Exactly which data classification, unrestricted, CUI, ITAR, does each in-scope use case touch, and is the deployment scoped accordingly?
- Does this deployment introduce any outbound network path to a public cloud service, directly or through an update mechanism?
- How is access segregated by program or contract, and does the AI layer inherit our existing ERP-level segregation or create a new one?
- What does our next CMMC or customer security assessment need to see documented about this AI system?
- How are model and software updates applied in an air-gapped environment, and who is accountable for that process?
- If we run more than one ERP, is the governance and audit framework shared, or are we building three separate compliance stories?
Frequently asked questions
Can we use a vendor's cloud AI copilot if we are ITAR-regulated?
It depends on the specific data involved and the vendor's exact cloud configuration for your tenant, but for genuinely ITAR-controlled technical data, most vendor cloud AI tiers carry deemed-export risk that a private, access-controlled on-prem deployment avoids by design. Get a written compliance answer from the vendor for your specific case before assuming otherwise.
Do we need a separate AI deployment for each ERP we run?
The connector layer is necessarily ERP-specific, but the model-serving and governance layers can often be shared across SAP, Infor LN, Costpoint, and other systems within the same security boundary, which reduces both cost and the number of separate compliance stories you have to maintain.
How does on-prem AI fit into a CMMC Level 2 assessment?
Treat the AI system as part of your scoped environment from the design stage: document what CUI it touches, how access is controlled, and how activity is logged, and include it explicitly in your System Security Plan rather than adding it later as an afterthought that surprises an assessor.
What GPU hardware is typically needed for this kind of deployment?
It depends on model size and concurrent user count, but mid-size open-weight models (in the 7B-70B parameter class) serving a pilot-scale user group typically run on one to a small number of enterprise GPUs; production scale for a larger user base needs proper sizing against expected concurrency, not a rule of thumb.
Can this work across multiple sites with different classification levels?
Yes, with a hybrid design: sites or programs handling ITAR/CUI data run in a dedicated air-gapped enclave, while commercial-only sites can use a lighter private cloud or on-prem deployment, sharing the same architectural pattern and governance framework without sharing physical infrastructure.
Does this replace our existing quality or configuration management system?
No. The AI layer is designed to sit alongside your existing quality, configuration management, and ERP systems, drafting and summarizing from their data, with a human remaining the record of authority for NCRs, CAPAs, and configuration changes.
How long does a compliance review typically add to the timeline?
Involving your facility security officer or empowered official at the discovery phase, rather than after a pilot is built, usually adds a few weeks up front but avoids a much larger delay later if the deployment model has to be redesigned after the fact.
Related guides
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.
CMMC 2.0 + on-prem AICMMC Level 2 AI for ERP Without Blowing Up Your Scope
How to deploy AI inside your CMMC 2.0 Level 2 assessment boundary without expanding CUI scope. Enclave architecture a CISO can defend to a C3PAO.
AS9100D + on-prem AIAI for AS9100 Quality Management on Your ERP
AI on top of your ERP quality module for AS9100D suppliers: NCR/CAPA drafting, FAI support, counterfeit parts screening, with a full audit trail.
EMS / PCBA + on-prem AIAI for EMS and PCBA Manufacturers Running SyteLine, Epicor, or NetSuite
AI for EMS and PCBA manufacturers on SyteLine, Epicor, or NetSuite: automate BOM scrubbing, AVL checks, and obsolescence alerts, grounded in your own ERP data on-prem.
Costpoint + CMMC-scoped AIOn-prem AI for Costpoint inside a CMMC Level 2 enclave
Deploy AI beside Deltek Costpoint inside a CMMC Level 2 enclave: what to check before adding any AI tool, and how on-prem inference avoids new CUI flows.
SAP + on-prem AI for A&DAI 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.
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 ToolCMMC 2.0 Level 2 Readiness Assessment
Answer 10 questions mapped to NIST SP 800-171 control families and get an instant CMMC Level 2 readiness score with prioritized next steps.
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.
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.
GuideDefense CIO AI Briefing: 2026 Edition
Defense CIO AI briefing for 2026: CMMC 2.0, ITAR, and DFARS constraints on AI, plus how defense contractors deploy LLMs without risking CUI exposure.
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.