Model Validation for LLMs and Agents: SR 11-7 (July 2026)

I'll be frank: most model risk governance programs inherited from the SR 11-7 era were designed to validate models that produce a single deterministic output from a bounded input space. LLMs don't do that. Agents definitely don't. SR 26-2 brought generative and agentic systems explicitly into scope, but the model validation methods that follow from that extension are meaningfully different from what teams are used to. Here's what that looks like in practice.

TLDR:

• SR 11-7 requires independent model validation, documentation, and governance; SR 26-2 extends all three to LLMs and agents.
• Traditional point-in-time validation fails for AI: probabilistic outputs, unbounded inputs, and agentic action chains each require continuous monitoring with threshold-based enforcement gates.
• Fairness auditing sets concrete thresholds: flag when any group's selection rate falls below 80% of the highest-performing group's rate (EEOC four-fifths rule, 29 CFR § 1607.4).
• A model inventory entry with missing fields is not a neutral gap: auditors treat every empty field as evidence the control was never in place.
• Openlayer is a unified evaluation, observability, and governance platform spanning pre-deployment through production, with enforcement gates that block outputs when thresholds are breached and generate the immutable audit records SR 11-7 expects.

What model validation is and what it covers

Model validation is the process of confirming that a model does what it claims to do, in the conditions where it will actually be used. Under SR 11-7, that confirmation covers three distinct activities: conceptual soundness review, outcome analysis, and ongoing monitoring.

What Each Activity Requires

SR 11-7 breaks model validation into components that each carry specific evidence requirements:

• Conceptual soundness review assesses whether the theory behind the model is appropriate for its intended use, whether the assumptions hold given the data and context, and whether the design choices can be defended to an independent reviewer.
• Outcome analysis tests whether the model produces accurate, stable results across the range of inputs it will encounter in production, including edge cases and populations it may not have been explicitly trained on.
• Ongoing monitoring tracks whether model performance degrades over time as the underlying data distribution changes, business conditions change, or usage patterns evolve in ways the original validation did not anticipate.

Together, these three activities produce the evidentiary record that model risk governance depends on: documented justification of design choices, test results showing performance against defined thresholds, and monitoring logs that confirm the model remains fit for purpose after deployment.

What SR 11-7 Explicitly Excludes from Independent Validation

One common misreading of SR 11-7 treats model development and model validation as activities that can share personnel. The guidance is direct: validators must be independent from model developers, with no stake in the model's approval. That independence is not a procedural formality. It is the mechanism that makes the evidentiary record credible to examiners.

SR 11-7, SR 26-2, and the regulatory foundation for model risk management

SR 11-7, issued by the Federal Reserve in 2011, remains the foundational regulatory document for model risk management in U.S. financial institutions. It sets out three core requirements: independent model validation, documentation of model development and use, and governance structures that assign clear accountability for model risk. SR 26-2, released on April 17, 2026, extends that foundation explicitly to AI systems, closing the gap between guidance written for statistical models and the behavioral realities of LLMs and agents.

What SR 11-7 Put in Place

The original guidance defined a model as any quantitative method, system, or approach that applies statistical, economic, financial, or mathematical theories to process inputs into quantitative estimates. That definition was broad enough to cover credit scorecards and VaR models but left ambiguous how it applied to systems that generate text, reason across retrieved documents, or take actions through tool calls.

SR 11-7 organized model risk management around three pillars:

• Independent model validation: a function separate from model development that tests whether a model performs as intended, across the full range of conditions it will encounter in production, beyond the conditions used during development.
• Documentation standards: records covering model purpose, methodology, data sources, assumptions, limitations, and validation results, maintained well enough that a reviewer unfamiliar with the model could assess its fitness for use.
• Governance and accountability: defined ownership for each model in use, with escalation paths when validation findings are unresolved or model performance degrades.

What SR 26-2 Adds

SR 26-2 preserves that structure and extends it to AI systems by closing four gaps that SR 11-7 left open.

