EU AI Act readiness for employment and education assessment: start with the evidence trail

There is a predictable moment in most compliance programmes when a useful question becomes a spreadsheet. Someone asks, Are we ready for the EU AI Act? and the organisation responds by collecting policies, supplier questionnaires and screenshots. The folder grows, but the team still cannot explain exactly where AI influences an assessment decision or what a reviewer is expected to do when the system is wrong.

For employment and education assessment, that is the wrong end of the problem. Readiness begins with the decision pathway, not the document library. The European Commission identifies certain AI uses in employment and education among the areas that can be high-risk. The detailed classification depends on intended purpose and context, and the implementation timetable has changed as the legislation has evolved. This article is practical guidance, not legal advice: confirm your classification, dates and duties with qualified counsel. But do not wait for a legal memo before making the workflow understandable.

Map the real use, including the unofficial one

Write down every place AI touches the assessment lifecycle: drafting questions, recommending difficulty, checking identity, monitoring behaviour, scoring responses, summarising evidence, ranking candidates, drafting feedback and creating capability profiles. Then ask what happens next. Does a person see the output? Can they change it? Does it alter who progresses? Is it copied into another system?

The official product description is rarely enough. A tool sold as feedback assistance may be used by an overworked reviewer as a de facto score. A recruitment chatbot may quietly screen people before they reach the declared assessment. A general-purpose model may be connected to a rubric by a local team without procurement knowing. Talk to authors, markers, recruiters, support staff and data teams. Shadow a real case from invitation to final decision. The gap between intended and actual use is where many governance failures begin.

For each use, record the affected population, the consequence, the input data, the output, the person with final authority and the systems that receive the result. Include foreseeable misuse. The reviewer should not rely on this alone is not a control if the interface and workload make reliance almost inevitable.

Classify a use case, not a brand name

Teams often ask whether a particular vendor is AI Act compliant. That question is too broad. The same component can support a low-consequence drafting task in one organisation and influence access to employment or education in another. Classification follows intended purpose and deployment, not the confidence of a sales presentation.

Create a short classification record for each use case. State why the system is or is not within a listed high-risk area, what exclusions or conditions you believe apply, who reached the view and when it will be reconsidered. Link the assessment to the system version and contract. If a feature or purpose changes, reopen the record. This is far more defensible than a single permanent label attached to a product.

Do not treat human in the loop as an automatic escape hatch. A human who sees only a recommendation, has seconds to respond and is measured on throughput may not provide meaningful oversight. The practical question is whether the person can understand the evidence, recognise limitations, disagree without friction and stop the route when something is wrong.

Build the evidence trail while the system is still being designed

An audit trail cannot be bolted on after a challenge. Decide what you will need to reconstruct before launch. At minimum, connect the assessment version, rubric or decision policy, relevant response or observation, AI output, source material, model or component version, reviewer action, final outcome and any later correction.

Keep suggestion and decision separate. If a reviewer edits AI-generated feedback, retain the original suggestion and the approved version rather than overwriting one with the other. If an automated flag sends a response to moderation, record the flag as a trigger, not a finding. That distinction allows the organisation to see how often reviewers override assistance and whether certain groups experience different error patterns.

Good records also make product improvement possible. Without them, an organisation can measure speed but not whether the system saved meaningful work, shifted error, or created new review burden. Evidence is not merely for regulators. It is how the team learns whether the feature deserves to remain live.

Turn human oversight into a designed role

Name the person or role accountable for the final decision. Define what they must inspect, what they may approve, what requires a second reviewer and what must never be automated. Give them a clear view of supporting evidence and known limitations. If the model has insufficient support, the interface should show uncertainty rather than forcing a recommendation.

Then test the role under realistic conditions. Give reviewers a plausible but unsupported suggestion, a case with conflicting evidence and a case outside the intended population. Observe whether they notice, correct and escalate. Repeat the exercise at normal workload. Oversight that works only in a workshop with unlimited time is not an operational control.

Reviewers also need authority. They should be able to pause an individual case, disable assisted output where authorised, request another evidence source and record disagreement. Performance targets should not reward automatic acceptance. Monitor review time and queue size so staffing pressure does not silently convert human judgement into a rubber stamp.

Ask suppliers for usable evidence

A long responsible-AI statement may contain little that helps a deployer. Ask the supplier to demonstrate the intended-purpose boundary, data flow and decision record using a realistic case. Request performance evidence for populations and conditions relevant to your use, not only a headline accuracy number. Understand known limitations, accessibility testing, change notification, incident handling, security controls and data retention.

Contracts should secure the information you need to meet your own obligations. That may include version notices, audit data, support for investigations, subprocessor changes, deletion evidence and the ability to suspend a feature without losing the assessment service. Clarify whether submitted content or reviewer corrections are used to train models. If you cannot obtain enough evidence to govern a consequential use, that is a deployment decision, not a paperwork inconvenience.

Monitor outcomes, not only uptime

Technical availability tells you whether the service ran. It does not tell you whether it treated people consistently or supported valid decisions. Define monitoring before launch: unsupported outputs, reviewer overrides, disagreement rates, completion and drop-off, accommodation issues, subgroup error patterns, appeals, incidents and time spent correcting suggestions.

Choose thresholds that trigger action. A material model change may require revalidation. A spike in overrides could indicate drift, a new response pattern or a rubric problem. Missing audit data may require pausing assisted decisions even if the assessment itself remains available. Assign an owner and rehearse the stop process; an emergency control that nobody has permission to use is not a control.

Monitoring also needs context. An apparent improvement in average marking time can hide longer appeals or more second reviews. A consistent overall error rate can hide a problem concentrated in one language group. Review quantitative indicators alongside candidate feedback and examples of actual decisions.

Prepare an explanation a real person can use

Candidates and learners do not need a lecture on model architecture. They need a truthful account of where automation was used, what it contributed, who decided, what data was processed and how to request human review. Give that information before the assessment where it affects preparation or choice, and again beside the result where a challenge can be made.

Internal explanations need more detail. A support colleague should be able to locate the relevant record without asking engineering to reconstruct logs. A reviewer should see the rubric and evidence used at the time, not todays version. An auditor should be able to follow the path without receiving unrestricted access to every candidates data.

A ninety-day readiness sequence

1. Weeks 1-2: identify every AI-supported assessment use and its owner. Map actual decision pathways and affected populations.
2. Weeks 3-4: complete use-case classification and data mapping with legal, privacy, assessment and accessibility input.
3. Weeks 5-6: define human authority, evidence records, notice, appeal routes and operational stop conditions.
4. Weeks 7-9: test representative and edge cases, including workload, accessibility, unsupported output and subgroup analysis.
5. Weeks 10-12: close supplier gaps, train reviewers through scenarios, rehearse incidents and approve a bounded deployment.

This is not the end state. It is enough structure to replace vague confidence with an inspectable operating model. Continue monitoring, record changes and revisit classification when purpose or functionality shifts.

The useful test of readiness

Ask the team to choose one recent assessment decision influenced by AI. Can they show the exact system use, approved source, version, suggestion, reviewer action and final outcome? Can they explain the route to the affected person in plain language? Can they identify who would stop the feature if tomorrows monitoring revealed a problem?

If the answer requires several people searching different systems, readiness is incomplete. The work is not to make the compliance folder thicker. It is to make the decision path visible, reviewable and correctable while the system is live.