Federal student privacy

FERPA and AI in K-12 Schools: A District Guide

FERPA does not approve or prohibit AI products by category. A district must identify the education records involved, establish consent or a valid exception, satisfy every condition of that exception, and control how the provider uses and maintains the records.

Audience
School district privacy, legal, technology, security, procurement, curriculum, data governance, and application teams
Read time
20 min read
Published
Reviewed
Review
TrueMadeAI Engineering

Current status: Last reviewed August 11, 2026. This guide provides educational information, not legal advice or a determination that any product or use complies with FERPA.

FERPA does not make AI categorically allowed or categorically prohibited. It requires a covered school district to determine whether an AI use involves personally identifiable information from education records, whether consent or a valid exception permits the disclosure, and whether every condition of that legal basis is satisfied for the actual provider, product, account, feature, and data flow.

For many district-provided AI services, the relevant FERPA path may be the school-official exception. That exception is conditional. The provider must perform an outsourced institutional service or function, remain under the district’s direct control regarding the use and maintenance of education records, follow FERPA’s limits on use and redisclosure, and meet the district’s annual-notice criteria. The district must also use reasonable methods to limit access to records in which a school official has a legitimate educational interest.

A contract or data privacy agreement can document those boundaries. It does not create the educational purpose, prove legitimate educational interest, make every product feature part of the approved arrangement, or prevent a person from submitting more student information than a task requires.

Last reviewed August 11, 2026. This guide describes federal FERPA requirements and district operating practices. State student-privacy laws, contracts, records rules, security requirements, and local policy can impose additional obligations.

The answer-first FERPA test for an AI use

Before a district sends records to an AI service, answer these questions in order:

  1. Is the district covered by FERPA? FERPA applies to educational agencies and institutions that receive funds under a program administered by the U.S. Department of Education.
  2. Does the use involve an education record? Identify the source record, not merely the format. A prompt, file, transcript, summary, embedding, or output may contain information drawn from a maintained education record.
  3. Is personally identifiable information involved? A name is not the only identifier. FERPA’s definition also addresses direct and indirect identifiers and information that, alone or in combination with other available information, can identify a student.
  4. Will the district disclose that information to another party? Trace the actual route through the application, model provider, logging service, connector, support system, and other recipient.
  5. Is there prior written consent or a specific exception to consent? Do not describe an exception as blanket authorization. Match the facts to the exact conditions of the exception.
  6. Are all conditions still true in the configured deployment? Account type, provider, model route, retention, connected tools, and subprocessors can change the answer.
  7. Can the district demonstrate the decision? Preserve the approval, purpose, data boundary, contract, configuration, owner, and review date appropriate to the use.

This sequence matters. Vendor security, a DPA, district SSO, and DLP are safeguards. None of them answers the legal-basis question by itself.

What FERPA requires, and what districts should add operationally

Topic Federal FERPA baseline District operating control
Consent Prior written consent is generally required before disclosing PII from education records unless a regulatory exception applies Record the consent or exception relied on for each approved data flow
School official An outsourced party may qualify only if the conditions in 34 CFR 99.31(a)(1) are met Bind the exact provider, product, account, features, users, and purpose in the approval record and contract
Legitimate educational interest The district must use reasonable methods to ensure school officials access only records in which they have a legitimate educational interest Use role, class, grade, student relationship, purpose, and operation to limit access rather than relying on login alone
Direct control An outsourced school official must be under district control regarding the use and maintenance of education records Put instructions, administrative controls, audit rights, change controls, deletion, and remedies into enforceable terms
Use and redisclosure A recipient generally may use PII only for the purpose for which disclosure was made and may not redisclose it except as FERPA permits Identify every model provider, subprocessor, connector, and support path, then flow restrictions through the chain
Access and records FERPA gives parents and eligible students defined rights concerning education records; disclosure recordkeeping applies subject to regulatory exceptions Ensure the district can locate, export, correct, preserve, and delete covered provider-held records as applicable
Security FERPA does not prescribe a particular security control Apply appropriate identity, access, encryption, logging, DLP, incident response, and vendor-security measures based on the risk
Breach response FERPA does not contain a general direct breach-notification requirement Prepare for FERPA recordkeeping plus any state, contract, insurance, other federal, and district notification duties

