The AI System Inventory Schema That Maps to the AI Act Risk Tiers

An AI inventory that lists model names, vendors and owners is an asset register. An AI inventory a regulator can use is a classification decision, written down one row at a time.

Most firms building towards the EU AI Act start the same way: a spreadsheet with a column for “system”, a column for “vendor” and a hopeful column headed “uses AI?”. It photographs well in a steering meeting. It also collapses the moment anyone with supervisory authority asks the first real question, which is never “what AI do you run” but “which tier does each of these sit in, and what is your role for it”. Regulation (EU) 2024/1689 does not care that you have a list. It cares that each entry can be classified, and that the classification is evidenced. The fix is not a bigger spreadsheet. It is a schema designed backwards from the obligations, so every record is born carrying the fields a supervisor will eventually demand.

The risk tier is the spine, not a column

The Act sorts systems by risk, and every downstream obligation hangs off that sort. There are four practical positions. Prohibited practices under Article 5 — social scoring, certain biometric categorisation, untargeted facial-image scraping — which you should be able to prove you do not operate. High-risk systems under Article 6, which arrive by two routes: the standalone use cases listed in Annex III (biometrics, critical infrastructure, education, employment, access to essential services including creditworthiness and insurance pricing, law enforcement, migration and border control, and the administration of justice), and systems embedded as a safety component of a product already regulated under Annex I. Then transparency-risk systems under Article 50, where the duty is to tell people they are dealing with a machine or with synthetic content. And minimal-risk systems, which carry no new obligations but still belong in the inventory so you can show you assessed them.

General-purpose AI models sit outside that ladder entirely, with their own obligations under Chapter V that have applied since 2 August 2025. If you fine-tune or host one, or build on top of a provider who does, that provenance belongs in the record too. A schema that treats risk tier as one optional column among many has already lost. It has to be a required, enumerated field that forces a decision on every entry, and for high-risk entries it has to force two more: which Annex III heading applies, and whether you are claiming the Article 6(3) exemption. That exemption lets you argue a listed system is not high-risk where it performs a narrow procedural task and poses no significant risk — but never where it profiles natural persons, and never without a documented assessment you keep and, in most cases, register.

The fields a supervisor will actually ask for

Below is an inventory-entry schema sized to those obligations rather than to what a database happens to make easy. It is deliberately strict: a required risk tier, a required role, an intended purpose captured as the provider stated it, and explicit slots for the evidence that Articles 11, 14 and 49 will later require. Treat it as the contract every AI system in the estate must satisfy before it reaches production.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://example.org/schemas/ai-system-inventory-entry.json",
  "title": "AI System Inventory Entry",
  "description": "One record per AI system, sized to the fields an AI Act supervisor asks for.",
  "type": "object",
  "required": ["system_id", "name", "our_role", "intended_purpose",
               "risk_tier", "lifecycle_status", "owner"],
  "additionalProperties": false,
  "properties": {
    "system_id":       { "type": "string",
      "description": "Stable internal identifier; never reused." },
    "name":            { "type": "string" },
    "our_role": {
      "description": "Our organisation's role for this system under Reg (EU) 2024/1689.",
      "type": "string",
      "enum": ["provider", "deployer", "importer",
               "distributor", "authorised_representative"] },
    "intended_purpose": {
      "type": "string",
      "description": "Purpose as the provider states it (Art 3). Deviating can change the tier." },
    "risk_tier": {
      "type": "string",
      "enum": ["prohibited", "high_risk", "transparency", "minimal", "gpai_model"],
      "description": "Art 5; Art 6 with Annex III or Annex I; Art 50; minimal; or a GPAI model (Ch V)." },
    "annex_iii_area": {
      "description": "Annex III heading (1-8) where high-risk by that route; null otherwise.",
      "type": ["integer", "null"], "minimum": 1, "maximum": 8 },
    "article_6_3_exemption": {
      "type": "boolean", "default": false,
      "description": "True only with a documented Art 6(3) assessment. Keep and register it." },
    "data_sources": {
      "type": "array", "items": { "type": "string" },
      "description": "Training, validation and input feeds — evidence for Annex IV." },
    "model_provenance": {
      "type": "object",
      "description": "Origin of the underlying model; matters when deploying someone else's GPAI.",
      "properties": {
        "supplier":     { "type": "string" },
        "model_name":   { "type": "string" },
        "version":      { "type": "string" },
        "gpai_upstream":{ "type": "boolean" } } },
    "human_oversight": {
      "type": "string",
      "description": "The oversight measure in operation (Art 14): who can intervene, and how." },
    "conformity_status": {
      "type": "string",
      "enum": ["not_started", "in_progress", "assessed", "declared", "registered"],
      "description": "Progress towards assessment, EU declaration and Art 49 registration." },
    "eu_database_id": {
      "type": ["string", "null"],
      "description": "Art 49 registration reference once entered in the EU database; null until then." },
    "lifecycle_status": {
      "type": "string",
      "enum": ["planned", "in_development", "in_production", "retired"] },
    "owner": {
      "type": "string",
      "description": "Named accountable individual, not a team mailbox." },
    "last_reviewed": {
      "type": "string", "format": "date",
      "description": "Date of last classification review; re-check on any material change of purpose." }
  }
}

