Theme 8 — Compliance, Privacy & Model Governance
The reflex this theme builds: if you can't explain it, prove it, or delete it — you don't govern it.
Why this theme matters
In fraud, credit, lending, and insurance, a model is not a piece of software that happens to touch regulated data — the model is a regulated artifact. Regulators examine it, courts subpoena the data around it, and laws constrain what it may learn from and what it must be able to explain. Governance failures are unlike ordinary bugs: they are silent for years — the model scores, the bucket stores, the feature weights — and then catastrophic in an afternoon, when an examiner asks a question, a journalist runs an analysis, or a litigation discovery request lands. Nothing broke on the day the failure was created; everything breaks on the day someone looks.
That timing inverts the usual cost curve. A normal bug is cheapest to fix right after it ships; a governance gap is cheapest at design time — an inventory entry, a validation report, a lifecycle rule, a one-day fairness test — and ruinous at audit time, when the same gap becomes a formal finding, a frozen roadmap, a rebuilt model, or a legal event. Every drill here is the same story with different furniture: a control that existed on paper (or in someone's head) but nowhere in the platform. Abbreviations are expanded on first use; the full reference is glossary.md.
The drills
| # | Drill | One-line hook | Problem diagram | ~Difficulty |
|---|---|---|---|---|
| 49 | The Zombie Model | A score nobody recognizes has been deciding loans, unwatched, for four years. | timeline | intro |
| 50 | The Examiner's Question | The model was validated — verbally, by its own builders, with a deck that no longer exists. | sequence | core |
| 51 | The Bucket Named archive-temp-final2 | A discovery request surfaces twelve-year-old applicant data in a bucket with temp in its name. | timeline | core |
| 52 | The Proxy Variable | A distance in kilometers turns out to encode decades of neighborhood demographics. | sequence | advanced |
| 53 | Purpose Creep | Every access was authorized — and the campaign was still a consent violation. | sequence | core |
Best practices — the governance checklist
What to actually do, distilled from drills 49–53:
- Keep a model inventory: every model making or influencing production decisions is registered — owner, deploy date, documentation link, training-data location, downstream dependencies. If it decides and it isn't in the inventory, that is the finding.
- Assign ownership by role, not by person: people leave and teams dissolve; a role survives the reorg. Add "reassign model and data ownership" to every reorg and offboarding checklist, and run a quarterly review that verifies every owner resolves to a live human.
- Make documentation a shipping requirement: model purpose, training data, assumptions, limitations, and known failure modes are written before deployment — no docs, no deploy. The document is the audit trail of thinking that was supposed to happen anyway.
- Require independent validation before deployment, per SR 11-7 (the Federal Reserve's supervisory guidance on model risk): validated by people who didn't build it, producing a written report with challenger comparisons and assumptions testing. "The builders walked us through it" is not validation — it's a demo.
- Give every model a lifecycle: a review date and a retirement plan assigned at birth, under Model Risk Management (MRM). Models without retirement plans become zombies; zombies become two-quarter remediation programs.
- Maintain a data inventory: every store holding customer or applicant data — including buckets, backups, feature stores, and derived datasets — registered with its purpose and retention class. You cannot retain, delete, or defend what you can't enumerate.
- Enforce retention platform-side: lifecycle rules and TTLs (Time To Live — automatic expiry) that delete on schedule with no human in the loop, plus a scanner that flags any store holding data past its class. A retention policy without enforcement is a confession waiting for discovery.
- Propagate deletion through lineage: a deletion request must reach replicas, backups, feature stores, and derived datasets — and be verified by a job that samples for survivors. "Deleted from the main database" while copies persist is worse than not answering.
- Test disparate impact across all features, pre-launch and ongoing: no feature is exempt for being "obviously" neutral — under ECOA (the Equal Credit Opportunity Act), a feature doesn't need to name a protected class to encode one. Search for less-discriminatory alternatives before launch, and monitor fairness per segment in production.
- Make purpose an access-control dimension: data carries its consented purpose as metadata, access grants name a purpose (not just a team), and any new use triggers a consent review. If the platform can't distinguish fraud prevention from marketing, neither can your legal defense.
- Rehearse the examiner's question: once a quarter, pick a random production model and try to produce — within one day — its owner, documentation, validation report, and data lineage. Every gap you find in the drill is a finding you won't receive in the exam.
- Budget governance at design time: an inventory entry, a validation report, a lifecycle rule, and a one-day fairness test are each hours of work when the model is born — and each maps to a multi-month remediation when discovered at audit time. The cost curve is inverted; act on the cheap end.
Back to all drill themes · Abbreviation reference: glossary