You bought it, you did not build it — and that changes everything
fictional demo profile
A family firm uses an HR AI tool for pre-selection. The works council has raised concerns. The most valuable thing a compliance tool can do here is not to hand over a long list — it is to say which duties are yours and which belong to your vendor.
- AI Act · deployer · Art. 26
- GDPR · employment context
- no conformity assessment
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 family firm, a bought-in tool, an unhappy works council
Mueller Maschinenbau GmbH (fictional demo profile) is a third-generation family business in mechanical engineering, run by a managing director with a commercial rather than a technical background. The company introduced an HR AI tool for applicant pre-selection on the strength of a vendor pitch, without a compliance review beforehand. Then the works council raised concerns, and the question landed on a desk where nobody had planned for it.
The firm did not develop the tool; it uses one. In AI Act terms that makes it a deployer, not a provider, and that single word decides most of what follows. The use case — screening people for employment — is nevertheless in the high-risk band, so the deployer's own duty set is real rather than nominal. What this persona needs is an honest classification in plain language, a short list of what to do, and a clear statement of what the vendor owes. The demo profile answers: deployer, EU establishment, high-risk Annex III system in the employment field, personal data yes, special categories no, automated decisions unsure, no EU representative needed because the company is established in the Union. No intermediary service, so the DSA profile stays empty.
A short list — and a shorter one that is not yours
The suite activates the AI Act on the deployer side and the GDPR in the employment context. It does not open the conformity-assessment track, the CE-marking track or the Annex IV technical documentation: those belong to the provider of the system. It does not open the general-purpose model chapter, and it does not open the DSA. The interesting part of this profile is the subtraction, not the addition — a deployer who is handed a provider's duty list will either despair or ignore it, and both outcomes are worse than a correct short list.
Central articles for this profile
| Article | Duty in short | Why for this profile |
|---|---|---|
| AI Act · Art. 3 | Definitions of provider and deployer | The whole case hinges on which of the two you are — and buying under your own brand can change the answer. |
| AI Act · Annex III (4) | Employment, worker management and access to self-employment | Pre-selection of applicants is a listed use case, so the system is high-risk even though you only use it. |
| AI Act · Art. 4 | AI literacy of staff dealing with the system | Applies to deployers too, and is one of the few duties that can be met with training rather than documents. |
| AI Act · Art. 26 | Deployer duties: use according to the instructions, assign competent human oversight, ensure relevant input data, monitor operation, keep the logs, inform the provider and the authorities of serious incidents | This is the list. It is short, it is operational, and it is the one that was missing before the works council asked. |
| AI Act · Art. 26(7) | Inform workers' representatives and affected workers before putting a high-risk system into use at the workplace | The provision that speaks directly to the trigger of this case — and it is an information duty, on a schedule. |
| AI Act · Art. 27 | Fundamental-rights impact assessment — addressed to public bodies and certain listed services | Not applicable here. Shown as excluded, with the reason, rather than silently left out. |
| AI Act · Art. 43 · 47 · 48 + Annex IV | Conformity assessment, declaration of conformity, CE marking, technical documentation | Your vendor's duties, not yours. Useful as purchasing questions — not as your own project plan. |
| GDPR · Art. 35 | Data protection impact assessment | The employer is the controller for applicant data; systematic evaluation in an employment context is a named trigger. |
| GDPR · Art. 22 | Automated individual decision-making, including profiling | If the ranking is followed rather than reviewed, the question arises for the employer — regardless of who wrote the model. |
| GDPR · Art. 88 | Processing in the employment context under more specific national rules | The bridge from the GDPR into German employee data protection, which is where this fact pattern actually lives. |
| GDPR · Art. 13 · 14 | Information to applicants about the processing | The privacy notice in the application process has to reflect that a tool is involved. |
| GDPR · Art. 28 · 30 | Data-processing agreement with the vendor, and the record of processing activities | The two documents an authority asks for first — and the ones a purchase-driven rollout usually skips. |
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
-
Deployer is not provider
The heaviest duties in the AI Act — conformity assessment, declaration of conformity, CE marking, the Annex IV technical documentation — are addressed to whoever develops the system and puts it on the market. A company that buys and uses the tool owes something different and much shorter: Art. 26. Getting this wrong in either direction is expensive. Handed the provider list, a mid-sized firm starts a project it cannot finish; handed nothing, it misses the duties it really has. There is also a trap in the other direction: putting your own name on a bought system, or changing its intended purpose, can turn a deployer into a provider.
-
No fundamental-rights assessment, but probably a data-protection one
The fundamental-rights impact assessment under Art. 27 AI Act looks made for this situation and is not: it addresses bodies governed by public law and certain listed services, not a private manufacturer using employment AI. The suite leaves it out and says why. The data protection impact assessment under Art. 35 GDPR, by contrast, is a serious candidate here — the employer is the controller, and applicant screening is exactly the kind of systematic evaluation that triggers it. Two assessments that sound interchangeable, one of which is not owed and one of which probably is.
-
EU information duty meets German co-determination
Art. 26(7) AI Act requires workers' representatives to be informed before a high-risk system is put into use at the workplace. German works-constitution law has its own rules for selection guidelines and for technical systems capable of monitoring employees, and employee data protection adds a third layer. These are separate legal tracks: informing the works council under the AI Act does not settle a co-determination question, and a works agreement does not discharge the AI Act duty. The map names the national flank as context; whether and how it bites is an assessment for the firm, not an output of the software.
-
Responsibility follows the use, not the code
Under the GDPR the employer is the controller for applicant data even though the model came from outside. If HR follows the tool's ranking rather than genuinely reviewing it, the automated-decision question under Art. 22 arises for the employer. That is not something the vendor can absorb by contract, and it is the point where an operational habit — how carefully a recruiter actually looks — turns into a legal position.
Built for someone who is not a compliance department
A pre-wizard in plain language
Every term of art carries a tooltip — what a provider is, what a deployer is, what Annex III means, why the distinction matters — and every question has an honest escape: unsure, to be clarified in the mandate. The point is that a managing director can complete it without a translator, and that an unsure answer is recorded as unsure rather than guessed.
Role-aware obligation cockpit
The deployer set built around Art. 26 with its operational duties, together with the classification of the system as high-risk in the employment field. Provider duties are shown as the counterpart they are — visible, labelled, and outside your own list.
The vendor boundary as a working tool
Because the map keeps the two roles apart, the provider side becomes a purchasing instrument: instructions for use, technical documentation, declaration of conformity, logging capability, oversight design. Questions to ask before renewal — and the fastest way for a mid-sized company to find out how solid its vendor really is.
Cross-regulation view and radar
The seams that matter here: deployer versus provider, the impact-assessment pair, and the employment flank. 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 short classification memo, a deployer duty list, a supplier questionnaire drawn from the provider duties, an outline for the data protection impact assessment 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 for a case like this it is the more important one, because the sharpest questions are national and factual: how the works council has to be involved, whether an existing works agreement covers the tool, whether the pre-selection is already an automated decision, and what can still be renegotiated with the vendor. That work belongs to the law firm Theo Funk under a separate mandate. 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.