# Private AI Layer for Infor M3 On-Prem: Reference Architecture > Source: https://netray.co/erp-help/private-ai-layer-infor-m3-on-prem-architecture > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer For Infor M3 on-prem, use the M3 API (MI programs) for permission-aware record access, a read-only reporting copy of the M3 database for aggregates, a local retrieval index for documents, and an open-weight model on your own GPUs. Mirror M3 users, companies, divisions and warehouse authorities in the tool server and send writes only through MI programs with human approval. ## Kind advanced ## System infor-m3 ## Erp Infor M3 on-prem ## Module AI integration / M3 API and MI programs ## Query how to add AI to Infor M3 on-prem ## Alternate Queries - Infor M3 AI integration without cloud - M3 API MI programs AI assistant - private LLM for Infor M3 DB2 IBM i - Infor M3 MITMAS read-only AI ## Applies To Infor M3 on-premises (Business Engine on IBM i/DB2, Oracle or SQL Server) with M3 API (MI programs) and Infor ION ## Steps ### How to build a private AI layer on Infor M3 **Items:** - List the M3 companies, divisions, facilities and warehouses in scope and the target questions. - Identify the MI programs that return the data (for example MMS200MI for items, OIS100MI for customer orders, PPS200MI for purchase orders) and confirm access with your M3 admin. - Stand up a read-only reporting copy of selected M3 tables for aggregates and history. - Index documents, drawings and attachments locally with company and ACL metadata. - Expose named read actions through an MCP or tool server mapping to specific MI transactions or parameterised queries. - Serve an open-weight model on local GPUs and log every prompt, tool call and answer. - Phase the rollout: read-only questions, drafts, then approved actions through MI programs. ## Sections ### Data access paths in M3 **Body:** M3 data sits in the Business Engine database: DB2 for i on IBM i installations, or SQL Server or Oracle elsewhere. Tables use five-letter names such as MITMAS for item master, MITBAL for item balances by warehouse, OOHEAD and OOLINE for customer orders, MPHEAD and MPLINE for purchase orders, MWOHED for manufacturing orders, with the company number (CONO) as the first key field. The supported programmatic layer is the M3 API: MI programs (for example MMS200MI with transaction GetItmBasic) called over REST, usually through the ION API gateway, or directly on the M3 API endpoint. MI programs apply M3 business rules and authorities, so they suit record lookups and write-back. A reporting copy is better for aggregates and history. Documents attach through M3 document management and often live on file shares and in other systems; index them separately. **Code:** - GET /M3/m3api-rest/execute/MMS200MI/GetItmBasic?ITNO=BRK-1001 Authorization: Bearer -- Verify the endpoint path and required fields for your M3 and ION configuration. - SELECT MMITNO, MMITDS, MMSTAT FROM MITMAS WHERE MMCONO = 100 AND MMSTAT = '20'; -- Library or schema name depends on your installation. ### Reference architecture **Body:** Inside your network run: a reporting copy of selected M3 tables, a document index, a tool server, a model server and an audit store. Credentials stay in the tool server; the model only sees tool results. On IBM i, a journal-based replication or scheduled copy to a Linux or Windows reporting database keeps the Power system load low. If you use ION, keep the gateway inside the boundary; air-gapped sites need local identity and no external callbacks. A 8B to 32B open-weight model is enough for lookups and summaries; keep vLLM or Ollama on a separate GPU host rather than on the M3 server. ### Permissions and write-back **Body:** M3 authorisation is granular: users and roles get authority to programs, and data authority by company, division, facility and warehouse. Reproduce that: authenticate the user through your identity provider, call MI programs with that user's identity where possible, and filter reporting-copy queries by the same company, division and warehouse lists. Write-back: use MI programs such as order or purchase change transactions only after a named user approves a drafted action. Keep the assistant out of direct database writes. ### Sizing, limits and honest caveats **Body:** For a few hundred named users with 10 to 25 percent daily activity, one to two inference GPUs typically cover peak. Document indexes of 100,000 to 1,000,000 pages usually sit in the tens of GB. Limits: MI programs return field codes that need reference-data lookups to read well; transaction names and fields vary by version, so test each; heavy aggregate questions need the reporting copy, not repeated API calls. If Infor's own M3 analytics already answer your questions, add an LLM only where natural language or documents are the gap. ## Pitfalls - Calling MI programs in loops for aggregate questions instead of using a reporting copy. - Ignoring company, division and warehouse authority and returning cross-division data. - Showing raw codes without joining the reference data that explains them. - Hard-coding MI transaction names without checking the version. - Pointing the model server at the Business Engine host and starving it. ## Ai Angle ERPray already targets Infor M3: it reads through the M3 API and a reporting copy, shows the call or query behind each answer, honours M3 roles, and runs on your own GPUs. Write actions stay drafts until a user approves them. ## Faq ### Can M3 AI run on-prem only? **Answer:** Yes. The M3 API, a reporting database copy, a document index and an open-weight model can all stay inside your network. ION can also be on-prem. ### Do I use MI programs or SQL? **Answer:** MI programs for record lookups, business rules and writes; SQL on a reporting copy for aggregates and history. Both sit behind a tool server. ### How does M3 authority carry over? **Answer:** Map users to M3 users and their company, division, facility and warehouse authority in the tool server and apply it to both API calls and retrieval. ### Is IBM i a problem? **Answer:** No, but keep the model on separate GPU hardware and replicate data off the Power system for reporting to protect production performance. ## Search terms Infor M3 AI integration, M3 API AI assistant, M3 on-prem private LLM, MI programs REST, Infor M3 MITMAS, M3 IBM i AI, Infor M3 chatbot, M3 MCP server --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json