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.

Student Data Privacy in EdTech AI: FERPA and COPPA

An edtech tutoring bot sends a student's question, prior work, and sometimes a name to a language model. A grading assistant sends the essay and roster identifier. Before a school approves either product, it should ask three questions: which model endpoint receives the prompt, does the vendor meet FERPA's school-official conditions, and what COPPA consent and retention terms apply to children under 13? The education record leaves the school's boundary inside that HTTP request. I want to show how FERPA, COPPA, and state student-privacy law attach to this route, and what evidence answers those vendor questions.

TL;DR

Before student work reaches an LLM, confirm the FERPA school-official relationship, COPPA consent and retention terms, and the approved destination endpoint.

The request record should name the caller, student-data class, model endpoint, and policy decision so a school can verify its vendor controls against the traffic that actually left its boundary.

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, building a non-educational profile, or selling the data. A model provider's terms determine whether submitted prompts are retained or used for training, so the operator needs a written secondary-use restriction and a route that reaches only the contracted endpoint.

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. Before the request reaches a provider, the proxy reads the decrypted prompt, classifies student PII, names, identifiers, and free-text work that identifies a minor, then applies a policy decision.

Destination policy allows student data to reach model endpoints bound by the school-official and SOPIPA terms, while an uncontrolled-model request is stopped before disclosure. The per-decision record names the caller, the student data classes, the model reached, and the outcome, giving a district privacy officer or an FTC inquiry evidence tied to the live request. The proxy runs inline and fails closed, so the data-processing agreement governs the traffic as well as the contract. Book a demo today.