Compliance Guide
How to Audit EdTech AI Vendors for FERPA Compliance
To audit EdTech AI vendors for FERPA compliance, start by confirming the FERPA basis for disclosure, usually the school official exception or audit/evaluation exception. Then test whether the vendor is under the education organization’s direct control for use and maintenance of education-record PII, limits use and redisclosure, protects linked or linkable student data, and can return or destroy data when it is no longer needed.
For AI systems, the audit must also examine prompts, retrieved context, embeddings, logs, generated outputs, model-training restrictions, tool calls, agent permissions, subprocessors, and runtime auditability.
FERPA AI vendor audit scope
A practical audit should connect the legal basis for disclosure to the technical places where student data may move, persist, or be transformed. The following scope areas summarize the supplied audit focus.
Legal basis
Document the FERPA exception, purpose, scope, duration, and permitted use before student data is disclosed.
Data flow
Map where education-record PII enters, persists, is transformed, embedded, logged, retrieved, or sent onward.
AI controls
Assess prompt handling, retrieval authorization, model-training limits, tool permissions, and generated output governance.
Ongoing oversight
Require logs, access reviews, deletion verification, change notice, and runtime policy enforcement after approval.
Map FERPA obligations to the AI architecture
A useful FERPA AI vendor audit follows the data, not the product description. Many EdTech AI systems include an application front end, orchestration layer, retrieval system, vector database, model provider, logging and telemetry stack, support tooling, and subprocessors. Student PII may appear in each layer, sometimes in forms that are not obvious to business reviewers.
Identify where student PII appears
Prompts and uploaded files can contain direct student identifiers. Retrieved context may include grades, accommodations, disciplinary notes, attendance, or other education-record data. Embeddings may encode content derived from student records and must be assessed for tenant isolation, authorization filtering, and deletion behavior.
Review operational records and logs
Logs may preserve prompts, outputs, errors, tool inputs, and support actions. Generated outputs may become operational records if they are maintained by the school or vendor and are directly related to identifiable students.
Verify retrieval authorization
For retrieval-augmented generation, the audit should verify that authorization is enforced before retrieval, not merely at the user interface. The vendor should show how records are filtered by tenant, role, student relationship, or other approved access boundaries before they enter the model context window.
Assess agentic features
For agentic features, the audit scope expands again. An AI agent may call tools, query systems, send messages, retrieve student files, or update records based on delegated permissions. The vendor should provide tool allowlists, scoped credentials, approval gates for sensitive actions, and logs of tool inputs, outputs, and authorization decisions.
Evaluate enforcement points
Policy enforcement should be evaluated at multiple points: before model submission, before retrieval, before tool execution, and before output delivery. A control that only warns users after sensitive data has already been sent to a model or subprocessor may not be sufficient for FERPA-aligned governance.
Why FERPA vendor oversight changes when AI is introduced
AI changes the review surface because education-record PII can be included in prompts, retrieved context, embeddings, generated outputs, telemetry, support tools, and downstream model or tool calls. A vendor assessment that only reviews the application interface may miss where student data is copied, inferred from, retained, or sent onward.
The audit should therefore confirm both the FERPA disclosure basis and the technical controls that keep vendor activity aligned with the approved educational purpose.
Evaluate AI-specific risks during procurement and reassessment
During procurement and reassessment, compliance teams should review how the vendor limits use and redisclosure, protects linked or linkable student data, restricts model training, and handles records that must be returned or destroyed when no longer needed.
| Audit area | Questions to resolve | Evidence to request |
|---|---|---|
| FERPA basis and purpose | Which FERPA exception supports the disclosure, and what educational purpose limits the vendor’s use? | Decision record, contract terms, permitted-use language, redisclosure restrictions. |
| Data flow and persistence | Where does student PII enter, persist, transform, get embedded, get logged, or move to a subprocessor? | Data flow maps, retention schedules, subprocessor lists, storage and logging descriptions. |
| Retrieval and authorization | Are access controls enforced before retrieval and before context enters the model window? | Tenant, role, student-relationship, or other approved access-boundary controls. |
| Agent and tool permissions | Can an AI agent query systems, retrieve student files, send messages, update records, or call tools? | Tool allowlists, scoped credentials, approval gates, logs of tool inputs and outputs. |
| Deletion and return | Can student PII be returned or destroyed when it is no longer needed? | Deletion procedures for active systems, logs, embeddings, caches, backups, evaluation datasets, and subprocessor environments. |
Evidence to request during a FERPA AI vendor audit
- Documentation of the FERPA disclosure basis, authorized purpose, covered data categories, and permitted users.
- Contractual restrictions on use, redisclosure, model training, secondary use, and retention.
- Data flow documentation showing prompts, retrieved context, embeddings, logs, generated outputs, tool calls, subprocessors, and support access.
- Authorization controls for tenant boundaries, roles, student relationships, retrieval filters, and delegated agent permissions.
- Runtime logs for prompts, retrieval events, model outputs, policy denials, tool calls, exports, human access, and deletion events.
- Deletion or return procedures covering active systems, logs, embeddings, caches, backups, evaluation datasets, and subprocessor environments.
- Change notice obligations for new models, subprocessors, agent capabilities, telemetry expansion, retention changes, or new data uses.
Operate the vendor relationship as an ongoing control, not a one-time approval
- Maintain a FERPA decision record: Document the disclosure basis, authorized purpose, covered data categories, permitted users, vendor obligations, and any restrictions on training or secondary use.
- Schedule periodic access reviews: Review user, administrator, support, service account, agent, and tool permissions to confirm least privilege still matches the approved educational purpose.
- Review runtime logs: Use audit logs to examine prompts, retrieval events, model outputs, policy denials, tool calls, exports, human access, and deletion events.
- Test deletion obligations: Periodically verify that student PII can be deleted or returned from active systems, logs, embeddings, caches, backups, evaluation datasets, and subprocessor environments.
- Require change notice: Contractually require notice and reassessment for new models, subprocessors, agent capabilities, telemetry expansion, retention changes, or new data uses.
- Prepare for AI-specific incidents: Incident response plans should address prompt leakage, unauthorized retrieval, overbroad tool access, output-based data leakage, and misconfigured logging or training.
Where runtime governance supports FERPA-aligned oversight
Runtime governance supports FERPA-aligned oversight by making policy enforcement and auditability part of day-to-day AI operation. For EdTech AI systems, that means controls should be available where data is submitted to models, retrieved into context, passed to tools, returned as output, retained in logs, or accessed by human operators.
How should retrieval-augmented generation be audited?
Review whether authorization is enforced before retrieval, and whether records are filtered by tenant, role, student relationship, or other approved access boundaries before they enter the model context window.
Why do embeddings need review?
Embeddings may encode content derived from student records. They should be assessed for tenant isolation, authorization filtering, and deletion behavior.
What makes agentic features different?
An AI agent may call tools, query systems, send messages, retrieve student files, or update records based on delegated permissions. Audits should review tool allowlists, scoped credentials, approval gates, and logs of tool inputs, outputs, and authorization decisions.
Strengthen FERPA oversight for AI agents and tools
If your EdTech environment uses AI agents that access student data, evaluate how runtime policy enforcement, least-privilege permissions, tool approvals, and audit logging can support ongoing compliance governance.
Request a Demo