Data protection

Report Alchemy processes children's personal data on behalf of schools. This page is the whole picture in one place: who is responsible for what, exactly what we hold and where, how long we keep it, and the agreement your school can sign.

Last updated: 29 October 2026Sagwa Limited (Report Alchemy)Hosted in the UK; reports written by OpenAI in the US

The short version

If you only read one section, read this one.

  • The pupil forms ask for a name, and a first name is enough. There is no separate field for a surname, and no date of birth, address, UPN, photograph or contact detail is requested anywhere in the product. There is no file upload.
  • The application and its database are hosted in Google Cloud's London region (europe-west2).
  • Report text is generated by OpenAI in the United States under Standard Contractual Clauses with the UK Addendum. Content sent through the API is not used to train their models.
  • Name replacement, which is pseudonymisation in UK GDPR terms, is on for every account by default. A teacher can switch it off for their own account; accepting the DPA switches it back on. With it on, the names of pupils the teacher has added are replaced with a code before anything is sent for generation, and put back on our servers afterwards. Names we have not been told about, such as a child named in a pasted example report, are not detected. See §4.4.
  • Each account sets a retention period for pupil records, defaulting to 24 months after a pupil was last written about. Automatic deletion is currently switched off. See §5.2.
  • Any teacher can erase one pupil, download a copy of everything we hold on their account, or delete the account entirely, from inside the product, without contacting us.
  • We do not sell data, show advertising to pupils, profile children, or make automated decisions with legal or similarly significant effects.

1. Who is responsible for what

1.1. Where a school buys or authorises Report Alchemy, the school is the data controller and Sagwa Limited is a data processor acting on the school's documented instructions. Those instructions are the ones set out in the Data Processing Agreement.

1.2. Where an individual teacher signs up with a personal account and enters pupil data, the school remains the controller of that pupil data. The teacher is responsible for having their school's authorisation to use a third-party tool for this purpose. Our terms require it, and sign-up, by email or by Google, asks the teacher to confirm it.

1.3. For the teacher's own account data, meaning their name, email address, billing record and usage, Sagwa Limited is the controller. That processing is described in the Privacy Policy.

2. What we hold

2.1. The table below is exhaustive for pupil data. It is short because the product deliberately collects very little.

CategoryWhat it isWhy we hold itRetention
Pupil identifier A name, as typed by the teacher; the form asks for a first name. Optionally pronouns and a year group. So the report is written about the right child, and so the next report can build on the last. Account retention period, by default 24 months from last use. See §5.2 on enforcement.
Teacher's notes Free text the teacher types into the report form, such as attainment, effort, behaviour and next steps. It is the input the report is written from. Same as the pupil record
Standing notes Optional context a teacher records once, such as "EAL, joined in Year 4". So it does not have to be retyped each term. Same as the pupil record
Generated reports The report text produced for that pupil, and any refined versions. So the teacher can retrieve their work and carry it into the next report. Same as the pupil record
AI suggestions Suggested wording for a report section, generated from the teacher's notes when the teacher asks for suggestions. So the teacher can pick up or adapt a suggested phrase. Same as the pupil record
Parents' evening notes Short talking points for a parents' evening appointment, generated from the pupil's report or the teacher's notes. So the teacher has a crib sheet for the meeting. They are kept apart from report history, so a new report is never written from them. Same as the pupil record
Class groupings A class name a teacher chooses, such as "Year 4 Oak", and which pupils are in it. So a whole class can be written in one sitting. Same as the pupil record
Report formats The structure of the school's report, usually derived from an existing report the teacher pastes in. So generated reports match the school's own house style. Until deleted by the teacher

2.2. A caution about example reports. The most powerful feature in Report Alchemy learns your format from a report you have already written. If you paste in a real past report, it will contain whatever that report contained, including a child's name. It is stored as your format's example and is sent with each generation. If that matters to you, replace the name in the example with a placeholder before saving it. The format is copied from the report's structure, which does not need the name.

