D365 SCM + on-prem AI
AI for Dynamics 365 Supply Chain Management on Local Business Data
Short answer
Dynamics 365 Supply Chain Management's Local Business Data (LBD) option runs transactional workloads on Azure Local infrastructure a manufacturer controls, built for plants with limited or intermittent connectivity. A private LLM grounded on that same edge environment can answer production and warehouse questions without depending on cloud reachability, but LBD is closer to a disconnected-edge model than a fully air-gapped one, and an IT director should understand that distinction before assuming it satisfies an air-gap requirement.
- ERP
- Dynamics 365 Supply Chain Management, D365 SCM Local Business Data (on-prem)
- Industries
- Manufacturing, Aerospace, Defense
- Written for
- IT Director
Dynamics 365 Supply Chain Management's Local Business Data deployment option exists for exactly the operational reality a lot of manufacturers live with: a plant floor that cannot guarantee continuous, low-latency connectivity to a cloud data center, running on Azure Local infrastructure the company hosts and controls, with the transactional workload processed locally and reconciled back to the cloud instance on a schedule. For a manufacturer that needs production and warehouse execution to keep working through a connectivity gap, LBD is a real answer to a real problem.
What LBD is not, and this matters for an IT director scoping AI on top of it, is a classic fully air-gapped on-premises deployment in the way a self-hosted SQL Server AX instance used to be. LBD's architecture depends on Azure Arc and Azure Local connectivity for management, updates, and periodic data reconciliation with the cloud F&SCM instance. It is closer to disconnected-edge computing than to a network with no path to the internet at all, and that nuance needs to be explicit in any project that assumes LBD equals an ITAR-grade air gap.
Given that, the right AI architecture mirrors LBD's own design intent: model serving and the semantic layer live on infrastructure co-located with the LBD environment, so production and warehouse question-answering keeps working even during a reconciliation gap or a connectivity outage, rather than depending on a round trip to a cloud AI service. Data entities and OData APIs against the LBD instance provide the grounding, the same pattern used against the cloud F&SCM service, just pointed at the local instance instead.
For aerospace, defense, and electronics manufacturers evaluating LBD specifically because of data control requirements, the honest recommendation is to treat the AI project and the LBD deployment decision as connected but separate questions: confirm with Microsoft or your partner exactly what data crosses the Azure Local-to-cloud reconciliation link and under what conditions, before assuming the AI layer inherits an air-gap guarantee the underlying platform does not fully provide on its own.
What usually gets in the way
The problems we hear most from it director teams running Dynamics 365 Supply Chain Management.
Standard D365 Copilot features assume continuous cloud connectivity
Native Copilot capabilities in D365 SCM are built around the cloud service; they do not map cleanly onto a plant running LBD's disconnected-edge model, where the AI experience needs to keep working locally.
Plant floor staff cannot always reach the cloud instance
Shop-floor and warehouse workstations on a segmented plant network may have limited or no path to the cloud F&SCM service, which is the entire reason LBD exists, but that same limitation affects any cloud-dependent AI feature.
LBD's edge-to-cloud reconciliation model is not well understood internally
IT teams evaluating LBD for a regulated environment often assume it behaves like classic on-prem AX; the actual Azure Arc and reconciliation dependencies need explicit review before that assumption is relied on.
Production and warehouse exceptions still require active monitoring
Component shortages, warehouse task exceptions, and master planning action messages surface in D365's own workspaces, but nothing proactively summarizes them for a supervisor without someone checking regularly.
Defense-adjacent manufacturers assume LBD equals air-gapped by default
The marketing language around on-premises and local processing can be read as a stronger data isolation guarantee than the platform's actual reconciliation architecture provides without a deliberate review.
Where AI earns its place in Dynamics 365 Supply Chain Management
Each use case names the ERP objects it reads or writes, so your ERP team can judge the integration effort before anyone commits budget.
Production floor status Q&A that survives a connectivity gap
A supervisor asks about released production order status, routing progress, or BOM detail, answered from the local LBD instance so the AI layer keeps working through a cloud reconciliation outage.
Touches: Released Production Order, Route, Bill of Materials
Outcome: Keeps production status question-answering available exactly when connectivity is most likely to be unreliable, which is when it matters most.
Warehouse pick, pack, and putaway exception flagging
An agent reviews Warehouse Management mobile app task data for stalled or exception-flagged work and summarizes it for a warehouse supervisor in plain language.
Touches: Advanced Warehousing work tables, Warehouse Management mobile app tasks
Outcome: Cuts the time to spot and resolve a stalled putaway or pick task, without a supervisor manually scanning the work list.
Master planning exception explanation
A planner asks why a planned order or an action message appeared, and gets a plain-language explanation grounded in master planning inputs, rather than reading the raw exception message.
Touches: Master Planning, Planned Order, Action Message
Outcome: Reduces the interpretation burden on planners who are not deeply fluent in D365's planning engine logic.
Component shortage and schedule-risk flags
An agent compares BOM requirements against on-hand and incoming inventory for released production orders, flagging schedule risk before a shortage stops the line.
Touches: Inventory on-hand, Bill of Materials, Production schedule
Outcome: Gives production planners earlier warning of a component shortage than discovering it at the point of assembly.
Data entity-grounded text-to-query for plant staff
Plant staff ask questions in plain English that translate into a query against exposed OData data entities on the LBD instance, executed read-only, with the entity and filter shown.
Touches: OData data entities for production, inventory, and warehouse
Outcome: Removes the dependency on a small group of D365-fluent staff for routine plant-floor reporting questions.
Document intake for receiving and inspection at the edge
OCR and classify receiving documents, packing slips, and certificates of conformance locally, proposing a match against open purchase order lines for a clerk to confirm.
Touches: Purchase order receiving, Quality order
Outcome: Keeps document-driven receiving processes moving even during a period when the cloud reconciliation link is degraded.
Edge-to-cloud reconciliation monitoring assistant
An agent watches LBD's synchronization and reconciliation status and flags conflicts or delays for IT before they cause a data integrity issue between the edge and cloud instances.
Touches: LBD synchronization and reconciliation logs
Outcome: Surfaces sync problems to IT proactively rather than discovering a reconciliation conflict after it has already affected reporting.
Reference architecture
Model serving and the semantic layer are co-located with the LBD environment on Azure Local infrastructure, grounding question-answering and exception detection on local data entities so the AI layer keeps working through connectivity gaps, with governance built around LBD's own edge-to-cloud reconciliation model.
- 1
Edge connectivity
OData data entities and custom services exposed by the LBD instance, queried locally on the plant network rather than routed through the cloud F&SCM service.
- 2
Semantic layer
A mapping from D365 SCM's production, warehouse, and planning entities to plant-floor vocabulary, accounting for any custom X++ fields added to the local instance.
- 3
Model serving
Open-weight models served on hardware co-located with the LBD environment, so inference continues to work independent of the Azure Arc management and reconciliation connection.
- 4
Retrieval and agents
Text-to-query against local data entities for structured questions, scheduled exception agents for warehouse and shortage flags, and a dedicated monitor for reconciliation status.
- 5
Governance and audit
Every answer logged with the local entity and record identifiers it drew from, with reconciliation-aware logging so an auditor can distinguish edge-only activity from data that has synced to the cloud instance.
Integration notes for your ERP team
- Confirm which data entities and custom services are actually exposed on the specific LBD instance version before scoping the connector; entity availability can differ from the cloud F&SCM service.
- Co-locate model serving and the semantic layer with the LBD hardware itself, not in the cloud, so the AI layer's availability matches LBD's own connectivity-resilience design intent.
- Review the Azure Arc and Azure Local reconciliation architecture directly with Microsoft or your implementation partner before making any ITAR or CMMC representation about the AI project's data isolation; do not assume it from the LBD name alone.
- Use Data Management (DIXF) for any bulk data preparation needed to seed the semantic layer, rather than ad hoc extraction scripts against the local database.
- Authenticate to the local data entities through an Azure AD app registration scoped appropriately for the edge environment, keeping agent activity auditable separately from human users.
- Build the reconciliation-monitoring use case early; it gives IT direct visibility into a part of LBD's operation that is otherwise opaque without watching Azure Arc status manually.
- Plan capacity for the plant network specifically: edge hardware for both LBD and AI inference needs to be sized together, not treated as two unrelated projects competing for the same rack space.
Deployment options
Edge-colocated on-prem
Manufacturers running LBD specifically for connectivity resilience, or for defense-adjacent data handling requirements, once the Azure Arc reconciliation link has been reviewed against those requirements.
Model and semantic layer run on hardware on the same plant network as the LBD environment, with inference continuing to function during a reconciliation gap.
Private or sovereign cloud complement
Companies wanting the same AI capability against the cloud F&SCM instance for sites not running LBD, kept consistent with the edge deployment's architecture.
A parallel, dedicated-tenant cloud deployment connecting to the cloud F&SCM instance, using the same semantic layer and agent patterns as the edge sites.
Hybrid pilot
IT teams wanting to prove one use case, such as production status Q&A, at a single plant before extending the pattern to other LBD sites.
A scoped pilot on modest edge hardware at one site, same architecture, replicated to additional plants once proven.
Compliance and data control
How the architecture supports your obligations. Certification and accountability stay with your organisation; the design keeps the evidence straightforward.
ITAR / export control
Before relying on LBD for ITAR-relevant data isolation, review exactly what crosses the Azure Arc and reconciliation link with Microsoft or your partner; the AI layer's own model serving can be kept fully local regardless of that review's outcome.
CMMC 2.0 / DFARS 252.204-7012 / NIST SP 800-171
Model serving and the semantic layer stay on the plant's own infrastructure, with CUI-relevant data processed locally rather than sent to a public AI API, consistent with LBD's own edge-processing design intent.
Data residency at the edge
Production, warehouse, and quality data used for grounding stays within the plant's local environment; only what LBD itself reconciles to the cloud follows that separate, already-governed path.
Change management
The AI layer reads through standard data entities and does not modify X++ code or LBD configuration, keeping it outside existing D365 change control scope for the underlying ERP.
Where Netray fits
Custom build
LBD is a newer deployment pattern with edge-specific connectivity and reconciliation considerations that do not fit a generic packaged connector; the architecture needs to be built and validated against the specific LBD instance.
ERPray
Once the semantic layer against LBD's data entities exists, ERPray's connector pattern can provide general-purpose, cited question-answering for plant staff, consistent with how it works against a standard cloud D365 SCM instance.
How an engagement runs
Phase 1 . 3-4 weeks
Discovery
- -Confirmed data entity and API coverage on the specific LBD instance
- -Architecture review of the Azure Arc reconciliation link against ITAR/CMMC requirements, with Microsoft or the partner involved
- -Semantic layer scoping for the pilot use case
- -Success criteria agreed with IT and plant operations
Phase 2 . 6-8 weeks
Pilot
- -Working text-to-query layer against local data entities at one plant
- -Model serving deployed on edge hardware co-located with LBD
- -5-10 real production or warehouse questions answered end to end, tested with connectivity to the cloud instance deliberately interrupted
- -Pilot review with IT director and plant operations sponsor
Phase 3 . 8-10 weeks
Production
- -Role-based access aligned to existing D365 SCM permissions
- -Reconciliation-monitoring agent in production
- -Audit logging distinguishing edge-only activity from cloud-synced data
- -Runbook for IT to operate the edge AI stack alongside LBD
Phase 4 . ongoing
Scale
- -Pattern replicated to additional LBD plant sites
- -Additional use cases, such as shortage flags and document intake, layered on the same edge infrastructure
- -Quarterly review of connectivity-gap incidents and how the AI layer performed during them
Questions to ask any vendor, including us
A short list that separates real Dynamics 365 Supply Chain Management AI work from a chatbot demo.
- Exactly what data crosses the Azure Arc and reconciliation link between our LBD instance and the cloud, and under what conditions?
- Does the AI layer keep working during a connectivity gap between the plant and the cloud F&SCM instance, or does it depend on that link?
- Is LBD, on its own, sufficient for our ITAR or CMMC data isolation requirement, or does it need a deliberate architecture review first?
- Where does the model run relative to our LBD hardware, and does inference require any cloud round trip?
- Which D365 SCM data entities are actually exposed on our specific LBD instance version?
- How do you handle authentication for agent activity against a local, edge-hosted D365 environment?
- What happens to the AI layer's answers if a reconciliation conflict occurs between the edge and cloud instances?
- Can this same architecture extend to additional plant sites, and how does that change the model serving footprint?
Frequently asked questions
Is Local Business Data the same as a fully air-gapped on-premises deployment?
Not quite. LBD runs the transactional workload locally on Azure Local infrastructure you control, but it depends on Azure Arc connectivity for management and periodic reconciliation with the cloud F&SCM instance. It is closer to a disconnected-edge model than a classic air gap, and that distinction should be confirmed with Microsoft or your partner before relying on it for an ITAR or CMMC representation.
Will an AI layer on LBD keep working if the plant loses connectivity to the cloud?
Yes, if model serving and the semantic layer are co-located with the LBD hardware itself, as recommended. Inference and question-answering against local data entities do not require a round trip to the cloud F&SCM instance, matching LBD's own connectivity-resilience design intent.
Does the AI layer change how LBD reconciles data with the cloud?
No. The AI layer reads through standard data entities and does not modify X++ code, LBD configuration, or the reconciliation process itself. It sits alongside LBD's existing architecture rather than altering it.
Can this answer production and warehouse questions the same way it would on the cloud D365 SCM service?
Yes, using the same data entity and OData connector pattern, just pointed at the local LBD instance instead of the cloud service. Entity availability should be confirmed for the specific LBD version before scoping the connector, since it can lag the cloud service's API surface.
Is LBD required to get on-prem AI for Dynamics 365 Supply Chain Management?
No. Manufacturers on the standard cloud D365 SCM service can still run AI model serving fully on-prem or in a private cloud, connecting to the cloud instance's data entities over a controlled connection. LBD is relevant specifically when connectivity resilience or edge processing is itself the requirement.
How does this handle warehouse exception detection specifically?
A scheduled agent reviews Warehouse Management mobile app task data, such as stalled pick or putaway tasks, and summarizes exceptions for a supervisor in plain language, reading from the same local data entities used for other question-answering use cases.
What is the first thing an IT director should verify before starting an AI project on LBD?
Exactly what data and metadata cross the Azure Arc and reconciliation link to the cloud, and under what conditions, verified directly with Microsoft or the implementation partner. That answer shapes the compliance posture of the AI project more than any AI-specific design decision does.
Related guides
AI for Dynamics 365 Finance and Supply Chain beyond Copilot
AI for D365 Finance and Supply Chain beyond Microsoft Copilot: private LLM grounded on data entities and OData, on-prem-capable via Local Business Data.
On-prem AI, any ERP, A&DOn-Prem AI for ERP in Aerospace, Defense, and Electronics Manufacturing
A hub guide to on-prem AI across SAP, Infor LN, Costpoint, IFS, and Oracle EBS for aerospace, defense, and electronics manufacturers under ITAR, CMMC, and AS9100.
Agents + approval gatesAI Agents for ERP, Running On-Prem
A practical guide to on-prem AI agents for ERP: what they can safely automate, where human approval belongs, and how to design the guardrails.
ITAR + on-prem AIITAR-Compliant AI for ERP Technical Data
How to add generative AI to your ERP without creating a deemed export under ITAR. On-prem architecture patterns an Empowered Official can sign off on.
RAG + SQL + permissionsA Private LLM Grounded on Your ERP Data
How a private LLM answers questions on your ERP data: RAG plus text-to-SQL, role-based permissions inherited from the ERP, and where each fits.
Business Central + private AIAI for Dynamics 365 Business Central, on-premises or SaaS, beyond Copilot
AI for Business Central beyond Copilot: grounded question answering over BC's data via OData and APIs, for on-premises and SaaS tenants alike.
Plan it with numbers
On-Prem AI ROI Calculator
Turn hours saved per employee into annual net benefit, payback months, and 3-year ROI for an on-prem AI investment.
Free ToolCloud vs On-Premise ERP Cost Calculator
Put cloud subscription and on-premise ERP costs side by side over 5 years, including the maintenance, infrastructure, and staffing lines that skew the comparison.
Free ToolManufacturing AI Readiness Assessment
Score your manufacturing operation's readiness for AI across data, systems, people, and governance, and get a prioritized roadmap for closing the gaps.
GuideWhy On-Prem AI Is Back in 2026
On-prem AI is back in 2026 as data sovereignty, CMMC 2.0, and GPU economics shift the math. Why manufacturers are moving LLMs behind the firewall.
GuideHybrid AI Architecture Patterns for Manufacturers
Hybrid AI architecture patterns for manufacturers: what runs on-prem vs cloud, data boundaries, latency budgets, and ITAR-safe designs that scale.
GuideOn-Prem AI for Defense Contractors: The Complete Guide
On-prem AI for defense contractors: deploy LLMs and AI agents inside your CMMC and ITAR boundary. Architecture, hardware costs, timelines, and vendor options.
Talk it through with an engineer who knows Dynamics 365 Supply Chain Management
Bring one real question your team cannot answer from the ERP today. We will map the data path, the model, and where it runs, and tell you honestly if AI is the wrong tool for it.