Child data minimisation in edtech: what to collect, what to refuse and who decides

Child data minimisation in edtech comes down to one discipline: collect what the learning needs, and stop there. It sounds obvious. In practice, almost every product decision pulls the other way. Analytics wants more events. Personalisation wants more profile fields. Sales wants richer usage reports for schools. Growth wants a way to reach families directly. Each request is reasonable on its own, and together they turn a learning tool into a data collection system that happens to teach.

EduRelia is Oryvelon's AI learning company for students, families and schools. It carries the strictest data standard in our group. This article explains the practice behind that standard: how we think about schools as controllers, how consent works when the user is a child, what we refuse to collect and how minimisation shapes the AI features themselves. It describes our approach, not legal advice. Laws such as GDPR, KVKK and COPPA set different requirements in different places, and every deployment has to be checked against the rules that actually apply.

Why children's data needs a different standard

Children cannot meaningfully weigh what they are giving away. They type what they are asked, answer what the screen suggests and rarely read a notice. The data they generate is also unusually long-lived: a learning record, a behaviour note or a written disclosure made at ten years old can follow someone for decades if it is kept and copied.

Regulators across many jurisdictions treat children's data as needing extra protection for exactly these reasons. But the stronger argument for an operator is trust. Schools will not adopt a product they cannot explain to parents. Parents will not keep a product they suspect of profiling their child. A company that treats child data carelessly does not have a compliance problem; it has a business problem.

So we start from the opposite end. Instead of asking "what data could make this better?", we ask "what is the smallest set of data that lets a child learn well here?"

Start from the learning purpose

Minimisation only works if the purpose is written down precisely. "Improve learning" is not a purpose; it justifies anything. A usable purpose looks more like this:

• Show a student the next appropriate exercise in a topic, based on their recent answers.
• Let a teacher see which students in their class are stuck on which skill.
• Let a parent see the time spent and topics covered this week.

Each purpose points to specific data. The first needs recent answers and a skill model — not a birth date, not a photo, not a home address. The second needs class membership and progress per skill — not the full text of every answer forever. The third needs weekly aggregates — not a keystroke log.

When someone proposes a new data field, the question is always "which written purpose needs it?" If none does, the field is not added. If the purpose is new, the purpose is discussed first, and only then the field.

Schools as controllers: who decides

When a school licenses EduRelia for its pupils — the B2B2C model we describe in B2B2C licensing for schools — the school is usually the party that decides why and how pupil data is used. In GDPR language, the school is typically the controller and the product provider a processor acting on its instructions. Other frameworks use different terms, but the idea is similar: the institution responsible for the child's education decides, and the provider follows.

That has practical consequences for how we build.

The school's instructions are the scope. If the licence covers maths practice for two year groups, the product processes data for that. It does not quietly add features that use pupil data for something the school did not agree to.

The school sees and controls its data. A school administrator should be able to see which pupils are enrolled, what is stored about them, and remove them. When the licence ends, the school's data is returned or deleted according to the agreement.

We do not reach around the school. A pupil account created through a school is not a marketing lead. We do not email the child, and we do not use the school relationship to acquire the family as a separate consumer customer without a clear, separate and appropriate process. Our reasoning on this is in Separating marketing consent from product consent.

Each school is its own boundary. Schools are isolated from one another, and pupil data from one school is never visible to another. We explain the patterns in Tenant isolation explained.

Families can also use EduRelia directly, without a school. In that case the parent or guardian is the account holder, and the relationship is with them. The minimisation rules do not loosen; the only difference is who decides and who receives explanations.

Consent that makes sense to families

Consent for children is not one checkbox. It is layered, and each layer has a different audience.

1. The institution. In a school deployment, the school agreement sets out what is processed and why. Depending on the jurisdiction and the lawful basis the school relies on, the school may also need to inform or obtain consent from parents.
2. The parent or guardian. For direct consumer use, the parent is the account holder. Where the law requires verifiable parental consent for children under a certain age, the product has to obtain it before collecting personal information from the child.
3. The child. Even when a child cannot legally consent, they deserve an explanation they can understand. A short, plain-language note — "your teacher can see which questions you got right, so they can help you" — respects the child and reduces surprises.

