Article 10 data governance: requirements and evidence

What Article 10 data governance asks for and why it is hard

If you are the compliance lead or engineer facing the Article 10 deadline, the short answer is that you must govern the data behind your high-risk AI system as a managed process, not as a one-time dataset export. Article 10 expects you to document where training, validation and testing data came from, how it was collected and prepared, what assumptions were made about it, and whether it is relevant, sufficiently representative and as free of errors and gaps as practical. You also have to examine the data for biases, apply mitigation where bias is found, and record the data gaps you could not close. The risk behind these demands is concrete: a model trained on skewed, stale or poorly labeled data can produce discriminatory or unreliable outputs for the people it scores, screens or advises, and the harm falls on those people first.

The work is hard for two reasons. First, provenance is often undocumented. Datasets arrive through scraping, vendor feeds, internal exports and manual labeling, and the decisions behind them sit in people's heads or in ticket threads. A practical first step is to build a data register per dataset that records source, licence or legal basis, collection period, transformations and owner, then ask your engineers to confirm which datasets they cannot trace. Second, bias examination touches special-category personal data such as health, ethnicity or religion, which the GDPR restricts. Regulation (EU) 2026/1744 deleted Article 10(5) and moved the rules for processing special categories for bias detection into a new Article 4a. Under that article, synthetic or anonymized data does not suffice where bias detection needs the real attributes, and you must pseudonymize, restrict access, prevent onward transfer, delete the data once the bias is corrected, and record the reasons in your GDPR records of processing. Confirm the current wording with your legal team against the consolidated text.

Plan the timeline against the dates. The 2026 amendment moved the high-risk rules for Annex III systems to 2 December 2027, so that is the date to build toward for most systems in this group. Because the harmonised standard on bias management, prEN 18283, was still in development when CEN-CENELEC reported in May 2026, you cannot rely on a published standard to define what a good bias examination looks like. Decide now who owns the data governance file, which bias metrics you will use and how you will justify them, and whether an outside assessor will review the approach before it is tested. Ask any implementation partner to show how the evidence will be produced, and remember that only an independent auditor or notified body issues conformity findings.

Which datasets, systems and teams fall under Article 10

Article 10 duties depend on a few early decisions: whether the system trains its own models, which data sources feed it, and whether the setting of use is well covered by the data. Each card below is a scoping question to settle before the data governance plan is written, along with the team that owns the answer.

Training, validation and testing sets

If the high-risk system trains its own models, Article 10(2) governance applies to training, validation and testing data alike. Record which sets exist, who created each one, and where they are stored. Check that the same governance covers all three, because a gap in one set is often where bias examination fails.

Testing-only systems

Under Article 10(6), a high-risk system that does not train models must apply the data requirements to its testing data sets only. The team should document that no model is trained in-house, confirm this against the vendor or pre-trained model contract, and keep the test set design under the same governance as any other data set.

The Article 42(1) presumption

Article 42(1) presumes compliance with Article 10(4) for systems trained and tested on data that reflects their setting of use. Whether this is realistic depends on the deployment population, geography and workflow. Ask whether the data matches the real setting, and if not, plan the evidence needed to show representativeness without the presumption.

Third-party and pre-trained data sources

Pre-trained models, licensed data sets, public corpora and data bought from brokers all feed the system. For each source, record its origin, license, collection method and known gaps. Ask vendors for documentation of design choices and collection processes, since Article 10(2) governance cannot be shown for data the organization cannot describe.

Special-category data for bias detection

Where bias detection requires special-category personal data, the 2026 amendment moved the rules into Article 4a. The legal and privacy team should confirm that synthetic or anonymized data would not suffice, that pseudonymization and access controls are in place, and that the processing is recorded in the GDPR records of processing.

Who owns each part of the work

Data engineering owns collection, labeling, cleaning and lineage. ML teams own splits, metrics and bias testing. Legal and privacy own the lawful basis, Article 4a conditions and records. Domain experts define the setting of use and judge whether the data reflects it. Name one owner per decision, because gaps usually sit between these teams.

How to build a data governance process that holds up at assessment

