Who Counts as All Staff for AI Training?

Every financial services firm rolling out AI literacy training eventually faces the same question: who exactly counts as "all staff"?

It sounds like a simple scoping exercise, but get it wrong and the consequences are significant. Too narrow a definition leaves large parts of the business without the awareness they need to use AI tools safely or spot AI-related risks in their daily work. Too vague a definition makes the programme difficult to govern or evidence.

Under increasing regulatory attention — including the expectations set out in the UK's AI Skills Compact — firms are being asked to demonstrate that their entire workforce, not just technical teams, understands AI risks and opportunities.

This article explains how to think about "all staff" in practical terms, so training programmes are scoped correctly from the outset rather than defaulting to whoever happens to build or directly operate the AI tools.

Why Scoping "All Staff" Correctly Matters

When a firm introduces an AI-enabled tool — a lending decision engine, a claims triage system, a trading signal generator — the natural instinct is to train the people who build it and the people who operate it directly.

That instinct is understandable, but it is incomplete.

Regulators and government policy, including the AI Compact, are increasingly framing AI literacy as a firm-wide capability rather than a specialist skill confined to data science or IT. The underlying logic is straightforward: AI-driven outcomes affect far more people than those who design or operate the systems producing them.

A customer service representative explaining a declined loan application, a compliance officer monitoring for unfair outcomes, and a branch manager handling a complaint are all dealing with the consequences of an AI-driven decision — even though none of them touch the underlying model.

If training scope is defined too narrowly, these groups are left without the baseline understanding they need to do their jobs responsibly. That creates a governance gap that is increasingly visible to regulators, auditors and, ultimately, customers.

How Firms Have Traditionally Scoped Training Populations

Historically, technology training in financial services has followed a simple rule: train the people who use the system.

When a new trading platform, policy administration system or case management tool was introduced, training was limited to the direct users — typically a defined operational team. This approach worked well for tools with contained, predictable use.

AI-enabled tools behave differently. Their outputs ripple outward into customer conversations, compliance monitoring, complaints handling and senior management reporting, often well beyond the team that operates the system day to day.

Applying the traditional "train the direct users" rule to AI tools tends to produce a training population that is far too narrow: usually the technology or data team that built the tool, and perhaps the immediate operational team that uses it. Everyone else affected by its outputs is left out.

This narrower approach is not wrong so much as outdated. It made sense when technology tools had limited, contained effects. It does not reflect how AI-driven decisions now propagate through an organisation.

Where a Broader, Role-Based View Helps

A more defensible way to scope "all staff" is to ask a different question: who is exposed to AI tools or AI-influenced decisions, in any capacity?

This reframes scope around exposure rather than department or job title, and it tends to surface several groups that are commonly missed:

• Customer-facing staff who explain, justify or discuss AI-influenced decisions with customers, even if they never operate the underlying system.
• Operations teams who process outputs from AI tools, such as flagged transactions or triaged cases.
• Compliance and risk functions responsible for monitoring AI-driven outcomes for fairness, bias or regulatory breaches.
• Complaints and customer service teams who handle the fallout when an AI-influenced decision is challenged.
• Senior management and board members, who hold oversight responsibility for AI-related risk even though they do not use the tools directly.

None of these groups need the same depth of technical training as the team that built the tool. But all of them need enough understanding to recognise what the tool can and cannot do, where its limitations lie, and when to escalate a concern.

Thinking in terms of exposure rather than department produces a training population that is both broader and more defensible than one built around job titles alone.

Practical Considerations When Defining Your Population

Once exposure is accepted as the guiding principle, several practical questions follow.

Contractors and third parties. Anyone with access to AI-enabled systems, or whose work depends on outputs from those systems, should be assessed for inclusion — not automatically excluded because of their employment status. The relevant question is exposure and risk, not contract type.

Part-time and temporary staff. The same logic applies. If a part-time customer service adviser handles AI-influenced decisions, their limited hours do not reduce their exposure to the associated risks.

Senior leadership and the board. Oversight responsibility does not disappear simply because a director does not use the AI tool personally. Leadership needs a level of literacy sufficient to ask the right questions and challenge assumptions, even if the content differs from operational training.

Documentation and review. Scope decisions should be written down, along with the reasoning behind them, and revisited as AI tool adoption spreads. A population that was correctly scoped for one AI tool may be incomplete once a second or third tool is introduced elsewhere in the business.

There is no single universal answer to who counts as "all staff" — it depends on how and where AI is used across a particular organisation. What matters is that the reasoning is risk-based, exposure-based, and consistently applied, rather than defaulting to whichever team happens to be most visible during implementation.

Example

A London-based retail bank is rolling out an AI literacy programme after introducing an AI-assisted lending decision tool.

Initially, the L&D team plans training only for the data science team that built the tool and the underwriters who use it directly.

During a governance review, it becomes clear that customer service staff explaining lending decisions to applicants, compliance staff monitoring fair lending outcomes, and branch managers fielding customer complaints all interact with the consequences of the AI tool's decisions, even though they never touch the system directly.

The bank revises its training scope to include customer service, compliance, branch management, and senior leadership alongside the original technical audience, ensuring that anyone affected by or responsible for explaining AI-driven decisions has a baseline understanding of how the tool works and its limitations.

FAQs

• Does "all staff" include part-time or temporary employees?

  Yes, in principle. Inclusion should be based on their exposure to AI-enabled tools or decisions, not their employment status, though the depth and format of training may vary depending on their role.

• Do senior executives and board members need AI training too?

  Yes. They carry oversight and governance responsibility for AI-related risk, so their training needs differ in content and depth from operational staff, but not in necessity.

• Should contractors and third-party staff be included in AI training?

  It depends on their level of access to AI-enabled systems and decisions. Firms should assess this on a risk basis rather than excluding contractors or third parties by default.