AI Skills Inference: Building a Skills Inventory Automatically

By Kevin Kim · Updated Oct 11, 2026

AI skills inference is the use of machine learning and language models to work out which skills each employee has, and at what level, from evidence you already hold (profiles, CVs, job history, project work, learning records, feedback), and to map those skills to a shared taxonomy so the whole company can search and compare them. It replaces the old approach of asking everyone to tick boxes in a form that goes stale in a month.

This guide is for HR leaders, talent and learning heads, and managers who've been told to "get a skills inventory" and don't want a six-month self-assessment campaign. It covers what the technology does, what data it needs, how a taxonomy fits, how to validate the output, and where privacy and fairness bite. It sits inside the AI in HR section and feeds directly into the AI internal talent marketplace and AI in learning and development.

Key Facts

• ESCO, the European Commission's multilingual classification, describes 3,039 occupations and 13,939 skills linked to them, translated into 28 languages, and it lists matching jobseekers to jobs by skills as one use (ESCO).
• O*NET, the US occupational database, is updated quarterly, and its 31.0 release updated 208 occupations (O*NET Resource Center).
• The World Economic Forum's Future of Jobs Report 2025 expects 39% of workers' existing skill sets to be transformed or become outdated over 2025 to 2030, down from 44% in 2023 and a peak of 57% in 2020 (WEF).
• The same report finds that for every 100 workers, 59 would need training by 2030, and 11 are unlikely to get the reskilling they need (WEF).
• GDPR Recital 39 says every reasonable step should be taken to ensure inaccurate personal data is rectified or deleted, which applies directly to inferred skills (EUR-Lex).

What Skills Inference Actually Does

In ACE Framework terms, skills inference ingests text and structured HR data, analyzes it to extract and classify skills, and predicts a proficiency or likelihood for each skill a person holds or could quickly acquire. It's an extraction-and-classification pattern with a recommendation layer on top.

Four jobs are bundled together under the label:

1. Extraction. Pull skill mentions out of CVs, profiles, job descriptions, project write-ups and course titles.
2. Normalization. Map "ran SQL reports", "wrote database queries" and "data analysis in SQL" to one entry in a taxonomy, so the same skill isn't counted three ways.
3. Inference. Go beyond what's written. Someone who led a supplier negotiation, managed a budget and wrote the contract summary probably has negotiation and commercial skills even if no document says so.
4. Levelling. Estimate how strong the skill is, using evidence such as recency, depth of the project, certifications and peer or manager input.

The third job is where AI earns its place, and also where it's most likely to be wrong. Extraction is largely solved. Inference is a probability, and your process should treat it as one.

Where the Evidence Comes From

A skills inventory is only as good as the evidence behind it. Different sources tell you different things.

The best inventories combine several sources and let evidence agree or disagree. A skill backed by a project record, a certification and a manager endorsement is solid. A skill that appears only in one old CV bullet is a weak signal and should be shown that way. For the data side, see HR data foundations for AI, because inference quality tracks data quality almost one for one.

Building a Skills Taxonomy

A taxonomy is the shared vocabulary that turns free text into comparable data. Without one, "stakeholder management", "managing stakeholders" and "client relationship skills" are three different things and you can't count anyone.

You have three realistic options.

Adopt a public taxonomy. ESCO and ONET are the two reference points most teams start from. ESCO is built to give a common language across countries and says its skills are linked to occupations and available in 28 languages, which matters for multinational workforces (ESCO). ONET describes work and worker characteristics for US occupations and refreshes on a quarterly cycle (O*NET Resource Center). Both are public references, which makes your data easier to share and audit.

Use a vendor's proprietary taxonomy. Many talent platforms ship their own. It's fast to start, but you're tied to a vendor's definitions, and moving later means re-mapping everything. Ask for a mapping to ESCO or O*NET so you keep an exit.

Build your own. Needed only when your business has specialist skills that no public list covers, such as a specific machine, regulation or product. Even then, start from a public base and add a thin custom layer on top.

Whichever route you take, a few design choices matter more than the choice of list:

• Keep it small enough to use. Thousands of fine-grained skills overwhelm managers. Many companies group skills into a few hundred that map to real decisions about hiring, moving and training.
• Separate skill, proficiency and evidence. "Python" is the skill, "advanced" is the level, and "shipped two production services in 2025" is the evidence.
• Assign an owner. Skills change, so someone has to add, merge and retire them. The WEF figure above, 39% of skill sets transformed by 2030, is the reason this can't be a one-off project. For how fast skills decay, see skills half-life and continuous reskilling.
• Link to your competency model. Skills are what people can do. Competencies are the broader behaviors you expect in a role. Your core competencies framework should reference skills, not duplicate them.

Real Examples by Function

Talent acquisition. A recruiter needs a data engineer. Instead of searching job titles, the system finds employees whose project history and learning records add up to the needed skills, and flags three internal candidates before the role is posted externally.

Learning and development. L&D compares the inferred skills of the customer success team against what the next two years of product plans demand. The gap in analytics and onboarding design becomes the training budget, with no survey needed. This is the same logic described in AI in learning and development.

Internal mobility. A warehouse supervisor's profile shows planning, safety compliance and team coaching, which map closely to an operations planner role. The inference surfaces a move nobody had thought of. This feeds the AI internal talent marketplace.

