A phased roadmap for standing up AI governance that lasts, sequencing visibility before control and control before assurance.
Executive summary
- A roadmap turns the governance framework into a sequence an enterprise can actually follow, so that building governance is a series of achievable steps rather than an overwhelming whole.
- Sequencing matters as much as content. Visibility and ownership come first, because an enterprise cannot govern what it cannot see, and assurance depends on the visibility beneath it.
- Early phases deliver quick wins such as an AI inventory and clear ownership, which reduce risk immediately and earn the credibility to continue.
- The end state is a repeatable operating capability, not a finished project, because AI use keeps changing and governance must absorb new use, models, and regulation without restarting.
- The roadmap should be adapted to the enterprise starting point, building what is missing rather than rebuilding what already exists.
Source basis: Australian Government Guidance for AI Adoption: Foundations; NIST AI RMF Playbook; ISO/IEC 42001:2023, Artificial intelligence management system. Full citations and scope notes appear below.
From framework to a followable sequence
A governance framework describes what good AI governance looks like, but it does not tell an enterprise where to start or in what order to build, and this gap is what a roadmap fills. Faced with the whole framework at once, an enterprise can feel overwhelmed, unsure whether to begin with policy, controls, risk, or assurance, and this paralysis is a common reason governance stalls before it starts. The roadmap resolves this by turning the framework into a sequence, a series of achievable phases that build toward the whole, so the enterprise always knows what to do next.
The roadmap is not merely a project plan but an expression of the logic by which governance capabilities depend on one another. Some capabilities are foundations that others require, and building them in the wrong order wastes effort, so the roadmap encodes the dependencies, ensuring that foundations come before the capabilities that rest on them. This is why a roadmap is more than a list of tasks with dates: it is a sequence that reflects how governance actually builds, which is what makes following it efficient rather than merely organised.
The roadmap also makes governance a manageable programme rather than an open ended aspiration, by giving it phases with defined outcomes. Each phase delivers something concrete, an inventory, a set of controls, an assurance capability, so that progress is visible and the programme can demonstrate value as it goes. This is important for sustaining the effort, because a governance programme that shows no concrete progress for months loses support, while one that delivers visible outcomes at each phase earns the backing to continue. The roadmap structures governance for delivery.
Visibility first
The single most important principle of the roadmap is that visibility comes first, because an enterprise cannot govern what it cannot see. Before an enterprise can control AI use, assess its risk, or assure its governance, it must know what AI it uses, where, by whom, and for what. This is why the roadmap begins with an inventory of AI use and clear ownership, not with sophisticated controls or assurance. Building controls before knowing what to control, or assurance before there is anything to assure, is building on air, which is why visibility must come first.
Visibility first also delivers the fastest risk reduction, which is what makes it a good place to start beyond its logical necessity. Simply knowing what AI the enterprise uses, and assigning owners to it, reduces risk immediately, because the largest AI risk is usually the use the enterprise does not know about and no one owns. An inventory that surfaces ungoverned AI use, and ownership that makes someone accountable for each, addresses this before any control is built, delivering value in the first phase that justifies continuing to the next.
The primacy of visibility is why the roadmap resists the temptation to start with the more visible and satisfying work of policy and controls. Writing policy and building controls feel like progress, and they are more concrete than the unglamorous work of building an inventory, but they are premature if the enterprise does not yet know what AI it has. The roadmap insists on the less glamorous foundation first, because the alternative, controls and policy applied to an incompletely understood AI estate, leaves the most dangerous use, the unknown use, ungoverned.
The baseline phase
The first phase, roughly the first thirty days, establishes the baseline of visibility and ownership on which everything else builds. The core activities are to inventory AI use across the enterprise, including the embedded and shadow use that is easy to miss, to assign accountable owners to the AI portfolio and its material use cases, and to set core policy that establishes the basic boundaries of acceptable AI use. These activities are achievable quickly and deliver immediate risk reduction, which is what makes the baseline phase both foundational and valuable in its own right.
The baseline phase should be pragmatic rather than perfect, because its purpose is to establish a foundation quickly, not to achieve completeness. The inventory will not capture every AI use on the first pass, and the core policy will not cover every situation, but a good enough baseline established in thirty days is far more valuable than a perfect one that takes a year, because it enables the phases that follow. The discipline of the baseline phase is to establish the foundation fast and improve it later, rather than delaying the whole roadmap in pursuit of an initial perfection that is neither achievable nor necessary.
The baseline phase also sets up the governance to continue, by establishing the ownership and the basic process that later phases will build on. Assigning owners is not only a risk reduction but the establishment of the accountability that later phases depend on, and setting core policy establishes the policy process that later phases will extend. The baseline phase is therefore both an end, delivering immediate value, and a beginning, establishing the foundations of accountability and process that the control, assurance, and operating phases require. It is the phase that makes the rest possible.
The control phase
The second phase, roughly thirty to ninety days, builds control on the foundation of visibility, adding the mechanisms that keep AI use within bounds. The core activities are to risk tier the use cases identified in the baseline, so that governance can be proportionate, to add approval workflows for higher risk use, so that consequential AI use is authorised, and to add monitoring, so that AI behaviour can be observed. These activities turn the visibility established in the baseline into active governance, moving from knowing what AI the enterprise uses to shaping how it is used.
The control phase depends entirely on the baseline, which is why it comes second, because controls can only be applied to AI use that is known and owned. Risk tiering requires the inventory to tier, approval workflows require the ownership to route approvals to, and monitoring requires knowing what to monitor. An enterprise that skipped the baseline and tried to start here would find it had nothing to apply controls to, which is the wasted effort the sequencing exists to prevent. The control phase builds directly on the baseline, extending it into active governance.
The control phase is where governance begins to bite, and this is where it must be careful to remain proportionate. Adding controls creates friction, and controls applied too heavily or too uniformly drive the shadow AI the baseline worked to surface. The control phase must therefore apply controls in proportion to the risk tiers it establishes, with strong control on high risk use and light control on low risk use, and it must provide a fast path for governed adoption. Done well, the control phase makes governed adoption easier than the shadow alternative; done badly, it undermines the visibility the baseline achieved.
The assurance phase
The third phase, roughly ninety to one hundred and eighty days, builds assurance on the foundation of control, adding the evidence, reporting, and independent challenge that let governance be demonstrated and trusted. The core activities are to build the evidence that controls produce as they operate, to establish reporting that carries governance information to the board, and to introduce independent challenge through the second and third lines. This phase turns governance that operates into governance that can be shown to operate, which is what board oversight and external trust require.
The assurance phase depends on the control phase, because there is nothing to assure until controls operate, which is why it comes third. Assurance tests whether controls work, so it requires controls to test, and it uses the evidence controls produce, so it requires controls that produce evidence. An enterprise that tried to build assurance before control would find it had nothing to assure, which is why the roadmap places assurance after control. The assurance phase builds on the operating controls of the second phase, adding the demonstration and challenge that turn operation into trusted governance.
The assurance phase is where governance becomes credible to outsiders, which is often when the pressure to have it arrives. Boards ask for assurance, regulators ask for demonstration, and customers ask for evidence, and the assurance phase is what lets the enterprise answer these demands. An enterprise that has completed the baseline and control phases has good governance, but until it completes the assurance phase, it cannot fully demonstrate it, which leaves it unable to satisfy the outsiders who need to trust it. The assurance phase is what makes governance credible beyond the enterprise itself.
The roadmap horizons
The three build phases, together with the operating capability they culminate in, map to four horizons across the first year, and seeing them as horizons rather than a fixed schedule keeps the roadmap adaptable to the enterprise pace. The baseline horizon establishes visibility and ownership, the control horizon adds proportionate control, the assurance horizon adds evidence and challenge, and the operating horizon turns the whole into a repeatable capability. The timeline below shows these horizons. The durations are indicative, and an enterprise moves at the pace its context allows, but the order is what matters, because each horizon builds on the last.
The horizons also correspond to increasing maturity, so that an enterprise progressing through them is building capability that can be measured against the capability model. The baseline horizon establishes the accountability and policy domains at a basic level, the control horizon builds the risk and oversight domains, the assurance horizon builds the assurance and evidence domains, and the operating horizon raises them all toward managed and continuously assured. The roadmap and the capability model are therefore two views of the same progression, the roadmap as a sequence in time and the capability model as a set of capabilities to mature.
The horizons should be understood as cumulative rather than sequential and disposable, because each horizon capability continues to operate as the next is built. The visibility established in the baseline continues through all the later horizons, the controls of the control horizon continue through assurance and operating, and so on. The horizons build a growing governance capability, not a series of phases each replaced by the next, which is why the operating horizon is not a fifth thing but the point at which all the earlier capabilities run together as a durable whole. The roadmap accumulates rather than replaces.
From baseline to operating capability
Four cumulative horizons across the first year. Durations are indicative; the order is what matters, because each builds on the last.
- 10 to 30 daysBaseline
Inventory AI use, name accountable owners, and set core policy.
- 230 to 90 daysControl
Risk tier use cases, add approval workflows and monitoring.
- 390 to 180 daysAssure
Build evidence, reporting, and independent challenge.
- 4180 to 365 daysOperate
Run a repeatable capability that absorbs new use, models, and regulation.
Sequencing logic and dependencies
The order of the roadmap is not arbitrary but follows from the dependencies between governance capabilities, and understanding these dependencies is what lets an enterprise sequence its own work correctly. Visibility is a foundation because control, risk assessment, and assurance all require knowing what AI exists. Control is a foundation for assurance because assurance tests controls. Evidence is a foundation for reporting and audit because both draw on it. These dependencies mean the capabilities must be built in a particular order, and violating that order wastes effort on capabilities that cannot yet work.
The most important dependency, and the one enterprises most often violate, is that assurance depends on visibility and control. Enterprises under pressure to demonstrate AI governance sometimes try to build assurance first, to satisfy a board or a regulator, before they have the visibility and control that assurance requires. This produces assurance that finds nothing because there is nothing yet to assure, or that assures governance that does not really operate, which is worse than no assurance because it provides false comfort. The dependency means assurance must come after the foundations it tests.
Recognising the dependencies also helps an enterprise sequence work within its own context, because the same logic applies whatever the starting point. An enterprise further along may not need the full baseline phase, but it still cannot build assurance on control it does not have, and it still cannot control AI it cannot see. The stack below sets out the sequencing principles that follow from the dependencies. Applying these principles, rather than following the exact phases mechanically, is what lets an enterprise build its own roadmap correctly from wherever it starts.
The dependencies that set the order
The roadmap order follows from these dependencies. Applying the principles lets an enterprise sequence its own work correctly.
Quick wins and foundations
A good roadmap balances quick wins, which build momentum and credibility, with foundations, which are less visible but essential, and managing this balance is part of sequencing well. The baseline phase is rich in quick wins: an inventory and clear ownership deliver visible risk reduction fast, which is what earns the support to continue. But the roadmap must also build foundations that pay off later, such as the evidence capability that assurance will need, even though these are less immediately visible. Neglecting foundations for quick wins leaves the later phases without what they require.
The tension between quick wins and foundations is real, because the pressure for visible progress can crowd out the less glamorous foundational work. An enterprise eager to show governance progress may keep delivering visible quick wins while neglecting to build the evidence and process foundations that the operating capability will need, and then find, when it reaches the later phases, that the foundations are missing. The roadmap manages this by ensuring each phase builds both the visible capability and the foundation the next phase requires, so that quick wins and foundations advance together.
The best quick wins are those that are also foundations, delivering immediate value while building toward the whole, and the roadmap seeks these where possible. The AI inventory is the exemplar: it delivers immediate risk reduction, a quick win, while establishing the visibility that all later phases require, a foundation. Assigning owners is similar. Seeking work that is both a quick win and a foundation is what lets the roadmap satisfy the demand for visible progress without sacrificing the foundations, which is the balance a well sequenced roadmap strikes.
Deliverables per horizon
Each horizon of the roadmap has defined deliverables, and setting them out gives the programme concrete goals and lets progress be measured. The baseline horizon delivers an AI inventory, assigned owners, and core policy. The control horizon delivers risk tiering, approval workflows, and monitoring. The assurance horizon delivers evidence, reporting, and independent challenge. The operating horizon delivers a repeatable capability. The matrix below sets out these deliverables by horizon, which turns the roadmap from a direction into a set of concrete goals the programme can be held to.
Defining deliverables also makes the roadmap accountable, because a phase either delivered its outputs or it did not. A roadmap expressed only as directions, build visibility, then control, then assurance, is hard to hold to account, because it is unclear when a phase is complete. A roadmap with defined deliverables per horizon is accountable, because completion is verifiable: the inventory exists or it does not, the approval workflows operate or they do not. This accountability is what keeps the programme on track and lets its sponsors see whether it is progressing as planned.
The deliverables also connect the roadmap to the wider governance system, because each is a component of the framework the roadmap is building toward. The inventory feeds the risk register, the approval workflows implement the accountability model, the evidence populates the evidence framework, and so on. Seeing the deliverables this way, as the components of the framework being assembled in sequence, is what connects the roadmap to the whole it builds toward, so that completing the roadmap is completing the framework, phase by phase, rather than building something separate.
What each horizon delivers
Defined deliverables make the roadmap accountable and connect each phase to the framework it is assembling.
Adapting the roadmap to the starting point
No two enterprises start from the same place, so the roadmap must be adapted to the starting point rather than followed identically by all. An enterprise with strong existing security and control discipline may already have much of the control and evidence capability, needing mainly to add the AI specific elements. One earlier in its governance maturity may need to build several phases from the beginning. The roadmap provides the sequence, but the enterprise applies it from where it actually stands, building what is missing rather than rebuilding what already exists.
Adapting the roadmap requires knowing the starting point, which is where the readiness and capability assessments connect to the roadmap. An assessment of current capability shows what the enterprise already has and what it lacks, which is exactly what is needed to adapt the roadmap. The enterprise uses the assessment to identify its gaps, then applies the roadmap sequence to close them in the right order. The roadmap and the assessment work together, the assessment showing where the enterprise stands and the roadmap showing how to progress from there.
Adapting the roadmap does not mean abandoning the sequence, because the dependencies hold whatever the starting point. An enterprise that already has strong controls still cannot assure AI it cannot see, so it still needs visibility before assurance, even if it needs less baseline work than an enterprise starting from nothing. The adaptation is in what to build, not in the order of the dependencies, which are fixed by the logic of how governance capabilities rest on one another. The roadmap is adapted in content but constant in sequence, because the sequence follows from dependencies that do not change.
From roadmap to operating capability
The destination of the roadmap is not a completed project but a repeatable operating capability, and understanding this changes how the roadmap is approached. A project has an end, but AI governance does not, because AI use keeps changing and governance must keep pace. The operating horizon therefore does not complete governance but establishes the capability to keep governing: a function that can absorb new AI use, new models, and new regulation without starting over. The roadmap builds toward this capability, and reaching it means the enterprise can now govern AI as an ongoing discipline rather than a one time build.
The most common roadmap failure is treating it as a project that ends, so that governance is built and then left to decay as AI use moves on. An enterprise that completes the roadmap and disbands the effort will find, within months, that its governance no longer matches its AI use, because both keep changing. The remedy is to understand from the start that the roadmap builds a capability to be operated, not a project to be finished, so that the enterprise plans for the ongoing operation rather than the completion. The operating capability is the point, not the phases that build it.
A second common failure is violating the sequence, usually by trying to build assurance before the visibility and control it requires, under pressure to demonstrate governance. The remedy is to respect the dependencies, building the foundations before the capabilities that rest on them, even when the pressure is to show the visible assurance first. Governance built in the wrong order wastes effort and produces assurance that assures nothing, which is why the sequence, though sometimes inconvenient, is what makes the roadmap efficient. Respecting the sequence is respecting the logic of how governance builds.
Conclusion: the Helixar perspective
The Helixar research perspective is that visibility should come first, because ungoverned AI use is the risk an enterprise cannot manage. The roadmap begins with an inventory and ownership not only because they are logically prior but because they address the largest risk directly: the AI use the enterprise does not know about. Operational policy governance gives early visibility of what AI is doing and the evidence to prove control, which lets the later assurance phases of the roadmap rest on fact rather than reconstruction.
This is why the roadmap sequences visibility before control and control before assurance. Each phase produces the foundation the next requires, and the operational governance that provides visibility in the baseline also produces the evidence that assurance needs later, so that building governance in this order is not only logical but efficient, because the early phases generate what the later phases consume. The roadmap is a sequence in which each step makes the next easier, which is the mark of a well designed build order.
Read alongside the programme design and best practices reports, this roadmap shows how an enterprise builds AI governance that lasts: a phased sequence from a baseline of visibility to a durable operating capability, respecting the dependencies, balancing quick wins with foundations, and adapting to the starting point. The roadmap turns the framework into something an enterprise can actually follow, one achievable phase at a time. For the whole discipline these reports support, the Enterprise AI Governance Framework is the anchor.
Enterprise checklist
- Start with an AI inventory and clear ownership, before controls or assurance.
- Add risk tiering, approvals, and monitoring next, in proportion to risk.
- Build evidence, reporting, and independent challenge after visibility and control exist.
- Respect the dependencies: visibility before control, control before assurance.
- Balance quick wins with foundations, and seek work that is both.
- Adapt the roadmap to your starting point, building what is missing.
- Aim for a repeatable operating capability, not a project that ends.
Frequently asked questions
What should come first in an AI governance roadmap?
Why does the sequence matter so much?
Is AI governance a project or a capability?
How do we adapt the roadmap to where we already are?
What is the most common roadmap failure?
Method and source use
This report is a Helixar synthesis of the cited public standards and guidance. Named sources are linked at first mention and listed below. Unless a cited source is identified, maturity levels, diagrams, allocations, scores, and operating models are illustrative Helixar reference models, not survey findings or legal requirements. Organisations should verify current obligations with the authoritative source and qualified advisers.
References
- Australian Government Guidance for AI Adoption: Foundations
- NIST AI RMF Playbook
- ISO/IEC 42001:2023, Artificial intelligence management system
- NIST AI Risk Management Framework (AI RMF 1.0)
- Helixar research: Enterprise AI Readiness Assessment
- Helixar research: AI Governance Programme Design
- Helixar research: Enterprise AI Governance Framework