Skip to main content

Children's Data in AI: COPPA and GDPR-K Compliance Implementation

Children's Data in AI: COPPA and GDPR-K Compliance Implementation

Children's data creates a stricter AI boundary because the risk model changes before you ever ask whether the answer is useful. Student records, ages, parental contact details, and classroom context all make the prompt itself more sensitive. Keeptrusts supports a practical control stack for this: student-privacy to catch student-record markers and under-13 age text, gdpr-compliance to require consent signals and optional verification, pii-detector to redact common identifiers, and data-routing-policy to keep minor-related traffic on the narrowest provider path.

Use this page when​

  • You govern AI features for education, youth products, or family-facing workflows.
  • You need a runtime pattern for parental consent, student-record detection, and zero-retention routing.
  • You want a concrete implementation that stays within current Keeptrusts capabilities.

Primary audience​

  • Primary: Technical Engineers and privacy owners
  • Secondary: Technical Leaders, AI Agents

The problem​

Children's-data compliance fails quickly when teams assume ordinary PII redaction is enough.

It is not enough to redact a name if the prompt still contains a transcript reference, a student identifier, an IEP marker, or a clear under-13 context. In many education and youth scenarios, the mere fact that the record belongs to a child changes the legal and operational threshold.

There is also an age-context problem. Keeptrusts documents a very specific implementation detail in Student Privacy: age_gate keys off age text in the message body, not a hidden user profile. That means the application has to carry the relevant child context explicitly into the governed request if it expects the age gate to fire.

Finally, children's-data workflows often mix multiple requirements at once: parental consent, student-record detection, structured identifier redaction, and provider-side retention limits. Treat those as separate checkboxes and something will eventually slip between them.

The solution​

Use the current Keeptrusts controls for what they are best at.

Use Student Privacy to detect student-record keywords and patterns, and enable age_gate: true so under-13 content is forced to block when the age appears in message text.

Use Compliance Policies Configuration and gdpr-compliance to require a consent token header and verify it externally. In family and school settings, that creates an auditable boundary between approved and unapproved processing.

Use PII Detector to redact common identifiers that may still appear in valid educational workflows.

Use Data Routing Policy so child-related traffic is sent only to providers that meet the retention and training constraints you are willing to accept.

That stack aligns well with the operational guidance in EdTech and Privacy Officer, but the actual enforcement happens in the policy chain.

Implementation​

This example routes under-13 student traffic through its own consumer group and applies consent, student-record, redaction, and provider-handling controls together.

pack:
  name: minors-ai-governance
  version: "1.0.0"
  enabled: true

providers:
  targets:
    - id: student-safe-zdr
      provider: openai
      model: gpt-5.4-mini-mini
      secret_key_ref:
        env: OPENAI_STUDENT_KEY
      data_policy:
        zero_data_retention: true
        training_opt_out: true
        retention_days: 0
        in_memory_only: true
        sanitized: true
        accepts_tokenized_input: true
        allow_internet_egress: false
        local_only_processing: true

consumer_groups:
  key_header: Authorization
  groups:
    - name: student-portal-under-13
      api_keys:
        - "sha256:be9d587defa1f0c09ef49eb17e206983a5f8f8289e4281860bd0ee5a19592c67"
      upstream: student-safe-zdr
      chain:
        - gdpr-compliance
        - student-privacy
        - pii-detector
        - data-routing-policy
        - audit-logger

policy:
  gdpr-compliance:
    consent_required: true
    consent_header: X-Parent-Consent-Token
    consent_verification_endpoint: https://privacy.internal.edustack.net/verify-parental-consent
    erasure_webhook: https://privacy.internal.edustack.net/minor-erasure
    data_categories:
      - personal
      - child
      - education
    retention_days: 30
    timeout_ms: 2500

  student-privacy:
    action: block
    age_gate: true

  pii-detector:
    action: redact
    detect_patterns:
      - 'STU-\d{6}'
      - 'CLASS-\d{4}'
    redaction:
      marker_format: label
      include_metadata: true

  data-routing-policy:
    require_zero_data_retention: true
    require_no_training: true
    max_retention_days: 0
    sanitize_before_provider: true
    tokenize_sensitive_fields: true
    allow_internet_egress: false
    local_only_processing: true
    on_no_compliant_provider: block
    log_provider_selection: true

  audit-logger: {}

The most important operational detail is the age signal. Because student-privacy looks for age text inside the message body, the application should inject a short governed context string such as Student context: age 12. when the request belongs to an under-13 workflow. Do not assume the gateway can infer this from a user profile it never receives.

The consumer-group split is also useful. It ensures that minor-facing traffic is not casually mixed with general educational traffic using the same key and chain. In practice, that lowers the chance that a less-governed surface accidentally inherits a more sensitive workload.

Before rollout, lint the config and test representative requests, especially ones containing student id, transcript, iep, or inline age text. The goal is not to prove a theoretical compliance story. The goal is to show that the exact requests you worry about actually block, redact, or route as intended.

Results and impact​

This pattern gives teams a much clearer answer to a difficult question: what happens when child-related data reaches the AI boundary?

Consent is checked, student-record markers are inspected, structured identifiers are redacted, and provider eligibility is narrowed before the request proceeds. That is a much stronger posture than saying the application should probably have been careful.

It also improves collaboration between product, privacy, and platform teams because each team can see where its responsibility begins and ends.

Key takeaways​

  • Use Student Privacy for student-record keywords and under-13 age gating.
  • Carry age context explicitly in the request body when you depend on age_gate.
  • Use gdpr-compliance to enforce parental or guardian consent signals on the governed path.
  • Keep child-related traffic on the narrowest provider route with Data Routing Policy.
  • Separate minor-facing traffic from general traffic with its own consumer-group identity whenever possible.

Next steps​