AI Wrote Your Privacy Policy. Who Checks It?

Ask Claude or ChatGPT for a privacy policy and you'll have one in twenty minutes. A data protection impact assessment (DPIA), a retention policy, a record of processing activities: same story. The documents arrive well-structured, correctly headed, confident. For a firm that has been putting compliance off, it feels like the problem just solved itself.

Here is the question your insurer, the ICO, and eventually a client will ask about that folder: who checked it?

Regulators read a DPIA a model drafted the same way they read one a human typed. What they read closely is whether it describes your firm truthfully. And that is where AI-drafted compliance documents fail, in a specific and repeatable way that we can demonstrate with a live example.

The certification claim the summaries get wrong

In early August 2026 we re-checked every claim in our own published documents that can go stale, every one, against the primary source. Most held. Two failed, the same way, and one of them is the perfect specimen.

Ask a summary of AI vendor compliance and there is a good chance it will tell you OpenAI is certified under the EU-US Data Privacy Framework. Comparison sites say it. Vendor round-ups say it. Until early August, a page on this site said it.

The official DPF register says otherwise. Searched by legal entity name, under every status, as at 11 August 2026 OpenAI has no record: no active certification, no lapsed one, nothing. OpenAI's own Data Processing Addendum, updated December 2025 and effective 1 January 2026, agrees, because it never mentions the Framework. The DPA does the work instead: the Standard Contractual Clauses incorporated directly, OpenAI Ireland as the contracting entity for EEA and Swiss customers, the UK Addendum applied to UK data. Anthropic is the same, no register record and SCCs in the DPA, and a page of ours repeated that error too. Of the three big model vendors, only Google LLC actually holds the certification.

This is a fact that costs one query to check, and it is wrong across a large part of what the internet says about these vendors. Which means it is wrong in the training data. Which means a model drafting your ROPA can, with complete confidence, record the Data Privacy Framework as your transfer safeguard for OpenAI, and your own records will then certify a protection that does not exist. If a regulator or an opposing solicitor reads that entry next to the register, they will treat the rest of your documentation as unverified too.

A model is a good writer trained on sources that are wrong in checkable ways, and nothing in the drafting step does the checking.

The three ways an unverified draft fails

It repeats the industry's errors. The certification claim is one specimen of a class. Retention defaults, sub-processor lists, training-data policies, which contract terms apply to which account tier: these are precise, checkable facts that vendor summaries get wrong constantly, and the models learned from the summaries. The draft inherits every error, delivered fluently.

It invents your firm. A privacy policy states what data you collect, who you share it with, and how long you keep it. A DPIA describes your systems and your safeguards. The model knows none of this, so it fills the gaps with plausible defaults: a tidy list of processors you may not use, retention periods nobody in your firm has ever agreed, a lawful basis chosen because it is the one that usually fits. The result reads convincingly, and it describes a generic firm with your name at the top. Your privacy notice is public and instantly checkable, and when it does not match what you actually process, that mismatch is the first red flag a regulator sees, before anyone even asks about the incident that brought them to your door.

It goes stale silently. A compliance document is a snapshot of moving facts. OpenAI's current DPA took effect on 1 January 2026, and most of the round-ups and summaries still have not caught up. Vendors change retention defaults, add sub-processors, restructure which entity you contract with. The EU AI Act's transparency duties have applied since 2 August 2026. A document that was right when generated drifts out of truth without anything looking different on the page.

A document nobody checked is evidence against you

The accountability principle in UK GDPR asks you to demonstrate compliance, and your documentation is how you do it. That cuts both ways.

Producing a folder of policies proves you knew the obligations existed. If the folder turns out to be unverified boilerplate (generic processors, invented retention periods, a transfer safeguard the register refutes), the folder itself shows how seriously the obligations were taken. In a reportable breach, a difficult subject access request, or a professional indemnity claim, the paperwork is exhibit one. Wrong paperwork reads as a firm that wanted the appearance of compliance at the lowest possible effort, and it hands whoever is across the table the easiest finding of their week.

Draft with AI, then verify every load-bearing claim

We use these tools daily, and drafting with them is sensible. The draft was always the cheap part. The expensive part of compliance work has always been knowing which claims in a draft are load-bearing and checking each one against the primary source: the register, the vendor's actual contract, your firm's actual practice.

If your AI has already produced your compliance folder, here are five checks you can run yourself this week.

1. Check every transfer claim against the register. For any US vendor in your documents, search its legal entity name at dataprivacyframework.gov, both statuses. If there is no record, the Framework carries nothing for you. Then open the vendor's DPA and search the text for "Standard Contractual Clauses": no register record and no SCCs in the contract is a finding. Write down what you found and the date you looked.

2. Check the processor list against reality. Does the document name the vendors your firm actually uses, including whatever connects your AI tools to your mailbox or accounting system? A generic list is a tell that nobody looked.

3. Check the retention periods against practice. Whatever the document promises, ask whether the firm actually deletes anything on that schedule. If the firm cannot prove deletion on that schedule, the stated period is a documented promise a regulator can test.

4. Read your privacy notice next to your actual processing. List what you genuinely collect and every tool it flows through, then read the public notice. Every mismatch is visible to a regulator from their desk.

5. Check the dates. Find the effective date on each vendor document your folder cites, then open that vendor's live terms page and compare. OpenAI's current DPA, for example, took effect on 1 January 2026, and a citation to anything older dates the whole folder. For anything user-facing that reaches EU users, check the folder reflects the AI Act transparency duties that have applied since 2 August 2026.

If you would rather have it verified by someone accountable, that is what a £500 written scoping review is: your documents against your actual systems, every finding traced to a primary source, priced next steps for anything that needs rewriting, and the £500 deducted from the project fee if you proceed. The deliverable states what was verified in place, and when, with a CIPP/E-certified practitioner's name on it. That form of words is the one an insurer or procurement reviewer can rely on.

The tools will keep getting better at drafting. They still cannot put a name behind the claim that the document is true, and that is the part an insurer or a regulator needs.