AI regulatory change logs are now a board level control

AI Trust & Governance

3 May 2026 | By Ashley Marshall

The AI compliance problem is not that the rules are unknowable. It is that the rules keep moving while your models, vendors and use cases keep moving too.

The control gap is between legal updates and operational reality

Most AI governance programmes begin with a sensible artefact: a policy, a risk assessment template, a procurement questionnaire or a register of AI tools. Those artefacts matter, but they are not enough when the regulatory environment keeps changing. The missing control is often the simplest one: a dated, owned and auditable record of what changed, why it matters and what the organisation did next.

This matters because AI obligations are no longer arriving as one neat piece of UK legislation. UK businesses are reading across the EU AI Act, ICO guidance, the Data (Use and Access) Act 2025, DRCF papers, sector regulator signals, cyber guidance and supplier terms. A company using Microsoft Copilot, OpenAI, Anthropic, Google Gemini, Workday, Salesforce Einstein or a specialist recruitment tool may face different duties depending on role, use case, geography, user notice, data type and contractual position. The same tool can be low risk in one workflow and materially higher risk in another.

The European Commission's AI Act page is a useful example. It says prohibited AI practices and AI literacy obligations applied from February 2025, GPAI obligations applied from August 2025, transparency rules apply from August 2026, and some high risk AI rules run to August 2027. For a UK business, the practical question is not simply whether the UK has copied the EU approach. It is whether the business sells into the EU, employs EU staff, processes EU personal data, buys EU supplier services or uses a model provider whose compliance changes affect downstream customers.

The EU AI Act lists logging of activity, documentation, human oversight, robustness, cyber security and accuracy among high risk obligations. Those are not abstract legal concepts. They are operating disciplines. A regulatory change log is how the organisation connects a new rule or guidance update to real controls: procurement clauses, model cards, DPIAs, training materials, release notes, incident processes and accountable owners.

The ICO is signalling more guidance, not less

The UK position is often described as light touch. That phrase is useful politically, but risky operationally. The ICO is not waiting for a single AI Act style statute before it supervises AI systems. Its data protection guidance already covers accountability, transparency, lawfulness, fairness, accuracy, data minimisation, security and individual rights. More importantly, the ICO has made clear that this guidance is under review because the Data (Use and Access) Act became law on 19 June 2025.

In its March 2026 AI and biometrics strategy update, the ICO said it is working on automated decision making and profiling guidance, with draft guidance for consultation due in the coming months. It also said that this draft guidance will inform parts of its AI and ADM code of practice, which the government committed to during the passage of the Data (Use and Access) Act 2025. That is a direct signal to boards and compliance teams: do not assume the guidance pack you used last year will be the guidance pack you need later this year.

The ICO's March 2026 update says ADM and profiling guidance is being prepared and will feed into an AI and ADM code of practice. That should change how businesses manage compliance evidence. A data protection impact assessment written in January may need to be revisited in July if the ICO clarifies expectations on profiling, human review or explanation. A recruitment tool approved by HR may need legal, data protection and procurement review if guidance lands on automated shortlisting.

What this means in practice is straightforward: every AI system record should have a regulatory change history, not just an original approval date. The log should capture the source of the change, the affected systems, the accountable owner, the decision taken, the evidence reviewed and the next review date. Without that record, the business cannot show that it noticed the change, interpreted it, assigned it and acted on it.

Suppliers are part of the regulatory surface

AI regulatory change is not only published by regulators. It also arrives inside supplier updates. A model provider changes retention settings. A SaaS platform adds generative summaries. A recruitment vendor moves from assisted ranking to automated shortlisting. A CRM adds an agent that can update records or send messages. A cloud provider changes where inference is processed. Each of those changes can alter the data protection, cyber security, contractual and operational risk profile of the system.

This is where many UK businesses are weakest. Procurement teams often collect supplier documents at onboarding, then treat the file as complete. But AI suppliers iterate quickly. Terms of service, subprocessors, model versions, training opt outs, region controls, audit reports, SOC 2 letters, product notices and data processing addenda can all change after the initial approval. If the organisation has no owned change log, those changes are scattered across inboxes, admin consoles, release notes and vendor portals.

The ICO's audit work on AI recruitment tools shows why this matters. In November 2024, it reported consensual audits with developers and providers of AI powered sourcing, screening and selection tools used in recruitment. The ICO recognised the potential employer benefits, but highlighted risks to people, privacy and information rights. That is a useful warning beyond recruitment: where a supplier's AI affects people, the buyer still needs evidence that risks have been assessed and controlled.

A practical supplier change log should record at least eight fields: supplier, product, AI feature, change source, effective date, affected use cases, owner decision and evidence link. Stronger versions add legal basis impact, DPIA impact, security impact, EU AI Act role, human oversight impact and whether staff or customer notices need updating. The point is not bureaucracy for its own sake. The point is to stop AI supplier risk becoming an unmanaged feed of product announcements.

The ICO's recruitment AI audit focused on developers and providers, but buyers should treat supplier changes as their own governance evidence trail.

Cyber security guidance turns change tracking into resilience

Regulatory change logs should not sit only with legal or compliance. AI governance is now inseparable from cyber security. The UK government's AI Cyber Security Code of Practice, published by DSIT with NCSC involvement, sets out baseline cyber security principles for organisations that develop and deploy AI systems. It also says the code and implementation guide will be submitted to ETSI as the basis for a new global standard, TS 104 223, with an accompanying implementation guide, TR 104 128.