A sequence that moves from knowing which datasets exist to proving, with dated records, that training, validation and testing data were chosen, prepared, examined and reviewed in line with Article 10. Each step produces a record an assessor can sample.

Inventory every dataset and its role
List each training, validation and testing data set the system uses, along with the model or system it feeds, its owner and its storage location. Mark which sets are used for training, which for validation and which for testing, because Article 10(6) applies the data requirements only to testing data for systems that do not train models. Done means every set has a register entry with an owner, a purpose and a version identifier. The output is a dataset register, kept under version control so changes can be traced.
Record design choices, origin and assumptions
For each dataset, document why it was chosen, how it was collected or sourced, the legal basis and licence for use, and the assumptions the team made about the people or situations it describes. Article 10(2) expects governance over design choices, collection processes and origin, so an assessor will ask for this reasoning, not only the file. Done means each register entry links to a design note signed by the accountable owner. Wiki page histories are useful here because they show what changed, when and by whom.
Log preparation steps such as labeling and cleaning
Record every preparation operation: labeling instructions, annotator qualifications, cleaning rules, deduplication, filtering, normalization and any synthetic augmentation. Keep the scripts or pipeline configuration that performed each step so the output can be reproduced. Done means a preparation log can take any sample record and show what happened to it between collection and use. The output is a preparation log tied to dataset versions, with labeling quality checks recorded alongside it.
Test representativeness and find data gaps
Compare each dataset against the geographical, contextual, behavioral and functional setting in which the system will be used, as Article 10(4) requires. Check coverage across the groups and conditions the system will meet, check error and completeness rates, and record the statistical properties you measured. Article 42(1) presumes compliance with Article 10(4) for systems trained and tested on data that reflects their setting of use, so document that match explicitly. Done means a gap analysis lists each identified shortfall, the affected population or condition, and the action taken or the residual limitation accepted.
Examine data for bias and decide on mitigation
Examine the datasets for possible biases that could affect health, safety or fundamental rights, or lead to discrimination the Act prohibits, as Article 10(2) requires. Where bias is found, select and document mitigation measures and re-test to confirm the effect. If the examination needs special-category personal data, Article 4a sets the conditions: pseudonymization, state-of-the-art security, strict and documented access controls, no transfer to other parties, deletion once the bias is corrected, and the reasons recorded in the GDPR records of processing. Article 4a(1) also states that synthetic or anonymized data would not suffice for that purpose, so record why it was needed. Done means a bias examination record covers each finding, mitigation, re-test result and the Article 4a conditions where they applied. Note that CEN-CENELEC reported in May 2026 that prEN 18283 on managing bias was still in development, so confirm current standards before you rely on a method.
Set access controls and retention for data artifacts
Apply role-based permissions to the datasets, preparation logs, gap analyses and bias records, so that access to personal data and to the bias examination is limited to named roles. Record who can read, change and export each artifact, and confirm that access reviews happen on a set schedule that you define. Done means an access matrix exists, has been reviewed by the data owner, and matches the actual permissions in the systems that hold the data. Confirm the retention rules with your legal team, since they depend on your own obligations.
Review the data governance cycle
Set a review trigger for each dataset, such as a retraining, a change in the setting of use, a new data source, a monitoring finding or an incident. At each review, re-run the representativeness, gap and bias checks, update the register and log the decision. Done means every change to a dataset or preparation step has a dated review record, and the post-deployment findings from Article 9 risk management and Article 12 logs feed back into the next cycle. Confirm the review frequency with your accountable owner and your internal policy.

How an assessor tests Article 10 compliance

This table walks through the areas an assessor typically examines under Article 10, the evidence each one asks for, and the gaps that come up most often. Read each row as a question the assessor will put to your data governance file, and check whether your records answer it for every training, validation and testing data set.

