Most AI governance still sits in policies, committees and approval processes. That is no longer enough. As AI systems gain access to enterprise data, tools and workflows, governance must move into the execution path - where permissions, actions, exceptions and evidence can be controlled.
An AI policy can tell employees not to paste confidential information into a public tool. It cannot stop them. It can require human review of high-impact decisions. It cannot ensure that the reviewer sees the relevant evidence, has authority to challenge the output or intervenes before an action becomes effective. It can prohibit unapproved models. It cannot prevent an application from calling one.
This is the central weakness in much enterprise AI governance. Organisations have written the rules, formed committees and published principles, but the systems doing the work often sit outside those controls. The result is a growing gap between governance intent and operational behaviour.
Policy remains necessary. It defines values, risk appetite, decision rights and acceptable use. But it becomes governance only when it is connected to mechanisms that shape what systems and people can actually do.
For enterprise AI, governance must become executable.
Policy describes the boundary but does not hold it
The policy-first approach was understandable when most enterprise AI was experimental. A small number of teams could submit use cases for review, complete risk assessments and work within limited sandboxes. Governance happened before deployment because relatively little happened after it.
That operating assumption is disappearing. Generative AI is being adopted through software subscriptions, embedded assistants, application programming interfaces and workflow tools. Microsoft and LinkedIn reported in 2024 that 75% of global knowledge workers were using AI at work and that 78% of AI users were bringing their own tools into the workplace. This is company-sponsored survey research rather than a universal benchmark, but it captures the governance problem: adoption can spread through individual behaviour faster than central processes can see or control it.
A written rule is weakest precisely where pressure is highest. Employees choose the fastest available route. Product teams connect the model that meets a release deadline. Business units deploy a specialist tool before procurement, security and data governance have caught up. Once these decisions become distributed, policy depends on every person correctly interpreting and following it in every context.
Accountability, however, does not remain distributed. In 2024, a British Columbia tribunal found that Air Canada had not taken reasonable care to ensure information provided by its chatbot was accurate. The decision treated the chatbot as part of the company's website, not as an independent actor. The wider implication is straightforward: an organisation remains responsible for the outcome produced through its systems, even when the immediate output was machine-generated.
Policy can assign responsibility on paper. Operational governance must make that responsibility visible in the system.
AI turns governance into an execution problem
Traditional software normally behaves within a defined set of programmed paths. AI systems introduce greater variability. Their outputs depend on the model, instructions, user input, retrieved information, connected tools and the state of the surrounding workflow. Agentic systems add another dimension by turning outputs into actions.
That changes the unit of governance. The relevant object is no longer only the model or use case. It is the complete decision and execution chain.
Consider an internal AI assistant that prepares a supplier response. The governance questions begin before generation:
- Which user is making the request?
- Which documents can the system retrieve?
- Is the information current, approved and appropriate for that user?
- Which model and provider may process it?
- Can the output be sent automatically or only drafted?
- Which claims require evidence or human approval?
- What is recorded if the answer is challenged later?
A policy may address all seven questions. Unless the architecture enforces the answers, each remains an instruction rather than a control.
This is why regulation and standards are increasingly concerned with operational capability. The EU AI Act requires, for high-risk systems, lifecycle risk management, automatic event logging, designed-in human oversight, a quality management system and post-market monitoring. Article 12 states that high-risk systems must technically allow automatic recording of events. Article 14 requires systems to be designed so that people can oversee them effectively. Article 72 requires systematic collection and analysis of performance data throughout the system's lifetime.
The direction is clear. Governance is expected to operate through the system, not merely around it.
The same shift has already happened elsewhere
AI governance is not the first discipline to discover that policy alone is structurally weak.
Cybersecurity policies became meaningful through identity controls, multifactor authentication, endpoint protection, network segmentation, monitoring and incident response. Cloud governance moved from approved-provider lists and architecture boards towards automated configuration rules, deployment controls and continuous posture management. Privacy moved beyond notices and staff guidance towards data minimisation, access restrictions, retention controls and privacy by design.
The General Data Protection Regulation makes the distinction explicit. Article 25 requires appropriate technical and organisational measures to implement data-protection principles effectively and to ensure that, by default, only necessary personal data is processed. The obligation is not satisfied by declaring a principle; the safeguard must be integrated into processing.
AI governance is following the same path because the failure modes are similarly operational. Sensitive data is exposed during retrieval or prompting. An unsuitable model is selected during routing. An agent exceeds its authority while invoking a tool. A misleading response becomes consequential when it enters a customer, employment, financial or operational workflow.
The lesson is not that every enterprise needs an entirely new governance stack. Much of the foundation already exists in identity and access management, data governance, security operations, software delivery, workflow orchestration and enterprise risk. The missing capability is coordination: converting AI policy into controls across those domains and connecting the resulting evidence back to accountable owners.
Executable governance needs a complete control chain
A useful way to design the target state is as a policy-control-evidence chain. Each link has a distinct purpose. Weakness in any one breaks the governance model.
Intent defines the decision
The intent layer establishes what the organisation permits, prohibits and escalates. It includes principles, risk appetite, use-case classification, data rules, autonomy limits and accountability.
This layer remains human-led. Leaders must decide, for example, whether an AI system may recommend a supplier, approve a payment, alter a customer record or send an external communication. These are business decisions with legal, ethical and commercial consequences. Technology can apply the decision, but it should not quietly make it.
The intent must also be specific enough to implement. “Use AI responsibly” cannot become a control. “Customer financial information may be processed only through approved models within the enterprise tenant” can.
Controls shape system behaviour
The control layer converts intent into preventive, detective and corrective mechanisms.
Preventive controls include identity checks, model allowlists, data-loss prevention, entitlement-aware retrieval, tool permissions, transaction limits and deployment gates. Detective controls include prompt and action traces, anomalous-behaviour alerts, evaluation results and policy-violation monitoring. Corrective controls include disabling a connector, revoking an agent's credentials, rolling back a model version or requiring a workflow to fall back to human handling.
The location of each control matters. Data restrictions belong at the point of retrieval and transmission. Model restrictions belong at the gateway or platform layer. Approval thresholds belong inside the workflow before the action becomes effective. Agent permissions belong with the identity under which the agent operates.
Controls added only to a governance dashboard may describe exposure without reducing it.
Evidence proves that governance operated
The evidence layer shows what happened and whether the control worked. It should capture the relevant identity, model, data sources, tool calls, decisions, approvals, overrides, exceptions and outcomes without collecting more sensitive information than necessary.
This is more than audit preparation. Evidence supports incident response, model improvement, supplier assurance and executive oversight. It also closes the loop: recurring exceptions may show that the policy is unrealistic; repeated control failures may expose a design weakness; low override rates may indicate either strong performance or passive human review.
NIST's AI Risk Management Framework reflects this operating logic by organising activity across Govern, Map, Measure and Manage, with governance intended to inform the other functions. ISO/IEC 42001 similarly treats AI governance as a management system that must be implemented, maintained, evaluated and continually improved.
Governance is therefore not a one-way instruction from committee to system. It is a feedback loop between intent, execution, evidence and change.
Executable does not mean fully automated
The strongest version of the thesis would be wrong. Not every governance requirement can or should be converted into a deterministic rule.
AI behaviour remains probabilistic. Context can change the meaning of an action. Fairness, proportionality, public interest and acceptable residual risk often require human judgement. Controls can also fail. The UK National Cyber Security Centre has warned that prompt injection is likely to remain a residual risk and cannot be removed simply by buying a product or applying a single safeguard.
The purpose of executable governance is therefore not to guarantee perfect behaviour. It is to reduce preventable risk, constrain the potential impact of failure and create evidence for intervention.
This requires proportionality. A low-risk assistant used to summarise non-sensitive internal notes does not need the same controls as an agent that changes account data or initiates transactions. A practical model is to increase control with consequence:
- Assistive use: Approved access, clear data boundaries and basic attribution.
- Workflow-embedded use: Identity-aware data access, evaluation, monitoring and defined fallbacks.
- High-impact decisions: Documented thresholds, meaningful human challenge and retained evidence.
- Autonomous actions: Bounded permissions, transaction limits, revocation, escalation and recovery mechanisms.
Over-enforcement creates its own governance risk. When approved systems are difficult to access or governance routes take too long, teams create workarounds and visibility declines. The aim is not maximum control. It is sufficient control, placed where it changes the outcome.
The leadership question is whether policy survives production
Boards and executive teams do not need to choose a single “AI governance platform” before they can act. They need to establish whether material AI use passes through a governed operating path.
Five questions expose the current position:
- What is running? Maintain an inventory of material AI systems, embedded features, agents, models and connectors, with named business and technical owners.
- What can it reach and do? Record the data, tools, systems and actions available to each use case, including delegated and machine identities.
- Where is each rule enforced? Map material policy requirements to a technical control, workflow control or explicit human decision. A policy statement with no control point should be treated as an open risk.
- What evidence is produced? Define the traces, evaluations, approvals, exceptions and incident records needed to reconstruct behaviour and test control effectiveness.
- Who can intervene? Give named owners the authority to pause, restrict, override or retire a system, and make escalation thresholds clear before an incident.
This agenda changes the conversation. Instead of asking whether an AI policy has been approved, leaders ask whether the organisation can demonstrate that the policy is operating.
That distinction will become more important as AI moves from generating content to coordinating work and taking action. A chatbot can produce an inaccurate answer. An agent can carry that answer into a customer record, supplier decision, payment process or operational system. The distance between output and consequence is shrinking.
Policy remains the source of intent. Governance is the machinery that carries that intent into decisions, constraints and evidence.
The organisations that govern AI well will not necessarily have the longest principles or the largest committees. They will be able to show what ran, who authorised it, what it could access, which controls applied, what happened and who acted when the result fell outside expectations.
Governance is not the document that says the right thing. It is the operating system that makes the right outcome more likely, the wrong outcome harder and both visible to accountable leaders.
