EU AI Act for education and edtech: what applies

Does the EU AI Act apply to our education AI, and what does it cost to get ready?

Admission, grading, level assessment and exam proctoring AI are high-risk under Annex III point 3, and the high-risk rules for Annex III systems apply from 2 December 2027, as amended in 2026. If your school, university or edtech product uses AI for any of these functions, you should treat the Act as applying now for planning purposes, even though the main obligations bite later. Annex III point 3 also covers AI that steers learning, assesses learning outcomes, or monitors students during tests for prohibited behavior, so the scope is wider than most procurement teams expect. Separately, Article 5(1)(f) has prohibited AI that infers emotions of people in education institutions since 2 February 2025, unless the system is intended for medical or safety reasons. Check whether any tool your institution already runs, including webcam-based engagement or attention features, falls under that ban today.

Whether you are a deployer (the school or university using the system) or a provider (the edtech vendor placing it on the market) decides which duties land on you, and the role can differ for the same product. Cost and effort then depend on that role, the number of systems in scope, and how mature your existing evidence is, such as documented logs, instructions for use and human oversight records. The organization always owns its controls. An implementation partner can prepare systems, documentation and evidence, but only an independent assessor or certification body issues any report or certificate. No fixed price is given here because the work follows from the scope you define. Confirm with your legal team whether your use is covered by Annex III or an exception under Article 6(3) before you commit budget.

For a first estimate, ask every AI vendor for a written statement of the intended purpose of each feature and whether it touches admission, grading, level assessment or proctoring. Ask your team to list every system already in use, including features switched on by default in a learning platform update. Then ask potential partners for a quote built from that inventory, separating one-time work (classification, documentation, risk management set-up, oversight design) from recurring work (log retention, monitoring, re-review after updates). Ask what each quote assumes about the number of systems, the role you hold, and what evidence already exists. Those answers, not a headline figure, will show what getting ready will cost your institution.

Which education uses are high-risk under Annex III point 3?

Annex III point 3 names four education uses that become high-risk when an AI system performs them. Each card below covers one use, what it catches in practice, and what to verify before deciding a system falls inside it.

Access and admission decisions

Systems intended to determine access or admission to education and vocational training are high-risk. This catches applicant ranking, admission scoring and automated routing of applications to programs or course places. Check whether the tool only sorts or formats applications for staff, or whether its output effectively decides who gets a place, because that difference drives the classification. Confirm the intended purpose stated in the vendor's instructions for use, since it defines the scope.

Evaluating learning outcomes

Systems that evaluate learning outcomes are high-risk, including where the evaluation is used to steer the learning process. This covers automated grading of essays or exams, feedback engines that set next learning steps, and adaptive platforms that decide what a learner studies next. Institutions should confirm whether a tool produces a final grade, a recommendation, or only a suggestion a teacher reviews, since human oversight duties under Article 26 apply to the deployer regardless of the label.

Assessing the level of education

Systems intended to assess the level of education a person will receive or will be able to access are high-risk. This can reach placement tests that set a track, language level assignments and tools that determine which qualification pathway a learner is offered. Check whether the output fixes a learner's level or only informs a placement advisor, and document the decision logic so you can explain outcomes to the affected person.

Monitoring prohibited behavior during tests

Systems intended to monitor and detect prohibited behavior of students during tests are high-risk. Remote proctoring that flags gaze movement, audio, multiple faces or screen activity falls here. Two checks matter: whether the system infers emotion, which Article 5(1)(f) prohibits in education institutions except for medical or safety reasons, and whether a human reviews every flag before a sanction follows. Ask the vendor to confirm both in writing.

Why emotion recognition in classrooms is banned outright

Article 5(1)(f) prohibits AI systems that infer the emotions of natural persons in education institutions, and the same prohibition covers the workplace. Unlike a high-risk system, which can be placed on the market once it meets the requirements, this practice is banned outright. The only carve-out is for systems intended for medical or safety reasons. A school, university or training provider cannot rely on a general product benefit, such as improving engagement or supporting wellbeing, to bring an emotion-inferring tool within that exception. The question for an education buyer is therefore not how to manage the risk of such a tool, but whether the tool can be used at all.

