GDPR Checklist for AI Tools in Education (2026)

Most GDPR reviews of an AI tool for the classroom stop at the app vendor's privacy policy. That's gate two, not gate one — the AI model actually doing the listening has its own terms, sitting one layer below the page a DPO usually opens first. Clear that layer first, or the rest of the review is checking the wrong document.

Why AI voice tools are different: student audio, real-time processing, and the sub-processor chain

A worksheet app stores typed answers. A voice tutor captures a continuous audio stream, sends it to a model in real time, gets a spoken response back, and often keeps a transcript for progress tracking. That's a longer chain, and every hand-off is a place data crosses a contract boundary — or a border.

The typical path: student device → app vendor's backend → third-party AI model API processing audio live → optional transcription sub-processor → storage. A grammar checker might have one or two hops; a live AI tutor usually has three or four, and at least one is a foundation-model company the school never signed anything with directly. That's why voice tools trip GDPR's Article 35(3) DPIA triggers more easily than static edtech — real-time processing of children's data, via newer technology, at cohort scale, checks several boxes at once.

Gate 1 — the underlying AI provider's terms: the layer most reviews skip

Here's the item most institutional privacy checklists miss, and the one we think matters most: the app vendor's Data Processing Agreement describes what the vendor promises. It says nothing about what the AI model underneath is contractually allowed to do — that's a separate agreement, between the vendor and the model provider, that the school never sees unless it asks.

Foundation-model companies commonly set their own age floor and purpose-of-use limits in their API terms, distinct from their consumer-facing chat app — often an 18-or-older default, with minors' data permitted only under a separate enterprise agreement carrying commitments like no training on inputs and defined retention. Exact wording varies by provider and changes with contract updates — confirm the current clause directly before enrolling a class of minors.

The question isn't "is your privacy policy GDPR-compliant" — most are, on paper. It's: "Which model or API do you call, under whose terms, and do those terms permit processing data from users under 18 without a separate agreement?" If the vendor can't answer that in writing, that's the finding to write up.

Gate 2 — when does an AI language tool trigger a DPIA, and who runs it

Under GDPR Article 35(1), a controller must run a DPIA when processing is "likely to result in a high risk to the rights and freedoms of natural persons." According to the Article 29 Working Party's Guidelines on Data Protection Impact Assessment (WP248 rev.01, 2017), later endorsed by the EDPB, nine screening criteria determine whether processing is likely high-risk — you rarely need all nine; per that guidance, meeting two criteria is usually enough to require a DPIA, and in some cases a single criterion can be enough on its own.

DPIA trigger criterion	Present in a live AI voice tutor?
Processing data from vulnerable data subjects (children)	Yes, in any K-12 or under-18 deployment
Innovative use of technology	Yes — real-time generative AI voice processing
Systematic monitoring	Often, if usage/progress is tracked per student
Large-scale processing	Yes, at cohort or institution scale
Evaluation or scoring	Yes, if the tool grades fluency, pronunciation, or speaking level
Special category / biometric-adjacent data	Possible — see the biometric-data FAQ below

The controller — the school, university, or the local authority above it — runs the DPIA, not the vendor. The vendor's job is supplying inputs: a data-flow diagram, sub-processor list, retention figures, and transfer mechanisms. A vendor offering to "handle your DPIA for you" is grading its own homework; use their inputs, but keep sign-off with your own DPO.

Gate 3 — mapping the data flow: where audio goes, who touches it, which region

Ask the vendor to walk the audio's actual path, hop by hop, not describe it in the abstract. A usable map looks like this:

Stage	What happens	Ask the vendor
Capture	Audio recorded on the student's device	Is it buffered locally before sending?
Transmission	Sent to the app's backend	Encrypted in transit? Which region does the backend sit in?
AI processing	Forwarded to the model provider's API in real time	Which provider, which region, what transfer mechanism if outside the EEA/UK?
Transcription / scoring	Speech converted to text and assessed	Same sub-processor as the model, or a separate one?
Storage	Transcript and/or audio retained for progress tracking or QA	Where, for how long, and under whose contract?

Where any hop sits outside the EEA or UK, GDPR Chapter V (Articles 44–49) requires a valid transfer mechanism — Standard Contractual Clauses are the common fallback since Schrems II. Ask for the SCC reference by name, not a vague "we're GDPR compliant" line.

Gate 4 — retention and deletion: why "no data stored" claims deserve a follow-up question

"We don't store the audio" is technically true for a lot of vendors, and it's also incomplete. It usually just means the app vendor's own database doesn't persist the recording — not whether:

• the AI model provider logs inputs separately for abuse monitoring
• that provider's default retention window is shorter than advertised, absent a negotiated zero-retention agreement
• crash logs or QA sampling capture audio snippets outside the normal storage path
• backups outlive a deletion triggered in the app itself

GDPR Article 5(1)(e) — storage limitation — requires data be kept no longer than necessary. Article 17 gives the data subject (or the school, for a minor) a right to erasure. Article 28 requires that obligation to flow down to sub-processors. The follow-up question that separates a real answer from a marketing line: "Show me the clause in your DPA, and your AI provider's DPA, that sets the retention window — not the webpage that says zero."

Gate 5 — safeguarding for under-18s: consent, age assurance, and staff access

