# AI for Infor XA on IBM i: On-Prem, No Replatforming Required > Source: https://netray.co/erp-ai/infor-xa-ai-integration > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: AI for ERP ## Short answer Infor XA still runs core manufacturing for a meaningful number of shops on IBM i, and none of them need to replatform to get value from AI. DB2 for i is a mature, well-understood database with SQL access, ODBC drivers, and years of tooling built around it, which is exactly what a retrieval-augmented question-answering system needs. The practical path is a connector that reads DB2 for i views on a schedule or via change data capture, paired with a model running on a small on-prem GPU server, so nothing about your XA environment has to change. ## Kind platform ## Erp Family infor ## Erp Products - Infor XA - Infor XA on IBM i ## Industries - Manufacturing - Discrete Manufacturing - Electronics ## Region United States ## Persona IT Director ## Eyebrow Infor XA on IBM i + on-prem AI ## Intro Infor XA on IBM i is one of the more durable ERP platforms in manufacturing, and one of the most frequently written off by vendors who assume everything has to move to a browser-based cloud product before it can be modernized. That assumption is wrong for AI specifically. DB2 for i supports standard SQL, has mature ODBC and JDBC drivers, and has been queryable by reporting tools for decades. A model that needs to answer 'which open orders reference this part' does not care whether the database sits on IBM i or SQL Server, it cares whether it can run a query against it. The real friction in XA shops is usually organizational, not technical: a small IT team that keeps the green-screen and its RPG customizations running reliably, understandably cautious about anything that touches the production LPAR. That caution is well placed for changes to XA itself. It does not need to extend to a read-only connector that pulls from DB2 for i into a separate AI system running on its own hardware, with no changes to XA's application code. For an IT director under pressure to show a modernization roadmap without a multi-year, multi-million-dollar replatforming project, AI grounded on the existing XA database is a credible interim step. It gives the business (planners, buyers, customer service) a faster way to get answers out of a system that is otherwise still running fine, and it buys time to make the ERP replacement decision deliberately instead of under deadline pressure from an unrelated AI mandate. It also produces something a future migration project will need anyway: a documented, queried, and validated map of what the XA schema actually contains and how the business uses it, which is exactly the kind of asset that makes a later migration to SyteLine, CloudSuite, or another platform cheaper and less risky. ## Pain Points ### Institutional knowledge is tied to the green screen **Detail:** The handful of people who know which XA screen and field to check for a given question are also the people closest to retirement. New hires take months to get comfortable navigating XA menus for routine lookups. ### IT is asked for AI with no replatform budget **Detail:** Leadership wants generative AI, but there is no appetite for a multi-year ERP replacement project right now. Vendor pitches that assume a cloud migration first do not fit the actual budget or timeline. ### Reporting is batch and after the fact **Detail:** Most reporting against DB2 for i runs overnight or on a fixed schedule. Questions that need a current answer, like today's late orders, mean someone running an RPG program or query manually. ### Custom RPG programs hold undocumented business logic **Detail:** Years of customization mean the 'real' rule for how a field is calculated lives inside an RPG program, not in any documentation, making it hard for anyone outside IT to trust a number without checking with a developer. ### Skills to maintain IBM i and RPG are shrinking **Detail:** The pool of people who can competently support DB2 for i and RPG customizations is smaller every year, which raises the stakes on anything that could disrupt the existing system. ## Use Cases ### Order and shipment status Q&A **Description:** Customer service asks about the status of a specific order, expected ship date, and whether anything is on hold, without opening XA screens. **Erp Objects:** Order header and line files, shipment and allocation files in DB2 for i **Outcome:** Cuts the time to answer a customer status call from a multi-screen XA lookup to an immediate, cited answer. ### Open purchase order and receipt tracking **Description:** A buyer asks which purchase orders are past due, which have partial receipts, and which vendors are consistently late. **Erp Objects:** Purchase order header/detail files, receiving transaction files **Outcome:** Surfaces the vendors and lines actually driving expedite work instead of a flat report the buyer has to scan manually. ### Inventory and item lookup **Description:** Planners ask on-hand quantity, allocated quantity, and where-used information for a part across warehouses. **Erp Objects:** Item master, inventory balance, and where-used files **Outcome:** Removes a step that used to require navigating three or four XA menus to assemble one answer. ### RPG business-rule documentation **Description:** An agent reads through RPG source (with IT oversight) and produces plain-language documentation of what a given program or calculation actually does. **Erp Objects:** RPG source members, copybooks, program documentation where it exists **Outcome:** Builds a documentation base for logic that previously existed only in code, reducing risk when the one developer who understands it is unavailable. ### Engineering change and BOM impact **Description:** Engineering asks which open jobs and orders reference a part or routing before making a change. **Erp Objects:** Bill of material and routing files, open order and job files **Outcome:** Reduces the chance a change goes out against the wrong revision because nobody checked what was still open against the old one. ### Demand and backlog summary for management **Description:** Operations leadership asks for a plain-language summary of backlog by product line or customer, without waiting for the weekly report cycle. **Erp Objects:** Order files, product/item classification files **Outcome:** Gives leadership a current answer between report cycles instead of working from data that is a week old. ### Vendor and quality history lookup **Description:** Quality asks about a vendor's rejection history for a specific part before approving a new lot. **Erp Objects:** Receiving inspection files, vendor master, nonconformance records if tracked in XA **Outcome:** Turns a lookup that used to require a developer or power user's help into a self-service answer for the quality team. ## Architecture **Overview:** The connector reads DB2 for i through SQL/ODBC or journal-based change data capture, without modifying XA's application layer. A semantic layer translates IBM i file and field names into plain business terms, and the model runs on a dedicated GPU server that never has to touch the IBM i LPAR directly. **Layers:** #### IBM i / DB2 for i connectors **Detail:** SQL access to DB2 for i physical and logical files via ODBC/JDBC, or journal-based change data capture for near-real-time updates without polling. #### Data and semantic layer **Detail:** A translation layer mapping cryptic IBM i file and field names to the business vocabulary planners, buyers, and customer service actually use. #### Model serving **Detail:** An open-weight model served with vLLM or Ollama on x86 GPU hardware separate from the IBM i LPAR, sized to concurrent user load. #### Retrieval and agents **Detail:** Retrieval-augmented generation for lookups and status questions, plus narrowly scoped agents for tasks like RPG documentation generation, reviewed by IT before publishing. #### Governance and audit **Detail:** Access checks against the requesting user's role, a query log for every answer, and no write access back into XA files by default. ## Deployment Options ### Air-gapped on-prem **Fit:** Shops running XA for defense, government, or otherwise sensitive manufacturing that do not want data leaving the building. **Detail:** GPU server and connector run inside your network, reading DB2 for i over your internal network with no outbound dependency. ### Private or sovereign cloud **Fit:** IT teams that want to avoid buying and racking new GPU hardware but still need control over where data and models run. **Detail:** The AI stack runs in a private tenancy while the connector reaches back to your on-prem IBM i over a site-to-site VPN or dedicated link. ### Hybrid **Fit:** Teams piloting on one department before committing budget, or wanting DR options separate from the primary IBM i environment. **Detail:** Core model serving stays close to the data for latency; ancillary functions like document indexing can run off the same network if convenient. ## Compliance ### For XA shops supplying the DoD, keeping the model and connector inside the same network boundary as the IBM i system avoids sending CUI-adjacent order and part data to an external API. **Framework:** CMMC 2.0 / DFARS 252.204-7012 ### Because the connector is read-only against DB2 for i by default, it does not introduce a new change-control burden on the validated XA application itself. **Framework:** Change control for regulated manufacturing ### Running the model on infrastructure you control keeps order, customer, and part data inside whatever jurisdiction your compliance requirements specify. **Framework:** Data residency ### Queries are scoped by the requesting user's existing role, so someone without visibility into a plant's data in XA does not gain it through the AI layer. **Framework:** Access control continuity ## Integration Notes DB2 for i is reachable via standard SQL over ODBC/JDBC; most read use cases do not require touching RPG programs at all. For fields whose real value depends on business logic buried in an RPG program (a calculated status, for example), plan a short discovery pass with a developer who knows the program before trusting the field. Journal-based change data capture (using IBM i journaling) gives near-real-time updates without repeated full-table polling, which matters for status questions that need to be current. Keep the AI stack on separate x86 GPU hardware; there is no need and generally no practical way to run model inference on the IBM i LPAR itself. Where XA has been customized, expect field and file names that diverge from stock documentation; budget discovery time to validate the semantic layer against a few known-answer questions before going live. Write-back is rarely worth the risk on XA; most pilots stay read-only, with any action items (an email, a documentation draft) handled outside the IBM i system entirely. ## Product Fit ### ERPray **Why:** Grounded question answering over XA's order, inventory, and purchasing data through DB2 for i is a direct fit, with the underlying SQL shown for every answer. ### Custom build **Why:** RPG documentation generation and other IBM-i-specific tasks are specialized enough to warrant a purpose-built agent rather than a general-purpose chat interface. ## Engagement ### Discovery **Duration:** 2-3 weeks **Deliverables:** - Review of DB2 for i schema, key files, and any relevant RPG customizations - Assessment of ODBC/JDBC access and change data capture options - Shortlist of pilot use cases, typically order status and inventory lookup first - Hosting decision: air-gapped, private cloud, or hybrid ### Pilot **Duration:** 6-8 weeks **Deliverables:** - Working connector and semantic layer for the pilot use cases - Model serving stood up on dedicated GPU hardware - Pilot group of customer service, planning, or buying staff using it against live data - Accuracy review against a set of known-answer questions drawn from real XA lookups ### Production **Duration:** 4-6 weeks **Deliverables:** - Access control and audit logging hardened for production use - Rollout to the broader team beyond the pilot group - Documentation of the semantic layer handed to your IT team - Runbook for monitoring and incident response ### Scale **Duration:** Ongoing **Deliverables:** - Additional use cases (RPG documentation, engineering change impact) added from the backlog - Periodic review of open-weight model options as they improve - Optional extension into a future migration-readiness assessment if a replatform is eventually planned ## Buyer Questions - Does this require any change to our IBM i LPAR, RPG programs, or XA application code? - How does the connector read DB2 for i: direct SQL, journal-based change capture, or something else? - Can you show me the exact SQL behind an answer, not just the generated text? - What happens to data in transit between the IBM i system and the GPU server? - Do you require us to migrate off XA or onto a cloud platform before this works? - How is access scoped to match what a given user can already see in XA? - What is the ongoing cost to run this once the pilot ends, in hardware and support? - Can your team read and document RPG, or does that require our own developer's involvement throughout? ## Faq ### Do we need to move off Infor XA or IBM i to use AI? **Answer:** No. DB2 for i is a standard SQL-accessible database, and AI can be built to read it directly through ODBC/JDBC or journal-based change capture, with no changes to XA itself or the IBM i platform. Replatforming is a separate decision that is not a prerequisite for adding AI. ### Is IBM i too old a platform for modern AI tooling? **Answer:** No. The database layer (DB2 for i) has decades of mature SQL tooling built around it. The AI model itself runs on separate x86 GPU hardware, so the age of the IBM i platform is not a limiting factor for model performance, only for how the connector reads data out of it. ### How do you handle business logic that lives inside RPG programs rather than the database? **Answer:** For fields whose true value depends on RPG calculations rather than a straightforward column, we work with your developer during discovery to either replicate the logic in the semantic layer or have the agent read the RPG source directly to document and validate the rule before it is trusted. ### Will this disrupt our production IBM i environment? **Answer:** The connector is read-only against DB2 for i in the vast majority of deployments, running from separate hardware and querying on a schedule or via journal capture. It does not modify XA's application code, database structures, or the IBM i LPAR configuration. ### What is a realistic first use case for an XA shop? **Answer:** Order and shipment status lookup for customer service, and inventory or purchase order status for planners and buyers, are the most common starting points. Both are read-only, self-contained within a small set of DB2 for i files, and produce a daily time saving that is easy to measure. ### Does this help if we eventually plan to migrate off XA? **Answer:** Yes, indirectly. Building the semantic layer to answer questions accurately requires documenting what the XA schema actually contains and how fields are really used, which is exactly the kind of discovery work a future migration project needs, so it is not wasted effort either way. ### Can this run fully on-prem for a defense-adjacent XA shop? **Answer:** Yes. The model, connector, and application can run entirely inside your network on hardware you control, with DB2 for i accessed over your internal network and no outbound API dependency required for normal operation. ## Search terms Infor XA AI, Infor XA AI integration, on-prem AI for Infor XA, Infor XA copilot, Infor XA generative AI, AI for IBM i ERP, AS/400 ERP AI, DB2 for i AI integration, Infor XA natural language query, IBM i AI without migration, Infor XA modernization AI, legacy ERP AI IBM i, private LLM Infor XA, Infor XA RPG documentation AI --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json