The practical difficulty is that the prohibited behavior is often hidden inside a product that is sold for something else. Online proctoring tools, lesson analytics dashboards and video-based classroom assistants may describe their outputs as attention, focus, stress, confusion or disengagement. Whether those labels amount to inferring emotions depends on what the system actually derives from face, voice, gaze or body signals, and not on the marketing term. Before any pilot, ask the vendor in writing which signals the product processes, which outputs it generates for each signal, whether any output is shown to teachers, students or administrators, and whether the model was trained or validated to detect emotional states. Ask for the technical documentation rather than a summary slide.

If the vendor cannot give a clear answer, treat the feature as a likely prohibited practice and disable or remove it before the system is used with students or staff. Keep the vendor's written answers in the file for the AI system, since they become part of the evidence an institution would need if a market surveillance authority asked how the tool was assessed. Where a product includes an emotion-inference feature alongside legitimate functions, the safer design is to confirm that the feature is switched off and cannot be re-enabled by a local administrator. Under Article 99, prohibited practices carry the highest fine tier: EUR 35 million or 7% of worldwide annual turnover, whichever is higher.

What schools and edtech vendors must do as deployers and providers

Schools, universities, training providers and other institutions that use an Annex III point 3 system are deployers. They do not design the system, but they decide how it runs in admissions, grading and exam settings, so the Act places operating duties on them. The obligations for Annex III systems apply from 2 December 2027, while AI literacy under Article 4 already applies and the Article 26 text sets the operating duties.

Use the system per its instructions: Configure and run the product only for the uses the provider describes, and apply technical and organizational measures such as role-based access and approved use cases under Article 26(1) and (2).
Assign competent human oversight: Name staff who have the competence, training, authority and support to review outputs and overrule them. For example, a proctoring flag should go to a person who can dismiss it (illustrative).
Inform students and applicants: Under Article 26(11), tell people when a system makes or assists decisions about them, and put that notice in admissions and assessment workflows.
Keep AI literacy current: Article 4 requires measures so that staff and others operating AI on the institution's behalf have sufficient AI literacy for their role, and records of training help show this.

Before go-live, confirm that each use case has a named overseer, a student-facing notice and a training record, and ask the vendor which logs the system produces and how long they are kept.

How to get an education AI system ready before 2 December 2027

This sequence takes an institution or edtech vendor from an unknown set of AI features to a documented, classified and evidenced position on the high-risk rules that apply to Annex III education systems from 2 December 2027.

