Forum Discussion
Advocate IIPreparing Enterprise Data Warehouses for AI-Powered Applications
Hi everyone,
I am exploring how organizations are preparing their enterprise data platforms for AI-powered applications.
As more teams start building AI assistants and intelligent applications, having clean, structured, and accessible data becomes increasingly important.
I would like to understand how the community is approaching this with Microsoft Fabric Data Warehouse.
Some questions:
- What data modeling approaches work best when preparing warehouse data for AI and analytics workloads?
- How are teams balancing traditional BI reporting requirements with new AI use cases?
- What strategies are you using for maintaining data quality and governance at scale?
- Are there recommended patterns for connecting AI applications with enterprise warehouse data securely?
Would love to hear practical experiences and lessons learned from teams working with Fabric Data Warehouse.
Thanks!
Don't split this into two systems, keep it one.Whatever feeds power bi should be the same gold layer/semantic model your ai agent hit too, running on direct lake.If your ai app is going straight to warehouse tables insted of that layer, you are asking for headaches later.
Big thing on governance this year is Onelake security, GA'd back in april . Set your row and column security once at the onelake level and forget rebuilding it in the sql endpoint, power bi notebooks, wherever else, it just applies everywhere now. Used to be such a pain keeping all that in sync.
For hooking an AI app up securely, publish it as a fabric data agent and expose that as an MCP server. It uses a regular entra token, so it only ever sees what that user could already see, RLS and all, no extra permission layer to babysit. One gotcha, if you're using an external MCP client, check the cross-geo setting on your tenant first.
And honestly, Direct lake is the real fix for the BI vs AI resource, both are hitting the same delta tables now instead of duplicate copies everywhere.
5 Replies
v-achippaCommunity Support
Hi codeautomation,
Thank you for reaching out to Microsoft Fabric Community.
Thank you NehaNellepalli and ShivekMaharaj for the prompt response.
As we haven’t heard back from you, we wanted to kindly follow up to check if the solution provided by the user's for the issue worked? or let us know if you need any further assistance.
Thanks and regards,
Anjan Kumar Chippa- v-achippa
Hi codeautomation,
We wanted to kindly follow up to check if the solution provided by the user's for the issue worked? or let us know if you need any further assistance.
Thanks and regards,
Anjan Kumar Chippa
jubinsoniMemorable Member
Hi codeautomation ,
Agree with keeping BI and AI on the same foundation. One thing that's helped me is adding a small, dedicated schema of views just for AI use. Each view is flattened to one clear grain, uses plain business names instead of codes and abbreviations, and only includes the columns an agent actually needs. Your star schema stays as is for BI, and the agent gets a simpler surface that's much harder to get wrong.
The other thing worth planning early is unstructured data. Most AI apps end up needing more than numbers, things like contracts, support tickets or product docs. The warehouse is great for "what were sales last quarter" but not for "what did the customer complain about." Pairing it with Azure AI Search or Foundry IQ for documents, and letting an agent use both as tools, covers a lot more real questions.
And whatever you build, keep a set of test questions with known answers and rerun them whenever the schema or instructions change. It's the easiest way to catch accuracy drops before your users do.
Don't split this into two systems, keep it one.Whatever feeds power bi should be the same gold layer/semantic model your ai agent hit too, running on direct lake.If your ai app is going straight to warehouse tables insted of that layer, you are asking for headaches later.
Big thing on governance this year is Onelake security, GA'd back in april . Set your row and column security once at the onelake level and forget rebuilding it in the sql endpoint, power bi notebooks, wherever else, it just applies everywhere now. Used to be such a pain keeping all that in sync.
For hooking an AI app up securely, publish it as a fabric data agent and expose that as an MCP server. It uses a regular entra token, so it only ever sees what that user could already see, RLS and all, no extra permission layer to babysit. One gotcha, if you're using an external MCP client, check the cross-geo setting on your tenant first.
And honestly, Direct lake is the real fix for the BI vs AI resource, both are hitting the same delta tables now instead of duplicate copies everywhere.
- ShivekMaharaj
Community Champion
Hi codeautomation,
I agree with the general idea of avoiding a separate "AI warehouse." I would normally keep BI and AI on the same governed enterprise data foundation, but expose that data through different semantic/query layers depending on the workload.
One thing I would add is that preparing a Warehouse for AI is not really about abandoning traditional dimensional modelling. In many cases it makes it even more important.
Microsoft's Fabric Data Agent guidance recommends keeping the schema exposed to the agent focused, using clear business-friendly names, documenting table grain and relationships, defining business terminology, and providing example queries where the logic is not obvious.
So I would still build stable facts/dimensions or similarly well-defined analytical entities, with clear keys and governed business definitions. A very wide or ambiguous enterprise schema is harder for both humans and NL2SQL agents to reason over.
For Fabric Warehouse specifically, I would also keep security at the Warehouse boundary rather than assuming OneLake security alone covers every access path. Fabric Warehouse supports item permissions together with SQL object-level, row-level and column-level security, as described in the Warehouse security guidance.
A published Fabric Data Agent can query Warehouse directly using its NL2SQL capability, so you do not necessarily need another copy of the data for the AI application.
For external applications, the newer Fabric Data Agent MCP endpoint is also worth considering. One security detail there is important: the Fabric bearer token can represent either a user or a service principal.
If you use a user token, access can follow that user's Fabric/Warehouse permissions. If you use a service principal, the application is operating with the service principal's permissions instead, so per-user authorization needs to be designed explicitly rather than assumed.
I would therefore think of the architecture as:
Warehouse/Lakehouse -> governed enterprise data
Semantic model -> curated BI metrics and business logic
Fabric Data Agent -> governed natural-language query layer
MCP/application -> external AI experienceI would not make Direct Lake mandatory for this architecture either. Direct Lake is very useful for Power BI over OneLake, but Fabric Data Agent can query a Warehouse directly, so the right interface can differ while the underlying business data remains shared.
One other current consideration: if Data Agent responses are sent to external services through MCP or another non-Fabric service, Microsoft notes that those responses may leave Fabric's compliance/geographic boundary depending on the consuming service. That is worth including in the security review for enterprise AI deployments.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
