NYC Public Schools’ AI tool list shows why districts must audit software features

New York City Public Schools’ newly disclosed list of 38 software products flagged under its 2026-27 AI restrictions has turned a philosophical debate about classroom AI into a practical procurement lesson for every district: if you want to enforce an AI policy, you have to audit software by feature, not just by product name. Chalkbeat reported on October 23 that the list included reading and math programs, assessment tools, and even a chatbot the department built with Microsoft. City officials told Chalkbeat the restriction applies to student-facing generative AI features, not necessarily to entire products, and that some vendors have already stayed in schools by switching those features off. (chalkbeat.org)

That answers the question many school leaders have been asking since districts started tightening AI rules this year: don’t begin with a “banned apps” spreadsheet. Begin with a feature inventory. In New York’s case, the same product category could land in very different places depending on whether the AI is generative, whether students can directly use it, whether an exemption applies, and whether the AI can be disabled without blowing up instruction midyear. What remains murky in New York is how quickly vendors can be reclassified and how the city initially sorted products in the first place. (route-fifty.com)

What New York City is actually restricting

For the 2026-27 school year, NYC Public Schools says it is imposing a moratorium on student-facing generative AI in grades 2K through 8, while high school students get only limited, guided use for approved purposes. In a family message before school started, the district said high school use would be confined to carefully controlled pilots involving five vetted programs, plus supervised career-readiness settings such as Career and Technical Education. The same message also said teachers may continue using approved AI tools for instructional planning and operational work, but not for grading, behavior monitoring, or placement, promotion, or graduation decisions. (schools.nyc.gov)

Those distinctions matter because they explain why a district can target an AI feature without condemning every tool that contains automation somewhere under the hood. NYC also says the policy does not apply to assistive technology tied to a student’s IEP or 504 plan, or to technology needed for language access for English language learners under federal and state mandates. In other words, the policy is narrower than “AI is banned,” but harder to operationalize than a simple allow-or-block list. (schools.nyc.gov)

The newly public product list shows how messy that line-drawing gets. Chalkbeat reported that Amira, the AI-powered reading tutor used in more than 200 city schools, was banned outright because officials said it could not function without AI. The city also ended student access to its own “teaching assistant” chatbot built with Microsoft and used in six schools last year. But other products landed in a gray zone: Wordly was flagged even though the company told Chalkbeat it does not use the kind of generative AI barred by the policy, and NYC’s own rules carve out language-access supports. (route-fifty.com)

Vendor marketing helps explain the confusion, but not resolve it. Amira describes itself as an AI reading assistant and says its product adds “AI trained on how the brain learns to read,” which makes New York’s conclusion that AI is core to the product easier to understand. Wordly, by contrast, markets AI translation, captions, and summaries for meetings and events. That does not prove whether Wordly should or should not be covered by NYC’s student-facing generative AI rule, but it does show why procurement teams cannot stop at the question, “Does this company use AI?” They have to ask what kind, for whom, and in what workflow. (amiralearning.com)

The procurement lesson: inventory features, not logos

The practical takeaway from New York is that districts need an AI register attached to their existing edtech review process. At minimum, that register should identify the product, the specific AI-enabled feature, whether it is student-facing or staff-facing, which grades can reach it, what student data goes to the vendor, whether the feature is on by default, whether the district can disable it itself, and whether the rest of the product still works if that feature is turned off. That checklist is an inference from New York’s rollout, but it is grounded in the city’s vendor-by-vendor effort to determine whether AI components can be disabled and in the broader risk-management approach recommended by the National Institute of Standards and Technology, which says AI trustworthiness considerations should be built into the design, development, use, and evaluation of AI systems. (route-fifty.com)

Privacy and contract teams should be in that review from the start, not after an edtech dispute breaks into public view. NYC’s own privacy policy says written agreements with outside parties must spell out how student data will be kept confidential and secure, and New York’s Parents’ Bill of Rights says the system must maintain written agreements with outside parties that receive student personally identifiable information. State Education Law 2-d likewise requires contracts or written agreements with third-party contractors receiving student data to include a data privacy and security plan. Those rules existed before the AI fight, but New York’s October disclosures show they are now also the most obvious place to demand AI-specific disclosures and notice requirements. (schools.nyc.gov)

That is the second-order effect other districts should notice. Once generative AI features start appearing inside familiar literacy, math, translation, and assessment platforms, the real governance problem is no longer whether to approve “an AI tool.” It is whether a previously approved core product has quietly acquired a student-facing feature that changes the instructional, privacy, or policy risk profile after purchase. If the answer can change with a software update, districts need contract language that requires disclosure before that change reaches classrooms. That final step is an inference, but it follows directly from NYC’s experience of scrambling to sort which features could be shut off and which products had to be removed. (route-fifty.com)

What school leaders can do before the next renewal cycle

The immediate move for curriculum, IT, privacy, and procurement leaders is not to wait for their own version of New York’s public dispute. Start with products embedded in core instruction and multilingual communication, then ask vendors for a written attestation covering four points: whether the product includes generative AI at all, whether students can directly interact with it, whether the district can disable it without losing the rest of the service, and whether any student data is used to train models. The U.S. Education Department’s student privacy guidance says written agreements are a best practice even where FERPA alone would not require them, and NYC already posts public information about outside-party agreements for tools that receive student data. (studentprivacy.ed.gov)

New York’s flagged list should not be read as a universal judgment that every named product is unsafe or noncompliant everywhere; even in the city, statuses may change as vendors disable features or make their case for exemptions. But the episode is a useful warning for school systems writing AI rules this year. The next procurement headache is unlikely to be a flashy standalone chatbot. It is more likely to be a familiar product already in your rostering system, now carrying one student-facing generative feature your contract never asked about. (route-fifty.com)