EU Regulations for Tech Hiring in Poland: 2026 Guide

When a company hires an engineer, data specialist or product professional in Poland, regulation tends to surface in very ordinary parts of the process: a sourced LinkedIn profile, notes in the ATS, an AI-generated ranking or a salary conversation.

Three EU frameworks sit behind those moments: the General Data Protection Regulation (GDPR), the EU AI Act and the Pay Transparency Directive. They are not at the same stage. GDPR has applied for years. Most of the AI Act is now applicable, but its high-risk rules for covered recruitment systems have been postponed. Poland has already introduced part of the Directive’s recruitment framework, while broader implementation remains unfinished.

So the useful question is not simply “Which regulation applies?” It is “What happens to a candidate from first contact to final decision?” Advertising an employment role, keeping someone in a talent pool and sourcing an independent contractor can raise different questions.

This article provides general information about recruitment operations and EU and Polish regulatory developments. It is not legal advice. Employers should obtain specialist advice for their specific circumstances where necessary.

The three EU regulatory areas tech employers should watch

In practical terms, four parts of the hiring process deserve the most attention: sourcing, candidate-data handling, AI-assisted screening and compensation discussions. The rest of this guide follows that workflow and separates today’s rules from those that apply later or still need broader Polish implementation.

GDPR still shapes the fundamentals of candidate-data processing

Most recruitment files contain far more than a CV. There may be salary expectations, recruiter notes, interview feedback, assessment results, availability and a record of why someone did, or did not, move forward. The employer needs a reason for holding each category of information, a lawful basis for using it and a decision on how long to keep it.

That does not mean recruiters should ask for consent by default. Under the current Polish Labour Code, an employer may request specified information from an employment candidate, including contact details and, where necessary for the role, education, qualifications and employment history. Depending on the data and purpose, current recruitment may therefore rely on a basis other than consent under Article 6 GDPR.

Consent still has a place. Keeping an application for future vacancies, for example, is a separate purpose for which consent may be appropriate, as discussed in the UODO guide for employers. In day-to-day terms, recruiters should be able to explain why they need the information, who will see it and how long it will remain in the process.

For a technical role, separate what is needed for the vacancy in front of you from optional details and future-recruitment data. A CV, coding-task result and interview score may all support the same search. That does not automatically justify keeping everything for unrelated roles under one generic checkbox.

Direct applications, sourcing and privacy information

For direct applicants, Article 13 GDPR requires privacy information at collection. It should be easy to find and describe the recruitment process the person is actually entering: who controls the data, why it is used, who receives it, whether relevant transfers occur, how long it is kept and which rights the candidate has. A generic website notice may not cover that clearly enough.

The same issue arises with sourced candidates. Information taken from LinkedIn, GitHub, a portfolio or another public source is still personal data. Article 14 GDPR may require the person to be informed, subject to its timing rules and exceptions. The UODO recruitment guidance also cautions against treating everything visible on social media as available for unrestricted recruitment use. Sourcing should remain tied to the person’s professional context, with transparent communication at first contact.

This comes up often in proactive technical recruitment. A public repository may help a recruiter spot relevant engineering experience. It does not open the door to using unrelated personal information in the assessment. The first message should make it clear how the recruiter found the person and what happens if they are interested, or if they decline.

Retention, talent pools and access

Avoid choosing one retention period simply because another company uses it. An active search, a future-opportunities talent pool and records retained in connection with a possible claim may involve different purposes. Employers should document their approach, take advice where necessary and make sure deletion or anonymisation actually happens when the approved period ends.

A talent pool is a separate recruitment activity, not an indefinite extension of every completed search. Candidates should know that their details may be considered for future roles and how they can withdraw consent or object where applicable.

The everyday controls are straightforward: keep interview notes job-related, limit ATS access and avoid stray CV copies in personal drives or long email chains. Candidates also need a workable route to exercise their rights under the GDPR.

What GDPR means when you use an external recruitment agency

Bringing in an agency adds another hand-off. That is manageable, but only if both sides know what happens to candidate data.

