Cross-Geo AI Processing in Fabric Copilot: What Indian Enterprises Should Check Before Enabling AI Features

Microsoft Fabric can keep an enterprise data estate in an Indian capacity while an AI request gets processed elsewhere. 

For Indian CIOs, that distinction deserves attention before Copilot reaches a production workspace. 

Microsoft’s current Fabric documentation maps capacities in India to Azure OpenAI processing in the United States for Copilot in Fabric. Microsoft therefore requires administrators to enable the cross-geo processing setting when an Indian capacity needs these Copilot experiences. 

At the same time, Microsoft enables the general tenant setting “Users can use Copilot and other features powered by Azure OpenAI” by default. The separate settings that allow Azure OpenAI data processing and storage outside the capacity’s geographic region remain disabled by default. 

That creates an important governance decision. 

A CIO cannot assess Fabric Copilot data residency by asking only where the Fabric capacity resides. The team must also establish: 

• what Copilot feature employees will use; 

• what information that feature sends for AI processing; 

• where Microsoft processes it; 

• whether the experience stores conversation history; 

• whether another service receives the answer; 

• which users can invoke the feature; and 

• whether the data carries regulatory, contractual or internal residency restrictions. 

For many Indian enterprises, especially banks, payment companies, healthcare providers and regulated multinationals, that review belongs ahead of broad Copilot enablement. 

Does Fabric Copilot process data outside India? 

Fig 1: Fabric administrators control Copilot access, cross-geo AI processing and cross-geo storage through separate tenant settings. 

Yes, it can. For an Indian Fabric capacity, Microsoft’s current regional mapping shows Fabric Copilot using Azure OpenAI processing in the US, which requires the cross-geo processing setting. 

Fabric capacity location	Azure OpenAI processing geography	Cross-geo processing?	What admins must do
India	US	Yes	Enable cross-geo data processing
US	US	No	Enable Copilot
EU Data Boundary	EU Data Boundary	No	Enable Copilot
UK	EU Data Boundary	Yes	Enable cross-geo proce ssing

This does not mean that Microsoft automatically relocates the enterprise’s entire Fabric data estate to the US. 

Fabric separates several concepts that teams often group together under “data residency”: 

Layer	Question the CIO should ask
Fabric data	Where does the lakehouse, warehouse or semantic model reside?
AI processing	Where can Azure OpenAI process the prompt and grounding infor mation?
AI storage	Can an AI experience store information outside the capacity geography?
Conversation history	Does the feature retain previous conversations between sessions?
Connected service	Where does the answer go after Fabric returns it?

Microsoft says Copilot processing can include the user’s prompt, meta-prompts, data structure or schema, and conversation history. Depending on the Copilot experience, grounding can also involve information accessible to the user that helps the model answer the request. 

Think about a CFO asking: 

“Why did operating margin fall in the western region?” 

The underlying financial model may remain within Fabric. Copilot still needs enough context to interpret “operating margin”, identify the relevant model and generate an answer. That AI-processing path deserves its own governance review. 

This is why an India-hosted capacity alone cannot answer the residency question. 

The first decision: what data are you willing to expose to cross-geo AI processing? 

Fig 2: Copilot combines the user’s request with relevant context before Azure OpenAI processes the prompt and returns an answer. 

Start with the data, not the Copilot toggle. 

Create a simple classification for the Fabric workspaces that may use AI. 

For example: 

Lower sensitivity 

• public or published information; 

• general product information; 

• non-sensitive operational metrics. 

Controlled enterprise information 

• sales performance; 

• procurement data; 

• internal forecasts; 

• employee operational information; 

• customer analytics. 

Restricted information 

• payment data; 

• detailed personal information; 

• health information; 

• confidential financial records; 

• regulated records; 

• information subject to contractual localisation clauses. 

Then ask one practical question for each class: 

Can this category of information participate in an AI request that Microsoft may process outside India? 

That question brings the CIO, CISO, data owner and compliance team into the same decision. 

Microsoft states that Azure OpenAI models used by Fabric run within Microsoft’s Azure environment. Microsoft does not send the data to the public OpenAI service, and it does not use customer prompts and outputs to train foundation models. 

