A number that decides — and three different Article 22s
fictional demo profile
BonitätsCheck FinTech sells creditworthiness scores to banks. That puts it in the high-risk band of the AI Act and at the centre of the sharpest data-protection question in EU law: when does producing a score become making a decision?
- AI Act · provider · high-risk
- GDPR · Art. 22 + case law
- DSA · not activated
Model case study. This scenario is built on a fictional demo persona that ships with the Regingada Compliance Suite — not a real client, not a real company. Any similarity to existing companies is coincidental. It shows how the suite maps a profile of this shape to EU digital law. No legal advice.
Scoring as a service, sold to banks
BonitätsCheck FinTech GmbH (fictional demo profile) runs creditworthiness scoring as a service from Frankfurt and sells it business-to-business to bank customers. It develops the model and places it on the market under its own name, so under the AI Act it is a provider; its bank customers are the deployers. Evaluating the creditworthiness of natural persons is one of the listed use cases in Annex III, in the category of access to essential private and public services — which puts the product in the high-risk band.
The data-protection side is not a parallel problem, it is the same problem seen from a different angle. A score derived from personal data and used to grant or refuse credit is the textbook case of an automated individual decision, and European case law has already worked through exactly this constellation. Special categories are a live risk too, not because anyone collects them, but because proxies can reconstruct them. The demo profile answers: provider, EU establishment, high-risk Annex III system, personal data yes, automated decisions yes, special categories unsure. No intermediary service, so the DSA profile stays empty.
High-risk provider duties, plus the Article 22 core
The suite activates the AI Act provider track and the GDPR — and in the GDPR it reaches further than the baseline, because the profile explicitly answers yes to automated decisions. It does not activate the DSA; a scoring API is not an intermediary service. The high-risk classification is reached through the Annex III category on access to essential private and public services, which is where creditworthiness evaluation is listed — the map shows that route rather than asserting a conclusion.
Central articles for this profile
| Article | Duty in short | Why for this profile |
|---|---|---|
| AI Act · Art. 6 + Annex III (5) | Classification rules and the listed use case on access to essential private and public services | The route by which creditworthiness scoring lands in the high-risk band — worth reading before assuming it does not. |
| AI Act · Art. 9 | Risk management system across the lifecycle | A scoring model is retrained against shifting portfolios; the risk file has to move with it. |
| AI Act · Art. 10 | Data governance and examination for possible biases | Proxy variables are the central technical risk of credit scoring, and this is where they have to be looked at. |
| AI Act · Art. 11 + Annex IV | Technical documentation before placing on the market | Bank customers under supervisory pressure will ask for it, and it cannot be produced retroactively. |
| AI Act · Art. 12 | Automatic recording of events | A contested score has to be reconstructable, including the model version that produced it. |
| AI Act · Art. 13 | Transparency and instructions for use towards deployers | The banks can only exercise their own oversight duties on the basis of what the instructions tell them. |
| AI Act · Art. 14 | Human oversight built into the system | Sounds like the human-intervention right in the GDPR and is a different duty — see the collision points. |
| AI Act · Art. 15 · 17 | Accuracy, robustness and cybersecurity; quality management system | Declared discrimination and stability metrics become commitments rather than slides. |
| AI Act · Art. 43 · 47 · 48 · 49 | Conformity assessment, declaration of conformity, CE marking, registration | The market-access chain for a high-risk product, with a lead time that has to be planned into the roadmap. |
| AI Act · Art. 72 · 73 | Post-market monitoring and reporting of serious incidents | Model drift in a credit portfolio is a monitoring question long before it becomes an incident. |
| GDPR · Art. 22 | Prohibition in principle of decisions based solely on automated processing, with exceptions and safeguards | The centre of gravity of the whole case — and the article the case law has already applied to scoring. |
| GDPR · Art. 15(1)(h) | Meaningful information about the logic involved, and the significance and consequences | The access request that turns model documentation into an external-facing obligation. |
| GDPR · Recital 71 | Interpretive anchor for profiling, safeguards and non-discrimination | Names credit scoring explicitly and shapes how Art. 22 is read. |
| CJEU · C-634/21 | SCHUFA: the establishment of a score can itself be an automated individual decision | Directly on this business model — the score provider cannot simply point at the bank. |
| CJEU · C-203/22 | Scope and limits of the information duty about the logic involved, against trade-secret claims | Sets the frame for how much of the model has to be explained, and to whom. |
| GDPR · Art. 9 | Special categories of personal data | Proxy correlations can reconstruct sensitive attributes that were never deliberately collected. |
| GDPR · Art. 35 | Data protection impact assessment | Systematic and extensive evaluation with legal or similarly significant effects is the named trigger. |
Articles are shown because a profile of this shape reaches them, not because a lawyer has found that they apply to you. Which of them actually bite in a concrete company is an assessment — and that is a mandate.
Where the regimes rub against each other
-
Art. 22 GDPR is not a prohibited AI practice
This is the trap that costs credit-scoring providers the most time. Art. 22 GDPR is a data-protection rule about automated decisions, with exceptions and safeguards. The prohibitions on AI practices live in Art. 5 of the AI Act and are a different instrument entirely. And Art. 22 of the AI Act is neither: it concerns authorised representatives of third-country providers. In the map, the concept of prohibited AI practices sits exclusively on the AI Act Art. 5 nodes and on no GDPR node — the separation is built into the data, not just written in a footnote.
-
Who actually makes the decision?
The intuitive division of labour — "we produce a number, the bank decides" — has been tested in Luxembourg. In C-634/21 the Court held that establishing a score can itself amount to an automated individual decision where the third party draws strongly on that value in deciding on the contract. For this profile that turns an architectural assumption into a legal one: the safeguards under Art. 22(3) may attach to the score provider, not only to its customer. The map carries the judgment as its own node with links into Art. 22, the access right and Recital 71, so the reasoning can be followed rather than taken on trust.
-
Human oversight is not human intervention
Art. 14 AI Act obliges the provider to design a system that can be effectively overseen by people. Art. 22(3) GDPR gives the data subject a right to obtain human intervention from the controller. Two similar-sounding requirements with different addressees, different triggers and different tests: one is a design duty owed before market placement, the other a right exercised after a decision. Building a review button satisfies neither by itself, and the map keeps them apart on purpose.
-
Looking for bias means looking at sensitive data
The AI Act expects a high-risk provider to examine its datasets for bias. In credit scoring the realistic sources of bias are proxies — location, purchase history, name patterns — that can stand in for characteristics protected by Art. 9 GDPR. Examining them properly may mean processing exactly what the GDPR restricts. The AI Act contemplates that under narrow conditions; it does not switch the GDPR off. This is the seam where a data-protection view and a model-governance view have to be taken together.
The provider stack, and the case law that reads it
Obligation cockpit
The high-risk provider set, filtered by role and tier: risk management, data governance, documentation, logging, transparency, oversight, robustness and quality management, followed by conformity assessment, marking, registration and the post-market strand. Deployer duties — the ones the bank customers owe — are shown as the counterpart they are, not folded into your own list.
GDPR twin with the finance sector view
The processing register and the sector options bring the Art. 22 anchors up front for banking and creditworthiness assessment, with the impact assessment, the access right under Art. 15(1)(h) and the special-category question attached rather than buried.
Case law as part of the map
C-634/21 and C-203/22 are nodes in the corpus, connected by interpretation edges into the articles they read — Art. 22 and its paragraphs, the access right, Recital 71 — and cross-linked into the AI Act layer. Judgments are not a separate newsletter; they sit where the article sits.
Cross-regulation view and radar
The Article 22 separations and the oversight-versus-intervention seam as curated walk-throughs. The radar carries change entries tagged to the profile and reports the state of its watchlist with a date; it does not claim to be a live feed.
Deliverables — and the DRAFT rule
The suite can generate a classification memo on the high-risk route, an obligation register, an Art. 22 analysis outline with the case-law anchors, an Annex IV documentation outline and a gap report. Everything it produces is marked DRAFT. A DRAFT carries no signature, no assessment and no liability; it is a structured starting point. It becomes an assessment only when the law firm Theo Funk takes it into a mandate and signs it off. Package details and prices are listed separately under pricing.
Where the software stops
Everything above is orientation: a map of what a profile of this shape reaches in EU digital law, drawn from a public corpus and readable back to its sources. It is structured self-assessment and decision support — it is not an evaluation of a specific company, and it is not legal advice.
The assessment is the second step, and it belongs to the law firm Theo Funk under a separate mandate: whether a given score is already an automated decision within the meaning of Art. 22, how far the information about the logic must go against trade-secret interests, how responsibility is allocated between the scoring provider and the bank, and what the conformity assessment has to cover. Regingada UG (haftungsbeschränkt) builds the software; the firm does the legal work. The two are strictly separated, and that separation is the reason the tool can be as blunt as it is.
Other profiles: all five model cases. Packages: pricing.
Orientation, not legal advice
This model case and the suite provide orientation and information only. They are not legal advice. Individual-case advice is provided exclusively by the law firm Theo Funk under a separate mandate. Regingada UG (haftungsbeschränkt) — the software company and appointed EU representative — and the law firm are strictly separated.