BBVA's experience suggests that discovering employee AI use cases and making them useful elsewhere are different jobs. Give people a supported way to expose the work they want help with, then examine the particular task before widening its use. A large inventory can tell a sponsor where to look. It cannot establish which ideas deliver value or which another team can safely adopt.
For a bank's adoption leader, the useful question is what sits between an employee's promising experiment and an accepted service. BBVA's public accounts describe peer support, specialist review and a developing shared framework. Read those accounts with their dates and definitions attached, then ask what evidence your own receiving team would need. The wider roles and industries guide explains why the work and its consequences matter more than a department label.
Read the counts before drawing a scaling story
8,000+
active use cases reported by BBVA
In its April 30, 2026 talent account, BBVA also described around 700 cases as relevant for their potential and strategic importance. These are the bank's reported categories, not a count of independently validated returns.
The distinction in that finding matters. Being active, having strategic potential and producing an accepted business result describe different things. The account does not supply a common review threshold or a complete history showing how individual cases moved between those categories. Dividing the smaller count by the larger one would give an impressive-looking percentage without establishing a graduation rate.
An earlier OpenAI customer interview with BBVA, dated November 6, 2025, reported more than 20,000 custom GPTs created and around 4,000 frequently used. That is a supplier account involving bank leaders. Created assistants and frequent use are different units from the later use-case inventory. Subtracting the figures would not reveal how many unsuccessful ideas BBVA retired.
Before repeating a count in a steering meeting, resolve three questions:
- What was counted? A tool someone created, a person using it, a recurring task and a strategic opportunity can overlap without being interchangeable.
- When and for whom? Retain the publication date, population and period. Two snapshots may describe different access or organizational coverage.
- What decision does it support? An activity count can identify something to investigate. A decision to fund, maintain or widen a service needs evidence about that service.
Keep the original definition beside the number. If you cannot establish that two measures describe the same group and unit, present them separately rather than drawing a funnel between them.
Look for the work employees are trying to improve
BBVA's April talent account describes employee “wizards” who find uses, share practice and help colleagues bring AI into their work. The practical lesson is to listen to people who encounter a recurring difficulty. An adoption team can miss that difficulty when it starts with a catalogue of tool features.
A participant offers a related perspective. In an April 20, 2026 post, Toni Roldán Monés described more than a year and a half working with BBVA's global AI adoption team. He emphasized supporting advanced users and peer communities alongside leadership involvement. That is a collaborator's interpretation of the program, rather than an independent test of which intervention caused adoption. It still directs attention to a concrete question: can someone who finds a useful task get help making it understandable to colleagues?
Suppose Jamie Lee coordinates facilities requests in another bank's branches. Jamie repeatedly turns hurried notes about a counter printer's faults into maintenance tickets. An assistant might help draft a clearer ticket from the current asset record, the maintenance form and Jamie's observations. The useful discovery is the repeated rewriting and missing fault detail, rather than a general request to “use AI in branch operations.”

