AI literacy in banking: who to train, on what, and with what evidence

In short. In a bank, the AI literacy obligation under Article 4 and the competence requirements of ISO/IEC 42001 clause 7 meet a workforce already trained on other fronts, from anti-money laundering to MiFID II. AI training that works doesn't start from scratch, it builds onto those programs. Three roles are critical, those assessing creditworthiness, those exercising human oversight over models, and those approving adoption decisions, and for them the evidence has to be individual.

In financial services, mandatory training is a settled routine, with calendars, platforms and tracking that have existed for years. That's an advantage and at the same time the reason AI training often gets set up badly, added as a generic module inside a framework designed for something else.

Why the anti-money laundering model doesn't work here

AML training has a structure banks know well: content identical across role bands, periodic delivery, final test, tracking. Transferring that scheme onto AI produces a plan that holds the form and misses the substance.

The difference is that AML rules describe behaviours to follow, while AI requirements ask people to recognise when one specific system is producing an anomalous outcome. The first can be taught in the abstract, the second cannot. A module explaining what a machine learning model is doesn't put an analyst in a position to notice that a scoring system is treating two equivalent applications differently.

There's also a difference in perimeter. AML concerns whoever works on certain processes, while AI literacy concerns anyone using a system, including network advisors and staff at service companies working on your processes.

The three roles needing individual evidence

For most staff, awareness is enough: knowing what the tool they use does and who to report an anomaly to. Three roles are the exception, and for those the documentation has to be named and tied to the specific system.

Those assessing creditworthiness with model support. Credit scoring of natural persons is classified as high risk under Annex III of the AI Act, and anyone working on that process needs to read the output, recognise cases where the model sits outside its validity range, and know how to depart from the suggestion.

Those exercising human oversight. The competence obligation for these people was not touched by the Article 4 relief introduced by the Digital Omnibus. It remains in full, and their evidence has to show that the person was able to intervene on that system, not that they attended a course on AI in general.

Those approving a system's adoption. Management, the risk committee, whoever signs off on going live. A signature without understanding puts the decision-making process in question, and in an audit the finding travels from clause 7 up to clause 5 on leadership.

What to reuse and what to build

The existing training framework already covers part of the work, and mapping it is worth doing before buying anything new.

Element	Already present in a bank	What's missing for AI
Platform and tracking	Yes, well established	Link between evidence and specific system
Training on automated decisions	Partly, through GDPR	Extension to AI Act requirements
Model risk culture	Yes, within risk functions	Extension beyond risk functions
Effectiveness verification	Quiz-based tests	Practical cases on models in use
Perimeter extended to suppliers	Partial	Requirements in outsourcing contracts

The costliest row is the last one. Many banks outsource customer service, debt collection or parts of loan processing, and those people use AI systems on your processes without falling inside your training plans. The only instrument is the contract.

The module no vendor can write

The most useful part of AI training in a bank cannot be bought, because it requires information only you hold: which models are in production, which decisions they affect, which edge cases have already been observed, who to report anomalous behaviour to and what happens next.

Thirty or forty minutes per system, prepared by whoever knows that system, worth more than four hours on the structure of the regulation. It's also the material that, in an inspection or in litigation, shows human oversight genuinely existed.

What an auditor asks an analyst

During a verification the sample follows precise criteria: it starts from the role matrix and picks people working on the most exposed systems, recent joiners, and whoever signed approvals.

The questions are simple and nearly always the same. What does the system you use every day do. How would you notice it getting something wrong. What do you do if it happens. Who do you report it to. When no answer comes, the finding concerns the management system that delivered training without verifying its effectiveness, not the person.

Where to start

The starting point isn't the course catalogue, it's the AI system inventory, because without knowing which systems are in use and on which processes, training calibrated to context stays calibrated to an idea of the context.

From there you build the matrix linking roles to competences, separate what's needed as awareness from what's needed as verifiable competence, and decide for which roles the evidence has to be individual. The full requirements are in clause 7 explained without jargon, and the relationship between the two obligations in AI literacy and ISO 42001 competence.

The sector's regulatory context, with the full map of overlapping rules, is on the AI governance for banks and financial services page.

Our approach to building role-based tracks is described on the AI Training page. To assess what your bank's plan is missing, you can book an assessment meeting.