AI data discovery for PII and PHI: how LLMs classify columns

AI data discovery for PII and PHI uses a language model to read your database catalog, the table names, column names and data types, and label each column as personal, financial, health or secret data. It finds sensitive columns that keyword rules miss, such as abbreviated legacy names, without reading the records themselves. This post is for security, privacy and database teams who need an inventory of where personal and health data lives. It explains how metadata classification works, where it falls short, what it means for privacy, and how it compares with regex and sampling scanners.

Sensitive data discovery is the process of locating data that needs extra protection, such as personal, health, payment and authentication data, across databases and file stores, and labelling it so that access controls, monitoring and compliance reporting can target it.

What counts as PII and PHI in a database?

NIST SP 800-122 defines PII as “any information about an individual maintained by an agency”, including information that can distinguish or trace an individual’s identity and “any other information that is linked or linkable to an individual, such as medical, educational, financial, and employment information.” The guide adds that elements which identify no one on their own can identify a person when combined, which matters for discovery: a postcode column and a birth date column in the same table carry more risk together than apart.

HIPAA’s definition, in the HHS regulation at 45 CFR 160.103, makes protected health information individually identifiable health information that is transmitted or maintained in electronic or any other form. It covers information about a person’s physical or mental health, care or payment for care that identifies them, or where there is “a reasonable basis to believe the information can be used to identify the individual.” In a database, that usually means patient identifiers, medical record numbers, diagnosis and procedure codes, and any table that links them to a person.

Class	Typical column names	Framework it usually maps to
Personal data (PII)	FIRST_NAME, NATIONAL_ID, PHONE_NUMBER, USR_EML_V2	GDPR, UK GDPR, India’s DPDP Act
Health records (PHI)	PATIENT_MRN, DIAGNOSIS_CODE, PT_DOB	HIPAA
Financial and cards	CREDIT_CARD_NUM, BANK_IBAN, TX_AMT_GROSS	PCI DSS
Secrets	PASSWORD_HASH, API_TOKEN, AUTH_BLOB	Internal security policy

Three ways to find sensitive data, compared

Discovery tools use one of three broad methods, and many combine them. Our sensitive data discovery glossary entry covers the term; the methods differ in what they read.

Name rules. A fixed list of keywords is matched against column names. Microsoft’s SQL Data Discovery & Classification in SSMS, for example, scans a database “for columns (based on column names only)” and returns recommended classifications for a person to accept or change. Rules are fast and read no data, but they miss names outside the keyword list.

Content inspection. The scanner reads values and tests them against detectors. Google Cloud’s Sensitive Data Protection describes built-in infoType detectors, custom dictionaries and regular expression detectors that match on content. This finds a card number whatever the column is called, but it needs read access to the data and costs time on large tables. That is why sampling exists: Google’s guidance is to start with one table “and use sampling”, and to enable sampling where it is available to reduce latency. Sampling trades coverage for speed, since sparse values may fall outside the sample.

Language-model classification of metadata. A model reads names and types and infers meaning the way a DBA would. It reads no values.

Method	Reads data values	Handles cryptic names	Catches mislabelled columns	Main cost
Name rules	No	Poorly	No	Keyword list upkeep
Content regex and dictionaries	Yes	Yes (ignores names)	Yes, for well-formed patterns	Data access, scan time, false matches
Row sampling	Yes, a subset	Yes	Partly, depends on sample	Missed sparse values
LLM on metadata	No	Well	No	Model hosting and review effort

How LLM classification of column names and types works

The model receives a structured description of new columns and returns a label and a confidence for each. SWOT DAM’s Sensitive Data Sentinel is a worked example, and its documentation describes the cycle:

1. Every 24 hours a background scheduler gathers newly created table and column definitions from each monitored database’s catalog.
2. It sends those definitions, names and types only, to the configured model: OpenAI’s gpt-4o-mini, your own Azure OpenAI deployment, or a local Ollama model.
3. The model answers in strict JSON structured output, so every column comes back in a fixed shape.
4. Each column is labelled as PII, financial, PHI or authentication and cryptographic secrets, with a confidence score.
5. The labels appear in the console, mapped to frameworks such as GDPR, PCI DSS 4.0 and HIPAA.

The model’s advantage is context. USR_EML_V2 in a USERS table beside USR_PHN reads as an email address; TX_AMT_GROSS in TRANSACTIONS reads as a monetary amount. A keyword rule for “email” or “amount” matches neither.

Limits of metadata-only discovery

Metadata classification is only as good as the names it reads. Know where it fails before you rely on it.

• Generic names. A column called ATTR_3, NOTES or PAYLOAD can hold anything. Free-text fields often carry health details or names typed by staff, and no name-based method will flag them.
• Misleading names. A column renamed during a migration may no longer hold what its name says. Only content inspection catches that.
• Combinations. NIST’s point about linkable data applies: a model labelling one column at a time may rate a postcode as low risk when the table also holds birth dates and gender.
• Model error. Language models produce confident mistakes. Confidence scores help you order a review queue; they are not proof.
• Coverage of the catalog. Discovery sees the databases it is pointed at. Copies in data warehouses, exports and test environments need their own scans.

A sound programme uses metadata classification for breadth and speed across every database, then applies content checks to generic or high-risk columns that the model cannot judge.

Privacy considerations when using a language model

Sending metadata is safer than sending records, but it is not nothing. Table and column names can reveal a product roadmap, an acquisition, or the fact that you hold a particular kind of health data. Decide where the model runs as you would for any processor.

Model host	What leaves your network	Questions to settle
Public API (for example OpenAI)	Column names and types	Provider’s data retention and training terms, region, contract
Your own cloud deployment (for example Azure OpenAI)	Names and types, to your tenant	Tenant region, access control, logging
Local model (for example Ollama)	Nothing	Server capacity, model choice, patching

For regulated environments where schema metadata may not leave the network, a local model removes the external transfer entirely. Record the decision in your data protection impact assessment either way.

Using AI data discovery results for PII and PHI

An inventory is only useful if controls use it. In SWOT DAM, the mass-read alert rule fires when one query reads more than 50,000 rows from a table flagged as PII or financial, so the Sentinel’s labels decide which tables that rule watches. The same labels show auditors where personal and health data lives, which supports a HIPAA risk analysis or a record of processing. Our guide to database activity monitoring explains how those alerts fit with the rest of the audit trail, and the HIPAA compliance page covers the wider control set for health data.

Discovery rollout checklist

• List every database, warehouse and non-production copy that may hold personal or health data.
• Choose the model host and record the decision in your DPIA.
• Run a first classification across the estate and export the results.
• Send each data owner their columns to confirm, correct or reject.
• Flag generic and free-text columns for content inspection.
• Review tables where several quasi-identifiers appear together.
• Point monitoring and alert rules at the confirmed sensitive tables.
• Schedule daily runs and a manual scan after each major migration.

Next steps

AI data discovery classifies PII and PHI columns from names and types, which gives you a broad, privacy-preserving inventory, while content checks cover the columns whose names say nothing. Confirm the results with data owners and connect them to monitoring so the inventory changes what you watch. See how the Sensitive Data Sentinel works on your schemas on the SWOT DAM product page, or book a demo.