Governing AI in Assessment and Skills Inference

Preparing for the AI Act's high-risk duties in education and employment.

This course helps you govern AI that supports assessment, recognition and skills inference. You will work on realistic cases from a corporate academy or HR department and from a university, college or training provider. By the end you will have written a governance plan for one AI use.

Who it is for

• L&D and corporate academy leads
• HR, talent acquisition and mobility teams
• Programme and micro-credential leads
• Quality, registry and admissions staff
• Professional bodies and sector associations
• ICoBC Lead Reviewers

Prerequisite: ICB-F07 AI Literacy for Recognition Work.

Framework alignment: ICoBC Credentialing Skills Framework (ICSF), skill AIRC "Trustworthy AI in recognition" (VRITE pillar: Trustworthiness), level L4 "Assure", stage A "Ability". At this level you govern AI use in assessment and skills inference, assess regulatory classification and design oversight and delegation controls for agents. At the Ability stage you practise the capability on realistic tasks in a controlled setting, here cases and a project.

Learning outcomes

1. Classify AI uses in credentialing under the EU AI Act, including the high-risk categories for education and employment.
2. Design human oversight, documentation and quality controls for AI-supported assessment and skills inference.
3. Test AI systems for bias and error with representative data.
4. Prepare for the obligations that apply from 2 December 2027.

Workload: 10 hours notional learning in a blended cohort. This file covers the self-paced part. Live and workshop elements appear as facilitator notes.

Assessment: You write an AI governance plan for one AI use. A trained assessor marks it with the rubric in "Assessment and badge". A short knowledge check supports your preparation. Quality focus: VRITE Trustworthiness and Rigor.

Badge: Passing the assessment leads to the badge "Governing AI in Assessment and Skills Inference (Ability, L4)", alignment code ICSF-AIRC-L4-A. The evidence is your governance plan.

Status as of November 2026; check before publishing. This course describes the EU AI Act and the AI Omnibus as understood in November 2026. It is not legal advice. Confirm the final published legal text with your legal counsel.

Classification

In this module you learn to decide where an AI use sits under the EU AI Act. Classification is the first governance act, because every later duty depends on it.

Why classification comes first

The EU AI Act sorts AI uses by risk. The main groups are prohibited practices, high-risk systems, systems with transparency duties and systems with minimal risk. Your obligations depend on the group.

A governance lead who classifies late pays twice. Controls built for the wrong risk level need rework, and a contract signed before classification may lack the clauses you need.

Recognition work touches several parts of the Act. Assessment of learners, admission decisions, hiring, promotion and task allocation are all areas where the Act pays close attention. Skills inference, where software estimates what a person can do from CVs, activity data or assessment results, also sits close to these areas.

You classify an AI use, not a tool. The same software can be minimal risk when it suggests learning content and high-risk when its output feeds a promotion decision. Always describe the use first: who is affected, what the system outputs, and what decision that output influences.

The education and employment categories

Annex III of the AI Act lists high-risk use cases. Two areas matter most for this course.

Education and vocational training. The Act lists AI used to determine access or admission, to evaluate learning outcomes, to assess the appropriate level of education a person will receive, and to monitor prohibited behaviour during tests. If your AI scores learner work, steers a learning path based on assessed outcomes or screens applicants, it is a strong candidate for high-risk.

Employment, workers management and access to self-employment. The Act lists AI used for recruitment and selection, for decisions on promotion or termination, for task allocation based on behaviour or personal traits, and for monitoring and evaluating performance. Skills inference used for any of these decisions may be high-risk.

The Act also contains exceptions for narrow procedural or preparatory tasks that do not materially influence decisions. Treat exceptions with care. If you rely on one, record your reasoning in writing. The record is part of your evidence.

Skills inference is an emerging area. It is common in HR software, and its classification depends on use. Inference that only helps an employee browse learning options is different from inference that ranks candidates for a post.

A classification decision tree

Use the tree below as a working aid. It simplifies the law, so confirm borderline cases with legal counsel.

Worked example: Skills inference in an HR department

