CASRAI Dictionary

Tag: AI Act research exemption

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

  • Deemed Export Rule and AI Research Compliance

    The deemed export rule treats the release of export-controlled technology or source code to a foreign national inside the United States as if it were an export to that person’s home country, even though nothing crosses a physical border. For AI research groups, this means that giving a foreign-national graduate student or postdoc access to certain model weights, training code, or restricted technical data can itself require a federal export licence.

    A deemed export is any release of “technology” or “technical data” — controlled under the Export Administration Regulations (EAR) or the International Traffic in Arms Regulations (ITAR) — to a foreign person physically present in the United States. The doctrine is old; its application to frontier AI systems is new, and it now collides with university research practice.

    What is the deemed export rule?

    Under 15 CFR 734.13(b) of the EAR, releasing controlled technology or source code to a foreign person in the United States is “deemed” to be an export to that person’s country of nationality. The Bureau of Industry and Security (BIS), the Commerce Department agency administering the EAR, names universities and high-technology research institutions as typical deemed-export-licence users, alongside biochemical, medical and computer-sector organisations.

    A “release” can occur through conversation, email, or lab access that lets a foreign national read or modify controlled source code — no shipment is required. Permanent residents, US citizens, and “protected individuals” under US immigration law are exempt; most international graduate students and postdocs on visas are not.

    How the fundamental research exclusion applies to AI research

    Most university AI research avoids deemed export licensing through the fundamental research exclusion at 15 CFR 734.8. Fundamental research is basic or applied research in science and engineering where the resulting information is ordinarily published and shared broadly, with no restrictions on foreign-national participation and no government-imposed access controls.

    The exclusion is conditional, not automatic. It fails where:

    • Results are restricted for proprietary or commercial reasons, such as a sponsorship agreement with a publication-delay clause.
    • The funding agreement imposes access or dissemination controls, which some defence-adjacent AI grants do.
    • The activity involves direct transfer of a controlled item — hardware, software, or source code — rather than an exchange of research information.

    Information already publicly available, including open-access papers and public code repositories, is separately exempt from EAR licensing.

    When AI models, weights and training infrastructure trigger a deemed export

    Using a publicly available AI chatbot or API is not, by itself, a release of controlled technology. Risk rises when a foreign national gains access to model architecture details, training methodologies, or model weights covered by an Export Control Classification Number (ECCN) on the Commerce Control List, or to advanced computing hardware BIS has specifically controlled.

    BIS tightened advanced-computing controls in its October 2022 Interim Final Rule, amended October 2023, then went further in January 2025 with a Framework for Artificial Intelligence Diffusion rule that, for the first time, extended export-control treatment to certain closed-weight AI model parameters, not only training hardware. Disclosing weights, architecture specifications, or training-cluster configuration for a covered model to a foreign-national researcher can itself be a release event.

    Much of this tightening is explicitly framed around china ai regulation concerns — restricting frontier compute and model know-how flowing to entities on the BIS Entity List. Nationality alone does not create liability; nationality plus access to a controlled item, combined with funding or sponsor restrictions, does.

    US deemed export rules vs the EU AI Act research exemption

    Institutions with EU partnerships increasingly ask how the US doctrine compares with the European approach. The EU AI Act — Regulation (EU) 2024/1689 — takes a structurally different route: rather than controlling technology transfer by nationality, it excludes AI systems and models developed and used exclusively for scientific research from most of the Act’s obligations, under Article 2(6) and Article 2(8).

    Aspect US deemed export rule EU AI Act research exemption
    Governing instrument EAR, 15 CFR 734.13(b) and 734.8 Regulation (EU) 2024/1689, Art. 2(6) & 2(8)
    What triggers the rule Release of controlled technology to a foreign person Placing an AI system on the market or into service
    Exclusion basis Fundamental research intended for open publication Research and development activity, prior to market placement
    Administering body Bureau of Industry and Security (Commerce Dept.) National market surveillance authorities / EU AI Office
    Nationality relevant? Yes — central to the rule No — exemption is activity-based, not person-based

    The distinction matters for compliance design: a US export control office manages deemed exports as a personnel and access-control question, while an EU research-exemption assessment is a product-lifecycle question. A model built for fundamental research at a US university may fall outside the AI Act exemption once deployed commercially — the two frameworks do not map onto each other cleanly.

    Compliance steps for universities with foreign national researchers

    Export control officers, research administrators, and AI lab principal investigators need a shared workflow before granting foreign nationals lab or system access:

    1. Screen every incoming foreign national against the BIS Entity List and the Treasury Denied Persons List before granting technical access.
    2. Classify the technology, dataset, or model against the Commerce Control List to determine whether an ECCN applies.
    3. Document the fundamental research exclusion in writing at project inception — funding terms, publication plans, and sponsor restrictions.
    4. Restrict access to controlled weights or training infrastructure until the export control office confirms licence status.
    5. Certify deemed export status accurately on Form I-129 for H-1B, H-1B1, L-1, and O-1A hires, as USCIS requires.
    6. Use the NIST AI Risk Management Framework to document AI system risk tiers internally — a defensible record, though not itself an export-control exemption.

    Treat this as distinct from state ai laws, such as Colorado’s and California’s AI transparency statutes, which govern AI deployment to end users, not technology transfer to foreign persons — a university can comply with one and still be exposed under the other. Guidance from the Center for AI Standards and Innovation (CAISI), the Commerce Department body that succeeded the original AI Security Institute at NIST, can inform risk-evaluation methodology, though it is not itself an export-control determination. See CASRAI’s research administration resources for broader governance context.

    Frequently asked questions

    What are the criteria for a deemed export?

    A deemed export occurs when controlled technology or source code is released to a foreign person inside the United States. The criteria: the item sits on the Commerce Control List or US Munitions List, the recipient is not a citizen, permanent resident, or protected individual, and no exclusion applies.

    How can a university determine whether an activity is a deemed export?

    A university’s export control office classifies the technology against its ECCN or USML category, checks whether the fundamental research exclusion applies, and confirms the researcher’s immigration status. If the technology is controlled, the researcher is a foreign person, and no exclusion fits, a licence is required before access.

    Who is exempt from the deemed export rule?

    US citizens, lawful permanent residents, and individuals granted protected individual status under US immigration law are exempt from deemed export licensing regardless of the technology involved. Most international students and postdocs on visas do not qualify for this exemption and depend instead on the fundamental research exclusion.

    Does using a publicly available AI model trigger a deemed export?

    No. Interacting with a publicly available AI model — a public API, chatbot, or open-weight release with no access restrictions — is not a controlled release under the EAR. Risk arises only when a foreign national gains access to restricted model weights, proprietary architecture details, or controlled training infrastructure not available to the public.

    Implications and outlook

    Export control offices built their playbooks around physical items and classified research; AI weights and training infrastructure do not fit that playbook cleanly. As BIS extends ECCN coverage into software and model parameters, universities running foreign-national-staffed AI labs face rising documentation burden even where no licence is ultimately required.

    Expect continued divergence between the deemed export regime, EU AI Act research-exemption practice, and state ai laws — three separate compliance tracks addressing different questions. Research administrators who map these tracks now, rather than after an incident, will be better placed as controls continue to tighten.

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

  • EU AI Act Research Exemption: What Article 2(6) Actually Covers

    A run of academic literature published since mid-2025 — an editorial in GRUR International, a peer-reviewed analysis in Nature’s npj Digital Medicine, and a widely cited Swedish doctoral paper — has converged on the same conclusion: the EU AI Act research exemption is far narrower, and far less certain, than most research offices assume. Regulation (EU) 2024/1689 does carve scientific research and development out of scope, but that carve-out is built from two separate provisions with different wording, different triggers, and different failure points. For institutions running AI-assisted studies, clinical trials, or general-purpose model development, misreading where the exemption ends is now a live compliance risk.

    What Article 2(6) actually says

    Article 2(6) of the AI Act states that the Regulation “does not apply to AI systems or AI models, including their output, specifically developed and put into service for the sole purpose of scientific research and development.” Two conditions must both be met: the system or model must be developed for scientific research, and it must be put into service — first used for its intended purpose — exclusively for that research. Recital 25 is the only interpretive gloss the legislative text offers, and it does not define “scientific research and development” further.

    Critically, Article 2(6) exempts systems that are put into service for research, but it does not extend to systems that are placed on the market. That distinction — put into service versus placed on the market, defined respectively in Articles 3(10) and 3(9) — is where the exemption’s practical limits begin.

    Two exemptions, not one: Article 2(6) vs Article 2(8)

    Law professor Michèle Finck’s October 2025 editorial “In Search of the Lost Research Exemption” (GRUR International, Vol. 74, Issue 10) makes the point that is most often missed: the AI Act contains two distinct research exemptions, not one. Article 2(6) is narrow and limited to scientific research; Article 2(8) is broader and covers any research, testing or development activity, scientific or not, but only up to the point of market placement or service.

    Provision What it exempts Key limit
    Article 2(6) AI systems/models developed and put into service solely for scientific research and development Not limited to pre-market stage, but strictly tied to “sole purpose” of research — loses protection once put into service for any other use
    Article 2(8) Any research, testing or development activity (not limited to science) regarding AI systems or models Applies only prior to placing on the market or putting into service; explicitly excludes real-world testing

    Finck argues that this dual structure creates an “interpretative conundrum”: if Article 2(8) only ever covers activity that happens before market placement, and market placement is already the trigger for the Act’s obligations regardless of the exemption, the provision risks adding little independent legal value — precisely the ambiguity that gives the “lost” exemption its name.

    Where the research exemption stops applying

    The Nature-published analysis by Meszaros and colleagues (npj Digital Medicine, 2026) sets out a conceptual framework built around a single regulatory threshold: placement on the market or putting into service. Everything on the research side of that line can be exempt; everything on the other side is regulated. Three scenarios repeatedly cross that line.

    Commercialisation and dual-purpose systems

    A system loses its exemption the moment it is not developed for the sole purpose of research. Finck highlights that Horizon Europe-style collaborations, where a university partners with an industrial co-investigator who intends to commercialise the output once the exploratory phase ends, sit in exactly this grey zone. Whether “commercial purpose” is assessed objectively (does a commercial partner exist) or subjectively (did the researchers intend commercialisation) remains unresolved in the text itself.

    Post-market deployment and real-world testing

    Article 2(8) states plainly that “testing in real-world conditions shall not be covered by that exclusion.” A model tested only in a closed lab environment can remain exempt; the same model tested on live users, patients, or public-facing systems generally cannot, unless it proceeds through the Act’s dedicated real-world testing and regulatory sandbox framework (Articles 57–61). Colonna’s 2024 analysis for the DiVA repository similarly stresses that the exemption was never intended to cover deployment-stage activity dressed up as “ongoing research.”

    GPAI models and systemic-risk obligations

    Because Article 2(6) explicitly names “AI models” alongside “AI systems,” a general-purpose AI (GPAI) model built and used solely for research is exempt. That exemption evaporates once a provider places the model on the Union market — including releasing a checkpoint for downstream use beyond pure research. From that point, Title VIII’s GPAI obligations under Article 53 (technical documentation, copyright-compliance summaries) apply, and models presumed to carry systemic risk — those trained with cumulative compute above 10^25 FLOPs — face the additional Article 55 duties regardless of open-source licensing. A separate, unconditional exclusion exists for military, defence and national-security AI under Article 2(3); that provision is absolute and is not contingent on “sole purpose,” unlike the research exemptions.

    Frequently asked questions

    What is Article 2(6) of the EU AI Act?

    Article 2(6) excludes AI systems and AI models — including their output — from the AI Act when they are specifically developed and put into service for the sole purpose of scientific research and development. It does not, however, exempt systems that have been placed on the market.

    Does the AI Act research exemption cover real-world testing?

    No. Article 2(8) states explicitly that testing in real-world conditions is not covered by the research exclusion. Researchers deploying systems outside a controlled setting generally need to use the Act’s regulatory sandbox and real-world testing framework instead.

    Are GPAI models exempt from the AI Act during research?

    Yes, while a general-purpose AI model is developed and used solely for research it falls outside scope. Once placed on the market, Title VIII obligations attach, with stricter Article 55 duties for models presumed to carry systemic risk above the 10^25 FLOPs training-compute threshold.

    Can university-industry collaborations rely on the research exemption?

    Only where the sole purpose remains scientific research. Per Finck’s 2025 analysis, Horizon Europe-style projects involving a commercial partner intending future exploitation risk losing Article 2(6)/2(8) protection once a profit-oriented purpose is established.

    What this means for research institutions and publishers

    Research administration offices — the ARMA, EARMA and INORMS community that oversees institutional compliance — now have a practical due-diligence question to add to AI-enabled research proposals: at what point does this project’s AI system move from “developed for research” to “put into service” or “placed on the market”? That question matters most for:

    • Clinical and biomedical AI tools that progress from retrospective lab validation to prospective real-world testing on patients.
    • Multi-partner Horizon Europe consortia where an industrial partner holds commercialisation rights from the outset.
    • Open-source model releases on code and model-sharing platforms, which several commentators — including the arXiv paper “Beware! The AI Act Can Also Apply to Your AI Research” — flag as a possible trigger for “placing on the market.”
    • Foundational research (for example, in AI explainability or causal reasoning) whose downstream applications are not yet known at the outset, which Finck notes may struggle to meet the “sole purpose” test even where no commercial partner is currently involved.

    Institutions with dedicated research administration functions are best placed to build this threshold assessment into ethics review and grant-agreement workflows now, rather than retrofitting compliance once a system reaches deployment.

    Looking ahead

    The AI Act’s general provisions, including Article 2’s scope rules, have applied since 2 February 2025; GPAI obligations followed on 2 August 2025; most remaining obligations, including high-risk system requirements under Annex III, become applicable from 2 August 2026. Every commentator reviewed here — Finck, Meszaros et al., and Colonna — reaches the same practical conclusion: the European Commission’s promised guidance on the research exemptions has not yet resolved the “sole purpose,” commercial-intent, and real-world-testing ambiguities in the text. Until that guidance lands, institutions should treat the exemption as a narrow, conditional safe harbour rather than a blanket shield, and document the specific research purpose, funding structure, and deployment plan for every AI system that currently relies on it.