AI Act, EN 18286 and ISO/IEC 42001: A Chief Compliance Officer's Agenda

In brief

The citation of EN 18286 changes a Chief Compliance Officer's question from "what will the standard say?" to "can we show that our quality management system meets it?" Answering it depends on decisions only the compliance function can drive.

• Start with the inventory and your role. Obligations attach to roles (provider, deployer, importer, distributor), and roles shift when a system is rebranded, substantially modified or repurposed.¹
• Plan to the real dates. High-risk duties apply from 2 December 2027 for Annex III systems and 2 August 2028 for AI in Annex I products. The prohibitions, AI literacy and Article 50 transparency rules already apply, and two further prohibitions arrive on 2 December 2026.²
• Build one system, not three. Use ISO/IEC 42001 for organisation-wide AI governance and EN 18286 as the regulatory QMS for each high-risk system you provide. An ISO/IEC 42001 certificate is not AI Act conformity.³⁴
• Close the gaps the standards leave. Only Article 17 has a cited standard. Articles 9 to 15 must be evidenced by your own documented means until more standards are cited.⁵⁶
• Contract for it. The Act requires written agreements with suppliers of AI systems, models, tools and components used in high-risk systems.¹

This is the third post in our series. The first introduced EN 18286 and how the Commission brought it into play; the second explained how it relates to the AI Act and ISO/IEC 42001.

Start with the inventory and the role map

Every AI Act obligation attaches to a role and a risk category. Until you know which AI systems you have, what each is for, and which role you play for each, neither EN 18286 nor ISO/IEC 42001 can be scoped.

Build the inventory. List every AI system the organisation develops, buys, embeds or uses, including general-purpose models consumed through APIs. ISO/IEC 42001 already expects this: the organisation must consider each system's intended purpose and determine its roles (clause 4.1).⁷

Classify against Article 6. A system is high-risk if it is a safety component of, or is itself, a product under Annex I legislation that requires third-party conformity assessment, or if it falls within an Annex III use case.⁸ Three details deserve attention.

• The Digital Omnibus narrowed the Annex I route. AI used solely for non-safety purposes such as user assistance, performance optimisation or quality control is not a safety component, unless its failure would endanger health and safety.⁸
• An Annex III system escapes high-risk status if it poses no significant risk, for example because it performs only a narrow procedural or preparatory task. A system that profiles natural persons is always high-risk.⁸
• A provider relying on that derogation must document its assessment before placing the system on the market, register it, and produce the assessment on request.⁸

Map the role for each system.

Sources: ⁴, ¹, ⁹, ¹⁰.

The third row is where most organisations are caught out. A business unit that points a general-purpose model at CV screening or creditworthiness has, in law, become a provider of a high-risk system.¹ The CCO's job is to make that decision visible before it is taken, not after.

Get the timeline right

Much guidance still in circulation describes the pre-Omnibus timetable. These are the dates that now matter.²¹¹⁵

AI Act milestones after the Digital Omnibus, February 2025 to August 2028

Sources: ³, ², ¹¹, ⁵.

Three readings follow. First, nothing already in force was deferred: the prohibitions, AI literacy, general-purpose AI model duties and Article 50 transparency all apply, and two new prohibitions bite on 2 December 2026.² Second, the standards pipeline runs on a different clock from the application dates. The amended standardisation request expires on 28 February 2027, but the drafts on risk management, cybersecurity and logging were all rejected at enquiry in 2026, so some Section 2 standards may arrive late in the window, or after it.⁵ Third, thirteen months is short for a conformity programme. Classification, a QMS built to EN 18286, technical documentation, supplier agreements and, for biometrics, a notified body all sit on the critical path. One transitional rule cuts the other way: high-risk systems already on the market before their application date are caught only if their design changes significantly afterwards, although systems intended for use by public authorities must comply by 2 August 2030 regardless.¹²

Choose the management system architecture

The second post in this series argued for one integrated system in three layers: ISO/IEC 42001 for the organisation, EN 18286 for each regulated system, and documented means for the requirements no standard yet covers. For a CCO, three decisions follow.

Where EN 18286 sits. If you provide high-risk systems, make EN 18286 the spine of the regulatory QMS. It is now the reference against which your own Annex VI check, or a notified body's Annex VII assessment, will read Article 17.¹³⁶ If you already run ISO 9001, ISO 13485 or ISO/IEC 42001, extend that system rather than build a parallel one, as the Commission itself recommends.³

