Does AI Detection Share Student Work with Third Parties?

When a teacher submits a piece of student work to an AI detection tool, the focus is almost always on the result: the likelihood score, the confidence label, the reasoning. What happens to the actual text in the moments between submission and result rarely gets the same attention. For most tools, that journey is more complicated - and involves more organisations - than the interface suggests.

Understanding data sharing is not a bureaucratic exercise. It is the practical question of whether the school's use of a particular detection tool is compatible with UK GDPR, whether students and parents have adequate disclosure about how their work is processed, and whether the school is in a defensible position if a complaint or incident occurs. The answers are often less reassuring than they appear.

What "Third Party" Actually Means for a Detection Tool

Under UK GDPR, when a school uses a third-party service to process personal data, that service acts as a data processor on the school's behalf. The school remains the data controller - meaning it is responsible for ensuring the processor handles data lawfully and securely. This relationship must be formalised in a Data Processing Agreement, and the school must be satisfied that the processor provides sufficient guarantees about data protection.

Where it gets complicated is that most detection tools are not simple one-organisation operations. Behind the interface a teacher uses sits a technology stack that typically involves multiple vendors. An AI detection tool might use OpenAI's API to power its language model analysis, Amazon Web Services or Google Cloud to host its infrastructure, and a third-party analytics service to monitor platform usage. Each of these organisations becomes a sub-processor: a data processor engaged by the initial processor to assist with processing the school's data.

This matters because the school's DPA with the detection tool does not automatically cover those sub-processors. If the detection tool's privacy policy lists OpenAI as a sub-processor but does not specify the data retention terms of that sub-processing arrangement, the school cannot verify that student work submitted through the tool is not retained by OpenAI for its own purposes. The tool's assurances about privacy only extend as far as its own practices - not the practices of every service it relies on.

Sub-Processors and Why They Matter

The sub-processor chain is where privacy risks become genuinely difficult to manage. A detection tool might have excellent data handling practices at its own level - no retention of submitted content, no training on submissions - while simultaneously routing that content through an AI API provider whose default terms do permit content retention for model improvement.

OpenAI's API, for example, operates under different terms depending on the tier and configuration. API users who have not specifically opted out of content logging, or who are not on a paid tier with zero-data-retention enabled, may find that submitted content is retained for up to thirty days for abuse monitoring purposes. Whether this applies in any specific detection tool's integration depends on exactly how that tool has configured its API access - and that configuration is almost never visible to the teacher making a submission.

The same complexity applies to other AI providers. A detection tool built on Claude's API operates under Anthropic's data handling terms, which may differ from OpenAI's. A tool using Google's language models operates under Google Cloud's terms. Each has a different set of default behaviours, different opt-out mechanisms, and different consequences for submitted content. Without disclosure of which AI backend a detection tool uses and what data handling terms apply, a teacher has no basis on which to assess the actual risk.

For UK schools, this matters particularly because of data residency. International data transfers - sending student data to a server outside the UK - require a lawful basis under UK GDPR Article 46. Many AI API providers process data in the United States by default. If a detection tool routes submitted student work through a US-based AI API without disclosing this as an international transfer, the school is likely in breach of its data transfer obligations without knowing it.

Questions to Ask Before You Submit Student Work

A responsible approach to any AI detection tool starts with a set of specific questions that the tool's documentation should be able to answer clearly. Vague reassurances about "taking privacy seriously" are not adequate - the questions are concrete, and so should be the answers.

Which sub-processors does the tool use? A GDPR-compliant service will list its sub-processors, either in its privacy policy or in a publicly accessible addendum. If this information is not available, the school cannot complete its due diligence.

Is there a Data Processing Agreement available for schools? The DPA should cover the tool's own practices and should identify sub-processors. It should not require the school to negotiate from scratch - a purpose-built educational tool will have a standard DPA ready to execute.

