# How to Add AI to Epicor Kinetic On-Premises Without Moving Your Data

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

## Short answer

You can run a useful AI assistant on an on-premises Epicor Kinetic estate without sending data to a public cloud. Read through BAQs and the REST v2 OData layer (or a read-only SQL Server replica of the Erp schema), index documents locally, serve an open-weight model with vLLM or Ollama on your own GPUs, and route any write through supported Epicor business objects with a human approval step.

## Kind

advanced

## System

epicor

## Erp

Epicor Kinetic (on-premises)

## Module

Integration / REST v2 / BAQ / SQL Server

## Query

how to add AI to Epicor Kinetic on-prem

## Alternate Queries

- Epicor Kinetic AI integration without cloud
- private LLM for Epicor Kinetic on-premises
- Epicor Kinetic ChatGPT alternative on-prem BAQ REST
- air-gapped AI assistant for Epicor Kinetic

## Applies To

Epicor Kinetic on-premises (SQL Server back end, REST v2 available) in single-company and multi-company installs; the same pattern applies to air-gapped networks with a local model registry

## Steps

### How to stand up a private AI layer on Epicor Kinetic on-prem

**Items:**

Inventory the questions people actually ask: open jobs and due dates, part availability by warehouse, quote and order status, supplier lateness, MRP pegging. Each question maps to one or more BAQs or Erp schema tables.

Build or reuse BAQs for those questions in Business Activity Query Designer, mark them as executable through the API, and keep them narrow (named columns, date filters) instead of exposing whole tables.

Create a dedicated Epicor service user and API key for the integration, and decide whether calls run as that service identity or on behalf of the end user with their own token (the second option preserves Epicor security natively).

Stand up a read-only SQL Server reporting copy (an Always On readable secondary, log shipping or a restored backup) for bulk and historical questions so analytical load never touches the production database.

Build a retrieval index over documents and attachments (job travelers, drawings, inspection reports, supplier certs, SOPs) on a local vector store, storing the source system, company, plant and ACL tags with every chunk.

Expose approved read actions through a tool server (MCP or a plain HTTP tool API): for example get_job_status, find_part_availability, list_late_purchase_orders. The model never receives a connection string.

Serve an open-weight model with vLLM or Ollama on local GPUs, route every prompt and tool call through a gateway that logs user, tool, parameters and row counts to an append-only audit store.

Pilot read-only with a small group for several weeks, then add drafts (a purchase order or quote saved as a draft), then approved actions that call the relevant business object after a person confirms.

## Sections

### Data access paths in Kinetic

**Body:**

Kinetic exposes data three useful ways. The REST v2 OData service publishes business objects (for example Erp.BO.JobEntrySvc) and, through the BaqSvc endpoint, any BAQ you have enabled for the API. The SQL Server database holds the Erp schema (tables such as Erp.JobHead, Erp.JobMtl, Erp.JobOper, Erp.PartTran, Erp.Part, Erp.PartBin, Erp.OrderHed, Erp.OrderDtl, Erp.POHeader, Erp.PODetail), and Epicor Functions and BPM directives let you add server-side logic behind a defined contract.

For an assistant, BAQs are usually the best first path. They are named, versioned, reviewable by the business, and they run under Epicor security. Direct SQL is better for history, trend questions and cross-table analytics, because you can index and tune a replica freely. Do not point a model at production with a generic SQL tool: give it parameterised, pre-approved queries.

Use REST v2 with the API key header plus the user credential or token your site configured. The URL shape for a BAQ is /api/v2/odata/{Company}/BaqSvc/{BAQId}/Data and for a business object is /api/v2/odata/{Company}/Erp.BO.JobEntrySvc/JobHeads.

**Code:**

GET https://erp.example.local/ERP/api/v2/odata/EPIC03/BaqSvc/AI_OpenJobs/Data?$filter=ReqDueDate lt 2026-11-30&$top=50
X-API-Key: <integration key>
Authorization: Bearer <user or service token>
Accept: application/json

-- Read-only replica query for the same question
SELECT TOP 50 jh.JobNum, jh.PartNum, jh.ProdQty, jh.ReqDueDate
FROM Erp.JobHead jh
WHERE jh.Company = 'EPIC03'
  AND jh.JobClosed = 0
  AND jh.JobComplete = 0
ORDER BY jh.ReqDueDate;

### Reference architecture, including air-gapped

**Body:**

The components are: a readable SQL Server copy for analytics, a change feed (SQL Server change tracking or CDC on the replica) that keeps the retrieval index current, a document extractor for attachments and the files your Epicor install references, a vector store, a tool server with approved read actions, a model server (vLLM for throughput, Ollama for small pilots), and a gateway with an audit log. Everything runs inside your network.

