Article 17 — Quality Management System
Article 17 requires providers of high-risk AI systems to establish a quality management system (QMS) that covers the full lifecycle of the system. The QMS must be proportionate to the size and nature of the provider’s organisation, but the minimum requirements are defined specifically in Article 17(1).
What the Article Requires
Article 17(1) lists the elements a QMS must address. The ones most directly relevant to production operation — and where VeriProof provides direct support — are:
| QMS element | Article 17(1) sub-paragraph | VeriProof support |
|---|---|---|
| Post-market monitoring | (h) | Session capture, governance scoring, trend reports |
| Record-keeping procedures | (i) | Immutable session records with blockchain proofs |
| Incident handling and corrective action | (j) | Alert rules, incident session export, corrective action log |
| Procedures for serious incident reporting | (k) | Evidence packages for regulatory reporting |
Post-Market Monitoring as a QMS Element
Article 17(1)(h) requires your QMS to include a procedure for collecting and analysing data from the system’s actual use in the market. This procedure must feed back into the risk management system (Article 9) and trigger corrective action when needed.
VeriProof is the technical implementation of this QMS element. The governance scoring configuration you establish defines what you’re monitoring; the alert rules define when you act; the evidence export defines how you document that the monitoring functioned as intended.
Record-Keeping
Article 17(1)(i) requires that your QMS includes procedures to ensure that records required by the Act are kept and are accurate.
VeriProof satisfies this requirement through:
- Immutable storage: Every session record is stored with a blockchain-anchored Merkle proof. Any alteration to the record after anchoring is detectable
- Verifiable export integrity: Evidence packages include blockchain proof material and export metadata that document when the package was generated and what records it covers
- Long-term retention: Configure retention periods up to 7 years to meet the Act’s expected documentation retention horizon (typically coextensive with the system’s operational lifetime)
Incident Handling and Corrective Action
Article 17(1)(j) requires that your QMS includes a procedure for handling non-conformities and taking corrective action.
Incident Detection
Alert rules are the incident detection mechanism in your QMS. Each alert rule corresponds to a risk threshold from your Article 9 risk analysis. Open Monitoring in the Customer Portal and click + New Rule (or use Quick Setup to start from a template). Configure the metric type (for example, governance score, guardrail pass rate, or a custom metadata field), set the threshold and time window, assign a severity, and add the email addresses of your QMS owner and risk team. Save the rule — it becomes active immediately.
Incident Investigation
When an alert fires, open the Monitoring → Trigger History tab in the Customer Portal. Click the trigger to see the affected sessions. From the session detail view, open Session Replay (Time Machine) to examine the full trace — the model, the inputs, the intermediate steps, and the outputs — in the exact state it was at ingest. Work through the lowest-scoring sessions first to identify the common pattern.
Corrective Action Documentation
Article 17(1)(j) requires that corrective actions be documented. Back in the Monitoring → Trigger History tab, click the trigger and use the Acknowledge button to record your initial response note. Once the corrective action is complete, click Resolve and enter the root cause, the action taken, and the date corrective action was completed.
The complete acknowledgement and resolution history is included in evidence package exports, giving auditors a documented log of every incident and its outcome.
Serious Incident Reporting (Article 99)
Article 17(1)(k) and Article 99 require providers to report serious incidents to market surveillance authorities. A serious incident is one that resulted in risk to health, safety, or fundamental rights, or constituted a breach of obligations under EU law.
When a serious incident occurs, generate an incident-specific evidence package:
Identify the affected sessions
Open Compliance → Privacy & Data Rights and use the date range filter to narrow sessions to the incident window. Alternatively, open Monitoring → Trigger History and filter by the alert rule that fired during the incident. Export the session list using the Evidence Exports tab in the Application Workspace for the affected app.
Generate the incident evidence package
In Compliance → Audit Engagements, create a new engagement scoped to the incident period, tag it as an Article 99 serious incident, and attach the session list. Then go to Compliance → Evidence Exports, choose the EU AI Act framework, select articles 9 and 17, set the date range to cover the incident window, and download the signed PDF. Attach the acknowledgement and resolution notes from Monitoring as a supplementary document.
Supplement with corrective action documentation
Add the corrective action taken and the root cause analysis to the package before submission to the relevant national authority.
Submit to the national competent authority
The authority, timeline, and format for Article 99 reporting varies by member state. Most member states use the European Commission’s coordinated reporting system. Consult your legal counsel for jurisdiction-specific requirements.
QMS Documentation Package
The Article 17 evidence package includes:
- Post-market monitoring summary for the period (session counts, governance score distribution)
- Alert trigger history with acknowledgement notes and corrective action records
- Complete incident report for any Article 99 events in the period
- Blockchain proof sample demonstrating record integrity
- Standing declaration that the QMS operated as configured throughout the period
Next Steps
- Article 9 — Risk Management — risk management system that feeds Article 17
- Evidence Packaging Walkthrough — step-by-step package generation
- Alert Rules guide — configuring the incident detection mechanism
- Time-Machine guide — session replay for incident investigation