AI System Register Template: The Step-One Artifact for EU AI Act Compliance

Template3 June 2026· 16 min read

Copy-paste AI system register template: 10 columns plus field-by-field guidance, the backbone of Article 11 and Article 12. High-risk deadline 2 December 2027.

An AI system register is the foundational, step-one artifact of EU AI Act compliance under Regulation (EU) 2024/1689: a structured record with one row per AI system, capturing what each system does, who owns it, how it is classified, and where it stands on conformity. It is the operational layer that makes the statutory obligations tractable — and the first document a competent authority asks to see.

Regulation (EU) 2024/1689 does not prescribe a single statutory register form. But Article 11 requires high-risk providers to draw up technical documentation following Annex IV, and Article 12 requires high-risk systems to keep automatic logs over their lifetime. You cannot meet either obligation across an estate of systems you have not enumerated. The register is how you enumerate, classify, and govern them.

This page gives you a clean, copy-paste ten-column template, field-by-field guidance keyed to the governing Articles, a worked example, and the penalty and deadline picture as it stands in June 2026.

What an AI System Register Is — and Why It Comes First

The precise term: register, not warehouse-style inventory

Use the word register deliberately. A register is a disciplined, one-row-per-system control record — narrower and more standardised than a broad, warehouse-style AI inventory that sweeps up every tool, integration, and instance of shadow AI. The inventory is the discovery exercise; the register is the governed artifact it produces. The inventory finds; the register governs.

Each row corresponds to one AI system as defined in Article 3(1) — a machine-based system that infers, from the inputs it receives, outputs such as predictions, recommendations, decisions, or content. If a tool meets that definition, it earns a row. If it does not, it stays in the broader inventory as context but does not clutter the governed register.

Why it is step one

The register comes first because every downstream obligation presupposes it. Article 6 risk classification, the Article 9 risk management system, Article 11 technical documentation, Article 12 record-keeping, and Article 49 EU-database registration all assume you already know which AI systems you operate and how each is classified. You cannot scope obligations you have not enumerated.

The register is not itself a statutory form — but it is the operational backbone that makes the statute workable, and the first thing a market-surveillance authority requests under its supervision and access powers (Articles 74–77). The practical sequence is: build an AI inventory as the discovery sweep, then distil the governed register from it.

The Backbone of Article 11 Documentation and Article 12 Record-Keeping

The register is the spine that the rest of your high-risk evidence base hangs from. Two obligations sit directly on top of it.

Technical documentation — Article 11

Article 11 requires providers of high-risk AI systems to draw up technical documentation following Annex IV before the system is placed on the market, and to keep it current. The register supplies the spine of that file: system identity, intended purpose, role, classification, and conformity status all map straight into Annex IV sections. Keep the register and the Article 11 technical documentation file in the same source of truth so they cannot drift apart between audits.

Record-keeping — Article 12

Article 12 requires high-risk AI systems to technically allow for the automatic recording of events — logs — over the system's lifetime. The register is where you document that logging is enabled, where logs are stored, and the retention regime. It is the index to your Article 12 record-keeping evidence, not the logs themselves.

Living document, not a snapshot

