Student-Centered AI in K-12: A Vendor's Perspective on What Policy Should Require

Seven principles for K-12 AI policy

1. Parent visibility is a default, not a feature

The first question a parent asks about a kid-facing AI tool is “what is my kid talking to it about?” The honest answer should not be hidden behind a settings menu, an upgrade tier, or a “request access” workflow.

Default visibility means: a parent can read their kid's full AI conversation history with no extra steps. Not a permissioned “kid shares with parent” model. Not a weekly digest. Not “available on request.” The parent is part of the audience the AI is talking to.

What this means for policy: vendors serving K-12 should publicly document whether parent visibility is default or opt-in, who the legal owner of conversation data is, and what (if anything) requires extra workflow to access. Default-visible should be the only structure approved for kid-facing AI under 13. Over-13 can be configurable with documented parental consent.

2. AI literacy is kid-as-director, not kid-as-consumer

The literacy gap right now isn't “kids don't know AI exists.” It's “kids consume AI output without exercising judgment.” A kid who pastes their essay prompt into a chatbot and submits the result has not practiced AI literacy — they've practiced credential laundering.

Real AI literacy is the practice of: specifying what you want, reading what AI produces critically, identifying where it's wrong, iterating, and taking responsibility for the final output. Kids who develop this become more capable. Kids who skip it become more dependent.

What this means for policy: K-12 AI experiences should require kid-as-director patterns — kids prompting, evaluating, revising, owning the outcome. Tools that produce single-shot outputs without iteration loops should not count toward “AI literacy” requirements, even if they're labeled as educational.

3. Safety is cascaded, not classifier-deep

