COPPA AI controls mapping across legal duties and HTTP enforcement

COPPA AI controls mapping begins when a child-facing service collects personal information. In an AI tutor, text and voice can enter separate systems alongside profile context and device identifiers before an HTTP request reaches the model. One policy engine sees part of that route. The map needs a legal requirement and control point, plus an owner and test, with evidence and a remaining gap. I would pin it beside the architecture diagram, where a missing owner becomes visible before launch.

TL;DR

• Map each duty in 16 CFR Part 312 to a control point and accountable owner, with a test procedure and retained artifact.
• Keep scope and notice separate from consent and parental rights. Treat minimization and security separately from vendor assurance and retention.
• Use an HTTP gateway for policy on deliberately routed LLM requests. Supply identity context and content classification alongside the destination and decision evidence.
• Record partial coverage plainly. Embedded AI and local execution sit elsewhere, along with direct consumer use and parent verification. Contracts and database deletion also sit elsewhere.

Scope and audience map to the product boundary

The current text of 16 CFR Part 312 defines covered operators and children under age 13, plus collection and personal information. It also defines audience categories. Scope sits in product governance.

• Legal requirement: determine whether the operator and collection fall within the Rule's scope.
• Control point: product intake and audience design, supported by the age-screen flow and service inventory.
• Owner: privacy counsel with product management.
• Test: trace representative child and adult journeys, plus unknown-age journeys, into every collection channel.
• Evidence: approved scope memo and audience evidence, supported by marketing materials and the age-screen specification. Retain the data-flow diagram.
• HTTP boundary: a gateway can consume an upstream audience or age-policy attribute. It cannot determine legal coverage from a request alone.

Notice maps to the release process

The notice provision requires direct and online notices explaining collection and use, plus disclosure and recipients. The notices also explain purposes and retention.

• Legal requirement: give the required notice before covered collection and address material changes.
• Control point: privacy-content management and deployment approval.
• Owner: privacy operations, supported by product and engineering.
• Test: compare the effective notice against captured synthetic payloads and current providers. Check subprocessors and purposes against retention settings.
• Evidence: notice version and approval, supported by the delivery event and route inventory. Retain the change assessment.
• HTTP boundary: request records can identify the actual model destination and policy version. Notice drafting and delivery remain upstream controls.

The FTC's COPPA compliance guide is staff guidance rather than binding Commission text, and it gives practical detail for notices and other duties.

Consent maps to collection and disclosure gates

The consent provision generally requires verifiable parental consent before collection and use or disclosure, subject to exceptions. When applicable, the Rule requires a separate choice for non-integral third-party disclosure.

• Legal requirement: obtain the required consent and honor the authorized collection and use, plus the disclosure state.
• Control point: account activation and collection API, with the disclosure route and consent-state service.
• Owner: privacy operations for the decision; identity engineering for parent verification; product engineering for enforcement.
• Test: attempt covered collection with missing and valid states, then with revoked and disclosure-limited states using synthetic accounts.
• Evidence: parent-verification result and notice version, supported by authorized purposes and recipient choice. Retain the timestamp and revocation with test events.
• HTTP boundary: a gateway can enforce an application-supplied consent or purpose state against a model route. It cannot establish that the person consenting is the parent.

Parent rights map to identity and data retrieval

The parental-rights provision gives a verified parent a means to review the child's personal information and refuse further use or collection. The parent can also direct deletion.

• Legal requirement: authenticate the requesting parent and execute review and refusal, followed by deletion rights.
• Control point: rights portal and identity verification, supported by data discovery and the suppression service. Deletion orchestration completes the process.
• Owner: privacy operations with IAM and data owners.
• Test: complete an access and revocation case, followed by a deletion case, across the consent store and application. Include the model integration and support system alongside governed vendors.
• Evidence: request ticket and verification result, supported by the search manifest and response package. Retain the suppression state and deletion receipts with exceptions.
• HTTP boundary: a gateway may use a stable child or account reference to block future managed requests after revocation. The rights workflow and source-system deletion require separate systems.