Those protections matter. They still do not remove an enterprise’s responsibility to examine geographical processing, internal policy and sector requirements. 

Processing and storage are two different decisions 

This is one of the easiest areas for enterprises to misunderstand. 

Microsoft provides separate tenant controls for: 

1. allowing Azure OpenAI to process data outside the capacity’s geographic region, compliance boundary or national cloud instance; and 

2. allowing Azure OpenAI to store data outside those boundaries. 

An approval for cross-geo processing should therefore never become an assumed approval for cross-geo storage. 

The storage setting becomes especially important for Copilot in Notebooks and Fabric data agents. Microsoft explains that these conversational experiences can retain conversation history between sessions. For capacities outside the US and EU Data Boundary, the conversation-history control allows that history to reside in the Azure OpenAI region used by the experience. Users can clear it, and Microsoft states that unremoved history can remain for up to 28 days. 

A governance review should document three separate answers: 

• Can the data be processed outside India? 

• Can any part of the interaction be stored outside India? 

• How long can the AI conversation persist? 

If the business cannot answer all three, it has not completed the residency assessment. 

For organizations building their wider analytics architecture, our guide to Microsoft Fabric services and enterprise BI roadmaps explains why governance increasingly has to span the data, semantic and AI layers together. 

Connected Fabric data agents create another boundary to review 

Fabric data agents make this issue more important. 

A company can build a Fabric data agent over a warehouse, lakehouse, Power BI semantic model, KQL database or other supported Fabric source. Users can then consume that agent through other experiences. 

Fig 3: When a Fabric data agent connects to another AI client, governance must cover the receiving service as well as Fabric. 

Microsoft currently supports or previews connections involving services such as: 

• Microsoft 365 Copilot; 

• Microsoft Copilot Studio; 

• Microsoft Foundry; 

• external applications; and 

• Model Context Protocol clients. 

Microsoft explicitly warns that when organizations consume a Fabric data agent through a non-Fabric service, the response may move outside Fabric’s compliance boundary or geographic region. The receiving service’s own terms and data-handling policies then govern its processing and storage. 

That changes the governance map. 

Consider this route: 

Power BI semantic model → Fabric data agent → Microsoft 365 Copilot → employee 

A Fabric administrator may correctly configure the data agent. The compliance team still needs to review what happens when Microsoft 365 Copilot consumes its response. 

An MCP integration deserves the same scrutiny: 

Fabric data → data agent → MCP server → external AI client 

Microsoft warns that the client may process or store returned responses outside Fabric’s geographic and compliance boundary. 

A security review that stops at Fabric therefore misses part of the AI data path. 

Indian compliance teams should avoid one blanket answer 

Indian law does not create one universal data-residency rule for every organization and every data class. 

The Digital Personal Data Protection Act gives the Central Government power to restrict transfers of personal data to notified countries or territories. Section 16 also preserves any Indian law that provides stronger restrictions for a particular type of data or Data Fiduciary. 

India has also notified the Digital Personal Data Protection Rules, 2025, giving enterprises a more concrete compliance framework to plan against. 

Sector requirements can go further. 

For example, RBI’s payment-data direction requires authorized payment system providers to ensure that the entire data relating to payment systems they operate is stored in India, including end-to-end transaction information. RBI also places responsibility on the regulated entity for relevant service providers and intermediaries. 

Healthcare organizations face another governance context. The National Health Authority describes ABDM around a consent-based, federated architecture in which health records remain with the healthcare providers that create and store them. 

A BFSI or healthcare company therefore needs a data-class-specific review. A general statement such as “Microsoft Fabric is compliant” cannot settle the organization’s particular residency obligations, contracts, risk appetite or processing purpose. 

Aufait’s guide to the DPDP Rules and Microsoft governance controls provides a broader view of data discovery, classification, Purview and access controls that enterprises can use alongside the Fabric-specific assessment. 

Power BI Copilot needs the same tenant-level thinking 

Power BI teams should pay particular attention because Copilot in Power BI uses the Fabric capacity and tenant-control model. 

Microsoft requires Power BI Desktop users to connect to a workspace assigned to a Copilot-enabled Fabric capacity. Administrators can also scope Copilot settings to selected security groups and delegate settings to capacity administrators. 

