EN 18286 readiness in 5 steps: from AI governance to auditable compliance

In the first article of our series we introduced EN 18286:2026, and in the second we clarified why ISO/IEC 42001 does not replace Article 17 of the AI Act. Now comes the question that ends every one of these conversations: “Fine, but what do I actually do on Monday morning?” This article answers that – in five steps, with concrete outputs. Let's start with the most important message: in all likelihood, you do not have to build from scratch.

Why you don't have to start from zero

The most common mistake we see in readiness projects is that the organisation launches a separate, parallel “AI Act project” – with new document templates, a new risk methodology and a new audit cycle, alongside the management systems it already has. This is expensive, slow, and in the end two systems compete for the same resources.

The structure of EN 18286 suggests exactly the opposite. The standard is built on the classic ISO frame of clauses 4–10, and in its informative annexes it explicitly provides a mapping to ISO 9001 (Annex C) and to ISO/IEC 42001 (Annex D). This is no accident: the drafters assumed that most affected organisations already run some kind of management system.

The real work, therefore, is not building the system but extending the existing one and inserting the missing, AI-specific layers. Here is how that looks in five steps.

Step 1 – Mapping AI systems and roles

Goal: to know what you have, and in what capacity you are present on the market.

During the inventory, many organisations find more AI systems than they initially accounted for. The typical reasons are built-in AI features of SaaS tools, home-grown scoring logic, and “shadow AI” – tools introduced independently by business units. The exact gap varies by organisation, which is why it has to be uncovered through an inventory.

Two dimensions must be recorded for every system:

• What is this system? Intended purpose, user base, what decision it supports or makes, on what data.
• What is our role in it? This is the critical question. The AI Act distinguishes, among others, between the provider and the deployer. Under Article 25, a distributor, importer, deployer or other third party may in certain cases become a provider: for example if they put their own name or trademark on a high-risk AI system already placed on the market or put into service, make a substantial modification to it, or change the intended purpose in such a way that a system that was previously not high-risk becomes high-risk.

Customisation and white-label solutions are therefore worth subjecting to a separate legal and technical review. Fine-tuning a recruitment tool or offering a credit-scoring feature under your own brand does not automatically make the organisation a provider; the conditions of Article 25 have to be assessed on the basis of the specific modification, the use of the brand name and the intended purpose.

Output: an AI inventory recording, per system, the intended purpose, the role and the legally relevant classification – for example prohibited practice, high-risk, subject to transparency obligations under Article 50, or other. How long the exercise takes depends on the size of the organisation and the visibility of AI use; 2–4 weeks can be treated as a project estimate at best.

Step 2 – Determining the applicable AI Act requirements

Goal: to make the scope of the project a question of fact, not a matter of debate.

After the inventory, it has to be decided per system which requirements apply. This is not a theoretical exercise: it directly determines how much work lies ahead of you.

Classification	What comes into play	Deadline
High-risk, Annex III	The relevant requirements and provider obligations of Chapter III, Sections 2–3, plus – where applicable – conformity assessment, registration in the EU database, post-market monitoring and incident reporting	2 December 2027
High-risk, Annex I (product-embedded)	The relevant AI Act requirements aligned with the related Union product legislation and its conformity assessment regime	2 August 2028
Systems and uses subject to transparency under Article 50	The case-dependent transparency obligations under Article 50	Already applicable (2 August 2026)
Providers and deployers of AI systems	Article 4 – AI literacy	Already applicable (2 February 2025)

Annex ZA of EN 18286 indicates which AI Act requirements the standard aims to cover, including Article 17(1) and the first sentence of Article 11(1). At present, however, there is no OJEU citation. The legal effect of a future citation would have to be judged on the basis of Article 40 of the AI Act and the precise scope determined by the Commission; it is therefore not advisable to promise an automatic, full presumption of conformity under Article 17 in advance.

Output: a per-system requirement map (“applicability matrix”) that assigns the applicable articles and the responsible organisational unit to every affected system.

Step 3 – Reusing existing processes

Goal: to find what already exists – it is simply not documented in AI language. In our experience, for an organisation with a working ISO system this is typically 40–60 per cent of the requirements; this is an estimate based on our own project experience, not published statistics.

This step significantly influences the time and resource needs of the project. The more existing processes, controls and evidence can genuinely be reused, the smaller the new compliance layer that has to be built.

The key word is extension: the same document control procedure, the same audit programme, the same management review cycle – supplemented with inputs relating to AI systems. Do not launch a separate project for something that can be solved by widening the scope of an existing procedure.

Output: a reuse map that assigns existing procedures to the clauses of EN 18286 and marks which ones need only a scope extension and which have to be substantially rewritten.

Step 4 – Identifying the real gaps

