Bank AI Assistants: A Practical Productivity Scorecard

An AI licence is not a productivity gain. That gap is the most useful message for banks in the latest ECB blog on workplace AI adoption. The share of workers reporting that they use AI at work rose from 26% in 2024 to 41% in 2025 and 52% in 2026. But reach, time saved and economic productivity are different measures. A bank rolling out an AI assistant therefore needs a measurement system that follows the path from access to a verified operational result.

The ECB findings are a useful reference point, not a banking benchmark. They come from survey responses by workers in 11 euro area countries, not measured process data from financial institutions. Usage and time savings are self-reported. They may reflect perceptions, different task mixes and estimation error. Banks should not copy these figures into a business case or treat them as evidence of their own productivity.

Adoption is not deployment

The rise in reported use shows how quickly AI is entering everyday work. It does not reveal whether an institution has issued licences, whether employees use public tools independently, or whether an assistant is embedded in a controlled process. In March, the ECB’s speech on AI and the euro area economy noted that most firms still use AI only moderately or infrequently. Access does not amount to integration into production, service and organisational processes.

A banking programme should therefore separate at least three levels:

1. Deployment: Who has technically and legally permitted access?

2. Adoption: Who uses the assistant in practice and returns to it?

3. Integration: In which defined workflow step does it produce an auditable result?

This distinction prevents a familiar reporting error. A large number of activated accounts can coexist with little process impact. Conversely, a narrowly scoped assistant inside a high-volume workflow may matter more than a widely available tool with no workflow connection.

A measurement chain for banking assistants

A useful scorecard does not start with “productivity”. It begins with a chain of observable measures. Each stage answers a different management question.

Usage. Track eligible users, active users, frequency and return rate. Analyse results by role, team and approved use case, rather than using them for individual performance monitoring. Usage shows reach, not value.

Eligible-task coverage. The denominator should not be total working time. It should be the set of tasks previously defined as suitable and permitted for the assistant. For a research aid, the measure could be the share of eligible cases with documented use. For a summarisation assistant, it could be the share of approved document types processed. This reveals whether low use reflects limited need, weak integration or unclear rules.

Verified time saved. In the ECB survey, the median AI user reports saving three hours a week, equal to 7.7% of median working time. That is a self-reported, user-level estimate. Only 48.8% of all workers reported both using AI and saving time; the article derives an economy-wide efficiency estimate of about 3.8%. Even that figure is not automatically additional output, because the released capacity may be used in other ways (ECB).

A bank should test time against a baseline: the same task category, comparable complexity, defined start and end points, and a sufficient observation period. System timestamps can show cycle time; samples and short user prompts can explain why it changed. Measured acceleration counts only after waiting time, extra controls and downstream corrections are included.

Quality and rework. Faster is not better if drafts need more correction. Each use case needs a small set of business criteria: completeness, factual accuracy, source support, compliance with templates and clarity. Relevant measures include first-pass acceptance, correction rate and minutes of rework. Customer-facing material should receive risk-based review by accountable subject-matter experts.

Risk incidents. A productivity dashboard without a risk view is incomplete for a bank. The taxonomy might include prohibited data entry, unsupported statements, communication-policy breaches, access-control failures and outputs that had to be withdrawn. Compliance, information security, privacy and model-risk teams should agree the definitions. A low incident count means little without usage volume and a known reporting route.

Human handoffs. An assistant may accelerate work by preparing a case correctly; it may also merely move effort elsewhere. Measure the handoff rate, reason for escalation, completeness of transferred context and handling time after transfer. The relevant unit is the whole case journey, not the model’s response time.

Training. Around half of the workers in the ECB article identify better training and a better understanding of usefulness as factors that would encourage adoption. Completion rates alone are therefore weak evidence. Banks should assess whether staff can recognise permitted tasks, structure inputs, check outputs and escalate uncertainty. Short practical exercises and subsequent quality data are more informative than the number of completed learning modules (ECB).

Turn metrics into a controlled experiment

Before launch, each use case should have a measurement card: target process, eligible tasks, excluded data and decisions, baseline, quality criteria, accountable role and stop thresholds. A pilot can then be compared with a suitable earlier period or control group. Where a controlled comparison is not practical, the institution should at least document task mix and volume before and after introduction.

Keep the denominator stable. “20% faster handling” means little without the case type, quality level and rework. Averages can also mislead when a small number of large gains shape the distribution. The ECB blog explicitly describes the distribution of reported time savings as highly skewed. For a banking process, the median, dispersion and share of cases with no improvement may be more useful than a single mean (ECB).

Reporting should also distinguish the learning phase from steady-state operations. Early on, usage and training may dominate. Later, quality stability, rework, risk incidents and end-to-end cycle time should carry more weight. A use case should not scale merely because people like using it. It should scale when performance and control remain stable over several periods.

Design workflow integration and governance together

The ECB’s March speech describes productivity gains as dependent on organisational restructuring, skills, infrastructure and other complementary investment. In a bank, the assistant should therefore operate where context, permissions, templates, approval and the audit trail meet. Copying content between a separate chat and core systems creates breaks in the process, raises data-handling risks and makes measurement harder.

Governance is not a control block added at the end. It defines which tasks belong in the eligible-coverage denominator, when human review is mandatory, which data may be processed and which events trigger a stop. Those same decisions make productivity measures comparable. Without stable process and risk boundaries, a dashboard measures changing work rather than impact.

The management question is therefore not, “How many employees have the assistant?” It is, “At which permitted workflow step does it demonstrably improve time or quality without increasing rework, risk or handoff cost?” Answering that question for each use case allows a bank to prioritise investment, improve training and retire weak applications. That is how deployment becomes controlled, measurable adoption.

Illustration: AI-generated. AI-assisted content: We use AI technologies and automated agents in the creation of our articles, including from Microsoft, Google, OpenAI, Anthropic and other providers. Topics, editorial direction and final approval remain with our team.