# Private AI Layer for SyteLine On-Prem: Reference Architecture > Source: https://netray.co/erp-help/private-ai-layer-syteline-on-prem-architecture > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer To add AI to SyteLine without moving data to a cloud, keep SQL Server and the Mongoose application tier where they are, expose a read-only reporting copy and approved IDO calls to a tool server, and serve an open-weight model with vLLM or Ollama on local GPUs. Mirror SyteLine user groups and site access in the tool server, log every prompt and query, and send any write-back through IDO methods with human approval. ## Kind advanced ## System syteline ## Erp Infor SyteLine (CloudSuite Industrial) on-prem ## Module AI integration / Mongoose IDOs and SQL Server ## Query how to add AI to SyteLine on-prem ## Alternate Queries - SyteLine AI integration without cloud - private LLM for Infor SyteLine on SQL Server - SyteLine IDO REST API for AI assistant - CloudSuite Industrial on-prem chatbot ## Applies To Infor SyteLine 8.x and CloudSuite Industrial 9.x/10.x on-premises, SQL Server back end, Mongoose application framework ## Steps ### How to build a private AI layer on SyteLine **Items:** - Inventory the data the assistant needs: items, customer orders, jobs, POs, inventory, plus attached documents such as drawings, certs and work instructions. - Stand up a read-only path: an AlwaysOn secondary or a log-shipped reporting copy of the SyteLine databases, plus a service account with SELECT only. - Decide per question type whether to read through IDOs (permission-aware, business logic applied) or through SQL views on the reporting copy (faster for aggregates). - Build a retrieval index over documents and attachments with a local embedding model and a vector store inside the same network zone. - Expose approved read actions through an MCP or tool server; every tool maps to one named IDO load or one parameterised query, never free SQL. - Serve an open-weight model (Qwen, Llama, Mistral or gpt-oss class) with vLLM or Ollama on local GPUs, behind the tool server and an audit log. - Roll out in three phases: read-only questions, then drafts (PO notes, NCR text, quote emails), then approved actions through IDO methods. ## Sections ### Data access paths in SyteLine **Body:** SyteLine stores data in SQL Server. Multi-site installations use tables with an _mst suffix (for example item_mst, coitem_mst, co_mst, job_mst, po_mst) carrying a site_ref column, and views without the suffix that filter to the current site context. Querying the base tables directly bypasses that site filtering, so a reporting copy needs its own site rules. The supported programmatic layer is the Mongoose IDO (Intelligent Data Object). IDOs wrap tables with business logic, calculated properties and user permissions. They are reachable through the IDO request service over REST and SOAP, and through the ION API gateway when Infor OS is installed. For an AI layer, IDOs are the safest read path for single-record and short-list questions; SQL on a reporting copy is better for aggregates and trend questions. Attachments live in Mongoose document objects linked to records, and many plants also keep drawings and certs on file shares. Index both. **Code:** -- Reporting copy, read-only service account, one site SELECT TOP 50 i.item, i.description, i.u_m, i.unit_cost FROM dbo.item AS i WHERE i.stat = 'A' ORDER BY i.item; GET /IDORequestService/ido/load/SLItems?properties=Item,Description,UnitCost&filter=Item%20LIKE%20'BRK%25'&rowcap=50 Authorization: -- Verify the IDO name and property names in your IDO metadata before use. ### Reference architecture **Body:** Put five components inside the plant network: a reporting replica of the SyteLine databases, a document index, a tool server, a model server and an audit store. The tool server is the only component that talks to SyteLine; the model never receives credentials and never builds SQL against production. Change data capture or scheduled extracts keep the document index and any denormalised search tables fresh. For an air-gapped site, load model weights, container images and Python wheels through a controlled transfer station and pin versions; nothing in the runtime path needs internet access. Typical models for this workload are 8B to 32B open-weight models for question answering, plus a small embedding model. Larger models help on multi-step analysis but are not required for lookups. ### Permissions, sites and write-back **Body:** SyteLine authorisation is built on Mongoose user groups, form and IDO method permissions, and site access. The assistant must act as the asking user: authenticate the user through your identity provider, map them to their SyteLine user, and call IDOs with that identity, or filter reporting-copy queries by the same site and group rules. A shared service account that sees everything is the failure to avoid. Write-back should go only through supported IDO methods or Infor-documented APIs, never UPDATE statements. Keep the assistant to drafts first: a proposed PO change, a drafted NCR, a quote. A named user approves in the SyteLine form or in a confirmation step that calls the IDO as that user. ### Sizing, limits and when not to bother **Body:** For 100 to 500 named users with 10 to 25 percent active per day, one to two inference GPUs in the 24 to 80 GB class usually cover peak load for a 8B to 32B model; a second node adds redundancy. The index for 100,000 to 1,000,000 document pages is typically tens of GB, not hundreds. Use the sizing calculator for your own numbers. Limits: heavily customised schemas and user-defined fields need mapping work; older SyteLine 8.x builds may lack newer REST behaviour; calculated figures such as MRP results and costing roll-ups should come from IDO or reports, not be re-derived by the model. If you only need standard reports in natural language, Infor's own tooling on Infor OS may be enough. ## Pitfalls - Querying _mst tables as a super user and returning rows from sites the asker cannot access. - Letting the model write SQL against production instead of calling named, parameterised tools. - Indexing attachments without carrying the record-level permissions into the index metadata. - Re-deriving costs or MRP results in the model instead of reading the system of record. - Writing back with direct UPDATE statements that skip IDO business rules and audit trails. ## Ai Angle SyteRay and ERPray are built for this pattern on SyteLine: they read through IDOs and a reporting copy, show the query behind each answer, respect SyteLine roles and sites, and run on your own GPUs. Write actions stay behind human approval and IDO methods. ## Faq ### Can SyteLine AI run fully on-prem? **Answer:** Yes. SQL Server, the Mongoose tier, the retrieval index and an open-weight model served by vLLM or Ollama can all sit on your network, including air-gapped, with model weights loaded through a transfer process. ### Should the AI read IDOs or SQL? **Answer:** Use IDOs for permission-aware record lookups and anything with business logic, and a read-only SQL reporting copy for aggregates. Both go through a tool server so the model never holds credentials. ### Does it need CloudSuite Industrial? **Answer:** No. On-prem SyteLine 8.x and CSI on your own servers work. Check which REST and ION features your build exposes; the SQL reporting-copy path works regardless. ### How do I stop it showing other sites' data? **Answer:** Apply the asker's SyteLine user groups and site list in the tool server, and filter reporting-copy queries by site_ref, so retrieval is scoped before the model sees any text. ## Search terms SyteLine AI integration, SyteLine on-prem AI, CloudSuite Industrial private LLM, SyteLine IDO REST, SyteLine chatbot, SyteLine SQL Server reporting copy, private AI SyteLine air-gapped, SyteLine MCP server --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json