Whether to certify against ISO/IEC 42001. Certification is a commercial and governance choice, not a legal one. An ISO/IEC 42001 certificate is not conformity with the Act and is not a notified-body certificate under Article 44.⁴ It is still worth having for many organisations: it gives customers an auditable signal and disciplines the organisation-wide layer (policy, inventory, impact assessment, supplier control) that the Act does not itself prescribe for most systems.

How to treat the presumption. A presumption of conformity is a rebuttable evidential advantage, not a safe harbour.⁵ It covers only the provisions mapped in Annex ZA, attaches only if you conform to the mapped clauses, lapses if the Official Journal reference is withdrawn,¹⁴ and in places depends on conditions, such as technical documentation that contains every Annex IV element and a risk management system that complies with Article 9.¹³ Claim it in the technical documentation only for what EN 18286 covers, and justify Articles 9 to 15 requirement by requirement.⁶

Two phrases should never appear in a board paper. "We are ISO/IEC 42001 certified, so we are AI Act compliant" is wrong in law. "We follow EN 18286" is true only of the QMS; it says nothing about the risk management, data, logging, oversight, accuracy, robustness or cybersecurity of the systems themselves.⁶

Evidence, conformity assessment and life after launch

A QMS is judged by its evidence. Three workstreams carry most of the load, and each has a long lead time.

Pick the conformity assessment route early. For most Annex III systems (points 2 to 8), conformity assessment is internal control under Annex VI, with no notified body.¹¹ The provider verifies its own QMS against Article 17 and its technical documentation against Section 2.⁴⁶ For biometric systems under Annex III point 1, internal control is available only where harmonised standards or common specifications covering Section 2 have been applied; today, that means a notified body under Annex VII.¹¹ For AI in Annex I products, the sectoral conformity assessment applies, with the Article 17 QMS assessed within it, and notified bodies designated under sectoral law must apply for AI Act designation by 28 January 2028.¹¹ If you will need a notified body, start the conversation now.

Produce the technical documentation system by system. EN 18286's presumption reaches the duty to draw up technical documentation before placing on the market and keep it current, but only if that documentation contains every Annex IV element; the standard does not supply the content.¹³ Annex IV still has to be completed for each system, and EN 18286 adds documentation demands of its own, such as reproducible test records and a documented rationale for every decision on whether a modification is substantial.¹³ SMEs, start-ups and small mid-caps may use a simplified Commission form, which notified bodies must accept.¹⁵

Run post-market monitoring and incident reporting as live processes. Article 17 requires both inside the QMS.¹⁶ The reporting clock is short: a serious incident must be reported within 15 days of awareness, within 10 days where a person has died, and within 2 days for a widespread infringement or a serious and irreversible disruption of critical infrastructure. An incomplete initial report is allowed.¹⁷ Build the playbook to the Act, not only to EN 18286. The standard's two-day category mentions critical infrastructure but not widespread infringements, and it starts the clock when the provider becomes aware, whereas Article 73 can start it from the deployer's awareness.¹³¹⁷ Deployers who identify a serious incident must tell the provider first, then the importer or distributor and the authority.⁹ Your incident playbook must therefore work across company boundaries, which brings us to contracts.

Supply chain and contracts

The Act has turned AI supply chains into regulated relationships. Four points should shape every contract that touches a high-risk system.

A written agreement is mandatory, and its absence is fineable. A provider of a high-risk system and any third party supplying an AI system, AI model, tools, services, components or processes used in it must agree in writing the information, capabilities, technical access and other assistance the provider needs to comply, judged against the state of the art.¹ Since the Digital Omnibus, breach of that duty sits in the tier of fines up to EUR 15 million or 3% of worldwide turnover.¹⁰ Free and open-source components are exempt, but general-purpose AI models are not.¹ The AI Office may publish voluntary model terms.¹

Plan for a change of provider. Where a customer becomes the provider under Article 25(1), the original provider must cooperate. It must hand over technical documentation, disclose known limitations and failure modes, and give targeted technical access for testing and validation.¹ That duty falls away if the original provider clearly specified that its system is not to be turned into a high-risk system.¹ Expect vendors to write exactly that into their terms. If you intend a high-risk use, negotiate the cooperation package expressly before you sign.

Allocate the obligations that rebranding moves. Putting your name or trademark on a high-risk system makes you its provider, but the Act preserves contractual arrangements that allocate the obligations otherwise.¹ Draft that allocation deliberately, and match it to who can actually run the QMS, the technical documentation and incident reporting.

