The General Data Protection Regulation (GDPR) has been a firm basis for data protection in companies and authorities for years. Directories of processing activities, data protection impact assessments and reporting processes are established in many places. But a dangerous gap is emerging when it comes to technical-organizational measures (TOM): Many TOM documentation was created between 2018 and 2022 – i.e. before the widespread use of generative and agentic artificial intelligence (AI).

Old assumptions meet new actors

Article 32 GDPR requires “appropriate technical and organizational measures”. These include pseudonymization, encryption, confidentiality, integrity, availability, resilience and procedures for regular review of effectiveness. However, this logic assumes that all actors act predictably: employees with a clear role, service accounts with a defined mission or applications with fixed functions.

It is precisely this requirement that breaks down with autonomous AI agents. If an agent is manipulated through prompt injection, it does not necessarily follow the purpose of its session. A retrieval augmented generation pipeline (RAG) can pull more context from a vector store than is required for the query. And a model that has been fine-tuned with personal data can later reproduce this information in responses without the controller reliably recognizing it.

This means that many older TOM documentation lacks not only individual controls, but also an entire vocabulary for new risk scenarios.

Article 32 needs a new technical translation

Today, a reliable implementation of Article 32 must go deeper than at the model or application level. The data layer is crucial because models, runtime environments and prompts can be replaced, updated or manipulated.

First, an AI agent’s access to personal data must be tied to a specific natural person. It is not the agent identity that should be crucial, but rather the user’s authenticated session. In this way, the classic concept of “authorized personnel” is transferred to the AI ​​world.

Second, purely role-based access control (RBAC) is no longer sufficient. Attribute-based access control (ABAC) can take into account additional factors: document classification, purpose of the session, scope of responsibility, or consent of the data subject. This makes earmarking technically feasible.

Third, there needs to be tamper-proof audit trails. If protocols are only at the model or runtime level, they may disappear when a system is replaced. However, Article 5 GDPR requires those responsible to be able to “prove” compliance – even years later.

The test affects the architecture

In the future, the crucial question will no longer be whether a company has TOM documents. But whether its architecture actually enforces the documented level of protection. Current figures show the pressure to act: 63 percent of organizations cannot enforce purpose restrictions for AI agents, 60 percent cannot terminate a misbehaving agent in a timely manner and 55 percent cannot isolate AI systems from other network access.

This makes the second GDPR decade an architectural review. If you continue to treat TOMs like static guidelines, you risk that they will no longer be useful in the next test. Companies should therefore now adapt their measures to AI agents, RAG systems and tamper-proof evidence – before supervisory authorities identify these gaps themselves.