As we approach year-end, attention quickly turns to policy suite attestation, quantitative and qualitative reporting, and capturing the successes and lessons learned over the past year. For many insurers, AI will now feature in each of these, whether or not it has been formally recognised in the framework.

The BMA’s proposed guidance on the responsible use of AI asks firms to extend the frameworks they already have. That is a sensible approach, and the enterprise view of risk is not under threat from AI. The practical challenge is one of balance: governing AI from the top down while it arrives from the bottom up, one tool and one team at a time.

AI may sit across actuarial, underwriting, claims, technology and compliance functions, each with its own policies and responsibilities. Updating those policies is necessary. But the gaps appear in the spaces between them: a use case that touches several departments and belongs to none; staff turning to unapproved tools because the approved route is too restrictive, or does not exist; a tool with broad access to data and an ill-defined purpose or scope. None of these is an existential threat to the risk framework. They are creep, and creep is what frameworks are worst at noticing.

That is where embedding AI into an existing enterprise risk management framework takes more care than it first appears.

What the proposed guidance means in practice

The BMA’s Consultation Paper of 14 August 2026 proposes a Guidance Note for every sector the BMA regulates, with comments closing on 30 October 2026. It follows the July 2025 Discussion Paper and industry feedback favouring integration into existing governance structures.

The proposed Guidance Note explains how existing requirements apply when a firm uses AI. Where a specific rule exists, that rule prevails. A firm need not establish a separate AI governance framework solely because it uses AI, provided its existing arrangements address the material risks. Different or heightened risks may require those arrangements to be enhanced.

Two features matter in practice:

  • The use case is the unit of analysis. The same model can support several activities with different risks. Each use case needs to be assessed on its own merits, using the firm’s existing materiality and risk methods.
  • Materiality and risk are assessed separately. Materiality concerns the importance of the use case to the firm. Risk concerns its potential for harm to policyholders or cedents, counterparties or markets. An administrative AI agent may be of low materiality but still carry high risk if it has broad access to sensitive data.

What proportionality means

Proportionality means the BMA expects a firm to spend more effort where more could go wrong. That covers how important the use case is to the firm, and how much harm it could do to policyholders, cedents, counterparties or markets. A use case that feeds pricing, reserving or capital assumptions, or handles confidential policyholder data, needs more governance, testing and oversight than one that drafts internal emails. The size of the firm shapes how that is done, but it is the use case that decides how much.

The BMA has taken the same line before. In its 2019 thematic review of insurers’ CISSA and GSSA submissions, it accepted simpler stress testing from less complex insurers, with justification appropriate to their risks. But it still expected material risks to be properly tested, and each framework to stay specific to the insurer’s own risk profile “even after taking proportionality into account” (BMA, 2019 review, pp. 11 and 17).

The same test applies to AI. A smaller firm can use simpler structures than a large group, but a high-risk use case still needs testing, oversight and challenge to match. Either way, the firm has to identify the use case, name an owner, understand what could go wrong and be able to challenge what the tool produces. Proportionality changes how much work that takes, not whether it is done.

Where AI belongs

The proposed Guidance Note maps AI risk themes to existing Bermuda frameworks. For most insurers, the work will involve targeted enhancements to documents already maintained:

  • ERM framework and risk appetite: AI use cases within the risk taxonomy, with board-approved boundaries for adoption, including restricted and prohibited uses.
  • Model risk and actuarial governance: proportionate validation, drift monitoring and change control. Changes to vendor models, prompts or retrieval sources should be assessed for their effect on the use case.
  • Outsourcing and operational resilience: AI vendors, embedded AI features, concentration on common model and cloud providers, and fallback arrangements.
  • Cyber risk: threats such as prompt injection and data poisoning, alongside unapproved staff use of AI tools, often called “shadow AI”.
  • Data governance: provenance, permitted use and ethical sourcing of data.
  • Conduct, AML/ATF and recordkeeping: AI-supported communications and decisions subject to the standards and accountability that already apply. AI does not replace the accountability of the Money Laundering Reporting Officer.

The Operational Resilience and Outsourcing Code provides a further opportunity to address AI dependencies as part of the insurer’s wider work on resilience and outsourcing.

This is more than adding an AI paragraph to each policy. The relevant controls need to reflect what the insurer is actually doing, including AI features introduced through existing vendors.

The ownership gap

Ownership is often where an embedded approach first becomes difficult.

The chief actuary typically owns actuarial models and assumptions, while the CRO owns the enterprise view of risk. AI used in claims triage, underwriting support or interactions with policyholders or cedents may sit outside traditional actuarial work while still carrying significant model risk.