That detail matters. If a voluntary code becomes the basis for a global standard, buyers and auditors will start to treat it as a benchmark. Insurers may ask about it. Enterprise customers may include it in due diligence. Boards may use it to test whether AI systems have credible controls for model supply chain risk, prompt injection, data leakage, monitoring, vulnerability handling and incident response. A business that cannot show when it reviewed the code, mapped it to controls and assigned remediation will look less mature than one that can.

GOV.UK says DSIT and NCSC will submit the AI Cyber Security Code of Practice to ETSI as the basis for a new global standard. That is not a reason to panic. It is a reason to create traceability. If the ETSI version changes terminology, control wording or evidence expectations, the organisation needs to know which AI systems and suppliers are affected.

What this means in practice: treat cyber guidance updates like dependency updates. When OpenSSL, a cloud IAM control or a payment provider changes, technical teams usually know they need a ticket, owner and closure evidence. AI controls deserve the same discipline. Put the regulatory or standards change into the same operational rhythm as security exceptions, supplier assurance actions and risk acceptance records. Otherwise the AI register becomes a snapshot while the real system keeps changing around it.

The common misconception is that a register is enough

The leading counterargument is understandable: many firms already have an AI register, a DPIA process, supplier onboarding and a policy. Why add another log? The answer is that a register says what exists. A change log says how the organisation responds when the world around that system changes. Those are different controls.

An AI register might tell you that the business uses a language model for customer support drafts. It might record the business owner, data categories, supplier and approval date. But it usually will not tell you that the supplier changed its data retention option in March, the ICO opened a consultation in April, the EU transparency duty becomes relevant in August, the model version changed in September and customer notices were updated in October. Without a change log, each update becomes a memory test.

There is also a cultural benefit. A change log forces ownership. Someone has to decide whether a new rule affects the business. Someone has to decide whether a supplier update is material. Someone has to record why no action was required. That last point is important. Good governance is not the same as doing something every time. Sometimes the correct decision is 'not applicable', 'monitor only' or 'no control change required'. But the decision should be evidenced.

For UK SMEs, this can be lightweight. A shared spreadsheet, Jira project, GRC tool, Notion database or SharePoint list can work if the fields are consistent and the owner is clear. Larger organisations may link the log to ServiceNow, Archer, OneTrust, Drata, Vanta or their procurement platform. The tooling matters less than the operating habit: every relevant regulatory, standards or supplier change receives an owner, impact decision, action status and evidence link.

That is why the log should sit beside the AI register, not replace it. The register is the map. The change log is the maintenance record.

A practical format for UK boards and operators

A useful AI regulatory change log should be boring, specific and easy to audit. Start with columns for date identified, source, summary, affected regulation or guidance, affected system, affected supplier, business owner, legal owner, security owner, risk rating, decision, action required, due date, status and evidence link. Add a final column for board or committee reporting if the issue is material. Avoid vague statuses such as 'reviewing' unless there is a named next step.

The source categories should include regulators, legislation, standards, sector bodies, suppliers, internal incidents, customer requirements and audit findings. For this topic, examples include the ICO, DRCF, DSIT, NCSC, EU AI Office, FCA, Ofcom, CMA, NHS AI Lab, ISO, ETSI, cloud providers and major AI vendors. The log should also track negative decisions. If the EU AI Act update does not apply because the system is UK only and has no EU deployment, record that analysis and review trigger. Future expansion may change the answer.

The cadence should match the risk. High impact AI systems, such as recruitment screening, credit decisions, clinical triage, safety critical workflows or customer facing agents, deserve monthly review. Lower risk internal productivity use can be reviewed quarterly. Supplier updates should be captured as they arrive, because contractual notice windows can be short. Material changes should feed into the risk committee, data protection steering group or board pack.

The DRCF's April 2026 agentic AI update, summarised in Osborne Clarke's UK Regulatory Outlook, is a good example of why this needs to be ongoing. The DRCF identified cross regulatory implications across governance, data protection and cyber security, consumer rights and interests, and market dynamics and competition. It also plans 2026/27 horizon scanning on interfaces between users, firms and digital services, consumer robotics and physical AI, and the consumer experience of emerging technologies.

That is exactly the kind of signal a business should log before it becomes a formal enforcement expectation. Boards do not need every detail. They do need assurance that the organisation has a repeatable mechanism for noticing change, interpreting it and turning it into action.

Frequently Asked Questions

What is an AI regulatory change log?

It is an auditable record of regulatory, standards, supplier and internal changes that may affect AI systems. It records the source, affected systems, owner, risk decision, actions, dates and evidence.

Is this different from an AI register?

Yes. An AI register records the systems the organisation uses. A change log records how those systems are reviewed and updated when guidance, law, supplier behaviour or risk changes.

Do UK businesses need this if the EU AI Act is not UK law?

Often, yes. UK businesses may be affected if they sell into the EU, deploy AI for EU users, rely on EU suppliers, process EU data or buy tools whose providers change controls because of the AI Act.

Who should own the change log?

Ownership should usually sit with the AI governance lead, risk function, data protection officer or compliance owner. Individual entries should have named business, legal, security and procurement owners where relevant.

How often should it be reviewed?

High impact AI systems should be reviewed monthly. Lower risk internal productivity tools can usually be reviewed quarterly, provided supplier notices and urgent regulator updates are captured as they arrive.

What should be logged from suppliers?

Log model version changes, data retention settings, subprocessors, hosting regions, product AI features, security attestations, terms changes, training data options, incident notices and material release notes.

Does a spreadsheet count as a valid change log?

Yes, if it is controlled, consistently maintained and linked to evidence. The tool is less important than clear ownership, complete fields, review cadence and reliable audit history.

What is the biggest mistake to avoid?

Avoid treating AI governance as a one time approval. AI systems, laws and suppliers change continuously, so the organisation needs a live operating control rather than static paperwork.