Expert finding & skills mapping

In most organisations nobody knows who actually knows what: the person who solved the same problem two years ago sits in another department, and HR skills fields are empty or outdated. AI builds skill profiles from the work people actually produce (documents, tickets, code, projects), maps them onto a skills taxonomy and answers "who can help with X?" with evidence. The key design decision is the boundary: finding a colleague to ask is low-risk; using the same data to rate, rank or allocate employees quickly becomes a high-risk HR system with works-council and GDPR implications.

Problem & value

• Today: experts are found through hallway knowledge, mailing-list questions and stale competency spreadsheets. Self-declared skills in HR systems are rarely maintained. Staff leave and their know-how is lost; projects are staffed from the same few known names; internal vacancies are filled externally because internal candidates are invisible.
• AI value: (1) expert location - semantic search over people via the evidence they produced; (2) skills inference - turning unstructured traces into normalised skill tags; (3) skills inventory - an aggregated view for workforce planning, upskilling and succession; (4) question routing - suggest the right person or channel when a question arrives.
• Standards help: ESCO, the European Commission's multilingual classification, lists 3,039 occupations and 13,939 skills in 28 languages, giving a free, GDPR-neutral common vocabulary [1].
• No credible universal ROI figure exists. Vendor claims about faster staffing or more internal moves are mostly self-reported; measure your own baseline (time to find an expert, share of internal fills) instead of relying on them.

Variants

• Enterprise talent marketplace: internal job and project matching, mentoring, gig assignments (skills inference tied to the HR suite).
• Engineering/code-owner finder: expertise derived from commits, code reviews, incident tickets (developer audience; often the easiest start because the data is work product, not HR data).
• Consulting / professional services: staffing proposals matched to past project references and certifications.
• Research & universities: find collaborators and reviewers from publications and grants (see KNOW-008).
• Public sector: competence registers for crisis staffing and cross-agency knowledge, typically with strict works-council/staff-council co-determination.
• Question routing in chat: a bot in Teams/Slack that proposes an expert or a past answer (links to KNOW-002, KNOW-011).
• SMB: a lightweight skills matrix plus search over the wiki's authors; a full inference engine is usually overkill below ~200 staff.
• Private use: not applicable in the narrow sense; the closest analogue is personal CV/skills tracking (see KNOW-018).

How it works

sources (HR master data, wiki, DMS, tickets, git, project reports, CVs)
  -> ingestion with permission check + PII minimisation (guardrails)
  -> evidence extraction (document parsing, authorship, role in project)
  -> skill extraction & normalisation to taxonomy (LLM + NER classifier, ESCO / internal model)
  -> person-skill-evidence graph (skill, level estimate, recency, source links)
  -> employee review: confirm / correct / hide skills (opt-in visibility)
  -> search & ranking (hybrid BM25 + embeddings + reranker, filters: location, language, availability)
  -> UI / chat / API  ->  contact request or question routing

• Skill extraction: an LLM maps text to taxonomy IDs; a fine-tuned encoder classifier is cheaper at volume. Multilingual embeddings (e.g. BGE-M3, MIT licence, >100 languages [4]) handle German and English mixed content.
• Evidence over assertion: every inferred skill carries links to the underlying documents/projects and a recency date; skills decay without fresh evidence.
• Graph: a knowledge graph of people - projects - skills - documents enables multi-hop queries ("who worked with customer X on topic Y?"); see KNOW-013.
• Human-in-the-loop: employees see, correct and can suppress their own inferred profile; managers never see raw private traces. Expert contact is a request, not an assignment.

Data preparation

Data sources are HR profiles and skills lists, project and ticket histories, documents authored by staff, code repositories and training records. In an SMB they sit in the HR system, Excel sheets, the intranet, file shares and mail. Typical gaps: outdated or empty profiles, free-text skill names without a common vocabulary, authorship missing from documents, personal data with a different original purpose, and unclear consent or access rights.

Preparation steps: (1) check purpose, legal basis and works agreement before reusing any data ([PREP-025], [PREP-024]); (2) inventory sources and owners ([PREP-001], [PREP-004]); (3) clean and structure skills tables ([PREP-011]); (4) build a skills taxonomy with synonyms ([PREP-015], [PREP-019]); (5) restrict to work-related content and pseudonymise where possible ([PREP-022]); (6) check permissions so results respect access rights ([PREP-023]). Tools: spreadsheet clean-up, OpenRefine, HR suite exports. Preparation takes about 40 percent of the effort; employee self-maintained profiles are the most reliable data. See [GUIDE-003].

Implementation paths

Which path for whom

• SMB (A): HR suites and intranet products increasingly include skills and expert search, which avoids building a system on employee data.
• Enterprise (B): Skills data from HR, projects and code needs custom integration with strict access control, which an own build on cloud APIs handles well.
• Developer (C): Open-source search, a graph store and open-weight embeddings keep personal data in house and under full control.
• Public (C): Employee data in public bodies calls for sovereign hosting and open components, subject to staff council agreement.