The practical effect is that model validation for AI systems now carries the same regulatory weight as validation for traditional quantitative models, with specific expectations for how teams document, test, and monitor systems whose outputs are probabilistic and whose behavior can shift without a code change.

The three pillars of model risk management

SR 11-7 organizes model risk management around three interlocking disciplines. Each one targets a distinct failure mode, and all three must be present for a governance program to hold up under regulatory scrutiny.

Model Development and Implementation

Sound model development begins before a single line of code is written. Developers must document the conceptual framework behind a model, the data used to build it, and the assumptions embedded in its design. SR 11-7 expects this documentation to be detailed enough that an independent reviewer can reconstruct the reasoning without asking the original developer for clarification.

Model Validation

Model validation is the independent review process that stress-tests a model's logic, data, and performance before it reaches production. Validators assess whether the model does what its documentation claims, whether it performs acceptably across the range of conditions it will encounter, and whether its outputs can be explained and defended to a regulator. Validation is not a one-time gate; SR 11-7 requires ongoing validation activity whenever a model's inputs, outputs, or operating environment change materially.

Model Risk Governance

Model risk governance is the organizational infrastructure that keeps development and validation accountable. It covers model inventory management, tiered risk classification, clear ownership assignment, and escalation paths when a model's behavior falls outside approved parameters. Without governance, even rigorous validation findings can go unacted on.

Why traditional model validation breaks down for AI systems

Traditional model validation was built for a different era of statistical models. Regression models, scorecards, and decision trees produce deterministic, auditable outputs from well-defined input features. SR 11-7 assumes validators can inspect a model's logic, stress-test it against historical scenarios, and draw clear conclusions about whether it performs within acceptable bounds.

LLMs and agents break every one of those assumptions.

There are four specific failure modes where traditional validation frameworks lose their footing with AI systems:

• Outputs are probabilistic and context-dependent: The same prompt can produce materially different outputs across runs. A credit decisioning model built on logistic regression will return the same prediction for the same inputs every time. An LLM-based underwriting assistant will not. Validation frameworks that rely on point-in-time testing against fixed test sets cannot capture this variance.
• The input space is effectively unbounded: Traditional model validation operates on structured feature sets with known distributions. LLMs accept free-form text, which means the input space cannot be fully catalogued or stress-tested through conventional scenario design. Coverage that feels complete is not.
• Behavior is shaped by training, not explicit programming: A regression model's logic is legible in its coefficients. An LLM's behavior develops from billions of parameters shaped by pre-training data that validators rarely have full visibility into. Model risk governance frameworks designed around inspectable model logic do not transfer cleanly to this architecture.
• Agents introduce compounding, sequential risk: A single-inference model has one failure surface. An agent that plans across multiple steps, selects tools, and modifies external state has failure surfaces at every decision point, and errors compound. A flawed tool call in step two changes the context for every subsequent step.

The result is that model risk governance programs applying SR 11-7 validation methods to LLMs and agents are testing a narrow slice of actual risk exposure. Point-in-time backtests, champion-challenger comparisons, and sensitivity analyses on structured inputs were never designed to catch hallucination rates, instruction-following failures, or agentic reasoning chains that drift from their intended scope.

Model validation techniques for AI applications

Model validation for AI systems borrows the structured rigor of SR 11-7 but requires a substantially expanded toolkit. Where traditional model validation checked statistical assumptions, backtests, and sensitivity analyses, AI model validation must cover behavioral testing, adversarial probing, fairness auditing, and runtime drift detection across a system that may be non-deterministic by design.

Core Validation Techniques

There are four primary categories of validation work that apply across LLMs and agent-based systems:

• Benchmark and task-specific evaluation tests the model against held-out datasets and domain-relevant tasks, confirming that performance metrics align with the intended use case before any deployment decision.
• Behavioral and adversarial testing probes the model with edge cases, out-of-distribution inputs, and deliberately adversarial prompts to surface failure modes that aggregate accuracy scores would never reveal.
• Fairness and disparity auditing measures demographic parity gaps, equal opportunity rates, and calibration differences across protected groups, with alerts triggered when any group's outcome rate falls below 80% of the highest-performing group's rate (EEOC four-fifths rule, 29 CFR § 1607.4).
• Drift and degradation monitoring tracks input distribution changes, output quality regression, and groundedness score changes post-deployment, flagging when scores fall below the threshold set at deployment approval.

