Children & Family Privacy Notice

1. Current age boundary#

Adults may read public information and contact SRC AI about SRC Mentor. A child should not independently submit personal information through a public form, newsletter or Assistant. SRC AI does not currently offer a public child account or claim that a family product is live.

2. Parent and guardian role#

A parent or lawful guardian should make an enquiry and must have authority to act for the child. Family relationship, custody and consent rules vary. SRC AI may need proportionate verification before acting on a child-data request or enabling a future account.

3. Data minimization#

An initial public enquiry should describe the adult’s interest without naming a child or providing school, health, disability, location, identity or educational records. A future child-appropriate workflow must collect only data necessary for a defined learning or mentoring purpose and explain why each material category is needed.

4. Future child accounts#

Before any child account exists, SRC AI must define age gates, adult and child roles, guardian authorization, account recovery, visibility, consent, safety escalation and deletion. A child must not be asked to accept adult legal terms that the applicable law assigns to a guardian.

5. Educational and development data#

Learning goals, progress, research interests, reflections and mentoring interactions can reveal sensitive information even when they are not formal school records. Access should be role-based and designed around the child’s wellbeing, evolving capacity and reasonable expectations. Public sharing must be off by default.

6. AI interactions#

AI can make errors and should not replace a parent, teacher, counsellor, clinician or safeguarding professional. A child-facing system requires age-appropriate explanations, bounded topics, content safeguards, human escalation and testing. It must not encourage a child to keep unsafe secrets or treat automated output as authoritative professional advice.

7. Profiling and advertising#

A future family experience should not use a child’s data for behavioral advertising or sell it. Profiling and automated decisions must be limited, transparent and assessed for age, purpose and legal requirements. Development recommendations should remain reviewable by responsible humans.

8. Safety and safeguarding#

Product design must include reporting, moderation and escalation appropriate to the service without promising emergency response that is not actually staffed. SRC AI is not an emergency service. A person facing immediate danger should contact the appropriate local emergency or safeguarding service.

9. Service providers#

Any Provider processing child or family information requires heightened review of purpose, access, location, retention, training use, deletion, security and contractual protection. A Provider must not be connected simply because the technical integration exists.

10. Retention#

Child and family information should be retained for the shortest period consistent with the active purpose, safety, account integrity and law. Production policy must set periods for uncompleted guardian verification, inactive accounts, learning history, safety reports and backups. Deletion should propagate to Providers subject to lawful exceptions and delayed backup cycles.

11. Access, correction and deletion#

A verified parent, guardian or eligible young person may request access, correction or deletion where applicable. SRC AI must consider the child’s rights, age and interests, the requester’s authority, another person’s privacy, safety and legal retention. Do not send identity evidence until a secure verification method is provided.

12. Unintended submission#

If you believe a child submitted information through a public channel, use the contact form and identify the approximate date, route and adult contact needed to locate it. Do not repeat the child’s sensitive information. SRC AI will assess containment, verification, deletion and any legal or safety duty.

13. Jurisdiction-dependent consent#

Age thresholds, verifiable parental consent, child participation and educational-data requirements vary. This Notice does not claim compliance with a named children’s regime before a qualified assessment. A future launch must map the actual user locations, age range, school or family roles and Providers and implement the applicable requirements.

14. Transparency and family choice#

Notices should be understandable to both adults and young people, distinguish required from optional data and explain who can see it. Families should receive meaningful choices rather than dark patterns. A material change to child-data use may require renewed notice or consent.

15. Contact and relation to the Privacy Policy#

Questions, notices, complaints and requests may be sent through the SRC AI contact form. Use the category that best matches the request and provide enough information for SRC AI to identify the relevant interaction. Do not send account credentials, payment-card data, identity documents or other sensitive records through a public form. SRC AI may ask for proportionate evidence of identity or authority through an appropriate protected channel before acting on a request.

