AI Assurance Evidence Registers for UK Businesses

AI Trust & Governance

5 July 2026 | By Ashley Marshall

AI governance is no longer a policy exercise. UK businesses need a live evidence register that proves what has been assessed, accepted and reviewed.

Why assurance evidence registers are becoming the missing layer

Most UK businesses adopting AI governance are now discovering the same uncomfortable gap. They can name the policy, the risk owner, the vendor and the intended use case, but they cannot quickly show the evidence that proves those controls are alive. That is where an AI assurance evidence register earns its place. It is not a new standard, a new committee or another compliance theatre document. It is the practical operating record that connects AI systems, decisions, risks, supplier claims, testing results and review dates in one place.

DSIT's AI Management Essentials consultation is a useful signal. The proposed AIME tool asked organisations to maintain a complete and up-to-date record of AI systems, document impact and risk assessments, keep data records, request supplier documentation, review records at least annually and investigate reported concerns. Those requirements sound straightforward until a board, customer or procurement team asks, "show me". A policy says what should happen. An evidence register shows what has happened, who accepted it, when it will be reviewed and what is still missing.

The timing matters. DSIT says the UK AI assurance market is set to grow six-fold by 2035, unlocking more than GBP6.5 billion. That growth will not only come from specialist auditors and tool vendors. It will come from routine buyer expectations. A finance director, public sector framework, insurer or enterprise customer will increasingly want a defensible trail for AI use. For a mid-sized company, the register becomes the place where that trail is maintained before anyone asks for it.

What this means in practice is simple. If your organisation uses Microsoft Copilot, ChatGPT Enterprise, an AI-enabled CRM, an underwriting model, a recruitment screening tool or a customer service chatbot, the evidence register should answer four questions quickly: what is the system, what risk does it create, what control evidence exists, and who is accountable for keeping it current. Without that, AI governance remains scattered across Slack threads, procurement folders, DPIAs, supplier PDFs and risk committee minutes.

How it maps to ISO/IEC 42001 without copying the standard into a spreadsheet

ISO/IEC 42001 matters because it gives organisations a management system lens for AI. The AI Standards Hub lists ISO/IEC 42001:2023 and BS ISO/IEC 42001:2023 as the published artificial intelligence management system standard, with BSI and ISO as the standards bodies and ART/1 as the relevant UK committee. The point is not that every UK company needs certification tomorrow. The point is that serious AI governance is moving from informal principles to repeatable management systems.

An evidence register should not try to reproduce ISO/IEC 42001 clause by clause. That is usually how registers become unmaintainable. Instead, it should map evidence to the management system questions leaders actually need to answer. Do we know which AI systems we use? Have we assessed their impacts? Do we understand data quality and provenance? Have we defined human oversight and escalation? Have we reviewed supplier evidence? Are incidents and concerns recorded? Are controls reviewed when the model, workflow or vendor changes?

A practical register normally needs fields for system name, business owner, system purpose, supplier or internal developer, user group, affected parties, data categories, risk rating, applicable controls, evidence links, evidence owner, review frequency, last review date, open actions, residual risk decision and approval record. That sounds administrative, but it is the minimum scaffolding that turns a one-off AI assessment into a repeatable management process. It also helps avoid the common failure where every AI project creates its own bespoke checklist and nobody can compare risks across the estate.

The important design choice is to keep the register evidence-led rather than opinion-led. "Low risk" is not enough. The register should point to the evidence behind that rating: a DPIA, supplier security pack, model card, bias test, user impact assessment, prompt logging policy, red-team report, procurement note, incident response playbook or board decision. When evidence is missing, the register should say so plainly and record the interim decision. ISO-style maturity comes from consistent decision records, not from pretending every control is already perfect.

AIME shows the evidence categories UK firms should start with

The draft AIME tool is especially useful because it translates AI governance into business-readable evidence categories. Its accessible self-assessment asks whether organisations maintain an AI system record, have an AI policy, define fairness, document impact assessments, conduct risk assessments, manage data quality and provenance, mitigate bias, apply data protection by design, record issue reporting and communicate technical or non-technical documentation to interested parties. That is effectively a starter taxonomy for an evidence register.

