by PrivScan (LX AI)
A privacy-policy gap is any place where your published notice does not match what the product actually does with personal data. AI features create gaps quickly, because they add collection points that a template written before the feature existed never mentions.
When a user types a prompt or uploads a file, the text or binary often leaves the browser and goes to a model provider. I have seen many teams treat this as a transient step that does not need disclosure, but the moment the data can be linked to an individual it becomes personal data under GDPR and similar laws.
Older privacy notices were written around account data and cookies. They list categories like “name”, “email”, “usage logs”. Prompt text and file uploads are not mentioned, so the notice is silent.
| Data point | Disclosure needed | Example wording |
|---|---|---|
| Prompt text | Purpose: model inference; Retention: 30 days | We send your prompts to https://www.nist.gov/itl/ai-risk-management-framework for inference and keep them for 30 days to improve response quality. |
| Uploaded file | Purpose: feature extraction; Retention: until deletion request | Uploaded images are processed to extract features and are stored until you delete your account or request removal. |
Notice that the table includes a live link to the NIST AI Risk Management Framework, which provides guidance on documenting model‑related data flows.
Many products keep logs of prompts, outputs, and internal scores for debugging, abuse detection, or model monitoring. These logs are often retained longer than user‑account data, creating a mismatch.
If the log contains a user‑specific identifier (even a hashed email) or can be combined with other data to re‑identify a person, the log falls under personal data. I have seen cases where a simple session ID combined with a known IP range allowed re‑identification.
When you add these items, the notice moves from silent to explicit, closing a common gap.
Early privacy templates rarely listed “image”, “audio”, or “generic file” as data types. AI features that accept these inputs create new collection points that the notice does not cover.
Templates were built around text fields and cookies. When a product adds an image‑upload‑to‑recognize‑objects feature, the notice still talks only about “user‑provided text”. The omission is a gap.
Even if the model does not store the raw file, the act of transmitting it to a third party is a transfer of personal data.
Adding these lines makes the notice match the product’s actual behavior.
When model output influences a user’s rights — such as granting a loan, showing a job, or moderating content — the notice must explain the logic and the consequences.
Many teams put a vague line like “we use AI to improve experience”. That is insufficient when the output has legal or material effects.
I want to be honest about the limits of the advice above. This guide does not promise that following it will give you 100 % compliance, nor does it claim that you will never miss a gap.
Treat this as a practical starting point, not a final certification.
I keep a written checklist next to every release that touches this topic. The list is boring on purpose: name the owner, name the evidence artifact, and name the rollback. If a step cannot produce a file, a ticket, or a log line, it is not a step — it is a wish.
| Signal | What to record | Stop-ship? |
|---|---|---|
| Unexpected write or send | Tool name, args, identity | Yes until gated |
| Missing confirmation on destructive action | Call path and bypass | Yes |
| Untrusted text treated as instruction | Source surface and resulting action | Yes for agent reach |
| Scanner clean, judgment open | Deferred items + owner | Only if core path safe |
privacyscan helps with the measurable first pass. Architecture choices, legal sign-off, and customer-facing claims still need a human owner. Treat every checklist row as decision support, not a certificate.
When a prospect asks whether the product "covers everything," I answer with the boundary: automated checks catch known patterns; novel chains and policy judgment still need review. That honesty keeps support load down and keeps the blog aligned with what the product actually does.
If you need a second opinion, pair this write-up with the references below and with your own staging reproduction. Do not skip the reproduction step just because a model wrote a confident summary.
It can be. If the prompt can be linked to an identified or identifiable person, it falls in scope and needs to be covered by the notice.
Recipients of personal data are normally disclosed. Naming the provider, or at least the category and location, is the safer disclosure.
If user content is used to train or improve a model, say so plainly. Silence on that point is one of the most-read lines of any AI privacy notice.
On every material change to what you collect or which providers you use — for AI products, that is usually more often than once a year.
No. It reports the gaps it can detect from the site and your description. Drafting the disclosure still needs a human.
No. It is a decision-support checklist, and a reviewer still has to confirm the facts.
It scans your site for common GDPR gaps - cookie-consent granularity (Art. 7), lawful-basis statements (Art. 6), and data-retention notices (Art. 13/14) - then scores readiness from 0 to 100.
No. It is decision-support that flags likely gaps; final assessments should be confirmed with a qualified privacy professional.
EU GDPR by default, with UK GDPR and global guidance selectable in the input.
A weighted check of consent, lawful basis, retention, and tracker transparency; the demo returns a sample 54/100 with cited articles.
Pro exports the full scan and remediation checklist; Free includes one watermarked run per day.
It analyzes the URL plus your described data practices; deeper SPA crawling is on the roadmap.
Try the product: PrivScan