England named thirteen specific tests for safe classroom AI

The classroom note

A business manager asked to sign off on a new AI tool before it reaches a classroom is usually working from a sales page, not a specification. Reading the documents that actually define "safe" and "interoperable" for this sector, as retrieved on 16 September 2026, turns that sign-off into a list of specific things a vendor can be asked to demonstrate, rather than a general assurance to trust.

What the evidence says

The Department for Education's generative AI product safety standards, updated 19 January 2026, set out named requirements rather than a general promise: products should "effectively and reliably prevent users from accessing harmful or inappropriate content," be "compliant with relevant data protection legislation," and "not store, collect or use intellectual property created by learners...for any commercial purposes." A 2026 update added standards requiring products to "mitigate the potential for cognitive deskilling" and to "detect signs of learner distress." Separately, 1EdTech's open standards - including OneRoster for "secure exchange of data between an institution's teaching and learning systems" and Comprehensive Learner Record for portable records of achievement - exist precisely so a school is not locked to one vendor's proprietary format. The US Department of Education's FERPA guidance for vendors adds a legal condition underneath both: a vendor handling student data as a "school official" must remain "under the direct control" of the school or district "with respect to the use and maintenance" of that data.

The implementation question

Each named requirement above is really a question a procurement officer can put directly to a vendor, with a documentable answer: which content-filtering standard does the product meet; where is data stored and who can access it; does the contract permit the vendor to use student-created content commercially; does the product export rosters and records in an open, 1EdTech-compatible format or only its own; and does the district retain direct control over the data under FERPA's school-official test. None of this requires specialist technical expertise to ask - it requires treating "safe" and "compatible" as claims with named, checkable parts rather than adjectives on a slide.

What holds and what fails

What holds: naming these standards turns a values-laden pitch into a compliance conversation a school can actually verify against a document. What fails: assuming that meeting one standard, such as data protection, implies the others are also met - the safety standards, interoperability standards and FERPA guidance are three separate frameworks with different authors and no single body checking all three together. This is an editorial checklist built from those documents, not a certification: it names the questions, not the answers.

• Which named safety standard, if any, does this product's content filtering and distress-detection meet?
• Can our roster, grade and learner-record data move in and out of this product in an open, 1EdTech-compatible format?
• Does our contract keep the district in direct control of student data, as FERPA's school-official exception requires?

A vendor's brochure describes a product. These three documents describe the tests a school is entitled to ask that product to pass before money changes hands.