EU AI Act Article 17: Writing the Data Management Procedure in Your Quality Management System

This page is general information, not legal advice. Confirm requirements with counsel for your jurisdiction and use case.

What Article 17(1)(f) actually requires

Article 17(1)(f) requires documented procedures, not a particular tool or certification, covering every data operation performed before and for the purpose of placing a high-risk system on the market [6]. The listed operations are acquisition, collection, analysis, labeling, storage, filtration, mining, aggregation and retention. Article 17 also says the QMS must be documented "in a systematic and orderly manner" as written policies, procedures and instructions [6]. An undocumented habit, a Slack thread or a Jupyter notebook does not meet that bar.

The duty sits with the provider. If you buy data from a third party, the procedure still has to govern how that data enters your pipeline, because a notified body or market surveillance authority will judge your controls, not your supplier's. Our page on when fine-tuning with acquired data makes you a provider covers the role question first.

Article 17 also allows integration. Providers already under sectoral quality rules (for example medical device QMS under ISO 13485-style regimes) may fold these elements into existing systems, and regulated financial institutions can meet most of it through internal-governance rules, with exceptions [6]. Article 17(2) makes implementation proportionate to provider size, and Article 63 lets microenterprises meet certain QMS elements in a simplified way [6]. Verify with counsel which elements the simplification covers before an SME relies on it.

How Article 17 relates to Article 10, Annex IV and Article 18

Article 17 sets the process, Article 10 sets the quality outcome, Annex IV sets what you must describe, and Article 18 sets how long you keep it. Article 10 requires training, validation and testing data sets to be subject to data governance and management practices and to meet quality criteria such as relevance, representativeness and examination for possible biases [1]. Annex IV point 2(d) asks, where relevant, for datasheets describing data provenance, scope, main characteristics, how data was obtained and selected, and labeling and cleaning methodologies [2].

Article 18 requires providers to keep the technical documentation and the QMS documentation for 10 years after the system is placed on the market or put into service [3]. Your data management procedure therefore has to outlive the dataset license, the supplier relationship and probably the team that wrote it. Retention terms in data licenses need to be reconciled with that 10-year documentation horizon; see regulator access to licensed training datasets.

The practical design rule: one record per dataset version, created by the procedure, that feeds three consumers. Those are the Article 10 data governance evidence, the Annex IV dataset descriptions, and the Article 18 archive. Under Annex VII, a notified body assessing your QMS and technical documentation may also be given access to the training, validation and testing data sets themselves [4].

Timing after the Digital Omnibus

As of October 2026, the high-risk obligations are not yet applicable, but the procedure has to exist before the data it governs is acquired. Regulation (EU) 2026/1744 amended the AI Act and was published in the Official Journal on 24 July 2026 [5]. Commentary reports that high-risk application dates moved to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems; check the OJ text for your category [5].

Data acquired in 2026 for a system placed on the market in 2028 will be examined under the procedure you claim governed it. Retroactively reconstructing provenance for a corpus assembled without intake records is slow, costly and often incomplete. Our deadlines page maps acquisition planning to the new dates.

The harmonised QMS standard: EN 18286 status

EN 18286 is the CEN-CENELEC JTC 21 standard being drafted for the Article 17 QMS, and as of October 2026 you should confirm its publication status before relying on it. Under the AI Act, a presumption of conformity arises only once a harmonised standard's reference is published in the OJ [6]. Check the OJ before you write "conforms to EN 18286" into a declaration.

Until then, structure your procedure so it maps cleanly to EN 18286 clauses once you hold the text. ISO/IEC 5259-4 gives a data quality process framework covering supervised learning and labeling [7], and ISO/IEC 42001 gives a management-system skeleton (policy, roles, documented information, internal audit) [8]. Neither is a substitute for Article 17, but both reduce rework. For supplier-side controls, see ISO/IEC 42001 Annex A data and supplier controls.

The eight sections of the data management procedure

A defensible procedure has eight controlled sections, each producing a named record. The order below follows the data lifecycle that Article 17(1)(f) lists [6].

1. Intake request. Who may request data, the intended purpose (training, validation or test), the high-risk use case, required populations and geographies, and the Article 10 quality targets the data must help meet [1].
2. Rights and license check. Chain of title, license scope (training, fine-tuning, evaluation, derivative models), term, territory, and whether regulator and notified body access is allowed. Personal data triggers a GDPR lawful-basis and DPIA check, and special-category data for bias detection follows Article 10(5) conditions.
3. Required supplier documentation. A minimum evidence pack: source systems and extraction dates, record counts, schema and data dictionary, collection context, consents or legal basis, de-identification method and residual-risk statement, and known gaps.
4. Approval gate. Named approvers (data owner, legal, privacy, quality) sign a dataset version, identified by content hash, before any copy enters training storage.
5. Labelling and annotation QA. Guidelines version, annotator qualification, inter-annotator agreement metric (for example Cohen's kappa or Krippendorff's alpha) with thresholds, adjudication rules, and gold-set audit rates [7].
6. Storage, filtration and access control. Storage location, encryption, role-based access, segregation of test sets from training sets, and logged filtering, deduplication and aggregation steps with code versions.
7. Retention and deletion. Dataset retention tied to license terms, documentation retention tied to the 10-year Article 18 period [3], and deletion evidence when a license ends.
8. Change control. Any new source, relabeling, filter change or merge creates a new dataset version, re-runs the affected gates, and triggers an Annex IV update [2].

A common failure mode is section 6 without section 8: teams log filters but overwrite the dataset in place, so the version the model was trained on cannot be reproduced. Another is approving a supplier rather than a dataset version, which lets later deliveries bypass review.

Worked record: one dataset version through the procedure

The record below is what your procedure should emit for every dataset version. Fields map to Article 10, Annex IV point 2(d) and the Article 18 archive.

Illustrative example: invented to show structure; it does not describe an available dataset.

Supplier evidence to request before acquisition

Ask every data supplier for the evidence your procedure needs before contract signature, not after delivery. Practical requests include the extraction query or export job definition, the data dictionary, consent or notice language in force during collection, the de-identification method and who verified it, and written permission for notified body and authority access to the data where the license restricts disclosure [4].

Buyers who source operational data through SourceX describe the data they need rather than the businesses, and SourceX looks for US businesses that hold it, with each release approved by the supplying company. Every dataset is rights-reviewed for ownership and consents and delivered under a license defining records, uses, term and delivery, and diligence materials on source, rights, preparation and allowed use are prepared per dataset. That maps directly onto sections 2 and 3 of the procedure; buyers can start a request at SourceX for AI data buyers. For the general purchase process, see how to procure enterprise training data.

Sourcing data your Article 17 procedure can document

SourceX sources operational datasets from US companies on request and manages the licensing and ongoing purchases; it does not hold stock, and a request does not guarantee a match. Personal details are removed or replaced before delivery with the method recorded and a sample checked, and delivery runs through private, access-controlled workflows after an executed agreement and supplier approval. Describe the data your high-risk system needs at https://sourcex.si/buyers.