# PII Detection — User Guide

Oversai can find personal information (PII) in text, such as names, email
addresses, phone numbers and card numbers. It can also give you back a copy of
the text with that information hidden. Use it to clean conversation transcripts,
notes or exports before you share them or analyze them further.


YOUR DATA STAYS PRIVATE

 * Everything happens inside Oversai. The text is not sent to any outside AI
   service or third-party provider.

 * Nothing is saved. The text you submit and the results are not written to any
   database or log. Once the response comes back, nothing is kept.

 * You must be signed in. Only authenticated Oversai users can use it.

--------------------------------------------------------------------------------


HOW DETECTION WORKS

Detection uses two complementary methods together:


1. PATTERN RECOGNITION (STRUCTURED DATA)

Many kinds of personal data have a fixed format. Email addresses always have an
@ and a domain, and card numbers follow known lengths and pass a checksum (the
Luhn algorithm). For these, Oversai matches the text against those known formats
and runs validation checks where they exist.

 * Strengths: consistent and precise. A valid card number or email is almost
   always found.

 * Typical confidence: high (often 0.75–1.0).


2. LANGUAGE UNDERSTANDING (UNSTRUCTURED DATA)

Names of people, places and organizations follow no fixed format. “Jordan” can
be a person or a country. For these, Oversai uses a natural-language model that
reads the surrounding words to decide what a word refers to.

 * Strengths: finds information that no pattern could describe.

 * Trade-off: results depend on context, so they are less certain. Expect lower
   confidence scores and occasional mistakes (see Known limitations below).


CONTEXT BOOSTS CONFIDENCE

If words like “phone”, “card” or “email” appear near a match, the detector
becomes more confident that the match really is that type of information.


CONFIDENCE SCORES

Every detection has a score from 0 to 1 that shows how sure the detector is:

Score

Meaning

0.9 – 1.0

Very likely correct, usually a validated pattern (email, card number)

0.6 – 0.9

Likely correct (names, phone numbers)

below 0.6

Possible match; review before relying on it

You can set a minimum score (score_threshold) so that only detections at or
above it are returned. By default no minimum is applied (0.0), so every
detection is returned, including low-confidence ones.

--------------------------------------------------------------------------------


WHAT CAN BE DETECTED

Structured (pattern-based):

Type

Example

EMAIL_ADDRESS

maria.lopez@acme.com

PHONE_NUMBER

415-555-0132

CREDIT_CARD

4095-2609-9393-4932

IBAN_CODE

GB82 WEST 1234 5698 7654 32

IP_ADDRESS

192.168.0.1

MAC_ADDRESS

00:1A:2B:3C:4D:5E

URL

acme.com/account

CRYPTO

Bitcoin wallet addresses

DATE_TIME

12 March 2025

US_SSN, US_ITIN, US_PASSPORT, US_DRIVER_LICENSE, US_BANK_NUMBER

US identifiers

UK_NHS

UK NHS number

MEDICAL_LICENSE

US medical license numbers

Unstructured (language-based):

Type

Example

PERSON

Maria Lopez

LOCATION

Madrid, 5th Avenue

ORGANIZATION

Acme Corp

NRP

Nationality, religious or political group

AGE

34 years old


LANGUAGE SUPPORT

English only. Text in other languages may still have structured data (emails,
card numbers) detected, but names and places will be unreliable.
Country-specific identifiers outside the US and UK (for example Spanish NIF/NIE
or Italian fiscal codes) are not supported at this time.

--------------------------------------------------------------------------------


HIDING THE DETECTED INFORMATION

You can choose how detected information is hidden:

Method

Result for maria.lopez@acme.com

Best for

Replace (default)

<EMAIL_ADDRESS> or your own label, e.g. [REDACTED]

Readable transcripts that still show what was removed

Mask

********************, or partially masked, e.g. ****-****-****-4932

Keeping part of a value visible (such as the last digits of a card)

Redact

(removed entirely)

Shortest output, no trace left

Hash

a3f1… (a fixed-length fingerprint)

Matching the same value across records without revealing it

> Tip: custom labels cannot contain angle brackets (< >). Use [REDACTED] or ***
> instead.

If a piece of text is matched as more than one type (for example, a card number
that is also recognized as a date), Oversai resolves the conflict automatically
when hiding it, so the value is replaced only once.

--------------------------------------------------------------------------------


ACCURACY: HOW IT IS TESTED


WHAT IS TESTED TODAY

Oversai runs automated tests on every code change. They check that:

 * Common PII is found. A reference sentence that contains a name, an email, a
   phone number and a card number must have all four detected, at the correct
   positions in the text.

 * Hidden data is really gone. After anonymization, the original name, email and
   card number must no longer appear in the output.

 * Each hiding method behaves exactly as described. Replace, mask (full and
   partial), redact and hash are each checked against the exact expected output.

 * Filters work. Restricting detection to one type returns only that type, and a
   minimum score removes every detection below it.

 * Clean text is left alone. Text without personal information comes back
   unchanged and with no detections.

 * Invalid requests are rejected with a clear error instead of returning partial
   results.


WHAT THIS DOES — AND DOES NOT — GUARANTEE

These tests confirm that the feature works correctly and reliably detects
common, clearly written PII. They are not a statistical accuracy benchmark.
Oversai has not yet measured detection rates (how much real PII is caught, how
many false alarms there are) against a large set of real-world conversations,
and publishes no precision or recall figures today.

In practice:

 * Structured data (emails, card numbers, IBANs, IP addresses) is highly
   reliable, because it follows strict formats and is often validated with
   checksums.

 * Names, places and organizations are good but not perfect, and quality depends
   on how the text is written.


KNOWN LIMITATIONS

Situation

What can happen

Names written in lowercase, misspelled, or from speech-to-text transcripts

A name may be missed

Uncommon or non-English names

A name may be missed or get a low score

Abbreviations and acronyms (e.g. “IP”, “ID”)

May be wrongly tagged as an organization

Long number sequences

May be tagged as more than one type (e.g. card number and date)

Email addresses

The domain part may also show up as a URL

Non-English text

Names and places are unreliable

Non-US/UK national IDs

Not detected

> ⚠️ Automatic detection reduces risk but does not remove it. For regulated or
> highly sensitive data, combine it with a human review step.

--------------------------------------------------------------------------------


BEST PRACTICES

 1. For maximum protection (catch as much as possible): keep the minimum score
    low (0.0–0.3) and accept that some non-PII words may be hidden too.

 2. For readable output (fewer false alarms): set a minimum score of about 0.6,
    and/or limit detection to the structured types you care about.

 3. When you only care about payment data: restrict detection to CREDIT_CARD and
    IBAN_CODE, and use mask to keep the last digits visible.

 4. Check a sample first. Before processing large volumes, run a few
    representative conversations and review what is caught and what is missed.

 5. Keep a human in the loop for anything shared outside your organization.

--------------------------------------------------------------------------------


FAQ

Is my text sent to ChatGPT, Claude or any other AI provider? No. Detection runs
entirely inside Oversai’s own infrastructure.

Is the text stored anywhere? No. Neither the input nor the result is saved.

Why was the first request slow? The first request after a period of inactivity
loads the language model and can take a few seconds. Requests after that are
almost instant.

Why does the same text show two detections? The two detection methods can both
flag the same value, for example a phone number. When you anonymize, Oversai
merges these automatically.

Is there a size limit? Yes. Up to 50,000 characters per request.

Can it detect PII in Spanish (or another language)? Not reliably today. Only
English is supported.