The high-risk provider who owes nothing to the DSA
fictional demo profile
TalentSync Solutions GmbH screens CVs for HR departments. That single product line puts it in the high-risk band of the AI Act and squarely inside the GDPR — and leaves an entire regime untouched.
- AI Act · provider · Annex III
- GDPR · Art. 22 + Art. 9
- 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.
A screening model, sold to HR departments
TalentSync Solutions GmbH (fictional demo profile) builds recruiting AI: CV screening and candidate matching, licensed to the HR departments of larger employers. It is a mid-stage startup established in Munich, so it sits inside the Union and cannot be reached through the third-country route. In the vocabulary of the AI Act it is a provider — it develops the system and places it on the market under its own name — while its customers are the deployers. Screening and selecting natural persons for employment is one of the listed use cases in Annex III, which puts the product in the high-risk band rather than the transparency band.
The same product is a personal-data engine. It profiles applicants, and its output feeds pre-selection decisions that have real effects on people who never chose to be scored. Health signals, gaps in a CV or language proxies can pull special categories into a dataset that was never meant to hold them. Two regimes therefore meet inside one codebase, and neither of them is optional. The demo profile answers the pre-wizard accordingly: provider, EU establishment, high-risk Annex III system, personal data yes, Art. 9 status unsure, Art. 22 status unsure.
Two regimes on, one regime off
The suite activates the AI Act provider track and the GDPR. It does not activate the DSA — TalentSync operates no intermediary service, so that profile stays empty and no DSA obligations, packages or deliverables are offered. It also does not open the GPAI track: an Annex III high-risk system is not a general-purpose model, and conflating the two is the classic mis-sale. The fundamental-rights impact assessment under Art. 27 stays out of the provider's list as well, because it addresses certain deployers, not the developer.
Central articles for this profile
| Article | Duty in short | Why for this profile |
|---|---|---|
| AI Act · Annex III (4) | Employment, worker management and access to self-employment | CV screening and candidate selection is the listed use case that triggers the high-risk classification in the first place. |
| AI Act · Art. 9 | Risk management system across the whole lifecycle | Not a one-off document: the risks of a screening model change with every retraining round. |
| AI Act · Art. 10 | Data and data governance for training, validation and testing sets, including examination for bias | The bias question that every HR buyer asks lives here, not in a marketing claim. |
| AI Act · Art. 11 + Annex IV | Technical documentation drawn up before the system is placed on the market | A provider duty. Customers cannot produce it, and asking them to is a red flag in due diligence. |
| AI Act · Art. 12 | Automatic recording of events over the lifetime of the system | Without logs, a contested screening run cannot be reconstructed after the fact. |
| AI Act · Art. 13 | Transparency and instructions for use towards deployers | The HR customer can only meet its own duties if the instructions actually carry them. |
| AI Act · Art. 14 | Human oversight designed into the system | A recruiter must be able to override the ranking, not merely confirm it. |
| AI Act · Art. 15 | Accuracy, robustness and cybersecurity | Declared performance levels become a legal commitment, not a datasheet. |
| AI Act · Art. 17 | Quality management system | The organisational spine that carries the other provider duties in a growing startup. |
| AI Act · Art. 43 | Conformity assessment before market placement | The gate a high-risk product has to pass; it needs a plan, not a sprint. |
| AI Act · Art. 47 · 48 | EU declaration of conformity and CE marking | The visible output of the assessment — and the part procurement departments ask for. |
| AI Act · Art. 49 | Registration in the EU database before placing on the market | A high-risk Annex III system becomes publicly traceable to its provider. |
| AI Act · Art. 72 · 73 | Post-market monitoring plan and reporting of serious incidents | Duties that start after launch, which is exactly when startup attention drops. |
| GDPR · Art. 22 | Automated individual decision-making, including profiling | The pre-selection question: how automated is a ranking before it becomes a decision? |
| GDPR · Art. 9 | Special categories of personal data | Health or belief signals can arrive through proxies nobody deliberately collected. |
| GDPR · Art. 35 · 36 | Data protection impact assessment and prior consultation | Systematic evaluation of personal aspects at scale is the textbook DPIA trigger. |
| GDPR · Art. 28 | Processor duties and data-processing agreements | One agreement per HR customer — at volume this becomes a contract-management problem. |
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 Art. 22 AI Act
Same number, different norm. Art. 22 GDPR governs automated individual decisions; Art. 22 AI Act governs the authorised representative of a provider established outside the Union. The map keeps them as separate anchors with no edge between them — a false friend that is deliberately not drawn as an overlap. For an HR provider whose whole compliance conversation revolves around "Article 22", that distinction saves an entire wrong workstream.
-
The FRIA is not the provider's homework
Art. 27 AI Act — the fundamental-rights impact assessment — is a duty of certain deployers, not of the developer. For this profile it does not fire, and the suite leaves it out of the obligation set instead of padding the list. The GDPR impact assessment under Art. 35, by contrast, does concern the provider's own processing. Two impact assessments, two addressees, two legal bases: mixing them is a common and expensive mistake.
-
Testing for bias means touching sensitive data
The AI Act expects providers of high-risk systems to examine their datasets for bias; doing that properly can require the very special categories that Art. 9 GDPR restricts. The AI Act contemplates such processing under strict conditions, but it does not switch off the GDPR. This is a genuine seam between the two regimes, and it is the point where a data-protection view and an AI-governance view have to be taken together rather than in sequence.
-
The employment-law flank sits outside EU digital law
In an HR fact pattern German employment law runs alongside: employee data protection, works-constitution rules on selection guidelines, and equal-treatment law. The map names that flank as context so it is not forgotten, but it is national law and not part of the EU digital-law corpus. Whether it bites — and how — is a legal assessment for the firm, not an output of the software.
From a five-question profile to a working list
Obligation cockpit
The provider set, filtered by role and risk tier: the Chapter III duties on risk management, data governance, documentation, logging, transparency, oversight and robustness, plus the quality-management, conformity-assessment, marking, registration and post-market strands. Duties that belong to deployers stay out. Each entry carries its source node, so the list can be read back to the norm text rather than trusted on faith.
Annex IV cockpit and sub-cockpits
The technical documentation is broken into task lists instead of prose: the risk-management file under Art. 9 and Art. 11, the logging design under Art. 12, the instructions for use under Art. 13, the oversight measures under Art. 14. What exists, what is missing, what is still an assumption.
Cross-regulation view
The seams between the AI Act and the GDPR as explicit connections — and, just as importantly, the false friends that are shown as separated rather than linked. The Art. 22 pair is one of the curated walk-throughs.
Radar watch
Change entries tagged to the profile rather than a general newsfeed: movement in the high-risk timetable, and proposals touching bias detection with sensitive data. The radar reports the state of the watchlist with its date; it does not claim to be a live feed.
Deliverables — and the DRAFT rule
The suite can generate a classification memo, an obligation register, a gap report and an outline for the Annex IV documentation. 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 the classification holds, how far the conformity assessment has to go, what the instructions for use must say, whether a ranking is already an automated decision. Regingada UG (haftungsbeschränkt) builds the software and takes on appointed EU-representative functions; 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.