The right column contains operational recommendations, not a claim that FERPA names each control.

How the school-official exception applies to AI providers

34 CFR 99.31(a)(1) permits disclosure without prior consent to a school official with a legitimate educational interest. A contractor, consultant, volunteer, or other outsourced party may be treated as a school official only when it satisfies the regulation’s conditions.

1. The provider performs an outsourced institutional function

The district should describe the service or function with enough precision to evaluate it. “AI” is a technology label, not an institutional purpose.

Compare:

  • too broad: “help students with AI”;
  • governable: “provide formative writing feedback for students in grades 9 through 12 in enrolled English courses, without assigning final grades”;
  • too broad: “improve district operations”;
  • governable: “summarize approved public enrollment-policy documents for family-service staff, with source citations and human review.”

The description should identify what the provider does, who uses it, which records are involved, and what it may not do.

2. The district maintains direct control

Direct control concerns the provider’s use and maintenance of education records. A privacy policy that the provider can change unilaterally may be poor evidence of district control. The U.S. Department of Education explains that appropriate contract provisions can help establish direct control.

Direct control should be tested in practice:

  • Can the district restrict eligible users and data sources?
  • Can the district disable features, connectors, or accounts?
  • Are provider uses limited to district-authorized purposes?
  • Can the district obtain records and required evidence?
  • Can the district require return or destruction at the end of the purpose?
  • Can the provider add a model provider or subprocessor without notice or review?
  • What happens if the provider breaches an instruction?

FERPA does not generally require a written agreement solely because a district uses the school-official exception. That does not make a click-through agreement sufficient. Written terms are a practical way to define and enforce direct control, and state law, local policy, procurement rules, or another FERPA exception may require a written agreement.

3. Use and redisclosure remain limited

Under 34 CFR 99.33, a recipient generally may use PII only for the purpose for which the disclosure was made and may not disclose it to another party without prior consent, except where FERPA permits further disclosure.

For an AI deployment, this requires more than naming the customer-facing vendor. The district should identify:

  • the model provider or approved model deployment;
  • hosting, observability, support, and security providers that may receive covered content;
  • retrieval systems and document stores;
  • plug-ins, agents, connected drives, web search, and action tools;
  • human review or support access;
  • downstream destinations for generated output.

A connected service can create a new disclosure path. A feature that was acceptable with no connectors may require a new review after storage, search, email, or action tools are enabled.

4. The provider meets the annual-notice criteria

If a district discloses records under the school-official exception, its annual FERPA notice must specify the criteria for who constitutes a school official and what constitutes a legitimate educational interest. See 34 CFR 99.7.

The district should confirm that its notice actually covers the outsourced service relationship it intends to use. A contract cannot repair an annual notice that defines school officials too narrowly or omits the relevant criteria.

5. Access remains tied to legitimate educational interest

FERPA requires reasonable methods to ensure that school officials obtain access only to education records in which they have legitimate educational interests. The Department of Education notes that a district may use physical or technological controls, or an effective administrative policy that remains compliant.

This is why SSO is necessary but insufficient. SSO can establish that a person is a district user. It does not establish that the person needs a particular student’s IEP, discipline record, grade, health detail, or family information for the request being made.

For district AI applications, authorization should occur before retrieval. Determine whether the acting person or application is allowed to access the student, record, field, purpose, and operation before a retrieval system supplies context. DLP after retrieval is additional protection. It cannot retroactively authorize the original access.

A DPA documents the boundary; it does not create the boundary

A data privacy agreement is one part of an AI approval. It should match the exact deployment rather than the vendor’s brand in general.

At minimum, document:

