Exact data matching for AI DLP: test the record

Exact data matching can help AI DLP recognise known structured records, provided the classifier, reference dataset and enforcement path all work together. Test matching and delivery separately, including formatting variants, supporting evidence, newly added records and harmless lookalikes.

Microsoft Purview's Exact Data Match documentation explains a concrete implementation. This guide uses that documentation to propose an evaluation method. No tenant testing was performed, and the article makes no universal claim about coverage across Copilot, browsers or other AI clients.

Start with the records that matter

A general pattern can recognise the shape of an identifier. Exact Data Match, or EDM, compares candidate values against a source table representing the organisation's protected records. Microsoft describes comparison using one-way cryptographic hashes.

That design can improve specificity when many harmless values share a sensitive identifier's format. Its usefulness depends on the quality and currency of the source table. An omitted record or incorrectly prepared field can remain outside the intended match even when the underlying pattern is recognised.

Choose one structured data class for the initial evaluation. Define its owner, authoritative source, refresh process and intended policy outcome. Keep broad confidential prose and information absent from the table in separate test categories so the evaluation states exactly what EDM is expected to identify.

Test the first classifier and supporting evidence

Purview first needs an existing sensitive information type to discover the primary element that triggers an EDM lookup. The rule package also defines supporting evidence, confidence and proximity. These settings determine which combinations qualify as a match.

Use a fictional reference dataset with a deliberately chosen primary pattern and harmless supporting fields. Establish a positive case containing the expected combination. Then vary one property at a time: an identifier absent from the table, missing support, support from another record, or evidence beyond the configured proximity.

Write the expected outcomes from the intended rule before running the cases. A successful positive sample alone would leave overly broad matching undiscovered. Keep the classifier result separate from the eventual allow, audit, redact or block decision.

When the primary format needs a custom sensitive information type, verify that type independently. Microsoft's configurable-matching guidance discusses both built-in and custom classifiers. The general pattern still needs to recognise the variants passed to the exact lookup.

Make formatting assumptions visible

Microsoft's configurable matching guidance allows case-insensitive matching and specified ignored delimiters. The documented defaults are case-sensitive matching and no ignored delimiter characters.

The same guidance says the underlying classifier must support the input variations. Adding a delimiter to EDM configuration therefore leaves a separate prerequisite: the first classifier must discover that version of the value.

Create paired synthetic cases for each authorised normalisation, such as case differences or a chosen separator. Add an unapproved alteration that should remain a mismatch. Record the exact classifier, schema and source-table versions.

If supporting evidence contains several words, examine the documented multi-token matching option and its configuration. Whitespace, token boundaries and proximity deserve explicit cases when they affect the protected records your staff actually handle.

Prove dataset refresh reaches the decision

Use a small fictional record that is initially absent from the reference dataset. Record the baseline result, add it through the approved refresh process, and repeat after the documented processing interval. Keep the old and new source-table versions in the test record.

Perform the reverse case for an entry removed under the organisation's approved data policy. Agree whether other classifiers should continue to identify its format. A change in EDM membership and an overall DLP decision can diverge because several rules may apply.

Monitor rejected uploads and stale data separately from content matches. Assign someone to investigate a missed refresh and define acceptable age for each dataset. The business owner should understand what protection is lost when the reference data falls behind.

Verify the actual AI route

Purview's documented EDM service matrix lists particular DLP locations, including SharePoint, OneDrive, Teams Chat, Exchange Online and Devices. It does not establish that every AI interaction is inspected at the moment content leaves a client.

Map the exact browser, desktop application or connector to its supported policy location and enforcement point. In an authorised test setup, use synthetic records and a controlled destination to verify both the decision and whether the content was delivered. Include an allowed case to confirm legitimate work still completes.

Hashing the reference table describes one data-handling boundary. Ask separately how inspected content, diagnostics and event evidence are processed and retained. The source-table mechanism supplies no blanket privacy conclusion about every part of the workflow.

Compare products using the same cases

Retain matches, misses, harmless lookalikes, refresh delays and observed delivery outcomes as separate results. This makes a vendor comparison useful without reducing it to a detector percentage that hides workflow gaps.

Our AI DLP comparison guide covers the wider selection decision. Exact matching adds a narrower acceptance question: can the chosen control recognise the organisation's current records and apply the intended policy on the route staff use?

Review your AI data boundaries with Promptective.