Does FERPA ban universities from using LLMs with education records?

FERPA governs disclosure and use of personally identifiable information from education records. An outside service may fit an applicable exception when the institution satisfies its conditions. For the school-official exception, those conditions include an institutional function and legitimate educational interest, plus direct control and use and redisclosure restrictions. The university should evaluate the actual provider and account, along with the model route and purpose. It should separately evaluate the data and contract. An approved brand name alone leaves that analysis incomplete.

Can a university solve shadow AI with an approved-tool list?

An approved-tool list creates a procurement boundary. Runtime policy still needs to distinguish public research from a prompt containing a transcript or participant interview. A financial-aid file requires the same distinction. The useful decision binds identity and role to purpose and content. It also evaluates the destination on each managed HTTP request. Direct browser sessions that avoid the route require browser and endpoint controls, plus DNS and egress controls.

What belongs in a denied-request record?

Record the user or agent and source application, plus the institutional purpose and detected information class. Add the intended endpoint and active policy version, together with the timestamp and denial reason. A controlled fingerprint or source reference can support correlation while limiting duplicate storage. That record proves the configured policy acted before the LLM received the prompt.

Can the gateway inspect AI built into a learning platform?

Coverage depends on the model route. A university-controlled application can send its authenticated HTTP model call through an external enforcement point. A learning platform that performs inference inside the vendor's service bypasses the university's proxy. Contract terms and product configuration, plus vendor audit exports and assurance evidence, must cover that path.

Shadow AI in Higher Education: Student Records and Research Data, Plus Financial Aid

An academic adviser pastes a student's transcript and probation note into an AI assistant, adding the student's accommodation history to draft a follow-up email. The browser tab uses the adviser's personal account. A yellow sticky note beside the monitor carries the student's campus ID. One outbound HTTPS request can move an education record into a service the university never approved, with no campus record of the provider or purpose and no record of the terms.

Shadow AI in higher education spreads through a decentralized institution. Faculty choose teaching tools. Researchers add model APIs to scripts. Admissions and financial aid hold different records under different rules, as do advancement and human resources. The useful security question is precise: which authenticated person or agent sent which campus data to which LLM endpoint, under which policy?

TL;DR

Campus shadow AI can expose education records and applicant files, along with research material and donor data, plus financial-aid records through a single prompt.
FERPA duties follow personally identifiable information from education records into an AI request; removing a filename leaves the record content intact.
Covered financial activities can add FTC Safeguards Rule duties, including oversight of service providers handling customer information.
DeepInspect governs authenticated HTTP model calls routed through it. Direct consumer browsing and vendor-internal AI need separate controls.

Campus data converges inside the prompt

Higher education systems separate records by office. An LLM prompt can collapse those boundaries in seconds. An adviser may combine grades with health-related accommodation context. An admissions analyst can send essays and reviewer notes. The same request can include demographic fields. Financial-aid staff handle tax and loan information. Advancement teams hold donor profiles. Faculty members choose teaching tools within their schools and departments. Research groups work with participant data and unpublished findings. They also handle licensed corpora and grant proposals. Source code can enter the request as well.

The DeepInspect shadow AI pillar explains how unauthorized model use bypasses procurement and security review. A university adds decentralized buying authority and broad academic autonomy. That combination makes provider-domain inventory necessary but incomplete. The prompt content and originating identity determine the actual exposure. The source application and destination matter as well. So does the purpose.

I would reject a campus policy that treats every public chatbot as one risk category. A professor summarizing an open-access article presents a different decision than an adviser sending named student notes. Governance by provider logo erases that distinction. Request-level policy preserves it.

FERPA follows education records into AI traffic

The Department of Education publishes the current FERPA regulations at 34 CFR Part 99. The rules govern disclosure of personally identifiable information from education records and provide exceptions with specific conditions. Under the school-official exception, an outside party must perform an institutional service or function and meet the institution's criteria for a school official with a legitimate educational interest. It must remain under the institution's direct control concerning use and maintenance of records and follow use and redisclosure restrictions.

An employee's personal AI account arrives with none of that institutional analysis by default. The university lacks an approved function and negotiated handling terms. It also lacks verified subprocessors and a documented route. A copied transcript or advising note still carries record content after the user removes the portal header.

The approved workflow should identify the institution and user or agent. It should also identify the student-record category and legitimate purpose. The provider account and model endpoint should be identified as well. It should record retention terms and applicable policy. The FERPA and AI compliance guide covers the school-official conditions in more detail. Shadow AI is the branch where the model request escapes that approved arrangement.

Research data creates a second confidentiality path

Research material needs its own policy family. A lab prompt may contain interview transcripts and genomic fields, plus survey responses and export-controlled technical detail. It may also contain sponsor data or findings awaiting peer review. Another request may include public abstracts and open-source code. The destination decision should reflect the data-use agreement and consent terms, plus sponsor restrictions and institutional review requirements. The software or corpus license that governs the source material also applies.

