What Article 10 requires, what “high-risk” means in practice, and how GreenBirch Data Risk Monitor evidences compliance.

Executive Summary

The EU AI Act is the world’s first comprehensive law on artificial intelligence, and it does not treat AI as a single, uniform risk. For any firm using AI to support decisions on credit, insurance, employment or other sensitive outcomes, the Act imposes some of its most demanding obligations. Critically, a large share of those obligations relate to the data feeding the model and not on the model alone.

Article 10 of the Act sets out, in granular detail, what good data governance looks like for a high-risk AI system: where the data came from, how it was prepared, whether it is representative and complete, and what has been done to find and address bias and gaps. For most firms today, answering these questions is a manual, one-off exercise pulled together under pressure ahead of an audit or a client due-diligence request. A board can no longer rely on this approach, and it will not hold up once these new obligations are enforced.

This briefing sets out what the Act requires and by when, what counts as “high-risk” AI in practice, what the Act expects of firms managing a high-risk system, and how GreenBirch Data Risk Monitor (DRM) gives boards and senior management a standing, evidenced answer to the question regulators, clients, their own risk and compliance committees and stakeholders will keep returning to: how do you know the data behind this model can be trusted?

1. The Act and Its Timeline: More Than One Date

The EU AI Act (Regulation (EU) 2024/1689) entered into force on 1 August 2024 and was designed to become fully applicable two years later, on 2 August 2026. In practice, its obligations have always been phased, and that phasing has shifted since the Act was first agreed:

• 2 February 2025 – the Act’s outright prohibitions on unacceptable-risk AI practices, and its AI literacy obligations, took effect.
• 2 August 2025 – governance rules and obligations for general-purpose AI (GPAI) models became applicable.
• 2 August 2026 – the Act’s transparency obligations (Article 50) – covering matters such as disclosing AI-generated content and informing people they are interacting with a machine – come into effect, and this remains the date on which the Act as originally written was to become fully applicable.
• 2 December 2027 – following a political agreement reached in May 2026 and a package of amendments (the “AI Omnibus”) that entered into force in July 2026, this is now the date from which obligations for high-risk AI systems in sensitive areas listed in the EU AI Act’s Annex III – including employment, essential services such as credit and insurance, and several other categories – will apply.
• 2 August 2028 – high-risk AI systems that are safety components of regulated products, such as machinery or medical devices, now have until this date to comply.

A note on timing The obligations most relevant to this briefing – including Article 10 – sit within the Annex III high-risk regime, whose compliance deadline has moved from 2 August 2026 to 2 December 2027 as a result of the AI Omnibus. 2 August 2026 remains a significant date: it is when the Act’s transparency rules bite, and it was the original target for high-risk obligations. Firms should treat the extension as additional runway to get data governance right, not as a reason to deprioritise it – evidencing provenance, quality, and control across every data set feeding a high-risk system is not something that can be assembled quickly once the deadline is close.

This delay provides an important opportunity for organisations – this Regulation requires significant effort to comply. A firm that pauses its high-risk AI data governance programme because “2 August 2026 has been pushed back” will still face the December 2027 deadline, still faces client and counterparty due diligence in the meantime, and still carries the underlying business risk of ungoverned data feeding consequential decisions – regardless of what the regulation requires.

2. What Counts as “High-Risk” AI in Practice

Article 6 of the Act sets two independent tests for whether an AI system is high-risk. The first applies where an AI system is a safety component of, or is itself, a product already regulated under existing EU product-safety law (such as machinery or medical devices) and that product requires third-party conformity assessment. The second, and the one most relevant to financial and professional services, applies where the AI system performs a function listed in Annex III of the Act.

Annex III sets out eight categories of sensitive use. For most firms in financial services, insurance, and professional services, the categories that matter most are:

• Essential private and public services – including AI used to assess creditworthiness or establish a credit score (fraud-detection use is excluded from this category), and AI used for risk assessment and pricing in life and health insurance.
• Employment and worker management – including AI used in recruitment and candidate selection, and AI that affects the terms of a working relationship, promotion, task allocation, or performance monitoring.
• Biometric identification and categorisation, law enforcement, critical infrastructure, education, migration, and the administration of justice – relevant to firms operating in or adjacent to these areas.

A narrow exemption in Article 6(3) allows some Annex III systems to avoid high-risk classification where they perform only a limited procedural task, merely improve the result of a completed human activity, detect patterns without replacing human judgement, or carry out preparatory work – but firms relying on this exemption must document their reasoning, and the burden of proof sits with the firm, not the regulator.

