Skip to main content
Back to Blog
AI 12 min read 30 April 2026

How to Build an AI System Register: EU AI Act + ISO 42001 + NIST AI RMF

A practical guide to building a multi-framework AI system register for SMEs. Covers EU AI Act risk classification, ISO/IEC 42001:2023 alignment, NIST AI RMF posture and the ICO AI auditing framework — and the pitfalls that destroy AI-inventory programmes.

Most organisations have AI systems they do not have on a list. The first hour spent building the list typically reveals a half-dozen AI use cases nobody knew the business depended on. The second hour reveals at least one use case that should have been classified as high-risk under the EU AI Act six months ago.

This guide explains how to build an AI system register that satisfies the EU AI Act, aligns with ISO/IEC 42001:2023 (the AI management system standard), maps to the NIST AI Risk Management Framework, and complements the UK ICO's AI auditing framework. It is written for SMEs and mid-market organisations between 50 and 500 employees, and assumes you do not have a dedicated AI governance team.

Why a register, not a "policy"

SME AI governance work tends to start with a policy and stop there. A one-page AI policy is a useful artefact, but it is not what regulators and auditors are asking for in 2026. They are asking for evidence that you know which AI systems you operate, in what role, classified at what risk tier, with what oversight.

The register is the artefact that proves it. The policy says what you should do; the register says what you are actually doing.

What the register must contain

A single sheet (or database table) with one row per AI system. The columns that matter:

  • System identifier and name — short stable ID and human-readable name
  • Purpose — one paragraph describing what the system does and why
  • Vendor or in-house — and the vendor name if applicable
  • Owner — accountable person (real name, not "the team")
  • Department(s) using it — which business units
  • Data classification — Public / Internal / Confidential / Restricted, mapped to your existing data classification scheme
  • Personal data involved — None / Standard / Special category
  • Automated decisions — None / Decision-support / Solely automated (latter triggers GDPR Article 22)
  • EU AI Act risk tier — Prohibited / High-risk / Limited-risk / Minimal-risk
  • Organisation role(s) — Provider / Deployer / Importer / Distributor / GPAI Provider
  • Article 50 transparency obligations triggered — Yes / No
  • Human oversight in place — Yes / Partial / No (with description)
  • Article 4 AI literacy training — Yes / In progress / No
  • Last reviewed — date
  • Status — Active / Retired / Archived

Add an ISO 42001 alignment field (Aligned / Partial / Gaps), a NIST AI RMF posture field (the same), and an ICO AI auditing framework field if you process UK data subjects' data. The four-framework view is what enterprise customers, regulators and insurers increasingly ask for.

EU AI Act risk classification — the practical method

The four-tier classification under the EU AI Act (Regulation (EU) 2024/1689) sounds straightforward and is misapplied frequently. The decision flow:

  1. Step 1 — Article 5 prohibition check. Does the system fall under any of the eight Article 5 prohibitions (subliminal manipulation, exploitation of vulnerabilities, social scoring by public authorities, predictive policing solely on profiling, untargeted FR-database scraping, emotion recognition in workplace/education with limited exceptions, biometric categorisation by sensitive attributes, real-time remote biometric identification by law enforcement in public spaces with narrow exceptions)? If yes — prohibited. Stop.
  2. Step 2 — Annex III check. Does the system fall under any of the eight Annex III categories (biometrics, critical infrastructure, education, employment and worker management, essential services, law enforcement, migration / asylum / border, administration of justice and democratic processes)? If yes — provisional high-risk; consider Article 6(3) exit.
  3. Step 3 — Article 6(3) exit. An Annex III system is NOT high-risk if it (a) performs a narrow procedural task, (b) improves a previously completed human activity, (c) detects patterns or deviations without replacing or influencing the human assessment, or (d) performs a preparatory task. But: profiling of natural persons is always high-risk regardless. Document the exit assessment if you rely on it.
  4. Step 4 — Article 50 transparency. Does the system interact with people, generate synthetic content, perform emotion recognition or biometric categorisation? If yes, limited-risk and Article 50 transparency obligations apply.
  5. Step 5 — Default minimal-risk. Everything else.

The most common SME errors: classifying a CV-screening tool as limited-risk (it is high-risk under Annex III(4)); classifying a vendor-supplied chatbot as minimal-risk (Article 50 transparency applies); classifying a fine-tuned vendor LLM as a deployer use case (Article 25 may have made the SME a provider).

Organisation roles — get this right early

Article 25 makes the role analysis non-trivial. Five roles to consider:

  • Provider — develops the AI system and places it on the market under its own name; or under Article 25, has substantially modified an existing high-risk AI system; or has placed its name or trademark on a system already on the market
  • Deployer — uses the system under its own authority for a professional purpose
  • Importer — places on the EU market a system from a non-EU provider
  • Distributor — other supply-chain actor making the system available on the EU market
  • GPAI Provider — places a general-purpose AI model on the market (separate role with dedicated obligations under Articles 53-55)