Inventory every AI feature in scope
List every AI feature in use or planned across admissions, learning platforms, assessment, proctoring and student support, including features bought from vendors and features built in-house. Record the vendor, the version, the data each feature uses and the people it affects. Work with procurement and the data protection officer so that nothing sits outside the list. The step is done when the inventory has a named owner and every feature has a row. The inventory is also the starting point for every later step.
Map each feature to Annex III or Article 5
For each inventory row, decide whether the feature falls under Annex III point 3, which covers access or admission, learning outcome evaluation, the level of education a person will receive, and monitoring of prohibited behavior during tests. Check separately whether any feature infers emotions of students or staff, which Article 5(1)(f) prohibits in education institutions except for medical or safety reasons. Record the reasoning for features that look borderline, including any reliance on the Article 6(3) exemption. Confirm the working interpretation against the draft Commission guidelines on classification. The output is a classification memo that signs off each feature as high-risk, prohibited, or outside the high-risk rules.
Assign provider and deployer roles
Decide, for each high-risk feature, whether the institution is a deployer, a provider, or both. A school that buys a grading tool and uses it under its own name is normally a deployer. A school that repurposes a vendor tool for a new education purpose, or puts its own system on the market, may become a provider. Confirm the vendor's role and the contract terms that allocate instructions, logs and support. The output is a role register that names, for each system, the legal entity responsible for each set of obligations and the contract clauses that back it up.
Gap-assess against Articles 16 and 26
Compare the current state of each system with the provider obligations in Article 16, including quality management, documentation, log keeping, conformity assessment, registration and accessibility, and with the deployer obligations in Article 26, including use under the instructions for use, competent human oversight, log retention and informing affected people under Article 26(11). Use a control-by-control worksheet and mark each gap with an owner. Ask vendors for their conformity evidence in writing. The output is a gap register with a prioritized remediation plan that the governance board has reviewed.
Build the technical file and logging
For providers, prepare the technical documentation and the logging capability the Act requires, covering the system's intended purpose, data governance, performance limits, human oversight design and risk controls. For deployers, collect the vendor documentation, configure logging on the platform where the institution controls it, and set a retention rule. Store evidence in a controlled repository with version history. The output is a technical file for each provider system and a deployer evidence folder for each deployed system, each reviewed against the gap register.
Run the Annex VI internal control procedure
For Annex III point 3 systems, the conformity assessment route is the internal control procedure in Annex VI, which does not involve a notified body. The provider performs the checks itself, verifies that the quality management system and technical documentation meet the requirements, and records the result. Where the provider is an outside vendor, confirm that the vendor has run this procedure and ask for the evidence. An independent assessor can review the work, but only the provider's own assessment establishes conformity. The output is a signed internal control record for each system, which feeds the EU declaration of conformity.
Register and confirm readiness before the date
Prepare the EU declaration of conformity and the CE marking where the provider route requires them, and complete registration of the high-risk system in the EU database where Article 49 applies. Confirm the deployer notices and the human oversight assignments are in place for every system still in use. Check the list against the inventory so no system is missing. The output is a readiness report signed by the accountable executive, with a dated review cycle ahead of 2 December 2027. Ask your auditor or advisor to confirm scope, but remember that the institution, not the consultant, owns the declaration.

What makes education AI compliance more or less expensive

The effort to comply with the AI Act in education depends less on the software itself than on how many AI uses the institution runs, how much it changes them, and what records it already keeps. Each driver below can be scoped, and most of them can be reduced before a quote is written.

Number of AI features in scope

Each AI feature that decides admission, grades learners, assesses their level or monitors students during tests is a separate high-risk system to inventory, document and oversee. Features that only generate study aids or summarize notes may fall outside Annex III entirely. Ask the vendor which features are in scope and whether each one is switched on in your tenancy, since disabled features rarely need a separate file.

Customization and fine-tuning

If the institution only configures a vendor tool, it is usually a deployer. If it retrains a model, changes its intended purpose or repackages it under its own name for other institutions, it may take on provider duties, which include a quality management system and conformity assessment. Confirm with counsel where that line falls for each change before scoping, because provider status adds more work than any other single factor.

Data sources and student volume

Systems that draw on learning records, assessment history, attendance or behavioral data need documented data governance and clear data flows. The number of learners affected and the number of data sources each system reads both increase the testing, monitoring and log review needed. Ask vendors where training and inference data is stored, how long it is kept, and whether it can be exported for your own records.

Campuses and jurisdictions

Each campus, faculty or national education authority can impose its own rules on admissions, proctoring and data protection, and each may need its own deployer instructions and oversight roles. Multi-country institutions also face several market surveillance authorities. Map the sites and member states where each system is used before estimating effort, and decide whether one central control set can cover all of them.

Third-party models and suppliers

When an edtech product calls an external general-purpose model, responsibilities split across the institution, the edtech vendor and the model supplier. Contracts must show who supplies documentation, logs, incident notices and changes to the model. Review each subprocessor in the chain and confirm how the vendor will notify you when the underlying model changes, since a model swap can alter the risk classification.

Maturity of existing evidence

Institutions that already keep system logs, change records, vendor assessments and access reviews can reuse them for AI Act evidence. Institutions without them will need to build a record from scratch for each high-risk system. Before requesting a quote, check whether your current logging covers AI decisions, whether human reviewers' overrides are recorded, and whether vendor documentation is current.

Who owns the controls, who prepares the evidence, and who issues the report

