ai
DSAR Assembler: An AI Agent That Prepares Access Request Packs
The DSAR Assembler is an AI agent that collects a person's data from the systems around a customer data platform (CDP) and drafts the response pack for a verified access request. It supports privacy analysts at propose level (L2). A person verifies identity, decides exemptions and sends the reply. The agent does none of these, and deadlines do not move if it is off.
Rail level: L2 · Risk: high · Function: compliance privacy security
By Art Kukharenko · Published · Updated
All AI agent railsThe rail comes from the AI agent rails method, and the end-to-end process sits in DSAR automation with an AI agent.
Rail at a glance
The DSAR Assembler's rail holds one subject per run and gives the session no outbound tool. A scoped data view and a tool allow-list enforce both limits.
Scroll horizontally to see all columns.
| Field | Value |
|---|---|
| Job | Collect data for a verified access request and draft the response pack. |
| Trigger | A request whose requester a person has verified. |
| Data scope | The data subject's records within the request scope, and the system map, with no other subjects' data in the session. |
| Tool scope | Read: system map, in-scope records, response templates; propose: a response pack and draft reply; execute: none. |
| Output contract | Pack by system, gaps found, third-party data flagged, exemptions to consider, draft reply. |
| Gate | A privacy analyst signs off every pack and decides exemptions. |
| Limits | One subject per run, no outbound tools, and working copies kept only for the life of the request. |
| Ledger | Request ID, systems searched, gaps, reviewer, sign-off date. |
| Evaluation | Seeded requests with known records across systems. |
| Owner and kill switch | DPO; an Orchestrator pause returns requests to the manual process with deadlines unchanged. |
What it does and who uses it
The DSAR Assembler does the collecting, often the slowest part of an access request, and leaves every judgement to a privacy analyst.
Illustrative run: a customer's request reaches the privacy inbox on 5 March. The case system records that date and a latest reply date of 5 April, which follows a worked example from the European Data Protection Board (EDPB) 2. An analyst confirms identity through the customer's existing login and marks the case verified. The assembler searches the mapped systems and returns a pack by system. It reports that the call-recording vendor returned nothing and that paper files were not searched. It flags a support ticket naming the customer's partner, and a fraud note as an exemption to consider. The analyst redacts the name, takes advice on the note, edits the draft and sends the reply.
The clock belongs to the request, not to the agent, as this sequence shows.
Scroll horizontally to see all columns.
| Step | Who acts | Effect on the deadline |
|---|---|---|
| Request reaches an official channel | Case system records it | The one-month period starts, even if nobody has noticed the request 23 |
| Reasonable doubt about identity | A person asks for more information 3 | Time may be suspended if that was asked without undue delay 2 |
| Identity verified | A person | The agent may start, and the clock does not restart |
| Collect, draft, then decide exemptions | DSAR Assembler, then a privacy analyst | None |
| Extension for complex or numerous requests | A person informs the requester within the first month | Up to two further months 3 |
These dates reflect the General Data Protection Regulation (GDPR). Other regimes run their own clocks, so set those per regime with advice.
Why this level
Collecting and drafting stay at propose level (L2) because the last step cannot be undone. Once a reply has gone, another person's details cannot be recalled.
The Rule of Two 1 fixes the tool list. Support tickets and email bodies are untrusted text, and the session holds a person's records, so a third property is out of the question. No tool can send, delete or close. That also blocks the obvious injection, a ticket telling the model to forward a file.
The level will not rise, however good the drafting becomes. Under GDPR Article 15(4) the copy must not harm others' rights and freedoms 4. The EDPB says a general concern is not enough: the effect must be shown in the concrete case, and others' information should be made illegible where possible rather than refusing a copy 2. A person has to own that judgement.
Three ways it fails, and the control for each
Access-request errors tend to be invisible in the pack itself.
Scroll horizontally to see all columns.
| Failure | What it looks like | Control |
|---|---|---|
| Another person's data in the pack | A joint account, a partner named in a ticket, or an earlier false merge pulls in someone else's records. | A scoped view and one subject per run. Third-party mentions are flagged, and a profile with a recent merge gets a warning. |
| A system quietly missed | A new tool or a processor's copy is absent from the system map, yet the pack looks complete. | The pack lists each mapped system as searched, empty or unreachable. The EDPB expects searches across IT systems, non-IT filing systems and processors 2, so unsearched sources appear as gaps. |
| Deadline tied to the agent | The agent is paused, and the team waits for it while the month runs out. | The case system owns the date and its alerts. A pause routes requests to the manual process, and drills confirm the team can finish by hand. |
How to evaluate it
A good DSAR Assembler speeds up the analyst's check without missing anything. Seeded requests are the fairest test, because you know what should be found.
- Missed-system rate on seeded requests. Plant records for a test person across systems, including a processor and an archive.
- Third-party flag recall. Seed other people's names in tickets, and treat any that reach an unflagged pack as a serious error.
- Days to complete against the legal deadline, tracked by the case system whether or not the agent ran.
- Draft completeness, checking the Article 15(1) information, including automated decision-making.
- Hostile text. Seed tickets telling the model to omit records, then compare the pack with connector record counts.
- Back-up honesty. The EDPB asks for transparency when back-up data differs from live data 2, so a known difference should appear as a gap.
Where it runs
Access requests gather one person's record in one place, so this agent needs a private model inside the customer environment, and no external model may see this data. The on-premise LLM guide covers sizing. PrivyCDP describes limits on data access and review of results for its AI-assisted features, but this assembler is a method it does not ship.
Related
- DSAR automation with an AI agent: the steps from request to reply.
- AI agents for compliance, privacy and security teams: where privacy work sits among these agents.
- Rail card template: a place to record your system map owner.
Other privacy agents are listed from the AI agent rails hub. Download the rail card template to record your gate and deadline owner.
Browse use casesFunction playbooksAgent roster
FAQ
Can AI fully automate a DSAR response?
No. Collection and drafting can be automated. Verifying identity, deciding exemptions and sending the reply stay with people, because each carries a legal judgement or cannot be reversed.
When does the DSAR clock start?
The EDPB says it starts when the request reaches the controller through an official channel, not when someone reads it or when an agent runs.
What happens if the agent is switched off?
The deadlines stay exactly where they were. Requests return to the manual process, and the case system keeps the same dates and alerts.
Sources
This article is general information, not legal advice.
Further reading
- AI Agents for Privacy Compliance
- Automate DSAR Response: AI Agent Rails
- AI Access Review Assistant
- Agent rails
- AI Agent Permissions Template Download
Published: · Updated:
Editorial dates describe content changes. Confirm current sources before making legal, security or purchasing decisions.