# AI for ERP in Israel: Defense Export Controls and Air-Gapped Deployment

> Source: https://netray.co/erp-ai/ai-for-erp-israel-defense-electronics
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: AI for ERP

## Short answer

Israeli defense and electronics manufacturers running SAP, Oracle E-Business Suite, Infor LN, or Priority ERP can add AI to their ERP entirely inside an existing segregated or closed network, without any prompt or document ever reaching a public cloud endpoint. The design has to satisfy the Defense Export Control Act licensing regime and the physical network segregation many Israeli defense suppliers already operate under, which is a narrower and more concrete requirement than a general privacy law.

## Kind

region

## Erp Family

multi-erp

## Erp Products

- SAP S/4HANA
- Oracle E-Business Suite
- Infor LN
- Priority ERP

## Industries

- Defense
- Electronics
- Aerospace

## Region

Israel

## Persona

CIO

## Eyebrow

Israel defense + air-gapped AI

## Intro

Israel's defense-electronics industrial base includes a large number of mid-size suppliers feeding larger primes, and most of them run one of a small set of ERPs, SAP, Oracle E-Business Suite, Infor LN, or the locally common Priority ERP, sometimes more than one at once after an acquisition. The AI conversation for these companies starts from a constraint most vendors are not built to handle: technical data controlled under the Defense Export Control Act cannot go near a public LLM API, even indirectly through a SaaS copilot whose backend happens to be cloud-hosted.

The Defense Export Control Act, 5767-2007 (DECA), and the licensing regime administered by the Defense Export Control Agency under the Ministry of Defense, govern the export of defense know-how and controlled items, and a lot of ordinary engineering and quoting work touches that controlled category without anyone treating it as unusual day to day. Many suppliers already operate physically segregated, closed networks for exactly this reason, and any AI deployment on top of the ERP has to live inside that same segregation, not next to it.

That constraint rules out almost every SaaS AI product by default, since a closed network structurally cannot reach an external API, and it also rules out treating AI as a bolt-on project separate from the existing network security architecture. What it does not rule out is AI itself: a private LLM deployed inside the same segregated segment as the ERP is a normal extension of infrastructure these teams already operate, not a new category of risk.

In practice, the first useful deployment is close to what any manufacturer would want, natural-language query over ERP data, faster access to prior quote and design precedent, first-draft NCR text, run entirely inside the network boundary that already exists. Companies running more than one ERP after an acquisition often find the cross-system query capability, one question answered from both SAP and Priority data, is the single most valuable piece.

## Pain Points

### DECA-controlled data cannot approach a public LLM API

**Detail:** Even an indirect path, a SaaS copilot whose model calls happen to run through an external cloud, is incompatible with the handling requirements for defense export controlled technical data, ruling out most commercial AI products outright.

### Closed-network environments make ordinary SaaS AI structurally impossible

**Detail:** Sites operating a segregated or air-gapped network for controlled programmes have no path to an external API by design, so any AI capability has to be deployed inside the same boundary, not layered on top of it.

### Engineering precedent is trapped, not searchable

**Detail:** Prior quotes, design rationale, and BOM history sit in ERP attachments and email threads that are hard to search precisely because they are controlled, and the difficulty is a data-handling problem, not just a search-tooling gap.

### Group companies run different ERPs with no shared query layer

**Detail:** A parent company on SAP and an acquired subsidiary on Priority or Infor LN have no common way for a group-level manager to ask a single question across both systems.

### Small IT teams cannot absorb a multi-month platform project

**Detail:** Most of these companies run lean IT organizations already stretched by ERP support, and an AI initiative that demands a long, resource-heavy platform buildout before delivering anything usable will not survive budget review.

## Use Cases

### Natural-language query inside the closed network

**Description:** Planners, buyers, and engineers ask questions and get answers grounded in ERP data without any query ever leaving the segregated network segment.

**Erp Objects:** Sales orders, open purchase orders, inventory balances, production schedule

**Outcome:** answers routine status questions in seconds without breaking the network segregation the facility already relies on

### Engineering and quote precedent search

**Description:** Finds prior quotes, BOM structures, and drawing metadata relevant to a new RFQ, respecting the same access controls as the source documents.

**Erp Objects:** Historical quotes, BOM records, drawing metadata linked from the ERP or PLM system

**Outcome:** cuts the time engineers spend hunting for comparable prior work from a manual search across systems to a direct query

### Export licence and end-use tracking assistant

**Description:** Flags a sales order or shipment against outstanding export licence or end-user certificate requirements before release.

**Erp Objects:** Customer master, sales order headers, export licence and shipment records