Obligation area	Evidence an assessor expects	Common findings
Design choices and data governance	Documented design decisions for each data set, with the reasons for selecting features, sources and collection criteria, and the person who approved them	Design rationale exists only in engineering chat threads or was never recorded for earlier model versions
Collection processes and origin	Provenance records for each source, including license or legal basis, collection dates, collection method and any third-party terms	Provenance is stated at dataset level only, or purchased and scraped data has no recorded origin
Preparation (labeling, cleaning, enrichment)	Written labeling guidelines, annotator instructions, inter-annotator agreement checks and a log of cleaning and transformation steps	Labeling rules changed during the project without version history, so the training set cannot be reproduced
Assumptions about what the data measures	A stated list of assumptions, such as what each field represents and which population it is meant to describe, with review records	Assumptions are implicit in code or were written once and never tested against later data
Availability and suitability	Assessment of whether the data is available at the quality and volume needed, and whether it fits the intended purpose and setting of use	Suitability is asserted without comparing the data to the operating environment described in the instructions for use
Examination for biases	Bias analysis plan, metrics chosen and why, results by relevant group, and the decision taken on each finding	Bias checks were run once before launch and never repeated after retraining or data refresh
Bias mitigation measures	Records of each mitigation applied, its effect on the metrics, residual bias accepted and who accepted it	Mitigation is described in general terms with no before and after measurements
Data gap identification	A gap register listing missing populations, under-represented conditions and proxy variables, with planned actions and owners	No gap register exists, or gaps are noted without a link to the risk management file
Representativeness and completeness	Statistical profiles of each data set compared with the geographic, contextual, behavioral or functional setting of use, plus error and missing-value rates	Representativeness is judged by volume alone, and the setting of use is not defined in the technical documentation

What the 2026 Article 4a change means for bias detection

Regulation (EU) 2026/1744 removed the bias-detection rules from Article 10(5) and placed them in a new Article 4a. The permission to process special categories of personal data for bias detection now sits in its own article, and it comes with a strict condition: the provider or deployer must show that other data, such as synthetic or anonymized data, would not suffice for the detection task. Before relying on the permission, the team should write down why synthetic or anonymized alternatives were tested and rejected for the specific model and dataset. That reasoning is the first thing an assessor will ask to see.

Article 4a(1) attaches a set of safeguards to the permission. Special-category data must be pseudonymized and protected with state-of-the-art security. Access must be strict and documented, so the access list, the approval for each grant, and the review of who still needs access should all be kept as records. The data may not be transferred to other parties, and it must be deleted once the bias has been corrected. The reasons for the processing also belong in the GDPR records of processing, so the data protection officer or privacy lead needs to be involved from the start rather than after the model is built. Organizations should confirm these steps with their own privacy counsel, since the GDPR interaction depends on their processing context.

Article 4a(2) extends the same permission, under the same safeguards, to providers and deployers of other AI systems and models, and to deployers of high-risk systems. The extension allows the permission to be used more widely, but it does not create a duty to detect bias. An organization that chooses not to run special-category bias detection has not breached Article 4a by doing so. Teams should still record that decision and its rationale, because the bias examination required under Article 10(2) remains in force and must be justified through other means. Confirm with the CEN-CENELEC standards programme whether the bias management standard in development, prEN 18283, changes how that examination should be documented.

Evidence that passes an Article 10 review

An Article 10 review tests whether data governance is documented, traceable and kept current, not whether a dataset was once well prepared. The six artifacts below connect the provenance of each dataset to the bias decisions made about it and the records that show those decisions still hold after retraining.

Dataset register with provenance and licensing

A register lists every training, validation and testing data set with its source, collection method, legal basis for use, license terms, owner and the Article 10(2) design choices made for it. Assessors use it as the entry point to every other artifact, so each data set should have one row that links to its preparation log and bias report. Check that licensing terms are recorded against the version used, because a license that changes between retrainings can invalidate a data set without any change to the files. Keep the register under version control and review it at every retraining cycle.

Data preparation logs

Preparation logs record each labeling, cleaning, filtering, deduplication and transformation step, with the rule applied, the person or tool that applied it and the input and output counts. Article 10(2) names preparation as a governed stage, so an assessor will expect to reproduce any step from the log alone. Labeling guidelines and inter-annotator checks belong in the same record. Where a preparation script changes, the log should show which version of the script produced which data set version.

Representativeness and gap analyses

