The most dangerous moment in an AI governance program is the week after the maturity assessment lands.

You have a report. It’s thorough, it’s well-received, and it contains somewhere between fifteen and sixty recommendations rated by priority. Everyone agrees with it. And then, three months later, four of the recommendations are done — the four that were easy — and the assessment has quietly become a document people reference rather than a plan people execute.

I’ve been on both sides of this. I’ve delivered maturity assessments — NIST CSF 2.0, CIS Controls, ISO 27001 gap analyses, AI governance maturity models — and I’ve been the person picking up someone else’s assessment and told to make it real. The gap between the two jobs is bigger than most organizations expect, and it isn’t a resourcing gap. It’s a translation gap.

Why assessments don’t self-execute

Assessment reports are organized to communicate findings. Roadmaps have to be organized to sequence work. Those are different structures, and converting between them is real work that nobody budgets for.

Three specific mismatches cause most of the failures:

Findings are grouped by domain, but work is constrained by dependency. An assessment groups recommendations under headings — governance, risk, data, lifecycle, third party. That’s readable. But “establish AI risk tiering” and “implement tiered assessment workflows” appear in different sections while being strictly sequential. Execute by section and you’ll build the workflow before the criteria it depends on.

Priority ratings ignore effort and prerequisites. A “critical” finding that requires a tool procurement, a data governance prerequisite and two new hires is not the first thing you do, no matter how it’s rated. Priority is an input to sequencing, not a substitute for it.

Recommendations are written as outcomes, not as work. “Establish comprehensive AI governance across the enterprise” is a finding. It is not a task, it has no owner, and it cannot be tracked. Someone has to decompose it, and if that someone isn’t named, it doesn’t happen.

The conversion: from findings to a work breakdown

Here’s the mechanical process I’d run in the first three weeks after an assessment lands.

Step 1 — Normalize every recommendation into a deliverable. Each finding becomes one or more discrete deliverables with a noun at the centre: a risk tiering standard, an AI system inventory, an intake form integrated into procurement, an AI clause set for contracts, a monitoring dashboard. If you can’t name the thing that will exist when the work is done, the recommendation isn’t ready to schedule.

Step 2 — Map dependencies honestly. Draw the actual graph. Most AI governance programs have the same critical path underneath them, whatever the assessment’s structure:

policy and scope → AI system inventory → risk tiering standard → intake workflow → assessment methodology → control requirements per tier → monitoring → metrics and reporting → independent assurance

Almost everything else hangs off that spine. The inventory in particular is load-bearing: it’s the denominator for every metric you will ever report, and programs that defer it end up rebuilding half their roadmap when they finally do it.

Step 3 — Size effort in bands, not estimates. Small (under two weeks of effort), medium (two to eight weeks), large (a quarter or more), or dependent-on-others. Precision here is false comfort; the bands are enough to sequence.

Step 4 — Assign a single named owner per deliverable. Not a team, a person. And confirm it with them rather than assigning it in a spreadsheet — the difference between an owner and an assignee is that an owner has agreed.

Step 5 — Sequence into waves. Then, crucially, stop and check the sequence against capacity. A roadmap that assumes the governance lead can personally deliver eleven deliverables in a quarter isn’t a roadmap.

Sequencing: the shape that works

Assuming a twelve-month horizon and a program starting from a low or partial maturity baseline:

Wave 1 — Foundations (months 1–3). Scope and AI policy. The inventory, populated to at least 80% coverage. Risk tiering standard. Decision rights and the governance forum with a charter and decision log. The procurement screening question — the cheapest high-coverage control available anywhere in the program.

Nothing in Wave 1 requires new tooling, and that’s deliberate. If your roadmap’s first quarter depends on a procurement cycle, you’ve built in a delay you don’t control.

Wave 2 — Process (months 3–6). Intake workflow. Tiered assessment methodology, including the AI system impact assessment. Launch gate criteria. AI-specific contract clauses. Baseline training and awareness. Wave 2 is where governance becomes visible to the rest of the organization, which makes communication as important as the artifacts.

Wave 3 — Depth (months 6–9). Control requirements per tier. Evaluation and testing standards. Production monitoring. Third-party AI due diligence at scale. Incident response scenarios for AI. This is the wave where the work gets genuinely technical and where the operating model’s division of labour earns its keep — the governance function should be defining requirements here, not implementing them.

Wave 4 — Assurance (months 9–12). Metrics and executive reporting. Internal audit of the program. Periodic review cycles running. If you’re heading for ISO/IEC 42001 certification, this is where the internal audit and management review cycle needs to have actually run at least once.

Pick two quick wins, deliberately

Programs need early evidence that they produce something other than meetings. Choose quick wins on two criteria: visible to the people who fund the program, and genuinely useful to the people subject to it.

The two that consistently deliver:

The inventory’s first cut. Even a rough inventory produces an immediate, quotable fact — “we found 47 AI systems in use; leadership was aware of 12.” That number does more for program funding than any amount of framework explanation. It’s also the finding that most reliably converts skeptical executives, because it reframes AI governance from a hypothetical future risk to a present blind spot.

A fast, low-friction path for low-risk use cases. Publishing “here’s how to get a low-risk AI use case approved in three days” makes the governance function an enabler in its first quarter rather than a gate. Every subsequent conversation is easier.

Avoid the tempting quick win of writing the policy first and calling it progress. Policy is necessary and it is not evidence of capability.

Tracking that survives month four

Roadmaps decay in a predictable way: enthusiasm in month one, drift in month three, a rescoping conversation in month five. What prevents it:

  • A single tracker with owner, deliverable, wave, status, dependency and target date. In whatever tool your organization already uses. Do not build a bespoke governance tracking tool; you’ll spend Wave 1 maintaining it.
  • A short monthly cadence — thirty minutes, exceptions only, blocked items escalated rather than discussed.
  • Explicit re-baselining rather than silent slippage. When something slips, move it and say so. Roadmaps lose credibility through unacknowledged drift far faster than through openly renegotiated dates.
  • Traceability back to the assessment finding. When leadership asks “what happened to recommendation 14?”, you want a one-click answer. This matters enormously if the assessment came from an external party who will be back to reassess.

Report progress in outcomes, not activity

The reporting mistake that quietly kills programs is measuring the roadmap by completion percentage. “We are 62% through the roadmap” tells an executive nothing about whether AI risk has reduced.

Report instead against risk-relevant outcomes: percentage of known AI systems with an assigned owner and risk tier; percentage of high-tier systems with a current impact assessment; number of systems in production without an approved launch gate; median time from intake to decision. Those numbers tell a risk story, and — usefully — they’re the same numbers that survive the transition from roadmap to steady-state operations, which is the moment most programs lose their reporting narrative entirely.

The thing most roadmaps miss

Every AI governance roadmap I’ve reviewed treats the program as a project with an end date. It isn’t. Somewhere around month nine, the work shifts from building the capability to running it — intake volume becomes steady-state, reviews come due, the inventory needs continuous maintenance, and someone has to keep doing all of it.

Plan for that transition explicitly, in the roadmap, with named steady-state owners and an estimate of ongoing effort. Programs that don’t plan for it arrive at month thirteen with a completed roadmap, a congratulatory email, and nobody funded to keep the machine running.

If you’re sitting on an AI governance maturity assessment and working out how to execute it, I’d be glad to talk it through — or start with the free AI readiness self-assessment if you need a baseline first.