The employer and recruitment provider do not automatically fall into one fixed GDPR relationship. Their roles depend on who determines the purposes and means of processing. An agency may be an independent controller for some sourcing, a processor for a defined client operation or, in some circumstances, a joint controller. The agreement should reflect what both parties actually do. The European Data Protection Board’s guidance explains these roles.

Before the first outreach message goes out, agree:

• who collects the candidate’s details and provides privacy information;
• when CVs, screening notes and interview feedback are shared;
• which systems and providers receive the data;
• what happens after rejection, withdrawal or hire; and
• whether data leaves the European Economic Area.

Those decisions should appear in the appropriate agreements and candidate information. They should also be visible in the workflow. Who tells the candidate that their CV has reached the client? Who requests deletion from an assessment platform? Who closes the loop after rejection?

A structured recruitment partner can make those hand-offs much cleaner by maintaining the pipeline and assigning each update. It cannot promise compliance on the employer’s behalf; both parties remain responsible for the activities they control. A broad “GDPR compliant” sentence in an agency agreement is no substitute for that clarity.

The EU AI Act puts recruitment AI under greater scrutiny

AI features now appear throughout recruitment software: in job advertising, sourcing, candidate matching, CV filtering, assessments and interview analysis. The label on the product tells you very little. What matters is what the feature does and how much weight its output carries in the hiring decision.

Annex III of the EU AI Act classifies certain systems used in employment, worker management and access to self-employment as high-risk. Covered uses include targeted job advertising, application filtering and candidate evaluation. Depending on the use case, tools that rank people for independent-contractor work may also fall within scope.

That does not make every AI feature high-risk. A tool that schedules interviews or organises documents without materially influencing assessment may fall outside the category. The Commission’s official employment examples, however, treat automated matching and ranking as high-risk when the ranking is a primary input for recruiters, even if a person can override it. Classification depends on intended purpose, functionality and the Article 6 test.

The timing is easy to get wrong

This is where older summaries can quickly become misleading. The AI Act entered into force on 1 August 2024. Prohibitions and initial AI-literacy provisions started applying on 2 February 2025, governance and general-purpose AI provisions followed on 2 August 2025, and most remaining provisions became applicable on 2 August 2026.

However, the 2026 AI Omnibus amendment changed the timetable for high-risk systems. The Commission’s current AI Act timeline confirms that the high-risk requirements for Annex III systems, including covered recruitment tools, are due to apply from 2 December 2027.

The 2027 date is not a free pass until then. GDPR already applies to candidate profiling and can restrict solely automated decisions with legal or similarly significant effects unless an exception and safeguards apply. Anti-discrimination and Polish employment rules continue to matter too.

What employers should check before using AI in recruitment

Start by listing the actual use cases. What does each feature receive? What does it produce? At what point does that output reach a recruiter or hiring manager?

Do this feature by feature, not product by product. The same ATS might use AI to draft an email, organise applications and rank candidates. Those functions do not necessarily have the same classification or influence. One yes-or-no answer about whether the platform “uses AI” will not tell you enough.

Use these questions during procurement and review:

1. Where does the output matter? Separate administrative help from features that recommend, rank, filter or reject candidates.
2. What was the feature designed to do? AI Act classification follows intended use, not the most convenient product label.
3. What can the provider show you? Ask for its classification, instructions, validation information, known limitations and supporting documentation.
4. Which candidate data goes in? Check CV fields, assessment answers, recordings and inferred information, then consider the GDPR basis and whether a data-protection impact assessment is needed.
5. Can a recruiter genuinely disagree? The reviewer needs to understand the job-related factors, spot weak inputs and have authority to challenge the result.
6. What will you record and tell candidates? Plan proportionate logs and candidate information, including preparation for the future high-risk-system duties.

When the high-risk rules apply, employers using covered recruitment systems will normally be deployers. Article 26 of the AI Act will require covered deployers to follow instructions, assign competent human oversight, monitor the system, retain relevant logs and inform affected people. For Annex III recruitment systems, these duties are due from 2 December 2027. They are not requirements already owed by every employer today.

