The EU AI Act for universities: what deployers must do in 2026

Most universities are not AI developers. They are deployers: they buy or license AI tools and use them on staff, students and applicants. This guide sets out what the AI Act already requires of a university on 7 October 2026, what the AI Omnibus moved to December 2027, and how to build an AI register that also feeds your GDPR work.

Published 7 October 2026 · Sources checked 7 October 2026

Timeline: what applies on 7 October 2026

The AI Act (Regulation (EU) 2024/1689) entered into force on 1 August 2024 and applies in stages. On 19 November 2025 the Commission proposed a targeted amendment, the "AI Omnibus", as part of its digital simplification package. That proposal has now completed the legislative process. According to the European Parliament's Legislative Observatory, Parliament adopted its first-reading position on 16 June 2026, the Council adopted the act on 29 June 2026, it was signed on 8 July 2026 and published in the Official Journal on 24 July 2026 as Regulation (EU) 2026/1744 [4]. The Commission confirms that it entered into force on 27 July 2026 [2].

The resulting dates, as set out in the amended Article 113 [5] and the Commission's official timeline [3], are:

The Commission's proposal had linked the start date to the availability of standards, with a backstop [12]; the adopted text sets a fixed date of 2 December 2027 for Annex III systems [5]. Only the high-risk chapter moved. AI literacy, the prohibitions and the transparency rules were not postponed.

The EUR-Lex website was only partly available on 7 October 2026 and we could not open the Official Journal text of Regulation (EU) 2026/1744 directly. We read the amended articles in the Commission's AI Act Service Desk explorer, which marks each amended and new provision, and confirmed the procedure dates on the Parliament's Legislative Observatory.

Provider or deployer: which one is your university?

The AI Act places most obligations on providers and a narrower set on deployers. The definitions in Article 3 [6] are:

• Provider: a natural or legal person, public authority, agency or other body that develops an AI system (or has one developed) and places it on the market or puts it into service under its own name or trademark, whether for payment or free of charge (Article 3(3)).
• Deployer: a natural or legal person, public authority, agency or other body using an AI system under its authority, except in a personal non-professional activity (Article 3(4)).

In practice a university is a deployer for almost every licensed tool: a learning platform with AI features, a transcription service, a chatbot licence for staff. The vendor is the provider. The Act applies to deployers established or located in the EU, and to non-EU providers and deployers where the output is used in the EU (Article 2(1)) [7].

A university can become a provider in two ways that matter:

1. Building in house. If a faculty or IT department develops an AI system and puts it into service for its own use under the university's name, for example an in-house admissions scoring model, the definition of provider covers that. Public authorities are named in the definition.
2. Changing the purpose of a general tool. Article 25(1)(c) says a deployer is treated as the provider of a high-risk system if it modifies the intended purpose of an AI system, including a general-purpose AI system, that was not high-risk, so that it becomes high-risk [8]. Using a general chatbot to propose grades that count towards a final evaluation is the kind of scenario to check carefully against this provision.

Validemic's analysis The second route is the one universities most often overlook. A teacher who wires a general chatbot into a marking workflow has not bought a high-risk system, but the use may still be an Annex III use. Your register should record the actual use, not only the product.

Article 4: AI literacy in practice

AI literacy has applied since 2 February 2025. The AI Omnibus amended Article 4. The text now reads, in substance [9]:

• Providers and deployers shall take measures to support the development of AI literacy of their staff and other persons dealing with the operation and use of AI systems on their behalf, taking into account their technical knowledge, experience, education and training, the context of use and the people on whom the systems are used (Article 4(1)).
• The obligation "does not require providers or deployers to guarantee any specific level of AI literacy of any individual" (Article 4(1)).
• The Commission and the Member States shall support these efforts, and the Commission shall publish practical examples of compliance (Article 4(2)). The AI Board shall adopt recommendations (Article 4(3)).

Article 3(56) defines AI literacy as the skills, knowledge and understanding that allow providers, deployers and affected persons to make an informed deployment of AI systems and to be aware of the opportunities, risks and possible harm [6].

What the Commission's Q&A says

The Commission's AI literacy Q&A, updated after the Omnibus, is the most practical guidance available [10]. Points relevant to universities:

• AI literacy remains an obligation, but no specific or "sufficient" level is mandated after the amendment.
• There is no duty to measure employees' knowledge, no certificate is needed, and organisations can keep an internal record of training and other guidance.
• No specific governance structure, such as an AI officer, is mandated for Article 4.
• "Other persons" acting on the deployer's behalf can include contractors and service providers.
• An organisation whose staff use ChatGPT for writing or translation must still comply; staff should be informed about specific risks such as hallucination.
• Relying only on instructions for use, or asking staff to read them, may be ineffective in many cases.
• For deployers of high-risk systems, the separate duty to ensure staff assigned to human oversight are trained remains in place (see Article 26).
• Supervision and enforcement of Article 4 sit with national market surveillance authorities, not the AI Office.