Path A - Buy (recommended for most organisations with an HR suite)

• Skills in the HR/talent suite: Workday (Skills Cloud), SAP SuccessFactors (Talent Intelligence Hub), Oracle HCM, Cornerstone, Microsoft Viva Skills / People Skills in Microsoft 365 (inference from M365 signals - check current licensing and EU data-boundary status). SAP and Personio are EU vendors; Personio targets SMBs.
• Talent-intelligence / marketplace platforms: Eightfold, Gloat, Beamery, Lightcast (skills data), SmartRecruiters-type recruiting suites add internal mobility. Most are US-based - verify EU hosting, sub-processors and works-council compatibility.
• Enterprise search with people results: Glean, Microsoft 365 Copilot people search, Elastic- and Sinequa-based setups (Sinequa is French); Starmind (Swiss) specialises in routing questions to internal experts.
• Choose A when: you already run an HR suite or M365, want an inventory rather than a research project, and can configure visibility and opt-in properly.

Path B - Build on cloud APIs

• Models: an EU-hostable frontier LLM for skill extraction and answer summaries (Claude, Gemini, GPT via EU regions, or Mistral as an EU provider); embedding API plus reranker for search.
• Stack: connectors to wiki/DMS/git/ticketing (reuse the KNOW-002 ingestion), a graph or relational store for person-skill-evidence, a simple UI or Teams/Slack bot, n8n or Power Automate for sync jobs.
• Rule: send only work artefacts needed for extraction, not full HR records; pseudonymise before the API call where possible and store the mapping internally.
• Choose B when: you need custom sources (code, tickets, customer projects) or a bespoke taxonomy.

Path C - Self-host (open source)

• Models: open-weight multilingual embeddings (BGE-M3 [4]), an open reranker, and a mid-size instruction LLM (Qwen3 / Mistral / Llama family, 8-30B) served via vLLM or Ollama for skill tagging.
• Parsing & search: Docling for document ingestion [5], OpenSearch (Apache 2.0) for hybrid search [6], Postgres + pgvector or Qdrant, Neo4j/Memgraph or Apache AGE for the skill graph; ESCO as the taxonomy [1].
• Hardware: HW2 (one 24-32 GB GPU) is sufficient for mid-sized companies; HW1/CPU can run the embedding side alone. Personal data stays on premises, which makes the works-council discussion easier.
• Ops effort: moderate; the hard part is connectors and permission mirroring, not the models.

Path D - Custom training

Worth it only for large employers with a proprietary competency model or domain jargon (e.g. engineering disciplines): fine-tune an encoder to map text to your skill IDs, or train a ranking model on "expert accepted / rejected" feedback. Needs hundreds to thousands of labelled text-skill pairs; employee corrections in the review step are the natural label source. Never train on data whose purpose was not compatible with this use.

State of the art (2026)

• Skills-first HR platforms now ship LLM-based skill inference and normalisation to large taxonomies as a standard feature; the differentiator is data coverage and the quality of the review loop, not the model.
• Hybrid retrieval + rerank over authored content is the practical core of expert finding; pure vector search misses exact product/part names, pure keyword search misses synonyms.
• Taxonomies: ESCO (EU), O*NET (US), proprietary graphs of vendors; mapping between them is automated but imperfect, especially for German compound terms and company-internal jargon.
• Agentic routing: assistants that not only name the expert but draft the request, check calendar availability and summarise relevant prior material (see AGENT-002).
• Limits and failure modes: (1) authorship is not expertise - people who wrote a document may have copied it, and reviewers/mentors leave few traces; (2) tacit and offline knowledge is invisible; (3) LLM-inferred levels ("expert", "advanced") are weakly calibrated - show evidence, not scores; (4) staleness and bias: people with more written output, or with a particular language/style, are over-ranked, and part-time or non-desk workers are under-represented; (5) popular experts get overloaded - add availability and load balancing; (6) permission leaks if the index does not mirror source ACLs.
• No public benchmark measures "expert finding for enterprises" end to end; evaluate with your own gold set (known questions and the experts who answered them).

Shared resources & combinations

• Same stack as retrieval use cases: embedding-text + reranker + vector-db + search-engine as in KNOW-001 (enterprise search) and KNOW-002 (RAG assistant) - one index and one connector layer can serve all three; people become another entity type.
• Graph: shares the knowledge-graph build with KNOW-013 (GraphRAG).
• Content side: KNOW-011 (KB/FAQ generation) reduces expert load by turning answered questions into articles; KNOW-014 (organisational memory) captures what departing experts know; KNOW-027 (SOP generation from expert videos) is the structured follow-up when an expert is about to leave.
• HR neighbour: AGENT-033 (talent sourcing) uses similar skill matching on external candidates - that variant is explicitly high-risk (Annex III 4(a)); keep the data and purposes separate.
• Hardware: one HW2 server hosting embeddings, reranker and a ~8-30B LLM can serve this and the retrieval use cases above.

