Data Privacy and AI in the Corporate Portal: What's Allowed, What Isn't, and Where the Fear-Marketing Starts

AI and personal data — a phrase that makes any CHRO's eye twitch. On one side, the security team is shouting "no AI on our data." On the other, the product team wants to roll out conversational surveys and a Manager Coach. Where, between these poles, is the truth?

First, something important: I am not a lawyer, and this article is not a substitute for advice from your legal team or your data-protection authority. It's the operational view of a product team that, over the last couple of years, has made "allowed or not allowed" choices every day in a real HR-tech system serving both EU and international clients. If you have a procurement process with a real compliance review, you still need your own lawyer. This article is so you have something substantive to discuss with them.

And one more thing. The topic of data-protection law often collapses into two extremes: either paranoia ("AI is banned entirely"), or naivety ("we're fine, let's just turn it on"). Both extremes are wrong. The real position is: AI can be used if the process is transparent, consent is explicit, k≥5 is technical, and data is properly located. Now, the details.

What GDPR Means for HR Tech

The General Data Protection Regulation (GDPR) is the principal data-protection framework across the EU, in force since 2018 and the de-facto model that many other regimes (UK GDPR, and various national laws) follow. For HR tech, several baseline principles matter.

Employee data is personal data. Name, date of birth, job title, department, contacts, photo, in some cases biometrics (for access passes and facial recognition), performance ratings, survey results. All of this falls under the regulation's protection.

Data residency and transfers (Chapter V of the GDPR). Personal data of EU subjects can only be transferred outside the EU under specific safeguards (adequacy decisions, Standard Contractual Clauses, etc.). This is a requirement many overseas SaaS vendors don't properly cover, and it's a critical point when choosing HR tech.

Lawful basis and consent. Processing personal data requires a lawful basis (with exceptions for the employer's legitimate interests — for example, HR record-keeping). When we talk about AI processing (which goes beyond record-keeping), the basis often needs to be explicit consent, documented separately.

Data-subject rights. An employee has the right to know what data about them is processed, and to request correction or erasure (subject to the retention periods set by employment law).

Controller vs processor. Who's the data controller is usually the employer itself. The HR-tech SaaS vendor is usually a processor (acting on the controller's instructions). This division of responsibility must be fixed in a contract (a DPA, Data Processing Agreement).

In recent years, additional guidance has emerged on biometric data (special-category data with stricter requirements) and on automated decision-making, and the EU AI Act now layers specific obligations on certain "high-risk" HR use cases on top of the GDPR. As of March 2026, the general GDPR regime still governs most HR-tech processing. But that's no reason to relax — regulators are already reviewing AI scenarios in HR tech.

Where AI Touches Personal Data, and Where It Barely Does

The most common mistake is reasoning about "AI and PII" in the abstract. In practice, AI in HR tech uses completely different data in different scenarios, and the level of compliance attention should differ.

AI scenario	Data used	Compliance risk
AI greetings / draft phrasings	Name, role, recent activity	Medium
Recognition drafter	Name, projects, shared actions	Medium
Conversational survey	Free-text responses, identity link	High
Engagement intelligence / signals	Behavioral data across modules	High
Onboarding path generation	Role, experience, progress	Medium
Manager Coach briefs	1:1 history, team signals	High

What this shows: most AI scenarios are medium- to high-risk, and each requires its own controls. Not "we have AI in general," but "each AI feature has its own compliance profile." That's the discipline that separates a mature vendor from one meeting a regulator for the first time.

And a separate, important point: passing data through an LLM is processing of personal data. When you send a prompt with an employee's name and context to OpenAI or another model, you transfer PII to a third party. This requires, at minimum, contractual terms with the model provider, and often the subject's consent as well.

k≥5 Anonymity — Technical, Not Declarative

The most common trick in HR-tech marketing: "our surveys guarantee anonymity." When you dig in, it turns out HR can filter survey results by a department of 3 people, and for two of them it's already obvious who answered what.

That's not anonymity. It's a declaration of anonymity.

k≥5 anonymity means: aggregated data (charts, averages, distributions) is not shown if a cohort has fewer than 5 unique respondents. If an HR filter yields a cohort of 4, the system shows "insufficient data to display." No percentages, no charts, no "1 of 4 disagree" — because from that you could infer who it is.

To implement it correctly means doing it at the SQL-query level, not the UI level:

SELECT department, AVG(score), COUNT(*)
FROM survey_responses
WHERE survey_id = X
GROUP BY department
HAVING COUNT(*) >= 5