Minimization maps to interface and payload design

The minimization provision limits conditioning participation on unnecessary personal information. Open text and voice can gather details outside a fixed schema.

• Legal requirement: constrain required collection to the approved need.
• Control point: interface copy and mandatory fields, supported by prompt templates and profile injection. Memory and request transformation complete the control.
• Owner: product, approved by privacy.
• Test: complete the activity without rejected fields. Then submit synthetic excess information and observe the designed treatment.
• Evidence: necessity analysis and field register, supported by the prompt-template version and UX test. Retain the policy event.
• HTTP boundary: prompt classification and redaction can reduce excess data in a routed LLM payload. Collection that already entered application storage still needs upstream minimization and deletion.

Student data privacy in EdTech AI shows how this control interacts with FERPA and vendor terms in schools.

Security and vendors map to the security program

The security provision requires a written program and coordinator, plus a risk assessment at least annually. It also requires safeguards and testing, followed by evaluation and relevant provider assurances.

• Legal requirement: maintain the program and apply reasonable steps plus assurances before relevant collection or maintenance, or release by another entity.
• Control point: security governance and architecture review, supported by provider onboarding and monitoring. Remediation completes the process.
• Owner: designated security coordinator and vendor management.
• Test: inspect current risk coverage and execute safeguard tests. Reconcile providers with observed routes and follow findings through closure.
• Evidence: program document and risk assessment, supported by the safeguard register and test output. Retain monitoring records and contracts, plus written assurances and remediation approvals.
• HTTP boundary: a gateway can enforce approved destinations and record routed traffic. Provider capability and written assurances remain adjacent controls alongside incident response and IAM. Endpoint security and opaque embedded inference also remain adjacent controls.

The AI vendor due diligence checklist covers the broader supplier review beyond request enforcement.

Retention maps to every repository

The retention provision permits purpose-bound storage, bars indefinite retention, and requires a written policy naming purposes and business need, plus a deletion timeframe.

• Legal requirement: apply purpose-bound retention and protective deletion.
• Control point: application database and prompt store, plus the model-provider account and analytics. Include the support copy and backup, alongside the consent system and audit repository.
• Owner: records management with privacy and system owners.
• Test: age synthetic records past the approved period and run deletion. Inspect downstream copies and review each exception.
• Evidence: written policy and configured schedules, supported by job logs and provider confirmations. Retain backup treatment and exception approvals, followed by the retest.
• HTTP boundary: a gateway can minimize its own evidence and attach expiry metadata. It has no authority to delete copies retained by the application or model provider.

The FTC's 2025 final rule amendments explain the updated security and disclosure provisions, plus the notice and retention provisions that took effect through the amended Rule.

The HTTP control row needs explicit prerequisites

For a child-facing application that deliberately routes authenticated HTTP calls to an LLM, the control row should name its inputs: originating user or agent identity and audience or age-policy context, plus approved purpose and consent-related state. Include child-data classification and model destination alongside versioned policy. The test set should include permitted and redacted events, plus denied and failed events. Include changed-policy events.

Evidence should record a stable event ID and supplied context, plus classification and destination. Record the policy version and decision alongside the timestamp and integrity data. The AI governance audit framework can place those events in a wider testing program. Coverage remains partial when the application omits context or a user calls the provider directly. It is also partial when a local model runs without HTTP routing or a vendor hides inference inside its own service.

DeepInspect

DeepInspect can implement the HTTP row for authenticated user or agent traffic deliberately routed to an LLM endpoint. The upstream application supplies identity and policy context. DeepInspect evaluates that context with prompt classification and destination under a versioned policy, then permits or redacts, denies or records the decision.

The resulting event can support a mapped test and independent request evidence. Embedded-vendor inference and local models remain assigned to adjacent controls, alongside direct unrouted calls and stolen credentials. IAM and parent verification remain adjacent controls, as do consent capture and notices. Contracts and deletion outside DeepInspect remain assigned to adjacent controls. Book a demo today.