Is AI Grading FERPA Compliant? What Schools and Districts Should Verify

Every AI grading vendor says it is FERPA compliant. The claim is close to meaningless on its own — FERPA has no certifying body, so any vendor can write the words on a marketing page. What actually protects a district is knowing which questions to ask and what a good answer looks like.

This is the evaluation checklist we would want a district to run against us. It is written to be used on any vendor, including Graider, and it names the places where honest answers are uncomfortable. If a vendor cannot answer these in writing, that is your answer.

How FERPA actually applies to an AI grading tool

Student work, grades, and roster records are education records. FERPA restricts how a school discloses them. The provision that makes edtech possible is the school official exception (34 CFR §99.31(a)(1)(i)(B)): a district may disclose education records to a vendor performing an institutional service, provided the vendor is under the district's direct control as to the use and maintenance of those records, and does not redisclose them.

Three practical consequences fall out of that, and they are what your questions should target:

• Direct control has to be established somewhere — in practice, a written agreement. A vendor with no data protection agreement to sign has not established it.
• The vendor may only use the data for the service. Using student work to improve a general-purpose model is not the service you bought.
• Redisclosure is limited. If the vendor sends student work to a third party — and every AI grading tool does, because the AI provider is a third party — that chain has to be accounted for.

That last point is the one most evaluations miss. An AI grading tool is never a single vendor. It is a vendor plus every AI provider, OCR service, database host, and error-monitoring service behind it.

Where COPPA comes in (and why grade 6 matters)

COPPA governs collection of personal information from children under 13. Teachers often assume it is a K–5 concern. It is not: a typical 6th grader is 11 or 12, so any tool used in a 6–12 building is likely handling data from students COPPA covers.

For school-authorized educational services, the FTC has long recognized that the school may provide consent on behalf of parents rather than the vendor collecting parental consent directly. That permission is conditional, and the conditions are the useful part of your evaluation:

• The data is used only for the school-authorized educational purpose.
• There is no commercial use — no behavioral advertising, no profiling, no sale of student data.
• The school receives notice of the vendor's data practices sufficient to inform parents.
• The school can access and delete student data on request.

Note what this means: if a vendor's AI provider trains on the prompts it receives, the "no commercial use" condition is not satisfied — regardless of what the vendor's privacy page says. This is a question about the vendor's contracts with its providers, not about the vendor's intentions.

The 10-question vendor checklist

Send these to any AI grading vendor and ask for written answers. The follow-ups matter more than the initial replies.

Questions 1–3: What leaves your building

1. What exactly is transmitted to the AI provider?

Ask for specifics: the student's name, the student ID, the assignment text, the rubric, the teacher's instructions? "We take privacy seriously" is not an answer. The useful answer is a list.

Good answer: the vendor can enumerate the fields and tell you which identifiers are removed before transmission.

2. Is student work de-identified before it is sent — and does that include images?

This is the highest-yield question on the list, because text and images are usually handled differently and vendors rarely volunteer the distinction.

Stripping a name from typed text is tractable. Stripping a name a student wrote at the top of a photographed worksheet is a different problem — the name is pixels, not a database field. Many tools that de-identify typed work send photos through as captured.

Follow-up that separates careful vendors from careless ones: "Does your de-identification apply to photo and handwritten submissions?" A vendor that says "yes, everything" without qualification is either doing something unusual, or has not thought about it.

3. What happens when de-identification fails?

Name-stripping is heuristic. Unusual spellings, nicknames, and a student signing their essay will defeat it. Ask what the system does when it is not confident — does it block the send, or send anyway and hope?

Questions 4–6: Who else touches the data

4. Give me the complete sub-processor list.

Not just the AI provider. The full chain: AI providers, OCR services, database host, hosting platform, error monitoring, email delivery, analytics. For each: what data it receives, where it is processed, and whether a data protection agreement is in place.

A vendor that cannot produce this list on request does not know its own data flows.

5. Do any of your providers train on student data?

Ask for this in writing, per provider, and ask which contractual tier it depends on. This is the question with the sharpest edge, because the answer often varies by plan: the same AI provider may have very different data-use terms on a free tier versus a paid or enterprise tier.

Follow-up: "Which of your provider accounts are on those terms today?" A no-training guarantee that applies to a plan the vendor has not purchased yet is not a guarantee.

6. How long does each provider retain what you send?

Separate from the vendor's own retention. Many AI providers retain API inputs for a period for abuse monitoring even when they do not train on them. Zero-retention arrangements generally exist but usually require a specific agreement rather than being the default.

Questions 7–8: Deletion and retention

7. Can you delete one student, and prove it?

Under FERPA and most state agreements a district can require deletion. Ask two things: whether deletion is per student or all-or-nothing, and whether the system will tell you if the deletion failed.

That second half matters more than it sounds. A system that reports success for a deletion that did not fully complete is worse than one that reports an honest failure, because the district believes the record is gone.

Follow-up: "If a grading job is running when I delete a student, can that job re-create the record?" This is a real failure mode in systems that process work in the background, and it is a question very few vendors expect.

8. What is your retention schedule?

Not "we delete on request" — that is a deletion process, not a retention policy. Ask how long submissions, rosters, and grades are kept by default, and what happens at the end of a school year or when a contract ends.

Questions 9–10: Contracts and state law

9. Will you sign our data protection agreement?

Most districts have their own, often based on the Student Data Privacy Consortium (SDPC) National Data Privacy Agreement. A vendor that will only accept its own terms is a harder procurement, and a vendor that has never seen an NDPA is early.

10. Which state addenda can you meet?

If you are in New York (Ed Law 2-d), Illinois (SOPPA), or California (SOPIPA/AB 1584), these carry obligations beyond FERPA — and several require specific contract language rather than a general assurance.

How Graider answers these, including the gaps

We think a vendor that only publishes its strong answers is not giving you enough to evaluate. Here are ours, including the parts we would rather not advertise.

What we strip before student work reaches an AI provider

For typed work, Graider removes student names and name fragments, email addresses, phone numbers, and student identifiers from the text before it is sent. The check runs immediately before each provider call rather than only at intake.

Where that protection does not reach — our honest gap

Photo and handwritten submissions are not automatically de-identified. If a student writes their name at the top of a page and photographs it, that name is in the image we send for transcription. We say this in our privacy policy as well, because a district's security review will find it, and it is better read from us than discovered.

What we do about it today: the OCR service we use for handwritten and math work is configured so that submitted images are not retained for quality assurance or product improvement — they are transcribed and not kept for those purposes. That reduces exposure. It does not de-identify the image, and we are not going to describe it as if it does.

Student access is teacher-controlled

Students cannot self-register. They reach Graider through a class login or a join code issued by their teacher, which means the roster is defined by the school rather than assembled by the product.

Deletion is per student, and reports honestly

Graider supports deleting an individual student's records, not only wholesale account deletion, and deletions are written to an audit log. We have put substantial engineering into the failure case specifically: a deletion that cannot be confirmed reports as a failure rather than as success, and a grading job already in flight cannot resurrect a record that was deleted while it ran.

Where we are still building

• A published retention schedule. We delete on request, but we have not yet published default retention periods. That is a real gap against question 8, and we would flag it about any vendor.
• Provider agreements. Some are executed and some are in progress; we will tell a district exactly which is which rather than answer in the aggregate.
• Image de-identification. Covered above. It is the limitation we would most want a district to weigh.

This article is written for evaluation purposes and is not legal advice. Districts should involve their own counsel or privacy officer when assessing any vendor and before signing a data protection agreement.