Does a signed data privacy agreement make an AI vendor FERPA compliant?

A contract can document purpose and control; use and redisclosure; security and deletion; and other obligations. FERPA's school-official exception still depends on the actual institutional function, the district's direct control regarding education records, and legitimate educational interest. District privacy and legal teams should evaluate the service. Request policy can then restrict managed model calls to the approved purpose and user roles, data classes, accounts, and endpoints.

Should a district approve the vendor or each model?

The vendor relationship belongs in procurement, while technical approval should identify the products and accounts; endpoints and model families; regions; and handling settings that were reviewed. A model or route change can affect subprocessors and retention, data location, and available safeguards. District policy should define which changes require renewed review. Until that decision is complete, a new identifier can enter a restricted state rather than inherit the vendor's existing approval.

Can a gateway govern AI embedded inside an edtech platform?

Coverage depends on the inference path. A district-controlled application can route an authenticated HTTP call through an external enforcement point. An edtech supplier that calls its model entirely inside the supplier's environment bypasses the district gateway. Contracts and data-flow documentation, administrative settings, vendor logs, and reassessment must cover that path. Local models and personal devices need controls in their respective layers, as do direct consumer accounts.

What evidence should the district keep after approving an AI vendor?

Keep the approved purpose and scope; contract; privacy and security review; provider account and model routes; subprocessors and regions; retention and deletion terms; change notices and route tests; exceptions and incidents; and reassessment history. For managed model calls, retain decision records that connect identity and purpose; student-data classification and destination; policy version and outcome; and time. District counsel and privacy officials should set retention because the evidence itself may reference an education record.

AI Vendor Risk in K-12 Education Follows Each Student Data Request

A district approves an AI writing assistant after legal and curriculum review plus privacy and security review. Three months later, the provider changes the model behind its classroom endpoint and adds a new subprocessor. On Tuesday afternoon, a teacher pastes an individualized education program excerpt into the same approved application. The green vendor record says the company passed review, yet it cannot show which model received the excerpt or which approved purpose covered the transfer. AI vendor risk K-12 education programs need to connect supplier conditions to the request that carries student data.

TL;DR

FERPA school-official status depends on function and legitimate educational interest, plus district control and limits on use and redisclosure.
The amended COPPA Rule requires covered operators to assess certain service providers and obtain written assurances while maintaining security and retention programs.
District approval should become request policy tied to identity and purpose; student-data class; provider account and model; region; and policy version.
Diligence belongs in the vendor file, with actual use reconstructed from per-request decision records.

FERPA makes vendor approval conditional

The FERPA regulations in 34 CFR Part 99 let an outside party such as a contractor, consultant or volunteer qualify as a school official under defined conditions. The party must perform an institutional service or function for which the district would otherwise use employees. It must remain under the district's direct control regarding the use and maintenance of education records. FERPA's redisclosure provision limits later use and disclosure. The district must also use reasonable methods to restrict school officials to records in which they have legitimate educational interests.

Those conditions belong in the vendor record, but they also describe runtime facts. A teacher-assistance model may perform an approved function for one workflow while an experimental capability sits outside that purpose. Direct control becomes difficult to defend when the district cannot identify the provider account and model route or the retention setting and downstream recipient attached to a request.

The broader privacy review belongs in student data privacy for edtech AI. Vendor risk starts where those approved conditions become technical constraints.

COPPA adds security and downstream assurance duties

The Federal Trade Commission's 2025 final amendments to the COPPA Rule took effect on June 23, 2025, with a general compliance date of April 22, 2026. The final rule requires a covered operator to keep a written information security program, assess internal and external risks at least annually, test safeguards regularly, and update the program when material circumstances change.

The amended rule also addresses downstream parties. Before allowing another operator or service provider to collect or maintain children's personal information on its behalf, or before allowing a third party to do so or releasing that information, the operator must take reasonable steps to determine that the recipient can protect it and obtain written assurances. Its retention provision requires a written policy stating the collection purposes and business need for retention, plus the deletion timeframe. Personal information collected online from a child may not be retained indefinitely.

