The Register That Stays Useful: A UK Operating Model for AI Inventories

Many UK organisations begin their AI governance work by adding an AI tab to the record of processing activities. The first version looks promising. It lists tools, owners and purposes. Six months later it is incomplete, contested and ignored. The problem is not the spreadsheet. It is the operating model around it.

A ROPA has a legal purpose: it records processing activities under UK GDPR. An AI inventory has a wider management purpose. It should help an organisation find AI use cases, assess risk, trigger DPIAs, link vendors and contracts, and report to the board. If the inventory is treated as a compliance annex, it will decay. If it is designed as a maintained service, it can become a practical control.

Why the bolt-on register fails

Bolt-on registers fail in predictable ways. Ownership is unclear, so updates depend on goodwill. The taxonomy is too narrow, so teams do not recognise their tools as AI. Intake is informal, so procurement and security learn about use cases late. The register has no decision linkage, so it cannot trigger a DPIA or a contract review. And there is no reconciliation, so shadow AI accumulates between annual reviews.

A register also fails when it asks for too much. Long forms discourage disclosure. A minimum viable record, linked to existing systems, is more sustainable than a perfect taxonomy that nobody completes.

Design principles for a maintainable inventory

Start with one front door. Whether a team is buying a tool, building a model or enabling an embedded feature, the same intake route should apply. Keep the minimum fields small: use case, business owner, purpose, personal data, UK individuals, vendor or model, data sources, deployment status and risk tier. Link to existing records rather than duplicating them.

Evidence should take priority over description. A register entry that says 'low risk' is weak. An entry linked to a DPIA screening, a vendor assessment, a data flow and a contract clause is stronger. Design for change: models are updated, vendors change terms and use cases expand. The inventory needs event-driven review, not only an annual cycle.

The operating model

Scope and taxonomy

Define AI broadly enough to capture embedded and generative features, but precisely enough to be usable. Include tools that infer, recommend, rank, generate content, automate decisions or process personal data through a model. Distinguish between vendor products, internal builds and features switched on inside existing platforms.

Intake and triage

Route procurement, IT and business requests through a short triage. Ask whether personal data is involved, whether UK individuals are affected, whether the use case could produce significant effects, whether a new vendor or model is involved and whether the model or purpose is changing. The output should be a risk tier and a DPIA trigger decision, not a completed register entry alone.

Data lineage and DPIA linkage

Link each use case to the data map. Record source systems, data categories, special category data, retention, training data and outputs. The DPIA screening should be a required field for higher-risk cases. If the inventory cannot show where data comes from and where it goes, it cannot support assurance.

Vendor and contract linkage

Record the contract identifier, processing terms, subprocessors, model improvement terms, audit or information rights and security assurances. AI-specific clauses matter, but so does the ability to find them when a model changes. Link the inventory to the contract management system rather than copying clauses into the register.

Evidence and assurance

Attach or link to vendor assessments, test results, human oversight arrangements, monitoring plans and incident records. The register should show what has been assured and when, not only what has been described. For high-risk use cases, record the residual risk acceptance and review date.

Reporting and roles

Give the inventory a named owner and a small governance forum. The DPO, procurement, security, legal and business owners each have a role, but accountability should sit with a designated AI governance lead or data governance function. Board reporting should use a small set of metrics: number of use cases, high-risk cases, overdue DPIAs, vendor issues, reconciliations completed and shadow AI discovered.

Cadence and maintenance

Maintenance should be routine. Review new intake monthly, reconcile the register with procurement and cloud spend quarterly, align with the ROPA annually and update on events such as a model change, vendor notice, incident or new regulation. A register is a service, not a project. It needs a service owner, a backlog and a review rhythm.

Maturity checklist for UK governance teams

Use the checklist to score each dimension, not just the register as a whole.

• Scope: Level 1 is ad hoc tools; Level 2 covers known vendors; Level 3 includes embedded AI and internal builds; Level 4 uses discovery and procurement data to find shadow AI.
• Ownership: Level 1 has no owner; Level 2 has a coordinator; Level 3 has a named accountable owner and RACI; Level 4 has performance measures for the service.
• Intake: Level 1 is email-based; Level 2 has a form; Level 3 is embedded in procurement and IT change; Level 4 triggers automated triage and DPIA screening.
• Lineage: Level 1 lists purposes; Level 2 lists data categories; Level 3 links to source systems and retention; Level 4 maintains lineage through model and vendor changes.
• DPIA linkage: Level 1 is separate; Level 2 has a field; Level 3 triggers screening and tracks mitigations; Level 4 reports overdue and residual risk to the board.
• Contracts: Level 1 holds documents; Level 2 records contract IDs; Level 3 links AI clauses and subprocessors; Level 4 monitors change notices and revalidation.
• Reporting: Level 1 has no reporting; Level 2 provides an annual list; Level 3 reports quarterly metrics; Level 4 uses metrics to drive decisions and remediation.

A useful target for most organisations in 2026 is Level 3: linked, owned and reviewed. Level 4 should follow only where the risk and scale justify the investment.

A 90-day start

In the first 30 days, appoint an owner, agree the scope and publish a minimum data set. In days 30 to 60, run a reconciliation against procurement, cloud and IT asset records, and link the highest-risk use cases to DPIAs and contracts. In days 60 to 90, establish quarterly reporting and a monthly intake review. Do not wait for a perfect taxonomy. A maintained register with visible gaps is more useful than a polished register nobody trusts.

The inventory will only remain useful if it is part of how the organisation makes decisions. That means linking it to procurement, DPIAs, contracts and board reporting, and giving someone the authority to keep it current. An AI register is not a record of good intentions. It is an operating control.