# AI for ERP Across the US Defense Supply Chain > Source: https://netray.co/erp-ai/ai-for-erp-us-defense-contractors > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: AI for ERP ## Short answer The US defense supply chain runs on a patchwork of ERPs - SAP at primes, Infor LN or SyteLine at mid-tier manufacturers, Deltek Costpoint for government accounting, Oracle EBS or Epicor at smaller suppliers - and a CIO adding AI has to make it work across that patchwork without introducing a new ITAR, CMMC, or DFARS gap. The workable approach starts with one or two bounded use cases inside a private or air-gapped deployment, proves the control story with the compliance team, then extends across ERPs and facilities using the same governed architecture rather than a different tool for each system. ## Kind persona ## Erp Family multi-erp ## Erp Products - SAP S/4HANA - Infor SyteLine - Infor LN - Deltek Costpoint - Oracle EBS - Epicor Kinetic ## Industries - Aerospace - Defense - Electronics ## Region United States ## Persona CIO ## Eyebrow Defense contractor AI ## Intro If you are the CIO at a defense prime, or at a tier 2 or tier 3 supplier feeding one, your ERP landscape is rarely a single clean system. Primes often run SAP alongside legacy or acquired-company systems; mid-tier manufacturers run Infor LN or SyteLine, Epicor Kinetic, or Oracle EBS; smaller job shops run Deltek Costpoint for government accounting next to a shop-floor system that was never designed with export control in mind. AI has to work across that reality, not against a single idealized ERP. The pressure to move is real: primes are asking suppliers to quote faster, engineering teams want the same AI speed everyone reads about, and finance wants better visibility into WIP and backlog without another manual report. The pressure to move carefully is equally real: a defense supply chain CIO cannot afford an AI rollout that creates an ITAR deemed export question, expands CMMC scope unexpectedly, or gives a prime's security team a reason to flag your facility during a supplier review. Smaller suppliers face a specific version of this problem - thin IT staff, no dedicated compliance function, and flow-down security requirements from the prime that read like they were written for a much larger organization. The AI approach that works here is not the one with the most features, it is the one that a two-person IT team can actually operate and defend during a supplier security questionnaire. This page lays out a practical path: bounded use cases, a governed architecture that works across whichever ERP or ERPs you run, and the sequence of questions worth working through with compliance before rollout, whether you build this with Netray or evaluate it independently. ## Pain Points ### Fragmented ERP landscape across the supply chain **Detail:** A single AI approach has to work whether the underlying system is SAP, Infor LN, Infor SyteLine, Deltek Costpoint, Oracle EBS, or Epicor Kinetic, and few AI vendors have touched more than one or two of these. ### Compliance burden falls hardest on the smallest suppliers **Detail:** Tier 2 and 3 suppliers face the same ITAR, CMMC, and DFARS expectations as much larger primes, with a fraction of the IT and compliance staff to implement AI safely. ### Quoting speed pressure versus data control **Detail:** Sales and engineering want AI to speed up RFQ response and engineering change turnaround, but every acceleration idea has to be checked against what data it touches and where. ### Workforce lacks deep AI or security background **Detail:** Manufacturing IT teams are often generalists managing ERP, network, and shop floor systems together, with limited bandwidth to evaluate AI security claims in detail. ### Public AI tools are increasingly restricted by prime security requirements **Detail:** Supplier security questionnaires and flow-down clauses are starting to ask directly whether public AI tools touch program data, pushing suppliers toward governed alternatives whether or not they have evaluated one yet. ## Use Cases ### Quote-to-cash acceleration bounded to non-controlled data **Description:** Draft RFQ response sections (lead time, historical pricing context, capacity availability) from ERP order history, with technical data excluded from the AI-accessible scope unless separately cleared. **Erp Objects:** Quote/order history, capacity and routing data, customer master **Outcome:** shortens RFQ turnaround for the ERP-sourced sections of a quote ### Engineering change impact analysis **Description:** Summarize which open orders, routings, and inventory positions are affected by an ECO, scoped to the requesting user's authorized data. **Erp Objects:** ECO/ECN records, BOM revision history, open order and inventory tables **Outcome:** reduces the manual cross-referencing engineers do for each change ### Receiving inspection and traceability documentation assist **Description:** Draft lot/serial traceability summaries and certificate of conformance language from receiving and inspection records. **Erp Objects:** Receiving inspection records, lot/serial tables, supplier certification data **Outcome:** cuts documentation time for routine receiving inspection paperwork ### RFQ intake triage **Description:** Triage incoming RFQs against historical capability and capacity data to flag which ones are a realistic fit before sales spends time on a full quote. **Erp Objects:** Historical job/order data, capacity plan, customer master **Outcome:** reduces time spent fully quoting RFQs unlikely to be won or fulfilled ### Master data cleanup after M&A or ERP consolidation **Description:** Flag likely duplicate or inconsistent item, vendor, and customer master records across merged ERP instances for review before consolidation. **Erp Objects:** Item master, vendor master, customer master across source systems **Outcome:** reduces the manual review workload during a data migration or consolidation project ### Working capital and WIP visibility Q&A **Description:** Answer plain-language questions from finance and operations about WIP aging, backlog, and cash conversion, grounded in live ERP data. **Erp Objects:** WIP, job cost, and order backlog tables **Outcome:** reduces the ad hoc reporting burden on finance for routine working capital questions ### Capacity and scheduling assistant **Description:** Answer scheduling and capacity questions (what happens to the schedule if this job slips) grounded in current routing and capacity data. **Erp Objects:** Routing, work center capacity, and scheduled order tables **Outcome:** speeds up what-if scheduling conversations that currently require a planner to run manual reports ## Architecture **Overview:** The architecture is built to be ERP-agnostic at the connector layer so the same governed core - model serving, retrieval, and audit - works whether the source system is SAP, Infor LN or SyteLine, Deltek Costpoint, Oracle EBS, or Epicor Kinetic. **Layers:** #### ERP connectors **Detail:** System-specific connectors (SyteLine IDOs, LN BODs, Costpoint reporting views, EBS interface views, Epicor REST v2) normalize data into a common semantic layer, so the same governed core sits behind any of them. #### Data and semantic layer **Detail:** A common data model maps ERP-specific fields to plain business terms and applies sensitivity tags (technical data, CUI, ordinary operational data) consistently across systems. #### Model serving **Detail:** Open-weight models served on customer-controlled GPUs, sized to actual usage, whether that means a single mid-tier facility or a rollout across several plants running different ERPs. #### Retrieval and agents **Detail:** Retrieval-augmented generation and narrow agents (quote drafting, ECO impact analysis) operate within the requesting user's role and data scope, regardless of which underlying ERP the data came from. #### Governance and audit **Detail:** A single audit trail spans use cases and ERPs, giving compliance and IT one place to review access and usage instead of a different log format per system. ## Deployment Options ### Air-gapped on-prem **Fit:** Facilities where a prime's flow-down requirements or internal policy call for no external network path **Detail:** Runs entirely inside the facility network, which is often the simplest option to explain during a supplier security review because there is no external data path to describe. ### Private or sovereign cloud **Fit:** Multi-facility organizations that want centralized management without losing control over hosting and personnel **Detail:** A customer-controlled tenancy lets a CIO manage AI centrally across facilities and ERPs while still specifying hosting region and access controls in the service agreement. ### Hybrid **Fit:** Organizations with a mix of controlled and non-controlled data, or a phased rollout across facilities **Detail:** Non-controlled operational data at one facility can move to a broader environment sooner, while a facility with ITAR or CUI exposure stays on the more restrictive pattern until it is proven out. ## Compliance ### Where technical data is in scope, the AI architecture keeps it inside a boundary accessible only to US persons, consistent with the Technology Control Plan. **Framework:** ITAR (22 CFR 120-130) ### The AI system is scoped into the existing assessment boundary rather than treated as an exempt add-on, with control implementation matched to the facility's actual CMMC level. **Framework:** CMMC 2.0 (Level 1 or Level 2 depending on data handled) ### For facilities handling covered defense information, the AI system inherits access, audit, and communications protection controls from the same control matrix used elsewhere in the environment. **Framework:** DFARS 252.204-7012 / NIST SP 800-171 ### AI-assisted quality documentation (NCR drafting, traceability summaries) is designed to produce a clear evidence trail back to source ERP records, supporting rather than obscuring the audit trail an AS9100 auditor expects. **Framework:** AS9100 (where applicable) ## Integration Notes Connect to the ERP through read-only service accounts scoped to the same CUI-bearing tables and roles your existing access control policy already defines, so the AI inherits least privilege rather than inventing a new model. SAP S/4HANA: OData services and CDS views for orders, BOMs and project systems; RFC/BAPI for anything not exposed as OData. Infor SyteLine and LN: IDO requests, ION API or read replicas of the application database. Deltek Costpoint: reporting views and the Costpoint web services layer for timesheet and labor data. Keep technical data (drawings, specifications, work instructions in PLM or document management) in a separate retrieval index with its own export-control markings, so ITAR-marked content is only retrievable by users cleared for it. Run embedding, retrieval and inference on GPUs inside the enclave boundary; no model call, telemetry or update channel reaches a public endpoint. Model weights are imported through the same media-transfer procedure you use for other software. Log every prompt, retrieved record ID, generated answer and user identity to your SIEM, so AI activity appears in the same audit evidence as any other system handling CUI. Any write-back (a purchase requisition, an NCR, a schedule change) is proposed by the agent and committed only after a named user approves it through the ERP's own transaction, preserving the ERP as the system of record. ## Product Fit ### ERPray **Why:** Grounded question-answering and dashboards over live ERP data fit organizations running SAP, Infor LN, Oracle EBS, or Deltek Costpoint that want a common AI experience across systems. ### SyteRay **Why:** For facilities specifically running Infor SyteLine or CloudSuite Industrial, SyteRay's SyteLine-specific accelerators (form/IDO customization, reporting) complement the broader multi-ERP architecture. ### Custom build **Why:** Quote drafting, ECO impact analysis, and master data cleanup across merged or multiple ERP instances are specific enough to warrant a purpose-built agent layer. ## Engagement ### Discovery **Duration:** 2-3 weeks **Deliverables:** - Inventory of ERP systems in scope across facilities - Review of applicable compliance regimes per facility (ITAR, CMMC level, DFARS 7012, AS9100) - Prioritized list of use cases with data sensitivity noted - Draft architecture and deployment option recommendation ### Pilot **Duration:** 6-8 weeks **Deliverables:** - One or two use cases live at a single facility on its primary ERP - Access control and audit logging validated with IT and compliance - Pilot results and lessons documented for rollout to additional facilities ### Production **Duration:** 8-12 weeks **Deliverables:** - Pilot use cases hardened and rolled out at the initial facility - Connector work completed for a second ERP if applicable - Governance documentation ready for supplier security reviews ### Scale **Duration:** ongoing **Deliverables:** - Rollout to additional facilities and ERPs using the same governed core - New use cases added incrementally - Central audit and usage reporting across the full footprint ## Buyer Questions - Can your architecture connect to more than one ERP without rebuilding the governance layer from scratch? - How does the system handle a facility that runs a different ERP than the rest of our organization? - What is your approach if part of our data is ITAR-controlled and part is not? - Can you show a reference architecture diagram for how data moves from ERP to model and back? - What does a supplier security questionnaire answer look like for this system? - How do you size GPU capacity for a multi-facility rollout without over-provisioning? - What is the realistic timeline from pilot to a second facility going live? - Who owns the data, models, and logs if we change vendors later? ## Faq ### Can one AI architecture really serve a company running multiple different ERPs? **Answer:** Yes, if the architecture separates ERP-specific connectors from the governed core (model serving, retrieval, audit). The connector layer normalizes data from each ERP into a common semantic model, so the same governance and access control logic applies regardless of the source system. ### Where should a smaller tier 2 or tier 3 supplier start with AI on their ERP? **Answer:** Start with one bounded, clearly valuable use case, such as RFQ triage or engineering change summarization, on data that does not carry ITAR or CUI restrictions, deployed on infrastructure you already control. Prove the pattern works operationally and from a compliance standpoint before extending to more sensitive data. ### Do primes actually check whether their suppliers use AI safely? **Answer:** Supplier security questionnaires increasingly ask about AI tool usage and data handling, and this is becoming a standard part of supply chain risk reviews. Being able to answer clearly, with an architecture diagram and a governance story, is increasingly a competitive factor in supplier qualification. ### How does AI help with engineering change management specifically? **Answer:** An AI layer grounded in ERP data can summarize what an engineering change actually affects - open orders, inventory positions, routings - faster than manually cross-referencing multiple screens, while still respecting the same access controls that already govern who can see that data. ### Is it realistic for a small supplier to run AI on-prem without a large IT team? **Answer:** It is realistic if the deployment is scoped to a small number of use cases and sized appropriately, often on a single server with one or a few GPUs rather than a large cluster. The operational burden is closer to maintaining another application server than running a full data center. ### What happens if we acquire or are acquired by a company running a different ERP? **Answer:** A connector-based architecture makes this more manageable: adding a connector for the new ERP extends the same governed core rather than requiring a parallel AI system, and AI-assisted master data cleanup can help during the consolidation itself. ### How do we know if we need CMMC Level 1 or Level 2 controls for our AI system? **Answer:** It depends on whether the data the AI touches includes Controlled Unclassified Information (Level 2) or only Federal Contract Information (Level 1). This is worth confirming with your compliance team or C3PAO liaison before finalizing the AI architecture, since it changes both scope and cost. ## Search terms AI for defense contractors, ERP AI defense supply chain, on-prem AI defense manufacturing, AI for tier 2 tier 3 suppliers, defense contractor ERP AI, ITAR CMMC AI ERP, defense manufacturing generative AI, AI for defense primes, aerospace defense ERP AI, defense supplier AI copilot, AI for defense manufacturers, secure AI defense industrial base --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json