Goal: so that you know exactly where new work arises – and how much.

The gap analysis is best run along the elements of Article 17(1), the requirements of EN 18286 and the further AI Act obligations applicable to the given system. In our experience, the following areas in particular are worth checking separately:

• System-specific compliance evidence. Alongside organisation-level QMS policies, it has to be determined what documentation and evidence supports the fulfilment of the applicable requirements for each high-risk AI system.
• Change management for continuously learning systems. Pre-determined changes taken into account at the time of conformity assessment, and later modifications, have to be handled in a way that makes it possible to establish whether a new conformity assessment or a documentation update is needed.
• Incident reporting deadlines. Article 73 sets specific statutory deadlines, so the organisation needs a working and tested escalation process, not merely a general incident policy.
• AI-specific supplier controls. Information and control needs relating to model, data and component suppliers have to be determined on the basis of the given supply chain, contractual roles and risks.
• Fundamental rights aspects – where applicable. The FRIA under Article 27 is not a general obligation for every provider or deployer; it applies to certain deployers of specified high-risk systems. Where relevant, it is worth aligning it with the DPIA under the GDPR.

EN 18286 also addresses topics that are less usual in classic QMS practice, such as fundamental rights aspects relating to interested or affected persons, and environmental sustainability. These should not be presented as if they were standalone AI Act obligations of identical content for every organisation; applicability has to be judged on the basis of the standard and the specific statutory role.

Output: a prioritised gap list, each item with an owner, an estimated effort and a deadline. You only have to count back from 2 December 2027 for high-risk systems under Annex III; for systems under Annex I the main deadline is 2 August 2028.

Step 5 – Documentation, monitoring and evidence

Goal: so that compliance is not a claim but something you can demonstrate.

This is the phase in which compliance becomes verifiable. In a regulatory or customer due diligence review, a policy or a general statement is not enough: up-to-date, retrievable and consistent evidence has to be linked to the applicable requirements.

A typical evidence base – depending on applicability to the given system and role – may consist of the following, for example:

• Technical documentation per system (Article 11 + Annex IV), under version control
• Test and validation records, with the date of the run and the responsible person
• Data lineage and data handling evidence: where Article 10 applies, the origin, preparation, relevant quality characteristics and handling of the data have to be documented, among other things; the precise content depends on the nature of the system and the data use.
• Automatic logging (Article 12) – and the retention regime for the logs
• Post-market monitoring plan (Article 72) and the associated measurement data
• Incident register and a documented trail of the reports (Article 73)
• A change log for every material model or data change
• Training records (Article 4, AI literacy)
• Supplier agreements and AI-specific information-sharing or control clauses, where the supply chain and contractual roles justify them
• Management review minutes in which AI compliance is an agenda item

Monitoring is not a task for after project closure. Provider post-market monitoring is an obligation under Article 72 of the AI Act, and management review is part of operating the QMS. These are best introduced so that evidence of actual operation and review is already being generated before the deadline.

Output: a working evidence base with defined owners and review cycles – not a folder of documents, but a maintained system.

A realistic schedule

For a medium-sized organisation with several high-risk systems, readiness can easily be a multi-month, complex programme. The figure of 12–18 months can be used as an experience-based project estimate at best; the actual time needed is determined by the number and maturity of the systems, the existing QMS and the severity of the gaps.

The deadline of 2 December 2027 applies to high-risk systems under Annex III. For those, the start really is now; for high-risk systems under Annex I the main application date is 2 August 2028. A working ISO system can be an advantage, but only after an actual assessment of the reusable controls.

Let's start with step 1 – together

The Harveys team runs these five steps as a turnkey methodology. Where we can add the most value:

• AI inventory and role clarification – mapping the full system estate and drawing the provider/deployer line under Article 25. This is the step where most organisations find unpleasant surprises – better now than during an audit.
• Reuse and gap analysis – we show what can be carried over unchanged from your existing ISO 9001 / ISO 42001 / ISO 27001 / GDPR apparatus, what needs a scope extension, and where genuinely new work arises. With a prioritised gap list and a schedule.
• Building the evidence base.

If you haven't read them yet, it is worth starting with the earlier parts of the series: EN 18286:2026 – the standard itself, and ISO/IEC 42001 and EN 18286 – the relationship between the two standards.

Let's start preparing – together

The Harveys team specialises in AI Act compliance readiness, advisory services and ongoing professional support.

Request a short AI Act compliance assessment. We look at how the EU AI Act affects your organisation, which systems need a more detailed review, and where it is worth starting with a gap analysis.

AI Act compliance assessment →

---

This article is for information purposes only and does not constitute legal advice. Determining specific compliance obligations requires an individual assessment of the system and the organisation, and where appropriate the involvement of legal counsel.