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
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
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
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
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
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.
Where Netray fits
ERPray
Grounded question-answering over ERP data with read-only access and visible underlying queries fits the deemed-export design well: every answer traces back to a source record and a permission check, which is exactly what an Empowered Official needs to see.
Custom build
ECO summarization, classification lookup assist, and log condensation are narrow, high-value agents best built to your specific TCP scope, ERP field layout, and review workflow rather than adapted from a generic product.
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.
- 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?
- Does any component of your stack call an external API, even for licensing checks, telemetry, or health monitoring?
- 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?
- What is logged, in what format, and for how long, and can our Empowered Official export that log for an export management system review?
- 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?
- If we later need to move from a pilot environment to a fully air-gapped one, what has to change in the architecture?
- What happens to embeddings and cached data if we terminate the engagement - can we confirm deletion in writing?
- 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.
Related guides
CMMC 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.
DFARS 7012 + NIST 800-171Mapping DFARS 7012 and NIST 800-171 Controls to AI on Your ERP
Map DFARS 252.204-7012 and NIST SP 800-171 control families to an AI system layered on your ERP, with evidence a Compliance Manager can defend.
Defense contractor AIAI for ERP Across the US Defense Supply Chain
A CIO's guide to adding AI on top of the ERP defense primes and tier 2-3 suppliers already run, without adding a compliance risk the program cannot absorb.
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.
Infor LN + on-prem AI for A&DAI for Infor LN in Aerospace and Defense Manufacturing
AI grounded on Infor LN project, contract, and configuration management data for aerospace and defense manufacturers, with on-prem deployment for ITAR.
On-prem AI, any ERP, A&DOn-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.
Plan it with numbers
ITAR AI Workload Compliance Assessment
Score your AI deployments across eight dimensions of ITAR exposure, from technical data classification and US persons access control to technology control plan coverage.
Free ToolITAR Compliance Checklist for Manufacturers
A 32-point checklist covering DDTC registration, technical data controls, foreign person access, IT security, and recordkeeping for ITAR-regulated manufacturers.
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.
GuideITAR and CMMC Handling of AI Workloads
How ITAR and CMMC apply to AI workloads: technical data boundaries, CUI handling, assessed environments, and where on-prem AI is the only option.
GuideITAR-Compliant AI Tools for Manufacturing: Requirements and Options
ITAR-compliant AI tools for manufacturing: what export control rules mean for LLMs, which vendors qualify, and how to deploy AI without a deemed-export risk.
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.
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.