Why a phone-number regex cannot solve personal-data detection

A phone-number expression may find the number in a customer message and still miss the personal data that matters most. The same message could contain a name, a delivery landmark, a relationship to another person and a health-related request. A pattern that correctly identifies digits has answered one narrow question.

This is a useful starting point for engineering. Define that narrow question honestly, then decide what additional evidence the workflow needs. Presidio describes a combination of recognisers, patterns, context and machine learning, while explicitly warning that automated detection cannot guarantee that all sensitive information will be found.

A pattern recognises a shape

A regular expression can identify text that resembles a telephone number. Depending on its design, it might allow spaces, brackets or a country prefix. That helps with variation in formatting. It does not establish who owns the number, whether it is active, whether the surrounding passage concerns a person, or whether another identifier was missed.

A long sequence of digits could also be an order reference. A short number could be a meaningful extension in an internal directory. Adding rules can improve a specific workflow, but each change alters what the detector accepts and rejects.

Context can help distinguish these cases. Words such as “call”, “mobile” or their equivalents in the actual messages may strengthen a candidate. Yet context words can themselves vary by language, spelling and channel. Presidio’s analyser documentation supports combining recognisers and context. Treat that mechanism as a design tool, not a universal accuracy claim.

Start with the consequence of a miss

Consider a hypothetical support assistant that sends customer enquiries to a language model. Its engineers want to remove personal identifiers before transmission. A phone-only filter would leave a message such as “Please send the parcel to the blue gate beside my daughter’s school; ask for Meera” largely untouched.

Whether each phrase needs transformation depends on the purpose, identifiability and approved data path. The lesson is that the phone pattern does not decide the whole question. The team needs an entity policy covering names, addresses, identifiers and contextual information, with a documented response when the content does not fit the policy.

Write that policy against the actual task. A telephone-routing service may need a number to complete a call. A demonstration dataset may have no reason to contain any real customer information. The acceptable output is different in each case.

Build two collections, not one success demo

A useful evaluation collection includes examples that should be detected and examples that should remain. Include alternative formatting, adjacent punctuation, line breaks and messages with several numbers. Add confusing examples such as invoice references and public service contact details when those distinctions matter to the policy.

Also include messages with personal data outside the phone-number category. Otherwise the team can report excellent phone matching while leaving its broader privacy objective unevaluated.

For each example, record the expected entity, its exact span and the expected downstream action. Keep the original text protected. Label synthetic fixtures clearly. Use non-functional contact placeholders for workflow tests and document any limitations in format-recognition fixtures.

Presidio’s evaluation guidance recommends measuring detection against the intended use case. Its existence does not supply a score for your dataset. Run the evaluation on held-out cases and report both missed entities and unnecessary detections.

Separate the detector from the decision

A recogniser returns evidence. The application decides what to do with it. Those decisions might include replacing a span, holding a message for review or allowing it through a specifically approved route.

Do not silently treat a low score as proof that a message contains no personal data. A recogniser’s score is not automatically a calibrated probability for the workflow. A threshold should be justified by observed errors and the consequences of those errors.

The same separation helps with failures. If the detector times out, the application should follow an explicit fallback rule. Sending the original payload because detection is unavailable can defeat the purpose of placing the check there.

Questions for the release review

• Which personal-data categories are within this detector’s evaluated scope?
• Which message languages and channels are represented in the evaluation set?
• What plausible non-personal strings does the phone pattern incorrectly capture?
• What happens when text includes an unknown entity or the detector fails?
• Can a reviewer reproduce the result from the fixture, recogniser version and threshold?

A regex remains valuable when its role is clear. It can supply a fast, inspectable signal inside a larger decision process. The release claim should name the categories and conditions that were tested, and leave untested coverage visible.