Several of those categories deserve priority. The first is the AI system record. DSIT describes it as an inventory of documentation, assets and resources related to AI systems, including technical documentation, impact and risk assessments, model analyses and data records. For businesses, this should become the top layer of the register. It tells you which systems exist and which evidence packs belong to each one. The second priority is supplier evidence. AIME asks whether organisations procuring third-party AI request and receive documentation, assets and resources from providers. That matters because many UK firms are adopting AI through SaaS vendors rather than building models internally.

The third priority is issue reporting. AIME asks whether employees, users and external third parties can report concerns or failures, whether anonymity or confidentiality is available, whether an owner is identified, and whether concerns and investigations are documented. That belongs in the same evidence register because assurance is not only pre-deployment. A system that looked acceptable at launch can become risky after a prompt change, data drift, vendor update or new user behaviour.

What this means in practice is that a company should start with a single register and four evidence folders: system record, risk and impact, supplier and data, and monitoring and issues. Each AI system gets one row and each evidence category has a status: complete, partial, missing, not applicable or under review. This is far more useful than asking every team to "do AI governance" in the abstract. It gives compliance, technology, procurement and operations the same live map.

The data protection evidence cannot sit somewhere else

AI assurance cannot be separated from data protection when personal data is involved. The ICO's artificial intelligence guidance page points organisations to detailed AI and data protection guidance, practical advice on explaining AI-assisted decisions, biometric data guidance, the AI and data protection risk toolkit and the data analytics toolkit. That is a clear message for UK businesses: AI assurance evidence has to include privacy, fairness, explainability and individual rights, not just model performance.

The evidence register should therefore link directly to DPIAs, lawful basis assessments, legitimate interests assessments where relevant, data minimisation decisions, retention decisions, access controls, breach records, explanation materials, human review procedures and records of how individuals can challenge or query AI-assisted decisions. If the AI system processes special category data, biometric data or employment data, the register should flag that clearly. If the supplier claims not to use customer data for training, the register should link to the contract term or data processing addendum that says so.

This is where many AI projects fail quietly. The technical team may have evaluated accuracy. Procurement may have reviewed a data processing agreement. Legal may have checked a DPIA. Operations may have written user instructions. But when those artefacts live in separate systems, the organisation cannot easily prove that the whole control set exists for a specific AI use case. A register brings those fragments together without forcing every team into the same software platform.

The practical test is whether a senior owner can open the register and answer: whose data is used, for what purpose, with which supplier, under which contract, with what explanation to affected people, and with what monitoring after deployment. If the answer requires three meetings and a forensic search of email, the business does not yet have AI assurance evidence. It has scattered governance activity. That may be better than nothing, but it will not survive serious customer, regulator or board scrutiny.

The SME objection is fair, but the answer is proportionality

The strongest counterargument is not that evidence registers are useless. It is that they can become burdensome, especially for SMEs. DSIT's AIME government response records exactly that concern. Respondents supported the aims of AIME, but raised issues around technical language, one-size-fits-all approaches, third-party AI systems, specialist knowledge and the risk that procurement use could add disproportionate burden for smaller firms. DSIT ultimately said it would not publish AIME or make it a government procurement requirement, and would instead focus future guidance on foundational governance measures for SMEs.

That is a sensible warning. A 40-person services firm using AI-enabled office software should not be expected to run the same assurance machinery as a bank building credit decisioning models. But proportionality is not the same as absence. The smaller firm still needs to know what AI it uses, whether personal or confidential data is involved, what the supplier promises, which staff can use it, which tasks are prohibited, and how incidents or concerns are escalated. A lightweight register is often the least burdensome way to achieve that because it prevents repeated rediscovery.

There is also a commercial angle. Larger customers increasingly ask AI questions during due diligence: do you use AI in service delivery, do you train models on client data, what controls exist, do you have human oversight, can you evidence supplier terms, and what happens if the system produces a harmful output? A business that can answer from a maintained register looks more mature than one that improvises from memory.

