# Private AI for Epicor Kinetic Cloud, Outside the Multi-Tenant Boundary > Source: https://netray.co/erp-ai/epicor-kinetic-cloud-private-ai > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: AI for ERP ## Short answer Epicor Kinetic Cloud runs as multi-tenant SaaS, which is fine for most workloads but raises a real question for manufacturers with export-controlled BOMs, routings, or customer IP: where does an AI feature actually process that data. A private AI layer grounds a self-hosted model on Kinetic's REST v2 API, BAQs, and Data Fabric, running on infrastructure you control, so the answer to that question is simply nowhere near Epicor's multi-tenant environment. ## Kind platform ## Erp Family epicor ## Erp Products - Epicor Kinetic - Epicor Kinetic Cloud ## Industries - Discrete Manufacturing - Industrial Equipment - Electronics - Aerospace ## Region Global ## Persona CIO ## Eyebrow Kinetic Cloud + private AI ## Intro If you are looking at Epicor Kinetic private cloud AI, the pattern is the same whichever way Kinetic is hosted: the model and retrieval layer run on infrastructure you control and read Kinetic through REST v2 and BAQs. Kinetic Cloud is Epicor's flagship manufacturing ERP, and its data model is genuinely well suited to AI: Business Activity Queries (BAQs) already package common questions into governed, reusable queries, the REST v2 API exposes nearly everything programmatically, and Epicor Data Fabric increasingly centralizes reporting data across modules. For a CIO evaluating AI, that is good news. The harder question is where any AI feature, whether Epicor's own or a third party's, actually runs and what happens to the data it touches. For manufacturers building for aerospace, defense, or other regulated end markets, that question is not abstract. A BOM or routing tied to an export-controlled part number, or a customer's proprietary design data sitting in engineering notes, cannot simply flow into a shared, multi-tenant AI feature without careful review of where the data lands and who might be able to access it, even accidentally, through model training or logging. A private AI layer solves this by keeping the model itself, and everything it touches, on infrastructure the manufacturer controls: an on-prem GPU server, a single-tenant private cloud, or a hybrid setup where Kinetic stays in Epicor's cloud but the AI layer reads through the REST v2 API into a system you operate. BAQs, Data Fabric, and Epicor Functions provide the plumbing; the model serving, retrieval, and governance sit entirely outside Epicor's multi-tenant boundary. This page walks through the specific pain points Kinetic Cloud IT and operations teams run into, seven use cases with the Kinetic objects they touch, and the architecture and compliance considerations for running AI this way. ## Pain Points ### Multi-tenant SaaS makes data residency a real question, not a formality **Detail:** Before pointing any AI feature, native or third party, at Kinetic Cloud production data, IT has to understand exactly where that feature processes and stores data, which is a harder conversation for export-controlled or customer-IP data than for routine transactional data. ### BAQs answer known questions well, but new questions still need a ticket **Detail:** A well-built BAQ library covers recurring reporting needs, but a planner or plant manager with a genuinely new question still has to ask IT to write a new query, and that queue rarely moves fast. ### The REST v2 API and Data Fabric expose the data, but not an ask-anything experience **Detail:** Kinetic's API surface is strong, but turning that into a governed, cited, natural-language experience for planners, finance, and shop floor staff is still a build project that most IT teams have not had bandwidth for. ### BPM directives automate what someone had time to write **Detail:** Business Process Management directives are powerful for enforcing rules and automating routine decisions, but the backlog of manual approvals and exception handling almost always exceeds the team's capacity to write and test new directives. ### A single natural-language view across Kinetic and adjacent systems is missing **Detail:** Quality, PLM, and MES tools often sit outside Kinetic, so answering a cross-system question, like the impact of an engineering change on open jobs and quality holds, means checking multiple systems by hand. ## Use Cases ### Ask-anything over Kinetic grounded in BAQs and Data Fabric **Description:** Planners, finance, and operations ask questions in plain English and get an answer grounded in existing BAQs where one exists, or a new query generated and shown for review where one does not. **Erp Objects:** BAQs, Epicor Data Fabric, REST v2 API **Outcome:** Routine questions get answered without a new BAQ ticket, and the underlying query is always shown for verification. ### MRP and APS exception triage **Description:** An agent summarizes MRP action messages and APS exceptions, grouping related suggestions and drafting recommended job or PO changes for a planner to approve with one click. **Erp Objects:** MRP action messages, job suggestions, PO suggestions, APS schedule **Outcome:** Planners triage exception queues in a fraction of the time, working from drafted recommendations instead of raw message lists. ### Approval copilot alongside BPM directives **Description:** For approvals not yet automated by a BPM directive, the assistant drafts a recommendation with the relevant policy or historical precedent cited, so an approver reviews rather than researches from scratch. **Erp Objects:** BPM directive logs, approval workflows, job and PO transactions **Outcome:** Routine approvals move faster because the reviewer starts from a drafted, cited recommendation. ### Engineering change impact assistant **Description:** When an ECO is proposed, the assistant identifies affected open jobs, purchase orders, and inventory before the change is released, rather than after problems surface. **Erp Objects:** ECO/ECN records, BOM, routings, open jobs and POs **Outcome:** Engineering and planning see the downstream impact of a change before release instead of discovering it after the fact. ### Quality NCR and CAPA drafting from shop floor notes **Description:** Quality engineers get a first-draft NCR or CAPA narrative generated from operator notes and inspection records, which they edit and approve rather than write from a blank page. **Erp Objects:** NCR records, CAPA records, inspection results **Outcome:** Cuts the time to write up a nonconformance, freeing quality staff for root-cause work instead of documentation. ### Shop floor operator copilot **Description:** Operators ask routing, work instruction, and specification questions on a tablet at the work center and get an answer grounded in the current job traveler, without leaving the floor. **Erp Objects:** Job traveler, work instructions, labor entry, routing **Outcome:** Fewer walks to the supervisor's office for routine routing or specification questions. ### Month-end close and variance commentary **Description:** Controllers get a first-draft variance narrative, grounded in Kinetic job costing and GL data, to edit and finalize rather than build from scratch each close. **Erp Objects:** GL, job costing, cost variance reports **Outcome:** Cuts the manual drafting time in month-end close variance commentary. ## Architecture **Overview:** The AI layer connects to Kinetic Cloud through its REST v2 API, BAQ execution service, and Data Fabric extracts, but the model itself, the retrieval index, and the agent logic run entirely outside Epicor's multi-tenant environment, on infrastructure the manufacturer owns or a single-tenant private cloud it controls. **Layers:** #### Kinetic connector layer **Detail:** Authenticated access via REST v2 API and BAQ execution, supplemented by scheduled Data Fabric extracts for reporting-heavy use cases, using a scoped service account. #### Semantic and data layer **Detail:** Maps Kinetic's data model, BAQ output, and Data Fabric tables into business terms so the model reasons about jobs, ECOs, and NCRs rather than raw field names. #### Model serving **Detail:** An open-weight model served with vLLM or Ollama on GPU hardware fully outside Epicor's cloud, whether on-prem or in a single-tenant private cloud. #### Retrieval and agents **Detail:** RAG grounds answers in current Kinetic data; agents for MRP triage, ECO impact, and NCR drafting operate read-only by default, with any write-back requiring explicit human approval. #### Governance and audit **Detail:** Access mirrors Kinetic security roles, and every query, retrieved record, and generated answer is logged, giving IT a full audit trail independent of Epicor's own logs. ## Deployment Options ### Air-gapped on-prem **Fit:** Manufacturers with export-controlled data who run Kinetic on-prem or in a private cloud rather than Epicor's multi-tenant SaaS **Detail:** Model and data both stay inside the manufacturer's own network boundary, with the Kinetic connector operating over a local API or database access rather than the public internet. ### Private or sovereign cloud **Fit:** Kinetic Cloud (multi-tenant SaaS) customers who need a private AI layer without moving off Epicor's cloud **Detail:** The AI layer runs in a single-tenant private cloud instance under the manufacturer's control, reading Kinetic data over REST v2, so Kinetic stays in Epicor's SaaS while AI processing stays private. ### Hybrid **Fit:** Manufacturers piloting AI in one plant or business unit before a broader rollout **Detail:** Data Fabric extracts feed a pilot instance for one division, proving accuracy and value before extending the connector and model capacity to the rest of the organization. ## Compliance ### Export-controlled BOM, routing, and drawing data stays within a US-persons-controlled, private infrastructure boundary rather than transiting Epicor's multi-tenant AI features or a public LLM API. **Framework:** ITAR / EAR ### For defense-supply-chain manufacturers, the private AI layer's infrastructure is scoped to sit inside the same CUI-handling enclave as Kinetic, rather than introducing a new external processing boundary. **Framework:** CMMC 2.0 ### NCR and CAPA drafting preserves full traceability to the underlying inspection and operator records, since quality auditors need to trace any AI-assisted narrative back to source data. **Framework:** AS9100 / ISO 9001 ### Where any cloud component is used for the private AI layer, it is evaluated and documented independently of Epicor's own SOC 2 posture, since the two are separate systems. **Framework:** SOC 2 ### For manufacturers with regional data residency requirements that differ from where Epicor hosts Kinetic Cloud, the private AI layer's infrastructure can be sited independently to meet that requirement. **Framework:** Data residency ## Integration Notes Primary integration path is the Kinetic REST v2 API with OAuth-based service account authentication, scoped to read-only access for the majority of use cases. BAQs already in production get reused directly rather than reinvented; the semantic layer maps to existing BAQ output first and only generates new queries where a gap exists. Epicor Data Fabric extracts are useful for reporting-heavy use cases like variance commentary, where a batch feed is more efficient than repeated live API calls. Epicor Functions can expose narrowly scoped custom endpoints for specific agent actions, keeping the write-back surface small and auditable. ECO and NCR drafting agents need access to unstructured operator and engineering notes alongside structured Kinetic records; document ingestion is scoped and reviewed before go-live. For on-prem or private-cloud Kinetic deployments, direct database access (where supported) can supplement the API for higher-volume reporting use cases. Any write-back, whether an MRP action taken or an NCR filed, goes through a human approval step by default; auto-approval is only enabled after a track record is established. ## Product Fit ### ERPray **Why:** Directly fits ask-anything question answering over Kinetic data, dashboards for planners and finance, and agents for MRP triage and approvals, all grounded and auditable. ### Custom build **Why:** ECO impact analysis, NCR/CAPA drafting, and shop-floor copilots typically need workflow-specific logic and unstructured document handling beyond a generic Q&A layer. ## Engagement ### Discovery **Duration:** 2-3 weeks **Deliverables:** - Inventory of existing BAQs, Data Fabric feeds, and REST v2 API usage - Classification of export-controlled or customer-IP data in scope - Deployment model decision (on-prem, private cloud, or hybrid) based on data sensitivity - Prioritized use case list scored by planning, quality, and finance impact ### Pilot **Duration:** 6-8 weeks **Deliverables:** - Working ask-anything Q&A over BAQ and Data Fabric data for one business unit - MRP/APS exception triage agent tested against a live planning cycle - Access control mapped to Kinetic security roles - Accuracy review with planning, quality, and finance stakeholders ### Production **Duration:** 4-8 weeks **Deliverables:** - Company-wide rollout across relevant business units - ECO impact assistant and NCR drafting live with human review - Full audit logging independent of Epicor's own logs - Documentation for CMMC/ITAR data-handling review where applicable ### Scale **Duration:** Ongoing **Deliverables:** - Additional agents for shop floor and month-end close - Periodic accuracy review of drafted narratives against auditor expectations - Capacity and GPU planning as usage grows - Extension to additional plants or divisions ## Buyer Questions - Exactly where does the model run, and is that location fully outside Epicor's multi-tenant AI environment? - Does the private AI layer ever send export-controlled BOM or routing data to a public LLM API, even transiently? - How does the solution reuse our existing BAQ library rather than duplicating that work? - What is the write-back path for agent-drafted actions, and is human approval mandatory by default? - How is access control mapped to our existing Kinetic security roles? - Can this run in a private cloud we control if we are not ready for on-prem GPU hardware? - What audit trail exists independent of Epicor's own SOC 2 and logging? - What does a pilot for one business unit cost, and what does full rollout cost beyond that? ## Faq ### Is Epicor's own AI capability enough, or do we need a private layer? **Answer:** For manufacturers without export-controlled or customer-IP data sensitivity, Epicor's own AI features may be sufficient. A private layer becomes the right answer when data residency, ITAR/EAR exposure, or customer contract terms require processing to stay entirely outside a multi-tenant AI environment that the manufacturer does not fully control. ### Does a private AI layer duplicate our existing BAQs? **Answer:** No, it reuses them. The semantic layer is built to map to existing BAQs first, so the AI answers routine questions using queries your team has already validated. New queries are only generated for genuinely new questions, and those are shown for review rather than run blind. ### Can this work if Kinetic stays on Epicor's multi-tenant cloud? **Answer:** Yes. The most common setup keeps Kinetic in Epicor's SaaS environment and runs the AI layer, model, and data processing in a separate private cloud or on-prem environment, connecting through the REST v2 API. Kinetic itself does not need to move for this to work. ### How does this handle ITAR-controlled BOM or routing data? **Answer:** The connector and model serving are scoped to a US-persons-controlled infrastructure boundary, and export-controlled data never transits a public LLM API or a multi-tenant AI feature outside that boundary. This is a deployment design decision made explicit during discovery, not an afterthought. ### What is the realistic timeline from decision to a working pilot? **Answer:** Most Kinetic Cloud pilots go from discovery to a working ask-anything Q&A pilot for one business unit in roughly two to three months, assuming BAQ and Data Fabric access is already reasonably mature. Deployments starting from a weaker data foundation take longer for the discovery phase. ### Do we need a data scientist on staff to run this? **Answer:** No. The model, retrieval layer, and agents are built and tuned during the engagement; day-to-day operation is closer to managing a reporting tool than a data science project. IT retains ownership of access control, audit review, and requests for new use cases. ### How does this compare in cost to Epicor's own AI add-ons? **Answer:** Costs differ in structure: Epicor's native AI features are typically a subscription line item, while a private AI layer has upfront integration cost plus ongoing infrastructure and model-serving cost. For manufacturers who need the private-infrastructure guarantee, that trade-off is usually worth evaluating against the compliance requirement, not against price alone. ## Search terms Epicor Kinetic AI, Epicor Kinetic Cloud AI integration, private AI for Epicor Kinetic, on-prem AI for Epicor Kinetic Cloud, Epicor Kinetic copilot, Epicor Kinetic generative AI, Kinetic BAQ AI, Epicor Kinetic REST API AI agent, Kinetic Data Fabric AI, AI for Epicor manufacturers, Epicor Kinetic ITAR AI, Epicor Kinetic chatbot, Epicor AI alternative on-prem --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json