The Privacy Policy explains general Website, security, Provider, transfer and rights practices. This Notice controls where it provides stronger or more specific child and family safeguards.

16. Age assurance and proportionality#

A future child or family service should use an age-assurance method proportionate to the feature, risk, territory and data involved. It should not collect more identity information than the safety purpose requires. A simple public information page may need no age check, while an account, communication or sensitive learning record can require stronger controls.

Age assurance can be inaccurate and should include a safe correction route. A child should not lose access to general public safety information merely because a high-data verification method is unavailable.

17. Guardian controls and changing authority#

A guardian workflow should explain who can create, view, correct, export and delete a child record; how another guardian is invited; and what happens when authority is disputed or changes. SRC AI must not assume that possession of an email address proves legal authority. Proportionate evidence and escalation may be required.

Controls should evolve with age, capability and local law. A young person may gain independent rights over information, while safety or legal obligations can limit a guardian request. Product design must address this transition before accounts are launched.

18. Learning records, observations and inferences#

Learning goals, progress, interests, difficulties, mentor notes and inferred preferences can become sensitive in context even when not legally classified as special-category data. A future SRC Mentor service should collect only information linked to a defined learning or safeguarding purpose and distinguish user-provided facts from automated or human interpretation.

Inferences should not be presented as diagnoses, fixed ability or destiny. Families and eligible young people need a way to question or correct material records. High-impact education, wellbeing and safety decisions remain with responsible humans and qualified professionals.

19. Communications, community and moderation#

If future features allow messages, groups, mentor contact or user-generated content, SRC AI must establish age-appropriate visibility, reporting, blocking, moderation and escalation before launch. Default public discoverability of a child profile, contact detail or precise location is not appropriate.

Automated moderation may help prioritize risk but can miss context or make mistakes. Credible safety concerns require trained human review and documented action. The service should explain emergency limitations and direct users to local emergency resources when appropriate.

20. Research, testing and product improvement#

Usability testing or research involving children requires a clear purpose, voluntary participation, suitable guardian and child information, minimization, safe researchers and a withdrawal process. Participation in ordinary service should not depend on unrelated research consent. Incentives must not create inappropriate pressure.

Product telemetry should be aggregated where practical and must not be used to build an undisclosed advertising profile. Research publication should prevent reasonable identification and address small groups, quotations and contextual clues.

21. Family requests, conflict and safety exceptions#

SRC AI may receive conflicting correction, access or deletion requests from family members. It should verify authority, consider the child’s rights and safety, avoid revealing one person’s confidential information to another and seek professional guidance where necessary. A routine support process is not a forum for deciding custody or family law.

Deletion may be limited by safeguarding evidence, legal claims, mandatory records or another person’s rights. Any limitation should be specific and explained where lawful, with access restricted while the record remains.

22. Launch gate for child and family features#

Before collecting child account or developmental information, SRC AI should complete a product-specific privacy and safety assessment, supported-age decision, guardian model, consent analysis, data map, retention schedule, Provider review, abuse testing, accessibility review, incident process and age-appropriate notice. Public product direction alone is not authorization to collect data.

Until that gate is approved, SRCAI.co should not present a child sign-up, ask for educational records or invite sensitive AI conversations. Families may request general public information through an adult without naming a child.

23. Child-friendly information and transparency#

A future child-facing notice should explain in age-appropriate language what information is requested, why, who can see it, how AI may help, what choices exist and how to ask for help. The adult notice remains available for detail, but complexity should not be used to hide a material practice from a young person.

Changes affecting visibility, profiling, communication or retention should be explained before taking effect where required. A decorative character or friendly tone does not replace accurate information.

24. Consent and authorization records#

Where guardian consent is the approved basis, the service should record the request, verified authority method, scope, policy version, time and withdrawal without retaining excessive identity evidence. Consent for one activity, such as mentoring communication, is not consent for advertising or unrelated research.

