CASRAI Dictionary

Tag: ai act regulation

  • 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.

  • AI Act Annex III Education Systems Explained

    Annex III of the EU AI Act (Regulation (EU) 2024/1689) classifies four specific education uses as high-risk: admissions and access decisions, evaluation of learning outcomes, assessment of the appropriate level of education for an individual, and monitoring students for prohibited behaviour during tests. That fourth category covers most commercial exam-proctoring software. Because these systems influence a person’s access to education, providers and institutions face conformity-assessment, documentation and human-oversight duties — and, as of mid-2026, a revised compliance timeline that most procurement guidance has not yet caught up with.

    Annex III is the section of the AI Act that lists the stand-alone use cases treated as high-risk regardless of sector, and education is one of eight listed domains. Under Article 6(2), any system matching an Annex III description is high-risk unless it falls within a narrow set of Article 6(3) exemptions for purely preparatory or narrow procedural tasks.

    What Annex III Actually Classifies as High-Risk in Education

    Annex III, point 3, lists four education and vocational-training use cases. Each is high-risk in its own right, not as a bundled “education AI” category:

    Annex III, point 3 What it covers Typical real-world system
    3(a) Access and admission Determining access, admission, or assignment of people to educational and vocational institutions at any level Admissions-ranking algorithms; automated place-allocation tools
    3(b) Evaluating learning outcomes Assessing outcomes, including where results steer a person’s subsequent learning path Automated essay and short-answer scoring; adaptive-learning placement engines
    3(c) Assessing appropriate education level Determining the level of education a person will receive or can access Streaming and tracking tools; aptitude-based course-eligibility systems
    3(d) Monitoring prohibited behaviour Detecting prohibited conduct by students during tests Remote exam-proctoring software with anomaly or gaze detection

    This structure matters for procurement: a vendor’s product might satisfy only one limb (proctoring under 3(d)) while a different module of the same platform — an automated grading feature, say — separately triggers 3(b). Each function needs its own classification check rather than a single institution-wide judgement.

    Why Proctoring and Admissions AI Meet the High-Risk Threshold

    The AI Act treats education systems as high-risk because their outputs shape a person’s access to opportunity, not because the underlying technology is novel. Recital 56 explains that AI in education can determine “the educational and professional course of a person’s life” and, where biased or opaque, can perpetuate discrimination on grounds such as disability, ethnic origin or sexual orientation.

    Two features push a system firmly into the high-risk tier. First, if the tool performs profiling of natural persons — building a behavioural or performance profile used in a decision — Article 6(3) removes the narrow-task exemptions entirely, so the system is automatically high-risk. Most commercial proctoring tools that flag “suspicious behaviour” patterns over time perform exactly this kind of profiling. Second, where a system’s error directly changes an admission, grading or progression outcome, it cannot credibly claim the “preparatory task only” or “improves a human decision” carve-outs in Article 6(3), because the human reviewer rarely has the practical capacity to re-examine every flagged case in full.

    Conformity-Assessment Duties That Follow

    Classification as high-risk is the trigger, not the end point. Providers placing an Annex III education system on the market must run it through conformity assessment under Article 43 before deployment, and both providers and deploying institutions then carry ongoing obligations:

    • Establish and maintain a risk-management system across the tool’s lifecycle
    • Use training, validation and test data that is relevant, representative and checked for bias
    • Produce technical documentation demonstrating compliance, and enable automatic logging for traceability
    • Complete a declaration of conformity, affix the CE marking, and register the system in the EU high-risk AI database under Article 49
    • Deployers must run a fundamental rights impact assessment before first use, keep human oversight with real override authority, and tell students and applicants that a high-risk system is involved

    None of these duties can be delegated to the software vendor by contract alone. An institution that deploys a high-risk admissions tool is a deployer under the Act and carries deployer-specific obligations even where the vendor, as provider, has already completed its own conformity assessment.

    The compliance timeline itself has shifted since most existing guidance was written. Article 113 originally set 2 August 2026 as the date the Annex III obligations became applicable. On 7 May 2026, the European Parliament and the Council reached a provisional political agreement on the Digital Omnibus on AI, replacing that date with fixed extensions: 2 December 2027 for stand-alone Annex III systems (including education), and 2 August 2028 for Annex I product-embedded systems. Separately, the marking obligations under Article 50(2) now fall due on 2 December 2026. Until the agreed text is formally adopted and published in the Official Journal, the original 2 August 2026 date remains the legally binding one — institutions should treat the extension as highly likely, not yet certain.

    Obligation Original deadline Revised deadline (Digital Omnibus, agreed 7 May 2026)
    Annex III stand-alone high-risk systems (education, employment, essential services) 2 August 2026 2 December 2027
    Annex I product-embedded high-risk systems 2 August 2027 2 August 2028
    Article 50(2) transparency/marking obligations 2 August 2026 2 December 2026

    What This Means for Procurement of Proctoring and Admissions AI

    For institutions and publishers buying exam-proctoring, admissions-ranking or automated-scoring tools, the practical question is no longer “is this AI regulated eventually” but “which Annex III limb applies, and can the vendor prove it.” A procurement checklist built around Annex III should require vendors to confirm, in writing, before contract renewal:

    • Whether each distinct feature of the product (scoring, proctoring, ranking) falls under Annex III, point 3(a)-(d), and if so, which limb
    • Evidence of a completed or in-progress conformity assessment and EU database registration, or a documented Article 6(3) exemption assessment
    • What training data was used, and what bias-testing was performed against protected characteristics
    • What logging and traceability the institution will have access to for its own record-keeping duties as deployer
    • Whether the tool performs any form of profiling, since this removes access to the narrow-task exemptions

    Institutions with any EU touchpoint — joint degrees, EU-based applicants, satellite campuses — should apply the same checklist even where their primary jurisdiction sits outside the EU, because the Act’s extraterritorial scope catches systems whose output is used within the EU.

    Common Questions on Annex III Education Systems

    What Is Considered a High-Risk AI System Under the AI Act?

    An AI system is high-risk if it is a safety component of a product covered by Annex I legislation, or if its use case appears in Annex III — covering biometrics, education, employment, essential services, law enforcement, migration and justice — unless it genuinely poses no significant risk under the narrow Article 6(3) exemptions.

    Which Education Apps Are High-Risk Under the AI Act?

    Annex III, point 3 names four categories: admissions and access tools, learning-outcome evaluation systems, tools assessing a person’s appropriate education level, and software monitoring students for prohibited behaviour in tests. Automated essay scoring and exam proctoring fall squarely within these limbs.

    Can an Exam Proctor Be AI?

    Yes — many institutions already use AI-based remote proctoring that analyses movement, gaze and audio to flag suspected cheating. Under the AI Act, this function sits within Annex III, point 3(d), making the software high-risk and subject to conformity-assessment and human-oversight duties, not a substitute human decision-maker.

    Are Any Education AI Practices Banned Outright, Not Just High-Risk?

    Yes. Since 2 February 2025, Article 5 has banned emotion-recognition systems in educational settings outright, with no research or institutional exemption, except narrow medical or safety uses. This sits above the high-risk tier — a banned practice cannot be brought into compliance through conformity assessment.

    The classification logic behind Annex III will not soften even as its application date moves. Institutions and publishers procuring proctoring, admissions or scoring AI gain a longer runway to 2 December 2027, but the underlying duties — bias-tested data, documented conformity assessment, human override authority, and registration in the EU database — remain the fixed reference point for any system that touches a student’s access to education.

  • AI Act Researcher Access to High-Risk Systems

    Article 92 of the EU AI Act does not create a DSA-style “vetted researcher” scheme for high-risk AI systems. It gives the European Commission’s AI Office — supported by Commission-appointed independent experts — power to demand evaluation access, including source code, to general-purpose AI models with systemic risk. Outside academics cannot yet apply for access under Article 92 itself.

    Article 92 is the provision of Regulation (EU) 2024/1689 that lets the AI Office conduct compliance and systemic-risk evaluations of general-purpose AI (GPAI) models, requesting access “through APIs or further appropriate technical means and tools, including source code” from the model’s provider. It becomes applicable on 2 August 2026, under the Article 113 staggered-application timetable.

    What Article 92 actually grants

    Article 92(1) gives the AI Office, after consulting the AI Board, the power to evaluate a general-purpose AI model in two circumstances: where information already gathered under Article 91 is insufficient to assess a provider’s compliance, or to investigate systemic risks following a qualified alert from the scientific panel under Article 90.

    Under Article 92(3), the Commission may request access to the model “through APIs or further appropriate technical means and tools, including source code.” Article 92(4) requires each request to state its legal basis, purpose, and the fine under Article 101 that applies if the provider refuses. This is a regulator-to-provider compliance channel, not an open door for the research community.

    Who can request access — and who cannot

    The Commission may itself request access, or it may appoint independent experts to carry out the evaluation on its behalf, drawn in particular from the scientific panel established under Article 68. Those experts must meet the Article 68(2) criteria before they can touch any model.

    • Particular expertise and competence in AI, demonstrated through up-to-date scientific or technical knowledge.
    • Independence from any provider of AI systems or general-purpose AI models.
    • A demonstrated ability to carry out evaluation activities diligently, accurately, and objectively.

    There is no equivalent of the DSA’s open application route. A university researcher cannot submit a “duly substantiated application” to a national authority and be awarded status; the Commission selects panel members, and the AI Office decides when to deploy them. Article 68(4) further binds experts to confidentiality and impartiality, and requires each to file a public declaration of interests.

    What data, logs, and systems are in scope

    Article 92 targets general-purpose AI models — not the full universe of “high-risk AI systems” listed under Annex III (recruitment tools, credit-scoring systems, education-admission systems, and the like). The provision is narrower and sits in Chapter V’s enforcement toolkit for GPAI providers, with particular focus on models presenting systemic risk.

    A GPAI model is presumed to carry systemic risk once its cumulative training compute exceeds 1025 floating-point operations (FLOPs), per the AI Act’s Article 51 threshold; the Commission can also designate a model systemic on the scientific panel’s advice. Once access is requested, the scope can include:

    • API-level access to the model’s outputs and behaviour under specified test conditions.
    • Source code, where API access is insufficient to complete the evaluation.
    • Prior “structured dialogue” under Article 92(7), where the AI Office first discusses the provider’s internal testing and risk-mitigation measures before formally requesting access.

    Article 92(6) leaves the fine-grained detail — expert-selection procedure, evaluation arrangements, timelines — to a future Commission implementing act, so several operational details remain unsettled ahead of the 2 August 2026 application date.

    Article 92 vs the DSA’s vetted-researcher regime

    Commentary that describes Article 92 as “modelled on the DSA” understates a structural difference: the Digital Services Act’s Article 40(8) builds a standing, application-based pathway for named external researchers, while the AI Act channels evaluation through a Commission-controlled expert panel. The table below sets out the contrast.

    Feature AI Act Article 92 DSA Article 40
    Who gets access AI Office directly, or independent experts appointed by the Commission External “vetted researchers” who apply and are approved
    Application route None — experts are selected by the Commission from the Article 68 scientific panel Duly substantiated application to a Digital Services Coordinator
    Eligibility test Article 68(2): AI expertise, independence, diligence Article 40(8): research-organisation affiliation, independence, funding disclosure, data-security capability, proportionality, public-results commitment
    Subject matter General-purpose AI models, especially those with systemic risk Data held by very large online platforms and search engines
    Trigger Insufficient Article 91 information, or a systemic-risk alert Research into systemic risks under Article 34(1)
    Legal instrument Regulation (EU) 2024/1689 Regulation (EU) 2022/2065

    For a researcher hoping to independently audit a high-risk AI system deployed by a university, employer, or public body, Article 92 currently offers no comparable entry point. The closer analogue for that kind of scrutiny remains national market-surveillance authority activity under Chapter IX of the AI Act, not a researcher-access clause.

    Answer-first Q&A

    Does the AI Act give researchers open access to high-risk AI systems?

    No. Article 92 grants access powers to the AI Office and Commission-appointed independent experts, not to self-nominating academic researchers. Unlike the DSA, there is no statutory application process through which an outside researcher can request evaluation access to a high-risk AI system or a general-purpose AI model.

    What is the difference between AI Act Article 92 and DSA Article 40?

    Article 92 lets the Commission compel access to general-purpose AI models for compliance and systemic-risk evaluation, using its own appointed experts. DSA Article 40 instead lets external “vetted researchers” apply to a Digital Services Coordinator for access to platform data, a genuinely open external-researcher pathway that Article 92 does not replicate.

    Who qualifies as an independent expert under Article 68?

    Under Article 68(2), experts must show up-to-date AI expertise, complete independence from any AI system or model provider, and the ability to work diligently and objectively. The Commission selects the panel, sets its size, and must ensure fair gender and geographical representation among members.

    When does Article 92 take effect?

    Article 92 becomes applicable on 2 August 2026, in line with the AI Act’s staggered timetable under Article 113. The supporting scientific panel under Article 68 was already applicable from 2 August 2025, giving the Commission a year to establish the panel before evaluation powers activate.

    Implications for research administrators and institutions

    Research administration teams should separate two distinct exposures. First, if their institution deploys AI systems that fall under Annex III — admissions or assignment tools for educational institutions, recruitment and candidate-evaluation systems, or emergency-services triage tools — those systems are “high-risk” under the AI Act’s own Chapter III framework and carry provider or deployer obligations regardless of Article 92.

    Second, if their institution’s researchers want to study a general-purpose AI model with systemic risk, Article 92 does not currently give them a route to request evaluation access in the way DSA Article 40 lets accredited researchers request platform data. Institutions monitoring AI governance developments in research administration should track the Commission’s pending Article 92(6) implementing act, since it may eventually broaden how external expertise is brought into the evaluation process.

    Outlook

    The gap between Article 92’s provider-facing evaluation power and the DSA’s researcher-facing access regime is likely to remain a live policy debate through 2026 and 2027, as the AI Office builds out its scientific panel and issues the implementing acts required by Article 92(6). Until then, claims that the AI Act “grants researcher access to high-risk systems” overstate what the text currently delivers: a regulator’s evaluation tool, not a researcher’s request mechanism.

  • 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.