FERPA, Cloud Inference, and the Data-Sovereignty Question Procurement Should Be Asking

For procurement officers and general counsel evaluating AI-assisted accessibility tooling, the data-protection question that most vendor pitches do not address is also the most consequential one. When an institution's course materials are processed by an AI accessibility tool, the tool sends content somewhere to be inferred against — and where "somewhere" is, what is logged at that endpoint, and whether the institution's data-protection agreement covers that data flow are not questions whose answers can be assumed. For programmes built around the defensibility model laid out in the defensibility standard, this is the one of the six contract requirements where vendor responses tend to be vaguest, and where a casual procurement review most often fails to surface a real exposure.

Two questions sit at the heart of the issue. First, what counts as an "education record" under FERPA — and therefore what triggers FERPA's third-party-vendor protections. Second, whether a vendor that subprocesses inference through a foundation-model provider has produced a data flow the institution's existing data-protection agreement actually covers. The honest answer, across most institutional procurement reviews of AI accessibility tools today, is that the second question has not been asked in writing.

What FERPA actually covers

FERPA's "education records" definition (20 USC § 1232g; 34 CFR § 99.3) is broader than many institutional procurement reviews initially treat it. Education records are any records "directly related to a student" and "maintained by an educational agency or institution or by a party acting for the agency or institution." A faculty-uploaded exam paper that contains a student's name, identifier, or work product is an education record. A graded assignment is an education record. A discussion-forum post bearing a student's identifying handle is an education record. A lab report submitted via the LMS, an essay graded on Canvas, an answer key paired with student responses — all education records.

The "school official" exception (34 CFR § 99.31(a)(1)(i)(B)) permits disclosure to outside parties only under specific conditions: the party must perform a service for which the institution would otherwise use its own employees, must be under direct institutional control, must use the records only for authorised purposes, and must not redisclose them. Each condition is testable. None can be assumed.

The Department of Education's FERPA portal treats third-party AI service providers under this same school-official framework. The framework is not new. What is new is the volume and variety of student-content flows that AI tooling introduces into the institutional infrastructure, and the corresponding need for procurement to verify each flow against the framework rather than assume the vendor has done so.

What cloud inference actually does to data

When an AI accessibility tool processes a document, the model runs somewhere. Three architectures are common.

In the first, a vendor operates its own inference infrastructure on contracted compute. The data flow is institution → vendor → vendor's compute. The data-protection agreement is between the institution and the vendor. If the agreement covers the vendor's full data flow, FERPA compliance is plausible.

In the second, a vendor calls a third-party foundation-model API — OpenAI, Anthropic, Google, or another provider — for inference. The data flow is institution → vendor → foundation-model provider. There are now three parties to the data flow, and the institution's data-protection agreement is typically with only one of them. The foundation-model provider's terms of service govern what happens to the data once it arrives at the inference endpoint: retention windows, training-data inclusion (whether the data is or is not used to improve future models), logging policies, and any data-residency commitments. Many foundation-model providers offer enterprise tiers with stricter terms; many vendors in the accessibility-AI market do not subscribe to those tiers, defaulting their customers' data flow into the looser default-tier conditions.

In the third architecture, the inference runs on infrastructure the institution operates directly, or on a vendor environment that is fully covered by the institution's data-protection agreement and operates within the institutional network perimeter. The data flow stays under one set of contractual controls. This is the architecture that produces FERPA defensibility without requiring a chain of three-party negotiations.

The specific procurement question for any AI accessibility vendor is therefore narrow: which of these three architectures applies to the vendor's product, and is the data flow fully covered by an executed data-protection agreement? The question is not theoretical. It has direct contract consequences for a complaint or a data-breach investigation.

The DPA gap most institutions have today

A useful audit any procurement office can run today is to take three vendor contracts in their AI accessibility portfolio and verify, for each, whether the data-protection agreement covers the inference path. Three patterns recur in the audits we have seen across higher-ed procurement reviews.

The first is silent subprocessor disclosure: the vendor's contract permits subprocessors generally but does not name the foundation-model provider. The contract is technically compliant with the institution's standard subprocessor clause, but the institution does not know in writing where its content is being inferred. A complaint investigation requesting "where does our student content go" cannot be answered from the contract alone.

The second is partial DPA coverage: the vendor has signed the institution's data-protection agreement, but the agreement covers the vendor's own infrastructure, not the third-party inference endpoint. The vendor's terms of service with the foundation-model provider are between the vendor and the provider; the institution is not party to those terms. Whatever protections the institution negotiated apply at the vendor boundary, not at the inference boundary.

The third is unsigned residency commitments: the vendor's marketing material describes data residency in the institution's region, but the contract contains no enforceable residency clause. In a regulated procurement environment, marketing claims that do not appear in the contract cannot be relied on.

Each of these patterns is fixable, but only if the institution surfaces the gap in writing during procurement review. The gap will not surface in a vendor demonstration, will not appear in a scanner-conformance scoring document, and will not be mentioned in a sales conversation unless the institution asks.

Questions procurement should add to vendor DDQs

Five questions, each requiring a written response, close the procurement gap.

First, where does inference physically execute? Country, region, and data-centre operator. Marketing-language answers (e.g., "in the cloud") are unacceptable.

Second, what subprocessors are involved in inference, and on what terms? A list of named subprocessors with the terms-of-service or data-protection clauses that govern the flow.

Third, what is logged at the inference endpoint, and for how long is it retained? Logs of submitted content, of derived outputs, and of any metadata associated with the institutional account. Retention windows must be specified in the contract, not in marketing material.

Fourth, is submitted content used to train or improve future models? A binary yes/no, with the contract clause that enforces it. Training-data exclusion is enforceable only if it appears in the contract.

Fifth, does the institution's executed data-protection agreement cover the full data flow including the inference endpoint? If the answer is no, what additional agreement closes the gap?

Vendors whose written responses to these five questions are clear and contractually backed are vendors whose data-protection posture an institution can defend in writing. Vendors whose responses require qualification or additional negotiation are vendors whose existing customers may be carrying a procurement gap they have not yet surfaced.

Self-hosted inference as a procurement category

The architectural option that eliminates the questions above as a category is self-hosted inference: running the model on infrastructure the institution operates directly, or on a vendor environment fully inside the data-protection agreement perimeter. This is not a single vendor's offering — it is a procurement category that several accessibility-AI vendors now support. For institutions whose risk posture is high, whose student-content sensitivity is unusually broad, or whose state-level data-protection regulations exceed FERPA's federal floor, self-hosted inference removes the third-party-inference question from the procurement matrix entirely.

The trade-off is transparent. Self-hosted inference requires institutional infrastructure (or a vendor partnership operating inside the institutional perimeter) and may carry per-document costs that differ from cloud-inference pricing. For institutions whose data-protection posture cannot tolerate the contract gaps surveyed in the previous section, the trade-off is worth examining at the procurement-strategy level — not just the vendor-comparison level. The broader contract framework these architectural choices fit into is covered in the defensibility standard's procurement section.