What Changes for LLMs and Agents

Traditional validation produces a point-in-time certification. For LLMs and agentic systems, validation is continuous. A model that passed evaluation in March may behave differently in July if upstream data sources changed, prompts evolved, or the model itself was updated by a third-party provider without notice.

Agent validation adds another layer: you are validating model outputs and the full decision chain beneath them. Tool calls, memory reads, and multi-step reasoning paths each introduce failure surfaces that single-inference evaluation does not cover. Validating an agent means confirming that each reasoning step is grounded, that tool call outputs are within expected ranges, and that the agent does not take irreversible external actions outside its approved scope.

Conceptual soundness and outcomes analysis for AI models

Conceptual soundness sits at the heart of SR 11-7's model validation requirements, and extending it to LLMs and agents means asking whether a model is doing what it claims to do, for the right reasons, in the conditions it was built for.

For traditional models, this involves reviewing the theoretical basis of the model's assumptions, the statistical techniques used, and whether the math holds up. For LLMs and agents, the question changes: there is no closed-form derivation to audit. Instead, validators assess whether the model's outputs are grounded, coherent, and consistent with its intended purpose across the range of inputs it will actually encounter in production.

What Outcomes Analysis Covers

There are three primary dimensions to outcomes analysis for AI models under an extended SR 11-7 framework:

• Output quality and groundedness: whether the model produces responses that are factually supported by the context it was given, as opposed to confabulated. Groundedness scores below 85% should trigger a review gate before deployment proceeds.
• Behavioral consistency: whether the model behaves predictably across semantically equivalent inputs, different prompt orderings, or minor surface-level variations. Inconsistency here is a model risk, and a material one (not a UX issue).
• Decision traceability: whether the reasoning path from input to output can be reconstructed after the fact. For agentic systems, this extends to the full tool-call chain, including every intermediate step, beyond the final output alone.

Outcomes analysis does not stop at deployment. Post-deployment monitoring feeds back into the outcomes record, and any drift beyond defined thresholds reopens the validation question.

Ongoing monitoring as the primary risk control for AI

For traditional models, periodic validation cycles, annual reviews, and backtesting against held-out data form the backbone of ongoing risk control. The model either performs within acceptable bounds or it gets flagged for redevelopment. That loop works because the model's behavior is largely a function of its weights, and its weights don't change between reviews.

LLMs and agents break that assumption entirely. Behavior changes with every prompt, every context window, every tool call, every upstream API change, and every update to a retrieval corpus. A model that passed validation last quarter may be producing materially different outputs today, and no periodic review cycle will catch that in time to matter.

Ongoing monitoring for AI systems requires controls that operate continuously, not periodically. There are several distinct failure modes that monitoring must cover:

• Prompt injection and jailbreak attempts that cause the model to ignore system instructions, producing outputs outside the approved use case boundary.
• Retrieval quality degradation, where the documents being surfaced in RAG pipelines drift from the intent of the query, pulling groundedness scores below acceptable thresholds without any change to the model itself.
• Agentic scope creep, where multi-step agents begin taking tool calls or external actions that fall outside the intended operating scope, often gradually and without a single triggering event.
• Output distribution drift, where the statistical character of responses moves across demographic groups or query types in ways that create disparate impact exposure over time.

From Observation to Enforcement

Logging these failure modes is observation. The SR 11-7 intent, and the expectation regulators are increasingly applying to AI, is enforcement. That means setting threshold-based gates that do not merely alert a reviewer but halt inference or escalate automatically when a defined limit is breached.

