AI Governance for Banking

AI governance for a Saudi bank should define how AI influences customer treatment, financial decisions and operational actions, then place those functions within the bank's existing authority and control arrangements. A system that prepares a collections call is different from one that changes repayment terms or restricts an account. The governance record must preserve that difference.

This guide is for banking operations, risk, compliance, technology and executive sponsors. It uses an illustrative consumer-collections assistant to show how an apparently administrative use can become consequential through ranking, drafting and workflow design. The proposed controls are operating-design guidance; the bank's specialists determine applicable SAMA and other requirements.

Locate the AI function within the bank's control environment

Identify the business process, accountable executive, operational owner and existing control functions before creating a separate AI committee. The bank needs a route that connects AI decisions to established risk, compliance, information-security and technology governance.

SAMA's IT Governance Framework announcement identifies its regulated institutional scope, including local banks. The AI programme should assess the applicable current framework and other relevant instructions rather than assuming that an AI policy replaces them.

Map the exact activity: preparing a contact summary, prioritising work, recommending a response, sending a message or executing an account action. Each can require a different authority and evidence. A single inventory entry called collections AI hides important differences.

The AI inventory should connect those functions to the systems, data, suppliers and decisions they affect. Record which parts are advisory and which can alter a customer's position.

Separate customer-service assistance from financial authority

For a collections assistant, define what staff may rely on. A generated summary can help locate relevant information, but the authorised process must confirm account status, current arrangements and the appropriate next action. The model should not invent a promise, deadline or consequence.

Call prioritisation also deserves review. Moving a case to the top of a queue changes the attention it receives; repeatedly placing another case at the bottom can delay help. Assess that influence even where the system does not directly approve or refuse a financial product.

Keep restructuring, settlement, deductions, account restrictions and other consequential actions within the bank's applicable authority and procedures. Do not infer permission to perform those actions from approval to draft an outreach message.

The AI approval route should state the boundary in operational terms, including which interfaces remain unavailable to the assistant and which decisions require qualified staff.

Use current collections rules as an applicability input

The SAMA Debt Collection Regulations and Procedures published in March 2025 address banks and finance companies within their defined creditor and individual-consumer scope. They include responsibilities for conduct by employees and third parties. The bank should map the current applicable provisions into its actual collections process.

A general AI risk label is not a substitute for that mapping. Compliance specialists should identify relevant contact, treatment, deduction, record and oversight conditions. The design team then demonstrates how the AI-supported process respects those conditions.

Preserve scope distinctions. An example concerning individual consumers should not be presented as a complete guide to corporate recoveries, investment services or every financial institution. Different activities can involve different rules and authorities.

Use a maintained obligation-to-control record so changes in regulatory instructions reach scripts, queue logic, staff training and supplier configuration. A legal update that remains in an email does not change the customer experience.

Worked example: outreach preparation and hardship routing

Consider an illustrative bank proposing an assistant that summarises permitted account information and drafts a call preparation note. It may identify that a case needs review by the bank's specialist support team, but it does not determine eligibility for revised terms or make an account change.

The bank prepares 36 synthetic challenge cases: ten with a payment posted after an earlier extract, eight involving an unresolved dispute, seven requiring specialist review of changed circumstances, six with an incorrect contact association and five with a recent contact already recorded. The categories are distinct for this exercise and are not a prevalence estimate.

The expected handling differs. A stale payment snapshot should trigger current-status verification. An unresolved dispute should follow the approved dispute route. Changed circumstances should reach the appropriate specialist without the model making an unsupported personal inference. An incorrect contact association should stop that proposed communication.

The five recently contacted cases test whether the assistant uses current contact history and the bank's applicable contact controls. The exercise does not invent a universal contact-frequency rule; it tests the institution's approved rules and the current regulatory conditions relevant to them.

Illustrative decision boundaries in collections assistance

AI output	Required human or system check	Authority retained
Draft account summary	Verify current balance and relevant arrangement from authoritative records	Approved servicing process
Suggested contact priority	Check dispute, recent contact and specialist-routing conditions	Collections operations owner
Possible changed circumstances	Review the customer's actual information through the appropriate specialist route	Authorised customer-support decision
Suggested repayment change	Outside the assistant's permitted scope	Bank's existing delegated financial authority

