Why the GDPR applies to every HR AI tool
A language model that summarises an application processes personal data. A tool that drafts a reference letter from bullet points processes performance data. A chatbot that answers employee questions knows who is asking. There is hardly an AI use case in HR without a link to a person, and therefore hardly one without the GDPR. That is not a barrier against AI. It is a sequence: first the frame, then the tool.
The good news: the requirements are the same as for any other HR software. Anyone who has rolled out an HRIS knows them. What is new is only that AI vendors may sit outside the EU, and that prompts entered into some tools are used for training unless the agreement rules it out. For subsidiaries of international groups there is a third point: a group-wide vendor contract signed in the US or UK does not automatically cover the German entity's processing, and the local DPO will ask for the Article 28 terms in writing.
Data processing agreement
If the AI runs through an external vendor, such as Microsoft Copilot, ChatGPT Enterprise or Claude for Work, a data processing agreement under Article 28 GDPR is required. Without that agreement the processing is not compliant, regardless of how well the tool performs. The major vendors provide these agreements for their enterprise versions, with EU data processing and an exclusion of training on customer data. Free consumer versions have no such agreement, and that is exactly where HR data ends up when nobody sets a rule.
Three questions for every agreement: Where is the data processed? Are prompts used for training? How long does the vendor keep them? The answers belong in the works council agreement, because the works council (Betriebsrat, the elected employee representation) will ask them.
Legal basis, and which data may go in
Retention periods
Applicant data that passes through an AI tool is subject to the same retention periods as all other applicant data, as a rule six months after rejection, unless there is a legitimate interest in keeping it longer, such as a pending discrimination claim under the German General Equal Treatment Act (AGG). The tool itself must not keep its own, longer copy. In practice that means erasure has to happen in the AI tool as well, in histories, logs and caches, not only in the applicant tracking system. If you cannot control that, do not use the tool for applicant data.
Data subject rights
Access and erasure requests must also cover data processed through an AI tool. That presupposes that you know what the tool stores and where, not just what it displays. On top of that, for automated pre-selection there is Article 22 GDPR, the right not to be subject to a decision based solely on automated processing. That is the legal reason why a human makes every personnel decision and the tool only prepares it, and why that sentence appears in every works agreement and every policy.
Impact assessment and data protection officer
For AI-based application screening and performance evaluation, a data protection impact assessment (DPIA) is almost always mandatory, because people are evaluated systematically. It documents the risks the processing poses to the people affected and how those risks are limited. The data protection officer belongs in from the start, not as a sign-off station at the end. The DPO knows the questions the works council will ask, and the works council expects the DPO to have co-signed the agreement. Bring the DPO in after the first works council meeting and you lose weeks.
Four steps to a clean frame
Which tools, which data, which purposes. Honestly, including unofficial usage.
A data processing agreement with every vendor, a legal basis per purpose, third-country transfers settled.
Name the risks, define the measures, document. In parallel with the works council agreement.
Retention periods in the tool, a process for access and erasure, the record of processing activities updated.
Data protection and co-determination for AI routines and system rollouts in earlier roles, in alignment with data protection officers. Practical guidance, not legal advice. More about me
GDPR checklist for AI tools in HR
Six checkpoints to secure data protection before rolling out a new AI tool: agreement, legal basis, data, retention, rights, impact assessment. With the three questions to ask every vendor agreement.
Frequently asked questions
Is the AI vendor's privacy policy enough?
No. A separate data processing agreement under Article 28 GDPR is required on top. The privacy policy describes what the vendor does. The agreement obliges the vendor to do it.
Does the data protection officer have to approve every tool individually?
The DPO should at least be involved in use cases subject to co-determination and in high-risk cases. Formal approval duties depend on your internal process. Involvement in the impact assessment is mandatory.
May applicant data go into a language model at all?
With a data processing agreement, a legal basis and a retention period, yes. Without an agreement, for instance in free consumer versions, no. Health data and other special categories only with an explicit legal basis.
What if the vendor is based outside the EU?
Then an additional basis for the third-country transfer is needed, such as standard contractual clauses or an adequacy decision. The major vendors offer EU data processing, and that should be written into the agreement.
Do we need a data protection impact assessment?
For AI-based application screening and performance evaluation, almost always yes, because people are evaluated systematically. For plain text drafts without personal data, usually not. When in doubt, let the DPO decide.