Context: the HR department of a mid-sized company wants to use skills inference software. The software reads employee profiles and project histories and returns a skills map for each person.

Step 1, describe the use. The HR lead lists three planned uses: (a) employees browse a skills map to find courses, (b) managers search the map to staff projects, (c) the talent board uses the map to shortlist people for promotion.

Step 2, classify each use. Use (a) supports self-directed learning. No decision about the employee depends on it, so it is likely minimal risk, though transparency and data protection rules still apply. Use (b) allocates tasks. If allocation depends on inferred traits or behaviour, it may fall in the Annex III employment category. Use (c) feeds a promotion decision and is a clear candidate for high-risk.

Step 3, decide. The HR lead splits the rollout. Use (a) goes live with basic controls. Uses (b) and (c) stay in a pilot until the high-risk controls from the next modules are in place.

Result: one tool, three uses, two risk positions. The lead records each decision and the reasoning in a classification register.

Practice activity: Classify four uses

Take the four uses below. For each, apply the decision tree and write two lines: your classification and your reasoning. Use the labels "likely prohibited", "likely high-risk", "exception to document" or "likely lower risk".

1. A university uses software to score open-text answers in a final course exam. The score counts towards the grade.
2. A training provider uses a chatbot that answers learners' questions about opening hours and enrolment steps.
3. A corporate academy uses AI to rank internal applicants for a leadership programme with limited places.
4. A registry team uses AI to pre-sort incoming credential documents by language and format, with no decision about the person.

Compare your answers with the notes in the facilitator section. Where you disagree, write down what extra fact would change your answer.

Timing and the Omnibus

Under the AI Omnibus, with a provisional agreement of 7 May 2026, obligations for Annex III high-risk systems apply from 2 December 2027. Annex I product-embedded systems follow from 2 August 2028. Credentialing and HR uses mostly sit in Annex III. This gives you a planning window. It also means that a system procured today will still be in service when the duties begin.

Status as of November 2026; check before publishing. Confirm that the Omnibus text is final and published before you fix dates in a contract or a plan.

Use the window to build a register of AI uses, classify each one and plan controls. Do not wait for the date. Evidence gathered now, such as test results and oversight logs, will be useful later.

Oversight

Once you know a use is high-risk, you need people and controls around it. This module covers human oversight of AI in assessment and skills inference, and delegation to AI agents.

What human oversight means

Human oversight means that a competent person can understand, monitor, question and override the output of an AI system. The AI Act requires high-risk systems to be designed so that this is possible, and deployers must put real people in charge of the system's use.

A person who clicks "approve" on every suggestion is not providing oversight. Oversight needs four things:

• Competence: the reviewer understands the task, the system's limits and the likely errors.
• Authority: the reviewer can overrule the system without penalty.
• Time and information: the reviewer has enough time and enough evidence to judge a case, such as the source material and the system's confidence.
• Records: the reviewer's decisions and overrides are logged.

Watch for automation bias, the habit of trusting a machine's answer too easily. Counter it with design: show evidence next to scores, ask reviewers to form a view before they see the AI result on a sample of cases, and track override rates. A rate of zero overrides is a warning sign, not a success.

Designing the oversight loop

An oversight loop turns principles into a routine. It has five steps: the system proposes, a person reviews, the person decides, the decision is logged, and the log feeds a regular quality review. The quality review adjusts thresholds, retraining needs and reviewer guidance.

Define in advance what triggers escalation. Examples include low confidence, a result that would deny a person a place or a promotion, a request from the person affected, or a case in a group where error rates are known to be higher.

Define who can pause the system. A named role, such as the programme lead or the head of HR operations, should have the authority to stop use if monitoring shows a problem.

Affected people deserve a route to challenge. Describe how a learner or employee can ask for a human review and how long the answer takes.

Worked example: Oversight for AI-supported marking in a university

Context: a university faculty uses AI to give first-pass scores on short written answers in a large first-year course. The marks count towards the grade, so the use is a candidate for high-risk.

The programme lead designs the loop.