The right starting point is a risk-tiered register. Low-risk internal productivity tools might need a short evidence pack: approved use policy, supplier terms, data handling rules and annual review. Customer-facing or employee-impacting systems need more: impact assessment, DPIA, testing, monitoring, escalation, training records and named senior approval. High-impact systems need deeper technical evaluation and independent assurance. That tiering keeps the register useful instead of turning it into a compliance tax.

How to build the register in the first thirty days

The best first version is deliberately plain. Use a spreadsheet, Airtable, Notion, SharePoint List, ServiceNow GRC, Jira, Archer or whichever governance platform your business already maintains. Do not buy a specialist tool until you know the workflow. The first thirty days should produce visibility, not elegance. Start by listing every AI system the organisation develops, buys or uses in a business process. Include obvious tools such as Microsoft Copilot and ChatGPT Enterprise, but also AI features embedded in CRM, HR, finance, security, customer service and analytics platforms.

Next, create a standard row template. At minimum, record the system purpose, owner, supplier, users, affected parties, data categories, risk tier, business process, approval status, evidence links, outstanding gaps, review date and escalation route. Then add control evidence categories aligned to AIME and ISO/IEC 42001 thinking: policy, system record, impact assessment, risk assessment, data protection, fairness and bias, supplier due diligence, user guidance, monitoring, incident reporting and communication to affected parties.

For each system, apply a simple status. Green means evidence exists and has been reviewed. Amber means evidence is partial or out of date. Red means evidence is missing for a material control. Grey means not applicable, with a reason. This immediately creates a governance backlog that leaders can prioritise. It also stops the familiar argument where teams debate abstract AI risk without knowing which evidence is actually absent.

Finally, make ownership explicit. Every evidence item needs an owner, review date and decision record. A register with no owner becomes stale. A register with no review date becomes a snapshot. A register with no decision record becomes a folder of documents rather than assurance evidence. After thirty days, the board or senior leadership team should be able to see which AI systems are in use, which controls are proven, which gaps matter most, and which decisions require their risk appetite. That is the moment AI governance becomes operational.

Frequently Asked Questions

What is an AI assurance evidence register?

It is a maintained record that links each AI system to the evidence showing how it is governed, assessed, monitored and reviewed. It usually includes system ownership, risk ratings, supplier evidence, DPIAs, testing records, incident logs, policy approvals and open actions.

Is an evidence register required by ISO/IEC 42001?

ISO/IEC 42001 is a management system standard, so organisations need controlled information and evidence that processes are operating. A register is a practical way to organise that evidence, even if the standard does not prescribe one spreadsheet format.

How does this relate to the UK AI Management Essentials tool?

The AIME self-assessment asked organisations to maintain AI system records, document risks and impacts, manage data, review supplier evidence and record reported concerns. An evidence register turns those questions into a live operational record.

Should SMEs build the same register as large enterprises?

No. SMEs should use a proportionate version. Low-risk internal tools may only need basic supplier, policy and data handling evidence. Higher-impact systems need deeper assessment, monitoring and approval records.

Who should own the AI evidence register?

Ownership usually sits with a senior accountable function such as risk, compliance, information governance, security or operations. Individual evidence items still need business owners, technical owners and supplier owners.

What evidence should be collected for third-party AI tools?

Collect supplier security information, data processing terms, model or system documentation, training data statements where available, bias or safety testing summaries, usage restrictions, audit rights, incident notification terms and exit provisions.

How often should the register be reviewed?

Review frequency should follow risk. Low-risk systems may be reviewed annually. Customer-facing, personal-data-heavy or decision-support systems should be reviewed more often, and always after a major vendor, data, model or process change.

Can this be managed in a spreadsheet?

Yes, for the first version. A well-owned spreadsheet with links to evidence is often better than an expensive tool nobody uses. Move to a GRC platform when workflow, permissions and reporting needs justify it.