Protect Student Data When Adopting AI Tools

A teacher finds a useful tool, the class signs up, and personal data about minors begins flowing to a company nobody has assessed under terms nobody has read. This is not negligence — it is the predictable result of adoption being one click and review being a process that nobody told the teacher about.

The fix is a review that is short enough to actually happen. What follows is meant to fit in twenty minutes per tool.

Map what leaves

Most people picture the assignment text. That is the smallest part.

Account data — names, email addresses, and often a class or year group, which together identify a specific child at a specific school.

Content — everything typed, uploaded, or dictated, including drafts and anything personal a student mentions in passing. Students disclose a great deal in free-text fields.

Behavioural data — timestamps, session length, revision counts, click paths. Rarely considered and often the most revealing, since it describes how a student works and when they struggle.

Inferences — proficiency estimates, engagement scores, and predictions the product generates. These are new personal data created about the student, they frequently persist, and they can follow a learner in ways nobody intended.

Third-party flows — analytics, advertising, and subprocessors, which is how data reaches companies you never chose. Where a product wraps another provider's model, the content reaches that provider too.

Sketch this for one tool you already use. The sketch usually changes the conversation on its own.

Review the vendor on the terms that matter

Not a legal review — nine questions with written answers.

Is student input used to train their models? The single most important question, and the answer often differs between consumer and education plans. It should be no, in writing.

Who is the data controller? In an education context the institution usually needs to be, with the vendor processing on instruction.

What is the retention period, and is deletion real? Including backups, and including inferences derived from the data.

Where is it stored and processed? Cross-border transfer rules apply in many jurisdictions.

Who are the subprocessors? And are you notified when they change?

What is the minimum age, and what does the vendor require for younger users? Products designed for adults frequently have terms that simply do not permit minors.

Is there an education-specific agreement? Many vendors offer one with materially better terms, and it is usually not the default.

What happens at contract end? Export and deletion.

Has there been a breach, and how was it handled?

Two answers should stop adoption outright: training on student input, and a minimum age above your students with no compliant alternative.

Reduce what the activity needs

Before adding controls, remove data. The most effective privacy measure is not collecting something.

Teacher-mediated use — the teacher operates the tool and students never have accounts — eliminates the entire account-data category and is appropriate for a great deal of classroom work, especially with younger learners.

Institutional accounts with pseudonymous identifiers keep the mapping between identifier and student inside the school.

Shared or class accounts work for some activities, at the cost of individual progress tracking.

Individual named accounts are sometimes genuinely necessary and should be a deliberate decision rather than a default.

Also strip content: student names inside submitted text, personal details in prompts, and photographs. And set a rule that students should not enter personal information about themselves or others — then teach why, since that instruction is itself part of digital literacy.

Consent, and what it does not fix

Where the law requires consent, get it properly: specific to the tool and purpose, from the right person given the student's age, with a genuine alternative for anyone who declines. Consent buried in a start-of-year form is unlikely to be meaningful.

Note two limits. Consent does not make an unsafe tool safe — a product that trains on student input is not made acceptable by a signature. And where there is a power imbalance, consent is a weak protection: a student who feels unable to refuse has not really consented. This is why minimisation and vendor review come first, and consent last.

Practice

Take one tool already in use and complete the data map and the nine questions. Where you cannot find an answer, that absence is the finding.

Then design one activity two ways — with individual accounts and teacher-mediated — and compare what is genuinely lost. The gap is frequently smaller than assumed, which makes the lower-risk version the obvious choice.

Write the outcome as a one-page approval note. A short reusable format is what turns this from an exception into a routine.

Common mistakes

Adopting first and reviewing later. The data has already left.

Reading the consumer terms. The education agreement often exists and is materially different.

Ignoring behavioural data and inferences. Usually the most revealing categories, and the least discussed.

Treating consent as the whole answer. It does not fix an unsafe tool, and it is weak where refusal feels impossible.