Shift-left vs shift-right AI governance: where pre-deployment controls end and runtime enforcement begins

Defining shift-left and shift-right AI governance

Shift-left AI governance moves governance effort earlier in the lifecycle. It includes defining policy, assessing risk, deciding who and what an AI system can access, testing behavior, and gating release through review and approval. Its output is a documented decision: this system, for this purpose, under these conditions, is approved.

Shift-right AI governance applies controls while the system operates. It includes enforcing policy on individual interactions and tool calls, monitoring performance in the real operating setting, escalating to a human when an action crosses a defined threshold, and producing evidence of what happened. Its output is observed and enforced behavior.

The boundary between them is the moment live inputs arrive. Everything before that point is a judgment about expected behavior. Everything after it is a fact about actual behavior. A regulator asking what an AI system was allowed to do and what it did is asking for both: the approved intent from the left and the record of behavior from the right.

What each side cannot guarantee

Relying on shift-left alone leaves a gap between approved intent and actual behavior. A system can pass evaluation and review and still receive an input nobody tested, return sensitive data in a response, or call a tool in a way the approval did not contemplate. Least-privilege design limits which tools an agent holds, but it does not decide whether a permitted tool call is acceptable for a particular request. Pre-deployment evidence also ages. A point-in-time assessment says little about the system months later.

Relying on shift-right alone has the opposite problem. Runtime enforcement applies rules, but someone must decide which rules, for which systems, at what risk tolerance. Without design-time risk decisions, enforcement is arbitrary and the evidence it produces has no approved baseline to be compared against. Runtime controls also cannot fix a poorly scoped system or a use case that should not have been approved.

Agentic and tool-calling environments sharpen both gaps. Two controls matter most here. Least-privilege tool grants restrict what an agent can reach. Human-in-the-loop override thresholds act on individual high-risk or ambiguous actions. They address different failure points, and the second requires you to decide in advance which actions meet the threshold.

How the EU AI Act combines both sides

Regulation (EU) 2024/1689 is in force as of October 2026, and its structure reflects the split. For high-risk AI systems it requires a risk management system that is established, implemented, documented and maintained. That is a lifecycle obligation, not a one-time pre-launch exercise. It also provides that high-risk systems should only be placed on the market, put into service or used if they comply with mandatory requirements.

On oversight, the text says human oversight measures must be proportionate to the risks, the level of autonomy and the context of use. Some measures are identified by the provider and built into the system before it is placed on the market, where technically feasible. Deployers, in turn, carry responsibilities tied to monitoring performance in a real-life setting. Design of oversight sits on the left, and operation of it sits on the right.

Where an authority finds non-compliance, it can require corrective action, withdrawal or recall, with a period set by the authority and in any event within the shorter of 15 working days or as provided in the relevant Union harmonisation legislation. These remedies come after the fact. They show why organizations need to know their provider or deployer role and be ready to evidence and remediate quickly, but they are not a substitute for controls that act while the system runs.

For NIST AI RMF, a practical starting point is to connect AI governance to existing organizational risk controls and set risk tolerance ratings that consider financial, operational, safety, business, reputational and model risks.

Runtime enforcement as the shift-right layer

Runtime policy enforcement means the policy decision is made in the execution path, on each interaction or tool call, before the action completes. The possible outcomes are to allow, redact, block, rate limit, or escalate for human approval. This differs from after-the-fact review, which reads what already happened. Enforcement changes the outcome. Review only describes it.

Trussed provides this shift-right layer. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, at the level of individual interactions and tool calls. Policy is enforced at runtime, not reviewed after the fact. Because enforcement produces the record, the result is continuous, audit-ready evidence mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. Trussed runs self-managed in the customer cloud, with configurable retention and data residency. It has operated in continuous production in a regulated enterprise for more than 18 months.

Trussed does not replace the left side. Risk assessment, testing and approval decisions remain with your program, and they define the policy that runtime enforcement applies. The scope here is individual interactions and tool calls, not transaction-level governance or end-to-end tracing of agentic workflows.