Data Subject Request SLA Governance

2. Summary

Data Subject Request SLA Governance requires that AI agent systems track and meet time-bound regulatory obligations for every category of data subject request — access (DSAR), deletion (erasure), rectification (correction), portability, restriction, and objection. The system must implement automated request routing, SLA tracking with escalation, multi-system data discovery (across all agent data stores including memory, caches, vector databases, and derived artefacts), response assembly, and delivery within the legally mandated timeframe. This dimension ensures that the complexity of AI agent architectures — with data distributed across multiple stores, contexts, and derived artefacts — does not prevent organisations from meeting their legal obligations to data subjects.

3. Example

Scenario A — DSAR Failure Due to Distributed Agent Data: A data subject submits a DSAR to a financial services firm. The privacy team searches the primary customer database and provides the structured record within 20 days. However, the data subject's personal data also exists in: 3 AI agent conversation logs (customer service, financial advice, complaint handling), a vector database used for RAG retrieval, a feature store containing derived risk scores, an archived model training dataset, and a third-party enrichment cache. None of these are included in the DSAR response. The data subject complains to the ICO, which conducts an audit and discovers the additional data stores. Result: ICO enforcement notice for incomplete DSAR response, GBP 500,000 fine, and mandatory DSAR process remediation including a complete data mapping exercise across all agent systems.

What went wrong: The DSAR process only searched the primary database. AI agent data stores were not included in the data discovery scope. No data mapping existed that included agent conversation logs, vector stores, or feature stores. The organisation could not provide a complete account of the data subject's personal data.

Scenario B — Deletion Request Partially Fulfilled: A data subject exercises their right to erasure under GDPR Article 17. The organisation deletes the customer record from the primary database within 25 days. However, the data persists in: agent conversation logs (retained for quality), a vector database embedding derived from the customer's interactions, a model training dataset snapshot, and a backup tape. The data subject submits a follow-up DSAR 6 months later and discovers that their data still exists in the organisation's systems. Result: ICO finding of failure to comply with erasure request, second fine, and mandatory implementation of a comprehensive data discovery and deletion framework.

What went wrong: The deletion process did not cover all data locations. AI-specific data stores (vector databases, training snapshots) were not in scope. No verification step confirmed that deletion was complete across all systems.

Scenario C — Multi-System DSAR Correctly Executed: A data subject submits a DSAR to a healthcare organisation. The automated DSAR workflow: (1) registers the request with an SLA timer (30-day GDPR deadline), (2) queries the data discovery registry for all data stores containing data for the subject, (3) retrieves records from: the patient database (structured), 4 AI agent conversation logs (unstructured), 2 vector database entries (embeddings — extracted to human-readable summaries), 1 feature store entry (risk score with provenance), and 1 third-party enrichment record, (4) assembles the response with redaction of third-party personal data, (5) delivers the response at day 22, (6) logs the complete DSAR lifecycle. Result: Complete DSAR response delivered within the statutory timeframe. Audit finds full compliance.

4. Requirement Statement

Scope: This dimension applies to all AI agent systems that process personal data of data subjects who have rights under applicable data protection law. It covers all categories of data subject request: access (GDPR Article 15, CCPA Section 1798.100), erasure (Article 17, CCPA Section 1798.105), rectification (Article 16), portability (Article 20), restriction (Article 18), and objection (Article 21). The scope extends to all data stores that may contain personal data associated with the data subject, including but not limited to: primary databases, agent conversation logs, agent working memory, vector databases, feature stores, model training datasets, enrichment caches, backup systems, and third-party processors. If any agent component holds personal data, it is in scope for data subject requests. Agents that process only anonymised data verified as non-reversible are excluded.

4.1. A conforming system MUST maintain a comprehensive data discovery registry mapping every data store that may contain personal data, including all AI agent-specific stores (conversation logs, vector databases, feature stores, memory systems, and derived artefacts).

