How to Build an AI Register in 90 Minutes (EU AI Act)

Most European SMBs treat the AI register as a heavyweight deliverable they will produce when EU AI Act enforcement bites. That is a category error. A working v1 takes ninety minutes if you scope it as a deployer-side inventory rather than a compliance artefact. Below is the five-step build we run with operations leads in our audit engagements. It puts an Annex III risk picture on a page by Friday afternoon and earns the room to do the slower work properly afterwards.

Quick Answer. An AI register is your deployer-side inventory of the AI systems your organisation runs. For the high-risk systems within the Act's scope it is where you document the controls that will meet the Article 26 duties — which apply from 2 December 2027 for the Article 6(2)/Annex III route and 2 August 2028 for Article 6(1) systems related to Annex I Section A products ¹; for everything else it is the map that tells you which systems those are. A working first version takes ninety minutes for an SMB under 200 staff.

What is an AI register?

The AI register is to the Article 26 deployer duties, which apply to high-risk systems from 2 December 2027 on the Article 6(2)/Annex III route and 2 August 2028 for Article 6(1) systems related to Annex I Section A products, what the Records of Processing Activities is to Article 30 of the GDPR — with Article 30(5) conditioning that record duty for organisations under 250 employees, though it still applies where the processing is likely to risk rights and freedoms, is not occasional, or covers Article 9 or Article 10 data. It is a living inventory that names each system in scope, classifies its risk tier and assigns an accountable person.

The EU AI Act does not prescribe the register's format in regulation text, and the Chapter III high-risk-system deployer duties discussed here are not yet in application: Article 113 sets 2 December 2027 for systems classified under Article 6(2) and Annex III, and 2 August 2028 for systems classified under Article 6(1). That second date does not reach every Annex I system: Article 2(2) limits Article 6(1) high-risk systems related to products under Annex I Section B legislation to Article 6(1), Article 60a and Articles 102–112, with Articles 57–59 only on the integration condition. Article 26 is not in that set, so those systems never acquire the deployer duties on any date. The 2 August 2028 route is for Article 6(1) systems related to products under Section A legislation, and only where the system is actually classified high-risk under Article 6(1). From those dates, and for high-risk systems, Article 26(2) requires the deployer to assign human oversight to natural persons with the necessary competence, training and authority, and to give them the necessary support; Article 26(6) requires the deployer of a high-risk system to keep the logs that system generates automatically, to the extent those logs are under the deployer's control, for a period appropriate to the intended purpose and at least six months, unless applicable Union or national law provides otherwise ¹. The register is the operational substrate that makes both visible. Where a high-risk system processes personal data, a data protection impact assessment is required under Article 35 of the GDPR where the processing is likely to result in a high risk to the rights and freedoms of natural persons ².

Why ninety minutes works (and what it does not buy you)

The register is not the destination. It is the map. Ninety minutes is enough to surface what AI is in use, classify its risk tier, and assign accountability. What ninety minutes does not buy you: a Fundamental Rights Impact Assessment, which Article 27 requires from 2 December 2027, and only of the deployer types and Annex III uses it specifies rather than of every high-risk row; the Article 4 AI-literacy measures — Article 4 has been applicable since 2 February 2025, and its current wording took effect on 27 July 2026; a vendor due-diligence pack.

The discipline of timeboxing matters more than the polish. In our engagements the SMBs that treat the register as a multi-week project usually do not produce one, and the ones that timebox a first version to ninety minutes produce it on day one and iterate. Article 26 includes duties that will run while a high-risk system is in use once they apply — 2 December 2027 on the Article 6(2)/Annex III route, 2 August 2028 for Article 6(1) systems related to Annex I Section A products — so a v1 you can update is worth strictly more than a v3 you have not started.

How does the 90-minute AI register workflow run?

Step 1 — List every AI system in use (15 minutes)

Three sources cover most of what you will find. Pull paid SaaS subscriptions from your finance ledger or expenses card — any vendor with "AI", "ML", "Copilot", "Assistant", or "Insight" in the product name belongs on the list. Pull embedded AI from your existing platforms — Microsoft 365 Copilot, Google Workspace Gemini features, Salesforce Einstein, HubSpot Breeze, Outlook auto-replies, Teams meeting summaries are all in scope, paid for or not. Pull shadow AI from a one-paragraph all-hands message asking which AI tools staff use day to day, including unpaid consumer accounts.