These analyses compare each data set against the geographical, contextual, behavioral or functional setting in which the system will be used, as Article 10(3) and (4) require. The analysis should name the population groups, conditions and edge cases the data does not cover, and state what the provider did about each gap, including whether the gap was accepted and why. Ask whether the analysis was written against the deployment setting described in the instructions for use, not against the convenience sample the team happened to have.

Bias examination reports and mitigation decisions

A bias examination report records which groups were tested, the metrics used, the thresholds applied and the results before and after mitigation. Article 10(2) requires examination for biases and mitigation measures, so each mitigation decision needs a rationale, an owner and a note of any residual disparity accepted. Prepare for the fact that CEN-CENELEC reported in May 2026 that prEN 18283 on managing bias was still in development, so document the method you chose and the reason for choosing it.

Article 4a records for special-category data

Where special-category personal data was processed to detect or correct bias, Article 4a requires a documented justification that synthetic or anonymized data would not suffice. The record should also show pseudonymization, access controls limited to named roles, a prohibition on transfer to other parties, and the deletion date once the bias is corrected. Confirm that the reasons for processing appear in the GDPR records of processing. Note that Article 4a(2) extends the permission to other AI providers and deployers, but it does not create a duty to detect bias.

Versioned change history

Assessors test whether the data set that trained a model can be identified after the fact. Keep every change to a data set, register entry, preparation rule or bias decision in a version-controlled record that shows what changed, when and by whom, and can restore earlier states. Tie each model version to the exact data set versions it used. Retraining is where this breaks down, so schedule a register and gap review whenever a data set is replaced, not only before the annual audit.

What meeting Article 10 costs in money and effort

This table breaks down the cost components of meeting Article 10 data governance, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to structure a quote request and to see where self-hosted open-source tooling reduces license spend. No fee figures are supplied for this topic, so the table names what to request rather than amounts.

Cost component	Who is paid or who carries it	One-time or recurring	What drives the cost
Tooling and licenses	Software vendors, or internal teams for self-hosted tools	Recurring for commercial licenses, one-time for setup	Number of data pipelines and seats; self-hosted open-source tools can remove most license spend
Provenance and preparation records	Data engineers, data stewards or an implementation partner	One-time per dataset, recurring for each new data version	Number of datasets, labeling steps and third-party sources to document
Bias examination and mitigation work	Data scientists, domain experts and ML engineers	Recurring with each retraining or test cycle	Number of protected characteristics examined and number of models
Legal and privacy review for Article 4a	Privacy counsel, DPO and security staff	One-time for the initial assessment, recurring when processing changes	Whether special-category data is used, pseudonymization approach and GDPR record updates
Third-party and licensed data review	Procurement, legal and the data provider	One-time per source, recurring at renewal	Volume of external data, contract terms and documentation the supplier provides
External review or independent test	Specialist reviewers or testing firms, if engaged	Recurring when scope or models change	Scope of the review and how many systems need independent examination
Auditor or assessor effort	Independent auditor, notified body or assessor, where applicable	Recurring at each assessment cycle	Scope, evidence quality and the conformity route that applies to the system
Retraining and re-examination	Internal ML teams and compute providers	Recurring with each retraining cycle	Retraining frequency, compute costs and whether test sets must be rebuilt

Who owns Article 10 work, who can help and where the assessor stops

Article 10 places its duties on the provider of a high-risk AI system, and on the deployer where the deployer controls the data it uses. Only your organization can decide why a data set is fit for a given purpose, which populations matter in your setting of use, and which bias findings are acceptable or require mitigation. Those decisions cannot be outsourced, because they depend on your product, your users and your risk appetite.

Data governance decisions: Document design choices, collection processes, origin, labeling and cleaning, and the assumptions behind them, as Article 10(2) asks.
Bias examination and mitigation: Decide which groups and error patterns to test, and record how each finding was handled.
Data gap identification: Own the register of known gaps and the plan to close or disclose them.
Accountability and sign-off: Name the people who approve each data set and each residual risk.
Special-category processing: If you rely on the Article 4a route for bias detection, keep the GDPR records of processing and the access controls current.

Before you engage any outside party, confirm internally which team holds each of these decisions and where the evidence will live.

Where organizations fall short on Article 10 and how to close it