Where is data processed? For tools that use AI APIs, the relevant question is not just where the tool's own servers are located, but where the AI processing occurs. A tool hosted in the UK that routes text to a US-based AI API is still conducting an international data transfer.

Does the AI backend retain submitted content? This is distinct from whether the detection tool itself retains content. If the underlying AI model is provided by a third party, the school needs to know what that provider does with submitted data, not just what the detection tool does.

Is student work used for model training? Some detection tools use submitted content to improve their own detection models. Where this happens, it should be disclosed clearly, and it requires consent from students and parents as a distinct processing activity beyond what is necessary for the immediate detection purpose.

How GradeOrbit Handles Third-Party Processing

GradeOrbit was built specifically for UK secondary schools, and its approach to third-party data sharing is designed to be transparent rather than opaque.

Student work submitted for AI detection in GradeOrbit is processed using Google's Gemini API. GradeOrbit uses Google's paid Gemini service, whose terms rule out using customer content to train Google's models - submitted student work is processed to produce the result and is not used for model training. This is not a default consumer arrangement with Google; it is a specific API configuration with contractual data handling terms.

AI detection runs on school accounts, where pupils' work is held by GradeOrbit under the school's Data Processing Agreement and compared with their own earlier writing. It is sent to the Gemini API for processing, and the result - a score from 0 to 100 for how far the new work departs from the pupil's own writing, the confidence label, and the detailed reasoning - is returned and displayed. The work is wiped at the end of the school's retention window or at offboarding.

Because detection compares each pupil's new work with their own earlier work, that work is held with real names and is not redacted or anonymised - which is exactly why it sits under a signed DPA rather than being handled informally. Scans are removed when a run archives (90 days by default, and the school can set anything from 7 to 365 days), and pupil records follow the school's retention window and are wiped at offboarding. Individual teacher accounts, which are for marking only and do not include detection, work the opposite way: names are redacted in the browser before upload and uploaded work is never saved.

Detection results provide a full explanation alongside the score: a confidence label, the signals the model noticed, and a plain-English reasoning paragraph on how the new work compares with the pupil's own earlier writing. A likelihood score arrived at through an explained process is professionally more useful than an opaque percentage - and it is the difference between a result a teacher can act on and one they are simply asked to trust. Detection is included in every school teacher seat, with no per-check charge. For guidance on interpreting and acting on detection results, see our post on how to interpret AI detection scores.

Building a Consistent Policy in Your School

Individual teachers making good decisions about their own practice is helpful, but it is not the same as a school having a coherent, consistent approach to AI detection data handling. The risk of inconsistency is real: if different teachers in the same department are using different detection tools with different data handling standards, the school cannot make reliable representations about how student data is managed.

A school-level policy on AI detection tools should specify which tools are approved for use, confirm that each has a valid DPA in place, and document the sub-processor arrangements. This does not need to be a lengthy document - it needs to be clear about which tools are permitted and why others are not. The Records of Processing Activities that UK GDPR requires schools to maintain should include AI detection as a processing activity, identifying the tool used and its role as a data processor.

Staff training is also part of a consistent approach. Teachers who understand why data handling matters for detection tools - not just that there are rules, but what the actual risks are - are better placed to use permitted tools correctly and to question new tools before adopting them. For a broader framework for implementing detection across a school, our post on how schools can implement AI detection consistently covers the policy and process considerations in detail.

Try GradeOrbit's Transparent AI Detection

GradeOrbit gives UK schools AI detection with a clear data chain: submitted work processed by Google's paid Gemini service under no-training terms, held by GradeOrbit only under the school's Data Processing Agreement, and never used for model training. The sub-processing arrangement is not hidden in fine print - it is part of how the platform is designed and documented.

If you are currently using a detection tool and are not certain which AI provider processes submissions on its behalf, or whether that provider's data handling terms are compatible with your school's UK GDPR obligations, now is a good time to find out. The question is not whether detection is useful - it is - but whether the tool you are using is safe for the data it handles.

Start a free school trial and see how transparent, DPA-backed detection works for your school.