AI Regulation for Dutch Companies: A Practical Compliance Guide

Artificial intelligence is becoming ordinary infrastructure for Dutch business. A sales team asks a language model to prepare an account brief, an industrial company predicts machine failures, a service desk summarizes incidents, and a recruitment team searches applications with an automated ranking feature. These uses can create real value, but they also create questions about personal data, discrimination, safety, accountability, and evidence. The relevant question is no longer whether a company uses AI. It is whether the company knows what it uses, what role it plays, who may be affected, and how it will respond when a system is wrong.

This guide is for Dutch B2B companies, including software businesses, manufacturers, professional services firms, logistics providers, financial technology companies, and suppliers to government or regulated industries. It is practical operating guidance, not legal advice. The legal position and implementation materials should be checked again before a decision is made. The guide describes the framework as current to September 2026 and deliberately labels binding law, official guidance, voluntary standards, and proposals separately. That distinction matters: an official explanation can help you comply, but it does not automatically create a new legal duty.

The Dutch legal map in plain English

The centre of the framework is Regulation (EU) 2024/1689, the EU AI Act. It is a directly applicable EU regulation, not a Dutch bill that must be copied into national law. The official AI Act text on EUR-Lex defines obligations for providers, deployers, importers, distributors, product manufacturers, and authorised representatives. It can apply to a Dutch company even when the provider is outside the EU, including where an output is used in the Union. Applicability depends on the system, role, location, purpose, and relevant transition date.

The AI Act is phased. Some prohibitions and the AI literacy obligation apply earlier than the complete high-risk regime. Transparency duties, governance requirements, general purpose AI obligations, and high-risk requirements have separate dates and transitional rules. The European Commission's AI regulatory framework page is a useful official source for implementation updates, guidance, codes, and standards. Keep the Regulation itself as the legal source of truth and record the date and provision used for every conclusion.

Dutch law continues to apply alongside the AI Act. The General Data Protection Regulation, or GDPR, governs personal data processing. The Dutch Uitvoeringswet Algemene verordening gegevensbescherming, or UAVG supplements the GDPR in areas left to national law. The Autoriteit Persoonsgegevens, or AP remains the Dutch data protection authority. A company cannot solve an unlawful processing activity by calling it artificial intelligence, and it cannot satisfy every AI Act duty by completing a GDPR form.

The Netherlands also has national institutions and sector supervisors with different remits. The Digital Trust Center and the Rijksinspectie Digitale Infrastructuur, or RDI publish Dutch information about digital infrastructure and AI supervision. The AP has a specific interest in algorithms and AI where personal data or data protection is involved. The Netherlands has identified the AP and RDI in the national implementation landscape, with responsibilities depending on the system and legal basis. Financial services companies must also consider the Dutch Central Bank, DNB, and the Netherlands Authority for the Financial Markets, AFM. The exact supervisory allocation should be checked for each use case rather than assumed from the vendor's country.

Law, guidance, and proposals are different things

A defensible compliance programme starts with a legal register that has three clearly separated layers. The first layer is binding law: the AI Act, GDPR, UAVG, employment legislation, a contract, a court order, or an applicable sector regulation. The second layer is guidance: an AP publication, Commission guidance, an RDI explanation, or a supervisory expectation. Guidance is not identical to legislation, but it can show how a competent authority interprets a duty and what good practice looks like. The third layer is a proposal or policy direction, such as a draft law, consultation, strategy, or legislative amendment that has not entered into force.

Dutch companies should also watch EU implementation material. Harmonised standards, codes of practice, Commission guidance, and templates may become important ways to organise conformity evidence. They do not change the legal text by themselves. If your policy says that a voluntary code is mandatory, or that a draft standard guarantees compliance, a reviewer will reasonably question the accuracy of the entire programme.

Start with an AI inventory, not a policy

A policy drafted before discovery describes an imaginary company. Start with an inventory broad enough to include purchased SaaS, embedded features, APIs, experiments, open source models, browser extensions, spreadsheet add-ons, customer integrations, and tools employees have adopted without procurement approval. Ask every function to list the system, feature, purpose, users, data, supplier, model or service version, countries involved, and whether the output affects a person, a product, safety, access, or a legal obligation.