Legal basis and safeguarding are two different questions, and schools sometimes only answer the first. According to GDPR Article 8(1), the default digital consent age is 16, with member states free to lower it to 13 — the exact threshold differs by country (for example, 13 in Denmark, Portugal, Sweden, and the UK's domestic regime, versus 15 in France and Greece), so confirm it locally before relying on consent as the legal basis. Most school deployments don't run on individual consent at all; they rely on the institution's public task or legitimate interest, with consent reserved for optional extras.

That doesn't remove the safeguarding layer. A defensible deployment for minors still needs:

Safeguarding control	What to verify
Age assurance	How the app confirms a user is a student in the enrolled cohort, not a generic consumer signup
Content controls	Topic restrictions and moderation appropriate to the age group in each voice mode
Staff visibility	Whether teachers or safeguarding leads can review transcripts if a concern is raised
Reporting path	A named contact for a parent, student, or staff member to flag a problem

US institutions carry two additional obligations: FERPA governs student education records at federally funded schools, and COPPA requires verifiable parental consent before collecting data from children under 13. Neither substitutes for the GDPR gates above where EU or UK students are also enrolled — treat them as an added lens, not a replacement.

The copy-paste DPO question list (20 questions)

Group these by gate and send them to any vendor before a pilot. A vendor that answers all twenty in writing, without hedging, has done the work.

Gate	#	Question
1. Provider terms	1	Which AI model or API does your product call in production?
	2	Under whose terms of service — yours, or the model provider's?
	3	Do those terms permit processing data from users under 18?
	4	If not by default, do you hold a separate enterprise/education agreement that does?
2. DPIA	5	Have you supplied a data-flow diagram we can attach to our own DPIA?
	6	Do you claim your product removes our need to run a DPIA? (If yes, that's a red flag.)
	7	Is student data used to evaluate, score, or profile students automatically?
	8	Is the processing "large scale" across our cohort, architecturally?
3. Data flow	9	List every sub-processor that touches student audio, by name.
	10	In which region is each sub-processor's processing/storage located?
	11	What is the legal transfer mechanism for any hop outside the EEA/UK?
	12	Is audio encrypted in transit and at rest at every hop?
4. Retention	13	What is the retention window at the app layer, in writing?
	14	What is the retention window at the AI provider layer — is it different?
	15	Can a deletion request from us reach every sub-processor, including backups?
	16	Is student input ever used to train or fine-tune a model, by you or your AI provider?
5. Safeguarding	17	How is student age verified or assured at signup?
	18	What content controls apply for minors specifically?
	19	Can our safeguarding lead review a transcript if a concern is raised?
	20	Who is our named contact for a data protection or safeguarding incident?

For the broader evaluation this checklist sits inside — pricing, pilot structure, procurement beyond privacy — see our guide to evaluating AI language tools for institutions. For university language centres specifically, speaking practice for university language centres covers the staffing-versus-tooling comparison directly.

How LinguaLive answers these questions today — including the uncomfortable ones

We built this checklist partly because answering it honestly for our own product surfaced the gap in Gate 1. Here's where we stand, plainly.

Question	LinguaLive's answer today
Which AI model powers the live voice conversation?	Google's Gemini Live API. Student audio is sent to Google's model in real time to generate the tutor's response — a genuine sub-processor relationship, not something we abstract away.
Does the underlying provider's terms clear under-18 use without a separate agreement?	The honest, unresolved part: provider-level terms for minors' data are an active compliance question, not a settled one. If your pilot involves under-18 students, ask us for current signed documentation before enrolling anyone — don't take a webpage's word for it, ours included.
What other sub-processors touch student data?	Supabase, for backend database and infrastructure, alongside Google for the AI processing layer.
What's the retention window?	Defined in our Data Processing Agreement, provided on request — we don't advertise a "zero data stored" claim, because it wouldn't survive the follow-up question in Gate 4.
Where is data processed/stored?	Region-specific detail we confirm per institutional agreement rather than publish generically here. Ask us for the current regional configuration directly before relying on it in your own DPIA.

That's also why our institutional page leads with a pilot conversation, not a self-serve signup: a director or DPO evaluating how an AI language tutor actually works under the hood deserves a direct answer to all twenty questions above, not a compliance page written to close the sale before the DPIA is done.

Frequently Asked Questions

Do AI tools in schools need a DPIA?

Often yes — GDPR Article 35 covers processing "likely to result in high risk," and AI processing of children's data usually clears that bar. The school, as controller, must run it.

Can students under 18 legally use AI language apps?

Check two layers: the app vendor's terms and the underlying AI provider's terms. Many foundation-model API terms set an 18-plus floor unless a separate enterprise agreement applies.

Where is student voice data processed by AI tutoring apps?

Through the app vendor's backend, then a third-party AI model provider's servers in real time, and sometimes a separate transcription sub-processor. Ask for the region and transfer mechanism at each hop.

What questions should a DPO ask an AI vendor?

Which model it calls, whether that provider's terms permit under-18 data, where audio is processed and stored, retention length, and who can access transcripts. See the full 20-question list above.

Do schools need parental consent for AI tools?

Not always — many deployments rely on the institution's public task rather than individual consent. GDPR Article 8 still requires parental consent for services offered directly to children below the national digital consent age (16, lowerable to 13).

Is student voice data biometric data under GDPR?

Not automatically. Article 4(14) defines biometric data as data used to uniquely identify a person — plain transcription audio usually falls outside that. It becomes biometric, and special-category under Article 9, if the system builds an identifying voiceprint.

If you're running this checklist against a real pilot decision, we'd rather have the direct conversation than let a privacy page answer for us. Visit LinguaLive for Education to talk through your DPIA, your DPO's question list, and an honest answer on where our own provider-terms review stands today.