AI Subprocessor Disclosure Obligations for Children's Apps: What EdTech Operators Must Know Under COPPA

The COPPA Operator Chain — When Your AI Vendor Becomes a Covered Operator

Every AI tool in your EdTech stack sits somewhere on a COPPA classification spectrum. At one end: a service provider that processes children's data on your behalf, constrained to your instructions, and treated under the law as an extension of your own data operations. At the other end: a covered co-operator with independent notice, consent, and liability obligations. Where your AI vendor lands depends on two questions you control — and most EdTech founders are not asking either of them.

The first question is whether the vendor has received actual knowledge that it is processing data from a children's directed service. Under the FTC's guidance on third-party operators, actual knowledge exists when (1) you — the child-directed first party — directly communicate that your app is directed to children under 13, or (2) a representative of the vendor itself identifies your service as child-directed. This matters because the trigger is not the data itself. It is what you tell the vendor. If your API onboarding documentation, DPA cover letter, or system prompt metadata discloses that users are under 13, you have likely conferred actual knowledge on the vendor — and with it, potential co-operator status under COPPA.

The second question is whether the vendor's data use stays within the contracted function. Under 16 CFR § 312.2, a vendor that collects and maintains children's data on your behalf is treated as acting as you — not as an independent third party — but only so long as it refrains from using that information for any purpose outside the specific contracted activities. The statute is explicit: no behavioral advertising, no individual profile creation, no secondary uses. Once the vendor exceeds those limits, it does not remain a service provider. It becomes a third party. And if it has actual knowledge of the children-directed nature of your platform, it becomes a covered operator.

The FTC developed the actual knowledge doctrine in the context of ad networks and plug-ins, not LLM APIs. Whether the same analysis applies to OpenAI or Google Gemini when an EdTech operator's API metadata discloses child-directed usage is an open legal question — but it is not a safe one to leave unresolved. The compliance burden starts with you. COPPA makes the operator of the children's directed service responsible for vendor conduct, which means your liability for an AI vendor's unauthorized data use does not depend on whether the vendor knew better.

What COPPA's Privacy Notice Must Disclose About Third-Party Data Sharing

A privacy notice that says "we use third-party services to improve your experience" does not satisfy COPPA. Neither does one that names categories of vendors without identifying them. The regulatory floor under 16 CFR § 312.4 is specific: your online privacy notice must identify by name or category every third party to which you disclose children's personal information and must state the purpose of each disclosure. If your reading app sends student query data to an OpenAI API endpoint, OpenAI — or at minimum the category "AI language model providers" — must appear in your privacy notice with a stated purpose.

The 2025 COPPA amendments add a second disclosure track on top of this baseline. You now have two distinct notice obligations:

• Online privacy policy (persistent): The public-facing policy on your website and app must identify all third-party AI vendors by name or category, describe the purpose of each disclosure, and include a prominently labeled link on every page where children's data is collected — not buried in a footer. Under 16 CFR § 312.4, that link must appear "in close proximity to the requests for information."
• Direct parental notice (at collection): The notice delivered to parents before you collect their child's data must now identify third-party recipients by both name and category and specify the disclosure purpose. "Third-party analytics and AI services" is no longer sufficient. Parents must be told it is OpenAI, it is the Google Gemini API, and the purpose is reading comprehension personalization — before they consent.

One common misconception: relying on the support-for-internal-operations exception does not eliminate notice obligations. It redirects them. Under the 2025 amendments, operators relying on the exception to justify processing persistent identifiers without parental consent must now specify in their privacy notice which internal operations justify the collection and describe the safeguards preventing misuse — including how those identifiers will not be used for behavioral advertising or profile building. The exception is a consent bypass, not a disclosure bypass.

Audit your privacy notice against these standards before your next app update. If your AI vendor stack changed and your notice did not, you have a live compliance gap — not a future one.

The 2025 FTC COPPA Rule Update — How It Changed Subprocessor Treatment

The FTC's amended COPPA rule was published in the Federal Register on April 22, 2025. It became effective June 23, 2025. Operators have until April 22, 2026 to comply. If your EdTech product is in development, soft launch, or already shipping, that deadline is not abstract — it is an operational calendar item.

The most consequential change for AI-powered children's products is the FTC's definitive statement on model training. The agency was explicit: "Disclosures of a child's personal information to third parties…to train or otherwise develop artificial intelligence technologies, are not integral to the website or online service and would require consent." This is not an inference from regulatory structure. It is a direct FTC ruling. AI training is categorically excluded from the support-for-internal-operations exception. Routing children's data to any AI vendor for model training — whether that vendor is a startup or a major platform — requires separate verifiable parental consent beyond the general COPPA consent you already obtain. There is no workaround through contract structure.

The 2025 amendments also impose two new operational obligations that directly affect how EdTech teams manage AI subprocessors:

• Written assurances: Before sharing children's data with any third party, operators must take reasonable steps to verify the third party's data protection capabilities and obtain a written commitment that the third party will maintain the "confidentiality, security, and integrity" of children's data. A standard click-through API terms acceptance does not satisfy this. It requires a signed DPA addendum with security commitments specific to the children's data use case.
• Written information security program: For the first time, COPPA mandates a formal, documented ISMP. Operators must designate security coordinators, conduct regular risk assessments, test safeguards, and perform annual program evaluations. This ISMP must address how AI subprocessors are vetted and what contractual security controls they are subject to.

One open question the FTC did not resolve: whether the new AI-training consent requirement applies retroactively to children's data collected before June 23, 2025. That gap requires counsel analysis for any operator with historical training data from its user base. Similarly, whether standard AI vendor DPAs from major platforms satisfy the new written assurance standard has not been formally addressed — a live compliance question for every team currently relying on click-through API agreements.

The 'Support for Internal Operations' Exception — What It Covers and What It Doesn't

The support-for-internal-operations exception is the mechanism that lets EdTech operators route children's data through AI vendors without triggering the full COPPA third-party disclosure and consent regime — but only if the vendor's data use stays within a defined perimeter. That perimeter is not a matter of contractual drafting. It is a matter of what the vendor actually does with the data.

Under 16 CFR § 312.2, the exception covers a specific enumerated list of activities: maintaining website functionality, performing network communications, authenticating users, personalizing content, serving contextual (not behavioral) advertising, protecting security and integrity, ensuring legal compliance, and fulfilling child requests as permitted by the rule. AI functions that map cleanly onto these categories — fraud detection, content recommendation based on in-session behavior, login authentication — have a plausible claim to the exception. AI functions that do not appear on this list require separate analysis.

The 2025 amendments drew explicit bright lines on what the exception does not cover:

• Targeted advertising: Categorically excluded. Requires separate parental consent.
• Building user profiles for third parties: Categorically excluded. Requires separate parental consent.
• AI model training and development: Categorically excluded. The FTC ruled it non-integral regardless of who benefits from the training.

Two important nuances the 2025 amendments left unresolved. First, the FTC declined to restrict "engagement-driving techniques" as a prohibited internal operation — so AI-powered adaptive learning and recommendation engines remain technically within the exception's text — but the FTC explicitly reserved enforcement rights under FTC Act Section 5 for unfair practices. That is not a safe harbor; it is an enforcement warning. Second, the line between "personalizing content" (a qualifying activity) and "building an individual profile" (a disqualifying activity) has not been applied to adaptive learning algorithms. If your AI personalization engine builds persistent learner profiles that exceed the in-session context, that characterization question carries real enforcement risk.

The 2025 amendments also added a notice obligation for operators relying on the exception: your privacy notice must now specify the exact internal operations for which persistent identifiers are collected and describe the safeguards preventing unauthorized use. Generic language — "we use identifiers to improve your experience" — no longer qualifies.

Structuring Data Processing Agreements with AI Vendors to Preserve the Exception

The 2025 COPPA amendments made vendor contracts load-bearing compliance infrastructure. The written assurance requirement is not a best practice — it is a precondition. Before any children's personal information flows to an AI vendor, you must obtain a signed commitment that the vendor will maintain the "confidentiality, security, and integrity" of that data. A standard API terms acceptance does not satisfy this. If your AI vendor relationship currently rests on click-through terms, you have an open compliance gap that must be papered before the April 22, 2026 deadline.

A COPPA-compliant DPA with an AI vendor should be structured in four layers, each mapping to a specific regulatory obligation:

1. Purpose limitation: The vendor may use children's data only for the contracted function — reading comprehension personalization, fraud detection, content moderation — and nothing else. This clause preserves the support-for-internal-operations exception by ensuring the vendor's data use stays within the enumerated activities.
2. Training prohibition: An explicit prohibition on using children's data to train, fine-tune, or otherwise improve the vendor's own AI models. This maps directly to the FTC's ruling that AI training is non-integral and requires separate parental consent — consent your DPA should make structurally impossible to trigger without your affirmative action.
3. Retention and deletion: Documented retention periods tied to operational necessity, with deletion schedules for data no longer needed. Commissioner Bedoya was direct: algorithm improvement claims do not override COPPA's prohibition on indefinite retention. Your DPA must set a number, not a policy aspiration.
4. Security assurances and audit rights: The written assurances required by the 2025 amendments. Include flow-down obligations for any subprocessors the AI vendor engages — if OpenAI uses a cloud logging provider, that provider's access to children's data must be subject to the same constraints.

On the major platforms: OpenAI's default API configuration does not use customer data for model training, but default abuse-monitoring log retention runs up to 30 days. For children's apps, that default retention may itself constitute unauthorized data retention under COPPA. Zero data retention — which requires sales-team approval and acceptance of additional requirements — must be specifically negotiated before deploying the API in an under-13 context. OpenAI makes this explicit: you should not use their services to process personal data of children under 13 without first implementing ZDR. Google Vertex AI and Gemini API offer comparable no-training commitments, but ZDR is not the default configuration — it requires a separate application. Neither platform's standard enterprise DPA was designed against the 2025 COPPA written assurance standard, making a COPPA-specific addendum the appropriate structure for each.

