The Family Educational Rights and Privacy Act protects personally identifiable information in student education records. Student writing submitted as coursework qualifies. The Department of Education's Student Privacy Policy Office maintains guidance on how the statute applies to third-party services.
Quick answer
AI detection tools handle FERPA-protected student writing on vendor infrastructure. Before signing, districts should confirm where data is processed, how long it is retained, whether it can be used for model training, which subprocessors touch it, and how deletion is handled at contract end. All five should appear explicitly in the data processing agreement. Missing any of them is a common compliance gap.
The sections below cover the applicable FERPA baseline, how detector workflows interact with it, the vendor questions that matter most, the compliance gaps we see repeatedly in published policy documents, and the specific DPA language to insist on.
What FERPA requires
The key mechanism for detector procurement is the school official exception. Under this provision, a vendor performing an institutional service can access student records without individual parental consent if the vendor is under the direct control of the school, uses the data only for the authorized purpose, and is subject to FERPA's re-disclosure and use restrictions. Every one of those conditions has to be reflected in the contract for the exception to apply.
A detector contract that reserves the right to train on student writing is not FERPA-compatible under the school official exception, no matter what the marketing page says.
The Working Educators editors
How AI detection tools interact with FERPA
The typical detector workflow uploads student text to a vendor server, runs it through a classifier, and returns a report. In most implementations, the vendor stores a copy of the submitted text at least temporarily. Some vendors use submitted text to improve the classifier. Some route the text through subprocessors like a cloud model provider or a hosted infrastructure service. Each of these hops is a FERPA-relevant data flow.
The classifier output itself, particularly if it flags specific sentences as AI-generated, becomes part of the education record when it is used in an integrity determination. That means the report is subject to the same access, amendment, and disclosure rules as any other record. Vendors that offer permanent, non-modifiable audit logs are simpler to defend on this point than vendors that overwrite reports.
The vendor questions districts should ask
Five questions cover most of the ground. First, where is the data processed and stored, including geographic region. Second, how long is submitted text retained after processing, and is that retention configurable. Third, is submitted text used for training or improving the classifier, and can that use be opted out contractually. Fourth, which subprocessors touch the data, and does the vendor commit to notify the district of subprocessor changes. Fifth, what happens to the data at contract end, and how is deletion verified.
The answers to these questions should appear in writing, ideally in the contract itself rather than in a marketing page that the vendor can update unilaterally. If a vendor cannot answer any of them in writing before signing, that is a signal about how the answer will be treated after signing.
Common compliance gaps
The most common gap is the training use question. Vendors that reserve the right to use submitted content to improve their model, without an explicit contractual opt-out, are effectively treating student writing as a training corpus. That is a hard sell under the school official exception, which limits the vendor to using the data only for the authorized purpose.
The second common gap is subprocessor disclosure. Many detector vendors run their classifiers on top of a hosted large-model provider. The identity and terms of that subprocessor matter, and blanket references to standard cloud infrastructure are not sufficient. The third is deletion verification. Contracts that promise deletion but do not specify a mechanism for confirming it leave districts unable to demonstrate compliance at audit.
What to put in the data processing agreement
The data processing agreement should include explicit clauses on the five vendor questions above, plus a breach notification timeline, a right to audit, and a data return or deletion procedure at contract end. It should name the applicable statute, incorporate district-specific policy references, and specify that the school official exception applies.
For districts writing procurement policy from scratch, model DPA language from state student-privacy consortia is a reasonable starting point. Pair the DPA work with a broader AI policy that governs how detector scores can be cited in disciplinary proceedings. See our AI policy guide for the wider frame, and the district policy patterns piece for the classroom-level implications.
Frequently Asked Questions
Does FERPA prohibit AI detection tools?▼
No. FERPA governs how student records are handled, not whether they can be processed by a third-party tool. A properly structured contract under the school official exception can authorize the processing.
Is teacher-only use of a free detector a FERPA issue?▼
It can be. If a teacher pastes an identifiable student essay into a consumer-facing tool with no district contract in place, the vendor is not operating under the school official exception and the disclosure may be improper.
What about tools that anonymize submissions?▼
Anonymization helps but is not a full solution. Writing samples can be re-identifiable, and the classifier output may still be used in a way that ties back to a specific student. Anonymization should be a supplement to the contractual protections, not a replacement.
Do state student-privacy laws add requirements?▼
Often yes. States like California, New York, Illinois, and Colorado have layered additional requirements onto the FERPA baseline. Check your state consortium's model contract language.
What if the vendor won't sign a district DPA?▼
Consider that a procurement red flag. Serious education vendors are used to signing district DPAs, and refusal usually indicates a mismatch between the product's data practices and the district's compliance posture.
The Bottom Line
FERPA compliance for AI detection is not a technical problem. It is a procurement problem. The tools that make it easy are the ones that already build for institutional buyers with published data terms, named subprocessors, and clear training-use language. The tools that make it hard are the consumer-facing ones with terms designed for individual users.
Districts that write the five vendor questions into their procurement process and refuse to sign without written answers will filter out most of the compliance risk before the contract stage. The remaining work is keeping the DPA up to date as vendors add features and change subprocessors.
