The EU AI Act requires oversight of AI in use.Oversight means before execution, not after.
Article 14 requires that high-risk AI systems be subject to effective human oversight while they operate. Article 9 requires risk controls across the system lifecycle. Article 26 places these duties on the enterprises that deploy AI, not only the vendors that build it.
Runtime Authority Control is the authorization layer that satisfies the control half of the Act. RAC verifies and authorizes machine-initiated actions before they execute, under the policy in force, in the context that exists at that moment.
For enterprises deploying high-risk AI in the European Union.
The deadline moved. The obligation did not.
In July 2026, the Digital Omnibus on AI entered into force. Standalone high-risk obligations now apply from December 2, 2027. High-risk AI embedded in regulated products follows in August 2028. Other provisions were not deferred and apply on their original schedule.
European regulators and every major legal advisory are saying the same thing: the extension exists because standards were not ready, not because the requirements changed. Enterprises are expected to use the runway to build, and the guidance points specifically at human-oversight design.
Three articles. One architectural conclusion.
The Act does not tell enterprises how to build oversight. It tells them what oversight must be capable of.
Human oversight
High-risk AI systems must be designed so that natural persons can effectively oversee them while in use, including the ability to intervene and to interrupt operation. Oversight that begins after an action has executed is not oversight. It is review. The article describes a control point that sits in front of execution.
Risk management
Risk controls must operate across the full lifecycle of the system, including operation. A risk identified at runtime and mitigated at runtime requires an enforcement mechanism at runtime. Documentation of risk is not mitigation of risk.
Deployer obligations
The duty to use high-risk AI in accordance with its instructions, under appropriate oversight, falls on the deploying enterprise. Your vendor's controls do not discharge your obligation. The enterprise needs its own authorization layer, governing every machine-initiated action across its own systems, regardless of which vendor produced the model.
The conclusion is architectural, not legal: these obligations cannot be satisfied by anything that acts after execution.
You cannot intervene in something that already happened.
Machine-initiated actions trigger workflows, call APIs, modify records, and move money. Once an action executes, the consequence exists. A log can tell you it happened. A review can tell you it should not have. Neither can stop it.
The Act's language is precise: the capability to intervene, the capability to interrupt. Both are pre-execution capabilities. An enterprise whose oversight architecture consists of monitoring, logging, and periodic review has built an architecture that observes violations. The Act requires an architecture that prevents them.
Every machine-initiated action is checked against the policy in force before it executes. Authorized actions proceed. Unauthorized actions never happen. That is what oversight means when machines act.
The authorization layer for machine-initiated actions.
RAC operates in production today as the pre-execution enforcement layer between machine intent and enterprise execution.
Decisions in the path
Every machine-initiated action is authorized or denied in real time, before downstream systems are affected. RAC returns a deterministic outcome the calling system must obey.
Current policy, live context
Decisions are made against the policy in effect at the moment of action, in the context that actually exists, not against a policy snapshot from the last audit or a permission granted earlier.
Every machine actor
RAC governs actions regardless of which model, agent, orchestration layer, or automation framework initiated them. One authorization layer, every machine actor, one deterministic outcome.
This is not a compliance product. The EU AI Act is the forcing function. Control over what machines are allowed to do is the requirement your enterprise carries either way.
Enforcement is half the Act. Proof is the other half.
The EU AI Act also requires record-keeping, traceability, and the ability to demonstrate that governance held over time. That is a verification problem, not an authorization problem. It is addressed by a sibling category, in a sibling venture inside the Hartstone Institute portfolio.
Authorizes execution
The pre-execution layer. Every machine-initiated action is verified and authorized before it happens. Article 14 human oversight, Article 9 runtime risk mitigation, Article 26 deployer control.
Verifies governance held
Governance Verification Infrastructure. Continuous, decision-linked evidence that machine action remained within policy at the moment it occurred. Article 12 record-keeping, Article 19 log retention, post-market monitoring.
RAC enforces. CORTHEM proves. Two obligations, two architectural answers, one portfolio.
Read the CORTHEM EU AI Act Brief →Build the oversight architecturethe Act requires.
Enterprises deploying AI in Europe now hold a sixteen-month window before the deferred high-risk deadline. RAC briefings are scheduled selectively for teams with active machine-initiated execution and a genuine oversight mandate.
Submissions go directly to Runtime Authority Control. We respond to qualified enterprise inquiries within two business days.
Already exploring the console? Sign in · Want a reference walkthrough? See the reference demo
This page describes regulatory context for informational purposes and is not legal advice. Obligations under Regulation (EU) 2024/1689 as amended depend on system classification and deployment context. Enterprises should consult qualified counsel regarding their specific obligations.