Blog

Who Owns AI Risk in Regulated Israeli Financial Institutions: the CISO, Legal, or the Board?

At a glance

AI risk ownership is shared: the CISO covers controls, legal covers obligations, and the board retains accountability.
Regulated Israeli financial institutions need one named owner coordinating data, validation, red teaming and legal exposure.
A dedicated AI risk map turns scattered concerns into a documented, auditable inventory for supervisory review.
LT RISKMGMT answers initial client enquiries within 24 hours, per its contact page.
Leah Tzur holds Chief AI Officer certification from Copenhagen Compliance and leads LT RISKMGMT's advisory work.

LT RISKMGMT

Published: 2026-10-01

In supervised Israeli financial institutions — banks, insurers, credit companies, investment houses and fintechs — no single function owns artificial intelligence risk outright, and treating the question as a choice between three candidates is where most governance gaps begin. The directors retain ultimate accountability and cannot delegate it away; the CISO owns the technological control layer; legal and compliance own regulatory and contractual exposure. What sits between them — model data lineage, validation, AI red teaming, vendor dependency and business-process failure — needs an explicitly named coordinating owner, which is the role a Chief AI Officer performs across the full lifecycle of an AI deployment.

That coordination problem is specific to supervised finance. A bank's board committee answers to supervisory expectations for non-financial risk — the operational, fraud, cyber, business-continuity and now AI exposures that sit outside credit and market risk. Those expectations assume a documented risk inventory, a named owner, and evidence that controls were tested rather than assumed. Generative tooling inside a lending workflow or a trading desk's middle office control layer does not fit neatly into any existing register, so it lands in the gap between information security, legal, and internal audit — and stays there until someone writes it down.

LT Risk Management works in exactly that gap. The firm, led by Leah Tzur, who is certified as a Chief AI Officer by Copenhagen Compliance, provides advisory work, outsourced risk management, training and workshops across AI governance, cyber risk in the business process, operational risk, fraud prevention and business continuity planning for Israel's supervised financial sector. This article sets out how the three candidate owners actually divide the work, what an AI risk map contains, which capability classes a regulated institution needs before it names a vendor, and how directors can evidence that the exposure is governed as of 2026 rather than merely acknowledged.

Who actually owns AI risk inside an organization today?

In practice, no single function actually owns AI risk end to end inside a supervised financial institution — ownership is split across the board, the risk function, Legal and the CISO, and each holds a different kind of it. This section narrows deliberately to the segment at the centre of the question: Israeli supervised financial institutions — banks, insurers, credit companies, investment houses and fintechs — where ownership is shaped by the supervisor's directives and by second-line and third-line structures that already exist for other non-financial risks (NFR: operational risk, fraud, cyber, business continuity and now artificial intelligence).

"Ownership" splits into distinct attributes, and confusion between them is where governance gaps open.

Ownership attribute — Who it typically sits with — Why it matters
Accountability — The board, usually via its risk or audit committee — Cannot be delegated downward; directors answer personally for the adequacy of the risk framework, including models and automated decisions
Management — A designated executive who manages artificial intelligence across the organization in 360 degrees, or the CRO where no such role exists — Owns the lifecycle: data provenance, validation, AI red teaming, and the dedicated AI risk map that lists exposures per use case
Control — Second-line risk and compliance, with internal audit as third line — Independent challenge and testing; without it, self-assessment by the building team is the only evidence directors receive
Legal and regulatory interpretation — Legal counsel and compliance — Translates obligations — contractual, privacy, and frameworks such as the EU AI Act — into binding requirements for each deployment
Technological security of AI systems — The CISO — Covers one arm of the exposure: model and infrastructure protection, identity, and monitoring

LT Risk Management works with this split directly. Its Chief AI Officer service — built around the role that manages artificial intelligence across the organization in 360 degrees — combines strategic AI advisory, risk-management support through implementation, and a dedicated AI risk map, while accountability remains with the directors. Leah Tzur, the firm's chief executive, holds that certification from Copenhagen Compliance.

What part of AI risk does the CISO own, and where does that ownership stop?

Narrowing the question to one concrete part of the problem — a supervised financial institution in Israel deploying generative models — the AI risk that sits with the CISO is the layer where models behave like any other system: identity, access, data movement, vendor security and telemetry. Exposures that live inside the business process itself are governed through other functions.

Exposures that belong inside the information security mandate

Exposure — What it covers — Why ownership is clear
Model access and identity — Federated sign-on, role-based entitlements, service accounts calling model APIs — Identical control plane to any other application the CISO already governs
Data leakage — Customer data, credit files or trading records sent to an external model endpoint — Falls under existing data classification and loss-prevention controls, aligned to ISO 27001
Shadow AI — Unsanctioned consumer AI tools adopted by staff without procurement — discovery through SaaS and network inventory — An unmanaged endpoint is a security asset problem
Vendor and supply-chain security — Model provider security posture, sub-processors, hosting region — Standard third-party security due diligence
Logging and monitoring — Prompt and output retention, SOC alerting, forensic reconstruction — Monitoring coverage is a security operations function

