What documentation registers should an organisation keep?

What is the inventory register?

The inventory register is the master list of AI systems and uses, with one entry per system or use case, recording the identifier, version, intended purpose, users, affected people, actors and roles, model dependencies, deployment geography, and review owner and date. The inventory should be the starting point for every other register: classification, evidence, incident and change records should all reference the inventory identifier, so that they can be linked to the system they concern. The inventory should be reviewed regularly and when a new system is added, a system is retired, or a purpose changes, and earlier entries should be retained with their history, so that a retired system can still be traced. An inventory that lists only vendor names or subscriptions, without intended purpose and roles, cannot support the governance work that follows from it.

What decision and evidence registers are needed?

A decision register should record each classification, scope, role, and release decision, with the system identifier, the question decided, the provision considered, the evidence relied on, the conclusion, the reviewer, the date, and the review trigger. An evidence register, or evidence index, should link each requirement and obligation to the document, test result, or record that evidences it, with version, date and owner. The two registers should be linked, so that a decision can be followed to its evidence, and evidence can be followed back to the decision it supports. A decision without evidence, or evidence without a decision, leaves a gap in the chain that a reviewer will find. Both registers should be controlled, with version history, so that a change creates a new entry rather than overwriting the old one.

For the broader regulatory framework, see AI governance planning checklist.

What incident and change registers are needed?

An incident register should record each incident, near miss, complaint, and pattern, with the system identifier, date, description, triage, investigation, corrective action, and learning, linked to the log entries and the risk file. A change register should record each change, with the system identifier, version, description, assessment, testing, decision on conformity and notification, and communication to affected parties. The two registers should be linked, because an incident can trigger a change, and a change can cause an incident, and the history of both should be readable together. Both registers should have named owners, review cadences, and retention plans, and should be searchable by system, date, and severity, so that a pattern across systems or over time can be identified and addressed.

What supplier and transparency registers are needed?

A supplier register should record each supplier, model, and service dependency, with the contract, the information pack received, the gaps raised, the update and incident channels, and the review date. A transparency register should record each disclosure and marking decision, with the system or content, the paragraph considered, the notice or mark given, the testing carried out, and the review date. Both registers should be linked to the inventory, so that a supplier change or a transparency change can be traced to the systems it affects. A supplier register that lists only contract dates, without the information pack and gap log, cannot show whether the downstream information needed for a system assessment was received. A transparency register that lists only that Article 50 was considered, without the notice and test for each case, cannot show that any specific disclosure was given.

How should registers be controlled and kept current?

Registers should be held in a controlled system, with access controls, version history, and backup, and with a named owner for each register and a deputy or handover arrangement. Entries should be made at the time of the decision or event, not reconstructed months later, and should be reviewed on a cadence that matches the volume of activity. A periodic audit should sample entries, check that pointers resolve to current versions, and record the audit and any fixes. Registers should be retained for the period the organisation sets for governance records, taking into account the retention periods the Act sets for provider and deployer records. A register system that depends on one person, that is kept in personal files, or that is not backed up, will fail when that person leaves or when a record is needed urgently.

Continue with AI governance operating model.

What does this guide not decide?

This guide does not decide what register format a particular organisation must use, how long its records must be kept, or whether a specific register entry is sufficient. It does not design a register system or assess a record. Those questions depend on the organisation's systems, obligations, and existing record systems, together with the consolidated legal text for the retention periods that apply. An organisation should design its registers to fit its systems, link them by stable identifiers, test that entries can be traced to underlying files, and confirm the design with a competent authority or legal adviser where the record position is material to a release or incident decision.

Frequently asked questions

Continue through this AI Act cluster

• AI governance planning checklist
• AI governance operating model
• Evidence chains for high-risk requirements
• First steps for an AI system inventory
• Provider responsibilities
• AI literacy in practice