• Proposal: the system gives a score and highlights the passages that drove it.
• Review: a trained marker sees the answer, the score and the highlights. For a random 10 per cent sample (illustrative), the marker scores first and sees the AI result afterwards. This tests whether markers follow the machine too closely.
• Decision: the marker accepts or changes the score. Any fail grade must be checked by a human, whatever the confidence.
• Log: every change is recorded with a reason code.
• Quality review: each term, the programme lead reviews override rates by question and by learner group, and adjusts guidance.

Result: the faculty can show who looked at what, and can show that human judgement carried real weight.

Delegation and agents

AI agents, meaning systems that take steps on their own such as gathering evidence, drafting decisions or contacting people, add a delegation question. What may the agent do without a human step, and what must always wait for a person?

Write a delegation rule for each agent task. A simple scale helps:

• Level 0, suggest only: the agent drafts and a person acts.
• Level 1, act with approval: the agent prepares an action and waits for a person to approve it.
• Level 2, act and report: the agent acts within narrow limits and reports afterwards, with a way to reverse the action.

For high-risk uses that affect a person's access, grade, hiring or promotion, keep decisions at Level 0 or Level 1. Level 2 may suit low-impact housekeeping, such as formatting a document.

Control the agent's reach as well. Limit its data access to what the task needs, record every action it takes, and set stop conditions, such as a maximum number of steps or a prohibited action list.

Practice activity: Design an oversight loop and delegation rules

Choose one of these two cases.

Case A, corporate academy: an agent reads employee learning records, infers skills and drafts shortlists for a limited-place leadership programme.

Case B, training provider: an agent checks submitted evidence portfolios against assessment criteria and drafts a pass or refer recommendation.

Write a one-page oversight design that covers:

1. The classification you assume and why.
2. The reviewer role, the competence it needs and its authority to overrule.
3. Escalation triggers (at least three).
4. A delegation rule for each agent task, using Levels 0 to 2.
5. What is logged and who reviews the logs, and how often.
6. How a person affected can ask for human review.

Testing

You cannot govern what you have not tested. This module shows how to test AI systems for bias and error with data that represents the people the system will affect.

Why test with representative data

A supplier's accuracy figure describes performance on the supplier's data. Your learners or employees may differ in language, age, background, disability, subject area or writing style. A system can perform well on average and poorly for a group.

Representative data reflects the people and tasks of your own context. For a university, that may be work from several faculties, years and learner groups. For a corporate academy, it may be profiles from several business units, job families, countries and career stages.

Respect data protection law when you assemble test data. Use the minimum data needed, apply a lawful basis, and anonymise or pseudonymise where possible. Where you need group information to test for bias, check what you may lawfully collect and how to store it safely, and involve your data protection officer.

Types of error and bias

Define what "error" means for your use before you measure.

• False positive: the system credits a skill or a pass that the person does not have.
• False negative: the system misses a skill or fails a person who has it.
• Calibration error: confidence scores do not match real accuracy.
• Drift: performance changes over time as data or tasks change.

Which error costs more depends on the use. In an admission screen, false negatives can shut a capable person out. In a safety credential, false positives can put a person in a role they cannot perform.

To look for bias, compare results across groups. Useful comparisons include error rates by group, the rate at which people are rated at each level by group, and the gap between the AI result and a trusted human result by group. Large gaps need investigation. A gap may come from the data, the model, the criteria or the human reference itself.

Keep statistics honest. Small groups give unstable numbers, so note group sizes and avoid strong claims from tiny samples. Treat a test as evidence for a decision, not as proof of fairness.

A testing routine

A practical routine has six steps.

1. Define the use, the decision it influences and the errors that matter most.
2. Build a test set from your own context, with human reference labels from at least two trained raters. Measure how much the raters agree.
3. Run the system on the test set, blind to the reference labels.
4. Compare results overall and by group. Record error types and group sizes.
5. Decide on actions: accept, adjust thresholds, add controls, restrict the use, or reject the system.
6. Repeat at set times and after any change to the system, the data or the use.

Write down the pass criteria before you test. Setting thresholds after seeing the results invites bias.

