AI can reduce recruitment admin, surface relevant experience, and help teams handle high application volumes. Yet for European HR directors, the most consequential procurement question is not whether an AI feature is impressive. It is whether the tool will reuse a candidate’s CV, interview notes, assessment responses, or inferred attributes to train a model outside your control.
That distinction is central to GDPR compliant AI recruitment. Candidate data are not a free product-improvement resource. They are personal data processed for a defined hiring purpose, with real effects on people’s access to work. The UK Information Commissioner’s Office (ICO) has warned that AI recruitment tools can compromise privacy or unfairly exclude jobseekers when used unlawfully, and its audits found examples of excessive collection and indefinite retention. [1]
For HR, privacy, and procurement leaders, the practical decision is clear: do not approve an AI ATS on the strength of a security badge or a promise of “EU hosting.” Approve it when the supplier can prove—contractually and operationally—that candidate data stay within agreed purposes, access paths, locations, and retention limits.
“Organisations considering buying AI tools to help with their recruitment process must ask key data protection questions to providers and seek clear assurances of their compliance with the law.” — Ian Hulme, ICO Director of Assurance [1]
The real risk: purpose creep from applicant record to model-training data
A recruitment platform may process more than contact details and work history. CVs can reveal nationality, education, employment gaps, professional memberships, and sometimes health information or other special-category data. Interview transcripts, assessments, recruiter notes, and ranking outputs add further sensitivity. When that information flows to an external large language model (LLM) or a vendor’s shared learning system, the original hiring purpose can quietly become product development or general model training.
This is purpose creep. It can happen when a “CV summariser” sends full documents to a third-party model provider, when customer prompts are retained for quality improvement, or when a vendor states that it “anonymises” data but cannot explain what is removed, where the data travel, or whether information could still be extracted from the resulting model. The European Data Protection Board (EDPB) is explicit that a model trained on personal data is not automatically anonymous; a controller claiming anonymity must be able to demonstrate that the likelihood of extracting personal data from the model or through queries is insignificant. [3]
A defensible AI ATS data privacy position therefore begins with a bright line: candidate and customer data must not train a shared, external, or foundation model unless the employer has explicitly instructed it, documented an appropriate lawful basis and purpose, and completed the necessary privacy assessment. In routine recruitment procurement, the lower-risk default is simpler: no training, no secondary use, and no opt-out ambiguity.
| Procurement question | Strong answer | Warning sign |
|---|---|---|
| Can candidate data improve your AI? | “No. Customer and candidate content is excluded from shared model training and product improvement by default and by contract.” | “Data may be used to improve services unless you contact support.” |
| What data leave the ATS? | A documented data-flow map covering CVs, prompts, outputs, logs, telemetry, and support access. | A generic architecture diagram with no model-provider or logging detail. |
| Is anonymisation enough? | The supplier explains its technical method, residual risk, and why training is necessary; it does not rely on the label alone. | “We anonymise everything” without evidence, scope, or model-extraction testing. |
| Can we delete data fully? | Deletion covers production, backups on a stated schedule, indexes, logs, and any permitted derived data. | “Deleted from the UI” with no retention or backup explanation. |
What GDPR asks you to control—not just what your vendor promises
A privacy-compliant AI recruitment programme is an operating model. GDPR Article 5 requires personal data to be processed lawfully, fairly, and transparently, while also being collected for specified purposes and kept to what is necessary. [2] An AI feature does not make those principles optional; it makes evidence of compliance more important.
Start by defining the purpose narrowly. For example, “summarise an applicant’s CV for the recruiting team in requisition X” is materially different from “retain all applicant content to improve our matching engine.” If the supplier acts on your behalf, GDPR Article 28 requires you to use processors that provide sufficient guarantees and to govern processing through a binding contract. The contract must set out, among other things, the subject matter, duration, nature, purpose, data types, data-subject categories, and the controller’s rights and obligations. [2]
This is why a Data Processing Agreement (DPA) should be treated as a sourcing control, not a legal formality. It should prohibit the processor from using candidate data for its own purposes; specify approved sub-processors; require assistance with rights requests and breaches; and set a clear return-or-deletion obligation at the end of the service. The ICO likewise advises recruiters to identify controller and processor roles, document them clearly in a contract, and provide explicit, comprehensive written instructions to a processor. [1]
A Data Protection Impact Assessment (DPIA) should be completed before deployment where processing is likely to create a high risk to individuals’ rights and freedoms—particularly relevant where new technology evaluates or ranks candidates. GDPR Article 35 requires this assessment before the processing begins in such cases, and the ICO recommends conducting it at procurement stage and keeping it current as impacts evolve. [1] [2]
EU servers matter—but they are not the entire answer
EU candidate data protection is not established simply because an ATS says “hosted in Frankfurt” or “EU cloud.” EEA hosting can reduce exposure and simplify data-residency design, but it does not answer who can remotely access data, where AI inference runs, where logs and backups are stored, or whether a sub-processor receives prompts outside the EEA.
The European Commission states that special safeguards are required when personal data are transferred outside the EEA so that protection travels with the data. It identifies mechanisms such as adequacy decisions, standard contractual clauses, binding corporate rules, certification mechanisms, codes of conduct, and limited derogations. [4] Accordingly, require your supplier to map not only storage location but also access and transfer locations for support, security operations, analytics, LLM inference, model monitoring, and every sub-processor.
The right question is not, “Are your servers in the EU?” It is: “Can you show us every location where candidate personal data are stored, accessed, processed, logged, backed up, or exposed to an AI model, and the safeguards for any non-EEA flow?”
| Control area | Evidence to request before selection | Approval standard |
|---|---|---|
| Data residency and transfers | Data-flow diagram, list of processing and support locations, sub-processor register, and transfer mechanism where relevant. | No unexplained non-EEA access or onward transfer. |
| No-training policy | DPA clause plus product documentation covering prompts, uploads, outputs, logs, and derived data. | Secondary model training is prohibited by default; any exception requires written instruction. |
| Encryption and key protection | Security architecture stating encryption in transit and at rest, identity/access controls, key-management model, and independent assurance evidence. | Controls are risk-appropriate and independently evidenced—not merely described as “bank-level.” |
| Access governance | Role-based access control, MFA/SSO support, audit logs, privileged-access process, and support-access approvals. | Access is least-privilege, attributable, and reviewable. |
| Retention and deletion | Retention schedule, deletion workflow, backup lifecycle, export format, and deletion certificate process. | Candidate data can be exported and deleted within agreed, verifiable timelines. |
| Incident readiness | Breach notification commitment, incident contacts, testing cadence, and contractual cooperation duties. | The supplier can notify you without undue delay and support your response obligations. |
“Bank-level encryption” is a marketing phrase; security evidence is the test
Encryption is important, but it is not a compliance verdict. GDPR Article 32 requires controllers and processors to implement technical and organisational measures appropriate to the risk, explicitly including pseudonymisation and encryption where appropriate. [2] A sound security review should consequently examine the complete control environment: encryption in transit and at rest, secure key management, strong identity controls, segregation of customer data, auditability, vulnerability management, backup protection, and tested incident response.
Ask the supplier whether your tenant is logically isolated; whether their personnel can view CV contents; how production support access is approved and logged; and whether an AI provider receives raw personal data or a minimised, pseudonymised version. Request recent independent assurance documents under appropriate confidentiality terms, then have security and privacy colleagues validate the scope. A certificate can support assurance, but it should not replace a data-flow review and contractual restrictions on reuse.
Keep a human decision-maker where it counts
Candidate privacy and fairness intersect at the point of selection. GDPR Article 22 gives individuals a right not to be subject to a decision based solely on automated processing, including profiling, where it produces legal or similarly significant effects, subject to specific exceptions and safeguards. [2] For recruitment teams, this means that a nominal human click is not enough if an algorithmic score routinely dictates who is screened out.
Candidate notices should explain how and why AI is used, the significance and likely consequences of automated processing where applicable, and the route for candidates to challenge decisions. [1] [2] Build a working review process: recruiters must have the authority, information, time, and training to reassess an AI recommendation. Monitor for accuracy and adverse patterns after launch rather than assuming pre-launch testing settles the issue.
This also aligns with the EU AI Act’s employment context. The European Commission’s AI Act Service Desk says AI used for recruitment or selection, including automated job matching and ranking that analyses CVs or scores candidate answers, may be classified as high-risk. It notes that human discretion does not automatically remove that classification when rankings or scores are a primary input that meaningfully affects decisions. [5]
A practical approval gate for secure hiring platforms
The most reliable way to select secure hiring platforms is to make privacy evidence a gating criterion, not an afterthought once the preferred product has been chosen. A supplier should be unable to pass security and privacy review if it cannot articulate its no-training policy, its complete AI/sub-processor chain, or its deletion mechanism.
First, have HR map every intended AI use case: CV parsing, candidate matching, interview transcription, assessment scoring, sourcing, and recruiter copilots. Then involve the DPO or privacy lead, information security, procurement, legal, and the business owner to complete a DPIA-led review. Ensure the DPIA tests necessity, proportionality, transparency, security, transfers, retention, bias, and meaningful human intervention—not just cyber controls.
Second, turn the review into enforceable requirements. The selected vendor’s DPA and order form should state that it processes candidate data only on documented instructions; does not train its own or third-party models with those data; does not sell or disclose them; gives advance notice of sub-processor changes; and returns or deletes data at contract end. The agreement should also specify audit and evidence rights, assistance with candidate requests, incident notice, and restrictions on any non-EEA transfers.
Finally, verify the configuration you buy. Disable any optional training, analytics, or data-retention switches. Restrict integration scopes, establish a candidate-retention schedule, and maintain a register of AI features and model providers. Reassess the system when a provider adds a new copilot, changes an LLM partner, introduces a new sub-processor, or expands data use. Compliance is sustained through change control, not obtained once at signature.
The decision: choose control over vague assurances
The best GDPR compliant AI recruitment platform is not the one that claims to be “fully compliant” in a brochure. It is the one that enables your organisation to demonstrate control: data are processed for defined hiring purposes; no candidate record becomes shared training material by default; access and transfers are mapped; security measures are proportionate and evidenced; retention is enforceable; and human reviewers remain accountable for consequential decisions.
For European HR directors, this is not a brake on responsible AI adoption. It is the condition for using AI in hiring without creating a hidden data-liability problem. Ask for evidence, put the no-training rule in the contract, and treat any opaque answer as a reason to pause the procurement.
This article provides general information and is not legal advice. Obtain advice tailored to your organisation, jurisdictions, intended processing, and workforce obligations.
References
[1] Thinking of using AI to assist recruitment? Our key data protection considerations | ICO
[2] Regulation – 2016/679 – EN – gdpr – EUR-Lex
[4] Rules on international data transfers – European Commission