Consider an insurer using a vendor’s AI tool to prioritise claims for review. Claims owns the process and technology manages the vendor relationship. The tool does not calculate reserves, so it may never enter actuarial model governance. Yet errors could delay claims, affect policyholders or cedents, or influence the information used elsewhere in the business.

A reinsurer using AI to enhance exposure data before it is loaded into a catastrophe vendor model may face a similar question. The tool may standardise addresses, extract information from submissions or infer missing construction and occupancy details. Underwriting may own the source data, while the catastrophe modelling team owns the model run. Yet AI-generated estimates can influence modelled losses and, in turn, pricing, accumulation management and capital assessment. Those estimates need to be distinguishable from reported data, with proportionate validation and a clear owner for approving their use.

In both cases, the question is who owns the use case, who assesses its risks and who can intervene when its behaviour changes. Ownership needs to cover the assumptions entering a model as well as the model itself.

Every material use case needs a named business owner, with review and sign-off from technology, risk and, where relevant, actuarial functions proportionate to the risk. Responsibility should remain clear when a use case crosses functional boundaries.

What should stand on its own

Embedding does not mean everything must be dispersed through existing documents. Three items can help the arrangements hold together:

  • An AI acceptable-use policy: approved tools, limits on data entered into them and escalation routes. Staff need one place to look, and this is a direct control over shadow AI.
  • An AI inventory: a new register or additional fields in an existing model, system or vendor register. It should capture purpose, owner, materiality, risk, autonomy, data sensitivity and third-party dependencies. Lower-risk productivity tools can be grouped, while material use cases need individual entries.
  • A short connecting standard: a map of the relevant policies, accountable owners, approval routes and board reporting arrangements.

The connecting standard need not repeat the controls contained elsewhere. Its purpose is to make clear how those controls work together and who is responsible for maintaining that connection.

The board needs the resulting consolidated view. The proposed Guidance Note expects management information to extend to material AI use cases, risk ratings, performance and drift indicators, incidents and near misses, third-party dependencies and remediation. That information has to be drawn together from the functions where AI is used.

Where it comes together: the CISSA

For commercial insurers, the year-end 2026 CISSA is a practical opportunity to consider whether AI is adequately reflected in the risk profile.

The proposed Guidance Note does not introduce an AI section into the CISSA. That does not mean AI stays out.

AI enters the CISSA through the risk profile, not through the Guidance Note. The CISSA’s existing scope includes the identification and assessment of “all reasonably foreseeable material risks”. The BMA’s instructions also explain that the risk profile considers such risks arising from the insurer’s operations or operational environment. Where AI is material to an insurer’s operations or risk profile, it belongs in the CISSA because the CISSA’s own scope captures it (BMA CISSA requirements; BMA, Year-End Instructions Handbook, section C11.1).

The likely areas include:

  • operational and third-party risk, including dependence on common model and cloud providers;
  • model risk, where AI feeds pricing, reserving, catastrophe modelling or capital modelling;
  • emerging risks, including AI-related liability in insureds’ businesses;
  • stress and scenario testing, such as the failure of a provider or a model.

There is also a separate question: whether AI has helped prepare the submission itself.

The proposed Guidance Note addresses the integrity of regulatory submissions. Where AI materially influences a submission, firms should consider human review and greater explainability. Generative AI content intended for supervisors should be reviewed. If AI helps prepare the CISSA or BSCR, the insurer should be able to explain how the output was checked. Existing model-change requirements continue to apply where AI touches an approved internal capital model.

Supporting evidence also matters. The BMA may request inventories, risk assessments, validation and monitoring results, board reporting and third-party due diligence through normal supervisory engagement. The insurer’s risk narrative and that evidence need to agree.

Other sectors do not file a CISSA, but the same logic applies to their own risk assessments and supervisory returns.

Where to start

With the guidance still in draft, three steps are worth taking now:

  1. Map the AI use cases across the business, including features switched on inside vendor tools, and assess each for materiality and risk. This is what sets proportionality: the assessment tells you where the effort should go.
  2. Assign a named owner to every material use case, and scale the review and approval each one needs to its risk rather than to the size of the firm. Ownership is what stops a cross-departmental use case falling between functions, and a clear approved route is what stops shadow AI.
  3. Document how the relevant policies, controls and reporting connect, so they support one view for the board and the CISSA.

None of this calls for a new framework. It calls for the existing one to be applied with some care.

If you are working through AI ownership, board reporting or its implications for the CISSA, I would be glad to discuss how these fit within your existing framework.

Sources