Learning analytics and GDPR: what universities may do with student data

Every learning platform records what students open, submit and when. Learning analytics turns those traces into dashboards, early warnings and personalised feedback. Done well, it helps students who are struggling; done carelessly, it profiles students without their knowledge and drifts into uses nobody agreed to. This guide explains what the GDPR allows, how profiling and Article 22 apply, what published university policies say, and what the EU AI Act will require from 2 December 2027.

Published 7 October 2026 · Sources checked 7 October 2026

What counts as learning analytics

The University of Edinburgh uses the Society for Learning Analytics Research definition: "the measurement, collection, analysis and reporting of data about learners and their contexts, for purposes of understanding and optimising learning and the environments in which it occurs" [12]. In practice universities run four kinds of analytics, with rising data protection impact:

Data sources usually include the learning management system, the student information system, library and attendance systems, and increasingly AI tutors and assessment tools. Combining them is what makes analytics useful, and also what raises the risk.

Legal basis

Article 6(1)(e) GDPR permits processing necessary for a task carried out in the public interest or in the exercise of official authority, and Article 6(3) requires that basis to be laid down by Union or Member State law [1]. For a public university, teaching, examining and supporting students are statutory tasks. Learning analytics can rest on that basis where it is genuinely necessary for those tasks, for example to identify students who need support or to improve course design.

Article 6(1)(f), legitimate interests, "shall not apply to processing carried out by public authorities in the performance of their tasks" [1]. Whether a university counts as a public authority depends on national law. Private institutions that rely on legitimate interests need a documented balancing test; our legitimate interest assessment template sets one out.

Consent is generally a poor fit for core analytics. Recital 43 says consent is unlikely to be freely given where there is a clear imbalance, in particular where the controller is a public authority [1]. Consent remains useful for optional features a student can genuinely decline without disadvantage, such as opting into a personalised study coach.

Validemic's analysis "Necessary" is the operative word. Public task covers analytics that serves teaching and student support in a way students can reasonably expect. It is weaker for open-ended data mining, experimental models or commercial product improvement by the vendor. Write down what the analytics is for, and why less intrusive means (such as aggregate data or teacher judgement) are not enough.

Purpose limitation and function creep

Article 5(1)(b) requires data to be collected for specified, explicit and legitimate purposes and not further processed in an incompatible way [1]. Learning platform logs are collected to deliver courses. Using them to predict dropout is a further purpose. Where the further processing is not based on consent or a specific legal provision, Article 6(4) requires a compatibility test that weighs the link between purposes, the context and relationship with students, the nature of the data (especially special categories), the possible consequences for students and the safeguards, such as pseudonymisation [1]. Recital 50 adds that where processing is based on public task, Union or Member State law may specify which further purposes are compatible [1].

The bigger risk is analytics data drifting into uses that were never part of the plan:

• Discipline and fraud. Activity logs used as evidence in misconduct cases.
• Staff performance. Course analytics used to rate teachers. The University of Edinburgh's principles say learning analytics data "will not be used to monitor staff performance, unless specifically authorised following additional consultation" [12].
• Admissions and funding. Engagement scores feeding scholarship or progression decisions.
• Vendor reuse. The platform provider using institutional data to train or improve its own models.

Each of these needs its own assessment, and some will not be compatible. Put the excluded uses in the policy, not only the permitted ones.

Special category and inferred data

Learning analytics rarely sets out to process health, ethnicity or religion, but it can reach them. Disability support records, adjustments for exams, absence patterns around religious holidays or demographic fields used to check for bias are all special category data or can reveal it. The Court of Justice held in C-184/20 that data liable to disclose a sensitive characteristic indirectly, by deduction, falls under Article 9(1) [16]. A model that infers a likely disability from behaviour is processing health data.

The Jisc code of practice, written for UK institutions, says student consent is required for the collection and use of special category data such as ethnicity for learning analytics, and that such use requires additional safeguards [11]. Under the EU GDPR, an Article 9(2) exception is needed, which may be explicit consent or a provision of national law; check which your Member State provides. The AI Act adds a narrow, separate permission to process special category data where strictly necessary to detect and correct bias in AI systems, under strict conditions (Article 4a, as inserted by the AI Omnibus) [17].