The Federal Trade Commission declined to finalize proposed school-authorization and education-technology amendments in that rulemaking. Districts should avoid treating the 2025 amendments as a blanket permission for classroom AI. The applicable operator and audience, collection path, and existing guidance still need service-specific review.

The vendor inventory should describe an executable route

A K-12 vendor entry needs more than a company name and renewal date. It should identify each approved product and provider account; model endpoint and model family; hosting region and subprocessor chain; retention mode and deletion process; educational purpose; age or grade scope; permitted data classes; and accountable district owner. Contract language should address model changes and new subprocessors because either can alter the approved route while the user interface stays unchanged.

That inventory can supply attributes to an enforcement point. A teacher using a district lesson-planning workflow may send public curriculum material to one contracted endpoint. A counseling workflow carrying education records may require a different route or prohibit an external model. Student-facing tutoring may use an age-specific account with narrower collection and retention terms.

My view is that a district-wide green light for an AI vendor is a paper control. Schools already separate a library database from a special-education case system. Giving both workflows the same model permission discards a distinction the district enforces everywhere else.

AI vendor risk management covers the supplier program. The K-12 implementation should make its approved conditions usable by policy at the model call.

Student context has to travel with the request

Picture a case manager with a blue IEP folder open beside a district laptop. The screen shows an approved teaching assistant with the district logo. Beside it, the teacher selects a paragraph containing a reading score and disability category, along with an accommodation and parent concern, then asks the model to rewrite it in plain language. The logo proves which application is open. It says nothing about the student's record and the teacher's legitimate interest or about the model destination selected behind the interface.

The district application should attach the authenticated user or agent and role; school and approved workflow; educational purpose; age or grade context; and case or course reference. Content classification adds the relevant student-data category. The policy decision can then compare those facts with the provider account and model, region, and vendor approval state.

A shared API credential loses the person and purpose behind the call. The post-authentication problem in K-12 shadow AI shows the same gap on unapproved routes. Vendor approval fixes the destination question only when the managed request preserves enough context to decide if this use belongs there.

Change control needs request-level evidence

AI suppliers can change models and subprocessors, routing and retention behavior, or product functions between annual reviews. Contracts should define notice and approval requirements. Technical policy can catch the changes visible at the district-controlled request boundary. A new model identifier and account, region, or endpoint can move the call into review rather than inherit permission from the vendor name.

The district should test the route with synthetic records before launch and after a material change. One test can allow public lesson material through the approved teacher workflow. Another can present an IEP-like synthetic prompt to an endpoint that lacks approval for that data class. Preserve the expected result and actual outcome; test identity; provider and model; policy version and reviewer; and date.

A live decision record should capture the authenticated identity and acting application or agent; approved purpose and student-data classification; destination and model version; region and policy version; decision and reason; and timestamp. Full prompt retention deserves a separate privacy decision because it can create another repository of education records. A protected reference or content fingerprint may support correlation with less duplication.

The AI vendor risk assessment template provides diligence questions. Request evidence shows whether the deployed route stayed inside the resulting approval.

DeepInspect

DeepInspect sits between authenticated district users or agents and HTTP-based LLM endpoints as a stateless proxy. The district application supplies identity and role; school and purpose; age or grade context; and workflow references. DeepInspect classifies the routed request and checks those facts against the approved provider account and model, region, and versioned policy before student data reaches the endpoint.

Each decision creates a signed, tamper-evident record outside the calling application's write path. DeepInspect covers managed HTTP AI traffic deliberately routed through it. Vendor selection and contract interpretation; FERPA and COPPA analysis; consent and curriculum review; identity proofing; embedded vendor inference; local execution; and student decisions remain with their district owners.

Book a demo today.