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

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.

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.

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.