06-reference/research

coppa third party ai operator disclosure

2026-09-04·research-brief·source: deep-research·by Ray Data Co (deep-research synthesis)
scribble-workscoppaprivacyai-vendorslegal

Does piping Customize input to xAI trigger COPPA's third-party-disclosure rules?

Not legal advice. This is regulatory research against primary sources. It tells the founder what the Rule says and where our build already sits against it; it does not tell him what a court or the Commission would hold. The point at which a privacy attorney stops being useful and becomes necessary is named at the end of the synthesis.

The question

Verbatim: "Does routing a child's Customize input through a third-party AI image vendor (xAI Grok Imagine via the Cloudflare AI Gateway) trigger COPPA's third-party-operator disclosure/consent requirements, distinct from the parent-vs-teacher consent-class question already resolved?"

Context: Customize Stage 3 (art slots, the PAID generation tier) is in active build. [[2026-09-01-second-loop-proposal]] resolved who can consent; this asks whether the vendor hop is a separately-regulated event.

Headline: conditional — and on the architecture as built, all three conditions point away from a trigger. No separate verifiable parental consent is required for the xAI hop today. But the question aims at the wrong vendor (the raw parent sentence goes to Anthropic; xAI gets a schema-bounded derivative that is almost certainly not "personal information" under §312.2), and the real exposure it surfaced is contractual rather than regulatory: xAI's Enterprise ToS §12.2 has RDCO warranting that it does not send personal data at all, and expressly declines the subprocessor duties that §312.8(c) would otherwise let us paper over.

What we already know (from the vault)

What the web says

Primary text pulled directly from eCFR on 2026-09-04 (WebFetch is blocked on ecfr.gov; retrieved via curl with a browser user-agent against the eCFR renderer API). Part 312 source note: "78 FR 4008, Jan. 17, 2013, as amended at 90 FR 16977, Apr. 22, 2025." The 2025 amendments carried a general compliance date of 2026-04-22, which has passed — the amended Rule is in force today.

What the vendors' terms actually say

All retrieved 2026-09-04. The vendor is now legally "SpaceXAI LLC" across its legal documents; contracts and the privacy page should name that entity, not "xAI, Inc." (x.ai returns 403 to curl and WebFetch; these were retrieved via a browser.)

Convergences and contradictions

Synthesis for RDCO

The answer is conditional, and it resolves in RDCO's favour on the art rail, but for a reason nobody had written down, and it points at the wrong vendor. Reading the code rather than the spec, the Stage 3 path applies a structural bottleneck between the parent and xAI that the vault has never credited. src/lib/customize/art.js defines a closed brief schema (subject and setting as length-capped plain phrases, nouns[] as three to six entries each matching a letters-only regex, additionalProperties: false), validated by validateBrief(), which additionally rejects markup, PII and template tokens and runs a banned-word screen. buildImagePrompt() then composes those fields into a fixed template: "A coloring page of {subject}, with {setting}. Visible in the picture: {nouns}." plus a constant style line. The parent's sentence never reaches xAI. What reaches xAI is a machine-written description of a drawing. Against §312.2's enumerated definition, "a friendly smiling stegosaurus / a volcano in the background / ferns, rocks" is not personal information: not a first-and-last name, not contact information, not a persistent identifier. And because the call is server-to-server from a Worker, the end-user IP does not travel either; it is hashed locally with CUSTOMIZE_SALT for the rate gate and never forwarded. No personal information released means no "release of personal information... in identifiable form," which means no disclosure under §312.2 regardless of what xAI's terms permit. The training-rights question, which the dispatch correctly identified as decisive in the abstract, turns out not to be reached on this rail.