Exposures that fall outside it

Model validation and output quality. Whether a credit-scoring or fraud-triage model is accurate, stable and explainable is a model governance question, not a hardening question.
Business-process integrity. Where an AI output enters an approval chain, the exposure is segregation of duties, override rights and the embezzlement pathway created when a human control is quietly replaced by a machine suggestion.
Legal and regulatory classification. Duties flowing from frameworks such as the EU AI Act, customer disclosure and intellectual property questions sit with legal and compliance.
Continuity. Dependence on a single model provider belongs in the business continuity plan — the documented recovery arrangement for critical systems and processes.

LT Risk Management addresses this second group through a dedicated AI risk map and advisory work that accompanies a deployment across its lifecycle: data, validation, AI red teams, and the legal and regulatory aspects.

Which AI risks belong to Legal, compliance and the risk function?

This depends on what you mean by AI risk: some AI risks belong to Legal and compliance because they originate in law, contract and regulatory duty, while others belong to the risk function because they originate in how a business process actually runs. In supervised financial institutions in Israel, both meanings are live at the same time, and they are evidenced in different ways.

What does AI risk mean in the legal and compliance sense?

Here AI risk is an exposure that a regulator, a court or a counterparty could act on. Typical items sit with Legal, compliance and the data protection function:

Vendor and contractual exposure — what an AI supplier may do with the institution's data, who carries liability for a faulty output, and what audit and exit rights exist.
Privacy and data protection — lawful basis for training and inference data, cross-border transfer, and retention.
Consumer fairness in credit decisions — whether an automated underwriting or collections decision can be explained and defended as non-discriminatory.
Disclosure duties — telling customers, auditors and supervisors where an automated system participated in a decision.
Regulatory frameworks — the EU AI Act for institutions with European exposure, alongside the local supervisory directive set and risk-management standards such as ISO 31000.

A concrete example: a fintech lender adopts a third-party scoring model and must document, before launch, how an applicant can contest the outcome.

What does AI risk mean in the operational and non-financial sense?

Here AI risk is a failure mode inside the workflow. It covers operational risk, fraud and embezzlement exposure — an employee or an outsider exploiting an automated approval path — human error in prompt or data handling, cyber weaknesses in the business process, and business continuity (BCP) when a model or its vendor becomes unavailable during an emergency event.

This article uses the non-financial risk reading, which treats operational, fraud, cyber, continuity and AI exposures as one domain while the legal track runs in parallel and the governing body retains accountability for both. LT Risk Management provides a dedicated AI risk map and accompanies AI adoption across its lifecycle, covering data, validation, AI Red Teams and legal and regulatory aspects.

Why is the board ultimately accountable for AI risk, even when it does not manage it?

When the organization is a supervised financial institution — a bank, insurer, credit card company, investment house, fintech or non-bank credit provider — the board remains ultimately accountable for AI risk even though it never tunes a model or signs off on a prompt. Accountability in these entities follows the governance line rather than the technical one: supervisory expectations for risk management in regulated finance, and general frameworks such as ISO 31000, place ownership of the risk management framework with the board and executive management, who delegate execution but not responsibility. A CISO can secure the infrastructure, legal counsel can assess exposure under regimes such as the EU AI Act, and a dedicated AI risk owner can run the day-to-day discipline of data quality, validation and AI red teaming — yet the decision to accept a given level of exposure is reserved to the top of the house.

Meaningful oversight is therefore procedural, and it is visible in four artefacts:

Risk appetite — a written statement of how much AI-related exposure the institution is willing to carry, per use case, including uses it declines outright (for example, fully automated credit decisioning without human review).
Reporting cadence — a fixed rhythm at which the directors or their risk committee receive AI model inventory, incident and drift reporting, rather than ad-hoc updates when something breaks.
Escalation thresholds — pre-agreed triggers that force an item upward: a model operating outside validated parameters, a third-party AI vendor change, a customer-facing error pattern.
Documented decisions — minutes that record what was approved, on what evidence, and who dissented, so an internal auditor or supervisor can reconstruct the reasoning.

Governing bodies that lack an internal map of where AI already touches regulated processes usually start by commissioning one. LT Risk Management works in exactly this space; its consulting, trainings and lectures are attested to by leading clients in the Israeli financial and public sector, including Bank Discount, Bank Leumi, Bank of Israel, Menora Mivtachim, Visa Cal and the Ministry of Justice.

How do the CISO, Legal and the board compare across the main AI risk duties?