Validemic's analysis The safe default is to keep special category data out of predictive models and use it, if at all, only for separate fairness testing under strict access control.

Profiling and Article 22

Article 4(4) defines profiling as automated processing used to evaluate personal aspects, "in particular to analyse or predict aspects concerning that natural person's performance at work, economic situation, health, personal preferences, interests, reliability, behaviour, location or movements" [1]. A dropout risk score or an engagement rating is profiling. Profiling is lawful with a legal basis, but it brings three consequences.

1. The right to object

Article 21(1) gives students the right to object, on grounds relating to their particular situation, to processing based on Article 6(1)(e) or (f), "including profiling based on those provisions". The university must then stop unless it demonstrates compelling legitimate grounds that override the student's interests [1]. Build a route for objections into the system design.

2. Solely automated decisions

Article 22(1) gives a right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects or similarly significantly affects the person [1]. The WP29 guidelines give "decisions that affect someone's access to education, for example university admissions" as an example of a similarly significant effect, and say human involvement must be meaningful, "rather than just a token gesture", and carried out by someone with the authority and competence to change the decision [3].

The Court of Justice widened the picture in SCHUFA (C-634/21): the automated establishment of a probability value is itself an automated decision where a third party "draws strongly" on it to establish, implement or end a relationship with the person [4]. If advisers routinely act on a risk score without their own assessment, the score may be treated as the decision.

Where Article 22 applies, the exceptions in Article 22(2) are narrow: contract, Union or Member State law with safeguards, or explicit consent. Decisions must not be based on special category data unless explicit consent or substantial public interest applies with suitable safeguards (Article 22(4)) [1].

3. Practical design rules

• Predictions should trigger offers of support, not sanctions. The Jisc code says AI-enabled predictions "should prompt offers of support, not restrictions, penalties or high-stakes decisions", unless explicitly justified and governed [11].
• A named adviser reviews the student's situation before contacting them, and records what they decided and why.
• No automatic deregistration, loss of access, or change of level based on a score.
• Test whether the model performs worse for particular groups. The Edinburgh principles recognise that "data and algorithms can contain and perpetuate bias" [12].

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

Transparency and student access

Articles 13 and 14 require the university to tell students the purposes and legal basis of the processing, recipients, retention, their rights, and, where Article 22 decisions are made, "meaningful information about the logic involved, as well as the significance and the envisaged consequences" (Article 13(2)(f)) [1]. Even where Article 22 does not apply, the general fairness and transparency principle in Article 5(1)(a) requires students to understand that they are being profiled.

The Jisc code goes further on practice: institutions should explain the data sources, purposes, metrics, who has access and how to interpret the data, make clear whether AI is used, and let students access all analytics performed on their data, including "the metrics and labels attached to them" [11]. Students also have the right of access under Article 15, which covers risk scores and labels; see our guide to subject access requests.

What university policies say

Published policies show how institutions have translated these rules. Three examples, read on 7 October 2026:

The Open University example shows a trend: the address of its former policy on the ethical use of student data now leads to the Responsible AI Policy [14]. As analytics moves from statistics to machine learning, universities are folding learning analytics governance into broader AI governance. That makes sense if the AI register and the analytics policy point to each other; see our AI policy template.

Analytics inside learning platforms

Much learning analytics is not a separate project but a feature inside the learning management system, often switched on by a faculty or by default. Moodle is a clear example. It ships models including "Students at risk of dropping out", "Upcoming activities due" and "No teaching". Its documentation says "most learning analytics models are not enabled by default" and that machine learning models "must be trained on a site with data" [15]. Enabling the dropout model is therefore a decision to profile students using your own data, and should go through the same governance as any other analytics project.

Commercial platforms increasingly add AI analytics and AI-assisted grading. Our fact sheets cover what each vendor documents: Moodle, Canvas, Blackboard, Brightspace and itslearning. For each platform, ask:

1. Which analytics and AI features exist, which are on by default, and who can switch them on?
2. Is the vendor a processor for analytics, or does it use institutional data for its own purposes such as product improvement or model training?
3. Where is analytics data processed, and by which subprocessors?
4. Can predictions and labels be exported for student access requests, and deleted on schedule?
5. How does the vendor classify each AI feature under the AI Act?

The EU AI Act: Annex III points 3(b) and 3(c)

Annex III lists as high-risk AI systems intended to "evaluate learning outcomes, including when those outcomes are used to steer the learning process" (point 3(b)) and to assess "the appropriate level of education that an individual will receive or will be able to access" (point 3(c)) in education institutions at all levels [5]. Under the amended Article 113, the high-risk rules apply to Annex III systems from 2 December 2027 [7].

Article 6(3) allows some Annex III systems to escape the high-risk label where they pose no significant risk, for example by performing a narrow procedural or preparatory task. But "an AI system referred to in Annex III shall always be considered to be high-risk where the AI system performs profiling of natural persons" [6]. Learning analytics that profiles individual students for a 3(b) or 3(c) purpose is therefore likely to be high-risk.

The Commission's draft examples, not yet formally adopted (the public consultation closed on 23 July 2026), help with triage [9]:

• In scope of 3(b): grading and feedback systems for tests that count towards a final evaluation; a personalised learning assistant that generates reports with grades.
• In scope of 3(c): adaptive placement tools; AI classifiers that classify students with special needs.
• Out of scope: student-initiated personalised recommendations not used by the institution; trend analysis of attainment whose output is not used for decisions about individual students; learning companions for neurodivergent students not intended to determine grades.
• Filtered out by Article 6(3): a grade calculator that averages marks; an assessment review tool that detects deviations in grading patterns without replacing human assessment.

Validemic's analysis A dropout early-warning model is not named in the draft examples. Whether it falls under 3(b) depends on whether it evaluates learning outcomes or steers learning, which many such models do. Plan as if it does: the cost of preparing is low compared with discovering in 2028 that you deployed a high-risk system without oversight, logs or a fundamental rights impact assessment.

If a system is high-risk, the university as deployer must use it according to the instructions for use, assign competent human oversight, monitor it, keep logs for at least six months, use the provider's information in its DPIA and inform students that they are subject to the system (Article 26) [8]. Bodies governed by public law must also carry out a fundamental rights impact assessment before first use, which may cross-reference the DPIA (Article 27) [18]. The AI Act education checker walks through the classification.

Already prohibited: attention and emotion tracking

Article 5(1)(f) has prohibited AI that infers emotions in education institutions since 2 February 2025. The Commission's guidelines state that "using an emotion recognition AI system by an education institution to infer the interest and attention of students is prohibited" [10]. They also note that inferring emotions from written text is not based on biometric data and so falls outside this prohibition, while inferring emotions from keystrokes, facial expressions or posture falls within it [10]. Engagement analytics built on webcam or typing behaviour should be checked against this line.

DPIA and retention

Article 35(3)(a) requires a DPIA for systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions with legal or similarly significant effects are based [1]. Beyond that, the WP29 criteria include evaluation or scoring (with predicting performance and behaviour as examples), matching or combining datasets, large-scale processing and vulnerable data subjects; meeting two criteria normally requires a DPIA [2]. Predictive learning analytics typically meets several. Our DPIA template guide includes a worked learning analytics example.

Retention is often overlooked. Raw clickstream data, model features, predictions and records of interventions each need a period. The Jisc code says data should be retained "only for appropriate and clearly defined periods" and that personal data used for or generated by learning analytics should be destroyed or anonymised on request, except specified fields such as grades [11]. Under Article 5(1)(e) GDPR, predictions about a student should not outlive their purpose [1]. Our retention schedule guide has a model.

Checklist