What Happens When an AI Vendor Uses Children's Data for Model Training

The legal consequence is unambiguous. Under the 2025 COPPA amendments, disclosing children's data to an AI vendor for model training purposes is a non-integral third-party disclosure that requires separate verifiable parental consent. If your vendor is training on children's data and you have not obtained that specific consent, you are in violation of COPPA — regardless of what the vendor's own terms say about data use. The operator bears the compliance obligation. The vendor's conduct is your liability.

The enforcement analogy is direct. In the FTC's action against Apitor — a robotic toy maker — the agency pursued the operator for allowing a third-party Chinese analytics provider to collect geolocation data from children without parental consent. The settlement required a $500,000 penalty and a mandatory vendor oversight program, including disgorgement of unlawfully collected data. The analytics provider's conduct was attributed to the operator. An EdTech company whose AI vendor trains on children's data without consent faces the same theory: you enabled the unauthorized collection by routing the data to the vendor, and you are responsible for constraining what the vendor does with it.

The FTC's September 2025 enforcement activity signals that AI-specific COPPA enforcement is not hypothetical. The agency settled a $10 million action against Disney for third-party data collection without proper parental consent, and in the same month launched a formal Section 6(b) inquiry into AI chatbot companies' data practices with children — issuing orders to seven companies. The chatbot inquiry makes explicit that the FTC is actively investigating how AI platforms handle children's conversational data. EdTech operators whose products involve AI-mediated student interaction are directly within that enforcement aperture.

A secondary risk layer exists for major platform vendors. When an EdTech operator's onboarding process, API metadata, or DPA cover letter communicates that the platform serves children under 13, and the vendor then uses that data for model training, the vendor may itself become a covered COPPA co-operator — with independent notice and consent obligations. That theory remains untested in the AI context, but the underlying FTC guidance on actual knowledge and co-operator status does not have a carve-out for LLM providers. OpenAI's developer policy acknowledges this risk directly: it prohibits using its API to process under-13 data without ZDR enabled and reserves audit rights and API termination for non-compliant customers. Non-compliance creates layered exposure — COPPA violation, API termination, and potential contractual breach — simultaneously.

Two Compliance Scenarios and a Pre-Launch Checklist

Scenario 1 — Compliant: An educational reading app uses the OpenAI API to power a reading comprehension personalization feature. Before launch, the team negotiated zero data retention with OpenAI's sales team and executed a signed DPA addendum that (a) limits data use to reading personalization only, (b) prohibits model training on student data, (c) sets a 30-day deletion schedule for session logs, and (d) requires security commitments meeting the 2025 COPPA written assurance standard. The privacy notice names OpenAI as a service provider, states "reading comprehension personalization" as the data use purpose, and includes a prominently linked privacy policy on every collection screen. Parental consent was obtained for the underlying data collection. No separate AI-training consent is needed because the vendor's contracted use is integral to the service — and the DPA makes training structurally prohibited. This structure preserves the support-for-internal-operations exception at every layer.

Scenario 2 — Non-Compliant: A tutoring app routes student conversation logs through an LLM API to generate personalized feedback. The team accepted the vendor's standard click-through API terms without a signed DPA. The privacy notice states "we use third-party AI services to personalize your experience" without naming the vendor. The API's default log retention runs 30 days and the team did not negotiate ZDR. No separate consent was obtained for any non-integral use. When the vendor's default configuration logs conversation data for abuse monitoring, that retention constitutes unauthorized data processing under COPPA. The privacy notice fails the 2025 identification-by-name requirement. The operator has breached OpenAI's developer policy and is simultaneously exposed to COPPA enforcement. Post-launch remediation — revised notices, retroactive DPA negotiation, potential consent recollection, data disgorgement — is substantially more expensive than pre-launch diligence.

Pre-Launch AI Vendor Checklist (apply at three stages):

Vendor Selection:

• Does the vendor offer zero data retention for under-13 deployments? If yes, is it self-serve or does it require separate approval?
• Does the vendor's standard DPA prohibit model training on customer data? Is that prohibition specific enough to cover fine-tuning and derivative training?
• Does the vendor identify its own subprocessors and subject them to flow-down data protection obligations?

DPA Execution:

• Is there a signed DPA addendum (not click-through) with purpose limitation, training prohibition, retention schedule, and 2025 COPPA written assurance language?
• Does the DPA require the vendor to notify you of any security incident affecting children's data within a defined timeframe?
• Does the DPA include deletion assistance obligations for parental deletion requests?

Pre-Launch Notice Review:

• Does your privacy policy name every AI vendor by name or category and state the purpose of each disclosure?
• Does your parental consent notice identify AI vendors by both name and category, as required by the 2025 amendments?
• If you rely on the support-for-internal-operations exception for persistent identifiers, does your notice specify the exact operations and describe the safeguards against misuse?
• Are privacy notice links placed prominently on every screen where children's data is collected — not only in the footer?

The April 22, 2026 compliance deadline for the 2025 amendments is not a future horizon for teams shipping today. If your app is in development or soft launch, these requirements apply to your current architecture — not to a future version.