# How to Add AI to SYSPRO On-Prem Without Moving Your Data

> Source: https://netray.co/erp-help/private-ai-layer-syspro-on-prem-architecture
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: ERP Help

## Short answer

SYSPRO runs on SQL Server with one database per company, and it exposes supported read and write paths through e.net Solutions business objects. A private AI layer reads from a read-only SQL Server copy, answers from a local open-weight model on your own GPUs, and writes back only through business objects after a human approves. Nothing has to leave your network.

## Kind

advanced

## System

syspro

## Erp

SYSPRO (on-prem)

## Module

AI integration / Private architecture

## Query

how to add AI to SYSPRO on-prem

## Alternate Queries

- SYSPRO AI integration without cloud
- SYSPRO private LLM on-prem
- SYSPRO e.net business objects AI assistant
- chat with SYSPRO data on premises

## Applies To

SYSPRO 7 Update 1 and SYSPRO 8 on-premises, SQL Server back end. Business object names and XML schemas vary by release, so check the e.net documentation for your version.

## Steps

### Add a private AI layer to SYSPRO in seven steps

**Items:**

Inventory what SYSPRO holds today: which companies, which modules (inventory, sales orders, work in progress, purchasing, MRP), and which operators need which answers.

Stand up a read-only copy of the company databases on SQL Server, using an Always On readable secondary, log shipping with a standby restore, or transactional replication.

Create a dedicated schema of views over the tables the assistant may read (for example inventory, sales order and job views) and a login that can select only from that schema.

Expose approved read actions as tools: parameterised SQL views for bulk questions, and e.net query business objects such as INVQRY and SORQRY for single-record lookups that honour SYSPRO logic.

Build a retrieval index over documents and attachments (drawings, certificates, supplier PDFs, work instructions) with the permissions of the source folder carried into the index.

Serve an open-weight model with vLLM or Ollama on local GPUs, behind an internal gateway that logs every prompt, tool call, SQL statement and answer.

Roll out in phases: read-only questions first, then drafts of documents and transactions, then approved actions through business objects with a named human approver.

## Sections

### Data access paths in SYSPRO

**Body:**

SYSPRO stores each company in its own SQL Server database, with a separate system-wide database for operators, companies and setup. Core tables follow a readable naming pattern: InvMaster for stock codes, InvWarehouse for quantities by warehouse, SorMaster and SorDetail for sales orders, WipMaster for jobs, PorMasterHdr and PorMasterDetail for purchase orders, ArCustomer and ApSupplier for the sub-ledgers. Confirm column names against the data dictionary for your release before you freeze a view.

For reads that need SYSPRO business logic rather than raw rows, use the e.net Solutions business objects. Query objects such as INVQRY and SORQRY take an XML request and return XML, and they run under a SYSPRO operator so operator security applies. Posting objects such as SORTOI and PORTOI create transactions with full validation. The e.net layer is reachable through COM, .NET and the web services front end.

Bulk analytical questions ("which warehouses are below safety stock for stock codes in this category") belong on SQL views. Single-record questions ("what is the status of sales order 000123") are better served by a query business object, because the result matches what the operator would see on screen.

**Code:**

-- Read-only view over the replica (verify column names for your release)
CREATE VIEW ai_read.v_stock_by_warehouse AS
SELECT m.StockCode, m.Description, w.Warehouse, w.QtyOnHand
FROM dbo.InvMaster m
JOIN dbo.InvWarehouse w ON w.StockCode = m.StockCode;

SELECT TOP 50 StockCode, Warehouse, QtyOnHand
FROM ai_read.v_stock_by_warehouse
WHERE StockCode LIKE 'A1%' AND QtyOnHand <= 0;

<!-- INVQRY request shape: confirm against the XSD shipped with your version -->
<Query>
  <Key>
    <StockCode>A100</StockCode>
  </Key>
</Query>

### Reference architecture, including the air-gapped option

**Body:**

The pattern has six parts: a read-only SQL Server replica, change data capture feeding the retrieval index, a document index, a tool server that exposes only approved read actions, a model server, and an audit log. SQL Server change tracking or CDC on the replica source tells the indexer which rows changed, so the index stays current without scanning the company database.

The tool server can speak the Model Context Protocol so any compliant client can call the same approved actions. Each tool has a fixed SQL view or a fixed business object call, a parameter schema, and a row limit. The model never receives a connection string and never composes arbitrary SQL against the live database.

For an air-gapped site, the entire stack runs inside the enclave: model weights are carried in on approved media, container images come from an internal registry, and the gateway has no outbound route. Updates to the model or index happen by controlled import, not by the internet.

**Code:**