Most SMEs are deployers of vendor systems and providers of any in-house tools. The frequent surprise: fine-tuning a vendor LLM with proprietary data is potentially a substantial modification under Article 25, making the SME a provider for the modified system. This is fact-specific and should be documented carefully.

ISO/IEC 42001:2023 alignment — the AIMS overlay

ISO/IEC 42001:2023 is the international standard for AI management systems. It is structurally similar to ISO 27001 (a Plan-Do-Check-Act ISMS shape) and uses Annex A controls grouped by lifecycle stage.

For each AI system in your register, assess its alignment to ISO 42001 on three levels:

  • Aligned — an AI management system exists; documented controls cover the relevant Annex A clauses; periodic review is evident; the AI policy is enforced
  • Partial — some controls in place; gaps in oversight, change management or AI policy; no integrated AIMS
  • Gaps — no formal AI management system; controls ad-hoc or absent

An ISO 42001 certification effort is a 12-18 month programme costing £30,000-£100,000 for an SME. Most SMEs are not in that programme and do not need to be — but the directional alignment view in your register is increasingly asked about by enterprise customers and procurement teams.

NIST AI Risk Management Framework — Govern, Map, Measure, Manage

NIST AI RMF 1.0 organises AI risk management into four functions:

  • Govern — AI risk-management governance, policies, accountability structures
  • Map — system context, intended use, deployment environment, dependencies
  • Measure — performance metrics, risk metrics, monitoring
  • Manage — risk-treatment decisions and ongoing risk management

For your register, posture per system:

  • Aligned — explicit governance structure; system context documented; measurable performance and risk metrics; ongoing risk management evident
  • Partial — at least two of four functions show some maturity; gaps in others
  • Gaps — little or no NIST AI RMF alignment

NIST AI RMF is not a regulation. It is a voluntary framework that has become the de-facto reference in US enterprise procurement and is increasingly cited in vendor RFPs. For UK and EU SMEs, alignment to NIST AI RMF is a procurement asset rather than a compliance requirement.

UK ICO AI auditing framework — the eight principles

The Information Commissioner's Office (ICO) AI auditing framework applies where you process personal data of UK data subjects in connection with AI systems. Eight principles:

  1. Accountability and governance
  2. Lawful basis for processing
  3. Fairness
  4. Transparency
  5. Data minimisation and accuracy
  6. Security
  7. Individual rights (including Article 22 automated decisions)
  8. Effectiveness of mitigation measures

For each AI system processing UK personal data, assess posture (Aligned / Partial / Gaps). Where the system performs solely automated decisions producing legal or significant effects, GDPR Article 22 obligations layer on top.

Action items per system — the part that drives outcomes

A register without action items is a list. A register with framework-attributed, prioritised action items is a programme. For each system that scores below "aligned" on any framework, capture:

  • A concrete action (not "improve governance" — instead "name a designated AI Governance Officer for this system; effective Q3 2026")
  • The framework it addresses (EU AI Act, ISO 42001, NIST AI RMF, ICO AI auditing)
  • Priority (P0 = within 30 days; P1 = within 90 days; P2 = within 180 days)
  • Owner
  • Optional: deadline

The register and the action-item list together are what an auditor or enterprise procurement team wants to see.

Quarterly cadence — and what triggers an out-of-cycle review

The register is not a one-shot deliverable. Quarterly review by the AI Governance Officer is the floor. Out-of-cycle reviews triggered by:

  • A new AI system going live (review within 30 days of go-live)
  • A substantial modification to an existing system (Article 25 trigger)
  • A change in the system's data flows or customer-facing exposure
  • A regulatory change (Commission delegated act updating Annex III; AI Office guidance)
  • A serious incident under Article 73 (provider-side) or material near-miss (deployer-side)

Three pitfalls that destroy AI-inventory programmes

Pitfall 1 — Over-scoping at the start

The team tries to build the perfect register from day one and never finishes. Capture the basic columns first; add framework-alignment fields in the second pass; add action-items in the third. A working 80% register is better than a perfect register that does not exist.

Pitfall 2 — IT-only ownership

The IT team builds the register and the rest of the business does not engage. The register documents the systems IT knows about and misses the marketing tool, the HR tool, the embedded AI in the M365 tenant. AI inventory is cross-functional or it is incomplete.

Pitfall 3 — Static document

The register is built once and never refreshed. Six months later it bears little resemblance to the actual operating reality. The register is a database (or a sheet treated like one), not a Word document; it has explicit review cadence and out-of-cycle triggers.

Where SummitBridge Horizon fits

AI Risk Scorer turns this from a hand-built sheet into a portfolio dashboard. £19/month, unlimited classifications, multi-framework analysis (EU AI Act + ISO 42001 + NIST AI RMF + ICO AI auditing) per system, branded register PDF export. The free EU AI Act risk classifier handles one-shot single-system classification.

For organisations needing a conformity assessment under EU AI Act Article 43, an ISO/IEC 42001 certification audit, or a full NIST AI RMF programme implementation, our advisory team takes it further from £750.

Need help with this?

Our team can help you assess where you stand and build a practical remediation plan. Free 30-minute consultation — no obligation.

Book a Free Consultation

Related Articles