Adapted from the Polish article, originally published on 12 May 2026. The English version was published on 01 October 2026.
A team uses AI to organise correspondence and prepare summaries. Later, HR asks whether the same setup could filter CVs and rank candidates. The technical step may look small, but the system now helps decide who gets access to a job.
The EU AI Act looks at the system’s intended purpose and the way it affects people, as well as the technology. A new use case can change the legal assessment and, in some circumstances, the organisation’s role. That is a question to answer before the recruitment workflow reaches production.
The Polish article grew out of a discussion about organisational AI deployment at an IT Cluster breakfast. Its central point remains useful for an international team: implementing AI changes a business process, with consequences for data, responsibility and governance. For a business operating in Poland, the AI Act is an EU regulation; Polish employment and data protection requirements need their own assessment alongside it.
What you will learn
- Why the use case matters as much as the chosen model.
- How recruitment can bring a system into a high-risk category.
- How deployer and provider responsibilities differ.
- Why changing intended purpose can affect your role.
- What to document before moving an AI workflow into production.
In brief
- An AI tool approved for one process is not automatically approved for another.
- Filtering applications and evaluating candidates are uses specifically addressed by the AI Act’s high-risk framework.
- An organisation that changes the intended purpose may become a provider under the conditions in Article 25.
- Not every adaptation or experiment makes a system high-risk or turns its user into a provider.
- A useful governance checkpoint identifies the purpose, data, influence on people and owner of the decision.
Start with the use case
Choosing a model is only part of the deployment decision. Describe the process: what the system does, what data it receives, who uses the output and which decisions it influences.
The same underlying technology can support routine office work or be part of a decision affecting employment. An existing GDPR review, procurement approval or security assessment does not automatically cover the new purpose. Review the changes in the process and the safeguards it needs.
A practical assessment should keep the AI system, the underlying model and the organisation’s activity distinct. The fact that a third party supplies a general-purpose model does not settle who is responsible for a new system built around it.
A hypothetical case: from email summaries to candidate rankings
This example is illustrative, not a client history. A company has introduced an AI tool for correspondence. It has assessed data use, trained the team and documented the approved workflow. It considers itself a deployer using a vendor’s system.
Applications arrive faster than HR can review them. The team adapts the workflow using past recruitment data, previous decisions and selection criteria. It now filters CVs, removes applications and ranks candidates for further review.
The questions have changed. The tool is no longer simply organising an inbox. It affects how people are evaluated for work, and its outputs may influence whether a person is considered at all.
Annex III of the AI Act identifies recruitment and selection uses, including analysing and filtering applications and evaluating candidates. The classification must also be assessed under Article 6, including its conditions and exceptions. A human appearing somewhere in the process does not by itself resolve that assessment.
A change in intended purpose deserves a new assessment even if the model, interface and vendor are familiar.
What is the difference between a deployer and a provider?
In simplified terms, a deployer uses an AI system under its authority. A provider develops a system, or has it developed, and places it on the market or puts it into service under its name or trademark. The legal definitions and the actual activity matter more than the label in a procurement spreadsheet.
A deployer generally has a narrower set of responsibilities than a provider, but that does not mean it has none. For high-risk systems, both roles have duties appropriate to their position. GDPR, employment rules and the organisation’s own contractual obligations can also apply.
The provider’s responsibilities cover the system and its conformity framework. A team that begins modifying a system or constructing a new application cannot rely solely on the vendor’s assessment of the original use.
When can the organisation’s role change?
Article 25 of the AI Act addresses responsibilities along the value chain. Among its scenarios are rebranding an existing high-risk system, substantially modifying it while it remains high-risk, and changing the intended purpose of a previously non-high-risk system so that it becomes high-risk under Article 6.
The recruitment scenario calls for checking those conditions, rather than assuming a role change just because the team has adjusted a prompt or used historical data. What has been changed, who supplies the resulting system and how it is put into service are all relevant.
A change from inbox administration to candidate filtering is significant because the new purpose can fall within the employment category. Clarify the actual arrangement with the vendor, the technical documentation available and who is responsible for the resulting system.
What might need to change operationally?
Depending on classification and role, the work can involve risk management, technical documentation, instructions, logs, monitoring, human oversight and the allocation of responsibility for decisions.
Document how HR uses the output. Does a ranking determine which applications are read? Can staff identify and challenge an unreliable result? Is there a process for reviewing the system when selection criteria or input data change?
These questions help connect legal obligations with the actual operation. A policy saying “a human remains responsible” does not show how that person obtains the information and authority needed to supervise the process.
Build the checkpoint into deployment
Compliance by design means considering the legal and operational requirements while the workflow is being designed. A proportionate checkpoint can be brief: purpose, affected people, data, system changes, classification, roles and the person approving the next step.
In the hypothetical recruitment case, the change should trigger a review before the company starts filtering real applications. Procurement, HR, security, data protection and the technical team each hold information needed to make that review useful.
The result may be approval with controls, a narrower use case, more vendor information or a decision not to deploy that particular workflow. Keep the reasons and the conditions in the project record so that the next change can be assessed against them.
Questions to answer before production
- What exactly will the system do, and in which process?
- Will it affect applicants, employees, customers or other people?
- Does it assist a person or filter, evaluate or recommend a decision?
- Has the intended purpose changed?
- Have we modified the system or built a new application around a model?
- What is our role, and which vendor responsibilities can we demonstrate?
- Who owns the process, the data, supervision and the final decision?
- What evidence explains the classification, risks and controls?
- What change will trigger another assessment?
Make responsibility visible
Begin with an inventory of AI use cases, named process owners, an assessment of classification and roles, and a record of data use and supervision. A small organisation may not need an elaborate governance programme, but it should know where AI influences people and who answers for the workflow.
If you are introducing AI in HR, customer service, document analysis or decision automation in Poland, our technology and AI legal services can help assess the use case and turn the findings into documents and deployment decisions. Discuss your planned use with us.
Sources and further reading
- AI Act, Article 6: classification of high-risk systems.
- AI Act, Annex III: high-risk uses, including recruitment.
- AI Act, Article 25: responsibilities along the value chain.
- Klaster IT, the Polish technology cluster whose discussion prompted the original article.