A policy is switched on to stop staff pasting student records into AI tools. In the first week it produces several hundred alerts.
A sample is reviewed. A few are the intended case exactly, and they are the reason the policy exists. Most are staff pasting their own work, which happens to contain a number in the shape of a student identifier. One is a staff member pasting a draft of their own performance review into a writing assistant, which the policy was never meant to look at and which somebody on the security team has now read. By week three the policy has been narrowed until it fires almost never, the reporting shows a reassuring decline, and the programme has spent credibility it will need later.
Nothing in that sequence is unusual and nothing in it is anyone's incompetence. It is the predictable result of switching on a control without understanding its error model. The question this chapter answers is what would have had to be understood in advance for the first week to go differently.
Two problems, not one
Data loss prevention is sold as one thing and is two. Classification asks whether a piece of content is sensitive. Enforcement asks what to do about it if it is.
They are independent. Enforcement is largely a solved engineering problem: given a verdict, blocking a paste or an upload is straightforward. Classification is not solved and will not be, because it is an inference about meaning made from text, and the difficulty is all here.
Put that first, and every vendor conversation in the category reorders itself. The demonstration always shows enforcement, because enforcement demonstrates well. The thing that determines whether the deployment succeeds is the accuracy of the classifier against the organisation's own content, which cannot be demonstrated in a meeting.
How classification actually works
Five techniques, in rough order of how much they ask of the organisation.
Pattern matching with corroboration. A regular expression describes the shape of an identifier. Where the identifier carries a checksum, the checksum is validated, which removes a large share of coincidental matches. Supporting evidence is then required within a proximity window: keywords such as 'patient' or 'account', or other patterns nearby. A confidence level is computed from how much supporting evidence was found, and the policy sets a threshold and an instance count (high). This is the workhorse and it is what most built-in sensitive information types are.
Exact data match. Instead of describing a shape, the organisation supplies the actual values: a table of student numbers, of patient identifiers, of customer records. The values are hashed with a salt before upload, so the service never holds them in the clear, and matching is then against known values rather than against a pattern. Precision rises sharply and false positives fall. The cost is that somebody must build and refresh the table (high).
Trainable classifiers. A model is trained on examples of a category of document and returns a probability that new content belongs to it. Useful for material that has no pattern at all: a contract, a research proposal, a legal opinion. Microsoft supplies pretrained classifiers and supports custom ones built from an organisation's own samples (high).
Document fingerprinting. For form-shaped material, the template itself becomes the pattern.
Sensitivity labels. The case where a human already answered the question. A label applied to a document travels with it and can be acted on directly, which sidesteps classification entirely, at the cost of depending on labelling discipline.
The error model is the same across all of them and is worth stating plainly. Every knob that reduces false positives increases false negatives. Raising a confidence threshold, requiring more instances, demanding more corroboration: each makes the classifier quieter and blinder in the same movement. There is no setting that eliminates both, and a deployment plan that does not say which error it is choosing to accept has not been written.
Three enforcement locations
The same policy language spans three quite different situations, and the capabilities are not the same in each, which is a persistent source of confusion.
At rest. Scanning content where it is stored: mailboxes, sites, repositories. There is time to be thorough, nothing is happening live, and the output is a map of where sensitive material has accumulated. This is where most organisations discover that the real problem is oversharing rather than exfiltration.
In motion. Inspecting traffic at a network chokepoint. This requires being in the path, and for anything encrypted it requires breaking TLS, with the cost, breakage and proportionality problems Chapter 5 and Chapter 7 set out. In an Australian public-sector institution the proportionality argument against full interception is usually decisive, and the internal source report reaches that conclusion for exactly the reasons Part Five develops.
At the endpoint. On the device, where content exists in the clear before anything encrypts it. What changes here is that enforcement acts on activities rather than files. The catalogue is concrete: copy to clipboard, copy to removable media, copy to a network share, print, upload to a restricted service domain, paste to a supported browser, access by a restricted application (high). This is the location that matters most for AI, because the AI exfiltration event is an activity, not a file movement.
The response ladder, and risk-adaptive enforcement
Audit, warn, warn with justification, block with override, block. Deployments start at the top of that ladder for a reason that is worth making explicit: a policy in audit mode is not a security control at all. It is a measurement of the classifier's behaviour against real traffic, and the first fortnight of alerts is the data that tells you whether the policy is ready to enforce anything. The opening scene of this chapter is what it looks like when audit mode is skipped, or when its output is read as an incident queue instead of as a calibration exercise.
Above that sits risk-adaptive enforcement, where the same policy behaves differently depending on a risk level computed for the individual. Insider risk management assigns users a minor, moderate or elevated risk level from observed activity, and a policy condition can then apply block or block-with-override only to users at those levels, leaving everyone else in audit (high). It is worth checking which policy locations this actually supports, because it is narrower than the marketing implies and Microsoft's own documentation is not consistent about it. Two pages state that adaptive protection currently supports Exchange, Teams and devices; the data loss prevention policy reference also lists unmanaged cloud apps for the same condition (medium; the discrepancy is noted under open questions).
The design appeal is obvious and the design risk is worth naming here rather than in Part Five. Adaptive enforcement means the control an individual experiences depends on a machine-computed judgement about them. That is defensible, and it is a different kind of thing from a uniform rule, and the difference is exactly what a privacy officer will want to discuss.
The shadow AI lens: a prompt is the worst case
Why the classifier struggles. Compare two events. A staff member attaches a spreadsheet of two thousand student records to an external email: the classifier sees thousands of pattern matches with checksums and corroborating column headers, at maximum confidence, unambiguously. A staff member types three sentences into an AI tool describing a student's circumstances in their own words, using no identifier at all, to ask how to word a difficult email.
The second is the more sensitive disclosure by most reasonable judgements. It matches nothing. It contains no pattern, no identifier, no checksum, and nothing a keyword proximity rule can catch. Meanwhile the first staff member's ordinary prose, containing a six-digit figure, matches.
Prompts are short, unstructured, frequently paraphrased rather than pasted, and often sensitive in ways that live in meaning rather than in form. That combination is close to the worst case for every technique in the classification section. AI data loss prevention therefore produces both more false positives and more false negatives than file-based data loss prevention on the same policy, and the honest answer to 'why did it not catch that' is usually that there was nothing there to catch.
The three places a prompt can be intercepted. The clipboard, watched by the endpoint agent on an onboarded device. The upload or paste into the page, seen by the endpoint agent through native integration in Microsoft's browser or through the compliance browser extension in Chrome and Firefox, which is Windows-only and requires the device to be onboarded (high). And the submission of the prompt itself, caught inline by the browser data security built into Edge for Business, which needs no device onboarding at all, because, as Chapters 14, 18 and 19 established, that control lives inside the browser rather than below it (high).
Only the third reaches an unmanaged device, which is why it carries a disproportionate share of any realistic bring-your-own-device posture, and why it is also the one a staff member can step around by using a different browser.
The named policies, read as mechanism. Microsoft's posture management surface offers a set of one-click policies, and they are worth reading as instances of the general model rather than as a feature list. One detects when users visit AI sites, using insider risk browser signals. One detects sensitive information pasted or uploaded to AI sites, in audit mode, across Edge, Chrome and Firefox. One blocks elevated-risk users from pasting or uploading, using adaptive protection. One detects inline in Edge for a selection of common sensitive information types and blocks the prompt from being sent. One collects prompts sent to AI applications in Edge for discovery purposes (high). Each maps onto an interception point and an enforcement location described above.
Metadata or content, and why the default matters. The discovery collection policy covers all users in audit mode and does not capture content (high). Capturing prompt and response content is a separate decision, requiring a collection policy edited to enable content capture, and it is what everything downstream depends on: retention, eDiscovery and communication compliance for third-party AI applications all state the same dependency (high). Retention and eDiscovery for those applications are further restricted to the Edge browser and to a named set of services, currently ChatGPT, Microsoft's consumer chat, Google Gemini and DeepSeek (high).
This is the single most useful fact in the chapter for a conversation with a privacy officer, and it should be led with rather than buried. The default posture detects that sensitive information of a given type was shared, and does not retain what was said. Moving to content capture is a deliberate step up the invasiveness scale that Part Five sets out, and it should be justified, scoped and disclosed rather than switched on because it was available.
The screenshot, the retype, the phone camera, the paraphrase. Content-aware control assumes the content passes through a channel the control is watching, in a form the classifier recognises. A staff member summarising a record in their own words defeats every technique in this chapter, and no configuration change addresses it. Say so early and plainly, because a programme that implies otherwise will be embarrassed by the first incident.
Content that never touches disk is invisible to endpoint classification. Microsoft states the limit directly: if data is never saved to a file on the device, endpoint data loss prevention cannot scan or classify it (high). Typing directly into a browser is exactly that case, which is why the in-browser interception point exists at all.
Some AI applications send content in encoded form to dynamically generated endpoints, which can defeat policy enforcement. This is Microsoft's own documented caveat, and it is a useful antidote to the assumption that 'AI sites' is a settled list that a vendor keeps current on your behalf.
Platform parity is uneven. The endpoint activity table shows macOS support trailing Windows, with paste to supported browsers still in preview on macOS at the time of checking (high). The specific paths an organisation intends to control need testing on the build actually deployed, not read from a matrix.
Adaptive protection does not cover every policy location an author might assume, and the documented list differs between pages, so confirm it in the tenant rather than from a page (medium).
The supported-site list is maintained by the vendor and changes, so coverage is a subscription to somebody else's judgement about what counts as an AI application.
And the failure mode that does not announce itself: false positives are not merely noise, they are a privacy event, because reviewing an alert means a person reads content the programme did not intend to collect. The pressure that creates leads to tuning down, which reduces incident counts, which reads in reporting as success. A programme measuring its own effectiveness by alert volume cannot distinguish that from working.
- Explain the difference between classification and enforcement to a manager who has asked why the data loss product 'missed' a leak.
- Describe the three points at which a prompt can be intercepted, and say which devices each one reaches.
- A colleague proposes going straight to block mode because audit mode 'does not protect anything'. Give the two-sentence reply.
- Explain to a privacy officer what metadata-only collection means in practice, and what specifically would change if content capture were enabled.
- Name the failure mode that no configuration change addresses, and say what you would do about it instead of a technical control.
Glossary terms used in this chapter
activity explorer · adaptive protection · browser data security · collection policy · confidence level · Defined from earlier chapters and reused here · device onboarding · DLP · document fingerprinting · endpoint DLP · exact data match · false positive · inline DLP · Insider Risk Management · Microsoft Compliance Extension · Purview · sensitive information type · sensitivity label · TLS inspection · trainable classifier
Sources
Every Microsoft Learn page below was verified against the Microsoft Learn documentation service on 9 August 2026.
- Microsoft Learn, 'Learn about sensitive information types'. learn.microsoft.com The reference for pattern, keyword, proximity and confidence-level matching, and for the tuning options that trade false positives against false negatives. Last checked 9 August 2026; (high).
- Microsoft Learn, 'Learn about exact data match based sensitive information types'. learn.microsoft.com Supports the description of exact data match, including that the organisation supplies its own schema and values, that these are hashed with a salt so that only hashed values are uploaded, and that the approach results in fewer false positives. Last checked 9 August 2026; (high).
- Microsoft Learn, 'Increase classifier accuracy'. learn.microsoft.com Supports the account of false positives and false negatives as the two error modes of a classifier, and the tuning options for reducing each. Last checked 9 August 2026; (high).
- Microsoft Learn, 'Learn about Endpoint data loss prevention'. learn.microsoft.com The source for the endpoint activity catalogue used in this chapter, including copy to clipboard, paste to supported browsers, upload to a restricted cloud service domain, print and copy to removable media, with their Windows and macOS support status; and for the statement that data never saved to a file on the device cannot be scanned or classified. Last checked 9 August 2026; (high).
- Microsoft Learn, 'Learn about Data Loss Prevention for Cloud Apps in Edge for Business'. learn.microsoft.com Supports the claim that the protection is built into the browser and does not require the device to be onboarded into Microsoft Purview. Last checked 9 August 2026; (high).
- Microsoft Learn, 'Use Microsoft Purview to manage data security and compliance for other AI apps'. learn.microsoft.com Supports the dependency of retention, eDiscovery and communication compliance on a collection policy configured to capture content, and the restriction of those capabilities to the Edge browser and a named set of AI services. Last checked 9 August 2026; (high).
- Microsoft Learn, 'Considerations for DSPM for AI to manage data security and compliance protections for AI interactions'. learn.microsoft.com The source for the named one-click policies described in this chapter, including that the discovery collection policy covers all users in audit mode only and does not capture content. Last checked 9 August 2026; (high).
- Microsoft Learn, 'Help dynamically mitigate risks with Adaptive Protection'. learn.microsoft.com Supports the minor, moderate and elevated insider risk levels, the dynamic application of block, block with override and warning, and the statement that adaptive protection currently supports Exchange, Teams and devices as policy locations. Last checked 9 August 2026; (high).
- Microsoft Learn, 'Learn about Adaptive Protection in Data Loss Prevention'. learn.microsoft.com Supports the integration between insider risk levels and data loss prevention policy conditions. Last checked 9 August 2026; (high).
- Telemetry and Control Options for Shadow AI in an Australian University (this project's internal source report). The source of the invasiveness ladder that this chapter's metadata-versus-content discussion maps onto, of the recommendation against full TLS interception, and of the documented caveat that some AI applications send content in encoded form to dynamically generated endpoints.
Open questions
The list of AI sites supported by Microsoft Purview for browser-based protections, and the narrower list supported for retention and eDiscovery, both change. Check the current supported-sites page before designing coverage claims around either (medium).
macOS endpoint data loss prevention supports a narrower set of activities than Windows and several entries are in preview. Test the specific paste, upload and drag paths you intend to control on the macOS build actually deployed (medium).
Whether adaptive protection is appropriate in an Australian public-sector institution is a proportionality question rather than a technical one, and Part Five takes it up. I am not aware of published Australian sector guidance specific to risk-adaptive enforcement (low).
The policy locations supported by adaptive protection are stated differently on different Microsoft pages: the adaptive protection articles say Exchange, Teams and devices, while the data loss prevention policy reference also lists unmanaged cloud apps. I have not resolved which is current. Check the condition in the policy editor before designing around either list (medium).
Last updated 9 August 2026