The risks to a child.
Assessed, and published unfinished.

Aevum Teacher Manager processes the work, and sometimes the names, of children. Under UK GDPR a Data Protection Impact Assessment is required wherever processing is likely to be high risk, and the regulator names children's data and new technology as triggers. We engage both. So this is not a document we chose to write to look thorough. It is one the law requires, and the Department for Education expects it during development rather than at launch. Ours is late. We would rather publish it late than quietly not have one.

A teacher submits pupil work, planning material or curriculum context. The assistant returns drafts, marking decisions or reports. The teacher reviews and decides, and nothing reaches a class unreviewed. The personal data involved is pupils' work, any names appearing on it, and any SEND information a teacher chooses to supply. In a school deployment, all of it stays in the building. It does not travel to us. There is no central store of children's work at Aevum to breach, to lose, or to be compelled to hand over, because we never receive it. That is the configuration this assessment covers. The trial configuration runs the model on Aevum's own server and is scoped so that no pupil work reaches it.

Before anything reaches a model, an obfuscation step removes or replaces identifying information. The model sees the work, not the child. That ordering is enforced in code rather than promised in a policy, and no feature is allowed to reorder it. Separately, we do not use customer data to train, fine-tune or improve any product. That is a narrower claim than “we do not train”, and we make the narrower one because it is the true one: our models are trained on curated, licence-clean material before any school sees them, and whatever the software learns in your school stays in your school.

A child is mis-graded in a way that follows them.

Anything checkable is decided by computation, not by a model. The model is reserved for judgement, and a calibrated gate sends anything uncertain to the teacher, who remains the marker of record. The marking study that would put a number on this is running; we publish it when it completes. The measurement against human markers on real work does not exist yet, so the teacher's review is load-bearing rather than a formality.

Children's work leaves the school.

In a school deployment it is handled in the building, with no call out to us while it works, so the risk is answered by the architecture rather than by a promise about our conduct. In the trial the model runs on our server, so we answer the same risk by not sending pupils' work there at all: the features that read children's work are not in the trial.

Children's work ends up in a training set.

There is no route by which it could. We never receive it, and a licence firewall enforces in code what may enter any of our corpora.

The software's transcription silently corrects a pupil's mistake.

That would erase the evidence of what the child actually did, which is the thing a teacher needs. Checks on digit fidelity and crossings-out catch it, and uncertain pages go to a person. We rejected a version of the model that scored better precisely because it was correcting pupils' errors.

It works less well for some children than others.

We will answer this with evidence, not an estimate. The fairness audit is a commitment we have made in public, with SEND as its first axis rather than an afterthought, and the finding is published when it exists.

A teacher stops really checking.

Only genuinely uncertain decisions are routed for review, so the queue stays meaningful, and every decision shows its reason and the evidence behind it rather than a bare number.

If you ask us to delete your child’s data, deleting the records is easy. The harder question is what happens to a model that has already learned from them — because once software has learned from something, that learning is spread thinly across the whole model rather than sitting in a file you can delete. There is no reliable way, anywhere in this industry today, to reach into a trained model and remove one person’s influence. Researchers call it machine unlearning and it is an open problem, not a solved one. Any company telling you otherwise is describing something they cannot yet do.

So here is our position, and what we have actually done about it.

We treat a model that has learned from personal information as a kind of record in its own right, carrying the same obligations about access, retention and deletion as any other record. Most of this industry does not say that out loud.

Then we largely design the problem away. Your data stays in the building. We never receive your pupils’ work, and we never train our models on it — they are trained beforehand, on curated, licence-clean material. Anything the software learns from your school stays on your school’s own system. That means erasure is something you do, in the building, rather than a request you have to send us and hope we can honour.

And we test what is left. We run a standard privacy attack against our own models, the kind a researcher would use to ask whether a model can reveal what it was trained on. In our most recent round the attack performed no better than guesswork, and on the model trained on real children’s handwriting it identified nothing at all. That is not a deletion mechanism, and we will not dress it up as one. It is evidence that there is very little left in the model to delete.

What we still owe you is a mechanism, and an independent review of this judgement. Neither exists yet, which is why this section is here rather than tucked into a footnote.

Independent review of this assessment. A Data Processing Agreement your DPO can sign, which a solicitor will draft rather than us. Retention periods you configure and we document. The fairness audit. The red-team report. And consultation, which for a company that says nothing about disabled children without disabled people in the room should include teachers, a school's data protection officer, and children and families themselves. None of that is done. All of it is named here because a list of what is missing is more useful to you than a document that reads as though nothing is.

We assess the processing as proportionate for its purpose: the data stays in the building, a teacher decides every output, and none of it trains anything. The serious risks are answered by how the software is built rather than by how we promise to behave, which is the sturdier of the two. But this assessment is not signed off, and three things gate that: an independent review, the fairness audit, and a written answer to the question in section 05. Until those exist, this is an honest account of a system still being built, and it should be read as one.

Reviewed on every model change, policy change, mitigation or incident, and at minimum annually. Questions, or a request for the fuller working document, to hello@aevumfoundry.ai.