An AI Risk Transfer Strategy for Deployment & Capital Allocation
As AI takes on more authority, financial exposure can grow quickly. A system that recommends an action creates one level of risk. A system that can approve transactions or make commitments on the company’s behalf can put substantially more capital and liability at stake.
AI risk can be insured, but only in part. No single category of insurance covers the full range of AI-related losses. Some may fall within existing policies; others may require endorsements, specialized coverage, or contractual protections from vendors. Other exposures may be impossible or uneconomic to transfer. Operating controls can reduce exposure, but some risk will remain with the enterprise. AI strategy should therefore treat risk transfer and retained exposure as part of deployment and capital-allocation decisions, alongside the value each AI use case is expected to create.
The AI Risk Allocation Framework connects the authority given to AI with the losses that could follow, the exposure operating controls can prevent, and the protection available through insurance and contracts. It then identifies the financial risk the enterprise must retain. Management can weigh that exposure against its risk appetite, available capital, and the incremental value of deployment to determine whether a use case should scale, operate within tighter limits, or be redesigned.
Define the Business Loss Behind the AI Workflow
Start with the business outcome that could fail, not the AI system that could cause it. An AI risk management inventory shows where the technology is used, but not what the business stands to lose. An AI system that supports internal work creates a different exposure from one that makes decisions affecting customers.
Translate AI Failure Into Business Loss
For each material workflow and use case, identify the failure, affected parties, and financial consequences. A manufacturer using an AI-assisted quality inspection system, for example, could face defective products reaching customers, acceptable products being rejected, or production stopping while the system is investigated.
The same system can create very different liabilities, remediation costs, and operating consequences depending on the outcome.
AI-related losses do not require a cyberattack. At a May 2026 workshop on AI incident management, the National Institute of Standards and Technology (NIST) examined attacks against AI systems separately from incidents involving misuse or malfunction. An AI system can cause harm without being compromised, whether it is used outside its approved purpose or fails during an authorized task.
For an enterprise, that could mean an AI system producing an incorrect output, taking an unintended action, or making an unauthorized commitment. These events can lead to faulty transactions, customer harm, operational disruption, or liability. Exposure depends not only on whether AI is secure, but also on how it behaves and how much authority the business gives it.
Customer communication shows how that exposure can materialize. In Moffatt v. Air Canada, a British Columbia tribunal found the airline liable for negligent misrepresentation after its website chatbot provided incorrect information about bereavement fares. The chatbot’s underlying architecture was not established, but the case reinforces a broader principle: delegating customer communication to an automated system does not shield responsibility for what that system communicates.
Intentional misuse presents a different exposure. In 2024, fraudsters used AI-generated video and audio to impersonate senior executives during a fabricated video conference, inducing an employee at Arup, an engineering firm, to authorize transfers totaling approximately HK$200 million (US$25.6 million). Rather than causing an unintended system error, the perpetrators used AI to deceive the enterprise. The incident demonstrates how AI-enabled fraud can create substantial financial losses even without a breach of the company’s systems.
Separate losses the enterprise absorbs directly from claims or obligations created for others. Mistaken payments, unusable inventory, remediation, and interrupted operations can affect the balance sheet before any third party brings a claim.
Other events can create financial obligations to customers, employees, or regulators. In 2023, iTutorGroup agreed to pay $365,000 to settle an employment discrimination lawsuit after its automated hiring software rejected more than 200 qualified applicants based on age. The settlement illustrates how automated decision-making can generate financial liability, a risk enterprises must also consider when deploying AI in employment decisions. Customer claims, professional liability, intellectual-property disputes, and contractual penalties can similarly turn AI-related failures into third-party exposure.
Test Whether the Exposure Can Spread
An AI use case may appear manageable in isolation while contributing to a much larger enterprise exposure.
The Financial Stability Board has identified third-party dependencies, service-provider concentration, and substitutability among the vulnerabilities relevant to monitoring AI adoption in financial services. The same issue extends across industries. Separate applications may rely on the same foundation model, cloud environment, data provider, or orchestration platform.
Shared dependencies can change the scale of loss. In December 2024, an OpenAI infrastructure failure disrupted ChatGPT, OpenAI’s API, and Sora for several hours. A change to a shared infrastructure component triggered cascading failures across multiple services. For enterprises relying on the same AI provider across customer service, operations, or finance, a similar disruption could affect several workflows simultaneously. Portfolio risk therefore depends not only on individual deployments, but also on how multiple systems can fail together.
Management should evaluate an isolated incident, a sustained disruption within one workflow, and a correlated event affecting several workflows. Assess the gross exposure before insurance or vendor recovery so the underlying loss remains visible.
Key Takeaway
Individually manageable AI risks can become material when several deployments share the same point of failure.
Explore Our Risk Management Services
P&C Global’s risk management practice helps enterprises bound AI exposure, test coverage, and fund the risk they retain.
Bound AI Exposure Through Operating Design
The next AI risk management decision is how much exposure the enterprise will allow AI to create before intervention. Once AI can act on the enterprise’s behalf, management needs to define the boundaries of that authority and how quickly the organization can step in when activity moves outside them.
Set the Limits of AI Authority
Management should set limits on transaction values, approved counterparties, customer commitments, and decisions that require human approval.
For transactional workflows, management should also understand how much exposure can build before intervention is required. A low-value action repeated thousands of times can create more risk than a single large transaction. Transaction size, action volume, detection time, and reversibility all affect the amount at risk.
Those limits should be enforced through transaction systems, with clearly defined override rules, automatic stop conditions, and exception reviews. Instructions to the AI should reinforce those controls, not replace them.
Design for Intervention & Continuity
Human oversight needs an operating specification. Naming a reviewer does not establish effective control. Management needs to know what the person must detect, how many decisions can realistically be assessed, how quickly intervention can occur, and who assumes authority when the primary reviewer is unavailable. Oversight that cannot keep pace with the workflow does little to constrain the resulting exposure.
NIST’s AI Risk Management Framework Playbook calls for mechanisms and assigned responsibilities to bypass, disengage, or deactivate systems whose performance or outcomes become inconsistent with intended use. It also recommends contingency processes for mission-critical systems and decision thresholds for deactivation.
Stopping the system is only part of the requirement. The enterprise also needs to know how essential work will continue. Minimum service levels, manual capacity, prioritization rules, and restart conditions determine whether management can intervene without creating a second operational problem.
Enforce Authority Through Independent Controls
Automated controls can prevent unauthorized AI actions before they create financial losses. In October 2026, American Express introduced its Intent Intelligence Framework, designed to verify that purchases initiated by AI agents remain within customer-approved boundaries.
The framework captures purchase instructions, including spending limits, merchant preferences, and other conditions. The customer then authenticates and approves those instructions. A digital token representing the approved conditions can be used to obtain a payment credential restricted by the authorized parameters. Under this design, payment systems could verify whether a proposed purchase aligns with the customer’s authenticated instructions rather than relying solely on the AI agent’s interpretation.
The broader principle extends beyond payments. Enterprises can apply independent authorization checks to AI-initiated procurement, refunds, and other transactions, preventing actions outside approved limits while preserving evidence for investigations or disputes. Such controls can reduce financial exposure before losses occur, rather than relying exclusively on detection, intervention, or recovery afterward.
Controls should earn their place through the authority they constrain, the losses they prevent, or the time they give the enterprise to respond. In some cases, bounded authority may create greater value than maximum automation.
Key Takeaway
AI authority should expand only as fast as the enterprise can contain the financial exposure it creates.
Explore Our AI Governance Services
P&C Global’s AI governance services help set the authority limits, controls, and oversight behind AI-enabled work.
Test AI Insurance & Contractual Recovery
Coverage depends on the nature of the loss, not simply on the fact that AI was involved. Different policies may apply to different consequences of the same AI-related event, depending on who suffered the loss and the type of claim. An AI insurance label does not make protection comprehensive, and the absence of one does not make existing coverage irrelevant.
Illustrative AI Losses and Potential Insurance Coverage
Loss Scenario | Potential Insurance Coverage |
Security breach or deepfake fraud | Cyber insurance for covered security incidents; commercial crime or social-engineering coverage for fraudulent payments. |
Professional error or customer harm | Professional liability or technology errors and omissions (E&O), where claims arise from covered services. |
Discriminatory employment decisions | Employment practices liability insurance (EPLI) for certain discrimination claims. |
Intellectual-property claims | Media liability, specialized intellectual-property insurance, or applicable E&O coverage. |
Bodily injury or property damage | Commercial general liability or products liability, subject to applicable exclusions. |
Business interruption | Cyber business interruption for qualifying system disruptions, or property insurance where covered physical damage triggers the loss. |
These are potential sources of recovery, not assurances of coverage. Actual protection depends on policy definitions, causation, exclusions, sublimits, conditions, and applicable law. Management must test each policy against the specific financial consequences of an AI incident rather than assume coverage because AI was involved.
Test Coverage Against the Loss
Policy wording is already moving in both directions. In 2024, Coalition introduced an Affirmative AI Endorsement that expanded its cyber-policy definitions to address AI-related security events and fraudulent instructions delivered through deepfakes or other AI technology. The endorsement makes explicit how certain AI-enabled events can fall within existing cyber insurance coverage.
Other wording can narrow protection. Verisk introduced an optional general liability exclusion for generative AI that, when added to a commercial general liability policy, removes coverage for certain personal and advertising injury claims involving the technology. The exclusion applies to a defined category of liability rather than every AI-related loss.
Together, the examples show why management cannot infer protection from a policy label. The complete contract determines what is covered, excluded, limited, or subject to conditions before recovery.
Specialized AI insurance is emerging, but available coverage may fall well short of potential exposure. In February 2026, Mosaic Insurance and Munich Re announced coverage for defined AI performance failures with up to $15 million in initial capacity for AI developers and vendors. Such protection addresses risks that traditional policies may not cover, although potential liabilities for major AI providers could substantially exceed individual coverage limits.
For enterprises using these technologies, the challenge is different. A vendor’s insurance does not necessarily protect its customers against operating disruption, contractual obligations, or other losses resulting from AI failures. Coverage under the enterprise’s own policies may also be limited or uncertain, particularly when losses fall between traditional insurance categories. Even specialized coverage may not respond if the event causing the enterprise’s loss does not meet the policy’s defined performance thresholds.
A policy’s overall limit may overstate the protection available when a specific loss is subject to a lower sublimit, leaving the enterprise responsible for a larger share of the exposure.
Trace the Contractual Recovery Chain
Insurance is only one potential source of recovery. Supplier agreements may provide service credits, warranties, indemnities, liability caps, or required insurance, but those protections do not necessarily mirror the obligations the enterprise has accepted with its own customers.
Trace those obligations through the supply chain. A customer commitment may ultimately depend on an application provider, model provider, cloud platform, or other supplier whose liability is narrower or capped.
That mismatch can leave the enterprise carrying losses it assumed had been transferred. An indemnity may apply but stop at a contractual limit. A supplier may owe compensation but lack the financial capacity to absorb a large event. Multiple recovery sources may also overlap rather than provide additional protection.
Contractual recovery may also depend on meeting specific operating requirements. Microsoft’s Customer Copyright Commitment, for example, requires customers using applicable Azure OpenAI and other configurable generative-AI services to implement specified safeguards and retain testing and evaluation records when submitting certain intellectual-property claims.
For each material risk transfer scenario, separate recovery into three categories: reasonably supportable, conditional, and unresolved. Only reasonably supportable recovery should reduce the amount of risk treated as remaining with the enterprise.
Key Takeaway
Risk transfer should be valued by the loss it can reliably absorb, not by the amount of insurance or contractual protection purchased.
Approve the AI Deployment and Fund the Remaining Risk
Insurance availability should not be treated as evidence that an AI deployment is well controlled or economically sound. Limited loss histories, rapid technology change, and uncertainty about the effectiveness of individual safeguards make AI risk difficult to price. Underwriting can provide useful external scrutiny, but management still owns the decision about whether the value created justifies the risk that remains.
Compare AI Operating Models on Value and Risk
Compare feasible operating models against the same business objective. If the current manual or legacy process already produces errors, delays, fraud exposure, customer friction, or capacity constraints, those risks and costs belong in the comparison. AI should be evaluated against the real alternative, not against a risk-free process that does not exist.
For each option, assess the business value created, technology and operating costs, controls and fallback capacity, insurance and contractual transfer costs, reasonably supportable recovery, and remaining financial exposure.
Exhibit: The AI Risk Allocation Waterfall
Gross scenario loss | Potential financial loss from a defined AI failure |
Less: Loss prevented by controls | Exposure avoided through enforced limits, approvals, and intervention |
Residual exposure | Potential loss remaining after controls |
Less: Supportable recovery | Insurance and contractual compensation reasonably expected to apply |
Retained scenario loss | Financial exposure the enterprise must absorb |
Management decision: Compare the retained loss with risk appetite, available capital, and the incremental value of deployment.
Where reliable loss data is limited, use scenarios and ranges rather than precise probabilities. Scenario and sensitivity analysis can show which assumptions change the investment decision. A deployment may produce attractive average economics while still creating a severe loss the enterprise cannot absorb.
Applying the Framework: AI Refund Authority
Consider a retailer evaluating an AI customer-service agent to accelerate routine refunds and reduce manual review. The agent can issue refunds of up to $200 and process as many as 1,000 each hour.
A three-hour configuration error could therefore generate as much as $600,000 in mistaken payments before investigation, remediation, or other costs.
Management now has several choices. It could permit broad refund authority, require human approval for higher-risk transactions, or impose an aggregate ceiling that stops automated refunds once total payments reach a defined threshold. Each design offers a different balance of speed, operating cost, and financial exposure.
Suppose the retailer sets an independently enforced $100,000 ceiling on total automated refunds, with additional payments suspended until an authorized reviewer resets the limit. The control reduces the amount that can be paid incorrectly before activity stops, but it may also delay legitimate refunds and increase manual workload.
The decision is not simply whether the AI agent is “safe” or “insured.” It is whether the additional speed and automation justify the exposure the retailer would still retain under each operating design.
Management might approve bounded authority for routine refunds while preserving human approval for exceptions. Broader autonomy would need to produce enough additional value to justify the greater financial exposure it creates.
Key Takeaway
AI authority should be treated as an investment variable. Broader autonomy earns its place only when the additional value justifies the greater exposure the enterprise must control or absorb.
Reassess as AI Exposure & Protection Change
Approval should not remain fixed as the deployment and its operating environment change. Establish review triggers for developments that could alter the original decision, including greater transaction authority, higher volumes, new customer commitments, entry into another jurisdiction, a different model or supplier, revised policy wording, or changes to contractual protections.
Not every system update requires executive review. Reassessment is warranted when a change could materially affect the loss scenario, control effectiveness, expected recovery, or the economics supporting the deployment.
Actual performance should then determine whether the original approval still holds. Did controls operate as expected? Could essential work continue when the system was constrained or suspended? Did suppliers provide the support assumed? Did incidents or near misses reveal costs or dependencies that were not anticipated?
Evidence should change the decision when warranted. If an AI procurement agent repeatedly hits its spending ceiling or triggers manual review, the safeguards may be working as intended, but the pattern may also indicate that the workflow or authority limits need redesign. An interval without a claim, however, does not establish that the underlying exposure has disappeared.
Watch for Portfolio-Level AI Risk
Portfolio risk can also shift over time. Individually approved deployments may gradually increase reliance on the same model provider, infrastructure platform, or insurance aggregate even when no single application changes materially.
Management should be prepared to renew the approval, narrow authority, strengthen protection, redesign the workflow, or retire the deployment as conditions change.
Key Takeaway
AI approval should remain valid only while the assumptions that justified it continue to hold.
Scale AI With Explicit Financial Accountability
AI risk management should scale with a clear view of which losses have been constrained, which have been transferred, and which the enterprise has chosen to retain.
That clarity can change which form of automation creates the most value. Broad autonomy may look attractive until the costs of controls, continuity, risk transfer, and retained exposure are included. In some cases, a more constrained design will create stronger value. In others, the benefits may justify greater authority and deliberately retained risk.
Leadership should make that trade-off explicit before material AI deployments scale. Insurance can absorb part of the financial loss when AI fails, but it cannot determine how much authority the enterprise should delegate or how much exposure it should accept. The authority given to AI should not exceed the enterprise’s ability to control, transfer, or absorb the risk it creates.
