# Private AI Layer for Infor LN On-Prem: Reference Architecture > Source: https://netray.co/erp-help/private-ai-layer-infor-ln-on-prem-architecture > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer For Infor LN on-prem, read through a reporting copy of the LN database and approved ION API or BOD-based calls, run retrieval over documents and attachments locally, and serve an open-weight model on your own GPUs. Map LN authorisations and companies into the tool server, log everything, and write back only through LN's supported interfaces with human approval. ## Kind advanced ## System infor-ln ## Erp Infor LN on-prem ## Module AI integration / BODs, ION and LN DLLs ## Query how to add AI to Infor LN on-prem ## Alternate Queries - Infor LN AI integration without cloud - private LLM for Infor LN Oracle database - Infor LN BOD ION API AI assistant - LN tables tdsls400 read-only AI ## Applies To Infor LN 10.x on-premises with Oracle or SQL Server (or DB2) and ION; LN UI and the LN bshell/DLL tier ## Steps ### How to build a private AI layer on Infor LN **Items:** - List the LN packages and companies in scope (for example sales, purchase, manufacturing, warehousing) and the documents to index. - Create a read-only reporting copy of the LN database and a service account limited to the tables you approve. - Decide which questions use ION API and BODs (supported, permission-aware) and which use SQL on the copy (aggregates and history). - Index documents and attachments with a local embedding model, carrying company and ACL metadata. - Expose named read actions through an MCP or tool server; no free-form SQL from the model. - Serve an open-weight model with vLLM or Ollama on local GPUs and log every prompt, tool call and answer. - Phase the rollout: read-only questions, drafts, then approved actions through LN's supported APIs. ## Sections ### Data access paths in LN **Body:** LN tables follow a package, module and number naming scheme: tcibd001 holds general item data, tdsls400 and tdsls401 sales order headers and lines, tdpur400 and tdpur401 purchase orders, tisfc001 production orders. In the database, the company number is appended to the table name (so tdsls400100 for company 100), and column names carry a t_ or t$ prefix depending on the database driver. Check the data dictionary on your system before writing queries. The supported integration layer is Infor ION: BODs (Business Object Documents) published and consumed through ION, and the ION API gateway for REST calls. Inside LN, 3GL libraries (DLLs) and Application Function Server style interfaces run business logic; these are suited to write-back and to calling standard functions rather than reimplementing them. Use SQL on a reporting copy for history and aggregates, ION API or BODs for record-level and permission-aware access. **Code:** -- Reporting copy, read-only, company 100 (verify table and column names in your data dictionary) SELECT t_orno, t_cuno, t_odat FROM tdsls400100 WHERE t_odat > SYSDATE - 30 ORDER BY t_odat DESC; GET https://ion-gateway.example.local//LN/?$filter=... Authorization: Bearer -- Service paths depend on the ION API services you publish for LN. ### Reference architecture **Body:** Keep five components on your network: the reporting database copy, a document and attachment index, a tool server, a model server and an audit store. The tool server is the only path to LN data; credentials never reach the model. BOD flows can also feed the index: subscribe a listener to the documents you care about (for example item or order BODs) so retrieval stays fresh without hammering production. Air-gapped sites load images and weights through a transfer station and run ION inside the boundary. Open-weight models in the 8B to 32B range cover question answering over orders, purchasing and production; add a reranker if your documents are long and technical. ### Permissions and write-back **Body:** LN has its own user and role authorisation by session and table, and data is partitioned by company. Authenticate users through your identity provider, map them to LN users, and enforce company and role filters in the tool server. For ION API calls use the user's identity or a delegated token, not one all-seeing account. Write-back goes through supported APIs only: BOD-driven integrations, ION API services or LN's standard business functions. Never UPDATE tables. Let the assistant prepare a purchase requisition or a drafted change, and have a named user approve it. ### Sizing, limits and honest caveats **Body:** For a few hundred named users with 10 to 25 percent daily activity, one to two inference GPUs usually suffice, with a second node for redundancy. Document indexes for 100,000 to 1,000,000 pages normally land in the tens of GB. Limits: LN's customisations and extensions vary by site and version; table and field names must be taken from your own data dictionary; and the reporting copy must respect company partitioning. For standard BI questions, Infor's own analytics may be enough before you add an LLM. ## Pitfalls - Hard-coding table names without the company suffix or without checking the data dictionary. - Using one super-user connection so every employee sees every company. - Treating a BOD as a query interface: BODs are for document flow, use ION API or SQL copy for lookups. - Letting the model write to LN tables directly. - Ignoring custom tables and domains that carry the data users actually ask about. ## Ai Angle ERPray connects to LN through a read-only copy and ION-based access, shows the query it ran, honours LN roles and companies, and can run on your own GPUs. Any write action is a draft that a user approves. ## Faq ### Can Infor LN AI work without cloud? **Answer:** Yes. A reporting copy, local retrieval index and an open-weight model on your GPUs can all run on-prem. ION must be available if you use BOD or ION API paths; it can also be inside your network. ### Should I query LN tables directly? **Answer:** Only on a read-only reporting copy and only for aggregates and history. Use ION API for permission-aware record access and keep the model behind a tool server. ### How do companies and authorisations carry over? **Answer:** Map each user to an LN user and company list in the tool server, and filter both SQL and retrieval by those values before any text reaches the model. ### What about writing to LN? **Answer:** Use BODs, ION API services or standard LN business functions with human approval. Direct table updates skip business logic and audit. ## Search terms Infor LN AI integration, Infor LN on-prem AI, LN BOD ION API, Infor LN private LLM, Infor LN tdsls400, Infor LN chatbot, Infor LN air-gapped AI, Infor LN MCP server --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json