Studio
A supervised tool that lets middle-school students build real web pages by describing what they want. Used in class, with a teacher in the room, on a licence held by the school.
An AI writes the code. Students describe what they want and a large language model produces a web page. Every student sees this stated in the product itself, persistently — not as a notice they dismiss once. It gets things wrong, and noticing that is part of what the course teaches.
What we collect
No names. Not the student's, not a parent's, not an email address. Students
sign in with a project code — a word and four digits, like kite-9134 — and
the seat they are sitting at. There is no account, no password, and no profile.
The link between a child and their code lives on paper, held by the teacher, and is never written into our systems. We store what was typed and what was built; we do not store who typed it.
So the record looks like this
- The project code, and the seat used that day
- What the student asked for, and what the AI produced
- The pages they built, and the versions along the way
- Which safety category each request fell into, so a teacher can supervise
What we do not collect
- Names, emails, phone numbers, addresses, or photographs
- Anything about a student's behaviour, attention, or performance
- Anything a student does outside class — the Studio cannot build anything at home
Outside class, students can look but not build. A student can sign in at home to see the pages they already made and show them to a parent. They cannot ask the AI for anything new — that needs a teacher in the room, because the whole safety design depends on an adult being there.
If a student types personal information anyway, the system is built to notice and to leave it out of what gets built. We would rather it never arrived, and we plan for the fact that sometimes it will.
How long we keep it
Deletion is enforced by the database itself rather than by a job someone has to remember to run. The figures below are the outer ones, including the window in which a deleted record still sits in an encrypted backup.
| What | Kept for |
|---|---|
| Prompts and the session record | About three months, and gone entirely within seven |
| Projects and version history | The course, then about six months |
| Work published for a family showcase | About six months, then deleted automatically |
| Records flagged as a safeguarding concern | Kept until a school administrator releases them — see below |
| The paper list linking a name to a code | Held by the teacher, destroyed at the end of the course. Never in our systems. |
Safeguarding records are the deliberate exception. If a student writes something suggesting they may be at risk, that record is held until an adult at the school decides it can go. A system that quietly deleted those on a schedule would delete exactly the records that matter most.
Who can see a student's work
Three roles, and the differences between them are enforced by the software rather than left to policy.
| Role | Can see | Cannot |
|---|---|---|
| Teacher the adult in the room |
Everything their own class types, as it happens | Release a safeguarding record |
| School administrator principal, safeguarding lead |
Safeguarding concerns in full; any single transcript on request | Browse the class feed's contents routinely |
| Studio staff us |
System health, errors, and cost | Read student work as a matter of course |
When our staff do need to look at content — to investigate a fault a school has reported — it requires naming the school and stating a reason, and the record of that access is written before the content is shown. Those access records are never deleted.
Safety
Every request a student makes is checked before anything is built, and everything produced is checked again before the student sees it. Pages students build run in an isolated sandbox that cannot reach the internet at all — it cannot load outside images, scripts, or trackers, and cannot send anything anywhere.
If a student writes something suggesting they may be at risk of harm, the system does not try to counsel them. It tells them plainly that the adult in the room has been told, names that adult, and alerts the teacher within seconds. That is a person's job, not software's.
Compliance
Studio is built for middle-school classes — roughly ages 11 to 14, which in any real class means some students are under 13 and some are over. It is operated in compliance with the Children's Online Privacy Protection Act (COPPA), which applies to the younger ones.
We do not sort students by age, because we do not collect anything that would require it. No names, contact details, or persistent identifiers tied to an individual — for anyone, of any age. Working out who in a classroom is twelve and who is thirteen would itself mean collecting a birth date, and the stricter rule applied to everybody costs nothing when the answer is "nothing" either way.
Schools license Studio and control access to it. Students are enrolled by their teacher; there is no public sign-up and no way for a child to create an account. We comply with applicable child-safety and student-privacy law, and we will provide a school with any record we hold for one of its project codes on request.
Studio is built on Anthropic's Claude models and operated under Anthropic's requirements for organizations serving minors.
Questions
Parents: your child's teacher can show you exactly what your child has made and asked for, and can request the full record for their project code. That is usually the fastest route.
Schools, or anyone who would rather ask us directly: privacy@aibuilderlab.org.