How Is AI Literacy Embedded in Control Processes?

Every risk and compliance function eventually faces the same question: how do we make sure AI awareness doesn't fade after the training session ends?

Financial services firms are increasingly using AI in decision-support and operational tools across trading, underwriting, client servicing and settlement. Regulators and government initiatives, including the AI Skills Compact, now expect firms to identify and monitor AI-related risks as routine business as usual - not as a one-off project.

Training builds initial awareness. But awareness on its own does not persist. Without a permanent home in day-to-day control activity, AI literacy risks becoming something people learned once, rather than something the organisation actually does.

That permanent home is the control framework itself - the RCSAs, monitoring plans, testing scripts and assurance reviews that risk and compliance teams already run. Embedding AI literacy there is what turns a training outcome into an operational habit.

Why training alone is not enough

Standalone AI training sessions are useful for building initial understanding. They explain what AI is, where it is used across the organisation, and what risks it can introduce.

But training has a natural half-life. Without reinforcement, people forget detail, priorities shift, and new starters miss the session entirely. Meanwhile, the AI tools in use across the business keep changing - new use cases appear, existing tools are updated, and risk profiles shift accordingly.

If AI literacy exists only as a training record, it cannot keep pace with that rate of change. It also has no natural trigger for renewal - nothing forces anyone to revisit it until the next scheduled course.

Control processes do not have this problem. They already run on a cadence. They already have owners. They already require evidence. Embedding AI literacy into them means AI-related risk consideration inherits that same discipline, rather than depending on memory or goodwill.

How firms have traditionally updated controls for emerging risks

This is not a new problem. Firms have faced it before with cyber risk, conduct risk and financial crime.

The traditional approach follows a familiar pattern:

• A risk taxonomy is reviewed and updated to include the new risk category.
• Control libraries are revised so that relevant controls reference the new risk.
• RCSA templates and testing scripts are amended to prompt for it explicitly.
• Control owners are briefed on what has changed and why.
• The updated framework is rolled into the next assessment cycle.

This works well for risks that evolve at a measured pace, where an annual or semi-annual review cycle is sufficient to keep documentation current.

AI-related risk does not always behave this way. New tools and use cases can appear between review cycles. A desk might adopt an AI-assisted tool mid-year, well before the next scheduled RCSA refresh. Applying the traditional cadence unmodified risks leaving control documentation permanently a step behind actual AI use.

Where AI-assisted tools can help

This is where AI-assisted tools genuinely help risk and compliance teams - not by deciding what belongs in a control, but by reducing the manual effort of finding where controls need attention.

AI tools can scan existing control libraries, RCSAs and testing scripts to identify:

• Controls that reference systems or processes now known to use AI, but have not been updated to reflect it.
• Testing scripts that lack any prompt for AI-related exceptions, overrides or anomalies.
• Inconsistencies where similar controls across different desks or business units have been updated at different times or to different standards.

This turns a large manual document review exercise into a manageable set of flagged gaps for human attention.

Crucially, the tool identifies candidates for review. It does not decide what the control should say, how a testing script should be worded, or what an acceptable override rate looks like. Those remain judgement calls for risk and compliance professionals, informed by their understanding of the business and its risk appetite.

Keeping control owners literate enough to apply the change

Updating a testing script to ask about AI-flagged exceptions only works if the control owner completing that test understands what a reasonable answer looks like.

This is why embedding AI literacy into controls and training AI literacy in the first place are connected but distinct activities. Training builds the baseline understanding. Embedding gives that understanding a recurring task to be applied to. Without both, either the control prompt goes unanswered meaningfully, or the training knowledge has nowhere regular to be exercised.

Example

A London-based bond trading desk introduces an AI-assisted trade reconciliation tool that flags likely mismatches before human review.

The second-line risk team updates the desk's existing RCSA and monitoring plan to include specific prompts about AI-flagged exceptions, override rates and model drift. Control testing scripts are revised to ask not just whether reconciliation occurred, but whether traders appropriately scrutinised AI-flagged items before clearing them.

Within a few testing cycles, this updated control surfaces a pattern: several traders were clearing AI-flagged exceptions without independent checks, effectively rubber-stamping the tool's output. This prompts targeted retraining and a revision of desk-level escalation thresholds.

The risk was caught not by the original training programme, but by the control itself - because AI-related considerations had been built into what the control was designed to test.

FAQs

• Is embedding AI literacy in controls the same as AI model risk management?

  No. Embedding AI literacy into controls is about making sure people and processes routinely consider AI-related risks as part of everyday control activity, such as RCSAs and testing scripts. AI model risk management is a separate, more technical discipline concerned with validating the AI models themselves. The two are related but address different problems.

• How often should embedded AI-related controls be reviewed?

  More frequently than a traditional annual RCSA cycle typically allows. Because AI tools and use cases can change between scheduled review dates, many firms link review triggers to specific events - such as the introduction of a new AI tool or a material change to an existing one - rather than relying solely on the standard assessment calendar.

• Do control owners need to become AI experts to apply these updated controls?

  No. Control owners need working AI literacy proportional to their role, not deep technical expertise. This means understanding enough to recognise AI-related risks, ask sensible questions and apply judgement to AI-assisted outputs. That literacy is reinforced through the embedded control activity itself, not through separate technical training.