The EU AI Act is Regulation (EU) 2024/1689, the first comprehensive law on artificial intelligence anywhere in the world. It entered into force on 1 August 2024 and applies in stages, and because it is a regulation it works directly in the Netherlands without any Dutch statute having to repeat it. Its logic is risk-based: a handful of AI practices are banned outright, a defined group of high-risk systems carries heavy obligations, systems that interact with people or generate content carry transparency duties, and everything else is left free.
What the EU AI Act is and when each part applies
The Act regulates AI systems and general-purpose AI models placed on the EU market or put into service in the Union, and it does so by role rather than by sector. The two roles that matter to most organisations are the provider, meaning the party that develops an AI system or has it developed and puts it on the market under its own name, and the deployer, meaning the party that uses an AI system under its own authority in a professional capacity. Importers and distributors have their own, lighter set of duties. A Dutch company that buys a screening tool from an American vendor is a deployer; the same company becomes a provider the moment it puts its own name on the tool or substantially modifies it for its own purposes.
The Act also has extraterritorial reach. A provider established outside the EU is caught if it places a system on the Union market, and so is a provider or deployer outside the EU whose system produces output that is used in the Union. The practical effect is the same as with the GDPR: contracts with non-EU vendors have to carry the obligations through, because a Dutch deployer cannot comply on paper it does not have.
The application timetable
The staged entry into application is the single most misunderstood part of the Act, partly because the timetable was amended after adoption. The prohibitions and the obligation to ensure AI literacy have applied since 2 February 2025. The rules for general-purpose AI models, together with the governance structure and the penalty regime, have applied since 2 August 2025. The bulk of the remaining provisions, including the transparency obligations for systems that interact with people or generate synthetic content, became applicable on 2 August 2026.
The high-risk regime is the part that moved. Under the digital omnibus package the obligations for high-risk systems listed in Annex III, the stand-alone systems used in areas such as employment, education, credit and essential services, apply from 2 December 2027. The obligations for high-risk AI that is a safety component of a product already covered by EU product legislation, listed in Annex I, apply from 2 August 2028. Nothing else in the Act was postponed: the bans, the general-purpose model rules and the transparency duties stand as they are.
| What | Applies from |
|---|---|
| Prohibited AI practices and the AI literacy obligation | 2 February 2025 |
| General-purpose AI models, governance and penalties | 2 August 2025 |
| Transparency obligations and the general body of the Act | 2 August 2026 |
| High-risk systems listed in Annex III | 2 December 2027 |
| High-risk AI as a safety component under Annex I product law | 2 August 2028 |
Deferred does not mean irrelevant. Procurement cycles, model training and vendor contracts for systems that will be high-risk run for years, and a system bought today will still be running when the obligations bite. The deferral buys implementation time; it does not remove the requirement to design for it.
The four risk levels
Classification comes before everything else, because the tier decides the obligations. Getting it wrong in either direction is expensive: under-classification exposes the organisation to enforcement, over-classification loads a conformity regime onto a tool that never needed it.
Prohibited practices
Article 5 bans a closed list of practices outright, and that ban has been in force since February 2025. It covers AI that manipulates behaviour through subliminal or deliberately deceptive techniques in a way that causes significant harm, and AI that exploits vulnerabilities linked to age, disability or social or economic situation. It covers social scoring by public or private actors where the resulting treatment is unjustified or disproportionate to the behaviour assessed. It covers systems that predict criminal offending on the basis of profiling or personality traits alone, the untargeted scraping of facial images from the internet or CCTV to build recognition databases, emotion recognition in the workplace and in education outside narrow medical or safety uses, and biometric categorisation to infer characteristics such as race, political opinion or sexual orientation. Real-time remote biometric identification in publicly accessible spaces for law enforcement is prohibited except in tightly defined situations subject to prior authorisation.
Two of these matter directly to ordinary employers. Emotion recognition applied to staff, for example software that scores tone of voice in a call centre or attention in a meeting, is not a grey area but a banned practice. And the enforcement risk here is the heaviest in the Act.
High-risk systems
A system is high-risk in one of two ways. It is a safety component of a product covered by the EU product legislation listed in Annex I, such as medical devices, machinery, lifts or vehicles, and that product requires third-party conformity assessment. Or it falls within one of the areas listed in Annex III: biometrics, critical infrastructure, education and vocational training, employment and worker management, access to essential private and public services including creditworthiness and life and health insurance pricing, law enforcement, migration and border control, and the administration of justice and democratic processes.
Annex III is not a blanket rule. A system in one of those areas is not high-risk where it performs a narrow procedural task, improves the result of previously completed human activity, detects decision patterns without replacing human assessment, or performs a preparatory task. A provider that relies on that exception has to document its assessment, and profiling of natural persons always keeps the system in the high-risk category. The practical result for Dutch employers is that a tool which ranks or filters job applicants, allocates tasks, or monitors and evaluates performance is high-risk, while a tool that only formats or spell-checks a vacancy text is not.
Transparency obligations
Article 50 applies regardless of risk tier and has been applicable since August 2026. A system that interacts directly with people has to make clear that they are dealing with an AI system, unless that is obvious from the context. Synthetic audio, image, video and text content has to be marked in a machine-readable way as artificially generated or manipulated. A deployer that publishes a deepfake, meaning content that appreciably resembles real people, places or events and would falsely appear authentic, must disclose that it is artificially generated, and a deployer that publishes AI-generated text to inform the public on matters of public interest must disclose it unless a human has reviewed the text and someone bears editorial responsibility for it. Emotion recognition and biometric categorisation systems, where they are permitted at all, carry an obligation to inform the people exposed to them.
Everything else
The large majority of AI in commercial use, from spam filters and demand forecasting to document search, falls outside all of the above and carries no obligations under the Act beyond the general AI literacy duty. The Act does not create a licence requirement for AI as such, and it does not require anyone to register ordinary business software.
What a provider of a high-risk system must do
The high-risk regime is built like EU product law, and that is the key to understanding it. The provider has to demonstrate conformity before the system reaches the market and has to keep demonstrating it afterwards. The requirements sit in articles 9 to 15 of the Act and each addresses a specific way in which an AI system can fail.
A risk management system has to run across the entire lifecycle, identifying reasonably foreseeable risks to health, safety and fundamental rights and adopting measures against them, including for foreseeable misuse. Training, validation and test data have to meet data governance requirements: relevance, representativeness, examination for bias, and appropriate statistical properties for the intended purpose. Technical documentation has to exist before the system is placed on the market and has to be detailed enough for an authority to assess conformity. The system has to log events automatically so that its operation can be traced. Instructions for use have to tell the deployer what the system does, how accurate it is, what its known limitations are and how to exercise oversight. The system has to be designed so that a human can genuinely intervene, including a stop function. And it has to reach an appropriate level of accuracy, robustness and cybersecurity, declared in the instructions.
Around those substantive requirements sits the process. The provider maintains a quality management system, carries out a conformity assessment, which for most Annex III systems is an internal control procedure but for some biometric systems involves a notified body, draws up an EU declaration of conformity, affixes the CE marking, and registers the system in the EU database before putting it into service. After launch, a post-market monitoring plan gathers experience from the field, and serious incidents have to be reported to the market surveillance authority within short deadlines.
Human oversight deserves separate attention because it is where paper compliance and real compliance diverge. An override button that nobody is trained to use, or a reviewer who approves a hundred algorithmic recommendations an hour, is not oversight. The Act requires that the people assigned to it understand the system’s capacities and limits, are alert to automation bias, can correctly interpret the output and can decide not to use it. That has consequences for staffing and workload, not only for the interface.
What a deployer must do
Most Dutch organisations will never be providers. They buy AI and use it, which makes them deployers, and the deployer obligations in article 26 are the ones most likely to be overlooked. A deployer of a high-risk system has to use it in accordance with the instructions, assign human oversight to people who have the competence, training and authority to exercise it, ensure that the input data it controls is relevant and sufficiently representative, monitor the operation and suspend use and inform the provider where it identifies a risk, and keep the automatically generated logs for an appropriate period.
Two duties are specific to the workplace. Before putting a high-risk AI system into service at work, the deployer has to inform the workers’ representatives and the affected workers that they will be subject to it. And where the system is used to make or assist decisions about natural persons, those persons have to be informed. In a Dutch company this connects directly to the works council, whose consent is required for arrangements concerning the processing of employee personal data and for facilities suitable for observing or checking attendance, conduct or performance. An AI tool that scores or ranks employees engages both. We set out the employment side of this in more detail in our article on AI and automation in Dutch employment law.
Certain deployers additionally have to carry out a fundamental rights impact assessment before first use: bodies governed by public law, private entities providing public services, and deployers of systems that evaluate creditworthiness or that carry out risk assessment and pricing in life and health insurance. That assessment describes the processes in which the system will be used, the categories of people affected, the specific risks of harm and the human oversight and remedial measures. It sits alongside, not instead of, the data protection impact assessment under the GDPR.
One obligation applies to every organisation regardless of risk tier and has already been in force since February 2025: providers and deployers must take measures to ensure a sufficient level of AI literacy among the staff who operate AI systems on their behalf, taking account of their training, experience and the context of use. This is not a certification requirement; it is a duty to make sure the people using the tools understand what they are and are not capable of. It is also the easiest obligation to evidence, and the easiest to fail.
Finally, a person affected by a decision taken on the basis of a high-risk system that produces legal effects or similarly significantly affects them has a right to obtain a clear and meaningful explanation of the role of the system in the decision. Anyone can also lodge a complaint with the national market surveillance authority.
General-purpose AI models
Chapter V of the Act regulates general-purpose AI models, the large models that sit underneath most current AI products, and those rules have applied since August 2025. A provider of such a model must draw up and keep technical documentation, provide information to downstream providers who build systems on the model, put in place a policy to comply with EU copyright law including the reservation of rights against text and data mining, and publish a sufficiently detailed summary of the content used for training. Providers of models presenting systemic risk have additional duties including model evaluation, adversarial testing, tracking and reporting serious incidents and ensuring cybersecurity.
For an ordinary Dutch business, the relevance is indirect but real. If you build a product on someone else’s model, you rely on the information they are obliged to give you, and your contract should say so. If you fine-tune a model substantially, you may step into the provider role yourself. And if your use case is one where the model’s training data or copyright position matters, the summary the model provider publishes is now a document you can actually ask about.
Who enforces the AI Act in the Netherlands
Enforcement is split between Brussels and the member states. At European level the AI Office within the European Commission supervises general-purpose AI models directly, develops codes of practice and guidance, and coordinates with the European Artificial Intelligence Board, which brings together the member states, and with an independent scientific panel of experts. Everything other than general-purpose models is enforced nationally by market surveillance authorities designated by each member state, with notified bodies carrying out third-party conformity assessment where the Act requires it.
The Dutch position is still being settled. The Act itself applies directly, so businesses are already bound by the parts that have entered into application, but the national implementing act that designates the supervisors and their powers has not yet entered into force. The draft went out for public consultation in the spring of 2026 and is working its way through the legislative process, which means the eventual designations and the exact allocation of powers can still change and no date should be assumed.
The model in the draft is a hybrid one. Existing sector regulators become market surveillance authorities within their own domains, so healthcare AI sits with the healthcare inspectorate, AI in the workplace with the labour inspectorate, and so on. The Autoriteit Persoonsgegevens (the Dutch data protection authority) and the Rijksinspectie Digitale Infrastructuur are given coordinating roles, with the AP acting as the residual supervisor for high-risk systems that have no obvious sector regulator and the RDI acting as the national contact point. For businesses this means the practical question is not only whether a system is high-risk but which regulator will be looking at it.
The penalty regime is tiered and it is severe. The heaviest tier, expressed as a fixed maximum or a percentage of worldwide annual turnover, whichever is higher, applies to breaches of the prohibitions in article 5. A middle tier applies to breaches of most other obligations, including the high-risk requirements and the transparency duties. A lower tier applies to supplying incorrect, incomplete or misleading information to notified bodies or authorities. The current maxima are set out in article 99 of the Regulation, and lighter ceilings apply to small and medium-sized enterprises and start-ups. Enforcement, however, is not only about fines: market surveillance authorities can require corrective action, restrict or prohibit the making available of a system, and order its withdrawal or recall.
How the AI Act sits alongside data protection and liability
The AI Act does not replace anything. It is added to the existing body of law, and in most Dutch AI projects the GDPR remains the more immediately demanding instrument. Every AI system trained on or applied to personal data still needs a legal basis, still triggers transparency duties, and still requires a data protection impact assessment where the processing is likely to result in a high risk. The GDPR’s own rule on automated individual decision-making applies independently of the AI Act, and it gives the person concerned rights to human intervention and to contest the decision. Our overview of the General Data Protection Regulation sets out that framework.
Liability is the area where expectations most often outrun reality. The proposed AI Liability Directive, which would have harmonised civil claims for damage caused by AI, has been withdrawn. That leaves two routes. The first is national law: in the Netherlands, a claim in tort under article 6:162 of the Civil Code, or a contractual claim against the supplier, assessed with the ordinary rules on causation and on the burden of proof. The second is the reformed European product liability regime, which expressly brings software, including AI systems, within the concept of a product and eases the evidential position of claimants; member states have to transpose it into national law, and until the Dutch implementing legislation is in force the existing product liability provisions of the Civil Code apply.
Criminal responsibility is a separate question again, and one that the AI Act does not answer at all. Where an autonomous system causes harm, Dutch criminal law looks for a natural or legal person with intent or culpable negligence, which is a very different exercise from regulatory compliance. We discuss it in our article on AI and criminal law: who is responsible when a machine commits a crime.
A practical route to compliance
The work divides into four steps, and the first two are worth doing even by organisations that are convinced they have nothing high-risk.
Start with an inventory. List every AI system the organisation develops, buys, embeds or pilots, including the tools that arrived through a departmental subscription rather than through procurement. For each one record what it does, who supplies it, what data it uses, who operates it and what decisions it influences. Shadow AI, adopted by teams without central visibility, is where most classification surprises are found.
Then determine your role and the risk tier for each system, in that order, because the same tool produces different obligations depending on whether you are its provider or its deployer. Record the reasoning, particularly where you conclude that an Annex III system falls within one of the exceptions; that record is the first thing a supervisor will ask for.
Next, run a gap analysis against the obligations that actually attach. For a deployer of a high-risk system this means oversight arrangements and the competence of the people carrying them out, input data quality, log retention, information to workers and their representatives, and where applicable the fundamental rights impact assessment. For a provider it means the full article 9 to 15 file plus the quality management system and the conformity route.
Finally, fix the contracts and the governance. Vendor agreements should oblige the supplier to provide the instructions for use, the technical information a deployer needs, incident notifications and support for regulatory requests, and should allocate responsibility if the system turns out to be misclassified. Internally, assign ownership of AI compliance to a named person, connect it to existing privacy and security governance rather than building a parallel structure, and put the AI literacy obligation on the training calendar. Our IT law practice supports organisations through exactly this sequence.
Five misconceptions worth clearing up
The same misunderstandings surface in almost every intake conversation, and each of them leads organisations to spend effort in the wrong place.
The first is that the Act bans or licenses general AI use. It does neither. Using a commercial chat assistant to draft an internal memo triggers no obligation beyond AI literacy and, where the output is published to inform the public, the disclosure duty. What triggers the heavy regime is the purpose the system serves, not the technology behind it.
The second is that a human signature removes the high-risk label. It does not. The exception for systems performing a narrow procedural or preparatory task is drawn tightly, and a tool that ranks candidates or flags files for closer review is influencing the decision even if a person signs it. A rubber stamp is not human oversight and it is not a way out of Annex III.
The third is that only developers are regulated. Deployer obligations are real, they are enforceable against the organisation that uses the system, and several of them, informing workers and their representatives, assigning competent oversight, keeping logs, cannot be delegated to the vendor at all.
The fourth is that everything already installed is grandfathered. Systems placed on the market before the high-risk rules apply are in principle caught only if their design is significantly changed afterwards, but that carve-out is narrower than it sounds: model updates, retraining and repurposing are exactly the kind of change that brings a system back into scope. A separate and stricter rule applies to systems used by public authorities. Anyone planning to rely on the transitional position should document the configuration as it stands now.
The fifth is that the AI Act supersedes existing law. It sits on top of it. Data protection, non-discrimination law, consumer law, sector regulation, employment law and the works council’s rights all continue to apply in full, and in the Netherlands it is usually one of those, rather than the AI Act itself, that produces the first concrete complaint. An AI project that satisfies the AI Act but fails the GDPR is not compliant, and the reverse is equally true.
Frequently asked questions
The questions below come up in almost every first conversation about the Act.
What is a High-Risk AI system?
Simply put, a high-risk AI system is any system that could pose a serious threat to a person’s health, safety, or fundamental rights. The Act lays out several specific categories, such as AI used in critical infrastructure like transport, in medical devices, and in systems for recruitment or managing employees.
For example, an algorithm that screens CVs to shortlist candidates for a job interview is considered high-risk. Why? Because its decisions can have a huge impact on someone's career and livelihood. Systems like these will need to pass strict conformity assessments before they can even be put on the EU market.
Does the AI Act affect my small business if I only use AI tools from other companies?
Yes, it almost certainly does. The AI Act’s rules aren’t just for the big tech companies that build the AI. While the ‘provider’ (the company that creates the AI) has the heaviest compliance burden, the ‘user’ (that’s your business, when you deploy the system) also has clear responsibilities.
If you use a high-risk system, you are responsible for ensuring it’s operated according to the provider’s instructions, maintaining human oversight, and monitoring its performance. Even for something lower risk, like a customer service chatbot, you still have a transparency obligation to make it clear to people that they're interacting with an AI.
What are the first steps for my organisation to prepare?
The most critical first step is to create a detailed inventory of every single AI system your organisation currently uses or is planning to adopt. Think of this audit as the foundation of your entire compliance strategy.
For each system, you need to go beyond just listing its name. You must document its purpose and then classify it according to the AI Act's risk categories: unacceptable, high, limited, or minimal.
Once you’ve identified any high-risk systems, your next move is to conduct a gap analysis. This involves comparing your current practices against the Act's specific requirements for things like data governance, technical documentation, and human oversight. Starting this process now is absolutely vital, as getting to full compliance is a detailed and time-consuming job.
Law & More advises providers and deployers on AI Act classification, on the contracts that make compliance workable in a supply chain, and on the overlap with data protection and liability. If you are working out which obligations apply to a system you build or use, we are glad to go through it with you.
