DAY 4 — 4 Part Mini-Series: You've Read Three Frameworks. Here's the 90-Day Plan That Makes Any of Them Real.
Three days, three frameworks, one uncomfortable pattern.
NIST gave the field a shared vocabulary and put the hardest calls on leadership's desk without saying who on that desk actually signs. ISO/IEC 42001 gave the field something you can be certified against — proof a process exists, not proof the judgment inside it is any good. The EU AI Act gave the field deadlines and penalties, then still left the enterprise's actual risk decisions exactly where the other two left them.
A framework can tell you what good looks like. It cannot tell you who owns the call, and it cannot make the call for you.
That's the thread running through this whole series, so Day 4 isn't a fourth review. It's what to do about the first three — starting Monday, with the org you have today, not the one you wish you had. The distinction that matters below: some of what follows is what a framework actually requires. Most of it is my own recommendation for how to operationalize what all three leave unsaid. I'll flag which is which.
What the Three Actually Taught Us
NIST AI RMF is voluntary and administered by nobody. Its value is a common vocabulary — seven characteristics of trustworthy AI, the Govern-Map-Measure-Manage cycle. Its gap is that the RMF itself provides no certification, no enforcement mechanism, and no independent way to check an alignment claim — so two organizations can both say "we're NIST-aligned" and mean very different levels of governance maturity.
ISO/IEC 42001 is the one you can be audited against. Certification proves a management system exists and runs with discipline. It doesn't prove the judgment inside that system is any good — a certified company can still make a bad call on risk appetite, because the standard was never built to make that call for it.
The EU AI Act is the one with a clock and a penalty attached — up to €35 million or 7% of worldwide turnover for prohibited practices, with lower tiers below that (Art. 99). It's also the one most likely to create false confidence: for most high-risk systems, the Act's default conformity path is internal self-assessment (Annex VI) — a provider can complete it entirely in-house. Third-party review by a notified body is the exception, not the rule, required mainly for biometric systems or where no harmonized standard exists (Art. 43). A valid CE marking and a complete Annex VI file can exist without any independent business or ethics review ever having questioned whether the system should have been built. Compliance and governance are not the same claim.
Where They Converge
Strip away the vocabulary and the same operating needs surface in all three — some as explicit textual requirements, others as gaps each framework leaves for the organization to close itself:
Someone accountable for residual risk. NIST's Govern function expects senior leadership to take responsibility for AI risk decisions; ISO's Clause 6.1.3 explicitly requires "designated management" to approve a risk treatment plan and accept residual risk. Neither names who that person is at your company, and the Act doesn't require an internal risk-acceptance role at all — that's the operating need I'm drawing out of the three, not something all three state in equivalent terms.
A decision before launch, not a discovery after. NIST's Measure/Manage functions, ISO's Clause 6.1.3 and A.6.2.5, and the Act's Article 43 conformity assessment all assume a pre-deployment checkpoint of some kind exists.
Independent review — encouraged more than required. NIST's Measure function notes that "processes for independent review can improve the effectiveness of testing," but doesn't mandate it. ISO's own text is more direct about the gap: nothing in the standard requires a validator to be independent of the developer. The Act requires third-party review only for the narrower set of cases above; for Article 9 conformity testing generally, the text doesn't require separation of duties either. Building real independence into validation is a recommendation I'm layering on top of all three, not something any of them requires outright.
Monitoring that continues after shipping. NIST's Measure/Manage cycle, ISO's Clause 9.1 and A.6.2.6, and the Act's Article 72 post-market monitoring obligation (high-risk systems only) all assume risk doesn't end at deployment.
Evidence that can be produced, not reconstructed. All three expect documentation — but as the ISO and Act reviews in this series both flagged, a document existing and a control operating are different claims, and none of the three independently verifies the difference for you.
Where They Differ
The differences aren't really about content — they're about what happens if you get it wrong.
NIST AI RMF ISO/IEC 42001 EU AI Act Nature Voluntary guidance Certifiable management-system standard Binding law Conformity/certification check None built in — no assessment mechanism exists Optional — accredited auditor, if you pursue certification Mandatory for in-scope high-risk systems Independent (third-party) assurance Not addressed Only if you choose certification Required only for narrow categories (e.g., biometrics); most high-risk systems self-assess internally What it proves A common vocabulary is in use A management system exists and operates with discipline A specific legal bar was met Consequence of gaps Reputational, competitive Loss of certification Fines up to €35M / 7% of worldwide turnover for the most serious violations Prescriptiveness Low — outcomes, not controls Moderate — process requirements, few numeric thresholds Highest for in-scope high-risk systems, still silent on internal decision rights
None of that changes the underlying job. It changes what it costs you to skip it.
The 90 Days: One Program, Not Three Framework Projects
Not "are we aligned to X" — every review in this series showed that question is close to meaningless on its own. A 90-day path from wherever your organization is today to having the things all three frameworks assume exist. No framework prescribes this sequence — it's my own recommended build order, designed to run under a single accountable sponsor: typically a Chief AI/Data Officer, Chief Risk Officer, or an existing enterprise risk function, not a committee. Someone has to own the 90 days themselves, or the same diffusion-of-responsibility problem this whole series has been describing just relocates one level up.
Worked example, carried through all three phases below: say the system in question is an internal hiring-screening tool that ranks resumes. (Whether it meets the Act's formal Annex III high-risk test is its own legal analysis — for this example, assume the organization's internal risk tiering, built in Month 1, puts it in the top tier regardless.) By day 30 it has a named business owner (Talent Acquisition), a technical owner (the ML team that built it), and a risk owner (HR/Legal). By day 60 it has been through independent validation — someone outside the build team checked its scoring for disparate impact — and a named executive accepted the residual risk in writing before it went live. By day 90 someone is watching its override rate monthly, "a qualified candidate rejected without human review" is a defined incident category, and all of that evidence sits in one place an auditor or regulator could actually find it.
Days 1–30: Know What You Have and Who Owns It
You cannot govern what you cannot see, and you cannot hold anyone accountable for a system nobody has claimed. This month is inventory and ownership — resist the urge to write policy before you've done this.
Build a real AI inventory. Not just internally built models — vendor AI embedded in SaaS tools, copilots, foundation-model API calls, agents, anything shaping a decision. If you don't know it exists, assume someone in your building is already using it.
Assign four named roles to every system on that list: a business owner, a technical owner, a risk owner, and an approval authority. One person can hold more than one role; no role goes unassigned. This is where "shared responsibility" — the phrase every framework leans on — stops being diffuse.
Write a one-page risk appetite statement. What's allowed, what needs controls, what's high-risk, what's off the table. This is a leadership document, not an engineering one — a data scientist can tell you a model is 94% accurate; only the business can decide whether a 3-point accuracy gap is worth trading for explainability.
Classify every system against that appetite. The Act's tiers — unacceptable, high-risk, limited-risk, minimal-risk — are a useful internal sorting mechanism even outside EU scope, though your own tiers don't need to mirror the Act's legal categories exactly.
End of Month 1, you should be able to answer: "What AI do we actually have, and who owns each one?" If leadership needs three spreadsheets that don't agree with each other to answer that, you're not ready for Month 2.
Days 31–60: Build the Gate Nobody Can Route Around
This is the month where "independent review" becomes an actual chokepoint instead of a line in a policy document. All three frameworks point toward a pre-launch checkpoint of some kind; none of them specify the cross-functional gate described below — that's my recommended way of operationalizing what they leave implicit.
Design one pre-production checklist, tiered by the classification from Month 1. Low-risk systems get an expedited path; high-risk systems get the full sequence — design review, validation, security/privacy review, business sign-off, final approval.
Structurally separate validation from development. The person confirming a system meets its thresholds shouldn't be the person who built it. This is the easiest control to fake — a rubber-stamped internal review looks identical to an independent one until you ask who's actually in the room.
Name a residual-risk acceptance authority, tiered by severity. A business owner can accept residual risk on a low-tier system; your highest-stakes systems should require a governance committee or an accountable executive, with board visibility for anything that could genuinely harm someone.
Test the gate on something already live. Pick a system currently in production and walk it backward through your new checklist. If you can't produce dated approval records for each stage — or the dates were clearly generated after the fact — you've found your first real gap, and it's better to find it now than in an audit.
End of Month 2, you should be able to answer: "Show me a system your gate actually rejected or sent back." If the honest answer is "never," the gate is ceremonial — a failure mode every review in this series flagged in some form.
Days 61–90: Prove It's Still True After Launch
Governance that stops at deployment is a launch event, not governance. This last month is about making a system's ongoing behavior visible, with someone actually watching.
Stand up monitoring with a named owner and a real threshold, not a dashboard nobody checks. At minimum: performance drift, an incident/complaint channel, and an override-rate metric if humans are meant to be reviewing the system's output.
Write down what counts as an AI incident — a wrong output, a biased outcome, a near-miss caught before harm occurred — with severity tiers and response timelines. None of the three frameworks defines this for you; all three assume it exists.
Test your ability to actually stop a system — disable it, withdraw it, isolate it, or roll it back — rather than assuming the mechanism works because it's documented somewhere. A control that's never been exercised should be treated as unproven, whatever form that control takes for a given system.
Centralize the evidence. Inventory entries, approval records, validation reports, incident logs — one place, retrievable on demand, not scattered across individual teams' drives. That's the gap between "documented" and "documented, current, and centrally accessible" that the NIST review in this series flagged as the most common source of false confidence in self-assessments.
Put a repeat cycle on the calendar now. Reassess risk tiers, re-check the gate, review incident data — every 90 days, or on material change. Systems change, teams shift from deployer to provider without noticing, and none of this stays true on its own.
End of Month 3, you should be able to answer: "For our highest-risk system, who owns the residual risk right now, and what's the current value of the metric they're supposed to be watching?" If either half of that answer is "I'd have to check," the program exists more on paper than in practice.
The Real Test
A framework — voluntary, certifiable, or legally binding — can define the outcomes you're supposed to hit. It cannot name your risk owner, decide your risk appetite, or accept residual risk on your behalf. That's not a flaw in NIST, ISO, or the Act. It's the honest limit of what any one document, written for every industry or built as regulation rather than an operating manual, can do.
Ninety days won't get you a mature program. It will get you past the point where "we're aligned to the framework" rests on a policy binder instead of a named person who can answer for a specific system today, without checking three spreadsheets first.
Not whether the document exists. Whether someone can actually answer for it.