Learn
This article walks through the entire conformity assessment process for high-risk financial-services AI under Regulation (EU) 2024/1689 - what it is, when a notified body is involved, what documentation you prepare, and how the timeline changed in mid-2026.
Start with the deadline, because it moved. The original text of the AI Act set 2 August 2026 as the day high-risk obligations began to apply. On 16 June 2026 the European Parliament approved the Digital Omnibus on AI, and the Council gave its final green light on 29 June 2026. The package postpones the high-risk deadlines: standalone Annex III systems - which is where credit scoring and insurance pricing sit - now apply from 2 December 2027, and high-risk AI embedded as a safety component in products already covered by EU harmonisation legislation (Annex I) applies from 2 August 2028. The regulation enters into force on publication in the Official Journal, expected in July 2026.
One thing did not move: the Article 50 transparency obligations - labelling AI-generated content, telling people they are interacting with an AI - still apply from 2 August 2026. So the general transparency clock is running now; the heavy high-risk conformity work has more runway than the original timeline implied.
The other useful fact up front: most financial institutions do not need a notified body. For the point 5 financial-services categories, Article 43(2) prescribes the internal-control route, which means you assess yourself against a prescribed methodology and declare conformity. That is cheaper than an external assessment, but self-assessment is not the same as light-touch. The documentation alone is substantial.
| Governing law | Regulation (EU) 2024/1689 (the EU AI Act) |
| High-risk deadline (standalone, Annex III) | 2 December 2027 (postponed from 2 August 2026 by the Digital Omnibus on AI) |
| High-risk deadline (embedded in Annex I products) | 2 August 2028 (postponed from 2 August 2027) |
| Article 50 transparency | Still applies from 2 August 2026 - unchanged |
| Assessment route for finance (Annex III point 5) | Internal control, Annex VI (self-assessment) - no notified body, per Article 43(2) |
| Maximum penalty (Article 99) | Up to EUR 15 000 000 or 3% of total worldwide annual turnover for breaching provider obligations under Article 16 |
First, what exactly is a conformity assessment?
Strip away the legal wording and a conformity assessment is a structured process for demonstrating that a high-risk AI system meets the AI Act's requirements before it is placed on the market or put into service. It is the AI equivalent of the CE-marking logic used for regulated products: you show the system is safe, well-governed, documented, and subject to human oversight.
The legal basis is Article 43. For high-risk systems listed in points 2 to 8 of Annex III - which includes the financial-services categories in point 5 - Article 43(2) requires the internal control procedure described in Annex VI. You assess yourself against the prescribed methodology and declare conformity on the basis of that evaluation.
A notified-body assessment under Annex VII is the exception, not the rule for finance. It is an option only for point 1 of Annex III - remote biometric identification - and becomes mandatory there only where the provider has not fully applied the relevant harmonised standards or common specifications. Credit scoring and insurance pricing are point 5, so the internal-control route applies and no notified body is involved. Separately, where an AI system is a safety component of a product already covered by the EU harmonisation legislation in Annex I, Article 43(3) routes the conformity assessment through that sectoral regime instead.
Do not read "self-assessment" as "optional." The AI Act is specific about what the internal assessment must cover, and market surveillance authorities can request the documentation at any time. A poorly conducted self-assessment is worse than none, because it manufactures a false sense of compliance.
Which financial AI systems are high-risk?
Two entries in Annex III point 5 do the work for financial services. Credit scoring is point 5(b):
“AI systems intended to be used to evaluate the creditworthiness of natural persons or establish their credit score, with the exception of AI systems used for the purpose of detecting financial fraud.” - Annex III, point 5(b)
Life and health insurance risk assessment and pricing is point 5(c):
“AI systems intended to be used for risk assessment and pricing in relation to natural persons in the case of life and health insurance.” - Annex III, point 5(c)
Two boundaries follow directly from the text. Fraud detection is carved out of the credit-scoring category, so an AI system used purely to detect financial fraud is not high-risk on that basis. And point 5(c) is limited to life and health insurance - it does not sweep in every insurance line. In practical terms, for a typical bank or insurer the classification tends to land like this:
Clearly high-risk
AI credit scoring and automated lending decisions (point 5(b)); AI risk assessment and pricing for life and health insurance (point 5(c)).
Assess carefully
AI that segments customers in a way that governs access to credit; automated claims decisions that determine an insurance outcome for a person.
Not high-risk on this basis
Fraud detection (explicitly excluded from 5(b)); general chatbots; internal analytics; market-data processing. Article 50 transparency may still apply.
Check other regimes
Algorithmic trading, AML transaction monitoring and KYC automation may sit under MiFID II or AML law rather than Annex III. Classify each system on its own facts.
The requirement categories you are proving against
The conformity assessment verifies that a high-risk system meets the essential requirements in Section 2 of the AI Act - Articles 8 to 15. It is worth seeing them as categories rather than a wall of articles, because your technical documentation is organised around them:
| Risk management (Art. 9) | A continuous, lifecycle risk management system - not a point-in-time assessment. |
| Data and data governance (Art. 10) | Training, validation and testing data that is relevant, sufficiently representative, and examined for bias. |
| Technical documentation (Art. 11, Annex IV) | The full record of the system, drawn up before it is placed on the market and kept up to date. |
| Record-keeping and logging (Art. 12) | Automatic logging of events over the system's lifetime for traceability. |
| Transparency and information (Art. 13) | Instructions for use that let a deployer understand and interpret the system's output. |
| Human oversight (Art. 14) | Measures that let a person effectively oversee the system and intervene. |
| Accuracy, robustness, cybersecurity (Art. 15) | Appropriate levels of accuracy, resilience, and security against manipulation, declared and maintained. |
Article 8 is the umbrella that ties these together and requires compliance with the whole set. Everything else in the process - the quality management system, the documentation, the declaration - exists to evidence that these articles are satisfied.
The conformity assessment process, step by step
Based on Annex VI and Articles 8 to 17, 47 to 49 of the EU AI Act
Step 1: Establish your quality management system (Art. 17)
Before you assess individual systems, you need a quality management system covering the AI lifecycle. This is familiar from a manufacturing or ISO background but new territory for many financial institutions.
Under Article 17 the QMS must cover design and development procedures, testing and validation, data management, post-market monitoring, incident reporting, communication with authorities, record-keeping, resource management, and accountability. It is the organisational layer that makes governance consistent across every system.
Step 2: Build the technical documentation (Art. 11, Annex IV)
This is where most teams stall. Annex IV is detailed. For each high-risk system it must include, among other elements:
- A general description: intended purpose, provider, version, how it interacts with other systems
- The development process and the system's main design choices and architecture
- Risk management details under Article 9
- Data governance under Article 10 - training, validation and testing datasets
- Performance metrics, accuracy and robustness measures under Article 15
- Human oversight measures under Article 14
- The logging capabilities under Article 12
- Expected lifetime, foreseeable changes, and maintenance
Step 3: Implement the risk management system (Art. 9)
Article 9 requires a risk management system that runs across the entire lifecycle - a continuous process, not a one-off assessment. It must identify and analyse known and reasonably foreseeable risks, estimate risks under intended use and reasonably foreseeable misuse, evaluate risks from post-market monitoring data, and adopt appropriate mitigation.
For a credit-scoring model that means documenting risks such as demographic bias, data-quality degradation, model drift, adversarial inputs, and the consequences of incorrect decisions - and then showing the mitigation for each.
Step 4: Ensure data governance (Art. 10)
Article 10 requires that training, validation and testing datasets are relevant, sufficiently representative, and to the best extent possible free of errors and complete for the intended purpose. You document collection, preparation operations such as labelling and cleaning, known gaps, and the examination for possible biases. For a bank using AI credit scoring, that means demonstrating your training data does not systematically under-represent protected groups, that validation data is separated from training data, and that you have tested for proxy discrimination.
Step 5: Test against defined metrics (Art. 9 and 15)
Testing happens before placing on the market and at points through the lifecycle. Article 9 requires testing against preliminarily defined metrics and probabilistic thresholds, so you cannot simply run the model and eyeball the output. Define acceptance criteria upfront - accuracy thresholds, fairness metrics, robustness benchmarks under Article 15 - and test against them with a documented methodology, results, and corrective actions.
Step 6: Conduct the internal assessment (Annex VI)
This is where it comes together. The internal control procedure in Annex VI requires you to verify that:
- Your quality management system complies with Article 17
- Your technical documentation complies with Article 11 and Annex IV
- The design and development process is consistent with the QMS
- The system meets the essential requirements in Articles 8 to 15
Step 7: Declare conformity, mark, and register (Art. 47 to 49)
Once the assessment is complete you draw up the EU declaration of conformity under Article 47, affix the CE marking under Article 48 (affixed digitally for systems that are not physical products), and register the system in the EU database for high-risk AI systems under Article 49 before placing it on the market or putting it into service. The declaration and technical documentation must be kept for 10 years after the system is placed on the market. That is a long retention window - make the record-keeping durable.
The documentation reality check
The load is real. Annex IV technical documentation has to be detailed enough for a market surveillance authority to understand a system's purpose, architecture, training data, testing, performance, limitations, and risk mitigations without speaking to you. That is a serious document per system, not a one-page attestation.
Now count the systems in production that fall inside Annex III point 5: the credit-scoring model, the automated underwriting engine, the life and health insurance pricing model. Each needs its own Annex IV file, its own risk assessment, its own test reports, and its own declaration of conformity - on top of the single quality management system that covers them all.
That is why the 2 December 2027 deadline, while further off than the original 2 August 2026 date, is not an invitation to wait. The work scales with the number of high-risk systems, and the first Annex IV file always takes longest.
Provider vs deployer: who does the assessment?
This trips up a lot of financial institutions. The AI Act distinguishes providers (who develop the system or have it developed and place it on the market under their own name) from deployers (who use it). The conformity assessment is the provider's responsibility.
So if your bank buys a credit-scoring model from a vendor that puts it on the market, the vendor is the provider and carries the assessment. Your bank is the deployer. But Article 25 says a deployer becomes a provider - and inherits the assessment obligation - if it:
- Puts its own name or trademark on the high-risk system already on the market
- Makes a substantial modification to the system
- Modifies the intended purpose of a system so that it becomes high-risk
In financial services, substantial modification is common. You buy a credit-scoring framework, retrain it on your own data, change the features, and recalibrate the thresholds to your risk appetite. Whether that is a substantial modification is a real question - and if it is, the conformity assessment becomes yours.
Even as a pure deployer, Article 26 imposes obligations: use the system per its instructions, ensure human oversight, monitor operation, keep the automatically generated logs for at least six months, and carry out a fundamental rights impact assessment where Article 27 requires one.
A sensible order of work
With the standalone high-risk deadline now at 2 December 2027, there is more runway than the original timeline allowed - but the sequence still matters, because each stage depends on the one before it.
Inventory and classification first. Catalogue every AI system in the organisation and classify each against Annex III. For each one, decide whether you are provider or deployer. Most organisations are surprised how many systems surface once they look carefully - the spreadsheet with a few macros may be running a machine-learning library underneath.
Then the quality management system. If you do not have a QMS for AI, build one against Article 17. If you already hold ISO/IEC 42001, the AI management system standard, there is significant overlap - but Article 17 has specific requirements that ISO/IEC 42001 does not fully cover.
Then technical documentation, highest-risk system first. Build the Annex IV file for your most critical system and use it as a template for the rest. Assign a named owner per system; this cannot be done by committee.
Then testing and validation. Run, or document existing, testing against defined metrics - fairness, robustness, accuracy - with methodology, results, and conclusions.
Then assessment, declaration, and registration. Conduct the Annex VI internal assessment, draw up the declarations of conformity, register in the EU database, and stand up post-market monitoring. Remember the Article 50 transparency obligations run from 2 August 2026, ahead of all of this.
It is a lot. It is also manageable.
The process looks overwhelming at first - Annex IV especially - but it is a structured sequence with clear steps, and the second system takes far less time than the first once you have a working template.
Financial institutions are not starting from zero. You already run model governance (SR 11-7, SS1/23, EBA guidelines), data-quality processes, and model testing. The conformity assessment restructures and augments what you have rather than replacing it.
And if you are running AI Act conformity alongside DORA, GDPR, and other obligations, a platform that maps a single control to every regulation it satisfies keeps the effort from multiplying. DORA's ICT risk-management and testing controls, for instance, overlap meaningfully with the Article 9 and Article 15 evidence you are already producing - the same artefact can serve both.
Frequently Asked Questions
When must high-risk financial AI comply with the EU AI Act?
For standalone Annex III systems, including credit scoring (point 5(b)) and life and health insurance pricing (point 5(c)), the deadline is 2 December 2027. The Digital Omnibus on AI - approved by the European Parliament on 16 June 2026 and adopted by the Council on 29 June 2026 - postponed it from the original 2 August 2026. High-risk AI embedded as a safety component in Annex I products applies from 2 August 2028. The Article 50 transparency obligations still apply from 2 August 2026.
Does a bank need a notified body for its credit-scoring AI?
No. Credit scoring is Annex III point 5, and Article 43(2) requires the internal control procedure in Annex VI - a self-assessment with no notified body. A notified-body assessment under Annex VII can apply only to remote biometric identification (point 1), and only where the provider has not fully applied harmonised standards or common specifications.
Is the bank the provider or the deployer?
If you buy a credit-scoring model that a vendor places on the market under its own name, the vendor is the provider and runs the conformity assessment; the bank is the deployer. But under Article 25 a deployer becomes the provider if it re-brands the system, makes a substantial modification, or changes the intended purpose so the system becomes high-risk. Retraining and recalibrating a purchased model can cross that line.
What are the penalties for non-compliance?
Article 99 sets tiers. Breaching the prohibited-practices rules in Article 5 can draw up to EUR 35 000 000 or 7% of total worldwide annual turnover. Breaching other obligations - including the provider obligations in Article 16 that carry the high-risk requirements - can draw up to EUR 15 000 000 or 3%. Supplying incorrect, incomplete or misleading information to authorities or notified bodies can draw up to EUR 7 500 000 or 1%. For SMEs and start-ups the lower of the fixed amount or the percentage applies.
How does the AI Act relate to DORA for financial entities?
They are separate regimes with overlapping evidence. DORA governs ICT risk management, testing, incident reporting and third-party risk for financial entities; the AI Act governs the safety and governance of high-risk AI systems. The AI Act's Article 9 risk management and Article 15 robustness and cybersecurity requirements draw on artefacts you are likely producing for DORA already, so a control mapped once can satisfy both - but neither regime is a substitute for the other.
Track your AI Act conformity journey with Venvera
One workspace for AI Act, DORA and GDPR
Venvera helps financial institutions run EU AI Act conformity alongside DORA, GDPR and their other obligations - with cross-regulation control mapping, risk assessments, and gap analysis in one place. Starting at €399/month.
Book a Demo →Primary sources
This guide is drawn from the regulation and official sources:
- Regulation (EU) 2024/1689 - the EU AI Act, including Article 43 (conformity assessment), Articles 8 to 17, 47 to 49, Article 99 (penalties), and Annex III point 5, Annex IV and Annex VI.
- European Commission - AI Act policy pages.
- Council of the EU - "Artificial intelligence: Council gives final green light to simplify and streamline rules" (29 June 2026), on the Digital Omnibus and the postponed high-risk deadlines.
Last updated: 14 July 2026. The EU AI Act is subject to ongoing implementing acts and guidance from the European AI Office, and the Digital Omnibus enters into force on publication in the Official Journal. This article is educational and does not constitute legal advice.
