How Execution-Time Enforcement Resolves the Identifiability Gap Without Amending Article 4(1) GDPR

How Execution-Time Enforcement Resolves the Identifiability Gap Without Amending Article 4(1) GDPR

Context

In light of the February 2026 Council compromise removing the proposed amendment to Article 4(1) GDPR within the Digital Omnibus, and following the EDPB–EDPS Joint Opinion 2/2026, the legislative direction appears to preserve the current definition of "personal data" while addressing pseudonymisation and identifiability through guidance rather than redefinition.

This contribution does not advocate for amending the GDPR definition. It explores whether the underlying policy objective — legal certainty for entities that genuinely cannot re-identify pseudonymised data — might be achievable through technical architecture rather than definitional change.

The Identifiability Gap

Recital 26 GDPR requires that account be taken of "means reasonably likely to be used" to identify a person. However, no technical mechanism currently exists to make that assessment verifiable, stable over time, consistent across processing chains, or resistant to AI-driven inference advances. As a result, identifiability remains probabilistic, entity-relative, and contested.

What Execution-Time Enforcement Solves

1. Identifiability becomes a verifiable technical property, not a subjective assessment Virtual Identities (VIs) are cryptographically derived, session-scoped, and purpose-bound. Whether a recipient can re-identify a data subject becomes a provable cryptographic question — not a legal argument about "means reasonably likely to be used."
2. Re-identification resistance is stable over time and AI-proof by construction VIs rotate per session, per purpose, per context. No stable identifier exists across interactions. AI-driven inference fails because there is nothing stable to correlate — not today, not as AI capabilities advance. Protection does not degrade with technological progress.
3. Consistency across every entity in the processing chain Compliance Jurisdiction Tokens (CJTs) travel inseparably with the data. Every processor, sub-processor, and cross-border recipient operates under the same cryptographic constraints. Identifiability does not change depending on which entity holds the data — it is architecturally uniform.
4. Lawful judicial re-identification remains available Court-authorised unmasking through hardware-enforced, quota-bound mechanisms preserves law enforcement access. Privacy and accountability coexist — not as a policy balance, but as an architectural property.
5. Purpose limitation is cryptographically enforced, not declared Purpose is bound at data collection and enforced at execution time. Secondary use is technically impossible, not merely prohibited. This directly addresses the concern that pseudonymised data may be re-purposed in ways that restore identifiability.
6. No amendment to Article 4(1) required The definition of personal data remains unchanged. What changes is the technical substrate: data systems become capable of making Recital 26 assessments machine-verifiable rather than subjective. The law does not need to change — the architecture evolves to make the law enforceable.
7. Directly relevant to current EU policy tracks The architecture provides implementation-ready mechanisms for:

• EDPB pseudonymisation guidance — verifiable non-identifiability
• AI Act high-risk processing — purpose-bound execution with algorithmic logic verification
• Digital Euro privacy design — cash-like privacy with AML compliance
• eIDAS 2.0 — privacy-preserving identity without persistent tracking
• Article 28 processor obligations — cryptographic enforcement across processing chains
• NIS2 security-of-processing — fail-closed execution at system boundaries

Core Insight

The identifiability gap is not a legal drafting problem. It is an enforcement architecture problem. Execution-time enforcement closes the gap by converting identifiability from a contested legal interpretation into a deterministic technical property — without touching the GDPR text.

The definition stays. The architecture delivers what the definition always intended.