A single safety classifier is a single point of failure. Real safety stacks several layers: input filtering (does the kid's prompt match a redirect pattern?), model-level guardrails (does the model itself know to refuse?), output filtering (does the response match a refusal pattern?), and parent visibility (does the parent see what happened?).

Most “AI safety” conversations stop at the model-level layer. That's the layer the vendor controls least — model behavior changes with every release. The layers under the vendor's full control (input filter, output filter, parent visibility) are the durable ones.

What this means for policy: vendors should publicly document the layers of their safety stack and what each is designed to catch. “AI safety” without specified layers is a marketing claim, not a practice. Districts evaluating vendors should ask for the layer diagram.

4. Data minimization beats data-processing agreements

Data-processing agreements (DPAs) tell you what a vendor will do with kid data once they've collected it. They don't tell you what data the vendor doesn't collect.

The kid-data a vendor never collects is the kid-data that can never leak, never get subpoenaed, never get sold during a vendor acquisition, and never appear in a future model's training set. Minimization is structural protection. DPAs are contractual.

What this means for policy: vendors should publish two lists — a data-collected list (every field stored about a kid, with why) and a data-not-collected list (every kid signal they could collect but deliberately don't, e.g. precise geolocation, voice biometrics, third-party tracking pixels). Districts evaluating vendors should weight minimization above contract language, because contracts are only as strong as the next vendor acquisition.

5. Equity in AI access does not mean uniform AI deployment

A district with two technology staff cannot self-build AI tools the way a district with twenty can. Mandating self-built or “open-source-first” approaches penalizes under-resourced districts. Mandating vendor-only approaches creates dependence and ongoing cost.

Equity-aware policy lets each district pick the deployment model that fits their capacity — vendor-managed with tight contracts, self-hosted with vendor support, or fully self-built — and shifts the regulatory bar to the principles each must meet (visibility, safety, minimization, age-adaptation), not the implementation pattern.

What this means for policy: avoid prescriptive deployment models. Require principles. A small district running a vendor-managed tool that meets the principles should be evaluated equally with a large district running its own.

6. Age-adaptive design is required, not optional

A 6-year-old's AI experience cannot be a smaller version of a 16-year-old's. Reading level, complexity, parent involvement norms, content filtering, and supervision expectations differ by 5-year band. Treating “K-12 AI” as one regulatory bucket misses this.

Vendors that ship a single experience for “kids” are usually shipping a teen experience that's been blocked-down for younger kids — which produces both bored 16-year-olds and confused 6-year-olds.

What this means for policy: vendor compliance should be evaluated per age band (K-2, 3-5, 6-8, 9-12), not “K-12 overall.” Vendors should publicly document how the experience adapts across age bands — reading level, parent-visibility defaults, allowed content categories, time-on-task norms.

7. Vendor practices should be publicly verifiable, not self-attested

Self-attested vendor security and safety claims are the lowest level of evidence. Public, third-party-verifiable practices (Common Sense Privacy Seal, SOC 2 reports, transparent architecture documentation) are higher. The gap matters because most district staff don't have time to verify vendor claims one by one.

What this means for policy: vendor evaluation rubrics should explicitly score evidence type for each claim — self-attested, public-documented, or third-party-audited — and weight them accordingly. A vendor that publishes its data architecture should be weighted differently from one that only claims to be “secure.”

Three additions worth considering

A working policy should give superintendents and procurement officers tools, not just principles. Three additions worth weighing:

• Sample RFP language a district can lift directly when evaluating AI vendors — covering visibility, age-adaptation, safety layers, minimization, and evidence type. Without this, every district reinvents the procurement wheel and most reinvent it badly.
• A safe-harbor framework: vendors that publicly meet the defined principles get fast-track district approval. This creates incentive for vendor compliance, not just enforcement after the fact.
• A 12-month re-review cycle built into the policy itself. AI capability changes faster than annual review can keep up. The policy should commit to revision on a 12-month cadence, with explicit ownership.

Three things we'd be cautious of

• Over-regulating use cases vs. practices. “No AI in ELA writing” is brittle — it dies the moment AI integrates into a word processor. “AI used in ELA writing must preserve student authorship via [specified mechanism]” is durable.
• Mandating specific vendors or tools. Creates lock-in and gives mandated vendors no incentive to improve. The policy should specify principles vendors must meet, not vendors districts must use.
• Conflating safety with restriction. Removing AI from kid use is restriction. Making AI safer for kid use is safety. They are different things, and districts that confuse the two end up with both more restriction and less safety.

An independent reference point: the Texas AI in Education Task Force

A vendor arguing for a strong policy floor invites a fair objection: of course you would — you built for it. So it is worth noting where an independent body, with no product to sell, reaches congruent conclusions.

In June 2026 the Texas AI in Education Task Force — convened by the University of Texas at Austin's Texas Advanced Computing Center under the Google.org-funded ALIGN project, and authored by a coalition of educators, administrators, parents, and industry and higher-education representatives — published Leading the Way in K-12 Education. Its framing converges with several of the principles above:

• Literacy is direction, not consumption. The report defines an AI-literate student as one who uses AI to “enhance their own personal skills and capabilities, not replace them” — to “brainstorm, get feedback, debug code, or improve a draft product rather than offloading critical thinking and production to AI tools.” That is principle 2, in a state task force's words.
• Banning is not protecting. The report is explicit that “even if AI student usage is banned in schools, students need to develop foundational AI literacy skills” — the same supervision-over-prohibition logic we describe above. A ban displaces the learning; it does not deliver it. Neither does open access: the OECD Digital Education Outlook 2026 reports that students with general-purpose generative AI produce better work, but that the advantage disappears — and sometimes reverses — on exams once access is removed, unless the AI is designed into the pedagogy. Blocking and unguided access fail the same way; what works is the child directing, checking, and correcting the tool.
• Guidance should be principle-based and procurement-aware. Among its four recommendations, the Task Force calls for statewide guidance covering “responsible use policies for both educators and students, data privacy, AI procurement and student assessment,” and for a leadership role with “built-in cycles of iteration, given the rapid pace of change” — echoing our notes on verifiable practices, data minimization, and a standing re-review cadence.

The Task Force's remit is different from ours: it advises state policymakers on leadership, teacher preparation, and learning standards — not vendor product design, which is our lane. We do not implement its recommendations, and we do not claim its endorsement. We cite it because the convergence is the point: when a neutral, university-convened coalition and a parent-visibility-first vendor independently arrive at the same student-centered principles, those principles are more likely to be sound — and worth encoding in the policy AASA and Day of AI are drafting.

Source: Torbey, R., Fletcher, C.L., De Jesús, S., & Antoine, A. (2026). Leading the Way in K-12 Education: Recommendations of the Texas AI in Education Task Force. Texas Advanced Computing Center, University of Texas at Austin.

About Xyplor

Xyplor is an AI maker for kids ages 6 to 17 — children build real, playable games and tools by directing AI, not by being tutored through answers. We default to parent visibility on every AI interaction (no opt-in step, no upgrade tier, no weekly-digest substitute), and practice COPPA-aligned design. There is no open chat and no contact from strangers: kids can message only a friend both parents have approved, every message is AI-moderated before delivery, anything flagged is surfaced to parents, and a parent can block any connection — and the one richer shared surface, a co-created project, is fully visible to both parents.

A safety-design point: supervision beats prohibition

Our original edition described Xyplor as having no kid-to-kid messaging at all. We have since shipped messaging deliberately — because a flat ban is weaker child safety than it looks. Children who want to talk to a friend about what they are building will do it somewhere; a ban simply pushes that conversation onto an unsupervised platform with no moderation and no parent visibility. Adesigned channel — gated behind dual-parent approval, machine-moderated on every message, and fully visible to parents — is the safer outcome. We flag this for policymakers: requirements should reward supervised, parent-controlled, auditable communication surfaces rather than mandate their absence, which predictably displaces the risk rather than removing it.

We wrote this paper because the policy AASA and Day of AI are drafting will define the procurement environment we operate in for years. Our incentive is for that policy to be good — strong on principles, evidence-weighted, age-adaptive, equity-aware — even where it raises our own bar.

We're at xyplor.com. This document is published under CC BY 4.0; quote, share, or adapt freely with attribution.