# AI for Infor LX: A Private Layer on Top of Your IBM i Investment > Source: https://netray.co/erp-ai/infor-lx-ai-integration > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: AI for ERP ## Short answer Infor LX, the direct descendant of BPCS, still runs core manufacturing on IBM i at plants that have no near-term plan to replatform; a private AI layer reads LX data through Business Object Documents and IBM i file access, answers planner and CSR questions in plain language, and drafts routine paperwork without sending green-screen data to a public model API. On-prem deployment keeps the AI workload inside the same IBM i boundary LX itself already runs in. ## Kind platform ## Erp Family infor ## Erp Products - Infor LX - Infor LX CloudSuite ## Industries - Manufacturing - Food and Beverage - Industrial Equipment - Chemicals ## Region Global ## Persona IT Director ## Eyebrow Infor LX + AI ## Intro If you run Infor LX today, the odds are good that the 5250 green-screen and RPG program logic underneath it have been stable for a very long time, and that stability is exactly why LX still runs production for food and beverage, chemical, and industrial equipment plants that migrated off BPCS years ago and never had a business reason to move again. The system works. The problem is that almost nobody outside a small group of long-tenured planners and IT staff can get an answer out of it without knowing which program, menu option, or query to run. Every AI conversation your leadership team has now assumes a modern cloud ERP with a chat window built in. LX does not have that, and Infor's own generative AI messaging is aimed squarely at CloudSuite customers on its multi-tenant platform, not at an on-prem IBM i shop running LX. That leaves you choosing between waiting for a replatforming project that may be years away, or finding a way to add AI value to the system you actually run today. The technical path is more available than it looks. LX already exposes structured integration through Business Object Documents over Infor ION for shops that have adopted it, and every LX installation supports direct, read-only access to its DB2 for i files for reporting and BI tools. A private AI layer builds on the same two paths: it answers questions and drafts documents by reading LX data through a supported interface, and it routes anything that would write back to LX through the same approval a person would give before keying a transaction. This page covers what that looks like specifically for LX: the realistic use cases for a planner- and CSR-heavy IBM i shop, how the connector and governance layers are built, deployment options for a plant that will likely stay on IBM i for years, and the questions worth asking before committing budget. ## Pain Points ### RPG and 5250 knowledge is concentrated in a shrinking group **Detail:** The staff who know which LX program and menu option answers a given question are often close to retirement, and that knowledge rarely gets written down anywhere a new hire can find it. ### Reporting requests queue up behind IT **Detail:** Anyone who needs an answer outside a standard LX inquiry screen or an existing query comes to IT, which means routine questions compete with everything else on a small IBM i team's plate. ### MRP action messages get triaged by habit, not data **Detail:** After an MRP regeneration, planners work through action messages largely from memory of which exceptions usually matter, rather than a structured view of root cause and priority. ### No self-service path for order and inventory status **Detail:** CSRs and sales staff who are not fluent in LX inquiry screens end up calling a planner or customer service lead for status that is technically already in the system. ### AI vendor pitches assume a system LX is not **Detail:** Most generative AI demos from ERP vendors are built around a modern web UI and a cloud tenant; almost none of them address a 5250-based, IBM i-hosted LX environment directly. ## Use Cases ### Order and shipment status in plain English **Description:** CSRs and sales staff ask about order status, ship dates, and open quantities without navigating LX order entry and inventory inquiry screens. **Erp Objects:** LX order entry and inventory management files, BODs published via ION where configured **Outcome:** Cuts routine order-status questions that used to require a call to planning down to a direct, immediate answer. ### MRP exception triage **Description:** An agent groups the post-regeneration action message list by likely root cause, such as a late supplier or a demand change, and proposes a priority order for a planner to confirm. **Erp Objects:** LX MRP action messages, purchase order and work order files **Outcome:** Shortens the time a planner spends scanning a long action message list after each regeneration to a focused review. ### Inventory and lot inquiry across facilities **Description:** Warehouse and quality staff check on-hand, allocated, and lot-traceable quantities across multiple facilities without learning facility-specific inquiry screens. **Erp Objects:** LX inventory and lot control files across facility codes **Outcome:** Reduces ad hoc inventory lookup requests, particularly useful during month-end and cycle counts. ### Purchase order expediting drafts **Description:** The system drafts expedite or confirmation follow-ups to suppliers for late purchase order lines, referencing the PO number, item, and promised date, for a buyer to review before sending. **Erp Objects:** LX purchase order header and detail files, vendor master **Outcome:** Turns a recurring afternoon of manual follow-up drafting into a short review-and-send step for the buyer. ### Standard cost variance explanation **Description:** When a standard cost update produces an unexpected variance on an item, an agent traces the change back to a specific bill of material, routing, or purchase cost update and summarizes it for the cost accountant. **Erp Objects:** LX item cost, bill of material, and routing files **Outcome:** Turns a variance investigation that used to take an afternoon of file navigation into a first-pass summary in minutes. ### Onboarding help for new planners and CSRs **Description:** New staff ask the assistant how a specific LX process or menu option works, grounded in documentation and prior transaction examples, instead of interrupting a senior colleague repeatedly. **Erp Objects:** LX process documentation, historical transaction examples from production files **Outcome:** Shortens the ramp time for new hires on LX-specific processes without adding to a trainer's workload. ### BOD and integration traceability **Description:** For shops running ION, business users ask why a specific record changed, and the assistant traces the answer back to the triggering BOD or integration event without involving IT. **Erp Objects:** BOD publish and subscribe logs, ION workflow history **Outcome:** Cuts the number of integration-tracing tickets that land on a stretched IBM i team. ## Architecture **Overview:** The pattern for LX keeps the model close to the IBM i database, uses the same BOD and file-access paths any supported integration already uses, and puts a human approval step in front of anything that writes back to production. **Layers:** #### ERP connectors **Detail:** Business Object Documents through Infor ION where configured, and direct, read-only DB2 for i file access for facilities that have not adopted ION, matching how existing reporting and BI tools already read LX data. #### Data and semantic layer **Detail:** A business glossary maps LX's file and field naming, including plant-specific customizations, to the terms planners, buyers, and CSRs actually use, so a question resolves to the right file and facility. #### Model serving **Detail:** An open-weight model served with vLLM or Ollama on a GPU server that sits alongside, not inside, the IBM i partition, sized to the plant's query volume rather than a per-seat cloud subscription. #### Retrieval and agents **Detail:** Retrieval-augmented generation grounds answers in current LX data and linked documents; agent workflows that would write to LX, such as a PO expedite draft, stop at an approval step before anything is posted. #### Governance and audit **Detail:** LX's facility and menu-level security is mirrored so a user only sees what their LX sign-on already permits, and every query and proposed write is logged for review. ## Deployment Options ### Air-gapped on-prem **Fit:** Plants running LX on an on-prem IBM i partition, especially food, chemical, or defense-adjacent manufacturers who cannot send production data outside their network. **Detail:** The model, retrieval index, and LX connector all run inside the plant network with no outbound internet dependency for inference; model updates are applied as offline packages on a schedule you control. ### Private or sovereign cloud **Fit:** Organizations running LX on a hosted or managed IBM i environment and comfortable keeping the AI workload in that same private tenancy. **Detail:** The model runs in a customer-controlled VPC or private cloud region, separate from any Infor multi-tenant cloud, connected to the IBM i partition over a private link. ### Hybrid **Fit:** Multi-plant organizations with LX on-prem at some sites and other Infor products or a future CloudSuite plan for others. **Detail:** Interactive question-answering and any write-approval workflow stay close to the IBM i partition; heavier batch jobs, such as a full document re-index, run on scheduled private-cloud capacity with no live LX credentials attached. ## Compliance ### For LX shops that hold technical data subject to ITAR or EAR, on-prem deployment means that data never crosses a network boundary to a third-party model API, removing a deemed-export question rather than requiring a compliance exception. **Framework:** ITAR / export control ### The AI layer is deployed inside the same network enclave and access controls that already scope CUI around LX, so it inherits the boundary instead of becoming a new system your assessor has to review separately. **Framework:** CMMC 2.0 / NIST SP 800-171 ### Manufacturers under contractual data-handling clauses from their own customers keep those commitments intact, since query and retrieval activity never leaves infrastructure you control. **Framework:** Customer data-handling flow-downs ### Because the AI layer reads LX through the same BOD and file-access paths as existing integrations, it fits inside your current IBM i change control and patch cadence rather than introducing a separate governance process. **Framework:** Internal change control ## Integration Notes Where ION is deployed, BODs handle structured reads and writes, reusing the same ION Workflow and BOD Mapper configuration already in place for other integrations rather than building a parallel path. Facilities that have not adopted ION are reached through direct, read-only DB2 for i file access, the same interface most existing LX reporting and BI tools already use. A read replica or a scheduled extract handles high-volume question-answering traffic so ad hoc queries never add load to the production IBM i partition during a shift. LX's facility, menu, and authority-level security is mirrored into the AI layer's access control so a user's answers are automatically scoped to what their LX sign-on already sees. Plant-specific RPG customizations and modified programs are mapped explicitly during discovery; anything not mapped is simply invisible to the assistant rather than guessed at. The connector layer is built to be version-aware across LX releases, since most long-running IBM i shops carry a mix of standard and customized programs that behave differently by version. ## Product Fit ### ERPray **Why:** ERPray's ERP-agnostic connector architecture reaches LX through BODs and IBM i file access, making it the direct fit for natural-language question answering, dashboards, and agents without a bespoke integration project. ### Custom build **Why:** Plants with heavy RPG customization or a need to combine LX data with MES, warehouse automation, or document systems typically extend the same on-prem architecture with a custom build. ## Engagement ### Discovery **Duration:** 2-3 weeks **Deliverables:** - Inventory of LX files, BODs, and RPG customizations in scope - Business glossary draft mapping LX terms to plain language - Shortlist of two to three pilot use cases ranked by volume and complexity ### Pilot **Duration:** 6-8 weeks **Deliverables:** - Working connector to LX BODs or IBM i files in a test environment - One to two use cases live with a defined planner or CSR group - Access control mirrored to LX facility and authority levels ### Production **Duration:** 4-6 weeks **Deliverables:** - Hardened deployment on production-grade hardware or private cloud - Audit logging and monitoring in place - Approval workflows configured for any write-back use cases ### Scale **Duration:** Ongoing **Deliverables:** - Additional use cases added from the discovery backlog - Rollout to additional facilities or business units - Periodic review of query logs to refine the semantic layer ## Buyer Questions - Does the connector use BODs and IBM i file access the way our existing integrations already do, or does it require a new access path into the partition? - Where does the model actually run, and does any LX data leave our network at any point in the pipeline? - How does the assistant respect our existing LX facility, menu, and authority-level security rather than creating a parallel permission model? - What does the audit log capture, and can our internal audit team read it directly? - What happens to accuracy when we modify an RPG program or add a plant-specific customization? - What is the ongoing cost of running this, including GPU hardware, not just the initial project fee? - Who owns the connector and semantic layer configuration after go-live, us or the vendor? ## Faq ### Can we add AI to LX without a CloudSuite migration? **Answer:** Yes. LX's data is reachable through BODs where ION is deployed, and through direct DB2 for i file access everywhere else, so a private AI layer connects the same way an existing integration or reporting tool would, with no requirement to move to a multi-tenant cloud first. ### Does this replace Infor's own AI roadmap for LX? **Answer:** It is a separate, self-hosted layer rather than a dependency on Infor's roadmap. Most of Infor's current generative AI messaging targets CloudSuite customers on its multi-tenant platform, which leaves a real gap for on-prem LX shops that a private layer fills directly. ### How does the assistant handle our RPG customizations? **Answer:** Customized programs and modified files are mapped explicitly during discovery so the assistant reflects what your specific LX installation actually does, including plant-specific fields, rather than a generic BPCS or LX baseline. ### What stops the AI from writing bad data into LX? **Answer:** Question-answering and search are read-only by default. Anything that would create or change a record, such as a purchase order follow-up, is drafted by the assistant but requires a person to review and approve it before it is keyed, the same as any other integration with write access. ### Do we need new hardware alongside our IBM i partition? **Answer:** Yes, typically a separate GPU server or workstation sits alongside the partition rather than running on it; sizing depends on concurrent users and query volume and is scoped during discovery rather than assumed up front. ### How long does a pilot take? **Answer:** A typical pilot runs six to eight weeks after a two to three week discovery phase, covering one or two use cases with a defined user group, enough to measure real accuracy and time savings before a production decision. ### Is this worth doing if we plan to replace LX eventually? **Answer:** Often yes, because the connector and use case work done now, mapping files, building the semantic layer, defining approval workflows, carries forward conceptually to whatever system replaces LX, and the AI value is not wasted while a replatforming project is still years out. ## Search terms Infor LX AI, Infor LX AI integration, BPCS AI integration, on-prem AI for Infor LX, Infor LX copilot, Infor LX generative AI, LX IBM i AI, Infor LX chatbot, Infor LX natural language query, AI agents for Infor LX, private LLM Infor LX, Infor LX MRP AI --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json