# AI for Power BI on ERP Data: Answers Beyond the Dashboard You Already Built

> Source: https://netray.co/erp-ai/power-bi-ai-on-erp-data
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: AI for ERP

## Short answer

AI on Power BI and ERP data means a language model that reads your semantic model (tables, measures, relationships) and, where needed, the live ERP, then answers plain-English questions with the query shown. Copilot in Power BI covers cloud-hosted models; a private layer covers the cases where ERP data, row-level security or sovereignty rules keep the model on your own infrastructure.

## Kind

platform

## Erp Family

mfg-systems

## Erp Products

- Power BI

## Industries

- Manufacturing
- Aerospace
- Electronics

## Region

Global

## Persona

BI Lead

## Eyebrow

Power BI + ERP + private AI

## Intro

Most manufacturers already have Power BI. A BI developer pulled sales orders, work orders, inventory and purchase receipts from the ERP, built a star schema, wrote DAX measures for on-time delivery and margin, and published a handful of reports. Those reports answer the questions someone anticipated. The Monday-morning questions are different: which late jobs share a supplier, why did scrap rise on one routing, what changed in open purchase commitments since Friday.

Each of those questions turns into a ticket for the same one or two BI developers. They know which fact table holds the data, which relationships are inactive, and which measure is the trusted one. Everybody else guesses, exports to Excel, and produces a second version of the truth. The bottleneck is not the visuals. It is the knowledge of the model.

Copilot in Power BI and the Q&A experience address part of this, but they work on the semantic model as published, depend on the Power BI service and the licensing around Fabric capacity, and cannot reach the ERP records the model never imported. For plants with export-controlled data, customer NDAs, or a policy against sending operational data to a hosted model, that is a hard stop.

This page explains how a private AI layer works with Power BI: what it reads from the semantic model, when it should go past the model to the ERP, how row-level security is carried through, and where Copilot or a simpler fix is the better answer.

## Pain Points

### Report backlog is a knowledge bottleneck

**Detail:** Ad hoc questions queue behind BI developers because only they know which tables, relationships and DAX measures answer a question correctly. Business users export to Excel and rebuild logic that already exists in the model.

### Import models go stale between refreshes

**Detail:** Scheduled refresh through the on-premises data gateway means the model reflects the last refresh, not the shop floor right now. Questions about today's shortages are answered with yesterday's data unless someone built a DirectQuery path.

### Measure sprawl and conflicting definitions

**Detail:** Three reports define on-time delivery three ways, one by promise date, one by request date, one by ship date. A language model without governance will pick one silently, so the semantic layer has to carry the approved definitions.

### Row-level security is easy to bypass by accident

**Detail:** RLS roles defined in the model protect report viewers, but an export, a side database or an AI tool with a service account can read everything. Any AI layer must evaluate the asker's identity, not a superuser's.

### Copilot needs the data to leave your boundary

**Detail:** Copilot in Power BI runs through Microsoft-hosted services and needs capacity-based licensing. That is acceptable for many companies and not for defense, regulated or NDA-bound workloads.

## Use Cases

### Natural-language questions over the semantic model

**Description:** A planner asks a question in plain English. The layer maps it to tables and approved measures, generates a DAX query, runs it against the model and returns the result with the DAX visible for the BI team to audit.

**Erp Objects:** Power BI semantic model, DAX measures, fact tables for sales orders, work orders and inventory

**Outcome:** Moves routine questions off the BI backlog and leaves developers on model design instead of one-off report requests.

### Drill from a KPI to the ERP transaction

**Description:** When a dashboard shows late shipments rising, the user asks which orders and why. The layer follows from the model to the ERP order lines, shipments and holds that the import never carried.

**Erp Objects:** ERP order lines, shipment records, credit and quality holds

**Outcome:** Closes the gap between 'the number is red' and 'here are the five orders to call about'.

### Measure and model documentation

**Description:** The assistant reads the model's tables, columns, relationships and DAX and answers 'how is gross margin calculated and which report uses it', so definitions stop living in one developer's head.

**Erp Objects:** Model metadata through the XMLA endpoint, measure definitions, report lineage

**Outcome:** Shorter onboarding for new analysts and fewer duplicate measures.