This gives a CIO an important rollout option. 

You do not need to expose every workspace and every business team to the same AI policy on day one. 

A safer rollout might begin with: 

• one approved Fabric capacity; 

• selected security groups; 

• governed semantic models; 

• lower-sensitivity data domains; 

• named model and workspace owners; and 

• a defined review period. 

The organization can then expand access after security, compliance and business owners inspect actual usage. 

The same principle applies to the quality of the answers themselves. Our recent article on Power BI Copilot readiness explains how semantic models, KPI ownership, permissions and BI governance affect the answers users receive. 

What multi-country governance looks like in practice: Etihad Airways 

Aufait Technologies has already dealt with the kind of cross-border data complexity that makes AI governance difficult. 

For Etihad Airways, Aufait implemented an insurance management solution that automated policy management, renewals and endorsements across 41 stations. Aufait’s wider published airline insurance implementation also used Power Automate, Power BI, SharePoint, RPA and SAP SuccessFactors to bring employee and policy information from multiple countries into a controlled digital environment. 

The relevance to Fabric Copilot is the governance problem underneath the technology. 

An airline operating across countries cannot treat employee insurance data as one unrestricted pool of information. Location, role, policy type and regulatory requirements affect who should see the data and how the organisation should handle it. Once AI enters that environment, the enterprise has another question to answer: where can the context used for an AI response be processed, and which users or connected services can receive that response? 

That is why Fabric AI governance should begin with data classification and access design rather than the Copilot switch itself. 

Aufait Technologies brings this experience into Fabric governance engagements by combining Microsoft platform architecture with the practical access, workflow and compliance controls required in multi-country enterprise environments. 

What should a CIO check before enabling Fabric Copilot in India? 

Use this as the pre-enablement review. 

1. Confirm the Fabric capacity geography 

Record where each production capacity resides. 

2. Identify every AI feature in scope 

Separate Power BI Copilot, Fabric notebooks, data agents and connected-agent scenarios. They do not all handle storage and conversation history in the same way. 

3. Record the cross-geo tenant settings 

Document whether the organization allows cross-geo processing, cross-geo storage and conversation-history storage. 

4. Classify the data behind each workspace 

Identify personal, payment, health, financial, confidential and contractually restricted information. 

5. Scope access deliberately 

Use security groups and capacity-level controls to limit early adoption where appropriate. 

6. Trace connected agents beyond Fabric 

Document every destination that can consume a Fabric data agent response. 

7. Check sector and contractual restrictions 

Bring legal, privacy, security and business owners into the review for sensitive workloads. 

8. Record the decision 

For every AI-enabled data domain, keep evidence of: 

• approved processing geography; 

• permitted AI feature; 

• data owner; 

• access group; 

• retention position; 

• connected services; and 

• approver 

That record gives the organization something more useful than a one-time “Copilot approved” decision. It creates an auditable AI-control position that teams can revisit when Microsoft changes a feature, adds a new connection or introduces another agent experience. 

The question Indian CIOs should answer before enablement 

Cross-geo AI processing is not automatically a reason to stop a Fabric Copilot programme. 

It is a reason to understand the programme precisely. 

For an Indian enterprise, the important unit of governance is: 

data class + Fabric feature + processing geography + storage behaviour + connected service + user access. 

Once the organization knows those six things, it can make a defensible decision. 

Microsoft gives administrators meaningful controls over Copilot availability, cross-geo processing, cross-geo storage, capacity scope and user access. Fabric data agents also create powerful routes into Microsoft 365 and other AI environments. 

The CIO’s responsibility is to know which routes the organization has opened before sensitive enterprise data starts travelling through them. 

Make Fabric AI enablement a governed decision 

Review the tenant. Classify the data. Trace the AI path. Define who can use it. 

Aufait Technologies helps enterprises configure Microsoft Fabric governance, Power BI controls, Microsoft security settings and compliance-ready AI architectures. 

Request a Fabric Governance & AI Readiness Review → 

Disclaimer: All images belong to their respective owners. Image courtesy Microsoft Blogs.  

Frequently Asked Questions