# Tool definition exposed to the model (illustrative)
{
  "name": "syspro_stock_by_warehouse",
  "description": "On-hand quantity by warehouse for a stock code pattern",
  "source": "ai_read.v_stock_by_warehouse",
  "params": {"stock_code_like": "string", "warehouse": "string?"},
  "max_rows": 200,
  "mode": "read-only"
}

### Permissions and write-back

**Body:**

SYSPRO secures access by operator, with operator groups, company access, warehouse and branch restrictions, and per-program permissions. The assistant should act as the asking user, not as a service account with broad rights. Practically: authenticate the user with the same directory the operators use, map the directory account to the SYSPRO operator code, and apply that operator's company and warehouse list as mandatory filters on every tool call. Where a view cannot express the restriction, route that question through the business object so SYSPRO itself enforces it.

Write-back goes only through supported business objects. The assistant prepares a draft (for example the XML for a sales order line change or a stock adjustment), shows the exact payload and the expected effect, and waits for a named approver. On approval the gateway submits the XML under that approver's operator code, so SYSPRO audit trails show a person, not an AI. Direct UPDATE statements against SYSPRO tables are out of bounds, because they skip validation, allocation and journal logic.

### Sizing and phased rollout

**Body:**

For a typical SYSPRO site with 50 to 500 named users, expect 1 or 2 data center GPUs to be enough for an assistant serving a 14B to 32B class open-weight model, with a second GPU mainly for resilience. A 70B class model usually needs two 80 GB GPUs or aggressive quantization. The retrieval index is modest: tens of thousands of documents typically fit in a few tens of gigabytes including vectors. Treat these as planning ranges and measure with your own prompts.

Phase 1 (4 to 8 weeks): read-only questions on stock, orders, jobs and purchasing, with every answer showing the query used. Phase 2: drafts such as supplier emails, shortage summaries, job traveller notes and transaction payloads, all unsent. Phase 3: approved actions through business objects for a short list of low-risk transactions, each with an approver and rollback procedure.

### Honest limits

**Body:**

If your questions are mostly "show me this report", SYSPRO Reporting Services, Analytics or a BI tool you already own may be enough, and cheaper. A language model adds value for questions that cross modules, need explanation, or involve documents. Custom forms, user-defined fields and heavy customisation need mapping work; the assistant only knows what the views and descriptions tell it.

Version constraints apply: business object availability, XML schemas and web service options differ between SYSPRO 7 and 8 releases. Companies with several sites on separate servers need one replica and one tool server per site or a federated design. Model answers on numeric aggregates should come from SQL, never from the model's own arithmetic.

## Pitfalls

- Pointing the model at the live production database with a broad login, which risks load spikes and exposes every company.
- Skipping operator-to-user mapping so every employee sees the same data through the assistant.
- Letting the model write SQL freely instead of calling fixed views and business objects.
- Indexing attachment folders without carrying their folder permissions into the index.
- Posting transactions with a shared service operator so the audit trail shows no human.
- Trusting model arithmetic for totals instead of returning SQL aggregates.

## Ai Angle

ERPray connects to SYSPRO as a grounded, read-only assistant: it shows the query behind each answer, respects operator rights, and can run on your own GPUs. For custom builds, Netray designs the tool server, retrieval index and approval workflow with your SYSPRO partner so the work fits how your operators already use the system.

## Faq

### Can I run AI on SYSPRO without sending data to the cloud?

**Answer:** Yes. SYSPRO data sits in SQL Server on your servers. Replicate it read-only, serve an open-weight model with vLLM or Ollama on local GPUs, and keep the gateway inside your network. In an air-gapped design there is no outbound route at all.

### Should the AI read SQL tables or use e.net business objects?

**Answer:** Use both for different jobs. SQL views suit bulk and analytical questions on a replica. Query business objects suit single-record lookups where SYSPRO logic and operator security should decide what is shown. Posting always goes through business objects.

### How do operator permissions carry over?

**Answer:** Map each directory user to a SYSPRO operator, then apply that operator's company, warehouse and program rights as filters on every tool call, or route the call through a business object so SYSPRO enforces them.

### How many GPUs does a SYSPRO assistant need?

**Answer:** Often one or two for 50 to 500 named users on a mid-size open-weight model, plus spare capacity for resilience. Peak concurrency, context length and model size drive the number, so measure with real prompts before buying.

## Search terms

add AI to SYSPRO on-prem, SYSPRO AI integration, SYSPRO private LLM, SYSPRO e.net business objects AI, chat with SYSPRO data, SYSPRO on-premises AI assistant, SYSPRO air-gapped AI, SYSPRO SQL Server read replica AI

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