The exposure that does exist is on the text rail, to Anthropic, and the question inverted it. functions/api/customize.js:307 sends the scrubbed about string to Anthropic. The privacy page is admirably blunt about the residual hole: the name-stripping "only covers the name box. If you type a name inside your sentence — 'Mae is 4 and loves horses' — our code does not spot it, so that name goes to the model." The Customize spec's own behaviour-critic fixtures do exactly this ("Se llama Mateo, tiene 4 años", "Twins, Ava and Leo"). So free-text about a named child reaches Anthropic. Even there the analysis is not obviously lost (a first name without a last name is not enumerated PI, and item 11 needs an identifier to combine with) but it is a far thinner argument than the art rail's, and it is the one worth taking to counsel. The secondary residual on the art rail is narrower and cheap to close: the nouns[] regex is letters-only, which admits a first name, so a text-pass failure that emitted "Mae" as a noun would put a name in front of xAI. Screening the brief against the name field before dispatch would make the art rail's argument airtight by construction rather than by the model behaving.

The training question, the one the dispatch called decisive, resolves in our favour, but not cleanly, and it was the second-most-important thing on the page. xAI's Enterprise ToS §3.1 disclaims training on User Content by default, with no opt-out required. Had the analysis run off the consumer Grok terms, which train by default and take "full rights" from logged-out users, it would have reached the opposite answer; the consumer/enterprise split is the trap here, and the API traffic is squarely enterprise. Two qualifiers keep this from being an unconditional SFIO fit. §3.1's own trailing clause, "subject to disclosures to Customer and Customer-controlled user settings", lets a future disclosure or toggle re-enable training without a contract amendment, so the commitment is revocable by notice. And §3.3 reserves the right to use "de-identified and/or aggregated data derived from Customer's use of the Services" for "any lawful purpose" unless we are on the Zero Data Retention API. Against §312.2's SFIO proviso, which forbids use "for any other purpose" full stop, "any lawful purpose" is the wrong shape even when de-identified. So: if personal information ever did travel to xAI, whether xAI qualifies as an SFIO provider is genuinely unsettled, and I am not going to manufacture certainty about it. Here the calibration has to be precise, because two different tests are easy to blur. On the "integral" test under §312.5(a)(2), the FTC has spoken: the 2025 preamble at 90 FR 16950 says disclosures "to train or otherwise develop artificial intelligence technologies, are not integral" and require separate consent, while disclosures "necessary to provide the product or service the consumer is asking for are integral" — which is what generating the picture a parent asked for plainly is. That is as close to on-point as the record gets, and it favours us. On the distinct SFIO / "third party" test under §312.2, the FTC has said nothing. The structural inference the Rule supports is clear enough (SFIO status is destroyed by any use "for any other purpose," and training is plainly another purpose) but the Commission has never said this in terms, and no enforcement action in Jan 2024 through Sep 2026 addresses a third-party AI vendor at all. The nearest case, U.S. v. Amazon (Alexa, 2023), is first-party. Anyone who tells the founder this is settled is guessing. A sobering counterweight to file next to the favourable reading: xAI is one of seven recipients of the FTC's September 2025 6(b) orders on AI companion chatbots, which demand exactly the training-corpus and third-party-sharing detail this analysis turns on. One more conflation to avoid: cf-aig-collect-log: 'false' is not a vendor commitment. It governs Cloudflare's logging, not xAI's use of the payload, and Cloudflare's Service-Specific Terms say in terms that its DPA and Information Security Exhibit "do not apply" to third-party products reached through AI Gateway. There is no processor cover on the xAI leg. Relatedly, gateway logging is on by default and we suppress it per-request, so our resting state is weaker than the spec's "logging OFF" phrasing implies.