The school, college, university or training provider that uses an AI system is the deployer. An edtech company that places an admissions, grading or proctoring system on the market is the provider. Either way, the organization owns the legal duties and the decisions about whether, where and how a system is used. Those duties do not transfer to a consultant because work was outsourced.

Classification decisions: Deciding whether a system falls under Annex III point 3 and documenting the reasoning, including any Article 6(3) argument.
Human oversight: Assigning oversight to staff with the competence, training, authority and support that Article 26 requires.
Learner information: Telling students and applicants when a high-risk system makes or assists decisions about them.
Provider duties: For vendors, owning the quality management system, technical documentation, conformity assessment and registration.
Sign-off: Only the organization can approve the EU declaration of conformity it issues as provider.

Check that your contracts and governance records name the owner of each of these duties before any partner starts work.

Questions education buyers ask about the EU AI Act

Is a school using a licensed exam proctoring tool a deployer under the EU AI Act?

Yes, in most cases a school that runs a licensed proctoring tool under its own authority is a deployer, because the Act defines that role by use within the EU. Annex III point 3 lists AI systems intended to monitor and detect prohibited behavior of students during tests as high-risk, so this use falls in the high-risk category. As a deployer, the school must use the system according to the provider's instructions for use, and it must assign human oversight to staff with the necessary competence, training, authority and support (Article 26(1) and (2)). It must also inform students that they are subject to the system (Article 26(11)). Separately, Article 5(1)(f) bans systems that infer emotions in education institutions, except for medical or safety reasons, so confirm in writing that the tool does not do this.

Does customizing an edtech product make a school its provider?

It can, and the answer depends on what the school does with the system and whether it places the system on the market or puts it into service under its own name, not on how much code it changes. The Act's rules on who counts as a provider also cover deployers that modify a system or change its intended purpose, so the question should be settled with counsel before the contract is signed. If the school does become a provider of a high-risk system, it takes on the provider duties in Article 16, including a quality management system, documentation, log keeping, conformity assessment, an EU declaration of conformity, CE marking, registration and corrective action. For example, an illustrative case would be a school that retrains a vendor's grading model on its own criteria and then uses it for grading decisions. Put the allocation of these duties in the contract, including who owns each change.

Does the 2027 date give schools enough time to act now?

Less time than the date suggests, because several duties already apply. Under Regulation (EU) 2026/1744, the high-risk rules for Annex III systems apply from 2 December 2027. The prohibitions in Chapter II and the AI literacy duty in Article 4 have applied since 2 February 2025, and Article 4 covers all AI systems, not only high-risk ones. This means the classroom ban on emotion inference is already in force. Before 2027, a school needs an inventory of its AI systems, a decision on its role for each system, and written answers from vendors about their conformity route and documentation. Those steps depend on procurement and contract cycles, so starting them now leaves more room for review. Confirm the current dates against the consolidated text of the Act.

What must our institution do itself, and what can we hand off?

The institution must own the decisions and the people-facing duties, and it can hand off preparation work that does not carry those duties. Keep these tasks internal:

Maintain the inventory of AI systems and decide the role the institution holds for each one
Assign human oversight of high-risk uses, such as admission, grading and exam monitoring, to named staff with competence, training, authority and support
Inform students and staff that they are subject to a system, and deliver AI literacy training to the staff who operate it
Use each system according to the provider's instructions and keep the logs the deployer controls

A vendor or implementation partner can prepare technical configuration, documentation packs and evidence records. For Annex III systems, the provider carries the internal control procedure in Annex VI and issues the EU declaration of conformity, so ask the vendor to show both before purchase.

Can a consultant take over AI Act ownership from our staff?

No. The institution owns its obligations under the Act, and an outside party can prepare systems, controls and evidence, but it cannot carry the duties in the institution's place. Article 26 requires oversight by people inside the deployer with the authority to act, so a consultant can support that role without replacing it. DeployOpen prepares systems, controls and evidence for compliance assessments, and it does not issue audit reports, attestations or certifications. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask any consultant to name the internal owner for each task, what they will hand over at the end, and which parts remain with the institution after the engagement closes. Ongoing support is available as a retainer.

