You cannot measure AI adoption with one number.
The Bank of England and Financial Conduct Authority reported in 2024 that 75% of 118 responding financial-services firms were already using AI. A 2026 Department for Science, Innovation and Technology study, based on a weighted survey of 3,500 UK businesses, put current use among finance and real-estate businesses at 21%.
Those figures are not directly comparable. The populations, definitions and survey methods differ. That is the point. Inside a firm, the phrase "AI adoption" can cover a licence assigned, a login, a recurring AI-assisted workflow, a faster investment-committee paper, or client work that passes review with less rework. Put those into one rate and you get a number with no decision attached.
A useful measurement system keeps them separate.
A working definition of AI adoption
AI adoption is the repeated, authorised use of AI in a defined workflow by the people expected to run it, with evidence that it produces an acceptable result under the agreed controls.
That is the working definition I use in this guide. It is a measurement contract, not an industry benchmark.
Buying a tool enables use. Training can make use more likely. Neither proves that the work changed. Adoption begins when the behaviour repeats in a bounded workflow and the result meets the standard the team set in advance. Team capability goes one step further: another operator can reproduce that result without the original user coaching them through it.
Executive summary
- Measure one workflow at a time. "Copilot adoption" is too broad; "preparing a first draft of an investment-committee paper from approved source material" can be observed.
- Keep access, activity, repeated workflow use, operating outcomes and control performance as separate layers. Do not blend them into a maturity score.
- Record a baseline before the intervention. Use comparable work, the same metric definitions and the strongest practical comparison group.
- Count accepted work, not generated output. Include review time, corrections, exceptions, tool cost and implementation effort.
- Report numerators, denominators, observation windows and evidence locations. A percentage without those four things is decoration.
- Treat a customer case study as an evidence file. Every number needs a source record, an owner, a limitation and permission to publish.
The right unit is a workflow
An investment firm does not adopt AI in the abstract. A private-equity deal team may use it to query a data room, prepare a market map or draft an investment-committee paper. A wealth manager may use it for meeting preparation, call notes or a first draft of a client follow-up. An advisory team may use it for research synthesis, proposal drafting or quality review.
Each workflow has a different user, frequency, source boundary, acceptance standard and consequence of error. A weekly portfolio-monitoring workflow cannot share a denominator with a quarterly client report. Nor should a low-risk internal summary share a control threshold with a recommendation that reaches a client or informs an investment decision.
Write the unit of measurement in one sentence:
When [trigger] occurs, [eligible operator] uses [approved AI system] with [permitted inputs] to produce [defined output], which [named reviewer] accepts against [quality and control standard].
If the team cannot complete that sentence, it is too early to discuss an adoption rate.
This is also where declared progress separates from demonstrated progress. I call that distance the Demonstration Gap. Licences, training attendance and pilots belong in the declared ledger. Accepted work, repeated behaviour and moved operating measures belong in the demonstrated one. You need both ledgers, but only one proves that the capability exists.
The five-layer adoption evidence stack
The stack answers five different questions. Keep the answers visible beside each other.
| Layer | Question | Measures to record | What it proves |
|---|---|---|---|
| 1. Access | Could the right people use the approved system? | Eligible operators, authorised operators, licence or access rate, training completion, blocked access | Readiness and coverage |
| 2. Behaviour | Did they use it, then return? | Active users in a defined period, active days, returning users, voluntary repeat use, time to first accepted run | Use beyond nominal availability |
| 3. Workflow | Did use occur in the intended work, and can it travel? | Accepted AI-assisted runs, workflow penetration, repeat runs, independent operators, time to reuse, documented version | A repeatable team method rather than isolated activity |
| 4. Outcome | Did the work improve against a baseline? | Cycle time, throughput, first-pass acceptance, substantive rework, error rate, decision time, cost, realised capacity, relevant business KPI | Task value and, where attribution is defensible, business value |
| 5. Control | Did the gain remain inside the firm's limits? | Review completion, evidence trace, policy pass rate, exception and escalation rate, manual switchbacks, incidents, data-boundary breaches | An acceptable result, not merely a faster one |
Layer 1: access
Access is an input. It still matters because a poor denominator corrupts every rate after it.
Authorised access rate = authorised operators / eligible operators- Record why an eligible operator lacks access: policy, licence allocation, training, role, data restriction or technical failure.
- Separate authorised tools from unapproved or unknown tools. A survey that cannot see shadow use should say so.
A high access rate can coexist with no adoption. That is not a paradox. It means the firm has bought the possibility of changed work.
Layer 2: behaviour
Define an active user in terms of an intentional action and a fixed observation window. Vendor dashboards can help with this layer. Microsoft, for example, defines an active Copilot user as someone who performed at least one intentional action in the previous 28 days, and a returning user as someone active in both the current and preceding period.
Those are useful operational definitions. They remain usage measures.
Active rate = active eligible operators / eligible operatorsReturning rate = operators active in both periods / operators active in the preceding period- Report active days or actions per active operator beside the rate so one accidental click does not look like a habit.
- Segment by team, role and workflow only where the group is large enough to report responsibly.
Do not set a universal target. A tool used for quarterly reporting should not be judged by daily activity.
Layer 3: workflow
This is where adoption starts to become visible in the work.
Workflow penetration = accepted AI-assisted runs / eligible completed runsRepeat-run rate = operators with at least two accepted runs / operators with at least one accepted run- Record the number of distinct operators who complete the workflow to the agreed standard without the original operator guiding them.
- Record the workflow version, model or system, approved source boundary, reviewer and result.
One working measure worth testing is time to reuse. Start the clock at the first accepted AI-assisted run and stop it when a second operator independently reaches the same acceptance standard. It is a proposed diagnostic, not a benchmark. A long interval tells you where to look: unclear instructions, missing context, a hidden judgement call, poor incentives, weak access or a control step that was never written down.
The raw dates matter more than a traffic-light label.
Layer 4: outcome
Measure the work before pricing the value.
Useful workflow outcomes include:
- median cycle time, with the distribution shown where volume permits;
- completed work per comparable period;
- first-pass acceptance against a written rubric;
- substantive corrections or rework minutes;
- factual, calculation or citation errors found in review;
- decision or response time;
- capacity that was actually redeployed to named work;
- a business measure with a plausible causal link, such as proposal conversion, client response time or research coverage.
For a task where lower is better, a simple cycle-time calculation is:
Cycle-time improvement = (baseline median - measured median) / baseline median
Keep the baseline median, measured median, sample size and observation window beside the percentage.
Time saved is not automatically cash saved. If two hours disappear from a weekly task but the team does not remove cost, increase output or move that capacity to something named, report two hours of released capacity. Do not quietly convert it into salary value.
A conservative value bridge is:
Net measured value = realised capacity value + attributable revenue contribution + evidenced loss avoidance - tool cost - implementation cost - review cost - remediation cost
Show each component. If attribution is weak, leave it out and report the task-level evidence instead.
Layer 5: control
Investment and advisory work can contain client data, market-sensitive information, regulated communications and judgement with real consequences. The measurement system must show whether the workflow stayed inside the firm's own boundaries.
Control pass rate = sampled runs meeting every required control / sampled AI-assisted runsException rate = runs sent to an exception or escalation route / AI-assisted runsManual switchback rate = runs returned to the prior manual route / AI-assisted runs- Record review completion, unsupported claims, source-trace failures, data-boundary exceptions, incidents and near misses where those measures apply.
- Record the reason for every switchback. A rising rate may mean the workflow, model, source material or policy has changed.
This guide is not a compliance checklist. Apply the firm's legal, regulatory, fiduciary, data, security and model-risk requirements to the specific use case.
A scorecard for investment and advisory workflows
The following rows are measurement designs, not claims about results.
| Workflow | Behaviour and workflow evidence | Outcome evidence | Quality and control evidence | Possible business bridge |
|---|---|---|---|---|
| Research synthesis | Returning analysts, accepted briefs, independent reuse of the workflow | Median time to accepted brief, coverage per period, rework minutes | Source coverage, unsupported statements, reviewer acceptance | More companies, sectors or themes covered at the same standard |
| Data-room or due-diligence review | Eligible projects using the workflow, repeat use across projects, independent operators | Query response time, documents processed, review effort | Missed issues, false positives, source trace, escalation rate | Earlier issue identification or more diligence completed with the same team |
| Investment-committee paper | Accepted AI-assisted drafts, returning authors, workflow version used | Draft-to-approval time, substantive revision count | Citation and calculation checks, reviewer sign-off, sensitive-data handling | More decision time for the committee, if the released time is observed |
| Client meeting preparation and follow-up | Eligible meetings using the workflow, repeat use by advisers | Preparation time, follow-up time, completion rate | Factual corrections, suitability or compliance review where applicable, client-data controls | Faster response or more adviser capacity, with attribution stated cautiously |
| Portfolio monitoring | Scheduled runs completed, independent coverage by the team | Time from source update to reviewed signal, analyst review time | False alerts, missed alerts, source trace, escalation | More holdings covered or faster review of material signals |
| Proposal or RFP drafting | Returning users, accepted first drafts, reuse across opportunities | Cycle time, first-pass acceptance, substantive edits | Claim substantiation, confidentiality checks, approval completion | Proposal throughput or conversion, with other causes disclosed |
The best metric is the one tied to the workflow's original reason for existing. If the reason was faster research, measure accepted research time and quality. If the reason was better risk detection, a login rate is several steps away from the claim.
How to set up the measurement in practice
1. Name one workflow and one owner
Choose a workflow with a clear trigger, enough volume to observe, a reviewer and an output that can be judged. Name the operational owner and the measurement owner. They may be the same person in a small team, but the responsibilities should still be explicit.
Avoid starting with "all analysts" or "the whole advisory practice". Start with a piece of work that fits on a screen.
2. Write the measurement contract before the pilot
Record:
- the workflow and why it matters;
- eligible operators and eligible workflow instances;
- approved tool, model or system version;
- permitted and prohibited inputs;
- definition of an acceptable result;
- required human review and decision rights;
- baseline metrics and data sources;
- intended outcome and the evidence that would support it;
- known risks, stop conditions and exception route;
- the decision at the end: scale, redesign, extend the test or stop.
This prevents the team choosing the success measure after it has seen the result.
3. Establish a comparable baseline
Use the same workflow definition, output standard and population. Cover a complete operating cycle rather than an arbitrary number of days. A quarterly workflow needs a baseline that respects its quarterly rhythm.
Record volume, median cycle time, quality, rework, exceptions and cost before introducing the AI-assisted route. Note any concurrent change in staffing, demand, source data, process or policy.
4. Instrument the smallest useful event record
For each eligible workflow instance, capture:
| Field | Purpose |
|---|---|
| Workflow instance ID | Joins usage, outcome and review evidence without relying on a person's memory |
| Date and trigger | Defines the observation period and operating context |
| Operator and role | Supports cohort analysis under the firm's privacy rules |
| Tool, model and workflow version | Makes the result reproducible and reveals changes over time |
| AI-assisted or comparison route | Identifies the intervention |
| Start, first draft and acceptance time | Measures cycle time without using self-report alone |
| Reviewer and acceptance result | Connects activity to accepted work |
| Rework, exception and switchback | Captures hidden burden and failure |
| Source or evidence record | Lets another person verify the claim |
Collect only what the firm is permitted to collect. Publish aggregated results only where the underlying group and consent make that responsible.
5. Use the strongest practical comparison
In descending order of confidence, consider:
- random allocation of comparable eligible work or operators where it is ethical and operationally sensible;
- a staggered rollout, so later groups provide a temporary comparison;
- a matched comparison across similar teams, people or workflow instances;
- a within-person comparison on comparable work;
- a before-and-after comparison with concurrent changes and limitations stated.
The UK Government's guidance on evaluating AI interventions recommends iterative evaluation through small tests, wider pilots and full rollout, and asks evaluators to be explicit about what early findings can and cannot support at scale. The same discipline is useful here even though the setting is private-sector work.
6. Review the work, not only the telemetry
Usage logs cannot tell you whether an investment thesis is sound or a client communication is acceptable. Use a written rubric and a domain reviewer. Where feasible, blind the reviewer to whether AI was used.
Sample both successful and failed runs. Record substantive corrections, unsupported claims, missed evidence, false alerts, data-boundary problems and the review minutes required to catch them.
7. Read the layers without averaging them away
At the decision meeting, show one page:
- access and the true eligible denominator;
- active and returning behaviour;
- accepted workflow use and independent reuse;
- outcomes against baseline and comparator;
- control results, exceptions and review burden;
- costs, limitations and the proposed decision.
Do not average these into one score. A high usage rate can hide no improvement. A faster task can hide more corrections. A strong result from one expert can hide a workflow nobody else can run.
8. Turn the accepted method into team memory
If the evidence supports continued use, save the workflow close to the work itself. Capture the trigger, permitted inputs, steps, judgement points, acceptance standard, failure route, owner and review date. Keep an accepted example and the reason it passed.
Then run it with a second operator. That is the moment a personal trick begins to become a team capability.
Remeasure when the model, tool, source boundary, policy, team or workflow changes materially. NIST's AI Risk Management Framework treats measurement and risk management as continuing work across the system lifecycle, which is the sensible posture here too.
What not to call adoption
Licences alone
A licence count answers who has access. It says nothing about the work completed, the result accepted or the value realised.
Logins alone
A login can show awareness or curiosity. It cannot show that someone used AI in a target workflow or returned because it helped.
Self-reported hours alone
Ask people about their experience, but pair the answer with timestamps, accepted outputs and review effort where possible. Recall and enthusiasm are useful qualitative evidence, not a stopwatch.
Output volume alone
More drafts can create more review. Count accepted work and the burden required to accept it.
A universal maturity score
One number hides the failure mode. Keep access, behaviour, workflow, outcome and control evidence separate so the next action remains obvious.
A business result with no comparison
Revenue, investment performance and client retention have many causes. Name the causal path, use a comparator where possible and state what the evidence cannot isolate.
The decision this measurement should support
The measurement is finished only when it changes an operating decision.
- Scale when repeated, independent use produces an accepted result and the outcome improves inside the control limits.
- Redesign when the task has value but people do not return, the review burden erases the gain or the workflow depends on hidden coaching.
- Extend the test when volume or the comparison is too weak to support a decision, with the next evidence gap named in advance.
- Stop when the task does not improve, the control burden is disproportionate or a safer manual route remains better.
The awkward question is not how many people have access. It is which workflows the team can demonstrate, what changed when they ran them, and whether the evidence survives scrutiny.
If you cannot name a second operator and an accepted result, you may have a capable user. You do not yet have a team capability.
Put one workflow on the screen at the next adoption review and ask someone other than its inventor to run it.
One-page named-customer case-study template
Template status: blank by design. Do not publish a completed case study until the customer is named, every result is supported by a source record, limitations are complete, and the customer has approved the wording.
[Customer name]: [verified result] in [named workflow]
| Case field | Customer-approved value |
|---|---|
| Customer | [Legal name and approved public name] |
| Sector | [Investment manager, wealth manager, private-capital firm, advisory firm, other] |
| Team | [Function, geography and team size] |
| Workflow | [One bounded workflow] |
| Measurement period | [Baseline dates] compared with [evaluation dates] |
| Publication permission | [Approver, date and scope of consent] |
The starting point
[Describe the workflow before the intervention in 80 words or fewer. State the trigger, operator, output, reviewer and the problem to solve. Do not add market claims.]
The measurement contract
| Field | Customer-approved value |
|---|---|
| Intended outcome | [One outcome] |
| Eligible operators | [Count and inclusion rule] |
| Eligible workflow instances | [Count and inclusion rule] |
| Approved AI system and version | [Tool, model, configuration and dates] |
| Acceptance standard | [Written rubric and threshold] |
| Required review | [Role, coverage and decision right] |
| Baseline source | [System, report or evidence path] |
| Comparison method | [Random, staggered, matched, within-person or before-and-after] |
| Stop and exception conditions | [Conditions and route] |
What changed
| Measure | Baseline | Evaluation | Change | Denominator and window | Evidence owner and source |
|---|---|---|---|---|---|
| Authorised access rate | [ ] | [ ] | [ ] | [ ] | [ ] |
| Returning workflow users | [ ] | [ ] | [ ] | [ ] | [ ] |
| Accepted AI-assisted runs | [ ] | [ ] | [ ] | [ ] | [ ] |
| Independent operators reaching acceptance | [ ] | [ ] | [ ] | [ ] | [ ] |
| Time to reuse | [ ] | [ ] | [ ] | [ ] | [ ] |
| Median cycle time | [ ] | [ ] | [ ] | [ ] | [ ] |
| First-pass acceptance | [ ] | [ ] | [ ] | [ ] | [ ] |
| Substantive rework | [ ] | [ ] | [ ] | [ ] | [ ] |
| Exception or switchback rate | [ ] | [ ] | [ ] | [ ] | [ ] |
| Review effort | [ ] | [ ] | [ ] | [ ] | [ ] |
| Tool and implementation cost | [ ] | [ ] | [ ] | [ ] | [ ] |
| Realised capacity or business measure | [ ] | [ ] | [ ] | [ ] | [ ] |
Control evidence
| Control field | Customer-approved value |
|---|---|
| Permitted data and source boundary | [ ] |
| Human-review rate and reviewer | [ ] |
| Exceptions, incidents and near misses | [ ] |
| Manual switchbacks and reasons | [ ] |
| Workflow owner, version and next review date | [ ] |
Customer perspective
"[Exact customer-approved quotation. Name, role, organisation.]"
What the evidence supports
[State the narrowest defensible conclusion. Distinguish observed task improvement, released capacity and attributed business value.]
Limitations
[State sample size, observation length, missing data, concurrent changes, selection effects, model or workflow changes, and what the comparison cannot establish.]
| Approval field | Value |
|---|---|
| Evidence reviewed by | [Name, role, date] |
| Customer approval | [Name, role, date] |
| Publication owner | [Name, date] |
| Links to source records | [Internal evidence locations for every published number] |
Answer-ready excerpts
What is AI adoption?
AI adoption is the repeated, authorised use of AI in a defined workflow by the people expected to run it, with evidence that it produces an acceptable result under agreed controls. Access, licences and training are inputs. Adoption becomes visible when use repeats in real work, the result meets a written standard and another operator can reproduce it.
How should an investment firm measure AI adoption?
Measure AI adoption one workflow at a time across five separate layers: access, behaviour, workflow use, outcome and control. Record who was eligible, who returned, how many accepted workflow runs used AI, what changed against a baseline, and whether quality and risk stayed inside the firm's limits. Report the numerator, denominator, observation window and evidence source for every rate.
Which AI adoption metrics matter most?
Useful metrics include authorised access, active and returning users, workflow penetration, repeat-run rate, independent reuse, median cycle time, first-pass acceptance, substantive rework, review effort, exception rate and realised capacity. The right set depends on the workflow. Licence counts and logins can describe readiness or activity, but they do not prove changed work or value on their own.
What is the difference between AI usage and AI adoption?
AI usage is an action, such as opening a tool or sending a prompt. AI adoption is repeated use inside a defined workflow that produces an accepted result under agreed controls. A person can use AI once without changing how the team works. Team adoption requires evidence that the behaviour repeats and the method can be reproduced by someone else.
How do you calculate AI ROI without overstating it?
Start with observed task outcomes, then build a conservative value bridge. Include realised capacity, attributable revenue contribution and evidenced loss avoidance. Subtract tool, implementation, review and remediation costs. Do not price every self-reported saved hour as cash. If capacity was released but not redeployed or removed, report the hours and name that limitation.
Why are licences and training not enough?
Licences show authorised access and training shows participation in an enablement activity. Both can be necessary. Neither shows that an operator returned, used AI in the intended workflow, produced accepted work, improved an outcome or stayed inside the control boundary. Treat them as the first layer of evidence, not the final result.
What is time to reuse?
Time to reuse is a proposed workflow diagnostic. Start the clock at the first accepted AI-assisted run and stop it when a second operator independently reaches the same acceptance standard. It is not a universal benchmark. It helps locate the friction between one person's successful method and a capability the team can reproduce.
Sources and methodology
The two opening figures use different populations and methods, which is why they should not be treated as directly comparable benchmarks. External numeric claims and evaluation guidance in this guide draw on:
- Bank of England and Financial Conduct Authority, Artificial intelligence in UK financial services, 21 November 2024. The survey received 118 responses from regulated financial-services firms; 75% of respondents said they were using AI.
- Department for Science, Innovation and Technology, AI Adoption Research, updated 13 February 2026. The weighted survey covered 3,500 UK businesses and reported 21% current use for the combined finance and real-estate sector.
- The Investment Association, Artificial Intelligence: Current and Future Usage within Investment Management, October 2024. Used for the sector's questions about productivity, time saved, additional work and cost savings, not as customer proof.
- Microsoft Learn, Connect to the Microsoft Copilot Dashboard for Microsoft 365 customers. Used as an example of active and returning-user definitions, not as a cross-vendor benchmark.
- NIST AI Risk Management Framework and Generative AI Profile. Used to support lifecycle measurement and the control layer.
- UK Government Evaluation Task Force, Guidance on the Impact Evaluation of AI Interventions. Used for the comparison and evaluation steps.
The five-layer evidence stack is a proposed synthesis, not an externally validated standard. Time to reuse is explicitly a diagnostic to test, not a benchmark. The case-study template is blank because the available evidence contains no named-customer adoption dataset, approved quotation or publishable before-and-after result.