Effort, cost & KPIs

• Path A: weeks to configure plus a 3-6 month change process (opt-in, communication, works council); licences per employee, often bundled in HR/M365 suites.
• Path B: 2-4 months for a first connector set and UI; API cost is small versus engineering time.
• Path C: 3-5 months incl. connectors and permission mirroring; one GPU server plus part-time ops.
• KPIs: time to find an expert (baseline vs. after), share of expert requests answered, accept/reject rate of suggested experts, share of employees who confirmed their profile, skill-profile freshness, internal fill rate for vacancies, expert-load distribution (avoid hotspots), data-subject requests handled.

People & change

Involve management, the HR lead and the works council before any data is touched; the use case processes employee data, so the DPO joins at the start too. IT and data owners (HR system, intranet, repositories) follow, and employees as end users should help shape the skills taxonomy. Choose a pilot group of volunteers, for example one department, and let them maintain their own profiles ([GUIDE-009]).

Works council: yes. The system analyses documents, tickets and code by person and is objectively suited to monitor performance, so co-determination under §87(1) no. 6 BetrVG applies; the council must also be informed under §90(1) no. 3, may call an expert under §80(3), and §95(2a) matters if results feed selection or staffing decisions ([GUIDE-004]). Public bodies involve the Personalrat. A DPIA under Art. 35 GDPR is likely because people are systematically evaluated ([GUIDE-005]).

Agree in a works agreement that skills are voluntary, visible to the employee, never used for appraisal or dismissal, and that employees can correct or hide entries. AI literacy measures ([GUIDE-006]) and open communication about purpose ([GUIDE-008]) address the typical fear of surveillance. Humans decide on staffing; the system only suggests.

Risks, regulation & compliance

• EU AI Act - depends on purpose. A search tool that suggests a colleague to ask is generally minimal risk (AI literacy duty, Art. 4). As soon as the system is used to allocate tasks based on individual behaviour or personal traits, to evaluate performance, or to decide promotion or termination, or to filter job applications, it falls under Annex III point 4 and becomes high-risk (provider/deployer duties, human oversight, transparency to workers) [3]. Using inferred skills for external recruiting is also Annex III 4(a). Emotion inference from employee communication is prohibited at work (Art. 5(1)(f)) - never include it. Chat-style interfaces need the Art. 50 transparency notice.
• GDPR: skill profiles are personal data of employees. Legal basis is Art. 6 plus national employment law under the Art. 88 opening clause [2]; in Germany §26 BDSG applies, and the CJEU has held (C-34/21, 30 March 2023) that national employment-data rules must meet Art. 88 requirements, so consent is rarely a safe basis in the power imbalance of employment. Do a DPIA, purpose limitation (expert finding only), data minimisation, transparency, access/rectification (employees can see and correct their profile), retention and deletion on leaving.
• Co-determination: in Germany, technical systems that can monitor behaviour or performance trigger works-council co-determination (§87(1) no. 6 BetrVG); agree a works agreement (Betriebsvereinbarung) before pilots with real data. Equivalent bodies exist in other member states.
• Other risks: discrimination through biased inference (gender, part-time, language), chilling effects if staff feel profiled, ACL leaks, over-reliance on a few "visible" experts.
• Mitigations: opt-in or opt-out visibility per employee, evidence display instead of numeric ratings, no use in appraisal or pay, role-based access to aggregates (small groups suppressed), audit log, bias tests on rankings, regular deletion of stale inferences.

Getting started

1. Define the purpose narrowly ("find a colleague to ask") and agree it with the data-protection officer and works council; write the exclusion list (no appraisal, no pay, no monitoring).
2. Pick a taxonomy (ESCO or your competency model) and 2-3 low-risk sources (wiki authorship, ticket resolvers, project references).
3. Build a pilot on one department: ingest, infer skills, let employees review their own profile.
4. Evaluate with a gold set of 50-100 real past questions and the people who answered them; compare against the current way of finding experts.
5. Roll out with a feedback button ("not an expert in this") and measure time-to-expert and acceptance.

Sources

1. European Commission - ESCO, what is ESCO (3,039 occupations, 13,939 skills, 28 languages) - https://esco.ec.europa.eu/en/about-esco/what-esco
2. GDPR Art. 88 - processing in the context of employment - https://gdpr-info.eu/art-88-gdpr/
3. AI Act Annex III, point 4 (employment, workers management) - https://artificialintelligenceact.eu/annex/3/
4. BAAI/bge-m3 model card (MIT, >100 languages, dense/sparse/multi-vector) - https://huggingface.co/BAAI/bge-m3
5. Docling project (MIT, document parsing) - https://github.com/docling-project/docling
6. OpenSearch project (Apache 2.0) - https://github.com/opensearch-project/OpenSearch
7. Regulation (EU) 2024/1689 (AI Act) - https://eur-lex.europa.eu/eli/reg/2024/1689/oj