Pasting a student's name, grades, or IEP details into a consumer AI chatbot can breach FERPA. That is the short version, and it is the part most quick-start guides skip. The Family Educational Rights and Privacy Act (20 U.S.C. Sec. 1232g) protects the personally identifiable information in a student's education records, and personally identifiable information from those records should not flow into a consumer AI tool without a written agreement arranged through your school or district. A teacher drafting feedback at 9pm, feeding real student work into a free AI tab, is exactly the situation the law was not written to allow.
None of this means teachers cannot use AI. It means the student data you put in front of the model has to be handled the same careful way you already handle a paper gradebook. This guide covers what FERPA and COPPA actually require, where the real gap sits, and a workflow you can run without a lawyer on speed dial.
What FERPA actually protects
FERPA protects the personally identifiable information inside a student's education records. Education records are the files your school maintains about a student: grades, transcripts, disciplinary notes, disability documentation, and similar records tied to a named individual. When you copy that information into a consumer AI tool, you are disclosing an education record to a third party, and FERPA generally prohibits releasing that information without written consent unless a specific exception applies.
The trap is that consumer AI feels private. A chat window on your own laptop looks like a notepad. It is not. Free AI tiers may retain and use conversation data to train future models, which means the student names, grades, or IEP details you type could persist inside a system your district never vetted and cannot audit. That combination, a real education record plus an unvetted third party plus no agreement, is where a FERPA problem starts.
It helps to picture the disclosure as physical. Copying a named student's grades into a free chatbot is closer to mailing a photocopy of their file to a company you have never contracted with than it is to jotting a note. The information leaves the school's control, lands with a third party, and you have no contract governing what happens next. FERPA cares about that transfer, not about how the interface feels while you do it.
Where COPPA comes in for younger students
For students under 13, COPPA adds a second layer on top of FERPA. The Children's Online Privacy Protection Act (15 U.S.C. Sec. 6501) governs online services that collect personal information from children under 13. When a K-12 classroom uses an AI service with younger students, the school generally needs verifiable parental consent and appropriate agreements in place before that data collection happens.
In practice, that consent and those agreements are handled at the district level, not by an individual teacher signing up for a tool on a Tuesday. If you teach elementary or middle school and want to route student work through an AI service, the question is not whether the tool is good. The question is whether your district has already put a signed agreement and a consent process behind it.
| What it covers | FERPA | COPPA |
|---|---|---|
| Statute | 20 U.S.C. Sec. 1232g | 15 U.S.C. Sec. 6501 |
| Who it protects | Students with education records at a school | Children under 13 online |
| What it guards | PII inside education records (grades, IEPs, discipline) | Personal information collected from young children online |
| Key rule for AI use | No disclosure to a third party without written consent or an exception | Verifiable parental consent and agreements before collection |
| Who usually handles it | School or district, not the individual teacher | School or district on behalf of parents |
The safe workflow: data minimization first
Submit only the minimum information the task actually needs. This single habit, data minimization, removes most of the risk before any agreement question comes up. If you can get useful help from an AI tool without typing a student's name, grade, disability information, or Social Security number, then there is no education record leaving your hands and no FERPA disclosure to worry about.
Most classroom AI tasks survive this test easily. You can ask for a rubric, a set of differentiated reading questions, or feedback on a de-identified writing sample without ever attaching it to a real child. Strip the identifying details and you turn a risky prompt into a safe one. The mental sort is quick once you practice it: for every piece of information you are about to type, ask whether it points to one specific student.
What to keep out of the prompt
- Student names, initials, and student ID numbers.
- Grades, scores, or rankings tied to a named individual.
- Disability information, including IEP and 504 details.
- Social Security numbers and any government identifiers.
- Home addresses, family details, and anything that could re-identify a student even without a name attached.
The safe versions of the same tasks usually take one small edit. Instead of pasting a student's essay under their name, paste it with the name removed and ask for feedback on the writing. Instead of a named roster of real grades, describe the pattern you are seeing in anonymous terms. Instead of typing IEP details to get accommodation ideas, ask for general strategies for the type of need without the identifying record. Removing the name is a start, not the finish line: student ID numbers and details specific enough to re-identify a child count as PII too. The tool gives you the same help, and no education record leaves your control.
Why minimization holds up under FERPA
Data minimization is not just a personal safety habit; it lines up with how FERPA is written. FERPA restricts the disclosure of personally identifiable information from education records. If the text you type carries no personal identifiers and cannot reasonably be traced back to one student, then there is no education record being disclosed, and the disclosure rule has nothing to bite on. That is why a de-identified prompt sidesteps the agreement question entirely rather than merely reducing the odds of a problem.
There is a related exception worth knowing so you do not confuse it with a free pass. FERPA lets a school share an education record with a school official who has a legitimate educational interest, and that framework is how an approved vendor can process student data on the school's behalf without separate parental consent for each disclosure. The catch is that the vendor has to be brought inside that framework by the district, under the district's direct control, through a written arrangement. The Department of Education calls the written agreement a best practice precisely because it documents the direct control the exception requires. A teacher opening a personal account on a public tool is not the district extending a school-official relationship; it is a solo disclosure to an outside party. Minimization keeps you clear of that line, and the school-official exception is what your district uses when real data genuinely has to move.
The one place minimization runs out is the tool itself. A district-approved service with a signed agreement can safely receive more than a personal free-tier account can, because the agreement changes who is responsible for the data. That is the line the next section covers.
When you do need real student data, you need a DPA
If a task genuinely requires identifiable student data inside an AI tool, that tool needs a data processing agreement arranged through your school or district. A DPA is the kind of written arrangement FERPA's school-official framework leans on: it binds the vendor to handle education records under the school's control, restricts how the data can be used, and keeps that data out of general model training. Without it, the free-tier default may treat your students' work as fair game for training.
This is also why the decision usually is not yours alone to make. An individual teacher cannot sign a district into a vendor relationship, and clicking through a consumer tool's terms of service is not the same as having a DPA in place. If a tool would genuinely help your class and it needs real student data, the productive move is to route the request to whoever manages educational technology or data privacy for your district. They can check whether an agreement already exists, request one, or point you to an approved alternative that covers the same need.
The rule of thumb: if the prompt contains a real student's identifiable information, the tool behind it needs a written agreement from your district. If it does not, minimize and keep going. When in doubt, de-identify first and ask your district second.
Directory information is a narrow exception, not a loophole. FERPA lets schools designate certain low-sensitivity items, such as a student's name or grade level, as directory information that can be shared under specific conditions and after parents get a chance to opt out. That framing was built for yearbooks and honor rolls, not for feeding an AI model. It does not turn grades, IEPs, or behavioral records into shareable data.
Here is what most guides won't tell you
In my reading of how these tools work, the directory-information framing has a blind spot worth flagging: behavioral metadata. FERPA and its directory-information categories were written around records like names, grades, and enrollment status. AI-powered classroom tools also generate a different kind of data: how long a student spent on a topic, how often they interacted, and what their response patterns look like over time. This is my own observation rather than a settled legal category, but that behavioral metadata sits in a gap the directory-information framing does not cleanly address.
Why this matters: metadata can be revealing even when no name is obviously attached. A record of interaction frequency and time-per-topic can reflect a struggling reader or a student with an accommodation, and that inference can be as sensitive as the grade itself. Because the classic FERPA categories do not map neatly onto it, this data can slip past the checklist people use to decide what is protected. Treat behavioral signals from AI tools with the same care you give grades, and ask what your district-approved tools do with the interaction logs they collect.
Before adopting an AI tool for a class, ask three questions: Is there a signed agreement through my district? What happens to student inputs, are they used for training? And what interaction or behavioral data does the tool log, and who can see it?
Keeping your planning context separate from the model
The recurring friction for teachers is that useful AI help wants context, and good context tends to include the exact student details FERPA protects. You want the tool to remember which students need which supports, yet you cannot safely park that in a consumer model's training path. That is the specific pain point an external memory layer addresses.
MemX is an external memory layer that sits alongside the AI tools you already use, holding your planning context under your own control instead of inside the model. Sensitive student details can stay in a space that is private by architecture, with per-user isolation, encryption at rest, and on-device options, and kept out of the model's general training path. It is portable across ChatGPT, Claude, and Gemini, so switching tools does not scatter your context. MemX is not a substitute for your district's data agreement or a compliance guarantee, but it gives you a place to keep classroom context that does not force student PII into an unvetted chatbot.
01Can teachers use ChatGPT with student data?
Not with identifiable student data on a personal free account. That can be a FERPA disclosure to a third party without a written agreement. Use a district-approved tool with a signed agreement, or de-identify the data first by removing names, grades, and other identifiers.
02Does FERPA apply to AI tools?
Yes. FERPA protects PII in education records regardless of the technology. Copying that PII into a consumer AI tool is a disclosure to a third party, which generally requires written consent or an exception arranged through the school or district.
03What student data is safe to put in an AI prompt?
Data with no personal identifiers. Remove names, grades tied to individuals, disability information, Social Security numbers, and student IDs. Submit only the minimum the task needs. A de-identified writing sample or an anonymous rubric request is generally safe.
04Do I need parental consent to use AI with students under 13?
For students under 13, COPPA generally requires verifiable parental consent and appropriate agreements before an online service collects their personal information. That consent and those agreements are handled at the district level, not by an individual teacher signing up alone.
05Is a student's name directory information I can share with AI?
Not for this purpose. Directory information is a narrow FERPA exception built for yearbooks and honor rolls under specific conditions. It does not authorize feeding student records into an AI model, and it does not cover grades, IEPs, or behavioral data.
The core discipline is simple: assume a consumer AI tool will keep what you type, then decide what you are willing to hand over on that basis. Minimize by default, get a district agreement before using real identifiable data, and treat the behavioral metadata AI tools generate as if it were part of the record too. Do that, and you can use these tools without turning your gradebook into training data.