Every field earns its place against a specific duty. Intended purpose is not description for its own sake — deviate from it and a limited-risk system can become high-risk, so the field is the trigger for re-classification. Data sources and model provenance are the seed of the Annex IV technical file; capture them at inventory time and you are part-way to generating that technical documentation from your pipeline rather than reconstructing it under deadline. Human oversight is a free-text description of the actual intervention in place, because the risk-management system Article 9 requires is judged on what operates, not on what a policy claims. And conformity status plus the database reference are there so the inventory can answer the Article 49 question directly: is this system registered, and if not, why not.

Role decides which obligations attach

The same physical system carries completely different duties depending on who you are to it. Build and place a high-risk system on the market under your own name and you are the provider, on the hook for the full conformity assessment, technical documentation, and registration before it goes live. Buy one and switch it on and you are the deployer, with the narrower but real set of obligations in Article 26 — operate it per instructions, assign competent human oversight, keep logs, and, if you are a public authority, register your use under Article 49. Fine-tune a high-risk system substantially, or put your name on someone else’s, and you can inherit provider obligations you did not expect.

This is why role is a required, enumerated field rather than a note. An inventory that records only “system: yes, AI: yes” cannot tell you where your obligations start. One that records role, tier and provenance can tell you, per system, exactly which chapter of the Act you are reading — and where a supplier’s GPAI model upstream shifts part of the burden onto them, which is precisely the seam supervisors probe.

Build for the dates, not the demo

The timeline has moved, and the movement is easy to misread as relief. Prohibited practices and AI-literacy duties have applied since 2 February 2025. GPAI-model obligations, the governance architecture and the penalty regime have applied since 2 August 2025. General application and the Article 50 transparency duties land on 2 August 2026 as planned. What shifted is the heavy tier: under the Digital Omnibus, given final political sign-off by the Council on 29 June 2026, the Annex III high-risk obligations move from 2 August 2026 to 2 December 2027, and the product-embedded high-risk systems in Annex I move to 2 August 2028. Confirm the exact wording against the Official Journal text as it is published, but the direction is settled: the classification rules did not change, only the clock did.

Sixteen months feels like room to wait. It is not. The inventory is the artefact everything else is built on — you cannot run a conformity assessment on a system you have not classified, and you cannot classify at scale from a spreadsheet that never held the right fields. Stand up the schema now, populate it while the estate is small enough to reason about, and December 2027 becomes an assessment exercise against records that already exist. Leave it, and the reprieve simply moves the day you discover your inventory cannot answer the first question a supervisor asks.