Back to notes

March 20, 2026 · 5 min read

Regulatory Pressure Is Quietly Changing How We Build Interpretable Models

Nobody announced a mandate, but the compliance questions on every new model project have gotten pointed enough that interpretability stopped being optional and started being a design requirement.

Hot TakeCompliance

Nobody handed us a new regulation to comply with overnight. What changed is quieter than that — the discovery and diligence questions on every model project touching consumer-facing decisions have gotten noticeably more specific over the last couple of years, and "can you explain this decision to the person it affected" has moved from a nice-to-have to a question that stalls a project if the answer isn't ready.

What's actually driving this

A patchwork of state-level AI decision disclosure requirements, growing enforcement attention on automated decision-making in lending and employment contexts, and clients' own legal teams getting more conservative in anticipation of rules that haven't fully landed yet. Nobody I've worked with is reacting to an actual enforcement action against them specifically — they're reacting to watching enforcement actions happen to companies that look a lot like them.

The regulation most teams are designing for right now isn't the one that exists yet. It's the one their legal team is confident is coming.

What this changes about how models get built

The practical shift is interpretability moving earlier in the design process instead of being bolted on after a model's already built and someone asks an uncomfortable question. We now default to scoping "can this decision be explained to the person affected by it, in plain language" as a requirement alongside accuracy targets at the start of any model touching credit, hiring, or similar high-stakes consumer decisions, rather than treating it as a nice-to-have.

  • Interpretable model families get a real seat at the table during model selection, not just a fallback if the black-box model gets challenged.
  • Explanation generation (SHAP, LIME, or similar) scoped as a deliverable from day one on regulated-adjacent use cases.
  • Documentation of why a given feature is used and what it means gets written during development, not reconstructed under pressure later.
  • Legal and compliance brought into model scoping conversations earlier than engineering teams are usually used to.

None of this is about predicting exactly what regulation lands where. It's a straightforward bet that the cost of building explainability in from the start is much lower than the cost of retrofitting it under pressure once a regulator, a journalist, or a customer's lawyer asks the question you don't have a ready answer for.