CASRAI Dictionary

Tag: EU AI Act compliance

  • EU AI Office: Enforcement for Research Bodies

    The EU AI Office does not enforce most of the AI Act. It is a European Commission unit, inside the Directorate-General for Communications Networks, Content and Technology (DG CNECT), with exclusive competence over general-purpose AI (GPAI) models. Day-to-day enforcement against high-risk AI systems — the category covering most tools used in universities, funders and public research bodies — falls to each Member State’s national market surveillance authority, not the AI Office.

    The EU AI Office is the Commission’s central coordinating body for Regulation (EU) 2024/1689 (the AI Act), responsible for supervising GPAI models, chairing the technical governance structure and preparing Commission guidance — while national authorities retain enforcement power over almost everything else.

    What is the EU AI Office?

    The AI Office was established by a European Commission decision in January 2024, alongside political agreement on the AI Act. It sits within DG CNECT rather than as a stand-alone agency, and functions legally as part of the Commission — so references to “the AI Office” in the Act’s text are references to the Commission acting through that unit.

    Its headquarters are in Brussels. Wikipedia’s infobox for the European Artificial Intelligence Office records around 60 staff at 2024 launch, projected above 140, under Director Lucilla Sioli. The Office also acts as Secretariat to the European AI Board, the forum of one representative per Member State coordinating national implementation.

    • Supervises GPAI model providers under AI Act Chapter V
    • Drafts codes of practice, guidelines and implementing acts for the Commission
    • Coordinates joint investigations across Member States on cross-border AI risk
    • Runs the AI Act Service Desk and single information platform
    • Chairs the scientific panel of independent experts monitoring systemic-risk models

    Who actually enforces the AI Act — the AI Office or national authorities?

    Enforcement is split by system type, not centralised in one body. The AI Office’s remit is narrow but powerful: only GPAI models and systems — the foundation models underpinning many downstream research tools. Everything else, including the high-risk systems a university, funder or public research agency is far more likely to deploy directly, is enforced nationally.

    Each Member State designates one or more market surveillance authorities (MSAs) under Article 74, alongside a “notifying authority” overseeing conformity-assessment bodies. Because States may designate sector-specific bodies rather than one regulator, the map is fragmented: CMS Law’s 2025 enforcement analysis notes that, once sectoral designations are counted, several thousand bodies across the EU can hold market-surveillance-authority status, with AI systems now added to their remit.

    A separate rule applies to the EU’s own institutions. Under Article 74(9), the European Data Protection Supervisor (EDPS) is the market surveillance authority for AI systems used by EU institutions, bodies, offices and agencies — relevant to EU-funded research infrastructures and executive agencies, as distinct from national universities and funders.

    Body Enforces Covers Key power
    EU AI Office GPAI model obligations (Chapter V) Foundation-model providers, EU-wide Model evaluations, mitigation orders, market withdrawal
    National market surveillance authority High-risk and other AI system obligations Deployers/providers within one Member State, incl. universities and public bodies Inspections, corrective orders, fines
    European Data Protection Supervisor All AI Act obligations EU institutions, bodies, offices and agencies Fines against EU public administration
    European AI Board Coordination, not direct enforcement All 27 Member States (via national reps) Consistency, joint-investigation coordination

    Does the research exemption apply to universities and public bodies?

    Partly, and the boundary matters more than most explainers acknowledge. Article 2(8) states that obligations do not apply to research, testing or development activity on an AI system before it is placed on the market or put into service. Article 2(6) separately exempts systems developed and used for the sole purpose of scientific research and development.

    Neither carve-out protects a university once it moves from research into operational use. Annex III(3) classifies AI systems used to evaluate exam answers, determine admission or assess applicants as high-risk. A plagiarism-detection or admissions-scoring tool a university actually deploys against students is therefore fully in scope — and, because most universities and funders are “bodies governed by public law”, Article 27 requires a fundamental rights impact assessment (FRIA) before deployment.

    How can research institutions and public bodies seek guidance?

    Three channels exist, and institutions frequently default to the wrong one. The AI Act Service Desk (ai-act-service-desk.ec.europa.eu) is the Commission’s central portal where any stakeholder, including a university legal office or funder’s compliance team, can submit a question and get an answer from a Commission-coordinated expert team; it is the right first stop for interpretive questions on scope, classification or the research exemptions above.

    For enforcement-specific queries — “is our deployed system high-risk, and what must we file?” — the correct contact is the national market surveillance authority in the institution’s own Member State, not the AI Office, which has no jurisdiction over nationally-deployed high-risk systems. EU-affiliated bodies should instead approach the EDPS. National governments must separately establish AI regulatory sandboxes, giving public research bodies a supervised route to trial new systems before full-scale deployment.

    What are the penalties for AI Act non-compliance?

    Article 99 sets three fine tiers, using the higher figure for large organisations and the lower for SMEs and start-ups:

    • Up to €35 million or 7% of global annual turnover for breaching prohibited AI practices (Article 5)
    • Up to €15 million or 3% of global annual turnover for breaching most other provider or deployer obligations
    • Up to €7.5 million or 1% of global annual turnover for supplying incorrect, incomplete or misleading information to authorities or notified bodies

    Article 101 gives the Commission a separate fining power against GPAI model providers, up to 3% of worldwide annual turnover or €15 million, whichever is higher, for infringements the AI Office identifies through model evaluation. Public-sector bodies are not exempt from Article 99 fines, though Member States retain some discretion over how penalties apply to public administration.

    Providers can reduce GPAI exposure by signing the General-Purpose AI Code of Practice, published by the AI Office in 2025 with independent experts across transparency, copyright and safety/security chapters. Adherence is voluntary but, pending harmonised standards, creates a presumption of conformity — worth knowing for institutions procuring GPAI tools from signatory vendors.

    Answer-first questions on the EU AI Office

    Where is the EU AI Office?

    The EU AI Office is headquartered in Brussels, inside the European Commission’s Directorate-General for Communications Networks, Content and Technology (DG CNECT). It is not a separate legal agency; it operates as a Commission unit with its own director, staff and published mandate under the AI Act’s governance provisions.

    Who is the head of the EU AI Office?

    The EU AI Office is led by Director Lucilla Sioli, who reports within DG CNECT’s management structure. The director’s mandate covers GPAI supervision, Secretariat duties for the European AI Board, and coordination of the scientific panel of independent experts that monitors systemic-risk models.

    What is a market surveillance authority?

    A market surveillance authority is the national body a Member State designates to monitor, inspect and take corrective or punitive action against non-compliant products — including, under the AI Act, high-risk AI systems deployed within that country’s territory, such as university admissions or assessment tools.

    What is post-market monitoring under the AI Act?

    Post-market monitoring is the ongoing obligation on providers and deployers of high-risk AI to actively collect and analyse performance data after deployment. It feeds directly into market surveillance authority oversight, giving regulators evidence to investigate serious incidents or systemic risk once a system is in real-world use.

    Implications for research administrators

    The practical takeaway is that “who do we ask” and “who can fine us” are different questions with different answers. The AI Office is the right destination for interpretive guidance on GPAI; the national market surveillance authority holds actual enforcement jurisdiction over a deployed high-risk system inside a research institution.

    As GPAI-based tools proliferate across grant review, plagiarism screening and admissions, institutions that conflate the AI Office’s central mandate with national enforcement risk misdirecting queries and missing the FRIA obligations Article 27 attaches to public bodies. Building this literacy now, ahead of the Act’s staged 2025–2027 application timeline, is cheaper than resolving a misdirected enforcement dispute later. For related governance context, see CASRAI’s research administration resources.

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

  • AI Act High-Risk Classification: Annex III for Academic AI Systems

    Admissions-screening tools, exam proctoring software, and subject-profiling systems built or bought by universities are now squarely inside EU compliance scope. AI Act high-risk classification is not a label a developer chooses — it is determined by a fixed legal test set out in Article 6 and Annex III of Regulation (EU) 2024/1689, and most research-facing AI that touches education, employment, or biometric data will fail that test into the “high-risk” tier by default. This walkthrough applies the actual Annex III criteria to the tools research administrators are most likely to encounter.

    What “High-Risk” Means Under the AI Act

    The AI Act sorts systems into four tiers: unacceptable risk (banned outright, applicable since 2 February 2025), high risk, limited risk (transparency duties only), and minimal risk (unregulated). There is no fifth “probably fine” category for academic tools — a system either clears the high-risk gate or it does not.

    Article 6 sets two separate high-risk routes. The first covers AI embedded as a safety component in products already regulated under Annex I product-safety law (medical devices, machinery, and similar). The second — the one that catches nearly all academic and research-administration tools — is Annex III: a fixed list of use cases that are always considered high-risk unless a narrow exemption applies.

    Obligations tied to the Annex III route generally apply from 2 August 2026; the Annex I product-safety route gets an extra year, to 2 August 2027. Providers who conclude their own Annex III system is not high-risk must document that assessment and register it before deployment (Article 6(4)) — silence or informal judgement calls are not a defence.

    The Annex III Walkthrough for Academic AI Systems

    Annex III groups high-risk triggers into eight domains. Three of them account for almost every academic AI tool that raises a compliance question: education, employment, and biometrics. The table below maps common research-institution tools to the specific Annex III clause they hit.

    Annex III category Example academic AI use Clause Verdict
    Education and vocational training Admissions-ranking or applicant-screening AI Annex III(3)(a) High-risk
    Education and vocational training Automated scoring that steers a student’s learning path Annex III(3)(b) High-risk
    Education and vocational training Exam-proctoring software flagging “prohibited behaviour” Annex III(3)(d) High-risk
    Employment and workers management AI screening postdoc, faculty, or research-staff applications Annex III(4)(a) High-risk
    Biometrics Emotion-recognition tool used in a lecture-engagement study Annex III(1)(c) High-risk, unless a narrow medical/safety exception applies
    Biometrics Biometric categorisation inferring ethnicity or political views from images for research subject profiling Annex III(1)(b) High-risk — the profiling override applies (see below)

    Education and Training Triggers

    Annex III(3) lists four education triggers: access/admission decisions, evaluation of learning outcomes, assessment of the appropriate level of education a person can access, and monitoring of prohibited behaviour during tests. A tool only needs to match one clause — not all four — to be caught. An institutional dashboard that merely displays grades without influencing a decision is unlikely to trigger this route; a model that ranks or filters applicants does.

    Employment and Research-Staff Triggers

    Annex III(4) covers recruitment and selection tools (targeted job adverts, CV filtering, candidate scoring) and tools used in promotion, termination, task allocation, or performance monitoring of an existing workforce. Research institutions using AI to shortlist grant-funded researchers, PhD candidates, or lab staff sit inside this trigger on the same footing as any commercial employer.

    Biometric-Categorisation and Profiling Triggers

    Annex III(1) is the sharpest edge for research tools. It covers remote biometric identification, biometric categorisation systems that infer sensitive attributes (race, political opinion, trade union membership, religious belief, sex life, or sexual orientation) from biometric data, and emotion-recognition systems — with only a narrow carve-out for systems used purely for medical or safety purposes. A study instrument that infers demographic or affective attributes from facial or voice data for research subject profiling falls inside this trigger even when the researchers’ intent is purely academic.

    The Narrow-Task Exemption — and Why Profiling Overrides It

    Article 6(3) gives Annex III systems four possible escapes: performing a narrow procedural task, improving the result of work a human already completed, detecting deviations from a prior human decision without replacing it, or performing a preparatory task before a human assessment. A system that clears one of these tests can be treated as not high-risk — but the provider must still document that judgement.

    Critically, Article 6(3) carries an override that most summaries omit: an Annex III system is always high-risk if it performs profiling of natural persons, regardless of whether it would otherwise qualify for the narrow-task exemption. Profiling is defined broadly under EU data-protection law as automated processing used to evaluate personal aspects such as performance, behaviour, preferences, or location. Any admissions tool, proctoring tool, or research instrument that builds a profile of an individual cannot use the narrow-task escape — it is high-risk by default.

    One further nuance matters for university researchers: Article 2 excludes AI systems developed and used solely for scientific research and development from the Regulation’s scope entirely. That exclusion evaporates the moment the same tool is deployed operationally — for example, adapted from a lab study into a live admissions or proctoring product.

    Common Questions on AI Act High-Risk Classification

    What is high risk under the AI Act?

    An AI system is high-risk if it is a safety component of a product regulated under Annex I, or if its use case appears in Annex III — covering biometrics, education, employment, and public services — unless a documented Article 6(3) exemption applies and no profiling occurs.

    What are the four levels of risk in the AI Act?

    The Regulation defines four tiers: unacceptable risk (prohibited outright), high risk (strict pre-market obligations), limited risk (transparency duties, such as disclosing AI-generated content), and minimal risk (largely unregulated, voluntary codes only).

    What are high-risk use cases under the AI Act?

    Annex III lists eight domains: biometrics, critical infrastructure, education and vocational training, employment and worker management, access to essential services, law enforcement, migration and border control, and administration of justice or democratic processes.

    What are examples of high-risk AI systems?

    Documented examples include admissions-screening AI, exam-proctoring software, CV-filtering recruitment tools, creditworthiness scoring, biometric categorisation systems, and remote facial-recognition identification tools used by public authorities.

    Implications for Research Administrators and Developers

    For institutions procuring or building these tools, the practical checklist is short but unforgiving:

    • Map every AI tool touching admissions, assessment, proctoring, staff recruitment, or biometric data against the specific Annex III clause it might trigger.
    • Test each candidate system against the four Article 6(3) exemption conditions — and check separately whether it performs profiling, which overrides any exemption.
    • Document the classification assessment before deployment, even where the conclusion is “not high-risk,” and be ready to produce it to national competent authorities on request.
    • Re-run the assessment when a research prototype moves from the Article 2 scientific-research exclusion into operational use — the exclusion does not travel with the tool.
    • Track the compliance calendar: prohibited-practice bans applied from 2 February 2025; most Annex III obligations apply from 2 August 2026; the Annex I product-safety route follows in August 2027.

    Research administrators sit at the intersection of procurement, ethics review, and data governance, which makes this classification exercise an institutional responsibility rather than a vendor’s alone. Bodies advancing research-administration practice — including CASRAI’s research administration resources — increasingly treat AI-tool risk mapping as a standard due-diligence step alongside existing data-protection and research-integrity checks, and institutions building internal glossaries can cross-reference definitions of profiling, biometric categorisation, and related terms in the CASRAI dictionary.

    The European Commission is due to publish detailed implementation guidelines and worked examples for Article 6 classification. Until then, the safest institutional posture is to assume Annex III applies wherever an academic AI system reaches a decision about a person’s access, evaluation, employment, or biometric profile — and to document the reasoning either way.

  • AI Literacy Obligation Article 4: Staff Training Checklist

    The AI literacy obligation Article 4 of the EU Artificial Intelligence Act has applied since 2 February 2025, yet many research institutions still treat it as a future item rather than a live requirement. Article 4 states that providers and deployers of AI systems “shall take measures to ensure, to their best extent, a sufficient level of AI literacy of their staff and other persons dealing with the operation and use of AI systems on their behalf.” For universities, funders, and research institutes running admissions tools, grant-screening software, or generative AI assistants, that duty is already in force. This article sets out a practical checklist for what “sufficient” means in a research setting, who it covers, and how to evidence it.

    What Article 4 actually requires

    Article 4 does not prescribe a fixed curriculum, test, or certificate. It requires institutions to calibrate AI literacy measures against staff technical knowledge, experience, education, training, and the context in which AI systems are used. The obligation applies to both “providers” (organisations that develop and place an AI system on the market) and “deployers” (organisations using an AI system for a professional purpose).

    A research institution can be either, sometimes simultaneously. A department that builds a bespoke research-data classification model is a provider of that system; the same university using an off-the-shelf tool for applicant screening or meeting transcription is a deployer. The AI Act scope includes a narrow exemption for systems developed and used exclusively for scientific research before market placement — but once a research tool is deployed operationally, that exemption falls away and Article 4 applies in full.

    The statutory definition of AI literacy, in Article 3(56), is: skills, knowledge and understanding that allow providers, deployers and affected persons to make an informed deployment of AI systems, and gain awareness of the opportunities and risks it can cause. The Commission’s AI Office has confirmed it will not impose a single mandatory format.

    Who counts as “staff” under the AI literacy obligation

    This is where most institutions under-scope their programmes. The Commission’s guidance clarifies that “staff and other persons” is broader than payroll headcount — it extends to anyone acting on the institution’s behalf, including contractors and service providers. In a research setting that typically means:

    • Researchers and PIs using generative AI tools for literature review, drafting, or data analysis
    • Research administrators and grants officers using AI-assisted screening or compliance-checking tools
    • HR and admissions staff using AI-based applicant or candidate screening systems
    • IT and research-computing staff configuring or maintaining institutional AI deployments
    • External contractors or visiting researchers granted access to institutional AI systems
    • Board and senior leadership, who need enough literacy to assess institutional AI risk

    Article 4 does not require every group to receive identical training: a developer configuring a high-risk system needs materially more depth than an administrator using a transcription tool. The table below illustrates how role and system risk map onto training depth.

    Personnel category Typical AI Act role Indicative literacy depth
    Data scientists building institutional AI tools Provider Technical: limitations, bias, risk mitigation, documentation
    Grants/admissions staff using screening AI Deployer Operational: output interpretation, human oversight, escalation
    Researchers using generative AI for drafting/analysis Deployer (or exempt if pre-market research use) General awareness: hallucination risk, confidentiality
    Contractors/visiting staff with system access “Other persons” acting on the institution’s behalf Baseline awareness proportionate to access level
    Governing board/senior leadership Deployer (oversight capacity) Strategic: risk appetite, resourcing, regulatory exposure

    Building a defensible AI literacy programme

    The Commission’s AI Literacy Q&A sets out a four-step minimum approach research institutions can adapt directly:

    • Establish a general understanding of AI within the organisation — what AI is used, where, and why
    • Determine the institution’s role for each system: provider, deployer, or both
    • Assess the risk level of each AI system in use, including any high-risk systems under Chapter III
    • Build literacy actions proportionate to staff knowledge gaps and the context of use

    Relying solely on a vendor’s instructions for use is explicitly insufficient — this mirrors the separate Article 26 duty on deployers of high-risk systems to ensure staff are “sufficiently trained” to exercise human oversight.

    What is Article 4 of the EU AI Act?

    Article 4 is the AI Act provision requiring providers and deployers to ensure a “sufficient level” of AI literacy among staff and other persons operating AI systems on their behalf. It has applied since 2 February 2025, ahead of most other AI Act obligations, and covers technical knowledge, training context, and the persons affected by the system.

    What is the definition of AI literacy in the EU AI Act?

    Article 3(56) defines AI literacy as the skills, knowledge and understanding that let providers, deployers and affected persons make informed decisions about deploying AI systems, while remaining aware of the opportunities, risks, and potential harms those systems can cause in their specific context of use.

    Who at a research institution needs AI literacy training under Article 4?

    Anyone dealing with an AI system’s operation or output on the institution’s behalf, not just IT or data-science staff. This includes researchers, administrators, HR and admissions teams, contractors, and senior leadership — with training depth proportionate to each group’s technical role and the risk level of the system they use.

    Does Article 4 require a certificate or formal training records?

    No. The AI Office has confirmed there is no mandated test or certificate for Article 4 compliance. Institutions should instead keep an internal record of training delivered, attendance, and content — evidence that becomes essential if a national market surveillance authority later reviews compliance.

    Documenting compliance: what evidence to keep

    Because Article 4 sets no certification standard, the practical question is evidential: what would a research institution show a national market surveillance authority if asked? A defensible record typically includes:

    • A written AI inventory identifying each system in use, its provider/deployer classification, and risk tier
    • Training content and delivery records (dates, attendance, format) mapped to each staff category
    • A documented rationale for why the chosen literacy measures were “sufficient” for each role and system
    • An AI use policy communicated to staff, contractors, and other relevant persons
    • A review cycle — literacy measures should be revisited as systems and risk profiles change

    National market surveillance authorities take over enforcement of Article 4 from 2 August 2026, when the AI Act’s general application and high-risk provisions take effect. Enforcement is meant to be proportionate — gravity, intent, and negligence are all considered — but an incident with no evidence of staff training is likely to weigh against an institution.

    Implications for research institutions and GPAI tools

    Research institutions increasingly deploy general-purpose AI (GPAI) tools — large language model assistants embedded in research-writing or literature-search workflows — rather than narrow, purpose-built systems. The AI Act GPAI provisions (Chapter V, applying to GPAI model providers from 2 August 2025) sit alongside, not instead of, the Article 4 duty on deployers: using a GPAI-based writing assistant still makes an institution a deployer under Article 4, regardless of the model provider’s own transparency obligations.

    One development worth tracking: the European Commission’s 2025 Digital Omnibus proposal would shift part of the Article 4 burden from individual organisations toward Member States and the Commission itself. That proposal has not been adopted, so the current text of Article 4 remains binding on institutions as providers or deployers — institutions should not defer action for a change that may not materialise as proposed.

    Sector signals reinforce the direction of travel: UK courts have separately expected legal professionals to demonstrate AI competence in submissions, and UK financial regulators have referenced the Senior Managers Regime in connection with AI risk oversight — evidence that “sufficient AI literacy” is becoming an expectation beyond the AI Act’s direct territorial reach.

    What research institutions should do next

    Institutions without a formal AI literacy programme should start with an AI system inventory, classify each system by provider/deployer role and risk tier, then build tiered training from that analysis rather than buying a generic module. Article 4 rewards documented judgement over box-ticking: the institutions best placed for enforcement from August 2026 will be those that can show a reasoned, evidenced, role-differentiated approach. Research-administration functions, which typically already own institutional policy documentation, are well positioned to lead this work alongside data protection, IT governance, and research integrity offices.