The Q&A suggests a minimum approach: a general understanding of AI in the organisation, clarity on whether the organisation is a provider or deployer, awareness of the risks of the systems used, and literacy actions built on that analysis and tailored to the audience and context [10].

Staff and students

Article 4 covers staff and other persons dealing with AI systems on the university's behalf. Students using a tool for their own studies are generally affected persons or users rather than people acting on the university's behalf. The definition of AI literacy does mention affected persons, and the Q&A notes that literacy can also be useful for clients depending on the risk [10].

Validemic's analysis A proportionate university programme usually has three layers: a short general module for all staff who use AI tools; role-specific guidance for groups with higher exposure (admissions officers, examiners, IT and procurement, researchers handling personal data); and practical training for anyone who will oversee a high-risk system from December 2027. Students who act for the university, for example as teaching assistants who grade, fit the "on its behalf" category for that role. Keep a dated record of what was offered and to whom.

Article 5: prohibitions that matter in education

The prohibited practices have applied since 2 February 2025 [5]. Most are far from university life, but one is aimed directly at education.

Emotion recognition in education institutions

Article 5(1)(f) prohibits placing on the market, putting into service for this purpose, or using AI systems "to infer emotions of a natural person in the areas of workplace and education institutions", except where the system is intended for medical or safety reasons [11]. A university is both a workplace (for staff) and an education institution (for students), so the ban covers both groups.

The Commission's guidelines on prohibited practices give education-specific examples [13]:

• The term education institutions is broad: public and private, all levels, online, in person or blended. The prohibition also applies to candidates during the admissions process.
• Eye-tracking in online exams to detect use of unauthorised material is not prohibited, because it does not infer emotions. If the same system also detects emotions such as arousal or anxiety, that use falls within the prohibition.
• Using emotion recognition to infer students' interest or attention is prohibited. Using it during admissions tests is prohibited.
• Emotion recognition in a role-play for training (for example training actors or teachers) is allowed only if the results cannot affect the evaluation or certification of the person being trained.
• The medical and safety exception is narrow. A system to detect burnout or depression in an education institution is not covered by it.

The guidelines link the prohibition to biometric data: the definition of an emotion recognition system refers to inferring emotions or intentions on the basis of biometric data, such as voice or facial expressions [13]. Note that the Commission's guidelines are non-binding; authoritative interpretation is for the Court of Justice.

Other prohibitions to screen for

Also screen for biometric categorisation that infers sensitive characteristics (Article 5(1)(g)) and social scoring (Article 5(1)(c)). From 2 December 2026, new points (ba) and (bb) prohibit AI systems that generate non-consensual intimate imagery of identifiable people or child sexual abuse material, under the conditions in Article 5(1a) [11][5].

Annex III: high-risk education use cases

Annex III point 3 lists four education use cases as high-risk [14]:

Recital 56 explains the reason: these systems may determine a person's educational and professional course and their ability to secure a livelihood, and may perpetuate discrimination [15]. Annex III point 1(c) separately lists emotion recognition systems as high-risk where they are not prohibited, which in education they generally are.

The Article 6(3) filter

An Annex III system is not high-risk if it does not pose a significant risk of harm, including by not materially influencing the outcome of decision-making, and at least one of four conditions applies: a narrow procedural task; improving the result of a previously completed human activity; detecting decision patterns without replacing or influencing the human assessment without proper review; or a preparatory task to an assessment (Article 6(3)) [16]. The filter never applies where the system performs profiling of natural persons. A provider that relies on the filter must document its assessment before placing the system on the market (Article 6(4)).

The Commission's draft examples

The Commission's draft guidelines on high-risk classification were open for consultation until 23 July 2026 and had not been formally adopted when we checked [17]. They are still the clearest indication of how the Commission reads point 3 [18]:

• In scope: automated admissions systems that evaluate applications to determine eligibility; AI grading of tests and exams that count towards a final evaluation; adaptive placement tools; AI proctoring that monitors test takers using facial recognition, keystroke analysis or screen monitoring.
• Out of scope: a university chatbot that answers general admissions questions; a language-learning app used voluntarily that leads to no credential; plagiarism checks of homework against existing content, because they do not involve live monitoring during a test.
• In scope but filtered out by Article 6(3): tools that index, translate or organise application files; a grade calculator that averages weighted marks; a checker that flags errors in an exam paper written by a teacher; a tool that reviews past admissions decisions for inconsistencies.