This review cannot sit only with procurement or IT. Talent teams need to know which scores recruiters see, whether a low score can hide a candidate and what evidence appears before someone accepts the recommendation.

Human judgement still matters

The direction of travel in the AI Act matches a basic recruitment principle: automation can support a decision, but it should not replace accountable judgement.

That is especially true in technical hiring. A job title or keyword match may say little about the scale of systems a candidate built, the ownership they held or how transferable their experience is. Communication, project relevance, motivation, availability and compensation expectations still need interpretation.

Consider two senior engineers who list the same stack. One may have maintained a narrow component; the other designed services, handled incidents and influenced architecture. A structured screening call can uncover that difference before the technical interview without pretending to replace the hiring manager’s assessment.

Of course, human review is not automatically unbiased. It still needs defined criteria, structured questions and job-relevant evidence. Reviewers should be able to explain a shortlist decision, especially when they accept or reject an automated recommendation.

At RemoDevs, automation may support sourcing or workflow efficiency, but shortlist decisions should be tied to the actual role requirements and reviewed by recruiters rather than presented as an unexplained algorithmic score. This is also why a specialist IT recruitment process in Poland should begin with a detailed role intake, not a search of a CV database.

The EU Pay Transparency Directive affects recruitment before employment starts

Pay transparency starts before someone joins the company. The EU Pay Transparency Directive entered into force on 6 June 2023 and required Member States to transpose it by 7 June 2026. Its recruitment provisions cover information about initial pay or a pay range based on objective, gender-neutral criteria, restrictions on salary-history questions and non-discriminatory, gender-neutral recruitment.

The Directive allows the information to appear in the vacancy notice, before the interview or otherwise early enough for an informed discussion. For a recruitment team, the takeaway is practical: do not leave compensation undefined until the final offer, and do not use a candidate’s previous salary as the starting point for the new role.

The Directive still needs national implementation. Its deadline did not automatically create an identical set of obligations for every private employer in Poland.

Poland has already enacted part of the recruitment framework. Since 24 December 2025, Article 18³ca of the Polish Labour Code has required employment candidates to receive information about initial remuneration or its range, based on objective and gender-neutral criteria. Relevant collective-agreement or remuneration rules must also be provided where applicable. The candidate must receive the information early enough for an informed and transparent negotiation:

• in the job advertisement;
• before the interview, if no advertisement was published or the information was not in it; or
• before employment, if it was not provided earlier.

This does not mean every Polish job advertisement must display a salary range. The current Labour Code allows disclosure before the interview when the advertisement omitted it. Article 22¹ also excludes current and previous pay from the employment-history information an employer may request. Job advertisements and titles must be gender-neutral, and recruitment must be non-discriminatory.

These Labour Code provisions concern applicants for employment. Genuine contractor sourcing may require a different analysis, although GDPR and the AI Act’s access-to-self-employment category can still be relevant. Define the working model before recruitment begins.

What salary transparency means for tech hiring in practice

Even if disclosure can legally happen later, defining the range before sourcing makes for a better process. A recruiter cannot represent a role honestly until the hiring manager has agreed what the organisation can offer.

Before opening a technical role, settle:

• the employment or contractor model;
• the currency and whether figures are gross, net or invoiced;
• fixed and variable compensation;
• how seniority, location and working pattern affect the band; and
• objective placement criteria and exception approval.

When the only answer is “salary depends on the candidate,” the criteria often have not been defined. A defensible band keeps the search within budget and makes recruiter outreach more credible.

Market information should remain separate from the company’s approved range. RemoDevs’ guide to the cost of hiring a senior developer in Poland can support budgeting, but the employer still needs objective criteria for the particular role.

An external recruitment partner should capture this during intake and use the same approved information in advertisements, direct outreach and candidate calls. A candidate should not hear one range from the recruiter and another from the hiring manager.

