PII, Masking and Access Control for AI Analytics

The fastest way to kill an AI analytics rollout is one screenshot: a chat answer containing a real customer's SSN, posted in the security team's Slack channel. Everything pauses, reviews spawn, and the project that took six months to approve takes six more to un-freeze.

The prevention is well-understood engineering. Here's the complete pattern.

Where PII actually leaks in AI analytics

An LLM-based analytics system has four leak surfaces, and most teams only think about the first:

1. The answer — restricted values rendered directly to a user who shouldn't see them.
2. The model context — sample rows or query results passed to the LLM to help it reason. Whatever enters context may leave via logs, traces, or the model provider.
3. The generated SQL — literal values embedded in WHERE clauses ("customers named John Smith") end up in query logs.
4. Derived artifacts — dashboards, scheduled reports and exports built from AI answers, forwarded to wide audiences.

A masking strategy that only covers surface 1 is a demo, not a control.

The four-part control

1. Classify automatically, confirm manually

Manual tagging doesn't survive contact with a 3,000-table warehouse. Classification must run at connection time — name patterns (ssn, dob, email), value patterns (regexes over samples), and context (a 9-digit column in a residents table). Auto-flags are then reviewed by a domain owner. In Sema, sensitive columns are flagged as *Restricted* during discovery, before anyone asks a question.

2. Enforce by role, at query time

The same question must behave differently by requester:

Requester	Behavior	Audit event
Viewer / analyst	Refusal with reason — the query never runs	restricted_refusal
Admin / owner	Query runs, values returned masked ([restricted])	restricted_override
Explicitly entitled role	Raw values, business justification recorded	entitled access

The refusal case matters more than it looks: a system that silently drops restricted columns produces subtly wrong answers; one that explains why it refused builds trust and teaches policy. This is a core part of text-to-SQL governance.

3. Keep raw values out of model context

Rule of thumb: the LLM should never hold data the requesting user couldn't see directly. Masking must apply before results or samples reach the model, not just before the UI renders. If your architecture sends raw result sets to the model "to summarize", your compliance boundary now includes your model provider.

4. Audit every decision

Each refusal, mask and override goes to an append-only log with who, what, when and which policy fired. This turns compliance questions ("who accessed patient contact data in June?") into a filter operation, and gives your privacy owner a monthly review artifact instead of a forensic project.

Industry notes

• Healthcare (PHI): classification must cover quasi-identifiers (DOB + ZIP is identifying); default aggressively to masked, with BAAs covering any model provider in the path.
• Financial services: regulators care about provability — the append-only audit log and exportable reports carry the exam, not the masking itself.
• SaaS: the common failure is payroll and support-ticket tables connected "temporarily" for one analysis. Classification at connect-time catches what humans forget.

Why this belongs in the semantic layer

Masking bolted onto each consumer (one policy in BI, one in the chat tool, one in notebooks) drifts immediately. Enforced once in the semantic layer — the chokepoint every question already flows through — policy is inherited by every consumer automatically, including the AI. One place to define, one place to audit, no gaps between tools.

That's the design in Sema: auto-classification at discovery, role-aware refusal and masking, and an append-only audit log on by default. See the broader governance picture in our AI data governance framework, or try it on your own data.