DPDP Compliance for EdTech: Children's Data and AI Use

DPDP Section 9: Children's Data Rules

DPDP Section 9 imposes strict restrictions on processing personal data of children (under 18): verifiable parental or guardian consent is required before any processing, behavioural tracking and targeted advertising to children is prohibited, and processing that could detrimental affect a child's wellbeing is prohibited.

For EdTech: if your platform has any users under 18 (which virtually every Indian EdTech does), you are subject to Section 9. The 'verifiable' consent requirement is the hard part — checking a box that says 'I am the parent' isn't sufficient. You need a process that actually verifies parental identity.

Age Verification and Parental Consent Implementation

Implementing verifiable parental consent: Option 1 (OTP-based) — during child registration, require a parent mobile number. Send OTP to that number. Parent must enter OTP to complete registration. Store the parent's mobile number and consent record. Option 2 (Document-based) — require parent Aadhaar-based DigiLocker verification. Higher friction, higher assurance. Required for higher-risk processing.

Age verification: DPDP doesn't specify a technical standard. Best practice: during registration, ask for date of birth. If under 18, trigger the parental consent flow. Store the date of birth as evidence of why parental consent was collected.

AI Tutoring Under DPDP Section 9

AI tutors that adapt to student behaviour, track learning patterns, and predict performance are processing children's personal data in ways that Section 9 directly governs. The behavioural tracking prohibition (Section 9(3)) may cover: learning pace analysis, attention monitoring (if camera-enabled), and performance prediction models.

To stay compliant: (1) Get explicit parental consent specifically for AI-adaptive features (separate from the base consent for the platform), (2) Never send student identifiers to third-party LLM APIs — redact student names, IDs, and any identifying context before AI processing, (3) Disable personalised advertising to all under-18 users regardless of consent.

Compliance operational checklist

DPDP Compliance for EdTech: Children's Data and AI Use should be reviewed as an operating control, not only as a reference article. The minimum checklist is a data inventory, a stated processing purpose, owner approval, PII detection at the AI boundary, redaction or tokenisation where possible, retention limits, vendor transfer records, and a tested user-rights workflow. This checklist gives engineering and compliance teams a shared language for deciding what must be blocked, what can be allowed in shadow mode, and what needs human review before production release.

For AI systems, the review should include prompts, retrieved context, tool call arguments, model responses, logs, traces, analytics events, exports, and support attachments. Many incidents happen because teams scan only the visible form field while sensitive data moves through background context or observability tooling. CrewCheck's recommended pattern is to place the scanner at the request boundary, record the policy version, and keep audit evidence that shows which identifiers were detected and what action was taken.

A practical rollout starts with representative samples from production-like traffic. Run a DPDP scan, sort findings by identifier sensitivity and blast radius, fix Aadhaar, PAN, financial, health, children's, and precise-location exposure first, then move to consent wording, retention, deletion, and vendor review. Use shadow mode when false positives could disrupt users, and promote to enforcement only after the exceptions have owners and expiry dates.

This page is educational and should be paired with legal review for final policy interpretation. The operational proof should still come from repeatable evidence: scanner results, audit exports, pull-request checks, policy configuration, and a documented owner for the workflow. That combination is what makes the content useful during buyer diligence, board review, regulatory questions, or an incident investigation.