<!--
author:   ICoBC - International Council on Badges and Credentials
email:    info@icobc.net
version:  1.0.0
language: en
narrator: UK English Female
comment:  A practice course for L&D, HR, programme, quality and registry staff on classifying, overseeing, testing, documenting and procuring AI used in assessment and skills inference under the EU AI Act.
@style
:root { --icobc-navy:#02375B; --icobc-orange:#F78222; --icobc-cyan:#5DCAE7; --icobc-lime:#B1CF37; --icobc-mist:#F1F5F8; --icobc-line:#D8E2E9; --icobc-muted:#4F6576; }
body { font-family: "Open Sans", Arial, sans-serif; }
h1, h2, h3, h4 { color: var(--icobc-navy); }
a { color: var(--icobc-navy); }
table th { background: var(--icobc-mist); color: var(--icobc-navy); }
blockquote { border-left: 4px solid var(--icobc-orange); background: var(--icobc-mist); padding: 8px 16px; }
@end
-->

# Governing AI in Assessment and Skills Inference

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

Course ID: ICB-A10. Badge: "Governing AI in Assessment and Skills Inference (Ability, L4)".

## About this course

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.

| Outcome | Module | How it is assessed |
|---|---|---|
| 1. Classify AI uses under the EU AI Act | Classification | Module quiz, governance plan section 1, knowledge check |
| 2. Design oversight, documentation and quality controls | Oversight | Module quiz, governance plan sections 2 and 4, knowledge check |
| 2. Design oversight, documentation and quality controls | Documentation | Module quiz, governance plan section 4, knowledge check |
| 3. Test AI systems for bias and error | Testing | Module quiz, governance plan section 3, knowledge check |
| 4. Prepare for the obligations from 2 December 2027 | Supplier management | Module quiz, governance plan sections 5 and 6, knowledge check |
| 4. Prepare for the obligations from 2 December 2027 | Classification | Governance plan section 6, knowledge check |

> 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.

<!-- VERIFY: Final published text of the AI Omnibus and the dates it sets for Annex III (2 December 2027) and Annex I (2 August 2028) obligations. -->

## 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.

<!-- VERIFY: Confirm current article references for risk tiers and Annex III with the final published AI Act and Omnibus text before quoting them. -->

### 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.

<!-- VERIFY: Wording of the Annex III education and employment categories and of the exception for narrow or preparatory tasks, against the final published text. -->

### A classification decision tree

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

<svg viewBox="0 0 800 450" width="100%" role="img" xmlns="http://www.w3.org/2000/svg" font-family="Open Sans, Arial, sans-serif">
  <title>Classification decision tree for AI uses in credentialing</title>
  <desc>A decision tree with three questions. Question one asks whether the use is a prohibited practice. Question two asks whether the output influences decisions on education access, learning outcomes, hiring, promotion or work evaluation. Question three asks whether a narrow or preparatory exception applies and is documented. The outcomes are stop, high-risk governance, document the exception and transparency or minimal-risk controls.</desc>
  <rect x="0" y="0" width="800" height="450" fill="#FFFFFF"/>
  <rect x="270" y="15" width="260" height="50" rx="6" fill="#02375B" stroke="#02375B" stroke-width="2"/>
  <text x="400" y="45" text-anchor="middle" font-size="16" fill="#FFFFFF">Describe the AI use</text>
  <line x1="400" y1="65" x2="400" y2="95" stroke="#02375B" stroke-width="2"/>
  <rect x="220" y="95" width="360" height="55" rx="6" fill="#F1F5F8" stroke="#02375B" stroke-width="2"/>
  <text x="400" y="118" text-anchor="middle" font-size="14" fill="#02375B">Q1. Is it a prohibited practice?</text>
  <text x="400" y="138" text-anchor="middle" font-size="14" fill="#4F6576">For example, banned emotion inference</text>
  <line x1="580" y1="122" x2="650" y2="122" stroke="#02375B" stroke-width="2"/>
  <text x="615" y="114" text-anchor="middle" font-size="14" fill="#02375B">Yes</text>
  <rect x="650" y="97" width="130" height="50" rx="6" fill="#F78222" stroke="#02375B" stroke-width="2"/>
  <text x="715" y="127" text-anchor="middle" font-size="14" fill="#02375B">Stop the use</text>
  <line x1="400" y1="150" x2="400" y2="185" stroke="#02375B" stroke-width="2"/>
  <text x="418" y="172" font-size="14" fill="#02375B">No</text>
  <rect x="190" y="185" width="420" height="65" rx="6" fill="#F1F5F8" stroke="#02375B" stroke-width="2"/>
  <text x="400" y="210" text-anchor="middle" font-size="14" fill="#02375B">Q2. Does the output influence admission, grading,</text>
  <text x="400" y="230" text-anchor="middle" font-size="14" fill="#02375B">hiring, promotion or work evaluation?</text>
  <line x1="190" y1="217" x2="120" y2="217" stroke="#02375B" stroke-width="2"/>
  <text x="155" y="209" text-anchor="middle" font-size="14" fill="#02375B">No</text>
  <rect x="10" y="190" width="110" height="55" rx="6" fill="#B1CF37" stroke="#02375B" stroke-width="2"/>
  <text x="65" y="214" text-anchor="middle" font-size="14" fill="#02375B">Check duties</text>
  <text x="65" y="232" text-anchor="middle" font-size="14" fill="#02375B">transparency</text>
  <line x1="400" y1="250" x2="400" y2="285" stroke="#02375B" stroke-width="2"/>
  <text x="418" y="272" font-size="14" fill="#02375B">Yes</text>
  <rect x="190" y="285" width="420" height="65" rx="6" fill="#F1F5F8" stroke="#02375B" stroke-width="2"/>
  <text x="400" y="310" text-anchor="middle" font-size="14" fill="#02375B">Q3. Is it a narrow or preparatory task with no</text>
  <text x="400" y="330" text-anchor="middle" font-size="14" fill="#02375B">material influence, and is that written down?</text>
  <line x1="610" y1="317" x2="660" y2="317" stroke="#02375B" stroke-width="2"/>
  <text x="635" y="309" text-anchor="middle" font-size="14" fill="#02375B">Yes</text>
  <rect x="660" y="285" width="130" height="65" rx="6" fill="#5DCAE7" stroke="#02375B" stroke-width="2"/>
  <text x="725" y="313" text-anchor="middle" font-size="14" fill="#02375B">Record the</text>
  <text x="725" y="333" text-anchor="middle" font-size="14" fill="#02375B">exception</text>
  <line x1="400" y1="350" x2="400" y2="385" stroke="#02375B" stroke-width="2"/>
  <text x="418" y="372" font-size="14" fill="#02375B">No</text>
  <rect x="230" y="385" width="340" height="50" rx="6" fill="#02375B" stroke="#02375B" stroke-width="2"/>
  <text x="400" y="416" text-anchor="middle" font-size="16" fill="#FFFFFF">High-risk governance applies</text>
</svg>

**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.

<details><summary>Facilitator notes</summary>

**Timing:** 45 minutes live workshop, after learners complete the self-paced unit.

**Suggested answers:** (1) likely high-risk, as it evaluates learning outcomes. (2) likely lower risk, with transparency duties on telling users they talk to an AI. (3) likely high-risk, as it affects access to training, and may touch employment categories if the programme influences promotion. (4) exception to document, since it is a narrow preparatory task, provided the reasoning is written and no decision depends on it.

**Discussion prompts:** What facts would move case 4 into high-risk, for example if the sort order influenced who is checked first and so who is admitted? Who in your organisation signs off a classification? Ask groups to present one disagreement.

**Caution:** Remind learners that this is a training exercise and not legal advice.

</details>

### 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.

<!-- VERIFY: Final published text of the AI Omnibus, including the application dates of 2 December 2027 and 2 August 2028. -->

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.

**Question 1.** A corporate academy uses AI to estimate a learner's skill level, and line managers use that estimate when they nominate staff for promotion. How should the academy classify this use first?

[( )] As minimal risk, because the tool only produces estimates
[(X)] As a candidate for high-risk, because the output influences a promotion decision
[( )] As a prohibited practice, because it uses personal data
[( )] As outside the AI Act, because the academy is not a technology supplier
[[?]] Look at what decision the output influences, not at the type of software.
****
Classification depends on the use. An output that feeds promotion decisions falls near the employment category of Annex III. Producing "only estimates" does not remove the influence on the decision. Using personal data does not by itself make a use prohibited, and a deployer such as an academy has its own duties under the Act.
****

**Question 2.** Which statement describes the unit that you classify?

[( )] The software product, once, for all customers
[( )] The supplier's company
[(X)] The specific AI use in its context, including who is affected and what decision it influences
[( )] The data centre where the model runs
[[?]] The same software can sit in different risk groups.
****
You classify the AI use. The same product can be minimal risk for one use and high-risk for another, depending on the decision it influences.
****

**Question 3.** A university uses AI to pre-sort admissions documents by file type. No decision about the applicant depends on the sort. What is the best governance step?

[( )] Treat it as prohibited and switch it off
[( )] Do nothing, because AI Act duties never apply to universities
[( )] Apply the full high-risk package without any analysis
[(X)] Record the reasoning that it is a narrow preparatory task and review it if the use changes
[[?]] Exceptions need written reasoning.
****
A narrow preparatory task may fall within an exception, but the reasoning must be written down and reviewed when the use changes, for example if the sort order starts to shape who is admitted.
****

**Question 4.** From which date do Annex III high-risk obligations apply under the AI Omnibus as understood in November 2026?

[( )] 2 August 2026
[( )] 2 August 2028
[(X)] 2 December 2027
[( )] 1 January 2030
[[?]] Annex I product-embedded systems apply later than Annex III.
****
Under the AI Omnibus, Annex III high-risk obligations apply from 2 December 2027 and Annex I systems from 2 August 2028. Check the final published text.
****

## 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.

<!-- VERIFY: Article wording on human oversight duties for providers and deployers in the final AI Act text. -->

### 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.

<svg viewBox="0 0 800 450" width="100%" role="img" xmlns="http://www.w3.org/2000/svg" font-family="Open Sans, Arial, sans-serif">
  <title>Human oversight loop for AI-supported assessment</title>
  <desc>A loop of five labelled steps. The AI system proposes a result. A trained reviewer checks the evidence. The reviewer decides to accept, change or reject. The decision is logged. A periodic quality review analyses overrides and errors and adjusts the controls. An arrow returns from the quality review to the proposal step.</desc>
  <rect x="0" y="0" width="800" height="450" fill="#FFFFFF"/>
  <circle cx="400" cy="225" r="62" fill="#02375B" stroke="#02375B" stroke-width="2"/>
  <text x="400" y="220" text-anchor="middle" font-size="16" fill="#FFFFFF">Person</text>
  <text x="400" y="242" text-anchor="middle" font-size="16" fill="#FFFFFF">affected</text>
  <rect x="300" y="20" width="200" height="60" rx="6" fill="#5DCAE7" stroke="#02375B" stroke-width="2"/>
  <text x="400" y="45" text-anchor="middle" font-size="14" fill="#02375B">1. AI system</text>
  <text x="400" y="65" text-anchor="middle" font-size="14" fill="#02375B">proposes a result</text>
  <rect x="580" y="110" width="200" height="60" rx="6" fill="#F78222" stroke="#02375B" stroke-width="2"/>
  <text x="680" y="135" text-anchor="middle" font-size="14" fill="#02375B">2. Trained reviewer</text>
  <text x="680" y="155" text-anchor="middle" font-size="14" fill="#02375B">checks the evidence</text>
  <rect x="580" y="290" width="200" height="60" rx="6" fill="#F78222" stroke="#02375B" stroke-width="2"/>
  <text x="680" y="315" text-anchor="middle" font-size="14" fill="#02375B">3. Reviewer decides:</text>
  <text x="680" y="335" text-anchor="middle" font-size="14" fill="#02375B">accept, change, reject</text>
  <rect x="300" y="370" width="200" height="60" rx="6" fill="#F1F5F8" stroke="#02375B" stroke-width="2"/>
  <text x="400" y="395" text-anchor="middle" font-size="14" fill="#02375B">4. Decision and</text>
  <text x="400" y="415" text-anchor="middle" font-size="14" fill="#02375B">override are logged</text>
  <rect x="20" y="200" width="220" height="60" rx="6" fill="#B1CF37" stroke="#02375B" stroke-width="2"/>
  <text x="130" y="225" text-anchor="middle" font-size="14" fill="#02375B">5. Quality review</text>
  <text x="130" y="245" text-anchor="middle" font-size="14" fill="#02375B">adjusts the controls</text>
  <line x1="500" y1="50" x2="580" y2="130" stroke="#02375B" stroke-width="2"/>
  <line x1="680" y1="170" x2="680" y2="290" stroke="#02375B" stroke-width="2"/>
  <line x1="580" y1="330" x2="500" y2="395" stroke="#02375B" stroke-width="2"/>
  <line x1="300" y1="400" x2="130" y2="260" stroke="#02375B" stroke-width="2"/>
  <line x1="130" y1="200" x2="300" y2="50" stroke="#02375B" stroke-width="2"/>
</svg>

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.

<details><summary>Facilitator notes</summary>

**Timing:** 60 minutes workshop. Individual drafting for 25 minutes, pair review for 15, plenary for 20.

**Peer review checklist:** Is the reviewer able to overrule without penalty? Is there a stop authority? Does any agent task make a final decision about a person? Would a zero override rate trigger a check?

**Common pitfalls to raise:** reviewers with no time, a "rubber stamp" step placed at the end of a pipeline, and delegation rules that are too vague to apply.

</details>

**Question 1.** A reviewer approves 100 per cent of AI-generated scores in a month. What is the most sensible governance response?

[( )] Treat it as proof that the AI system is perfectly accurate
[(X)] Investigate possible automation bias, for example with blind sample reviews
[( )] Remove the human review step to save time
[( )] Ask the supplier to hide the AI score from reviewers permanently
[[?]] Think about what a zero override rate might hide.
****
A complete absence of overrides may mean the reviewer follows the machine without real checking. Blind sampling, where the reviewer decides before seeing the AI result, is one way to test this.
****

**Question 2.** Which feature is essential for oversight to be real?

[( )] A reviewer who is named in the contract only
[( )] A dashboard that the reviewer may look at if time allows
[(X)] A reviewer with competence, authority to overrule, enough time and evidence, and a logged decision
[( )] An AI system with a confidence score above 90 per cent
[[?]] Four things must be present together.
****
Oversight needs competence, authority, time and information, and records. A confidence score alone does not replace a person who can judge and overrule.
****

**Question 3.** An agent drafts promotion shortlists. Which delegation level fits best?

[( )] Level 2, act and report, so the shortlist goes straight to the board
[( )] No rule is needed, because the agent only drafts
[(X)] Level 0 or Level 1, so a person reviews and decides before any action
[( )] Level 2 for the first year, then Level 0
[[?]] The decision affects a person's career.
****
Decisions that affect a person's access, grade, hiring or promotion should stay at suggest-only or act-with-approval levels. A written rule per task makes this checkable.
****

**Question 4.** Which item belongs in an oversight design for a high-risk use?

[( )] A promise that the supplier will handle all complaints
[(X)] A named role with authority to pause the system and a route for affected people to request human review
[( )] A rule that reviewers may not overrule results to keep scores consistent
[( )] A ban on logging, to protect reviewers' privacy
[[?]] Think about stop authority and the rights of the person affected.
****
A named stop authority and a route to human review are core parts of a workable design. Logging supports accountability, and reviewers must be free to overrule.
****

## 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.

<!-- VERIFY: Rules in the final AI Act and applicable data protection law on processing special categories of data for bias testing. -->

### 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:

| Group | Answers | Cases where AI score differs from human score by more than one grade band |
|---|---|---|
| Learners writing in their first language | 160 | 16 |
| Learners writing in a second language | 40 | 12 |

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.

<details><summary>Facilitator notes</summary>

**Timing:** 60 minutes workshop, including 15 minutes on the calculation.

**Answer for Part 2:** first-language group 16 of 160 is 10 per cent. Second-language group 12 of 40 is 30 per cent. The gap is large and worth investigating. The second group has only 40 answers, so the figure is unstable and the sample may not represent all second-language learners. Next steps could include a larger sample, a review of the human reference, a look at which question types drive the gap, added human review for affected cases, and a supplier query.

**Teaching point:** All numbers here are illustrative. Encourage learners to describe the limits of their evidence.

</details>

<svg viewBox="0 0 800 450" width="100%" role="img" xmlns="http://www.w3.org/2000/svg" font-family="Open Sans, Arial, sans-serif">
  <title>Bias test: comparing error rates across groups</title>
  <desc>A simple bar chart with illustrative values showing the share of AI results that differ from the human reference for three groups. Group A shows 10 per cent, group B shows 30 per cent and group C shows 12 per cent. A dashed line marks an illustrative acceptance limit at 15 per cent. Group B exceeds the limit and is labelled for investigation.</desc>
  <rect x="0" y="0" width="800" height="450" fill="#FFFFFF"/>
  <line x1="100" y1="50" x2="100" y2="360" stroke="#02375B" stroke-width="2"/>
  <line x1="100" y1="360" x2="740" y2="360" stroke="#02375B" stroke-width="2"/>
  <text x="30" y="40" font-size="14" fill="#4F6576">Share of results that differ (illustrative)</text>
  <line x1="95" y1="360" x2="100" y2="360" stroke="#02375B" stroke-width="2"/>
  <text x="85" y="365" text-anchor="end" font-size="14" fill="#4F6576">0%</text>
  <text x="85" y="285" text-anchor="end" font-size="14" fill="#4F6576">10%</text>
  <text x="85" y="205" text-anchor="end" font-size="14" fill="#4F6576">20%</text>
  <text x="85" y="125" text-anchor="end" font-size="14" fill="#4F6576">30%</text>
  <rect x="160" y="280" width="120" height="80" rx="6" fill="#5DCAE7" stroke="#02375B" stroke-width="2"/>
  <text x="220" y="270" text-anchor="middle" font-size="14" fill="#02375B">10%</text>
  <text x="220" y="385" text-anchor="middle" font-size="14" fill="#02375B">Group A</text>
  <rect x="340" y="120" width="120" height="240" rx="6" fill="#F78222" stroke="#02375B" stroke-width="2"/>
  <text x="400" y="110" text-anchor="middle" font-size="14" fill="#02375B">30%</text>
  <text x="400" y="385" text-anchor="middle" font-size="14" fill="#02375B">Group B</text>
  <rect x="520" y="264" width="120" height="96" rx="6" fill="#5DCAE7" stroke="#02375B" stroke-width="2"/>
  <text x="580" y="254" text-anchor="middle" font-size="14" fill="#02375B">12%</text>
  <text x="580" y="385" text-anchor="middle" font-size="14" fill="#02375B">Group C</text>
  <line x1="100" y1="240" x2="740" y2="240" stroke="#02375B" stroke-width="2" stroke-dasharray="8 6"/>
  <text x="740" y="230" text-anchor="end" font-size="14" fill="#02375B">Acceptance limit 15% (illustrative)</text>
  <text x="400" y="430" text-anchor="middle" font-size="14" fill="#02375B">Group B exceeds the limit: investigate</text>
</svg>

**Question 1.** Why does a supplier's overall accuracy figure not settle the question of bias in your context?

[( )] Because suppliers always publish false figures
[(X)] Because it describes the supplier's data, and performance may differ for groups and tasks in your own context
[( )] Because accuracy cannot be measured for AI systems
[( )] Because bias only matters for systems that use images
[[?]] Think about whose data was used.
****
An average figure from other data does not show how the system treats your learners or employees. Testing with representative local data and comparing groups reveals gaps that an average can hide.
****

**Question 2.** When should you set the pass criteria for a bias test?

[( )] After you see the results, so that they are realistic
[( )] After the supplier has reviewed the results
[(X)] Before you run the test
[( )] Only if a regulator asks
[[?]] Consider the risk of choosing thresholds that fit the result.
****
Pass criteria set before testing prevent thresholds from being bent to fit results. Record them in the test plan.
****

**Question 3.** In an admission screen, which error most directly shuts capable applicants out?

[( )] A false positive
[(X)] A false negative
[( )] A calibration gain
[( )] A high override rate
[[?]] The system misses people who do have the required capability.
****
A false negative means a person who meets the criterion is rated as not meeting it. In admissions this can exclude capable applicants, so it needs close attention.
****

**Question 4.** A bias test finds a large gap for a group with only 40 cases. What is the most sensible next step?

[( )] Ignore it, because the group is small
[( )] Declare the system unfair without further work
[(X)] Treat it as a warning, note the limits of the sample, and collect more evidence while adding controls
[( )] Remove the group from future tests
[[?]] Small samples give unstable numbers but still deserve a response.
****
A small sample limits what you can claim, but a large gap is a signal. Collect more evidence and add protective controls in the meantime.
****

**Question 5.** Which action belongs in a routine for repeating tests?

[( )] Testing only once, at purchase
[( )] Testing only after a complaint
[(X)] Re-testing at set intervals and after any change to the system, the data or the use
[( )] Re-testing only when the supplier agrees
[[?]] Drift and changes can alter results.
****
Systems, data and uses change. A routine that re-tests at set times and after changes keeps your evidence current.
****

## 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.

<!-- VERIFY: Deployer duties, log retention periods, worker information duties and any fundamental rights impact assessment duties in the final AI Act and Omnibus text. -->

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.

<!-- VERIFY: Serious incident reporting duties and timelines for providers and deployers in the final AI Act text. -->

<svg viewBox="0 0 800 450" width="100%" role="img" xmlns="http://www.w3.org/2000/svg" font-family="Open Sans, Arial, sans-serif">
  <title>Documentation set for one high-risk AI use</title>
  <desc>A central navy box labelled AI use register entry is linked to six labelled document boxes: classification record, oversight design, test evidence, operating logs, training records, and change and review log. Arrows run from the central box to each document.</desc>
  <rect x="0" y="0" width="800" height="450" fill="#FFFFFF"/>
  <rect x="280" y="185" width="240" height="80" rx="6" fill="#02375B" stroke="#02375B" stroke-width="2"/>
  <text x="400" y="220" text-anchor="middle" font-size="16" fill="#FFFFFF">AI use register</text>
  <text x="400" y="244" text-anchor="middle" font-size="16" fill="#FFFFFF">entry</text>
  <rect x="40" y="30" width="220" height="60" rx="6" fill="#F1F5F8" stroke="#02375B" stroke-width="2"/>
  <text x="150" y="66" text-anchor="middle" font-size="14" fill="#02375B">Classification record</text>
  <rect x="290" y="30" width="220" height="60" rx="6" fill="#F1F5F8" stroke="#02375B" stroke-width="2"/>
  <text x="400" y="66" text-anchor="middle" font-size="14" fill="#02375B">Oversight design</text>
  <rect x="540" y="30" width="220" height="60" rx="6" fill="#F1F5F8" stroke="#02375B" stroke-width="2"/>
  <text x="650" y="66" text-anchor="middle" font-size="14" fill="#02375B">Test evidence</text>
  <rect x="40" y="360" width="220" height="60" rx="6" fill="#B1CF37" stroke="#02375B" stroke-width="2"/>
  <text x="150" y="396" text-anchor="middle" font-size="14" fill="#02375B">Operating logs</text>
  <rect x="290" y="360" width="220" height="60" rx="6" fill="#B1CF37" stroke="#02375B" stroke-width="2"/>
  <text x="400" y="396" text-anchor="middle" font-size="14" fill="#02375B">Training records</text>
  <rect x="540" y="360" width="220" height="60" rx="6" fill="#B1CF37" stroke="#02375B" stroke-width="2"/>
  <text x="650" y="396" text-anchor="middle" font-size="14" fill="#02375B">Change and review log</text>
  <line x1="330" y1="185" x2="170" y2="90" stroke="#02375B" stroke-width="2"/>
  <line x1="400" y1="185" x2="400" y2="90" stroke="#02375B" stroke-width="2"/>
  <line x1="470" y1="185" x2="630" y2="90" stroke="#02375B" stroke-width="2"/>
  <line x1="330" y1="265" x2="170" y2="360" stroke="#02375B" stroke-width="2"/>
  <line x1="400" y1="265" x2="400" y2="360" stroke="#02375B" stroke-width="2"/>
  <line x1="470" y1="265" x2="630" y2="360" stroke="#02375B" stroke-width="2"/>
</svg>

**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.

<details><summary>Facilitator notes</summary>

**Timing:** 45 minutes workshop. Learners swap register entries and try to answer five questions about the other person's use using only the entry.

**Check for:** vague roles, a missing system version, no review date, logs with no retention rule, and no link to test evidence.

**Reminder:** Retention periods and incident duties depend on the final legal text and on national data protection rules. Direct learners to their legal and data protection teams.

</details>

**Question 1.** What is the main purpose of an audit trail for one decision?

[( )] To replace the human reviewer
[( )] To increase the AI system's accuracy automatically
[(X)] To let someone reconstruct what the system recommended, who decided and why
[( )] To avoid informing the person affected
[[?]] Think about appeals and reviews.
****
An audit trail supports review, appeals and accountability by showing the system version, the output, the reviewer and the final decision.
****

**Question 2.** Which pairing describes a quality control properly?

[( )] A promise to be careful, with no owner
[(X)] A routine check with an owner, a frequency and an action if the check fails
[( )] A one-off test at purchase
[( )] A supplier brochure about accuracy
[[?]] A control needs someone responsible and a response.
****
A control has an owner, a frequency and a defined action when it fails. Without these it is a good intention.
****

**Question 3.** Which item is missing if the model version used in practice cannot be matched to the version that was tested?

[( )] A marketing plan
[( )] A longer contract
[(X)] A change and review log or version check that links tests to the live system
[( )] A bigger test set
[[?]] Tests only apply to the version that was tested.
****
Test evidence applies to the tested version. A version check and a change log keep the link between what you tested and what you run.
****

**Question 4.** A serious incident affects many learners. What should your plan already say?

[( )] Nothing, because plans are written after incidents
[(X)] Who investigates, who informs the supplier and relevant authorities where required, how affected people are told and how the system is paused or corrected
[( )] That the supplier alone carries all responsibility
[( )] That logs should be deleted immediately to protect privacy
[[?]] Plan roles and steps before anything happens.
****
A prepared incident plan names roles and steps. Exact reporting duties depend on the final legal text and on your role, so check them with legal counsel.
****

## 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.

<!-- VERIFY: Definitions of provider and deployer, and conditions under which a deployer becomes a provider, in the final AI Act text. -->

### 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.

<!-- VERIFY: Conformity assessment and CE marking requirements for high-risk AI systems as they apply under the final text and Omnibus. -->

### 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.

<!-- VERIFY: Final application dates and any official guidance or harmonised standards relevant to high-risk obligations for Annex III systems. -->

<svg viewBox="0 0 800 450" width="100%" role="img" xmlns="http://www.w3.org/2000/svg" font-family="Open Sans, Arial, sans-serif">
  <title>Preparation timeline towards 2 December 2027</title>
  <desc>A horizontal timeline with five milestones towards 2 December 2027: register and classify uses, supplier due diligence, testing and oversight design, training and documentation, and rehearsal and readiness review. The final marker is labelled 2 December 2027, Annex III obligations apply.</desc>
  <rect x="0" y="0" width="800" height="450" fill="#FFFFFF"/>
  <line x1="60" y1="225" x2="740" y2="225" stroke="#02375B" stroke-width="2"/>
  <circle cx="100" cy="225" r="14" fill="#02375B" stroke="#02375B" stroke-width="2"/>
  <circle cx="240" cy="225" r="14" fill="#02375B" stroke="#02375B" stroke-width="2"/>
  <circle cx="380" cy="225" r="14" fill="#02375B" stroke="#02375B" stroke-width="2"/>
  <circle cx="520" cy="225" r="14" fill="#02375B" stroke="#02375B" stroke-width="2"/>
  <circle cx="660" cy="225" r="14" fill="#02375B" stroke="#02375B" stroke-width="2"/>
  <rect x="30" y="90" width="140" height="80" rx="6" fill="#B1CF37" stroke="#02375B" stroke-width="2"/>
  <text x="100" y="125" text-anchor="middle" font-size="14" fill="#02375B">1. Register and</text>
  <text x="100" y="145" text-anchor="middle" font-size="14" fill="#02375B">classify uses</text>
  <rect x="170" y="280" width="140" height="80" rx="6" fill="#F78222" stroke="#02375B" stroke-width="2"/>
  <text x="240" y="315" text-anchor="middle" font-size="14" fill="#02375B">2. Supplier</text>
  <text x="240" y="335" text-anchor="middle" font-size="14" fill="#02375B">due diligence</text>
  <rect x="310" y="90" width="140" height="80" rx="6" fill="#5DCAE7" stroke="#02375B" stroke-width="2"/>
  <text x="380" y="125" text-anchor="middle" font-size="14" fill="#02375B">3. Test and design</text>
  <text x="380" y="145" text-anchor="middle" font-size="14" fill="#02375B">oversight</text>
  <rect x="450" y="280" width="140" height="80" rx="6" fill="#5DCAE7" stroke="#02375B" stroke-width="2"/>
  <text x="520" y="315" text-anchor="middle" font-size="14" fill="#02375B">4. Train and</text>
  <text x="520" y="335" text-anchor="middle" font-size="14" fill="#02375B">document</text>
  <rect x="590" y="90" width="140" height="80" rx="6" fill="#F1F5F8" stroke="#02375B" stroke-width="2"/>
  <text x="660" y="125" text-anchor="middle" font-size="14" fill="#02375B">5. Rehearse and</text>
  <text x="660" y="145" text-anchor="middle" font-size="14" fill="#02375B">review readiness</text>
  <text x="660" y="262" text-anchor="middle" font-size="14" fill="#02375B">2 December 2027</text>
  <text x="660" y="400" text-anchor="middle" font-size="14" fill="#02375B">Annex III obligations apply</text>
  <line x1="100" y1="170" x2="100" y2="211" stroke="#02375B" stroke-width="2"/>
  <line x1="240" y1="280" x2="240" y2="239" stroke="#02375B" stroke-width="2"/>
  <line x1="380" y1="170" x2="380" y2="211" stroke="#02375B" stroke-width="2"/>
  <line x1="520" y1="280" x2="520" y2="239" stroke="#02375B" stroke-width="2"/>
  <line x1="660" y1="170" x2="660" y2="211" stroke="#02375B" stroke-width="2"/>
</svg>

**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.

<details><summary>Facilitator notes</summary>

**Timing:** 60 minutes workshop. Run a role play: half the group acts as suppliers who resist, using realistic objections such as "our model is proprietary" or "we cannot share test data".

**Debrief points:** What evidence can substitute for access to proprietary detail, such as independent assurance reports or your own testing? Which clauses are non-negotiable? What would make you walk away?

**Reminder:** This is training practice, not legal advice. Contracts need review by qualified counsel.

</details>

**Question 1.** A supplier says its product is "only decision support". What does that mean for your classification?

[( )] The product is automatically minimal risk
[( )] You no longer have any duties as a deployer
[(X)] You still classify the use according to how you apply the output in decisions
[( )] The supplier's wording replaces your own classification
[[?]] Classification follows the use in your context.
****
Marketing language does not set the risk group. If the output feeds decisions on access, grading, hiring or promotion, the use may be high-risk, and you still hold deployer duties.
****

**Question 2.** Which contract clause best protects your ability to keep test evidence valid?

[( )] A clause that allows silent model updates at any time
[(X)] A clause that requires advance notice of material changes and gives you the right to re-test before they go live
[( )] A clause that bans you from exporting logs
[( )] A clause that transfers all duties to you without documents
[[?]] Test evidence applies to a particular version.
****
Advance notice and a right to re-test let you confirm that a changed system still performs within your criteria before it affects people.
****

**Question 3.** The supplier offers an accuracy claim but no group-level results. What is the most sensible response?

[( )] Accept the claim, because suppliers know their products
[( )] Reject all AI systems permanently
[(X)] Ask for group-level evidence as a condition of purchase and plan your own tests with representative data
[( )] Publish the claim to learners as proof of fairness
[[?]] Ask for evidence and test for yourself.
****
Claims become useful with evidence. Asking for group-level results and running your own tests places the decision on solid ground.
****

**Question 4.** What is a sensible way to approach 2 December 2027?

[( )] Wait until the last month and then buy compliance software
[( )] Treat the date as irrelevant until a regulator contacts you
[(X)] Work backwards from the date with milestones for register, classification, due diligence, testing, oversight, training and rehearsal
[( )] Stop using all AI immediately and for ever
[[?]] Plan in steps with dates.
****
A milestone plan built backwards from the application date spreads the work and leaves time to fix gaps. Confirm the final dates against the published legal text.
****

## 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.

| Criterion | 3: Strong | 2: Competent | 1: Partial | 0: Not met |
|---|---|---|---|---|
| Classification (Outcome 1) | Describes the use precisely, applies the decision tree step by step, justifies the classification with reference to education or employment categories, documents any exception and flags open legal points | Classifies correctly with sound reasoning but with minor gaps in the use description or exception record | Classification stated with thin or partly wrong reasoning | No classification or clearly unsound |
| Oversight and delegation (Outcome 2) | Reviewer competence, authority, time and evidence, triggers, stop authority, human review route and agent delegation levels are specific and workable | Most elements present and workable, with some vague points | Oversight named in general terms, with few concrete controls | No real oversight, or reviewer cannot overrule |
| Testing (Outcome 3) | Test plan uses representative data lawfully, human reference with agreement check, relevant error types, group comparisons, criteria set in advance and a re-test routine | Sound plan with minor omissions, for example no agreement check or thin group rationale | Plan relies on supplier figures with limited own testing | No testing plan, or testing that cannot reveal bias |
| Documentation and quality controls (Outcome 2) | Register entry, logs, audit trail, controls with owner, frequency and action, and incident plan are complete and consistent with the rest of the plan | Most elements complete with minor gaps in owners or frequencies | Documentation listed without owners, retention or links to other sections | No usable documentation design |
| Supplier management (Outcome 4) | Role analysed, due diligence questions prioritised, clauses cover logs, changes, incidents and suspension, with fallbacks | Role and clauses sound, with limited fallbacks or prioritisation | Generic questions and clauses | No supplier controls, or accountability transferred to the supplier by contract |
| Readiness for 2 December 2027 (Outcome 4) | Dated milestone plan with owners and evidence, linked to risks, with clear statement of what must be checked against final legal text | Plan with dates and owners, with limited evidence or linkage | Plan lists tasks without dates or owners | No plan, or wrong dates presented as fact |
| Rigour and trustworthiness (VRITE) | Reasoning is coherent across sections, limits and uncertainties are stated, claims are not overstated, no invented facts | Mostly coherent with minor overstatement | Several inconsistencies or unsupported claims | Contradictory or misleading |

**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.

<details><summary>Facilitator notes</summary>

**Timing:** 2 to 3 hours of independent work for the plan, plus an optional 60-minute live session where learners present a one-page summary and receive peer questions.

**Assessor guidance:** Use the rubric as written. Check that numbers are labelled illustrative where real data is absent. Check that no statement of law goes beyond what the course sources support and that the learner has flagged items to verify against the final text. Provide written feedback on each criterion.

**Moderation:** Have a second assessor mark a sample of plans and discuss differences.

</details>

### Final knowledge check

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

**Question 1.** A university uses AI to score learners' written answers that count towards their final grade. Which classification is the best starting position?

[( )] Minimal risk, because humans may read the scores
[(X)] A candidate for high-risk, because the use evaluates learning outcomes
[( )] Prohibited, because AI must never touch grading
[( )] Outside the AI Act, because universities are exempt
[[?]] Education uses that evaluate learning outcomes appear in Annex III.
****
Evaluating learning outcomes is a listed education use case in Annex III, so such a use is a candidate for high-risk and needs a documented classification. Confirm wording against the final text.
****

**Question 2.** A company uses skills inference only so that employees can browse learning options. No manager sees the results. What is the most sensible view?

[( )] High-risk in all cases, because skills inference is always high-risk
[(X)] Likely lower risk for this use, with a written record, and a review if the use changes to influence employment decisions
[( )] Prohibited, because it processes personal data
[( )] Exempt from all rules, including data protection
[[?]] The decision influenced matters.
****
Classification follows the use. A browsing-only use that influences no decision is likely lower risk, but data protection and transparency still apply, and the classification must be revisited if managers start to use the output for promotion or allocation.
****

**Question 3.** Which design gives the strongest human oversight in AI-supported marking?

[( )] A reviewer who may only approve, never change, scores
[( )] A reviewer who sees only the AI score and no evidence
[(X)] A trained reviewer who sees the evidence, can overrule without penalty, and whose decisions are logged and reviewed
[( )] A reviewer who handles hundreds of cases per hour to keep pace
[[?]] Competence, authority, time, information and records.
****
Real oversight combines competence, authority, time, evidence and records. A reviewer who cannot change results or lacks time and evidence provides only the appearance of oversight.
****

**Question 4.** An agent drafts shortlists for a limited-place programme. Which rule is most suitable?

[( )] The agent publishes the shortlist and reports afterwards
[(X)] The agent drafts, and a named person approves before any action that affects a person
[( )] The agent may contact candidates and decide in cases of high confidence
[( )] No rule is needed, because the agent is only an assistant
[[?]] Choose the lowest delegation level that fits a decision about a person.
****
For decisions that affect access to training, suggest-only or act-with-approval levels keep a person responsible. Written rules make delegation checkable.
****

**Question 5.** Why test with representative local data?

[( )] Because supplier figures are always false
[(X)] Because performance may differ for your groups and tasks, and averages can hide gaps
[( )] Because local data is cheaper than supplier data
[( )] Because testing removes the need for oversight
[[?]] Whose data produced the supplier figure?
****
Group differences can hide behind a good average. Representative local data lets you see gaps that matter for your learners or employees. Testing complements oversight and does not replace it.
****

**Question 6.** When should pass criteria for a bias test be fixed?

[( )] After seeing the results
[( )] After the supplier comments on the results
[(X)] Before running the test, and recorded in the test plan
[( )] Only when a complaint arrives
[[?]] Avoid fitting thresholds to results.
****
Fixing criteria in advance protects the test from thresholds shaped by the results.
****

**Question 7.** A test shows a large error gap for a group of 40 cases. What is the best next step?

[( )] Ignore the gap, because the group is small
[( )] Declare the system unfair and stop all analysis
[(X)] Record it as a warning, state the sample limits, collect more evidence and add protective controls in the meantime
[( )] Drop that group from future tests
[[?]] Small samples limit claims but do not cancel signals.
****
A large gap in a small sample is a signal to investigate. State the limits, collect more evidence and protect people in the meantime.
****

**Question 8.** What belongs in a documentation set for one high-risk AI use?

[( )] Only the supplier's brochure
[(X)] A classification record, oversight design, test evidence, logs, training records and a change and review log
[( )] A single sentence saying the use is compliant
[( )] Only the contract
[[?]] The set must let someone reconstruct and check what you did.
****
A full set links classification, oversight, tests, logs, training and change history. Together they let others check your decisions.
****

**Question 9.** Which contract clause helps keep your test evidence valid over time?

[( )] A right for the supplier to change the model silently
[(X)] Advance notice of material changes with a right to re-test before go-live
[( )] A ban on log export
[( )] A clause that removes all supplier duties
[[?]] Tested versions and live versions must match.
****
Notice and a right to re-test allow you to confirm that a changed system still meets your criteria.
****

**Question 10.** As understood in November 2026, from when do Annex III high-risk obligations apply under the AI Omnibus, and what should you do about this?

[( )] From 2 August 2026, so no preparation is possible
[( )] From 2 August 2028, so you may ignore Annex III for now
[(X)] From 2 December 2027, so work backwards with dated milestones and check the final published text
[( )] From 1 January 2030, so plan only in 2029
[[?]] Annex I applies later than Annex III.
****
Under the provisional agreement of 7 May 2026, Annex III obligations apply from 2 December 2027 and Annex I from 2 August 2028. Build a milestone plan and verify the final published text.
****

## Sources and further reading

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

<!-- VERIFY: Add official URLs from EUR-Lex and the European Commission only after checking them against the live sites. This file lists titles and publishers, not links. -->

**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.
