Maurice Njoroge | The Notebook
JUL 13 2026 — Policy

So what would a framework written by both sides actually look like?

Last time, I made this argument: most AI accountability frameworks read like they were written by people who've never had to debug a production model at 2 am. Read ithere. That's still true. But complaining about it doesn't get anyone closer to a better framework. I went looking for what "better" would actually take. The first thing I found surprised me.

AI Accountability Frameworks

The EU AI Act's penalty chapter, which contains the real teeth, with penalties of up to €35 million or 7% of global turnover, has been legally applicable for almost a year. In that time, not a single fine has been issued: not by any Member State, not by the AI Office, not by the EU's data protection supervisor. As of a few months ago, only a handful of member states had even finished naming the authority responsible for enforcing it, and the deadline everyone had been building toward was just pushed back again.

That's not a story about engineers ignoring policy. It's a story about everyone still assembling the machinery, regulators included. This changes what "a framework written by both sides" should mean. It's not just engineers finally reading the policy. It's neither side pretending the other has already finished their homework.

Meanwhile, the frameworks that do exist are proliferating faster than anyone can reasonably implement them. NIST's AI Risk Management Framework structures work around four functions, including Govern, Map, Measure, and Manage. ISO/IEC 42001 offers a certifiable management-system standard. The EU AI Act layers binding legal obligations on top of both. On paper, these overlap significantly, and control work done for one often satisfies 60–70% of another. In practice, most teams experience them as three separate homework assignments, not one coherent system, because nobody designed them to be read together from the start.

EU AI Act NIST ISO 42001 Compliance Alignment

Here's what I think a framework written by both sides would actually need.

Start by separating "is this good engineering" from "is this legal."

Good Governance vs Legal Compliance

Passing a NIST risk-mapping exercise and shipping a clean model card feels like doing the work. It isn't the same as classifying a system correctly under a specific legal regime and registering it accordingly. Good technical practice and legal compliance are correlated, not identical. A lot of teams are operating as if the first automatically implies the second. A joint framework needs an explicit, boring, checklist-level bridge between technical maturity and legal classification instead of assuming one covers the other. That bridge is also where the compliance workflow and the engineering workflow stop being two separate homework assignments and become one thing: build the system to be classifiable, and the paper trail writes itself.

Get engineers in the room before the obligations are drafted, not after.

Get engineers in the room

The enforcement gap I opened isn't just a story about slow bureaucracy, but it's a symptom of this."Human oversight" and "post-market monitoring" language gets written by people who don't know, and can't know, what those obligations will require operationally, because the engineers who'd know are never in the drafting room. That's not a hypothetical failure mode. It's the same gap that leaves Member States, years later, still figuring out what "enforcement capacity" even means in practice. Policy knows where the liability points are. Engineers know where the failure points are. Right now, those two maps get drawn separately and stapled together after the fact, and everyone downstream inherits the seams.

Conclusion

None of this is a full spec. I'm not there yet, and given that even the regulators are still building out their own enforcement infrastructure, I don't think anyone fully is. I've come to think the honest next step isn't "policy needs to understand engineering better." It's more specific than that: policy needs engineers who've shipped things at 2 a.m., sitting at the table while the checklist gets written, not reviewing it afterward. And it needs everyone, on both technical and regulatory sides, to stop performing a confidence about "compliance" that the actual state of enforcement doesn't yet support.

If you're a standards body or a regulator, that means opening the drafting process itself, not just the comment period, to people who've operated production systems. If you're an engineering team, it means showing up to that table instead of waiting to be asked.

References

Liked this piece?

Share it with your network or someone who might find it useful.