Direct answer
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.
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.