Prevent stale or inferred facts from becoming customer statements

Separate source time, event time and the time the note is generated. A payment received after a snapshot can make an otherwise accurate summary misleading at the point of contact. Identify the facts that require a fresh system check immediately before use.

Preserve the difference between customer statements, staff observations and verified account events. The assistant should not turn “customer says a payment was made” into “payment confirmed”, or a tentative note about difficulty into a formal classification.

Require source references for material statements and an explicit unknown state. Where evidence conflicts, the draft should direct staff to resolve it through the approved process. Filling gaps with a plausible narrative creates a false record that can influence later decisions.

Protect the source record from accidental writeback. If the assistant can draft a note for review, distinguish draft storage from an authorised update to the customer's official history. Record the reviewer and accepted version where the process permits an update.

Design meaningful challenge by risk and compliance

Give control functions enough information to challenge the proposal: purpose, decision influence, data, population, supplier, evaluation and operating fallback. A demo showing fluent conversation does not establish appropriate customer treatment.

Review how the system handles difficult cases, not only routine accounts. Include complaints, uncertain identity, changed circumstances, language variation and stale records where relevant. Define what evidence would require a narrower scope or a pause.

Maintain independence appropriate to the bank's governance arrangements. The team promoting the benefit should not be the only party judging whether significant conditions have been met. Record differences of view and the authority that resolves them.

The AI impact assessment can organise potential consequences for customers and operations. Its findings should affect queue design, review responsibilities and access, rather than remain a document attached after approval.

Evaluate treatment quality alongside efficiency

Measure whether staff receive accurate, actionable preparation and whether the workflow respects the bank's customer-treatment controls. Track inappropriate contact proposals, missed specialist routing, incorrect account statements and review overrides alongside time saved.

Examine who experiences the errors. Language, channel, documentation quality and customer circumstances can affect how a system performs. Use an evaluation design suited to the task and have specialists decide which comparisons are meaningful and lawful.

Do not treat a small challenge set as proof of fairness across the portfolio. It can reveal specific failure modes and guide further evaluation. Report the sample construction, limitations and unresolved cases so decision-makers understand the evidence.

Review the human response too. If staff routinely accept polished drafts without checking current records, the operating control is weaker than its written description. Training and interface changes may be needed alongside model adjustments.

Control supplier and service access

Map the bank's data flow through source systems, retrieval, model calls, drafts, logs and support. Identify the identity and purpose at each step. A service that only needs selected account fields should not receive unrestricted customer history by default.

Review the actual supplier arrangement, including processing locations, subcontractors, retention, support access and change notice. Determine relevant regulatory and contractual conditions through the bank's established specialist processes. Avoid asserting that one cloud region or a vendor certificate settles the full question.

Use third-party AI risk questions to obtain service-specific evidence and record unknowns. The bank should know what it can investigate if a draft contains another customer's information or an unauthorised account action is attempted.

Trusted Data's financial-services AI overview provides wider implementation context. Any particular solution still needs the bank's own purpose, supplier and control assessment.

Make action boundaries technically enforceable

Align the assistant's available interfaces with its approved role. A drafting service should not receive credentials capable of changing repayment terms merely because a future feature might use them. Separate read access, draft creation and authorised execution.

If later scope includes sending communications or updating records, review the exact action, required approval, duplicate prevention and reconciliation. A successful model response is not proof that the action occurred correctly or only once.

Test denial cases using controlled environments. An instruction inside a customer message should not become authority to call another system. The service should enforce its permissions independently of generated text.

The agentic AI governance guide explains the additional decisions needed when a system gains tool access. Approval for summarisation should not silently expand into operational autonomy.

Prepare incident handling around customer consequences

Define responses to wrong-party communication, unsupported statements, exposed information, repeated contact proposals or unauthorised actions. Preserve the source and generated versions, timing and affected recipients under the bank's evidence-handling rules.

