AI Procurement Clauses: Where the EU Models Fall Short

Two sets of AI procurement clauses are within reach of a Dutch buyer: the European Commission's MCC-AI, published on 5 March 2025, and Article 14 of GIBIT 2025, the municipal IT procurement terms dated 12 February 2026. Both were drafted for public buyers. Both cite only Regulation (EU) 2024/1689, so neither reflects the Digital Omnibus on AI, in force since 27 July 2026. This is which clauses still hold and which ones you replace.

Written for the IT manager, IT director or informatiemanager at a private organisation between 250 and 5,000 FTE who is about to sign for an AI system. You already have an ICT partner and a procurement department with a template it trusts. What you do not have is a template written for you.

Which AI procurement clauses can a Dutch private buyer actually reach?

The first set is the EU model contractual clauses for AI, the MCC-AI, produced by the Community of Practice on the Public Procurement of AI with Commission support. The resource page carries a single publication date, 5 March 2025, for all three artefacts: a full version for high-risk AI, a light version for non-high-risk AI, and a commentary. Translations into 24 EU languages followed on 16 June 2025, so a Dutch text exists. There is no 2026 revision.

Read the Commentary before you lift anything from it. It states that it would not be appropriate for organisations other than public organisations to use the MCC-AI, while allowing that parts of them certainly could be used, assessed clause by clause. Its back matter says more than its press coverage does: status "Dynamic Working Document", version 12 February 2025, and no version since.

The second set is closer to home. GIBIT 2025 was adopted by the VNG and replaces GIBIT 2023; the articles PDF is dated 12 February 2026 and was published in March 2026, with an English translation in September. All 342 Dutch municipalities use GIBIT as their starting point for IT procurement, which makes it the most widely applied IT purchasing template in the country. It adds Article 14, AI-systemen next to the existing Article 13 on algoritmische toepassingen, because every AI system is an algorithmic application but not the reverse.

Both are buyer-side instruments. The supplier-side counterpart, the NLdigital Voorwaarden, decides more about who carries an AI failure than most buyers realise, and we took that apart in who gets paged when the AI breaks.

Why does a pre-Omnibus template matter in October 2026?

Regulation (EU) 2026/1744 of 8 July 2026, the Digital Omnibus on AI, amends Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230. It entered into force on 27 July 2026, six days before the AI Act's original high-risk date, and moved the Chapter III obligations for standalone Annex III high-risk systems to 2 December 2027, and for AI embedded in products already covered by EU product-safety law to 2 August 2028.

The substance of what you should ask a supplier barely changed, so most MCC-AI clauses survive. But every warranty pointing at a date, a conformity assessment or a CE mark now points at a different year than the drafters assumed, and the two changes that actually bite a contract sit in Articles 25 and 27.

The MCC-AI say so themselves. The Commentary explains that the clauses are intended to apply until the AI Act is fully applicable, and its footnote cites Article 85 of the Act as proposed by the Commission, applying 24 months after entry into force. In the adopted AI Act the application article is Article 113, not 85, and the horizon that footnote describes has both arrived and moved. It is a snapshot, and it says so.

The practical consequence cuts against the obvious reading of a deferral. A framework agreement signed this quarter is still running in December 2027. Those sixteen months are the only window in which you can negotiate the clause calmly.

Which MCC-AI clauses still hold, and which are now dated?

Clause by clause, in the numbering of the full high-risk version. The verdicts are ours.

• Article 2, risk management system (AI Act Article 9): holds, but change the trigger. The MCC-AI require implementation at delivery, which is weeks before anyone really uses the system. Tie it to production use.
• Article 3, data and data governance (Article 10): holds only in the configuration it assumes. The Commentary is explicit that it presumes the supplier decides which data sets are used, and that offloading those duties onto a supplier who never sees your data is not appropriate. The common mid-market case is your data in their model. Re-point the clause.
• Article 4, technical documentation and instructions for use (Articles 11 and 13): holds. Article 4.5 requires delivery in English, while GIBIT Article 15.2 requires Dutch for end-user documentation. Pick one deliberately.
• Article 5, record-keeping (Article 12): holds, with a gap the drafters flagged. The Commentary expects harmonised standards to be referenced in Article 5.1 once they exist, and they still do not. Do not wait for one; write a retention period and, via Article 5.3, your own real-time read access.
• Articles 6 and 7, transparency and human oversight (Articles 13 and 14): empty by design. Both route to annexes, E and F, that you fill in. That is where the engineering sits, and the template gives you none of it.

