# How to Add AI to MAPICS and Infor XA on IBM i Without Leaving Your Network

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

## Short answer

MAPICS and Infor XA keep their data in DB2 for i, which is readable over standard SQL through ODBC or JDBC. Capture changes from journals, copy them to a reporting database on x86, run the model on a separate GPU server, and the Power system stays untouched. Writes still go through the application's own programs.

## Kind

advanced

## System

infor-xa

## Erp

Infor XA / MAPICS on IBM i

## Module

DB2 for i data access / AI architecture

## Query

how to add AI to MAPICS XA on IBM i

## Alternate Queries

- Infor XA AI integration on-prem
- MAPICS IBM i ChatGPT alternative
- AS/400 ERP AI assistant DB2 for i
- private LLM for IBM i ERP

## Applies To

MAPICS XA and Infor XA on IBM i 7.3 or later. Exact file names and modules vary by release, so use your own data dictionary.

## Steps

### Reference build for a private AI layer on IBM i

**Items:**

- Inventory the XA libraries and the files behind the questions people ask (items, customer orders, purchase orders, MRP, work orders). Use the Infor XA data dictionary documentation and QSYS2.SYSTABLES to confirm names and descriptions.
- Decide the data path: read the IBM i directly with a read-only user over JDBC for low volume, or replicate to a reporting database on x86 for heavier use. Replication is the safer default.
- For replication, use journaling on the key files and a change-capture tool, or a scheduled extract, to feed a PostgreSQL or SQL Server reporting copy.
- Create a dedicated IBM i user profile with object authority limited to the files you approve, and use SQL GRANT or row and column access control for finer limits.
- Build views over the reporting copy with business names and fixed filters, and index related documents (drawings, POs, quality records) with the XA item or order number as metadata.
- Expose approved read actions through an MCP or REST tool server. Do not allow free-form SQL against base files.
- Serve an open-weight model with vLLM or Ollama on an x86 GPU server. The IBM i is not asked to run inference.
- Log every question and tool call, and review the log with the IBM i security administrator.

## Sections

### How XA data is reached on IBM i

**Body:**

XA business data lives in physical files in libraries on DB2 for i, and DB2 for i exposes them to SQL. Tools such as IBM i Access ODBC and the JTOpen JDBC driver connect from x86 servers, and the QSYS2 catalog views list tables, columns and text descriptions so you can discover what a library holds. File names in XA are short and release specific, so do not assume names from other ERPs.

The application's behaviour sits in RPG and CL programs. Reading files bypasses that logic, which is acceptable for questions but not for updates: posting an order or receipt directly into a file skips validation and corrupts planning data. Writes should call the application's own interfaces.

Infor offers integration options for XA depending on release and licence, such as ION connectors; check what your contract covers.

**Code:**

-- Discover tables and their text in a library (DB2 for i catalog)
SELECT table_schema, table_name, table_text
FROM qsys2.systables
WHERE table_schema = 'XALIB'
ORDER BY table_name;

-- JTOpen JDBC URL (read-only user)
-- jdbc:as400://ibmi-host;libraries=XALIB;naming=sql;access=read only

### Change capture, replica and model placement

**Body:**

Journaling is the natural change-capture mechanism on IBM i. If the key files are journaled, receivers record every insert, update and delete, and the QSYS2.DISPLAY_JOURNAL table function lets a reader consume those entries. A capture job applies them to a reporting database on x86, keeping the production partition free of analytical load.

Put the vector index, tool server and GPU model host on the x86 side, in the same network zone as the replica. Power hardware then sees only a modest stream of journal reads.

For an air-gapped plant, the whole chain stays inside the enclave and model files arrive on controlled media.

### Permissions and write-back

**Body:**

IBM i security is object based. A user profile needs authority to each file, and adopted authority in programs can grant more access than the profile alone. Build the AI service profile with the least authority that serves the approved views, and map each person's XA role to the assistant session so tool calls filter by what that person may see.

DB2 for i row and column access control, available in current releases, can mask cost fields or restrict by site on the source, and the replica should carry the same labels.

Write-back is the sensitive step. Create drafts first, then submit through the application's supported programs or ION flows with a named approver, never by writing to files.

### Sizing, rollout and limits

**Body:**

User counts for XA sites are often a few hundred named users with a minority active daily. The load is light for one or two GPUs; the extra effort goes into mapping files and descriptions.

Phase 1: read-only questions over items, orders, MRP and stock. Phase 2: drafts and summaries. Phase 3: approved actions through supported routes.

Limits: terse file and field names need a curated glossary before a model can use them well; customisations require mapping; and if the real goal is a screen refresh or a migration to a newer platform, an assistant will not replace that. It does let people ask questions today without waiting for a migration.

## Pitfalls

- Letting the model query base files directly instead of curated views with a glossary of terse XA field names.
- Running analytical SQL on the production partition and slowing batch jobs.
- Relying on a service profile with broad authority or adopted authority paths.
- Writing straight into files, which bypasses RPG business logic.
- Forgetting that the replica must carry the same site or role limits as the source.
- Leaving journaling off on files you need for change capture.

## Ai Angle

ERPray can read the replica and answer questions such as which purchase orders are late for a critical item, showing the SQL and respecting mapped roles. Netray builds the journal-based feed, retrieval index and local model serving, while your IBM i administrators and XA consultants own authority and data meaning.

## Faq

### Can we add AI to MAPICS or Infor XA without moving to the cloud?

**Answer:** Yes. DB2 for i is queryable over SQL, so a replica, retrieval index and open-weight model can run on x86 servers inside your network. The IBM i continues to run the ERP and is not asked to host the model.

### Does the model run on the IBM i?

**Answer:** No. Inference runs on a separate x86 GPU server. The IBM i supplies data through JDBC reads or a journal-fed replica, which keeps ERP performance predictable.

### How do we stop the assistant from corrupting data?

**Answer:** Keep it read-only first. Later, any change goes through the application's supported programs or integration flows as a draft a person approves, never by writing to the files directly.

### What if our file names are cryptic?

**Answer:** That is common in XA. Build a glossary from the data dictionary and file descriptions, wrap tables in views with readable names, and let the tool layer, not the model, decide which tables to touch.

## Search terms

MAPICS AI, Infor XA AI integration, IBM i ERP AI, DB2 for i LLM, AS/400 ERP chatbot, MAPICS XA on-prem AI, private AI IBM i, JDBC DB2 for i AI assistant

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