Contract area Questions to resolve
Scope Which legal entity, product, account, features, model deployment, region, and administrators are covered?
Purpose What institutional service is performed, and which secondary purposes are prohibited?
Data Which prompts, files, records, metadata, outputs, logs, and derived data are covered?
Instructions and control Who may issue instructions, change configuration, enable features, or authorize a new purpose?
Training and improvement Are inputs, outputs, feedback, files, metadata, and derived data excluded from model or service improvement? What exceptions remain?
Retention and deletion What is retained by type, for how long, where, and under which deletion trigger? What remains in backups or required security records?
Subprocessors Who processes which data for which function, and what notice, objection, and flow-down terms apply?
Access How can the district locate, export, amend, preserve, and delete records maintained on its behalf?
Security Which administrative, technical, and organizational controls apply to the actual product?
Incidents What triggers notice, when does the clock start, what evidence and cooperation are required, and who controls communications?
Change management What happens when the provider, model, region, feature, connector, term, or data use changes?
Exit How are services disabled, credentials revoked, records exported, data returned or destroyed, and completion documented?

Use the more detailed AI vendor and DPA review questions during procurement.

Why no training is not enough

“No training” is valuable only after its scope is defined. It should say which products, accounts, inputs, outputs, files, feedback, metadata, and derived data are covered and whether the commitment is contractual, configurable, or merely a current practice.

Even a strong no-training commitment does not answer:

  1. whether the district was authorized to disclose the record;
  2. whether the acting person had a legitimate educational interest;
  3. whether the prompt contained more information than the task required;
  4. how the service retains prompts, outputs, logs, or saved history;
  5. whether people may review content for support, security, or abuse monitoring;
  6. whether connected tools or subprocessors receive the content;
  7. whether the output becomes a new maintained education record.

A no-training commitment limits a particular downstream use. It does not mean no processing, no retention, no human access, no redisclosure, or no risk.

Over-disclosure remains a problem after approval

An approved product and a sound DPA can still receive excessive information. Common examples include:

  • uploading an entire IEP when the task requires only a short description of an accommodation;
  • pasting a discipline narrative with names, dates, witnesses, and family details to revise one paragraph;
  • sharing a class roster when aggregate counts would answer the question;
  • entering information about several students when the task concerns one authorized student;
  • including indirect identifiers that make a supposedly nameless record identifiable;
  • using a personal consumer account when the district agreement covers only a managed education or enterprise account.

FERPA’s legitimate-educational-interest requirement is not identical to a universal “minimum necessary” rule. Districts should avoid borrowing that phrase as if it were FERPA’s statutory test. Data minimization is still a sound privacy and security practice: provide only the information needed for the approved purpose and use a less identifying alternative when it will work.

The K-12 AI data-boundary framework helps districts document which sources, fields, transformations, routes, outputs, and evidence belong inside an approved use.

Retention and deletion require separate answers

FERPA does not impose one universal retention period for every provider relationship under the school-official exception. Other FERPA exceptions can have explicit destruction requirements, and state law, records schedules, contracts, litigation holds, and district policy may also control.

For each data type, identify:

  • the default and configurable retention period;
  • whether deletion removes active content, account history, logs, indexes, embeddings, caches, and support copies;
  • what remains in backups and when it expires;
  • which security, abuse, or legal records are retained separately;
  • whether a restored backup can recreate deleted data;
  • how termination, student departure, or purpose completion triggers deletion;
  • what evidence the district receives when deletion is complete.

Do not use “zero retention” as a vendor-wide description unless the exact product, endpoint, feature, and account in use are covered. Training, retention, deletion, and backup expiry are separate controls.

Subprocessors and connected services are part of the FERPA analysis

AI products frequently depend on other entities. A district should not assume that signing with the interface vendor resolves every downstream disclosure.

Require a current subprocessor record that identifies each legal entity, function, data category, location, and effective date. Determine how the provider flows purpose, use, redisclosure, security, retention, deletion, and incident requirements to each recipient.