• Articles 10 and 11, quality management system and conformity assessment (Articles 17 and 43): date-dependent, high-risk only. A warranty today that a conformity assessment has been carried out on a standalone Annex III system concerns an obligation that applies from 2 December 2027. Ask for the plan, not the certificate.
• Article 12, fundamental-rights impact assessment (Article 27): rewritten, and the clause to redraft. The Omnibus replaced Article 27 paragraphs 4 and 5. The old duty for the assessment to complement a GDPR Article 35 data protection impact assessment is gone; a deployer may now cross-reference that DPIA or lift relevant parts of it instead, and the AI Office questionnaire template is to carry the facility. Ask for cooperation on one combined assessment, and do not draft around a template we could not find published.
• Article 14, individual explanation: keep, unchanged. It is the strongest clause in the set, derived from the City of Amsterdam's 2019 model algorithm provisions and aligned to AI Act Article 86. Facing a complaint about an automated decision, it decides whether you can answer at all.
• Articles 15 to 18 and Annex B, rights to the data sets: keep, and treat Annex B as an exit lever. The Commentary says plainly that arranging rights to the supplier's data sets reduces dependency. It is the argument of the AI capability you should not outsource, written as a contract annex.
• Article 19, AI register: public-sector only. Delete it, or repurpose it into the internal AI inventory you will need anyway.
• Article 21, costs: keep it word for word. It assumes every cost the supplier incurs in implementing these clauses is already covered by the agreed price. The most useful sentence in the document for a buyer, and the first one a supplier will try to qualify.

What does GIBIT 2025 Article 14 have that the EU clauses do not?

Four things, one of which is the reason to read a municipal template at all.

• A duty to keep you out of provider status. Article 14.3 puts a duty of care on the supplier to prevent the buyer being qualified as aanbieder rather than gebruiksverantwoordelijke under Regulation (EU) 2024/1689, which may mean warning you off certain actions or preventing them. The MCC-AI have no equivalent. Fine-tune, rebrand or substantially modify a purchased system and the whole Chapter III stack lands on your IT department: Article 25 has said since 2024 that the original provider then stops being the provider of that system. What the Omnibus added is what that provider still owes you, spelling out documentation, information on limitations and failure modes, and reasonably expected technical access for testing, with no such duty where it clearly specified the system was not to be made high-risk.
• A priced route for the unforeseeable, where the supplier is the provider. Article 14.2 applies only in so far as the supplier qualifies as aanbieder, and then gives it 20 working days to propose scope, lead time, impact and cost for risk-control measures that were not foreseeable at bid time, with the tests run in your environment at your expense. Establish which side of that condition your supplier sits on first.
• Classification help, disclosed at bid time. Article 14.4 obliges the supplier to support the risk classification, share its reasoning, and flag at the offer if the system will very probably classify as high-risk.
• Logging as a traceability duty, not a feature. Articles 14.6 and 14.7 tie the depth of logging to the intended purpose and reasonably foreseeable misuse. The MCC-AI get there too, but GIBIT states the purpose, which is what you argue from when the logs turn out useless.

The caveat is real. GIBIT is written for a gemeente as Opdrachtgever, and its quality standards, agreement generator and public-law duties do not transfer. Read Article 13.2 yourself rather than the commentary around it: the adopted text lets the supplier enrich its own application with your data on two cumulative conditions, that the enrichment is in no way traceable to you and that personal data is handled under the processor agreement. That is a different test from full anonymisation. ICTRecht's write-up describes the consultation draft. Take the articles, not the regime.

What belongs in your next AI contract, whichever template you start from?

Five clauses that neither set gives you complete, and that get cut first when a tender runs late.

• A named model and a change notice. Both templates assume a system that changes through releases; model behaviour changes without one. Name model and version, and require notice with a test window before a swap.
• The evaluation set is yours. Not the training data, not the weights: the set of cases with agreed correct answers. Whoever holds it can change supplier.
• Logs with a retention period and your own read access, borrowing MCC-AI Article 5.3.
• The provider-flip duty from GIBIT Article 14.3, with a list of the actions that would trigger it in your environment.
• Compliance cost inside the price, from MCC-AI Article 21, with the GIBIT 14.2 route priced for anything genuinely unforeseeable.

Who owns this inside a 250 to 5,000 FTE IT organisation?

At this size the template belongs to procurement, the security questions to the security officer, the platform to the ICT partner and the model to the AI supplier. Article 14.3 decides your exposure and sits with none of them by default. That is the seam we work in: we are the AI supplier that works alongside your ICT partner, not a replacement for it. Name an owner before the next tender opens, not during the evaluation.

One national caveat. GIBIT is a Netherlands instrument and we found no Flemish equivalent: a Belgian reader has the MCC-AI in Dutch translation and little else, and nothing in GIBIT 2025 was drafted against Belgian public law. In either country the fastest useful step is classification. Our EU AI Act risk checker gets you to a defensible first answer, and AI implementation in the Netherlands sets out how we build next to an existing IT estate.

For a wider practitioner view, the IAPP's practical guide to the MCC-AI is the most useful secondary reading we found, though it is partly member-gated. Last reviewed on 1 October 2026 against the Commission resource page, the Commentary PDF, Regulation (EU) 2026/1744 and the published GIBIT 2025 articles; the MCC-AI had still not been revised on that date.

Frequently asked questions