# How to add a private AI layer to Infor XA on-prem

> Source: https://netray.co/erp-help/private-ai-layer-infor-xa-on-prem-architecture
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: ERP Help

## Short answer

Infor XA keeps its data in Db2 for i on IBM i, so the safest way to add AI is a read-only reporting copy or logical-file access over JDBC or ODBC, a retrieval index over documents, a small tool server that exposes approved queries, and an open-weight model served on local GPUs. Nothing has to leave the building, and any write-back goes through the supported XA transaction programs after a person approves it.

## Kind

advanced

## System

infor-xa

## Erp

Infor XA (IBM i)

## Module

Private AI / Integration Architecture

## Query

how to add AI to Infor XA on-prem

## Alternate Queries

- Infor XA AI integration without cloud
- MAPICS XA chatbot on IBM i
- use a local LLM with XA data on AS/400

## Applies To

Infor XA (formerly MAPICS XA) on IBM i 7.3 and later; the pattern also holds for earlier releases with Db2 for i access.

## Steps

### Reference build for Infor XA

**Items:**

- Inventory the XA libraries, journaling status and IBM i level, and name the 20 to 40 tables behind your first use cases.
- Create read-only SQL views with business-friendly column names over those files, in a separate library.
- Stand up a replica or scheduled extract so production is never queried by the assistant.
- Build the data dictionary: file, field, meaning, units, code values, join keys.
- Deploy an open-weight model with vLLM or Ollama on local GPUs and a small tool server that exposes only parameterised, approved queries.
- Map each signed-in user to their XA profile, company and facility, and apply it to every query.
- Add an audit log of question, SQL run, rows returned and user, then pilot with 10 to 20 people.

## Sections

### Data access paths in Infor XA

**Body:**

XA stores business data in Db2 for i libraries, typically one library per environment with physical files, logical files and in many cases customer-added files. Any program that can speak SQL to Db2 for i can read it: the IBM i Access ODBC driver, the JTOpen (jt400) JDBC driver, or the Db2 for i catalog views in QSYS2. Because XA file and field names are short and coded, the first job is a data dictionary: use QSYS2.SYSTABLES and QSYS2.SYSCOLUMNS together with the XA database documentation for your release, and store the mapping as plain-language descriptions the model can use.

For integration beyond SQL, Infor XA has historically exposed business logic through RPG and CL programs, data queues and its own interfaces, and newer releases can connect to Infor ION. Whether ION is available depends on your release and licence, so confirm that before designing around BODs. For an assistant that only reads, SQL over views is simpler and more transparent than any messaging layer.

**Code:**

-- Discover candidate tables in the XA data library (Db2 for i catalog)
SELECT TABLE_SCHEMA, TABLE_NAME, TABLE_TYPE, TABLE_TEXT
FROM QSYS2.SYSTABLES
WHERE TABLE_SCHEMA = 'XADATA' AND TABLE_TYPE IN ('T','P','L','V')
ORDER BY TABLE_NAME;

-- Read recent journal entries for change capture (journaling must already be on)
SELECT ENTRY_TIMESTAMP, JOURNAL_CODE, JOURNAL_ENTRY_TYPE, OBJECT_NAME
FROM TABLE(QSYS2.DISPLAY_JOURNAL(
  JOURNAL_LIBRARY => 'XADATA', JOURNAL_NAME => 'XAJRN',
  STARTING_TIMESTAMP => CURRENT TIMESTAMP - 1 HOUR)) AS J
WHERE JOURNAL_CODE = 'R';

### Reference architecture, including the air-gapped option

**Body:**

A workable private AI layer for Infor XA has six parts. First, a read-only data path: Db2 for i views and journals over a replica or reporting copy so production is not queried. Second, a retrieval index over the documents and attachments people actually search, built with an open embedding model and stored in a vector database that runs on your servers. Third, a tool server, for example an MCP server, that exposes a short list of approved read actions with typed parameters. Fourth, an open-weight model served with vLLM or Ollama on local GPUs. Fifth, an identity layer that carries XA user profile, company and facility into every request. Sixth, an audit log of who asked what, which queries ran and which documents were retrieved.

The model never receives a database connection string. It asks the tool server to run a named action, and the tool server builds the parameterised query, applies the user's visibility filter and returns rows. This keeps free-form SQL generation out of production paths and makes every answer traceable to a query you can show the user. For an air-gapped site, all six parts run with no outbound route; model weights and updates arrive on approved media and are scanned and checked before use.

