EU AI Act Annex III for Credit Scoring: The Documentation Burden, Mapped

For two years, any bank, fintech or credit bureau building an AI system to score consumer creditworthiness in the EU had a single date to plan against: 2 August 2026. That date no longer applies. A mid-2026 amendment to the EU AI Act pushed the core high-risk obligations for credit-scoring systems out to 2 December 2027, and changed nothing about what those obligations actually require, only when they start to bind. This article maps that requirement set article by article: what a risk-management file has to contain, what a human reviewer must actually be able to do, what accuracy and cybersecurity evidence looks like, and what belongs in the technical-documentation dossier a supervisor can ask to see.

What changed, and what didn't

The EU AI Act, Regulation (EU) 2024/1689^[1], entered into force on 1 August 2024. Its obligations were always staggered rather than immediate: the ban on prohibited AI practices applied from 2 February 2025, and the governance and general-purpose AI model rules followed on 2 August 2025, per Article 113's original timetable^[2]. Both dates have passed and both sets of duties are already live, independent of anything discussed below. What was originally due next, on 2 August 2026, was the core set of requirements for standalone high-risk systems listed in Annex III, credit scoring among them.

That third date moved. The Digital Omnibus on AI^[3], formally Regulation (EU) 2026/1744, was proposed by the European Commission on 19 November 2025, reached political agreement between Parliament and Council on 7 May 2026, and entered into force on 27 July 2026 after publication in the Official Journal. It amends Article 113 of the AI Act to set 2 December 2027 as the application date for Sections 1, 2 and 3 of Chapter III for systems classified as high-risk under Article 6(2) and Annex III, the classification route credit-scoring systems fall under. A separate, later date of 2 August 2028 now applies to high-risk systems embedded as safety components in regulated products under Annex I, a different pathway that rarely covers a standalone scoring model. Regulation (EU) 2026/1744, recital 40^[4]

The Commission's own reasoning points to timing infrastructure rather than a change of policy: its AI Act timeline page^[5] frames the new date as giving firms more time to work against harmonised standards and other support tools that were not ready on the original schedule. A Gibson Dunn briefing on the agreement^[6] reaches the same practical conclusion: the deferral reflects standards infrastructure catching up with the law, not a reason to pause preparation, and treats the new date as confirmed rather than provisional. Neither the classification test, nor the substance of Articles 9, 14, 15 and Annex IV, changed. Only the calendar did.

Is your credit-scoring system actually in scope?

Annex III lists eight categories of high-risk use case. Point 5 covers access to essential private and public services, and its financial-services sub-point is specific: Annex III, point 5(b)^[7] applies to "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." Two boundaries sit inside that sentence. The scope is natural persons, so a model scoring corporate counterparty risk sits outside this specific point. And fraud-detection systems are carved out even where they touch the same transaction data a credit model would use, because the Act treats fraud detection and creditworthiness assessment as different risks.

Being listed in Annex III is not automatically the end of the analysis. Article 6(3)^[8] lets a provider decide that a listed system is not, in fact, high-risk, where it does not pose a significant risk of harm to health, safety or fundamental rights, and where it does one of four narrow things: performs a narrow procedural task, improves the result of a previously completed human activity, detects decision-making patterns without replacing or influencing a proper human assessment, or performs a preparatory task ahead of an assessment that matters. Any system that profiles natural persons is excluded from this route entirely and stays high-risk regardless. A production credit-scoring model that produces a score a human underwriter then acts on is a difficult fit for that narrow list, since its output is precisely what the assessment turns on rather than a preparatory or merely procedural input, but the judgement is fact-specific and firms should not assume either answer without documenting the reasoning. Using the derogation is not a way to avoid paperwork, either: a provider relying on it must still document that assessment before the system reaches the market, and separately register under Article 49(2).

Article 9: the risk-management file

Article 9^[9] requires a risk-management system, not a risk-management event. It has to run as a continuous, iterative process across the system's whole lifecycle, which for a credit-scoring model means before the first production decision and again every time the model, its features or its training data change materially. The concrete obligations are identification and analysis of known and reasonably foreseeable risks to health, safety and fundamental rights, covering both the system's intended use and reasonably foreseeable misuse; estimation and evaluation of risks that only become visible once post-market monitoring data comes in; adoption of targeted mitigation measures, addressed through design changes where feasible and through information or training where a design change is not possible; and testing throughout development and again before the system is placed on the market, against metrics and thresholds appropriate to its intended purpose. Where the system may affect people under 18 or other vulnerable groups, that has to be considered explicitly rather than assumed away.

For a creditworthiness model, the file this produces should be able to answer a specific question: what fundamental-rights risk does this system pose, most obviously the risk that a proxy variable correlated with a protected characteristic drives a disparate outcome, and what test was run to check for it before and after deployment. A risk register that only tracks model performance, and not that specific question, will not satisfy Article 9 on its own. The article does allow a provider to fold this process into risk management it already runs under other EU law, such as existing prudential or consumer-credit risk frameworks, rather than build an entirely separate parallel system.

Article 14: designing human oversight in

