How to use this document
The DPIA obligation belongs to the school as controller, not to us. We cannot discharge it for you. What we can do is give you a complete and honest account of what the system does and what we assessed, so that your own DPIA is a review rather than an investigation.
1. Why a DPIA is needed
1.1. The ICO expects a DPIA where processing involves the data of children or other vulnerable people, or the use of innovative technology. Report Alchemy involves both: nearly every data subject is a child, and report text is drafted by a large language model.
1.2. It is worth being equally clear about what does not apply. There is no automated decision-making with legal or similarly significant effects (Article 22): the system produces draft prose, and a teacher decides what is sent. There is no systematic monitoring of a publicly accessible area, no matching or combining of datasets, no processing to deny a service, and no special category or criminal offence data.
2. The processing described
2.1. A teacher creates a report format, usually by pasting in a report they have already written so the system can copy its structure. They then enter a pupil's first name and short notes — attainment, effort, behaviour, next steps. Those notes are sent to an AI provider, which returns prose in the school's format. The teacher reads, edits and uses it.
2.2. The pupil's record is retained so that the next report can take account of the last, if the teacher chooses. Records are grouped into classes so a whole class can be written in one sitting.
2.3. Data flows: teacher's browser → our application (Google Cloud, London) → OpenAI API (United States) → our application → teacher's browser. Storage is in London throughout. The full inventory, with retention per category, is in §2 of the data protection overview.
2.4. Scale: at the time of writing, a small number of UK schools and individual teachers. A single teacher writing a full class produces roughly 30 pupil records per year group per year.
3. Necessity and proportionality
3.1. Lawful basis. For a school, the processing is normally necessary for the performance of a task carried out in the public interest (Article 6(1)(e)) — reporting to parents is a statutory duty in maintained schools — or, for independent schools, legitimate interests or contract. The school determines and records its own basis; we do not purport to choose it.
3.2. Necessity. Written reports must be produced regardless. The processing here replaces hours of drafting, not the professional judgement behind it. The alternative — a teacher typing the same observations into a general-purpose chatbot — involves the same transfer with none of the controls, and is what actually happens when schools have no sanctioned tool.
3.3. Data minimisation. The product asks for a first name and nothing else identifying. There is no field for a surname, date of birth, UPN, address, photograph, attendance or SEN record. This is a design decision, not a policy statement, and it caps the harm of any breach: a first name plus a teacher's comment is a low-identifiability record outside the school's own context.
3.4. Purpose limitation. The processing agreement forbids using pupil data for model training, marketing, profiling or any purpose beyond producing the school's reports.
4. Risks identified and what was done
4.1. Risks are scored for likelihood and severity of harm to the child, after the mitigations described.
| Risk | Mitigation | Residual |
|---|---|---|
| Pupil names transferred to a US AI provider. A name plus a comment about a child's behaviour leaves the UK. | Standard Contractual Clauses with the UK Addendum, and content submitted via the API is not used for model training. More substantially, pseudonymised generation removes the name from the transfer entirely, and it is available to every account at no cost. We recommend schools enable it. | Low with pseudonymisation on, Medium without |
| The model asserts something untrue about a child — an achievement, difficulty or incident the teacher never wrote — and it reaches a parent. | This is the principal risk and it is inherent to the technology. The prompt forbids inference beyond the notes supplied; an automated check scores every draft for unsupported content and regenerates up to three times; a measured test set is run against the model before any change to the prompt or model ships, and a change that increased invention has already been rejected on that evidence. Ultimately the teacher reads and owns every word. The product never sends anything to anyone. | Medium |
| Excessive data entered in free text. Nothing technically stops a teacher typing a safeguarding disclosure or medical detail into a notes box. | No field invites it, and guidance in the product and this documentation says first names and academic observations only. Schools should include Report Alchemy in their normal staff guidance on what goes into third-party tools. We do not scan free text, because scanning it would itself be more intrusive. | Medium |
| Data kept indefinitely. Persistent pupil records are what make the product useful and are also how a database of children quietly accumulates for years. | Automatic deletion on a retention period the school sets, defaulting to 24 months from the last time a pupil was written about, with an end-of-academic-year option. Writing about a pupil restarts their clock; silence deletes them. Per-pupil deletion dates can be set, and immediate erasure is one click. | Low |
| A name in a pasted example report. The format-learning feature works from a real past report, which may name a different child. | Pseudonymised generation also scrubs names in the example report where they match a pupil on that teacher's list. The limitation — a name we have never seen cannot be recognised — is documented rather than glossed over, and teachers are advised to replace the name in an example with a placeholder. | Medium |
| Account compromise exposes a teacher's whole class. | Google sign-in only, so there is no password for us to leak and account security inherits the school's own Google controls, including any MFA the school enforces. Sessions are server-side and revocable. Data is scoped per account in every query. | Low |
| Breach of the hosted database. | Managed Cloud SQL in London, encrypted at rest, no authorised public network, unencrypted connections refused, access limited to named accounts. Breach notification to the school within 24 hours. The limited data model means a breach exposes first names and teacher comments, not a full pupil profile. | Low |
| Supplier failure. A one-person company holding school data. | Data is exportable in full at any time, in one click, without asking us. Nothing is locked in a proprietary format. This is stated rather than hidden because it is a fair question to ask of any small supplier. | Medium |
| Children have no practical way to object to processing they are unaware of. | The school remains responsible for its privacy notice to pupils and parents; we give it the material to describe this processing accurately, including this page. A parental erasure request can be actioned by the class teacher immediately, without a request to us and without a waiting period. | Low |
5. Conclusion
5.1. With the mitigations above, the residual risk is judged acceptable, and no prior consultation with the Information Commissioner is considered necessary under Article 36.
5.2. Two risks are deliberately recorded as medium rather than argued down. The first is factual invention by the model, which no amount of prompting eliminates and which is managed by measurement and by keeping a teacher between the draft and the parent. The second is what a teacher chooses to type into a free-text box, which is a matter of school guidance rather than something a supplier can engineer away.
5.3. The single most effective control available to a school is pseudonymised generation. It moves the transfer risk from medium to low at no cost and no loss of quality, and we would encourage any school to make it standard.
6. Review
6.1. This assessment is reviewed at least annually, and immediately on: a change of AI provider or model family, a new sub-processor handling pupil data, any change to the categories of data collected, or any personal data breach.
6.2. Questions, challenges and corrections are genuinely welcome at admin@report-alchemy.com. If your DPO disagrees with a scoring here, we would rather hear it than not.