Treat shadow AI as in scope for the inventory. A staff member pasting a CV into a free ChatGPT account may put the organisation in the employment category of Annex III, which Article 6(2) and (3) govern — test it rather than assume it — and the personal data has left your environment under the GDPR ². The register's job is to surface that, not to police it. Policing comes in step 4 once you know what is there.

Step 2 — Risk-tier each system under Article 6 (20 minutes)

EU AI Act Annex III enumerates eight high-risk domains ¹: biometric identification, critical infrastructure, education and vocational training, employment and worker management, access to essential services, law enforcement, migration and border control, and administration of justice. For SMBs the live triggers are usually employment (CV screening, performance ranking, automated scheduling), access to services (credit decisions, insurance pricing), and education (training assessments, certifications).

For each system on your list, tag it as one of: high-risk — by Article 6(1), for a system related to a product covered by the Annex I Union harmonisation legislation and classified high-risk under that Article as read with 6(1a) to (1c); a Section B system keeps that classification, and what Article 2(2) changes is which provisions then apply to it, Article 26 not among them — or by Article 6(2) together with Annex III, which applies subject to Article 6(3): an Annex III system is not high-risk where it poses no significant risk of harm to the health, safety or fundamental rights of natural persons and meets one of the conditions that paragraph specifies, while an Annex III system that performs profiling of natural persons is always high-risk — limited-risk (transparency obligations under Article 50), minimal-risk, or general-purpose AI deployer. Those four tiers are our triage shorthand. The classification that matters legally comes from Article 6 by either route ¹, it is not settled by company size, and a vendor's own description of its product does not decide it for you.

Step 3 — Fill the ten core columns (25 minutes)

The columns that earn their place on a deployer register:

1. System name: what your staff calls it day to day.
2. Vendor: the legal entity behind the product.
3. Model or version: where known (e.g., GPT-4o, Claude 3.5, Gemini 1.5, in-house).
4. Use case: one sentence describing what the system decides or generates.
5. Risk tier: high / limited / minimal / GPAI deployer.
6. Personal data involved: Y/N, plus categories under the GDPR.
7. Lawful basis: the Article 6 GDPR basis (legitimate interests, contract, consent, and so on).
8. Accountable person: a named individual, not a team or role.
9. Automatic logs (Article 26(6), applicable from 2 December 2027 on the Article 6(2)/Annex III route and 2 August 2028 for Article 6(1) systems related to Annex I Section A products): for high-risk deployments — does the system generate logs automatically, are they under your control, and are they retained for a period appropriate to the intended purpose and at least six months unless Union or national law says otherwise. Y/N/N/A.
10. Date deployed: month and year, at minimum.

A spreadsheet with these ten columns is, in our experience, enough to answer the questions a customer's supplier-security review or a board member has opened with. Anything beyond is iterative work, not v1 work. Resist the urge to add columns until you have filled all ten across every row.

Step 4 — Name an accountable person per system (15 minutes)

From 2 December 2027 on the Article 6(2)/Annex III route, and 2 August 2028 for Article 6(1) systems related to Annex I Section A products, Article 26(2) requires the deployer to assign human oversight to natural persons with the necessary competence, training and authority, and to provide the necessary support ¹. Where oversight applies, Article 14(4) enables those persons, as appropriate and proportionate, to interpret the system's output correctly and to disregard, override or interrupt its operation ¹. Translate that to your register by recording who holds oversight for each high-risk row. We recommend a named individual rather than a role, because a role cannot be paged — our recommendation, not the Act's requirement.

For systems outside Annex III, name an owner anyway. Annex III is not the only route to high-risk status — Article 6(1) makes a system high-risk where it is a safety component of a product covered by the Union harmonisation legislation in Annex I, or is itself such a product, and where that product is required to undergo a third-party conformity assessment before it is placed on the market or put into service — read with Article 6(1a), which excludes a system used solely for non-safety-related aspects of user assistance, performance optimisation, service efficiency, automation, convenience or quality control, Article 6(1b), which brings back a system whose failure or malfunctioning would endanger health and safety, and Article 6(1c), under which a product needing that assessment solely for risks other than health and safety does not satisfy Article 6(1)(b) — so being outside Annex III does not by itself rule out high-risk classification. Operations leads and senior managers are the natural owners in most SMBs; a CTO or CDO is not required.

Step 5 — Spot-check human oversight on one high-risk system (15 minutes)

