Does an AI register replace the GDPR ROPA?

No, they are complementary inventories with different legal bases. The Records of Processing Activities (ROPA) is required under UK GDPR Article 30 and catalogues personal-data flows. The AI register is the deployer-side counterpart under EU AI Act Article 26 and ICO guidance, cataloguing every AI system regardless of whether it processes personal data. Many systems appear on both, but the cross-reference is one-to-many in both directions.

Our staff use free ChatGPT and consumer Copilot. Do those count for the register?

Yes. Article 26 deployer obligations apply to the SMB regardless of whether the AI subscription is corporate or consumer, paid or free. The moment a staff member uses an AI tool in the course of work, the SMB is the deployer and the system belongs on the register. Free consumer accounts also typically lack the data-processing agreement an enterprise tier provides, raising UK GDPR exposure rather than reducing it.

Our SMB is based outside the EU. Does the EU AI Act apply to our register?

For SMBs based outside the EU, direct EU AI Act applicability is narrower but rarely zero. The Act reaches extraterritorially when system output is used inside the EU, which happens routinely for SaaS products and B2B services. Even without EU exposure, national regulators are tracking the Act's deployer logic — the ICO has aligned UK AI guidance with it since 2023, and similar non-EU European jurisdictions are following suit. A register designed against Article 26 also satisfies these national directions of travel.

Who should own the AI register inside an SMB that has no CTO?

The Operations Director, Head of Compliance, or a senior person reporting to the MD. The register is editorial work, not technical: maintaining rows, refreshing risk tiers when systems change, and chasing accountable persons each quarter. A common SMB pattern is one named owner running the register at about three hours per quarter, plus the named accountable person per row carrying their own system-specific obligations.

How often should we refresh the register?

Quarterly is the realistic floor for SMBs, plus an event-driven refresh whenever a new AI system is procured or a major model change ships (a vendor moving from one model generation to the next, for example). For Annex III high-risk rows, log entries refresh continuously under Article 26(6). A static register a year old fails the demonstrability test in front of a regulator or enterprise procurement team.

Is a spreadsheet sufficient, or do we need a dedicated GRC tool?

For SMBs under about 200 staff, a spreadsheet is sufficient. The columns, the named owners, and the quarterly refresh discipline carry the audit weight, not the platform. Excel or Google Sheets with restricted access and version history satisfies the demonstrability requirement. Dedicated GRC tools become useful above roughly 500 staff or fifteen-plus AI systems; below that, the tool overhead exceeds the time savings.

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 — the same one that 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 the deployer-side inventory of every AI system in your organisation, presumed by EU AI Act Article 26 deployer obligations [1] and aligned with ICO guidance under UK GDPR [2]. A working v1 takes ninety minutes for SMBs under 200 staff: 15 minutes to list, 20 to risk-tier against Annex III, 25 to fill the core columns, and 30 to assign owners and spot-check oversight.

What is an AI register?

The AI register is to Article 26 deployer obligations what the Records of Processing Activities (ROPA) is to UK GDPR Article 30: a living inventory that names every system, classifies its risk tier, and assigns an accountable person. It is the document an ICO investigator, a procurement department, or an enterprise customer's vendor-security team will ask for first.

The EU AI Act does not prescribe the register's format in regulation text. Article 26(5) requires deployers of high-risk systems to ensure human oversight by a named, competent person; Article 26(6) requires logging of high-risk uses for at least six months [1]. The register is the operational substrate that makes both visible. The ICO has been clear since 2023 that AI processing personal data under UK GDPR triggers DPIA discipline and accountability obligations [2], and the ICO AI auditing toolkit enumerates the kinds of structured records an SMB will need [3]. No regulator mandates a specific tool. A spreadsheet that names the right columns and assigns the right owners passes the test.

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 — the trio of facts every deployer must demonstrate before a regulator, customer, or board asks. What ninety minutes does not buy you: a Fundamental Rights Impact Assessment under Article 27 for each Annex III system, an Article 4 AI-literacy curriculum proportionate to role, a vendor due-diligence pack covering DPAs and model cards, or a fully written human-oversight protocol [1]. Those are downstream workstreams, scoped against what the register surfaces.

The discipline of timeboxing matters more than the polish. In our audit engagements the SMBs that treat the register as a multi-week project usually do not produce one; the SMBs that timebox v1 to ninety minutes produce a register on day one and then iterate it. Article 26 obligations are continuous, not point-in-time, 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. A staff member pasting a CV into a free ChatGPT account makes the SMB an Annex III high-risk deployer under the EU AI Act employment provisions [1], and the data leaves your environment under UK GDPR [2]. The register's job is to surface it, not police it. Policing comes in step 4 once you know what is there.

Step 2 — Risk-tier each system against Annex III (20 minutes)

EU AI Act Annex III enumerates eight high-risk domains [1]: 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 (Annex III match), limited-risk (transparency obligations under Article 50), minimal-risk (no specific obligations beyond Article 4 literacy), or general-purpose AI deployer (using a GPAI model as the backbone for a chatbot or assistant) [1]. Most SMB stacks land in two or three tiers. The classification is the deployer's call; it is not delegable to the vendor and it is not affected by company size.

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

The columns that earn their place on a deployer register:

System name — what your staff calls it day to day.
Vendor — the legal entity behind the product.
Model or version — where known (e.g., GPT-4o, Claude 3.5, Gemini 1.5, in-house).
Use case — one sentence describing what the system decides or generates.
Risk tier — high / limited / minimal / GPAI deployer.
Personal data involved — Y/N, plus categories under UK GDPR.
Lawful basis — UK GDPR Article 6 basis (legitimate interest, contract, consent, etc.).
Accountable person — a named individual, not a team or role.
Article 26(6) logging — Y/N/N/A for high-risk deployments.
Date deployed — month and year, at minimum.

A spreadsheet with these ten columns answers the first question every regulator, customer, or board member will ask. 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)

Article 26(5) requires deployers of high-risk systems to ensure human oversight by a competent, accountable person with authority to pause or override the system [1]. Translate that to your register by naming an actual individual against every Annex III row — not a role like "IT lead" or "Head of Operations". The accountable person needs three properties: they can read the system's outputs, they have the authority to switch it off, and they are reachable by name in your register.

For non-Annex III systems, name an owner anyway. The formal obligation is lighter; the discipline is the same. 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 Annex III row, 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 under Article 4 (the literacy test) [1]? 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.

Which five pitfalls kill a v1 AI register?

Treating the register as a one-shot document. Article 26 obligations are continuous; the register is a living artefact reviewed at least quarterly and refreshed whenever a new AI system is deployed or a vendor pushes 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(5) presumes the latter [1].
Skipping Article 4 literacy entirely. Article 4 has applied since 2 February 2025 to every staff member using AI, proportionate to their role [1]. It is not a tier — every system surfaces an Article 4 obligation. Note it in the register even when the curriculum itself is downstream work.

What to do after the ninety minutes

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

FRIA scoping for each Annex III row, under EU AI Act Article 27 [1] — a separate, deeper document that the register's risk-tier column initiates rather than replaces.
Article 4 literacy curriculum — proportionate to role, scoped against the register's accountable-person column rather than against headcount.
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, and the same workstreams a retrofit approach covers in six compressed weeks for £85,000-145,000 — a multiplier consistent with the MIT Sloan post-GDPR data on EU firms cutting stored data 26% and computation 15% under enforcement pressure [4]. The register is the cheapest possible first move against that arithmetic.

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: May 2026. Version 1.0.