Personally identifiable information (PII) is any data that can identify a specific person — either on its own, or when combined with other information that is reasonably available. It covers direct identifiers, quasi-identifiers, and sensitive categories. PII privacy is the practice of keeping that data from being exposed, mishandled, or shared beyond its approved use.
That practice matters most at the moment content gets shared, because a proposal, dashboard, or AI-generated page inherits whatever personal data its source material contained — and a shared link travels further than a document ever did.
What is PII privacy?
PII privacy refers to the policies, controls, and handling practices used to protect personally identifiable information from unauthorized access, disclosure, or misuse. It is the difference between knowing a field is sensitive and having a workflow that prevents that field from leaving the building.
The phrase sounds simple, but the reality is context-dependent. A full name alone may not be sensitive in one workflow, yet a full name paired with an email address, phone number, physical address, account number, or login detail can quickly move into regulated or high-risk territory. In enterprise settings, the real question is not only whether data qualifies as PII. It is whether exposing it creates legal, contractual, reputational, or customer trust risk.
That is why mature teams treat PII privacy as part of the sharing workflow, not a policy document collecting dust in a folder named Final_Final_Approved_v7.
What PII stands for, and what PII data means
PII stands for personally identifiable information. PII data means any information that can be used to identify a specific individual — either on its own, or when combined with other information that is reasonably available.
Two clauses in that sentence do all the work. "Identify a specific individual" rules out genuinely aggregate data: a count of visitors from Ohio identifies nobody. "Combined with other information" rules the aggregate back in the moment the count is one person from a town of 400 who also appears in your CRM.
Different frameworks use different words for the same idea. Privacy law in the EU and UK uses "personal data," which is broader than the American term and explicitly includes online identifiers. US state privacy laws mostly say "personal information." Healthcare regulation in the US uses "protected health information" for the medical subset. Security frameworks say PII. For operational purposes, treat them as one question asked in four dialects: can this reach a person?
The practical consequence for a sales or marketing team is that you cannot look up a definitive list of PII fields and stop thinking. The list is a starting point. The judgment is about combination.
Direct identifiers, quasi-identifiers, and sensitive categories
Types of PII data sort cleanly into three tiers, and the tier determines how carefully you handle the field. Direct identifiers point at one person by themselves. Quasi-identifiers point at one person only in combination. Sensitive categories carry elevated consequences if exposed, regardless of how easily they identify anyone.
The US National Institute of Standards and Technology describes this using two words worth borrowing: linked and linkable information. Linked information is data that is already associated with a specific person — a name attached to an account number. Linkable information is data that could be associated with a person through some further step, such as cross-referencing a public record or another dataset you happen to also hold. Both are in scope. The second is the one teams forget, because each field on its own looks innocuous.
That is the linkability test, and it is the most useful single question in this whole subject: what else would someone need in order to turn this into a person, and how hard would it be to get? If the answer is "our own lead list, which is attached to this same email," the field is PII.
A first name in isolation may not matter. A first name inside a complaint summary tied to an employer, account status, and meeting date probably does. Healthcare, financial services, education, and enterprise B2B environments often apply stricter internal rules than generic definitions suggest, which means the operational question is not "is this legally PII everywhere?" It is "would our legal, security, or compliance team want this shared this way?" That standard tends to survive contact with reality.
Is an email address PII? And what counts as customer PII?
Yes — in most frameworks, an email address is PII. Under EU and UK data protection rules it is explicitly personal data. Under most US state privacy laws it counts as personal information. Under the NIST framing it is linked information when it contains a name, and linkable information when it does not.
The reason is the linkability test. margo.sterling@example.com contains a first name, a surname, and an employer in one string; it identifies a person without any further step. Even an opaque address such as b7k22@example.com is a unique key that can be joined to a marketing database, a breach corpus, or your own CRM. The address does not have to be self-describing to be identifying.
Customer PII is the same set of fields, scoped to people outside your organization: the contact details, account identifiers, billing references, support history, and behavioral records you hold about buyers and their employees. It is worth naming separately because it usually arrives under a contract. A master services agreement or data processing addendum frequently commits you to handling it more carefully than any statute requires — which means a customer's work email can be a contractual problem in a shared page even where it is a legal non-event.
The useful takeaway is not "email is dangerous." It is that a page holding one recipient's email is a different object from a page holding six hundred of them, and the definition alone will not tell you which one you built.
What PII looks like in AI outputs
AI-generated content contains PII more often than teams expect, because the model is not the source of the risk — the prompt is. Most teams assume exposure begins with training data. In practice the faster problem is output generation: users hand personal data over in prompts, paste in source documents, connect business systems, or ask for highly specific personalization.
Consider a normal workflow. A marketer asks a model to generate a follow-up microsite for a prospect. A revenue analyst uploads account notes to improve the personalization. A support lead requests a summary of a complaint thread. Nobody is trying to leak anything. They are trying to save time, and the resulting artifact inherits whatever the source material contained.
AI outputs also inherit context from the tools around them. If a model can reach customer records, ticketing systems, form submissions, or internal notes, the generated result may blend structured and unstructured data into one polished artifact. That artifact looks harmless precisely because it reads like a finished asset rather than a raw record dump.
The specific places PII hides in generated content are worth memorizing:
- Personalized pages — customer names, titles, email addresses, and company context pulled from notes and presented as body copy.
- Meeting and call summaries — attendee lists, direct dial numbers, health details mentioned in passing, billing disputes.
- Generated tables and reports — embedded rows carrying account owner names, contact fields, and support ticket references.
- Sample and placeholder values — a code snippet or rendered preview where the "example" data was copied from something real.
- Non-visible source — HTML comments, hidden form fields, metadata, and leftover variables that never render on screen but travel with the file.
Teams spot secrets like API keys faster than they spot personal data, because a token looks obviously dangerous. An email address inside a neatly formatted block of content looks normal. That is exactly why it gets missed — and why generated HTML deserves its own review step.
There is a line here worth drawing carefully, because it is not "never mention a person." Personalization is often the point. If a rep sends a password-protected page to one intended recipient and the content includes that recipient's name and company, that is reasonable. If the same page also carries private account notes, direct contact details for uninvolved individuals, or support history copied out of an internal system, the line has been crossed. Good governance does not ban personalization; it limits unnecessary exposure.
What PII scanning actually does
PII scanning inspects content for personal and regulated data before that content is stored, shared, or published. At the mechanical level it is pattern matching: rules that recognize the shape of a Social Security number, a credit card, an email address, a phone number, a passport number, a date of birth, a street address, an API key. Some scanners add a contextual layer that reasons about whether a name in a sentence is a real person or a placeholder.
It helps to know exactly which categories a scanner can catch on its own. HTMLvault's built-in scanner is regex-based, runs on every link, and costs zero AI tokens. It flags nine categories: Social Security numbers, financial account data, API keys and secrets, passport numbers, physical addresses, person names, dates of birth, email addresses, and phone numbers.
Scanning is not the same thing as a traditional data loss prevention program, and the difference matters during a security review. DLP is generally strong at monitoring email, endpoints, and sanctioned repositories. It is weaker where teams move quickly through lightweight publishing and AI-assisted work. The gap shows up in awkward ways: strict controls on attachments, no consistent gate for hosted HTML pages, previews, or browser-based share links. A scanner positioned at the point of sharing covers the workflow that generic controls tend to miss. It complements DLP; it does not replace it.
Be honest about what pattern matching cannot do. Broad rules produce false positives — a scanner that flags every ten-digit number as a compliance event will train users to dismiss warnings, which is worse than no scanner. Narrow rules miss edge cases. And regex sees strings, not meaning: it will catch jordan@example.com and miss "the buyer at the regional distributor who filed the complaint in March," which identifies someone just as effectively to anyone who knows the account. That contextual gap is the reason an AI layer exists as an option on top, and the reason human review still has a job.
A practical standard: what to do with each tier
The workable standard is three questions asked in order, before anything is shared. Does this output identify a real person? Is that identification necessary for the use case? Does the sharing method match the sensitivity of what is inside? If the answer to the third question is vague, the process is already too loose.
Mapped onto the tiers, that produces rules a team can actually follow:
- Sensitive categories — never in a shared page. Not redacted, not password-protected: removed. There is no business reason for a credential or a health note to sit in a proposal.
- Direct identifiers — allowed only for the person they belong to, and only on a controlled link. One recipient's name and company on a page sent to that recipient is fine. Six hundred of them in an export is a lead list, and a lead list is not a marketing asset.
- Quasi-identifiers — run the linkability test. Keep the business context, drop the fields that make the combination identifying. This is where redaction earns its place: the useful version of the page usually survives losing the account number.
What changes when PII lands in a shared link is distribution. Generation is one stage; sharing is where risk compounds. A page containing personal data raises a different set of questions the moment it has a URL: who can open it, whether it is indexed, how long it stays live, whether anyone can prove what was in it, and what happens when the recipient forwards it. Those are answerable with settings — configurable expiry, password protection, retention windows, no search indexing, an audit trail — or they are answerable with a shrug. Only one of those survives procurement.
Practically, that is what a tool in this category should give you: a scan that runs on every link, redaction before publication, configurable link expiry (from one hour to never on paid plans), retention windows you set down to auto-delete, password protection, links that are never indexed, and — on Teams and Enterprise — custom roles and audit logs, with SSO/SAML as a paid add-on on Teams and included on Enterprise. The scan is reachable from wherever the HTML gets written: the scan_html MCP tool and the REST API let Claude, ChatGPT, Zapier, Clay, Gemini, or any script check content before a link exists. Teams and Enterprise plans can add the AI scan layer by connecting their own Anthropic, OpenAI, or Google key, billed to that key rather than ours.
Common mistakes teams make with PII
The most common mistake is assuming internal drafts are low risk. In reality, drafts are where the worst content lives, because they contain raw exports, unreviewed prompts, placeholders, and copied records.
The next mistake is thinking PII only means highly regulated data. Teams protect Social Security numbers scrupulously and still casually expose names, emails, phone numbers, and internal identifiers that create real privacy and phishing risk.
A third is using generic sharing methods with no governance. Public links, inbox attachments, and unsecured previews are convenient, and convenience without controls tends to become an incident report.
The fourth mistake is treating "it depends" as a reason not to set a standard. Context-dependence is real — a gated internal prototype with test addresses is not a customer-facing page built from live CRM data, and a draft sent to two founders is not a client deliverable distributed across four agencies. But if a workflow regularly handles HTML that may contain names, emails, account data, prompts, or embedded secrets, it deserves a written rule rather than a case-by-case debate.
The last mistake is pretending the controls are free. Passwords add a step. Expiry requires forethought. A review gate can slow a launch by an afternoon. That friction is the actual cost, and it is worth stating plainly, because the alternative is a silent failure mode where sensitive content spreads further than anyone intended and nobody notices for nine months.
PII privacy, in the end, is about reducing preventable exposure while keeping work moving. For the sales rep, that means sending the proposal at 11:40 p.m. without wondering what came along with the export. For the marketer, it means shipping the page and knowing the date it comes down. For the RevOps lead assembling a report from four systems, it means the handoff gets inspected instead of trusted. And for the IT reviewer, it means the answer to "what happens if this link gets forwarded" is a setting rather than a shrug.