AI Marking Software for Heads of Computing and Digital Strategy

When the head of English brings a new AI marking software request to the senior leadership team, it usually lands on the head of computing's desk for a technical sign-off before approval. The teaching case is clear - marking workload is the single biggest driver of attrition in UK secondary schools - but the head of computing's job is to make sure that whatever lands on staff laptops is secure, sensible to deploy, and not going to create a data-protection problem six months later.

This post is for the head of computing, digital strategy lead, or IT manager who has been asked to evaluate GradeOrbit before a department or school-wide deployment. It covers the data-handling model, the deployment story across departments without per-teacher admin overhead, the per-teacher pricing that keeps central finance happy, and the signatory onboarding flow that gets you from "we are evaluating" to "marking criteria live across every department" without a procurement saga.

What Heads of Computing Get Asked to Vet

Three questions come up every time a new SaaS product is proposed for staff use: where does the student data go, who can see it, and what does it take to roll out across a department or the whole staff team. For AI marking specifically, a fourth question follows close behind: which AI model is the work being sent to, and what is the vendor's contract with that model provider.

GradeOrbit is built by a UK sole trader registered with the ICO and serving UK teachers only. The data-protection answer is short because the data-handling model is split cleanly by account type. On individual teacher accounts, no student work is ever stored on GradeOrbit's database or any other service. The pipeline is upload → client-side redaction → AI inference → results back to the teacher's browser, and nothing about the student work persists once the session ends. On a school account, pupils' work is stored under the school's Data Processing Agreement so staff can return to it, with scans removed when a marking run archives (90 days by default) and pupil records wiped at the end of the school's retention window or at offboarding.

Data Handling - Nothing Stored on Individual Accounts, DPA-Bound on School Accounts

For your data protection officer's review, the chain of custody for a piece of student work on an individual teacher account looks like this. The teacher uploads or scans the work into the browser. Before any AI processing, the teacher draws black boxes over names, candidate numbers, and any other PII visible on the image - the redaction is burnt into the pixels client-side via the Canvas API, not stored as a separate overlay. Only the redacted image is sent to Google Gemini for inference. Students are anonymised internally as "Student 1", "Student 2", etc. - no real names ever reach the AI processing layer. School accounts work the other way round: pupils' work is held under the school's DPA with real names, without redaction, so results (including AI detection, which compares new work with a pupil's own earlier work on file) can be linked to each pupil.

The AI provider is Google Gemini, served via Google Cloud's UK and EU regions. Google's terms for the Gemini API explicitly state that data sent via API is not used to train Google's models. The contract with Google is held by GradeOrbit, not by your school - which means your DPIA does not need to enumerate Google as a separate sub-processor of your school's data, only GradeOrbit's. For a deeper walk-through of the data-protection story, our SLT guide to AI marking software covers the contract questions in detail.

For schools that want a formal Data Processing Agreement on file, the school tier includes a DPA signed by the signatory during onboarding - this is the legal artefact your DPO will want before approving the platform for general staff use.

Deployment Across Departments Without Per-Teacher Admin

A common objection to new SaaS tools in schools is "who is going to provision sixty staff accounts and reset their passwords?" GradeOrbit's school deployment model avoids that overhead entirely. The school signatory (usually a headteacher, deputy head, or business manager) signs up on a school email address, signs the Data Processing Agreement, and starts a 30-day free trial with no card needed. Seat count and start date are chosen when the trial ends, with no automatic charge until the school confirms.

From that point, the signatory invites teachers by email; invites go to addresses on the school's own domain, and each teacher accepts and signs in with their school email. There is no per-teacher provisioning step on the IT department's side. The head of computing's involvement after onboarding is essentially zero - which is exactly what you want from a tool that is going to be used by sixty or eighty teachers across English, History, Sociology, Sciences, MFL, and the rest.

One Price per Teacher + Signatory Onboarding

The commercial model is one flat price per teacher, billed annually, with unlimited marking and unlimited AI detection included in every seat. There are no credits to buy, pool or top up, and no per-script or per-check charge. There is no per-teacher invoicing, no expense-claim trail, and no individual card on file - finance gets one annual invoice against the school's account.

Because the cost depends only on the number of teachers, it is fixed and known before the year starts. A department marking a full year group's worth of mocks in one week costs nothing extra - useful for the head of computing presenting back to SLT on the year's digital-tools budget, where the line does not move with usage.

If the platform is being evaluated for a wider federation or trust deployment, the SLT guide above covers the rollout pattern in detail.

What the Evaluation Process Looks Like

For a typical secondary school, the evaluation cycle is: one head of department running a small pilot on personal credits (Solo tier, no commitment), then a pitch to SLT once the workload-saving evidence is in, then the head of computing's technical sign-off, then the signatory onboarding flow. The whole sequence usually takes two to four weeks elapsed, with the technical sign-off being the smallest piece of the work - there is nothing to install, nothing to integrate, and no SSO configuration to wrangle.

Your evaluation checklist should include: confirmation of the data model for each account type, including the school retention window (covered above), confirmation of the AI sub-processor and its terms (Google Gemini, no training use), confirmation of the DPA on file (issued during signatory onboarding), confirmation of how pupil work is held on the school account (under the DPA, with real names and no redaction, unlike individual accounts), and confirmation of the deployment model (signatory + email invites on the school's domain). All five are documented in the onboarding flow.

Talk to Us About GradeOrbit for Your School

GradeOrbit is built for UK secondary schools that want to give every teacher access to consistent, mark-scheme-driven AI marking and AI detection without inheriting a data-protection problem in the process. The signatory onboarding flow, the DPA-backed, time-limited handling of student work, and one price per teacher with unlimited use are designed specifically for the way schools procure and operate digital tools.

If you are evaluating GradeOrbit for a department, a school, or a trust, head to the homepage to read the institutional documentation and get in touch - we are happy to walk through the data-protection model, the deployment story, and the seat count for your specific staff numbers before any commitment is made.