In practice, this means an AI system used to screen loan applications, price an insurance policy, shortlist job candidates, or monitor staff performance is very likely to be high-risk – and the obligations that follow apply to the firm deploying it as much as to the firm that built it.

3. What Managing a High-Risk AI System Requires

Chapter III of the Act sets out a connected package of obligations for high-risk AI systems, running from Article 8 through Article 17. Taken together, they require a firm to be able to show – not simply assert – that a high-risk system is controlled across its lifecycle:

Article	What it requires
Art. 9	A continuous risk management system spanning the system’s entire lifecycle – not a one-off assessment.
Art. 10	Data and data governance – the subject of this briefing, and the section that follows.
Art. 11	Technical documentation demonstrating how the system meets each requirement of the Act.
Art. 12	Automatic logging and record-keeping sufficient to trace the system’s operation and outputs.
Art. 13	Clear information to deployers on the system’s capabilities, limitations, and intended use.
Art. 14	Human oversight measures that allow a person to understand, intervene in, or override the system.
Art. 15	An appropriate level of accuracy, robustness, and cybersecurity across the system’s lifecycle.
Art. 17	A quality management system embedding these obligations into the provider’s ongoing operations.

Every one of these obligations depends, to some degree, on the quality of the underlying evidence a firm can produce:

• A risk management system is only as credible as the risks it has actually identified;
• technical documentation is only as useful as the detail behind it;
• human oversight is only meaningful if the person overseeing the system can see what is driving its output.

Article 10 underpins all of them – it is where that evidence must start and therefore form the foundation of any AI Governance Framework.

4. Article 10 in Focus: Data and Data Governance

Article 10 is one of the most operationally demanding provisions in the Act, precisely because it asks firms to evidence decisions that are often made informally, by different teams, at different times, and rarely written down in one place.

4.1 What the Article Requires

Where a high-risk AI system is trained using data, Article 10(1) requires that its training, validation, and testing data sets meet the quality criteria set out in the rest of the Article. Article 10(2) then requires that those data sets be subject to data governance and management practices covering, in particular:

Ref.	Article 10(2) governance practice
(a)	The design choices made in building the data set.
(b)	Data collection processes and the origin of the data – and, for personal data, the original purpose it was collected for.
(c)	Data-preparation steps such as annotation, labelling, cleaning, updating, enrichment, and aggregation.
(d)	The assumptions made about what the data is intended to measure or represent.
(e)	An assessment of the availability, quantity, and suitability of the data sets needed.
(f)	Examination for possible biases likely to affect health, safety, or fundamental rights, or to lead to discrimination.
(g)	Appropriate measures to detect, prevent, and mitigate the biases identified under (f).
(h)	Identification of data gaps or shortcomings, and how they can be addressed.

Article 10(3) then sets the quality bar itself: data sets must be relevant, sufficiently representative, and – to the best extent possible – free of errors and complete for their intended purpose, with appropriate statistical properties in relation to the people the system will affect. Article 10(4) requires that data sets take account of the specific geographic, contextual, behavioural, or functional setting in which the system will be used. Article 10(5) permits limited, tightly safeguarded processing of special category personal data solely to detect and correct bias, subject to strict conditions. Where a high-risk system does not involve training a model on data, Article 10(6) narrows this obligation to the testing data set alone.

4.2 What This Means in Practice

Read together, Article 10 is not a data quality checklist that can be completed once. It requires a firm to be able to answer, for every data set feeding a high-risk system, and for as long as that system remains in use: “where did this come from, what was done to it, is it good enough for this purpose, what bias have we looked for, and what gaps remain?”

For most firms, that is a hard question to answer today. Data feeding a high-risk model typically arrives from a mix of internal systems, third-party vendors, and increasingly other models, assembled over time by different teams using different tools, with no single record connecting a model’s output back to the sources and transformations behind it.

5. Where are the likely challenges?

Based on GreenBirch’s current knowledge and experience in the financial sector, these will be the main challenges firm’s will face in implementing the AI Act and, in particular, Article 10:

• No connected provenance. Firms can usually name their data sources, but cannot trace, end to end, which sources and transformations actually feed a given model output – the connective tissue Article 10(2)(b) and (c) require is missing.
• No systematic quality scoring. Assessments of relevance, representativeness, completeness, and error rates – the criteria in Article 10(3) – tend to happen informally, inconsistently, or only once, rather than as a standing, comparable measure across every source.
• Reactive, not proactive, gap identification. Data gaps and shortcomings under Article 10(2)(h) are usually discovered after something has already gone wrong – a complaint, an incorrect decision, a regulator’s question – rather than identified and tracked as part of normal operation.

