Author: Marc ten Eikelder, Head of EMEA Marketing and Senior Director of Industry Research at Kiteworks

The General Data Protection Regulation is celebrating its 10th anniversary. It came into force on 25 May 2016 and became binding two years later. From a German perspective, it is a success story, albeit with one current caveat.

Many data protection compliance measures for businesses and public authorities are now well established: records of processing activities under Article 30 are standard practice, data protection impact assessments under Article 35 are part of everyday project work, and notification processes under Article 33 run smoothly in most organisations. The aforementioned limitation: the technical and organisational measures (TOMs) under Article 32 – the so-called TOM documentation, which almost every German organisation maintains in some form – were predominantly drafted between 2018 and 2022. Most of these documents are technically sound, but it is likely that they will not pass the next audit.

The reason lies not in the Regulation itself, but in the fact that Article 32 of the GDPR was formulated using an actor model that effectively ceased to exist with the widespread adoption of artificial intelligence a year and a half ago.

Article 32 presupposes actors with predictable behaviour

Article 32 of the GDPR requires the implementation of “appropriate technical and organisational measures”, taking into account the state of the art, the costs of implementation, and the nature and scope of the processing.

Examples given include pseudonymisation and encryption (para. 1(a)), ensuring the confidentiality, integrity, availability and resilience of systems (para. 1(b)), recovery following an incident (para. 1(c)), and a procedure for regularly reviewing effectiveness (para. 1(d)).

Everything in this text presupposes that the actors accessing personal data behave in a predictable manner and with a documented purpose. In other words, people with designated roles, service accounts with defined tasks, or applications with clear functions. On this basis, TOMs can be designed and their effectiveness regularly reviewed – because the actors do what the architecture permits and do not attempt to circumvent it.

However, this prerequisite no longer applies to autonomous AI agents. An agent that has been manipulated by prompt injection does not adhere to the purpose limitation of the session in which it is running. A RAG pipeline that draws more context from the vector store than the prompt requires violates data minimisation without a policy violation being documented. A model that has been fine-tuned on personal data can reproduce this data in responses without the downstream controller realising when this is happening. The 2018 TOM documentation lacks the vocabulary to address any of this.

This is what an architecturally robust Article 32 implementation must achieve today

Three specific requirements emerge when reading Article 32 in the light of the AI reality of 2026. All three can be formulated with technical precision and must be implemented below the model and runtime layers – because everything above the data layer can be updated, replaced or influenced by prompt injection. The consequence of this is that the evidence disappears.

1. Authentication against the human user, not against the agent identity

Every Software Development Kit (SDK) operation of an AI agent handling personal data must be bound to an OAuth 2.0 session with a named natural person – not to a service account whose permissions are exercised “on behalf of” an unknown user. An agent manipulated by prompt injection cannot extract data that it would never be able to access without human authorisation. This is the Article 32-compliant translation of the concept of “authorised personnel” into the AI world.

2. Authorisation via attribute-based access control (ABAC) rather than purely role-based access control (RBAC) models

Roles determine whether a principal is generally permitted to access a folder. Attributes – document classification, declared purpose of the session, user’s jurisdiction, consent of the data subject – determine whether this actor is permitted to access this specific document at this exact moment. This is the operational form in which Article 5(1)(b) (“purpose limitation”) and Article 25 (“data protection by design”) become enforceable in the AI world.

3. Tamper-proof audit trails that outlive the model

Models are withdrawn, replaced, retrained. If the audit log resides at the model or runtime layer, the evidence disappears along with the model. However, Article 5(2) of the GDPR requires precisely this evidence: the controller must be able to “demonstrate” compliance – even three years later, when the processing originally commissioned has long since been replaced by other models.

Logging that detects tampering directly at the data level solves this problem.

It is the architecture that is put to the test, not the policy

The first decade of the GDPR has taught German organisations to write TOM documents. The second will be a test of whether the architecture actually delivers on what the documents promise. Current figures show a need for action here: according to a recent report *, 63 per cent of organisations cannot enforce purpose limitations for AI agents, and 60 per cent cannot promptly terminate a misbehaving agent. 55 per cent do not feel able to isolate AI systems from the rest of the network. Only 43 per cent currently have a centralised AI governance layer, without which the above requirements cannot be architecturally verified at all.

Each of these gaps will result in a finding under Article 32 of the GDPR during an audit – provided the auditor asks the right questions, which is increasingly being observed among supervisory authorities. Therefore, the time has come to update the TOMs before a supervisory authority does it for the companies.

*Kiteworks Data Security and Compliance Risk: 2026 Forecast Report

Marc ten Eikelder is Head of EMEA Marketing and Senior Director of Industry Research at Kiteworks and has been working for over ten years at the interface between technical data security architecture, regulatory compliance and market communications in the DACH region.