Because these examples are draft, treat them as guidance for triage, not a final answer. The free AI Act education checker walks through the same questions.

Reviewing a vendor right now? Validemic checks the vendor's documents against GDPR and the EU AI Act and cites every finding. Try the demo workspace

Article 26: deployer obligations

Article 26 sits in Chapter III, Section 3, so for Annex III systems it applies from 2 December 2027 [5]. The main duties for a university deploying a high-risk system are [19]:

1. Use according to the instructions for use, with appropriate technical and organisational measures (Article 26(1)).
2. Human oversight by people with the necessary competence, training and authority, and support (Article 26(2)).
3. Input data: where the university controls input data, ensure it is relevant and sufficiently representative for the intended purpose (Article 26(4)).
4. Monitoring on the basis of the instructions for use; inform the provider, and where there is a risk, the market surveillance authority, and suspend use. Serious incidents must be reported to the provider first and then the authorities (Article 26(5)).
5. Logs: keep automatically generated logs under the university's control for a period appropriate to the purpose, at least six months unless other law (notably data protection law) provides otherwise (Article 26(6)).
6. Workers: before using a high-risk system at the workplace, inform workers' representatives and affected workers (Article 26(7)).
7. Registration: deployers that are public authorities must comply with the registration duties in Article 49 and must not use a high-risk system that is not registered in the EU database (Article 26(8)). Article 49(3) requires such deployers to register their use [20].
8. DPIA link: use the provider's Article 13 information to carry out the GDPR data protection impact assessment where one is required (Article 26(9)).
9. Inform people: deployers of Annex III systems that make or assist decisions about people must inform them that they are subject to the system (Article 26(11)).
10. Cooperate with competent authorities (Article 26(12)).

Article 86 also gives affected persons a right to clear and meaningful explanations from the deployer of the role a high-risk Annex III system played in a decision with legal or similarly significant effects on them [21]. A rejected applicant would ask the university, not the vendor.

Validemic's analysis Whether a university is a "public authority" for Article 26(8) depends on its legal status under national law. Many public universities will be; private institutions may not be. Ask your legal office now, because it determines whether you must register uses in the EU database.

Article 27: fundamental rights impact assessment

Before deploying a high-risk Annex III system (other than critical infrastructure), Article 27(1) requires a fundamental rights impact assessment (FRIA) from three groups of deployers [22]:

• bodies governed by public law;
• private entities providing public services;
• deployers of the credit-scoring and insurance-pricing systems in Annex III points 5(b) and (c).

Recital 96 names education as an example of an area where private entities provide public services [23]. So both public universities (normally bodies governed by public law) and many private higher education institutions should expect to be covered. Check your institution's status with your legal office.

The assessment must describe [22]: the processes in which the system will be used; the period and frequency of use; the categories of people and groups likely to be affected; the specific risks of harm to them, taking account of the provider's information; how human oversight will be implemented; and the measures if risks materialise, including internal governance and complaint mechanisms. It applies to the first use and must be updated when elements change. The results must be notified to the market surveillance authority using a template from the AI Office (Article 27(3) and (5)).

The Omnibus amended Article 27(4) and (5): where obligations are already met through a GDPR DPIA, the FRIA can cross-reference the relevant sections of the DPIA or include relevant parts of it, and the AI Office template must allow for this [22].

Article 50: transparency

Article 50 has applied since 2 August 2026 [3][24]. It splits duties between providers and deployers [25]:

• Providers must design systems that interact directly with people so that people are told they are interacting with AI, unless that is obvious (Article 50(1)), and must mark synthetic audio, image, video or text output in a machine-readable, detectable way (Article 50(2)). Providers of generative systems already on the market before 2 August 2026 have until 2 December 2026 to meet Article 50(2) [3].
• Deployers of emotion recognition or biometric categorisation systems must inform the people exposed (Article 50(3)). Deployers of systems that create deepfakes must disclose that the content is artificially generated or manipulated, with lighter rules for evidently artistic or satirical work (Article 50(4)). Deployers that publish AI-generated text to inform the public on matters of public interest must disclose it, unless it has undergone human review or editorial control and someone holds editorial responsibility (Article 50(4)).

For a university, these duties mostly affect communications (synthetic video or voices of real people) and public news text generated without editorial review. A university that puts its own chatbot into service under its own name is the provider of that chatbot, so Article 50(1) applies to it. The Commission has published guidelines on Article 50 and a Code of Practice on transparency of AI-generated content [24].