Connected services need the same discipline. Retrieval from a district drive, a web-search feature, an email action, or a plug-in can expand both the data entering the model and the destinations receiving output. Review authorization before retrieval, not only the final prompt. Screen retrieved context as an additional safeguard, not as the source of authorization.

When a provider can make further disclosures on the district’s behalf, FERPA’s disclosure recordkeeping and redisclosure conditions may be relevant to the arrangement. Districts should determine the exact obligations with counsel rather than relying on a generic subprocessor list.

DLP reduces point-of-use risk, but does not create FERPA compliance

The Department of Education states that FERPA does not prescribe specific security controls. Data loss prevention is therefore best described as an operational safeguard, not a legal certification.

On a supported and configured path, DLP can evaluate content before it leaves a managed device and apply district policy by warning, transforming, or stopping a send. This helps address the moment a user accidentally pastes a student name, record excerpt, contact detail, or other protected content into an AI product.

DLP does not:

  • establish consent or a FERPA exception;
  • prove legitimate educational interest;
  • put a provider under district control;
  • bind a model provider or subprocessor;
  • cover every text, file, image, voice, connector, native application, or embedded AI surface;
  • guarantee that all identifying context was detected;
  • establish that transformed information is legally de-identified.

FERPA permits release of de-identified records without consent only after the responsible party makes a reasonable determination that the student’s identity is not personally identifiable, considering other reasonably available information and single or multiple releases. Replacing a name with a token is useful pseudonymization, but it is not automatically FERPA de-identification.

Read Why Data Loss Prevention Matters in K-12 AI for the distinction among authorization, provider terms, no-training commitments, and point-of-use controls.

Incident response must account for more than FERPA

The Department of Education’s Data Breach Response Checklist states that FERPA itself does not contain a general direct breach-notification requirement. That does not mean a district can ignore an unauthorized disclosure.

Depending on the event, the district may need to:

  • record a disclosure as required by 34 CFR 99.32, subject to its exceptions;
  • investigate whether FERPA’s access, use, or redisclosure conditions were violated;
  • follow state breach-notification and student-privacy laws;
  • satisfy DPA, insurance, records, cybersecurity, and other federal obligations;
  • preserve necessary evidence without creating an uncontrolled copy of sensitive prompts or outputs;
  • coordinate accurate communication with affected people and authorities;
  • disable the account, connector, model route, or application while facts are established.

Contractual notice should identify a trigger, deadline, required facts, preservation duties, cooperation, subprocessor handling, and communication authority. “Notify promptly” is difficult to operate during a real incident.

Use the K-12 AI incident response playbook to connect privacy, security, legal, curriculum, accessibility, communications, vendor, and records roles.

FERPA is necessary, but it is not the whole AI review

FERPA does not determine whether an AI output is accurate, instructionally appropriate, accessible, unbiased, secure, or suitable for a consequential decision. It also does not replace:

  • the Children’s Online Privacy Protection Act for covered operators and users under 13;
  • the Protection of Pupil Rights Amendment where applicable;
  • state student-privacy, AI, biometric, records, consumer-protection, and breach laws;
  • district accessibility, civil-rights, procurement, cybersecurity, records, and instructional requirements;
  • contract and insurance obligations.

The FTC’s COPPA guidance permits school authorization in limited educational circumstances when information is collected for the school’s use and benefit and for no other commercial purpose. That is a separate legal analysis, not a FERPA exception. Review the exact age group, operator, collection, purpose, notice, access, deletion, and parental-consent model.

Check the dated state K-12 AI laws and guidance tracker and use qualified district reviewers for applicable requirements.

A district implementation checklist

