Level 4 · The framing — two regimes in finance

§1 — One system, two regimes (finance)

Level 3 was your first overlay; this is your second — and the contrast is the point. In retina, one fact (“this is a medical device”) did both jobs: it made the system AI Act high-risk via Art. 6(1) and it made it an MDR device. The two regimes were coupled by the same fact.

Here the two regimes are orthogonal layers on the same asset. The system is high-risk for one reason — it scores the creditworthiness of natural persons, which is Annex III §5(b) (the use route). DORA stacks on for an entirely separate reason — the operator is a financial entity (a credit institution), so the model becomes an ICT asset the entity must manage for operational resilience. A credit-scoring model run by a non-financial business would still be AI Act high-risk under §5(b) but would carry no DORA. The AI-Act layer and the DORA layer are independent: same system, two regimes that happen to coincide.

More than the AI ActOne system, N regimes: the AI Act spine plus a sectoral regime stacked on top. The same signed bundle projects onto multiple catalogs — governed standards get real verdicts, DORA gets a signed crosswalk and a Register deliverable, NOT a verdict.

§2 — Which laws apply (and what each one governs)

Be precise about scope — honesty cuts both ways.

EU AI Act — high-risk, via Annex III §5(b). Nerea declares tier: high via the classify-system portal mission, with the basis spelled out in froga.yaml: “EU AI Act Annex III §5(b) (creditworthiness evaluation / credit scoring)”. That pulls the Articles 9–15 spine into scope. This is the use route, contrasting Level 3’s Art. 6(1) product route.
DORA (Reg. EU 2022/2554) — finance overlay. Declared in applicable_standards as eu/dora@2022, with a dora.entity block (LEI, legal name, country, entity type) because the operator is a credit institution. This is the overlay. But — and this is the crux of the level — DORA governs the model as an ICT asset, not as a governed AI-risk-management standard. The engine treats it differently from the spine’s standards: it does not print a DORA conformity verdict. The DORA deliverable is a signed Register of Information (§5). Never say “DORA gobernada”.

THE RED LINE — DORA is ICT operational resilience, NOT model governance

This is the GTM red line of the whole finance overlay, and it is worth saying flatly: DORA does not “govern” the model’s fairness, accuracy, or risk treatment — that is the AI Act’s job. DORA governs the model’s operational resilience as an ICT asset: that the entity has an ICT risk framework, that it keeps a Register of its ICT services and third-party providers, that it can detect and report ICT incidents, that it tests its resilience. So the engine’s DORA output is documentation — a signed Register + a cross-map of where the AI-Act evidence touches DORA’s expectations — and never a statement that the system “is DORA-conformant”. Saying a credit model is “DORA gobernada” because it carries this Register is precisely the over-claim this course refuses. The conformity verdict on the fairness of the model is the AI Act / ISO 23894 verdict, and in this demo that verdict closes GREEN after treatment (measured with real power, OOF over all 1,000 rows).

The scope frontier — what is and is not in scope here:

IN scope (what the engine emits): the per-system slice of DORA — the entity identification and the ICT-function description for this credit model — projected from the signed bundle into the Register of Information (xBRL-OIM), plus the cross-map onto DORA’s ICT-risk clauses. That is the deliverable a compliance officer can hand to a supervisor.
OUT of scope (DORA obligations the engine does not, and cannot, supply): threat-led penetration testing (TLPT), ICT-incident classification and reporting, concentration-risk and exit-strategy analysis, and the entity-wide ICT resilience programme. Those are organisational and operational duties of the financial entity, not properties of a per-system signed bundle. The engine takes you up to the per-system register entry and the cross-map, and honestly stops at the entity-wide resilience programme.

DORA — digital operational resilience of the AI modelThe reference page for the DORA overlay: how the engine projects the per-system slice of DORA onto the signed bundle as a Register of Information (xBRL-OIM) + crosswalk — a deliverable, not a verdict — and the honest gaps (TLPT, incident reporting, concentration risk) it leaves to the entity.