ChatGPT, Copilot and other general-purpose AI

The AI Act distinguishes a general-purpose AI model (Article 3(63)) from a general-purpose AI system built on such a model (Article 3(66)) [6]. The model obligations in Article 53, such as technical documentation, information for downstream providers, a copyright policy and a public summary of training content, fall on the model provider and have applied since 2 August 2025 [26][3]. The Commission has published guidelines on the scope of these obligations and a voluntary General-Purpose AI Code of Practice that providers can sign to demonstrate compliance [27][28].

A university that licenses a chatbot for staff and students is not a model provider. It is a deployer of an AI system. In practice that means:

• Article 4 applies to staff using the tool. The Commission's Q&A uses ChatGPT for writing and translation as an example of use that requires AI literacy measures [10].
• Article 50 deployer duties apply if staff use it to produce deepfakes or unreviewed public-interest text.
• The high-risk rules can still apply if the tool is used for an Annex III purpose. Article 25(1)(c) is the provision to check if a general system is repurposed for grading or admissions [8].
• GDPR applies throughout. The AI Act does not affect the GDPR (Article 2(7)) [7]. Consumer and institutional plans can differ on training and retention; our fact sheets on ChatGPT, Microsoft Copilot and Gemini set out what each vendor documents.

The research exemption: what it covers

Universities often assume research is outside the AI Act. Two provisions are relevant, and both are narrower than that [7]:

• Article 2(6): the Regulation does not apply to AI systems or models, including their output, "specifically developed and put into service for the sole purpose of scientific research and development".
• Article 2(8): it does not apply to research, testing or development activity regarding AI systems or models before they are placed on the market or put into service. Testing in real-world conditions is not covered by that exclusion.

Recital 25 adds two limits [29]. The exclusion is without prejudice to the obligation to comply once a system resulting from research is placed on the market or put into service. And, apart from systems developed solely for research, "any other AI system that may be used for the conduct of any research and development activity" remains subject to the Regulation. The Commission's prohibited-practices guidelines make the same point [13].

Research with personal data also remains subject to the GDPR and to research ethics review. The practical side of that is covered in our guide to GDPR for researchers using AI and cloud tools.

How the AI Act fits with GDPR and DPIAs

The AI Act sits on top of data protection law, not in place of it. Article 2(7), as amended, says the Regulation does not affect the GDPR, without prejudice to the new Article 4a and Article 59 [7]. Article 4a, added by the Omnibus, allows providers and deployers to process special categories of personal data where strictly necessary to detect and correct bias, under cumulative conditions such as pseudonymisation, strict access controls, no transfer to other parties and deletion once the bias is corrected [30][2].

Under the GDPR, a DPIA is mandatory where processing is likely to result in a high risk, including systematic and extensive evaluation of personal aspects based on automated processing on which decisions with legal or similarly significant effects are based. The EDPB lists criteria such as evaluation or scoring, systematic monitoring, sensitive data, vulnerable data subjects and innovative technology, and says that in most cases two criteria should trigger a DPIA [31]. AI tools used on students or applicants should be screened against each of those criteria.

Validemic's analysis The efficient route is one assessment file per AI use case: start with the DPIA you already need, add the FRIA elements from Article 27(1) where the system is high-risk, and attach the vendor's instructions for use. Our DPIA screening tool helps decide whether a DPIA is needed at all.

Checklist: building a university AI register

The AI Act does not require deployers to keep a register as such, but it is the most practical way to show which systems you deploy, which rules apply and what you have done. It can sit next to your GDPR record of processing activities (see our ROPA template guide).

Fields to record for each AI use

1. System and vendor: product name, version or plan, provider, contract and DPA reference.
2. Owner: the faculty or unit responsible, and a named contact.
3. Actual use: what it is used for, on whom (staff, students, applicants, research participants), and whether output feeds decisions.
4. Role: deployer, or provider (in-house build, own-name deployment, or a change of purpose under Article 25).
5. Prohibition screen: does it infer emotions, categorise by sensitive traits, or score people socially? If emotion inference applies in education or the workplace, stop the use unless the narrow medical or safety exception applies.
6. Annex III screen: does it fall under point 3(a) to (d) or another point? If yes, record whether the provider relies on Article 6(3) and ask for its documented assessment.
7. Transparency: does it interact with people, generate synthetic content, or publish text? Note who discloses what under Article 50.
8. AI literacy: which staff use it and which training or guidance they received, with dates.
9. GDPR: personal data categories, legal basis, DPIA needed or done, transfers outside the EEA, retention. Use the transfer mechanism tool and the DPA checker for the vendor side.
10. High-risk readiness (for Annex III uses before December 2027): instructions for use received; named human overseers and their training; log retention; worker information; registration status if you are a public authority; FRIA drafted; process for Article 86 explanation requests.
11. Review date: at least annually, and whenever the vendor changes the product or its subprocessors.