The Department of Education's guidance on privacy and security for online educational services emphasizes understanding which information a provider collects and how it uses that information. It also emphasizes how contractual terms affect control. The 2014 document addresses school and district online services rather than modern LLM architecture, yet the provider-review principle carries directly into a campus model route.

A research application can attach the principal investigator and protocol or project identifier to each HTTP request. It can attach the source repository and data classification as well. It can also attach the approved purpose. The enforcement point can then restrict a participant-data prompt to an authorized endpoint while permitting public-literature work on another route. Local models and offline computing remain under research-computing controls because those paths bypass an HTTP gateway.

Financial aid can add safeguards obligations

Campus finance functions hold bank details and tax information, plus loan records and identity documents. The FTC Safeguards Rule requires financial institutions under FTC jurisdiction to protect customer information and take steps to ensure that affiliates and service providers safeguard information in their care. A university should have counsel and its financial-aid compliance team determine which institutional activities and records fall within the applicable requirements.

For a covered workflow, an unknown AI service creates an immediate service-provider problem. Procurement has no contract to test. Security has no approved account or configuration. The financial-aid office lacks evidence about retention and reuse, plus incident notice and deletion. The request may also mix education-record information with financial customer information, so one prompt can engage more than one campus control set.

An approved route should bind the staff member or agent to the financial-aid function and specific purpose. Prompt classification can identify taxpayer identifiers and bank data, plus aid records and uploaded identity documents. Policy can deny a consumer endpoint or permit a contracted endpoint. It can redact fields when the remaining request is allowed. The event record preserves the destination and outcome for later review.

Discovery and enforcement cover different campus paths

A university needs to discover direct consumer use before it can move activity onto managed infrastructure. Secure web gateway logs and DNS telemetry, plus endpoint detection and browser controls, can reveal unapproved AI domains or accounts. Expense data and identity-provider events provide additional evidence. The shadow AI detection guide explains how those layers contribute different evidence.

Discovery rarely reveals the complete prompt after TLS termination occurs at the provider. An authenticated application or managed AI access service can route HTTP model traffic through an inline policy point. That path supports content classification before transmission and identity-aware enforcement. It also produces a per-decision record.

Vendor-embedded AI forms another branch. A learning platform, research service, student-information system, or productivity suite may call a model entirely inside the vendor's environment. Campus routing controls never receive that request. Contract review and configuration, plus vendor logs and data-flow documentation, have to cover it. Periodic assurance does too. The architecture diagram should label each path instead of coloring the entire campus "monitored."

Campus policy needs identity and institutional purpose

A useful request decision combines several inputs:

Identity: authenticated staff member or faculty member; student or contractor; service account; agent.
Institutional role: adviser or instructor; researcher or admissions analyst; financial-aid officer; administrator.
Purpose: advising or research; instruction or drafting; extraction or assessment; another approved use.
Data: education records or applicant material; participant data or financial information; donor records; public content.
Destination: provider account and model endpoint; region and approved handling tier.
Source context: campus application or project; course or protocol; office responsible for the request.

The calling application owns accurate identity and purpose context. Shared API credentials weaken the record because they reduce many people to one integration principal. Policy should evaluate the supplied attributes with prompt classification, together with the destination, at the moment of the call.

A denied event matters during review. It can show that a named adviser attempted to send record content to an unapproved endpoint and that the payload stopped before transmission. Repeated denials from the same workflow can also reveal a missing sanctioned service or a training problem.

Evidence should reconstruct one model request

A review team should be able to choose one request and reconstruct the control sequence. The record needs the authenticated person or agent and source application; the institutional purpose and detected data category; the intended model endpoint and policy version; the timestamp and outcome. If policy redacted content, the record should identify the rule and resulting route. Response records should correlate to permitted requests.

Prompt retention deserves a separate campus decision. Full content can create a new repository of student and research data. Some workflows may use a controlled source reference and content fingerprint. They may also store the classification. Legal holds and research obligations, plus student access rights and incident response, can require different retention choices.

The gateway record supports the technical event. It never replaces faculty judgment and research review, or FERPA analysis and financial-aid compliance. It also never replaces the underlying campus record. Joining the policy event to a course and project, or a student-service case and approved use identifier, gives auditors evidence without pretending that one control owns the entire institutional process.

DeepInspect

DeepInspect sits between authenticated university applications or agents and HTTP-based LLM endpoints. The campus application supplies identity and role, plus purpose and project or workflow context. DeepInspect classifies the routed prompt and applies per-role and per-route policy before an allowed request reaches the model. It can permit or deny according to the university's versioned rules. It can also redact.

Each routed decision produces an identity-bound audit record with the detected data category and destination, plus the policy version and timestamp. The record also includes the outcome. Consumer browser sessions and vendor-internal inference, plus local models and offline research pipelines, remain outside the proxy boundary. DeepInspect supplies enforcement and evidence for the managed HTTP AI traffic the university deliberately routes through it.

Book a demo today.