AI Act: the first harmonised standard is published, high risk delayed

Two pieces of AI Act news landed this summer and autumn, and they have to be read together. First, the obligations applying to high-risk AI systems listed in Annex III were pushed back from 2 August 2026 to 2 December 2027. Second, the regulation’s first harmonised standard was published on 14 October 2026: EN 18286, covering the quality management system.

Taken separately, the two send opposite signals: sixteen months of breathing room on one side, a normative requirement on the other. Taken together, they say the same thing. The timetable moved, the level of expectation did not, and you now know which reference to work against during the delay. Here is what the standard contains, what the presumption of conformity is actually worth, and what is useful to do between now and then.

What was published, and when

The Commission adopted implementing decision (EU) 2026/2274 on 12 October 2026, published in the Official Journal of the European Union on 14 October. It publishes the reference of standard EN 18286:2026, adopted by CEN and CENELEC in July 2026, titled “Artificial intelligence: quality management system for the European AI regulation”.

This is the first harmonised standard published under the AI Act. Others are expected: the standardisation request given to the European standardisation bodies covers around ten key areas of the regulation, from risk management to robustness and data quality. So this is a first stone, not the complete framework.

What the standard actually covers

EN 18286 is designed to help providers of high-risk AI systems implement article 17 of the AI Act, which requires a documented quality management system. It covers the system’s full life cycle.

• Governance: roles, responsibilities, quality policy, resources.
• Design and development: specifications, technical choices, traceability of decisions.
• Risk and data management: what feeds the system, where it comes from, how it is controlled.
• Verification and validation: the tests, and the evidence that you ran them.
• Change control: what happens when the model, the data or the configuration change.
• Post-market monitoring and reporting of serious incidents.

One reassuring point for smaller organisations: article 17(2) provides that implementation stays proportionate to the size and characteristics of the organisation. The standard does not impose a large industrial group’s apparatus on an SME, but it does require that every subject has been thought through.

If that list reminds you of a classic quality management system, that is no accident. The logic is documented quality applied to AI, and the standard can be folded into existing quality arrangements rather than living alongside them.

The presumption of conformity, and its limit

The value of a harmonised standard lies in a precise mechanism: a provider who applies it is presumed to comply with the requirements it covers. In an inspection, the burden of demonstration drops considerably, since establishing that the standard was followed is enough.

One legal nuance deserves flagging, and it is rarely mentioned. Article 40(1) of the regulation ties the presumption to the requirements in section 2 of chapter III, while article 17, on the quality management system, sits in section 3. Practitioners note that the basis for that presumption with regard to article 17 remains to be clarified. In other words, the protective effect is announced, its exact footing will be settled in practice.

Two other limits are worth stating. Applying the standard stays voluntary: you can demonstrate conformity another way, simply without the presumption. And the standard does not exempt you from the AI Act requirements it does not cover, nor from the conformity assessments required elsewhere.

The delay, and what it does not delay

The regulation (EU) 2026/1744, the AI strand of the European simplification package, pushed back the application of the high-risk obligations. Standalone systems listed in Annex III move from 2 August 2026 to 2 December 2027. Systems embedded in already regulated products, in Annex I, move to 2 August 2028.

Beware the common misreading. The delay covers the substantive requirements of chapter III. It does not touch the prohibitions in article 5, which still apply, nor the AI literacy obligation, meaning training for the teams who design or use these systems. We set out that split in our article on what actually applies since 2 August 2026.

Sixteen extra months is both a lot and very little. A lot, if you start now. Very little, if your system is already in production and the documentation does not exist: reconstructing the traceability of training data and design decisions after the fact is the most expensive exercise in the whole framework.

Are you even in scope?

That is the question to settle before any other, and the answer is no for most of the projects brought to us. The high-risk regime targets specific uses: biometrics, critical infrastructure, education, employment and worker management, access to essential services, law enforcement, migration, justice and democratic processes. To these are added AI systems embedded as a safety component in products already covered by EU legislation.

