An AI register is the first list an auditor or works council asks for: every AI system you use, including AI features that arrived inside software you already pay for. The version that survives an audit has one line per use, not per product, and twenty fields, each tied to a duty in the AI Act, the AVG or ISO/IEC 42001.
This guide is for the IT manager, CIO, informatiemanager or security officer at a Dutch or Flemish organisation of 250 to 5,000 people who now owns the register. Crux Digits builds AI systems alongside your ICT partner; we do not run your CMDB or discovery tooling. For the general definition, see AI governance; this post is the register itself.
Is an AI register a legal requirement?
No AI Act article makes a private deployer keep an AI register, but at least five duties cannot be evidenced without one.
Article 4 asks providers and deployers to take measures supporting AI literacy among staff who use AI systems. It has applied since 2 February 2025 under Article 113, and the Digital Omnibus on AI, Regulation (EU) 2026/1744, rewrote it from 27 July 2026: measures are required, a guaranteed level per person is not. You cannot target measures without knowing who uses which system.
Article 26 holds the deployer duties for high-risk systems, from human oversight to log retention. After the Omnibus they apply to Annex III systems from 2 December 2027 and to Annex I systems from 2 August 2028, per the Commission's announcement. Article 50 transparency duties fall under the general date of 2 August 2026, and Article 27 adds a fundamental rights impact assessment for public bodies, private providers of public services, and deployers of credit-scoring or life and health insurance systems.
On the privacy side, every organisation with more than 250 staff keeps a record of processing activities under AVG Article 30, as Ondernemersplein states, and runs a DPIA under Article 35 when processing is likely to be high risk, which the Autoriteit Persoonsgegevens links to new technologies and profiling.
What counts as an AI system in the register, and what does not?
Register anything that infers its output from its input, the test in AI Act Article 3(1), and leave out rules people wrote.
Article 3(1) defines an AI system as a machine-based system that infers from input how to generate outputs such as predictions, content, recommendations or decisions. The Commission's non-binding guidelines on the definition of 6 February 2025, as CMS summarises them, exclude basic data processing such as sorting and filtering, classical heuristics on predefined rules, simple prediction a basic statistical rule could match, and basic mathematical optimisation.
Our decision rule has three questions. Does it produce predictions, content, recommendations or decisions? Did a person write every rule behind that output? Is it switched on in your tenant or used for your work? Yes, no, yes means it goes in. An AI feature inside bought software counts from the day it is enabled, not the day you notice it. A borderline case goes in too, marked "outside the definition" with reason and assessor, so an auditor sees it was assessed, not missed.
Register per use, not per product. Microsoft's Copilot overview separates Copilot Chat on web data, the Premium add-on grounded in organisational data through Microsoft Graph, meeting summaries and transcription in Teams, and agents. Transcribing staff meetings raises a works council question that drafting in Word does not. One licence, three or four lines.
Which fields does an AI register need?
Twenty fields cover what an auditor asks: ten identify and classify the use, ten hold the evidence that duties are met. Each field below names the question it answers and who fills it.
1. Name and use. Product, feature and use in one line, for example "Microsoft 365 Copilot, Teams meeting recap, project meetings". Filled by the register owner.
2. Type. Built in house, built for you, bought AI product, AI feature in bought software, or public tool. Answers: who can change it. Filled by IT.
3. Business owner. Accountable for the use and its outcomes. Filled by the process's line manager.
4. Technical owner. The contact at IT or your ICT partner who can switch it off today. Filled by IT.
5. Supplier and contract. Supplier, contract reference, renewal date, and whether the AI arrived by update. Answers ISO/IEC 42001 third-party controls and, if you are in scope, supply chain security. Filled by procurement.
6. Purpose and process. Answers the first element of an Article 27 assessment and scopes any impact assessment. Filled by the business owner.
7. AI Act role. Deployer or provider under Article 3, and whether an Article 25 trigger applies: your name on a high-risk system, a substantial modification, or a new purpose that makes it high-risk. Filled by compliance or legal.
8. Risk class with reasoning. Prohibited-practice check, Annex III area, Article 50 case or minimal, with date and assessor. HR screening sits in Annex III point 4(a); under Article 6(3) an Annex III use that profiles people is always high-risk. A first pass fits in our EU AI Act risk checker. Filled by compliance.
9. Affected persons. Staff, applicants, customers, citizens. Answers Article 26(11), Article 27(1)(c) and the DPIA screening. Filled by the business owner.
10. Personal data and processing record. Yes or no, and the ID of the Article 30 entry. Filled by the privacy officer or FG.
11. DPIA. Status and link. Article 26(9) has deployers use the provider's information for the DPIA, and the amended Article 27(4) lets a fundamental rights assessment cross-reference it. Filled by the FG.
12. Data flow. Sources it reads, where processing happens, and whether the supplier may use your inputs for training. Filled by IT and security.
13. Instructions for use. Where the provider's instructions are stored, and which version. Answers Article 26(1). Filled by the technical owner.
14. Human oversight. The named role with the competence, training and authority Article 26(2) requires. Filled by the business owner.
15. Logs. Location and retention; for high-risk systems Article 26(6) requires at least six months for automatically generated logs under your control. Filled by IT.
16. Monitoring and incident route. Who informs the provider, and who decides to suspend use, as Article 26(5) describes. Filled by the technical owner.
17. Transparency. Whether and how people are told, under Article 50(3) and (4) and Article 26(11). Filled by the business owner.
18. Works council. Consent or information status under WOR Article 27, and the Article 26(7) duty to inform workers' representatives before workplace use. Filled by HR.
19. AI literacy. Which roles use it and which measure supports them. Answers Article 4. Filled by HR or learning and development.
20. Status and review. Live since, last review, next review, retirement date. Filled by the register owner.
Who owns the AI register if it is not IT?
One named register owner, usually the privacy officer, the CISO or a compliance lead; each line belongs to the business owner of the process.
IT cannot own it alone: the risk class depends on purpose, and only the business knows the purpose. The same recruitment platform can sit outside Annex III when it only schedules interviews and inside it when it ranks applicants. A workable split: IT or your ICT partner supplies discovery data and fields 2, 4, 12, 15 and 16; procurement field 5; the FG fields 10 and 11; HR 18 and 19; compliance signs off 7 and 8. The register owner chases gaps and reports to the management review.
How does the AI register relate to the CMDB and the verwerkingsregister?
Link them, do not copy: the CMDB knows the application, the verwerkingsregister the personal data, the AI register the use and its risk class.
The Article 30 record holds purpose, categories of people and data, retention, recipients and security. It does not say whether a step infers anything or which AI Act class applies. The CMDB holds the configuration item, licence and owner, not the purpose. Add an AI flag to the application CI, key each register line on the CMDB ID, and store the processing record ID in field 10. Three registers then answer one audit question without a fourth copy going stale.
For ISO/IEC 42001, the register is evidence for several of the 38 Annex A controls, in areas Vanta lists as resources for AI systems, assessing impacts of AI systems, the AI system life cycle, use of AI systems, and third-party and customer relationships. ISO/IEC 42005:2025, released in May 2025 per CMS, guides the impact assessment itself. Our post on ISO 42001 next to ISO 27001 covers what carries over from an ISMS.
If your organisation falls under the Cyberbeveiligingswet, in force since 15 August 2026, its Article 21 requires measures for the security of the supply chain, including relations with direct suppliers, as NCSC explains. Field 5 then doubles as supplier evidence; see the Cbw and AI suppliers.
How do you find shadow AI and AI inside software you already bought?
Use four sources: the contract list, the discovery tools already in your tenant, procurement and expense data, and a short questionnaire to process owners.
Start with contracts, because embedded AI can arrive by update, not purchase; see a vendor adding AI to existing software. In a Microsoft estate, Microsoft's AI discovery guidance names Entra Agent ID for Copilot Studio and Foundry agents, Purview DSPM for AI for Copilot and third-party AI sites, Defender for Cloud Apps with a Generative AI category of over a thousand apps, and Defender for Cloud CSPM for your own Azure AI workloads.
Then check card statements and purchase orders for AI subscriptions, and ask each process owner which tools they use, on what data, and who checks the output. Discovery that records named users can make the tooling a personeelsvolgsysteem, so read shadow AI detection and works council consent first.
What can a private organisation learn from the Dutch Algoritmeregister?
Its description template is a tested field list, and you may borrow it without any duty to publish.
The Algoritmeregister at algoritmes.overheid.nl launched in December 2022 and showed 1,599 algorithm descriptions from Dutch government bodies on 26 October 2026, focused on impactful algorithms including high-risk AI systems. Its about page says publishing is not yet mandatory even for government organisations, though an obligation is coming. Private organisations have no duty to publish. Public-authority deployers of high-risk systems must register in the EU database under Article 26(8), a separate duty.
Copy the structure of a published entry: purpose and impact, considerations, human intervention, risk management, legal basis, impact assessments, data, technical operation and supplier. Considerations, human intervention and impact assessments are the headings to add first, because no CMDB or verwerkingsregister holds them.
How often should the AI register be reviewed?
Review each line when a trigger fires and the whole register once a quarter; that is our working rule, not a legal deadline.
Triggers: a new vendor feature, purpose, data source or group of affected people, an incident, a contract renewal. Article 27(2) requires a fundamental rights assessment to be updated when an element changes; the register is where you notice. The quarterly pass checks owners and dates; an annual rerun of discovery catches what triggers missed. The register then feeds the ISO/IEC 42001 management review as an input.
Where Crux Digits fits
We do not maintain your register, run your discovery tooling or replace your ICT partner. We help with the AI systems we build: each is delivered with the material for fields 12 to 16, meaning the data flow, logging and retention set-up, human oversight step and instructions for use, so its line is complete on the day it goes live. The code and the documentation are yours.
How we build AI for organisations this size: applied AI for mid-sized businesses.
Last updated: 26 October 2026.
The AI audit & strategy: in one to two weeks, a ranked list of use cases with a return per opportunity, and a plan you own.
AI audit & strategy →