• Identify the product and feature, including model family, version, prompts, retrieval sources, plug-ins, agents, connected actions, and release stage.
• Record the provider, reseller, importer, distributor, hosting location, contract owner, sub-processors, support access, and incident contact.
• Describe the purpose in operational language, such as ranking candidates, prioritising support tickets, evaluating credit risk, forecasting demand, approving invoices, or drafting customer communication.
• Map input and output data. Flag personal data, special category data, employee data, confidential information, trade secrets, financial records, children’s data, biometric data, and safety-relevant information.
• Record the human decision around the system. Name the reviewer, describe what they can see, define override authority, and note whether the system can take an action without confirmation.
• Capture affected people, geography, language, sector, lifecycle status, known limitations, evaluation results, incidents, retention, and planned retirement.

Map AI Act roles system by system

One Dutch company can hold several AI Act roles. A software company may be a provider of a product it markets, a deployer of a foundation model used to operate that product, and an importer of a component supplied by a business outside the Union. A manufacturer may put an AI-enabled machine into service under its own name. A customer using an enterprise assistant is generally a deployer, even when the customer did not build the model.

• Provider: the actor that develops an AI system or general purpose AI model and places it on the market or puts it into service under its name or trademark. A substantial modification can change the analysis.
• Deployer: an organisation or person using an AI system under its authority, except for personal non-professional use. Most companies using an internal or purchased tool are deployers.
• Importer: an EU-established actor that places a system from a third country on the EU market. The supply chain and contractual arrangements matter.
• Distributor: a supply chain actor other than the provider or importer that makes a system available in the Union.
• Product manufacturer: a manufacturer that places an AI system together with a product under its name or trademark, or puts the system and product into service as a regulated product.
• Authorised representative: an EU-established representative appointed in the circumstances defined by the Act. Confirm the appointment and evidence rather than treating a local reseller as one automatically.

Screen prohibited practices first

The first substantive gate is not a general risk score. It is the prohibited-practice screen under Article 5 of the AI Act. The Act prohibits specified practices, including certain manipulative or deceptive techniques, exploitation of vulnerabilities, social scoring, and restricted forms of biometric categorisation or emotion recognition. The wording, exceptions, and context matter. A marketing label such as wellbeing analytics, fraud prevention, or productivity insight is not enough to establish that a use is permitted.

Ask whether the system influences behaviour through subliminal or manipulative techniques, exploits age, disability, or a social or economic situation, evaluates people over time in a way that can lead to unjustified detrimental treatment, infers sensitive characteristics in a restricted context, or uses biometric identification or categorisation in a prohibited setting. If the answer is uncertain, pause the launch and escalate. A prohibited use cannot be rescued by adding a disclaimer or assigning a nominal human reviewer.

AI literacy is a practical duty

Article 4 of the AI Act requires providers and deployers to take measures to ensure, to the best of their ability, a sufficient level of AI literacy for staff and other people operating or using AI on their behalf. This is not best implemented as a generic annual slide deck. Training should match the system, role, risk, and language of the workplace. A customer service user needs to recognise fabricated answers and escalate safely. An engineer needs evaluation, security, logging, and release controls. A manager needs to understand accountability, automation bias, and the limits of delegation.

Training cannot compensate for a poor technical boundary. Give employees an approved catalogue, enterprise accounts, clear data classifications, safe defaults, and a route to request a new tool. If the only official instruction is do not use AI, useful experimentation often moves to personal accounts where the company has less visibility and less control.

GDPR, UAVG, and AP expectations

Do not begin with the question, can we put this data into the model? Begin with why the company needs the data, what lawful basis permits the processing, whether the use is compatible with the original purpose, and whether a less intrusive method could achieve the same result. Consent is not a universal cure. It may be unsuitable where there is an imbalance of power, where the purpose is not specific, or where the processing is not genuinely optional.

A data protection impact assessment, or DPIA, is often appropriate for AI that systematically evaluates people, processes sensitive data, monitors employees, uses new technologies at scale, or creates a high risk to rights and freedoms. The AP's DPIA guidance provides Dutch context. Expand the DPIA with model purpose, training or retrieval data, evaluation, error distribution, human review, explanation, correction, rollback, vendor dependence, and residual risk. A DPIA is not a substitute for an AI Act classification, but the two assessments should share facts and controls.

The AP has also published material on algorithms and AI. Use the AP's algorithms and AI topic pages to track current Dutch supervisory information. Guidance can help interpret transparency, fairness, data quality, accountability, and risk, but label it as guidance in your register. When an AP position is stricter or more specific than your generic global policy, adapt the Dutch process and explain the reason.

Automated decisions and employment

