Any ERPRole & RegulationUnited States

ITAR + on-prem AI

ITAR-Compliant AI for ERP Technical Data

Short answer

Adding AI to an ERP that stores ITAR-controlled technical data means keeping every model call, embedding, and log entry inside a boundary that only US persons can reach - a public LLM API almost never satisfies that. The fix is an on-prem or customer-controlled private cloud stack where the model, the vector index, and the ERP connector all sit inside your existing Technology Control Plan, with access mapped to citizenship and need-to-know, not bolted on afterward. Done this way, AI can search technical manuals, draft engineering change summaries, and answer questions against BOM and routing data without a single byte leaving the boundary the Empowered Official already controls.

ERP
SAP S/4HANA, Infor SyteLine, Infor LN, Oracle EBS, Deltek Costpoint
Industries
Aerospace, Defense, Electronics
Written for
Empowered Official / CISO

If your ERP holds drawings, specifications, source code, or technical data tied to a defense article or defense service on the US Munitions List, every AI feature you add has to survive the same question your export compliance program already asks about every other system: who can access this, and are they a US person acting inside an authorized activity. A convenience feature that quietly routes a BOM description or a drawing excerpt to a public model API can turn into a deemed export the moment a foreign national engineer at the vendor, or a foreign-hosted subprocessor, touches that data - even briefly, even for caching.

Most engineering and operations teams are not trying to violate ITAR. They are trying to find a part number faster, summarize an engineering change, or ask a plain question of a system that answers in cryptic transaction codes. When the sanctioned tools do not do this, people paste text into whatever chat window is open on their screen. That shadow AI usage is the actual risk an Empowered Official has to manage today, and blocking the browser extension does not make the underlying need go away.

The alternative is not to refuse AI. It is to build the AI stack the same way you already build everything else that touches technical data: inside the boundary, with access control tied to the same citizenship and role attributes your PLM and file share already enforce, and with a full audit trail the Empowered Official can review on the same cadence as any other export management system control. That is an architecture decision, not a policy memo, and it is one your ERP vendor almost certainly will not make for you.

This page lays out what that architecture looks like when the AI sits on top of an ERP - SAP, Infor LN or SyteLine, Oracle EBS, Deltek Costpoint, or a mix across a supply chain - and what questions to ask any vendor, including Netray, before technical data gets anywhere near a model.

What usually gets in the way

The problems we hear most from empowered official / ciso teams running SAP S/4HANA.

Public LLM APIs are a deemed export waiting to happen

Sending a BOM line, a drawing note, or a spec paragraph to a hosted model can expose it to personnel or infrastructure outside the United States, including subprocessors most SaaS AI vendors do not disclose in enough detail to satisfy an export compliance review.

Shadow AI is already happening in the ERP

Engineers and planners copy technical data out of the ERP into whatever assistant is available on their laptop because the sanctioned tools are slower than a chat window. Blocking the tool without replacing the workflow just pushes the behavior further out of sight.

Vendor subprocessor lists rarely answer the citizenship question

Most AI vendors will tell you where data is hosted. Far fewer can tell you, in writing, that every person and system with any possible access to your technical data is a US person operating under your authorization.

ERP was never scoped into the Technology Control Plan for AI

File shares and PLM systems usually have documented access controls under the TCP. The ERP's BOM, routing, and document attachment tables often were not explicitly reviewed for AI exposure because AI on the ERP is new.

Productivity pressure versus the Empowered Official's obligation

Engineering and operations leadership want the same AI speed they read about everywhere else. The Empowered Official has to say yes in a way that still lets them certify, in good faith, that no unauthorized export occurred.

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.

Technical data flagging before export outside cleared roles

Scan ERP attachments and BOM text fields for language patterns consistent with export-controlled technical data before a document leaves a cleared workspace, so review effort goes to the items that actually need it.

Touches: Document/attachment tables, engineering change records, BOM component text and drawing references

Outcome: cuts blanket manual document review to a targeted queue of flagged items instead of every attachment

Engineering change summaries bounded to authorized users

Draft a plain-language summary of what an ECO/ECN changed - affected parts, routings, open orders - pulled only from ERP data the requesting user's role and citizenship attributes already permit them to see.

Touches: ECO/ECN header and detail records, BOM revision history, affected routing operations

Outcome: shortens the time engineering leads spend reading raw change records for routine ECOs

Natural-language search over technical manuals, on-prem only

Ground a retrieval index over work instructions, service bulletins, and spec documents entirely inside the boundary, so search behaves like an assistant without any query or document chunk ever leaving the network.

Touches: Document management repository, work instruction attachments, spec revision records

Outcome: reduces time spent hunting through folder structures for the current revision of a document

Classification and jurisdiction lookup assist

