# Adding a Private AI Layer to Business Central On-Premises > Source: https://netray.co/erp-help/private-ai-layer-business-central-on-prem-architecture > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer Business Central on-premises has a clean, supported read path: API v2.0, custom API pages written in AL, and OData web services, all enforcing the calling user's permissions. Put a tool server on top of those, add a retrieval index and an open-weight model on your own GPUs, and keep write-back behind human approval and the same APIs. ## Kind advanced ## System dynamics ## Erp Microsoft Dynamics 365 Business Central (on-premises) ## Module API v2.0 / OData / AL / Permissions ## Query how to add AI to Business Central on-premises ## Alternate Queries - Business Central on-prem AI without cloud - Business Central on-premises local LLM - Business Central API v2.0 chatbot private - Business Central on-prem Copilot alternative ## Applies To Business Central on-premises (versions 14 and later, wave releases) with the Business Central Server instance reachable from the tool server ## Steps ### How to stand up a private AI layer on Business Central **Items:** - Decide the first questions: item availability, open sales and purchase lines, customer and vendor ledger balances, production orders, approvals. - Choose the access path per question: API v2.0 for standard entities, a custom API page in AL for anything missing, and a SQL replica only for broad aggregates. - Configure authentication on the server instance and create a service identity with a minimal permission set, or delegate the user's identity from the tool server. - Publish the web services or API pages you need and test with a low-privilege user to confirm the permission behaviour. - Index attachments, item and customer notes and external documents in a local retrieval store; refresh incrementally using modified-at filters. - Wrap the endpoints in a tool server (MCP) with parameter validation, row limits and an audit log. - Serve an open-weight model with vLLM or Ollama on local GPUs and pilot read-only questions before drafts. ## Sections ### Real data access paths in Business Central **Body:** The standard API v2.0 exposes entities such as customers, vendors, items, salesOrders, salesInvoices, purchaseOrders and generalLedgerEntries under a companies path, and supports OData query options like $filter, $select, $expand and $top. Custom API pages written in AL let you expose any table with your own API publisher and group, and OData web services can publish pages and queries. The server instance exposes OData and API endpoints on configured ports, with Windows, NavUserPassword or Azure AD based authentication depending on how you set up the instance. The database is SQL Server, with tables named per company and suffixed with the app id, for example [CRONUS International Ltd_$Item$]. Direct SQL is possible on a replica but unsupported for logic, and FlowFields and calculated values are not stored. Use APIs for anything that must match what users see, and SQL only for bulk aggregates that you validate against the application. **Code:** GET https://bc-srv:7048/BC/api/v2.0/companies()/salesOrders?$filter=status eq 'Open'&$select=number,customerNumber,orderDate,totalAmountIncludingTax&$top=50 Authorization: Basic (or Windows / OAuth2 as configured) ### Reference architecture and air-gapped option **Body:** Run the tool server next to the Business Central server instance, with a read-only SQL replica for aggregates, a retrieval index for documents and an open-weight model on local GPUs. A change feed using the modified-at fields in the API or SQL change tracking keeps the index current. Every question, tool call, endpoint and answer is written to an audit log. For an air-gapped deployment, the same components run on an isolated network with models and packages brought in by controlled transfer. Microsoft's own Copilot features for Business Central are delivered through the cloud service, so check current availability for on-premises; a private layer is the practical route when data cannot leave your network. ### Permissions and write-back **Body:** Business Central permissions are sets assigned to users and user groups, evaluated at the object level (tables, pages, codeunits, queries) and can be extended with security filters. API and web service calls run under the identity of the caller, so delegating the user identity gives you true permission mirroring. If you use a single service identity for simplicity, you must enforce filters in the tool server and accept that it is more error-prone. Write-back uses the same APIs: the assistant drafts a sales quote or purchase order, a person approves, and the tool server POSTs to the API so validation, number series and workflow run. Keep write scopes narrow, record the approver in the audit log, and never use SQL for writes. ### Sizing, rollout and honest limits **Body:** A 50 to 250 user Business Central site usually needs one inference GPU for an 8B to 32B class model, plus a small server for the tool server and index. Attachment and document indexes commonly fall in the low gigabytes to low tens of gigabytes. Phase one is read-only questions, phase two is drafts for review, phase three is a few approved actions through the API. Honest limits: API rate limits and server resources apply, so batch heavy reads through the replica. Custom AL logic is reachable only if you expose it. If your needs are met by built-in reports, Power BI and standard search, a language model adds operating cost. And if cloud is acceptable for some data, Microsoft's own services may be simpler for that scope. ## Pitfalls - Using one broad service identity and forgetting to filter per user, which can expose data a user could not see in the client. - Treating API field names as identical to SQL columns. They are not, and the API applies business rules. - Pulling large sets through the API page by page for aggregates. Use the replica or a custom query API instead. - Skipping TLS and certificate setup on the server instance, then sending credentials in clear text. - Assuming cloud-only Copilot features exist on-premises without checking your version and licence. ## Ai Angle A grounded Business Central assistant calls the same APIs your integrations use, shows the request behind each answer and respects the calling user's permission sets. Netray builds the tool server, retrieval index and local model as a private layer in your environment. ## Faq ### Which API should the assistant use first? **Answer:** Start with API v2.0 for standard entities because it is documented and respects permissions. Add custom API pages in AL for tables and fields the standard API does not expose. ### Can we avoid SQL entirely? **Answer:** For most question types yes. Use SQL on a replica only for large aggregates or full-text scans, and validate results against the application before releasing. ### Does this work on Business Central 14? **Answer:** Yes for read paths in general, but API coverage and authentication options differ by version. Check the documentation for your build and test the endpoints you plan to depend on. ### How do we handle upgrades? **Answer:** Keep the tool server on API contracts rather than internal tables, version your custom API pages, and run an automated question set after each upgrade to catch regressions. ## Search terms Business Central on-premises AI, Business Central API v2.0 AI assistant, Business Central local LLM, Business Central custom API page AL, Business Central permission sets, private AI Business Central, Business Central Copilot alternative on-prem, air-gapped Business Central AI, chat with Business Central data, Business Central MCP server --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json