We keep a few rules for all layers:

• Say what happens, not what is permitted. A notice that lists every theoretical use is less honest than one that describes what the product actually does.
• No bundled consent. Agreeing to use the learning product never includes agreeing to marketing, research or anything else.
• Withdrawal is as easy as agreement. A parent who wants their child's account deleted should be able to request it without friction.
• Record it. Every consent or instruction is stored with a date, the text shown and who gave it, within the company that collected it.

What we do not collect

Case-by-case judgement is unreliable under deadline pressure, so EduRelia keeps a written "do not collect" list in its source-of-truth document. A new feature that needs something on the list needs an explicit, documented decision to change the list, not a quiet exception.

This list is deliberately blunt. It is easier to explain to a head teacher, easier to check in a review and harder to erode than a nuanced policy.

Minimising inside the data you do collect

Minimisation is not only about which fields exist. It also covers precision, retention and access.

Precision. Store the year group, not the birth date. Store the skill-level estimate, not every intermediate calculation. Store that a session lasted twenty minutes, not a second-by-second activity trace.

Pseudonymisation. Pupils can be identified internally by an ID, with the link to their name held only where the teacher view needs it. Analytics and model evaluation work on IDs, not names.

Retention. Answer histories are useful for a period, then summarised or deleted. Class data follows the school year and the licence. Nothing is kept "in case it is useful later". See Data retention and deletion.

Access. Teachers see their own classes. School administrators see their school. Support staff see only what they need to resolve a ticket, with access logged. Engineers do not browse production pupil data. The principles are in Least-privilege access for small teams.

Testing. Development and staging use synthetic pupils, never copies of real ones. The rule is simple and has no exceptions for "just this once". We explain the setup in Environments and test data.

How minimisation shapes AI learning features

AI makes minimisation more important, because a model will use whatever context it is given, and a child will type whatever comes to mind.

EduRelia's AI features are designed around a narrow context. When a student asks for help with a problem, the model receives the problem, the relevant curriculum material and a small summary of the student's recent performance on that skill. It does not receive the student's name, school or anything else it does not need to explain the step.

Several safeguards run through our AI gateway:

• Input filtering. If a child types personal details — a phone number, an address, a full name — into a free-text box, the system can detect and strip them before the text reaches a model provider or a log.
• Safety hooks. Messages that suggest a child may be at risk are not treated as ordinary learning questions. They follow a defined route agreed with the school, rather than being answered by a model. We describe the general approach in AI safety hooks for consumer products and Human escalation in AI products.
• No training on pupil data. Student inputs are not used to train or fine-tune models, and model providers are configured not to retain or train on the data where that option is available.
• Structured outputs. Explanations are generated against a schema, and curriculum facts come from verified material, not from the model's memory. AI explains; verified material decides.
• Minimal logs. Observability records latency, cost, errors and validation results. Conversation content is minimised, retained briefly and access-restricted.

One concrete example. Imagine a student writing, mid-exercise, "I can't do this, my dad says I'm stupid." A general chatbot might offer comfort and carry on. That message is not a maths question. In a school deployment it should follow the school's safeguarding route, and the product should not store it in a general conversation log where it could be seen out of context or kept indefinitely. Designing for that moment is part of minimisation: knowing what not to keep, and who should see what is kept.

What schools and parents should be able to see

Minimisation is more convincing when it is visible. We aim for EduRelia to be able to give any school or parent:

• A plain list of the data fields stored about a pupil, and why each exists.
• The retention period for each category.
• A description of which staff roles can access what.
• A statement of which model providers process data, in general terms, and under what restrictions.
• A working process to export or delete a pupil's data.

If we cannot produce one of these for a feature, the feature is not ready for children.

Common mistakes in edtech data practice

Patterns we deliberately avoid:

• Collecting now, deciding later. "We might use it for research" is the most common reason for over-collection. Research needs its own purpose, basis and approval.
• Consumer analytics in a child product. Generic analytics tools capture far more than a learning product needs, often including device identifiers and cross-site tracking. We keep analytics minimal and first-party where possible.
• Treating the school relationship as a funnel. Pupils enrolled by a school are not a consumer audience.
• Open text everywhere. Every free-text field is an invitation to disclose. Use structured answers where they serve learning just as well.
• Copying production into test. One developer's laptop becomes the least protected copy of children's data in the company.
• Forgetting derived data. Summaries, embeddings and cached explanations built from pupil work are pupil data too.

A minimisation review for new features

Before any EduRelia feature that touches pupil data ships, it passes a short written review.

1. Which written purpose does this feature serve?
2. What new data does it collect, and at what precision?
3. Is anything on the "do not collect" list involved?
4. Who can access the data, and how is access logged?
5. How long is it kept, and how is it deleted?
6. Does any of it reach a model provider, and with what restrictions?
7. How will a school or parent see it and remove it?
8. What happens if a child types something sensitive into it?

The review takes minutes for most features. For the few where it takes longer, that time is well spent.

One pupil's data, from enrolment to deletion

It helps to follow a single hypothetical pupil through the whole lifecycle, because minimisation decisions show up at every stage.

Enrolment. The school's administrator adds a class. For each pupil, the product needs a display name the teacher recognises, a year group and a class link. It does not ask for a birth date, a home address, a parent's phone number or a photo. If the school's own systems hold those, they stay there.

First sessions. The pupil signs in with a method the school chooses. The product records answers to exercises and builds a skill estimate per topic. It does not record device location, and it does not load third-party trackers.

Ongoing use. After a period, detailed answer histories are condensed into skill summaries. The teacher still sees who is stuck on fractions; nobody needs every wrong answer from six months ago.

Moving class or school. Moving between classes in the same school is a change the school makes. A pupil who leaves the school leaves its data behind; nothing follows them to a new institution unless the schools and family arrange that themselves.

End of licence. When the agreement ends, the school's data is exported if requested and then deleted, including derived summaries and cached explanations, within the period set in the contract.

At no point does the pupil become a marketing contact, a research subject or a data point in another product. That is what minimisation looks like when it runs end to end.

Why this matters for the group

EduRelia's standard is the strictest in Oryvelon, but it influences everyone. It proves that shared infrastructure can carry very different data rules for different companies, which is the whole point of sharing infrastructure while keeping data separate. It also sets a reference point. When another company asks whether it needs a data field, "would we collect this for a child?" is a useful test even when the user is an adult.

Summary

Child data minimisation in edtech means collecting only what a specific, written learning purpose needs, at the lowest useful precision, kept for the shortest useful time and seen by the fewest people. When schools license a product, the school usually decides how pupil data is used and the provider follows its instructions; families using the product directly are the decision-makers for their own children. At EduRelia we pair that with layered, unbundled consent, a blunt written list of data we do not collect, AI features that receive minimal context and never train on pupil data, and a short review for every feature that touches children's information — practices that make the product easier to trust, easier to explain and easier to adopt.

Questions and answers

What is data minimisation in edtech?

It is the practice of collecting, keeping and using only the student data needed for a specific learning purpose. Anything that is not needed for that purpose is not collected, or is deleted as soon as it stops being needed.

Who is responsible for student data when a school uses an edtech product?

In many school licensing arrangements the school acts as the data controller and decides how pupil data is used, while the edtech provider processes it on the school's behalf. The exact roles depend on the contract and local law, so they should be written down for each agreement.

Does EduRelia use student data for marketing or other products?

No. EduRelia does not use student data for marketing, advertising or any other Oryvelon product. Student data exists only to support the learning service the school or family signed up for.

Published by Oryvelon, a digital company builder · About the group · Our companies · More in Data, Privacy & Security

NextMarketing consent vs product consent: why we keep them separate in every company →