Does FERPA prohibit using AI with student records?

FERPA does not prohibit AI. It restricts disclosure of personally identifiable information from education records to third parties without consent, with an exception for vendors under the school's direct control that use the data only for the authorized purpose. So an AI tool can process student records when the model provider receiving the prompts is bound by the school-official conditions, and the same records sent to an uncontrolled general-purpose model fall outside the exception. The controlling question is which endpoint receives the data and under what terms.

How does COPPA apply to an edtech chatbot?

If the product collects personal information from children under 13, COPPA requires verifiable parental consent and constrains how that information is shared and retained. A chatbot that sends a child's input to a model provider is disclosing the child's personal information to a third party, and the operator remains responsible for what that provider does with it. The FTC's 2025 amendments tightened retention and third-party sharing, so the destination of a child's prompt and the provider's data-use terms are both compliance-relevant.

What is the risk of student data in a model prompt?

The risk is disclosure outside the regime that governs the record. A prompt carrying a student's name and work to a provider that trains on inputs or retains them creates a FERPA disclosure, a COPPA sharing event, and a SOPIPA secondary-use problem at once. Because the exposure happens in the request payload, controlling it means reading and classifying what the prompt carries and enforcing where it can go, rather than relying on the user to route sensitive work only to approved tools.

Do data-processing agreements cover this?

A data-processing agreement sets the terms, and it does not enforce them on the traffic. It binds the sanctioned provider and says nothing about a teacher or an application calling a different model that has no agreement. Closing the gap means enforcing the destination and the data classes on the actual requests, so student information reaches only providers the agreement covers and an out-of-scope call is stopped at the boundary.

EdTech AI and Student Data Privacy: FERPA, COPPA, and the PII-in-Prompts Problem

An edtech tutoring bot works by sending the student's question, and often the student's prior work and name, to a language model that generates the response. A grading assistant sends the essay and the roster identifier. In both flows the student's education record leaves the school's boundary inside an HTTP request to a model API, and the moment it does, three privacy regimes attach to that traffic. The Cloud Radix 2026 research on unauthorized AI use found sensitive data pasted into unsanctioned models at scale across sectors, and education carries the added weight of protecting minors. I want to walk what FERPA, COPPA, and state student-privacy law each require of that data flow, and show where the exposure actually sits.

FERPA and the education record in a prompt

The Family Educational Rights and Privacy Act, 20 U.S.C. 1232g and 34 CFR Part 99, protects personally identifiable information in student education records and restricts disclosure without parental consent. The Department of Education guidance allows disclosure to a vendor under the school-official exception at 34 CFR 99.31(a)(1) only when the vendor is under the school's direct control and uses the data solely for the authorized purpose. A student essay containing the student's name and analysis, sent to a general-purpose model with no such arrangement, is a disclosure of an education record outside the exception. The FERPA question is not whether AI is allowed, and whether the specific model endpoint receiving the prompt is a vendor bound to the school-official conditions or an uncontrolled third party.

COPPA and data from children under 13

The Children's Online Privacy Protection Act, 15 U.S.C. 6501 and the FTC's Rule at 16 CFR Part 312, requires verifiable parental consent before collecting personal information from a child under 13, and the FTC strengthened the Rule in 2025 with tighter limits on retention and third-party sharing. An edtech product used in elementary classrooms that routes a child's input to a model provider is sharing that child's personal information with a third party, which the operator has to account for under COPPA's consent and disclosure requirements. The FTC COPPA guidance makes the operator responsible for what downstream providers do with the data, so the prompt destination matters as much as the collection.

State law: SOPIPA and its descendants

California's Student Online Personal Information Protection Act set the template that many states copied. It bars an operator of a K-12 service from using covered student information for targeted advertising, from building a non-educational profile, and from selling the data. When student information flows into a model provider's prompt, the operator has to know the provider's data-use terms, because a provider that trains on submitted prompts or retains them for its own purposes puts the operator on the wrong side of SOPIPA. The compliance fact is contractual and technical together: the terms have to prohibit secondary use, and the traffic has to actually stay within a provider bound by those terms.

Where the exposure sits

All three regimes converge on the same event, a prompt carrying student PII crossing from the school or operator's boundary to a model endpoint. FERPA asks whether that endpoint is a controlled vendor. COPPA asks whether a child's data reaching it was consented and constrained. SOPIPA asks whether the provider is barred from secondary use. Each turns on which model received which student's data, under which terms, on which request. The FERPA-specific compliance treatment covers the school-official exception in depth. The broader pattern of regulated data leaving through model traffic is the same one documented in enterprise AI data exposure. Most edtech deployments govern this in a data-processing addendum and enforce nothing on the traffic itself, so a prompt to an out-of-scope model looks identical to a compliant one.

DeepInspect

This is the traffic layer where student-privacy obligations land, and it is where DeepInspect operates. DeepInspect is a stateless proxy on the AI request path between an edtech application and the model endpoints it calls. It reads the decrypted prompt, classifies student PII, names, identifiers, and free-text work that identifies a minor, and applies a policy decision before the request reaches a provider.

It enforces destination policy, so student data only reaches model endpoints bound by the school-official and SOPIPA terms, and traffic to an uncontrolled model is blocked rather than logged after the disclosure. It commits a per-decision record naming the caller, the student data classes involved, the model reached, and the outcome, which is the evidence a district privacy officer or an FTC inquiry asks for. It runs inline and fails closed. The result is that the contractual constraints in the data-processing agreement are enforced on the actual traffic instead of assumed. Map your student-data flows to the regimes that govern them and see where the gaps are today.