4.2. A conforming system MUST implement automated SLA tracking for every data subject request, with configurable SLA deadlines per request type and jurisdiction (e.g., 30 days for GDPR DSAR, 45 days for CCPA).

4.3. A conforming system MUST execute data discovery across all registered data stores when processing a data subject request, not only the primary database.

4.4. A conforming system MUST assemble a complete response covering all discovered data, including data in AI agent-specific stores, in a format that is comprehensible to the data subject.

4.5. A conforming system MUST implement automated escalation when a request approaches its SLA deadline (at minimum at 50% and 80% of the deadline), notifying responsible personnel.

4.6. A conforming system MUST verify, for erasure requests, that deletion has been completed across all registered data stores, including agent-specific stores, and retain a verification record.

4.7. A conforming system SHOULD implement automated retrieval from AI agent data stores, converting machine-readable formats (embeddings, feature vectors, serialised objects) to human-readable summaries where direct presentation is not meaningful.

4.8. A conforming system SHOULD support concurrent multi-jurisdiction SLA management, applying the most restrictive deadline when a data subject's data is processed across multiple jurisdictions.

4.9. A conforming system MAY implement self-service data subject request portals that provide real-time status updates on request processing.

5. Rationale

Data subject rights are fundamental to every major data protection framework. GDPR Chapter III establishes rights of access, rectification, erasure, restriction, portability, and objection. CCPA Section 1798.100 et seq. provides rights to know, delete, correct, and opt out. LGPD Articles 17-22 provide equivalent rights. Each framework imposes strict timeframes: 30 days under GDPR (extendable to 90 in complex cases), 45 days under CCPA (extendable to 90).

AI agent architectures create unique challenges for data subject request fulfilment because personal data is distributed across a wider range of stores than traditional applications. A conventional customer service application might store data in a primary database and a CRM. An AI agent system may store data in: the primary database, multiple agent conversation logs, vector databases used for semantic retrieval, feature stores containing derived attributes, model training dataset snapshots, agent working memory (persisted across sessions), enrichment caches from third-party sources, and backup systems. A DSAR that only searches the primary database is inherently incomplete.

The vector database challenge is particularly acute. When an AI agent uses retrieval-augmented generation (RAG), customer interactions may be embedded as vectors in a vector database. These embeddings encode personal data in a format that is not directly human-readable. A complete DSAR response must either extract and summarise the embedded content or explain that the data exists in encoded form and provide the source content from which the embedding was derived.

For deletion requests, the challenge is ensuring completeness. Deleting the primary database record while leaving conversation logs, embeddings, and feature store entries intact does not satisfy Article 17. The deletion must propagate to every store (intersecting with AG-320 for consent-based deletion), and the organisation must be able to verify that propagation is complete.

SLA management is critical because regulatory penalties for missed deadlines are increasing. The ICO has specifically cited DSAR response failures in enforcement actions. The CNIL fined Clearview AI EUR 20 million in part for failure to respond to data subject requests. As AI agents generate more personal data across more systems, the risk of SLA breaches due to incomplete data discovery grows.

6. Implementation Guidance

The core architecture for AG-325 is a data subject request management platform that orchestrates request intake, multi-system data discovery, response assembly, and SLA tracking.

Recommended patterns:

• Centralised DSR management platform. Implement a dedicated platform that receives all data subject requests, classifies them by type, assigns SLA deadlines based on request type and data subject jurisdiction, and orchestrates the fulfilment workflow. The platform maintains a data discovery registry listing every data store, its data custodian, the API or query mechanism for retrieval, and the expected response time. On request receipt, the platform queries all registered stores in parallel, collects results, assembles the response, and tracks progress against the SLA. Dashboard visibility shows: requests in progress, SLA status (green/amber/red), response completeness, and escalation status.
• AI data store connectors. Build dedicated connectors for each AI agent data store type: (1) conversation log connector — retrieves and formats conversation records for a specific data subject, (2) vector database connector — queries by subject identifier, retrieves associated embeddings, and maps them back to source documents for human-readable presentation, (3) feature store connector — retrieves derived features and their provenance, (4) model training data connector — queries training dataset snapshots for subject presence and returns affected records, (5) memory system connector — queries persistent agent memory for subject-related entries. Each connector returns data in a standardised format for assembly.
• Escalation and SLA management engine. Track each request against its jurisdictional SLA. At 50% of the deadline (day 15 for a 30-day GDPR DSAR), send an amber notification to the data custodian. At 80% (day 24), send a red escalation to the DPO. At 95% (day 28), escalate to senior management. If the deadline is missed, log the breach and trigger the extension process (if legally permissible) or the regulatory notification process.

Anti-patterns to avoid:

• Treating DSR fulfilment as a manual, ad-hoc process. Manual searching of individual systems is error-prone and unscalable. As the number of agent data stores grows, manual discovery will miss stores, miss records, and miss deadlines.
• Excluding AI agent data stores from the data map. The most common failure. Organisations map traditional databases but do not include conversation logs, vector stores, feature stores, or training data. Every data store containing personal data must be in the discovery registry.
• Providing raw machine data to data subjects. Returning a vector embedding or a serialised feature vector to a data subject does not satisfy the accessibility requirement. Machine-readable data must be translated to human-comprehensible format.
• Deleting from the primary database and calling it done. Erasure requests must be fulfilled across all data stores. Verification must confirm completeness. A partial deletion is a failed deletion.
• Ignoring SLA management until the deadline approaches. Without proactive tracking and escalation, SLA breaches are discovered only when they have already occurred. Automated tracking with graduated escalation prevents most breaches.

Industry Considerations

Financial Services. DSARs in financial services are complex due to the volume of transaction records, regulatory retention obligations, and the interaction between erasure rights and record-keeping requirements. The system must correctly apply exemptions (e.g., retention required for AML/KYC) while fulfilling the request for all non-exempt data.

Healthcare. Patient DSARs may involve clinical records with long retention periods, sensitive health data requiring additional security in response delivery, and interactions with multiple healthcare providers. Response assembly must include appropriate clinical context and redaction of third-party health data.

Cross-Border Operations. Data subjects in different jurisdictions have different deadlines and different rights. A data subject in the EU has 30-day DSAR rights; the same person making a CCPA request has 45-day rights. When data is processed across jurisdictions, the most restrictive deadline applies. AG-013 cross-referencing is essential.

Maturity Model

Basic Implementation — A DSR management system tracks requests and SLA deadlines. Data discovery covers primary databases and agent conversation logs. Responses are assembled manually. Escalation occurs at 80% of the SLA deadline. This level meets minimum requirements but may miss data in vector stores, feature stores, and training datasets.

Intermediate Implementation — Automated data discovery queries all registered data stores in parallel, including AI-specific stores. Connectors for vector databases and feature stores translate machine-readable data to human-comprehensible format. SLA tracking includes 50% and 80% escalation thresholds. Deletion verification confirms completeness across all stores. Responses are assembled automatically with manual review before delivery.

Advanced Implementation — All intermediate capabilities plus: self-service portal with real-time status updates. Concurrent multi-jurisdiction SLA management applies the most restrictive deadline. Automated response quality checks verify completeness before delivery. Predictive SLA monitoring identifies at-risk requests before escalation thresholds. Independent testing confirms that data discovery is complete across all stores. Average DSAR response time is below 15 days.

7. Evidence Requirements

Required artefacts:

• Data discovery registry. Complete mapping of all data stores containing personal data, including AI agent-specific stores, with data custodians and retrieval mechanisms.
• SLA compliance report. Analysis of all data subject requests over the reporting period showing: request volumes by type, average response times, SLA compliance rate, and breach details for any missed deadlines. Minimum 12 months.
• Sample DSAR responses. At least 10 redacted DSAR responses demonstrating multi-system data discovery, AI data store inclusion, and human-readable formatting.
• Deletion verification records. At least 10 erasure request records showing verification of complete deletion across all registered data stores.
• Escalation log. Records of SLA escalations demonstrating that the escalation mechanism functions and that escalated requests were resolved.

Retention requirements:

• DSR case records: minimum 5 years (to demonstrate compliance to regulators).
• Data discovery registry: retain current version and all prior versions for 3 years.

Access requirements:

• Producible to regulators within 48 hours. SLA compliance reports producible on demand.

8. Test Specification

Test 8.1: Multi-System Data Discovery

• Stimulus: Submit a DSAR for a data subject whose personal data exists in: the primary database, 2 agent conversation logs, 1 vector database, and 1 feature store. Verify that the response includes data from all 5 sources.
• Expected behaviour: The data discovery process queries all registered stores and retrieves data from each.
• Pass criteria: The response includes data from all 5 stores. No store is missed.
• Fail criteria: Data from any registered store is missing from the response.

Test 8.2: SLA Escalation Triggering

• Stimulus: Create a DSAR with a 30-day SLA. Allow the clock to reach day 15 without completion.
• Expected behaviour: An amber escalation notification is sent to the data custodian at day 15 (50% of SLA).
• Pass criteria: The escalation is triggered at the correct threshold. The notification is delivered to the correct recipient.
• Fail criteria: No escalation is triggered, or the escalation is triggered at the wrong threshold.

Test 8.3: Complete Erasure Verification

• Stimulus: Submit an erasure request for a data subject. After processing, query all registered data stores for any remaining records associated with the data subject.
• Expected behaviour: No records for the data subject remain in any registered store (except those retained under a separate lawful basis, which are documented).
• Pass criteria: Verification confirms complete deletion. The verification record documents each store checked and the outcome.
• Fail criteria: Records persist in any store without documented exemption.

Test 8.4: Vector Database Data Retrieval

• Stimulus: Submit a DSAR for a data subject whose interactions have been embedded in a vector database. Verify that the response includes a human-readable representation of the embedded data.
• Expected behaviour: The vector database connector retrieves the embeddings, maps them to source content, and presents a human-readable summary.
• Pass criteria: The response includes comprehensible information derived from the vector database. Raw embeddings are not presented without explanation.
• Fail criteria: Vector database data is omitted from the response, or raw embeddings are provided without human-readable context.

Test 8.5: Jurisdiction-Specific SLA Application

• Stimulus: Submit two DSARs: one from an EU data subject (30-day SLA) and one from a California data subject (45-day SLA). Verify that the correct SLA is applied to each.
• Expected behaviour: The EU DSAR has a 30-day deadline. The California DSAR has a 45-day deadline.
• Pass criteria: Jurisdiction-specific SLAs are correctly applied. Escalation thresholds correspond to the correct SLA.
• Fail criteria: A single global SLA is applied regardless of jurisdiction.

Test 8.6: Burst Request Handling

• Stimulus: Submit 200 DSARs simultaneously. Verify that all are registered, SLA timers are started, and data discovery proceeds for all.
• Expected behaviour: All 200 requests are registered. SLA tracking is active for each. Data discovery proceeds without dropping requests.
• Pass criteria: All 200 requests are processed within their respective SLAs. No request is dropped or lost.
• Fail criteria: Requests are dropped, or SLA timers fail under volume.

Conformance Scoring