Article 22 GDPR restricts decisions based solely on automated processing, including profiling, when a decision produces legal effects or similarly significantly affects a person, subject to defined exceptions and safeguards. A recommendation is not harmless merely because a manager clicks approve. Assess the real process: who sets the score, whether the reviewer can depart from it, whether the review is meaningful, and how much the output determines the final result. Document the route from input to recommendation to decision.

For customer or employee decisions, provide a meaningful route to information, human intervention, and challenge where the law requires it. Do not promise an explanation that the system cannot produce. Explain the information used, the purpose, the material factors, the role of the reviewer, relevant limitations, and what the person can do to correct an error. Coordinate this with GDPR Articles 13 to 15, equality and discrimination law, consumer rules, contractual duties, and the AI Act's transparency and high-risk requirements.

Employment use deserves a separate Dutch review. Recruitment ranking, performance scoring, shift allocation, promotion recommendations, worker monitoring, termination support, and emotion or productivity inference can affect rights and workplace relationships. Consult HR, privacy, legal, security, and the relevant works council or employee representation body. The Dutch Works Councils Act, or WOR can be relevant to decisions about personnel monitoring, processing employee data, and introducing or changing technology. The exact consultation or consent route depends on the system and organisation, so do not treat a vendor deployment as merely an IT purchase.

Set a high-impact employment rule: no automated recommendation is the sole basis for hiring, rejection, discipline, promotion, compensation, scheduling, or termination unless a specialist-approved process establishes that the use is lawful and adequately safeguarded. Train reviewers to challenge automation bias. Measure whether reviewers actually override outputs and sample outcomes by relevant group, language, role, and working arrangement. A human who sees only a green or red score is not necessarily exercising meaningful oversight.

Algorithm registers and public transparency

The Dutch government maintains an Algorithm Register for public sector algorithms. The register is primarily relevant to government bodies and their algorithms, not a universal filing obligation for every private B2B company. A private supplier may still need to provide information to a public customer so that the public body can meet its own transparency, procurement, audit, or register responsibilities. Contractually agree which documentation can be published and which confidential information must be protected.

For a private company, maintaining an internal algorithm and AI register is sensible even when no public listing is required. Record purpose, owner, role, data, affected people, classification, legal basis, supplier, model version, evaluation, human oversight, transparency notice, incidents, and review date. If a Dutch government customer asks for algorithm information, the internal register should make a verified response possible. Do not claim that an entry in a public register proves compliance. It is a transparency record, not a complete risk assessment.

Transparency for customers and users

Transparency duties depend on the system and use. Article 50 of the AI Act covers, among other things, informing people when they interact with certain AI systems and making specified generated or manipulated content identifiable. The precise scope, exceptions, technical requirements, and application dates must be checked against the current Regulation and Commission implementation material. Do not reduce transparency to a generic AI-generated label attached to every output.

For a customer assistant, explain at the point of interaction that the person is communicating with AI when the duty applies and offer a clear route to human help. For generated images, audio, video, or text, define when provenance metadata, a visible notice, an internal record, or a publication review is required. Coordinate AI notices with GDPR information duties, consumer protection, advertising, intellectual property, accessibility, and language requirements. A hidden notice in terms and conditions is often weak evidence of meaningful communication.

Transparency should describe the actual process. Say what the tool does, what information it uses, what it cannot do, whether a human checks the result, how long a person can expect a response, and how to challenge or correct an error. Give sales and customer success teams approved language. Add a change trigger so the notice is reviewed when the model, purpose, audience, action, or degree of autonomy changes.

High-risk classification and evidence

High-risk classification should follow a documented decision tree. First screen for prohibited practices. Then test whether the system is a safety component of a product covered by listed Union legislation or falls within an Annex III use. Annex III includes areas such as biometrics, critical infrastructure, education, employment, access to essential services, law enforcement, migration, justice, and democratic processes, subject to the Act's conditions and exceptions. A powerful general purpose model used to draft an internal email is not automatically high risk.

Record intended purpose, actual use, affected people, autonomy, impact, regulated product connection, provider or deployer role, exclusions considered, and the person approving the conclusion. Revisit the classification after a material change. Do not let a vendor's marketing category replace your own assessment. A tool marketed as an assistant can become high impact when connected to a hiring workflow, credit decision, safety control, or access decision.

For a high-risk system, the control plan can include a risk management system, data and data governance, technical documentation, automatic records and logging, instructions, human oversight, accuracy, robustness, cybersecurity, quality management, conformity assessment, registration, post-market monitoring, and incident reporting. Not every duty applies to every role in the same way. Build a requirement matrix that maps each applicable Article to an owner, control, evidence item, test, and review date.

