5 oktober 2026 | Geschreven door Eliza Badescu
A common situation with AI governance is that it doesn't fail due to policy, but rather fails to achieve success in its implementation. Although most organizations are able to draw up an AI policy, to appoint a steering committee, and to make a list of approved tools, the problem that they usually have is in answering questions such as: what data is used in an AI-enabled process, for what purpose and on what legal basis it is processed, who receives it, what output is produced, and who has the authority to intervene?
The EU AI Act deadlines for high-risk systems have moved, specifically Annex III systems to 2nd of December 2027 and AI embedded in regulated products to 2nd of August 2028. That does not mean the other items are not already in place. We can see that the transparency rules have applied since 2nd of August 2026, while the AI literacy obligation has been present since February 2025. We can also see that the GDPR and the ePrivacy Regulation have always applied to cases involving data feeding AI systems. The Dutch AP has made AI as one of the three strategic priorities for 2026 to 2028. It can be seen that the practical work starts with establishing a trace of how an AI-enabled process works, well before any high-risk AI deadline.
A good way to test AI governance is to follow an AI-powered process from its data inputs through its output and explain why that use is suitable and how it is controlled. In reality, this situation does not always come up as an AI governance issue. Instead, it usually begins with some of the following questions: Can we use our first-party customer data to improve the model? Does the original purpose for which we collected that data include this new use of personalization? Can our chatbot access the order history? And what occurs when an AI agent is able to call an API or write data back into another system?
Those may arrive as separate questions for marketing, IT, privacy and legal. Underneath it all, we can see that we have to establish the same facts: what data goes in, why is it being used, who gets access, what does the system do with it, what happens as a result?
The calendar changed, the underlying work however did not. We can see that the Regulations (EU) 2026/1744 entered into force in July 2026 and some elements were delayed, however, several relevant obligations are still in practice:
• Article 50 transparency obligations have applied since August 2nd of 2026. This would include requirements around direct interaction with certain AI systems and AI-generated or manipulated content. A limited grace period until December 2nd of 2026 applies to the machine-readable marketing requirement for relevant generative systems already on the market before 2nd of August.
• The AI literacy obligation has applied from February of 2025. Providers and deployers must take measures to ensure an appropriate level of AI literacy among staff and others dealing with AI systems on their behalf.
• GDPR and applicable ePrivacy rules continue to apply to personal data and device access independently of the AI Act.
• Regulatory attention is increasing. The Autoriteit Persoonsgegevens has made AI one of its three strategic priorities for 2026 to 2028.
The deferral gives organizations more time to meet one specific set of high-risk requirements. However, it does not remove the need to understand what data is already flowing into AI-enabled systems today.
This has come to be the case as AI has increasingly become a feature of systems which organizations already use. You can see it present in advertising platforms, bidding systems, personalization engines, customer data platforms, chatbots, office tools, and increasingly in agents that can interact with other systems.
That would lead us to believe that it is not always introduced as an AI Project. Oftentimes, we see that a vendor might add a new feature, someone enables it, customer data gets connected, and suddenly a platform is doing something very different from what it did six months ago. This inherently changes the risk. Models that can read customer data, make recommendations and trigger a workflow have the capacity to raise data protection, contractual, security and measurement questions all in the same breath.
Ownership is often fragmented here as well. We often see IT owning the tooling, while privacy and legal have their own segments, procurement governs the contracts and marketing focuses on the platform. Data moves across all of these teams, which is why there is initially a difficulty in establishing a complete flow.
The AP increased its scrutiny of cookie banners back in 2024. We can see this in the announcement from April 2025, when they started continuously scanning 10,000 Dutch websites, with around 500 organizations a year targeted for warnings. The AP also states that where GDPR consent is used, withdrawing consent must be as easy as giving it.
We can see this development in the Kruidvat case, with an important distinction. The six hundred thousand Euros fine published in July 2024 was a GDPR fine based on the finding that AS Watson, the operator of Kruidvat.nl, had processed personal data through tracking cookies without a lawful basis because valid consent had not been obtained. On objection, the AP reduced the fine to fifty thousand, while claiming that it was a GDPR violation. It cited the unnecessarily long duration of the process, AS Watson’s full admission of the violation, the relatively low seriousness of the infringement, and conformity with a comparable tracking cookie case. This final amount should not be understood as a standard price for a cookie violation, as it depends on its severity among other things.
One common failure point is the gap between what an organization says about the data used and what the technical implementation actually does. A privacy notice might describe one purpose, while consent management platforms record points regarding a visitor’s choice. If a tag were to fire before the choice is honored, a server-side container sends an identifier to another recipient. Furthermore, data collected for one purpose can later become an input into a model for another. Every downstream model, recommendation engine, or agent can inherit this problem, and it cannot be fixed at the model level if the issue was created earlier in the data collection process.
This is why AI data maps are becoming more important in the context of AI governance documentation. When we talk about data maps, we don't mean a static version sitting in a compliance folder, but one that reflects the technical reality. This would entail what data is collected, which tag or process collects it, what causes the trigger, where it lands, which identifiers go with it and what uses follow later on.
In this case, the unit of governance is not just for the tool, it is the use case and the data flow around it. An AI inventory for example, would tell you which systems the organization uses. It does not necessarily tell you which decisions those systems influence or which data reaches them. Oftentimes, two organizations can use the same personalization platform and have different risk profiles because they connect different data sets to it, configure it differently or use the output for different purposes. Even if the vendor states it is ‘privacy-preserving ’, ‘hashed’ or ‘not used for training’, you would still need to compare those claims with the actual configuration, data flow and the contractual terms established.
A significant number of governance decisions are actually made by the people who configure the technology. Usually, AI awareness programs start with leadership, while the people setting up the advertising platform, chatbot, CDP or agent make small decisions every day that determine how the system behaves. Questions such as whether a conversion event carries an identifier or if the chatbot can access the complete order database are all governance decisions as well. However, these questions are made in a configuration screen, not by leadership. This is why training operators matters as well. Leadership needs to set direction and accountability, but operators need enough understanding to recognize when a configuration choice changes the risk.
First, select an AI use case and try to trace it end to end in under an hour. Take a live example, such as a bidding model, product recommendation or chatbot interaction, and work backward, ask the following questions:
If answering those questions takes you a long time and involves three different departments, you might need some help to facilitate this process and make it more efficient. Good governance should make a defensible yes possible, giving you a clear understanding of what the system does and what needs to be controlled.
The main high-risk requirements apply from 2nd of December 2027 for Annex III systems and 2nd of August 2028 for high-risk AI embedded in products following Regulation (EU) 2026/1744.
The AI literacy obligation has applied since February 2025. Article 50 of the AI Act on transparency obligations for certain AI systems and AI-generated content has applied since 2nd of August 2026, subject to a limited transition period for machine-readable marking by relevant systems already on the market.
No, the deferral applies only to the high-risk regime. AI literacy and Article 50 of the AI Act on transparency obligations already apply, while GDPR and applicable ePrivacy requirements continue to apply independently to personal data and tracking technologies used by AI systems.
Not necessarily. A good starting point would be to understand which AI-enabled systems and use cases already exist and how data flows through them. A policy written without that information risks describing an organization that does not exist in practice.
No, a consent management platform can record and communicate a user’s choice. Whether the technical implementation honors that choice depends on the tags, containers, integrations, and vendors downstream. Consent is also only one possible part of the legal assessment. Not every AI use is based on consent.
Material AI use cases should have clear accountability, including someone who can review the use, escalate concerns, and stop or change systems when necessary. A central governance function is useful, but it does not replace ownership where the technology is actually configured and used.
Eliza Badescu is Lead Consultant Data Privacy & Compliance at Cloud Nine Digital. She joined the company to further strengthen and add value to its Privacy & Compliance pillar, helping organizations translate complex regulatory requirements into practical solutions.
She leads the development of Cloud Nine Digital’s privacy, compliance and governance expertise, with work spanning DPIAs, consent, privacy governance and the responsible and compliant use of AI.
Looking for support with AI governance, compliance or a DPIA for your AI use cases? Reach out to Cloud Nine Digital to see how Eliza and the team can support you.
If you're a Dutch marketing team checking whether your website meets consent requirements, you will often hear that it uses Google Consent Mode. Even though this is useful, it answers a narrower...
AI is booming. So are the services around it. In the market everyone is focussing on making sure that their content is AI ready. This means rewriting pages, adding structured data and fixing the...
From “not there yet” to a serious alternative A few years ago, we investigated the state of European cloud providers as a sovereign alternative to US big tech in the field of analytics. You can read...