AI Exam Monitoring Under the EU AI Act: High-Risk Obligations for Proctoring Vendors and Institutions

Online proctoring is explicitly named in EU AI Act Annex III. If your system uses AI to detect prohibited behaviour during tests, you are in the high-risk category — not by analogy, not by interpretation, but by the text of the regulation itself. The obligations that follow are substantial. They apply to the software vendor building the system and, separately, to the university or exam body deploying it.

This guide covers who bears which obligations, where the boundary with prohibited practice sits, and what a compliant programme looks like in practice. The deadline for stand-alone Annex III systems is 2 December 2027 under the Digital Omnibus agreed in May 2026, which deferred the original August 2026 date. That shift buys time to build a proper programme rather than bolt one together — but the documentation alone takes months.

Why AI Proctoring Is High-Risk Under Annex III Point 3

Annex III, point 3 lists AI systems for education and vocational training. Within that point, the Act names AI used for "monitoring and detecting prohibited behaviour of students during tests" as high-risk. There is no threshold of sophistication required. A system that analyses webcam feeds, keystroke patterns, screen activity, or audio to flag potential cheating during a live or recorded test session falls squarely here.

The classification rests on function and intended purpose, not on whether the system makes a final call. A tool that generates a "suspicion score" or a "review-required" flag, and whose output feeds into a consequential institutional decision about test validity, is just as much in scope as one that autonomously invalidates a sitting.

What the Article 6(3) filter can — and cannot — do

Article 6(3) allows a provider to register a system as non-high-risk despite falling under an Annex III heading if it genuinely poses no significant risk to health, safety, or fundamental rights. The standard cases for this filter: the system does narrow procedural work, it improves a previously completed human activity, or it detects patterns without influencing human assessment.

Exam proctoring does not fit these cases. The output is purpose-built to influence an institutional decision — test validity — that directly affects a student's educational standing. False cheating flags carry real stakes: disciplinary proceedings, lost grades, potential academic sanctions. Any provider who claims the Article 6(3) filter for a proctoring tool carries a heavy documentation burden and will face sceptical supervisory authorities. Proceed on the assumption that you are high-risk.

The Critical Boundary: Emotion Recognition Is Prohibited

Here the analysis becomes urgent. Annex III makes monitoring for behavioural misconduct high-risk. Article 5(1)(f) does something different: it prohibits AI systems that infer emotions of natural persons in the areas of education and the workplace (with narrow exceptions for medical or safety reasons).

If a proctoring system goes beyond detecting behaviours — gaze direction, multiple faces, screen switching — and begins inferring what a student is feeling during the exam (anxiety, confidence, deception-correlated affect), it crosses from high-risk into prohibited territory. The ban on emotion recognition in education has applied since 2 February 2025. It is not a future obligation; it is the law now.

Vendors should audit their feature set. Facial expression analysis, "engagement" scoring, or affect inference marketed as cheating signals are not saved by being inside a proctoring product. Strip them or confirm via your legal team that they do not, in substance, infer emotional state. This is not a grey area to manage through disclosure.

Roles: Vendor as Provider, Institution as Deployer

The EU AI Act distributes obligations across the supply chain, and proctoring involves two clearly distinct actors.

The proctoring vendor is the provider under Article 16. It develops and places the system on the market under its name. Provider obligations are the heaviest in the Act:

• Risk management system under Article 9 — a documented, lifecycle-spanning process that identifies foreseeable risks, assesses their severity, implements controls, and tracks residual risk.
• Technical documentation under Article 11 (Annex IV format) — the system's architecture, training data, performance metrics including demographic disaggregation, known limitations, and the instructions deployers need.
• Transparency information for deployers under Article 13 — what the system does, what it does not do, and how it should be operated.
• Human oversight design under Article 14 — the system must be built to allow deployers to intervene, pause, or override.
• Accuracy, robustness, and cybersecurity under Article 15.
• Conformity assessment under Article 43 before placing the system on the market.
• Registration in the EU database under Article 49.
• Post-market monitoring under Article 72 and serious-incident reporting under Article 73.

The institution is the deployer under Article 26. Its obligations are lighter but real:

• Verify the system has undergone conformity assessment and holds a CE mark / Declaration of Conformity before deployment.
• Follow the provider's instructions of use.
• Implement human oversight measures — specifically, ensure a qualified person reviews every flag before any consequential action is taken.
• Retain logs of system use for at least six months (Article 26).
• Inform students that AI monitoring is in operation.
• Report serious incidents to the provider and, where required, to the national competent authority.

One transition to watch: Article 25 says a deployer becomes a provider if it substantially modifies the system or changes its intended purpose. A university that retrains the vendor's model on its own student data, or deploys it for a use case outside the vendor's documented scope, has shifted roles. Provider obligations then attach.

Article 27 FRIA: Mandatory for Public Universities and Exam Bodies

The Fundamental Rights Impact Assessment under Article 27 is mandatory for deployers that are public bodies or bodies exercising public powers — this includes most state universities, national examination bodies, and regulated professional certification authorities. The FRIA requirement does not apply to private institutions, though good practice points in the same direction.

A FRIA for proctoring must:

• Identify the categories of people affected (students sitting exams, including any vulnerable sub-groups).
• Assess the foreseeable effects on fundamental rights — specifically the right to education (Article 14 EU Charter), non-discrimination (Article 21), privacy and data protection (Articles 7–8), and the right to an effective remedy (Article 47 Charter) in the event of a false flag.
• Document what mitigation measures are in place.
• Notify the relevant market surveillance authority before deployment.

The FRIA is not a legal formality. For proctoring, the equality analysis is the hard part: systems trained on narrow demographic datasets have documented performance disparities across skin tones, disability status, and language background. The FRIA should reflect actual testing data on your deployed system, not generic assertions of fairness.

The Discrimination and Accessibility Risk

The most substantive compliance risk in exam proctoring is not paperwork — it is discriminatory output. This is where Article 9 and Article 10 do their hardest work.

False-flag rates are not demographically neutral. Face-detection components in webcam-based systems have shown meaningful error rate disparities across skin tones, particularly for darker skin. A system that generates false cheating flags at higher rates for students of colour is producing discriminatory output under EU non-discrimination law as well as EU AI Act Article 9. The risk management system must identify this, quantify it on real deployment data, and document what controls reduce it.

Neurodivergent and disabled students face compounding risk. A student with ADHD may have gaze patterns that diverge from neurotypical baselines. A student with dyslexia types differently. A student with a motor disability may have keystroke timing that the model has never encountered in training. Article 10 requires providers to assess training data for representational gaps — datasets built on homogeneous test-taker populations produce systems that will disproportionately flag atypical behaviour. Providers must either validate performance on these sub-populations or document the limitation and require deployers to implement compensating controls (for instance, flagging cases with documented accommodations for specialist human review rather than running standard algorithmic assessment).

Deployers share responsibility here. Article 26 requires deployers to inform students of AI-based monitoring. A university that deploys proctoring without communicating to students with documented accommodations that the system has known performance gaps for their population is not meeting its oversight obligations. The provider's Article 13 information sets a floor; the deployer's Article 26 operational practices must match it.

Article 9 Risk Management in Practice

Article 9 requires a systematic, continuous process — not a one-off risk register. For a proctoring vendor, the practical structure looks like this.

Identify every foreseeable harm the system could cause: false accusations leading to disciplinary proceedings; discriminatory flagging affecting specific demographic groups; biometric data exposure; surveillance anxiety impairing student performance; accessibility barriers for students with accommodations; wrongful academic sanctions.

Assess probability and severity. A false-positive rate of 2% applied across 50,000 exam sittings is 1,000 students whose tests are flagged without cause. If even 10% of those escalate to formal disciplinary proceedings before the human review catches the error, that is 100 students facing serious consequences from an algorithmic error. Severity is high; the risk management process must reflect that.

Define mitigations. For demographic performance disparities: retraining on representative data, demographic parity audits before each new deployment context, and per-demographic threshold calibration. For disability accommodation edge cases: an automatic routing rule that sends any session tagged with a documented accommodation flag to specialist human review, bypassing standard algorithmic scoring.

Document residual risk. Some irreducible uncertainty remains in any probabilistic system. Document it honestly; deployers need this information to design appropriate oversight protocols.

Providers must update the risk management documentation whenever the system changes materially — retraining, threshold adjustment, new deployment context.

Article 10 and Training Data Governance

Article 10 applies to high-risk AI providers and governs training, validation, and testing data. For proctoring:

Training data must be representative of the intended user population, including demographic diversity across age, skin tone, disability status, and linguistic background. If the dataset was assembled from a single institution's exam sessions, document that limitation explicitly in the technical documentation.

Validation data must be kept separate from training data. Test-set performance — disaggregated by demographic group — must be reported in the Article 11 technical documentation. Providers who do not have this breakdown should treat it as a gap that needs to be closed before conformity assessment.

Data governance documentation should also cover: data collection methodology and whether participants consented; how long data is retained; and what processes govern retraining pipelines.

Technical Documentation and Conformity Assessment

Article 11 / Annex IV documentation is the evidentiary record that both the notified body and deployer institutions need. For proctoring systems it must include: a precise description of what behaviours the system is designed to detect and what its outputs mean; training data characterisation including demographic composition and known gaps; performance metrics disaggregated by subgroup; the thresholds at which flags are generated; instructions for deployer oversight; and the Article 9 risk management summary.

System-card format is useful here — a structured, modular document that deployers can work through during procurement. Universities should be asking for this documentation before signing contracts with proctoring vendors; vendors who cannot produce it are not yet ready for EU deployment.

Conformity assessment under Article 43 follows one of two routes. Most proctoring vendors will use the internal control procedure (Annex VI) if their system is not also a safety component of a regulated product, combined with documentation of a quality management system. Where Annex III point 3 systems present higher risk profiles, a notified body review may be required; vendors should confirm the applicable pathway with legal counsel. Either way, the output is the EU Declaration of Conformity (Article 47) and the CE mark, which deployers must verify before signing deployment contracts.

Registration under Article 49 in the EU database is mandatory for providers before the system goes to market. For systems using the Article 6(3) non-high-risk self-assessment, registration is still required — providers must log the assessment itself.

The Worked Example: A Certification Body and Its Vendor

A mid-sized professional certification body in the Netherlands deploys a third-party AI proctoring tool for its online exams. The certifying body is a public-law entity; it therefore carries both Article 26 deployer obligations and Article 27 FRIA requirements.

Before deployment:

• The certification body requests the vendor's Article 11 technical documentation, including the demographic performance report. It discovers the system's face-detection component was validated only on European-origin faces.
• It commissions an independent demographic audit of the vendor's system, finds a meaningful false-flag rate disparity for candidates with darker skin tones, and negotiates a contractual requirement for the vendor to produce a remediated version before launch.
• The FRIA documents this finding, records the mitigation (contractual requirement plus specialist human review for all flags pending the technical fix), and is filed with the Dutch national competent authority.
• Staff who will review flagged sessions receive training on the system's known limitations and documented biases.

At deployment:

• Every candidate is informed before the exam that AI monitoring is in operation, what data is collected, and how to contest a flag.
• No session is acted upon solely on the basis of the algorithmic output. Every flag is reviewed by a qualified staff member with access to full session context and the candidate's accommodation record.
• Sessions from candidates with documented accommodations are routed automatically to a senior reviewer who has completed additional training on atypical behaviour patterns.

Post-deployment:

• The certification body logs all flags, all override decisions, and outcomes. It reports aggregate flagging rates to the vendor quarterly.
• Within the first six months, the body identifies that flagging rates for one demographic sub-group remain elevated. It reports this to the vendor as a serious incident under Article 73 and suspends use of the automated score for that sub-group pending vendor remediation.

This is what Article 26 compliance looks like operationally — not a box-tick but an active oversight programme.

GDPR Intersection

Proctoring systems collect biometric data by design: facial images, potentially facial geometry, keystroke dynamics, audio. Biometric data is special-category data under GDPR Article 9. Processing it requires either explicit consent or another Article 9(2) basis — for most institutional exam settings, consent is structurally problematic (is a student who needs to pass an exam genuinely free to withhold consent?).

Institutions commonly rely on Article 9(2)(g) (substantial public interest) or contractual necessity, but the legal basis must be documented in the DPIA, which is required for biometric processing at scale under GDPR Article 35. The EU AI Act does not displace GDPR; both apply simultaneously. Vendors building proctoring tools for EU deployment must design with data minimisation in mind: collect only what is needed for the stated monitoring purpose, define retention periods, and give students rights of access and erasure over their biometric records.

