GDPR Article 17: Right to Erasure

SWT3 Clearing Engine and AI-REV.1 Evidence Mapping

TeNova | SWT3 Protocol v1.3.0 | May 2026 | engineering@tenovaai.com

Regulation
GDPR Art. 17

SWT3 Mechanisms
Clearing Engine + AI-REV.1

Cross-Reference
EU AI Act Art. 12

1. The Regulatory Dilemma

Organizations operating AI systems in the EU face a structural tension between two competing obligations:

GDPR Article 17: Right to Erasure	EU AI Act Article 12: Automatic Logging
Data subjects have the right to obtain erasure of personal data "without undue delay" when: consent is withdrawn, data is no longer necessary for its original purpose, the subject objects to processing, or the data was unlawfully processed.	High-risk AI systems must technically allow for "automatic recording of events (logs) over the lifetime of the system" to enable traceability of the AI system's functioning.

The conflict: If you delete the data to satisfy Article 17, you break the audit trail required by Article 12. If you retain the data to satisfy Article 12, you violate Article 17. Traditional logging and attestation tools that hash entire payloads force organizations to choose one obligation over the other.

SWT3 resolves this conflict. The locked fingerprint formula is computed from numeric factors (WHO, WHAT, HOW, WHEN), not from the raw AI metadata (prompts, responses, model names, provider details). The clearing engine strips sensitive data while the cryptographic proof survives intact. An organization can delete every byte of personal data and still independently verify that the AI system was compliant at the time of the interaction.

2. How the Clearing Engine Maps to Article 17

SWT3 defines four clearing levels. Each level strips progressively more metadata while preserving the cryptographic fingerprint. The fingerprint formula never changes regardless of clearing level.

Clearing Level	What Survives	What Is Purged	Art. 17 Posture
Level 0: Analytics	Full AI context: prompt text, response text, model name, provider, all metadata	Nothing purged	Does not satisfy Art. 17. Raw personal data is retained in the ledger.
Level 1: Standard	Model ID, provider name, prompt/response hashes, ai_context metadata	Raw prompt and response text	Partial. Prompt/response text is purged, but model and provider metadata may constitute personal data in some interpretations.
Level 2: Sensitive	Hashed model ID, numeric factors, fingerprint, CJT fields	Raw model name, provider name, all ai_context	Strong. All identifiable AI context is stripped. Only hashes and numeric verdicts remain.
Level 3: Classified	Numeric factors only (factor_a, factor_b, factor_c), fingerprint, CJT fields	All AI context, model ID is hashed, provider stripped	Full erasure. An auditor receives only a numeric pass/fail verdict with zero sensitive metadata. The fingerprint remains independently verifiable.

Key insight: At Clearing Level 3, the ledger record contains: a 12-character hex fingerprint, three integers, a millisecond timestamp, a procedure ID, and a verdict. No personal data. No prompt content. No model identity. Yet an auditor can take those same integers and timestamp, feed them into the public fingerprint formula, and independently confirm the anchor has not been altered. This is the mathematical decoupling that competitors cannot replicate.

3. AI-REV.1: Consent Withdrawal as a Cryptographic Event

When a data subject exercises their right to erasure under Article 17, SWT3 handles it as a first-class protocol event through AI-REV.1 (Anchor Revocation).

Revocation Reason Codes

Code	Reason	GDPR Mapping
0	unspecified	General revocation
1	model_recall	Not GDPR-specific
2	policy_violation	Art. 17(1)(d): unlawful processing
3	data_contamination	Art. 17(1)(d): unlawful processing
4	consent_withdrawal	Art. 17(1)(b): data subject withdraws consent
5	regulatory_order	Art. 17(1)(e): legal obligation to erase
6	error_correction	Art. 16: right to rectification

The Revocation Workflow

When a consent withdrawal request is received:

Identify affected anchors. Query the ledger for all anchors associated with the data subject (typically by session, agent_id, or external reference).
Mint AI-REV.1 anchors. For each affected anchor, call witness.revoke(fingerprint, "consent_withdrawal"). This mints a new anchor with reason code 4 that references the original fingerprint.
Delete the raw data. Purge all local copies of prompts, responses, and AI context associated with the data subject. If operating at Clearing Level 0 or 1, upgrade the affected ledger rows to Level 3.
Verify the audit trail. The revocation anchors themselves are logged in the ledger, creating tamper-evident proof that the erasure occurred, when it occurred, and why.