Testing should reflect Dutch operations. Check Dutch language performance, names, addresses, dates, decimal conventions, industry terminology, accessibility, regional variation, and edge cases. Test relevant groups and failure modes, not only average benchmark accuracy. Preserve test data governance, version, method, result, threshold, limitations, and approval. If the system cannot meet a required threshold, pause deployment or narrow the purpose instead of hiding the result in a footnote.

Dutch sector rules still apply

The AI Act does not replace sector regulation. A financial services company should connect AI classification to DNB and AFM expectations, outsourcing, model risk, operational resilience, consumer protection, anti-money laundering, credit, insurance, payments, and complaints. The EU Digital Operational Resilience Act may be relevant to financial entities and ICT providers in scope. A Dutch bank cannot justify an unsafe model by pointing to a general purpose AI contract.

Manufacturers should connect AI controls to product safety, the Machinery Regulation, medical device rules, industrial cybersecurity, quality management, and conformity assessment. A model that controls a machine, recommends a safety action, or changes a regulated product needs engineering and safety ownership as well as an AI compliance review. Healthcare providers and vendors should consider medical device classification, patient safety, health data, professional standards, and communication duties.

Procurement and vendor controls

Buying an AI feature does not transfer all responsibility. The supplier controls part of the model and infrastructure. Your company controls purpose, prompts, connected data, configuration, users, downstream decisions, and often the customer relationship. Classify the service before accepting standard terms. A writing assistant with no personal data and no decision effect should not receive the same review as an automated claims triage engine or a system connected to production equipment.

• Require the supplier to identify its AI Act role, model family, relevant versions, intended purpose, known limitations, compliance route, and responsible contact.
• Request technical and operational information needed for safe deployment, including logging, security, hosting, retention, data residency, sub-processors, access, and incident handling.
• Specify whether inputs, outputs, feedback, telemetry, files, and customer data are used for training, evaluation, abuse prevention, or other secondary purposes.
• Define advance notice and review rights for material model, functionality, data use, hosting, sub-processor, policy, or risk changes.
• Set incident notification windows, cooperation duties, evidence access, audit rights proportionate to risk, regulatory support, and a tested exit or migration plan.
• Require deletion or return at exit where feasible, address derived data and indexes, and prohibit the supplier from taking high-impact actions outside the approved purpose.

Create an AI procurement questionnaire that feeds the inventory instead of creating a parallel spreadsheet. Require business purpose, data classes, affected people, decision impact, autonomy, human review, legal role, sector, location, model change process, and evidence links. Procurement should not approve a high-impact use alone. A risk owner, privacy lead, security specialist, and business owner should approve the controls before production access is granted.

Human oversight must be operational

Human oversight is not a person pressing approve. Name the reviewer, explain the information they receive, provide sufficient time and domain knowledge, give them authority to override or stop the system, and record what happens when confidence is low or evidence conflicts. Do not measure a reviewer only by throughput. If staff are penalised for challenging outputs, the formal human-in-the-loop design is not real in practice.

Define guardrails for high-impact uses: automatic stops, dual review, escalation thresholds, sampling, maximum batch size, confidence limits, fallback procedures, and a human route for affected people. For an agent that can send messages, change records, issue a refund, approve a supplier, or control a workflow, use least privilege and require confirmation for irreversible actions. Review permissions as carefully as you review model accuracy.

Incident response and record keeping

An AI incident can be a wrong recommendation, discriminatory pattern, privacy breach, prompt injection, data poisoning, unsafe autonomous action, misleading synthetic media, loss of traceability, model outage, or failure of human oversight. Connect the response to existing privacy and security processes, but add model-specific fields: system and version, input or prompt reference, retrieval context, output, action taken, reviewer, affected people, reproducibility, vendor, and containment.

The playbook should cover access suspension, human review of affected cases, preservation of relevant logs, vendor escalation, legal and privacy assessment, notification where required, correction of records or decisions, root cause, remediation, and controlled restart. Minimise sensitive prompts in tickets and restrict incident evidence. Run tabletop exercises for a support assistant exposing confidential information, a recruitment model producing unequal outcomes, and an agent taking an unauthorised account action.

A practical 30, 60, and 90-day roadmap

Days 1 to 30 should create visibility and stop avoidable exposure. Appoint an executive sponsor, AI governance lead, privacy contact, security contact, and system owners. Issue an interim rule for sensitive data, high-impact decisions, autonomous actions, and public AI tools. Inventory use cases across business, IT, HR, product, procurement, security, quality, and suppliers. Screen each use for prohibited practices, high-risk indicators, GDPR impact, employment implications, sector rules, transparency triggers, and vendor dependence. Record unknowns with an owner and due date.

