Schools receive a lot of vendor proposals that mention FERPA in passing. "We are FERPA compliant" appears in pitch decks and product websites as if it were a certification -- a box checked that settles the question. It does not settle the question. FERPA compliance is not a status a vendor holds independently; it is a set of obligations the school and the vendor enter into together when student education records are involved. Understanding what that actually requires in practice makes piloting a new tool less intimidating and less legally risky.
What FERPA actually says about third-party tools
The Family Educational Rights and Privacy Act governs how schools handle education records -- any records directly related to a student that are maintained by the school. When a school shares those records with a third-party vendor, FERPA requires that the disclosure fall into a permitted category. For most edtech tools, the relevant category is the "school official" exception: a school may share education records with a vendor without parental consent if the vendor is functioning as a school official with a legitimate educational interest and is performing services the school would otherwise perform itself.
Using this exception requires a written agreement -- a data processing agreement or DPA -- in which the vendor agrees to use the student data only for the purposes specified, not to disclose it to further third parties without authorization, and to destroy or return the data when the relationship ends. Without a signed DPA, a school sharing student education records with a vendor is likely violating FERPA, regardless of whether the vendor has good intentions.
This is the first thing a school needs before piloting an AI tool that will touch student data: a signed DPA. The DPA does not need to be a hundred-page contract. A well-drafted DPA for an early-stage edtech pilot can be shorter than most school consent forms. What it must include: a description of what data is being shared, the specific purposes for which the vendor may use it, retention and deletion terms, and a statement that the vendor will not use student data for purposes outside the agreement including advertising, model training, or data brokering.
What data is actually being shared
The second thing a school needs is a clear data map: a specific list of what student data is being shared, in what form, and through what technical mechanism. This sounds more bureaucratic than it is. Most useful edtech tools need relatively minimal data to function: student identifiers (first name, grade level, assigned class), responses to practice questions or diagnostic items, and optionally performance data from the LMS.
The data map matters because it determines the scope of the privacy obligation. Sharing a student's name and their responses to twenty math questions carries a different risk profile than sharing their full academic record, attendance history, and behavior notes. A school that maps the data share precisely can make an informed risk assessment about whether the educational benefit justifies the data sharing. A school that signs up for a new tool without knowing what data is flowing is flying blind on the privacy analysis.
Some AI tools in the education space require more extensive data access than is necessary for their function -- they request full gradebook access when they only need diagnostic question responses, or they retain data beyond the pilot period in ways that are not disclosed. A data map conversation with the vendor at the start of the pilot surfaces these issues before they become contractual problems.
The model training question
One question that schools are increasingly asking, and should ask, is whether the vendor uses student responses to train AI models. The answer matters because model training is a purpose distinct from delivering the educational service the school signed up for. If a student's diagnostic responses are being used to train a model that will be sold to other customers or used to improve a product beyond what the school agreed to, that is a use of student data beyond the scope of the school official exception.
Vendors in the education space vary significantly on this point. Some explicitly prohibit using school-originated student data for model training. Others have vague privacy policies that do not address the question clearly. Still others disclose it in the terms of service in language that schools do not typically scrutinize closely. Before signing a DPA, a school should ask the question directly: will any student data generated through our use of your tool be used to train AI models? The answer should be in writing in the DPA, not just in a sales conversation.
State student privacy laws beyond FERPA
FERPA is the federal baseline, but most states have enacted additional student data privacy laws that impose obligations beyond FERPA. California's Student Online Personal Information Protection Act (SOPIPA) is one of the most cited, but similar laws exist in New York, Colorado, Texas, Illinois, and dozens of other states. These state laws often extend to a broader category of operators than FERPA's school-official exception, apply regardless of whether the school receives federal funding, and impose specific restrictions on advertising, data sharing, and data deletion.
A school that is relying solely on FERPA compliance as its privacy framework for new tool adoption may be unaware that its state law imposes additional or stricter obligations. Checking the vendor's DPA against the state's student privacy statute -- or asking the vendor whether their standard DPA covers the school's state's requirements -- is a reasonable due diligence step that takes less than an hour and can prevent regulatory problems later.
What the school's IT and legal teams actually need to see
In practice, piloting a new AI tool in a K-12 school typically requires sign-off from two groups: the curriculum or instructional team that evaluates the educational merit, and the IT and legal or compliance team that evaluates the data privacy and security dimensions. These two conversations often happen on different timelines, which creates delays when the privacy review starts only after the curriculum team has already committed to a pilot start date.
The practical solution is to run both tracks in parallel. The instructional team evaluates the product on educational merit. The IT team reviews the vendor's security practices (data encryption, access controls, breach notification procedures) and confirms that the technical integration is feasible. The legal or compliance lead reviews the DPA. If all three tracks reach a positive conclusion, the pilot can start. If any track identifies a problem, it can be addressed without having already made commitments to teachers or students about a start date.
None of this is more difficult than standard procurement due diligence for any other vendor the school uses. The privacy framework around student data is specific to education, but the practical steps -- confirm what data is shared, get a written agreement, check against state law, verify security practices -- are familiar institutional risk management processes. Treating them as obstacles specific to AI tools is a framing problem, not a real difficulty.