How we built the AI concepts register

Why the register was needed

Recent developments in AI have brought a growing range of tools, techniques and concepts into everyday workplace language. Much of the terminology is new, unfamiliar or changing quickly. People using SFIA may therefore search for terms such as prompt engineering, AI agents, explainable AI or MLOps, and expect to find SFIA skills with matching names.

SFIA is organised differently. It describes professional work and the levels of responsibility at which people perform it. It does not attempt to maintain a list of current products, techniques or market terminology. This helps SFIA remain stable as technologies change, but it can make relevant skills difficult to find if someone starts with a particular AI term.

The AI concepts register provides a route from that terminology into SFIA. For each concept, it identifies the SFIA skills that people may draw on and indicates how central each skill is to the concept.

A relationship in the register does not mean that an AI concept and a SFIA skill are equivalent. It means that applying, implementing, assuring or governing the concept may involve that skill.

Sources of AI terminology

We used three sources to identify terminology for the first version of the register.

SFIA 9: A framework for AI skills

This SFIA View brings together existing SFIA skills relevant to AI work. It provided the starting point from within SFIA.

Lightcast Open Skills

Lightcast Open Skills provided terminology drawn from labour-market data. It reflects the language used in job advertisements and other employment information, including product names, techniques, system capabilities and broad fields of practice.

We used the Information Technology category and its Artificial Intelligence and Machine Learning subcategory. The extract was taken on 24 July 2026 and contained 366 entries.

During the review, we identified 12 terms that appeared to have been classified outside their appropriate subject area. We shared these with Lightcast, which reviewed them positively and corrected the classifications in a subsequent data update. We have retained a record of those terms so that the figures for the original extract remain traceable.

CWA 18398 Annex K

CWA 18398 Annex K provided a structured set of AI skill areas developed through European expert input. It offered a different perspective from labour-market data and helped us check the breadth of the emerging register.

These sources serve different purposes and use different definitions of a skill. We did not expect their terminology or structures to align directly.

The three sources provided sufficient breadth for the first release. This does not mean they contain every useful AI term. Additional sources can be considered as the register is reviewed and extended.

The external sources are credited for the terminology they helped us identify. The decisions about how concepts relate to SFIA are SFIA Foundation interpretations.

Terms, concepts and mappings

The method distinguishes between three things:

• A source term is the wording found in one of the source lists.

• A concept is the subject under which related terms are brought together in the register.

• A mapping records how that concept relates to one or more SFIA skills.

Several source terms may therefore lead to one concept. One concept may also relate to several SFIA skills.

The first release contains 51 concepts, 92 distinct SFIA skills and 284 concept-to-skill relationships.

Method at a glance

We used the following steps:

1. Collected terminology from the three selected sources.

2. Classified what each term described.

3. Decided whether to retain, combine, redirect or exclude the term.

4. Brought duplicates, variants and closely related terms together as concepts.

5. Related each concept to relevant SFIA skills.

6. Recorded how central each skill was to the concept.

7. Reviewed the results for consistency and unintended claims of equivalence.

Each step involved judgement. The register is therefore an informed interpretation, not an automated translation between taxonomies.

Classifying the source terms

The Lightcast extract included several different kinds of information under the general heading of skills. This reflects its purpose as a detailed record of labour-market terminology.

Before mapping anything to SFIA, we considered what each term described.

Professional work or capability

Some terms described work that a person performs or a professional capability that can be assessed. These were candidates for individual mapping.

Tools, platforms and products

Product and platform names may be important requirements for a job, but they do not usually describe the underlying professional skill.

A requirement for PyTorch, for example, does not by itself tell us what the person will do. They might develop machine-learning models, integrate a model into software, conduct research or support an existing service. The work and responsibility must be understood before the relevant SFIA skills can be identified.

Tools can therefore be recorded as role requirements, but separately from the SFIA skills profile.

Techniques, algorithms and methods

These terms usually describe how work is performed. They may form part of the knowledge and experience required to apply a professional skill, but they do not always need to be treated as separate skills.

Some were retained as useful search terms. Others were combined under a broader concept or treated as supporting knowledge.

System capabilities

Some terms described what an AI system does, such as summarising text, generating images or supporting a diagnosis.

A system capability does not, by itself, identify the human work involved. Delivering it may require people to specify requirements, prepare data, design and build systems, test results, integrate services, manage risks and oversee operation. These activities may involve several SFIA skills.

Where a system capability was retained in the register, it was mapped through the professional work needed to deliver or oversee it.

Fields and umbrella terms

Broad terms such as artificial intelligence can be useful starting points, but they cover too much professional work to map neatly to one skill.

These terms may be better supported through a SFIA View, a collection of concepts or a role profile. Where they were retained, the register makes their breadth clear.

Certifications

A certification is a credential rather than a professional skill. It may provide supporting evidence of knowledge or capability, depending on the certification and how it was assessed.

Certifications should normally be recorded separately from the skills and responsibility levels required for a role.

Source classification issues

The 12 classification issues identified in the Lightcast extract were excluded before mapping. They remain in the analysis record to preserve the audit trail for the dated source extract.

Deciding how to treat each term

Classifying a term did not automatically determine whether it appeared in the register. We also considered whether it would provide a useful and reasonably stable way for someone to find SFIA content.