Surface prior USML category determinations and classification notes already tied to part numbers in the ERP, so engineers see the existing determination before assuming a part needs re-classification.

Touches: Item master custom fields, classification/jurisdiction notes, part revision history

Outcome: avoids duplicate classification requests for parts already reviewed

Access log summarization for periodic EO review

Condense who queried what technical data, when, and under which role, into a review-ready summary instead of a raw log dump the Empowered Official has to parse line by line.

Touches: AI query/response audit log, ERP user role and citizenship attribute table

Outcome: turns a periodic access review from a multi-hour log exercise into a focused read

Denied party screening against the vendor master

Cross-reference active suppliers and their contacts in the ERP vendor master against denied and restricted party lists on a schedule, flagging matches for the compliance team instead of relying on onboarding-time-only checks.

Touches: Vendor master, vendor contact records, purchase order header data

Outcome: catches list changes affecting existing suppliers between formal re-screening cycles

Bounded drafting for technical proposal sections

Draft the ERP-sourced technical sections of a proposal or SOW response - lead time, capability statements from historical job data - entirely inside the enclave, with the model never touching data outside the authorized scope of the request.

Touches: Job/order history, capacity and routing data, historical quote records

Outcome: reduces proposal turnaround for the ERP-sourced sections without adding an external tool to the process

Reference architecture

The design goal is simple to state and hard to fake: nothing that touches ERP technical data leaves a boundary the Empowered Official already controls. Every layer below runs on infrastructure you own or explicitly authorize, with access tied to the same citizenship and role attributes your export compliance program already tracks.

  1. 1

    ERP connectors (read-only)

    Direct, read-only connections to ERP APIs or replicated tables (SyteLine IDOs, SAP OData/CDS views, Oracle EBS interface views, Costpoint reporting views) with no path back into production tables unless a human explicitly approves a write.

  2. 2

    Data and semantic layer

    A semantic layer that maps cryptic ERP fields to plain business terms and tags technical data sensitivity, so the retrieval and generation layers know which records require US-person-only access before a query is ever answered.

  3. 3

    Model serving

    Open-weight models (Llama, Qwen, Mistral, or gpt-oss class) served with vLLM or Ollama on GPUs inside your network, with outbound internet access disabled at the network layer, not just at the application layer.

  4. 4

    Retrieval and agents

    Retrieval-augmented generation grounded in the technical data index, plus narrow agents (ECO summarization, log condensation) that operate strictly within the requesting user's already-provisioned ERP and citizenship scope.

  5. 5

    Governance and audit

    Full logging of every query, retrieved document, and generated response, mapped to the requesting user's role and citizenship attributes, retained on a schedule the Empowered Official sets for export management system review.

Integration notes for your ERP team

  • ERP connections are read-only by default; any write-back (updating an ECO status, closing a task) requires an explicit human approval step, never an autonomous model action.
  • Model weights, embeddings, and the vector index live on storage you control, inside the same network segment as the ERP database replica, not in a vendor-managed cloud account.
  • No component in the stack holds a live API key to a public model provider; outbound network rules are enforced at the firewall, not left to application configuration alone.
  • User identity flows from your existing ERP or directory authentication (SSO, PIV where used) into the AI layer, so citizenship and role attributes are enforced at query time, not just at ERP login.
  • Retrieval results are filtered before generation: the model never sees a document chunk the requesting user's role would not already be permitted to open in the ERP or document repository.
  • Every query, retrieved source, and generated answer is logged with user, timestamp, and data touched, in a format your compliance team can export for an Empowered Official review or an external audit.
  • Model updates and index rebuilds happen inside the same boundary as production use; there is no round trip through a vendor's cloud environment for fine-tuning or evaluation.

Deployment options

Air-gapped on-prem

Programs with hard ITAR technical data, classified adjacencies, or a contractual requirement for no external network path

Model, vector index, and ERP connector run entirely inside your facility's network with no outbound internet route, satisfying the strictest reading of deemed export exposure because there is no external path for data to travel.

Private or sovereign cloud

Programs that need elastic GPU capacity but still require full control over hosting location and personnel access

The same stack runs in a customer-controlled cloud tenancy (your subscription, your VPC, your key management) where you dictate hosting region and can require US-person-only administrative access in the service agreement.

Hybrid

Organizations with a mix of controlled and non-controlled ERP data across business units

Non-controlled ERP data (general finance, non-technical operations) can run in a broader environment while technical data stays isolated on a segregated network segment with its own model instance and access rules.

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)

Technical data is processed only within infrastructure and by personnel your export compliance program already authorizes; no component of the AI stack calls an external API or transmits technical data outside the boundary.

EAR (15 CFR, dual-use overlap)

Where items or data straddle USML and Commerce Control List classifications, the same access controls and logging apply so the classification question does not change how the AI system handles the data.

