# Epicor Kinetic Private AI Layer Blueprint Generator > Source: https://netray.co/tools/epicor-kinetic-private-ai-layer-blueprint-generator > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer Generate a shareable private AI architecture plan for Epicor Kinetic on-premises, with components, security controls, rollout phases and open questions for IT. ## Category epicor ## Erp Epicor Kinetic ## Industry Discrete Manufacturing ## Audience - CIO - IT manager - ERP architect - Infrastructure engineer ## Tool **Kind:** template **Output:** document **Fields:** #### Company name **Key:** company **Type:** text **Default:** Acme Precision Ltd #### System version **Key:** version **Type:** select **Options:** - Kinetic 2023.x - Kinetic 2022.x - Kinetic 2021.x - Kinetic 2024.x or later **Default:** Kinetic 2023.x #### Database engine **Key:** db **Type:** select **Options:** - SQL Server 2019 - SQL Server 2022 - SQL Server 2017 **Default:** SQL Server 2019 #### Hosting **Key:** hosting **Type:** select **Options:** - On-prem server - Private cloud - Air-gapped network **Default:** On-prem server #### Named users **Key:** users **Type:** number **Default:** 220 #### Sites or plants **Key:** sites **Type:** number **Default:** 2 #### Main use cases **Key:** use_cases **Type:** textarea **Default:** Open job status and due dates Part availability across warehouses Late purchase orders by supplier Quote and order status for sales #### Data that must never leave the site **Key:** never_leave **Type:** textarea **Default:** Customer drawings and specifications Cost rollups and margins Export-controlled technical data #### GPU available **Key:** gpu **Type:** select **Options:** - None yet - One 24 GB GPU - One 48 GB GPU - Two or more 48 GB GPUs - Cloud GPU in a private tenancy **Default:** One 48 GB GPU #### Target go-live **Key:** golive **Type:** date **Default:** 2027-02-01 **Blocks:** #### Private AI Layer Architecture Plan: Epicor Kinetic **Body:** Prepared for: {{company}} System: Epicor Kinetic {{version}} on {{db}} Hosting: {{hosting}} Named users: {{users}} across {{sites}} site(s) Target go-live: {{golive}} #### 1. Context and goals **Body:** 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: {{use_cases}} Data that must stay on site: {{never_leave}} GPU position: {{gpu}}. #### 2. Components **Table:** **Columns:** - Component - Design for {{company}} - Notes **Rows:** **0:** Data access path **1:** Executable BAQs through REST v2 (BaqSvc) for operational questions; read-only SQL Server copy of the Erp schema for history and analytics **2:** Business objects such as Erp.BO.JobEntrySvc are used when application rules must apply. **0:** Retrieval index **1:** Local vector store over job travelers, drawings, inspection reports, supplier certificates and SOPs; change tracking drives incremental updates **2:** Every chunk carries source, site and access tags; untagged content is excluded. **0:** Model serving **1:** Open-weight model on vLLM or Ollama, sized for {{users}} named users on {{gpu}} **2:** Model, quantisation and version recorded in the audit log. **0:** Tool server **1:** MCP or HTTP tool server exposing approved BAQ-backed actions such as job status and part availability **2:** Parameterised read actions only; row caps and column allow lists. **0:** Identity and permissions **1:** End-user token passthrough to Epicor where possible; otherwise a restricted service user with company, plant and security group tags mirrored into the index **2:** Unknown users and unmapped content default to no access. **0:** Audit **1:** Append-only log of user, prompt, tool call, parameters, row counts and answer **2:** Retained per {{company}} records policy; reviewed at each rollout phase. #### 3. Security controls mapped to your inputs **Table:** **Columns:** - Control - Implementation - Driven by **Rows:** **0:** Data residency **1:** Replica, index and model all inside the {{hosting}} boundary; no outbound API calls at run time **2:** Data that must never leave the site **0:** Least privilege **1:** Dedicated Epicor integration user limited to specific BAQs; read-only SQL login on the replica only **2:** System version and role model **0:** Network isolation **1:** Dedicated segment for model and tool servers; only the tool server reaches the data source **2:** Hosting **0:** Prompt injection defence **1:** Model receives bounded tool results only; no direct database or file access **2:** Use cases **0:** Write-back **1:** Writes only via Kinetic business objects or Epicor Functions under the approving user's identity, with a visible payload diff **2:** Phase 3 scope #### 4. Rollout plan **Table:** **Columns:** - Phase - Scope - Exit criteria **Rows:** **0:** 1: Read-only (weeks 1-6) **1:** Approved read actions and document Q&A for a pilot group at one site **2:** Accuracy review of sampled answers; no permission leaks in adversarial tests **0:** 2: Drafts (weeks 7-12) **1:** Summaries, reports and draft documents saved for human completion **2:** Users edit rather than rewrite; audit log reviewed by IT and data owners **0:** 3: Approved actions (week 13 onward) **1:** Narrow, reversible transactions via supported interfaces after explicit approval **2:** Rollback tested per action type; owner sign-off per action #### 5. Open questions for IT **Body:** 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 **Signatures:** - IT lead - Data owner - Information security - Business sponsor **Notes:** 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. ## Content **Intro:** 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. **Sections:** #### How to use it **Body:** 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. **Bullets:** - 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 **Body:** 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 **Body:** 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. **Bullets:** - 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 **Cta:** 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. **Faq:** #### Does this work for air-gapped Kinetic sites? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms Epicor Kinetic AI architecture, Epicor Kinetic on-prem AI plan, private LLM Epicor template, Epicor BAQ AI integration, Epicor Kinetic AI blueprint, on-prem AI architecture document --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json