Use EN 18286's supply-chain clause as the contract map. A provider applying the standard needs documented criteria for selecting suppliers, proportionate to the risk of the AI system; a plan for monitoring and re-evaluating them; a way of passing on the specifications they must meet; and a documented decision on how far each supplied product, component, dataset or service is controlled, which can range from checking a certification to reviewing code (clause 9.3).¹³ Where the provider cannot monitor a system directly, it must also put the deployer's monitoring requirements into the instructions for use, and it must tell deployers what to do when the system is retired (clauses 9.5.5 and 8.6).¹³ Each of those needs a contractual hook.

Make the standards contractual. Clauses that work well in practice include:

• a warranty that the supplier's QMS for the relevant system conforms to EN 18286:2026, with evidence on request and prompt notice of any non-conformity;
• delivery of the instructions for use and the information the deployer needs for its own data protection impact assessment and, where applicable, fundamental rights impact assessment;⁹
• incident cooperation timed to the Article 73 clock, with a short contractual deadline for the deployer to notify the provider, since the statutory clock can start from the deployer's awareness;¹⁷
• log retention and access consistent with the deployer's six-month minimum;⁹
• ISO/IEC 42001 certification as a supplier-governance signal, without treating it as evidence of AI Act conformity;⁴
• change control, with notice of substantial modifications and model updates that could trigger a new conformity assessment.¹¹

On the sell side, the same list becomes a disclosure pack. Providers who can hand customers an EN 18286 conformity statement, a complete instructions-for-use set and a tested incident interface will be better placed in procurement.

Governance, accountability and the board

Name the accountable people. Article 17(1)(m) requires an accountability framework setting out the responsibilities of management and staff for every QMS aspect.¹⁶ ISO/IEC 42001 supplies the organisational frame: leadership by top management, an AI policy, defined roles, internal audit and management review.⁴ EN 18286 is more specific. Top management must assign responsibility for, and remain accountable for, reporting on QMS performance, overseeing AI risk management, and keeping regulatory requirements and the state of the art under review. The people who oversee risk management and approve risk controls must hold named roles, with the authority to intervene.¹³ The CCO should own the framework, not every control. Engineering owns lifecycle evidence, procurement owns supplier terms, and the business owns intended-purpose decisions.

Treat AI literacy as a recorded programme. Since the Digital Omnibus, providers and deployers must take measures to support AI literacy, rather than ensure a sufficient level of it. The duty has applied since 2 February 2025; it now expressly requires no particular level of literacy in any individual and is judged on the measures taken.²¹⁸ For providers, EN 18286's competence and awareness clauses give that record a natural home.¹³ Record who was trained, on what, and why that fits their role.

Connect the AI Act to the regimes you already run.

• Data protection. Deployers must use the provider's information in their data protection impact assessment, and the Omnibus added a broader legal basis for processing special-category data to detect and correct bias.²⁹
• Financial services. Financial institutions can satisfy most of Article 17, and the deployer monitoring duty, through their internal governance rules, but must still deliver risk management, post-market monitoring and incident reporting.¹⁶⁹ Firms already managing ICT third-party risk under DORA should bring AI suppliers into the same register and contract programme.
• Regulated products. For AI in products covered by the sectoral legislation in Section A of Annex I, the Omnibus allows specific AI Act requirements to be limited where that legislation already gives equivalent or higher protection; the Commission must specify how by delegated acts due by 2 August 2027.¹⁹

Report exposure to the board, not activity. A useful quarterly report covers the number of high-risk systems by role; each system's conformity route and readiness against its application date; open gaps against Articles 9 to 15; Article 25(4) supplier agreements in place; incidents and near misses; and movement in the standards pipeline. EN 18286 requires management reviews to involve top management periodically, and an extra review whenever a serious-incident investigation finds the QMS wanting.¹³ Make the stakes explicit. Fines reach EUR 35 million or 7% of worldwide turnover for prohibited practices, and EUR 15 million or 3% for most provider, deployer and supply-chain obligations, with lower caps for SMEs and small mid-caps.¹⁰

A CCO checklist

Grouped by when each item needs to be done.

Before 2 December 2026

• Complete the AI inventory, including general-purpose models used through APIs, recording intended purpose and role for each system
• Screen every system against the ten Article 5 prohibitions, including the two that apply from 2 December 2026
• Confirm Article 50 transparency, and machine-readable marking for generative systems already on the market
• Document the AI literacy measures taken for each role

