State AI Policy Deadlines Are Now School ERP Requirements

By 1 July 2026, every school district, community school and STEM school in Ohio needed a board-adopted artificial intelligence policy on file. The deadline came from House Bill 96, the state’s operating budget, making Ohio the first US state to require an AI policy of every district. Six days earlier, the California Department of Education posted a model AI policy produced by the working group SB 1288 established; the letter announcing it is dated 6 July.

Read them as a vendor rather than an administrator and they stop being statements of values and start reading as a specification.

“Limits on AI detection software” constrains which products a district may buy and how their outputs may be used. “Student data may not be used to train AI models” is a contract term and a logging obligation. “Parents may review AI-generated material in their child’s record” is a retention and export requirement. Each lands in a schema, a config store, or a master services agreement. Most School ERP and edtech platforms satisfy none of them today, because the product was built assuming AI capabilities are features — and these are constraints on the data model underneath them.

134 bills, 31 states, one product#

By March 2026, MultiState counted 134 AI-in-education bills across 31 states in the current session, clustering into three themes: student data privacy including restrictions on training use, boundaries on AI use including limits on high-stakes decisions, and AI literacy in curriculum. California AB 1159 goes directly at prohibiting student data from training AI models; Oklahoma SB 1734 targets AI in high-stakes decisions.

The variation is the engineering problem. A vendor selling into Ohio, California and Oklahoma ships one codebase against three rule sets that diverge further every session.

This is not a US-only pattern, just where the deadlines landed first. The EU AI Act’s Article 50 transparency obligations became enforceable on 2 August 2026, requiring any AI system intended to interact directly with a person to disclose that it is an AI unless that is obvious to a reasonably well-informed observer. Different statute, same requirement, same component in your portal.

Per-district policy configuration is a feature flag surface#

The first structural consequence: policy becomes configuration, per tenant, expressed as data rather than a document someone uploads to a compliance folder. A workable policy object carries fields like these:

• whether AI-assisted drafting is available to students, and in which grade bands
• whether an AI output may inform a graded decision at all
• the disclosure wording shown at the point of interaction
• the retention window for AI artefacts attached to a student record
• whether third-party detection scores may be stored, displayed, or acted upon

The part teams get wrong is history. A board adopts a policy on a date, and the audit question is never “what is the setting now” — it is “what was the setting in March, when this happened to this student.” That makes policy config a slowly changing dimension with effective-from and effective-to timestamps, not a settings table you UPDATE in place. Overwriting the row destroys the only evidence that answers the question.

The same constraint reaches your Operational Automation. Nightly jobs, attendance nudges, scheduled report runs — anything unattended has to read the policy version in force at the time of the run and stamp it on the output.

Data-use provenance means proving a negative#

“Student data was never used to train a model” is a negative claim, and negatives are proved with contracts plus logs.

The contract half is non-negotiable: zero-retention terms with your model provider, no training on inputs or outputs, written into the data processing agreement and flowed down to every sub-processor. Without them the claim is unsupportable, and no application-layer engineering fixes that.

The evidence half is logging. Every model call from the School ERP should record the timestamp, tenant, model and version, endpoint region, the retention flag the call was made under, and which classes of student field appeared in the prompt. Not the payload itself — you do not want a second copy of student data in a log store — but enough lineage to reconstruct what left the building and under what terms.

Columbus City Schools adopted a policy barring student and staff data from being used to train AI models, and separately barring personally identifiable information from being entered into any tool the district has not approved. The second clause is harder, because it is about shadow usage rather than integrations — partly a procurement control, but also a product problem. If the ERP has a genuinely useful assistant inside the perimeter, staff have far less reason to paste a behaviour log into a consumer chatbot at 9pm.

Regulated verticals worked through this earlier. A Hospital Management System faced the same problem years ago — protected health information cannot cross into a vendor’s training corpus, and the answer was never a policy PDF. It was a signed agreement plus an audit trail on demand.

