CASRAI Dictionary

Tag: ai act text

  • AI Act Regulation: Penalties for Research Bodies

    AI Act regulation penalises non-compliance on a three-tier scale: up to €35 million or 7% of global annual turnover for prohibited AI practices, up to €15 million or 3% for high-risk and general-purpose AI failures, and up to €7.5 million or 1% for supplying false information to regulators — whichever figure is higher in each case. For a university, spinout, or research consortium, the exposure is rarely the maximum headline number; it is the cost of misclassifying an admissions algorithm, an exam-proctoring tool, or a recruitment screen as “low risk” when the law says otherwise.

    The EU Artificial Intelligence Act (Regulation (EU) 2024/1689) is the harmonised EU law setting risk-based obligations and penalties for AI systems, and it applies to research institutions as deployers whenever an AI system’s output affects people in the EU.

    What actually counts as an AI Act violation for a research institution?

    Universities and consortia rarely build the AI systems they use — they deploy them. Under the Act, a deployer is any organisation using an AI system in a professional capacity, and deployers carry real obligations even when a vendor built the underlying model. A learning-management platform that scores exam integrity, an HR tool that ranks job applicants, or an admissions filter all fall within scope if they touch people inside the EU, regardless of where the institution is based.

    Non-compliance is not a single offence. It spans failing to conduct a fundamental rights impact assessment, deploying an unregistered high-risk system, ignoring human-oversight requirements, or running a system the Act classifies as prohibited. Each failure mode sits on a different penalty tier.

    How much can an AI Act fine cost, tier by tier?

    Article 99 of Regulation (EU) 2024/1689 sets three fine bands. The final figure is whichever is higher — the flat euro cap or the percentage of worldwide annual turnover — which matters enormously for a university with a large total budget but a tiny AI-specific footprint.

    Violation type Maximum fine Turnover percentage Typical trigger for a research institution
    Prohibited AI practices (Art. 5) €35,000,000 7% Emotion-recognition in exams; covert biometric categorisation of students or staff
    High-risk system / GPAI obligation breaches €15,000,000 3% Recruitment or admissions AI deployed without a rights impact assessment
    Supplying incorrect, incomplete or misleading information €7,500,000 1% Inaccurate disclosures to a market surveillance authority or notified body

    Regulators must apply fines proportionately, weighing the nature, gravity and duration of the breach against the size of the organisation. Article 99(6) directs authorities to consider the interests of small and medium-sized enterprises and start-ups — relevant for university spinouts on constrained budgets — but this softens the number, not the underlying obligation.

    • Fines apply per infringement, so a consortium running several non-compliant systems faces cumulative, not capped, exposure.
    • Turnover is calculated on the whole legal entity’s global turnover, not just the department’s AI-related revenue or grant income.
    • National market surveillance authorities, not the EU AI Office, issue most fines against deployers; the AI Office focuses on general-purpose AI providers.

    Which of your institution’s AI systems could be “prohibited” outright?

    Article 5 bans a specific list of practices regardless of sector, and several map directly onto tools already used in higher education and research settings. A prohibited AI practice cannot be risk-managed into compliance — it must be withdrawn.

    The clearest overlaps for a research institution are:

    • Emotion recognition in educational institutions or workplaces, except for narrow medical or safety purposes — implicating some exam-proctoring and staff-monitoring software.
    • Biometric categorisation systems inferring race, political opinion, trade union membership, religion, or sexual orientation from biometric data.
    • Untargeted scraping of facial images from the internet or CCTV to build a recognition database — relevant to campus security systems built on scraped datasets.
    • Social-scoring-style evaluation of individuals by behaviour or personal traits leading to detrimental treatment unrelated to the original context.

    From 2 December 2026, two further prohibited categories take effect under the Digital Omnibus agreement: AI systems that generate or manipulate non-consensual intimate imagery (“nudifier” applications) and systems used to produce child sexual abuse material. Institutions running student-safeguarding or content-moderation tooling should confirm vendor compliance well ahead of that date.

    Has the Digital Omnibus changed the deadlines that matter?

    Yes, but selectively. The Act’s obligations phase in from its 1 August 2024 entry into force: prohibited practices became enforceable on 2 February 2025 (six months later), and general-purpose AI model obligations followed on 2 August 2025 (twelve months later). Both dates already passed and remain in force.

    In November 2025, the Council and Parliament agreed a “Digital Omnibus” simplification package — analysed by law firms including DLA Piper, Gibson Dunn and White & Case — pushing back the two remaining high-risk deadlines. Stand-alone high-risk systems under Annex III (covering most education, employment and public-service AI) now face obligations from 2 December 2027 rather than August 2026, a sixteen-month reprieve. High-risk AI embedded in regulated products under Annex I moves to 2 August 2028.

    Two dates were not delayed: Article 50 transparency obligations — labelling AI-generated content and disclosing chatbot interactions — still apply from 2 August 2026, the same date the Commission gains full penalty-enforcement powers over general-purpose AI providers. Institutions assuming the whole Act slipped to 2027 risk missing this transparency deadline.

    What should a research institution do now?

    The Digital Omnibus buys time on high-risk classification work, not on everything. A defensible position by August 2026 requires:

    • Inventory every AI system touching students, staff, applicants, or research subjects, tagged against the Article 5 prohibited list and Annex III high-risk categories.
    • Confirm any generative AI or chatbot-facing tool meets the Article 50 transparency requirement before 2 August 2026, independent of the high-risk delay.
    • Assign a named owner — typically in research administration or data governance — to track phased deadlines rather than treat the Act as one compliance date.
    • Apply vendor due diligence to procured AI tools, since deployer obligations do not disappear because a third party built the system.

    Answer-first: common questions on AI Act penalties

    Is the AI Act a regulation?

    Yes. The Artificial Intelligence Act is Regulation (EU) 2024/1689, meaning it applies directly and uniformly across all EU member states without needing national transposing legislation. It entered into force on 1 August 2024, and its obligations phase in over a multi-year timeline extending to 2028.

    What is the EU AI Act in 2026?

    By mid-2026, the prohibited-practice and general-purpose AI rules are already fully enforceable, while most high-risk system obligations have been pushed to December 2027 and August 2028 under the November 2025 Digital Omnibus agreement. Article 50 transparency duties and full GPAI enforcement powers still take effect on 2 August 2026 as originally scheduled.

    Does the UK have to comply with the EU AI Act?

    The UK has no domestic equivalent to the AI Act, but the regulation’s extraterritorial scope reaches UK institutions whenever their AI system’s output is used by, or affects, people in the EU. A UK university running an EU-facing admissions or research-collaboration platform can fall within scope despite being outside the bloc.

    Does the UK have any AI regulation of its own?

    Not a single statute. The UK relies on a sector-by-sector, principles-based approach enforced by existing regulators (ICO, EHRC, Ofcom) rather than one AI Act. This is why UK institutions with EU-facing systems must track both the domestic guidance and the EU regulation’s extraterritorial reach separately.

    What this means for institutional risk management

    The headline €35 million figure will rarely apply to a university outright, but the reputational cost of a prohibited-practice finding is not confined to the fine itself. A finding against emotion-recognition exam software invites scrutiny of every other AI-enabled assessment tool on campus, and funders increasingly expect institutions to demonstrate AI governance maturity, mirroring assurance expectations already familiar from research administration compliance frameworks.

    Treating AI Act regulation as a procurement and governance discipline — inventory, classification, named ownership, phased deadline tracking — converts an open-ended legal risk into a manageable operational programme.

    Where this is heading

    The Digital Omnibus shows the EU will adjust timelines under pressure, but it has not softened the penalty structure, and it has added prohibited categories rather than removed any. Research institutions should expect further phased deadlines and continued extraterritorial reach, and should treat every delay as a planning window, not a reason to deprioritise compliance work.

  • Foundation Model vs General-Purpose AI Systems Under the EU AI Act

    A foundation model is a large-scale AI model trained on broad data that can be adapted to many downstream tasks; a general-purpose AI system is the deployed product built on top of it. The foundation model vs general-purpose AI distinction is not academic under EU Regulation 2024/1689 (the AI Act): “general-purpose AI model” obligations attach to the model itself under Chapter V, while “AI system” obligations attach to a deployed application under Title III and depend entirely on how that application is used. For a university lab that fine-tunes an open-weight model into a research tool and releases it publicly, which category applies — and when — determines a materially different compliance workload.

    The AI Act defines a general-purpose AI model (Article 3(63)) as one that “displays significant generality” and can “competently perform a wide range of distinct tasks”, regardless of how it is placed on the market. A general-purpose AI system (Article 3(66)) is an AI system based on such a model that can serve a variety of purposes, whether used directly or integrated into other systems. The two terms are frequently conflated, but the Act’s compliance architecture depends on keeping them separate.

    What is a foundation model? A working definition

    A foundation model is an AI model trained on large, broad datasets — often using self-supervised learning — that generalises to a wide range of downstream tasks rather than being built for one narrow purpose. Large language models are the most cited example, but the concept also covers text-to-image, text-to-video, and multimodal models.

    The term originated in AI research (Stanford’s Center for Research on Foundation Models coined it in 2021) and is not itself a defined legal term in the AI Act. The Act’s operative category, general-purpose AI model, captures the same phenomenon in enforceable language, and in practice most models researchers call “foundation models” meet that legal definition.

    AI Act definitions: general-purpose AI model vs AI system

    The AI Act runs two separate regulatory tracks that a research team must understand independently, because passing one does not exempt a project from the other.

    The general-purpose AI model track (Chapter V, Articles 51–56) regulates the model layer. Under Article 53(1), providers must draw up technical documentation, inform downstream integrators, publish a training-content summary, and maintain a copyright policy. The Commission’s AI Office guidance is explicit that these “provisions… apply to the model itself, regardless of what is or will be its ultimate use.” Models trained with over 1025 FLOP are presumed to pose systemic risk under Article 51(1)(a), triggering evaluation and incident-reporting duties under Article 55.

    The AI system track (Title III, Articles 6–49) regulates the application layer. Obligations here — including the high-risk conformity-assessment regime under Annex III — depend entirely on context of use: what the system does, who it affects, and which domain it operates in. A system built on a fully documented foundation model can still be high-risk; one built on an under-documented model can still sit outside Title III if its use case is low-risk.

    Crucially, Article 2(8) excludes “any research, testing or development activity regarding AI systems or AI models prior to their being placed on the market or put into service” from the Act’s scope. This is the single most important provision for university labs: internal experimentation is largely unregulated, but that exemption ends the moment a tool is placed on the market — including released publicly under an open licence.

    When does fine-tuning create a new “provider”?

    Recital 97 clarifies that a model is still “placed on the market” if its provider integrates it into their own AI system, unless use is purely internal, third parties’ rights are unaffected, and the model carries no systemic risk. The Commission’s guidelines on scope (Section 3.2) add an indicative criterion: a downstream entity that fine-tunes an existing model becomes provider of a new general-purpose AI model once the modification’s training compute exceeds one-third of the original model’s training compute. Below that threshold, the original provider keeps Article 53 responsibility, and the lab’s own duties attach mainly at the system layer.

    Why the distinction matters for research software

    University labs increasingly build research tools — literature-screening assistants, peer-review triage systems, integrity checkers, grant-matching recommenders — on foundation models. Getting the model/system distinction wrong creates two risks: over-compliance (treating a low-risk tool as needing Annex III conformity assessment) or under-compliance (releasing a public tool without required Article 53 documentation).

    Two provisions reduce the burden for academic and open-source releases. First, Article 53(2) exempts providers from the Article 53(1)(a) and (b) documentation duties if the model is released open-source with public weights, architecture, and usage information — though this never extends to systemic-risk models. Second, Recital 109 requires that provider obligations “take due account of the size of the provider,” with simplified routes for SMEs and start-ups, a category many university spin-outs fall into.

    Neither exemption touches the AI system track. A tool that screens grant applicants or assesses researcher performance may still fall under Annex III’s high-risk categories regardless of how the underlying model is licensed.

    Worked examples for university labs

    The scenarios below show how the two tracks diverge depending on what is built and how it is released.

    Scenario General-purpose AI model duties AI system duties
    Fine-tunes an open-weight model for internal literature screening only, never released Not applicable — Article 2(8) research exemption while internal Not applicable — no placing on the market
    Releases the fine-tuned model publicly, open licence, weights published; fine-tuning compute under one-third of base compute Base-model provider keeps Article 53 duties; lab is not a new provider (one-third-compute criterion) Must assess use case under Title III; low-risk screening unlikely to trigger Annex III
    Substantially retrains a model (compute over one-third of base) and releases it as a research-assessment tool used in hiring-adjacent decisions Lab becomes provider of a new general-purpose AI model; full Article 53 duties apply Likely high-risk under Annex III (employment use); conformity assessment and human oversight required from 2 August 2026

    Frequently asked questions

    Are foundation models general purpose?

    Most, but not all. A model must display significant generality and competently perform a wide range of distinct tasks to meet the AI Act’s Article 3(63) definition; models fine-tuned to be narrowly specialised for one domain can fall outside it even if built on a general-purpose base.

    Is a chatbot built on a foundation model itself a foundation model?

    No. A chatbot is a deployed AI system; the language model behind it is the general-purpose AI model. The chatbot’s obligations run through Title III based on use case, while the model’s obligations run through Chapter V regardless of that use case.

    What is the difference between a foundation model and an AI agent?

    A foundation model is the underlying trained model; an AI agent is a system that uses one or more models to pursue goals with some autonomy, such as planning or calling tools. Under the AI Act, an agent built on a foundation model is assessed as an AI system, with obligations set by context of use, not by which model powers it.

    Compliance implications and what comes next

    For research offices evaluating an AI-powered tool before release, four checks separate compliant projects from exposed ones:

    • Confirm whether the tool is still covered by the Article 2(8) research exemption, or whether release plans amount to “placing on the market.”
    • Calculate whether fine-tuning compute crosses the one-third-of-original-compute threshold that can make the lab a new model provider.
    • Check the Article 53(2) open-source exemption conditions — weights, architecture, and usage information must all be public.
    • Assess the deployed system separately against Title III and Annex III; model-layer compliance never substitutes for system-layer risk classification.

    The compliance calendar is tightening. Prohibited AI practice rules have applied since 2 February 2025, general-purpose AI model obligations since 2 August 2025, and high-risk AI system obligations under Annex III take effect from 2 August 2026 — weeks away for any lab planning to release research software touching employment, education, or other Annex III domains. Labs that map tools against both tracks before release, not after, avoid finding out the hard way through a market-surveillance enquiry. Institutional research administration offices are increasingly the first checkpoint for that mapping.

  • General-Purpose AI Model Rules for Universities

    A general-purpose AI model is defined in Article 3(63) of the EU AI Act as an AI model that displays significant generality, can competently perform a wide range of distinct tasks, and can be integrated into varied downstream systems, regardless of how it is placed on the market. A university prototype never placed on the market or put into service falls outside these duties under the Article 2(8) research exemption; the moment that model, or a fine-tuned derivative, is published or supplied to a third party, Article 53 obligations on technical documentation, downstream information, copyright policy, and a training-content summary can attach.

    A general purpose ai model is not defined by branding — it is defined by a compute-and-capability test in the Act’s recitals and the Commission’s guidelines. That test matters for universities, because the same model can sit inside the research exemption one day and carry a regulated “provider” obligation the next, depending on what happens to it.

    What is a general-purpose AI model under the AI Act?

    Under Article 3(63) of the AI Act, a general-purpose AI model is one that “displays significant generality and is capable of competently performing a wide range of distinct tasks… and that can be integrated into a variety of downstream systems or applications.” Recital 98 anchors this operationally: models trained with at least a billion parameters using large-scale self-supervision are presumed to meet the generality bar.

    The Commission’s guidelines on the scope of GPAI obligations add a practical marker: an indicative threshold of 10^23 FLOP of training compute, combined with the ability to generate language, images, or video, points to GPAI status. A narrow classifier trained on one labelled dataset for one task — say, detecting a specific cell morphology in a pathology dataset — meets neither bar and is not a GPAI model; it is a narrow AI system governed, if at all, by the Act’s risk-based system rules in Chapters II–IV, not the model-layer rules in Chapter V.

    Foundation model vs general-purpose AI vs narrow research tool: the definitional test

    “Foundation model” is not a term the AI Act defines — it originates from the 2021 Stanford Center for Research on Foundation Models literature. What most people call a foundation model is simply a species of general-purpose AI model; the Act creates no separate legal category for it and regulates instead at the model layer (Chapter V) and the system layer (Chapters II–IV).

    A narrow research tool is not a defined legal term either. It survives through Article 2(8), which states the AI Act “does not apply to any research, testing or development activity regarding AI systems or AI models prior to their being placed on the market or put into service.” The three-way distinction that matters for universities is:

    Category Legal basis Obligation trigger
    General-purpose AI model Article 3(63), Recital 98 Placed on the market or put into service (any use case, any modality)
    “Foundation model” (industry term) No AI Act definition — a subset of GPAI in practice Same as GPAI: placement on the market
    Narrow research tool Article 2(8) exemption Never triggered while confined to pre-market research, testing or development

    The trigger is not architecture, size, or pedigree — it is whether the model has been placed on the market, defined in Article 3(9) as first supply for distribution or use in the Union, paid or free. A lab training a model for internal experiments stays inside Article 2(8); publishing its weights publicly, or licensing it to a partner, places it on the market and can trigger Article 53.

    What are the Article 53 obligations for GPAI providers?

    Article 53(1) of the AI Act sets four core obligations for any provider of a general-purpose AI model placed on the EU market, regardless of size or academic status:

    • Technical documentation (Article 53(1)(a)) — training/testing processes and evaluation results, available on request to the AI Office and national authorities.
    • Information for downstream providers (Article 53(1)(b)) — capabilities, limitations, and foreseeable misuse, so downstream builders can meet their own duties.
    • A copyright policy (Article 53(1)(c)) — how the provider complies with EU copyright law and respects rights reservations in training data.
    • A public training-content summary (Article 53(1)(d)) — using the Commission’s template, describing what content trained the model.

    These obligations have applied since 2 August 2025 under Article 113(b), with transitional rules for pre-existing models under Article 111(3). A heavier tier applies only to GPAI models posing systemic risk — an indicative 10^25 FLOP training-compute threshold under Article 51(1)(a)-(2), costing tens of millions of euros to reach per the Commission — triggering adversarial evaluation, risk mitigation, incident reporting, and cybersecurity duties under Article 55. Almost no university-trained model approaches 10^25 FLOP, so this tier rarely applies academically; base Article 53 duties can still apply well below it.

    How does the research exemption apply to universities that fine-tune models?

    Universities interact with the GPAI rules from two directions, and conflating them is the single most common compliance error. First, a university training its own large model purely for internal research stays inside Article 2(8) for as long as the model is neither placed on the market nor put into service — a threshold not crossed the moment a paper is published, but more likely triggered by supplying the model for use or distribution.

    Second, and less understood, is what happens when a university fine-tunes an existing GPAI model from a commercial lab. Recital 109 and the Commission’s guidelines indicate fine-tuning can make the modifier a “provider” of a new model — but only for the modification, not the underlying base model. The indicative criterion: if fine-tuning compute exceeds roughly one-third of the original model’s training compute, the university takes on provider obligations for that modification, typically discharged by supplementing existing documentation with what changed.

    Two further carve-outs matter for university open-model releases:

    • The open-source exemption (Article 53(2)) removes the documentation and downstream-information duties (53(1)(a)-(b)) for models released free and open-source with public parameters, weights, architecture and usage information — not the copyright-policy or training-summary duties, and never for a systemic-risk model.
    • Downstream system duties are separate. A university embedding a GPAI model in a chatbot, decision-support tool, or admissions-screening application must separately assess that system against the Act’s risk-based rules in Chapters II–IV, whether or not it is also a GPAI “provider.”

    Answer-first Q&A

    Is general purpose AI the same as generative AI?

    No. Generative AI describes output type — models producing text, images, audio or video — while general-purpose AI is a legal classification under Article 3(63) based on generality and integration potential. Most large generative models qualify as GPAI, per Recital 99, but the two terms describe different properties and are not interchangeable in the regulation.

    What is an example of general-purpose AI?

    Large language and multimodal models generating text, images, or code across many tasks — commonly called foundation models — are the Act’s typical example under Recital 99. A university-trained model only qualifies once it meets Recital 98’s generality and compute markers, not merely because it shares similar architecture.

    Is ChatGPT general-purpose AI?

    Yes. Widely used commercial assistants built on large generative models meet the Article 3(63) generality test and are treated as general-purpose AI models, subject to Article 53 obligations from their provider. This differs from a university’s narrow, single-task research classifier, which would not meet the same test.

    Implications for universities releasing open models

    The practical stakes are documentation discipline, not automatic prohibition. A university planning to publish a fine-tuned or original model should map, before release, whether Article 2(8) still applies, whether the one-third fine-tuning threshold has been crossed, and whether Article 53(2)’s open-source exemption covers the intended licence. Institutions publishing under permissive open licences with full weights and architecture disclosure can shed the heaviest documentation duties while still owing a copyright policy and training-content summary — obligations echoing the transparency practices research administrators already apply to funder mandates such as UKRI’s and Horizon Europe’s.

    As the AI Office refines its guidelines and the General-Purpose AI Code of Practice — assessed as adequate by the Commission and AI Board in 2025 — becomes the default route to demonstrating compliance, universities treating model-release governance as a standing institutional process, not a one-off legal review, will be best placed to keep publishing openly without falling foul of Article 53.

  • EU AI Act Compliance: University AI Checklist

    EU AI Act compliance obligations activate the moment a university’s AI system moves from a research prototype into real-world use. An admissions screening tool, a plagiarism detector, or a student-facing chatbot that starts operating on live applicant or student data falls outside the Article 2(6) research exemption and must meet the Regulation’s governance, documentation and human-oversight requirements for high-risk systems.

    The EU AI Act — Regulation (EU) 2024/1689 — is the European Union’s binding, risk-based framework that classifies artificial intelligence systems by risk level and imposes proportionate obligations on providers and deployers, including universities that operate AI tools within the EU or whose outputs affect EU users.

    What the Article 2(6) Research Exemption Actually Covers

    Article 2(6) excludes AI systems and AI models “specifically developed and put into service for the sole purpose of scientific research and development” from the Regulation’s scope. The exemption is narrow by design: it protects genuine R&D activity, not any AI project that happens to originate in a university lab.

    Most institutional coverage of the AI Act stops here, treating the research exemption as a blanket shield for higher education. It is not. The exemption tracks purpose, not origin: a model stays exempt only while its sole function is research — the instant it is repurposed to inform an operational decision, the exemption lapses for that use.

    This matters because universities routinely graduate tools from prototype to production: a thesis project becomes an admissions triage assistant, a plagiarism-detection experiment becomes the software every faculty uses to screen coursework. Each transition is a legal event under the AI Act, not just a technical rollout.

    Which University AI Systems Lose Exemption on Deployment

    Annex III of the AI Act designates four categories of education-sector AI as high-risk once deployed operationally: systems used to determine admission or assignment to an institution, to evaluate learning outcomes, to assess the appropriate level of education an individual should receive, and to monitor or detect prohibited student behaviour during tests — the Annex III wording that squarely covers exam-integrity and plagiarism-detection tools.

    A separate, already-enforceable rule applies to emotion-detection features sometimes bundled into exam-proctoring software: Article 5(1)(f) has banned emotion-recognition systems in educational institutions since 2 February 2025, with narrow exceptions for medical or safety purposes. A proctoring tool that infers stress or attentiveness from webcam data is not merely high-risk — it may be prohibited outright.

    Student-facing chatbots sit differently on the risk scale. A general enquiries chatbot typically falls under the lighter Article 50 transparency regime — it must disclose that users are interacting with AI — unless its outputs feed directly into an Annex III decision such as admissions ranking, in which case the high-risk obligations apply to that decision pathway.

    Deployment stage Example AI Act status University’s primary duty
    Lab prototype Model trained on institutional data, never used operationally Exempt — Article 2(6) Monitor for change of purpose
    Pilot with real users Admissions-triage assistant tested on live applicant files Conditionally exempt via regulatory sandbox Informed consent; sandbox registration (Article 57)
    Live admissions tool AI ranks or screens applicants operationally High-risk — Annex III(3)(a) Full Articles 9–15 obligations; FRIA (Article 27)
    Live exam-integrity monitor AI flags prohibited behaviour during tests High-risk — Annex III(3)(d) As above, plus an Article 5(1)(f) emotion-recognition check
    Public-facing chatbot Answers prospective-student enquiries Limited risk — Article 50 AI-interaction disclosure only

    The Governance and Documentation Checklist

    Once a system loses exemption, the deployer obligations that apply are the same ones any commercial organisation faces — but universities carry one duty that most private-sector guidance omits. Under Article 27, deployers that are bodies governed by public law must complete a Fundamental Rights Impact Assessment before putting a high-risk system into use. Most EU public universities meet that definition, which makes the FRIA a default step, not an optional extra.

    1. Inventory and classify every AI system reaching operational use, including vendor and embedded tools — not only in-house builds.
    2. Re-test Article 2(6) applicability at every go-live decision; log the classification rationale.
    3. Complete a Fundamental Rights Impact Assessment (Article 27) before deployment, particularly where the institution is a public-law body.
    4. Screen for Article 5 prohibited practices, including emotion recognition in educational settings.
    5. Establish human oversight checkpoints under Article 14: named staff, defined intervention points, escalation routes.
    6. Centralise technical documentation, instructions for use and event logging under Articles 11–13.
    7. Verify the vendor’s conformity assessment where a third-party tool is used — compliance cannot be outsourced to the supplier.
    8. Register the system in the EU high-risk database (Article 71) once the applicable Annex III deadline is reached.

    The compliance timeline has moved since most explainer content was written. Article 5 prohibitions and AI-literacy obligations have applied since 2 February 2025. General-purpose AI model obligations under Articles 51–55 have applied since 2 August 2025. Article 50 transparency duties take effect on 2 August 2026. Following the AI Act Omnibus political agreement of 7 May 2026, the Annex III high-risk deadline for use-based systems — including the education-sector list above — has been deferred to 2 December 2027, pending formal adoption and publication in the Official Journal.

    The deferral changes the runway, not the workload. Institutions that wait for the 2027 deadline to start classification and documentation work will find the FRIA and human-oversight design take longer to build than the calendar suggests.

    Compliance-Checker Tools and Regulatory Sandboxes

    The European Commission operates an official EU AI Act Compliance Checker through its AI Act Service Desk, which helps providers and deployers work out which obligations apply to a given system. It is a useful first-pass triage tool, but it does not substitute for a documented FRIA — it tells an institution which article applies, not how to evidence compliance with it.

    For institutions building a repeatable governance structure rather than a one-off assessment, ISO/IEC 42001 — the international standard for AI management systems — maps closely to the AI Act’s risk-management, data-governance and documentation articles, and offers a certifiable framework that research offices can run alongside existing research-integrity governance.

    Universities piloting a system before full operational rollout have a formal route available: Article 57 requires each Member State to establish at least one AI regulatory sandbox, giving providers — including public research institutions — a supervised environment to test systems with real users under national-authority oversight before the full high-risk regime applies.

    This governance shift sits alongside a broader move across research administration, where institutions are building the same kind of structured accountability for AI tools that they have long applied to research-integrity and data-management obligations.

    Common Questions on EU AI Act Compliance for Universities

    Does the EU AI Act research exemption cover university AI tools after deployment?

    No. The Article 2(6) exemption applies only while a system is developed and used solely for scientific research. Once a university deploys the same tool operationally — for admissions, plagiarism detection or another administrative decision — the exemption ends and high-risk or transparency obligations apply.

    Which university AI systems count as high-risk under the EU AI Act?

    Annex III lists four education categories: systems deciding admission or assignment, evaluating learning outcomes, assessing appropriate education level, and monitoring prohibited behaviour during tests. Admissions-screening tools and exam-integrity or plagiarism-detection systems fall squarely within this list once operational.

    What is a Fundamental Rights Impact Assessment and does it apply to universities?

    A Fundamental Rights Impact Assessment (Article 27) evaluates a high-risk AI system’s effect on individuals’ rights before deployment. It is mandatory for deployers that are bodies governed by public law — a category that covers most public universities in the EU deploying Annex III systems.

    When do EU AI Act high-risk obligations for education systems take effect?

    Following the Omnibus political agreement of 7 May 2026, Annex III high-risk obligations — including the education-sector list — are deferred to 2 December 2027, pending formal adoption. Article 5 prohibitions and GPAI obligations are already enforceable now.

    For research administrators, the practical implication is sequencing: build the AI inventory, classification log and human-oversight design now, while the Annex III deadline still allows time for a proper Fundamental Rights Impact Assessment rather than a rushed one. Waiting for the deadline to arrive before starting is the most common way institutions turn a manageable governance project into a last-minute compliance emergency.