InforERP Platform

Infor LX + AI

AI for Infor LX: A Private Layer on Top of Your IBM i Investment

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.

ERP: Infor LX, Infor LX CloudSuite
Industries: Manufacturing, Food and Beverage, Industrial Equipment, Chemicals
Written for: IT Director

Discuss your Infor LX environment See use cases

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.

What usually gets in the way

The problems we hear most from it director teams running Infor LX.

RPG and 5250 knowledge is concentrated in a shrinking group

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

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

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

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

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.

Where AI earns its place in Infor LX

Each use case names the ERP objects it reads or writes, so your ERP team can judge the integration effort before anyone commits budget.

Order and shipment status in plain English

CSRs and sales staff ask about order status, ship dates, and open quantities without navigating LX order entry and inventory inquiry screens.

Touches: 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

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.

Touches: 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

Warehouse and quality staff check on-hand, allocated, and lot-traceable quantities across multiple facilities without learning facility-specific inquiry screens.

Touches: 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

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.

Touches: 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

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.

Touches: 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

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.

Touches: 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

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.

Touches: BOD publish and subscribe logs, ION workflow history

Outcome: Cuts the number of integration-tracing tickets that land on a stretched IBM i team.

Reference architecture

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.

1
ERP connectors
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.
2
Data and semantic layer
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.
3
Model serving
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.
4
Retrieval and agents
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.
5
Governance and audit
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.

Integration notes for your ERP team

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.

Deployment options

Air-gapped on-prem

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.

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

Organizations running LX on a hosted or managed IBM i environment and comfortable keeping the AI workload in that same private tenancy.

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

Multi-plant organizations with LX on-prem at some sites and other Infor products or a future CloudSuite plan for others.

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 and data control

How the architecture supports your obligations. Certification and accountability stay with your organisation; the design keeps the evidence straightforward.

ITAR / export control

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.

CMMC 2.0 / NIST SP 800-171

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.

Customer data-handling flow-downs

Manufacturers under contractual data-handling clauses from their own customers keep those commitments intact, since query and retrieval activity never leaves infrastructure you control.

Internal change control

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.

Where Netray fits

ERPray

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

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.

How an engagement runs

Phase 1 . 2-3 weeks

Discovery

-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

Phase 2 . 6-8 weeks

Pilot

-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

Phase 3 . 4-6 weeks

Production

-Hardened deployment on production-grade hardware or private cloud
-Audit logging and monitoring in place
-Approval workflows configured for any write-back use cases

Phase 4 . Ongoing

Scale

-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

Questions to ask any vendor, including us

A short list that separates real Infor LX AI work from a chatbot demo.

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?

Frequently asked questions

Can we add AI to LX without a CloudSuite migration?

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?

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?

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?

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?

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?

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?

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.

Related guides

Infor SyteLine / CSI + AI

AI for Infor SyteLine and CloudSuite Industrial

Add grounded AI to Infor SyteLine or CloudSuite Industrial: natural-language answers, agents over IDOs and ION, on-prem or CloudSuite deployment.

Baan legacy + on-prem AI

AI for Legacy Baan IV/V: Capture the Knowledge Before It Walks Out the Door

Use AI to capture knowledge from ageing Baan IV/V systems, document undocumented customisations, and de-risk a future migration to LN or CloudSuite.

Infor OS + on-prem AI agents

AI Agents Over Infor ION API, BODs, and the Infor Data Lake

Build AI agents on Infor ION API Gateway, BODs, and Data Lake, alongside or instead of Infor's own GenAI features, with your choice of model and hosting.

Agents + approval gates

AI Agents for ERP, Running On-Prem

A practical guide to on-prem AI agents for ERP: what they can safely automate, where human approval belongs, and how to design the guardrails.

Ask your ERP anything

Natural Language Query for ERP Data: Ask SAP, Infor, or Oracle a Question in Plain English

See how natural language query over SAP, Infor, Oracle, and NetSuite data works: grounded text-to-SQL, role-based permissions, and a visible audit trail.

CSI, kept on-prem

On-Prem AI for CloudSuite Industrial, Without the Multi-Tenant Cloud Move

Add generative AI to CloudSuite Industrial without moving to Infor's multi-tenant cloud. On-prem private LLM options for CSI, with governance and audit built in.

Plan it with numbers

Free Tool

Talk it through with an engineer who knows Infor LX

Bring one real question your team cannot answer from the ERP today. We will map the data path, the model, and where it runs, and tell you honestly if AI is the wrong tool for it.

Start the conversation See ERPray

All AI for ERP guides