One practical tension: Article 72 post-market monitoring requires providers to retain data about real-world system performance. GDPR requires data minimisation and deletion. Providers should design their monitoring systems to retain aggregated, anonymised performance data rather than individual biometric records beyond what GDPR permits.

How Confir Helps

Confir's rule-based engine encodes the EU AI Act's role-determination logic directly. Answer a series of plain-English questions about how your proctoring system is built and deployed; Confir derives whether you are a provider or deployer, whether Article 27 FRIA applies to your organisation, and which of the 40+ high-risk controls apply to you specifically — with no ambiguity and no consultant required.

For proctoring vendors (providers), Confir generates the Annex IV technical documentation pack and the Article 47 Declaration of Conformity, pre-structured to the format conformity assessment requires. The Article 9 risk management module captures your hazard inventory, severity assessments, and mitigation records in a single auditable log — the format authorities and notified bodies expect.

For institutions running the Article 27 FRIA, Confir's FRIA workflow walks through each required element — rights affected, populations at risk, mitigations, authority notification — and produces a structured, print-ready assessment.

FAQ

Is all AI used in education high-risk under the EU AI Act?

No. Only systems that fall within the specific Annex III, point 3 categories are high-risk: AI for admissions or selection of natural persons; evaluation and assessment of learning outcomes; determining access to educational paths; and monitoring and detecting prohibited student behaviour during tests. An adaptive learning tool that personalises content, or an automated essay scorer that marks a submitted paper, sits outside these categories and is minimal risk unless it profiles individual students in a consequential way.

Does the emotion recognition ban apply to proctoring systems?

Yes, if the system infers emotional states. Article 5(1)(f) has prohibited AI that infers emotions in the areas of education and the workplace since 2 February 2025. A proctoring system that analyses facial expressions to infer anxiety, deception-correlated affect, or any emotional state crosses this line. Detecting observable behaviours (where a student is looking, whether a second face is visible) is different from inferring internal states. Vendors must be clear about which side of that line their feature set sits on.

Does the FRIA apply to private universities?

Article 27 applies to deployers that are public bodies or entities exercising public powers when deploying a high-risk AI system in a professional context. Many universities in EU member states are public-law entities or substantially publicly funded; they should take legal advice on their status. Fully private institutions are not in scope for the mandatory FRIA, but they retain all Article 26 deployer obligations, including human oversight and student notification. The FRIA is good practice regardless of legal mandate — the fundamental rights analysis it requires is the same analysis that de-risks deployment operationally.

What are the penalties for non-compliance?

Under Article 99(4), the maximum fine for breaching high-risk obligations is €15,000,000 or 3% of total worldwide annual turnover, whichever is higher. For companies that qualify as SMEs or start-ups, the fine is capped at whichever of the percentage or fixed amount is lower — a proportionality protection written into the Act at Article 99(6). These fines apply from 2 December 2027 for stand-alone Annex III systems. Deployers that deploy a non-compliant system also face fines under Article 99(4); the liability sits with both sides of the supply chain.

When must proctoring vendors be compliant?

For stand-alone Annex III systems, the high-risk obligations apply from 2 December 2027 under the Digital Omnibus agreed in May 2026 (political agreement; formal adoption expected before August 2026). The original date of 2 August 2026 has been deferred. Conformity assessment for proctoring systems typically takes six to twelve months once documentation is assembled, and the documentation itself takes several months to compile correctly. Vendors who wait until mid-2027 to start will find the timeline very tight.

Can a proctoring vendor claim the Article 6(3) non-high-risk exemption?

Theoretically, Article 6(3) allows a provider to self-declare non-high-risk status if the system poses no significant harm. In practice, the exemption is extremely difficult to sustain for a proctoring tool: the system's output directly influences a consequential institutional decision about test validity and student standing. Any system that profiles natural persons is explicitly excluded from the exemption. Providers should assume high-risk status and build accordingly. Claiming the exemption against evidence of real-world harm would be a serious aggravating factor in any supervisory investigation.

Related guides

• Article 6 high-risk classification
• AI student admission selection requirements
• enterprise compliance implementation guide
• Article 9 risk management framework
• determine if your system qualifies
• Annex III high-risk use cases
• Article 8 compliance requirements
• social benefits eligibility assessment systems
• medical imaging AI compliance obligations
• biometric identification Category 1 obligations