Lessons from the Rise of AI-Drafted DSARs

None of them are novel. What has changed is the requests themselves. They now arrive drafted with the help of AI: longer, more detailed, and often requesting information that may fall outside the scope of the right of access.

10 min read

Individuals are increasingly using AI to draft their subject access requests, and the results are long, structured and confident. They arrive with numbered sub-requests and sections asking for material that was never going to be disclosable; another person’s data, legally privileged advice, or simply more than any organisation must hand over. This post examines the common patterns and process challenges exposed by AI-drafted Data Subject Access Requests (DSARs), together with practical steps for addressing them.


Most organisations do not fail a subject access request because they are careless about privacy. They fail it because nobody put a timetable behind the deadline, or the search was scoped by whoever happened to be free that week, or the redactions were made defensively at 5pm on the final day.


The rules have recently changed, and the Data (Use and Access) Act 2025 (DUAA) rolled it out in phases. February 2026 gave statutory footing to two things: the ability to pause the response clock whilst awaiting clarification, and the standard that a search need only be reasonable and proportionate, not exhaustive. Both matter far more now a single DSAR runs to several pages. The complaints duty followed in June 2026.


Here are the patterns I see most often. Four come back to the standard operating procedure (SOP) that many organisations either drafted once and rarely revisited, or never quite got around to documenting in the first place. An AI-drafted request creates no new failures. It finds the ones you already had, faster.


LESSON ONE · PLANNING


No timetable behind the deadline

Every organisation knows a DSAR has to be answered within a month. Far fewer can tell you what has to be true by day five, day twelve, or day twenty. Nobody discovers the schedule has slipped until the final week, by which point there is no way to recover it. Length makes this worse. The instinct on receiving eight pages of numbered demands is to put it down and come back to it properly, which is exactly what there is no time for later.


THE MITIGATION


On logging, generate the dated milestones: dissect and scope, clarification decision, search complete, review and redaction complete, sign-off, and dispatch. Give the dissection its own milestone, ahead of the clarification decision, because a long request takes real time to read properly.


Give every milestone a named owner rather than a team. Escalate on a missed milestone rather than a missed deadline, because once the deadline itself has gone, all that is left is an apology.


Bonus tip. Set your own deadline a week ahead of the statutory one. Something will go wrong on some requests, and every mishap then costs you the buffer rather than the deadline.


LESSON TWO · CLARIFICATION


Using clarification to buy time instead of to understand the request

The DUAA put “stopping the clock” onto a statutory footing, and it is a genuinely useful provision. Where you process a large volume of information about someone and you reasonably need them to narrow the request, the month pauses while you ask and resumes when they reply.


What it is not is a way to buy three extra weeks. If the request was clear enough to action as received, a clarification email does not stop anything. Sent in week three, it gains you very little.


What an AI-drafted request looks like

Requests now tend to arrive with extensive detail, not ambiguity. It often spans several pages, cites Article 15 and the DUAA, and requests every record and piece of correspondence relating to the individual, regardless of format or whether they are identified by name. It reads as though written by somebody who knows exactly what they want, and that is the difficulty, because they usually do not. Somewhere in those pages is one specific thing they are worried about. Clarification is how you find it. The rest belongs to the model.


Break the request down before deciding whether to clarify

Start by taking the request apart. I group it four ways (see below), which helps identify whether clarification is needed and provides the framework for the search plan discussed in lesson three.

Table 1. A practical framework for breaking down a DSAR and planning proportionate searches.

You can then send a clarification request that is actually useful: these are the systems and records we hold, and the periods available; please confirm which information you would like us to search and over what timeframe. Simply asking someone to "Please clarify your request" is not a question anyone can meaningfully answer or be helpful.


Determining whether information should be disclosed

An AI-drafted request will often ask for things it cannot have, which is no reason to treat the whole of it with suspicion. Take each category on its own terms. The categories below are common examples, but each should be assessed carefully and documented on a case-by-case basis.

Table 2. Common categories of information that may fall outside the scope of disclosure or require further assessment.

THE MITIGATION


Use the SOP’s “dissect and scope” milestone as the test: can you dissect the request and identify where to search? If yes, do not ask for clarification. If not, ask that day and be specific.


Group the request before you answer it (as per table above). The grouping is your clarification question and the first draft of your search schedule. Ask about the period if you ask about nothing else.


Record the reason the request could not be actioned as received. If the pause is later challenged, that note is your evidence.