The same goes for seniority. If the role changes during the process, revisit the scope and pay band instead of quietly moving the candidate within an undefined range.

EU rules do not remove the need to check Polish employment law

For a hiring team, the EU-versus-Polish distinction is mostly practical. EU regulations apply according to their own timetables, while directives need national implementation. Polish legislation supplies the local employment rules and enforcement structure. Regulator guidance can help with day-to-day interpretation, but it does not replace the legal text.

The current Polish position is mixed:

• Data protection: GDPR applies directly alongside the Polish Labour Code and national data-protection law. UODO is the Polish supervisory authority.
• AI: Poland’s Act of 3 July 2026 on AI systems was published on 27 July 2026. Its main provisions entered into force on 11 August 2026, while specified institutional and enforcement provisions are due on 28 October 2026. The Act builds the national framework; it does not change the EU-level 2 December 2027 date for high-risk recruitment systems.
• Pay transparency: the June 2025 Labour Code amendment introduced recruitment-stage rules from 24 December 2025. The EU deadline has passed, but the broader UC127 implementation project remained a bill project on this article’s update date, with government adoption planned for the fourth quarter of 2026. Final rules and commencement dates may change.

International employers should choose the hiring model before sourcing starts. Direct employment, employer-of-record arrangements, genuine contracting and IT staff augmentation in Poland are not interchangeable. The structure affects who engages the person, who handles their data, who makes recruitment decisions and which employment rules apply.

Where the model or allocation of responsibilities is unclear, specialist Polish advice may be needed before publishing the role or changing the recruitment process.

A practical compliance-aware checklist for tech recruitment in Poland

1. Define the hiring model. Confirm employment or genuine contracting and identify which entity will engage the person.
2. Minimise candidate data and document the basis. Collect what each stage needs and do not use consent as a catch-all.
3. Provide relevant privacy information. Cover direct applicants and sourced candidates, including the employer, agency, recipients and relevant transfers.
4. Set retention rules. Define what happens after rejection, withdrawal, hire and expiry of any talent-pool period.
5. Map data hand-offs. Understand how CVs, notes and assessments move between the agency, employer and recruitment systems.
6. Inventory AI features. Record which tools recommend, rank, score, filter or reject and how much their output influences decisions.
7. Keep human review meaningful. Use role-related criteria and give reviewers enough information and authority to challenge automated recommendations.
8. Prepare for 2 December 2027. For potentially high-risk recruitment systems, obtain provider documentation and plan oversight, monitoring, logs and candidate information.
9. Define compensation before sourcing. Approve the model, range and objective placement criteria; remove salary-history questions from forms and interviews.
10. Review the legal status periodically. Recheck Polish pay-transparency implementation and the AI Act timetable before major process or vendor changes.

Where a specialist recruitment partner can help

Regulation does not remove the need to hire well. It makes an orderly process more valuable.

For companies hiring technical talent in Poland, a specialist recruitment partner can handle much of the work between an approved role and a defensible shortlist:

• clarifying the role, seniority, hiring model and salary range;
• sourcing against the agreed brief rather than forwarding a volume of CVs;
• screening against structured, job-related criteria;
• keeping candidates informed; and
• coordinating interviews, feedback and process hand-offs.

For senior or difficult-to-hire roles, that discipline helps surface context an automated score may miss: the scope of a candidate’s work, the systems they owned and the environments in which they performed well.

The employer gets a cleaner decision process too: one agreed brief, consistent candidate communication and a shortlist assessed against the criteria set at intake.

RemoDevs supports international companies with the operational side of IT recruitment in Poland, from role definition and sourcing through to structured screening and interview coordination. Shortlists remain human-reviewed and tied to the brief. The employer retains responsibility for its employment, legal and compliance decisions, while each party remains responsible for the activities it controls.

If you are building or expanding a technical team in Poland, RemoDevs can help structure the recruitment process and reach relevant candidates without turning it into a high-volume CV exercise.

Kamil Klepusewicz

Growth Expert

• Visit website