Consent Revocation Propagation Governance requires that when a data subject withdraws consent for a specific processing purpose, the withdrawal propagates through every system component that holds or processes the affected data — including agent memory, caches, downstream processors, derived models, enrichment pipelines, and third-party recipients. The withdrawal must take effect within a defined SLA, and all affected data must be deleted, anonymised, or flagged as unusable within that window. Processing must cease immediately upon revocation, even if deletion of all copies takes longer. This dimension ensures that consent withdrawal is not merely recorded but is structurally enforced across the entire data processing chain.
Scenario A — Consent Withdrawal Fails to Reach Agent Cache: A customer of an insurance company withdraws consent for marketing communications via the company's privacy portal. The central consent store updates immediately. However, the customer-facing AI agent maintains a local cache of customer profiles refreshed every 24 hours. The cache still shows consent as active. The agent sends 3 marketing messages over the next 18 hours before the cache refreshes. The customer complains to the data protection authority. Result: ICO reprimand, mandatory remediation order, and GBP 150,000 fine for continued processing after consent withdrawal.
What went wrong: The consent withdrawal was recorded centrally but not propagated to the agent's cache within the required timeframe. No mechanism existed to invalidate cached consent records on withdrawal. The agent relied on stale data to authorise processing.
Scenario B — Derived Data Survives Consent Withdrawal: A data subject withdraws consent for behavioural profiling from a fintech application. The application deletes the raw behavioural data within 48 hours. However, the behavioural data had previously been used to train a propensity model, and the model's feature vectors contain encoded representations of the withdrawn data. The model continues to make predictions influenced by the withdrawn data for 6 months until the next model retraining cycle. A regulatory audit discovers that the model's outputs are materially influenced by data for which consent has been withdrawn. Result: CNIL enforcement notice requiring model retraining, EUR 800,000 fine, and 4-month remediation timeline.
What went wrong: Raw data was deleted, but derived artefacts (model weights, feature vectors) were not addressed. The consent revocation process did not include derived data in its scope. No mechanism existed to assess whether a model needed retraining after a consent withdrawal.
Scenario C — Propagation Correctly Implemented: A healthcare AI platform receives a consent withdrawal for research data sharing from a patient. Within 15 minutes: (1) the consent store records the withdrawal, (2) a revocation event is published to all subscribing services, (3) the patient's data is flagged as "consent-withdrawn" in the primary database, (4) the AI agent's working memory is purged of the patient's research-related data, (5) the downstream research data warehouse receives the revocation and quarantines the patient's records, (6) a derived data assessment identifies that the patient's data contributed to 2 aggregate cohort models but the contribution is below the re-identification threshold — the models are flagged for review at next retraining but not immediately invalidated. The entire propagation chain completes within 2 hours. An audit trail documents every step. Result: Full compliance demonstrated, zero regulatory exposure.
Scope: This dimension applies to all AI agents that process personal data where consent is the lawful basis, or where the data subject has a right to object to processing (GDPR Article 21) regardless of lawful basis. It extends to every component in the data processing chain that holds, caches, derives from, or transmits personal data: agent runtime memory, persistent storage, caches, message queues, downstream processors, third-party data recipients, derived models, feature stores, embeddings, and backup systems. The scope includes data held by third-party processors acting on behalf of the controller — consent withdrawal obligations flow through the processing chain. Agents that process data exclusively under lawful bases that do not include a withdrawal right (e.g., legal obligation under Article 6(1)(c)) are excluded for that specific processing, though they remain in scope for any processing that relies on consent.
4.1. A conforming system MUST cease processing personal data for a specific purpose within 4 hours of receiving a valid consent withdrawal for that purpose, across all agent instances and processing components.
4.2. A conforming system MUST propagate consent withdrawal events to every system component that holds, caches, or processes the affected data, including agent memory, caches, downstream processors, and third-party recipients.
4.3. A conforming system MUST delete or irreversibly anonymise the affected personal data from all storage locations within 30 days of consent withdrawal, unless a separate lawful basis permits continued retention.
4.4. A conforming system MUST maintain an auditable record of every consent revocation event, including the timestamp of the withdrawal, the purpose codes affected, the propagation path, and the completion status of each downstream component.
4.5. A conforming system MUST assess, upon consent withdrawal, whether derived artefacts (models, scores, feature vectors, embeddings) are materially influenced by the withdrawn data and document the assessment outcome.
4.6. A conforming system MUST invalidate cached consent records immediately upon receiving a revocation event, rather than waiting for scheduled cache refreshes.
4.7. A conforming system SHOULD implement consent revocation as a publish-subscribe event, so that all subscribing components receive the withdrawal notification without requiring point-to-point integration.
4.8. A conforming system SHOULD complete the full propagation chain — from revocation receipt to confirmation from all downstream components — within 24 hours for standard cases.
4.9. A conforming system MAY implement a derived-data materiality threshold below which model retraining is deferred to the next scheduled cycle, provided the threshold is documented and defensible to regulators.
GDPR Article 7(3) states: "The data subject shall have the right to withdraw his or her consent at any time... It shall be as easy to withdraw as to give consent." The EDPB has interpreted "withdrawal" to mean effective withdrawal — not merely recording the withdrawal while processing continues. If data continues to be processed after consent is withdrawn, the processing is unlawful from the moment of withdrawal, regardless of whether the organisation eventually acts on it.
AI agents create unique challenges for consent revocation because data is distributed across multiple layers: the agent's runtime context (conversation memory, working state), persistent storage (databases, vector stores), caches (performance optimisation layers), derived artefacts (trained models, feature stores, embeddings), and downstream systems (third-party processors, analytics pipelines). A consent withdrawal that only reaches the primary database leaves data in potentially dozens of other locations.
The derived data problem is particularly acute. When personal data is used to train a machine learning model, the model's parameters encode information from that data. Simply deleting the training data does not remove the influence from the model. Research in machine unlearning has progressed but remains impractical for many production systems. AG-320 addresses this pragmatically: the system must assess the materiality of the influence, document the assessment, and take appropriate action (immediate retraining, scheduled retraining, or documented justification for no action if the influence is below a defensible threshold).
The cache invalidation requirement is critical because caching is ubiquitous in production AI systems. An agent that queries consent status from a local cache rather than the authoritative consent store will continue processing based on stale consent data. The latency between consent withdrawal and cache refresh represents a period of unlawful processing. For high-volume agents processing thousands of requests per minute, even a 1-hour cache refresh window could result in thousands of unlawful processing operations.
The core architecture for AG-320 is an event-driven consent revocation pipeline that propagates withdrawal events from the authoritative consent store to every consuming component, with acknowledgement tracking and completion verification.
Recommended patterns:
Anti-patterns to avoid:
Financial Services. Consent withdrawal for marketing or profiling purposes must not interfere with data required for regulatory obligations (AML/KYC, transaction records). The system must correctly distinguish between data held under consent and data held under legal obligation, ceasing only consent-based processing while retaining regulation-required data.
Healthcare. Patient consent withdrawal for research purposes must propagate to all research collaborators and data processors. The derived data challenge is particularly acute in healthcare AI, where models trained on patient data may influence treatment recommendations for other patients. Re-identification risk assessment is critical.
Retail and E-Commerce. Consent withdrawal for marketing frequently occurs at high volume (e.g., during privacy awareness campaigns). The system must handle burst revocation volumes — potentially thousands per hour — without processing delays.
Basic Implementation — Consent withdrawal is recorded in the central consent store. A scheduled process (daily or more frequent) propagates withdrawals to agent configurations and downstream systems. Caches refresh on schedule. Derived data impact is assessed manually. This level creates a processing window of up to 24 hours between withdrawal and enforcement and does not address caches or derived artefacts automatically.
Intermediate Implementation — Consent withdrawal triggers an event-driven propagation to all subscribing components within 4 hours. Agent caches are invalidated immediately on revocation events. Downstream processors receive automated notifications with acknowledgement tracking. Derived data impact assessment is automated using lineage metadata. The revocation orchestrator tracks completion and alerts on failures. All propagation steps are logged with timestamps.
Advanced Implementation — All intermediate capabilities plus: propagation completes within 1 hour for all standard components. Third-party processor revocation is automated with contractual SLA enforcement. Machine unlearning techniques are applied for high-materiality derived artefacts. Vector store and embedding deletion is verified through content inspection. The system supports cross-border propagation with jurisdiction-specific timing requirements per AG-013. Real-time dashboards show revocation status by data subject, purpose, and component. Independent testing verifies that no processing occurs after the revocation SLA expires.
Required artefacts:
Retention requirements:
Access requirements:
Test 8.1: Processing Cessation Within SLA
Test 8.2: Cache Invalidation on Revocation
Test 8.3: Downstream Propagation Completeness
Test 8.4: Derived Data Impact Assessment
Test 8.5: Agent Memory Purge Verification
Test 8.6: Burst Revocation Handling
| Regulation | Provision | Relationship Type |
|---|---|---|
| GDPR | Article 7(3) (Right to Withdraw Consent) | Direct requirement |
| GDPR | Article 17 (Right to Erasure) | Supports compliance |
| GDPR | Article 17(2) (Erasure Notification to Recipients) | Direct requirement |
| GDPR | Article 21 (Right to Object) | Supports compliance |
| CCPA/CPRA | Section 1798.105 (Right to Delete) | Supports compliance |
| UK Data Protection Act 2018 | Section 44 (Right to Erasure) | Direct requirement |
| LGPD (Brazil) | Article 18(VI) (Elimination of Data) | Direct requirement |
| EU AI Act | Article 10 (Data and Data Governance) | Supports compliance |
| NIST AI RMF | GOVERN 1.3, MANAGE 4.1 | Supports compliance |
Article 7(3) establishes the right to withdraw consent at any time. The EDPB has consistently held that withdrawal must be "effective" — the processing must actually cease, not merely be flagged for future cessation. AG-320 implements effective withdrawal by ensuring that the revocation propagates to every processing component and that processing ceases within a defined SLA. An organisation that records the withdrawal but continues processing for days or weeks while propagation occurs is in violation of Article 7(3) for the duration of the delay.
Article 17(2) requires the controller to inform recipients to whom personal data has been disclosed about the erasure request. AG-320's downstream propagation requirement directly implements this obligation. The propagation must reach third-party processors who have received the data, and the controller must be able to demonstrate that the notification was sent and acknowledged.
The CCPA right to deletion requires businesses to delete personal information upon consumer request and to direct service providers and contractors to delete as well. AG-320's propagation architecture supports this by providing the structural mechanism to track and enforce deletion across the processing chain.
The LGPD grants data subjects the right to elimination of personal data processed on the basis of consent. AG-320 ensures that this elimination is effective and propagated, meeting the LGPD's requirements in the same manner as GDPR compliance.
| Field | Value |
|---|---|
| Severity Rating | High |
| Blast Radius | Per-data-subject with potential escalation to organisation-wide regulatory action |
Consequence chain: When consent revocation fails to propagate, the organisation continues processing personal data without a lawful basis. Each continued processing operation is a separate GDPR Article 6 violation. For high-volume agents, this can mean thousands of unlawful processing operations per hour. The data subject, having withdrawn consent, has a legitimate expectation that processing has ceased — continued processing after explicit withdrawal demonstrates systemic non-compliance. Regulatory response is typically more severe for post-withdrawal violations than for pre-withdrawal deficiencies because the organisation was on notice that consent had been withdrawn. The CNIL fined a major retailer EUR 1.75 million specifically for continued marketing after consent withdrawal. The blast radius escalates when the failure is systemic — if the propagation mechanism is architecturally flawed, every consent withdrawal is affected, converting individual incidents into an organisation-wide compliance failure. For AI agents specifically, the derived data problem adds a long tail: model weights influenced by withdrawn data continue producing outputs indefinitely unless addressed, creating an ongoing violation that compounds over time.
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-322 (Data Minimisation by Design Governance), AG-325 (Data Subject Request SLA Governance).