LESSON THREE · SEARCH


An undocumented search

The reasonable and proportionate standard is now in statute. You are not required to search every system you have ever owned. You are required to make an effort proportionate to the circumstances: the volume of information, how hard it is to locate, and the resources available.


The trap is assuming a reasonable search speaks for itself. If you cannot show what was searched and why, it is hard to prove the search was reasonable. A long request will also try to pull you off the standard, because a list of sixty numbered items invites you to answer sixty numbered items. The grouping you did at scoping and clarification is what lets you describe the search you actually ran.


THE MITIGATION


A documented scoping framework promotes consistency across DSARs, helps colleagues understand where to search and where exclusions may apply, and makes it easier to provide a clear, defensible explanation of how the request was handled. Maintain a standing list of common systems, stakeholders and search approaches, then record any request-specific variations alongside it to create an audit trail of your decision-making.


Where a request arrives as a numbered list, note which grouping answered which item. Answering in the requester’s own order shows nothing was quietly dropped.


LESSON FOUR · REVIEW


Blanket third-party redaction

Information about other people is the hardest part of most disclosures, and the defensive instinct is to black out every name that isn’t the requester’s. That is not what the law says. You do not have to disclose information that would identify another individual unless they consented, or it is reasonable to disclose without consent. 


Over-redaction is a disclosure failure in its own right. It is also, in my experience, the thing most likely to convince a requester that you are hiding something. That challenge becomes harder as volumes increase. A request designed to capture every mention of an individual can generate substantial amounts of third-party information, making late-stage review impractical. 


THE MITIGATION


Keep a redaction schedule in the SOP (see table above): the recurring categories, each with its reason, then apply the judgement per instance. If you cannot articulate in a sentence why a category is withheld, that is a strong signal it should not be. The rationale you do record can then be carried through into the response letter.


For each third party, work through the three questions: can the information be provided without identifying them, by removing the name but keeping the substance? Have they consented? If not, is disclosure nonetheless reasonable?


Keep legal professional privilege as its own line in the schedule. It is decided on different grounds, and where a requester is in dispute with you it is the category most likely to be challenged.


LESSON  FIVE · RESPONSE


Treating the response as the end

Since 19 June 2026, organisations must give individuals a way to make data protection complaints directly, acknowledge those complaints within 30 days, and respond without undue delay. Privacy notices need to say so. A dissatisfied requester now has an internal route, and if you have not built one their route is the ICO. That matters most where the request was large and the disclosure partial.


THE MITIGATION


Make the response letter the start of a process rather than the end of one. State plainly what was searched, what is enclosed, and what has been withheld and why. Where you answered a grouped version of a longer request, show the grouping. Name the internal complaint route and how to use it. Then mention the right to complain to the ICO, in that order. 


If your DSAR procedure has not been updated for the DUAA, it is out of date. It is also worth asking whether it was written for the length of requests you are now receiving.


None of these five fixes require new technology or headcount. Four of them require a single document to be doing its job, an SOP with a timetable attached, a search schedule that grows with every request, and a redaction schedule that carries its own reasoning. The fifth is the internal complaint route. None of them require you to hold a view on AI. A machine-drafted request changes the volume and the tone, and nothing about the standard you are held to.

 

Is your DSAR procedure current?

If your process predates February 2026, it may not yet reflect the current legal position, including the complaints duty introduced in June 2026. I would be glad to review your DSAR procedure against the current position and leave you with a documented one. If you are holding one of these longer AI-drafted requests and are not certain how much of it you must answer, that is a week-one conversation rather than a week-three one.

 

Stay in the loop

If you found this useful, subscribe to the Roseline Data Privacy monthly newsletter and never miss out on our practical data privacy insights, updates, and tips delivered straight to your inbox. No noise, just what matters.

 

Sources & further reading

  1. Information Commissioner's Office, A guide to subject access

  2. Data (Use and Access) Act 2025, commencement of data protection provisions, February 2026

  3. Data Protection Act 2018, Schedule 2, Part 3, paragraph 16, Protection of the rights of others: general

  4. Data Protection Act 2018, Schedule 2 Part 4, paragraph 19, Legal professional privilege.

  5. UK GDPR Article 12(5), manifestly unfounded or excessive requests

Previous
Previous

What makes a good DPO?

Next
Next

Back to school transition: protecting children's data after the Reddit fine