DEV Community

Vaibhav
Vaibhav

Posted on

Model Risk Management for ML: Reproducibility and Lineage Are the Whole Game

#mlops #machinelearning #compliance #insurtech

As ML moves from dashboards to systems that make consequential decisions — pricing, approvals, payouts — the question changes from "is the model accurate?" to "can we govern it?" Banking has done this for years under the name Model Risk Management (MRM). Regulated industries like insurance are now getting the same treatment (NAIC model bulletin, EU AI Act), and the uncomfortable truth for engineers is that MRM, done properly, is almost entirely a data and lineage problem — not a modeling one.

What MRM actually demands

Strip away the governance vocabulary and every requirement lands on your data platform:

  • Reproducibility. Recreate exactly what a model trained on and how it scored a specific decision. That needs versioned data + versioned features + lineage — not "the training set was roughly this snapshot."
  • Per-decision explainability. When someone asks "why was this specific applicant declined?", "the model said so" fails. You need the inputs, the model version, and the reasoning traceable for that one case.
  • Bias/fairness testing. Requires clean, well-understood data and the ability to slice outcomes across groups.
  • Ongoing monitoring. Drift, performance, and data-quality tracked continuously, with the evidence retained.

None of it works if you can't reproduce a decision or trace lineage. MRM without lineage is aspirational paperwork.

The reproducibility test

Ask your platform this: "Show me exactly how decision X from eight months ago was produced." You should be able to return:

{
  "decision_id": "dec-771",
  "model_version": "pricing@2.4.1",
  "feature_set_version": "fs-2026-03-11",
  "input_snapshot": { "...": "as scored, immutable" },
  "training_data_version": "td-2026-02",
  "code_commit": "9a3f1c",
  "scored_at": "..."
}
Enter fullscreen mode Exit fullscreen mode

If any field is "we'd have to reconstruct it," you have model risk you can't yet measure. And here's the catch that bites hardest: lineage is captured as data flows, or it doesn't exist. You cannot retrofit the provenance of a decision made in a pipeline that wasn't built to remember. Retrain, refactor, or move the window and the past is gone.

A minimal, engineer-friendly MRM stack

  1. Model inventory. A living registry of every model in production — purpose, owner, inputs, version. You can't govern what you can't list.
  2. Pinned everything. Model version, feature-set version, code commit, and training-data version travel with every prediction as metadata.
  3. Immutable input snapshots for consequential decisions, stored as-scored.
  4. Independent validation + monitoring with an owner — someone other than the builder checks it, and drift/fairness alerts route to a named person with authority to pull the model.

Build it alongside the model, not after the audit

The teams that struggle aren't the ones with the least sophisticated models — they're the ones who shipped fast on a foundation that can't reproduce, trace, or explain what the models did. Retrofitting is painful and sometimes impossible. Build lineage and reproducibility in from day one and MRM stops being a fire drill.

Full write-up with the insurance/regulatory framing:

Model Risk Management for Insurance AI: The Framework Regulators Will Ask For →

From IntelliBooks' series on the data foundation under insurance AI.

Can your stack reproduce a decision from a year ago end to end? What's the weakest link — features, data versions, or code?

Top comments (0)