Practical, grounded practices for governing enterprise AI well, framed as patterns to adapt rather than a checklist to copy.
Executive summary
- Best practices are patterns that recur across enterprises that govern AI well, not a checklist to copy blindly. They should be adapted to context rather than applied mechanically.
- The strongest practices share a theme: they make governance operational, evidence based, and proportionate, rather than documentary, asserted, and uniform.
- Each best practice has a corresponding anti-pattern, the common mistake it corrects, and recognising the anti-pattern is often the fastest way to see why the practice matters.
- Practices should be grounded in recognised guidance such as the NIST AI Risk Management Framework, the OECD AI Principles, and ISO/IEC 42001, not invented in isolation.
- The single most reliable practice is to make governance operational, because when policy is enforced and evidence is produced as controls run, most other good practices become achievable.
Source basis: NIST AI RMF Playbook; OECD Recommendation of the Council on Artificial Intelligence; ISO/IEC 42001:2023, Artificial intelligence management system. Full citations and scope notes appear below.
Best practices are patterns, not a checklist
Best practices are most useful when understood as patterns that recur across enterprises that govern AI well, rather than as a checklist to be copied item by item. A checklist invites mechanical compliance, ticking boxes without understanding why each matters, which produces the appearance of good governance without its substance. A pattern invites understanding: seeing why a practice works, in what context, and how to adapt it, which produces governance that actually functions. The practices in this report are offered as patterns to understand and adapt, not boxes to tick.
The reason patterns beat checklists is that AI governance is contextual, and a practice that works well in one enterprise may need adaptation in another. The right degree of oversight, the right structure for accountability, and the right controls all depend on the enterprise size, sector, risk appetite, and AI use, so copying another enterprise practices exactly is unlikely to fit. Understanding the pattern behind a practice, the outcome it achieves and why, is what lets an enterprise adapt it to its own context, which is what makes the practice useful rather than a mismatched import.
These patterns are also grounded in recognised frameworks rather than invented, which is what distinguishes best practices from mere opinion. Each practice connects to guidance such as the NIST AI Risk Management Framework, the OECD AI Principles, or ISO/IEC 42001, so it rests on an established foundation rather than the preference of whoever compiled the list. This grounding matters, because it means the practices carry the weight of the frameworks behind them, and an enterprise adopting them is aligning with recognised guidance rather than following an unaccountable set of tips.
Govern the use case, not the model
The first best practice, and the most foundational, is to govern the use case rather than the model alone, because the same model carries very different risk depending on how it is used. A model that drafts internal notes and the same model wired into a customer facing decision workflow are two governance objects with two risk profiles, and governing at the model level misses this entirely. The pattern is to make the use case, with its data, tools, autonomy, users, and impact, the unit of governance, which captures the context that actually determines risk.
The anti-pattern this corrects is model level governance, which treats a model as if its risk were a fixed property. Enterprises that govern at the model level find themselves either over governing low risk uses of a capable model or, more dangerously, under governing high risk uses because the model was assessed in a low risk context. The use case pattern corrects this by governing each use of AI on its own terms, which is why it is foundational: it determines the unit at which all the other governance operates, and getting it wrong undermines everything built on it.
This practice grounds directly in the risk and framework guidance, which locate risk in context rather than components. The NIST AI Risk Management Framework maps risk at the level of the system in its context, and the risk register discipline records risk at the use case level. Adopting the use case as the unit of governance is therefore not a Helixar invention but an application of recognised guidance, and it is the practice on which the coherence of the whole governance depends, which is why it comes first among the patterns.
Enforce policy where AI acts
The second best practice is to enforce policy where AI acts, rather than relying on written policy and after the fact review, because policy that cannot be enforced at the point of action is intention rather than control. A policy that says sensitive data must not go to an unapproved model is real only if something prevents it at the moment the data would leave, and a policy that says high impact actions require approval is real only if something holds the action. The pattern is to give policy an enforcement point where AI activity happens.
The anti-pattern is policy that stops at publication, published to people and systems but not enforced, so that compliance depends on memory and goodwill. This produces the illusion of control, an enterprise that believes it is governed because it has policies, while the policies do not actually constrain what AI does. For assistive AI a human reviews, this may be tolerable, but for agents acting at machine speed it is not, because there is no human at each step to enforce the policy. The enforcement pattern corrects the illusion by making policy actually constrain behaviour.
This practice is the operational core of AI governance, and it is what Helixar calls operational policy governance. It grounds in the NIST Manage function, which calls for risk to be managed operationally, and it is what distinguishes governance that constrains AI from governance that describes how AI should behave. Enterprises that adopt this practice find that their policy becomes a control rather than a document, which is often the single change that most improves the reality of their governance, particularly as they deploy agents.
Tier oversight by risk
The third best practice is to tier oversight by risk, matching the intensity of governance to the impact of the use case, because uniform governance is both wasteful and counterproductive. Applying the same oversight to a low risk drafting assistant and a high impact decision system either over governs the assistant, wasting effort and slowing adoption, or under governs the decision system, leaving material risk unmanaged. The pattern is to define risk tiers and match oversight, testing, and evidence to them, so that governance is strong where it matters and light where it does not.
The anti-pattern is uniform governance, applying the same process to all AI regardless of risk, which fails in both directions at once. Uniform heavy governance drives low risk use into the shadows, as teams route around burdensome controls, while uniform light governance leaves high risk use unmanaged. The tiering pattern corrects this by directing governance where it is needed, which both protects against the high risk use and keeps the low risk use governed by making governed adoption easy. Proportionality is what makes governance both protective and adoptable.
This practice grounds in the proportionality that runs through the framework guidance, from the NIST emphasis on risk based management to the risk tiering of the oversight discipline. It is the practice that makes governance feasible at enterprise scale, because an enterprise with much AI use cannot govern all of it intensively, and tiering is what lets it concentrate its finite governance capacity where the impact is highest. Without tiering, governance either overwhelms the enterprise or spreads too thin to protect it, which is why proportionality is a recurring best practice.
Produce evidence as a byproduct of control
The fourth best practice is to produce evidence as a byproduct of control operation, rather than assembling it after the fact, because contemporaneous evidence is stronger and less costly than reconstructed evidence. When a control records what it does as it does it, the evidence is complete, attributable, and hard to dispute, and it exists without a special effort to gather it. The pattern is to design controls that produce evidence as they operate, so that the evidence framework populates itself and governance is demonstrable by construction rather than by retrospective assembly.
The anti-pattern is evidence assembled after the fact, gathered when an audit or incident forces the search, which is weaker because it is reconstructed and more costly because it requires special effort. Enterprises that treat evidence as something to produce when needed find, at the moment of challenge, that the evidence is incomplete or does not exist, because it was never captured. The byproduct pattern corrects this by capturing evidence at the moment of the event, which is both more reliable and, once designed, less effortful than assembling it later.
This practice connects governance to assurance, because the evidence controls produce is what assurance and audit test. It grounds in the evidence and assurance disciplines, and it is the practice that makes governance not only real but demonstrable, which is what boards, auditors, and regulators require. Enterprises that adopt this practice find that their assurance becomes easier and their governance becomes defensible, because the evidence that demonstrates it is a natural output of the governance operating, rather than a burden imposed on top of it.
Connect AI governance to enterprise risk
The fifth best practice is to connect AI governance to enterprise risk management, rather than building it as a separate island, because AI risk is enterprise risk and governing it separately deprives it of authority and coherence. AI risk affects operations, customers, privacy, security, and reputation, and it should be governed through the structures the enterprise already trusts, with AI risk feeding the enterprise risk register and AI governance connecting to the existing risk, security, and privacy functions. The pattern is integration, adding the AI specific overlay to established governance rather than replacing it.
The anti-pattern is the AI governance island, a separate structure with its own authority and processes disconnected from the enterprise governance, which the rest of the organisation tends to ignore. An island lacks the authority that comes from connection to the enterprise governance, duplicates the work of existing functions, and leaves gaps at the boundaries. The integration pattern corrects this by grounding AI governance in the enterprise governance, so that it inherits the authority the enterprise already has and leverages the functions the enterprise already operates.
This practice grounds in the governance guidance that treats AI as a governance responsibility of the whole organisation, such as ISO/IEC 38507, rather than a technical matter for a specialist team. It is the practice that gives AI governance reach and authority, because governance connected to the enterprise structure is governance the organisation accepts, while an island is governance the organisation can ignore. Connecting rather than isolating is what lets AI governance actually govern the enterprise, which is why integration is a recurring best practice.
The practices and their anti-patterns
Each best practice corrects a specific anti-pattern, and seeing the practice and anti-pattern together is often the clearest way to understand why the practice matters. The practice of governing the use case corrects model level governance. Enforcing policy where AI acts corrects policy that stops at publication. Tiering oversight corrects uniform governance. Producing evidence as a byproduct corrects evidence assembled after the fact. Connecting to enterprise risk corrects the governance island. The matrix below sets out the practices and the anti-patterns they correct.
The value of framing practices against anti-patterns is that the anti-patterns are common and recognisable, so an enterprise can often see its own situation in them. An enterprise that governs at the model level, or whose policy stops at publication, or that has built a governance island, can recognise the anti-pattern and see the practice that corrects it. This diagnostic use of the anti-patterns, recognising the mistake to find the practice, is often more useful than the practices stated positively, because it starts from where the enterprise actually is.
The anti-patterns also share a common root, which is the deeper insight the matrix reveals. Model level governance, policy that stops at publication, uniform governance, retrospective evidence, and the governance island are all forms of governance that is documentary rather than operational, asserted rather than demonstrated, or disconnected rather than integrated. The best practices, seen together, all move governance in the same direction: toward the operational, the evidenced, and the integrated. This shared direction is the underlying pattern behind all the individual patterns.
Each practice corrects a common mistake
Seeing the practice and the anti-pattern together is often the clearest way to understand why the practice matters.
What mature programmes avoid
Beyond the positive practices, mature governance programmes share a set of things they avoid, and these avoidances are as instructive as the practices. Mature programmes avoid policy that cannot be enforced, because they have learned that unenforceable policy provides false comfort. They avoid oversight that pressures reviewers to rubber stamp, because they know it provides no real control. They avoid evidence assembled only after an incident, because they have felt the weakness of reconstructed evidence. And they avoid governance disconnected from enterprise risk, because they have seen islands ignored.
These avoidances are learned, often the hard way, which is why they characterise mature programmes rather than new ones. A new programme may make these mistakes because they are natural and their costs are not yet visible, while a mature programme avoids them because it has experienced their costs. The stack below lists what mature programmes avoid. An enterprise can shortcut the learning by adopting these avoidances from the start, treating the accumulated experience of mature programmes as guidance rather than rediscovering the mistakes itself.
The avoidances, like the practices, share a direction, which is the same insight from the other side. What mature programmes avoid is governance that is documentary, asserted, uniform, or disconnected, the same anti-patterns the practices correct. This symmetry is not coincidental: the practices and the avoidances are two views of the same understanding, of what makes governance real versus merely apparent. Whether framed as what to do or what to avoid, the underlying lesson is the same, which is why the practices and avoidances reinforce rather than merely supplement each other.
What mature programmes have learned to avoid
These avoidances are learned, often the hard way. An enterprise can shortcut the learning by adopting them from the start.
Start with visibility
A recurring practice among enterprises that govern AI well is to start with visibility, building an inventory and clear ownership before sophisticated controls or assurance, because ungoverned AI use is the risk they cannot see. This practice reflects the hard won understanding that the largest AI risk is usually the use the enterprise does not know about, and that no amount of control or assurance on known use addresses the unknown use. The pattern is to make seeing the AI estate the first priority, because everything else depends on it.
The anti-pattern is to start with the visible and satisfying work of policy and controls, which feels like progress but is premature if the enterprise does not know what AI it has. Enterprises that start here build governance on an incompletely understood estate, leaving the unknown use, often the riskiest, ungoverned. The visibility first practice corrects this by insisting on the less glamorous foundation, which the roadmap discipline develops as the sequencing principle that visibility precedes control and control precedes assurance.
This practice also delivers the fastest risk reduction, which is why it is both logically prior and practically valuable. Simply knowing what AI the enterprise uses and assigning owners begins reducing risk immediately, addressing the largest risk directly, before any control is built. Enterprises that adopt this practice find that their first governance investment tends to pay off fastest, which both reduces risk and earns the support to continue. Starting with visibility is the practice that gets governance off to a strong start, which is why it recurs among enterprises that govern well.
Design for the agent, not just the model
As enterprises adopt agentic AI, a distinguishing practice of those that govern it well is to design governance for the agent, not just the model, because an agent creates risk through what it does, not only through whether its model is correct. Governing an agent means governing its authority: the tools it can call, the data it can reach, the actions it can take, and whether those limits are enforced. The pattern is to treat the agent authority as the primary governance object, which is a shift from the model focus that suffices for passive AI.
The anti-pattern is to govern an agent as if it were a passive model, validating the model and assuming a validated model means a safe agent. Enterprises that make this mistake have validated the engine without governing the vehicle, leaving what the agent does unconstrained even though the model is sound. The agent focused practice corrects this by governing what the agent is allowed to do, enforced at runtime, which is where the excessive agency risk that is central to agentic AI must be managed. Governing the agent, not just its model, is what makes agentic AI governable.
This practice is increasingly important as agents become more common, and it is where much of the framework distinctive emphasis lies. It grounds in the recognition, across the framework and the model risk and control objectives disciplines, that a validated model can still act unsafely and that agent authority must be bounded and enforced. Enterprises that adopt this practice govern their agents at runtime, bounding and recording their authority, which is what lets them deploy agents safely rather than deploying them and hoping. Designing for the agent is the practice that agentic AI makes essential.
Make governance operational
Underlying all the specific practices is a single most reliable practice: make governance operational rather than documentary, because operational governance is what makes most other good practices achievable. When policy is enforced and evidence is produced as controls run, the use case is governed in operation, oversight has an enforcement point, evidence exists as a byproduct, and the whole becomes demonstrable. Operational governance is therefore not one practice among many but the foundation that enables the others, which is why it is the practice an enterprise should prioritise if it prioritises only one.
The bars below illustrate, as a reference model, how the impact of the practices depends on whether governance is operational or documentary. A practice like tiering oversight or governing the use case has far more impact when governance is operational, because the tiers and use cases are actually governed in operation, than when governance is documentary, because then the tiers and use cases exist only on paper. The illustrative comparison shows that making governance operational amplifies the impact of the other practices, which is why it is the most reliable practice of all.
Making governance operational is also the practice that most directly closes the gap between governance intention and AI reality, which is the central problem of AI governance. Documentary governance describes how AI should behave; operational governance constrains how AI does behave. As AI becomes more autonomous and acts at machine speed, this gap becomes more dangerous, and operational governance becomes more essential. The enterprises that govern AI best are those that have made their governance operational, which is why this practice, more than any specific technique, is the mark of mature AI governance.
Illustrative practice impact, operational vs documentary
How the impact of the practices depends on whether governance is operational or documentary. Operational governance amplifies the others.
Adapting practices and common misapplications
Because the practices are patterns rather than a checklist, applying them well requires adaptation, and misapplication usually comes from applying them mechanically without understanding. Tiering oversight, applied without judgement, can become a rigid classification that does not fit the actual risks. Governing the use case, applied bureaucratically, can become a heavy assessment process that slows adoption. The practices are directions, not formulas, and applying them well means understanding the outcome each seeks and adapting the method to the enterprise context, rather than implementing them by rote.
A common misapplication is to adopt the vocabulary of the practices without the substance, claiming to govern the use case, enforce policy, and produce evidence while doing so only nominally. An enterprise can say it tiers oversight while its tiers are cosmetic, or that it enforces policy while its enforcement is a review that rubber stamps. This nominal adoption is the anti-pattern of the practices themselves, taking their form without their substance, and it is guarded against only by focusing on the outcome each practice seeks rather than the label, which is why understanding beats copying.
The remedy for misapplication is to keep returning to the purpose of each practice, asking whether it is achieving its outcome rather than whether it is nominally in place. The purpose of tiering oversight is proportionate protection, so the test is whether high risk use is actually well governed and low risk use is not obstructed, not whether tiers exist on paper. Keeping the purpose in view is what lets an enterprise apply the practices with judgement, adapting them to its context while preserving their substance, which is what turns the patterns into governance that works rather than governance that merely uses the right words.
Conclusion: the Helixar perspective
The Helixar research perspective is that the single most reliable practice is to make governance operational. When policy is enforced through operational policy governance and evidence is produced as controls run, most other good practices follow, because the enterprise can finally see and prove what its AI is doing. Governing the use case, tiering oversight, and producing evidence all become achievable when governance operates rather than merely describes, which is why making governance operational is the practice that enables the rest.
This is the thread that connects the best practices to the whole corpus. Each practice, examined closely, points toward operational governance: use case governance needs enforcement, evidence must be produced by controls, and agent governance requires runtime bounds. The practices are, in a sense, all facets of the single insight that governance must operate to be real, which is the insight operational policy governance embodies. The best practices are the ways this insight shows up across the different areas of AI governance.
Read alongside the roadmap and programme design reports, this report distils the patterns that distinguish AI governance that works: govern the use case, enforce where AI acts, tier by risk, evidence as a byproduct, connect to enterprise risk, start with visibility, design for the agent, and above all make governance operational. These are patterns to adapt, grounded in recognised frameworks, and their common direction is toward governance that operates, is demonstrated, and is integrated. For the whole discipline these reports support, the Enterprise AI Governance Framework is the anchor.
Enterprise checklist
- Govern the use case, including data, tools, autonomy, and impact, not only the model.
- Enforce high impact policy where AI activity happens, not only in a document.
- Match oversight intensity to risk, avoiding both under and over governance.
- Produce evidence as a byproduct of control, not assembled after the fact.
- Connect AI governance to enterprise risk rather than building a separate island.
- Start with visibility, and design governance for the agent, not just the model.
- Above all, make governance operational, which enables the other practices.
Frequently asked questions
What is the most important best practice?
Are best practices a checklist?
Why frame practices against anti-patterns?
What do the practices have in common?
How do we avoid misapplying the practices?
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
- NIST AI RMF Playbook
- OECD Recommendation of the Council on Artificial Intelligence
- ISO/IEC 42001:2023, Artificial intelligence management system
- ISO/IEC 38507:2022, Governance implications of the use of AI by organizations
- NIST AI Risk Management Framework (AI RMF 1.0)
- Helixar research: Enterprise AI Governance Roadmap
- Helixar research: Enterprise AI Governance Framework