Runtime controls in your stack
Bias checks, output validation, human-review gates, content filters — the controls your MRM team already specified now execute and emit signed evidence at runtime.
For AI in Financial Services
When the OCC, CFPB, NYDFS, or a bank counterparty asks what your AI workflow actually does at runtime, an MRM binder and a SOC 2 letter aren’t the answer. Glacis runs inside your infrastructure, instruments one production AI workflow with runtime controls, and produces signed evidence receipts MRM, internal audit, and examiners can verify — with zero sensitive-data egress.
Or read the SR 11-7 & AI guide →
The gap
SR 11-7 expects effective challenge, independent validation, and ongoing monitoring. Your model risk program documents all of it — but the guidance was written before generative AI, before non-deterministic outputs, before agentic workflows that call tools and rewrite data.
Examiners and counterparties have shifted from “show me the policy” to “show me the runtime evidence.” OCC, CFPB, and NYDFS inquiries increasingly ask which controls fired on a specific decision, not which controls exist on paper.
The Sprint scopes that runtime layer on one production AI workflow in three weeks — runtime controls, signed receipts, and an evidence pack that maps to your existing MRM framework.
How the sprint runs
Glacis instruments runtime controls beside your existing model-risk pipeline, signs each control outcome, and packages an evidence pack MRM and examiners can verify without seeing customer data.
Bias checks, output validation, human-review gates, content filters — the controls your MRM team already specified now execute and emit signed evidence at runtime.
Customer data, model inputs, and proprietary algorithms stay inside your infrastructure. Hashes and signed metadata are the only things that cross the boundary.
Timestamped, third-party notarized, cryptographically signed receipts assembled into an evidence pack mapped to SR 11-7, fair-lending, and counterparty review language.
Where evidence matters most
01 / VALIDATION
Prove your validation tests actually ran against production models. Not recreated for audit, not simulated — the real thing, timestamped and notarized.
EXAMINER · “Show me the validation runs on this quarter’s model.”
02 / MONITORING
Every control check, every threshold evaluation, every human review decision — captured as verifiable evidence. Continuous, not periodic.
EXAMINER · “What controls fired between examinations?”
03 / FAIR LENDING
Prove your bias controls executed on every decision. Cryptographic evidence that fairness checks ran — without exposing individual applications.
CFPB · “Did the fairness check run on this denial?”
04 / VENDOR AI
When you use vendor AI, prove your oversight controls executed. Evidence that you validated vendor outputs, not just that you have a policy to.
OCC · “Show me the oversight on the vendor model.”
What MRM gets
import { attest } from '@glacis/runtime'; const receipt = await attest({ workflow: 'underwrite.decision', policy: 'mrm.fairlending.v3', decision: 'PASS', rules: ['fairness.adverse_impact'], }); // → signed OVERT receipt; no customer data egress
Direction of travel
The OCC, Fed, and FDIC are paying attention. The EU AI Act treats credit scoring as high-risk. State regulators are adding AI-specific requirements to existing frameworks.
The pattern is consistent: regulators want evidence that AI governance is operational, not just documented. They want to see that controls executed, not just that they were planned.
Institutions that can demonstrate continuous, verifiable AI governance will face less friction. Those that can’t will face more scrutiny, more MRAs, and more constraints on AI adoption.
Related guides
Three weeks. One production AI workflow. Runtime controls instrumented inside your stack, and an evidence pack mapped to SR 11-7 and counterparty review. No rip-and-replace.
Or learn how continuous attestation works →