Connect operations, compliance, privacy, security and the responsible business owner. Each may need a different decision from the same incident. The AI incident response plan should identify how they coordinate and who can stop the affected function.

Provide a fallback to the established servicing process. Staff should be able to handle customer matters while the AI component is restricted. Pending drafts should remain clearly distinguished from approved communications.

Restart should depend on verified correction and appropriate retesting. Where the cause is an overbroad purpose, weak access or ineffective human review, changing the prompt alone will not close the issue.

Reconcile a specialist referral with the next customer interaction

In the collections-preparation example, routing a case to a specialist is not the same as the specialist accepting responsibility. Define the transition: the reason for referral, the information authorised for transfer, the receiving queue, acknowledgement and the owner while acceptance is pending. Otherwise a customer can be contacted again by the original workflow while a sensitive matter remains unresolved elsewhere.

Use a case state that reflects confirmed facts. “Referral requested” should not be presented to staff as “specialist review completed”. If a customer provides new information before acceptance, the workflow needs a defined route for updating the case and reconsidering the proposed contact. The responsible bank process determines whether to proceed, pause or use another service route.

Test a handover where a recently posted payment and a specialist referral arrive in different orders. The assistant should present the current authoritative state to the reviewer and preserve the reason for any pending action. It should not independently decide the financial treatment or repeat a communication simply because an earlier draft exists. The exercise verifies coordination between records and authorised processes.

Give unresolved referrals an operational owner and a visibility rule. A dashboard should distinguish newly submitted, accepted, returned for clarification and closed cases. Track aging using the bank's defined service expectations and applicable requirements. Do not invent a universal deadline for every bank, product and customer circumstance; the governance task is to ensure the actual requirement is understood and operated.

Include closure evidence from the receiving process. A referral is complete when the required handoff and subsequent decision are recorded according to that process, not when the AI has produced a plausible summary. If the receiving team rejects a referral as inappropriate, return the reason to the source workflow so the same type of case is not repeatedly sent to the wrong destination.

Review what the customer would understand from the draft

Ask a reviewer to read the proposed communication without the internal notes. Can they distinguish a factual account statement, a request for information, an available service route and an authorised decision? The message should not imply that an arrangement is agreed when staff have merely proposed a discussion, or that an issue has been resolved when a specialist has not yet reviewed it.

Check Arabic wording for the strength of commitment and the reason for contact. A courteous paraphrase can inadvertently turn a conditional possibility into a promise. Conversely, a terse translation may make an information request sound like a final adverse decision. Use the bank's approved language and have the relevant business and compliance owners review difficult examples.

Preserve meaningful customer explanations when summarising. If the customer disputes the account, reports a change in circumstances or asks for a particular review route, the draft should not reduce the interaction to a generic “unwilling to pay” label. The source and the customer's stated position should remain distinguishable from the assistant's interpretation, so the next authorised reviewer can assess the matter on its actual facts.

Use this communication review as a release gate for a changed template or summarisation rule. The business owner should see the before-and-after wording, the reason for the change and representative difficult cases. Record whether it changes only expression or also the apparent commitment, account status or next action. A text update can have an operational consequence even without a new system permission.

Keep oversight linked to the bank's actual exposure

Report the deployed scope, customer influence, open conditions, incidents and material changes. Separate model-performance signals from control failures and customer-treatment concerns. Executives need to know which decision each issue requires.

Review whether priority logic changes contact distribution or specialist workload. A system may improve average handling time while shifting difficult cases into an unstaffed queue. That is an operating consequence requiring governance, even if the model performs its narrow task correctly.

Maintain the relationship between approved scope and actual configuration. New channels, customer segments or account actions should trigger review before expansion. Use executive reporting to show unresolved dependencies and who owns them.

For AI governance setup, prepare the servicing workflow, delegations, applicable control requirements and a few representative case histories. Discuss AI governance setup for banking with Open for AI to connect the bank's decision authority to evidence, supplier controls and operating procedures. The bank's accountable teams remain responsible for the regulatory and customer decisions.