AI tools generate a kind of data that most district privacy policies were never written to handle. A prompt, a chat log, a model-generated summary, a dashboard insight built on top of a student's activity…none of this fits neatly into what most policies were drafted around. That gap is where a lot of well-intentioned AI adoption quietly runs into trouble, not because anyone did anything wrong, but because nobody asked where this new data actually lives inside the district's existing legal obligations.

This section is meant to help districts start asking the right questions, both for data handled inside the district and data handled by outside vendors. What follows is a starting framework, built to get that conversation moving in the right direction.

The regulatory landscape

AI tools should be reviewed with the following regulations in mind.

Under FERPA, an AI-generated transcript, summary, or dashboard entry about a specific student is very likely an education record the moment it exists in a district system, even though it did not come from a teacher's gradebook or a counselor's file. The "school official" exception can let a vendor process this kind of data without separate parental consent for every tool, but only when the vendor uses the data solely for the purpose the district authorized, and does not redisclose it elsewhere.

COPPA adds another layer for any tool used with students under 13. Districts can generally consent on a parent's behalf for tools used strictly for educational purposes, but that consent only holds up if the vendor's actual practices stay inside that boundary.

CIPA's internet safety and filtering obligations extend to AI tools the same way they apply to any other internet-connected resource a district uses.

And then there is the state layer, which varies more than people expect. Illinois SOPPA is one example of a state law that adds requirements on top of FERPA and COPPA. Ohio, Tennessee, and other states have their own frameworks, some newer than others. There is no universal answer here. Districts need to confirm what applies specifically to them.

What happens inside the district

Before a vendor is ever involved, districts are already generating AI-related data just through normal use. A teacher types something into a tool. A student's chat produces a transcript. A dashboard surfaces a pattern across a classroom. All of that data is something the district now has to think about.

Start with what actually counts as PII in an AI context. It is easy to think of PII as something that lives in a database, but a student's name, ID number, grades, IEP or 504 details, disciplinary notes, or behavioral observations are all still PII the moment they are typed into a prompt. That distinction matters because prompts feel casual in a way that database entries do not.

Identifiable student information should never go into an AI tool that has not been vetted and approved through the district's vendor process — the habit of thinking twice before typing a student's details into any AI system should hold everywhere.

That is also why it is worth setting a clear standing rule for staff: identifiable student information should never go into an AI tool that has not been vetted and approved through the district's vendor process. This matters most with general-purpose tools including those that anyone can open in a browser especially where there is no guarantee about redaction, access controls, or what happens to the data afterward. It matters less inside an approved, purpose-built platform where those protections are already built in, but the underlying habit of thinking twice before typing a student's details into any AI system should hold everywhere.

Retention deserves its own thinking too. AI-related data such as chat logs, generated summaries, and model outputs tends to accumulate faster and differently than traditional student records, so it makes sense to give it its own retention and deletion clock rather than folding it into the district's general record-retention schedule by default.

Then there is the parental notice question, which does not have a clean answer. Under FERPA's school official exception, a district can generally let an approved vendor process student data on its behalf without separate parental consent for each individual tool. That is the legal floor and it is not necessarily where districts should stop. A growing number are choosing to give parents plain-language notice of which AI tools are in use and why, even in cases where it is not strictly required, simply because it builds trust and heads off surprises.

What to expect from vendors

When it comes to third-party tools, a vendor's privacy policy should be able to answer four questions clearly:

  • Who else touches this data, including any subprocessors or underlying AI model providers
  • Whether student data is ever used to train or improve a model
  • Who actually owns the data
  • What happens to the data if the district ends the relationship

If a policy cannot answer these plainly, that is worth raising before anything gets signed.

Here is how EducAIte approaches this internally, as one example of what these commitments can look like in practice. Internal staff access to student data is logged and fully traceable, meaning every access is tied to a specific person, a school administrative authorization, a specific stated purpose, and a specific time window. Access unlocks under a lock-and-key model and automatically expires after 90 days, so nothing stays open indefinitely by default. And student data is never used to train or improve our models in identifiable form. Where data supports model improvement at all, it is aggregated and de-identified first. Our school partners always own their own data too.

This is meant as an illustration, and not a template every vendor will match. Districts should expect to see specifics like these vs. general assurances from any AI vendor they work with.

A quick word on staying ready

Two habits make everything above much easier to sustain over time.

First, before adopting or renewing any AI tool, run a short assessment: what data does this tool actually touch, what is the most sensitive data it could reasonably encounter, and does the vendor's policy hold up against the questions above. This does not need to be a lengthy formal process for every single tool, but it should be repeatable, and it is worth re-running whenever a vendor adds a new feature, a new subprocessor, or starts collecting a new category of data.

Second, keep a simple record on file for each AI tool in use: the vendor's current privacy policy and data processing agreement, the date of the district's last review, and who approved it. That record is what turns a compliance question into something easily answerable.

If you are interested in learning more or are in need of a formal data governance policy, reach out to Erica Bishaf at erica@educaitelearning.com or contact us here.