NIST SP 800-171

Access control, audit logging, and system/communications protection are designed to line up with the control families most Technology Control Plans already reference, easing the paperwork even where 800-171 is not separately mandated.

Company Technology Control Plan / export compliance program

The AI system is scoped into the existing TCP as a system that touches technical data, with role and citizenship mapping, access logging, and a defined review cadence the Empowered Official signs off on.

How an engagement runs

Phase 1 . 2-3 weeks

Discovery

  • -Review of the existing Technology Control Plan and how ERP technical data currently flows
  • -Interview with the Empowered Official and export compliance team on required controls
  • -Map of ERP tables, attachments, and fields that hold or reference technical data
  • -Draft architecture showing where the AI stack sits relative to the existing TCP boundary

Phase 2 . 6-8 weeks

Pilot

  • -One or two narrow use cases live in the air-gapped or private environment (for example, technical data flagging or ECO summarization)
  • -Access control mapping tested against real user roles and citizenship attributes
  • -Audit log format reviewed and approved for Empowered Official use
  • -Pilot findings documented for the export compliance file

Phase 3 . 8-12 weeks

Production

  • -Pilot use cases hardened and rolled out to the full authorized user population
  • -TCP language updated to formally scope the AI system
  • -Monitoring and alerting for anomalous access patterns
  • -Runbook for the Empowered Official's periodic review process

Phase 4 . ongoing

Scale

  • -Additional use cases added within the same governed architecture
  • -Quarterly review of access logs and TCP alignment
  • -Model and index updates performed inside the boundary
  • -Support for new programs or facilities added to the boundary

Questions to ask any vendor, including us

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

  1. Can you show me, on a network diagram, exactly where the model, the vector index, and the ERP connector run, and confirm there is no outbound internet path?
  2. Does any component of your stack call an external API, even for licensing checks, telemetry, or health monitoring?
  3. Who at your company, and at any subcontractor, has any possible access to our technical data, and can you confirm they are all US persons?
  4. What is logged, in what format, and for how long, and can our Empowered Official export that log for an export management system review?
  5. How does the system enforce that a user's citizenship and role attributes control what the model can retrieve, not just what the ERP screen shows?
  6. If we later need to move from a pilot environment to a fully air-gapped one, what has to change in the architecture?
  7. What happens to embeddings and cached data if we terminate the engagement - can we confirm deletion in writing?
  8. Who owns the model weights and the fine-tuned artifacts at the end of the engagement?

Frequently asked questions

Does using a public AI assistant on ITAR technical data always count as a deemed export?

Not automatically, but the risk is high enough that most export compliance programs treat it as one unless the vendor can document, in detail, that no foreign person or foreign-hosted infrastructure has any possible access to the data, including for caching, logging, or model improvement. Few public AI vendors can document that to an Empowered Official's satisfaction, which is why on-prem or fully customer-controlled deployment is the practical default for this data class.

Can we use a cloud-hosted large language model if it is deployed in a US region?

Region alone does not resolve the question; what matters is whether any personnel, subprocessors, or support staff with access to the underlying infrastructure could be foreign persons, and whether the vendor's own systems could route data outside the US even briefly. A private cloud deployment where you control the tenancy, the keys, and the access list is a stronger position than relying on a vendor's regional hosting claim.

What does an Empowered Official actually need to see from an AI system?

A clear map of what data the system can access, who can query it and on what authorization, a full log of queries and responses tied to user identity, and confirmation that no component transmits data outside the authorized boundary. This is the same evidence set used for any other system handling technical data; AI does not get a different standard.

Do we need to update our Technology Control Plan before deploying AI on the ERP?

In most cases yes. If the AI system can access technical data, it should be explicitly scoped into the TCP with its own access control and logging description, the same way a new file share or PLM module would be. Doing this before go-live, rather than retroactively, avoids a gap an audit could flag.

Is an air-gapped deployment always required for ITAR technical data and AI?

Not always, but it is the simplest way to satisfy the deemed export question because there is no external network path for data to travel. A private, customer-controlled cloud tenancy with strict personnel and hosting-location controls can also work, but it requires more documentation and vendor scrutiny to reach the same confidence level.

How is this different from just turning off Copilot or ChatGPT for engineering staff?

Turning off a tool removes one path but does not remove the underlying need to search technical data or draft summaries faster. Without a sanctioned, governed alternative inside the boundary, that need tends to resurface as shadow AI use on personal devices or unsanctioned tools, which is a harder risk to see and control.

Can the same architecture support both ITAR technical data and ordinary business data?

Yes, with segmentation. Non-controlled ERP data such as general finance or scheduling can run in a broader environment or even a managed cloud, while technical data stays isolated on its own model instance and network segment with tighter access rules, so you are not forced to apply the strictest controls to every dataset.

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.