Run the assistant against a replica rather than the production partition. IBM i high-availability products and Db2 journal-based replication can keep a second partition or a separate IBM i in near-real-time sync; for lighter needs a nightly or hourly extract of the needed files into PostgreSQL is enough. Journal receivers are the natural change-data-capture source, but journaling has to be enabled on the files you care about and it has a disk and CPU cost.

### Permissions: the assistant must never show more than the user may see

**Body:**

XA security is a mix of IBM i object authority, user profiles and XA's own application and company-level security. The assistant should not run under one broad profile. Create a read-only service profile that has *USE authority only on approved views, then enforce per-user visibility in the tool server: map the signed-in person to their XA user, company or facility, and add that filter to every query. Db2 for i row and column access control (RCAC) can enforce the same rule inside the database as a second layer.

Cost, margin and customer-specific price columns should be excluded from the default view set and exposed only to roles that already see them in XA screens.

### Write-back only through supported interfaces

**Body:**

Do not let a model write to XA files. If drafts are useful (for example a purchase requisition or a customer order comment), have the assistant produce a structured draft, show it to the user, and post it only through the supported XA entry programs or interface files, under the user's own XA profile, after an explicit approval click. Log the draft, approver and posting result.

### Sizing, phased rollout and honest limits

**Body:**

Sizing depends on concurrency, not on headcount. A pilot of 10 to 20 users with a 7B to 14B class model can run on one workstation-class or datacentre GPU with 24 to 48 GB of memory. A site with 100 to 300 named users, of whom a third use it daily, often needs one to four GPUs depending on model size and answer length. Retrieval indexes for tens of thousands of documents are typically in the single to low double digit gigabytes. Use the sizing calculator for your own numbers and treat results as ranges.

Roll out in three phases. Phase one is read-only questions over a small set of views and documents, with every answer showing the query or sources. Phase two adds drafts, such as a summary, a message or a prepared transaction, that the user reviews but that nothing posts. Phase three adds approved actions through Infor XA's supported interfaces, always under the approving user's identity, with an audit record.

Field and file names in XA are terse, so answer quality depends heavily on the data dictionary you build. Expect the first weeks to be spent on that mapping, not on the model. Heavily customised environments with many user-defined files need more mapping time.

If your questions are already answered by existing XA inquiries, saved queries or an existing BI tool, a language model adds convenience, not capability. Free-form analytical questions over many joined files are where it helps. Very old operating system levels or tight CPU capacity on the production partition are good reasons to use a replica only.

## Pitfalls

- Pointing the model at raw physical files with cryptic names and expecting good answers.
- Running assistant queries on the production partition during month-end.
- Using one shared service profile that bypasses per-user company or facility limits.
- Forgetting that customer-added fields and files are not in the vendor documentation.
- Enabling journaling everywhere for change capture without sizing the disk impact first.

## Ai Angle

ERPray and Netray's custom build work follow this pattern: read-only by default, the query is shown to the user, Infor XA roles and visibility are respected, and everything runs on your hardware with open-weight models. Where a vendor's own AI or standard reporting already answers the question, we say so; the private layer earns its place for cross-system questions, document search and sites that cannot send data off premises.

## Faq

### Can we use ION with XA for this?

**Answer:** Possibly, depending on your release and licence. ION BODs suit event-driven integration and write-back. For a read-only assistant, SQL views over a replica are usually simpler and easier to audit, so treat ION as optional rather than required.

### Do we need to move off IBM i first?

**Answer:** No. The assistant sits beside IBM i and reads through ODBC or JDBC. The data stays in your Db2 for i libraries or in a replica you control, so there is no migration prerequisite.

### Which model size is realistic?

**Answer:** For structured question answering over views, 7B to 32B open-weight models are often enough. Larger models help with long document summarisation. Test on your own questions before buying GPUs.

### Is this air-gap capable?

**Answer:** Yes. Models, vector index, tool server and replica can all run with no outbound route. Model updates are then brought in on approved media and checked before use.

## Search terms

Infor XA AI integration, MAPICS XA AI, add AI to Infor XA on-prem, Infor XA Db2 for i JDBC, IBM i local LLM, AS/400 ERP chatbot, private AI IBM i ERP, Infor XA reporting replica, air-gapped AI ERP IBM i

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json