Designing an AI governance programme that actually operates, with real authority, adequate resourcing, and a rhythm that outlasts the launch.
Executive summary
- A programme needs real authority, or it becomes advice that teams can ignore. Authority is the first design decision, not an afterthought.
- A programme needs enough resourcing to keep pace with AI adoption, because a programme that cannot keep up falls behind the AI it is meant to govern.
- Design should assemble the building blocks: charter, roles, policy and control library, evidence and reporting, and operating rhythm, each supporting the next.
- An operating rhythm is what keeps the programme delivering after the initial launch energy fades, turning governance from a launch into an ongoing discipline.
- The programme should coordinate and enforce across existing functions rather than duplicate them, with defined relationships that avoid both gaps and competition.
Source basis: ISO/IEC 42001:2023, Artificial intelligence management system; NIST AI Risk Management Framework (AI RMF 1.0); NIST AI RMF Playbook. Full citations and scope notes appear below.
Design determines whether a programme delivers
An AI governance programme succeeds or fails largely on its design, before any of its work begins. A well designed programme, with authority, resourcing, and rhythm, delivers governance that operates and lasts. A poorly designed one, however good its intentions, produces documents that teams ignore, stalls when its initial energy fades, or falls behind the AI it is meant to govern. The design decisions, about authority, resourcing, building blocks, and rhythm, are therefore the most consequential choices in standing up AI governance, because they determine whether the programme can deliver at all.
The reason design matters so much is that AI governance is a sustained discipline, not a one time build, and sustaining it requires a programme structured to last. A project can succeed on effort and enthusiasm, delivering a defined output and ending, but a governance programme must keep delivering indefinitely, absorbing new AI use and adapting to change. This ongoing demand is what makes design decisive: a programme designed for a burst of activity will fade, while one designed for sustained operation will endure. The design must anticipate the long run, not just the launch.
Programme design also determines whether governance connects to the enterprise or floats beside it. A programme designed in isolation, with its own authority and processes disconnected from the enterprise structure, tends to be ignored by the rest of the organisation, which does not recognise its authority. A programme designed to connect, with relationships to the existing functions and authority grounded in the enterprise governance, is one the organisation accepts. The design of these connections, as much as the internal design of the programme, determines whether it can actually govern the enterprise AI.
Authority: the charter
Authority is the first thing a programme needs, because without it the programme can advise but not govern, and advice that can be ignored is not governance. The programme derives its authority from a charter, a formal grant of mandate from the board or executive that establishes what the programme can decide, what it can require, and what escalation it can trigger. The charter is what transforms the programme from a well meaning initiative into a body with the standing to set policy, require compliance, and stop non compliant AI use, which is what governing actually requires.
The charter must grant real authority, not nominal authority, which is a distinction that determines whether the programme can function. A charter that establishes the programme but gives it no power to require anything leaves it dependent on persuasion, which fails when persuasion meets resistance. A charter that grants genuine authority, to set binding policy, to require approvals, to escalate non compliance to the board, gives the programme the standing to govern even reluctant parts of the organisation. The difference between nominal and real authority is the difference between a programme that can govern and one that can only recommend.
The charter should also define the limits of the programme authority, because unlimited authority is neither realistic nor desirable. The charter establishes what the programme decides itself, what it decides with others, and what it escalates, so that its authority is clear and bounded. This clarity prevents both the programme overreaching, claiming authority it does not have and provoking resistance, and underreaching, failing to exercise authority it does have. A well designed charter grants enough authority to govern, bounds it clearly, and connects it to the enterprise governance, so the programme authority is real, clear, and legitimate.
Resourcing to keep pace
A programme needs enough resourcing to keep pace with AI adoption, because AI use grows quickly and a programme that cannot keep up falls behind the very thing it governs. Resourcing determines how much AI use the programme can actually govern, how quickly it can assess new use cases, and how well it can maintain the governance it has built. An under resourced programme becomes a bottleneck, unable to keep up with the demand for governed adoption, which either slows the enterprise AI use or, more often, drives it into the shadows where the programme cannot govern it at all.
The resourcing challenge for AI governance is that demand grows faster than for most governance domains, because AI adoption is accelerating. A programme resourced for the AI use of today may be overwhelmed by the AI use of a year from now, so resourcing must anticipate growth rather than match current demand. This is a difficult case to make, because it asks for resources ahead of visible need, but it is essential, because a programme that is always catching up to yesterday demand can never get ahead of the risk. Resourcing for growth is what lets the programme lead rather than chase.
Resourcing also shapes what the programme can do itself versus what it must enable others to do, which is a key design choice. A programme cannot personally govern every AI use case in a large enterprise, so it must be resourced to build the tools, policies, and processes that let the business govern its own AI within the programme framework. This means resourcing the programme to be an enabler and enforcer rather than a doer of all governance, building the capability that scales governance across the enterprise rather than trying to perform it centrally, which does not scale.
The building blocks
A durable programme assembles a set of building blocks, each of which supports the next, and designing the programme means ensuring all of them are present. The building blocks are the charter and authority, the roles and decision rights, the policy and control library, the evidence and reporting engine, and the operating rhythm. Each is necessary, and a programme missing any one tends to stall at that point: without authority it cannot require, without roles it cannot act, without the policy library it has nothing to enforce, without evidence it cannot demonstrate, and without rhythm it fades.
The building blocks support one another in a logical structure, which is why they are best understood as a stack rather than a list. Authority enables the roles, the roles operate the policy library, the policy library generates the evidence, and the operating rhythm keeps all of them running. The stack below shows these building blocks. Assembling them in this supporting structure, rather than as disconnected components, is what makes the programme coherent, because each block rests on the ones below it and enables the ones above.
The building blocks also map to the ISO/IEC 42001 management system cycle of plan, operate, check, and improve, which grounds the programme design in a recognised standard. The charter and roles establish the plan, the policy and control library and evidence engine operate it, the reporting and assurance check it, and the operating rhythm drives improvement. This mapping is valuable because it connects the programme design to a recognised management system discipline, so the programme is built on an established foundation rather than an invented structure, which makes it both more robust and more defensible.
What a durable programme assembles
Each block supports the next. A programme missing any block tends to stall at that point.
Roles and decision rights
The programme needs defined roles and decision rights, because governance is exercised by people making decisions, and unclear roles produce either paralysis or unauthorised action. The roles establish who within the programme does what, and the decision rights establish who can decide what, connecting the programme to the accountability model. A programme with clear roles and decision rights can act decisively, because everyone knows who decides, while one with unclear roles either stalls, as decisions wait for someone to own them, or fragments, as people make decisions they are not authorised to make.
The programme roles should connect to the broader accountability chain rather than existing in isolation, because the programme governs AI that business owners own and executives are accountable for. The programme provides the policy, the challenge, and the coordination, but the accountability for AI use remains with the business and executive owners, so the programme roles are defined in relation to theirs. This connection is what keeps the programme from either taking on accountability it cannot exercise or leaving accountability unclear, and it is why the programme roles are designed alongside the enterprise accountability model.
The decision rights should be tiered by risk, so that the programme involvement is proportionate, which keeps it from becoming a bottleneck. Low risk AI use may be decided by business owners within the programme policy, while high risk use may require the programme direct involvement, and this tiering directs the programme scarce attention to where it is needed. A programme that must decide every AI use case, regardless of risk, cannot scale, while one that reserves its involvement for higher risk use, delegating lower risk decisions within its framework, governs at enterprise scale. The tiering of decision rights is what makes this scaling possible.
The policy and control library
The programme needs a library of policies and controls that it maintains and enforces, because this library is the substance of what the programme governs with. The policy library encodes the rules for AI use, and the control library provides the mechanisms that enforce them, and together they are the toolkit the programme uses to govern. Without this library, the programme has authority but nothing to exercise it with, which is why building and maintaining the library is a core programme function, connecting to the policy management and control objectives disciplines.
The library should be maintained as a living resource, not a static set of documents, because AI changes and the policies and controls must change with it. The programme maintains the library through the policy lifecycle, keeping policies current, retiring those that no longer apply, and adding new ones as AI use evolves. This ongoing maintenance is part of what the operating rhythm drives, and it is what keeps the library relevant. A library that is built once and left static becomes stale, describing yesterday AI, which is why maintaining it is an ongoing programme responsibility rather than a one time build.
The library also scales the programme, because it lets the business govern its own AI within the programme framework rather than requiring the programme to govern each use case directly. When the programme provides clear policies and reusable controls, business owners can apply them to their own AI use, governing within the framework the programme provides. This is how the programme scales governance across a large enterprise: not by governing everything centrally, which does not scale, but by providing the library that lets the whole enterprise govern its AI consistently. The library is the programme leverage.
The evidence and reporting engine
The programme needs an engine that produces evidence and reporting, because demonstrating governance is as important as performing it, and this engine is what makes governance visible. The evidence engine ensures that the programme controls produce records as they operate, populating the evidence framework, and the reporting engine carries governance information to the board, implementing the reporting framework. Together they turn the programme operation into demonstrable, overseen governance, which is what board oversight and external trust require, and without which the programme governs invisibly.
This engine should be designed to produce evidence and reporting as a byproduct of the programme operation, not as a separate effort, because evidence and reporting assembled separately are weaker and more costly. When the programme controls produce evidence as they operate, and the reporting draws on that evidence automatically, the engine runs itself, and the programme can demonstrate its governance without a special effort to gather evidence and prepare reports. This design, of evidence and reporting as byproducts of operation, is what makes demonstrable governance sustainable rather than a periodic burden.
The evidence and reporting engine is also what connects the programme to the assurance that gives it credibility, because assurance tests the evidence the engine produces. A programme with a strong evidence engine can be assured, because it produces the records assurance needs, while one without cannot demonstrate its governance to independent challenge. The engine is therefore the foundation of the programme credibility, connecting its operation to the assurance and reporting that let outsiders trust it. Designing a strong evidence and reporting engine is designing for credibility, not just for operation.
The operating rhythm
The operating rhythm is what keeps the programme delivering after the launch energy fades, and it is the building block most often neglected in programme design. A programme launched with enthusiasm can deliver strongly at first and then fade, as the initial energy dissipates and attention moves elsewhere, unless it has a rhythm that sustains its operation. The operating rhythm is the regular cadence of activities, reviews, and reporting that keeps the programme running, turning governance from a launch event into an ongoing discipline that continues regardless of the initial energy.
The rhythm follows the management cycle of plan, operate, check, and improve, running continuously so that the programme is always operating governance, checking whether it works, and improving it. The flow below shows this rhythm. Its value is that it makes the programme a self sustaining cycle rather than a one time build, because each turn of the cycle keeps the programme current, absorbing new AI use, testing whether governance works, and improving it. A programme with this rhythm endures, while one without it fades once the launch is over.
The rhythm also connects the programme building blocks into a running system, because it is what drives them all. The rhythm maintains the policy library, exercises the evidence engine, produces the reporting, and reviews the whole, so that the building blocks are not static assets but a running operation. This is why the operating rhythm is the block that animates the others: without it, the charter, roles, library, and engine exist but do not run together as a living programme. The rhythm is what turns the assembled building blocks into an operating capability, which is the point of the programme.
Plan, operate, check, improve
The rhythm that keeps the programme delivering after launch, running the building blocks as a self sustaining cycle.
Set policy, priorities, and risk appetite.
Run controls and govern AI use.
Assure, report, and challenge.
Update policy, controls, and design.
Relationships with existing functions
The programme does not govern AI alone but in relationship with the existing functions whose remit AI touches, and designing these relationships is as important as designing the programme itself. AI governance intersects with enterprise risk, information security, privacy, legal, compliance, procurement, and internal audit, and the programme must define its relationship with each, so that it coordinates and enforces without duplicating or competing. A programme that gets these relationships wrong either duplicates the work of other functions, wasting effort and creating conflict, or leaves gaps at the boundaries where no one is responsible.
The right relationship is usually one of coordination and enforcement rather than performance, with the programme providing the AI specific overlay and the existing functions providing their established discipline. Privacy governs the personal data aspects of AI, security governs the security aspects, and the programme coordinates them for AI and adds the AI specific governance that none of them cover alone. The matrix below shows these relationships. Defining them clearly is what lets the programme leverage the existing functions rather than duplicating them, which both saves effort and grounds AI governance in established discipline.
The relationships must be designed to avoid the gaps that appear at the boundaries between functions, which is where governance most often fails. The handoff between the programme and privacy on AI personal data, or between the programme and security on AI security, are exactly the points where a risk can fall between the two, each assuming the other covers it. Designing the relationships explicitly, so that every AI risk has a clear owner and every boundary has a defined handoff, is what closes these gaps. The programme relationships are not administrative detail but the design that determines whether the boundaries are managed or left as gaps.
How the programme relates to existing functions
The programme coordinates and enforces rather than duplicates, with defined handoffs so no risk falls between functions.
Sustaining delivery after launch
The hardest part of a governance programme is not launching it but sustaining it, because the energy and attention that launch a programme naturally fade, and sustaining delivery requires design that anticipates this. A programme designed only for launch, with a burst of activity to establish it and no plan for its ongoing operation, delivers its launch artefacts and then stops operating. A programme designed for sustained delivery, with an operating rhythm, adequate ongoing resourcing, and embedded relationships, continues delivering long after the launch, which is what governance requires.
Sustaining delivery depends particularly on the programme becoming embedded in how the enterprise operates rather than remaining a separate initiative. A programme that stays separate, dependent on its own energy and championing, is vulnerable to fading as attention moves on. A programme that embeds, becoming part of how AI use is approved, how risk is managed, and how the board oversees, is sustained by the enterprise operation itself, because it is now part of how the enterprise runs. This embedding, designed from the start, is what makes the programme durable rather than dependent on continued special attention.
Sustaining delivery also requires the programme to demonstrate ongoing value, because a programme that cannot show it is worth its cost will eventually lose support. The evidence and reporting engine is what lets the programme demonstrate its value, showing the risk it reduces and the governance it provides, so that its continued resourcing is justified. A programme that operates invisibly, unable to show its value, is vulnerable to being cut when budgets tighten, while one that continuously demonstrates its value through reporting is one the enterprise chooses to sustain. Demonstrating value is part of sustaining delivery.
Common programme failures
The most common programme failure is the absence of real authority, where the programme is established but given no power to require anything, so it can advise but not govern. The remedy is a charter that grants genuine authority, connected to the enterprise governance. A second failure is under resourcing, where the programme cannot keep pace with AI adoption and falls behind or becomes a bottleneck. The remedy is resourcing that anticipates growth and enables the business to govern within the programme framework rather than requiring the programme to do everything.
A third failure is the missing operating rhythm, where the programme launches with energy and fades, delivering strongly at first and then declining as attention moves on. The remedy is an operating rhythm that sustains the programme regardless of the initial energy. A fourth is poor relationships with existing functions, where the programme duplicates or competes with privacy, security, and risk, or leaves gaps at the boundaries. The remedy is defined relationships of coordination and enforcement, with explicit handoffs that close the boundary gaps.
Each of these failures is a failure of design rather than of effort, which is the central point: a programme fails when it is designed without a necessary building block, not when its people do not try hard enough. The remedy in each case is to design the programme completely, with real authority, adequate resourcing, all the building blocks, a sustaining rhythm, and defined relationships, so that the programme is structured to deliver. Good design is what lets good effort succeed, and its absence is what causes well intentioned programmes to stall.
Conclusion: the Helixar perspective
The Helixar research perspective is that a programme delivers when governance is operational rather than advisory. A programme that produces policies and recommendations, without a way to enforce them and demonstrate their operation, is advice that teams can ignore, however well designed its charter. When operational policy governance enforces policy and produces evidence as part of daily AI use, the programme has a delivery mechanism, not just a set of documents, which is what keeps it relevant and effective after launch.
This connects programme design to the operational layer, because the programme building blocks, the policy library, the evidence engine, and the operating rhythm, are most effective when governance is enforced and evidenced operationally. The programme that enforces its policies at runtime and produces evidence as controls operate has building blocks that run themselves, which is what makes the programme sustainable. The operational layer is what turns the programme design from an organisational structure into a delivering capability.
Read alongside the roadmap and best practices reports, this report shows how an enterprise designs an AI governance programme that lasts: with real authority, resourcing that anticipates growth, the full set of building blocks, an operating rhythm that outlasts the launch, and defined relationships with the existing functions. Programme design is what determines whether governance delivers, and it is the difference between a programme that governs and one that only recommends. For the whole discipline these reports support, the Enterprise AI Governance Framework is the anchor.
Enterprise checklist
- Grant the programme real authority through a charter connected to enterprise governance.
- Resource the programme to anticipate AI adoption growth, not just current demand.
- Assemble all the building blocks: charter, roles, policy library, evidence engine, rhythm.
- Tier decision rights by risk so the programme scales rather than becoming a bottleneck.
- Maintain a living policy and control library that lets the business govern within it.
- Run an operating rhythm that sustains delivery after the launch energy fades.
- Define relationships with risk, security, privacy, legal, and audit, with explicit handoffs.
Frequently asked questions
Why do governance programmes stall?
Should the programme duplicate existing functions?
How does the programme scale across a large enterprise?
What keeps a programme delivering after launch?
Why does authority matter so much?
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
- ISO/IEC 42001:2023, Artificial intelligence management system
- NIST AI Risk Management Framework (AI RMF 1.0)
- NIST AI RMF Playbook
- IIA Three Lines Model and position papers
- Helixar research: AI Governance Operating Model
- Helixar research: Enterprise AI Governance Roadmap
- Helixar research: Enterprise AI Governance Framework