EN 18286 clause 8 and clauses 9.1–9.5: lifecycle and operations

This page walks the per-AI-system layer of EN 18286:2026: clause 8 (AI system realization) and clauses 9.1 to 9.5 (the operational duties short of incidents). In Modulos these clauses are carried by the MFF-19 template's 11 Requirements, one application project per AI system in the QMS scope. The organization layer is on The QMS clauses; serious incidents and non-compliance (9.6–9.7) have their own page.

The Requirements on this page

Requirement	Clauses	Owns
MRF-380	8.1	Life cycle stages and realization processes
MRF-381	8.2	The AI system risk management system
MRF-382	8.3	Inception, design and development
MRF-383	8.4	Verification and validation
MRF-384	8.5	Data management
MRF-449	8.6	Retirement
MRF-448	8.7, 9.1	Identification and traceability
MRF-385	8.8, 9.2, 9.4	Continuous learning, support services, modifications
MRF-388	8.9	Product documentation
MRF-386	9.3	Supply chain
MRF-387	9.5	Post-market monitoring

Clause 8 — AI system realization

8.1 Processes along the life cycle (MRF-380). Realization runs on defined processes. Every life cycle stage an AI system passes through needs a documented, maintained process built so that both the regulatory requirements and the AI system requirements stay satisfied: inception, design and development, verification and validation, operation and monitoring, modifications, retirement, and the supporting actions (data management, documentation, identification, supply chain, post-market monitoring, incident reporting, non-compliance handling). For each process the clause requires decided criteria, a defined sequence and interaction with the others, monitoring of whether it delivers with correction when it does not, and enough retained documentation to show it ran as planned. The stages are not required to run in strict order.

8.2 Risk management system (MRF-381). What clause 8.2 demands is an outcome: each AI system runs under a documented risk management system that covers its whole life cycle, is built to the applicable regulatory requirements, and serves a high protection bar for health, safety and fundamental rights. The clause obliges that system to exist; for the risk management process itself it points to prEN 18228, so the process depth is that standard's subject. On the Annex ZA side this clause carries the Article 17(1)(g) row, subject to the risk management system complying with Article 9.

8.3 Inception, design and development (MRF-382). The chain starts with the intended purpose, fixed at inception. From there the provider turns the applicable regulatory requirements, essential requirements included, into AI system requirements it can actually test: complete, unambiguous, open to verification and validation. Those requirements pass a systematic review-and-approval gate before any specification is written, and further reviews as design, development and testing proceed. Specifications then describe the implementation, must themselves be verifiable, and live in the technical documentation; design and development controls (reviews, verification, validation) check the specifications against the requirements, with problems acted on and records kept. Consulting affected persons or their representatives about risks to health, safety and fundamental rights is a recommendation, steered by the risk assessment. The requirements-review machinery is owned by the overlay Control MCF-622.

8.4 Verification and validation (MRF-383). Two questions, two activities: verification (testing included) asks whether the implemented system matches its specifications; validation asks whether it can do its intended job. Validation runs during and after development, with the instructions for use and technical documentation in view, and has to be finished before the system reaches the market or service. Neither activity is ad hoc: both need documented plans and procedures stating the methods and the acceptance measures (numerical limits, ranges, or other verifiable criteria), aligned with best practice for the technology and written to be reproducible. Reproducibility comes from recording the applicable test conditions: hardware and compute environment, software frameworks and library versions, random seeds and initialization, training parameters and hyperparameters, dataset versions and preprocessing, and the handling of stochastic elements. Where a system is inherently stochastic, documented statistical bounds on run-to-run variation can stand in for exact replication. Validation frequency is the provider's call, and the validation results feed a residual-risk evaluation.

8.5 Data management (MRF-384). A strategy for meeting the regulatory requirements that apply to data management, plus defined, documented and implemented data-management processes for design, development, verification and validation, proportionate to the risk of the AI system: documented data requirements, and systems and procedures for acquisition, mining and collection, analysis, labeling, filtration, aggregation, retention and storage. Data here spans training, validation, testing, logging and input data as applicable. For data decommissioning the provider specifies, as applicable, a mechanism for destroying or archiving the data in line with regulatory requirements; destruction must not undercut the provider's ability to stay compliant, which is why the retirement-stage data Controls (MCF-84, MCF-85) carry the destroyed-or-archived disjunction.

8.6 Retirement (MRF-449). Retirement is a life cycle stage of its own. Planning the provider-side retirement work (risk-control measures out of the risk management system, data-management measures) is recommended; the notice is what is mandatory: every deployer must be told which measures fall to it when the system is retired. Clause 8.6 is not listed in Annex ZA, so no presumption row attaches; the deployer-notice duty is owned by the overlay Control MCF-669.

8.7 Identification (MRF-448). Every AI system, and every version of it that goes through a conformity assessment procedure, needs a stable reference of its own. That reference is the join key: it ties the system to its instructions for use, its technical documentation and the other relevant information, datasets included. Together with clause 9.1 below, it is what keeps the assessed version connected to the versions deployers actually run once non-substantial modifications accumulate.

