Data Protection Impact Assessment — Public Summary — physmat.org

This is a plain-language public summary of our Data Protection Impact Assessment (DPIA) for physmat.org. It is not the full DPIA. The full DPIA is a separate, detailed internal document — the regulator-facing artefact — that records the processing, the risks to children, the mitigations and the residual-risk decision in full, and that must be reviewed and signed by a qualified Data Protection Officer / solicitor before any reliance is placed on it. This summary is written to be read alongside our Privacy Policy, our AI Tutor Notice (see §5) and our Safeguarding Statement.

This service is offered in the United Kingdom. It is not offered in the United States at this time, and we do not target US users.

1. What this is, and what it is not

• This is a public, readable summary of the impact assessment we carried out for the way physmat.org processes children's personal data.
• This is not the full DPIA. The full DPIA is a separate artefact; it is the document a regulator would expect to see, and it is signed off by a qualified DPO/solicitor.
• Nothing here is a guarantee of compliance or a legal determination. Points that depend on a qualified legal judgement are marked; points that depend on a part of the system we are still building are marked; entity and figure placeholders are marked to be confirmed.

2. What processing was assessed

The DPIA assesses the personal-data processing involved in running physmat.org for children, and in particular the higher-risk parts:

• Child accounts — sign-in identity held in Amazon Cognito (email, account id) and account/learning data held in our database (name, date of birth, year group, parent email, school association, answers and practice activity, consent records).
• The optional AI tutor — an opt-in, paid (entitlement-gated) add-on with its own lawful basis; a child can use the whole problem bank without it. When used, a child types free text; a limited, pseudonymous payload is sent to an AI model to generate a hint or explanation, and the conversation is stored in the child's own account.
• Adaptive practice (the "picker") — an off-by-default feature that, when turned on, selects problems by difficulty from the child's own past activity, with no profile row stored.
• Parent / teacher / school visibility — which adults can see a child's activity, and on what basis.
• Payments — paid access via Stripe; we store only Stripe identifiers and subscription status, never card data.

Our role depends on how a child joins: in the school-provisioned flow the school is the data controller and we act as its processor under an Art. 28 agreement; in the consumer (parent) flow we are the controller.

3. Why a DPIA is required

A DPIA is required where processing is likely to result in a high risk to people's rights and freedoms. This platform combines three factors the ICO treats as high-risk:

• it processes the data of children, a vulnerable group given heightened protection under the ICO's Age Appropriate Design Code (Children's Code);
• it involves profiling / automated selection of content for children (the adaptive picker); and
• it uses a large language model (LLM) to process a child's free-text input (the AI tutor).

On that combination, carrying out a DPIA is treated as mandatory, not optional.

4. Key risks to children we considered

The DPIA identifies the main risks to children. In summary:

• Disclosure through the tutor's free text — including safeguarding. The tutor is the one place a child types in their own words, so it is the place a child might disclose that they are not safe. A risk disclosure that is silently ignored is a harm. How we approach this is set out in our Safeguarding Statement; the honest build position is in §6 below.
• Adaptive-practice harms. Profiling a child's performance to choose what they see could, if mishandled, narrow or distort a child's learning, or act on data it should not. Special-category data must never drive it.
• International-transfer dependency. Where the AI inference physically runs determines whether any personal data leaves the UK. This depends on the live runtime configuration, not the code default, and is a risk that must be verified, not assumed.
• Monitoring without a signal. Certain adults (a linked parent, a same-school teacher, an admin) can see parts of a child's activity, and we are adding a clear in-app indicator that shows a child when an adult can see their activity.
• Age and competence. Establishing a child's age band, and the basis on which a child (versus a parent) engages the service, carries risk if mischaracterised.

5. Mitigations in place or designed

Against those risks the DPIA records the following mitigations:

• High-privacy defaults. No third-party advertising or analytics trackers; no tracking cookies or pixels; sign-in tokens held in session storage only (cleared on tab close).
• Adaptive picker off by default. It is opt-in; a child can use the whole platform without it, and no profiling profile is persisted.
• Pseudonymous tutor payload. What is sent to the AI model is limited to the age band, the difficulty level, the problem text and the requested hint level — not the child's name, email, parent email, school or account identifier. To the model the interaction is pseudonymous.
• "This is an AI" disclosure. A child is told, in language they can understand, that they are talking to an AI helper and not a person, that its answers may be wrong, and what happens to what they type. (AI Act Art. 50 / ICO Std 4; AI Tutor Notice §2.)
• Intended retention, with deletion and anonymisation. On account deletion we delete the child's answers and assignments, anonymise the identifying fields, keep only non-identifying statistical fields plus an immutable consent/audit record, and remove identity from our sign-in provider. Tutor conversations and logs are kept for up to 6 months and then deleted on a rolling basis. We are implementing the automated deletion that enforces this.
• A safeguarding route. We commit that a child's risk disclosure is not silently ignored and that there is a route for a responsible person to act on it. (See Safeguarding Statement and §6 below.)

6. What we are still building

We do not present designed mitigations as if they already run. The DPIA records the following as in progress at the time of this summary:

• Automated retention deletion. Tutor conversations and logs are kept for up to 6 months and then deleted on a rolling basis. We are implementing the automated deletion that enforces this.
• In-app monitoring indicator. We are adding a clear in-app indicator that shows a child when an adult can see their activity.
• Safeguarding detection in the tutor. If a child discloses they may be at risk, we do not ignore it. We are building a system to detect such disclosures and escalate them to a responsible person who can act.

These gaps are part of the assessment precisely because they affect the residual-risk decision in §7. We will update this summary as each is built and tested, never before.

7. Outcome and residual risk

The DPIA's outcome — the residual-risk rating after mitigations, and the DPO sign-off — is recorded in the full DPIA, not settled here:

• Residual-risk rating:to be confirmed
• DPO sign-off:to be confirmed

Two principles apply to that outcome:

• The DPIA's findings are intended to shape the design — the mitigations in §5 and the build items in §6 are outputs of the assessment, not after-the-fact justifications. Outstanding items feed back into the residual-risk decision.
• If, after mitigations, the processing would still be high risk, we are required to consult the Information Commissioner's Office (ICO) for prior consultation before starting that processing.

8. Related documents

• Privacy Policy — what data we collect, why, lawful basis, sub-processors (§7), transfers, visibility, retention, rights.
• AI Tutor Notice — the optional tutor: that it is an AI, what is sent to the model, where it is processed, what happens to what a child types.
• Safeguarding Statement — our duty-of-care approach to a child's risk disclosure and the honest build position.

9. Contact

Questions about this summary or our data protection practices: mail@physmat.org. Data Protection Officer: to be confirmed. You also have the right to complain to the Information Commissioner's Office (ICO) — ico.org.uk. See Privacy Policy §10.