DocsPrograms

Model & AI governance

Updated 2026-10-07

Model and AI governance in Zovos is the Model & AI group of the sidebar, which holds two items. Model risk is your model risk management screen, and it has two tabs. The Model inventory tab is the register of your institution's models. The Model governance tab is the pack that documents how Zovos governs its own AI agents, for when an examiner asks about the vendor sitting in your compliance stack. AI systems is your inventory of AI use cases, including the AI embedded in software you bought. Each tab of Model risk appears only for people who can read it. At a smaller bank or credit union this hat usually sits on the CRO, the CCO, the CFO, or a fractional model risk officer. A larger institution typically gives it to a dedicated model risk team.

The model inventory and the AI systems registry are deliberately separate registers that cross-link, rather than one list with a checkbox.

They answer different questions. A model is a quantitative method producing an estimate you rely on. Examples are allowance, asset-liability, credit scoring, fraud, AML/CFT transaction monitoring, valuation and stress testing models. An AI system is any use of AI in the institution, including tools with no quantitative output at all: an assistant, a chatbot, a document summariser, a feature switched on inside a product you already licence. Forcing them into one register makes both worse. Cross-linking means a vendor model that is also an AI system appears in both without duplicated data.

Each model records its type, its deployment type, the vendor (linked to your third-party register), the version, the first-line owner, the developer, its purpose, and its inputs and outputs. Deployment types include spreadsheet or end-user computing, because a spreadsheet the institution relies on is a model whatever it is stored in.

Tiering runs on the same 5 by 5 engine as the risk register, so the tier is derived rather than typed. Each model carries a written tier rationale. The model record itself moves through draft, pending approval, changes requested, approved, and retired. A returned submission lands in changes requested. The model also has a separate lifecycle state of proposed, in use, under review, or retired. A use approval under maker-checker gates whether the model may be used at all.

The model's Change log is the only way its version moves. Each change records what changed, who made it, and a materiality determination made at the time. Entries are append-only, so a change recorded in error is corrected by recording another one. A material change is acted on rather than noted. The model goes under review, its next validation is pulled forward, and a model already approved for use goes back through the use approval. The model's Dependencies panel maps which models feed it and which it feeds, read from the links you draw between models, so you know what sits downstream of a change.

A completeness reconciliation sweeps your vendor register and requires every active vendor to be accounted for. Either it maps to a model, or someone records an explicit acknowledgement that it has none. Vendor-embedded models hiding in the vendor list are one of the most common examination findings in this area, and the reconciliation exists to close that hole.

Validations carry a type of full, limited scope, targeted review or annual review. They also carry an explicit independence flag distinguishing an external validator from an internal but independent one, along with the validator's name or firm. A validation moves from scheduled to in progress to pending sign-off to complete.

Completion is a governance act rather than a field you edit. The approver has to be someone other than the person who submitted the validation and other than the model's owner or developer. That constraint is what makes the record mean something.

Each validation also has a workpaper that records the work itself. It has three pillars, which are conceptual soundness, process verification and outcomes analysis. Each pillar carries a rating of not assessed, satisfactory, satisfactory with conditions or unsatisfactory, a narrative, evidence, and preparer and reviewer stamps. Findings raised on the workpaper become ordinary limitations in the same register as every other limitation. Where an outside firm performs the validation, Send upload link gives its delivery contact a time-boxed, revocable link to deliver the report and workpapers without an account or a seat. What the firm delivers lands as unverified evidence on that validation, and the link reaches nothing else.

Validation cadence is set per model and may be annual, semi-annual, quarterly, every two years, every three years, or no fixed cadence, and the choice carries a written rationale. Supervisory guidance on model risk management is explicitly risk-based, and a proportionate cadence at a small institution is a defensible decision when it is documented as one.

Validation findings are recorded as limitations, each with a severity, a compensating control, an owner and a target date. Dispositions run open, acceptance pending, then accepted or remediated. Accepting a limitation runs through maker-checker and requires a time bound once the risk is high enough to matter. The gate fires on either axis: when the limitation's own severity reaches your institution's hard-block tier, or when the model's residual tier does. A low-severity limitation on a critical model is gated too, which is the case people expect to slip through. Remediating one requires an evidence reference. A limitation can be promoted into the findings register so it inherits the same SLA, closure separation of duties and corrective-action-plan machinery as every other issue.

Ongoing monitoring gives each model a plan with a cadence and named metrics. Each metric states its threshold and can carry a unit and numeric lower and upper bounds. Each cycle produces an append-only attestation with a result of within thresholds, breach, or not performed. A breach requires a written summary and can open a linked limitation.

You can import the recorded value of each metric for a period from a CSV file. Re-importing a period restates its value rather than adding a second one. Each metric's recorded values are charted against its bounds, and Zovos proposes a result of within thresholds or breach from them. The proposal sits beside the owner's attested result and does not replace it. The owner's attestation stays the decision, and an attestation that departs from the proposal requires an override rationale.

The AI systems registry is your shadow-AI inventory. Every AI system is registered, whether it was built, bought, or quietly enabled inside a product. Each one is risk-tiered on the same 5 by 5 model and mapped against AI control sets from the shipped corpus, including the NIST AI Risk Management Framework and financial-services and ISO-derived AI management content.

Systems move through intake, assessment, approval, approved, review and retired. The go-live gate runs under maker-checker, so no AI system reaches production because someone flipped a field. Periodic reviews close with an outcome of tier confirmed, re-tiered, or retire system.

New use cases arrive through intake. The proposer's answers derive proposed tier inputs, and the second line works them from an Intake queue that shows what is waiting, what is flagged and the proposed likelihood and impact. Each proposal is confirmed one system at a time with the answers on screen, and there is no bulk confirm.

The Model governance tab of Model risk holds the pack for the AI you are examined on because you bought it from us. It is assembled from real agent-run telemetry rather than written as marketing copy. It contains an intended-use statement for each agent, its validation telemetry, token usage and cost controls, and a section-by-section mapping to supervisory expectations for model risk management and transaction-monitoring validation. Export PDF puts it in your binder. An examiner session whose grant covers the frameworks the pack maps to can open the Model governance tab and read the underlying agent runs inside the grant's frameworks and date window. Runs of the internal audit agents stay behind the internal audit wall. Note the boundary. This pack reports on the platform's own model usage. Your models report through the model inventory and your board pack.

There is no statistical computation anywhere in this area. Bias and fair-lending reviews are evidence capture. You record the review type, the performer, the methodology, the protected-class segments and the results your partner produced. Zovos does not run disparate-impact testing itself, and the analysis function says so rather than guessing.

Capture is not the whole of it, though. A review carries a scheduled date and publishes it to the obligations calendar, so a review cycle that quietly lapsed reads as overdue, and a completed review can be promoted straight into a finding.

Drift monitoring is an attestation trail rather than telemetry. Zovos records the cadence, the metrics, the thresholds, the metric values you import and each attested result, and proposes a result from those values. It does not stream live metrics from your models or compute back-tests for them.

A framework crosswalk is a mapping and never certification evidence. Zovos is built for United States supervision, and we make no claim of EU AI Act coverage.