For your highest-risk row classified under Article 6, walk through three questions: is a human reviewing the AI output before it affects a person (the human-in-the-loop test); can that human override the AI decision in practice (the authority test); has the human been given role-appropriate training (the literacy test — our operational check, not an individual outcome the amended Article 4 mandates) ¹? The answers go into a free-text "human-oversight notes" column adjacent to the ten core columns.

You will not finish the human-oversight protocol in fifteen minutes. The goal is to surface where the gap is, not to close it. A row reading "no human review on CV-screening; gap to close within 30 days" is exactly the right output. The register's job is to make the gap visible; closing it is a separate workstream and a separate budget.

Five pitfalls that kill a v1 register

• Treating the register as a one-shot document. Article 26 includes duties that will operate while a high-risk system is in use once they apply, from 2 December 2027 on the Article 6(2)/Annex III route and 2 August 2028 for Article 6(1) systems related to Annex I Section A products, so treat the register as a living artefact. We review ours quarterly and refresh it whenever a new system is deployed or a vendor ships a major model change.
• Missing shadow AI. Unpaid consumer accounts and personal Copilot sessions are the highest-incident, lowest-visibility category. If the register does not surface them, it lies.
• Buying a "compliance tool" before listing. A vendor's compliance SaaS will not classify your use cases. Only your team can. Spreadsheet first, tool later (or never; for SMBs under 200 staff a maintained spreadsheet is sufficient).
• Assigning a role instead of a person. "IT team" cannot be paged; a named individual with a phone number can. Article 26(2) will require oversight to be assigned to natural persons with the competence, training and authority to carry it out, from 2 December 2027 on the Article 6(2)/Annex III route and 2 August 2028 for Article 6(1) systems related to Annex I Section A products ¹ — naming one person per row is our recommendation for making that real, not a form the Act prescribes.
• Skipping AI literacy entirely. Article 4 has been applicable since 2 February 2025, and its current wording took effect on 27 July 2026. It requires providers and deployers to take measures to support the development of AI literacy among their staff and other persons dealing with the operation and use of AI systems on their behalf, taking into account their technical knowledge, experience, education and training and the context in which the systems are to be used, and considering the persons or groups of persons on whom the systems are to be used. It expressly does not require them to guarantee a particular level of AI literacy for any individual. It is a measures duty, not a per-system checkbox — note in the register which systems drive which training.

What to do after the ninety minutes

The register is the discovery layer. Three follow-up workstreams typically lift off it:

1. FRIA scoping under EU AI Act Article 27 ¹, which applies from 2 December 2027 and only to the deployer types and Annex III uses that provision actually covers — a separate, deeper document that the register's risk-tier column initiates rather than replaces.
2. AI literacy measures under Article 4 — applicable since 2 February 2025, in its current wording since 27 July 2026 — scoped against the register's accountable-person column rather than against headcount.
3. Vendor due-diligence pack: DPAs, model cards, GPAI lineage, scoped against the register's vendor column and refreshed at procurement renewal.

These are the workstreams a designed-in approach covers in roughly twelve weeks for £18,000-32,000 in our engagement experience; a retrofit covers the same ground in six compressed weeks for £85,000-145,000. Those figures and the multiplier between them are our own, not a published finding. Separately, MIT Sloan's post-GDPR research recorded EU firms cutting stored data and computation after the Regulation took effect ³.

Summary

AI Register in 90 Minutes — a deployer-side inventory
│
├─ The five-step build
│   ├─ List (15m) — paid, embedded, and shadow AI in scope
│   ├─ Risk-tier (20m) — match each system to Annex III
│   ├─ Ten columns (25m) — the audit-ready floor, no more
│   ├─ Name owners (15m) — a person per system, not a team
│   └─ Spot-check (15m) — surface the oversight gap, don't close it
│
├─ Why timebox v1
│   ├─ A living map — Article 26 duties are continuous
│   └─ v1 you update beats v3 you never start
│
└─ What it doesn't buy
    └─ Downstream — FRIA, Article 4 literacy, vendor due diligence

Related insights

• AI Governance From Day One: SMB Cost of Retrofitting Compliance — the cornerstone this guide supports. Read it for the cost arithmetic, the Northbridge case, and the seven artefacts of day-one governance.
• Your SMB Doesn't Need More AI Tools. It Needs an AI Strategy. — the upstream piece on why a sanctioned AI list matters more than any individual subscription, and the audit-and-consolidate sequence that produces one.

Last updated: September 2026. Version 1.1. Rebased on the AI Act consolidation of 27 July 2026.