GDPR & EU AI Act-Proof AI Recruitment Tools

This is not legal advice. It is a practical procurement orientation based on public information as of 29 May 2026, written by people who build recruitment AI, not by lawyers. For your own situation, consult a specialised IT lawyer. Every legal claim below is traceable to the official text via the embedded links.

Compliance is now a procurement criterion, not a formality

Until recently, you could buy a recruitment tool on features and price, and “sort out compliance later.” That window has closed. On 2 August 2026, recruitment AI becomes fully high-risk under the EU AI Act. Three months from now. From that date, hard requirements apply to any system that screens, scores, or proposes candidates, and as a buyer you are co-liable for deploying a tool that doesn’t meet them.

Here’s the point many buyers still underestimate: the law assigns obligations to two parties. The vendor (provider) builds the system to be compliant. But you, the organisation using it (deployer), carry your own set of obligations that you cannot delegate. A rejected candidate who files a complaint, an audit by the Data Protection Authority, or a tip from a competitor: in all those cases the regulator looks at you too.

This guide isn’t about “what is GDPR” or “what is the EU AI Act” as a concept. That’s covered in our deep dive on the EU AI Act for agentic recruitment, which explains the Annex III classification and the article numbers. Here we’re talking about the procurement side. What do you need to see, how do you verify it, and how do the tools you’re probably choosing between compare on documented compliance signals? Plus a list of ten questions to send every supplier upfront, not in the demo.

One note on the timeline first. On 7 May 2026, a political agreement was reached on a “Digital AI Omnibus” that may push the high-risk deadline to December 2027. That agreement has not yet been formally adopted. Until a definitive text exists, plan for 2 August 2026. A deferral that isn’t official yet is no basis for a procurement decision.

Three layers your tool has to pass through

Compliance for recruitment AI isn’t a single checklist but three regimes running in parallel. A tool that scores well on one layer and poorly on another is still a risk.

Layer 1: EU AI Act high-risk (from 2 August 2026)

Recruitment and selection systems are explicitly listed in Annex III, points 4(a) and 4(b) of the EU AI Act. That isn’t interpretation, it’s literal text: AI used for recruitment, for filtering job applications, for evaluating candidates, or for decisions about work-related relationships automatically falls into the highest risk category short of prohibited practices.

What that translates to in concrete obligations, summarised:

Requirement	Article	What it means in recruitment
Risk management	Art. 9	Ongoing register of what can go wrong (bias, faulty scoring, data leak) plus mitigations
Data governance	Art. 10	Training data representative and documented; bias detection as a design principle, not an afterthought
Technical documentation	Art. 11	Architecture, capabilities, limitations, data flows on paper
Logging	Art. 12	Automatic logs per event: who, which input, which output, which decision
Human oversight	Art. 14	A human can understand the output, override it, and stop the system
Accuracy & robustness	Art. 15	Documented accuracy under defined conditions, resilient against manipulation

Those obligations sit primarily with the vendor. But you as a deployer have your own set under Article 26: use the system according to provider instructions, keep your logs for at least six months, inform your workers, and report serious incidents within 72 hours. In certain cases, particularly for public bodies and large employers, a Fundamental Rights Impact Assessment (Article 27) is added on top. Penalties under Article 99 reach up to 15 million euro or 3% of global annual turnover for most violations.

Layer 2: GDPR Article 22 (active for years)

The EU AI Act does not replace the GDPR. Article 22 gives every candidate the right not to be subject to a decision based solely on automated processing that significantly affects them. A rejection on a job application falls under this without question.

The nuance that matters here: Article 22 has exceptions (Art. 22(2)), namely contractual necessity, explicit consent, or a legal basis in EU or member-state law. Those exceptions exist, but in a standard volume-rejection flow they rarely apply. A fully automated rejection without human intervention therefore requires a legal basis that isn’t available in most recruitment processes. It’s not that it’s always forbidden, but the bar is high and the burden of proof lies with you.

And if there is a human in the loop, that involvement must be “meaningful.” The Article 29 Working Party guidelines (WP251) make it explicit that a recruiter routinely clicking “approve” without examining the output does not, in legal terms, constitute human intervention. The green/orange validation layer some tools offer is designed precisely to make this demonstrable: the human has to actively assess, not ceremonially tick off.