During 2027

• Classify each system under Article 6, and document any Annex III derogation before placing the system on the market
• Obtain EN 18286:2026 and gap-assess your existing management systems (ISO 9001, ISO 13485 or ISO/IEC 42001) against it
• Decide whether to certify to ISO/IEC 42001, and scope the AIMS around the inventory
• Choose the conformity assessment route for each system, and engage a notified body early if one is needed
• Put Article 25(4) written agreements in place with every supplier of AI systems, models, tools or components used in high-risk systems, aligned with EN 18286's supplier-control requirements
• Build the serious-incident playbook to Article 73's 2, 10 and 15-day clocks, including clocks that start from a deployer's awareness, across supplier and customer boundaries
• Track the Section 2 standards and any common specifications, and document interim means for Articles 9 to 15

Before 2 December 2027 (Annex III) or 2 August 2028 (Annex I)

• Complete technical documentation, the EU declaration of conformity, CE marking and registration for each high-risk system you provide
• As a deployer, assign competent human oversight, keep logs for at least six months, inform workers and affected persons, and complete any required fundamental rights impact assessment
• Run a mock conformity assessment and a tabletop incident exercise, and report the results to the board

Sources: ², ¹, ⁹, ¹¹, ¹⁷, ⁸.

Related reading in this series

• Part 1 — Introducing EN 18286: The AI Act's Quality Management Standard
• Part 2 — The AI Act, EN 18286 and ISO/IEC 42001: How the Three Fit Together

Disclaimer

This article is general information, not legal advice, and does not create a client relationship. It reflects the AI Act as amended by Regulation (EU) 2026/1744 and the standards landscape as at 31 October 2026. Application dates, Commission guidance and the status of standards in development continue to move; verify the current position before acting. Statements about EN 18286 and ISO/IEC 42001 have been checked against the texts of EN 18286:2026 and ISO/IEC 42001:2023 and are paraphrased, not reproduced; both standards should be read in full before any conformity or certification claim is made. Contract clauses suggested here are illustrations, not drafting, and need tailoring to the system, the parties and the governing law.

Notes and sources

Footnotes

1. AI Act, Article 25, consolidated text as at 27 July 2026. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹

2. Regulation (EU) 2026/1744 of 8 July 2026 (Digital Omnibus on AI), OJ L, 2026/1744, 24 July 2026; summarised in Digital Omnibus on AI: what changed in the EU AI Act, euaiact.com. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

3. European Commission, First harmonised standard supporting the AI Act published in the Official Journal, 19 October 2026. ↩ ↩² ↩³

4. Modulos, ISO/IEC 42001 vs EU AI Act, updated 23 October 2026. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

5. G. P. Krog, Edition 16 (September 2026): the essence, AI Standardisation Watch, 8 September 2026. ↩ ↩² ↩³ ↩⁴ ↩⁵

6. spilma, AI Act: EN 18286 is the first harmonised standard cited, updated 16 October 2026. ↩ ↩² ↩³ ↩⁴ ↩⁵

7. ISO/IEC, ISO/IEC 42001:2023, Information technology – Artificial intelligence – Management system, first edition, December 2023. ↩

8. AI Act, Article 6, consolidated text as at 27 July 2026. ↩ ↩² ↩³ ↩⁴ ↩⁵

9. AI Act, Article 26, consolidated text as at 27 July 2026. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

10. AI Act, Article 99, consolidated text as at 27 July 2026. ↩ ↩² ↩³

11. AI Act, Article 43, consolidated text as at 27 July 2026. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

12. AI Act, Article 111, consolidated text as at 27 July 2026. ↩

13. CEN, EN 18286:2026, Artificial intelligence – Quality management system for EU AI Act regulatory purposes, approved by CEN on 12 July 2026 (available from national standards bodies). ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰

14. AI Act, Article 40, consolidated text as at 27 July 2026. ↩

15. AI Act, Article 11, consolidated text as at 27 July 2026. ↩

16. AI Act, Article 17, consolidated text as at 27 July 2026, AI Act Service Desk. ↩ ↩² ↩³

17. AI Act, Article 73, consolidated text as at 27 July 2026. ↩ ↩² ↩³ ↩⁴

18. AI Act, Article 4, consolidated text as at 27 July 2026. ↩

19. AI Act, Article 2(13), in the EUR-Lex consolidated text as at 27 July 2026. ↩