Job seekers face thousands of postings with inconsistent titles and requirements; employers and public employment services face the mirror problem. Recommender systems combining text embeddings, skills taxonomies and behavioural signals surface relevant vacancies and plausible career moves, and LLMs explain the match and the skill gap. The decisive question in the EU is who the system acts for: recommendations shown to the seeker are low-risk, whereas ranking candidates for an employer or steering jobseekers on behalf of an authority can be high-risk under the AI Act.
Problem & value
- Today: keyword search and manual filters on job boards; job alerts by title; caseworkers in public employment services (PES) matching by hand. Titles differ across firms and languages, and seekers often do not know which adjacent roles fit their skills.
- AI value: semantic matching beyond keywords, skills-based (not title-based) matching, cross-lingual retrieval, career-transition suggestions, and explanations that build trust. Better matches mean more relevant applications and less time to hire; for platforms, higher engagement.
- Evidence base: no universal uplift figure exists; platforms report A/B-tested engagement gains internally, and PES evaluations vary by country. Measure it on your own data [1][2].
- Policy context: the European skills taxonomy ESCO and the Europass/EURES portals provide shared vocabularies and cross-border vacancy data that matching systems can build on [3].
Variants
- Job board / marketplace: large-scale two-sided recommender (jobs to seekers, seekers to employers).
- Public employment service: matching and career guidance support for caseworkers and clients; strong governance requirements (see PRED-029 for profiling/risk scoring, which is a separate and more sensitive use case).
- Employer career site / internal mobility: recommend open roles and development paths to employees or alumni (talent marketplace).
- University career services: match students to internships and graduate roles; see REC-018.
- Private use: an individual uses a career assistant to explore roles and gaps; see PERS-012.
- Out of scope here: employer-side CV screening and ranking of candidates (AGENT-008), sourcing agents (AGENT-033).
How it works
- profile/CV + vacancies ingestion
- parsing & normalisation (skills/occupations mapped to ESCO, location, salary)
- embeddings (seeker, job) + vector index
- candidate retrieval (two-tower / ANN, hybrid with BM25 and hard filters)
- ranking (learning-to-rank on clicks/applications + business rules)
- LLM explanation & skill-gap summary
- delivery (feed, alerts, caseworker view)
- feedback events
- Retrieval: two-tower embedding models over profile and job text, combined with keyword search and hard constraints (location, work permit, language, remote policy).
- Ranking: gradient-boosted or neural rankers trained on implicit feedback (clicks, saves, applications); beware that application is the weak, biased signal and hire outcome is rarely observed.
- Skills layer: ESCO mapping gives multilingual, explainable skill overlap and adjacent-occupation links.
- Career paths: transitions mined from anonymised career histories or taxonomy links; LLM turns them into advice.
- Human-in-the-loop: in PES settings the caseworker reviews and decides; the seeker can always correct their profile, switch off personalisation and see why a job was shown.
Data preparation
Two data sets matter: vacancies and seeker profiles or CVs. Vacancies live in the ATS, career site, job boards and sometimes only in Word files or PDFs; profiles in the ATS, an HR system, caseworker software or as uploaded CVs (PDF, scans). Skill taxonomies are rarely maintained.
Typical gaps: free-text job ads without structure, inconsistent job titles, missing location or salary, scanned or multi-column CVs, duplicate candidates, no consent or retention records, and missing outcome data (hires), so only clicks and applications exist as weak labels. Access rights to applicant data are often too broad.
Preparation steps: - Parse CVs and ads into structured fields (DOC-014, PREP-007) and digitise paper files if needed (PREP-006). - Map titles and skills to ESCO and define category schemes (PREP-019, PREP-015). - Deduplicate and tidy tables (PREP-011); set consent and deletion rules (PREP-025). - Pseudonymise training data (PREP-022) and restrict access (PREP-023). - Build a test set with recruiters or caseworkers, including fairness checks (PREP-018).
Tools: document parsers, ESCO API, a vector database and a spreadsheet. Expect about 30 to 40 percent of effort in data work. See GUIDE-003.
Implementation paths
Which path for whom
- enterprise: Path B, because a career site or HR system needs matching integrated with own vacancies, ATS data and consent flows.
- public: Path C, because employment agencies and municipalities need sovereign EU or German hosting, explainability and control under procurement and public-law rules.
- developer: Path C, because open embedding and ranking models plus ESCO give full control over bias testing and explanations.
- private: Path A, because job-board recommendations and local apps are enough for individual job seekers.
Path A — Buy (off-the-shelf)
- Job-board and career-site platforms with built-in matching: LinkedIn, Indeed, StepStone (DE), Jobware, Xing/New Work (DE), Welcome to the Jungle (FR), Jobtome; for employers, ATS/career-site products with job recommendations (e.g. SmartRecruiters, Personio, Join, softgarden - the latter three EU).
- Talent marketplace / internal mobility: Eightfold, Gloat, Beamery, SAP SuccessFactors Opportunity Marketplace; check EU data residency and AI Act documentation.
- Choose A when: you run a career site or an HR system and need recommendations as a feature, not a product.
Path B — Build on cloud APIs
- Embeddings & ranking: managed embedding models (Mistral Embed, Cohere Embed multilingual, OpenAI, Google, Azure OpenAI in EU regions) plus a vector store (Qdrant - EU, Elasticsearch/OpenSearch, Azure AI Search, Vertex AI Vector Search) and a reranker (Cohere Rerank, Voyage).
- Managed recommenders: Amazon Personalize, Google Vertex AI Search for commerce/recommendations (not job-specific; evaluate fit), Azure AI Search.
- LLM layer: Claude, Gemini, GPT or Mistral models with structured output for explanations and skill-gap summaries; use EU-region endpoints.
- Taxonomy: ESCO web service/API and downloadable datasets for skills normalisation [3].
- Choose B when: you have your own vacancy and interaction data and need custom ranking logic.
Path C — Self-host (open source)
- Embeddings/rerankers: BGE-M3, multilingual-e5, Qwen3-Embedding and Qwen3-Reranker, Jina embeddings.
- Stack: Qdrant, Milvus, pgvector or OpenSearch; recommender libraries such as implicit, LightFM, TorchRec, RecBole; LightGBM/XGBoost for learning-to-rank.
- LLM for explanations: Mistral, Qwen or Llama-family open-weight models via vLLM.
- Hardware: HW2 is sufficient for embeddings, reranking and a mid-size LLM; scale out the index on CPU nodes. Typical for PES and public-sector sovereignty requirements.
Path D — Custom training
Worth it for large platforms with millions of interactions: train two-tower or sequence models (transformers over application histories) and fine-tune a skills-extraction model. Needs interaction logs, outcome labels (hires, retention where legally permitted) and fairness evaluation data.
State of the art (2026)
- Hybrid retrieval (dense + sparse + hard filters) with cross-encoder reranking is the common architecture; LLM rerankers and LLM-generated explanations are increasingly used.
- Skills-based matching replaces title matching; taxonomy-grounded extraction (ESCO) improves multilingual coverage [3].
- Conversational job search: chat assistants that interview the seeker and refine recommendations (see CONV-017 for the employer-side recruiting chatbot).
- Fairness research shows recommenders can reproduce gender and background bias in job ads exposure and ranking; audits of ad delivery have documented skewed delivery by gender in job advertising [4].
- Limits: cold-start users, sparse feedback, stale vacancies and duplicate or fake postings, popularity bias, salary opacity, and LLM explanations that sound plausible but misstate the match. Outcome (hire) labels are scarce, so clicks are used as proxy and can mislead.
Shared resources & combinations
- Same stack as REC-001/REC-002 (recommender, embeddings, vector DB, reranker); one retrieval platform can serve products, content and jobs.
- REC-016 (reciprocal matching) shares two-sided matching methods; REC-018 (course and degree planning) feeds upskilling recommendations.
- AGENT-008 / AGENT-033 (employer-side screening and sourcing) are the opposite side of the market and carry the high-risk obligations; PERS-012 (application assistant) is the natural downstream step.
- DOC-014-style document parsing helps ingest CVs.
Effort, cost & KPIs
- Path A: weeks; subscription per seat or per posting.
- Path B: 3-6 months for data pipelines, ranking, evaluation and consent handling; cost mainly engineering and vector/LLM inference.
- Path C/D: 6-12 months with an ML team; GPU cost is modest, data work dominates.
- KPIs: click-through and application rate per recommendation, relevant-application share, time to first application, placement or hire rate (where measurable), coverage of vacancies, diversity of exposure, complaint and opt-out rates, explanation accuracy.
People & change
Involve management and the department lead (HR, placement service) to define what the recommendation may and may not decide. The works council or staff council comes in at the concept stage: if recruiters or caseworkers are logged or evaluated, §87(1) no. 6 BetrVG (or Personalrat rights under BPersVG and state law) applies; §90(1) no. 3 requires early information, §80(3) allows an AI expert, and §95(2a) covers selection guidelines when AI supports hiring. For pure seeker-facing use without employee monitoring it may not apply, hence "depends".
The DPO is essential: applicant and profile data are personal, a DPIA is likely, and an AVV is needed with every processor (GUIDE-005). Employment-related AI may count as high-risk under Annex III, with duties from 2 Dec 2027; clarify with legal (GUIDE-014). IT and data owners secure access.
AI literacy: support recruiters and caseworkers with training on bias, explanations and overrides (GUIDE-006). Pilot with one job family or one office, with caseworkers confirming every recommendation. Typical concerns: discrimination, opaque scoring and job loss. Address them with bias tests, visible reasons, seeker opt-out and human decision rights (GUIDE-004, GUIDE-008).
Risks, regulation & compliance
- EU AI Act: Annex III point 4 lists AI systems for recruitment and selection (placing targeted job advertisements, analysing and filtering applications, evaluating candidates) and for decisions affecting work relationships as high-risk [5]. A neutral job search or recommendation feed that the seeker uses freely is generally lower risk, but targeted job advertising and systems that filter or rank candidates for employers fall into high-risk territory; a deployer must classify case by case. Public-service use that determines access to benefits or services can also be high-risk (Annex III point 5). High-risk duties: risk management, data governance, logging, human oversight, transparency, conformity assessment. Art. 5: emotion recognition in the workplace is prohibited; do not infer emotions from video or voice for matching. AI literacy (Art. 4) always applies.
- GDPR: CVs and profiles are personal data, possibly special categories (health, disability, ethnicity, inferred from text). Legal basis (consent or contract), data minimisation, retention limits, DPIA for large-scale profiling, Art. 22 limits on solely automated decisions with significant effects, and transparency about logic. Do not use protected attributes or close proxies for ranking.
- Anti-discrimination: EU equal-treatment directives and national law (in Germany the AGG) apply to job advertising and selection; test for disparate exposure across gender and age.
- Platform rules: the Digital Services Act requires transparency on recommender systems of online platforms and a non-profiling option for very large platforms [6]. Platform Work Directive may apply to algorithmic management of platform workers.
- Mitigations: bias audits, explanations in the UI, user controls, human caseworker review, logging, and separate models for seeker-facing recommendation and employer-facing ranking.
Getting started
- Decide whose agent the system is (seeker vs employer vs authority) and document the AI Act classification.
- Inventory vacancy and interaction data; normalise skills and occupations with ESCO.
- Build a hybrid retrieval baseline (BM25 + embeddings + filters) and evaluate offline against saved/applied jobs.
- Add reranking and LLM explanations; run an A/B test with fairness metrics by group.
- Ship user controls (edit profile, opt out of personalisation, feedback) and complete the DPIA.
Sources
- European Commission - ESCO: European Skills, Competences, Qualifications and Occupations - https://esco.ec.europa.eu/en
- European Network of Public Employment Services - https://ec.europa.eu/social/main.jsp?catId=1100
- ESCO web services and download - https://esco.ec.europa.eu/en/use-esco
- Ali et al. (2019), Discrimination through optimization: how Facebook's ad delivery can lead to skewed outcomes - https://arxiv.org/abs/1904.02095
- Regulation (EU) 2024/1689 (AI Act), Annex III - https://eur-lex.europa.eu/eli/reg/2024/1689/oj
- Regulation (EU) 2022/2065 (Digital Services Act) - https://eur-lex.europa.eu/eli/reg/2022/2065/oj
- Qdrant vector database documentation - https://qdrant.tech/documentation/
- BGE-M3 embedding model - https://huggingface.co/BAAI/bge-m3