A term could be:

• retained as an individual concept

• combined with related terms

• retained as an alternative search term

• covered through a broader concept

• directed towards a SFIA View or role profile

• treated as a supplementary tool, knowledge or certification requirement

• excluded after review.

Of the 366 entries in the Lightcast extract, about one in four was retained as an individual candidate for mapping. The remaining terms were combined, redirected or excluded according to what they described and how useful they would be as routes into SFIA.

The excluded terms were not necessarily incorrect or unimportant. They were unsuitable for individual mapping to SFIA for the purposes of this register.

Relating concepts to SFIA skills

For each retained concept, we considered the nature of its relationship with SFIA.

A concept might be:

• another name for work already described by a SFIA skill

• an existing professional skill applied in an AI context

• a technique or method used within a skill

• a broad area drawing on several SFIA skills

• a system capability requiring several kinds of professional work.

We then identified the relevant SFIA skills and recorded how central each was to the concept. This distinguishes skills that are fundamental to the concept from skills that may be relevant in some organisational contexts.

This is not a claim that SFIA contains a separate AI-specific skill for every market term. In many cases, the professional skill remains the same when AI is introduced. What changes may be the tools, work context, risks, evidence or knowledge required.

We used CWA 18398 Annex K as an external check on the resulting coverage. This helped us examine where the relationship with SFIA was direct and where an AI area needed to be understood through several skills or additional context. It did not, on its own, prove that SFIA was complete or that no changes should be considered.

What this teaches us about role profiles

The same distinctions are useful when an employer creates a skills-based role profile.

Job advertisements often combine professional skills, technologies, qualifications, knowledge and responsibilities in one list. All may be relevant, but they should not be treated as equivalent requirements.

Start with the work

Identify what the person will do and the outcomes for which they will carry responsibility. Then identify the SFIA skills and levels needed to perform that work.

Starting with a product name or fashionable term can lead to an incomplete profile because the same technology may be used for several different purposes.

Record tools separately

A tool requirement may affect recruitment, deployment or training, but it is not a substitute for the underlying professional skill.

People may meet the same SFIA skill and level requirement while having experience of different tools. Their tool experience may still affect their suitability for a particular job, so it should be recorded as a separate requirement.

Distinguish knowledge, skill, competency and responsibility

These terms describe related but different aspects of capability:

• Knowledge concerns what someone understands.

• Skill concerns their ability to perform an activity.

• Competency is demonstrated when knowledge, skills, experience and behaviours are applied effectively in a work context.

• Responsibility level describes the autonomy, influence, complexity, business impact and accountability involved.

A person may understand a technique without being able to apply it effectively. Being assigned responsibility for an outcome does not, by itself, demonstrate competence. Assessment should consider suitable evidence of application and results.

Translate system capabilities into human work

A requirement such as “AI-supported diagnostics” describes a system capability and its context. It does not define the role.

A useful profile would identify the people responsible for activities such as setting clinical requirements, preparing data, developing or configuring the system, validating results, integrating it into services and governing its use. These activities can then be related to SFIA skills and levels.

Define broad requirements

A requirement such as “artificial intelligence” or “data science” is usually too broad to assess as a single skill. It should prompt a discussion about the work, knowledge and responsibility the organisation actually needs.

Broad fields can still be useful when describing a role family, professional area or organisational capability.

Retain the domain context

SFIA is sector-neutral, but role profiles do not need to be.

Applying AI in healthcare, financial services or another regulated setting may draw on the same underlying SFIA skills. However, the domain changes the required knowledge, standards, risks, constraints and evidence.

The SFIA skills and the relevant domain requirements should both be recorded.

Ask a consistent set of questions

When reviewing a proposed requirement, ask:

1. What kind of thing is this: work, knowledge, a tool, a method, a system capability, a field or a credential?

2. What will the person actually do with it?

3. What decisions will they make?

4. What outcomes will they influence or be accountable for?

5. What level of responsibility will they exercise?

6. What evidence would demonstrate that they can do the work effectively?

These questions turn a list of market terms into a clearer and more assessable role profile.

Limits of the register

The register has several limitations.

• It reflects selected sources and the terminology available when they were reviewed.

• Labour-market terminology changes, so the source lists and search terms will need periodic review.

• A concept-to-skill relationship may vary according to organisational and sector context.

• The mappings help users find relevant SFIA skills. They are not formal statements that concepts are equivalent to those skills.

• Inclusion in the register does not demonstrate that an individual is competent.

• The register can inform the SFIA 10 review, but it does not by itself prove that the framework has no gaps.

Publishing the method and exclusions allows users to understand these limitations and challenge the judgements made.

How this supports SFIA 10

SFIA already describes many of the professional skills involved in developing, applying, managing and governing AI. Its technology-neutral design helps those descriptions remain useful as particular products and techniques change.

The AI concepts register makes that coverage easier to find. It also provides evidence about the terminology people use and where they may have difficulty locating relevant SFIA content.

SFIA is under active review for SFIA 10, including consideration of AI-assisted work and the everyday capability to work with AI. The register helps distinguish between:

• terminology that needs a better route into existing SFIA content

• concepts that need additional explanation or guidance

• possible changes that should be considered through the SFIA 10 process.

It therefore supports both current use of SFIA 9 and the continuing review of the framework.