True cost per AI-assisted customer interaction at a bank under the 2026 model risk guidance

What changed in model risk guidance, and why it matters for the cost model

On 17 April 2026 the OCC, the Federal Reserve Board and the FDIC issued revised interagency model risk management guidance (OCC Bulletin 2026-13 and Federal Reserve SR 26-2). The guidance clarifies model risk management principles, sets out a risk-based approach and rescinds prior model risk management guidance and other issuances. Policy frameworks and cost models that still cite earlier documents should be reviewed against the revised text, and counsel should confirm which earlier documents are affected and any transition timing. This is the position as of October 2026.

The guidance covers three areas: model development and use, including testing; model validation and monitoring, including conceptual soundness and outcomes analysis; and governance and controls, including clear policies and roles and responsibilities. It also states that practices appropriate for one banking organization may be inappropriate for another with a different risk profile or model purpose. That has a direct cost consequence. Validation depth and documentation effort for a customer-facing AI interaction should be justified against the risk of that use case, so the cost model has to be calibrated to your own institution and cannot be borrowed from a peer or a vendor.

Decomposing the cost: six components and how each behaves

Most banks start with inference and platform fees because they appear on an invoice. The other components are real costs that sit in different budgets, which is why risk, finance and technology leaders often cannot compare an AI-assisted interaction with a human-handled one. The table groups the components into direct, control-related and oversight-related costs and shows how each scales.

• Inference and platform fees: Direct. Variable per interaction, driven by model usage and any platform licensing tied to volume.
• Retrieval and orchestration: Direct. Variable per interaction through retrieval and tool calls, plus fixed infrastructure to run them.
• Runtime control and evidence production: Control-related. Variable for enforcement and evidence capture on each interaction, fixed or periodic for policy upkeep.
• Retention and data residency: Control-related. Grows with the volume of evidence stored and the retention period, with fixed setup cost.
• Human escalation and review: Oversight-related. Variable, proportional to escalation rate and the cost of each reviewed case.
• Validation, monitoring and incident remediation: Oversight-related. Validation and monitoring are periodic or fixed. Remediation is episodic and hard to forecast.

Technical drivers of the variable portion

The variable cost of an interaction is set by how much work the system does for each customer request. Token consumption depends on prompt length, retrieved context, conversation history and response length, so long multi-turn conversations cost more than single-turn answers. Each retrieval call and each tool call adds its own compute and orchestration cost. Latency matters indirectly: a design that adds checks or retries lengthens response time and can raise cost per interaction even when per-call prices are unchanged.

Escalation rate is usually the largest swing factor. An interaction handed to a human reviewer carries the AI cost already incurred plus the cost of the human handling it, so a small change in escalation rate can outweigh a large change in inference price. Measure each driver per interaction type, not as a blended average. A balance inquiry and a dispute-related conversation have very different token, retrieval and escalation profiles, and a single average hides the cost of the higher-risk use cases that draw the most scrutiny.

Fixed and periodic costs: validation, monitoring and governance

Validation evaluates whether a model performs as expected, including its reliability and limitations. Outcomes analysis and other validation elements can identify material errors or persistent deviations outside established performance thresholds. For customer-facing AI this creates recurring work: defining thresholds, running outcomes analyses, reviewing results, documenting findings and resolving deviations. These activities are periodic or continuous, not per interaction, so their cost is amortized over volume.

This produces a tradeoff that matters for forecasting. Fixed and periodic costs fall per interaction as volume grows, but each new use case can add its own validation, monitoring and documentation burden. Growth in use cases can therefore raise total fixed cost even while volume growth lowers the per-interaction figure. Governance and controls add a smaller recurring cost: maintaining policies, assigning roles and responsibilities, and keeping documentation current. Incident remediation belongs here as well. Customer-facing chatbots that are poorly deployed can lead to customer frustration, reduced trust and legal violations, so remediation should be carried as an expected-loss line, not left out.

How runtime enforcement and evidence generation affect the compliance portion

Evidence cost depends on where evidence is produced. When policy is checked in a review process after the fact, someone must reconstruct what the AI was allowed to do and what it did, usually by assembling records from several systems for an examiner or internal audit request. That effort is episodic, labor-heavy and difficult to attribute to individual interactions.

When policy is enforced in the execution path, each interaction is evaluated as it happens and the decision (allow, redact, block, or escalate for human approval) is recorded at that moment. Evidence becomes a byproduct of operation. The cost moves from assembling records on request to a per-interaction capture and storage cost, plus the fixed work of maintaining policy. This changes the shape of the compliance line without removing it. Retention period and data residency requirements still determine storage cost, and escalations still require human reviewers.

Trussed enforces policy in the execution path across models, agents and tools, and generates audit-ready evidence from that enforcement. It supports self-managed deployment in the customer cloud with configurable retention and data residency. For a cost model, the practical question is the same for any approach: what is captured per interaction, how long it is kept, where it is stored, and how quickly it can be produced for an examiner.

Applying the framework to your interaction volumes

Use one formula per interaction type: fully loaded cost equals variable cost per interaction, plus escalation rate multiplied by the cost of a reviewed case, plus allocated fixed and periodic cost divided by interaction volume. Published industry savings estimates are context only and should not be used as inputs. Use your own data.

• Define interaction types by risk and purpose, since validation depth should follow the risk of the use case.
• Measure variable cost per type: tokens, retrieval calls, tool calls, enforcement and evidence capture.
• Measure escalation rate and the fully loaded cost of a human-reviewed case, including reviewer time.
• List fixed and periodic costs by guidance area: development and testing, validation and monitoring, governance and controls.
• Allocate those costs across projected volume, then model a volume and use-case growth scenario to see which line moves first.
• Compare the result to the fully loaded cost of a human-handled interaction, using the same components.