Layer 3: ISO 27001 (the security baseline)

ISO 27001:2022 is an international standard for information security. A certified organisation runs an Information Security Management System (ISMS) with 93 controls, audited externally each year. For recruitment data, which carries a lot of personal information, that’s a meaningful signal.

Watch the trap: ISO 27001 is not the same as GDPR compliance and not the same as EU AI Act compliance. It covers most of the technical and organisational security measures the GDPR demands under Article 32, but it says nothing about candidate rights, automated decision-making, or bias in matching. A vendor whose only compliance answer is “ISO 27001 certified” has answered just one of the three layers. Push on the other two.

How the tools score on compliance signals

Below is a comparison based on what the vendors document publicly as of 29 May 2026. Important to read as intended: “not stated on public pages” does not mean “non-compliant.” It means the claim isn’t publicly verifiable and that you as a deployer carry the verification burden. In a high-risk context, that’s a reason to ask further, not to write a tool off automatically.

Tool	GDPR	ISO 27001	EU hosting	Other
Simply	✓	✓ certified	✓ (NL-HQ)	EU AI Act claim for AI Matching; SOC 2 not stated
In2Dialog	✓ processor agreement	not stated	NL-HQ, location not explicit	SOC not stated
Metaview	✓ + DPA	not stated	AWS UK (adequacy, not EEA)	SOC 2 Type II ✓
Carv	✓ GDPR readiness	not stated	not stated	Trust Center on request; NYC Local Law 144
Fireflies	✓ (Enterprise tier)	not stated	US default, EU = paid add-on	SOC 2 Type II ✓
Otter	no public docs (standard tiers)	not stated	not stated	highest verification effort for EU buyer

A short note per tool, so you know where to push.

Simply

Simply documents GDPR conformity and an ISO 27001 certification, hosting within the EU (Dutch headquarters), and claims EU AI Act compliance for the AI Matching functionality. SOC 2 is not stated. Ask us for the exact scope of that EU AI Act claim, and, as with every vendor, for the ISO certificate and the DPA.

In2Dialog

In2Dialog works with a processor agreement and is a Dutch company. The exact hosting location is not explicitly documented, and ISO 27001 or SOC 2 are not mentioned on public pages. For a Dutch buyer, the processor agreement is a good starting point; ask for the hosting location and any certifications.

Metaview

Metaview documents GDPR plus a Data Processing Agreement and a SOC 2 Type II report. ISO 27001 is not stated. Hosting runs on AWS in the United Kingdom. Note: the UK has an adequacy decision from the European Commission, so transfer is permitted, but the UK is not an EEA country. Ask specifically how the DPA covers that UK transfer and which Standard Contractual Clauses or adequacy basis applies.

Carv

Carv has a Trust Center (compliance.carv.com, behind a request-access wall) plus documented GDPR readiness and compliance with NYC Local Law 144 (the bias-audit law for automated hiring tools in New York). ISO 27001, SOC 2, and EU hosting are not stated on the public pages. Request access to the Trust Center and check EU hosting and certifications there.

Fireflies

Fireflies has a SOC 2 Type II report. GDPR conformity sits on the Enterprise tier. Important for EU buyers: the default hosting is in the US, and EU data storage is a paid add-on available only on Enterprise, not the default. There is no recruitment-specific EU AI Act claim. If you’re considering Fireflies for an EU recruitment context, the Enterprise tier with EU storage is effectively the floor, not an option.

Otter

On its standard tiers, Otter publishes no GDPR or EU-hosting documentation. For an EU recruitment buyer, that’s the highest verification effort of this list: you’ll have to ask what is actually arranged and on which tier. A general-purpose meeting notetaker isn’t built around the Annex III requirements, and you notice that in the documentation.

The pattern: the recruitment-specific tools (Simply, In2Dialog, Metaview, Carv) sit closer to the Annex III reality than the general notetakers (Fireflies, Otter), simply because their product category falls directly under it. But none of them releases you from your own deployer obligations.

The 10 questions to ask every vendor

Send these ten questions upfront by email, not in the demo. A vendor who takes a week to answer specifically gives you information about how an implementation will run later. A vendor who tries to flip the questions to “just trust us” doesn’t fit a high-risk AI context to begin with.

