Check the permissions before blaming the model
When a Copilot pilot surfaces something it should not have, the instinct is to blame the model. The cause is usually a SharePoint site from 2019 with broken inheritance, shared with Everyone Except External Users because somebody needed a file on a Friday.
Copilot is the first tool efficient enough to find that site. Search never got there because nobody searched for it. An assistant that reads across the whole estate on every prompt does.
Classify first, then enable
The order matters. Service-side auto-labelling across a small number of tiers gives you something Copilot can be scoped against, and Public, Internal Use Only, Confidential and Strictly Confidential is enough for most organisations. Use Purview sensitivity labels with DLP for Microsoft 365 Copilot to keep confidential files out of Copilot responses.
This work delays the demo everyone wants to see. On a recent regulator programme we ran labelling across 800+ sites before Copilot was enabled anywhere.
Preserve the audit metadata
Retention and DLP policies need designing alongside the labels, and they need to preserve the historical metadata auditors will ask for. It is easy to write a retention policy that satisfies the legal team and quietly destroys the evidence trail somebody needs in two years.
Run access-control and permissions reviews against the Microsoft 365 Unified Audit Log before you switch anything on, and write the findings up. Keep the exported results, because auditors will want evidence that a screenshot cannot give them.
What good looks like
A defensible answer to three questions: what is classified and how was that decided; what can Copilot reach and who agreed that scope; and who has had access to what over the reporting period.
If you can answer those, the rollout is a change-management exercise. If you cannot, you are taking a risk nobody has written down.