2.3. We do not request, and the product provides no field for: surnames, dates of birth, addresses, contact details, UPNs or other pupil identifiers, SEN or medical records, photographs, attendance data, or safeguarding records. A teacher could of course type such things into a free-text notes box; nothing prompts them to and we recommend they do not.

3. Where it is processed

3.1. The application, the database and all stored report content are hosted on Google Cloud Platform in the London region (europe-west2).

3.2. Generating a report requires sending the teacher's notes to an AI provider. That provider is OpenAI, L.L.C., in the United States. The transfer relies on Standard Contractual Clauses together with the UK International Data Transfer Addendum. Content submitted through OpenAI's API is not used to train their models.

3.3. The full sub-processor list, including payment and sign-in providers, with the data each receives and where, is maintained at Privacy Policy §4.5. We will give 30 days' notice before adding or replacing a sub-processor that processes pupil data, and a school may object.

3.4. We do not claim that pupil data never leaves the UK. Some competitors do. For that claim to be true of an AI report writer, generation itself must happen on UK infrastructure, which is not the case here. Name replacement is our answer to the same concern. It is on for every account by default, and replaces the names of pupils the teacher has added with a code before the request leaves our servers. Its limits are set out in §4.4.

4. Name replacement

4.1. This is on for every account by default, new and existing, since 23 September 2026. A teacher can switch it off for their own account, under Account, Data and privacy. In UK GDPR terms it is a form of pseudonymisation, and section 4.4 sets out what it does not cover. With it off, pupils' names are sent to OpenAI with the notes. Accepting the DPA switches it back on for that account. A change applies immediately to every generation afterwards.

4.2. With it on, before anything is sent to OpenAI we replace the pupil's name, and each part of it if it is more than one word, with a code such as "Pupil A", together with the names of the teacher's other saved pupils wherever they appear. This applies to:

  • the name field itself;
  • the teacher's notes for that report;
  • the example report attached to the format;
  • any previous reports used for continuity; and
  • requests for AI suggestions, for refining a report and for parents' evening notes.

4.3. The generated text comes back naming "Pupil A", and the real name is substituted back in on our servers before the teacher sees it. The finished report reads exactly as it would have. The prompt we retain for audit holds the placeholder, not the name.

4.4. What it does not cover. Free text is free text. The setting replaces the names of pupils the teacher has added to their account; it cannot recognise a name it has never been told about. A child named inside an example report a teacher pastes in, or a different child named in a notes box who is not on the teacher's pupil list, will not be detected. Teachers should remove those names before pasting. Names that are also everyday words, such as Will, May and Grace, are replaced only where they are written with a capital letter, so that “he will improve” is not mistaken for a child; initials on their own are not replaced. The free report generator, which needs no account, replaces no names, because it has no list of pupils to work from; its page says so before anyone types.

5. Retention and deletion

5.1. Every account sets a retention period covering pupil records, teachers' notes and generated reports. The options are 12, 24 or 36 months from the last time a pupil was written about, or the end of each academic year (31 August). The default is 24 months. Writing a new report about a pupil restarts their clock: a child a teacher still teaches is live data, a child not mentioned for two years is not.

5.2. Automatic deletion is currently switched off

The retention period above is the schedule we work to, and we apply it on request. Nothing is deleted automatically when it expires. We decided not to run an unsupervised job that irreversibly deletes schools' records while the product is this new.

What this does not change: erasure on request is immediate and complete, and a teacher can do it themselves without contacting us (see §6). A school can also instruct us in writing to clear everything past its retention period, and we will do so within 30 days.

5.3. Deletion, whenever it happens, removes the pupil record, every report generated for them, the teacher's notes behind those reports and any saved AI suggestions. It is immediate and irreversible. There is no soft-delete or recycle bin.