The result is that evidence of compliance, when it exists at all, is scattered across data engineering, model risk, and compliance teams, assembled under time pressure, and rarely presented in a form a board can meaningfully review or sign off on. That will make compliance with the EU AI Act very difficult unless the organisation changes the way it approaches the governance of AI. Just getting the documentation wrong can attract significant fines.

EU AI Act: Article 99 Paragraph 5 “The supply of incorrect, incomplete or misleading information to notified bodies or national competent authorities in reply to a request shall be subject to administrative fines of up to EUR 7 500 000 or, if the offender is an undertaking, up to 1 % of its total worldwide annual turnover for the preceding financial year, whichever is higher.”

6. How GreenBirch Data Risk Monitor Solves for Article 10

GreenBirch Data Risk Monitor (DRM) was built to close exactly this gap – connecting data lineage to data quality, and translating both into a form usable by data teams, model risk, compliance, and the board alike.

6.1 Mapping Every Data Source

DRM traces the full journey of data into a high-risk AI system: every internal data set, third-party feed, and upstream model that contributes to it, from original source through every transformation, to the point it reaches the model. This directly evidences the origin, collection, and preparation practices required under Article 10(2)(b) and (c), and the design choices and assumptions required under (a) and (d) – replacing scattered, undocumented knowledge within a single connected mapping system. It’s intuitive interface makes the information accessible to all – whether the user comes from the business, technical or compliance teams.

6.2 Scoring Sources for Quality

Each data source is scored against the quality dimensions Article 10(3) actually asks for: relevance, representativeness, completeness, error rate, and timeliness. Rather than a one-off assessment, this scoring is queried by DRM on a regular basis, so that a source’s quality position is always current – not a snapshot taken for the last audit.

6.3 Showing How Sources Are Delivered to the Model

DRM makes visible how each scored source combines and transforms on its way into the model – illustrating which feeds, which processing steps, and which upstream models sit behind a given output. This is the evidence base that supports the availability and suitability assessment required under Article 10(2)(e), and gives model risk and compliance teams a concrete answer to how a specific input influenced a specific outcome.

6.4 Surfacing Gaps and Supporting Bias Review

Where DRM’s mapping and scoring reveal a data gap, a stale feed, or a source falling short of its expected quality, that shortfall is captured and tracked as a standing item rather than left to be found by chance – directly supporting the gap-identification obligation in Article 10(2)(h). Where scoring surfaces a statistical skew or under-representation that could indicate bias, DRM surfaces it for the model risk and compliance teams responsible for bias examination and correction under Article 10(2)(f) and (g), giving them an evidenced starting point rather than a blank page.

6.5 Defining and Evidencing Controls

For every point in the pipeline where a risk is identified, DRM lets a firm define the control intended to mitigate it – a validation rule, a freshness threshold, a reconciliation check, a sign-off step – and track whether that control is in place and operating. Combined with the lineage and quality scoring above, this creates a standing, evidenced control framework for each high-risk system: not just what could go wrong, but what is being done about it, and proof that it is happening.

The board-level view All of this is translated into a single view that works at every level of the organisation: detailed enough for data and model risk teams to act on, and clear enough for the board to see, at a glance, which high-risk systems are backed by governed, quality-scored data – and which are not. However – this is not a just compliance exercise – this also allows a firm look forward to improvements and enables the agility required to respond to changing market conditions.

7. Conclusion

The extension of the Annex III high-risk deadline to 2 December 2027 buys firms time – but it does not remove the underlying obligation, and it should not be read as removing the underlying business risk of poorly governed data feeding consequential decisions about credit, insurance, or employment. Article 10 sets a demanding, granular standard, and meeting it depends on being able to trace, score, and control every data set feeding a high-risk system, continuously, not as a one-off exercise before an audit.

GreenBirch Data Risk Monitor gives boards and senior management exactly that: a standing, evidenced, board-ready view of the data behind every high-risk AI system – where it comes from, how good it is, how it reaches the model, and what controls are in place to manage the risk. That is the foundation not just for compliance with Article 10, but for the confidence a board needs to stand behind the decisions its AI systems make.

Get in touch to discuss a high-risk AI data governance review: info@greenbirch.net  |  +44 20 3287 5560