For an air-gapped site, load model weights, Python wheels and container images through a controlled transfer once, pin versions, and keep the embedding model local too. Nothing in this design calls an external API at run time. Updates then become a scheduled change window like any other server patch, with the model version recorded in the audit log.

Keep the model out of the data path where you can. Let the tool server run the query and return a bounded result (row cap, column allow list) and let the model only phrase and reason over what it receives. That one rule removes most prompt injection and data leakage risk.

### Permissions: making the assistant respect Epicor security

**Body:**

Kinetic security is built from security groups, menu and method permissions, company and plant assignments, and field or row restrictions applied through BPM and BAQ design. The safest pattern is to call the API as the end user (token passthrough), so Epicor itself enforces what that person can see. The assistant then needs no copy of the security model.

If you must use a service identity for the retrieval index, mirror access into the index: store company, plant and the security group list as filter metadata on every chunk, resolve the asking user's groups at query time, and apply the filter before retrieval. Documents with unknown ACLs should be excluded rather than defaulted to open.

Test it adversarially. Ask as a buyer for cost rollups only finance can see, and as a user in plant A for plant B jobs. Each denied case is a regression test you rerun after every Epicor upgrade, since security group changes and new BAQs shift the surface.

### Write-back, sizing and phased rollout

**Body:**

Write-back goes only through supported business objects, Epicor Functions or DMT-style loads, never through direct SQL. The assistant prepares a payload (for example a purchase order change) and shows it to the user as a diff; a person approves; the call runs under that person's identity so BPM directives and audit fields fire normally. Keep a rollback note for each action type.

Rough sizing for a mid-size plant: 100 to 300 named users, 20 to 40 percent active daily, typically needs one to two 24 GB to 48 GB class GPUs for a 7B to 32B parameter model, plus 16 to 64 GB of RAM for the vector store and a few hundred GB of storage for indexed documents. Concurrency, not user count, drives GPU needs, so measure peak requests before buying.

Roll out in three phases: read-only Q&A on BAQs for a pilot group; drafts and summaries (job status reports, supplier chasers); then approved actions for narrow, reversible transactions. Hold each phase for a few weeks and review the audit log before moving on.

**Code:**

# Example tool definition exposed to the model (read only)
{
  "name": "get_job_status",
  "description": "Return status, due date and open operations for one job",
  "inputSchema": {"type": "object", "properties": {"company": {"type": "string"}, "job_num": {"type": "string"}}, "required": ["company", "job_num"]},
  "backend": "BaqSvc/AI_JobStatus"
}

## Pitfalls

- Giving the model a generic SQL tool against production, which allows unbounded scans, schema leakage and accidental load.
- Using one shared service account for everything, so every user effectively inherits the integration's access.
- Indexing attachments without their access metadata, so a drawing restricted in Epicor becomes searchable by everyone.
- Building BAQs that return whole tables instead of named columns, which inflates tokens and widens exposure.
- Skipping a regression test of security cases after Kinetic upgrades or new BAQ releases.

## Ai Angle

ERPray is built for this pattern on Epicor: a grounded assistant that answers from approved BAQs and REST calls, shows the query it ran, respects Epicor roles, and can run entirely on your own GPUs. Where the questions are simple and fixed, Epicor's own dashboards and BAQ reports may be enough; the assistant earns its place on the cross-module questions that currently need an analyst.

## Faq

### Can an AI assistant work with Epicor Kinetic on-prem without the cloud?

**Answer:** Yes. Read data through BAQs and REST v2 or a read-only SQL Server replica, index documents locally, and serve an open-weight model with vLLM or Ollama on your own GPUs. Nothing in that design needs an external API at run time, which also makes an air-gapped deployment feasible.

### Should the assistant query SQL Server directly or use the REST API?

**Answer:** Use BAQs and REST for operational questions so Epicor security applies, and a read-only replica for history and analytics. Avoid direct writes to the database entirely. Direct SQL on production for a model is the pattern most likely to cause performance problems and data exposure.

### How do I stop the assistant showing data a user should not see?

**Answer:** Prefer calling the API with the end user's own token so Epicor enforces its groups and plants. If you use a service account for retrieval, copy company, plant and group metadata onto every indexed chunk and filter on it before retrieval, then test denied cases after each upgrade.

### How much GPU do we need?

**Answer:** It depends on peak concurrent requests, not named users. Many mid-size plants fit on one or two 24 GB to 48 GB GPUs with a 7B to 32B model. Measure real question volume in a pilot, then size with a calculator before purchasing hardware.

## Search terms

Epicor Kinetic AI integration, Epicor Kinetic on-prem AI, private LLM Epicor, Epicor BAQ REST v2 AI assistant, air-gapped AI Epicor, Epicor Kinetic ChatGPT on-premises, local LLM ERP Epicor, Epicor AI without cloud

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