The CISO, Legal and the board divide AI risk between them, but the comparison only becomes useful once the criteria are fixed in advance. Five criteria separate the three roles in supervised financial institutions: decision rights (who can approve, pause or retire a model), typical scenarios (which AI failures land on that desk), required evidence (what makes the decision defensible to a supervisor or internal audit), reporting output (the artefact the role actually produces), and failure mode when unassigned (what breaks if nobody holds the duty). Decision rights matter because an unclaimed veto stalls deployment; evidence matters because supervised entities must show an auditable trail against frameworks such as ISO 31000, ISO 27001 and Proper Conduct of Banking Business directives; failure modes matter because they are what an audit finding will name.

Criterion — CISO — Legal — Board
Decision rights — Approve or block models touching production systems and sensitive data — Approve lawful basis, contracts, intellectual property and disclosure — Set AI risk appetite; approve policy and escalation thresholds
Typical scenarios — Prompt injection, data leakage into a vendor model, identity abuse of an agent — EU AI Act classification, privacy exposure, third-party model terms — Material misjudgement by an automated decision; reputational loss
Required evidence — Control testing, access logs, red-teaming results — Legal opinions, contractual clauses, records of processing — Minutes, risk appetite statement, periodic AI risk reporting
Reporting output — Security and technical assurance report — Legal and regulatory position papers — Resolutions and the oversight record
Failure mode if unassigned — Models deployed without validation or monitoring — Non-compliant processing discovered after launch — No accountable owner when the regulator asks

AI risk gaps accumulate in the seams between these three roles, where a model passes technical review, clears a legal check, and still enters a live business process whose failure path nobody has mapped. LT Risk Management writes a dedicated AI risk map covering the model lifecycle — data, validation, AI red teams, and legal and regulatory aspects — alongside the institution's existing risk maps. A well-built map makes visible which of the three roles holds each duty in the table above.

Frequently Asked Questions

Who owns AI risk — the CISO, Legal, or the board of directors?

AI risk ownership is distributed, and in a supervised financial institution each layer carries a defined slice. The board of directors holds the ultimate accountability for the risk management framework and signs off on risk appetite. The CISO owns the technology controls and the security of models, data stores and interfaces. Legal and compliance own regulatory exposure, contracts with model vendors, intellectual property and privacy. LT Risk Management's AI governance advisory addresses the exposures that fall between these desks.

What does a Chief AI Officer do that a CISO or General Counsel does not?

A Chief AI Officer is the function that manages AI across the organization in 360 degrees — data sourcing, model validation, AI red teaming, and the legal and regulatory dimensions — over the full lifecycle of each deployment. Security is one arm of that mandate and stays with the CISO; legal exposure stays with counsel. Leah Tzur, CEO of LT, is certified as a Chief AI Officer by Copenhagen Compliance, and the firm provides this service together with a dedicated AI risk map for the organization.

What belongs in a dedicated AI risk map?

An AI risk map inventories each AI use case in the organization and records its exposures across the lifecycle: data provenance and quality, model validation, adversarial testing, human oversight points, third-party dependencies, and the legal and regulatory constraints that apply. A well-built map ties each exposure to a control, which is what allows a board committee to review AI as a managed non-financial risk rather than as a collection of projects. LT writes such dedicated AI risk maps as part of its Chief AI Officer service.

How do regulatory frameworks shape AI accountability for Israeli financial institutions?

Banks, insurers, credit companies, investment houses and fintechs in Israel already operate inside the Bank of Israel's Proper Conduct of Banking Business directives and parallel supervisory requirements, which place the risk management framework squarely under board responsibility. General frameworks such as ISO 31000 for risk management and ISO 27001 for information security supply the control vocabulary, while the EU AI Act adds a risk-tiered view of AI systems that many Israeli entities inherit through group structures and vendor contracts. Because AI introduces risks the organization did not have before, LT writes a dedicated AI risk map that sits alongside the existing operational, compliance and cyber risk maps.

Can a mid-sized institution own AI risk without hiring a full-time risk manager?

Yes. LT Risk Management offers Risk Manager as a Service, an outsourced risk manager arrangement aimed primarily at medium-sized and governmental organizations that do not want a full-time hire; LT holds the position and supplies the service at the volume the client requests. That arrangement gives the board a professional counterpart for AI, fraud, operational risk and business continuity questions. For initial enquiries, LT commits to responding within 24 hours — a service availability commitment from its consulting team, not a contractual service level.

How do directors and risk managers get trained on AI risk?

As published by LT, its certification course for operational, cyber and AI risk managers runs about 40 academic hours and is built as experiential learning, including workshops, hands-on exercises and a visit to a leading SOC, with guest lecturers from major organizations in Israel and abroad. The course is recognized by IRM, the Institute of Risk Management, an international body in risk manager education. As of 2026, LT also delivers executive workshops and lectures for boards and management teams on AI governance, fraud prevention and business continuity.

About this article

LT RISKMGMT publishes this article under its own name and is responsible for its accuracy. Articles are researched and drafted with AI assistance and approved by LT RISKMGMT before publication; publication and update dates reflect substantive edits, not automated refreshes. Last updated: 2026-10-01

Ready to get started?

See how LT RISKMGMT can help.

צרו קשר