AI Register and Inventory: A Practical Example

Register and inventory: what is the difference?

Organisations use AI inventory, AI system register and AI register rather flexibly. The inventory gives a structured view of systems used, developed or provided; the register can describe the maintained record for each system and its evolution. Both functions may sit in one tool.

This article focuses on operational use. Our general AI inventory guide explains the concept and its place within AI governance.

What an AI inventory is actually for

Its value is not counting tools, but connecting system → owner → purpose → risk → classification → control → evidence → review.

It can identify systems, assign accountability, reveal unauthorised AI, review suppliers, prioritise assessments, manage risk, flag impact assessments, support audits and preserve traceability. It is an entry point within the AI governance framework, not an end in itself.

What it should include at minimum

There is no universal field list. A practical starting point includes:

• identifier and system name
• intended purpose and process
• owner and supplier
• users and affected persons
• data categories
• risk and classification
• lifecycle status
• onboarding, last review and next review dates.

Add detail in proportion to complexity. Avoid both a register too poor to support decisions and one so large that nobody maintains it.

Basic identification fields

Internal ID

References such as AI-001 support links to risk, controls and evidence.

System name

“Candidate screening assistant” is more informative than a supplier’s product name alone.

Version

This matters when models, configurations or functions change.

Onboarding date

This records when the system entered the inventory. Its stable identifier should remain even as attributes change.

Purpose, process and users

“Chatbot” is not a sufficient purpose; “answer customers’ frequently asked product and service questions” is.

Record the business process and who uses the system: employees, customers, candidates, suppliers or the public. Intended purpose provides essential context for risk and classification.

Owner and accountability

Every material system needs an identifiable owner accountable for business use, even if somebody else developed it.

Recruitment AI may belong to HR, content generation to Marketing and fraud detection to Finance or Risk. Other roles can include technical, risk, data and oversight owners.

The essential question is who must act if something changes or fails? A clear model of roles and responsibilities supports this.

Supplier and third-party dependency

Record supplier, product, service, integration, relevant sub-suppliers, contract, renewal date and the internal relationship owner.

A significant supplier change may require fresh review of classification, risk, data, controls, documentation and contract terms.

Data and affected persons

Useful data categories include internal information, customer data, personal data, candidate data, financial data, public information and confidential documents.

Distinguish users from affected persons. HR may operate a tool affecting candidates; an employee may use a system affecting customers. This distinction can change the assessment required.

Risk, impact and classification

A low, medium or high risk label does not replace AI risk management; it should link to the underlying assessment.

AI Act classification is separate. A record may state pending, prohibited practice, high-risk, not high-risk, transparency requirement or outside the assessed scope, supported where necessary by a documented classification.

The register may also link to an impact assessment, privacy, security or legal review. It indexes evidence rather than replacing those analyses.

System status and lifecycle

Useful states include proposed, assessment, pilot, approved, operational, suspended, under review and retired.

Proposed systems may require assessment before approval; retired systems may require evidence retention. The inventory follows the entire lifecycle.

Practical AI inventory example

Consider an organisation using five systems:

Each row can link to risk, classification, impact, controls, supplier information, evidence and decisions. The inventory provides the overview, not every underlying record.

How to keep the inventory up to date

Updates may be triggered by a new system or pilot, a supplier, purpose, model, data, autonomy or affected-population change, an incident or retirement.

Periodic review is useful—perhaps annually for low-risk systems and more often for material ones—but significant changes should also trigger exceptional reviews.

How to connect the inventory with controls and evidence

Each record can link to risk, impact, classification, supplier, controls, evidence, approval, incidents and audit.

For example: AI-001 → RISK-014 → CTRL-021 → EVID-087.

The naming convention is optional. The important point is being able to reconstruct which system created a risk, which control was chosen and which evidence demonstrates operation.

Internal AI inventory and AI Act registration are not the same

An internal inventory is a governance tool. The AI Act creates specific EU database registration obligations for certain systems and operators.

Not every organisation using AI must register every tool in the EU database. The legal obligation depends on the applicable circumstances. Article 49 addresses registration for certain systems and operators, particularly those connected to Annex III, while Article 71 establishes the database.

Therefore: internal inventory ≠ automatic regulatory registration.

A well-designed inventory can support compliance where a formal obligation applies. Our AI Act obligations guide provides context, while an AI use policy can integrate registration into real processes.

Common mistakes

Recording only tools known to Technology

Business teams often introduce AI directly.

Using only the supplier name

Classification depends on use, not merely the product.

Failing to assign an owner

Systems without owners are rarely reviewed.

Creating too many fields

A register nobody maintains quickly loses value.

Excluding pilots

Risk may arise before production.

Confusing users and affected persons

The operator is not always the person experiencing the outcome.

Removing retired systems entirely

Traceability may require preserving their history.

Failing to link evidence

Value appears when each record leads to risks, controls and decisions.

Treating the inventory as finished

It is a living process, not a snapshot.

A good inventory turns awareness into governance

Knowing that an organisation uses fifteen AI tools says little. Value emerges when it can explain each system’s purpose, owner, data, affected people, risk, classification, controls, evidence and review date.

At that point, the inventory stops being a list and becomes a central governance tool.

References

• ISO/IEC 42001:2023 — Artificial intelligence management system.
• ISO/IEC 23894:2023 — Guidance on AI-related risk management.
• Regulation (EU) 2024/1689 — AI Act.
• Article 49 — Registration.
• Article 71 — EU database for certain AI systems.