### Narrative commentary on monthly packs

**Description:** Each month the assistant drafts commentary on variances (scrap, overtime, purchase price) from model results, for a controller to edit and approve.

**Erp Objects:** Cost variance, labor and scrap fact tables, purchase price history

**Outcome:** Takes first-draft commentary from hours to a review step, with the numbers traceable to the model.

### Data quality triage

**Description:** The layer scans loaded tables for orphan keys, blank item categories, negative inventory and duplicate suppliers, and explains which refresh or ERP setting is the likely cause.

**Erp Objects:** Dimension tables for item, supplier and customer, refresh logs

**Outcome:** Catches modelling and master-data problems before executives see a wrong number.

### Report request intake

**Description:** Instead of a vague email, the requester describes what they need. The assistant checks whether an existing report or measure already answers it and drafts a spec if not.

**Erp Objects:** Workspace report inventory, semantic model catalog

**Outcome:** Fewer duplicate reports and better-formed requests for the BI team.

### Cross-system questions the model cannot hold

**Description:** Questions that join the Power BI model with documents or systems outside it, such as supplier contracts or MES events, are answered by a layer that can reach several sources.

**Erp Objects:** Semantic model plus ERP tables, contract documents, MES event tables

**Outcome:** One question surface across sources that were never modelled together.

## Architecture

**Overview:** The AI layer sits beside Power BI, not inside it. It reads the semantic model through the XMLA endpoint or a published dataset and reads the ERP through its own read-only connector, so it can answer from governed measures first and fall back to source data when asked.

**Layers:**

#### Model connector

**Detail:** Connects to the semantic model through the XMLA endpoint or the Execute Queries API to read metadata and run DAX, using the identity of the asker so row-level security roles apply.

#### ERP connector

**Detail:** A read-only connector to the ERP database or API for records the model does not import, scoped to the same roles the ERP itself enforces.

#### Semantic mapping

**Detail:** A glossary tying business terms to approved measures, so 'on-time delivery' resolves to the one definition finance signed off, with synonyms and unit conventions recorded.

#### Model serving

**Detail:** An open-weight model such as Llama, Qwen or Mistral served with vLLM or Ollama on customer GPUs or in a sovereign cloud, sized to the number of concurrent askers.

#### Governance and audit

**Detail:** Every question, generated DAX or SQL, and result is logged against the user, and any write-back such as an email draft requires explicit human approval.

## Deployment Options

### On-prem next to Power BI Report Server

**Fit:** Plants that keep reports on Power BI Report Server or a gateway-fed model and cannot send data to hosted AI.

**Detail:** Model serving, retrieval and connectors run on customer hardware. Queries reach the model and ERP over the internal network only.

### Private cloud tenant

**Fit:** Companies on the Power BI service who want grounded AI without routing data to a shared hosted model.

**Detail:** The AI layer runs in the customer's own subscription or VPC and reaches the published model through the XMLA endpoint under the customer's tenant policies.

### Hybrid

**Fit:** Groups where headquarters uses Fabric and some plants must stay isolated.

**Detail:** A central governance layer with per-site connectors, so restricted plants never send data to a central model.

## Compliance

### The layer evaluates queries as the asking user so RLS roles and hidden columns in the semantic model continue to apply to AI answers.

**Framework:** Row-level and object-level security

### Serving the model on infrastructure the customer controls keeps controlled technical data inside the boundary the customer already manages; classification and access policy remain the customer's responsibility.

**Framework:** ITAR and EAR technical data

### A documented network path with no outbound model calls gives a concrete answer to customer security questionnaires.

**Framework:** Customer NDAs and data processing terms

### Answers cite the governed measure and the query, so finance can reproduce a number instead of trusting generated prose.

**Framework:** Financial reporting controls

## Integration Notes

- Reads semantic model metadata and runs DAX through the XMLA endpoint, which requires Premium, Fabric capacity or Premium Per User, or the Execute Queries REST API for smaller cases.
- For Power BI Report Server, queries go to the underlying Analysis Services or SQL source the report uses, since the service-only APIs are not available.
- On-premises data gateway behavior is respected: the layer does not bypass the gateway or open new paths to the ERP database.
- DirectQuery models can pass identity through to the source; Import models rely on RLS roles defined in the model, and the layer maps the asker to those roles.
- ERP access uses read replicas or reporting views where possible to avoid load on the transactional database.
- Measures marked as approved are preferred over ad hoc aggregation; when the user asks for something not in the model, the answer says so and shows the source query used.
- Usage and accuracy logs are exportable back into a Power BI report for the BI team to review.