1. Policy: adopt a short learning analytics policy with permitted purposes, excluded purposes (discipline, staff appraisal, vendor reuse) and named responsibilities.
2. Inventory: list every analytics and AI feature in your platforms, including those inside the LMS, and who enabled them.
3. Legal basis: record the basis for each use (public task with its national legal ground, or legitimate interests for private institutions) and the Article 6(4) compatibility assessment for reused data.
4. Special categories: keep them out of predictive models; identify the Article 9(2) exception for any use, including fairness testing.
5. Human in the loop: every prediction reviewed by a person with authority to disagree; no automatic consequences; record decisions.
6. Objections: a working process for Article 21 objections to profiling.
7. Transparency: a plain-language notice on data sources, metrics, AI use and logic; students can see their own scores and labels.
8. Fairness: test models for different error rates across groups before and after launch.
9. AI Act: classify each AI feature against Annex III 3(b) and 3(c); remove anything that infers attention or emotions; plan Article 26 and 27 duties for 2 December 2027.
10. DPIA before enabling predictive or adaptive models, updated when models or data sources change.
11. Vendors: DPA terms that bar the vendor from using institutional data for its own model training, with a subprocessor list and data location.
12. Retention: defined periods for raw data, features, predictions and intervention records.
13. Student voice: consult student representatives on design and review, as the Jisc code recommends.

Sources

All sources retrieved 7 October 2026.

1. Regulation (EU) 2016/679 (GDPR), Articles 4(4), 5, 6, 13, 21, 22 and 35 and recitals 43 and 50, text read from the Publications Office copy of the Official Journal.
2. Article 29 Working Party, Guidelines on Data Protection Impact Assessment (WP248 rev.01).
3. Article 29 Working Party, Guidelines on Automated individual decision-making and Profiling (WP251 rev.01).
4. Court of Justice of the EU, Judgment of 7 December 2023, SCHUFA Holding (Scoring), C-634/21, operative part, text read from the Publications Office.
5. AI Act, Annex III: High-risk AI systems referred to in Article 6(2), AI Act Service Desk.
6. AI Act (as amended), Article 6: Classification rules for high-risk AI systems.
7. AI Act (as amended by Regulation (EU) 2026/1744), Article 113: Entry into force and application.
8. AI Act, Article 26: Obligations of deployers of high-risk AI systems.
9. AI Act Service Desk, Draft guidelines summary: Education and vocational training (draft; see consultation page).
10. European Commission, Guidelines on prohibited AI practices, published 4 February 2025 and formally adopted as C(2025) 5052 on 29 July 2025, section 7 (emotion recognition), and Article 5.
11. Jisc, Code of practice for learning analytics, published 4 June 2015, updated 9 September 2026 (CC BY 4.0).
12. University of Edinburgh, Learning Analytics Principles and Purposes (PDF), linked from Principles and purposes.
13. University of Edinburgh, Learning Analytics Policy (policy page).
14. The Open University, Responsible AI Policy and policy PDF (version 1.3); the former address help.open.ac.uk/documents/policies/ethical-use-of-student-data redirects to this page.
15. MoodleDocs, Analytics (the live page blocked automated access on 7 October 2026; text read from the Internet Archive copy of 30 December 2024).
16. Court of Justice of the EU, Judgment of 1 August 2022, OT v Vyriausioji tarnybinės etikos komisija, C-184/20, text read from the Publications Office.
17. AI Act (new), Article 4a: Processing of special categories of personal data for bias detection and correction.
18. AI Act (as amended), Article 27: Fundamental rights impact assessment.

About this page

Sources checked on 7 October 2026. We read the GDPR and the Court of Justice judgments from the EU Publications Office, the AI Act through the Commission's AI Act Service Desk, the WP29 guidelines from the Commission's archive, and the published policies of the University of Edinburgh, the Open University and Jisc. The Jisc code and the two universities' policies are written for the UK, where the UK GDPR applies; we cite them as examples of practice, not as statements of EU law. The Commission's Annex III examples are drafts. This page is not legal advice; the legal basis for learning analytics at your institution depends on national education law and your institution's legal status. If you see an error or know a policy we should add, please contact us and we will correct it.