An internal assistant that summarises documents, a writing tool, a semantic search engine over your document base do not fall under this regime. On the other hand, a tool that screens job applications, scores employees, conditions access to an essential service or drives a safety device does, even if the AI part looks modest to you.

Classification follows the use, not the technical sophistication. That is exactly the work we do during AI scoping: determining the applicable regime before writing the first line of code, because it drives the architecture, the documentation and the budget.

Provider or deployer, the distinction that changes everything

The regulation does not treat the party that places a system on the market and the party that uses it in the same way. The provider develops the system, or has it developed, and markets it under its own name or trademark. The deployer uses it under its own authority in the course of its professional activity.

EN 18286 addresses providers: the article 17 quality management system is their responsibility. A deployer has real but markedly lighter obligations, essentially using the system in line with its instructions, ensuring competent human oversight, monitoring its operation and keeping the logs.

Many companies believe they are providers when they are deployers, and worry for nothing. Others do the opposite, which is more awkward, because three situations turn a deployer into a provider: putting your name or trademark on a high-risk system, substantially modifying it, or changing its purpose so that it becomes high risk when it was not.

What if you simply call an API?

This is the most frequent configuration in our projects: the intelligence comes from a third-party model called through an API, and the product is the one you build around it. That setup does not automatically make you the provider of a high-risk system, and it does not shield you either.

What counts is the use your product serves and the name it is sold under. If you publish a candidate screening tool under your brand, it hardly matters that the reasoning is delegated to an external model: it is your system, for a use listed in Annex III. Conversely, an internal writing assistant calling the same model stays outside the high-risk regime.

Two practical consequences. The first is contractual: your model providers must give you what you need to document your system, and reversibility matters, since changing model should not force you to redo all your documentation. We covered that question of independence in our article on OpenRouter. The second is architectural: logging inputs, outputs and the model version in use costs little when planned from the start, and becomes very expensive to retrofit.

What is useful to do during the delay

If you are in scope, four workstreams fit into sixteen months without tying up a whole team.

Start by classifying your systems one by one, and writing that classification down. A dashboard listing your AI uses, their regime and the person responsible for each beats a shared verbal conviction. It is also the document the first auditor will ask for.

Then put traceability in place as you go, not retrospectively. Where the data comes from, who approved which dataset, which model version runs in production, who decided what. A Git repository, tickets and a decision log are enough to start; what costs dearly is reconstructing all of it two years later.

Treat post-deployment monitoring as a product feature, not a compliance chore. Usable logging, drift detection, a procedure for reporting serious incidents. The same building blocks serve product quality and compliance, which is what makes the investment pay. We reached the same conclusion on AI agent security.

Finally, train the teams. The AI literacy obligation was not postponed, and it is the easiest to satisfy: who uses what, for what, and within which known limits.

What it changes for a budget

Compliance is not a line added at the end of a project, it is an architectural constraint. A system designed from the start with its traceability, tests and logging costs moderately more. The same system brought into compliance afterwards is paid for in rework, sometimes in a rebuild.

It is the same logic as the one described in our article on the cost of an AI project from POC to production: the model weighs little in the bill, industrialisation weighs a lot, and compliance is part of industrialisation. The publication of EN 18286 has at least this merit: it gives you a list of items to cost, instead of a vague risk.

What we take away from it

The AI Act’s first harmonised standard has existed since 14 October 2026. It covers the article 17 quality management system, spans the full life cycle, and opens a presumption of conformity whose exact legal footing remains to be clarified. Applying it is voluntary, and it does not cover the whole regulation.

In parallel, the Annex III high-risk obligations were pushed to 2 December 2027, those in Annex I to 2 August 2028. The prohibitions and AI literacy, meanwhile, already apply.

So the right reading is not “we have time”, it is “we finally know what to build, and we have sixteen months to do it properly”. We support this classification and implementation work in our AI transformation projects. If you do not know whether your systems fall under the high-risk regime, let’s talk.