Why Copilot governance starts with data boundaries, not the license
The hard part is not the license — it is the control model. Microsoft 365 Copilot uses the Microsoft Graph to reach any file, email, or chat the user can already open, so it amplifies existing access. A Swiss private bank must decide whether AI-assisted drafting can be permitted while preserving confidentiality and supervision, as one Swiss private-banking analysis frames it.
FINMA Guidance 08/2024 does not ban AI. It requires demonstrable governance and risk management, and it recommends that institutions contact FINMA early when planning AI in critical processes. The steps below turn that expectation into an implementable checklist.
The same discipline Swiss firms apply to AI process automation under FINMA and the nFADP applies here: classify first, restrict second, monitor always.
Phase 1 — Establish the data and residency boundary
Start here because Copilot cannot be governed after the fact — the boundary must exist before the first prompt. This phase sets classification, residency, and access hygiene, the three controls FINMA maps to data quality and governance.
- Inventory and classify data with Microsoft Purview sensitivity labels. Define a 4-tier scheme (Public, Internal, Confidential, Restricted). Restricted covers client identifying data and cross-border banking secrecy scope under the nFADP.
- Set Azure Switzerland North / Switzerland West as the data residency boundary. Confirm in-country Microsoft 365 processing and document it; residency is a recurring FINMA outsourcing question addressed in the Microsoft FINMA compliance checklist.
- Run a SharePoint and OneDrive access review before enabling Copilot. Remediate overshared sites and “Everyone except external” links, because Copilot surfaces whatever the user can already reach.
- Apply container-level labels to Teams, SharePoint sites, and Dataverse tables. Sensitivity labels on Dataverse rows and Power Platform environments keep AI Builder and Copilot Studio agents inside the same boundary.
Phase 2 — Control what Copilot can read, generate, and retain
This phase enforces the boundary at runtime. The direct control is Microsoft Purview DLP for Copilot, which can exclude labeled content from being processed or summarized, plus retention and audit to satisfy FINMA’s documentation expectation.
- Enforce Microsoft Purview DLP policies scoped to Microsoft 365 Copilot. Block Restricted-labeled content from Copilot prompts and responses; DLP for Copilot evaluates labels at query time.
- Configure retention and eDiscovery for Copilot interactions. Prompts and responses are stored and discoverable; set retention to your records policy (commonly 10 years for Swiss banking records).
- Restrict Copilot Studio and AI Builder agents to approved data sources. Use Data Loss Prevention policies in the Power Platform admin center to separate business and non-business connectors in each environment.
- Enable audit logging and route Copilot activity to your SIEM. Purview Audit captures Copilot events; feed them to monitoring so compliance can evidence oversight to FINMA.
Phase 3 — Prove governance is working
FINMA rewards institutions that show their work. This phase converts controls into evidence: testing, human oversight, and a documented model inventory.
- Test for oversharing and prompt-injection before go-live. Run red-team prompts against Restricted data and record that DLP blocked them; keep the test log as documentation.
- Publish an AI inventory and human-in-the-loop policy. List each Copilot and agent use case, its data scope, and the named accountable owner, aligned with the four FINMA principles below.
The data shows Copilot inherits permissions verbatim. In Muze’s experience, 60–80% of the total effort is the pre-enablement access cleanup, not the technical DLP configuration.
According to PwC’s analysis of Guidance 08/2024, 2024, FINMA’s principles are complemented by the EU AI Act’s risk logic — so Swiss banks should design controls that satisfy both. This is the same evidence-led posture salmon exporters use when they automate multi-regulator reporting for bodies like Mattilsynet and SEPA: the regulator wants proof, not promises.
“Copilot does not create a new access problem — it exposes the one you already had. In every Swiss engagement we start by fixing SharePoint permissions and pinning residency to Switzerland North. The DLP policy is the easy part; the data hygiene is the deliverable.” — Marco Chávez, Founder of Muze AI Consulting.
The four FINMA Guidance 08/2024 principles mapped to Microsoft controls
FINMA’s Guidance is organized around four supervisory themes. Each maps to a concrete Microsoft 365 and Power Platform control.
| FINMA 08/2024 theme | Microsoft / Power Platform control | Evidence produced |
|---|---|---|
| Governance & accountability | Named AI owner + Purview AI inventory | Documented use-case register |
| Data quality & confidentiality | Sensitivity labels + DLP for Copilot | Classification report, DLP hit log |
| Testing & robustness | Pre-go-live red-team prompt tests | Oversharing/injection test log |
| Documentation & transparency | Purview Audit + retention + eDiscovery | Immutable interaction records |
Did you do this? — verification checklist
Use this table before you enable Copilot for the first production user group.
| Step | Done | Note |
|---|---|---|
| Purview sensitivity labels (4 tiers) deployed | ☐ | Restricted = client data |
| Data residency pinned to Switzerland North | ☐ | Document for FINMA outsourcing |
| SharePoint/OneDrive access review completed | ☐ | Remove broad-share links |
| Dataverse & Power Platform environment labels | ☐ | Cover AI Builder / Copilot Studio |
| DLP for Copilot blocking Restricted content | ☐ | Test with sample prompts |
| Copilot retention & eDiscovery configured | ☐ | Match records policy |
| Power Platform connector DLP policies set | ☐ | Business vs. non-business split |
| Audit logging routed to SIEM | ☐ | Evidence of oversight |
| Oversharing / prompt-injection test log kept | ☐ | Pre-go-live |
| AI inventory + human-in-the-loop policy published | ☐ | Named owners |