Article 14^[10] is about what a human reviewing a system's output can actually do, not whether a human's name sits somewhere on the process. High-risk systems have to be designed, including through the human-machine interface, so that oversight measures give the person doing the overseeing five specific capacities: to understand the system's capabilities and limitations well enough to monitor its operation and notice anomalies or dysfunction; to remain aware of the tendency to over-rely on an automated output, sometimes called automation bias, particularly where the system is supporting rather than replacing a decision; to correctly interpret the system's output using the tools and methods available; to decide, in any given case, not to use the system or to disregard, override or reverse what it produces; and to intervene in its operation or halt it through a stop mechanism or equivalent.

The evidence a firm needs here is not a policy stating that a human reviews every application. It is proof that the reviewer's interface actually surfaces enough information to interpret the score, that override is a real and used option rather than a formality, and that the firm monitors for the specific failure mode Article 14 names: staff who technically have override authority but stop exercising independent judgement once a model has been in production for a while. An override rate that never moves is itself a signal worth investigating, not evidence the model has become reliable enough to stop checking.

Article 15: accuracy, robustness and cybersecurity evidence

Article 15^[11] requires an appropriate level of accuracy, robustness and cybersecurity, maintained consistently across the system's lifecycle rather than demonstrated once at launch. Three obligations do the practical work. Accuracy metrics and levels have to be declared in the instructions for use, meaning published and available to a deployer, not held internally as a confidential benchmark. The system has to be resilient to errors, faults and inconsistencies, including through technical redundancy such as backup or fail-safe arrangements, and where a model continues learning after deployment, the design has to address feedback loops so that a biased output does not become a biased input for the next training cycle. That last point matters more for credit scoring than for most other Annex III categories, because periodic retraining on a lender's own historic decisions is common practice and is exactly the mechanism through which a feedback loop compounds.

Cybersecurity is treated as its own requirement rather than folded into general IT security policy. The Act names the specific attack types a high-risk system's defences have to address: data poisoning, where training data is manipulated; model poisoning, aimed at pre-trained components used in training; adversarial examples, meaning inputs crafted to cause a mistake; and confidentiality attacks against the model itself. A technical-documentation dossier that cites generic information-security policy without addressing these named categories has not answered the question Article 15 asks.

Article 11 and Annex IV: the technical-documentation dossier

Article 11^[12] requires the provider to draw up technical documentation before the system reaches the market and keep it up to date, in a form clear enough that a supervisory authority can assess compliance from it. Annex IV^[13] sets out what belongs in it, in roughly nine parts: a general description of the system, its intended purpose and how it is distributed; a detailed account of how it was developed, including design specifications, architecture, data and training information, and validation and test procedures; a description of the human-oversight measures built in; a record of the system's capabilities, known limitations and foreseeable risks; a justification for why the chosen performance metrics fit this particular system; the Article 9 risk-management summary; a log of changes made across the system's lifecycle; the harmonised standards applied, or a description of the alternative approach where none exist; a copy of the EU declaration of conformity; and the post-market monitoring plan.

Two details soften what otherwise reads as a substantial single-pass document. Article 11 requires the Commission to produce a simplified documentation form for small and micro enterprises and start-ups, which notified bodies have to accept during conformity assessment, so the burden is not identical for a two-person lending fintech and a large bank. And Annex IV is not frozen: the Commission can amend it by delegated act, so the list above is the current shape of the obligation rather than a permanent one. Neither detail reduces what has to exist by 2 December 2027; both affect how proportionate the exercise can be.

The documentation-burden timeline, mapped to December 2027

The detail that is easy to miss in the deadline coverage is that this is not a staggered rollout. The Omnibus amendment sets one date for Sections 1 through 3 of Chapter III together, which means classification, risk management, technical documentation, human oversight, accuracy and the provider and deployer obligations that sit alongside them all become enforceable for Annex III systems on the same day. There is no separate earlier sub-deadline for finishing the documentation dossier before the oversight design is ready. The table below sets out the full sequence, including the milestones that have already passed.

Methodology: CloudFintech mapped each requirement to its governing article or annex using the consolidated EU AI Act (Regulation (EU) 2024/1689), the Digital Omnibus on AI (Regulation (EU) 2026/1744) and the European Commission's AI Act Service Desk. This is an editorial reference for structuring a compliance programme, not legal advice, and it does not cover every provider or deployer duty in the Regulation.

Primary sources: EU AI Act (Regulation (EU) 2024/1689); Digital Omnibus on AI (Regulation (EU) 2026/1744); European Commission AI Act Service Desk

Download underlying dataset

The table above shows when. The downloadable checklist turns that into what: six obligations, the article or annex behind each, and the concrete artefact a supervisor could ask to see. Treat both as an editorial reference for planning a compliance programme, not as a substitute for legal advice specific to a firm's own system and jurisdiction.

Preparing before the deadline

Sixteen months sounds generous until the work is broken down. A risk-management file that has to be tested and iterated, a technical-documentation dossier that has to be kept current rather than written once, and a human-oversight interface that has to be built and then evidenced in use are not tasks that compress well into the final quarter. The standards a provider will eventually test against are still emerging, but building the risk file, the documentation structure and the oversight design against the text of Articles 9, 14 and 15 directly does not need to wait for a published standard to begin.

For firms already working through faster AI-driven underwriting, the practical order of operations is to start with classification. Confirm in writing whether a system falls under Annex III point 5(b), whether any Article 6(3) derogation genuinely applies, and only then size the Article 9, 11, 14 and 15 work against a confirmed scope. For the wider picture of where AI is deployed across a bank and which of those deployments carry this kind of regulatory weight, see CloudFintech's map of AI in financial services.