As AI systems move from generating outputs to taking actions, governance can no longer sit only in policies, committees and retrospective audits. Leaders need controls that can evaluate identity, context and authority while work is happening, without pretending that every judgement can be reduced to code.
An enterprise policy might say that customer data must remain within an approved region, that payments above a threshold require additional authority or that an AI agent may prepare a response but not send it. Those rules can be clear on paper and still fail operationally.
The system may retrieve the data, call the tool or complete the transaction before anyone has time to interpret the policy. A review next week can explain what happened. It cannot prevent it.
This is the shift now confronting technology, risk and business leaders. As more decisions move into automated workflows, governance must move closer to execution. Controls need to become machine-readable, permissions more contextual and evidence generated as actions occur.
Governance is not becoming purely technical. It is becoming partly infrastructural.
Governance latency is becoming operational risk
Traditional governance assumes that there is time between intention and action. A policy is written, a system is designed, a deployment is approved and activity is reviewed later. That model remains appropriate for many decisions, particularly those that are infrequent, high impact or dependent on human judgement.
It is weaker when a system can make thousands of low-latency decisions across data, models, application programming interfaces and business processes. An AI assistant that only drafts text can be governed largely through review and usage rules. An agent that can retrieve customer records, update a case, trigger a refund and send a message creates a different control problem.
The issue is not simply speed. It is the combination of speed, scale and sequencing.
Each individual action may appear legitimate. The risk emerges from the chain: which identity initiated the task, what data was accessed, which tools were called, what authority was delegated and whether the combined outcome remained within policy. Once execution is distributed across several systems, a periodic control can see only the residue of the process.
That is why governance latency matters. When the time required to interpret and enforce policy is longer than the time required to act, governance becomes retrospective by default.
Regulatory and standards activity reinforces the direction of travel, although it should not be overstated. NIST's AI Risk Management Framework treats risk management as continuous across the AI lifecycle, while its playbook describes continuous monitoring as a way to track unexpected behaviour after deployment. ISO/IEC 42001 similarly establishes an organisational management system based on ongoing monitoring and continual improvement. The EU AI Act adds a significant compliance deadline, with major provisions applying from 2 August 2026. None of these instruments says that every control must become runtime software. Together, however, they make static evidence and annual assurance increasingly difficult to defend as the only control model.
A policy is not a control until something enforces it
The central governance problem is the gap between policy intent and operational execution.
Policies are written for human interpretation. They use terms such as appropriate, proportionate, sensitive and authorised because context matters. Systems require more explicit decisions: allow, deny, mask, limit, pause, escalate or record.
Turning one into the other is not a clerical exercise. It is a design discipline.
Consider a policy that says an AI system may use customer information only for an approved service purpose. To enforce that policy during execution, the organisation must define at least six things:
- Which customer information is in scope.
- Which purpose is being asserted.
- Which person, service or agent is making the request.
- What authority it is acting under.
- Which action is permitted.
- What evidence must be retained.
The policy must then be connected to enforcement points in identity services, data platforms, application programming interfaces and workflows. It needs versions, tests, approvals, exception handling and rollback. It also needs an owner who can decide what happens when two policies conflict.
Policy-as-code makes part of this possible. Open Policy Agent, for example, separates policy decisions from application logic and can enforce rules across microservices, application programming interface gateways, Kubernetes and delivery pipelines. Cedar similarly evaluates each request against authorisation policies to return an allow or deny decision. These technologies do not solve governance by themselves, but they prove that policy can be treated as a live operational dependency rather than a document consulted after the event.
The important distinction is between documenting a requirement and designing the mechanism that will make the requirement true.
Runtime governance is a control plane, not a single product
It is tempting to treat runtime governance as a new software category. That framing is too narrow.
Governance operates across the execution path. Identity establishes who or what is acting. Authorisation determines what it may do. Data controls determine what it may access. Orchestration determines which step can happen next. Observability records the decision, context and outcome. Human oversight handles ambiguity, exceptions and high-impact choices.
Runtime governance is therefore better understood as a control plane spanning these capabilities.
A useful architecture separates three functions:
Policy decision. A policy service evaluates the actor, action, resource and context.
Policy enforcement. The system in the execution path blocks, modifies, limits or escalates the action.
Evidence generation. Logs and traces record which policy version was applied, which inputs were evaluated and why the action was allowed or denied.
These functions may be distributed. A data platform may apply row-level restrictions, an application programming interface gateway may enforce rate and destination policies, an agent framework may limit available tools and a workflow engine may insert approval gates. The strategic requirement is not that every control sits in one platform. It is that the controls work coherently across the workflow.
That changes the investment question. Leaders should be cautious about buying a premature “AI governance platform” and assuming the architecture is complete. The more durable priority is to establish common policy interfaces, reusable control services and consistent evidence across existing platforms.
The moat is not the dashboard. It is the integration of governance into the path of work.
Identity becomes the first runtime control surface
Most enterprise controls still begin with human identity: an employee signs in, receives a role and operates within a relatively stable set of permissions.
Automated systems complicate that model. An agent may act for a person, a team or a business process. It may need permission for one task, for a limited period, across several systems. It may delegate part of the task to another service. A shared service account cannot adequately explain who authorised the action, which mandate applied or when that mandate should expire.
Runtime governance therefore depends on treating machines and agents as accountable identities.
That does not require inventing an entirely separate identity system. It requires extending established principles: unique identity, least privilege, short-lived credentials, explicit delegation and immediate revocation. The permission should be tied to the task, not inherited indefinitely from the person who initiated it.
Emerging technical work reflects this need. Current Internet-Drafts are exploring how existing workload identity and OAuth mechanisms could be applied to agent authentication, authorisation and delegation. These drafts have no formal standards status, but their existence is a useful market signal: the identity problem is moving from conceptual concern to active protocol design.
For leaders, the practical question is simple: can the organisation explain, for every material automated action, which identity acted, whose authority it used, what scope applied and how that authority could have been withdrawn?
If not, the organisation does not yet have accountable autonomy.
Orchestration determines whether governance can intervene
Policies cannot govern an action they cannot intercept.
This makes orchestration, the coordination of steps, systems and decisions across a workflow, one of the most important enforcement layers. It knows what has happened, what is about to happen and which context should travel to the next step.
Imagine an agent handling a customer complaint. It identifies the customer, retrieves order history, calculates a remedy and prepares a refund. Governance at the model layer might check the quality of the generated response. That is useful, but insufficient. The material controls sit elsewhere:
- The retrieval layer determines which records the agent can see.
- The identity layer establishes whether it may act for this customer.
- The workflow layer checks the refund amount against delegated authority.
- The payment service enforces the transaction limit.
- The communication service determines whether the response may be sent automatically.
- The evidence layer records the entire chain.
The workflow is the unit of risk.
This is why prompt instructions and model guardrails cannot carry the full governance burden. A prompt can influence behaviour, but it cannot revoke a credential, stop an application programming interface call or enforce segregation of duties. The decisive controls must sit at points where systems can actually interrupt execution.
For CIOs and CISOs, this means architecture reviews need to move beyond model selection and application features. They must examine the complete decision path: identity, data, tools, state, hand-offs, exceptions and consequences.
Continuous evidence turns control into assurance
A control that cannot be evidenced is difficult to trust and harder to audit.
Traditional assurance often reconstructs events from application logs, tickets and interviews. That is labour-intensive even for deterministic software. It becomes less reliable when AI systems assemble context dynamically, select tools and generate different execution paths for similar requests.
Runtime governance should generate evidence as a by-product of operation.
For each material action, the evidence should connect the policy to the decision: which rule applied, which identity and delegation were present, what context was evaluated, what data was accessed, what action followed and whether a human intervened.
Policy engines already demonstrate part of this pattern. Open Policy Agent decision logs can capture the policy queried, the input supplied and related metadata, supporting audit and debugging. The broader challenge is linking those policy decisions to workflow traces, model interactions and business outcomes.
This has a commercial consequence. Better evidence can reduce the cost of manual assurance, accelerate approval of new automated workflows and shorten investigations when something goes wrong. It can also reveal where controls are creating unnecessary friction.
The objective is not maximum logging. It is decision-grade traceability.
Executable governance can still fail
The shift to runtime control creates its own risks.
Poorly translated policies can automate the wrong interpretation. Excessive checks can add latency or make critical workflows brittle. A central policy service can become a new point of failure. Teams may create broad exceptions to keep work moving, gradually undermining the control model. Rich logs can create new privacy and security exposures.
Most importantly, executable governance can create false assurance. A system can prove that a rule ran without proving that the rule was appropriate, complete or effective.
Some judgements should therefore remain human. Decisions involving ethics, material customer harm, legal interpretation or unusual context may require approval before action. Others may operate with a person supervising exceptions rather than every transaction. Low-risk, high-volume decisions may be suitable for fully automated control.
The design task is to match governance mode to risk.
Runtime governance should complement design-time assessment, deployment controls and post-event assurance. It is the missing layer between them, not a replacement for them. The case is strong for autonomous agents and automated workflows, but weaker as a universal claim across every enterprise system.
Leaders need a governance engineering agenda
The organisational implication is as significant as the technical one. Policies have traditionally been owned by legal, risk or compliance teams, while enforcement is implemented across security, platform, data and application teams. Runtime governance makes the hand-off between those groups part of the control itself.
Enterprises need a governance engineering capability: a cross-functional discipline that translates policy into testable operational controls, maintains them through change and measures whether they work.
A practical agenda starts with five decisions.
Classify workflows by autonomy and consequence. Identify where systems can access sensitive data, commit resources, communicate externally or change customer outcomes without prior review.
Define authority as precisely as functionality. Specify what each system may decide, which tools it may use, what limits apply and when control returns to a person.
Create shared policy and enforcement services. Avoid rebuilding permissions, data restrictions and audit logic inside every application. Use common interfaces and reusable controls where possible.
Instrument evidence before scaling autonomy. Record identities, policy decisions, tool calls, data access, exceptions and outcomes while workflows are still bounded enough to understand.
Design failure and exception paths deliberately. Decide whether controls fail open or closed, how urgent overrides work, who reviews exceptions and how temporary access is removed.
This is not an argument for a large platform programme before the use cases exist. Organisations should begin with the highest-risk automated workflows, use existing identity, policy and observability capabilities where they are sufficient and build only where a material gap remains.
The leadership question is no longer whether the organisation has an AI policy. It is whether that policy can survive contact with execution.
As machines take on more operational authority, governance must become capable of acting at the same point. The organisations that recognise this early will not remove human accountability. They will give it an infrastructure through which it can operate.