5.4. A school can require a shorter period than the teacher has set, or a specific deletion date for a specific child, by writing to contact@report-alchemy.com, and we will do so within 30 days. A teacher can delete any pupil immediately at any time.

5.5. When automatic enforcement is switched on, existing accounts will be given at least 30 days' notice first, and this page will say so on the day it changes rather than afterwards.

5.6. Our hosting provider keeps seven automated daily backups of the database, so an erased record can survive in a backup for up to a week before ageing out. Backups are encrypted, are not reachable from the product, and are never used to restore an individual record.

6. Individual rights and requests

6.1. A parent asks the school to delete their child's data. The teacher can do it themselves, immediately, from Pupils. They are shown exactly what will be removed before confirming. No request to us and no waiting period.

6.2. A subject access request. A teacher can download everything held on their account as a single JSON file, from inside the product. If a school needs this collated across several teachers, write to contact@report-alchemy.com. We respond within one month, the legal limit, and usually within 5 working days.

6.3. Rectification. Pupil names, pronouns, year groups and notes are editable, and duplicate records for the same child can be merged.

6.4. We will notify the school without undue delay, and in any case within 24 hours of becoming aware, of any personal data breach affecting their data, with the detail required for the school to meet its own 72-hour obligation.

7. Security

7.1. What is in place:

  • All traffic is served over TLS. Plain HTTP is redirected, and we send Strict-Transport-Security with a one-year max-age so a browser will not try HTTP again.
  • Teachers sign in with Google or with an email address and password. Passwords are never stored. Only a salted scrypt hash is kept, and it cannot be turned back into the password. An email address must be confirmed before its account can be used, ten wrong passwords pause the account for 15 minutes, reset links expire after an hour and work once, and the session is renewed at every sign-in.
  • Sessions are server-side: the browser cookie is an opaque identifier pointing at a row in our database, not a payload of user data.
  • The database is a managed Cloud SQL instance in London, encrypted at rest. No public network is authorised to connect to it, and the instance accepts encrypted connections only.
  • Access to production is limited to named Google accounts belonging to the company's operator; there are no shared logins and no third-party contractors.
  • Report data is scoped to the account that created it in every query; there is no cross-account view.

7.2. What is not in place: Report Alchemy is a small company and holds no ISO 27001 or Cyber Essentials certification, has not commissioned an external penetration test, and does not offer a bespoke security schedule. If your procurement requires any of these, we would rather tell you now than at the end of a term's trial.

7.3. There is no advertising in the product, no third-party tracking of pupil data, and no pupil-facing surface at all. Children never log in and never see the product.

8. The AI, and what it does not do

8.1. Report Alchemy drafts text from notes a teacher has already written. It does not score, rank, predict or profile children, and it makes no decision about a child. The teacher writes the notes, reads the draft, edits it and decides what goes to parents.

8.2. There is therefore no automated decision-making producing legal or similarly significant effects under Article 22 UK GDPR, and no special category data is required by the product.

8.3. Generated text can be wrong. Our own testing measures how often the model asserts something the teacher did not write, and the product is designed around the assumption that a teacher reads every word before it leaves them. The DPIA treats this as the principal risk and sets out the mitigations.

9. Getting an agreement in place

9.1. Our Article 28 Data Processing Agreement is published in full and can be accepted online by someone authorised to bind the school. Acceptance is recorded with the signatory's name, role, organisation and timestamp, and both parties are bound by it from that moment.

9.2. If your school requires its own paper, send it to contact@report-alchemy.com. We will review and sign a standard local-authority or MAT processor agreement.

10. Contact

Data protection enquiries are handled by the company's director. The law does not require us to appoint a Data Protection Officer, because our core activities involve neither large-scale monitoring of people nor large-scale special category data. We respond within one month, the legal limit, and usually within 5 working days.

If you are not satisfied with how we have handled a data protection matter, you can complain to the Information Commissioner's Office at ico.org.uk.