Runtime control can verify whether an AI system operates within defined boundaries. It can determine whether an action is authorized, whether a condition has been met, or whether a defined limit has been exceeded.
But these controls rely on an assumption:
that the conditions they enforce still hold.
This is where a different governance problem emerges.
A system can behave correctly and a control can function correctly while the conditions underlying the original authorization have changed.
The deployment context can change. The system’s capabilities can shift. Responsibilities or workflows can change.
A technically robust control architecture can therefore provide precise evidence that a governance condition was enforced correctly even though that condition is no longer appropriate.
These are two different questions:
Enforcement correctness:
Was the specified condition enforced correctly?
Governance validity:
Does that condition still hold under current circumstances?
This is where runtime control reaches its limit. When an authorization is translated into an executable control, it must be possible to verify not only whether that control operates correctly, but also whether the conditions underlying the authorization still hold.
That assessment cannot simply be performed by the runtime control itself. Its task is to enforce the applicable condition. If it were also to decide whether that condition still holds or needs to be changed, enforcement, revalidation, and modification would be combined within the same authority.
A trigger for revalidation does not fully solve the problem either. It can only respond to changes that produce a relevant signal within its defined observation space. Other changes may fall outside that space. They may also become visible first in the surrounding workflow while runtime telemetry continues to appear normal.
The absence of a trigger therefore cannot automatically mean that an authorization remains valid.
Between two reviews, a condition may remain formally in force even though its underlying assumptions have already eroded.
The tolerable delay before revalidation therefore depends on the deployment context. The higher the execution frequency and the greater the potential consequences, the shorter the acceptable interval between reviews may become. This raises requirements for provider-side architecture, evidence capabilities, and integration.
Revalidation therefore becomes more than a governance requirement. It affects integration costs and the conditions under which a system can be deployed operationally.
The architectural question therefore shifts:
From:
Where and how is a governance condition enforced?
To:
How do we know when the conditions underlying an authorization no longer hold, when must they be revalidated, and who has the authority to change them?