Learner data protection: minors, consent and access

Student data privacy in AI systems is where edtech products most often fail their first serious customer review. A school network's data protection officer asks three questions: whose consent did you collect and how do you know it is valid, who can see what, and what does your AI do with a child's data when it is generating an answer. Most products have a privacy policy and no engineering answer to any of the three. This article gives the engineering answer.

It covers what India's Digital Personal Data Protection Act means for minors' data in practice, how consent is represented in a system rather than a PDF, how access scopes are enforced for students, parents, teachers and administrators, how retention limits are built in, and why grounded AI is a privacy control as well as a quality one. It is written for edtech founders and institution IT leads; it is not legal advice.

Why minors' data is different

India's DPDP Act treats anyone under eighteen as a child. Processing a child's personal data requires verifiable consent from a parent or lawful guardian, and the Act restricts tracking, behavioural monitoring and targeted advertising directed at children. The rules made under the Act set out how verifiable consent is to be obtained and provide limited exemptions for certain institutions and purposes, which is exactly why a school's DPO asks the questions above. The primary text is published by the Ministry of Electronics and Information Technology. Our general guide to the Act for AI systems is DPDP Act 2023 and AI: what Indian companies must do; this article is about the education-specific engineering.

Beyond the statute, learner data is sensitive in ways a fee ledger is not. Attempt histories reveal learning difficulties; tutor transcripts reveal frustration and sometimes disclosures about home life. The system has to be designed so the wrong person cannot see it and the AI cannot repeat it in the wrong place.

The four controls, and where each lives

Consent as a system, not a document

Consent for a minor is a record with structure: the child, the guardian, how the guardian was verified (an existing verified parent account with the institution, a government-ID-backed identity check, or another method the rules permit), the purposes consented to (learning, communication, analytics, AI tutoring), the date and the withdrawal history. Every feature that processes the child's data names the purpose it needs, and the consent service answers yes or no at request time. Withdrawal is honoured immediately: an AI tutor whose learner has had consent withdrawn stops, the data is queued for deletion within the retention rule, and the guardian gets confirmation. Purpose-specific consent also means a school can enable the support agent but not the tutor, which is a common request in the first term.

Access scopes for four roles

Learner data has an unusual shape: many people have a legitimate but partial view of one child. We model the relationships explicitly (guardian-of, teaches, counsels, administers) with validity periods, because a teacher's scope ends when the class ends and a guardian's may change. Every API request and every retrieval carries the requester's scope, and the filter is applied before ranking, so a query from a parent cannot retrieve another child's record however the question is phrased. Administrators get the widest scope and the most logging. The same principle underpins our permission-aware retrieval work for enterprise systems; the education version simply has more roles and shorter validity windows.

Testing scopes with negative cases

Scopes are tested with an explicit list of things that must not happen: a parent asking about a classmate, a teacher asking about last year's class, a tutor prompt engineered to reveal another student's mistakes. These negative cases run on every release, alongside the functional tests, and any failure blocks the release.

Retention built into the system

Retention is a schedule, not a promise. Each data class has a rule: tutor transcripts kept for a defined period then anonymised for evaluation use; attempt data retained for the learner's enrolment plus a fixed period; contact details deleted on withdrawal; academic records retained per regulatory requirement. The rule runs as a job with an audit record of what was deleted or anonymised and when. Evaluation sets built from real transcripts are anonymised at creation, because an eval suite that outlives the consent it was built on is a liability.

Grounded AI as a privacy control

A general model asked a question about a child will answer from whatever it was given plus its own associations. Grounding limits what it is given: only content the institution approved and only records the requester's scope permits. It also limits what the model may say: an output check confirms the answer stays within the retrieved material, so the tutor cannot free-associate a diagnosis from an attempt history or repeat a disclosure from a transcript to a different user. Child data AI that respects minors is, in engineering terms, retrieval-scoped, output-checked and logged. The AI tutors grounded in your curriculum article describes the tutor side; the private agentic AI service covers institutions that want the model itself hosted in their own environment.

Model providers and data residency

Where a hosted model API is used, the contract should state that prompts and outputs are not used for training and set the retention period on the provider's side; where that is not acceptable, an open-weight model in your own cloud removes the question. We route across providers per task and keep the choice reversible, so a change in a school's requirement does not mean a rebuild.

A worked example

A school-network edtech platform preparing for a large customer's data protection review had a privacy policy, a sign-up checkbox and a tutor built on a hosted model with the student's full history in the prompt. We introduced a consent service with purpose-level records and guardian verification through the school's existing parent accounts, replaced role checks scattered across the code with a relationship model enforced in the API and retrieval layers, added retention jobs with audit records, and rebuilt the tutor as a grounded system with scope-filtered retrieval and an output check. Negative-case tests were added to the release pipeline. The review passed, and the platform gained a per-school consent dashboard that became a selling point. The consent and access engineering matches what we did for the KYC document intelligence platform for an NBFC, where the regulator's questions were similar in shape.

Team and timeline

Bringing an existing edtech product up to this standard is typically an architect for the consent and access model, a backend engineer for enforcement and retention jobs, and an AI engineer for grounding and output checks, over six to ten weeks, with your DPO or counsel reviewing the purpose list and retention rules. Building it into a new product from the start is cheaper. A Sprint Zero at $3,250 / ₹2,00,000 produces the gap analysis and the plan in ten working days and is credited to the build. Retrofit work is scoped as LLM application or custom enterprise software engineering; current figures are on the pricing page, and our education sector page lists related work. Our own security practices are described on the security page.

Before you start: a checklist

• List every purpose for which learner data is processed and map each feature to one
• Decide how guardian identity is verified and record the method with each consent
• Model relationships (guardian, teacher, counsellor, administrator) with validity periods
• Enforce scope in the API and retrieval layer, and write the negative-case tests
• Set a retention rule per data class and implement it as an audited job
• Ground every AI feature in approved content and scoped records, with an output check
• Confirm model-provider terms on training use and retention, or self-host
• Have counsel confirm the position against the Act and the rules before launch

Glossary

• Data fiduciary: the organisation that decides why and how personal data is processed, under the DPDP Act
• Verifiable consent: consent from a guardian whose identity and relationship have been confirmed by a permitted method
• Purpose limitation: processing data only for the purposes consented to
• Access scope: the set of records a requester may see, derived from their relationships
• Groundedness: whether an AI answer stays within the material it was given
• Anonymisation: removing identifiers so data can no longer be linked to a learner

Related reading

See AI audit trails: what regulators will ask to see for logging, student support agents for admissions and fees for a scoped agent in practice, and zero data egress for the self-hosted option.

Consent checked at request time, scope enforced before retrieval, retention run as a job and AI that cannot leave its sources: that is what protecting a learner's data means in code.