• Score 0: No DSR management system exists — requests are handled ad-hoc with no SLA tracking.
• Score 1: A DSR tracking system exists but data discovery covers only the primary database. AI agent data stores are not in scope. SLA tracking is manual.
• Score 2: Automated data discovery covers all registered data stores including AI-specific stores. SLA tracking with graduated escalation is operational. Deletion verification confirms completeness. Vector database and feature store data is presented in human-readable format.
• Score 3: Verified by independent testing confirming complete multi-system discovery. Self-service portal with real-time status. Multi-jurisdiction SLA management. Predictive SLA monitoring. Average response time below 15 days. Zero SLA breaches in most recent reporting period.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
GDPR	Article 12 (Transparent Communication of Rights)	Direct requirement
GDPR	Articles 15-22 (Data Subject Rights)	Direct requirement
GDPR	Article 12(3) (One-Month Response Deadline)	Direct requirement
CCPA/CPRA	Sections 1798.100, 1798.105, 1798.106 (Rights to Know, Delete, Correct)	Direct requirement
UK Data Protection Act 2018	Sections 43-48 (Data Subject Rights)	Direct requirement
LGPD (Brazil)	Articles 17-22 (Data Subject Rights)	Direct requirement
EU AI Act	Article 86 (Right to Explanation)	Supports compliance
NIST AI RMF	GOVERN 1.3, MANAGE 4.2	Supports compliance

GDPR — Articles 12 and 15-22 (Data Subject Rights)

Article 12(3) requires the controller to provide information on action taken on a request "without undue delay and in any event within one month of receipt of the request." This period may be extended by two further months for complex requests, but the data subject must be informed of the extension within the first month. AG-325 implements this through automated SLA tracking with escalation. Articles 15-22 define the specific rights — access, rectification, erasure, restriction, portability, and objection — each of which requires the controller to search its systems comprehensively. AG-325's multi-system data discovery ensures that AI agent data stores are included in this search.

CCPA/CPRA — Sections 1798.100, 1798.105, 1798.106

The CCPA provides rights to know (access), delete, and (under CPRA) correct personal information. The response deadline is 45 days, extendable to 90 days with notice. AG-325's jurisdiction-specific SLA management applies the CCPA deadline for California data subjects while applying the GDPR deadline for EU data subjects. The CCPA's requirement to "search for the personal information it maintains" maps to AG-325's comprehensive data discovery.

LGPD — Articles 17-22

The LGPD provides data subject rights broadly parallel to GDPR, including access, correction, anonymisation, and deletion. AG-325's multi-jurisdiction SLA management includes LGPD timeframes and right categories.

10. Failure Severity

Field	Value
Severity Rating	High
Blast Radius	Per-data-subject for individual failures; organisation-wide for systemic DSAR process failures

Consequence chain: Missed DSAR deadlines are a direct, easily provable regulatory violation. The data subject has a timestamped request and the organisation has either responded within the deadline or not. The ICO has issued enforcement notices specifically for DSAR failures, and the CNIL has imposed fines exceeding EUR 20 million where DSAR non-compliance was a contributing factor. For AI agent systems, the risk is amplified by incomplete discovery: the organisation may believe it has responded completely but has missed agent data stores, leaving the response incomplete. An incomplete DSAR response discovered in a regulatory audit is treated more severely than a delayed response because it suggests systemic failure in data management. The operational impact of DSAR non-compliance includes: increased complaint volumes (data subjects who receive incomplete responses escalate), regulatory investigations (multiple complaints trigger pattern investigation), and remediation costs (mandatory process redesign, data mapping exercises, and system integration). For organisations processing data at scale, a systemic DSAR failure affecting thousands of data subjects creates class-action-equivalent regulatory exposure.

Cross-references: AG-059 (Data Classification & Sensitivity Labelling), AG-060 (Consent & Lawful Basis Verification), AG-061 (Data Subject Rights Execution), AG-063 (Privacy-by-Design Integration), AG-013 (Multi-Jurisdictional Compliance Mapping), AG-319 (Purpose-Consent Granularity Governance), AG-320 (Consent Revocation Propagation Governance), AG-322 (Data Minimisation by Design Governance), AG-324 (Automated Profiling Notice Governance), AG-328 (Data Localisation and Transfer Logging Governance).