AI Evidence Logs Are the Compliance Layer UK Agent Projects Need

AI Trust & Governance

1 May 2026 | By Ashley Marshall

The hard part of AI governance is no longer writing a policy. It is proving what an agent actually did when nobody was watching it step by step.

The governance gap is evidence, not policy

Most UK businesses now have some version of an AI policy. It usually says that staff must not paste confidential data into public tools, that humans remain accountable, and that risky use cases need review. That is useful, but it is not enough once the organisation starts using AI agents that can call tools, read files, draft replies, update CRM records, triage tickets or trigger operational workflows.

The practical question has changed. It is no longer simply, are we allowed to use AI here? It is, can we reconstruct what happened if the agent makes a bad recommendation, exposes personal data, creates a misleading customer message or takes action outside its intended scope? A policy cannot answer that after the event. An evidence log can.

By evidence log, I mean a structured operational record of an AI system's activity. At a minimum, that should include the use case, user, model or agent version, prompt or instruction class, data sources accessed, tools called, outputs produced, confidence or risk signals, human approvals, exceptions and final outcome. In more mature environments it also includes retrieval context, model configuration, policy checks, redactions, security events and links to the relevant DPIA, risk assessment or control owner.

This is where UK regulatory direction is heading. The government's Algorithmic Transparency Recording Standard is public sector focused, but it shows the operating model: publish what the tool does, why it is used, who owns it, what data it relies on, what risks exist and what mitigations are in place. Private sector firms do not need to copy the public register, but they should notice the pattern. Transparency is becoming a record keeping discipline.

UK regulators are asking for accountable use, not magic explanations

One common misconception is that AI compliance means being able to explain every weight, parameter or internal reasoning step inside a model. That is not realistic for frontier models, and in many business contexts it is not the most useful target. What UK regulators increasingly expect is accountable use: clear ownership, proportionate risk controls, fair customer outcomes, responsible data handling and the ability to evidence how a system is governed in practice.

The FCA's February 2026 page on AI and its regulatory approach is explicit that it does not plan to introduce extra AI rules for financial services. Instead, it will rely on existing frameworks, including Consumer Duty, accountability and governance. That matters beyond finance because it reflects the UK's broader preference for context based regulation rather than a single horizontal AI Act equivalent.

Evidence logs fit that model because they connect AI behaviour to existing duties. A sales agent that recommends a product can be assessed against suitability and customer communication standards. A recruitment screening assistant can be checked against fairness, privacy and automated decision making controls. A support agent handling complaints can be reviewed against response quality, vulnerability flags and escalation rules.

What this means in practice is simple: do not start with a 40 page AI governance document that nobody uses. Start with the records you would need if a regulator, customer, insurer, auditor or board member asked what happened. Which agent was involved? Which data did it see? Which human accepted or changed the recommendation? Which guardrail fired? Which exception was ignored? If those answers are not captured at the time, they are usually impossible to recreate later.

The numbers show why manual oversight will not scale

The most useful evidence for this shift comes from financial services, because the sector is already measuring AI deployment in detail. The joint Bank of England and FCA AI in UK financial services survey found that 75% of firms are using AI, with a further 10% planning to do so in the next three years. It also found that foundation models, including large language models, already make up 17% of AI use cases.

Those figures matter because governance workload rises faster than usage. A business can manually review ten AI generated email drafts. It cannot manually review every retrieval event, tool call and recommendation across thousands of agent interactions without turning the whole business into a compliance bottleneck. The answer is not to remove human oversight. The answer is to make oversight targeted, risk based and supported by good operational evidence.

The same survey found that 55% of AI use cases involve some automated decision making, although only 2% are fully autonomous. That is exactly the messy middle most UK businesses are entering: not robots running the company alone, but systems that influence decisions, prepare actions, route work, draft customer communications and shape what humans see. In that middle ground, an audit trail is not bureaucracy. It is how humans stay meaningfully in control.

For a practical agent deployment, this means classifying actions by risk. Low risk summarisation might need lightweight logging and sampling. Customer facing financial advice, employee screening, complaint handling or contract changes need stronger evidence: input records, retrieved source material, approval steps, escalation flags, versioning and periodic review. Tools such as LangSmith, Humanloop, Arize Phoenix, OpenTelemetry traces, cloud audit logs and SIEM platforms can all play a part, but the governance design matters more than the vendor logo.

Agentic AI creates a forensic problem for ordinary businesses

Traditional software usually fails in ways that are easier to replay. A user clicked a button, an API returned a value, a database changed and a log shows the transaction. Agentic AI is different because the system may interpret an instruction, retrieve context, choose between tools, draft intermediate outputs and adapt its next step based on previous results. That flexibility is the point, but it also creates a forensic problem.

The NCSC's April 2026 blog on frontier AI and cyber defence highlights how quickly agentic capability is improving. It cites AI Security Institute testing in which seven frontier models were evaluated on multi step cyber attack scenarios. On a 32 step simulated enterprise network attack, the best performing model averaged 15.6 steps with extended processing time and completed 22 of 32 steps in its best run. The NCSC's message is that defenders should assume capable AI tools are already available to attackers and must raise their defensive baseline.

For businesses deploying agents internally, the same logic applies in reverse. If an AI agent can chain actions together, the organisation needs a chain of evidence to match. Otherwise a risky outcome becomes a debate based on screenshots, memory and best guesses. Did the agent access the wrong folder? Did it retrieve outdated policy? Did a user instruct it badly? Did a connector expose too much permission? Did a human approve the final action without reading the source material?