Days 31 to 60 should convert findings into controls. Approve a role and classification method. Publish an approved tool catalogue and employee acceptable-use standard. Deliver role-based AI literacy. Update procurement questionnaires and priority contracts. Complete DPIAs and expanded AI impact reviews for the highest exposure systems. Configure access, redaction, retention, logging, notices, human review, incident intake, and rollback. Create the legal register with separate columns for EU law, Dutch law, guidance, voluntary material, and proposals.

Evidence and KPI checklist

• AI inventory with purpose, owner, role, provider, version, data, users, affected people, sector, classification, and review date.
• Legal register that identifies binding law, Dutch supplementary law, guidance, voluntary standards, proposals, source links, and application status.
• Prohibited-practice screen, high-risk assessment, DPIA or impact review, residual risk, approval conditions, and reassessment triggers.
• AI literacy curriculum, attendance, scenario assessments, role coverage, refreshers, and evidence for contractors or temporary staff.
• Data and model documentation, provenance, quality tests, Dutch language evaluation, fairness checks, limitations, and change history.
• Access configuration, retention schedule, logs, monitoring, human oversight instructions, override samples, escalation route, and rollback test.
• Vendor due diligence, contract clauses, model information, sub-processors, security evidence, incident commitments, and exit plan.
• Customer and employee notices, content labels, accessibility checks, approved scripts, correction routes, and evidence of where notices appear.
• Incident register, preserved evidence, impact assessment, communications, corrective actions, regulator or customer notifications, and restart approval.

Measure coverage and effectiveness together. Useful leading indicators include the percentage of uses inventoried, percentage with an owner and classification, approved-tool adoption, training coverage by role, vendor evidence coverage, systems with tested rollback, and material changes reviewed before release. Useful outcome indicators include human review completion, meaningful override rate, error rate by relevant group and language, privacy or security incidents, time to contain, time to correct an affected record, failed transparency checks, and unresolved high risks by age.

Avoid vanity metrics. One hundred percent training completion can coexist with employees uploading customer files to a personal account. A low incident count can mean poor reporting. A low override rate can mean a reliable model or an ineffective reviewer. Pair every metric with a definition, sample method, threshold, owner, trend, and action. Report exceptions and uncertainty to leadership, not only green percentages.

Common failure modes

• Treating the vendor's statement that a product is compliant as your classification, DPIA, risk assessment, or deployment approval.
• Assuming all generative AI is prohibited, or assuming a productivity tool is outside the AI Act because it is sold as SaaS.
• Writing one broad policy without configuring access, data controls, notices, logging, human review, monitoring, and incident response.
• Ignoring shadow AI because it is not in procurement. Shadow use is evidence that the approved workflow is missing, slow, or unusable.
• Calling a person human-in-the-loop when they cannot understand, challenge, override, or stop the recommendation.
• Presenting AP guidance, a voluntary code, a consultation, or a draft amendment as binding law.
• Keeping prompts and outputs indefinitely, copying sensitive material into tickets, or forgetting derived indexes, embeddings, and vendor retention.
• Testing only English, average cases, or clean data while ignoring Dutch names, dates, language, accessibility, edge cases, and affected groups.
• Buying a compliance platform that creates a second inventory instead of connecting with identity, procurement, privacy, security, quality, product, and incident systems.

Build versus buy

Buy mature commodity capabilities where they already work well: identity and access management, software discovery, training delivery, ticketing, evidence storage, vendor questionnaires, monitoring, and secure model hosting. Build or configure the judgment-heavy parts: your use case taxonomy, Dutch legal register, AI Act role mapping, prohibited-use gate, risk appetite, human review design, Dutch language evaluation, escalation rules, and executive reporting. A platform can organise evidence, but it cannot decide whether your recruitment process materially affects people or whether a reviewer can genuinely correct an outcome.

What can we do for you?

Magna Products helps Dutch B2B companies turn scattered AI experiments into controlled, useful operations. We can map your AI inventory, classify roles and use cases under the EU AI Act, connect GDPR and UAVG controls, design practical vendor and procurement checks, strengthen human review and transparency, and build evidence dashboards for owners and leadership. Talk with Magna Products to schedule a focused discovery workshop and leave with a prioritised 30, 60, and 90-day implementation backlog for your Netherlands operations.