How to build an AI system register for your company. Six steps

An AI system register is a list of the AI-based tools an organisation uses, together with who is responsible for each one, what it is used for and what data reaches it. For most companies it is not a separate obligation - it is the precondition for meeting the obligations that already apply.

Below are six steps, control questions for each and the fields that decide whether a register ends up being of any use.

When does an AI system register make sense?

The legal position is current as of 25 August 2026. The AI Act does not require an ordinary company to keep a register as such. The Article 49 duty to register in the EU database concerns high-risk systems, and those have been pushed to 2 December 2027 for Annex III and 2 August 2028 for Annex I.

The register earns its keep elsewhere. Article 4 has required competence measures matched to systems and roles since 2 February 2025. Article 50 requires disclosure and marking from 2 August 2026. Article 5 bans certain practices. None of the three can be met by an organisation that does not know what it uses.

Step 1: Tools - what are we actually using?

The list never gets built inside IT, because IT sees only what it bought itself. Start from invoices and company-card statements, then ask people. Marketing typically has two tools nobody knows about. Finance has one that has been running for two years.

Control questions: Have we checked subscriptions paid on cards by individual departments? Have we counted AI features built into systems used for years, for example in the CRM or the mail client? Have we counted tools used on personal accounts for work tasks? Did somebody just ask directly, rather than send a survey?

Skip this step and every step after it describes a different company from the one you actually work in.

Step 2: Owner - who is responsible for each entry?

The owner is the person who decides how the tool is used, not the one holding the admin password. That distinction looks like a formality right up until someone has to be asked whether it is fine to paste a customer list into the model.

Control questions: Does every entry carry a named person, not a department name? Does the owner know they are the owner? For shared accounts, do we know who actually uses them? Is anyone responsible for tools whose owner has left the company?

An entry with no owner never gets updated, and six months later it is a record of a tool that no longer exists.

Step 3: Purpose - what exactly is it used for?

This is the field where a content-free sentence lands most often. “Supporting the team's work” is not a purpose. A purpose is “generating product descriptions for the shop” or “initial screening of applications in recruitment.” The difference is practical: purpose decides whether a system falls into high-risk, what training scope its user needs, and whether anything needs to be disclosed.

Control questions: Does the purpose describe an activity rather than a category of tool? Can you tell from it who receives the output? Does it cover uses that emerged after rollout? Does it match what people actually do?

A vaguely written purpose saves thinking now and costs at every step that follows.

Step 4: Data - what reaches this tool?

Do not list examples, list categories: customer personal data, employee data, material under confidentiality, financial data, technical documentation. A category answers the risk question without opening a debate about individual files. This is also where the overlap with data protection shows up most often, so it is worth doing this step together with whoever owns that.

Control questions: Do we know where the tool processes data? Have we checked what the vendor does with the input? Does the plan we are on exclude training on our content? Did someone verify that, or just assume it?

An unknown answer in this field is information, not a gap. Write it down and come back to it.

Step 5: Role - are we a provider or a deployer?

This piece is written for a deployer - an organisation using off-the-shelf tools under its own responsibility. Most companies sit in that role and carry a narrower set of obligations than a provider. The role is not fixed once for the whole company, though - it is decided per system.

Control questions: Do we make any tool available to clients under our own name? Have we repurposed someone else's system beyond what the provider intended? Are we building on top of someone else's model and selling that on? Has anyone checked this per entry rather than in bulk?

A “yes” to any of those moves that entry into the provider role, with the full set of Article 25 obligations that come with it.

Step 6: Review - how will we know the register is current?

A register with no next review date is a photograph, not a document. Set a quarterly cycle and assign it to a person, ideally the same one who keeps the subscription list.

After this step the organisation has four things it can show: a list of systems with owners and purposes, assigned data categories, a decided role for every entry, and a date and scope for the last review along with what changed since the one before. That is the foundation everything else rests on: choosing training, assessing risk, disclosure, and answering a vendor questionnaire from a client.

Frequently asked questions

Does the register have to live in a piece of software?

No. A spreadsheet is enough and is a reasonable choice at a dozen or so entries. The problem shows up at maintenance, not at setup.

Do tools used only once need an entry?

Yes, if company data reached them. A one-off use leaves the same trace as regular use.

Is this the same as a GDPR processing register?

No, though the two overlap. A processing register covers personal data processing; an AI system register covers AI systems regardless of whether they process personal data.

By hand or with a tool?

You will build the first version of the register in a spreadsheet, and that is a sensible way to start. The cost shows up later: at review time, at tracking who answered whom, and at pulling out a summary you can show the board or a client. The AI TrustCERT platform keeps the register alongside risk assessment and a record of the measures taken, included in the price of the training licence. It supports the process and organises the evidence, it does not replace a legal assessment. You can open it for seven days without a card and see how it looks with your own tools.

Summary

An AI system register is not, for most companies, a separate obligation - it is the precondition for meeting the obligations that already apply. Start from invoices, not a survey, because invoices do not forget. Every entry needs a named owner and a purpose described as an activity, not a category. Data categories say more about risk than a list of files. Role is decided per system, since one tool offered to clients under your own name shifts obligations for the whole organisation. The last step, review with a date and an owner, decides whether after a quarter you still have a document or a photograph from one. The six steps then feed everything downstream: choosing training, assessing risk, answering vendor questionnaires.

This material is for information purposes. It is not legal advice or a guarantee of compliance with the AI Act. For a specific organisation, consult a lawyer.

✦ This article was written with the help of artificial intelligence and reviewed before publication by the author, who takes editorial responsibility for it.