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

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

1. 1Inventory 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.
2. 2Build 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.
3. 3Create 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).
4. 4Stand 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.
5. 5Build 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.
6. 6Expose 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.
7. 7Serve 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.
8. 8Pilot 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.

Reference architecture, including air-gapped

Write-back, sizing and phased rollout

# 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"
}

Common 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.