**Outcome:** catches a missing licence reference before a shipment releases rather than during a post-shipment review

### MRP exception triage

**Description:** Groups and prioritises reschedule, expedite, and cancel messages for planner review.

**Erp Objects:** MRP action messages, purchase order lines, supplier confirmations

**Outcome:** cuts routine exception triage time for the majority of low-risk lines

### NCR and CAPA drafting

**Description:** Drafts a first-pass root cause and containment narrative from a quality notification, formatted for AS9100 or ISO 9001.

**Erp Objects:** Quality notifications, NCR records, 8D worksheets

**Outcome:** gives the quality engineer a reviewable draft in minutes rather than a blank template

### Cross-ERP knowledge assistant for group companies

**Description:** Lets a group-level manager ask a single question spanning a parent's SAP instance and a subsidiary's Priority or Infor LN instance.

**Erp Objects:** Multi-instance sales, inventory, and production data across connected ERP systems

**Outcome:** replaces a round of emails to each subsidiary's controller with one query answered from all connected systems

### RFQ-to-quote drafting from historical costs

**Description:** Pulls comparable historical job costs and routing data to give estimators a grounded starting draft.

**Erp Objects:** Job costing history, routing data, quote header and line records

**Outcome:** shortens the time from RFQ receipt to a defensible first quote draft

## Architecture

**Overview:** The architecture assumes network segregation is a starting constraint, not an obstacle to design around, so every layer runs entirely inside the same boundary as the ERP itself.

**Layers:**

#### ERP connectors

**Detail:** Read-only connectors into SAP (OData/BAPI), Oracle E-Business Suite (interface tables, concurrent programs), Infor LN (BODs, ION), and Priority (its native API or ODBC layer), deployed inside the same network segment as the source system.

#### Data and semantic layer

**Detail:** A permissioned index that mirrors existing ERP and PLM access controls, tagged for DECA-controlled content so retrieval never surfaces controlled data to a user without the corresponding clearance.

#### Model serving

**Detail:** Open-weight models served entirely inside the segregated network, with no update or telemetry path that requires outbound internet connectivity.

#### Retrieval and agents

**Detail:** Retrieval-augmented generation grounded in connected ERP and PLM data, with any write-back action gated behind explicit human approval, all within the same network boundary.

#### Governance and audit

**Detail:** Query and action logging kept alongside the existing ERP audit trail, reviewed by the same security and compliance staff who already review network access logs.

## Deployment Options

### Fully air-gapped, closed network

**Fit:** companies operating a segregated or classified network for controlled programmes

**Detail:** Model serving and retrieval run entirely inside the existing closed network with zero outbound connectivity, matching the physical and personnel security controls already in place.

### Isolated private network with controlled egress

**Fit:** commercial, non-classified sites that still want strict data boundaries

**Detail:** A private network segment with tightly controlled, logged outbound access for specific purposes like model updates, suited to sites without full network segregation requirements.

### Hybrid for groups with both classified and commercial divisions

**Fit:** companies operating both defense and commercial electronics lines

**Detail:** Classified programme deployments stay fully air-gapped while commercial divisions run on an isolated private network, with clear data boundaries between the two.

## Compliance

### The AI deployment is designed so controlled technical data never transits a path outside the licensed handling boundary already established for that data under DECA.

**Framework:** Defense Export Control Act, 5767-2007 (DECA)

### Export licence and end-user tracking data already maintained for DECA compliance feeds the AI layer's guardrails, rather than creating a parallel tracking system.

**Framework:** Defense Export Control Agency licensing

### Personal data used in AI features is scoped to a documented business purpose, with the same access and security controls already applied to the underlying ERP.

**Framework:** Protection of Privacy Law, 5741-1981 and Data Security Regulations

### The AI deployment runs entirely inside the same segregated network as the ERP, with no new external connectivity introduced as part of the rollout.

**Framework:** Physical network segregation for controlled programmes

### For sites that operate to ISO 27001, the AI deployment's logging, access control, and change management practices are aligned to the same certification scope.

**Framework:** ISO 27001 as a hosting baseline

## Integration Notes

- SAP connections use OData and BAPI/RFC calls scoped to read-only roles.
- Oracle E-Business Suite integration reads from interface tables and standard concurrent program outputs.
- Infor LN integration goes through BODs and ION.
- Priority ERP integration uses its native API or ODBC layer rather than direct database access.
- The entire deployment runs inside existing network segmentation, with no new external connectivity introduced.
- Authentication rides on the existing network's identity and access management setup, scoped by clearance level.
- Hebrew and English are both supported at the UI and retrieval level.