Most Article 10 gaps are not missing policies. They are missing links between where data came from, how it was checked against the setting of use, and what was done with it afterward. The cards below cover the gaps assessors most often find and a concrete first step for each.

Undocumented provenance for purchased data

Teams often inherit pre-trained models, licensed datasets or scraped corpora with little record of origin, collection method or labeling. Article 10(2) expects the design choices, collection processes and origin of training, validation and testing data to be governed, so a purchased dataset with no origin file is a gap even when the data itself is sound. Start with a data register that records the source, licence terms, collection method, date range and the person accountable for each dataset before any training run uses it.

Representativeness tested only in the lab

Datasets are frequently checked for balance against the training population but never against the people, locations or conditions where the system is deployed. Article 10(4) asks data to reflect the geographical, contextual, behavioral or functional setting of use, and that gap is where accuracy drops after launch. Compare each dataset against a written description of the intended setting and record which subgroups or conditions are thin, then decide whether to collect more data or narrow the stated use.

Bias examined once, at launch

A single bias review before release leaves no evidence of how the data behaved as inputs drifted over time. Article 10(2) treats the examination for biases and the mitigation measures as part of ongoing data governance, and the lifecycle risk process in Article 9 points the same way. Schedule bias examinations tied to retraining, new data sources and monitoring alerts, and keep each result with the dataset version it tested.

Special-category data handled outside Article 4a

Teams sometimes use health, ethnicity or other special-category attributes to test for bias without the safeguards that Article 4a sets out. Under the 2026 amendment, that processing needs a documented reason why synthetic or anonymized data would not suffice, pseudonymization, strict access controls, no onward transfer and deletion once the bias is corrected. Confirm the Article 4a conditions in writing before any special-category field enters a bias test, and have counsel review the basis.

No deletion record for bias-testing data

Article 4a requires special-category data used for bias detection to be deleted once the bias is corrected, and the GDPR records of processing must show the reason for the processing. Without a deletion log, an assessor cannot confirm that the data is gone or when it went. Log each deletion with the dataset identifier, the date, the bias finding it closed and the person who approved it, and keep that log with the GDPR records.

Dataset versions not tied to model versions

When a model is retrained, teams often cannot say which data it learned from, which makes the Article 10 evidence unusable for any given release. Assessors ask for that traceability to connect data governance to the technical file and the logs the system keeps. Assign every model version a dataset manifest that lists the exact data versions, preparation steps and bias results, and store the manifest with the release record.

Questions buyers ask about Article 10 cost, timing and ownership

Can our team meet Article 10 without outside help?

Often yes, if the team has the right people and time. Article 10 is a data governance duty, so the provider owns it. Meeting it draws on data engineers, machine learning staff, privacy counsel and domain experts who understand the setting of use. Outside help usually goes toward preparing pipelines, lineage records and evidence packs, not toward owning the decisions. Start by confirming whether your system is in Annex III or Annex I and whether you train models or only test them, because Article 10(6) limits the data requirements to testing data sets for systems that do not train models. Then check whether anyone on staff has time to maintain the records after launch, since the work recurs with each data change.

What drives the effort of Article 10 work?

Effort rises with the number of data sets, how far their origin can be traced, and how much preparation happens before training. The main cost drivers are:

Provenance: how many sources, licenses and collection processes must be recorded for each data set.
Preparation: the volume of labeling, cleaning and gap analysis.
Bias examination: how many groups, features and settings must be tested, and how often.
Special-category data: whether Article 4a safeguards must be built into access controls, pseudonymization and deletion.
Existing tooling: whether versioning and access logs already exist or must be built.

Most of the cost is internal staff time, plus one-time pipeline work and recurring re-examination when data or the setting of use changes. Ask any partner to break its quote down by these drivers.

Does Article 4a apply to our bias detection work?

It applies only if your bias detection involves processing special categories of personal data. Regulation (EU) 2026/1744 deleted Article 10(5) and moved those rules into Article 4a, which requires that synthetic or anonymized data would not suffice for the purpose. The safeguards include pseudonymization, state-of-the-art security, strict and documented access controls, no transfer to other parties, deletion once the bias is corrected, and recording the reasons in your GDPR records of processing. Article 4a(2) extends the same permission to other providers and deployers, and it does not create an obligation to detect bias. Confirm the exact wording and your GDPR position with privacy counsel, using the consolidated text of Regulation (EU) 2026/1744.