Worked example: Testing skills inference in a corporate academy

Context: a corporate academy considers skills inference software for matching employees to development programmes, with results also visible to talent managers.

The academy lead builds a test set of 300 employee profiles (illustrative) across four business units, three career stages and two main languages. Two trained skills assessors each label the skills for every profile. They agree on most skills, and the lead sends the disagreements to a third assessor.

The lead runs the software and compares its output with the human labels. Overall agreement looks acceptable. By group, the software misses many skills for employees whose profiles are written in the second language, and for employees with short career histories. The false negative rate for these groups is clearly higher than for the others.

The lead records the finding, sets a rule that inferred skills are suggestions only and that the employee can add or correct skills, and asks the supplier for a fix. The lead schedules a re-test after the next software release.

Result: the academy has evidence, a restricted use and a clear trigger for review.

Practice activity: Plan and read a bias test

Part 1. Plan a test. For one AI use in your context, write a short test plan with:

1. The decision the AI output influences.
2. The error type that matters most and why.
3. The groups you will compare and why.
4. How you will build representative data lawfully.
5. Your pass criteria, written before testing.

Part 2. Read results. A university tests AI-assisted marking on 200 answers (illustrative). Results for two groups:

Calculate the rate for each group. Then write three sentences: what the numbers suggest, what you cannot conclude because of group size, and what you would do next.

Documentation

Good documentation shows what you decided and why. This module covers the records and quality controls that support high-risk AI use in assessment and skills inference.

What to document and why

Documentation serves three purposes. It lets your team run the system consistently, it lets reviewers and auditors check what you did, and it lets affected people receive an explanation.

For high-risk systems, the AI Act sets documentation and record-keeping duties. Providers produce technical documentation and instructions for use. Deployers, which is the role most ICoBC audiences hold, must follow the instructions, assign competent oversight, keep logs under their control for a set period, monitor the system, and inform workers or other affected people where the Act requires it.

A practical documentation set for one AI use includes:

• Use description and classification record: purpose, affected people, decision influenced, risk group and reasoning.
• Oversight design: roles, triggers, delegation rules and stop authority.
• Test evidence: plans, data descriptions, results, group comparisons and decisions.
• Operating logs: inputs where lawful, outputs, reviewer decisions, overrides and incidents.
• Instructions and training records: the supplier's instructions for use, and proof that reviewers were trained.
• Change and review log: every update, re-test and quality review.
• Information for affected people: notices and explanation routes.

Quality controls and the audit trail

A quality control is a routine check that catches problems. Pair each control with an owner, a frequency and an action when the check fails.

Examples for assessment and skills inference:

• Monthly review of override rates by reviewer and by group.
• A blind second-marking sample each term.
• A check that the model version in use matches the version tested.
• A review of complaints and corrections, with a root cause for each pattern.
• A drift check against a fixed set of reference cases.

An audit trail lets someone reconstruct a decision. For one case it should show the input, the system version, the output, the reviewer, the final decision and the date. Protect logs with access controls and apply data minimisation, so that the trail does not become a privacy risk of its own.

Plan how you will handle serious incidents, such as a systematic error that affected many people. The plan should say who investigates, who informs the supplier and relevant authorities where required, how affected people are told and how the system is paused or corrected. Check the final AI Act text for the exact incident reporting duties that apply to your role.

Worked example: Documentation for AI-assisted evidence checking at a training provider

Context: a training provider uses AI to pre-check evidence portfolios against assessment criteria for a vocational micro-credential. Assessors make the final decision.

The quality lead opens a register entry for the use and collects the documents.

• The classification record states that the use supports assessment of learning outcomes and is treated as high-risk, with reasoning.
• The oversight design names the lead assessor as reviewer and the quality lead as stop authority.
• The test evidence file holds the test plan, a description of the 250 portfolios (illustrative) and the group comparison.
• The operating log records the model version, each recommendation, the assessor's decision and any override reason.
• The training record lists who attended assessor training on the system's limits.
• A quarterly review note records override rates and one corrective action.