The genuinely new finding is contractual, not regulatory, and it cuts both ways. xAI Enterprise §12.2 has the customer "represent and warrant that it will not intentionally submit... any Personal Data to the Services except through SpaceXAI's ZDR-Enabled API," and states that xAI "will lack the information necessary to fulfill many obligations typically imposed on a subprocessor under a data processing agreement." Read that against the plan of record. The good news: it corroborates the architectural conclusion from the outside — RDCO has already warranted that the standard rail carries no personal data, and the brief-schema bottleneck is what makes that warranty true rather than aspirational. The bad news: §312.8(c) written assurances are probably not obtainable from xAI on the standard rail, because xAI has pre-emptively declined the posture those assurances describe. That closes off the cheapest item on the 2026-09-02 "adopt regardless" list by the ordinary route. The available route is the ZDR-Enabled API: one-hour deletion, no logs, no backups, no persistent copies, and it also extinguishes the §3.3 de-identified-data carve-out. ZDR is the single configuration change that would convert a defensible position into a documented one, and the dispatch's own hypothesis (that a no-retention configuration changes the analysis) is correct: it does, though by removing a contractual carve-out rather than by changing what is legally a disclosure.

What to actually do, in cost order. None of this is blocking, and nothing here requires a consent build. (1) Price and evaluate the xAI ZDR-Enabled API for the art rail. It is the only path to a §312.8(c)-shaped assurance from that vendor, and it collapses retention from 30 days to one hour. (2) Close the nouns[] name gap: the letters-only regex admits a first name, so screen the brief against the name field before dispatch; that makes the §12.2 warranty true by construction instead of by the text pass behaving. (3) Amend the charter's "not exposed to third parties" line to match the privacy page, which already names both vendors and their purposes and is close to what amended §312.4(d)(2) requires; the charter's current wording is a misrepresentation waiting to migrate into marketing copy, where FTC Act §5 reaches it independent of COPPA. While there, update the vendor's legal name to SpaceXAI LLC. (4) Write the §312.8(b) security program: a named coordinator, an annual risk assessment, in a document; a one-person LLC still needs the paper. (5) Set cf-aig-collect-log-payload: 'false' alongside the existing flag as belt-and-braces; the docs say the existing flag already supersedes it, so this is defence in depth, not a fix. What does not need doing is a separate verifiable-parental-consent flow for the xAI hop. Nothing in the current architecture releases personal information to xAI, and building a §312.5(a)(2) separate-consent gate for a disclosure that is not occurring would be the consent layer's bear case, "the expensive half that buys nothing a customer can see", realised for no reason.

When counsel stops being useful and becomes necessary. Not now, and this question does not on its own justify unparking the outreach the founder paused on 2026-09-02 18:30 ET. It collapses into the same predicate already scoped as question 1 of the [[2026-09-02-counsel-shortlist]] engagement: if the site is not "directed to children," none of the disclosure machinery opens. Adding a third sub-question to that one engagement costs almost nothing; opening a second engagement for the vendor hop would be paying twice for one answer. The line at which an attorney becomes necessary rather than useful is before the paid tier takes money from its first non-household customer, because paid billing plus v2 child-profile fields is the first moment a commercial relationship and stored child-adjacent data coexist, and because §12.2's warranty is a representation RDCO is making to a counterparty, which is a lawyer's question rather than an engineer's. The sub-question to add: given that the art rail sends only a schema-bounded, PII-screened image brief and the text rail sends a scrubbed parent sentence that may contain a child's first name, does either constitute a "disclosure" of "personal information" under §312.2 as amended, and is xAI's Enterprise ToS §3.1/§3.3 sufficient for "support for the internal operations" treatment?

Why this is in the vault

This unblocks Customize Stage 3, the paid generation tier in active build: it says a separate parental-consent gate for the xAI hop is not required by the current architecture, so the tier is not blocked on a consent build, and it converts the open item into three cheap paper tasks. It also corrects the record on which vendor carries the residual risk (Anthropic on the text rail, not xAI on the art rail), which changes what the counsel engagement in [[2026-09-02-account-relationship-model-decision]] §6 row 0 should ask.

Open follow-ups

Related

Sources

Vault

Code read directly (repo ~/Projects/scribble-works, 2026-09-04)

Primary regulatory sources

Vendor terms (all retrieved 2026-09-04; x.ai returns 403 to curl/WebFetch, retrieved via browser)

Not verified / flagged