How do the 2027 and 2028 dates change our Article 10 plan?

The dates set when you must be ready, and they should drive backward planning. As amended in 2026, the high-risk rules apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I product systems. Those dates replace 2 August 2026 and 2 August 2027. Data governance depends on history, such as provenance and bias examinations recorded at the time, so teams should start capturing those records well before the deadline. Also track the standards work: CEN-CENELEC reported in May 2026 that prEN 18283 on managing bias was still in development. Confirm any later change to these dates against the consolidated text before you lock a schedule.

Does an assessor certify our training data?

No assessor certifies training data on its own. Most Annex III high-risk systems use internal-control conformity assessment under Annex VI, so the provider performs the assessment and maintains the technical file. Notified bodies are involved for some biometric systems and for Annex I products under Article 43. Whoever reviews your work will look for documented data governance, examination results and mitigation records, and will test whether those records match the system in use. Only an independent auditor, assessor or certification body issues reports or certificates. DeployOpen prepares systems, controls and evidence for these reviews but does not issue them. Ask your reviewer which samples and records they expect before you define the evidence set.

Which open-source tools help produce Article 10 evidence?

Version control and access documentation tools can produce much of the governance record. XWiki keeps every page change under version control, recording what changed, when and by whom, and lets users compare and roll back versions, which suits data-set descriptions, assumptions and examination reports. BookStack assigns abilities through roles and allows permissions to be overridden at the shelf, book, chapter or page level, which helps document who may access sensitive data sets. Pipeline lineage and dataset versioning usually need a separate tool that your engineers select and test. Confirm that any tool fits your hosting, retention and access requirements inside your own infrastructure before relying on it for evidence.

What should a written scope for Article 10 work include?

A written scope should name exactly what will be delivered, for which systems and data sets, and who signs off each item. DeployOpen works to fixed scopes agreed in writing before work starts, and a quote follows from that scope. Ask for:

The systems and data sets covered, and whether training, validation and testing data each fall in scope.
The bias examination method, the groups and features tested, and the mitigation records to be produced.
Decisions on whether Article 4a applies, with the safeguards to be implemented.
Each evidence deliverable, its format and where it will be hosted.
Acceptance criteria, exclusions, change handling and post-delivery support terms.
Named responsibilities on both sides, including who owns the final compliance decisions.

A scope that lists these items makes the quote comparable across providers.

How DeployOpen prepares data governance evidence for Article 10

DeployOpen plans, builds and documents the data governance setup that supports Article 10 on self-hosted infrastructure inside the client's own environment. The organization keeps ownership of its controls and data decisions, while DeployOpen prepares the systems and evidence that show how training, validation and testing data were governed.

How we scope

Engagements are fixed-scope, with the data sets, AI systems and roles in scope agreed in writing before work starts.
The written scope lists which Article 10 elements are covered, such as provenance, preparation, bias examination and data gap records.
Scope also states whether Article 4a special-category processing for bias detection is in or out, and who approves it.

How we build

Versioned data governance records are set up in a self-hosted wiki so each data set's origin, design choices and assumptions stay traceable.
Access controls for data governance pages and bias-related data are configured by role, with permissions documented per shelf, book and page.
Pipeline and evaluation logs are captured so data preparation steps and bias examinations can be reproduced and reviewed later.

How we hand over

Handover includes a data governance register mapping each data set to its provenance, preparation steps, representativeness review and known gaps.
Test results from data quality and bias examinations are delivered as dated, exportable records tied to specific data set versions.
Runbooks explain how the client's staff update records, retire data sets and document decisions when data changes.

How we support

Ongoing support, upgrades and continuous testing of the data governance tooling are available as a retainer.
Retainers can cover periodic review of data gap registers and re-examination of bias findings when training data is refreshed.
Independent auditors or certification bodies assess the evidence, while DeployOpen prepares the systems and records for that review.