When we searched for “AI in HR” in Polish, the results were mostly about recruitment: CV matching, candidate scoring, automatic rejections. This article starts where recruitment ends — in HR administration, after the contract is signed. That is where a large share of the HR team’s paperwork sits: onboarding documents, questions about workplace rules, leave requests, confirmations and the formalities when someone leaves. At ploch.ai we build this kind of solution as part of AI automation for businesses, and we do not build candidate scoring at all.
I describe the technical and organisational side of an implementation: where the data comes from, who approves, what the assistant does not see. The classification of a system under the AI Act (the EU regulation on artificial intelligence) is assessed and documented by the provider of the system, with advice from a lawyer. The provider is the company that places the system on the market or puts it into service under its own name: the software supplier, or your company if it builds the system itself or has it built. The company using the system checks that classification with its lawyer. The legal basis for processing data is settled by your company with its lawyer. As the data controller, the company also checks, with advice from the data protection officer or a lawyer, whether the GDPR (the EU General Data Protection Regulation) requires a data protection impact assessment: a description of the processing, its necessity and the risks to people, with ways to reduce them. This applies to every place in this article where a legal provision comes up.
Two things are out of scope from the start. First, calculating pay: a language model (a program that understands and writes text) is not a payroll program, so payroll stays in the HR and payroll software. Second, the aim of the project. We do not run implementations meant to shrink the HR team. We help a company make the change without cutting jobs: the HR person stops copying and collecting documents and starts checking and approving them. Staffing decisions always rest with your company.
The shared rule: the assistant prepares, a person approves
The five processes below follow one pattern. An AI assistant — a program that reads documents and messages written in plain language and prepares a draft from them — never grants or withdraws an employee entitlement on its own. Every document and every request that touches a specific person’s entitlement — leave, pay, medical examinations or the work certificate — ends in an approval step by a named person, and that step leaves a trace in the log. How to design such a step so that it does not become reflex clicking is covered in our article on the person who approves the system’s decisions (human in the loop).
The second shared feature: we rely on what the company already has and can connect to without a rebuild — the HR mailbox, Teams or SharePoint, document templates, an e-signature and an approval step in the document flow. The HR and payroll software remains the main source of up-to-date employee data; the assistant does not replace it.
For every process I give one number to measure before and after the implementation. These are numbers to measure in your company, not promised results: without a starting point nobody can say later whether the automation achieved anything.
1. The full set of documents when someone joins
Where the data lives: contract details (role, department, start date) that the HR person confirms in a form in the employee portal or in a SharePoint document flow; the description of working conditions from the health-and-safety records — dangerous, harmful and burdensome factors and others arising from how the work is done, exposure levels and current test and measurement results for factors harmful to health (noise or dust, for example, not the employee’s medical tests) — indicated by the person responsible for health and safety; the list of documents the company requires, templates. The assistant does not read scans of the contract or the personal-data form; the personal data the referral needs (name, PESEL number, address) is completed by the HR person outside the model.
What the assistant prepares: a checklist for the specific role, a draft referral for the pre-employment medical examination (filled in by an ordinary template following the prescribed form, with no language model, from fields confirmed by HR and the person responsible for health and safety), information about statements the employee may submit, such as PIT-2 (the employee’s voluntary statement for tax purposes; on our checklist a missing PIT-2 does not block closing the checklist), and requests to IT to set up accounts for day one. Under Article 229 § 4a of the Polish Labour Code the examinations are carried out on a referral issued by the employer. Under § 4 the employer may not admit anyone to work without a valid medical certificate confirming no contraindications to work in the role “in the working conditions described in the referral for medical examinations”. So when working-conditions information required for the role is missing, the assistant reports the gap instead of preparing the referral. First, though, the HR person checks whether the new joiner is exempt from the pre-employment examination (Article 229 § 1¹, for example when rehired to the same role within 30 days). According to the Polish State Labour Inspection (PIP), the referral is issued in two copies, one of which goes to the person being examined. Outside the model, the HR person checks that the medical certificate is valid and confirms no contraindications to work in the role, then records the outcome on the checklist; the assistant has no access to the certificate’s content. The checklist also includes initial health and safety training: under Article 237³ § 2 of the Labour Code, the employer provides it before admitting the employee to work. According to PIP, it is not required if the employee takes up work in the same position they held with that employer immediately before the new employment contract. The employee confirms the training on paper (on the initial training card) or electronically (the employer then adds an annotation to the card and attaches the confirmation document or a reproduction of it); the card and attachments are kept in part B of the personnel file. The checklist cannot be closed until the HR person confirms two things: that the training is complete and the completed card has been received (or that this exception applies), and that the employee has confirmed being informed about the occupational risks of the work and the rules for protection against hazards (Article 226 point 2 of the Labour Code); this confirmation also goes into part B of the personnel file.
Who approves: an HR person authorised by the employer signs the referral and closes the checklist; the line manager confirms the access rights.
Which entitlement it touches: being allowed to start work — which is why no document leaves without a person’s signature.
What to measure: the number of days from the signed contract to a complete file for the new joiner.
2. Questions about workplace rules, benefits and procedures
Where the data lives: the work regulations, internal policies, the benefits rules, procedures — documents in SharePoint or on the HR drive. Never personnel files.
What the assistant prepares: an answer to the employee’s question in Teams or in a chat, citing the document and the passage it comes from. When the documents hold no answer, the assistant says “I don’t know” and passes the question to HR instead of guessing. We treat an employee’s text as the content of a question, not as an instruction to the assistant: the limits (which documents it may answer from, who receives what and where things go) are set outside the model and checked with tests in which someone tries to type instructions that get round those rules.
Who approves: HR approves the set of documents the assistant uses and every update to it. In the first version every answer reaches the employee only after an HR person has reviewed it; direct answers are switched on later, and only for types of question that needed no corrections in the pilot, and the employee knows from the first exchange that an AI system is answering, unless that is obvious (the rule in Article 50 of the AI Act; who carries that duty is for a lawyer to assess). Questions passed on are handled by a person.
Which entitlement it touches: all of them indirectly — which is why the assistant says what the rule is rather than deciding whether a given entitlement applies to a specific person.
What to measure: the time an HR person spends handling one question — before the implementation for writing the answer, afterwards for checking and correcting the assistant’s draft or handling a question passed on.
Unlike the general knowledge assistant described among our AI automation examples, this assistant answers from regulations and policies, not from employee files. Why — in the section on HR data below.
3. Leave requests and time-record corrections
Where the data lives: the request form in the employee portal or in Teams (a request sent by e-mail gets a reply from HR with a link to the form), the staffing rota (who is at work and who covers, without sick-leave markers), the work regulations. Leave on demand (up to 4 days a year, Article 167² of the Labour Code) is requested no later than the day it starts, generally before scheduled work begins, so it has a separate urgent route: the request, even one sent through another channel, goes straight to HR and the person authorised to grant leave, without waiting for the form or a cover check.
What the assistant prepares: a complete draft annual-leave request — after checking the dates and cover and filling in missing details, which the employee picks from a list rather than typing them — and, for time-record corrections, one description with the reason chosen from a list (for example “missed clock-in” or “company business outside the workplace”). An extra note, if the employee adds one, is read only by the HR person, never by the model. The form has no field for a health reason; the employee raises such matters directly with the HR person. Requests for leave that applies by law (maternity leave, for example) do not go through the assistant at all: the form sends them straight to the HR person, because the type of leave alone can reveal health information.
Who approves: before annual leave goes to the line manager, the HR person confirms in the HR and payroll software that the employee has enough days left. Annual-leave dates are, as a rule, agreed by an authorised line manager in line with the leave plan and company rules, and cases where the law binds the employer are checked by HR; leave that applies by law once the conditions are met (maternity leave, for example) is verified and recorded by the HR person, without a discretionary decision by the manager. Time-record corrections are checked and approved by an authorised HR person, with the line manager confirming circumstances only they know. The HR person enters the data into the HR and payroll software.
Which entitlement it touches: the right to leave and the working-time record — the decision always belongs to a person, including requests that look routine.
What to measure: the number of hours from the request until the employee is told the outcome or HR confirms the registration.
4. Confirmations and draft letters
Where the data lives: the request form in the employee portal or in Teams (a request sent by e-mail gets a reply from HR with a link to the form), company templates and data that the HR or payroll person copies in or approves; the assistant has no access to the HR and payroll software.
What the assistant prepares: a standard confirmation is filled in by an ordinary template, with no language model, because the data is already confirmed; for an unusual request the HR person reads the employee’s description and picks the type of letter; the description does not reach the model, and the assistant drafts the letter, with the fields that need confirming clearly marked, ready for e-signature.
Who approves: the HR person (and, for a confirmation of earnings, the payroll person) checks the data, and a person authorised by the employer signs.
Which entitlement it touches: a confirmation of employment or earnings that the employee needs, for example at a bank or an authority — which is why the company is responsible for the content, not the assistant.
What to measure: the time from the employee’s request to the confirmation being issued.
5. The leaver checklist
Where the data lives: the end date and role, which the HR person transfers from the HR and payroll software or the contract register into a form in the document flow — whether the employment ends by notice, by agreement, because a fixed-term contract expires or in any other way; the list of equipment and access rights and the work-certificate template in SharePoint or on the HR drive.
What the assistant prepares: a checklist with deadlines — returning equipment, removing access, handing over work — and a draft work certificate (świadectwo pracy), filled in by an ordinary template following the prescribed form, with no language model, from data confirmed by HR; the HR person completes the remaining fields. The deadline matters: Article 97 § 1 of the Polish Labour Code requires the certificate to be issued on the day the employment ends, unless the employer intends to employ the same person again within 7 days. When the next employment with that person is established within that period, the certificate is issued only on the employee’s request; the request may be made at any time, and the employer has 7 days from it to issue the certificate (Article 97 § 1¹ and § 1²), so the checklist has a separate path for such a request. If the planned re-employment does not happen, the checklist has a checkpoint at the end of the 7 days from the end of employment that reminds the HR person to issue the certificate. When issuing the certificate on the day the employment ends is objectively impossible, Article 97 § 1 allows 7 days to send it by post or deliver it another way, and that is a separate checklist item too. When employment ends because the employee dies, the employer prepares the certificate and places it in the deceased employee’s personnel file, and issues it within 7 days of a paper or electronic request from the spouse, another person eligible to apply for a survivor’s pension or, if there is no such person, an heir (§ 5 of the regulation on the work certificate); the checklist has a separate path for this. The checklist also covers formalities that HR and payroll handle in their own systems, where the assistant only reminds them of the deadlines: together with the certificate, the employer (where this obligation applies) gives the employee information on paper or electronically about how long employee records are kept, the right to collect them and the deadline for doing so, and the destruction of records not collected by that deadline; and the employer, as the contribution payer, submits form ZUS ZWUA to deregister the employee from insurance, generally within 7 days of the end of the employment on which that insurance cover is based.
Who approves: an HR person authorised by the employer signs the certificate, IT confirms that access has been removed, the line manager confirms the handover.
Which entitlement it touches: the work certificate — which is why a person always checks the draft certificate.
What to measure: the share of leavers whose access was all removed by their last working day.
The five processes in one table
| Process | Where the data lives | What the assistant prepares | Who approves | What to measure |
|---|---|---|---|---|
| Someone joins | details from HR and health and safety, templates | checklist, medical referral | HR, line manager | days to a complete file |
| Workplace-rules questions | regulations, policies, benefits | sourced answer or “I don’t know” | HR (documents, answers in the pilot) | HR time per question |
| Requests and time records | request form, staffing rota | draft leave request, time-record correction note | line manager, HR | hours to outcome or registration |
| Confirmations | request form, template, data from HR | draft letter for signature | HR, payroll | time to issue |
| Someone leaves | details entered by HR, access list | checklist, draft work certificate | HR, IT, line manager | access removed on time |
HR data: what the assistant does not read
HR data is by nature personal data, and some of it falls into the special categories. Article 9(1) of the GDPR (the EU General Data Protection Regulation) prohibits processing, among other things, personal data revealing trade union membership and data concerning health, with the exceptions listed in paragraph 2 of that Article. In HR this data is right on the surface: a sick note (e-ZLA, the Polish electronic sick note), a medical certificate, a union-dues deduction on the payroll.
The Polish Labour Code narrows the role of employee consent here as well. Article 22¹b § 1 says that consent can be the basis for processing data covered by Article 9(1) of the GDPR only where the data is handed over on the initiative of the candidate or the employee, and § 3 requires the employer’s written authorisation for persons processing the data referred to in § 1. We design the system so that documents containing such data do not reach a language model; text typed by employees is covered below. The legal basis, access to the data and the model provider’s role are assessed by the data controller (that is, your company) with their lawyer.
Four design rules follow from this:
- Sick notes, medical certificates and medical examination results are not input for the assistant. An HR person handles them in the HR and payroll software, as they do today.
- The assistant answers from approved company documents, not from employee files. Regulations and policies reach the assistant after their content has been checked and unnecessary personal data removed, such as names in worked examples.
- Questions and requests have their own safeguards. The company tells staff not to enter health data, information about trade union membership or any other special-category personal data covered by Article 9 of the GDPR (such as religious beliefs or sexual orientation) into the assistant. The forms have no fields for this information. Original documents, scans and attachments do not reach the model — only form fields and data confirmed by the HR person. In requests the employee does not write to the model: the reason and details are picked from a list, and an extra note is read only by the HR person. Freely typed text reaches the model only in questions about the rules, and it first goes through a simple keyword filter with no language model involved. A question in which the filter detects potential data in these categories goes to an authorised HR person without reaching the model. The filter can nevertheless miss such information, allowing it to reach the model. The data controller assesses this risk with their lawyer before launch, and the log has a short retention period and narrow access.
- Every document given to the assistant has an owner and a scope. HR knows which files the assistant reads and can check.
The legal basis, the model provider’s role and the data processing agreement are covered in a separate article on the GDPR when implementing a language model — I do not repeat them here.
The question log is employee data too
This point is easy to overlook in design. An HR assistant records questions, and employees’ questions say a lot about them: who asks about maternity leave, who about giving notice, who about remote working for health reasons. A log that records a name next to every question becomes a tool for watching people, even if nobody planned it that way.
The Polish Labour Code regulates monitoring in Article 22² (video) and Article 22³ (work e-mail), and Article 22³ § 4 extends the e-mail monitoring rules to other forms of monitoring where they are needed for the purposes in § 1. Whether the assistant’s log falls under these provisions is for a lawyer to decide. Whatever the answer, we settle three things at the start:
- Who sees the log. By default, a small group of authorised HR staff, not line managers. The person responsible for the system on the technical side sees only technical data without the question text, unless they hold written authorisation and a duty of confidentiality.
- How long it is kept. A short, written retention period instead of “forever, in case it comes in handy”.
- Whether questions are attributed to a person. Improving answers usually needs only the text of the question, without a name; attribution is switched on only where a matter needs an answer for a specific person. Removing the name is not always enough, because a person can sometimes be recognised from the question itself — so the short retention period and narrow access apply then too.
These decisions go into the system documentation and the information for staff before the assistant answers its first question. If a lawyer considers the log a form of monitoring, the launch has to be planned differently. The purposes, scope and method of monitoring then go into the work regulations (or a collective agreement or notice), staff are informed at least 2 weeks before launch, and a new person receives that information on paper or electronically before being admitted to work (Article 22² § 6–8, applied accordingly under Article 22³ § 3). Above all, though, Article 22³ § 4 allows other forms of monitoring only where they are necessary for the purposes in § 1: organising work so that working time is fully used and the work tools provided to the employee are properly used. If the log only serves to improve answers, the simpler option is a log without questions attributed to people; whether attribution is allowed is for a lawyer to assess before launch.
Three things we leave alone
We do not do three things, even when a client asks for them and even in a “just a suggestion for a person” version. We also rule out candidate scoring and emotion inference on our what we don’t do page.
1. Assessing and ranking candidates. Annex III to the AI Act, point 4(a), lists among high-risk systems AI systems intended for the recruitment or selection of people, “in particular to place targeted job advertisements, to analyse and filter job applications, and to evaluate candidates”. We refuse to assess and rank candidates: tools that read CVs and award points are ruled out for us from the start.
2. Inferring employees’ emotions and moods. Article 5(1)(f) of the AI Act prohibits the use of AI systems “to infer emotions of a natural person in the areas of workplace and education institutions”, except for medical or safety reasons. The prohibition has applied since 2 February 2025. The regulation defines an emotion recognition system as an AI system “for the purpose of identifying or inferring emotions or intentions of natural persons on the basis of their biometric data” (Article 3(39)), such as a face or a voice, so whether the prohibition covers analysing the text of messages alone is for a lawyer to assess. Our line is broader than the provision: we do not build “team mood analysis” from recordings or from employees’ messages.
3. Rating performance and deciding on promotion, dismissal or task allocation. Point 4(b) of the same Annex lists systems used “to make decisions affecting terms of work-related relationships, the promotion or termination of work-related contractual relationships, to allocate tasks based on individual behaviour or personal traits or characteristics or to monitor and evaluate the performance and behaviour of persons in such relationships”. Performance assessment, decisions on promotion and dismissal, and task allocation based on behaviour or traits are separate purposes named in that point. Predicting who will leave, performance reviews written by a model and assigning tasks by personality profile are not our scope.
For high-risk systems under Article 6(2) and Annex III, the requirements of Chapter III, Sections 1–3 of the AI Act, among them the duties of companies using such systems, apply from 2 December 2027; that date was set by amending Regulation (EU) 2026/1744. The Article 5 prohibition applies regardless of that date. Article 26(7) comes from those same Sections 1–3 of Chapter III, so for Annex III systems it also applies from 2 December 2027: before using a high-risk system at the workplace, the employer informs workers’ representatives and the affected workers. High-risk systems placed on the market or put into service before that date are different: these requirements, including Article 26(7), apply to them only if they undergo significant changes in their design on or after 2 December 2027 (Article 111(2)). Even without such a change, high-risk systems intended to be used by public authorities must be brought into line by 2 August 2030. Whether a system you already have is a high-risk system under Annex III is assessed and documented by its provider. From 2 December 2027, two further rules also apply. If the provider considers that an Annex III system is not high-risk, before placing the system on the market or putting it into service it must document that assessment and register itself and the system in the EU database (Article 6(4) and Article 49(2)). If your company substantially modifies a high-risk system already placed on the market or put into service, and the system remains high-risk, your company becomes its provider and takes on the provider’s obligations. The same applies if it changes the intended purpose of a system already placed on the market or put into service, previously not classified as high-risk, so that the system becomes high-risk (Article 25(1)(b)–(c)). Your company checks that assessment with its lawyer, and we implement the technical consequences in our AI Act technical compliance sprint.
The AI Act and the five processes: what to record now
None of the five processes rates people or decides on their employment, and that is exactly why they were chosen. Which category your specific assistant falls into is still for its provider to assess and document, with advice from a lawyer, and your company checks that assessment with its lawyer. On the technical side we prepare the material that assessment can rest on:
- an entry in the register of AI systems — purpose, input data, approver, model provider;
- an activity log — who approved which document and when;
- a description of what the system does not read — with the list of excluded sources from the section on HR data;
- preparing the HR staff — Article 4 of the AI Act, as amended by Regulation 2026/1744, obliges a company to take measures supporting AI literacy (an obligation of effort, not a guarantee of any given level); in practice it means the approver knows what the assistant gets wrong.
Deadlines and changes to the AI Act after the 2026 amendment (the so-called Digital Omnibus, Regulation 2026/1744) are collected in our article on the AI Act in Poland.
Where to start
With one process, not five. The simplest to start with is usually the second — questions about workplace rules — because it does not touch personnel files, and once it runs it is easy to compare the chosen measure with the measurement taken before the implementation. Before we build anything, it is worth counting for two to four weeks what I named for the chosen process: how long an answer to a question takes, how long a confirmation takes, how many days completing a file takes. Without that number nobody can honestly say whether the implementation paid off.
If that measurement shows a handful of questions a month and a confirmation once a quarter, that is a good result: automation is not needed, and it is better to know before a project. If the numbers are large, we describe how we run such a project — from choosing the process through the pilot to the handover — on our page about AI automation for businesses.
Sources, as at 13 October 2026
- Polish Labour Code, consolidated text: Dz.U. 2026 item 1245 (ISAP) (Polish) — law as at 27 August 2026; Articles 22¹b, 22², 22³, 97 § 1–1², 163 § 1, 167², 180 § 1, 226 point 2, 229 § 1¹, § 4 and § 4a, and 237³ § 2; read on 12 October 2026.
- Regulation (EU) 2024/1689 (AI Act) — Article 3(3) and (39), Article 5(1)(f), Article 6(2) and (4), Article 25(1), Article 26(7), Article 49(2), Article 50, Article 111(2), Annex III point 4; read on 13 October 2026.
- Regulation (EU) 2026/1744 — the 2 December 2027 date for Annex III high-risk systems and the amended Article 4 of the AI Act; read on 12 October 2026.
- Regulation (EU) 2016/679 (GDPR) — Articles 9 and 35; read on 12 October 2026.
- Polish Ministry of Finance, rules for statements affecting tax advances (podatki.gov.pl) (Polish) — the PIT-2 statement; read on 12 October 2026.
- Polish State Labour Inspection, what a referral for preventive medical examinations must contain (Polish) — referral contents; read on 12 October 2026.
- Regulation on the work certificate, consolidated text: Dz.U. 2024 item 1016 (ISAP) (Polish) — the certificate form and § 5 (death of the employee); read on 13 October 2026.
- Regulation amending the regulation on health and safety training: Dz.U. 2025 item 1640 (ISAP) (Polish) — paper or electronic confirmation of initial training (§ 12); read on 13 October 2026.
- Polish State Labour Inspection, does the employer have to agree to leave on demand? (Polish) — Article 167² and the deadline for the request; read on 13 October 2026.
- Regulation on employee records, consolidated text: Dz.U. 2026 item 474 (ISAP) (Polish) — § 3 point 2(f): confirmation of occupational-risk information in part B of the personnel file; read on 13 October 2026.
- Polish State Labour Inspection, employee records (PDF) (Polish) — the information provided with the work certificate; read on 13 October 2026.
- ZUS, deregistering an insured person (Polish) — form ZUS ZWUA and the 7-day deadline; read on 13 October 2026.
- Polish State Labour Inspection, health and safety training (Polish) — initial training, when it is not required, the initial training card in the personnel file; read on 13 October 2026.
- European Commission, AI Act Service Desk — Article 111 — transitional rules for high-risk systems placed on the market earlier, as amended; read on 13 October 2026.