8.8 Continuous learning (MRF-385). For an AI system that keeps learning after being placed on the market or put into service, the pre-determined changes arising from the learning are determined and documented during design and development, stay compliant with regulatory requirements, carry through every applicable life cycle phase and the risk management, and are verified and validated per change; all changes are logged. The technical documentation describes how the system learns, the pre-determined changes and their effects including on performance, and the data used; the instructions for use explain the learning behavior, its effects, and what deployers must consider in deployment, operation and maintenance. Learning outside the documented envelope is a modification for clause 9.4. Owned by the overlay Control MCF-668.

8.9 Product documentation (MRF-388). Each AI system needs a technical file deep enough for notified bodies and competent authorities to see what the system is, what it is made of, how it was developed, and whether it complies. The file exists before the system is placed on the market or put into service, and it gets revised whenever a modification touches the applicable regulatory requirements. The instructions for use get their own systems and procedures for creation and maintenance; their content and format the standard defers to prEN 18229-2. Clause 8.9.2 is the sole clause behind the Article 11(1) presumption row, on the condition that the documentation contains all Annex IV elements.

Clauses 9.1–9.5 — Operations

9.1 Placing on the market and putting into service (MRF-448). At the point of supply the duty shifts from versions to units: each AI system placed on the market or put into service carries its own identification (a serial number is the clause's example) so that record-keeping, post-market monitoring and the other regulatory duties can be traced back to the individual system through the distribution chain. Distinct from the 8.7 reference: 8.7 names the conformity-assessed version, 9.1 follows the systems actually supplied.

9.2 Support services (MRF-385). A recommendation: identify, specify and provide support services, considering the applicable regulatory requirements, the entities needing support, expected problem types and responses, support channels, diagnostic tooling, and a mechanism ensuring all deployers can communicate feedback on potential risks to health, safety and fundamental rights.

9.3 Supply chain (MRF-386). Supply-chain control measures so that externally supplied products, components, model training, test data and services fulfill the requirements the AI system needs to stay compliant: documented criteria for evaluating and selecting suppliers, proportionate to the AI system's risk; planned and documented monitoring and re-evaluation of continuing suppliers, with criteria, frequency and methods; communication to suppliers, as applicable and proportionate to their role, of the specifications needed to meet the QMS requirements; and a defined, documented extent of control over both the supplier and the supplied items, including the verification, validation and acceptance activities applied to them. Externally supplied design and development, data annotation, evaluations and testing are the clause's own examples. The supplier lifecycle is owned by the overlay Control MCF-620; with clauses 7.1 and 7.2 this clause completes the Article 17(1)(l) row.

9.4 Modifications (MRF-385). Changes to an AI system run through a controlled process at every life cycle stage, and the risk management system weighs their consequences. Once the system is on the market or in service, the process adds a classification step: is this modification substantial? The rationale is documented either way. A substantial one produces, in regulatory terms, a new AI system, meaning a fresh conformity assessment and a matching QMS update; whatever the classification, the technical documentation covers all versions. Owned, together with the version-reference scheme, by the overlay Control MCF-623.

9.5 Post-market monitoring (MRF-387). A plan-based post-market monitoring system, proportionate to the AI technologies and the system's risks, running from market placement or putting into service until retirement, enabling evaluation of continuous compliance with the essential requirements; the plan is part of the technical documentation. The monitoring approach is active and systematic, feeds performance evaluation, and considers the risks and risk-control measures, applicable regulatory requirements including data privacy, reliance on distributors, importers, deployers and third parties, intended purpose and reasonably foreseeable misuse, technical constraints, performance, and, where relevant, interaction with other AI systems. Information gathering is systematic: from deployers, users and other interested parties, from monitoring the system and its logs, from regulatory authorities, and from feedback and complaint mechanisms and serious incidents, with AI system logging implemented as appropriate. Procedures identify and act on new and emerging hazards surfaced by the monitoring. Where the provider cannot detect non-compliance without the deployer's involvement, and monitoring requirements are necessary to mitigate risk, those requirements go into the instructions for use, together with recommended monitoring tools where not integrated and the technical competency recommendations for monitoring. Handling of detected non-compliance is not part of this clause; it sits in clause 9.7 at organization level.

How the lifecycle layer maps in Modulos

Attach MFF-19 to one application project per AI system. The 11 Requirements resolve to 46 distinct Controls: the reused EU AI Act lifecycle, testing, data, documentation, monitoring and retirement families, plus the five application overlays MCF-620, MCF-622, MCF-623, MCF-668 and MCF-669. The operationalizing playbook has the full overlay table and the rollout sequence.

Related pages

EN 18286 overview

Status, structure, and how Modulos models the standard

The QMS clauses

The organization layer (clauses 4–7 and 10) on the OFF-19 side

Incidents and non-compliance

Clauses 9.6 and 9.7: deadlines, remedial menu, notifications

Annex ZA and presumption

Which rows these clauses carry

Source attribution

EN 18286:2026, Artificial intelligence — Quality management system for EU AI Act regulatory purposes, clause 8 and clauses 9.1 to 9.5, restated in the documentation's own words with the Modulos template mapping as of templates 1.0.26. For conformity-assessment purposes, verify against the published standard.

Disclaimer

This page is for general informational purposes and does not constitute legal advice.