Bridewell's 20-LLM Privacy Policy Audit Lands on 4,603 Words and a Flesch Score of 40.2
Bridewell published the analysis on 15 September 2026, and TechRadar Pro reported it a week later. The firm rated each policy on four things: length, estimated reading time, Flesch Reading Ease score, and how much technical and legal jargon it contained. According to Compare the Cloud's write-up, the policies average 4,603 words and would take the typical reader 19 minutes 44 seconds to get through. That precise figure explains why Bridewell's own release says "just under 20 minutes". TechRadar rounds it to 20.
The Flesch Reading Ease score, which Rudolf Flesch devised in 1948, is a formula based on sentence length and word length. Higher scores mean easier text. It is widely used to score texts, and a score over 60 is good, whereas a score below that is not. Bridewell treats 60 as the level suited to the general public. The 20 policies averaged 40.2. The formula measures how dense the prose is. It does not show whether a particular reader understood a particular clause, so the study tells you how hard the policies are to read, not how many people misread them.
Bridewell's public summary leaves some gaps. It does not list all 20 services, say when the policies were collected, or state the reading speed behind its time estimates. Treat the results as a snapshot of the policies at that moment, not a permanent ranking. Privacy policies change, and a figure for Muse Spark or Kimi K may not match the version live today.
Muse Spark, Kimi K and Cohere Command Sit at the Hard End of the Scale
The outliers are what drove the "over 20 minutes" headline. Bridewell found that Meta's Muse Spark has the longest policy in the sample: more than 14,000 words, which would take an average reader nearly an hour. Length is not its only problem, as the firm says it is also full of legal and technical jargon.
Moonshot AI's Kimi K is shorter but harder going. Kimi K from Moonshot AI is the hardest to parse, scoring 28.1 on the Flesch Reading Ease scale. Its 6,229-word policy takes about 25 minutes to read, less than half the length of Muse Spark's, but it has the lowest readability score in the study. Cohere's Command policy is next. Command by Cohere takes 27 minutes on average, with a Flesch score of 37.6.
ChatGPT, which Bridewell calls the UK's most popular LLM, does better but is still difficult. Its policy is 4,143 words, takes about 17 minutes, and scores 43.6. Bridewell notes that long sentences and legal language still make it hard for an average user. The popularity claim applies to the UK only, so it should not be read as a global ranking.
| Service | Words | Est. reading time | Flesch score |
|---|---|---|---|
| Meta Muse Spark | 14,000+ | nearly an hour | not given in summary |
| Moonshot AI Kimi K | 6,229 | ~25 minutes | 28.1 |
| Cohere Command | not given in summary | 27 minutes | 37.6 |
| OpenAI ChatGPT | 4,143 | ~17 minutes | 43.6 |
| Study average (20 services) | 4,603 | ~19m 44s | 40.2 |
TechRadar suggests that the more complex the model, the longer its policy. Bridewell's published figures do not test that idea, and the Kimi K example cuts against it: the policy with the hardest prose was far from the longest.
Academic Research on 74 Versions of LLM Privacy Policies Points the Same Way
Bridewell is a security consultancy, and its release ends with a pitch for its AI security consulting services. That is a reason to check its findings, and independent academic work reaches similar conclusions.
A longitudinal study posted to arXiv in November 2025 looked at 74 historical privacy policies and 115 supplemental privacy documents from 11 LLM providers across 5 countries up to August 2025. Its conclusion was blunt: "they are substantially longer, demand college-level reading ability, and remain highly vague." Help Net Security, which covered that research, reported that the average policy reached about 3,346 words, which is about 53 percent longer than the average for general software policies published in 2019.
The academic work also explains why the documents keep growing. New features introduce new data types and new usage scenarios, and rules differ across regions, which leads to new disclosures. Providers tend to build on top of existing text rather than revise it, so each update adds more material for users to work through. Bridewell predicts the same trend. The researchers add that the main policy is often not the whole story: providers publish extra documents such as model training notices or regional supplements.
The two studies measured different things. The academic sample is smaller in number of providers and older, with an average near 3,346 words against Bridewell's 4,603. Both still conclude that LLM privacy policies are long, get longer, and are written at a level most people struggle with. The researchers also flagged vague wording: providers often use wording that avoids firm commitments by relying on terms like may or might. A long, hedged policy is harder to act on than a long, precise one.
Training on Prompts Is the Clause 13 of the 20 Services Share
Reading time is only an inconvenience on its own. The finding with real consequences is what the policies say. Bridewell found that 13 of the 20 services train their models on user inputs and outputs. Some let users opt out and some do not. TechRadar adds that even where an opt out is possible, it isn't always clear how to action it.
Chris Linnell, Associate Director of Data Privacy at Bridewell, framed it as a question of who carries the burden. Opting out is left to users, he said, and the policies assume people have read and understood them, which many have not, especially on personal accounts. For businesses, his warning is that "employees may be at risk of sharing highly sensitive or confidential information that may end up being used to train LLMs."
Keep the scope in mind. Saying a service trains on inputs and outputs means its policy allows that use. It does not mean every prompt ends up inside a model. And training is only one way a provider handles your data. Retention, human review, sharing with subcontractors and storage location are separate questions, and an opt-out from training does not answer any of them.
ChatGPT's Data Controls Split Privacy Into Four Separate Switches
OpenAI's documentation shows how many separate settings sit behind what users think of as one privacy choice. ChatGPT is the service named most often in coverage of the Bridewell study, so it is a useful example. The details below apply to OpenAI only.
OpenAI states that for its individual services, including ChatGPT, Sora and Operator, it may use your content to train its models. Users can opt out in ChatGPT under Settings > Data controls, or through OpenAI's privacy portal by choosing "do not train on my content". The opt-out only applies to new conversations. Sora has its own settings, and OpenAI says a change made in the ChatGPT interface does not change Sora. The privacy portal opt-out does cover both.
The other controls work independently:
- Memory settings live in Settings > Personalization, separate from the model-improvement setting under Data controls.
- Temporary Chats do not appear in history, do not create or update memories, and are not used for training while they stay temporary. OpenAI may still keep a copy for up to 30 days for safety purposes.
- Saving a Temporary Chat turns it into a regular chat, which then follows the account's personalisation and model-improvement settings.
- Deleted chats are removed from OpenAI's systems within 30 days, unless they were already de-identified and separated from the account, or OpenAI must keep them for security or legal reasons.
Human access is a separate question again. OpenAI's help centre says a limited number of authorised staff and contracted service providers can access user content to investigate abuse or security incidents, to provide support, to handle legal matters, or to improve models unless the user has opted out. Its advice is direct: do not enter sensitive information you would not want reviewed or used.
Turning off training, then, does not make a conversation private in any broader sense. It covers one of at least four ways OpenAI handles your data. Any service with a 4,000-word policy is likely to have a similar set of separate controls. OpenAI simply documents its own well enough to see them.
Personal ChatGPT and Chatbot Accounts Are Where Enterprise AI Policy Breaks Down
The biggest risk for organisations comes from a survey Bridewell cites. It found that 77 percent of employees had pasted company information into AI or LLM tools, and 82 percent of those used a personal account. Bridewell's page gives no sample size, date or methodology for that survey, so treat the numbers as an indication of the problem, not a precise measurement.
Account type matters because providers treat business and consumer accounts differently. OpenAI says that by default it does not use content from ChatGPT Business, Enterprise, Edu, ChatGPT for Healthcare workspaces, or its API Platform to improve its models, although organisations can choose to share data where that option exists. Its older policy page uses the name "ChatGPT Team" for the business tier. Either way, the commitment is about training. It is not a promise of zero retention or immunity from other processing. Linnell says enterprise AI agreements usually bar the provider from training on inputs and outputs and give the organisation oversight of what is shared. When an employee uses a personal account, none of that applies.
The legal exposure is on the organisation's side. Linnell warns that if client or company data goes into LLMs without a lawful basis, there are potential data protection breach concerns. For a UK or EU business, that is a GDPR question as well as a security one. This article's own view: an employee who never reads a 17-minute ChatGPT policy has not turned on the opt-out, and the company data they paste in falls under consumer terms the company never agreed to.
What this means for you
If you set AI policy for an organisation, act now. Assume some staff are already pasting work data into personal chatbot accounts, and give them an approved, managed option with the default training exclusion before trying to police the unmanaged ones. Individual users can wait on none of this either: the settings take a few minutes to check, much less than the policy takes to read.
- Check whether your account is personal or managed by your organisation before entering work data. Providers such as OpenAI apply different default training rules to each.
- In a personal ChatGPT account, open Settings > Data controls to turn off model improvement, and remember it only applies to new conversations.
- Check Sora or other products from the same provider separately. OpenAI says a change in the ChatGPT interface does not carry over to Sora.
- Treat Temporary Chat as a way to avoid training and memory, not retention. OpenAI may keep a copy for up to 30 days.
- Give employees written guidance on which data classes must never go into any AI tool, whatever the opt-out settings say. Bridewell's own advice pairs clear internal rules with properly configured enterprise accounts.
- Recheck policies and settings from time to time. Academic research shows LLM providers keep adding to their policies as they ship new features.
Bridewell's numbers turn a familiar complaint into something measurable. A roughly 20-minute average and a readability score of 40.2 mean that for most people, the privacy policy is not really part of the decision to use a chatbot. Both Bridewell and the academic researchers expect policies to keep growing as providers add agents, memory and regional supplements. The practical response for IT teams is the one Linnell describes: move work use onto managed accounts with contractual training exclusions, and keep the policy text for the lawyers.