A Dutch public body deploying a high-risk AI system has two registers to think about. One is the EU database created by the AI Act, where registration is a legal duty under Art. 49. The other is the national Algoritmeregister, where publication is a transparency commitment with its own publication standard. They ask for overlapping information, they are not the same, and neither entry discharges the other. This article covers what the EU duty requires, what the Dutch entry contains, what a tool can safely pre-fill, and what should never be filled in without a person.
The EU database duty, and its numbering
Art. 49 has five paragraphs and they are easy to confuse. Art. 49(1) is the provider's registration of itself and the system before placing it on the market. Art. 49(2) is the provider's registration of a system it has concluded is not high-risk under the Art. 6(3) derogation. Art. 49(3) is the public-authority deployer's duty: before putting into service or using an Annex III high-risk system, deployers that are public authorities, Union institutions, bodies, offices or agencies, or persons acting on their behalf, register themselves, select the system, and register its use in the EU database referred to in Art. 71. Art. 49(4) moves registrations for Annex III points 1, 6 and 7 in the law enforcement, migration, asylum and border control areas into a secure non-public section. Art. 49(5) sends Annex III point 2 systems, critical infrastructure, to national registration instead.
Two consequences follow for a municipality or agency. First, you select a system that the provider has already registered. If it is not there, Art. 26(8) says you shall not use it and shall inform the provider or distributor. Second, the public-facing duty is yours even though the technical documentation is the provider's.
The application date for Annex III duties is 2 August 2026, with a transitional rule in Art. 111(2) that gives public-authority use of systems already on the market until 2 August 2030. The Digital Omnibus proposal may alter these dates, so check before scheduling.
What goes in the EU entry
Annex VIII, Section C sets out what a deployer submits under Art. 49(3). In summary: the deployer's name, address and contact details; the name of the person submitting on its behalf; the URL of the provider's entry for the system; a summary of the findings of the Art. 27 fundamental rights impact assessment; and, where applicable, a summary of the GDPR Art. 35 data protection impact assessment. The entry is therefore downstream of the FRIA and the DPIA. Registration cannot sensibly be the first thing you do.
What goes in the Dutch entry
The Algoritmeregister publishes entries in its own publication standard, version 1.0.0 at the time of writing, which the Ministry of the Interior maintains as a machine-readable schema. It has 32 properties, 18 of them mandatory, grouped into the standard's categories. The fields a body has to think hardest about are:
- Publication category. The standard distinguishes high-risk AI systems, which are category A, from other impactful and other algorithms. Whether a non-high-risk system is category B or C is the body's own judgement.
- Legal basis. The statutory task the system serves. Only the body knows this.
- Status and start date. Whether the system is in development or in use, and since when.
- Contact. A general contact point, and the standard says explicitly not a personal e-mail address.
- Purpose and impact, considerations, data, supplier. Descriptive fields in the body's own words.
- Human intervention, risk management, impact assessments, technical operation. Fields that can be drafted from an assessment and from the system's documentation.
A national entry is also expected to reference the impact assessment, which in the Netherlands normally means the IAMA record. If your IAMA, FRIA and DPIA live in one record, that reference is one identifier.
What a tool can pre-fill, and what it must not
Some fields follow from facts a screening already holds. If the computed classification is high-risk, the publication category can be proposed as category A, with a note where the classification rests on a claimed but undocumented Art. 6(3) derogation. Human intervention can be drafted from the Art. 14 or Art. 26(2) position. Risk management can summarise the tier, the applicable obligations and the number of unanswered questions. Impact assessments can state the DPIA, FRIA and prior-consultation positions with the basis each rests on. Technical operation can list where the codebase scan found AI components.
Other fields must never be guessed. Legal basis, status, start date, contact, purpose and impact, considerations, data and supplier are facts about the organisation, not about the code. A register entry published to citizens with a plausible guess in one of them is worse than an entry with an honest placeholder. The right behaviour for a tool is to print a visible "to complete" marker, in the language of the entry, and to print where every derived value came from so the publishing official can check it.
Two derivations deserve a human decision rather than a default. Whether category A should ever be proposed automatically, or every publication category left to the body, is a policy choice. So is which identifier goes in the source-id field.
A worked example
The fictional Brakelhout Water Authority is about to use a vendor's model to prioritise inspections of private sewage connections, with fines for non-compliance following an inspection. It is a body governed by public law. Whether the use falls in Annex III point 5(a), or in no Annex III area at all, is the question its lawyers are settling; assume high-risk for this example.
The order of work is: complete the FRIA and the DPIA, and record them in one assessment record. Ask the vendor for the URL of its Art. 49(1) entry; if none exists, do not go live and tell the vendor. Register the authority and its use under Art. 49(3), summarising both assessments. Draft the Algoritmeregister entry: category A proposed from the classification, human intervention from the inspector review step, impact assessments citing the record identifier. Then a named official fills in the legal basis (the water board bye-law), the status, the start date, the general contact address, the purpose in plain Dutch, and the supplier. Publish. Put an owner on keeping both entries current when the model version or the purpose changes.
How Landfall helps
For a public-sector project Landfall drafts the Algoritmeregister entry in the shape of the publication standard, as a Dutch table or as JSON keyed by the standard's own property names, with the origin of every derived value printed beside it. The eight fields it cannot know come out as the literal placeholder, and a test asserts that no English placeholder can leak into the Dutch entry. The Art. 49(3) row of the report states whether registration applies and on which answers that rests. A body that has already published an entry can paste it back in, and the closed fields become suggestions for unanswered questions, never answers.