SR 11-7 Compliance: Managing Model Risk with On-Premise AI Hardware

SR 11-7 does not ban third-party AI models. It requires a bank to validate any model it uses to the same standard as one built in-house: full access to how the model was developed, what data trained it, and how it behaves under stress. That's where most vendor-hosted AI deployments fail, because a hosted API withholds by design the internals a validator needs to sign off. On-premise deployment doesn't change what SR 11-7 asks for. It changes whether the bank can actually produce it.

What SR 11-7 actually requires

SR 11-7 is the joint Federal Reserve and OCC supervisory guidance on model risk management, published in April 2011 and still the governing standard for how U.S. banking organizations handle model risk. It defines a model broadly: any quantitative method, system, or approach that applies statistical, economic, financial, or mathematical theories to process input data into quantitative estimates. A large language model used to draft credit memos, screen transactions, or support underwriting decisions falls inside that definition, and examiners have been extending SR 11-7 expectations to AI and machine learning systems for years.

The guidance rests on three pillars. First, sound model development, implementation, and use: the bank has to be able to explain the model's conceptual soundness, the data it trained on, and the logic connecting inputs to outputs. Second, effective challenge through independent validation, carried out by staff with the authority and technical skill to actually contest the model builders' choices rather than rubber-stamp them. Third, governance — a board and senior management that own model risk as an enterprise risk category, with policies, inventories, and escalation paths that make the first two pillars enforceable instead of aspirational.

Under the first pillar, documentation has to let someone unfamiliar with the model understand what it does, why it was built that way, what alternatives were considered and rejected, and where its limitations lie. That includes the training data, the testing performed before deployment, and the ongoing outcomes analysis afterward. A vendor's marketing one-pager doesn't satisfy this. Neither does a model card that describes capabilities without describing internals.

Vendor models get no exemption

SR 11-7 is explicit that third-party and vendor-supplied models must be validated to the same standard as internally developed ones. The guidance acknowledges that vendor models create friction, since the modeling expertise sits outside the bank and the vendor may treat its methodology as proprietary, but it doesn't lower the bar in response. A bank relying on a vendor model is still expected to understand its logic, test it against the bank's own data, and monitor its performance over time. If the vendor won't disclose what the model is doing internally, the bank ends up doing due diligence on a black box — which satisfies neither the letter nor the intent of the guidance.

That's precisely the position a regulated institution lands in when it builds workflows on a general-purpose commercial AI API. The provider controls the weights, the training data composition, the fine-tuning history, and the version currently answering queries. The bank sees an API endpoint and a set of published benchmarks. Providers update production models routinely, often silently, and when that happens the bank has no visibility into what changed, no ability to re-run its own validation suite before the new version goes live, and often no reliable way to confirm a change occurred until behavior shifts.

Where on-premise deployment changes the compliance posture

Running inference and fine-tuning on hardware inside the institution's own environment doesn't automatically satisfy SR 11-7. Validation, monitoring, and governance are organizational disciplines, not features bundled with a server rack. What on-premise deployment does is remove the structural barriers that make those disciplines impossible with an opaque hosted API.

Model versioning and change control matter first. SR 11-7 monitoring depends on knowing exactly which model version is in production and when it changed. On sealed, air-gapped hardware, the institution controls every model update. Nothing changes without the bank initiating it, so version changes trigger the re-validation the guidance calls for instead of happening invisibly on a provider's release schedule.

Data lineage is the second piece. A validator has to trace what data trained or fine-tuned a model to assess conceptual soundness and identify bias. When fine-tuning happens inside the institution's own environment, on its own data, on hardware that never phones home, the lineage is whatever the bank's own MLOps process records. There's no provider-side training corpus the bank has to take on faith.

Testing access follows the same logic. Independent validators need to run their own test suites against the model, including adversarial and edge-case inputs, and observe the model's internals well enough to diagnose why it behaves a certain way. That's straightforward against a model running on the bank's own infrastructure. It's far more constrained against a rate-limited, terms-of-service-governed external API, where extensive adversarial probing may not even be permitted.

Data exposure during use raises a related concern. Sending customer financial data, credit files, or transaction records to an external inference endpoint creates a data governance question that sits alongside, and often complicates, the model risk question. Keeping inference on-premise removes that transmission entirely, simplifying the scope of what a validator and a privacy officer both have to assess.

And audit trail continuity closes the loop. Ongoing monitoring under SR 11-7 means benchmarking and process verification over time, not a one-time validation at launch. That requires stable, complete logs of model inputs, outputs, and performance metrics. A sealed on-premise system can log everything locally, under the bank's own retention policy, without depending on a vendor's logging tier or export terms.

What this looks like in practice

A bank using Element 31's Forge for internal code assistance, or Czar as a sandbox for fine-tuning a model on proprietary risk data, runs both entirely inside its own network boundary. Chassis provides the hardware layer those workloads run on, sealed and air-gapped, so no inference call and no training run leaves the institution's control. That architecture doesn't certify a bank as SR 11-7 compliant on its own — compliance still requires the bank to write the documentation, staff the independent validation function, and build the governance structure the guidance demands.

What the architecture provides is the precondition for doing that work honestly. A validator reviewing a model that runs on hardware the bank owns can request the training data, run adversarial tests without a rate limiter or a terms-of-service question in the way, and confirm that the version in production today is the version validated last quarter. A validator reviewing a hosted third-party API is largely reviewing what the vendor chose to disclose, then hoping the next silent update doesn't undo the conclusion.

For an institution that has to answer to Fed or OCC examiners about how it manages AI model risk, that difference is the whole argument for keeping the model, the data, and the audit trail inside the walls it already controls.

Sources: Federal Reserve, Supervisory Letter SR 11-7, April 2011.