A firm owner I spoke with recently had been using an AI tool to draft eligibility assessments for several months. When a client challenged one of those assessments, the owner knew AI had been involved. What she couldn’t say was which version of the prompt had been used, who had reviewed the output before it went out, or what the reviewer had actually checked. The challenge took three weeks to resolve. Good AI recordkeeping would have cut that to a few days.
What does recordkeeping for AI decisions actually mean?
Recordkeeping for AI decisions means keeping a structured log of what your AI tool was asked to do, what it produced, and who made the final call. For an owner-managed services firm, that means capturing six things: the prompt, the tool and model version, the source data, the business purpose, the reviewer’s name, and their approval or override decision, with a date and time attached.
The ICO’s AI and data protection guidance makes clear that organisations must be able to account for decisions involving personal data, including where AI contributed to them. The UK Government’s AI Playbook reinforces this: it requires clearly documented review and escalation processes, and states that humans should validate high-risk decisions influenced by AI. Neither expectation requires complex software. A structured log in your existing case-management tool or a shared spreadsheet is sufficient to start.
What matters more than the tool you use is the discipline. Someone in your firm should own the log, capture entries at the point of use, and be able to pull up a specific record if a customer or regulator asks. That person doesn’t need to be technical. They need to know what to write down and when.
Why does this matter for your business?
Two things make this relevant to a small UK services firm: regulatory accountability and self-protection when something goes wrong. The ICO expects organisations to demonstrate meaningful human oversight of AI-assisted decisions involving personal data. If your firm uses AI to help with pricing, complaints handling, hiring, or client eligibility checks, those are precisely the situations where that expectation applies.
The EU AI Act adds another layer for UK firms with EU customers or EU-facing workflows. High-risk AI systems under the Act carry explicit logging requirements, technical documentation obligations, and a duty to use the system in accordance with the instructions for use. UK-based firms are not outside the Act’s reach if their AI tools process data about EU residents or are deployed in EU-connected workflows.
The NCSC’s AI security guidance points in the same direction from a different angle. Prompt injection, data poisoning, and model manipulation are live threats. A prompt log and approval trail is a security control as well as a compliance record. If your AI tool’s outputs were tampered with and you have no record of what the original prompts looked like, you lose the ability to investigate.
Where will you actually meet this in your work?
The recordkeeping question becomes most pressing when AI assists with a decision that directly affects a customer, employee, or supplier. For a services firm in the five to fifty staff range, that typically means complaints handling, where an AI-drafted response shapes what you offer; pricing, where AI analysis influences a quote; client eligibility assessments; and HR uses such as shortlisting job applications.
The ICO’s guidance on automated decision-making applies where a decision is made solely by automated means and produces legal or similarly significant effects on a person. Many owner-managed firms are not automating decisions in that strict sense. But the closer your workflow gets to “the AI’s recommendation is what goes out”, the more important it becomes to show that a real person reviewed and took responsibility for it.
For firms operating in or adjacent to regulated financial services, the FCA has flagged governance, explainability, and model risk as issues that must be managed. If your work touches advice, pricing of financial products, or complaints, the documentation bar is higher and you should expect regulators to ask who approved a model’s outputs, not just who ran it.
When do you need formal records and when can you keep it lighter?
The level of rigour depends on what the AI output is used for. If your team uses AI to draft internal communications, summarise meeting notes, or generate first-pass copy that a person then revises substantially, a lighter approach is reasonable. The threshold rises when the AI output directly shapes a decision about a specific person, a sum of money, or access to a service.
A practical test, drawn from the ICO and UK Government’s risk-based framing, is whether the AI’s involvement affects someone’s rights, their access to something, or their financial position. Where the answer is yes, a formal record showing reviewer identity, what they checked, and what they decided is both defensible and expected. Where the answer is no, a brief log note is still good practice.
Headcount matters less than the nature of the decision. A firm with four employees using AI to assess applications carries a higher documentary obligation than a forty-person firm using AI to draft client newsletters. Regulators look at the nature of the decision and the data involved. The NCSC supports basic logging and access controls even for lower-stakes uses, because audit trails are standard security hygiene at any scale.
One common mistake is treating a human clicking “approve” as meaningful oversight when that person hasn’t actually reviewed the AI’s reasoning. The ICO and the UK Government’s AI Playbook both point toward genuine human intervention. The record should show what the reviewer looked at and why they agreed or disagreed. A click-to-approve with no review behind it doesn’t demonstrate the oversight either body expects.
What related concepts are worth knowing?
Three regulatory frameworks come up when AI recordkeeping is discussed in a UK context: the ICO’s automated decision-making rules, the UK Government’s Algorithmic Transparency Recording Standard, and the EU AI Act’s high-risk logging regime. Understanding roughly where each one applies helps you calibrate your approach and recognise when your documentation obligations are higher than the baseline.
The ICO’s automated decision-making guidance covers situations where a decision is based solely on automated processing and produces legal or similarly significant effects. If your AI tool is genuinely deciding outcomes without meaningful human review, rather than helping a person decide them, that guidance applies directly. Knowing where your workflows sit on that spectrum is the starting point for calibrating your recordkeeping.
The Algorithmic Transparency Recording Standard applies to central government departments and certain arm’s-length bodies, so it doesn’t apply to private firms directly. It does, however, set a useful model for what transparent, documented algorithmic decision-making looks like. If a public-sector client asks you to demonstrate governance over any AI you use in their workflow, ATRS-style thinking gives you a benchmark.
The EU AI Act is the broadest in reach. It applies to certain high-risk systems deployed in the EU, including those operated by UK-based providers serving EU customers. High-risk classification under the Act triggers technical documentation, logging, and human-oversight requirements. Even if your firm is not currently in scope, the Act defines what rigorous practice looks like, and UK firms working with EU clients should expect that bar to become a reference point over time.
The most practical starting point, regardless of which framework applies to you, is to set up a decision log this week and name one person to own it. That single step covers a meaningful share of the regulatory risk for a small services firm, and it costs only a few hours to get in place.