## Product Fit

### ERPray

**Why:** Question answering across SAP, Oracle E-Business Suite, Infor LN, or Priority data, deployed entirely inside an existing segregated network.

### Custom build

**Why:** The engineering and quote precedent search, and the export licence tracking assistant, are specific enough to a company's document control and export licensing setup to warrant a scoped custom build.

## Engagement

### Discovery

**Duration:** 2-3 weeks

**Deliverables:**

- Security walk-through of the existing network segregation and ERP access model
- Data classification review across ERP, PLM, and export licence records
- Deployment option recommendation aligned to the facility's existing network architecture

### Pilot

**Duration:** 6-8 weeks

**Deliverables:**

- Working natural-language query pilot for one department, deployed inside the existing network boundary
- Read-only connector to the primary ERP with clearance-scoped access controls
- Validation that no new external connectivity was introduced during the pilot

### Production

**Duration:** 8-12 weeks after pilot sign-off

**Deliverables:**

- Hardened deployment inside the agreed network segment
- Audit logging integrated alongside existing ERP and network security logs
- Runbook and internal admin training for ongoing operation

### Scale

**Duration:** ongoing

**Deliverables:**

- Cross-ERP query capability extended to additional group companies
- Additional use cases (export licence tracking, precedent search) added incrementally
- Periodic security review aligned to the facility's existing network audit cadence

## Buyer Questions

- Can this run with zero outbound connectivity, and how is that actually verified, not just claimed?
- How does the system handle DECA-controlled content differently from ordinary business data in the same ERP?
- What does the deployment look like for a company with both a classified programme and a commercial electronics line?
- How is access scoped by security clearance within the AI layer, not just within the ERP itself?
- Can this connect to more than one ERP at once if we have a subsidiary on a different system?
- What is the process for updating the model or the system without introducing new external connectivity?
- Who on your team has actually worked inside a closed or segregated network deployment before?

## Faq

### Can AI actually run inside a closed network with no internet access at all?

**Answer:** Yes, provided the model, the data index, and the retrieval layer are all deployed on infrastructure physically inside the network boundary from the start. Open-weight models can be served entirely offline once loaded, and updates can be applied through the same controlled media or maintenance window process already used for other software inside the network.

### Does DECA apply to routine ERP data, or only to technical drawings?

**Answer:** It depends on the specific data and licence terms, but a surprising amount of routine ERP data, BOM structures, quote history, supplier information, can carry DECA-relevant sensitivity depending on the programme. The safer design treats the whole ERP integration as potentially controlled and scopes access accordingly, rather than trying to classify every field individually in advance.

### We run SAP at the parent company and Priority at a subsidiary. Can one system query both?

**Answer:** Yes, with a connector into each system and a semantic layer that normalizes the data enough to answer a single question from either source. The response indicates which system the answer came from, which matters for the subsidiary's own compliance and audit needs as much as it does for the parent company's visibility.

### How is this different from just buying a commercial AI copilot?

**Answer:** Most commercial AI copilots, even ones marketed as enterprise-secure, depend on an external API call at some point in the pipeline, which a closed network cannot make. A deployment built specifically to run entirely inside network segregation, with model serving and retrieval both local, is a different architecture, not just a different vendor of the same thing.

### What happens to the audit trail this system produces?

**Answer:** Query and action logs are kept alongside the existing ERP audit trail, reviewed by the same security and compliance staff who already review network access and ERP logs, so a DECA compliance review or an internal security audit does not need a separate data pull for the AI layer.

### How long does a closed-network deployment take compared to a normal cloud AI rollout?

**Answer:** Longer at the start, because the security walk-through and network integration work in discovery takes real time, typically two to three weeks just to map the existing architecture. Once that is done, the pilot and production phases run on a similar timeline to any other on-prem deployment, roughly fourteen to twenty weeks total from kickoff to production.

### Can the AI layer help with export licence tracking without creating export risk itself?

**Answer:** Yes, because the assistant reads existing licence and end-user certificate data already tracked in the ERP and flags gaps before a shipment releases, it does not create new export exposure of its own. The system itself never transmits controlled data anywhere outside the same network boundary the ERP already operates in.

## Search terms

AI for ERP Israel, air-gapped AI Israel defense, DECA export control AI, AI for SAP Israel defense, AI for Priority ERP, closed network AI ERP, on-prem AI Israel electronics, private LLM Israel defense, AI for Infor LN Israel, AI copilot Israel manufacturing, defense export control AI ERP, segregated network AI deployment

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json
