HR data: What should never go into an internal AI system?

Organisations are investing heavily in AI for recruitment, talent management and workforce planning. But not all information held by HR departments is suitable for these uses. Which categories should be excluded from training or inference datasets under GDPR requirements and in light of discrimination risks and technical threats? This article sets out the legal framework, identifies data to exclude, examines technical threats and outlines governance measures for CIOs, CISOs, DPOs and executives seeking to use AI without undermining compliance or employee trust.

Introduction

Imagine a multinational's AI department deciding to feed its internal recommendation model with the full medical records of its 12,000 employees. Within weeks, the system identifies correlations between chronic illnesses and performance, generating mobility suggestions that, while seemingly relevant, expose every employee to a risk of illegal discrimination. A scandal erupts, data protection authorities launch an investigation, and the company sees its reputation tarnished and its legal budget skyrocket.

This scenario is not hypothetical: several recent incidents (e.g., health data leaks via a language model in 2022, sexist biases detected in a skills assessment tool) demonstrate that the temptation to use 'all' HR assets as raw material for AI can quickly become a costly blunder.

The challenge is twofold: complying with legal obligations (GDPR, Labour Code, European AI directives) and preserving the security and fairness of the models. To achieve this, one must first identify which data should be excluded a priori from any internal AI system, and then implement the necessary safeguards.

1 Legal and regulatory framework applicable to HR data

In summary: the processing of any data falling under Article 9 of the GDPR or categories protected by labour law must be justified, time-limited, and subject to reinforced governance. The absence of a legal basis constitutes sufficient grounds to exclude such data from internal AI systems.

2 Typology of HR data to be systematically prohibited

Key takeaway: any data classified as a 'special category' under GDPR or likely to create a power imbalance must be excluded a priori from training and inference datasets.

3 Technical risks associated with feeding AI with this data

3.1 Leaks and re-identification

Even when data is aggregated, generative models (LLM, diffusion) can be exploited via membership inference or data reconstruction attacks: an adversary queries the model with targeted prompts to retrieve sensitive information that was not explicitly stored.

3.2 Discriminatory biases

Variables such as age, gender, or ethnicity are often correlated with other attributes (e.g., salary level). If these fields are retained in the training set, the model may learn biased associations and reproduce or amplify existing discrimination.

3.3 Model inversion attacks

An attacker with limited access to the AI system's API could partially reconstruct original inputs (e.g., medical records) by analysing gradients or probabilistic responses, thereby compromising employee confidentiality.

3.4 Regulatory non-compliance and sanctions

Failure to comply with the data minimisation obligation (GDPR Art. 5(1)(c)) exposes the company to fines of up to 4% of total worldwide annual turnover or €20M, excluding costs associated with corrective actions and loss of trust.

4 Legitimate use cases: where is the scope actually open?

Key principle: each use case must be preceded by a Privacy Impact Assessment (PIA) to validate that the data used is proportionate, necessary, and correctly secured.

5 Secure architecture for HR data processing

Read the diagram notation

flowchart TD
    A[Sources RH] --> B{Data Lake sécurisé}
    B --> C["Ingestion (ETL) avec filtrage"]
    C --> D[Anonymisation / Pseudonymisation]
    D --> E["Data Vault (chiffrement au repos)"]
    E --> F["Environnement d’entraînement IA (sandbox)"]
    F --> G[Modèle entraîné]
    G --> H[Déploiement en production]
    style B fill:#f9f,stroke:#333,stroke-width:2px
    style D fill:#bbf,stroke:#333,stroke-width:2px

• Controlled ingestion: ETL pipelines include a filtering step that automatically removes any column corresponding to prohibited categories (e.g., health_status, political_affiliation).
• Anonymisation / pseudonymisation: prior to storage, direct identifiers are replaced by UUIDs and sensitive attributes are aggregated or blurred using differential privacy techniques (controlled ε‑budget).
• Encryption at rest: all data vault tables use AES‑256 with key rotation managed by an HSM (Hardware Security Module).
• Training sandbox: the learning environment is isolated, with no external network access, to mitigate the risk of exfiltration via covert channels.
• Role-Based Access Control (RBAC): only authorised data scientists and the DPO can view the dataset metadata.

This architecture meets confidentiality, integrity, and traceability requirements while maintaining the flexibility required for AI experimentation.

6 HR Dataset Governance

A robust governance process enables the demonstration of compliance during a CNIL audit and limits operational risks.

7 Specific points of vigilance for AI models

7.1 Model Inversion & Membership Inference

• Symptom: the model returns overly precise responses when provided with a prompt containing very little information.
• Mitigation: apply differential privacy during training, limit output granularity (e.g., providing aggregated scores rather than individual probabilities).

7.2 Imbalanced Data Bias

• Symptom: model performance varies significantly based on the candidate's gender or age.
• Mitigation: resampling, class re-weighting, fairness audits (e.g., Equal Opportunity and Demographic Parity metrics).

7.3 Reliance on Outdated Data

• Symptom: the model recommends training courses that no longer align with current market skills.
• Mitigation: implementation of a periodic retraining pipeline with validation of source freshness (TTL).

7.4 API reverse-engineering risks

• Symptom: a malicious user retrieves model weights through multiple API calls.
• Mitigation: rate limiting, strong authentication, monitoring of abnormal access patterns.

8 Operational recommendations for decision-makers

Operational conclusion

The introduction of artificial intelligence into the human resources function offers undeniable efficiency potential: reduction in recruitment time, improved visibility on