If you have a UI-side filter ("don't show cohorts <5") but the data itself is accessible through the API, it can be bypassed. SQL-level protection can't be.

The GDPR doesn't spell out "k≥5" by name, but the requirement to protect against re-identification absolutely exists. And in any serious procurement, "how is your survey anonymity implemented" is a standard question. A good answer: "at the SQL level, no UI filter bypasses it." A bad answer: "our policy says we don't show results for small cohorts."

And this rule applies not only to surveys. Every dashboard in engagement intelligence, every signal-based analytic, must follow k≥5 at the SQL level. Otherwise it's not analytics, it's a potential source of uncontrolled employee re-identification.

The Regional and Global Data Planes

For companies with employees across jurisdictions, a separate, important point. The same product can operate in two different legal spaces, and this affects the architecture.

EU employees — GDPR. Data hosted in an EU region, consent in GDPR form, AI models either locally hosted or covered by appropriate transfer safeguards, DPAs with providers under GDPR terms.

Employees elsewhere — CCPA (California), UK GDPR, and local laws. Data may live in the relevant regional cloud, AI models in their respective jurisdictions, consent in the locally required form, and SOC 2 / ISO 27001 certifications expected from the vendor.

A solution that works: a dual data plane. This isn't "hiding data" or "getting around the law." It's a lawful split of the product into two deployments, each serving its jurisdiction by its own rules:

• Regional plane. Servers in the required region, models hosted or contractually localized for that region, DPAs with LLM providers covering that territory, a separate domain.
• Global plane. Servers in EU/US depending on the client's region, models from international providers (OpenAI, Anthropic, Google), a GDPR-compliant DPA, a separate domain.

The codebase is shared; the deployments are separate. Data is not mixed between planes. A CHRO with teams in, say, Germany and the US would have two accounts — one in the EU plane for EU employees, one in the global plane for the rest. And that's correct from a compliance standpoint, even if it looks a little cumbersome.

This is normal practice for mature HR tech in 2026. If a vendor offers "a single global cloud" for EU employees too, ask them one question: "Where is EU employees' data physically stored?" If the answer isn't "in the EU" (or under valid transfer safeguards), you already have a GDPR problem.

A Compliance Checklist Before Buying AI HR Tech

One of the main artifacts of this article. Eight questions worth asking a vendor before buying an AI-HR system.

1. Where is our employees' personal data physically stored?
2. Which LLM providers are used, and under what contractual terms?
3. Is there a signed DPA (Data Processing Agreement)?
4. How is survey anonymity implemented — at the UI or SQL level?
5. What is the consent mechanism for AI processing of behavioral data?
6. Which certifications does the vendor hold (SOC 2, ISO 27001)?
7. Can data residency be separated for different jurisdictions?
8. How are LLM prompts logged, and for how long are they retained?

Red flag #1 — the vendor answers "trust us" or "everything's secure with us." That's not an answer to a compliance question. There should be concrete technical and legal confirmations.

Red flag #2 — the vendor offers "a single global cloud" for EU users. That's either ignorance of the GDPR or a decision to ignore it. Either way, a reason not to sign.

Red flag #3 — the vendor can't show a DPA, or strongly resists signing one. The DPA is a basic legal instrument; without it, you have no compliance argument to make to a regulator.

If all 8 questions are answered with clear, concrete responses, you have an argument to bring to your lawyer and your board. If the vendor goes quiet on any one, it's a signal that compliance isn't a priority for them, and you're buying risk along with the product.

The Bottom Line

Data-protection law + AI isn't a bogeyman or a reason to ban AI in HR. It's an operational discipline in which:

• Each AI scenario has its own compliance profile. AI greetings — low risk; a conversational survey — high. Treating everything the same is a mistake in both directions.
• k≥5 anonymity is technical, at the SQL level. A "we're all anonymous" declaration doesn't count.
• A dual data plane is the norm, not a fringe option. If you have both EU and international employees, two deployments are the only honest path.
• Pre-purchase compliance is 8 concrete questions with verifiable answers. Not "trust," but a DPA + certifications + a clear data architecture.

And most importantly — this isn't an area where you can "fix it later." Rolling out AI without a compliance framework from the start means that, by the time a regulator reviews you, you'll have several years of data that can't retroactively be made compliant. Build the framework upfront, and AI can be used calmly and broadly.

Next, we'll dig into why we rewrote our achievements system from scratch and made it feel like Duolingo, rather than corporate hardware with certificates.

If you want the procurement compliance checklist with an expanded 30-point list and a DPA template, it's linked in the card. No signup, in Google Docs, copy it and adapt it for your legal team.