EpicorFree templatePDF, Excel, Word exportEpicor KineticDiscrete Manufacturing

Epicor Kinetic Private AI Layer Blueprint Generator

This generator turns a few facts about your Epicor Kinetic estate into an architecture plan for a private AI assistant: how it reads data, where the model runs, how security is carried across, and how to roll out in phases. The output exports to PDF or Word for your IT review.

Fill in

Live preview
Download:

Epicor Kinetic Private AI Layer Blueprint Generator

Private AI Layer Architecture Plan: Epicor Kinetic

Prepared for: Acme Precision Ltd System: Epicor Kinetic Kinetic 2023.x on SQL Server 2019 Hosting: On-prem server Named users: 220 across 2 site(s) Target go-live: 2027-02-01

1. Context and goals

This plan describes a private AI layer over Epicor Kinetic running on premises. The assistant answers from live Epicor data and local documents, runs on infrastructure owned by the company, and never sends prompts or data to an external AI service.

Main use cases: Open job status and due dates Part availability across warehouses Late purchase orders by supplier Quote and order status for sales

Data that must stay on site: Customer drawings and specifications Cost rollups and margins Export-controlled technical data

GPU position: One 48 GB GPU.

2. Components

ComponentDesign for Acme Precision LtdNotes
Data access pathExecutable BAQs through REST v2 (BaqSvc) for operational questions; read-only SQL Server copy of the Erp schema for history and analyticsBusiness objects such as Erp.BO.JobEntrySvc are used when application rules must apply.
Retrieval indexLocal vector store over job travelers, drawings, inspection reports, supplier certificates and SOPs; change tracking drives incremental updatesEvery chunk carries source, site and access tags; untagged content is excluded.
Model servingOpen-weight model on vLLM or Ollama, sized for 220 named users on One 48 GB GPUModel, quantisation and version recorded in the audit log.
Tool serverMCP or HTTP tool server exposing approved BAQ-backed actions such as job status and part availabilityParameterised read actions only; row caps and column allow lists.
Identity and permissionsEnd-user token passthrough to Epicor where possible; otherwise a restricted service user with company, plant and security group tags mirrored into the indexUnknown users and unmapped content default to no access.
AuditAppend-only log of user, prompt, tool call, parameters, row counts and answerRetained per Acme Precision Ltd records policy; reviewed at each rollout phase.

3. Security controls mapped to your inputs

ControlImplementationDriven by
Data residencyReplica, index and model all inside the On-prem server boundary; no outbound API calls at run timeData that must never leave the site
Least privilegeDedicated Epicor integration user limited to specific BAQs; read-only SQL login on the replica onlySystem version and role model
Network isolationDedicated segment for model and tool servers; only the tool server reaches the data sourceHosting
Prompt injection defenceModel receives bounded tool results only; no direct database or file accessUse cases
Write-backWrites only via Kinetic business objects or Epicor Functions under the approving user's identity, with a visible payload diffPhase 3 scope

4. Rollout plan

PhaseScopeExit criteria
1: Read-only (weeks 1-6)Approved read actions and document Q&A for a pilot group at one siteAccuracy review of sampled answers; no permission leaks in adversarial tests
2: Drafts (weeks 7-12)Summaries, reports and draft documents saved for human completionUsers edit rather than rewrite; audit log reviewed by IT and data owners
3: Approved actions (week 13 onward)Narrow, reversible transactions via supported interfaces after explicit approvalRollback tested per action type; owner sign-off per action

5. Open questions for IT

Which Kinetic release and patch level is in production, and is REST v2 enabled with API keys? Which BAQs already exist and which need to be created and reviewed? Can a readable SQL Server secondary be added without licensing impact? Where do attachments live, and what access rules apply to them? Who owns approval of write-back actions? What is the network path for model and tool servers, and is a change window available?

Approvals

IT lead / Date
Data owner / Date
Information security / Date
Business sponsor / Date

Starting point for discussion, not a design guarantee. Verify REST v2 availability, authentication options and BAQ API settings against your Kinetic release and Epicor documentation. Model and GPU choices should be validated with a measured pilot.

Epicor Kinetic architecture review

Optional: have an engineer review your generated blueprint against your environment and flag gaps before you buy hardware.

Optional. The tool and every export work without this. No spam.

How to use it

Fill in the company, Kinetic release, database engine, hosting model, user and site counts, GPU position and target date. Then write the use cases as plain questions your users ask today, and list the data that must never leave the site. The document updates as you type; export it when it reads correctly.

  • Use real questions from your help desk or BAQ request queue
  • Be explicit about export-controlled or customer-restricted data
  • State the GPU you actually have or have budgeted
  • Pick air-gapped only if the network truly has no outbound path

What the plan contains

The plan has six parts: context, a components table, security controls mapped to your inputs, a three-phase rollout, open questions for IT, and an approvals block. The components cover the data access path (BAQs over REST v2 and a read-only replica), the retrieval index, model serving with vLLM or Ollama, the tool server, identity and permissions, and an audit log.

Common mistakes it helps you avoid

The usual failures are giving a model a generic SQL tool, running everything under one broad service account, and indexing attachments without their access rules. The plan makes each of these an explicit decision, and the open questions list prompts for the facts that most often delay projects.

  • No direct production SQL for the model
  • Per-user permissions carried into retrieval
  • Writes only through business objects with approval
  • Release-specific checks for REST and token support

Frequently Asked Questions

Does this work for air-gapped Kinetic sites?

Yes. Choose air-gapped hosting and the plan keeps models, embeddings, containers and the index inside the network, with weights and packages staged through a controlled transfer. Nothing in the architecture needs an outbound call at run time.

Is the plan specific to Kinetic or generic?

The data access path, identity model and write-back mechanisms are specific to Kinetic: BAQs, REST v2, business objects and Epicor security groups. The model serving and audit parts are the same as for any ERP.

Can I use the output as a project document?

Yes, as a starting document for IT and security review. It is not a final design: confirm version-specific details and run a measured pilot before purchasing hardware.

Does the assistant change data in Epicor?

Not in phases 1 and 2. In phase 3, narrow actions go through supported business objects under the approving user's identity after a visible diff. Many sites choose to stay read-only permanently, which is a valid outcome.

If you want an engineer to review the plan against your Kinetic environment, or to build it inside your network, Netray can do that. The generator is free to use without contact.

Keep exploring

Free tools

ERP fixes and how-tos

Guides

AI on your ERP

Integrations

Comparisons

Software