AI and COPPA Compliance: Children's Data in AI Systems

Children's privacy rules reach AI systems that knowingly collect data from children, and conversational products acquire that knowledge more readily than traditional ones. That makes age signal handling a design decision rather than a policy. This guide covers it, drawing on FISTA Solutions' AI agents work. This article is general guidance, not legal advice.

When do the rules apply?

Two routes in, and conversational products make the second one easier to trigger.

Route	What triggers it
Directed to children	Subject matter, design, audience
Actual knowledge	Knowing a specific user is a child
Age stated in conversation	Creates knowledge if logged
Third-party services on your product	Can bring obligations
General audience, no knowledge	Generally outside
Mixed audience	Fact-specific; get advice

Why does AI complicate the knowledge question?

Because conversational systems receive statements about age directly, and they log them.

A user mentioning their school year, their age, or their parent's permission is providing a signal. A product that captures that in a transcript while maintaining it has no knowledge of children using it is in a weak position, and the transcript is the evidence. Decide how to handle those signals deliberately.

What does verifiable parental consent require?

A method reasonably calculated to ensure the person providing consent is the parent, with several accepted approaches available.

It is a flow design constraint. Consent must come before collection, which means a product cannot start a conversation, detect a child, and then obtain consent for what it already collected. That sequencing has product consequences worth designing around rather than discovering.

How does minimisation apply?

It conflicts directly with the engineering habit of logging everything for debugging.

Collection must be limited to what is reasonably necessary for the activity, and retention to as long as needed. That reaches transcripts, prompt logs, and evaluation datasets — all of which teams keep indefinitely by default. Retention has to be enforced by scheduled deletion rather than stated in a policy.

What evidence do you need?

Notice and consent records, evidence of how age signals are handled, retention and deletion evidence covering transcripts and evaluation data, and documentation of what data is collected and why it is necessary.

If that evidence exists as a by-product of how systems are built and operated, you are in good shape. If it exists only as documents written for a review, you are not, and the difference is visible to anyone who looks carefully.

How does this change engineering practice?

It pushes age signal handling, consent sequencing, and enforced deletion into the design. The hardest of the three is sequencing: a conversational product that needs consent before collection has to structure the first interaction carefully.

Deletion is the most commonly failed. A retention policy the system does not enforce is worse than none, because it documents what should have happened and did not.

How does it interact with other regimes?

Usually more than expected. The same system can attract questions from a data protection authority, a sector supervisor, and a general AI regulator, each starting from a different premise and arriving at overlapping requirements.

One evidence base mapped to several requirements answers all of them. Separate programmes produce separate documents describing the same systems, and inconsistencies between them are themselves a finding.

What does compliance cost?

Mostly the cost of good engineering practice: evaluation, documentation, logging, and oversight design. Built into a project, the incremental cost is modest and much of it is work the system needed anyway.

Retrofitted onto a live system it becomes a project, performed under a deadline you did not choose, on something people already depend on. See AI compliance audit cost.

What are the common mistakes?

Logging age signals while claiming no knowledge. Obtaining consent after collection has started. Keeping transcripts and evaluation data indefinitely. And assuming a general-audience positioning removes the question.

Who owns this internally?

The function that owns the systems, with legal and compliance support. Ownership by compliance alone produces documents describing systems nobody changed; ownership by engineering alone produces good practice with no one accountable for the interpretation.

Name a person per system rather than a committee. Committees review; people decide.

What should you ask a supplier?

What documentation they provide about capabilities and limitations, what evaluation evidence they share, how they handle personal data, where processing happens, and what happens to your prompts and outputs.

Suppliers who have prepared answer those quickly. Suppliers who have not take weeks, and that delay is itself information about how the relationship will run.

How do you keep this current?

Assign someone to watch the sources that actually bind you rather than general commentary. Record what was checked and when, so the next review starts from a known point.

Rules in this area change, and a position taken eighteen months ago and never revisited is a risk in itself.

How do other regimes treat children's data?

More strictly in several places. Data protection regimes elsewhere set their own age thresholds for consent and impose additional duties around profiling and targeting children, and some codes of practice set design expectations for services likely to be accessed by children.

Products with international reach should design to the strictest applicable position rather than per market, because age-based variants are unusually error-prone.

What should you do first?

Search your transcripts and prompt logs for age signals. If they are there, you have knowledge, and the design question follows immediately.

How FISTA Solutions helps

FISTA Solutions builds AI systems so the evidence exists when it is needed: age signals handled deliberately rather than logged and ignored, retention enforced by scheduled deletion across transcripts and evaluation data, evaluation results dated and versioned, oversight designed structurally rather than asserted in policy, and documentation produced during the build rather than reconstructed afterwards. Delivery runs through AI enablement, AI agents, and forward deployed engineers. The record is 150+ projects for 50+ companies across 12+ countries.

To align a system with these requirements, message FISTA on WhatsApp, or read AI and GDPR data subject rights.