Where another basis applies, SRC AI should document it and still provide appropriate choices. The applicable age and authority rules depend on territory and must be professionally assessed before launch.

25. AI interactions and safety escalation#

A child-facing AI feature requires narrower topics, age-appropriate responses, sensitive-data warnings, crisis and abuse escalation, human oversight and adversarial testing. It must not encourage secrecy from a responsible adult, diagnose, manipulate emotion or present uncertain inference as fact.

Automated flags can be wrong. Safety review should limit access, document decisions and involve qualified humans. The current public Assistant is not designed for private child mentoring or emergency support.

26. Advertising, persuasion and commercial use#

SRC AI should not use child learning or family information for behavioral advertising or sell it as part of the current service. A future commercial communication must be age-appropriate, distinguish content from promotion and respect guardian and young-person rights.

Rewards, streaks and personalization should be assessed for undue pressure and wellbeing impact. Product engagement is not more important than a child’s safety, rest or autonomy.

27. Retention, deletion and backup handling#

A child or family data schedule should use short, purpose-linked periods and identify what happens when a pilot ends, an account closes, a young person reaches a transition age or guardian authority changes. Inactive records should not remain indefinitely for hypothetical future use.

Deletion can take time to age out of protected backups and can be limited by safeguarding or legal evidence. Restores must not reactivate a deleted account or old consent.

28. Providers and international processing#

A Provider handling child or family information requires heightened review of purpose, access, training use, location, retention, security and support. Disconnected architecture does not authorize transfer. Families should receive material Provider information before use where required.

International processing requires an applicable safeguard and assessment. A guardian should not be asked to waive a child’s non-waivable privacy protections as a condition of basic service.

29. Questions, complaints and independent help#

A child, young person, guardian or representative may report a privacy or safety concern through the contact route with minimum identifying detail. SRC AI should provide an accessible response and verify authority before disclosing a record.

Depending on location, an external regulator, safeguarding body or court may also be available. The final responsible entity and jurisdiction contacts must be configured before production rather than invented here.

30. Educational institutions and professional participants#

If a future SRC Mentor service involves a school, tutor, mentor, clinician or other professional, the agreement must identify each party’s role, authority, access and responsibility. A professional title must be verified where material and does not give unrestricted access to a child’s family record.

Institutional instructions and guardian rights can differ by jurisdiction. SRC AI should not assume it acts as a school official, health provider or legal guardian merely because a professional uses the service.

31. Location, camera, microphone and device permissions#

A child or family feature should not request precise location, camera, microphone, contacts or device files unless the specific activity genuinely requires it and the interface explains the purpose at the point of use. Permissions should be off by default and revocable where practical.

Browser or device permission does not replace the product’s guardian and privacy requirements. Recorded media requires clear access, retention, moderation and deletion rules before collection.

32. Accessibility and inclusive family use#

Child and guardian information should be understandable and usable across relevant disability, language, literacy and device needs. A guardian should be able to request an accessible alternative without disclosing unnecessary diagnosis. Safety instructions and reporting must not rely only on color, sound or complex text.

Accessibility needs should not be used to infer unrelated traits or target promotion. Product testing should include representative users and document unresolved barriers before release.

33. Data quality and family correction#

Families and eligible young people should be able to correct material account, learning and authority information. The system should distinguish a changed preference from correction of an inaccurate historical record and preserve only the audit detail needed for safety and integrity.

A disputed inference should be marked and reviewed rather than repeated as fact. SRC AI may require a qualified human when a correction affects safeguarding or another person’s rights.

34. Product retirement and safe migration#

If a child or family feature ends, SRC AI should provide suitable notice, explain export and deletion, prevent new collection, preserve required safety or legal records and revoke Provider access. Families should not be forced to accept an unrelated new use to retrieve their information.

Migration to another service requires role, security, privacy and compatibility review. A successor must not receive child information simply because technical transfer is possible.