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 shared credit pool 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 deliberately minimal: 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. Once the marking session ends, nothing about the student work persists on our servers.

Data Handling — No Student Work Stored, Redaction Client-Side

For your data protection officer's review, the chain of custody for a piece of student work in GradeOrbit 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.

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 buying guide 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 and completes the onboarding flow — DPA acceptance, billing, and seat count — in a single sitting.

From that point, individual teachers self-register against the school using their own school-domain email address; the system checks the email domain matches the school's onboarded domain and joins the teacher to the school automatically. 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.

School Credit Pool + Signatory Onboarding

The commercial model is a shared credit pool funded by the school's monthly Stripe subscription. The signatory chooses a seat count and monthly credit allocation at onboarding; credits are drawn down by individual teachers as they mark, and the pool refreshes each billing cycle. There is no per-teacher invoicing, no expense-claim trail, and no individual card on file — finance gets one invoice per month against the school's account.

For larger schools or multi-academy trusts, the credit pool can be sized to cover the marking load of an entire department or year group's worth of mocks in a single allocation. The signatory dashboard shows credit consumption across the staff team, which department is using the most, and which week of term saw the biggest spike — useful for the head of computing presenting back to SLT on the year's digital-tools budget.

If the platform is being evaluated for a multi-site federation or trust deployment, our guide to AI marking software for multi-academy trusts covers the trust-level rollout pattern in detail — the same shared-pool model scales to seventy schools without changing the deployment story.

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 no-storage data model (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 the redaction step (client-side, burnt-in), and confirmation of the deployment model (signatory + domain-based teacher self-join). 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 no-storage student work model, and the shared credit pool 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 credit-pool sizing for your specific staff numbers before any commitment is made.