Disclosure belongs in the component, not the terms of service#

When a parent opens the portal and asks a chat assistant why their child’s attendance dropped, the disclosure that they are talking to an AI is a UI requirement wired to a config value — rendered in the component, sourced from the tenant’s policy record, so a district that words its disclosure differently gets its own wording rather than yours.

Article 50’s carve-out for cases where the AI nature is “obvious” is not a place to shelter. The design intent of a portal assistant is to feel like help, which is what makes it non-obvious. Ship the disclosure. And let provenance follow the artefact outbound: an AI-drafted attendance message carries a marker in the record even where it carries none in the text the parent reads. That marker makes the next requirement possible at all.

Parent review rights force you to store the artefacts#

This is the requirement most likely to break an existing schema. A right of review implies the artefact exists, is attached to the student, is retrievable, and is comprehensible to a non-technical reader. So the record has to hold the output, the inputs that produced it, the model and version, the timestamp, and whether a human edited it before it landed. An AI-drafted report comment a teacher rewrote is a different object from one that shipped verbatim, and the record has to say which.

Storage is not the obstacle — the volume is trivial next to the traffic a School ERP absorbs on results day. The obstacle is that most systems store the final field value and nothing about how it got there. Retrofitting provenance onto a column that has only ever held a string is a migration with a backfill story, and roadmaps consistently under-scope it.

Educator discretion is an override, and the override is the record#

California’s model policy is explicit that concerns about inappropriate AI use must rest on educator evaluation, alternative assessment and documented evidence of authorship, with clear criteria for rebuttal available to students and families. Columbus likewise puts teacher discretion at the centre of student AI use.

Translated into product terms: every AI recommendation carries an accept, modify or reject action, and the disposition is stored as the system of record — not telemetry, but the authoritative account of what the school decided.

This applies hardest to anything that flags a student. An early-warning model that ranks students by risk is exactly the high-stakes decision bills like Oklahoma’s have in view. The flag is an input; the human’s disposition, with a reason code, is what the record holds.

The override log also happens to be the best evaluation dataset you will get: reject rate by feature, by school and by year group tells you where a model is wrong on real cohorts faster than any offline metric.

The detection limit is correct, so build the alternative#

AI detection software was always a bad control, and the policy restricting it is right. Detectors return a probability on authorship with no ground truth to calibrate against, and the errors are not randomly distributed. False positives fall hardest on second-language students, whose writing tends toward regular constructions and a narrower vocabulary — precisely the features detectors score as machine-generated. Accusing a student of cheating on a classifier score, with no meaningful appeal path, is indefensible whatever accuracy figure the vendor prints.

California’s line — that detection output must not be the sole basis for a disciplinary action or grade penalty — points at the replacement. Build process visibility instead of verdicts: draft history, revision timeline, the sequence of edits over a fortnight. Not to catch anyone, but to give a teacher the documented evidence of authorship the model policy asks for.

The cost is worth naming. Append-only edit streams, a retention policy and a viewer that makes two weeks of drafting legible in about thirty seconds is more engineering than calling a detection endpoint. It is also defensible in a hearing, which the endpoint is not.

The honest position#

A vendor that treats all of this as compliance ships a settings page. Twelve toggles, a PDF export, a datasheet line about being AI-policy ready, and no way for a district to answer the one question an audit turns on: what was the configuration on the day this happened, and what did the system do.

Treat it as a data model problem and the same requirements become the product. Versioned policy config, model-call provenance, artefact lineage, an override log that is the system of record — a Data Platform with the compliance surface built in rather than bolted on the front. It is also the only shape of AI implementation in a School ERP that survives a procurement team that has read its own state’s statute. One session produced 134 bills across 31 states; the next will not be smaller.

---

If your School ERP roadmap has AI features but no policy data model underneath them, the gap surfaces in a procurement questionnaire before it surfaces in engineering. We help education platforms design the config, provenance and audit layers that make those answers verifiable — talk to us.