Ask Jamie to show the existing request and explain what the maintenance team sends back for clarification. That conversation reveals the input, accepted output and avoidable work. It also exposes a limit: a well-worded ticket cannot establish a fault the employee has not observed.
Keep this experiment to permitted equipment information. It has no need for customer records, access credentials or instructions for repairing secure equipment. Jamie's colleague checks the draft against the observations and current form before submitting it through the established facilities process. The banking assistance and consequential-decision guide examines why task boundaries need to remain explicit.
Give discoveries a route to specialist support
BBVA's January 2025 account of employee applications describes a global adoption team providing technical support, workshops and community activity. It also describes work with champions and advanced users to assess scaling potential, involving legal, compliance and information-security functions. Its proposed impact assessment included quality, time and economic effects, among other criteria. These are the bank's described arrangements and intentions at that date, rather than proof that every recorded case completed the same review.
For another organization, the important design question is where a local discovery goes next. A helpful colleague may know the task and the tool. That knowledge alone does not give them authority to approve new data access or a service used by other branches.
Jamie should be able to explain the proposed ticket-drafting task to the people responsible for it:
- The facilities owner checks that the draft contains what the maintenance process needs.
- The relevant data and security owners resolve whether the proposed information and tool are permitted for that use.
- The adoption or support team helps make the method understandable and identifies who will handle problems if others use it.
Those responsibilities may sit with different people in your bank. Name the actual owners and use the established review route. Asking a champion to endorse the whole proposal can conceal an unresolved permission or support decision.
Examine a specific application for its specific risks
BBVA's March 2026 internal-audit assistant account is more informative about review than an inventory total. The bank describes risks including incorrect analysis or code, unsuitable data, lost traceability and overreliance. It describes reproducible analysis, information for users and continuing review, while keeping validation and conclusions with auditors. Its productivity benefit is presented as expected, not an already demonstrated gain.
That specificity is useful. An auditor needs to examine the data, analytical steps and conclusions. Jamie's facilities colleague needs to check a different output against different sources. Copying an audit review process into a printer-ticket trial would not make it appropriate simply because both tasks use AI.
For Jamie's draft, the colleague has three concrete checks:
- The printer. Match the asset identifier to the current record.
- The fault. Trace every statement to an observation; remove invented diagnoses and repair promises.
- The destination. Confirm the request goes to the current maintenance provider.
Compare the whole task with the current method, including the colleague's checking and any ticket returned for clarification.
Review effort belongs in the result. A draft produced quickly may still be expensive to verify. If the assistant repeatedly invents technical detail, simpler form guidance or a better source record may solve more of the problem. The discovery remains useful even if an AI tool is not the eventual solution.
Test the receiving branch before widening use
BBVA's October 2026 shared-framework announcement describes work on a common environment for creating and governing agents, with shared components and processes. It discusses access, permitted actions, human oversight and continuing assessment. Read that as the bank's stated direction and work in progress. It does not show that every local experiment has already become a maintained group-wide service.
Another branch may recognize Jamie's problem while having a different asset register, maintenance provider or submission form. Reusing the idea is plausible. Reusing the first branch's contact details and assumptions without checking them could send an accurate-looking request to the wrong place.
Try the printer-ticket idea in a receiving branch
Observe its actual request
Use that branch's permitted asset record, current maintenance form and employee observations. Find what needs rewriting or clarification.
Check a draft against those inputs
Have the responsible colleague verify the printer, observed fault and destination. Remove diagnoses and promises the inputs do not support.
Decide whether to support another attempt
Review checking effort and the accepted request. Resolve changed access, provider and support needs before widening use.
The trial needs someone who can maintain its source material and respond when the form or provider changes. A shared prompt with nobody responsible for those changes can spread obsolete instructions faster than the original manual process.
The internal use-case library guide covers how to make a useful example findable and understandable. That record helps another colleague assess an idea; it does not replace the receiving team's review. If the trial lacks acceptable outputs or sustainable support, use the pilot stop, extend or scale guide to decide what happens next.
The public accounts discussed here do not disclose a complete retirement history for BBVA's use cases. Your own portfolio should still have a way to revisit an idea when its sources change, its review burden outweighs the help or its owner can no longer support it. Record that decision and tell affected users where to go. Otherwise, an old experiment can remain discoverable long after it has ceased to be useful.
Questions about learning from BBVA's employee AI use cases
Did BBVA validate more than 8,000 profitable AI use cases?
BBVA's April 2026 account reports more than 8,000 active use cases, with around 700 considered relevant for potential and strategic importance. Those descriptions do not establish that every case was profitable or passed an identical validation process. Retain the bank's definitions and ask for service-specific evidence before using either count to justify investment. The count interpretation explains why a conversion rate cannot be inferred.
Can created assistants and active use cases be compared directly?
Only if the definitions, population and period make the comparison valid. A created assistant can support several tasks, and several assistants can concern the same task. BBVA's differently dated supplier and bank accounts do not establish a single matched group moving through stages. Present the measures separately unless you can verify that relationship; do not label the difference as abandoned or failed work.
Should AI champions approve ideas for other teams?
Champions can help colleagues identify tasks and explain how an experiment works. Approval for new data access, consequential actions or a maintained shared service belongs with the responsible owners under the organization's review process. Give champions a clear support route and a defined role. The specialist-support section shows how to keep an employee's idea moving without assigning one person every responsibility.
What should another branch check before adopting an employee's idea?
A receiving branch should test the idea with its own permitted inputs, current process and accountable reviewer. Check that the output is acceptable and that source maintenance, access and problem handling have owners. In the printer-ticket example, a different maintenance provider changes where the request goes even if the drafting task looks familiar. Resolve those differences before widening use.
Does frequent use prove that an AI use case should scale?
Frequent use is a reason to investigate the task and the user's experience. A scaling decision also needs evidence about accepted outputs, complete effort, consequences and continuing support in the receiving setting. Compare those with the current method and retain a route to change or stop the use. A busy tool can remain difficult to check, and an infrequent task can still matter to the people responsible for it.



