What the Article 17 quality management system asks providers to build
A provider placing a high-risk AI system on the EU market needs a written quality management system that governs how the system is designed, built, tested, released and watched after launch. Article 17 requires that system to exist as documented policies, procedures and instructions covering at least 13 aspects, from the compliance strategy and design control to testing and validation, data management, risk management, post-market monitoring, incident reporting, record-keeping, resources and an accountability framework. The risk it addresses is familiar to any engineering organization: development decisions made in different ways by different teams, test results that cannot be traced to a released version, and production problems that never reach the people who can fix the model or its documentation. The first task is to decide who owns each aspect and where each document will live, so that every later obligation can point to a single controlled source.
Several of the 13 aspects are not new to a mature organization. Change control, testing, supplier management and incident handling often already exist for software. What is new is the AI-specific layer: data governance for training and validation sets, documented design choices, accuracy and robustness testing, and monitoring of real-world performance. The reader should check which existing procedures can be extended and which must be written from scratch, and confirm with the organization's own legal or compliance team how Article 17 interacts with any sectoral quality system already in force. Proportionality also matters here. Article 17 as amended in 2026 scales implementation to the provider's size, so the depth of each procedure should match the organization's resources, while the rigor needed for compliance stays the same.
The harder part is operation. A quality management system that exists only as a binder does not satisfy the regulation, because an assessor will look for records showing that the procedures were followed for this system, on these dates, by these people. Each procedure must produce evidence that feeds the technical file, the logs, the post-market monitoring plan and the incident process described elsewhere in Chapter III. Teams should plan for that linkage from the start, agree which system holds the authoritative version of each document, and test the workflow on one real release before committing to the full set. Work with an assessor or the organization's own counsel to confirm how the QMS will be evidenced for the conformity route that applies.
Which providers must build an Article 17 quality management system
Article 17 applies to every provider of a high-risk AI system, whether the system falls under Annex III or Annex I and wherever the provider is established. Four scoping decisions determine how much work the quality management system requires and when it must be ready.
Non-EU providers whose output reaches the EU
Article 2 reaches providers established outside the EU when their AI output is used in the EU, so a US or Asian vendor can owe a full Article 17 system even with no EU office. Confirm with counsel where the output is used, not only where the company sells. A non-EU provider of a high-risk system must also appoint an EU authorised representative under Article 22, and that representative will expect to see the QMS documents on request. Map your EU customers and their use cases before deciding whether the Act applies.
Annex III or Annex I system
The route to high-risk status changes the timeline. Annex III systems, such as those used in employment, credit or education, must meet the high-risk rules from 2 December 2027. Annex I systems, which are AI components of regulated products, follow from 2 August 2028. Confirm which annex your system falls under before you plan the QMS, because product providers may need to fold Article 17 into existing product conformity work.
Notified body or internal control route
Under Annex VI the provider verifies its QMS internally. Under Annex VII a notified body assesses the QMS against Article 17 and keeps it under surveillance, which adds an external engagement, documentation review and audit cycle. Ask any notified body early about its queue and scope, and confirm whether your system falls under the biometric or Annex I routes that require one. The route you choose sets how much evidence the QMS must make available to an outside assessor.
SME, start-up and small mid-cap status
Article 17(2) requires implementation proportionate to size, with particular attention to SMEs, start-ups and small mid-cap enterprises, while keeping the rigor the compliance goal requires. Amended Article 63(1) lets SMEs without partner or linked enterprises meet certain QMS elements in a simplified manner under Commission guidelines. Confirm your headcount and ownership structure, including linked enterprises, because those facts decide whether the simplified route is open to you.
Existing sectoral QMS obligations
Article 17(3) lets a provider that already runs a quality management system under sectoral rules include the Article 17 aspects in that system instead of building a parallel one. Map the aspects your current ISO-based or product-regulation system already covers, then list the gaps, such as AI-specific data governance or post-market monitoring. Confirm with your sector regulator whether the existing system is accepted for this purpose.
Financial institution treatment
Article 17(4) treats financial institutions as compliant with Article 17 through their internal governance rules under Union financial services law, except for risk management, post-market monitoring and incident reporting. Those three aspects still need separate AI-specific documentation. Banks and insurers should confirm with their supervisor how internal governance records will be presented, and should avoid assuming that existing governance covers the three excluded aspects.
How to build the Article 17 quality management system in sequence
This sequence takes a provider from an inventory of its high-risk AI systems to a quality management system it can show an assessor, with each step closing on a named artifact so gaps are visible before the assessment starts.
Scope the AI systems and organizations covered
Start by listing every AI system the organization places on the EU market or puts into service under its own name, and mark which ones are high-risk under Annex III or Annex I. Record which legal entities, product lines and sites fall inside the QMS boundary, and whether any system is built on a general-purpose model the organization does not control. The owner is usually the head of AI or product compliance, with legal confirming the classification. The step is done when the team holds a scoped system register that names each high-risk system, its legal entity and the sectoral QMS rules that already apply to it.
Map existing processes to the 13 aspects
Take the 13 aspects that Article 17(1) requires and match each one against processes the organization already runs, such as secure development, change management, data governance, risk management, incident handling and record-keeping. Many organizations already hold procedures for some aspects through ISO/IEC 27001, ISO/IEC 42001 or a sectoral system, and those can be referenced rather than duplicated. The output is a crosswalk sheet that shows, for each aspect, the existing procedure, its owner and the gap where nothing exists yet. Confirm the mapping with the assessor or notified body where a sectoral system is relied on under Article 17(3).
Write the policies, procedures and instructions
Draft the written policies, procedures and work instructions that close the gaps in the crosswalk, starting with the compliance strategy and the accountability framework because the others depend on them. Keep each document short, state its purpose and scope, and link it to the aspect it serves. Procedures should describe what people do, not restate the regulation. Store the drafts in a controlled wiki or document system with approval records. The step is done when every aspect in the crosswalk points to an approved document and the gap register is empty or each open item has a dated owner.
Assign accountability and resources
Name an accountable owner for each aspect and each high-risk system, and record the people, budget and tools allocated to the QMS. Article 17 expects an accountability framework, so the RACI should show who approves releases, who signs off risk decisions, and who can stop a system from going live. Confirm the resources needed for testing, monitoring and record-keeping, and document who holds the authority to pause a non-conforming system. The output is a signed RACI and a resource statement that leadership has approved.
Set up change control and record-keeping
Put every change to a high-risk system through a controlled process that captures what changed, why, the risk review, the test results and the approver. Use a ticketing or change management tool that keeps history, and a document system that retains prior versions so an assessor can see what the QMS looked like at any date. Set retention rules that align with the record-keeping duties covered elsewhere in the Act. The step is done when a sample change can be traced from request to approval to deployment with no missing records.
Run testing and validation gates
Define the testing and validation gates a system must pass before release, covering functional, performance, bias, robustness and security checks against the requirements the system must meet. Record the acceptance criteria, the test data used, the results and the person who accepted residual risk. Gates should block release when criteria fail, and the QMS should state who can override them and how the override is documented. The output is a gate checklist per system and a set of test reports linked to the change records from the previous step.
Connect post-market monitoring and incident reporting
Link the QMS to the processes that watch the system after release, including how performance data is collected, how complaints and anomalies are triaged, and how serious incidents are escalated to the people who must report them. Define thresholds that trigger a review, the owner for each trigger, and how findings feed back into risk management and change control. The step is done when a simulated anomaly can be followed through triage, escalation and a documented corrective change, with each handoff recorded.
Run an internal review before the assessment
Before the independent assessment, run an internal audit of the QMS against the documented aspects, sampling real records for each system. Record findings in a register with severity, owner and due date, and close them or formally accept the residual risk. Management should review the results and confirm the QMS is operating as written. For providers using internal control under Annex VI, this review is the provider's own verification; for notified body routes, it prepares the evidence the body will examine. The output is an internal audit report and a closed or accepted findings register.
How an assessor tests the Article 17 quality management system
This table compares how an assessor tests each part of the Article 17 quality management system, what evidence they request and where systems usually fail. Read it by row to see the test method, then check who runs the test under Annex VI (internal verification by the provider) or Annex VII (notified body assessment and surveillance).
| Test area | What the assessor does | Evidence requested and common findings |
|---|---|---|
| Documented policies for the 13 aspects | Document review of written policies, procedures and instructions against each of the 13 aspects in Article 17(1). Under Annex VI the provider's own verification team performs this; under Annex VII the notified body does. | Evidence: a mapping from each aspect to a controlled document with an owner and version. Common finding: aspects such as data management or post-market monitoring covered only by a general policy with no procedure behind it. |
| Operation over time | Sample of records across the review period to confirm the system runs as written, not only as drafted. Notified body performs this during surveillance audits. | Evidence: dated review minutes, risk register updates, testing logs, incident and change records. Common finding: policies approved once and never revisited after a model change. |
| Accountability named to individuals | Interview with the accountable managers to confirm named roles, decision rights and escalation paths for each QMS aspect. | Evidence: role descriptions, a responsibility matrix and signed approvals. Common finding: responsibility assigned to a team or mailbox, with no individual who can explain the decisions. |
| Design and development control walkthrough | Live walkthrough of a recent change to a high-risk system, from request through testing, approval and release, to see the QMS controls applied. | Evidence: a complete change record linking the requirement, test results, sign-off and release. Common finding: changes released through a route that skips the documented approval step. |
| Link to the technical file | Cross-check that QMS procedures point to the technical documentation and that the documents agree on versions, data sources and test results. | Evidence: a traceability index between QMS records and the technical file. Common finding: technical file describing a model version that the QMS no longer reflects. |
| Proportionality decisions for SMEs | Review the written reasoning for how the provider applied Article 17(2) and any simplified route under Article 63(1), and check the rigor retained. | Evidence: a dated proportionality rationale approved by management, with the controls kept at full rigor. Common finding: simplification recorded without reasons or applied to risk management and incident reporting. |
| Sectoral and financial-sector integration | Check whether aspects covered by an existing sectoral or financial governance system under Article 17(3) or (4) are mapped and actually operated. | Evidence: a mapping showing which sectoral procedure covers which aspect, and where gaps remain. Common finding: assumed coverage with no written mapping of risk management or incident reporting. |
| Standards applied | Confirm which standards the provider relies on, including EN 18286:2026 where used, and that the claim matches the controls in place. | Evidence: a standards register with the version used and the gap analysis for any clause not met. Common finding: a standard cited in the documentation that the operating procedures do not follow. |
Integrating the QMS with sectoral and financial-sector systems
Article 17(3) allows a provider that already has quality management obligations under other Union sectoral rules to include the Article 17 aspects inside those existing systems instead of running a second, parallel QMS. The reuse is about coverage, not shortcuts: the existing system must actually address each aspect the AI Act requires, including design control, testing, data management, post-market monitoring and incident reporting, and the evidence must be traceable to the AI system.
- Gap mapping: Map each of the 13 Article 17(1) aspects against the sectoral procedures to find which ones already exist and which are missing or only partly covered.
- AI-specific procedures: Add AI-specific steps where the sectoral system is silent, such as training data governance and model performance monitoring.
- Single document set: Keep one set of controlled procedures and records so auditors can trace an AI requirement to the owning process without reading two systems.
- Ownership and sign-off: Name who approves changes to AI-related procedures, since the sectoral owner and the AI compliance owner may differ.
- Version control: Track which procedure version applied when each AI system was placed on the market.
Before relying on this route, confirm with your sector regulator and the relevant Commission guidance exactly which sectoral QMS obligations qualify and how they are assessed.
Article 17(4) treats financial institutions as meeting the QMS requirement through their internal governance arrangements, rules and procedures under Union financial services law. The deeming is partial. It does not cover risk management, post-market monitoring and incident reporting, which must still be addressed as AI Act obligations, so those three areas need dedicated, documented procedures even when the wider governance framework is reused.
- Governance reuse: Document how existing internal governance covers the other ten or eleven aspects, with references to the policies that hold them.
- Three carve-outs: Build separate AI risk management, post-market monitoring and incident reporting procedures that meet Article 17 directly.
- Operational risk linkage: Connect AI risk assessments to existing operational risk and model risk processes, recording where they differ.
- Incident routing: Map AI incident handling to existing incident reporting channels so the AI Act timelines can be met.
- Supervisory alignment: Keep records that show how the financial supervisor's expectations are reflected in the AI controls.
Confirm with your prudential or conduct supervisor, and with the Commission guidance, how the deeming applies to your institution and which internal rules count as qualifying governance.
Article 17(2) requires the QMS to be proportionate to the provider's size, in particular for SMEs, start-ups and small mid-cap enterprises, without lowering the rigor needed for compliance. Amended Article 63(1) goes further for SMEs without partner or linked enterprises, allowing certain QMS elements to be met in a simplified manner under guidelines the Commission is to issue. Illustrative example: a small vendor with a few developers may document one controlled procedure per aspect rather than a large suite, provided each aspect is still covered and traceable.
- Eligibility check: Confirm whether you have partner or linked enterprises, since that determines access to the simplified route.
- Lean document set: Combine related aspects into fewer, well-controlled procedures without dropping any of the 13.
- Reuse of tooling: Use a self-hosted wiki with version history and a ticketing system to hold procedures and change records at low cost.
- Scaled testing and monitoring: Size validation and post-market monitoring to the system's risk and user base.
- Harmonised standard path: Consider EN 18286:2026 as a structured route to demonstrate conformity with Article 17.
Confirm the eligibility conditions and the simplified elements in the Commission guidelines, since the detail is not yet fixed in this page's sources.
Evidence that shows a working quality management system
An assessor looks for a QMS that is operating, not one written for the audit. The cards below cover the documents and records that show Article 17 is applied day to day, and each one names how to keep it current between formal reviews. The common thread is that every record should trace back to a dated review, a linked change ticket or a named owner.
QMS manual and policy set
The manual is the top-level description of your compliance strategy, accountability framework and the scope of the QMS across the AI systems you provide. Map each of the 13 aspects in Article 17(1) to a named policy or procedure so an assessor can trace a requirement to its owner. Keep a document control register with an owner, approver and next review date for every policy, and log each approved revision. The review date on every policy is the item assessors check first, because stale policies signal that the QMS is not maintained.
Procedure and instruction library
Procedures and work instructions show how staff carry out design, testing, data handling and incident steps, and each must be versioned. Store them in a wiki or document system that records every change, who made it and when, and that lets you compare or roll back to earlier versions. Require a dated review cycle for each procedure, and tie any change to a ticket so the library reflects how work is actually done. Ask any vendor you evaluate to confirm how its version history and approval workflow export for an audit.
Design and development control records
These records show that each high-risk system was designed, changed and approved under the procedures you documented. Keep design reviews, approval sign-offs, and change requests that link requirements to the code, data and configuration that implement them. Each release should carry a record of who approved it, what was tested and which risks were reassessed. Review the change log at a fixed cadence so that any unapproved change is caught before the next assessment rather than during it.
Testing and validation reports
Testing reports show that the system performs as its documentation claims, under conditions that reflect the intended use. Record test plans, acceptance criteria, results, defects and the decision to release, and keep them for the lifetime of the system. Rerun validation after each material change and record the trigger, so the report history matches the release history. Confirm with your assessor which test evidence they expect for the specific Annex III or Annex I category you fall under.
Risk management and post-market monitoring records
Risk registers, risk assessments and monitoring reports show that you identify, reduce and watch risks across the system's life. Review the register on a scheduled cycle and whenever a new incident, complaint or performance drift is reported. Link each monitoring finding to a risk entry and to any corrective action it triggered. The dated risk review log shows the assessor that the register is alive, and it is the record most often found stale in readiness checks.
Incident and corrective action logs
Incident and corrective action logs record what went wrong, how it was investigated, what was changed and whether the change worked. Use a ticketing system with ITIL-style problem and change records so that each corrective action is linked to its root cause, the affected system version and the closure check. Track recurring issues and review open actions at a set interval. Incident handling also feeds the reporting duties in Article 73, so confirm with counsel which records must be retained for authority requests.
What EN 18286:2026 changes for proving Article 17 conformity
The Commission cited EN 18286:2026 as the first harmonised standard under the AI Act in Commission Implementing Decision (EU) 2026/2274, published on 14 October 2026. From that date, a provider that conforms to the standard benefits from a presumption of conformity with the quality management system requirements of Article 17. For a provider, this changes the question from "how do we interpret Article 17 ourselves?" to "can we show that our QMS follows a published, cited standard?" That is a practical shift for anyone building the QMS policies, procedures and instructions that Article 17 requires. CEN-CENELEC describes EN 18286 as a non-sector-specific QMS standard for organizations that provide AI systems, offering a clearer route to demonstrate conformity with Article 17. Because it is not tied to one sector, the same QMS can serve high-risk systems across HR, lending, healthcare or critical infrastructure, and it can sit alongside existing management systems such as ISO/IEC 27001 or ISO/IEC 42001. Confirm with the CEN-CENELEC announcement and the Official Journal how the standard's clauses map to the 13 aspects of Article 17 in your own QMS, and record that mapping as part of your technical file.
A presumption of conformity does not replace the provider's own evidence. It means that a QMS built to the cited standard is presumed to meet the matching Article 17 requirements, but the provider still has to show that the QMS is implemented, operated and maintained for each high-risk system it places on the market. Assessors will still ask for dated records of design reviews, test results, risk decisions, post-market monitoring outputs and incident handling. Plan the evidence trail before you rely on the standard, and check whether your conformity route under Annex VI or Annex VII changes what an assessor will request. Before you commit budget or redesign your QMS, confirm the standard's current status, its clauses and any amendments directly with CEN-CENELEC and the official EUR-Lex record for Implementing Decision (EU) 2026/2274. Buying the standard, reviewing its clauses against your current processes and deciding which procedures need rewriting are one-time costs; keeping the QMS current and producing records each release cycle are recurring. Ask any implementation partner or consultant to show how they will map the standard's clauses to your existing evidence before they quote.
Open-source tools that hold Article 17 QMS records
Article 17 expects written policies, procedures and instructions, plus records that show they are followed. The four tools below can hold that evidence: assessment tracking, versioned documents, controlled ownership and change or corrective action tickets. None of them writes the QMS for you, and each needs to be checked against your own environment before you rely on it.
Assessment tracking with CISO Assistant
CISO Assistant (AGPL-3.0-only) ships more than 200 frameworks and can run audits and compliance assessments against them, with automatic mapping between frameworks. For Article 17, it can track the status of each QMS aspect, the evidence attached to it and the assessment work done against it. Confirm that the framework content and mapping cover the AI Act and EN 18286 aspects you need, because a shipped framework library does not mean an AI Act library is included. Check how it exports evidence for an assessor.
Versioned policy library in XWiki
XWiki (LGPL-2.1-or-later) keeps every page change under version control, recording what changed, when and by whom. You can compare any two versions and roll back to an earlier one. That history is the kind of evidence an assessor uses to confirm that a policy or procedure was in force on a given date. Confirm that the retention and access settings on your instance meet your own record-keeping rules before you treat it as the system of record.
Document ownership in BookStack
BookStack (MIT) assigns abilities through roles and lets you override permissions per shelf, book, chapter or page. That allows a named owner to control each QMS document while others read it. Map each document to an accountable role in your QMS and test that a reader cannot edit a controlled procedure. Permissions alone do not prove approval, so keep the approval record in your own process.
Change and corrective action tickets in GLPI
The GLPI Assistance module (GPL-3.0-or-later) handles tickets, problems and changes following ITIL practices, with plannings, statistics, recurrent tickets and a Kanban view. For Article 17, it can hold change control records for the system and corrective action records raised from incidents or monitoring findings. Confirm that the workflow, approval steps and retention fit your change control process, and that the ticket history can be exported when an assessor asks for it.
What meeting Article 17 costs in money and effort
This table compares the main cost components of building and keeping an Article 17 quality management system, who is paid for each, and what moves it up or down. Read it as a list of items to price separately in any written quote, since no amounts are supplied for this page. The main takeaway is that most of the cost is recurring effort to keep the 13 aspects current, not the one-time drafting.
| Cost component | One-time or recurring | What drives it up | How to keep it down |
|---|---|---|---|
| Tooling and licenses | Recurring for hosting and administration; the supplied open-source tools carry no license fee to the user | Number of systems to host, high-availability needs, integration work with existing ticketing and document tools, and staff time to administer them | Reuse tools already run in-house, confirm license terms for each tool with its publisher, and size hosting to the QMS scope only |
| Engineering and compliance time to write the 13 aspects | One-time for the initial set of policies, procedures and instructions, then recurring for revisions | Number of AI systems in scope, depth of design and data governance procedures, and how many teams must contribute | Start from one shared template covering all 13 aspects and reuse it across systems, and assign named owners per aspect |
| Evidence upkeep | Recurring | Frequency of model changes, volume of test and monitoring records, and manual collection of records across tools | Store records in version-controlled systems with clear retention rules, and collect evidence as part of routine change and incident work |
| Proportionality review for SMEs and small mid-caps | One-time, then recurring when size or status changes | Partner or linked enterprise relationships that affect eligibility for the simplified route under Article 63(1) | Document the size and group status basis in writing and confirm it against the Commission guidelines before relying on the simplified route |
| External review or gap assessment | One-time or periodic, optional | Breadth of scope, number of systems, and whether the review tests the QMS or only the documents | Ask for a fixed-scope review against the 13 aspects with a written list of deliverables |
| Notified body fees where Annex VII applies | Recurring surveillance after initial assessment, plus initial assessment | Scope of the QMS, number of systems covered, and the notified body's assessment and surveillance schedule | Confirm which systems fall under Annex VII before engaging a body, and ask each body for its fee basis in writing |
| Auditor or assessor time | Recurring at each assessment or surveillance cycle | Size of the documentation set, quality of traceable records, and number of open findings from prior cycles | Keep the QMS records indexed and current so each assessment starts from a complete evidence set |
Who does what for the Article 17 quality management system
The provider remains legally responsible for its quality management system. Article 17 requires written policies, procedures and instructions, and the provider owns them. Accountability cannot be transferred to a consultant, a tool vendor or an assessor, so the decisions that define how the system works must be made and signed by people inside the organization. Outsourcing can help with build work, but the business still has to decide what the policies say and whether the organization actually follows them.
- Policy ownership: Approve the compliance strategy, the accountability framework and the scope of the QMS, and assign named owners for each of the 13 aspects.
- Design and risk decisions: Set risk acceptance criteria, approve design and development choices, and decide which standards the organization applies.
- Records and operation: Run post-market monitoring, incident handling, change decisions and management reviews, and keep the resulting records current.
- Resources: Fund staff, tooling and training, and confirm that people with the right authority can stop a release.
- Sign-off: Decide when the system is ready for assessment and who answers auditor questions.
Ask any partner to show which of these items it prepared and which the provider approved, and confirm that the provider can explain each policy without help.
An implementation partner such as DeployOpen prepares the systems, tooling, documentation structure and evidence that the provider's QMS depends on. Its work typically sits alongside the provider's team and is scoped in writing before work starts. The partner does not decide the provider's policies, does not sign the provider's declarations and does not issue reports or certificates. Only an independent auditor or notified body can do that.
- Documentation structure: Set up the document hierarchy, templates and version control so policies, procedures and instructions can be found and traced.
- Tooling and integration: Configure self-hosted platforms for ticketing, change records, compliance mapping and wiki content, and connect them to existing sectoral processes where Article 17(3) applies.
- Evidence capture: Design how logs, approvals and test results are collected, retained and linked to the requirements they support.
- Internal review: Run a pre-assessment review that tests whether the documents match how work is actually done.
- Handover: Document the configuration and train the provider's staff to operate and maintain it after the engagement ends.
Confirm the partner's written scope, its deliverables and who owns the final documents before work begins.
Where Annex VII applies, a notified body assesses the QMS against Article 17 and keeps it under surveillance. Under Annex VI, the provider verifies its own system internally, and an independent party may still be engaged to test it. In either case, the assessor tests the evidence and reaches its own conclusion. Its independence is the reason it can be trusted, so it cannot design the system it will later assess without losing that independence.
- Testing and sampling: Review policies against practice, sample records, and interview staff about how decisions are made.
- Findings and certificates: Record findings, decide on conformity and, where applicable, issue the certificate or assessment outcome.
- Surveillance: Carry out ongoing checks where a notified body keeps the QMS under surveillance.
- Independence limits: Decline to write the policies it will assess, and avoid advice that would make the assessed system its own design.
- Scope of help: Answer clarifying questions about the requirements, but leave the system design and documents to the provider and its partner.
Before engaging an assessor, ask how it separates advisory work from assessment, and whether any consultant it recommends is also working on the same system.
Questions buyers ask about the Article 17 quality management system
How much effort does an Article 17 quality management system take?
The effort depends mainly on how many high-risk systems the provider runs, which sector they serve, and what management systems already exist. A provider with one Annex III system and a certified ISO/IEC 27001 or sectoral quality system usually starts from documents it already has, and the work is mapping them to the 13 aspects in Article 17(1). A provider with several systems, no written quality policies, or a regulated sector with its own QMS obligations needs more work on design control, data management and post-market monitoring. Ask any consultant to break the estimate into inventory, gap analysis, documentation, testing evidence and internal review, and to state which of those steps assume existing controls.
Can an SME build an AI Act quality management system in-house?
Yes, an SME can build the system in-house if it has staff who understand the high-risk system and the time to write and maintain the procedures. Article 17(2) requires implementation proportionate to the provider's size, with particular attention to SMEs, start-ups and small mid-cap enterprises, while keeping the rigor the compliance needs. Amended Article 63(1) also lets SMEs without partner or linked enterprises meet certain QMS elements in a simplified manner under Commission guidelines. Check whether your organization meets that partner and linked enterprise test before you rely on the simplification, and confirm the current guidelines with your national authority or the Commission.
How long before the December 2027 and August 2028 deadlines should a provider start?
Start now, because the dates in the Act set the deadline for having the system ready, not the date you begin work. Under the 2026 amendment, the high-risk rules in Chapter III Sections 1 to 3 apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I product systems. Work backwards from those dates: inventory and gap analysis first, then QMS documentation, then testing and evidence collection, then an internal or notified body assessment where it applies. The length of each step depends on the system count and existing controls, so ask for a schedule with dated milestones in the written scope rather than relying on a general estimate.
Does EN 18286:2026 mean a provider is certified under the AI Act?
No. EN 18286:2026 is a harmonised standard, and it does not create a certificate that proves compliance. Commission Implementing Decision (EU) 2026/2274 cited it in the Official Journal on 14 October 2026, which gives a presumption of conformity with Article 17 for a provider that applies it. The provider still has to produce its own evidence, such as written procedures, records and test results, and an assessor still has to review that evidence where the route requires it. Only an independent body issues a certificate where one applies. Read the CEN-CENELEC explanation of EN 18286 before you decide how to structure your evidence.
What does the work need from our engineering, legal and product teams?
The QMS needs named owners in engineering, product, legal, data and security, because Article 17 covers design and development control, data management, testing, risk management and incident handling, and each area produces evidence. Engineering provides test results, model and data change records, and monitoring data. Legal and compliance decide the regulatory strategy, the accountability framework and how the QMS fits with GDPR and sectoral rules. Product and operations keep the instructions, release approvals and incident records current. Plan for these people to spend recurring time after launch, since the QMS must cover post-market monitoring and corrective action, not only the first release.
Can an implementation partner run the QMS for us?
A partner can prepare the QMS, but the provider keeps ownership of its controls and the decisions behind them. DeployOpen plans, implements, documents and supports self-hosted open-source platforms in the client's own infrastructure, and it prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications, and any conformity assessment is carried out by an independent auditor or certification body where one applies. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask for the written scope to list which Article 17 aspects the partner will document and which the provider's staff will own.
Can our Article 17 QMS be reused for ISO/IEC 42001 or other frameworks?
Some overlap is likely, because an AI management system and an AI Act quality management system both cover governance, risk, documentation and continual improvement. However, the overlap is not a formal mapping supplied for this page, and the AI Act requirements are specific to Article 17. Ask your auditor or assessor to confirm which clauses and controls your existing documents satisfy, and record that confirmation in your evidence file. Keep a traceability table that links each Article 17 aspect to the policy, procedure and record that covers it, so that a reviewer can see the reuse decision and its limits.
How DeployOpen scopes and prepares Article 17 evidence
DeployOpen helps providers of high-risk AI systems build the documented quality management system that Article 17 expects, inside their own infrastructure. The organization keeps ownership of its QMS, and DeployOpen prepares the systems, records and written procedures that show how it operates.
How we scope
- Agree a written scope covering which high-risk AI systems and which Article 17 aspects the QMS must govern.
- Map the provider's size and any sectoral QMS obligations, so the proportionality and Article 17(3) and (4) routes are settled before work starts.
- Confirm which conformity route applies, internal control under Annex VI or notified body assessment under Annex VII, and who will assess the QMS.
How we build
- Set up the self-hosted document, version control and approval workflow that holds the QMS policies, procedures and instructions.
- Configure ticketing for change control, incident handling and corrective actions so records are created as work happens.
- Test the workflows with the organization's own staff and record the results for the technical file.
How we hand over
- Deliver the QMS documents, record templates and workflow configuration in the organization's own environment, with named owners for each aspect.
- Provide a cross-reference that links each of the 13 Article 17(1) aspects to the document, system and record that evidences it.
- Give the organization a written list of gaps and open decisions for its internal owners and its independent assessor.
How we support
- Offer ongoing support for upgrades, backups and changes to the QMS tooling as a retainer, if the organization wants it.
- Support internal audit preparation and respond to questions from the independent assessor about how the system was built.
- Confirm with the organization and its assessor what evidence they need before any review, since DeployOpen does not issue reports or certificates.
