Students who may be struggling are noticed in week three, not at the exam board. A person reaches out and offers support, and the flag never decides anything about a student's progress.
At a glance
An illustrative scenario. The numbers are typical examples, not a client case study. The cloud services and UK rules were checked on 9 November 2026.
Most students who leave a course don't leave suddenly. They stop logging in to the virtual learning environment, miss a few seminars, submit a piece of work late or not at all. Each signal sits in a different system, and no single member of staff sees them together. By the time a personal tutor notices, the student may already have decided to go.
The data to spot this exists: VLE activity, attendance capture, library and lecture-capture use, submissions and the student record. What's missing is a reliable way to bring it together, show it to the right person, and make sure someone actually acts. Tutors are stretched, student support teams are busy, and dashboards that nobody owns get ignored.
This matters to students first, and to the university's obligations too. The OfS expects providers to support students to succeed and to deliver positive outcomes, measured through continuation and completion. But an early-warning system also carries real risks: flagging some groups of students more than others, using sensitive data without a clear basis, or quietly becoming part of decisions it was never meant for. The design has to deal with those risks from the start.
Agree these, and measure the baseline, before anything is built. Example targets are typical, not promises.
How long after a student starts disengaging a member of staff reaches out.
ExampleFrom weeks to within 5 working days
Share of flags where a tutor or adviser recorded an outcome. A flag nobody acts on is worse than no flag.
ExampleAbove 90%
Compared with a matched baseline from earlier years, not with students who weren't flagged.
ExampleMeasured, not promised
Flag rates, false-alarm rates and missed students, by ethnicity, disability, sex, age, mode of study and commuter status.
ExampleNo group flagged or missed out of proportion without a reason
Share of flagged students that tutors judged genuinely needed contact.
ExampleReviewed every month
How many students opt out or complain, and why. A sharp rise means the communication isn't working.
ExampleTracked, and discussed with the students' union
Cross-sector rules are on the UK regulation map.
B2 asks providers to give each cohort the support it needs to succeed. B3 sets minimum thresholds for continuation, completion and progression; for full-time first degrees, 80%, 75% and 60%, used with context rather than as an automatic test. The early-warning system supports students to continue. It must never be used to steer struggling students off a course to protect the numbers.
Universities in England are covered by the Public Sector Equality Duty, so do an equality impact assessment before the pilot and monitor outcomes by group. Disabled students may engage differently, for example through alternative formats that don't show as VLE logins, so a low score can be a sign the data is blind, not that the student is. In 2024 the High Court confirmed that the duty to make reasonable adjustments in higher education is anticipatory: it can apply before a student has disclosed a disability.
Early-warning scoring is profiling. That means a DPIA, a clear lawful basis, privacy information students can understand, and a working right to object. Health and mental-health information is special category data: it isn't a model feature, and it stays in student support's own case records. Protected characteristics are used only to monitor fairness, under the equality-monitoring condition in the Data Protection Act 2018, and are kept apart from the scoring.
Since 5 February 2026, the strict limit on solely automated significant decisions applies mainly where special category data is involved, and every other automated decision needs safeguards. This design makes no decision: the model prompts a person, and the person decides whether to make contact. Keep it that way, and keep the evidence that it is.
Where a tutor is worried about a student's safety, the university's own wellbeing and emergency procedures apply, including any trusted contact arrangements. The model plays no part. The ICO says this guide is under review after the Data (Use and Access) Act.
Sponsors must monitor whether sponsored students are academically engaging and report those who stop. Keep that compliance process separate, with its own records and staff. The early-warning score must never feed visa reporting, or students will lose trust in the support it offers.
Showing AWSAzuresovereign / on-prem services. Switch with the toggle; every diagram and table on this page follows it.
01Channels
02Intake
03Intelligence
04Orchestration
05Systems of record
06People
| Layer | AWS | Azure | Sovereign / on-prem |
|---|---|---|---|
| Data intakeBring in only the engagement fields agreed in the DPIA. No free-text notes, health or disability records. | AWS Glue, Amazon S3 | Data Factory in Microsoft Fabric, OneLake | Apache Airflow or n8n; Ceph or IONOS S3 Object Storage |
| Engagement data storeOne row per student per week. Simple, explainable features beat hundreds of opaque ones. | Amazon Redshift | Fabric Warehouse | PostgreSQL |
| Model training and scoringA gradient-boosted model or logistic regression is usually enough. Retrain each year on the university's own data, and compare with simple rules first. | Amazon SageMaker AI | Azure Machine Learning | MLflow and Kubeflow on Kubernetes |
| Reasons for each flagTurn the top factors into plain sentences a tutor can say out loud. If a reason can't be explained to a student, drop the feature. | SHAP on SageMaker AI | SHAP on Azure Machine Learning (also in its Responsible AI dashboard) | SHAP on Kubeflow |
| Fairness and drift monitoringSageMaker Clarify and Model Monitor closed to new customers on 30 July 2026, so use open-source libraries on either cloud. | Fairlearn and Evidently (open source) on SageMaker AI | Fairlearn and Evidently (open source) on Azure Machine Learning | Fairlearn and Evidently on Kubeflow |
| Opt-out registerChecked before every scoring run. An opted-out student is never scored, and still gets every normal form of support. | Amazon DynamoDB | Azure Cosmos DB | PostgreSQL |
| Workflow | AWS Step Functions | Fabric pipelines or Logic Apps | Temporal, or n8n |
| Middleware and events | Amazon EventBridge, SQS | Event Grid, Service Bus | Apache Kafka or RabbitMQ |
| Link to the case tool and student recordFlags arrive as tasks in the case tool tutors already use. Read-only from the student record. | API Gateway, plus your existing integration platform if you have one | API Management, plus your existing integration platform if you have one | Kong or your existing API gateway, plus your existing integration platform if you have one |
| Human reviewTutors see the flag, the reasons and the student's own engagement view in one place. | In the existing student support case tool | In the existing student support case tool | In the existing student support case tool |
| Identity, keys, data protectionRole-based access: a tutor sees only their own tutees. Disciplinary, progression and visa compliance roles have no access at all. | IAM Identity Center, KMS, Macie, Lake Formation | Entra ID, Key Vault, Purview | Keycloak or your existing Active Directory; OpenBao or HashiCorp Vault; an HSM |
| Monitoring and auditLog every flag, who saw it and what they did, so the follow-up rate and any misuse can be checked. | CloudWatch, CloudTrail | Azure Monitor, Log Analytics | Prometheus, Grafana, OpenTelemetry |
| UK data residencyThis is student data, some of it sensitive. Check the university's data policy before choosing an EU-hosted option. | eu-west-2 (London) | UK South / UK West | Your own UK data centre, or a UK or EU provider |
On a phone, the table shows the platform you pick. Sovereign / on-prem means open, portable components you can run in your own data centre or with a UK or European provider; IONOS is shown as one example, and others exist. What sovereign cloud means →
Many organisations keep core systems and sensitive data on their own servers. This is how the same design works across both.
Stays on-prem
The student record system, the student support case tool and timetabling stay where they are. So do any wellbeing, disability and counselling records, which are never connected to the model.
Uses cloud AI
The engagement data store, model training, nightly scoring and fairness monitoring run in a UK cloud region, or on the university's own Kubernetes platform for the sovereign option. Only the agreed engagement fields are sent, keyed by a pseudonymous student ID.
How they connect
Nightly extracts and the flag feed go through the API gateway over a private link (AWS Direct Connect or Azure ExpressRoute) or a site-to-site VPN. Flags come back as events into the case tool on campus.
If the link drops
Tutors and student support carry on exactly as they did before: attendance reports, tutorials and referrals. Scoring catches up on the next run. No support for a student depends on the model being available.
What each agent may do through its tools, what it may not, and where a person signs off. The limits are enforced by the platform, not the prompt.
Engagement model and routing
Where a person signs offA personal tutor or adviser decides whether and how to contact every flagged student, and records what happened. Any concern about a student's safety follows the university's wellbeing procedures, not the model. The model's permissions are enforced by the platform's identity and access controls, not by instructions in a prompt.
The student record and the case tool stay the systems of record. The model reads a nightly extract and writes only one thing: a task in the case tool. It never updates the student record.
Flags travel as events on a queue. If the case tool is down, flags wait and are delivered when it returns, each with an ID so nothing is created twice. A flag older than two weeks is dropped and re-scored, because stale flags send tutors after yesterday's problem.
Access is separated by design. The disciplinary, progression and visa compliance teams use their own processes and data, and the platform blocks them from the flags, reasons and scores.
The model can be paused at any point. Tutors still have their attendance and submission reports, and students still have every route to support.
Agree the purpose with students and staff, map the data sources, test data quality, and build a simple rules baseline from last year's data.
Gate · must be true to passPurpose statement agreed, DPIA and equality impact assessment started, students' union consulted, data access confirmed.
Two or three schools. Run the model in shadow first, then send flags to tutors, and compare with the rules baseline.
Gate · must be true to passBetter than the rules baseline, no group flagged or missed out of proportion, follow-up rate above target, DPO and equality sign-off.
Roll out to the pilot schools in full, with monitoring, support, the opt-out and a rollback plan.
Gate · must be true to passMonitoring live, tutor training done, privacy information published, fairness review group running.
Add schools one at a time, then postgraduate taught and part-time students, each with its own fairness check.
Gate · must be true to passEach new group passes the same fairness and follow-up gate.
| Activity | PVC Education | Director of student services | Solutions architectI can fill this | Technical PMI can fill this | Data scientists and engineersI can fill this | DPO | Equality lead | Students' union |
|---|---|---|---|---|---|---|---|---|
| Purpose and business case | Accountable | Responsible | Consulted | Consulted | Informed | Consulted | Consulted | Consulted |
| Target architecture and data flows | Informed | Consulted | Accountable and Responsible | Consulted | Consulted | Consulted | Informed | Informed |
| DPIA and privacy information | Accountable | Consulted | Consulted | Informed | Consulted | Responsible | Consulted | Consulted |
| Equality impact and fairness monitoring | Accountable | Consulted | Consulted | Informed | Responsible | Consulted | Responsible | Consulted |
| Model build and testing | Informed | Consulted | Accountable | Responsible | Responsible | Consulted | Consulted | Informed |
| Tutor training and follow-up process | Informed | Accountable and Responsible | Informed | Consulted | Informed | Consulted | Consulted | Consulted |
| Go-live decision | Accountable | Responsible | Consulted | Responsible | Consulted | Consulted | Consulted | Consulted |
| Run, monitor and improve | Informed | Accountable | Consulted | Consulted | Responsible | Consulted | Consulted | Informed |
R ResponsibleA AccountableC ConsultedI Informed· not involved
Option A
If there's no architect on the programme, I'd own the design end to end: the data flows from your VLE, attendance and student record, the model and its reasons, the access controls that keep it out of discipline and progression, and the gates. I'd work closely with your DPO, equality lead and student services, and report to your programme board.
Option B
If your planning team or partner already has an architect, I'd take on the data pipeline, the integration with your case tool and the access separation under their lead, and give them a second senior opinion on fairness monitoring, data protection and how the model is explained to students.
Goes wrong
The model learns that some groups log in less and flags them more, without anyone noticing.
How the design avoids it
Monitor flag and miss rates by group from the first week of the pilot, and drop features that act as proxies without a support reason.
Goes wrong
Flags go to tutors who have no time, so nothing happens and students are worse off for being watched.
How the design avoids it
Size the threshold to follow-up capacity, measure the follow-up rate, and route to student support where tutors can't.
Goes wrong
The score drifts into progression boards or attendance compliance.
How the design avoids it
A written purpose, access blocked by the platform for those roles, and a regular audit of who viewed flags.
Goes wrong
Students find out from a rumour, not from the university, and trust collapses.
How the design avoids it
Co-design with the students' union, clear privacy information, a student-facing view of their own data, and an easy opt-out.
Goes wrong
Health or wellbeing notes creep into the features because they predict well.
How the design avoids it
A fixed feature list agreed in the DPIA, change control, and special category data kept out of the pipeline entirely.
Changes already announced or under way that affect this design. More in the UK horizon scan.
Keep evidence of what the university does to support students, and its effect, in a form an assessment team could read. Report the effect of support honestly, not just the number of flags.
Keep the DPIA, the purpose statement, the reasons shown to tutors and the opt-out records ready to compare against the new code.
Keep visa engagement monitoring as its own process, so sponsor guidance changes never force changes to the support model.
If you operate in the EU, check whether the system is in scope, and keep the technical documentation and human oversight records the Act would need.
Good answers are specific. Vague answers to any of these are worth following up.
Whether you need someone to lead the design or to support the architect you already have, let's talk it through.
