A role-based programme to activate a retail bank's idle AI licences

Context

A regulated retail bank had already paid for generative AI. It held enterprise licences for the AI assistants built into its office productivity software. The premise of the engagement was that those licences were going largely unused. Access was not the obstacle. Staff could open the assistants; they could not see how to apply them to the specific work of their own role.

The pattern is common. Buying licences or running a generic course does not change how work gets done. The engagement was a programme to connect licences the bank already held to consistent, safe use in everyday work.

The challenge

Idle licences in a bank carry two costs. The first is plain: spend that produces nothing. The second is a control problem. Staff who get no help from the sanctioned tools may turn to unsanctioned ones, and bank information then leaves the environment the bank governs.

A standard course was the wrong answer for two reasons. Tasks differ by function: what helps a customer-facing team is not what helps a control function. And they differ by level of responsibility: a director has to govern use, an analyst has to do the work.

One constraint outranked the rest: the bank's own information-handling rules. Any use we taught had to be one the bank could defend under scrutiny, with protected information, traceable outputs and a person accountable for every result.

Our approach

We worked from the task outwards. The first question in each area was which real business, operations and control tasks consume time, not which features the software offers.

1. 1Diagnose friction on real tasksWhere day-to-day work gets stuck, and which of those tasks the licensed assistants can properly support.
2. 2Set routes by role and responsibilityAdoption routes segmented by function and level of responsibility, so each group works on uses that matter to its job.
3. 3Teach through hands-on workshopsPractical workshops combined our own case material with content from four vendor learning tracks.
4. 4Work inside the licensed toolsEach use case was set up and practised in the corporate tools staff already had, so the work stayed in the environment the bank governs.
5. 5Put governance in the curriculumInformation protection, traceability and human review taught within every use, and as a use-case family of their own, not as a closing compliance slide.

The programme ran as two workstreams: activating the technology asset (friction diagnosis, role-based routes, the case for using licences already bought), and practical workshops with governance.

What was built

The output was not software of ours. It was six families of applied use, set up in the bank's corporate tools, with the routes and rules that go with them.

• Research and document analysis. Extracting and summarising case files, contracts and complex regulation.
• Data analysis and reporting. Natural-language questions over spreadsheets and operational data, in support of reporting.
• Meeting preparation and minutes. Executive summaries, minutes and a record of what each committee agreed and who owns it.
• Drafting and official communication. First drafts aligned to the bank's tone, rigour and guidelines, for a person to finish and sign.
• Specialised agents. Designing agents dedicated to the frequent queries of front-line and back-office teams.
• Governance and human supervision. Information protection, no shadow IT, traceability and human validation, taught as working practice.

Four of the six are everyday assistive tasks, deliberately unglamorous. The fifth moves people from using an assistant to designing one. The sixth is what makes the other five acceptable in a regulated firm.

The four vendor learning tracks were teaching material: using them is not a claim of partnership with any vendor, or of certifications held by us.

Results

What we can state is scope: six families of use set up in the tools staff work in, routes defined by function and level of responsibility, and governance taught with each use. These come from the programme design, not from measurements of behaviour.

What we do not state is a number for the outcome. The economic logic is simple: the licences were already paid for, so any productive use improves their return. Logic is not measurement, and we will not dress it as one.

Nor do we offer evidence on usage. That the licences sat idle is how the engagement was framed, not a baseline we publish, and we make no claim about how use held up after handover. The right test is licence-activity data from the tools' admin consoles, by role, before the programme and some months after it.

Governance and risk

Shadow IT grows where sanctioned tools are not useful. Making the approved assistants useful for real tasks, and teaching which information may go into them, removes most of the reason to look elsewhere. A usage policy supports that control; it does not replace it.

Four working rules ran through every use case. Protected information stays inside the bank's licensed environment. Unsanctioned tools are not used for bank work. An output must be traceable to the material it rests on. A person reviews every output and remains accountable for it: the assistant drafts, it does not decide.

Scope was a control in itself. As designed, none of the six families takes a decision about a customer, a credit or a regulated control. They prepare material for the people who do. Customer-facing or decision-making use would be a different engagement, with its own risk assessment.

There are trade-offs. Role-based routes cost more to prepare than a single course. And a programme built on vendor assistants inherits the pace of vendor releases: the guidance needs an owner inside the bank who keeps it current after the consultants leave.

What we learned

• Idle AI licences are rarely an access problem. The usual gap is that nobody has shown people, on their own tasks, what the tool does for their job.
• In a regulated firm, useful sanctioned tools are the practical control against shadow IT. A policy with no usable alternative does not hold.
• Judge adoption work on licence-activity data by role, before and after. Where a supplier shows none, as we do not here, treat usage as unproven.

Client identity, locations and identifying details are withheld under confidentiality. Figures are rounded. Measured figures come from engagement records; client-reported figures are attributed, not audited; modelled figures are projections from the engagement's business case and are labelled as such.