At the end of September, the Spanish Data Protection Agency (AEPD), Spain's GDPR regulator, published a warning to a company that was preparing a tool to assess job applicants. The idea was fairly simple: analyse CVs, give each one a score and use that score to prioritise people in hiring and internal mobility processes.
The tool had not gone live yet. The company had told its staff that it planned to use it, and the AEPD stepped in before it did.
I find the case interesting because it shows two different problems inside the same application. One is the processing of personal data about people looking for a job. The other is the responsibility you take on when you decide what an AI system will be used for.
There is a question worth asking from the start: what happens if your own team builds that tool on top of a third-party API?
You don't need to train a model to end up as the provider of a high-risk system. In some cases, it is enough to build an application, give it a specific purpose and put it into service under your name. Article 25 of the AI Act adds further cases for those who start from systems that already existed.
What the AEPD told the company
The warning published on 23 September 2026 stresses four points that should be settled before a tool like this goes into use:
- Data protection by design. It has to be considered when the project is planned, not once it is already running.
- Risk assessment and, where required, a data protection impact assessment (DPIA). If the processing is likely to result in a high risk to people, it has to be assessed before it starts.
- Transparency. Applicants and employees need to understand that a tool is being used to assess them and what role their score plays.
- Effective human oversight. The company had said the final decision would be made by a person. The AEPD pointed out that this person must be able to question the result and decide on their own judgement. Signing off the machine's recommendation by default does not count.
One thing is worth clarifying: a warning is not a fine. It is a preventive measure. The regulator is pointing out risks before the planned processing takes place.
Two assessments with similar names also come up here, and they are easy to confuse. The DPIA comes from the GDPR and analyses the risks of processing personal data. The FRIA, the fundamental rights impact assessment in Article 27 of the AI Act, looks at the impact of certain uses of high-risk systems on fundamental rights.
Not every company that uses one of those systems has to carry out a FRIA. Within the nuances of Article 27, it applies to certain deployers, such as public bodies, private entities providing public services and some uses in creditworthiness and insurance. A private company screening CVs for its own hiring does not have to carry out a FRIA for that reason alone. Its GDPR obligations still apply.
The CV travels inside the prompt
When we think about an impact assessment, it is easy to focus on what the application does. There is another part that matters just as much: what happens to the information we send to the model.
Imagine the tool sends the full CV with every request. That can include the name, date of birth, photo, career history and other personal data. If the application is used for internal mobility, it can also carry information about people who already work at the company.
That is where the questions every engineering team should ask before deploying start. What data does the model actually need? Who processes the requests? Where does inference run? Are there additional sub-processors? Are prompts and responses stored? For how long?
Architecture has a lot to do with the answers. You can run a model on European infrastructure under contractual terms that exclude retaining the content, or call an API that processes data in other countries and keeps part of the requests. Each setup means reviewing its safeguards, the processors involved and, where relevant, international transfers.
Controlling the infrastructure does not settle every design decision either. If you send a photo or a date of birth that you don't need to assess an application, the problem starts before the API call is made.
Cutting that data down limits the exposure of personal information and can remove some signals that would introduce bias into the assessment. On its own, it does not guarantee that the system stops discriminating: the model can infer sensitive characteristics from other data.
What the assessment doesn't need stays out of the request. Minimisation reduces exposure, but it does not remove the risk of bias.
You also need to tell apart the inference provider's retention and your own application's traceability. An API that does not keep request content can be a good safeguard. Your system will still need the right logs and evidence, with limited access and justified retention periods, to explain how it worked and which decisions were made.
How a prompt can change your obligations
Back to the CV example.
Imagine the engineering team builds an application on top of a general-purpose model. In the system instructions it writes something like this:
You are a recruitment assistant. Read the attached CV, score its fit with the job opening from 1 to 10 and reject applications scoring below 5.
You haven't trained a model or changed its weights. You may have written only a few lines of code.
Even so, you have built an application that assesses and filters job applicants. Annex III of the AI Act explicitly lists those employment uses among high-risk systems, subject to the exceptions and conditions in Article 6.
The model belongs to a third party; your prompt sets the purpose. If the application assesses and filters applicants, it falls under Annex III and you are its provider.
What stands out is that much of the system's purpose can sit in instructions written in natural language. In traditional applications, that logic was spread across code, data and business rules. With general-purpose models, a text file can change an application's behaviour considerably.
That is why prompts that govern sensitive functions deserve the same care as the rest of the software: review them, version them, test them and document their changes.
If you develop that application and place it on the market or put it into service under your name, you can be its provider from the start, under the AI Act's general definition. If you start from a tool that already existed and change how it is used, Article 25 comes into play as well.
The three cases in Article 25
Article 25 sets out when a distributor, importer, deployer or other third party is considered the provider of a high-risk AI system. It covers three cases.
The three cases in Article 25 where you become the provider of a high-risk system.
1. You put your name or trademark on a high-risk system
You start from a high-risk system that has already been placed on the market or put into service and present it under your brand. The regulation provides that you can take on the provider role even if you haven't changed how it works, without prejudice to the contractual arrangements it allows for.
2. You substantially modify a high-risk system
You make relevant changes to a system that was already high-risk and remains so after the modification.
That can mean changes to the architecture, the decision logic or the training. But fine-tuning or editing a prompt is not automatically a substantial modification. You have to look at the scope of the change, what the original conformity assessment anticipated and how the change affects compliance or the system's purpose.
3. You change a system's purpose and make it high-risk
This is probably the easiest case to miss.
You take a tool that was not considered high-risk, including a general-purpose AI system already on the market or in service, and change its purpose so it is used in an activity that does fall into that category.
An application that answers questions about documents can end up being used to rank candidates or assess people's creditworthiness. At that point it is worth checking whether the new use changes its classification and who takes on the provider's obligations.
There is an important nuance: using a general-purpose model as a component of a new application is not automatically the change-of-purpose case in Article 25. First you have to identify which system has been developed, who offers it or puts it into service and what its intended purpose is.
So is every AI application high-risk?
Of course not.
Summarising internal documentation, drafting emails, helping with code or answering questions over a knowledge base does not automatically make an application a high-risk system. You have to look at its purpose and how it actually works.
Nor are you necessarily a provider because your company buys a screening tool and uses it according to the vendor's instructions. In principle you would be acting as a deployer, with the obligations that come with that role. That changes if you transform the tool or one of the Article 25 cases applies.
Article 6(3) also provides some exceptions for systems initially listed in Annex III. For example, narrow procedural tasks, certain preparatory tasks, or systems that detect patterns without replacing or materially influencing human assessment, provided the regulation's conditions are met.
Consider two instructions:
Summarise this CV so that a person can review it.
Score the CV and reject anyone below five.
The first one could fit an exception if it really is limited to a preparatory task and meets the other requirements. The second one directly takes part in assessing and rejecting people, so it cannot be treated as a simple administrative summary.
In addition, when a system profiles natural persons in the sense the regulation uses, Article 6(3) does not allow those exceptions. If a provider considers its system exempt, it has to justify and document that before placing it on the market or putting it into service, and meet the applicable registration obligations.
What you call the tool matters far less than what it does when someone uses it.
What happens to the original provider
Article 25 also deals with the relationship between the initial provider and whoever takes on that role after transforming the system.
When one of its cases applies, the original provider is no longer considered the provider of that specific system for the purposes of the article. That does not remove other obligations it may have, for example in relation to a general-purpose model.
The regulation expects it to cooperate with the new provider and to make certain information, technical documentation and access for testing available, under the corresponding conditions and exceptions.
One exception is especially relevant: if the original provider had clearly stated that its system was not to be changed into a high-risk system, it may be excluded from that cooperation obligation.
This changes the conversation with a vendor quite a bit. If you are going to build a regulated application on someone else's technology, you should check from the start which uses it allows, what safeguards it offers and what documentation it can give you.
Finding out you need those materials once the product is already running is a bad way to start.
What obligations you take on as a provider
When the high-risk regime applies, the requirements go well beyond publishing a privacy policy.
Article 16 of the AI Act , together with the other applicable provisions, sets obligations on risk management, data governance, technical documentation, record-keeping, instructions for use, human oversight, accuracy, robustness, cybersecurity, quality management and conformity assessment. Depending on the case, CE marking and the registrations the regulation requires also apply.
Much of that work comes down to being able to explain how the system behaves, which risks have been identified and which mechanisms exist to detect and correct them.
For many Annex III systems, conformity assessment is based on internal control, without an external body having to certify each application. That doesn't mean declaring that everything is fine is enough: the applicable requirements have to be met and documented.
In October 2026, the reference to the harmonised standard EN 18286:2026 was published in the Official Journal of the EU. It covers the quality management systems required by Article 17. Applying it can give a presumption of conformity for the requirements it covers, but it is not a general certification of compliance with the whole AI Act.
The deadlines have moved, but some obligations already apply
Regulation (EU) 2026/1744, known as the Digital Omnibus on AI, delayed some high-risk obligations:
- 2 December 2027: systems classified under Article 6(2) and Annex III, such as many employment uses.
- 2 August 2028: systems classified under Article 6(1) and Annex I.
These are the dates for the corresponding sections of Chapter III. They don't mean any application can be used without controls until then.
In recruitment, the GDPR already applies, including its obligations on transparency, data protection by design, impact assessments where required and the safeguards against certain solely automated decisions.
Employment law adds its own obligations, and they depend on the country. In Spain, the case in this article, Article 64.4.d of the Workers' Statute gives employee representatives the right to be informed about the parameters, rules and instructions of algorithms that affect employment decisions. And since 5 October 2026, Royal Decree 723/2026 requires employers to inform workers in writing that algorithmic or automated decision-making systems are in use and, in the cases it covers, about their criteria and operating rules. If you operate in another EU country, check the equivalent rules there.
High-risk obligations arrive in 2027 and 2028. Data protection and worker information obligations already apply.
So waiting until 2027 to start documenting these tools would be a mistake.
Take a very concrete situation. A year from now, someone asks you why an application was rejected. Can you recover which model version was used? What instructions did the application have? What data did it receive and what human intervention was there?
If you work with an open-weight model, you can pin and document a specific version of the weights and the deployed configuration. That makes control easier, although reproducing an output exactly also depends on the runtime environment and the inference parameters. With a third-party API, you will need to check what versioning guarantees the provider offers and how it announces changes.
In both cases, logging and justifying decisions remains the responsibility of whoever operates the system, within the limits and obligations that apply to them.
Five things I would check before deploying an application like this
- Document the purpose. Write down clearly what each system will be used for and which decisions it can influence. If someone proposes a new use, assess it again.
- Version the model and the instructions. Keep the relevant versions of prompts, models, configurations and changes. Treat sensitive changes as software changes that need review.
- Review what data you send. Minimise the information, check who processes the requests, where they run and what the retention and security terms are.
- Check the vendor's terms. Review the permitted uses and what documentation, technical support and guarantees they can provide when the system is subject to additional obligations.
- Record the classification and the decisions. If you believe a summarisation task is preparatory and can rely on Article 6(3), document why, verify that the actual behaviour matches that description and check whether there is profiling.
These questions should be part of product design. Answering them once people have been affected and decisions have been made usually costs a lot more.
I think the AEPD case is a useful warning for anyone building applications on third-party models. Adding an AI feature to a product is now so easy that it is tempting to skip some awkward questions. It is better to ask them early: what data it uses, which decisions it influences, who answers for how it works and what we will be able to show if something goes wrong.
Infrastructure can help you control processing, retention and model versions. The purpose you give the application, and its consequences for people, need the same level of attention.
Sources and further reading
- AEPD: press releases, including the 23 September 2026 warning on CV analysis (the warning itself is in Spanish).
- AI Act: consolidated text of Regulation (EU) 2024/1689 , especially Articles 3, 6, 16, 17, 25 and 27 and Annexes III and IV.
- Regulation (EU) 2026/1744: changes to the AI Act deadlines .
- European Commission: first harmonised standard supporting the AI Act (EN 18286:2026) .
- Spain's Royal Decree 723/2026 on worker information (in Spanish).
- GDPR , especially Articles 22, 25 and 35.
This article is for general information only and does not constitute legal advice.
