AI Policy to Evidence Mapping for Regulated Firms

AI policy to evidence mapping is the practice of tying every statement in a firm's AI policy to a specific, verifiable artifact that shows the statement was true in operation: which agent acted, under whose authority, against which control, and when. A policy that says humans oversee high-risk AI is an intention. A mapped policy names the control, the owner, the evidence record and the retention period, so an auditor can test the claim without relying on anyone's recollection.

This guide is written for risk, compliance and governance leaders at regulated financial services firms in the UK and EU, and for US teams that serve those markets. It covers what to map, how to build the map, where firms go wrong, and how to produce evidence without touching customer data.

TL;DR

• A policy-to-evidence map links each obligation (for example EU AI Act Article 26, FCA SYSC 4.1.1R, Consumer Duty outcomes) to a control, an owner and a machine-verifiable evidence item.
• System logs are necessary but not sufficient. Regulators expect an interpretive layer that connects technical records to customer outcomes and named accountable people.
• Start with an inventory of AI agents and their identities. Without it, shadow AI sits outside the map and outside the audit.
• Evidence can be built from metadata alone, so the governance layer does not become a new data-protection risk.
• Treat the map as a living control, refreshed whenever agents, permissions or regulatory dates change.

Table of Contents

• Why a policy alone no longer satisfies an auditor
• The three layers of a policy-to-evidence map
• Logs are not governance evidence
• How to build the map, step by step
• A worked example: a retail credit agent
• Common pitfalls
• Perspective: evidence by design
• Where AETHER Pulse fits
• Maintaining the map over time
• FAQ
• Sources

Why a policy alone no longer satisfies an auditor

Most regulated firms now have an AI policy. Far fewer can show, on request, that the policy operated on a given day for a given automated decision. That gap is what mapping closes.

The UK Financial Conduct Authority has been explicit that it does not plan separate AI rules. Its AI update points firms to existing high-level obligations, including SYSC 4.1.1R on robust governance and systems and controls, and keeps accountability with senior managers. That means the evidence an examiner asks for is the evidence you would produce for any other material system: who is accountable, which controls apply, and proof those controls ran.

In the EU, the framing is more prescriptive. Article 26 of the AI Act requires deployers of high-risk AI systems to use them according to their instructions, assign competent human oversight and monitor operation. The Commission's AI Act FAQ adds that oversight must be assigned to a person equipped and empowered to intervene, which makes it an operational duty and not a documentation exercise.

Both regimes converge on one demand: show, with records, that oversight existed and worked.

The three layers of a policy-to-evidence map

A defensible map has three layers. Firms that skip one tend to discover the omission during an audit.

Layer 1: Obligations

This is the regulatory and internal source text, broken into testable statements. Do not map a framework as a whole. Map its individual requirements.

Examples of testable statements:

• Deployer uses the high-risk system in accordance with its instructions for use (AI Act Article 26).
• Human oversight is assigned to a named, competent person with authority to intervene (AI Act Article 26).
• Automatically generated logs are retained for the required period (AI Act Articles 12 and 26).
• Systems and controls are robust and proportionate to the firm's activities (FCA SYSC 4.1.1R).
• Outcomes for retail customers are monitored and differential outcomes can be justified (FCA Consumer Duty).

Layer 2: Controls

A control is what the firm does to satisfy the statement. It needs an owner, a frequency and a trigger. Typical AI controls include approval before an agent is granted access to a system, periodic recertification of agent permissions, segregation between the party that configures an agent and the party that approves its actions, and escalation when an agent's behavior leaves its documented purpose.

Layer 3: Evidence

Evidence is the artifact proving the control operated. Strong evidence has four properties:

1. Provenance: you can say where it came from and which system produced it.
2. Timeliness: it was generated at or near the time of the event, not reconstructed afterward.
3. Integrity: it is tamper-evident, for example through cryptographic signing, so a third party can verify it has not been altered.
4. Traceability: it links back to the obligation and the control it supports.

A useful test: could an auditor, working offline with only the evidence pack, reach the same conclusion you did? If the answer depends on a conversation with the team, the evidence is incomplete.

Logs are not governance evidence

A frequent mistake is to treat the AI Act's logging requirement as the whole answer. Article 12 requires high-risk systems to have automatic logging capabilities that record events across their lifecycle, and Article 26 obliges deployers to keep the logs the system generates, for at least six months unless other law requires longer. Those logs matter, and they are a technical record of what the system did.