When a learner appeals a decision, the quality lead retrieves the case trail in minutes and shows what the system recommended, what the assessor decided and why.

Practice activity: Build a register entry and one audit trail

Part 1. For one AI use in your context, create a register entry with these fields: use name, purpose, affected people, decision influenced, risk classification and reasoning, supplier and system version, oversight roles, test evidence location, log location and retention rule, next review date.

Part 2. Write the audit trail record for one imaginary case. Include input type, system version, output, reviewer role, final decision, reason if changed and date. Then answer: what could someone not reconstruct from your trail? Add a field to fix the gap.

Supplier management

Most recognition bodies buy AI rather than build it. This module covers how to manage suppliers so that the duties you carry as a deployer are met, and how to prepare for 2 December 2027.

Provider and deployer roles

The AI Act distinguishes roles. The provider develops or places a system on the market. The deployer uses it under its own authority. An organisation that builds its own tool, or that substantially changes a system or puts its own name on it, may take on provider duties. Check the role you hold for each use, and record it in your register.

A deployer cannot hand off accountability by contract. The supplier supplies documents and technical measures, and you still own the use: the oversight, the training of reviewers, the monitoring, the information to affected people and the decisions made.

For skills inference tools in HR, the supplier may describe the product as "decision support". Your classification still depends on how you use the output.

What to ask suppliers

Build a due diligence set of questions that you can send before purchase and revisit at renewal.

• Intended purpose and known limits of the system, in writing.
• The supplier's own classification of the system and its reasoning.
• The conformity route for high-risk systems and the status of any conformity assessment, as the rules apply.
• Instructions for use, including the oversight measures the supplier expects.
• Test and validation data: what data, what groups, what results, what limits.
• Access to logs and the format in which you can export them.
• Change management: how you will be told about model updates, and how much notice you will get.
• Data protection: roles, locations of processing, sub-processors and retention.
• Support for incidents and for requests from affected people.
• Subcontractors, including providers of underlying models.

Ask for evidence, not only statements. A claim of fairness becomes useful when it comes with a description of the test data and results.

Contract clauses and the road to 2 December 2027

Place the questions into the contract. Useful clauses include:

• A duty to provide documentation and instructions for use needed for your deployer duties.
• Access to logs and to information needed for your own testing.
• Advance notice of material changes, with a right to re-test before they go live.
• Cooperation in incidents and with authorities.
• A right to suspend use, and exit and data return terms.
• A duty to inform you if the supplier's classification or conformity status changes.
• Audit or assurance rights, for example through independent reports.

Under the AI Omnibus, Annex III high-risk obligations apply from 2 December 2027. Build a simple plan with milestones. A possible sequence is: build a register of all AI uses, classify each one, prioritise high-risk uses, run supplier due diligence, test with representative data, put oversight and documentation in place, train reviewers, and rehearse an incident. Place dates against each step, working backwards from the application date.

Status as of November 2026; check before publishing. The date and the content of obligations come from a provisional agreement. Track the final published text and any guidance from the European Commission and national authorities.

Worked example: Procuring skills inference for a corporate academy

Context: the head of a corporate academy wants to buy skills inference software for the company's HR department. A vendor presents it as "decision support with high accuracy".

The head of the academy works with legal, procurement and data protection colleagues.

1. Role and classification: the company will be the deployer. Planned use includes shortlisting for promotion programmes, so the use is treated as a candidate for high-risk.
2. Due diligence: the team sends the question set. The supplier shares an intended-purpose statement but gives no group-level test results. The team treats this as a gap and makes group-level evidence a condition of purchase.
3. Contract: the team adds clauses for log export, notice of model changes with a right to re-test, incident cooperation and a suspension right.
4. Pilot: a limited pilot with the company's own test set and oversight loop runs before any rollout.
5. Timeline: the register shows the pilot ending well before 2 December 2027, with a go or no-go review.

Result: the company can show that it examined the supplier's claims and tied them to contract terms and its own tests.

Practice activity: Supplier questions and contract clauses