Additive, not destructive. SWT3 revocation is additive. It does not delete the original anchor from the ledger. Instead, it appends a new anchor that flags the original as revoked. This preserves the Merkle tree integrity while satisfying the erasure requirement. The organization can prove: (1) the interaction occurred, (2) it was compliant at the time, (3) the data was subsequently erased per the subject's request. All without retaining any personal data.

4. The Competitive Advantage

Organizations using traditional attestation or logging tools face a structural dilemma when handling erasure requests:

Approach	Art. 17 Compliance	Art. 12 Compliance	Outcome
Delete everything (raw data + logs + hashes)	Satisfied	Broken. No audit trail remains.	Compliant with privacy law, non-compliant with AI logging law.
Retain everything (keep full logs for audit)	Violated. Personal data persists.	Satisfied	Compliant with AI logging law, non-compliant with privacy law.
Hash-then-delete (hash the payload, delete raw data)	Partial. Hash may constitute personal data under some DPA interpretations if it can be re-linked.	Partial. Hash proves something existed but cannot be independently verified without the original data.	Uncertain legal standing. Depends on DPA interpretation.
SWT3 Clearing Level 3 + AI-REV.1	Satisfied. All personal data purged. Only numeric factors and fingerprint remain. Cannot be re-linked to the data subject.	Satisfied. Fingerprint is independently verifiable from the numeric factors alone. Full audit trail preserved.	Both obligations satisfied simultaneously.

Why competitors cannot replicate this: Traditional attestation tools compute hashes over entire payloads. When you redact any field from the payload, the hash changes and the cryptographic proof breaks. SWT3's fingerprint is computed exclusively from the numeric factor matrix, which never contains personal data. The clearing engine can strip everything else without touching the fingerprint inputs. This is a mathematical property of the protocol design, not a feature that can be added to existing tools.

5. Article 17 Exceptions

Article 17(3) defines exceptions where the right to erasure does not apply. SWT3's design aligns with two of these exceptions:

Exception	GDPR Text (Summarized)	SWT3 Relevance
Art. 17(3)(b)	Compliance with a legal obligation requiring processing	EU AI Act Art. 12 requires automatic logging. SWT3's cleared anchors satisfy this obligation without retaining personal data, potentially eliminating the need to invoke this exception at all.
Art. 17(3)(d)	Archiving purposes in the public interest, scientific or historical research, or statistical purposes	SWT3 anchors at Clearing Level 3 are statistical in nature (numeric factors only). They can be retained for research and trend analysis without privacy risk.

6. Implementation Checklist for DPOs

Data Protection Officers should verify the following when deploying SWT3 in GDPR-regulated environments:

Set minimum clearing level. Configure the tenant's minimum clearing level to Level 2 or Level 3 for any processing involving EU data subjects. This should be enforced server-side, not just in SDK configuration.
Map data subject identifiers. Establish a mapping between data subject identifiers and the SWT3 anchors produced by their interactions. This mapping enables targeted revocation when an erasure request is received.
Automate AI-REV.1 on erasure requests. Wire the organization's data subject request pipeline to call witness.revoke() with reason code 4 (consent_withdrawal) for all affected anchors.
Verify CJT field configuration. Ensure jurisdiction, legal_basis, and purpose_class are set correctly in the SDK configuration. These fields survive all clearing levels and provide regulatory context to auditors.
Document the clearing rationale. In the DPIA (Art. 35), document which clearing level was selected for each processing activity and why. Reference this guide as the technical basis.
Test the revocation workflow. Periodically test the full erasure workflow: receive request, identify anchors, mint AI-REV.1, purge raw data, verify audit trail integrity.

7. Cross-References

Document	Relevance
FRIA + DPIA Integration Guide	Evidence mapping for Art. 27 (FRIA) and Art. 35 (DPIA). Complements this document's Art. 17 focus.
SWT3 Deployer Responsibility Matrix	Defines which obligations are the deployer's responsibility vs. witnessed by SWT3.
SWT3 Protocol Threat Model	T-9 (Clearing Level Downgrade) is directly relevant to GDPR compliance risk.
SWT3 Protocol Specification v1.3.0, Section 9.3	Canonical clearing level definitions and AI-specific clearing rules.