In practice, this looks like blocking a response when a groundedness score falls below 0.80, suspending an agent workflow when a tool call pattern matches a flagged scope violation, or triggering a formal model risk review when demographic parity gaps exceed five percentage points across a rolling inference window (example thresholds; calibrate to your institution's risk appetite and the applicable regulatory floor). The monitoring infrastructure that captures these signals must write to an audit trail that survives the model's deployment lifecycle, because the evidentiary record regulators ask for during examination is built from that log, not reconstructed after the fact.

Independent validation and the three lines of defense

SR 11-7 organizes model risk oversight around a three-lines-of-defense structure, and that structure carries forward when applied to LLMs and agents, though each line requires meaningful expansion to cover the new failure modes these systems introduce.

The Three Lines and What Changes for AI

The core architecture holds: first-line model owners, second-line independent validation, third-line internal audit. But the substance of each line changes considerably.

• First-line model owners are responsible for documenting intended use, defining acceptable output behavior, and maintaining performance thresholds. This applies to statistical models with tabular outputs and equally to LLMs where "acceptable output" means setting groundedness floors (flag responses when groundedness falls below 85%), toxicity ceilings (block outputs when toxicity probability exceeds 0.15), and demographic parity limits (review when group selection rate gaps exceed 5 percentage points).
• Second-line independent validation must assess whether those thresholds were set appropriately and whether the evaluation suite actually covers the risk surface. For LLMs, that means reviewing prompt robustness tests, adversarial injection coverage, and whether the LLM-as-a-judge setup used for scalable grading has been itself validated against human review.
• Third-line internal audit reviews whether the governance process was followed (documentation exists, validation was independent, exceptions were tracked) and whether the audit trail is reconstructible. For agentic systems, this includes verifying that tool call logs, reasoning chains, and state change records are retained and traceable to specific model versions.

What Independent Validation Actually Requires for LLMs

Independent validation under SR 11-7 means the validating team had no material role in model development. That independence requirement does not change for LLMs, but the scope of what validation must cover does.

Traditional model validation reviews conceptual soundness, data quality, and backtesting results. For an LLM deployed in a credit or compliance context, independent validation should also cover:

• Behavioral consistency across prompt variants, including adversarial inputs the development team did not test
• Calibration of confidence outputs relative to ground truth, where applicable
• Output stability under distribution shift in input text characteristics
• Completeness of the failure mode inventory: what the model was not tested on, documented explicitly

The validating team's report is the artifact that closes the second-line obligation. That report must document what was tested, what was found, what thresholds were set or confirmed, and what residual risks were accepted with named owners. A validation summary that records only that "the model performed adequately" does not satisfy the evidentiary standard SR 11-7 expects.

Model risk governance: board oversight and organizational structure

SR 11-7 draws a clear line between model validation and model risk governance: validation is a technical activity; governance is an organizational one. For AI systems, that distinction carries real weight.

Effective model risk governance requires board-level ownership, beyond compliance sign-off alone. Directors need enough AI literacy to understand what a system can do, recognize when outputs warrant scrutiny, and ask whether validation evidence is complete before a high-risk model reaches production.

The Three-Layer Governance Structure

Most financial institutions that satisfy SR 11-7 expectations organize model risk governance across three layers:

• Board or board risk committee: sets the institution's overall risk appetite for model use, receives periodic reporting on model inventory status, validation backlogs, and material model failures, and approves the model risk management framework itself.
• Senior management and the model risk function: owns the model risk policy, maintains the model inventory, allocates validation resources, and reports material model risk exposures to the board.
• Model owners and developers: document intended use, maintain model performance data post-deployment, and initiate revalidation when use conditions change.

For LLMs and agents, each layer faces new obligations. Boards approving a credit decisioning LLM need reporting that covers output consistency and demographic parity gaps, going well beyond accuracy on a static test set. Model owners extending an agent into a new workflow need to treat that extension as a material change triggering revalidation, not a configuration update.

What Changes With AI

The governance structure itself does not need to be rebuilt, but several assumptions embedded in it do:

• Model inventory scope: Shadow AI deployment through unregistered fine-tuned models, third-party LLM APIs added without risk review, and off-the-shelf generative tools processing regulated data creates inventory gaps that traditional governance processes were not designed to catch.
• Materiality thresholds: SR 11-7 asks institutions to classify models by materiality. LLMs that generate customer-facing text or inform credit decisions are material by most definitions, even when deployed as API wrappers instead of internally trained models.
• Validation independence: The guidance requires that model validators be independent of model developers. When business units self-deploy LLM APIs, that independence collapses before governance has a chance to intervene.

Building and maintaining a model inventory for AI systems

Every AI model in production is a liability without a record of what it does, who owns it, and whether it is still performing within approved bounds. A model inventory is that record: the canonical source of truth that connects deployment decisions to regulatory obligations and makes governance auditable instead of aspirational.

The fields in that inventory determine whether it functions as a real control or a filing exercise.

What a Complete Inventory Entry Must Contain

Each system registered in the inventory should carry enough information that a compliance reviewer unfamiliar with the model could reconstruct its purpose, ownership, and monitoring status from the record alone. At minimum, each entry needs:

• A unique, persistent system identifier that traces the model across the registry, deployment logs, and audit trail, not a project name or display label, but an immutable ID present in every monitoring dashboard and incident record referencing that system.
• Named Model Owner and Governance Lead with role titles and direct contact, plus a documented handoff record if ownership has transferred. An unresolved ownership gap is an audit finding.
• Intended use, affected population, and the decisions the model informs or makes, followed by the risk classification under the applicable framework (SR 11-7 tier, EU AI Act Annex III, NIST AI RMF tier) with the specific provision that produced it cited by name.
• The exact model version hash deployed in production, traceable to the registry entry recording training data provenance, evaluation results, and the approval event authorizing deployment. A semantic version string alone is insufficient.
• Active monitoring status, the specific metrics under surveillance, the threshold value triggering each alert, and the date those thresholds were last reviewed and approved. A system listed as "monitored" without named metrics and numeric thresholds is not monitored in any auditable sense.
• Last evaluation date, evaluation type, and a link to the evaluation record in the audit trail, plus the scheduled next review date and the owner responsible for initiating it.
• Each regulatory obligation the system is subject to, listed as a discrete item with current compliance status and any open gaps named, owned, and dated.

Why Shadow AI Makes This Hard

The inventory only governs what is in it. Shadow AI, models running outside the registry, is where governance collapses in practice. Three channels account for most unregistered deployments:

• Data science teams spinning up fine-tuned models that never enter a registry, bypassing evaluation gates entirely.
• Product teams connecting third-party LLM APIs at the feature level without formal risk review, often under release pressure.
• Business units adopting off-the-shelf generative tools that process regulated data before compliance functions know they exist.

By the time an audit or incident surfaces one of these systems, it may have been running for months with no behavioral baseline on record. That gap is where regulatory obligations go unmet: no documentation, no monitoring, no evidence of conformity. Every field left empty in the inventory is not a neutral omission, auditors treat it as evidence the control was never in place.

Agentic AI and the governance gap SR 26-2 left open

SR 11-7 was written for statistical models with bounded, auditable behavior. Agents break that assumption entirely. Where a credit scoring model produces a single numeric output from a defined feature set, an autonomous agent executes multi-step action sequences, calls external tools, writes to databases, and modifies shared state, often without a human reviewer in the loop at any point.

SR 26-2 extended model risk management to generative AI, but the guidance still frames risk in terms of outputs over actions. That framing misses where agentic risk actually lives.

Where the Governance Gap Shows Up

Three structural properties of agents fall outside what SR 11-7 and SR 26-2 were designed to govern:

• Action consequences are irreversible in ways model outputs are not. A generated summary can be reviewed before it influences a decision. A tool call that submits a wire transfer, updates a customer record, or fires an API request to a third-party system has already changed external state before any governance layer sees it.
• Reasoning chains are not logged by default. Traditional model validation records inputs and outputs. An agent's intermediate steps, the tool selections, the sub-goal decompositions, the conditional branches taken, typically go unrecorded unless the inference infrastructure is explicitly built to capture them.
• Risk compounds across steps. A single agent action that falls within acceptable bounds can combine with two subsequent actions to produce an outcome no individual step would have flagged. Validation frameworks built around per-output evaluation have no native mechanism for catching emergent multi-step failure modes.

Overlapping obligations: EU AI Act and NIST AI RMF in an MRM context

Two regulatory frameworks now shape how financial institutions think about AI model governance, and they pull from different traditions without being incompatible.

The EU AI Act classifies credit scoring, loan underwriting, and employment screening systems as high-risk under Annex III, which triggers conformity assessment obligations under Article 43, accuracy and robustness requirements under Article 15, and logging obligations under Article 12. For example, a credit-scoring LLM deployed at a bank would require a conformity assessment before go-live and monthly Article 12 audit logs post-deployment. The NIST AI RMF, by contrast, organizes governance into four functions: Govern, Map, Measure, and Manage, all defined in the NIST AI Risk Management Framework.

Where SR 11-7 practitioners will find the most natural entry point is in the mapping between frameworks:

Neither framework replaces SR 11-7 for U.S.-supervised institutions. But both extend its logic into territory SR 11-7 was not written to cover: generative outputs, agentic decision chains, and probabilistic behavior that resists the deterministic validation methods traditional model risk management was built around.

Model Risk Governance Tools and the Current Market Overview

The AI governance tools market has grown quickly, but most vendors still operate within one of two lanes: pre-deployment evaluation or post-deployment observability. Few cross both, and fewer still extend into the enforcement layer that model risk governance actually requires.

Here is how the major players currently sit:

• Credo AI focuses on AI governance documentation and policy management. It helps teams build risk registers, map regulatory obligations, and generate audit artifacts, and does this well. Where it currently stops short is runtime: Credo AI does not monitor live model outputs, enforce behavioral thresholds at inference time, or flag drift in production. The audit trail it produces reflects what was planned and approved, not what the model is doing now.
• IBM watsonx.governance covers governance and compliance within the IBM ecosystem, with solid tooling for model documentation, fairness measurement, and explainability reporting. The constraint is architectural: organizations running models outside the IBM stack currently get incomplete coverage, and runtime enforcement gates are not a native capability.
• Arize AI sits on the observability side, with strong production monitoring for drift, data quality, and model performance degradation: it surfaces what is going wrong with real depth. But observation and enforcement are different controls. Arize currently logs and alerts; as of now, it does not block at inference time.

Openlayer spans the full lifecycle, covering pre-deployment evaluation, production monitoring, and active runtime enforcement, with model validation tools and enforcement gates that block outputs or halt promotion when defined thresholds are breached. The evaluation results, metric scores, and flagged failure modes from development become the evidentiary record that satisfies SR 11-7 model validation documentation requirements, not a separate compliance artifact assembled after the fact.

How Openlayer Extends Model Validation Across the Full MRM Lifecycle

Openlayer is built to close the gaps that SR 11-7 and its LLM-era extensions expose across every stage of the model lifecycle. Where traditional MRM tools stop at documentation review or periodic backtesting, Openlayer runs continuous evaluation, behavioral testing, and production monitoring as a unified workflow, so validation evidence accumulates in real time instead of arriving as a point-in-time snapshot before an exam.

Pre-Deployment Validation

Before any model reaches production, Openlayer runs structured evaluation suites across the dimensions MRM frameworks require. For LLMs, that means groundedness scoring, toxicity detection, semantic drift measurement, and demographic parity checks, all executed against version-controlled test sets. For agents, evaluation extends to tool-call accuracy, task completion rates across multi-step sequences, and reasoning chain integrity. Every result is written to an immutable audit record that carries the model version hash, test configuration, threshold values, and pass/fail outcomes, giving validators the evidentiary artifact SR 11-7 expects, not a summary report assembled after the fact.

Production Monitoring and Ongoing Validation

Post-deployment, Openlayer maintains the behavioral baseline set during pre-deployment validation and tracks deviation against it in production. When output distributions shift, demographic parity gaps widen past approved thresholds, or groundedness scores fall below the deployment floor, Openlayer triggers alerts and, where enforcement gates are configured, blocks further inference until a named owner reviews and clears the flag. That blocking step is what separates enforcement from observation; a drift alert that notifies without halting inference is a monitoring signal, not a governance control.

Governance Documentation and Audit Readiness

Across both stages, Openlayer generates and maintains the documentation artifacts that model risk governance requires:

• Model cards and intended-use records tied to specific version hashes in the model registry, so any deployed artifact can be traced back to its training data, evaluation results, and approval event.
• Ongoing monitoring logs that satisfy SR 11-7's periodic review requirements and supply the post-market monitoring records required under EU AI Act Annex IV.
• Incident records structured around the four-element specification that auditors inspect: input record, output record, expected output, and root-cause classification.
• Change management records linking model updates to re-validation events, so validators can confirm that a version change triggered the appropriate evaluation cycle instead of bypassing it.

These records are not assembled on demand for an audit. They accumulate continuously as models run, so the evidentiary gap that typically opens between deployment and review never forms.

Final Thoughts on Model Validation, Governance, and AI Risk Management

The core ask from SR 11-7 has not changed: show that your model does what it claims, in the conditions it will actually face, with a record that survives examination. What has changed is the surface area you need to cover when your models are LLMs and agents instead of regression scorecards. Your validation approach, your monitoring thresholds, and your audit artifacts need to reflect that shift. Reach out to the Openlayer team to see how that evidence record gets built in practice.

FAQ

How do SR 11-7 model validation requirements apply to LLMs and agents?

SR 11-7's three core requirements, independent validation, documentation standards, and governance accountability, apply directly to LLMs and agents, but the validation methods must expand considerably. Where traditional validation relied on backtests and sensitivity analyses against structured inputs, LLM and agent validation requires behavioral testing across adversarial prompts, fairness auditing across demographic groups, and continuous drift monitoring post-deployment, because a model that passed evaluation in March may behave differently in July without any code change.

What's the difference between model validation and model risk governance under SR 11-7?

Model validation is a technical activity, independent review of whether a model performs as claimed across the range of conditions it will encounter in production. Model risk governance is the organizational infrastructure that acts on those findings: model inventory management, tiered risk classification, named ownership, and escalation paths when performance falls outside approved parameters. Validation without governance means rigorous findings can go unacted on; governance without validation means the organizational structure has nothing credible to enforce against.

Should I use Credo AI or Openlayer for SR 11-7 and EU AI Act model risk governance?

Credo AI covers policy workflows and audit artifact generation but does not monitor live model outputs, enforce behavioral thresholds at inference time, or flag drift in production, the audit trail it produces reflects what was planned, not what the model is doing now. Openlayer runs pre-deployment evaluation, production monitoring, and active enforcement gates in a single workflow, so the evaluation results and flagged failure modes from development become the evidentiary record that satisfies SR 11-7 documentation requirements, not a separate compliance artifact assembled after the fact.

How do I build a model inventory that satisfies SR 11-7 and EU AI Act Annex IV and Article 12 requirements?

Each inventory entry needs a persistent system identifier traceable across deployment logs and audit records, named Model Owner and Governance Lead with role titles, an exact model version hash linked to training data provenance and approval events, and active monitoring status with specific metrics and numeric alert thresholds documented. A field left empty is not a neutral omission, auditors treat it as evidence the control was never in place, and shadow AI running outside the registry creates the specific gap where EU AI Act Annex IV documentation and Article 12 logging obligations go unmet.

What monitoring controls does SR 26-2 expect for agentic AI systems that SR 11-7 didn't cover?

SR 26-2 extended model risk management to AI systems, but its risk framing remains focused on outputs over actions, which misses where agentic risk actually lives. For agents, the meaningful control point is inference time, not review time: a tool call that submits a wire transfer or writes to an external database has already changed external state before any post-hoc log is reviewed. Governance programs applying SR 26-2 to agents need tool call authorization with explicit allow lists, sequence-level monitoring across full multi-step execution paths, and enforcement gates that block or suspend the workflow when intent-to-tool alignment falls below defined thresholds, going beyond drift alerts that merely notify after the action has executed.