Alain Rees · 11-07-2026 · 11 min leestijd
The AI Act, formally the AI Regulation, is the first broad European law that sets rules for developing and using artificial intelligence. The regulation works on a risk basis: the greater the risk an AI system poses to people and their rights, the heavier the requirements. This article explains what the AI Act entails, which obligations belong to which risk level, which role your organisation plays and how you comply demonstrably without ending up in a sprawl of loose documents.
In short
- The AI Act divides AI systems into four risk levels: unacceptable, high, limited and minimal.
- Systems with an unacceptable risk are prohibited, and systems with a high risk face heavy requirements.
- Unlike a directive, a regulation applies directly, so there is no Dutch law to wait for.
- Your obligations depend on your role as provider or as deployer.
- The basis of compliance is knowing which AI you use, so start with a register of your AI systems.
- Compliance coincides with the four phases of the Kantyra model: detect, assess, resolve and demonstrate.
The AI Act (Regulation (EU) 2024/1689) is European legislation that sets common rules for artificial intelligence across the entire European Union. Its goal is twofold. On the one hand, the law protects people's fundamental rights, health and safety; on the other, it leaves room for innovation and for a level playing field on the internal market.
The core of the law is a risk-based approach. The regulation does not look at the technology as such, but at what an AI system actually does in practice and what risk that creates. You know that same model from other European legislation. You first determine how risky something is, and you then match the requirements to it.
This is an important distinction that often causes confusion. Unlike the NIS2 directive, which first had to be transposed into national legislation (in the Netherlands the Cyber Security Act, the Cbw), the AI Act applies directly in all member states. There will be no separate Dutch AI law to comply with instead of the regulation. The obligations apply directly, and you do not have to wait for national transposition before getting started.
What is arranged nationally is the supervision. In the Netherlands, supervision is assigned to various market surveillance authorities, with a coordinating role for the Dutch Data Protection Authority. The precise division of powers and the enforcement practice are still taking shape, so verify the current state with the authorities involved.
The AI Act divides AI systems into four levels, each with its own regime.
At the level of unacceptable risk sit the prohibited practices. Think of systems that manipulate people in harmful ways, of social scoring by governments, and of certain forms of biometric recognition. You may not place these systems on the market or use them.
At the level of high risk sit the systems that can have major consequences for people. These are, for example, AI systems used in recruitment and selection, in access to education, in essential services, in critical infrastructure or in the context of law enforcement. AI that acts as a safety component in a regulated product also falls here. The heaviest requirements apply to these systems.
At the level of limited risk, transparency obligations dominate. If you use a chatbot, have your system make clear that someone is talking to a machine. If you generate or edit images, audio or text, that content must be recognisable as artificially generated.
At the level of minimal risk sits the vast majority of AI, such as spam filters or recommendations in a web shop. The regulation sets no special obligations here, although responsible use is of course always wise.
Alongside these four levels, the regulation has separate rules for general-purpose AI models, such as large language models. Those models carry their own obligations around documentation and transparency, and the heaviest models face additional requirements.
Your obligations depend strongly on your role. The regulation distinguishes several, but for most organisations two matter.
A provider develops an AI system or has it placed on the market under its own name. Providers of high-risk systems carry the most obligations, such as setting up a risk management system, getting the technical documentation in order and carrying out a conformity assessment.
A deployer uses an AI system for its own purposes. Most organisations fall into this category, for instance when you buy a ready-made system for recruitment or for customer contact. Deployers have obligations too. You must use the system according to its instructions, organise human oversight and, for high-risk systems, monitor its operation.
Note that you can change from deployer into provider. If you substantially modify a high-risk system, or market it under your own brand, the heavier obligations of a provider suddenly apply.
The AI Act entered into force on 1 August 2024, but the obligations become applicable in stages. The main lines of the statutory timeline are as follows:
This phasing is fixed in the regulation, but the precise dates and implementation details may have been adjusted by later amendments. Check the current state before steering by a specific date.
If one of your systems falls into the high-risk category, the bar is high. The main requirements that come with it are the following:
Many of these requirements resemble what you already do in information security and risk management. That is exactly the anchor point for not treating the AI Act as a stand-alone exercise.
An obligation that is easily overlooked is the one around AI literacy. Both providers and deployers must ensure that their staff have sufficient knowledge of AI to use the systems responsibly. What counts as sufficient depends on the employee's role and on the risk of the system. For many organisations this means structurally organising awareness and targeted training around AI, and keeping track of who has acquired which knowledge.
Here sits the step many organisations skip. You cannot comply with the AI Act if you do not know which AI you actually use. The basis of everything is therefore a register of your AI systems: a current overview of every system you develop or deploy.
For each system you record what it does, who the provider is, in which role you act, in which risk level it falls and how human oversight is arranged. That register is your starting point and your evidence at the same time. It shows that you do not merely know the regulation, but are in control of it. In Kantyra this register is the core of the AI module: every system has an owner, a status and a risk category, and you link it to the supplier, the asset and, if it processes personal data, the processing activity in the processing register.
You do not determine the risk category by gut feeling. In Kantyra, each system goes through an AI risk classification: a fixed questionnaire along the regulation, from your role and the prohibited practices to high risk, the transparency obligations and AI literacy, with a review round under the four-eyes principle. You record the outcome as the category in the register. The obligations themselves sit as the AI Act framework in the compliance register, with a status, an owner and the evidence per requirement, alongside the frameworks for the Cbw and the GDPR. This way the AI Act grows into your existing compliance process instead of becoming a separate track.
From that register, the lines run to your existing management. The risk assessment of a high-risk system connects to your information security and risk management (ISMS). You translate the requirements around documentation, human oversight and security into controls that you manage just like your other security controls. There is now also a standard that supports this: ISO/IEC 42001, the standard for an artificial intelligence management system. It relates to AI as ISO 27001 relates to information security. In Kantyra, ISO/IEC 42001 sits as a framework in the compliance register, next to the AI Act framework itself, so you serve the standard and the law with the same controls and the same evidence.
Like risk management and compliance management, complying with the AI Act cannot be captured in a single phase of the Kantyra model: it is the cycle of the model, applied to AI systems.
It starts with detect: knowing which AI you use, spotting new systems and substantial changes, and registering incidents involving AI. Then follows assess: the risk classification per system, from role and prohibited practices to high risk and transparency. In the resolve phase you fulfil the obligations that follow from the category: human oversight, transparency, documentation and AI literacy. And in the demonstrate phase, the AI register and the evidence per framework requirement together form the file for the regulator and the auditor.
The starting point carries extra meaning here. In information security, an organisation usually knows what is running; with AI that is rarely the case, because AI also arrives through existing software, through suppliers and through employees choosing their own tools. That is exactly why AI Act compliance starts at the bottom of the model, with detection.
You can keep your AI system register and the associated risk assessments in loose files, and as a start that is defensible. But as the number of AI systems grows and the regulator asks for demonstrability, you run into the same limits as in any other compliance effort. Loose files drift apart, and you lack the overview and the history you need.
In a GRC platform, you manage the AI system register, the risk classification and the controls as connected overviews within a single environment. Every system has an owner, a status and a risk category, and the connection with your information security prevents doing the same work twice.
With Kantyra you manage the AI Act in the same environment as your ISMS. Whether you see the regulation as a stand-alone obligation or as an extension of your existing management, your AI systems, your risks and your controls come together in one place. This makes the management of your AI systems just as demonstrable as your information security.
Is the AI Act the same as the GDPR? No. The GDPR is about protecting personal data, while the AI Act is about the risks of AI systems. They complement each other. An AI system that processes personal data must comply with both.
Should I wait for a Dutch AI law? No. The AI Act applies directly in all member states. Unlike the NIS2 directive, which was transposed through the Cbw, there will be no separate Dutch law to comply with instead.
When does the AI Act apply? The regulation applies in stages. The prohibited practices and AI literacy applied from February 2025, while most requirements for high-risk systems apply from August 2026. The precise dates may have been adjusted by later amendments, so verify the current state.
What is a high-risk AI system? A system that can have major consequences for people, for example in recruitment and selection, education, essential services, critical infrastructure or law enforcement. The heaviest requirements apply to these systems, such as risk management, documentation and human oversight.
Am I a provider or a deployer? You are a provider if you develop an AI system or place it on the market under your own name. You are a deployer if you use a system for your own purposes. Most organisations are deployers, but you become a provider as soon as you substantially modify a high-risk system.
Would you rather not manage AI Act compliance in loose files, but in one environment that connects to your information security? With Kantyra's AI module you maintain the AI register, take each system through the risk classification and manage the obligations of the regulation and ISO/IEC 42001 as frameworks in the compliance register, with the evidence attached. Request a demo and discover how to build AI Act compliance on top of your existing ISMS.
Kantyra is a Dutch ISMS and GRC platform that lets organisations manage their information security, risk management, continuity and AI compliance demonstrably, in line with ISO 27001, ISO 22301, ISO/IEC 42001, the Dutch Cyber Security Act and the AI Act.
In een demo van 30 minuten lopen we het model door aan de hand van jouw situatie.
Plan een demoCompliance management has a dusty reputation of ticking off lists, but designed well it is the process that translates requirements from legislation, standards and contracts into one set of controls with evidence. This article describes the five steps, the division of roles, and where the process sits in the Kantyra model.
A continuity plan on the shelf is not yet business continuity management. How to build a BCM process along ISO 22301: from policy and BIA to the registers that make your continuity demonstrable under the Dutch Cyber Security Act (Cbw).
In many organisations, risk management gets stuck in an annual form-filling exercise. This article shows how strategic, tactical and operational risk management together form one continuous system of steering, how the ISO 27005 cycle maps onto the Kantyra model, and how you connect the register to the processes around it.