Workforce planning. A finance director asks how many people could be redeployed to a new regulatory reporting team within a quarter. The inventory answers in hours, not weeks, by counting adjacent skills.

Managers. A project lead building a team sees suggested people with their evidence and confidence, and corrects the one suggestion that's clearly wrong. That correction improves the system.

How to Implement Skills Inference Step by Step

1. Name the decisions first. List the two or three decisions the inventory will inform, such as internal hiring, training budgets or redeployment. If you can't name them, you'll build a database nobody uses.
2. Pick the taxonomy. Choose ESCO, O*NET or a vendor's, and decide how many skills you'll actually track. Write the rules for merging and retiring skills.
3. Inventory your data. Find where CVs, role histories, learning records, project data and feedback live, who owns them, and how clean they are. Fix identifiers so one person isn't two records.
4. Check the legal basis. Decide which sources you may use for this purpose, what employees will be told, and whether a data protection impact assessment is needed. Involve legal and works councils early.
5. Run a pilot on one function. Choose one team with a clear use case, such as a customer support or finance team.
6. Let the model infer, then show the evidence. Every inferred skill should carry its source and a confidence level. No evidence, no skill.
7. Validate with people. Ask employees to confirm, correct or add skills, and ask managers to review their team. Treat disagreements as data about where the model fails.
8. Measure against a gold standard. For a sample, compare inferred skills to a trusted source such as an assessment or a careful manager review. Track precision (how many inferred skills are right) and recall (how many real skills were found).
9. Connect it to a decision. Feed the inventory into one real workflow, such as internal job matching or a training plan, and check whether outcomes improve.
10. Maintain it. Refresh evidence continuously, re-check accuracy at least yearly, and review the taxonomy on a schedule.

Validating the Output

Validation is where most projects either earn trust or lose it. Four checks are worth building in.

Employee confirmation. People know their own skills better than any model. A simple view where they accept, edit or remove inferred skills gives you ground truth and gives them agency. It also surfaces skills the model can't see, such as unpaid or community work.

Manager calibration. Managers review inferred levels for their team, ideally together, so that "advanced" means the same thing across groups.

Sample audits. Pull a random sample, compare to a stronger source, and calculate error rates by skill type. Soft skills such as communication or judgement are usually inferred less reliably than technical skills with clear artifacts.

Drift checks. Skills language changes, new tools appear and old ones fade. A model tuned last year will misread this year's job postings. Re-test on a schedule.

Be honest about what the number means. A skill shown as "inferred, medium confidence" is a lead for a conversation, not a qualification. If you let managers treat a model's guess as a certified fact, you've replaced a stale form with an unaccountable one.

Privacy, Fairness and Legal Limits

An inferred skill is personal data about a person, even though they never typed it in. Treat it that way.

Purpose limitation. Data collected for payroll or compliance shouldn't quietly feed a skills model. GDPR Recital 50 says further processing for a new purpose is generally allowed only if compatible with the original one (EUR-Lex). Document the purpose and tell employees.

Accuracy and correction. Because inferences can be wrong, people need a way to see and fix them. Recital 39 expects inaccurate data to be rectified or deleted, and Recital 71 describes a right not to be subject to a decision made by automated processing with legal or similarly significant effects (EUR-Lex). A skills score used as the sole basis for a redundancy or promotion decision would sit squarely in that territory.

Employment AI is high-risk in the EU. The European Commission lists AI tools for employment and worker management as high-risk, with those rules applying from 2 December 2027 (European Commission). Using inference to decide who is considered for roles or training may fall under that, so check with counsel. Rules differ outside the EU and are changing, so get local advice.

Bias. If the model learns from past promotions, it can learn who got promoted rather than who is skilled. Language also differs by background: some groups describe their work in modest terms, others in inflated terms, and extraction can reward the latter. Compare inferred skill coverage across gender, age, location and role family, and look for groups who are systematically under-described. Data minimization. Use work-related evidence, not private social media, personal messages or monitoring data. If a signal requires watching people to get it, it's the wrong signal.

Visibility. Decide who sees what. Employees should see their own profile. Managers might see their team's. Broad search by recruiters across the company should be limited to consented or role-relevant fields.

Common Pitfalls

• Starting with the tool, not the decision. A skills inventory without a use case becomes shelfware.
• Trusting inferred levels. Presence of a skill is easier to infer than depth. Show confidence.
• Counting course completions as skills. Finishing a module isn't the same as applying it.
• Ignoring taxonomy upkeep. Without an owner, duplicates and dead skills pile up within a year.
• Treating the inventory as a database of record. It's a living estimate, and it needs correction loops.
• Skipping employees. A system that is done to people, not with them, loses trust and data quality fast.
• Using it for high-stakes decisions too early. Start with opportunities (matching, learning), not penalties (selection for cuts).
• Forgetting adjacent skills. The most valuable output is often who is close to a skill, so reskilling is short.

Where to Go Next

Skills inference is the data layer. What you do with it decides its value. If the aim is moving people into new roles, read the AI internal talent marketplace guide. If it's closing gaps, see AI in learning and development. For the wider set of analytics around it, see people analytics and AI. And to query the resulting inventory in plain language, see AI for HR reporting.