What this means in practice is that AI logging should be designed like incident response evidence, not like vanity analytics. Capture enough to answer who, what, when, where, why and with what authority. Protect the logs themselves because they may contain personal data or sensitive business context. Set retention periods. Hash or sign important records where integrity matters. Make logs searchable by use case, customer, agent version, risk flag and human approver. The aim is not to surveil staff. The aim is to make high consequence automation reviewable.

Evidence logs turn privacy and trust into operational controls

Data protection is where evidence logging becomes especially practical. The ICO's AI and biometrics strategy announcement in June 2025 said the regulator would scrutinise emerging risks such as agentic AI as systems become increasingly capable of acting autonomously. The same announcement reported that 54% of surveyed people were concerned that police use of facial recognition technology would infringe their right to privacy. The specific example is policing, but the trust lesson applies widely: people want to know when AI affects them and what safeguards exist when it goes wrong.

Under UK GDPR, businesses already need to show lawful basis, purpose limitation, data minimisation, security, fairness and accountability. If an AI agent touches personal data, the evidence log is often the only practical way to demonstrate those principles at operational level. It can show that the agent accessed only the approved data source, that sensitive fields were redacted, that a human reviewed the recommendation, that automated decision making controls were triggered, or that an exception was escalated.

This is not just about avoiding fines. Evidence logs help teams improve systems. If a support agent keeps retrieving outdated policy articles, the log points to a knowledge base problem. If a recruitment assistant produces inconsistent shortlists, the log provides a review sample. If a sales agent repeatedly drafts claims that legal rejects, the log shows where guardrails or training need changing.

The counterargument is that logging everything creates more risk because logs can become a new store of sensitive data. That concern is valid. The answer is not to avoid evidence. It is to design it properly: minimise raw prompt storage where possible, separate identifiers from content, encrypt logs, control access, redact secrets, define retention by risk and document why each field is captured. A compliance layer that creates uncontrolled data exhaust has missed the point.

What a useful AI evidence log should contain

A useful evidence log is not a transcript dump. It is a structured record that lets the organisation govern, investigate and improve AI activity. For most UK businesses, the core schema should include five groups of information: identity, context, action, control and outcome.

Identity covers the agent, model, version, user, business owner and supplier. Context covers the use case, task type, data classification, source documents, retrieved records and policy constraints. Action covers tool calls, API requests, generated outputs and proposed changes. Control covers guardrails, approval steps, escalation triggers, override reasons, human reviewer identity and any security or privacy filters applied. Outcome covers the final decision, customer or operational impact, follow up action, review status and links to complaints or incidents where relevant.

The important discipline is proportionality. A marketing brainstorming assistant does not need the same evidence depth as an AI agent that changes customer records, screens job applicants or recommends regulated products. Use tiers. Tier one might capture basic usage and output metadata. Tier two adds retrieved sources, approval steps and risk flags. Tier three adds immutable records, independent review, retention locks and board reporting for high impact processes.

Businesses should also avoid building this as a compliance sidecar that nobody reads. The evidence log should feed actual management routines: monthly exception reviews, data protection audits, supplier performance conversations, model update approvals and incident response. If you already use ServiceNow, Jira, HubSpot, Salesforce, Microsoft Purview, Google Cloud Logging, AWS CloudTrail, Azure Monitor or a SIEM, integrate the record rather than creating yet another spreadsheet. The test is simple. If something goes wrong on a Friday afternoon, can the accountable manager understand the chain of events by Monday morning?

Frequently Asked Questions

Are AI evidence logs legally required in the UK?

There is no single UK law that says every business must keep an AI evidence log. But existing obligations around accountability, data protection, consumer outcomes, auditability, security and regulated decision making are much easier to meet when agent activity is recorded in a structured way.

Is an evidence log the same as an audit log?

It overlaps with an audit log, but it is usually broader. A normal audit log might show that an API call happened. An AI evidence log should also capture context such as the use case, data sources, model version, guardrails, human approval and final outcome.

Should businesses store every prompt and response?

Not always. Raw prompts can contain personal data, confidential information or secrets. A better approach is risk based: store enough to reconstruct important decisions, redact sensitive content where possible, and define retention periods by use case.

Who should own AI evidence logging?

Ownership should sit with the business owner of the AI use case, supported by compliance, data protection, security and IT. If nobody owns the log, nobody owns the operational risk.

What tools can help create evidence logs?

Depending on the stack, options include LangSmith, Humanloop, Arize Phoenix, OpenTelemetry, cloud audit logs, SIEM tooling, Microsoft Purview, AWS CloudTrail, Azure Monitor, Google Cloud Logging and workflow records in systems such as ServiceNow or Jira.

How does this relate to UK GDPR?

UK GDPR requires accountability, fairness, security, data minimisation and transparency when personal data is processed. Evidence logs help show how an AI agent handled personal data, what controls applied and whether human review occurred.

Will evidence logging slow AI adoption down?

Good logging should speed responsible adoption because it gives leaders, auditors and risk teams confidence to approve use cases. Poorly designed logging can become bureaucracy, so the depth of evidence should match the risk of the agent's actions.

What is the biggest mistake to avoid?

The biggest mistake is treating logging as a technical afterthought. Decide what questions the business must be able to answer after an incident, complaint or audit, then design the evidence record around those questions.