When a supplier adds AI to software you already licensed, the Dutch government's new handreiking gives three steps: check the contract, assess the risk, record an addendum. For a private buyer at 250 to 5,000 FTE, step one usually returns the same answer, which is that the supplier was allowed to. The levers that still work are the processor agreement and one AI Act deadline, 2 December 2026, that your supplier has probably not mentioned.
What does the Dutch government's AI-update handreiking actually say?
On 30 September 2026, the date PIANOo records, the Ministry of the Interior published Help! Mijn huidige dienst krijgt een update met AI erin, wat te doen?, a joint handreiking from central government, the provinces (IPO), the municipalities (VNG), the water boards and the Netwerk van Publieke Dienstverleners. PIANOo carried it first; VNG and Digitale Overheid followed in the second week of October, which is when most people saw it; the trade press followed on 14 October. The document itself sits on open.overheid.nl.
It is three steps. One: establish whether the AI component conflicts with the purpose and the conditions of the contract you already signed. Two: establish the risk and the intended use of that component. Three: record any extra conditions in an addendum with AI-specific terms. PIANOo's page is blunt about why it exists. Existing purchasing terms often give insufficient protection for this and do not yet meet the requirements of the AI-verordening. The handreiking is a first instalment; a broader framework for buying AI is being written under the Nederlandse Digitaliseringsstrategie, meant to align with the terms the public sector already uses, ARBIT centrally and GIBIT at municipal level.
Two details decide whether any of it is yours. It is addressed to inkopers and functioneel beheerders at public organisations, and its first step assumes you hold a purpose clause worth testing. Both assumptions hold for a municipality. Neither reliably holds for a manufacturer with 900 people, two ERP instances and a Microsoft estate.
Why does step one dead-end for most private buyers?
A public buyer contracting under ARBIT or GIBIT has a negotiated baseline to point at, and GIBIT 2025 carries AI-specific provisions; we went through those in AI procurement clauses and where the EU models fall short. A private buyer at this size signed the supplier's own order form and general terms, which almost always reserve a unilateral right to modify the service. Step one then returns the supplier was permitted to do this, and the path stops.
Dutch law does have an answer to an unreasonable clause, and it is the part most write-ups get backwards for this reader. Article 6:233(a) BW lets you void a term in general conditions that is unreasonably onerous, and a clause broad enough to let a supplier deliver a materially different service is a candidate. Article 6:235 BW then takes that protection away from larger companies: broadly, those that have published annual accounts, or that have fifty or more people working there when the contract is concluded. The defence a 30-person firm can reach is the one a 900-person organisation cannot. Mauritz Kop set this mechanism out in Dutch in August 2026, including the exit route for open-ended contracts through the Supreme Court's De Ronde Venen/Stedin ruling,. His piece is the best treatment of the clause mechanics in either language, and it names the one route a large company keeps: Article 6:248(2) BW, the derogating effect of reasonableness and fairness. That is a harder argument than vernietiging and not a lever to plan around.
What has not been said is the consequence for this band. Your contract-law position is weakest exactly where your estate is largest. The mid-market IT manager is in the worst of both worlds: too big for the reasonableness defence, too small to have negotiated bespoke terms with every SaaS supplier in a portfolio of forty applications. Accept that, and the question becomes which other levers you hold.
Which lever still works after the contract clause fails?
The processor agreement, because the right attached to it is procedural rather than a reasonableness test. Where a supplier's AI feature pulls in a new subprocessor, a model provider or a different cloud region, Article 28(2) GDPR applies: a processor shall not engage another processor without prior specific or general written authorisation of the controller, and under a general authorisation it shall inform the controller of any intended changes concerning the addition or replacement of other processors, thereby giving the controller the opportunity to object to such changes.
Read carefully what that is and is not. It is a right to be told and a right to object. It is not a veto, not a right to suspend and not a right to terminate; what an objection achieves depends entirely on what your own agreement says happens next, and Kop's analysis covers the thirty-day silence-is-consent notices suppliers send and the liability chain under Article 28(4). We are not going to re-argue it. The operational point for an IT manager is narrower: the subprocessor notice is usually the only moment the change is pushed to you in writing rather than published in release notes. Treating a supplier's AI toggle as a subprocessor change rather than a product update has been urged on smaller firms before; at this size the point is sharper, because that notice is the only trigger that lands on a named person. It also means the privacy officer's mailbox is the earliest warning system the IT organisation has. Nobody would design it that way.
What is the 2 December 2026 deadline your supplier has not mentioned?
Article 50(2) of the AI Act requires providers of systems generating synthetic audio, image, video or text to mark the output in a machine-readable format, detectable as artificially generated. Those transparency obligations have applied since 2 August 2026. For generative systems already placed on the market before that date, Article 111(4), as amended by the Digital Omnibus on AI (Regulation (EU) 2026/1744, in force since 27 July 2026), gives providers until 2 December 2026. Systems used for standard editing and systems authorised for law enforcement are out of scope. IBM's implementation timeline and ActuIA's reading of the same regulation agree on the date and on who owes it.
The duty sits on the provider, not on you. That is exactly what makes it useful. A supplier who bolted a generative feature onto a product you bought in 2024 is already under a dated legal obligation about how that output is marked, with six weeks left to run, and you are entitled to ask how they are meeting it. It is a question with a deadline behind it rather than a request for goodwill. Neither the Dutch handreiking nor the ABA's October checklist for clients whose vendor adds AI, which is otherwise the most thorough clause-by-clause list available, mentions Article 111(4) at all. Ask it in writing and keep the answer. It is the cheapest evidence you will get that the feature was assessed before it shipped.
Which of your own obligations change, and which do not?
Fewer than the supplier's slide deck implies, and on slower clocks than the compliance newsletters suggest.
- AI literacy. Article 4 was rewritten by the Digital Omnibus. Providers and deployers now take measures to support the development of AI literacy, and the article states that it does not require them to guarantee any specific level for any individual. A feature switched on for 400 users is a support obligation, not a certification programme.
- Impact assessment. The fundamental rights assessment under Article 27 binds only public bodies, private parties providing a public service, and deployers of credit-scoring or life-and-health-insurance systems, so most private buyers at this size never owed one. Where it does apply, Article 27 now lets a deployer refer to a GDPR data protection impact assessment instead of building a parallel artefact. If the feature touches personal data you already assessed, extend that DPIA rather than starting a second one; what actually binds a Dutch organisation under the GDPR has the sequence.
- High-risk duties. Annex III obligations moved to 2 December 2027 and Annex I to 2 August 2028. If the new feature sits in recruitment, credit scoring or access to essential services you have thirteen months, not none. Article 111(2) now reaches pre-existing systems only where their design is significantly changed, and a supplier's AI bolt-on may well be exactly that.
- Becoming the provider. Article 25 turns a deployer into a provider where it puts its own name or trademark on a high-risk system, or changes the intended purpose so that a system becomes high-risk. Rebranding the supplier's assistant as an internal tool and pointing it at a new decision is the realistic way a mid-market IT department walks into provider duties without noticing.
Who owes the answer to each of the five questions?
The handreiking names two roles, inkoper and functioneel beheerder. In an IT organisation of this size that work is spread across four people who do not share a queue: the contract owner, the application owner or functioneel beheerder, the privacy officer or FG, and the security officer. Which is why a supplier's AI feature arrives, is noticed by one of them, and never reaches the other three. An intake fixes that cheaply: five questions, each with one named owner and one artefact.
- Is the feature on by default, and can we switch it off per tenant? Application owner. Artefact: a screenshot of the admin setting and the date it was checked.
- Did we receive a subprocessor notice, and when does the objection window close? Privacy officer. Artefact: the dated notice, filed in the processing register.
- Does the output get marked, and will marking be in place by 2 December 2026? Contract owner, in writing to the supplier. Artefact: the supplier's written answer.
- Which workflow will people use it in, and does that workflow make a decision about a person? Application owner with the process owner. Artefact: one line in the service catalogue.
- What tier of change is this, and who approves it? Change manager. We argued a three-tier classification in AI change management, and a supplier-side feature flag is precisely the case that classification exists for.
Where this lands, and where we sit
Two weeks is enough to get in front of it. Week one: list the suppliers in your application portfolio that have shipped an AI feature since January, which for a mid-market estate of Microsoft, an ERP and a service desk tool is usually six to fifteen. Week two: run the five questions against the three that touch personal data or a customer-facing decision, and send question three to all of them before 2 December. You will not get an addendum out of most suppliers at this size, and step three of the handreiking is the step a private buyer reaches least often. The register of what you asked and what they answered is worth more than the addendum you did not get, because it is the artefact an auditor, a works council or your own board will ask for.
Crux Digits builds and runs AI systems alongside the ICT partner or internal IT team you already have. We do not run your service desk, your infrastructure or your contract desk, and we are not the party that signs your supplier's addendum. Where we are useful is the assessment in the middle: whether the feature does what the supplier says, what it does to the data path, and what replacing it would cost. Our work with mid-sized organisations is set out under applied AI for mid-sized business, and how an implementation actually runs here under AI implementation in the Netherlands. If you only want to know whether the feature lands in a risk class you have to care about, the AI Act risk checker answers that in a few minutes.
Last updated: 21 October 2026.
Software built around your process and data, with AI where it changes the outcome. Something working every week, and the code is yours.
Custom software development in the Netherlands →
