Bringing AI into your model risk program

Model-risk teams already have a framework for this. SR 26-2 places generative AI outside its formal scope and still expects it governed under the same principles, so the program needs extending, not reinventing. The challenge is that LLMs behave unlike the statistical models the program was built around: they're non-deterministic, prompt-sensitive, and easy to adopt without anyone telling model risk.

This brief walks the four pillars of the model risk guidance and what each looks like when the model is an LLM.

The hard part of an AI model inventory is completeness. LLMs enter firms through application features, copilots, and agents, often faster than any intake process tracks.

Deriving the inventory from the request path solves this structurally: if a model is called, it is observed and inventoried.

Ongoing monitoring for an LLM means more than availability. It means watching usage, cost, and governance findings (the rate of blocked prompts, redactions, and policy violations) as behavioral signals.

Captured inline, these become the monitoring evidence SR 26-2 expects, attributable by team and workflow.

Effective challenge and independent validation depend on documentation a reviewer can trust. For AI, the most credible documentation is an immutable record of what the model was permitted to do and what it actually did.

A tamper-evident audit trail serves as that record: versioned policy plus a hash-chained history that can't be quietly edited after the fact.

The governance pillar is about controls and accountability. Policy-as-code that your compliance and model-risk teams can read, instead of rules buried in application code, keeps the control owner and the control aligned.

Meilynx supplies the inventory, monitoring, documentation, and controls; your validators keep the judgment. The program stays yours; it now covers the models that arrived last.