Priorities for the next 14 months

1. Now: inventory AI uses, including features switched on inside existing platforms. Remove any emotion inference from teaching, exams and staff tools.
2. Now: document your Article 4 measures. Enforcement started in August 2026 [3].
3. Now: check Article 50 disclosures in communications and any own-name chatbots.
4. During 2027: for each Annex III candidate, obtain the provider's classification, instructions for use and conformity plans; set up oversight, logs and FRIA; check registration duties.
5. Procurement: add AI Act questions to vendor assessments now, so contracts signed in 2027 already cover deployer needs. Our vendor assessment guide and proctoring fact sheet show what to ask.

What is still pending

• The Commission's guidelines on high-risk classification are in draft; the consultation closed on 23 July 2026 [17].
• The AI Office template for the FRIA questionnaire (Article 27(5)) [22].
• The AI Board's recommendations on AI literacy (Article 4(3)) and the Commission's practical examples (Article 4(2)) [9].
• Harmonised standards for high-risk systems, which the Commission links to the delayed timeline [1].
• Separately, the broader Digital Omnibus proposal that would amend the GDPR (procedure 2025/0360(COD)) is still at committee stage in Parliament [32]. It does not change the AI Act dates above.

Sources

All sources retrieved 7 October 2026.

1. European Commission, AI Act: regulatory framework for AI (application timeline and AI Omnibus summary).
2. European Commission, AI Omnibus enters into force, 27 July 2026.
3. European Commission AI Act Service Desk, Timeline for the implementation of the EU AI Act.
4. European Parliament Legislative Observatory, Procedure 2025/0359(COD), final act Regulation (EU) 2026/1744, OJ L 24.07.2026.
5. AI Act (as amended), Article 113: Entry into force and application, AI Act Service Desk explorer.
6. AI Act, Article 3: Definitions.
7. AI Act (as amended), Article 2: Scope.
8. AI Act (as amended), Article 25: Responsibilities along the AI value chain.
9. AI Act (as amended), Article 4: AI literacy.
10. European Commission, AI Literacy: Questions & Answers.
11. AI Act (as amended), Article 5: Prohibited AI practices.
12. AI Act Service Desk, FAQ: Digital Omnibus (describes the Commission's proposal).
13. European Commission, Guidelines on prohibited AI practices, C(2025) 5052 final, sections 2.5.3 and 7.
14. AI Act, Annex III: High-risk AI systems referred to in Article 6(2).
15. AI Act, Recital 56.
16. AI Act (as amended), Article 6: Classification rules for high-risk AI systems.
17. AI Act Service Desk, Guidelines on the classification of high-risk AI systems (draft, consultation until 23 July 2026).
18. AI Act Service Desk, Draft guidelines summary: Education and vocational training.
19. AI Act, Article 26: Obligations of deployers of high-risk AI systems.
20. AI Act, Article 49: Registration.
21. AI Act, Article 86: Right to explanation of individual decision-making.
22. AI Act (as amended), Article 27: Fundamental rights impact assessment.
23. AI Act, Recital 96.
24. European Commission, Guidelines on transparency obligations for providers and deployers of certain AI systems.
25. AI Act (as amended), Article 50: Transparency obligations.
26. AI Act, Article 53: Obligations for providers of general-purpose AI models.
27. European Commission, Guidelines on the scope of obligations for providers of general-purpose AI models, 18 July 2025.
28. European Commission, The General-Purpose AI Code of Practice.
29. AI Act, Recital 25.
30. AI Act (new), Article 4a: Processing of special categories of personal data for bias detection and correction.
31. European Data Protection Board, Data protection guide for small business: Be compliant (section on DPIAs).
32. European Parliament Legislative Observatory, Procedure 2025/0360(COD), Digital Omnibus, status: awaiting committee decision.

About this page

Sources checked on 7 October 2026. We read the AI Act and the amendments made by Regulation (EU) 2026/1744 in the European Commission's AI Act Service Desk explorer, because EUR-Lex was only partly available on that date, and confirmed the legislative procedure on the European Parliament's Legislative Observatory. Commission guidelines are non-binding, and the high-risk classification guidelines quoted here are still drafts. This page explains the law for planning purposes and is not legal advice; your institution's legal status (public authority, body governed by public law) depends on national law. If you spot an error or a newer source, please contact us and we will correct it.