You lead quality at a university that plans to buy AI-assisted marking for large first-year courses. Prepare:

1. Eight due diligence questions you would send, in priority order, with one line on why each matters.
2. Four contract clauses you would insist on, with a fallback position for each if the supplier refuses.
3. A one-paragraph note to your programme board that explains what you still carry as deployer, whatever the supplier promises.
4. A five-step plan with target months leading to 2 December 2027.

Assessment and badge

The assessment task

Task: AI governance plan for one AI use.

Choose one AI use from your own work or from a realistic case provided by your facilitator. It must involve AI in assessment, recognition or skills inference. Write a governance plan of about 2,000 to 3,000 words with the six sections below. Use illustrative numbers where you lack real data and label them as such. Do not include personal data about real people.

1. Use and classification. Describe the use, the people affected and the decision influenced. Apply the classification decision tree. State your classification, your reasoning, any exception you rely on and the open points for legal counsel.
2. Oversight and delegation. Describe reviewer roles, competence, authority, escalation triggers, stop authority, the route for people to request human review and delegation levels for any agent tasks.
3. Testing. Describe your test plan: error types that matter, groups compared, representative data and how you would obtain it lawfully, human reference, pass criteria set in advance and re-test routine.
4. Documentation and quality controls. Describe the register entry, logs, audit trail, quality controls with owners and frequencies, and an incident plan.
5. Supplier management. Describe your role, due diligence questions, key contract clauses and how you will handle model changes.
6. Readiness for 2 December 2027. Provide a milestone plan with target dates, owners and the evidence you will hold at each step. State what you still need to check against the final published legal text.

A trained assessor marks the plan. No part of the plan is graded automatically in this file.

Rubric

Score each criterion from 0 to 3. Level 3 is a strong performance, level 2 is competent, level 1 is partial and level 0 is missing or unsound.

Pass rule: The plan passes with a total of at least 15 out of 21 points, with no criterion scored 0 and a score of at least 2 on the classification criterion and on the oversight and delegation criterion. A plan that does not pass may be revised once and resubmitted, following your provider's resubmission rules.

Evidence for the badge

Submit the governance plan as a single document. Where your use is real, remove personal data and commercially sensitive details before submission. The assessor records the rubric scores and the decision. A pass leads to the badge "Governing AI in Assessment and Skills Inference (Ability, L4)", alignment code ICSF-AIRC-L4-A.

Completing the course and earning the badge shows that you performed this governance task to the standard of the rubric in a controlled setting. It does not prove competency in a particular job.

Final knowledge check

This check supports your preparation and is not the badge assessment. Choose one answer for each question.

Sources and further reading

Status as of November 2026; check before publishing. Confirm that you use the final published versions of the texts below.

Legal texts and official bodies

• Regulation (EU) 2024/1689 of the European Parliament and of the Council laying down harmonised rules on artificial intelligence (Artificial Intelligence Act), published in the Official Journal of the European Union. Look for the consolidated text on EUR-Lex.
• The Digital Omnibus on AI (AI Omnibus), including the provisional agreement of 7 May 2026 and the final published text once available, via the European Commission and the Official Journal.
• Regulation (EU) 2016/679 (General Data Protection Regulation), for data protection duties in testing, logging and information to affected people.
• European Commission, AI Office: guidance and notices on the AI Act.

Standards bodies and frameworks

• ISO/IEC 42001, Artificial intelligence: management system, from the International Organization for Standardization and the International Electrotechnical Commission.
• ISO/IEC 23894, Artificial intelligence: guidance on risk management.
• NIST AI Risk Management Framework (AI RMF 1.0), published by the US National Institute of Standards and Technology.
• CEN-CENELEC Joint Technical Committee 21 (JTC 21): European standardisation work in support of the AI Act.

ICoBC materials

• ICoBC Credentialing Skills Framework (ICSF), skill AIRC "Trustworthy AI in recognition".
• ICB-F07 AI Literacy for Recognition Work (prerequisite course).

This course is training material and not legal advice. Take legal advice for decisions about classification, contracts and compliance.