They do not, on their own, show that a person with authority reviewed the system, that the system was operating within its intended purpose, or that a retail customer received a fair outcome. The FCA's expectation under the Consumer Duty is about outcomes. Its information for firms asks for the policies, processes and management information that support compliance, and board review of retail customer outcomes at least annually.

The interpretive layer connects the two. A mapped item might read: Agent A approves credit-limit adjustments; its identity, scopes and owner are recorded; its actions are logged; a named senior manager reviewed exceptions in the quarter; outcomes were sampled against the firm's fair-value assessment. Each clause points to a separate evidence item, and the chain is what an auditor follows.

Our own deeper treatment of this distinction is in AI logging for compliance teams.

How to build the map, step by step

1. Inventory every agent and its identity

You cannot map what you have not found. Start with an inventory of AI agents, copilots and automations, including those connected through OAuth grants, scripting automations and third-party integrations. For each, record the owning team, the identity it acts under, the systems it can reach and the permissions it holds.

The NIST AI RMF Playbook suggests actions for each subcategory of the framework's Govern, Map, Measure and Manage functions, and an inventory is the precondition for most of them. An identity graph, which shows how agents, human owners, service accounts and data scopes relate, turns the list into something you can query for concentration of risk. See AI identity graphs for regulated finance for how this works without agents installed on endpoints.

2. Classify each agent by purpose and risk

Record the intended purpose, the decisions the agent influences and whether it falls into a high-risk category under the EU AI Act. Add the exposure dimension that risk committees care about: what is the maximum financial effect if this agent misbehaves? A financial blast-radius estimate (the value of transactions, limits or accounts an agent can touch) lets you prioritize evidence work where it matters.

NIST AI RMF 1.0 stresses that early decisions about purpose and objectives create interdependencies across the lifecycle. If those assumptions are not documented and linked to later deployment records, you lose the ability to anticipate impacts. The classification step is where that link begins.

3. Decompose obligations into testable statements

Take each framework in scope and write the requirement as a statement a control can satisfy. Keep the source reference beside it. Resist the urge to merge overlapping requirements too early: one control often supports several statements, but the map should show that explicitly, so a change in one regulation does not silently orphan a control.

4. Assign controls and owners

Every statement gets at least one control and one accountable person. In UK firms this should align with the Senior Managers regime, since the FCA keeps accountability with senior managers. For EU high-risk deployments, name the human overseer Article 26 requires, and record their competence and authority.

5. Define the evidence item for each control

Specify what the artifact is, which system generates it, how often, how it is signed and how long it is kept. Prefer evidence that is deterministic: the same inputs produce the same record, so a reviewer can reproduce the conclusion. Our approach to this is covered in deterministic controls for AI in regulated finance.

6. Collect evidence continuously, not at audit time

Evidence assembled retroactively invites doubt. Collect on a schedule or event trigger, sign it at creation, and store it where it cannot be edited. A signed record created at the time of the decision proves the oversight process was running then, which a reconstructed report cannot.

7. Test the map with a mock audit

Pick three obligations at random and ask a colleague outside the governance team to trace each from the policy statement to the evidence. Every break in the chain is a gap to fix before an examiner finds it.

A worked example: a retail credit agent

Consider a firm that uses an AI agent to pre-screen retail credit applications. The map for a single obligation might look like this.

None of these items requires reading a customer's application. The inventory, the permissions, the configuration history and the approvals are all metadata. That matters, because it means the governance layer can be built without creating a second copy of sensitive data.

Common pitfalls

Treating governance as a static IT configuration. Oversight is a dynamic relationship between policy and what agents actually do. Agents get new scopes, owners leave, vendors ship features. A map that is reviewed annually will be wrong for most of the year.

Missing shadow AI. Employees connect tools through OAuth grants and automations that bypass change management. If the inventory relies on self-reporting, it will under-count. Metadata-level discovery closes this gap without inspecting content.

Relying on internal reports instead of verifiable evidence. A slide summarizing compliance is an assertion. Auditors prefer records they can verify independently, which is why signing and provenance matter.

Mapping to frameworks without dates. Regulatory timelines move. The EU's Digital Omnibus on AI entered into force on July 27, 2026 according to a law firm update, and the proposal defers the high-risk compliance deadline from August 2, 2026 to December 2, 2027. Confirm the current dates with counsel for your specific systems. Either way, the evidence you need takes time to accumulate, so waiting for the final deadline is a poor plan.

Ignoring third parties. Many agents are vendor-supplied. The firm is still accountable for their oversight. See our 30/90/180-day plan for third-party AI.

Perspective: evidence by design

We build AETHER Pulse on a simple observation: the cheapest evidence is the evidence a system emits as a by-product of operating, and the most expensive is the evidence a team assembles in the weeks before an audit.

