DSA Minors Safeguards Review Protocol — Lumi Tutor

Owner: product · Last updated: [LAST_UPDATED_DATE] Status: Draft technical mapping for counsel and safeguarding review. It does not satisfy the dsa-minors-safety release gate, establish DSA applicability, or approve any country or public launch.

This draft records implemented product controls and the evidence still required to assess them. Counsel must first determine whether Lumi, including the actual pilot configuration, is an online platform accessible to minors for the purposes of Article 28 of the Digital Services Act (DSA). If Article 28 applies, its measures must be appropriate and proportionate to the service's risks. This document is not a legal conclusion or a substitute for the actual risk assessment, human operating procedure, or signed review.

1. Applicable reference point

Article 28 requires providers of online platforms accessible to minors to put in place appropriate and proportionate measures for a high level of minors' privacy, safety and security. It also prohibits profiling-based advertising to a recipient known with reasonable certainty to be a minor, and does not require extra personal-data processing merely to establish minority.

The Commission's 2025 minors-protection guidelines use a rights-based, safety- and privacy-by-design, risk-based approach. They are voluntary guidance and do not automatically establish compliance. Counsel must assess the actual service, its distribution, user-generated/public-sharing functions, commercial model, and each pilot's facts before relying on this mapping.

Primary references:

• DSA, Regulation (EU) 2022/2065, Article 28
• European Commission: Guidelines on the protection of minors

2. Implemented technical controls to examine

These controls are product evidence, not a claim that they are sufficient for Article 28 or for any safeguarding duty.

• Tutor safety path. The child-tutor path applies server-side safety checks before provider use and checks tutor output before display. Blocked content receives a child-safe fallback and can create a SafetyEvent; the safety decision is not delegated solely to the model (../safety.md).
• Minimisation boundary. Product guidance prohibits soliciting a surname, address, phone number, photo, video, geolocation or persistent identifiers. Memory is summary-oriented and raw transcript retention is disabled by default. The actual controller, retention periods, processors and legal basis remain open for review (privacy-policy.md).
• Advertising boundary. The product design contains no advertising, behavioural advertising cookies or advertising profiles. This must remain verified in the deployed service and commercial configuration; it is not a substitute for counsel's DSA assessment.
• Engagement boundary. Rewards are designed as mastery-based, daily-capped and idempotent. The design excludes purchase-based or random rewards, loss-framing streak punishment, autoplay, and social-pressure mechanics (../gamification-plan.md). Child and accessibility review must still test whether the actual experience creates undue pressure or engagement harms.
• School sharing boundary. Where a parent shares a safety event with a school, the implementation checks parent ownership, active enrolment and distinct primary and backup safeguarding coverage before a school case can be opened. This does not appoint, train, monitor or evidence the availability of real safeguarding people.

3. Reporting, escalation and accountability are not yet evidenced

The product has technical routes for safety events, parent visibility and school safeguarding notifications. It does not currently evidence a named safeguarding lead and backup, a monitored on-call channel, response-time performance, country-validated helpline content, or a qualified child-protection review. The response times in ../safety-escalation.md are proposed operating targets, not achieved service-level evidence. No statement in this protocol should be read as a promise that an event reaches a human within a particular period.

Safety and privacy contact details remain placeholders until the real controller and operational inboxes are approved: [SAFETY_EMAIL] / [PRIVACY_EMAIL].

4. Age assurance and access

A child profile is designed to be created through parent/guardian or school authority paths; the legal basis, minor-consent route, school authority evidence and country-specific configuration remain subject to counsel review. Age-related information must not be expanded merely to satisfy this mapping. See minor-consent-authority-model.md and minor-consent-matrix.md.

5. Evidence required before the gate can be accepted

• [ ] Counsel records the DSA service classification and Article 28 applicability for the actual pilot.
• [ ] The product team maps the actual pilot's risk scenarios and measures to the Commission guidance.
• [ ] A named, trained safeguarding lead and independent backup accept a written, country-specific procedure and monitored contact route.
• [ ] A timed tabletop validates alert delivery, acknowledgement, parent communication, escalation, record-keeping and failure handling; findings are signed and any remediation is closed.
• [ ] Country helpline and mandatory-reporting content is reviewed by qualified local child-protection and legal reviewers before it is shown to children or relied upon operationally.
• [ ] Qualified child, accessibility and safeguarding reviewers assess the shipped experience, including age assurance, safety help-seeking, reporting, AI interactions and gamification.
• [ ] The real controller identity, safety/privacy contacts, retention decisions, processors and relevant pilot agreements are approved and reflected in final notices.

Until every applicable item is evidenced and accepted, this remains private-test review material and must not be presented as DSA compliance or launch readiness.