Before approval

  1. Define the institutional service and educational or operational purpose.
  2. Identify users, roles, grades, schools, and acting applications.
  3. Trace education records and PII from source through every recipient and output.
  4. Determine consent or the exact FERPA exception with qualified counsel.
  5. Confirm the annual FERPA notice supports the intended school-official criteria.
  6. Test legitimate educational interest and authorization before retrieval.
  7. Review the exact product, account, features, model route, region, connectors, and subprocessors.
  8. Negotiate direct control, purpose limits, redisclosure, retention, deletion, security, incidents, changes, and exit.
  9. Evaluate COPPA, state law, accessibility, civil rights, instructional quality, and records duties.
  10. Record an owner, approval status, conditions, evidence, expiry date, and material-change triggers.

Before rollout

  1. Configure district-managed accounts and disable unapproved features.
  2. Limit data access by role, relationship, purpose, and operation.
  3. Configure DLP and other safeguards on validated surfaces.
  4. Test text, files, images, voice, connectors, saved history, support, exports, and deletion separately.
  5. Give staff and students concrete examples of allowed context and excessive disclosure.
  6. Publish accurate notices and support paths for families and users.
  7. Test account disablement, connector removal, credential revocation, evidence access, and incident contacts.

During operation

  1. Review logs and evidence proportionate to risk without building an unlimited transcript archive.
  2. Revalidate after changes to purpose, users, data, model, provider, terms, features, subprocessors, or connected services.
  3. Exercise access, correction, export, deletion, and incident procedures.
  4. Retire the use and destroy data when the approved purpose ends, subject to applicable records and legal obligations.

The AI tool vetting and approval template turns these questions into a repeatable district record.

Frequently asked questions

Does FERPA prohibit schools from using AI?

No. FERPA does not approve or prohibit AI as a product category. It governs access to and disclosure of PII from education records by covered educational agencies and institutions. A district must evaluate the specific AI use, data, provider relationship, account, features, and legal basis.

Does a signed DPA establish that every AI use satisfies FERPA?

No. A DPA can document purpose, direct control, use limits, security, subprocessors, retention, deletion, and incident duties. The district must still establish consent or a valid FERPA exception and satisfy that exception for the actual data flow.

Can an AI provider qualify as a school official under FERPA?

Potentially. Under 34 CFR 99.31(a)(1), an outsourced contractor may qualify only when it performs an institutional service or function the district would otherwise use employees for, is under the district’s direct control regarding the use and maintenance of education records, is subject to FERPA’s use and redisclosure limits, and meets the district’s annual-notice criteria.

Does FERPA require a written contract under the school-official exception?

FERPA does not generally require a written agreement solely to use the school-official exception. The U.S. Department of Education recommends written terms because they can help establish direct control, and state law, local policy, procurement rules, or another FERPA exception may independently require an agreement.

Does a no-training commitment make student data safe to send to AI?

No. No training addresses one possible use of covered data. The service still processes the request, and separate terms may govern retention, logs, human review, support, abuse monitoring, connected services, and subprocessors. It also does not determine whether the disclosure was authorized or limited to what the educational purpose required.

Does district SSO prove that a staff member may disclose a student’s record?

No. SSO helps establish account identity. FERPA’s school-official exception separately requires a legitimate educational interest, and the district must use reasonable methods to limit access to the education records for which that interest exists.

Is DLP required by FERPA?

FERPA does not prescribe DLP or another specific security product. DLP is an operational safeguard that can reduce accidental or excessive disclosure on supported paths. It does not create legal authority, replace a DPA, or establish that transformed content is legally de-identified.

Does FERPA require direct notice after every student-data breach?

FERPA itself does not contain a general direct breach-notification requirement. FERPA recordkeeping rules, state breach laws, contracts, other federal requirements, and district policy may still create duties. Districts should use qualified counsel and an established incident process for the facts and jurisdiction involved.

Primary sources

This guide is educational information, not legal advice. It does not determine whether any product, contract, data flow, district, or use complies with FERPA or another requirement. Districts should use qualified legal, privacy, security, procurement, records, accessibility, and instructional reviewers for their circumstances.

Choose your Tenet path

Start with one district baseline. Add context when you need it.

Tenet Basic is free. Tenet District adds roster, classroom, teacher, grade, and schedule context.