Do we need a notified body for an education AI system?

Usually not for an education system in Annex III. Article 43(2) directs the Annex III categories for points 2 to 8, which include education, to the internal control procedure in Annex VI, and that procedure involves no notified body. Notified bodies become relevant for some biometric systems and for Annex I products (Article 43). For that reason, check whether the proctoring tool uses biometric identification, such as matching a student's face against a reference image, because that can change the conformity route. Ask the vendor to state the route in writing, with the evidence it will provide. Independent certification bodies, not implementation partners, issue certificates where a route requires them.

How to choose an implementation partner for education AI

An education AI system is high-risk when it decides admission, grades learners or proctors tests, so the partner you choose will touch student data and evidence that an assessor later reviews. The four checks below test where the partner works, how the work is priced, where its role ends and how it treats learner data and emotion-related features.

Confirm work inside your infrastructure

Ask whether the partner deploys and operates the system inside your cloud accounts, data center or private network, and who holds the administrator credentials. Student records, grading data and proctoring logs should stay under your control, with the partner working through access you can revoke. Ask which logs, configuration records and instructions for use the partner will hand over to you, since Article 26 expects deployers to use high-risk systems according to the provider's instructions. Confirm that you can reproduce the setup from documentation if the partner leaves.

Require a written fixed scope

Ask for a written scope that names the systems, the AI features in each, the evidence to be produced and the deliverables, before any work starts. A fixed scope makes it clear whether the partner is preparing a provider's technical documentation, configuring a deployer's oversight and logging, or both. Request the timeline and the acceptance criteria in the same document. Confirm which changes to scope require a new written agreement, since product updates to grading or admissions features can change the high-risk analysis.

Separate preparation from independent assessment

Ask the partner to explain, in writing, what it prepares and what it never signs. Preparation includes evidence collection, control configuration, gap analysis and documentation drafting. Only an independent auditor, assessor or certification body issues reports or certificates. For Annex III education systems, the conformity route is internal control under Annex VI, so the provider signs the declaration. Check that the partner does not describe its own work as a conformity assessment and that your organization remains the owner of its controls.

Ask how learner data and emotion features are handled

Ask how the partner minimizes, segments and deletes student data during implementation, and whether test environments use real learner records. Ask the partner to check your product for emotion recognition, since Article 5(1)(f) bans inferring emotions of people in education institutions unless the use is for medical or safety reasons. Request a written list of any affect-detection or attention-monitoring features, and confirm they are disabled or removed before deployment. Ask for the partner's approach to logging these checks so an assessor can see the decision.

How DeployOpen prepares education AI systems for compliance review

DeployOpen works on EU AI Act for education and edtech as an implementation partner. We prepare the systems, controls and evidence that an institution or edtech vendor needs for review, inside the client's own infrastructure. Only an independent auditor, assessor or certification body issues reports or certificates.

How we scope

We map which uses in your environment fall under the education categories of Annex III, including admission, grading and proctoring.
Engagements are fixed-scope, with systems, deliverables and timelines agreed in writing before any work starts.
We confirm whether you act as a deployer, a provider, or both, because the duties differ for each role.

How we build

We set up the self-hosted open-source platforms in your own cloud accounts, data centers or air-gapped networks.
We configure logging, access controls and human oversight workflows so the records needed for review are produced by default.
We check that emotion recognition features are disabled or excluded from the deployment where the prohibition applies.

How we hand over

We deliver the system inventory, configuration records, instructions for use and the logs and oversight records for each system in scope.
We document the controls and evidence mapped to each obligation so your compliance lead and assessor can trace them.
We run a readiness walkthrough with your staff so the people overseeing these systems understand their role and authority.

How we support

Ongoing support, upgrades and continuous security testing are available as retainers after handover.
We can help you prepare for the December 2027 date for Annex III systems, with the work agreed in your written scope.
Ask us to confirm which parts of the review fall to your auditor or notified body, and which parts remain with your team.

EU AI Act for education and edtech