Any ERPRole & RegulationUnited States

Defense contractor AI

AI for ERP Across the US Defense Supply Chain

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.

ERP
SAP S/4HANA, Infor SyteLine, Infor LN, Deltek Costpoint, Oracle EBS, Epicor Kinetic
Industries
Aerospace, Defense, Electronics
Written for
CIO

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.

What usually gets in the way

The problems we hear most from cio teams running SAP S/4HANA.

Fragmented ERP landscape across the supply chain

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

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

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

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

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.

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.

Quote-to-cash acceleration bounded to non-controlled data

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.

Touches: 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

Summarize which open orders, routings, and inventory positions are affected by an ECO, scoped to the requesting user's authorized data.

Touches: 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

Draft lot/serial traceability summaries and certificate of conformance language from receiving and inspection records.

Touches: Receiving inspection records, lot/serial tables, supplier certification data

Outcome: cuts documentation time for routine receiving inspection paperwork

RFQ intake triage

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.

Touches: 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

Flag likely duplicate or inconsistent item, vendor, and customer master records across merged ERP instances for review before consolidation.

Touches: 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

Answer plain-language questions from finance and operations about WIP aging, backlog, and cash conversion, grounded in live ERP data.

Touches: 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

Answer scheduling and capacity questions (what happens to the schedule if this job slips) grounded in current routing and capacity data.

Touches: Routing, work center capacity, and scheduled order tables

Outcome: speeds up what-if scheduling conversations that currently require a planner to run manual reports

Reference architecture

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.

  1. 1

    ERP connectors

    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.

  2. 2

    Data and semantic layer

    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.

  3. 3

    Model serving

    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.

  4. 4

    Retrieval and agents

    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.

  5. 5

    Governance and audit

    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.

Integration notes for your ERP team

  • 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.

Deployment options

Air-gapped on-prem

Facilities where a prime's flow-down requirements or internal policy call for no external network path

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

Multi-facility organizations that want centralized management without losing control over hosting and personnel

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

Organizations with a mix of controlled and non-controlled data, or a phased rollout across facilities

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 and data control

How the architecture supports your obligations. Certification and accountability stay with your organisation; the design keeps the evidence straightforward.

ITAR (22 CFR 120-130)

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.

CMMC 2.0 (Level 1 or Level 2 depending on data handled)

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.

DFARS 252.204-7012 / NIST SP 800-171

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.

AS9100 (where applicable)

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.

How an engagement runs

Phase 1 . 2-3 weeks

Discovery

  • -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

Phase 2 . 6-8 weeks

Pilot

  • -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

Phase 3 . 8-12 weeks

Production

  • -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

Phase 4 . ongoing

Scale

  • -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

Questions to ask any vendor, including us

A short list that separates real SAP S/4HANA AI work from a chatbot demo.

  1. Can your architecture connect to more than one ERP without rebuilding the governance layer from scratch?
  2. How does the system handle a facility that runs a different ERP than the rest of our organization?
  3. What is your approach if part of our data is ITAR-controlled and part is not?
  4. Can you show a reference architecture diagram for how data moves from ERP to model and back?
  5. What does a supplier security questionnaire answer look like for this system?
  6. How do you size GPU capacity for a multi-facility rollout without over-provisioning?
  7. What is the realistic timeline from pilot to a second facility going live?
  8. Who owns the data, models, and logs if we change vendors later?

Frequently asked questions

Can one AI architecture really serve a company running multiple different ERPs?

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?

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?

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?

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?

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?

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?

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.

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.