The register is a living document. It must be re-reviewed on a substantial modification (Article 3(23) — a change affecting the system's compliance with the requirements or altering its intended purpose), on a change of operating context, when the Annex III list is amended under Article 7, and after any serious incident reportable under Article 73. A Last review date field enforces that cadence.

Because Article 11 documentation must reflect the system as placed on the market, and Article 12 logs run for the system's lifetime, a stale register is itself a compliance gap. A system updated without a corresponding register and documentation revision is non-compliant — the gap is not the update, it is the silence in the record.

The AI System Register Template (Copy-Paste)

Here is the universal ten-column core. Paste it straight into a markdown doc, wiki, or spreadsheet and start populating one row per system.

| System name | Owner | Intended purpose (Art 3) | Provider/Deployer role | Risk tier (Art 6 / Annex III) | Personal-data categories | Third-party model / GPAI dependency | Deployment status | Conformity status | Last review date |
| ----------- | ----- | ------------------------ | ---------------------- | ----------------------------- | ------------------------ | ----------------------------------- | ----------------- | ----------------- | ---------------- |
|             |       |                          |                        |                               |                          |                                     |                   |                   |                  |

Keep the core register to these ten columns. Organisations with high-risk systems will extend it with a handful of high-risk-specific fields — Annex III sub-point, Article 6(3) exemption claimed, FRIA status (Article 27), and Article 49 registration date — but the ten-column core is the universal starting point for every estate.

Two rules govern how rows behave:

One row per distinct system at one version string. A substantially modified release generates a new linked row rather than overwriting the old one, so the change history survives.
The empty template is useless without governance. The value is in the field discipline below, not the columns themselves. A register nobody owns and nobody reviews is a spreadsheet, not a control.

Field-by-Field Guidance

Each column carries an Article reference because each column is doing regulatory work. Fill them with that work in mind.

Identity and ownership

System name. The internal name plus any commercial or product name. One row per distinct system, versioned where a release materially changes functionality.
Owner. A named, accountable individual — not a team. This is the person responsible for the row's accuracy and for triggering reviews, and the person an auditor escalates to. "The data team" is not an owner; "Head of People Ops" is.

Purpose, role, and risk tier

Intended purpose (Art 3). A precise statement of what the system does, the decision type (ranking, prediction, classification, generation), and the affected population. This language feeds directly into Article 11 / Annex IV and drives the Article 6 classification, so write it as if a regulator will read it — because one might.
Provider/Deployer role. Select the role under the Act: Provider (Article 16), Deployer (Article 26), Importer (Article 23), or Distributor (Article 24). Under Article 25, branding a third-party system as your own, substantially modifying it, or changing its intended purpose makes you the provider. Most companies using third-party tools are deployers; SaaS vendors shipping AI features are providers.
Risk tier (Art 6 / Annex III). One of Prohibited (Article 5), High-risk (Article 6 with Annex III or Annex I), Limited risk (Article 50 transparency), or Minimal. For high-risk via Article 6(2), record the specific Annex III point — for example Annex III point 5(b) for credit scoring, not the vague "Category 5". Precision here is what makes the risk classification defensible.

Data, dependencies, and status fields

Personal-data categories. The categories processed — name, biometric, health, location, behavioural. This is the cross-reference to your GDPR Article 30 record and the trigger for whether a DPIA (GDPR Article 35) or a FRIA (Article 27) is needed.
Third-party model / GPAI dependency. Name the underlying model and provider where the system is built on a general-purpose AI model. Record whether Annex XII downstream documentation has been received from the GPAI provider under Article 53.
Deployment status. Development / Pilot / Production / Retired. High-risk systems in development must already be tracked, because Article 11 documentation has to be ready before market placement, not bolted on after.
Conformity status. Not started / In progress / Complete / Lapsed. The Article 43 conformity assessment must be complete before a high-risk system is placed on the market — the Annex VI self-assessment route for most Annex III points, the Annex VII notified-body route for Annex III point 1 biometrics.
Last review date. The date the row was last verified, with the next review scheduled. A passed review date with no update is a documented compliance gap — worse than no date at all, because it proves you knew.

Worked Example: A Completed Register Row

A template is abstract until you populate it. Here is one fully completed high-risk row for a CV-screening tool:

| System name      | Owner             | Intended purpose (Art 3)                              | Provider/Deployer role | Risk tier (Art 6 / Annex III) | Personal-data categories                       | Third-party model / GPAI dependency | Deployment status | Conformity status                       | Last review date |
| ---------------- | ----------------- | ----------------------------------------------------- | ---------------------- | ----------------------------- | ---------------------------------------------- | ----------------------------------- | ----------------- | --------------------------------------- | ---------------- |
| TalentRank v2.1  | Head of People Ops| Ranks job applicants for shortlisting in recruitment  | Deployer (Art 26)      | High-risk — Annex III point 4(a) | name, employment history, inferred suitability | none / in-house gradient-boosted model | Production        | Provider self-assessment complete (Annex VI) | 2026-05-15       |

Reading a populated entry

That single row simultaneously answers four questions:

The Article 6 classification. Recruitment ranking falls under Annex III point 4(a), so the tier is high-risk — the classification is settled and recorded.
The Article 11 documentation scope. The intended-purpose text and role tell you exactly which Annex IV file must exist.
An Article 27 FRIA flag. A FRIA is not automatic for recruitment, but a system that profiles natural persons never qualifies for the Article 6(3) narrow-task exemption — so the exemption cannot be claimed away, and the FRIA question must be assessed, not assumed.
The Article 12 logging requirement. A high-risk Production system must have automatic logging enabled and indexed.

Why the classification rationale matters

Contrast that with a low-stakes row. An internal drafting assistant lands at Minimal — but it still earns a row, because a classification is a conclusion you document, not an assumption you make. The register row records the classification rationale and the date it was reached. That rationale is the artifact you hand a competent authority if your tier is ever challenged; without it, you are arguing from memory.

Penalties and the High-Risk Deadline (As of June 2026)

An inaccurate or out-of-date register is not a cosmetic problem. It engages real penalty exposure and undermines the evidence base behind the larger high-risk obligations.

The three penalty tiers — Article 99

Tier	Maximum fine	What it covers
Article 99(3)	EUR 35 million or 7% of total worldwide annual turnover	Article 5 prohibited-practice breaches
Article 99(4)	EUR 15 million or 3% of total worldwide annual turnover	Non-compliance with most other obligations — including the high-risk requirements your register supports
Article 99(5)	EUR 7.5 million or 1% of total worldwide annual turnover	Supplying incorrect, incomplete, or misleading information to notified bodies or competent authorities

The lowest tier is 1%, never 1.5%. And under Article 99(6), fines for SMEs and start-ups are capped proportionally at the lower of the percentage or the fixed amount — so smaller companies should not assume the headline figures apply unchanged.

Where the register bites: a register that is inaccurate or out of date is precisely the kind of incorrect or incomplete information that engages the Article 99(5) tier when shared with an authority — and it undermines the Article 11/12 evidence base behind the larger Article 99(4) exposure.

The Digital Omnibus caveat

The Digital Omnibus reached provisional political agreement on 6–7 May 2026, with the COREPER text confirmed around 13 May 2026. It agreed to defer the stand-alone high-risk Annex III obligations (Article 6(2)) from 2 August 2026 to 2 December 2027, and the Annex I product-embedded high-risk obligations (Article 6(1)) from 2 August 2027 to 2 August 2028.

The critical caveat: as of June 2026 this deferral is agreed but not yet law. It still requires a European Parliament plenary vote, formal Council adoption, and Official Journal publication. Until those happen, the statute still reads 2 August 2026 for high-risk Annex III obligations. Plan against the earlier date until the new one is actually in force.

Not everything moved. Article 5 prohibitions have applied since 2 February 2025; GPAI obligations under Articles 51–55 since 2 August 2025; and a new, fixed 2 December 2026 deadline was added (the CSAM / 'nudifier' ban plus content-marking under Article 50). These are fixed calendar dates — the 'stop the clock' proposal that would have tied the delay to harmonised-standards availability was rejected, so never describe the timeline as standards-contingent.

How the Register Underpins Audits and Article 49 Registration

The audit-readiness role

The register is the first document a market-surveillance authority requests. It demonstrates that you have enumerated, classified, and assigned ownership of every AI system before they probe any single one (supervision and access powers under Articles 74–77). An organisation that produces a clean register on request signals control; one that scrambles to assemble a list signals the opposite.

Feeding the Article 49 EU database

For high-risk systems, the register supplies the structured data submitted to the EU database under Article 49: providers must register before placing a high-risk system on the market, and providers claiming the Article 6(3) exemption must register too. The database itself is established under Article 71. The cleaner your register fields, the less rework the Article 49 submission costs.

Version control and change logs

Every row needs an immutable change log — who changed which field, when, and why. That audit trail, not the current snapshot, is what proves a classification was made on a given date rather than backdated. Quarterly review is the practical minimum; high-risk systems in production warrant a monthly operational check of logs, oversight records, and incident status, all reflected in the Last review date field.

Finally, distributed, ownerless registers fail at audit. Appoint one accountable organisation-level owner — head of compliance, DPO, or AI governance lead — over the register as a whole, with individual system owners certifying their own rows each cycle.

How Confir Helps

Confir auto-builds and maintains your AI system register as you onboard systems. You answer plain-English scenarios about each system, and Confir's deterministic, rule-based engine derives the role (Provider Article 16 / Deployer Article 26 / Importer Article 23 / Distributor Article 24) and the risk tier (Prohibited / High / Limited / Minimal) in a few steps — not a 40-question legal questionnaire.

The classification applies the same logic every time: the same inputs always produce the same tier and the same cited rationale, with no model inference and no hallucination. That reproducibility is exactly what makes a register defensible to a competent authority.

One intake then populates everything downstream — the AI risk register under Article 9, the Article 11 / Annex IV technical documentation pack, the Article 12 logging index, and the Article 49 registration data — all kept in a single source so they cannot drift apart. Every field change is written to an immutable, timestamped audit log, so the living-document review cadence and change history the Act expects are maintained without consultants and without an implementation project. If you are starting from scratch, the AI inventory template is the discovery companion that feeds the register.

Frequently Asked Questions

What is an AI system register under the EU AI Act?

It is a structured internal record, one row per AI system, capturing each system's name, owner, intended purpose, provider or deployer role, risk tier, data, dependencies, and conformity status. Regulation (EU) 2024/1689 does not mandate a fixed form, but the register is the practical backbone of Article 11 technical documentation and Article 12 record-keeping.

Is an AI system register legally required?

There is no single statutory register form, but it is effectively mandatory. Providers must draw up Article 11 technical documentation and enable Article 12 logging before placing a high-risk system on the market, and demonstrate compliance to authorities under Articles 74-77. You cannot meet those obligations across multiple systems without a maintained register.

What is the difference between an AI inventory and an AI system register?

An AI inventory is the broad discovery sweep that surfaces every tool, integration, and instance of shadow AI. The AI system register is the governed, one-row-per-system control artifact distilled from it — the classified, owned, version-controlled record that feeds Article 11 documentation, Article 49 registration, and audits. The inventory finds; the register governs.

What columns should an AI system register have?

At minimum ten: system name, owner, intended purpose (Article 3), provider or deployer role, risk tier (Article 6 / Annex III), personal-data categories, third-party model or GPAI dependency, deployment status, conformity status, and last review date. Organisations with high-risk systems extend it with Annex III sub-point, FRIA status, and Article 49 registration date.

When is the EU AI Act high-risk deadline?

The Digital Omnibus agreed in May 2026 to defer stand-alone high-risk Annex III obligations to 2 December 2027, and product-embedded Annex I high-risk to 2 August 2028. As of June 2026 this is agreed but not yet law — pending a Parliament vote, Council adoption, and Official Journal publication — so the statute still reads 2 August 2026 for high-risk Annex III until then.

What are the penalties for non-compliance with the EU AI Act?

Three tiers under Article 99: up to EUR 35 million or 7% of worldwide turnover for prohibited practices (Article 99(3)); up to EUR 15 million or 3% for most other obligation breaches (Article 99(4)); and up to EUR 7.5 million or 1% for supplying incorrect or misleading information to authorities (Article 99(5)). SMEs and start-ups get a proportional cap under Article 99(6).

Can I keep my AI system register in a spreadsheet?

Yes, at the start, for a small estate with no high-risk systems. Spreadsheets fail at scale: they do not enforce classification logic, link to Article 11 documentation, or prove when an entry was made. A spreadsheet without timestamps cannot show a classification was not backdated, which matters once a competent authority reviews your records.

Last reviewed June 2026. Cites Regulation (EU) 2024/1689 (EU AI Act).

Manage your EU AI Act compliance in one place

Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 7-day free trial.

Start free trial →