1. High-risk and conformity. Do you acknowledge that your tool falls under Annex III high-risk, and which conformity assessment have you completed? For recruitment AI, the internal assessment via Article 43 is common. Ask which document attests to it.
2. Risk-management dossier (Art. 9). Can you provide a risk-management dossier for the system we will use, with identification and mitigation of bias, accuracy, and data risks?
3. Per-candidate logging (Art. 12). Can you show an audit log of one actual decision: which input went in, which output came out, which reasoning, with timestamp and correlation ID, retrievable per candidate?
4. Explainability (Art. 14). How is a matching or scoring decision explained per criterion, ideally clickable back to the CV field or transcript line on which it is based?
5. Confirmation gates (Art. 14 / GDPR 22). Which actions require explicit human confirmation before execution? Irreversible actions such as a rejection email should sit behind a confirmation gate, not behind a toggle that can be accidentally turned off.
6. Hosting and DPA. Where does the data physically reside, and can you provide a signed Data Processing Agreement? For transfers outside the EEA: on what basis (adequacy, SCCs)?
7. ISO 27001 certificate. Are you ISO 27001:2022 certified, and can you share the current certificate plus the scope statement? (Note: the certificate covers security, not the candidate rights under the GDPR.)
8. Protected attributes (Art. 10). How do you guarantee that protected attributes (date of birth, gender, ethnicity) play no role in matching, not even indirectly via correlated features such as postcode?
9. Incident process (Art. 26). What is your incident-reporting process, and how do you support us in the 72-hour reporting duty as a deployer?
10. Training and retention. Do you use our candidate data to train your models? If not, how is that technically guaranteed, and what is the retention policy on termination?

A vendor giving a specific, documented answer on all ten is ready for 2 August. A vendor saying “we’re working on it” on three or more points isn’t.

How Simply meets these requirements

The following is how Simply meets the three layers in practice, not as a pitch but as a reference for what compliant looks like under the hood. Other vendors can have the same or better solutions. Run the ten questions on everyone, including us.

Logging and traceability (Article 12). The transparency layer makes every conclusion clickable back to its source. A summary sentence links back to the exact transcript passage and the corresponding audio fragment; a matching score breaks down per criterion with a reference to the CV field it rests on. That is exactly the traceability Article 12 demands, and at the same time the evidence you need when a candidate asks, under GDPR Article 22, why a decision turned out the way it did.

Human review (Article 14, GDPR 22). The smart data entry works with a green/orange validation system: what the AI recognises with high confidence shows green, what’s doubtful shows orange and requires an active human check. That makes human involvement demonstrable rather than ceremonial. Actions that cost money, time, or reputation, such as an email to a candidate, require explicit confirmation before sending.

Bias protection (Article 10). Protected attributes play no role in matching, not even indirectly via the embeddings. The AI matching is built to analyse based on what was actually said and shown, not on proxy variables.

Security and data governance. Simply is ISO 27001 certified and GDPR-compliant, hosts within the EU, and does not use customer data to train models. Customer data is kept strictly siloed per tenant.

One thing we make explicit: Simply is the ATS itself, not a layer running alongside one. That’s relevant for the role split under the Act. Simply is the provider of the AI functionality and you are the deployer, and because the candidate data stays inside one system there is no transfer between two vendors to paper over. What stays yours are the deployer duties themselves: informing candidates and staff, the human review, and keeping the logs behind it, and we think along on those during an implementation.

---

The compliance pressure doesn’t fall the same way for every agency. For staffing agencies, where rejections are sent at scale, the Article 22 flow is the sharpest bottleneck: with hundreds of rejections per week, the human review has to be watertight and demonstrable. For recruitment and selection agencies, where every candidate represents a commercial relationship, the explainability layer carries more weight, because a candidate rejected today can be the client of tomorrow.

For the broader legal frame: read the EU AI Act for agentic recruitment. For the practical tool choice per type of work, we also have pieces on AI tools that work with your ATS, what a modern ATS needs to do in 2026, AI notetakers for recruitment compared, and conversation intelligence for recruitment.

Want to test whether your current stack will be compliant on 2 August 2026? Request a demo, not as a sales pitch but as a structured compliance walkthrough where we apply the ten questions to your specific setup.