## Product Fit

### ERPray

**Why:** Grounded questions, dashboards and agents over live ERP data cover what the Power BI model never imported, with the query shown and roles respected.

### DataRay

**Why:** Where the answer spans the Power BI model, file shares and documents, DataRay chats across several on-prem sources.

## Engagement

### Discovery

**Duration:** 2-3 weeks

**Deliverables:**

- Inventory of semantic models, workspaces and capacity or Report Server setup
- Review of RLS roles, measures and approved definitions
- Ranked list of questions the BI backlog repeats
- Deployment recommendation

### Pilot

**Duration:** 6-8 weeks

**Deliverables:**

- Connector to one semantic model and the matching ERP tables
- Glossary of approved measures
- 3-5 question patterns live for a pilot group
- Accuracy review against known answers

### Production

**Duration:** 4-6 weeks

**Deliverables:**

- Identity pass-through and RLS validation
- Audit logging and usage report
- Runbook for adding models
- Handoff to the internal BI team

### Scale

**Duration:** Ongoing

**Deliverables:**

- Additional models and plants
- Approval-gated agent actions
- Quarterly accuracy review
- Model refresh as open-weight options improve

## Buyer Questions

- Does the AI layer run queries as the asking user so row-level security applies, or as a service account?
- Which measures does it treat as approved, and what happens when a requested metric is not in the model?
- What do we need that Copilot in Power BI does not already give us, and is Copilot good enough for our case?
- How does it behave with Import models that are hours old versus DirectQuery?
- Where does the model run and can you show the network path?
- Can it explain its DAX or SQL so our BI team can audit it?
- What licensing or capacity does the XMLA endpoint require in our tenant?
- What do we keep if we stop: connectors, glossary, logs?

## Faq

### Is this a replacement for Power BI?

**Answer:** No. Power BI stays the governed reporting layer. The AI layer is a question interface on top of the semantic model and the ERP. Standard reports, scheduled packs and certified datasets remain in Power BI, and the layer prefers approved measures over improvising calculations.

### When is Copilot in Power BI enough?

**Answer:** If your models live in the Power BI service, your data policy allows Microsoft-hosted AI, and your questions stay inside what is already modelled, Copilot may be enough and cheaper to adopt. A private layer is for ERP records beyond the model, sovereignty limits, or cross-source questions.

### How is row-level security handled?

**Answer:** Queries run under the asker's identity, so the roles defined in the semantic model apply to the DAX the layer generates. For ERP-side queries the layer uses the ERP's own roles. We test this explicitly with users in different roles before production.

### Can it work with Power BI Report Server?

**Answer:** Yes, with limits. Service-only APIs are not available, so the layer connects to the underlying Analysis Services or SQL sources and the report definitions instead of the cloud endpoints. Scope is agreed during discovery against your actual version.

### Will it write DAX that is correct?

**Answer:** Generated DAX is validated against the model schema, run in a read-only context, and shown to the user. Accuracy is highest for questions that map to approved measures; novel calculations get flagged for review rather than presented as certain.

### Does it send our data to a public model?

**Answer:** No. Open-weight models run on your hardware or in your own private cloud tenant. Retrieval and connectors run inside your network, and the deployment can be reviewed against your data policy before go-live.

### Can users write back to the ERP through it?

**Answer:** Only as drafts. An email to a supplier or a purchase follow-up can be drafted for review, and anything that changes ERP records goes through the ERP's own workflow with a person approving it.

## Search terms

Power BI AI on ERP data, Power BI natural language query, Power BI Copilot alternative, private AI for Power BI, Power BI ERP integration AI, Power BI on-premises AI, ask questions of Power BI semantic model, Power BI DAX generation AI, Power BI row level security AI, Power BI manufacturing analytics AI, Power BI Report Server AI, chat with Power BI data

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json