SR 11-7 was published by the Federal Reserve in 2011. The models it was written to govern were logistic regressions, gradient boosted trees, time series forecasting models, and credit scorecards. These models had a common set of properties that made them governable under a single framework: they had stable parameters that changed only when explicitly retrained, they operated on structured input features with known distributions, they produced numerical outputs that could be validated against holdout samples, and they could be fully documented in a model card that described their architecture, training data, performance characteristics, and known limitations.
Fifteen years later, banking organizations are deploying AI agent systems that share almost none of these properties. An AI agent does not have stable parameters in the SR 11-7 sense -- its behavior emerges from the interaction of a foundation model, a prompt template, a tool access configuration, a policy layer, and a memory context that evolves with every interaction. It does not operate on structured input features with known distributions -- it processes natural language, documents, and multi-modal data. Its outputs are not numerical scores but actions: sending communications, generating recommendations, routing workflows, and making decisions that affect customers and the institution's risk posture.
The question facing model risk management teams in 2026 is not whether SR 11-7 applies to AI agent systems -- the Federal Reserve has made clear that it does -- but how to adapt the framework's requirements to systems that are structurally different from the models it was written for. This article compares SR 11-7's core requirements dimension by dimension across traditional statistical models and AI agent systems, identifying where the framework translates directly, where it requires reinterpretation, and where entirely new governance structures are needed.
What SR 11-7 Actually Requires
Before comparing how the framework applies to different model types, it is worth restating what SR 11-7 actually mandates. The guidance establishes three core requirements for any model used in decision-making at a banking organization:
Model development and implementation must be documented and subject to review. The organization must understand what the model does, how it was built, what data it uses, and what its limitations are. Documentation must be sufficient for an independent party to evaluate the model's appropriateness.
Models must be independently validated. A party independent from the model's developers must assess the model's conceptual soundness, verify its implementation, and evaluate its performance against independent data. Validation must occur before production deployment and be repeated periodically.
Ongoing monitoring must detect degradation. Models in production must be monitored for changes in performance, changes in input data characteristics, and changes in the environment that could affect the model's reliability. The organization must have processes to respond when monitoring detects degradation.
These requirements are technology-neutral in principle. In practice, the specific methods used to satisfy them -- holdout samples for validation, parameter stability checks for monitoring, model cards for documentation -- were designed for statistical models. Applying them to AI agent systems requires translating the intent of each requirement into methods appropriate for the new model type.
Dimension 1: Model Inventory
Traditional Statistical Models
A traditional model inventory entry describes a self-contained artifact: a logistic regression with 47 input features, trained on 2.3 million records from 2019-2023, producing a probability score between 0 and 1. The model has a fixed architecture, fixed parameters (until explicitly retrained), and a fixed input schema. The inventory entry captures the model's purpose, owner, deployment location, input features, output format, performance metrics, last validation date, and next scheduled review. The model is a discrete, identifiable object that can be pointed to, versioned, and compared across versions.
AI Agent Systems
An AI agent is not a single model. It is a composite system: a foundation model (which may be updated by the provider without the institution's involvement), a prompt template (which shapes behavior but is not a "parameter" in the statistical sense), a set of tool integrations (which define what actions the agent can take), a policy layer (which constrains the agent's behavior), and often a memory or context store (which means the agent's effective behavior evolves over time as context accumulates). Inventorying this as a single "model" misrepresents its complexity. Inventorying each component separately loses the systemic behavior that emerges from their interaction.
| Inventory Dimension | Statistical Model | AI Agent System |
|---|---|---|
| Unit of inventory | Single model artifact (binary, weights file) | Composite system (foundation model + prompt + tools + policy + memory) |
| Parameter stability | Fixed between retraining events | Foundation model weights may change via provider updates; prompt and policy may change independently |
| Input schema | Fixed feature vector with known types and ranges | Variable: natural language, documents, multi-modal data, tool outputs |
| Output type | Numerical score or class label | Actions, recommendations, generated text, tool invocations |
| Version identity | Model version = weights + architecture + feature pipeline | System version = foundation model version + prompt version + tool config version + policy version |
The practical adaptation for model inventory is to treat the AI agent as a system-level inventory entry with explicit sub-component versioning. The inventory entry must capture the version of every component that contributes to the agent's behavior, because a change to any component -- the foundation model, the prompt, the tool access list, the policy rules -- changes the system's behavior in ways that may require revalidation.
Dimension 2: Validation
Traditional Statistical Models
Validation of a statistical model follows a well-established methodology: assess conceptual soundness (is the model architecture appropriate for the problem?), verify implementation (does the code correctly implement the specified model?), and evaluate performance on independent data (does the model perform acceptably on data it was not trained on?). The performance evaluation uses holdout samples, cross-validation, out-of-time testing, and benchmark comparisons. The validation produces quantitative metrics -- AUC, KS statistic, Gini coefficient, calibration curves -- that can be compared against thresholds and tracked over time.
AI Agent Systems
Holdout sample validation does not translate to AI agent systems for three reasons. First, agent behavior is not a function of input data alone -- it depends on the interaction between the input, the prompt context, the available tools, the policy layer, and potentially the accumulated memory state. A "holdout sample" would need to replicate all of these dimensions, not just the input data. Second, agent outputs are actions, not scores. Evaluating whether an action is "correct" requires defining correctness in terms of business rules, regulatory constraints, and contextual appropriateness -- which is a judgment that cannot be reduced to a single metric. Third, the same input can produce different outputs on different runs because foundation models are non-deterministic, which means validation must account for output variance that does not exist in statistical models.
The validation methodology that SR 11-7 reviewers are increasingly accepting for AI agent systems is behavioral test suites: structured collections of scenarios that test whether the agent behaves correctly across a representative range of situations. A behavioral test suite for a credit decisioning agent might include:
- Boundary cases: applications at the approval/denial threshold, testing that the agent's policy evaluation is consistent
- Regulatory compliance scenarios: applications involving protected class attributes, testing that the agent's behavior satisfies fair lending requirements
- Tool usage validation: scenarios requiring specific tool invocations, testing that the agent uses the correct tools with the correct parameters
- Policy adherence tests: scenarios designed to elicit policy-violating behavior, testing that the policy layer correctly constrains the agent
- Edge cases: unusual inputs, ambiguous scenarios, and adversarial prompts, testing the agent's behavior at the boundaries of its designed operating range
Behavioral test suites are run against the complete agent system -- not just the foundation model -- because it is the system's composite behavior that is deployed in production. Test results are recorded as pass/fail with detailed traces showing the agent's reasoning and policy evaluation for each scenario. This trace-based validation evidence replaces the quantitative metric reports used for statistical models.
Dimension 3: Documentation
Traditional Statistical Models
Model documentation for statistical models follows the model card pattern: a structured document describing the model's purpose, architecture, training data, feature engineering pipeline, performance metrics, known limitations, and intended use conditions. The model card is a complete description because the model is a self-contained artifact. If you have the model card and the model binary, you understand the model.
AI Agent Systems
A model card is insufficient for an AI agent system because the system's behavior is not determined by the model alone. Documenting the foundation model's architecture and training data describes one component of a multi-component system. The documentation for an AI agent must additionally cover:
- Policy layer specification: The explicit rules that constrain the agent's behavior, including what actions are permitted, what actions are prohibited, what conditions trigger escalation to human review, and what authority boundaries apply. This is not documentation that describes intended behavior -- it is the executable specification that enforces behavior.
- Tool access manifest: Every external tool, API, database, and service the agent can access, along with the permissions granted for each. The tool access manifest defines the agent's action space -- the set of things it can do in the world.
- Trace schema: The structure of the decision traces the agent produces, documenting what information is captured for each decision, how traces are stored, and how they can be queried for audit and validation purposes.
- Prompt template and context specification: The prompt template that shapes the agent's behavior, including any system instructions, few-shot examples, and dynamic context injection patterns.
- Memory and state management: How the agent's context evolves over time, what information is retained between interactions, and how memory state affects decision behavior.
| Documentation Artifact | Statistical Model | AI Agent System |
|---|---|---|
| Core document | Model card | System specification (model card + policy layer + tool manifest + trace schema) |
| Behavior specification | Implicit in model architecture and training data | Explicit in policy layer rules |
| Action space description | Output range (score boundaries, class labels) | Tool access manifest with per-tool permissions |
| Decision evidence format | Model output + input features | Decision trace (input facts + rules evaluated + tool calls + outcome) |
| Change documentation | Retraining record with new performance metrics | Component-level change log (which component changed, what changed, validation results) |
The documentation challenge for AI agent systems is that the system's documentation is never complete in the way a model card is complete. The foundation model's behavior cannot be fully specified because it is a general-purpose system operating under prompt guidance. What can be completely specified -- and what SR 11-7 reviewers increasingly focus on -- is the policy layer, the tool access manifest, and the trace schema. These are the components where the institution exercises direct control, and they are the components where documentation must be authoritative.
Dimension 4: Performance Monitoring
Traditional Statistical Models
Performance monitoring for statistical models focuses on detecting distribution shift and model degradation. The monitoring system tracks input feature distributions, comparing live data to training data distributions using statistical tests (Population Stability Index, Kolmogorov-Smirnov). When input distributions shift beyond defined thresholds, the monitoring system alerts the model risk team that the model may be operating outside its validated range. Output monitoring tracks prediction accuracy against observed outcomes, detecting calibration drift over time.
AI Agent Systems
Input distribution monitoring does not translate directly because AI agents process unstructured data without fixed feature vectors. Instead, performance monitoring for AI agents must track a different set of signals:
- Prompt and policy changes: Any modification to the prompt template, policy rules, or tool access configuration changes the agent's behavior and should trigger monitoring alerts equivalent to a model retraining event.
- Foundation model version changes: When the model provider updates the underlying model, the agent's behavior may change even though no institutional component changed. Monitoring must detect behavioral shifts that coincide with provider model updates.
- Tool behavior changes: If an external API the agent uses changes its behavior, response format, or availability, the agent's composite behavior may be affected. Tool endpoint monitoring is a form of input monitoring specific to agent systems.
- Policy violation rates: The rate at which the policy layer blocks agent actions is a critical performance signal. A sudden increase in policy violations may indicate that the foundation model's behavior has shifted. A sudden decrease may indicate that the policy layer is not being evaluated correctly.
- Behavioral consistency metrics: Running a fixed set of behavioral test cases against the live agent system on a regular cadence (daily or weekly) detects behavioral drift that may not be visible in aggregate metrics. If the agent's response to a specific scenario changes without any known system change, something has shifted.
McKinsey's analysis of AI in banking found that institutions with mature monitoring for AI agent systems track policy violation rates and behavioral consistency metrics as their primary early-warning signals -- replacing the distribution shift metrics that serve the same function for statistical models.
Dimension 5: Ongoing Model Risk Review
Traditional Statistical Models
SR 11-7 requires periodic revalidation of models, typically on an annual cycle. The revalidation assesses whether the model still performs within acceptable parameters, whether the business environment has changed in ways that affect the model's applicability, and whether the model's documentation remains current. Annual revalidation works for statistical models because these models are stable between retraining events -- if the model was valid in January and nothing has changed, it is likely still valid in June.
AI Agent Systems
Annual revalidation is insufficient for AI agent systems because the system can change between review cycles in ways that statistical models cannot. A foundation model provider update, a prompt modification, a policy rule change, or an accumulation of memory context can each alter the agent's behavior between annual reviews. Waiting twelve months to assess whether the system is still performing as validated creates an unacceptable governance gap.
The adaptation required is continuous monitoring with event-triggered revalidation. The annual review cycle still applies as a comprehensive assessment, but specific events should trigger interim revalidation:
- Foundation model version changes (provider-initiated or institutional)
- Policy rule modifications above a defined materiality threshold
- Tool access configuration changes (new tools added, permissions modified)
- Behavioral consistency test failures (the agent's response to a fixed scenario has changed)
- Policy violation rate anomalies (significant increase or decrease from baseline)
- Regulatory or business environment changes that affect the agent's operating context
Each event-triggered revalidation runs the behavioral test suite against the current system configuration and produces a validation report that documents what changed, how the change affected behavior, and whether the system still operates within its validated parameters. This creates a continuous validation record that supplements the annual comprehensive review.
| Review Dimension | Statistical Model | AI Agent System |
|---|---|---|
| Review cadence | Annual revalidation | Continuous monitoring + event-triggered revalidation + annual comprehensive review |
| Trigger for interim review | Retraining, performance degradation, material model change | Foundation model update, policy change, tool config change, behavioral drift, violation rate anomaly |
| Validation method | Holdout sample performance metrics | Behavioral test suite execution with trace-based evidence |
| Evidence artifact | Validation report with quantitative metrics | Validation report with behavioral test results + decision traces + policy evaluation records |
| Scope of review | Model performance and documentation currency | System-level behavior across all components (model + prompt + policy + tools + memory) |
The Structural Addition: A Deterministic Policy Layer
Across all five dimensions, one structural requirement emerges consistently: SR 11-7 reviewers now expect AI agent systems to include a deterministic policy layer that produces auditable decision rationales.
This is not merely a documentation requirement. It is an architectural requirement. The policy layer is the component that makes the rest of the SR 11-7 framework functional for agent systems:
- For inventory: The policy layer is the component the institution fully controls and can fully specify. While the foundation model's complete behavior cannot be inventoried, the policy layer's rules can be.
- For validation: Behavioral test suites test the agent against the policy layer's rules. The policy layer defines what "correct behavior" means in concrete, testable terms.
- For documentation: The policy layer is the executable specification of the agent's authorized behavior. It replaces the implicit behavior specification of a statistical model's architecture with an explicit, human-readable rule set.
- For monitoring: Policy violation rates and behavioral consistency against policy rules are the monitoring signals that replace distribution shift metrics.
- For ongoing review: Policy changes are the event triggers for revalidation. The policy layer's version history provides the change record that informs review scope.
The policy layer must be deterministic in the specific sense that SR 11-7 requires: given the same input facts and the same policy version, the policy evaluation must produce the same outcome every time. This determinism is what makes the agent system auditable. The foundation model is not deterministic -- it produces variable outputs. The policy layer is the component that converts variable model outputs into governed, reproducible decisions. As Gartner's research on model risk management concludes, financial institutions that have successfully adapted SR 11-7 for AI agents have done so by centering the policy layer as the primary governance surface, treating the foundation model as an input to a governed decision process rather than as the decision-maker itself.
The SEC's staff guidance on AI reinforces this direction. When the SEC requires that AI-assisted recommendations be explainable and that the basis for recommendations be documented, they are describing the output of a deterministic policy evaluation -- not the output of a foundation model inference. The policy layer is the component that generates the "basis for recommendation" that regulatory documentation requires.
Practical Implications for MRM Teams
For model risk management teams adapting their SR 11-7 processes to cover AI agent systems, the practical roadmap has three priorities:
First, expand the model inventory to treat agent systems as composite entries. Each agent system should be inventoried with explicit sub-component versioning: foundation model version, prompt template version, policy layer version, tool access configuration version. A change to any component should be recorded as a system-level change event.
Second, develop behavioral test suites as the primary validation methodology. Work with the agent's business owner to define the scenarios that represent the agent's operating range, including boundary cases, regulatory compliance scenarios, and adversarial edge cases. Run these test suites before production deployment and at every event-triggered revalidation. Store test results with full decision traces as the validation evidence artifact.
Third, require a deterministic policy layer as a precondition for production deployment. An AI agent system without an explicit, versioned, deterministic policy layer cannot satisfy SR 11-7's documentation, validation, and monitoring requirements. The policy layer is not optional governance overhead -- it is the structural component that makes SR 11-7 compliance achievable for non-deterministic AI systems.
The institutions that have moved furthest in adapting SR 11-7 for AI agents have not abandoned the framework. They have recognized that the framework's intent -- ensuring that models used in decision-making are understood, validated, documented, monitored, and reviewed -- applies to any decision-making system, regardless of its architecture. What changes is the method used to satisfy each requirement. The policy layer is the methodological bridge that translates SR 11-7's requirements from the world of stable statistical models to the world of adaptive AI agent systems.
For a deeper exploration of the governance architecture that supports this adaptation, see How Financial Services Teams Are Governing AI Decisions in 2026 and Decision Traces: The Audit Log Pattern That Makes AI Systems Defensible.