What Happens to Student Work After AI Marks It?
The appeal of AI marking is the result: a structured set of marks, categorised feedback, and exam board alignment returned in seconds rather than hours. Teachers who have spent Sunday evenings working through a class set of GCSE essays know what that time saving means in practice. But the question most teachers never think to ask is what happens to the student's work in the time between submission and result — and what remains of it after.
For some AI marking tools, the answer is straightforward: the work is processed, the result is returned, and the submission is discarded. For others, the answer is considerably more complicated, and the implications for schools operating under UK GDPR are significant. The difference is not always visible from the product's marketing copy — it requires reading the privacy policy, the terms of service, and ideally a Data Processing Agreement with enough specificity to be meaningful.
Retention vs. Deletion — A Critical Distinction
When an AI marking tool says it does not "store" submitted work, that statement can mean several different things, and the differences matter.
The clearest form of privacy protection is genuine deletion: the submitted content is processed by the AI model to generate an output, and then discarded. Nothing is written to a database, no copy is retained in a log, and no record of the original submission persists beyond the session. This is the standard that meaningfully protects student data.
A weaker form of protection is time-limited retention. Some tools retain submitted content for a defined period — seven days, thirty days — for purposes such as dispute resolution, abuse monitoring, or technical debugging. During that window, the data exists on the provider's servers and is subject to whatever security controls apply. A data breach during the retention period would expose the submission. For schools, even short-term retention creates obligations around disclosure, breach notification, and Records of Processing Activities that may not have been considered when the tool was adopted.
A third category is implicit retention through logging. Many tools do not intentionally retain submitted content, but their infrastructure generates logs — access logs, API call logs, error logs — that may capture fragments of submitted text as a side effect of standard technical operations. Whether these logs constitute "storage" is a question few tools address in their privacy documentation, and their existence can complicate the picture significantly.
Finally, there is retention for model training. Some AI marking tools use submitted student work to improve their detection or marking models. This is a qualitatively different kind of retention — not incidental, not time-limited, but purposeful and potentially permanent. Under UK GDPR, using personal data for model training is a secondary purpose that requires either explicit consent or a legitimate interest assessment that balances the tool provider's interests against the data subjects' rights. For student data, this is a high bar that most tools using submitted content for training have not met.
The Problem With AI Marking Tools That Don't Disclose Their Backends
A significant share of AI marking tools available to UK teachers are built on top of third-party AI APIs — most commonly from OpenAI, Anthropic, or Google. The tool provides the interface, the mark scheme logic, and the formatting of results; the actual language model work is performed by an AI provider operating as a sub-processor.
Whether student work is retained by that AI provider depends on the specific API configuration the tool has negotiated. OpenAI's API, for instance, offers a zero-data-retention option for eligible customers, under which submitted content is not stored after processing. But this is not the default for all API tiers, and not all EdTech tools using OpenAI's API have enabled it. If a teacher submits a student's essay to a marking tool that uses OpenAI's API without a zero-retention agreement in place, that essay may be retained by OpenAI for up to thirty days for abuse monitoring — regardless of what the marking tool's own privacy policy says about not storing student data.
The problem is compounded by the fact that most AI marking tools do not disclose which AI provider they use. A product that describes itself as using "advanced AI" or "proprietary language models" without identifying the underlying provider makes it impossible for a school to assess the actual data handling chain. UK GDPR requires schools to identify sub-processors in their Data Processing Agreements and to verify that sub-processing arrangements provide adequate data protection guarantees. A tool that obscures its AI backend makes this verification impossible.
What UK GDPR Requires of Schools Using AI Marking Tools
Schools using AI marking tools are data controllers, and the tools they use are data processors. This relationship creates specific legal requirements that apply regardless of whether individual teachers are aware of them.
A Data Processing Agreement is required before student data is shared with any third-party processor. The DPA must specify the subject matter, duration, and purpose of the processing; the nature and categories of personal data involved; and the obligations and rights of the data controller. For AI marking tools, this means the DPA should address what happens to submitted content, which sub-processors are used, and what data handling standards those sub-processors maintain.
Records of Processing Activities under UK GDPR Article 30 require schools to document each processing activity, including the categories of data, the purposes of processing, any international transfers, and the retention periods. Using an AI marking tool is a processing activity that should appear in the school's ROPA. If it does not, the school is not in compliance — regardless of whether the tool itself is operating lawfully.
The right to erasure is a further consideration. Students and parents can request deletion of personal data. If a marking tool retains student submissions — even for a short period — the school must be able to facilitate erasure requests that extend to the processor's records. A tool with no retention mechanism makes this straightforward. A tool with even temporary retention creates an obligation to verify that the processor can action erasure requests within the timeframes UK GDPR requires.
These are not hypothetical concerns for an enforcement scenario. They are the baseline of responsible data handling that the school's data protection officer — or the senior leader with data protection responsibility — should be satisfied about before any tool is approved for use with student data. Exam boards including AQA, Edexcel, and OCR have their own guidance on the use of third-party tools in the marking and assessment process, and schools using AI tools in ways not sanctioned by those bodies take on additional professional risk beyond GDPR.
How GradeOrbit Approaches Data After Marking
GradeOrbit was designed for UK secondary teachers, and its data handling after marking reflects a deliberate architectural choice rather than a policy aspiration.
Student work submitted to GradeOrbit for marking is processed using Google's Gemini API under a zero-data-retention configuration. Submitted content is sent to the Gemini model, the marking result is generated, and the submission is discarded. There is no retention period, no logging of submission content, and no use of student work for model training — by GradeOrbit or by the underlying AI provider.
GradeOrbit does not maintain a database of student submissions. The marks and feedback generated are returned to the teacher and displayed in the marking interface, but the original submitted content is not stored. If a teacher marks a class set of thirty essays, thirty results are returned — and thirty original submissions are gone. There is nothing in GradeOrbit's system to erase, because there is nothing retained.
For work containing identifying information, the client-side redaction tool allows teachers to black out student names, class details, or any other identifiable content before submission. The redaction happens in the browser; the AI model receives only the redacted version. Teachers marking AQA, Edexcel, or OCR work across GCSE and A-Level qualifications can specify the exam board, qualification level, and mark scheme, and GradeOrbit applies the relevant assessment objectives and level descriptors accordingly. The result includes marks at each criterion level, categorised feedback, and an overall grade — all in a format designed for teacher review before any feedback reaches students.
Physical paper scanning is supported via QR code: teachers photograph exam scripts with a mobile device, the image is transferred to the marking interface, processed, and discarded. There is no intermediate storage of scanned images on GradeOrbit's servers. For teachers working with handwritten work — the majority of GCSE and A-Level submissions — this means the most privacy-sensitive format is handled with the same zero-retention approach as typed submissions. For more on integrating this into a marking workflow, see our post on how to use AI marking for handwritten student work.
Reducing Workload Without Storing Data
The workload case for AI marking is well established. The Department for Education's teacher workload surveys have consistently identified marking as among the most time-intensive elements of the job, with secondary teachers spending significant hours each week on feedback that could be supported by technology. For a teacher marking 120 GCSE students across four classes, the difference between a tool that handles the mechanical application of mark scheme descriptors and one that requires reading and annotating every script manually is measured in hours per week.
What is less often acknowledged is that the workload benefit only materialises if the tool can actually be used — and a tool with inadequate data handling cannot be used responsibly with student data. A marking tool that saves two hours per class set but creates a GDPR compliance gap, an undisclosed international data transfer, or a sub-processing arrangement that retains student essays, is not a net time saving when the data protection implications are taken into account.
The decision is not between convenience and compliance. A tool built for UK schools — with zero retention, disclosed sub-processors, and a DPA available for schools — provides the same workload benefit without the compliance risk. The question for any school evaluating an AI marking tool is not just whether it marks well, but whether it handles the data it processes in a way the school can stand behind.
Try GradeOrbit's Privacy-First AI Marking
GradeOrbit gives UK secondary teachers AI-assisted marking aligned to AQA, Edexcel, and OCR mark schemes — with a data handling model built for schools rather than adapted from a consumer product. Student work is never stored. Sub-processing is handled through a zero-retention Gemini API configuration. Client-side redaction removes identifying content before any data leaves the device.
If you are using an AI marking tool and are not certain what happens to student submissions after the result is returned, the privacy policy and sub-processor documentation are the right places to start. If those documents do not give you a clear answer, the answer is probably not what you would want it to be.
Create your free GradeOrbit account and mark your first class set with confidence today.