FERPA and AI: What School Records Confidentiality Requires from AI Tools in K-12 and Higher Ed

The Family Educational Rights and Privacy Act (FERPA) protects the confidentiality of education records. The statute and its implementing regulations at 34 CFR Part 99 set out who can access education records, under what conditions, and with what disclosures. Schools and the edtech vendors operating on their behalf are now putting student-level data through AI tools for tutoring, grading assistance, behavioral analytics, parent communication drafts, and IEP support. The "school official" exception at 34 CFR 99.31(a)(1)(i)(B) is the doctrine that lets vendors process education records. The exception applies only when specific conditions are satisfied. Most AI vendor relationships in K-12 and higher education were constructed before AI tools came into the workflow and do not satisfy the conditions for the AI use specifically.

I want to walk through what FERPA requires when AI processes education records, where the school official exception breaks for AI tools, and the inspection architecture that produces a defensible record of AI access to student data.

What FERPA requires of vendor access to education records

The school official exception at 34 CFR 99.31(a)(1)(i)(B) lets schools share education records with parties performing services for the school, without prior parental consent, when four conditions are satisfied.

The first condition is that the party performs a service for which the school would otherwise use employees. The party has to be doing institutional work, not a vendor's own work.

The second condition is that the party is under the direct control of the school with respect to the use and maintenance of education records. Direct control means the school dictates the terms of use, retention, and disposal.

The third condition is that the party is subject to the use and re-disclosure restrictions at 34 CFR 99.33. The party cannot redisclose without authorization and cannot use the records for purposes outside the institutional service.

The fourth condition is that the party has a legitimate educational interest. The legitimate educational interest has to be defined in the school's annual notification of FERPA rights and tied to the specific function the party performs.

For an edtech vendor providing a tutoring platform, the conditions can be satisfied through a Data Privacy Agreement that includes the use restrictions, the redisclosure prohibition, the legitimate educational interest description, and the school's audit rights.

For an AI tool the vendor uses under the hood to power the tutoring feature, the conditions have to be flowed through. The AI provider becomes a sub-vendor with its own FERPA exposure. The school is the data owner. The vendor is the school official. The AI provider sits behind the vendor with its own retention, use, and redisclosure terms that the vendor's DPA has to constrain.

Where the school official exception breaks for AI tools

The exception breaks in four specific places when AI enters the workflow.

The AI provider's terms allow training or retention beyond the institutional service

OpenAI's default API terms have changed several times. Anthropic's terms differ. Google's terms differ. Microsoft Copilot terms differ. For each AI provider the edtech vendor uses, the school has to verify that the terms in effect at the time of use prohibit training on student data, limit retention to what is necessary for the service, and bind the AI provider to the use restrictions FERPA requires. Most vendors did not flow this through. The school's DPA with the vendor predates the AI integration. The vendor's contract with the AI provider may be a self-service consumer-grade signup.

The "direct control" condition fails when the AI provider sets the data flows

Direct control under 34 CFR 99.31 means the school dictates how the records are used and maintained. When an edtech vendor sends a student's writing sample to OpenAI for AI-assisted feedback, the data flow, retention, and processing terms are set by OpenAI's API contract, not by the school. The school's direct control over the AI step is weak. The exception applies only when the control is meaningful.

The legitimate educational interest is not defined for the AI step

Schools that drafted their FERPA annual notifications before AI was integrated into edtech did not enumerate the AI tools as parties with legitimate educational interest. The notifications cover vendors by category but rarely cover AI sub-vendors specifically. The legitimate educational interest condition is undefined for the AI step, which leaves the exception unavailable for that step.

The records are not produced for FERPA access requests

FERPA gives parents and eligible students the right to inspect and review the education records maintained on the student. The right extends to records that vendors maintain on the school's behalf. When a parent requests records and the records include AI-generated content, AI-suggested interventions, or AI risk classifications, the school has to produce those records. Vendors that store AI outputs as transient artifacts cannot satisfy the access request. Schools that cannot reach into vendor environments to produce the records sit on a compliance gap.

What real architecture requires for AI on education records

The architecture that satisfies the FERPA regime when AI is in the loop has three properties.

The first is identity attribution at the AI request boundary. Every AI call that touches an education record is tied to the school, the school official making the request, the student whose record is involved, and the legitimate educational interest under which the call is made. The attribution is on the call, not reconstructed from session metadata.

The second is per-decision audit records. Every AI interaction produces a record containing the inputs (or input fingerprints), the AI output, the retention parameters, the policy that governed the call, and a cryptographic signature. The records support FERPA access requests, audit obligations, and incident investigation.

The third is policy enforcement at the prompt boundary. PII in education records is detected at the prompt. Re-identifiable information is redacted, blocked, or routed to a sanctioned AI provider with the right contractual terms. The policy is school-specific and runs at the AI request layer regardless of which edtech vendor's product the request originates from.

DeepInspect

This is the gap DeepInspect closes for K-12 and higher education AI use. DeepInspect sits inline between school environments (or edtech vendor environments operating under the school official exception) and any AI provider. For every AI call that involves an education record, DeepInspect attaches the school's identity, the school official's role, the student identifier (or fingerprint where direct identification is not appropriate), the data classification under FERPA, and the policy version in effect. It records the outcome with a cryptographic signature.

For the school, the inspection layer produces the records that satisfy a FERPA access request, an Office of Civil Rights audit, or a state-level data privacy audit. For the edtech vendor operating under the school official exception, the inspection layer demonstrates direct control and supports the vendor's contractual obligations to the schools the vendor serves.

If you are running an edtech product or a school district CTO function and your AI usage sits outside the school official exception's conditions, let's talk.