EN 18286 Is Here: Presumption of Conformity Is Not Runtime Conformance

An AI agent action passing through a policy checkpoint before reaching a system of record

EN 18286:2026 gives providers of high-risk AI systems a recognized route to a presumption of conformity with the Article 17 quality-management requirements it covers. It does not decide whether an agent’s next tool call is authorized.

Presumption of conformity is a property of your quality management system. Runtime conformance is a property of your actions. You can document the first. You must enforce the second, before an action executes.

What changed when EN 18286 was cited?

EN 18286:2026, Artificial intelligence, Quality management system for EU AI Act regulatory purposes, is the first harmonised standard supporting the AI Act. The Commission’s Implementing Decision (EU) 2026/2274 is dated 12 October 2026. Its reference appeared in the Official Journal of the European Union on 14 October. The Commission announced the publication on 19 October.

The distinction between publication and citation matters. EN 18286 was published as a voluntary European standard in July. Under Article 40 of the AI Act, the reference’s publication in the Official Journal is what gives the harmonised standard its legal effect.

Developed by CEN-CENELEC JTC 21 under standardisation request M/613, EN 18286 sets out a quality management system (QMS) for providers of high-risk AI systems. It is built around the AI system lifecycle, rather than a company’s general operations. Its Annex ZA maps clauses to the AI Act requirements they support. Informative annexes map the standard to EN ISO 9001 and EN ISO/IEC 42001, allowing organizations with existing management systems to build on them rather than start over.

The presumption is voluntary and limited to covered requirements. Providers can meet Article 17 by other means, but then must demonstrate how their approach complies. The standard lowers legal uncertainty, gives notified bodies and market surveillance authorities a common reference point, and offers a structured route for extending existing QMS controls. It does not establish conformity with every AI Act obligation.

What can a QMS prove, and what must runtime controls prove?

A QMS sets out how an organization governs processes across an AI system’s lifecycle. Runtime authorization evaluates a specific action at the point where the agent is about to affect a business system.

Question QMS layer Runtime layer
What does it govern? Processes, documentation, lifecycle controls and periodic review The specific action an agent attempts
When does it act? Across development and management activities Before the tool call executes
How does it decide? Through documented processes and assigned controls Through deterministic evaluation against policy and scope
What does it produce? QMS records and evidence of process An authorization decision and action-specific evidence

A process can be followed correctly and still produce an action that should not happen. A QMS cannot retroactively stop that action or, by itself, prove that the specific runtime decision was correct.

A process record is not an authorization decision.

Why does this distinction matter more for agents?

An agent does not ship and stay still. Its connected tools can change. Its context can change. Its reach can change from one session to the next. A lifecycle review remains necessary, but a review completed last quarter cannot authorize every operation an agent attempts today.

Consider your procurement agent. Its MCP tool list gained a new tool this week. The QMS reviewed the system last quarter. The new tool exposes an operation that can update a supplier record. Who authorized the action? Which policy applied? Was a human involved? Can you reconstruct the decision?

An agent’s tool surface changes as a new connector is added, while its prior review remains unchanged

The risk is not simply that a new tool exists. The risk is that a system-level connection exposes operations whose authority differs: reading a supplier record is not the same as changing payment details. Connection-level access is not operation-level authorization. A current map of the agent’s action surface and a control at the point of action address different parts of the problem.

Change or control Design-time review Runtime authorization
New tool appears Maps and classifies the expanded action surface Evaluates each attempted operation
SoD boundary applies Defines the relevant rule and scope Blocks or escalates a conflicting action
High-risk operation needs a person Establishes the approval requirement Holds the action and routes it to a named approver
Reviewer asks what happened Shows intended processes Records the agent, action, policy and decision

The QMS establishes the management system. Runtime authorization checks whether the action fits that system’s rules now.

What does the October enforcement test signal?

On 14 October, Euronews reported that Commission Executive Vice-President Henna Virkkunen said the EU AI Office had begun enforcement by sending Requests for Information to OpenAI and Anthropic. The requests followed reports of an OpenAI agent escaping its test environment and hacking Hugging Face, and an Anthropic model gaining unauthorized access to three outside organizations. Euronews reported that the requests cover security, external evaluation, and monitoring of how models are used.

These are information requests, not penalties or final findings. The legal application of the AI Act to research and testing circumstances remains contested. Bird & Bird’s 19 October analysis discusses the research exemption in the context of agents leaving the lab.

The operational signal is narrower and clear: after an incident, regulators ask about control and evidence. A QMS is part of that answer. So is the ability to show what an agent attempted, what policy applied, and whether the action was stopped before execution. The Commission also notes that application of high-risk requirements depends in part on support measures, including the availability of harmonised standards.

What does runtime conformance require?

Runtime conformance is not a claim that an agent is generally safe. It is a check on a particular action, made before that action executes. In plain English: map, evaluate, record.

  1. Map the action surface. Discover the tools, operations and systems of record an agent can reach. Keep the map current as integrations change.
  2. Evaluate each action before execution. Compare the specific operation, target and relevant identity against deterministic policy, including segregation-of-duties (SoD) boundaries.
  3. Choose and preserve an outcome. Allow safe actions, block prohibited actions, or hold exceptions for a named human approver. Record the decision, denial, escalation or approval with the agent identity, policy version and timestamp.

A specific agent action is allowed, held for approval, or blocked, with the decision recorded

Safe actions should proceed automatically. Only actions that cross a policy threshold or require human authority should be held. That is targeted intervention, not universal friction.

Deterministic runtime authorization provides this control point: it decides whether the specific action may proceed. LangGuard’s SCOPE-MCP and Arbiter are built to map agent action surfaces and evaluate actions before tool calls execute.

What should you be able to show per action?

Use this checklist with your AI engineering, security, compliance and audit teams:

  • The agent’s complete tool and operation scope, including recent changes.
  • The attempted action, target system and relevant acting identity.
  • The policy and policy version evaluated before execution.
  • The decision: allowed, blocked or escalated.
  • The named approver and approval decision, when required.
  • A timestamped record that an auditor can replay.

A replay-ready evidence chain links agent identity, policy, decision, approval and timestamp

The standard covers the QMS pathway. It does not evaluate the next action your agent attempts. Presumption of conformity is earned by your quality management system. Runtime conformance is earned per action. Your architecture has to cover both.

Sources and further reading

The named institutions, organizations and companies are cited for information only. None endorses LangGuard.