What is an AI register — and why every deployer needs one

Every AI governance framework — the EU AI Act, ISO 42001, NIST AI RMF — starts from the same object: a register of the AI systems you actually operate. Here is what an AI register is, what belongs in each entry, and why it is the first artifact anyone asks for.

Updated July 17, 2026 · Informational guidance, not legal advice

The register, defined

An AI register (also called an AI registry, AI inventory, or AI system register) is a structured record of every AI system an organization provides or deploys — one entry per system, each carrying the facts that governance decisions hang off: what the system does, who owns it, what role you hold for it, what risk class it falls into, and where the evidence behind those answers lives.

It is not a model card, not a vendor list, and not a data-processing record, though it touches all three. A model card describes one model's behaviour; a register describes your portfolio and your obligations across it. The unit of account is the AI system in its deployment context — the same unit the EU AI Act regulates.

Why regulation keeps arriving at the register

The EU AI Act never says the words "maintain an AI register" as a general duty — and yet almost none of its obligations can be met without one. Article 5 requires you to know no system crosses into prohibited practices. Article 6 and Annex III require a risk classification per system, with documented reasoning. Article 4 requires literacy appropriate to the systems staff actually use. Article 26 attaches oversight, monitoring, and log-retention duties per high-risk system. Article 50 attaches transparency duties per interacting or generating system. Every one of those is a per-system determination — and the register is where per-system determinations live.

  • ISO/IEC 42001 makes the AI system inventory an explicit element of an AI management system.
  • The NIST AI RMF's Map function starts by establishing context per system — an inventory by another name.
  • The Colorado AI Act and similar US state laws require deployers to know which of their systems make consequential decisions.
  • Enterprise procurement questionnaires increasingly open with: "list the AI systems in your product and their risk classifications."

The first question test

Whether the person asking is a regulator, an enterprise customer's counsel, or your own board, the first question is always some form of "what AI do you operate?" An organization that cannot answer from a maintained record fails the meeting in the first five minutes, whatever the true state of its governance.

What belongs in each entry

A useful register entry answers the questions a reviewer will actually ask. The fields in Attevera's free template are a workable baseline:

  • Identity and purpose: system name and a one-sentence statement of what it does, for whom. Intended purpose is what classification hangs on.
  • Role under the AI Act: provider, deployer, or both — per system, with the reasoning.
  • Vendor and model: who builds it and what it runs on, so upstream changes are traceable.
  • Data inputs and data subjects: what goes in, and whose data it is — including whether people in the EU are affected.
  • Risk tier and Annex III alignment: the classification and the specific Annex III area (or the documented conclusion that none applies).
  • Article 50 transparency duties: whether the system interacts with people or generates content, and what disclosure applies.
  • Control owner: a named person, not a mailbox.
  • Evidence location, last material change, and next review date: where the proof lives and when someone last confirmed the entry still reflects reality.

From spreadsheet to operating record

Most registers start as a spreadsheet, and a spreadsheet is a legitimate start — the free template linked below is exactly that. The limits show up at the next step: a spreadsheet does not flag evidence going stale, does not map entries to the specific articles that apply, does not assign and chase control owners, and does not produce an audit trail showing the record was maintained over time rather than assembled the week before a review.

The register earns its keep when it stops being a list and starts being the operating record the rest of the program hangs off: obligations mapped per entry, owners assigned, evidence attached with review dates, and a monthly rhythm that keeps it honest as systems, vendors, and uses change.

Start with the free AI system register template

A fillable register template with the 14 fields above and a realistic completed example — yours regardless of whether you ever use Attevera.

Get the free template

Frequently asked questions

Is an AI register legally required under the EU AI Act?

There is no single article commanding every organization to keep one. But the Act's per-system duties — classification under Article 6, deployer obligations under Article 26, transparency under Article 50 — presuppose you know your systems, and Article 49 separately requires registering high-risk Annex III systems in the EU's public database. In practice a register is the only credible way to evidence the rest. This is informational guidance, not legal advice.

What counts as an AI system for the register?

The Act's Article 3(1) definition is broad: a machine-based system that infers from inputs how to generate outputs like predictions, content, recommendations, or decisions. Practically: include vendor AI features your teams use, AI features in your own product, and internal models — and record borderline cases with a note rather than silently excluding them.

How is an AI register different from a RoPA under GDPR?

A record of processing activities inventories personal-data processing; an AI register inventories AI systems and their AI-Act-specific attributes — role, risk class, oversight, transparency duties. They overlap on data fields and should cross-reference each other, but neither substitutes for the other.

How often should the register be reviewed?

Monthly is the cadence that keeps a register honest in a living product organization — new systems appear, vendors ship new features, uses drift. Each entry should carry a next-review date and an owner accountable for it, so staleness is visible instead of silent.

Keep reading