That is why we connect through OAuth metadata only. We do not install endpoint agents, and we do not touch customer data. For a regulated firm, that changes the internal conversation. Data protection, security architecture and procurement have far less to review when the tool never sees a customer record, and the governance function can start producing evidence in weeks, not quarters.

We also hold that every risk classification should be deterministic and cited. If a platform tells a compliance officer that an agent is high risk, the officer should be able to see the rule applied and the public source behind it. Our evidence packs are signed with HMAC-SHA256, so the integrity of each item can be checked offline by an auditor or regulator without access to our systems.

We would also be direct about limits. Evidence of oversight does not replace oversight. A signed record proves that a review took place; it does not make the review good. The map exists to make accountable people's work visible and testable, not to substitute for it.

— Eleye

Where AETHER Pulse fits

AETHER Pulse is a read-only governance and evidence layer for regulated financial services firms. It builds the inventory and identity graph of AI agents from metadata, surfaces risk concentration including financial blast-radius exposure, and generates provenance-tracked evidence packs aligned to EU AI Act Article 26, the Data (Use and Access) Act, FCA SYSC and Consumer Duty, and ICO frameworks.

If you want to see what a mapped policy looks like in practice, review the plans on our pricing page, which covers the Design Partner and Production options and an Article 26 readiness audit, or start from the AETHER Pulse home page for the Free, Pro and Enterprise plans.

Maintaining the map over time

A map decays unless someone owns its upkeep. Build three habits into the governance calendar.

• Event-driven refresh: when a new agent is connected, a permission scope changes or an owner leaves, the inventory and map update automatically or trigger a review.
• Regulatory watch: assign someone to track changes to the AI Act timeline, FCA publications and ICO guidance. Update the obligation layer, then trace which controls and evidence items are affected.
• Periodic assurance: have internal audit sample the map each cycle, checking that evidence items exist, are signed and link to the right obligations. Our guide to agentless governance in 90 to 120 days sets out a rollout sequence, and the governance framework article shows how the four NIST functions translate into evidence.

For a US team, one practical note: the NIST AI RMF is voluntary and non-regulatory, but it gives a shared vocabulary for the map, and its documentation habits align with the controls UK and EU supervisors expect. Treat it as a structure, and treat the EU and UK rules as the obligations.

FAQ

What is the difference between AI policy mapping and AI risk assessment?

A risk assessment evaluates how likely and how severe harm could be from a system. Policy to evidence mapping connects the rules the firm has committed to with the proof that those rules were followed. The two feed each other: classification from the assessment decides which obligations apply, and the map shows whether the corresponding controls ran.

Do system logs satisfy EU AI Act Article 26?

They satisfy part of it. Deployers of high-risk systems must keep automatically generated logs for at least six months, unless other law requires longer. Article 26 also requires human oversight and monitoring according to instructions for use, which need separate evidence such as named overseers, competence records and review outputs.

Can evidence be produced without accessing customer data?

For most governance questions, yes. Agent inventory, identity, permissions, configuration changes, approvals and review records are metadata. A metadata-only approach avoids creating a new store of sensitive data, though some outcome testing under Consumer Duty will still involve the firm's own data handled under its existing controls. Read more in our article on privacy-preserving agent audits.

How often should the map be updated?

Continuously for the inventory and evidence, and at least with every material change to agents, permissions or regulation. A full human review at least annually is a sensible floor, and it fits the FCA's expectation that boards review retail customer outcomes at least once a year.

Does the FCA require a separate AI framework?

No. The FCA's published position is that existing principles, including SYSC 4.1.1R and senior manager accountability, already apply to AI. Firms should therefore map AI controls into their existing governance and systems and controls framework. Confirm how this applies to your permissions and activities with your compliance adviser.

Sources

• AI Act Service Desk: Article 26, obligations of deployers of high-risk AI systems
• AI Act Service Desk: Article 12, record-keeping
• European Commission: Navigating the AI Act
• FCA: AI Update
• FCA: Consumer Duty information for firms
• NIST: AI Risk Management Framework (AI RMF 1.0)
• NIST: AI RMF Playbook
• DLA Piper: The Digital AI Omnibus, proposed deferral of high-risk AI obligations

Recommended

• AI Agent Governance for Finance: Four Functions, Evidence by Design
• AI Logging for Compliance Teams: Audit Evidence Without Customer Data
• Map NIST to Evidence: Regulator Ready AI Reports for Compliance
• Decision Pipeline Evidence for Finance: Prove Intent Before Execution