FERPA Compliant AI Tools: 2026 K–12 Vetting Checklist

Artificial intelligence is changing classrooms fast. Teachers use it to build worksheets, generate quizzes, draft lesson plans, and personalize learning. But every one of those use cases raises a question that districts can't afford to get wrong: is student privacy protected?

For U.S. schools, the answer starts with the Family Educational Rights and Privacy Act, commonly known as FERPA. And the tools that get this right are what we call ferpa compliant ai tools, platforms designed with specific safeguards to legally protect student data through signed agreements, data minimization, and clear policies against using student information for AI model training.

This guide covers everything educators and administrators need to confidently select and implement these tools. Whether you're a teacher exploring options or a district IT lead building a vetting process, this is the checklist that matters.

Looking for AI tools built for K-12 privacy from the start? Explore TeachTools' features to see how compliance and classroom utility work together.

FERPA Is Not a Certification

One of the most common misconceptions in edtech conversations is that a vendor can be "FERPA certified." This needs to be stated clearly: FERPA is not a certification program. There is no government body that reviews software and stamps it with a FERPA seal of approval. No vendor can truthfully claim to hold a FERPA certificate.

FERPA is a federal law that places obligations on schools and districts that receive federal funding. It governs how those institutions handle student education records. When a vendor says it is "FERPA compliant," what it really means is that the tool has been designed to help schools meet their own FERPA obligations, typically through contractual agreements, privacy policies, and technical safeguards.

Practitioners on Reddit frequently call this out. In privacy focused education threads, IT administrators warn colleagues to be skeptical of any vendor marketing materials that use the phrase "FERPA certified." The U.S. Department of Education does not certify or endorse any product. The responsibility for compliance falls entirely on the school district.

This distinction matters because it shifts the burden. Districts cannot outsource compliance. They must evaluate each tool, negotiate agreements, and verify that the vendor's practices actually align with the law. A vendor can make compliance easier (and many good ones do), but the legal accountability stays with the school.

Understanding the Legal and Data Framework

Before any AI tool reaches a classroom, it needs a thorough review against fundamental privacy laws and data agreements. This is the foundation of responsible AI adoption.

What FERPA Actually Requires

A FERPA compliance review is a detailed inspection to confirm an AI tool follows the rules protecting student education records. School districts examine how the AI handles student data, looking for any risk of improperly disclosing personally identifiable information (PII). This involves checking the tool's privacy policy, security measures, and data use terms against FERPA's requirements.

The key questions are straightforward: Does the tool collect sensitive student details without consent? Does it use data for anything beyond authorized educational purposes? Can it function without student PII at all?

FERPA vs. COPPA: Understanding the Scope

Districts often conflate FERPA and COPPA, but these two laws serve different purposes and apply in different ways. Getting this distinction right is essential when vetting ferpa compliant ai tools.

FERPA applies to any educational agency or institution that receives federal funding. It protects the privacy of student education records and gives parents (or eligible students over 18) rights to access and control those records. FERPA's scope covers students of all ages in funded institutions.

COPPA (the Children's Online Privacy Protection Act) is enforced by the FTC and applies to commercial websites and online services that collect personal information from children under 13. COPPA requires verifiable parental consent before collecting data from young children, and it applies regardless of whether the service is used in a school setting.

Here's where it gets tricky: a tool used in a K-5 classroom may need to satisfy both laws simultaneously. FERPA governs the school's handling of education records, while COPPA governs the vendor's collection practices for users under 13. A tool that passes a FERPA review might still violate COPPA if it collects data from young students without proper consent mechanisms.

For a deeper breakdown, the COPPA compliance guide for AI tools in classrooms covers the practical overlap and where each law applies.

	FERPA	COPPA
Enforced by	U.S. Department of Education	Federal Trade Commission (FTC)
Applies to	Schools and districts receiving federal funds	Commercial websites/services collecting data from children under 13
Age scope	All students in covered institutions	Children under 13
Core requirement	Protect education records; limit disclosure of PII	Obtain verifiable parental consent before collecting children's data
Consent mechanism	"School official" exception can bypass parent consent	Requires direct parental consent (schools can consent on behalf in some cases)

When evaluating tools, districts should ask vendors to address both laws explicitly, especially for elementary school use cases.

School Official Agreements and Data Processing Agreements

Under FERPA, schools can share student data with third party vendors without parental consent if that vendor is designated as a "school official." This special status means the company performs a service the school would otherwise handle itself, operates under the school's direct control, and uses data only for its authorized purpose.

This relationship is formalized in a Data Processing Agreement (DPA). A DPA is a legal contract where the vendor commits to:

• Protecting student data according to specific security standards
• Using the data only for the agreed upon educational service
• Not re-disclosing the information to unauthorized parties
• Securely deleting the data when the contract ends

Many districts now require a signed DPA before any AI tool is approved. Vendors serious about working with schools come prepared with a standard DPA, making approval much smoother. You can review what to look for in a vendor DPA for a practical walkthrough.

The SDPC National Data Privacy Agreement

Beyond individual district DPAs, many states and districts now participate in the Student Data Privacy Consortium (SDPC) National Data Privacy Agreement framework. The SDPC, managed by the Access 4 Learning Community (A4L), provides a standardized DPA template that has been adopted across most U.S. states.

The advantage is efficiency. Instead of every district negotiating its own unique agreement with the same vendor, the SDPC framework creates a single agreement that multiple districts in a state can sign onto. Once a vendor signs the National DPA with one state's lead agency, other districts in that state can join through a simple exhibit process.

When evaluating AI tools, asking whether a vendor has signed the SDPC National DPA is a strong signal. It indicates the vendor has gone through a rigorous, standardized review process rather than just drafting their own self-serving privacy policy. Districts can check the SDPC vendor list to see which companies have active agreements.

Key Features of FERPA Compliant AI Tools

Beyond legal paperwork, truly ferpa compliant ai tools are built with privacy features from the ground up. These are the technical and policy safeguards that separate compliant tools from risky ones.

Student PII Minimization and the "Zero Data" Goal

The safest way to protect student data is to not collect it. Student PII minimization means limiting collection of personally identifiable information to the absolute minimum needed. A good AI tool shouldn't need a student's full name, address, or ID number to generate a worksheet or a lesson plan.

The gold standard is a "zero data" approach where no student PII is ever stored on the vendor's servers. Some platforms achieve this by automatically redacting names and identifiers before information is processed by the AI model. The AI works only with educational content, not private details about a child.

Does the Use Case Actually Need Student PII?

This is a question that doesn't get asked often enough, and it should come before any technical review. Before approving an AI tool, districts need to determine whether the specific use case requires student PII at all.

Many of the most common AI applications in education, generating worksheets, building quiz questions, drafting lesson plans, creating rubrics, need zero student data. A teacher typing "Create a 5th grade worksheet on fractions with mixed numbers" is sending only instructional content to the AI. No student is identified. No record is created.

On the other hand, a tool that provides personalized learning recommendations based on a student's performance history, or one that generates individualized IEP progress notes, inherently requires some form of student data to function.

The practical framework looks like this:

• No PII needed: Content generation (worksheets, quizzes, lesson plans, rubrics), general classroom communications, vocabulary games
• May need PII: Adaptive learning platforms, student performance dashboards, automated feedback on individual student work
• Definitely needs PII: Student information systems, IEP management tools, grade books synced to student records

If the use case falls in the first category, the compliance burden drops significantly. The tool still needs a solid privacy policy, but the risk profile is fundamentally different. This assessment should be step one in any vetting workflow.

Vendor Use of Student PII for Product Improvement

Here's a point that trips up many districts. Even vendors that promise not to use student data for AI model training may still use aggregated or de-identified student data for "product improvement." These are different things, and the distinction matters.

Model training means feeding student inputs directly into the AI to make it smarter. If a vendor trains its model on student essays, that private information could surface in a response to another user, creating a serious privacy breach.

Product improvement is broader. It can include analyzing usage patterns, tracking which features get used most, measuring error rates, or studying how students interact with the platform. Some of this is benign (and genuinely helpful for making better tools). Some of it crosses lines.

The concern is that "product improvement" can become a catch-all that lets vendors do nearly anything with data. Practitioners in education privacy forums report finding vague language in vendor policies that allows data use for "improving our services" without defining what that means.

When reviewing a vendor's policies, districts should ask:

• Does the vendor distinguish between model training and product analytics?
• Is any student level data (even de-identified) used for product development?
• Can the district opt out of non-essential data collection?
• Are these terms clearly spelled out in the DPA, not just the marketing page?

OpenAI's API policy, for example, states that data sent through the API is not used for training by default. But districts should verify this for every vendor in the supply chain, not assume it.

Preventing AI Output from Disclosing Student PII

Safeguards must work both ways. Not only should AI tools avoid collecting PII, but they must also prevent it from appearing in generated output. Even if an AI has access to student information for a legitimate reason (like generating personalized feedback), it should never expose those private facts to unauthorized users.

This is achieved through several methods:

• A strict no training policy: If the model never learns the PII, it can't repeat it
• Output filtering: The AI scans its own response before sending it to check for and remove sensitive data patterns
• Data minimization: The AI never receives PII to begin with, making it impossible to leak

These technical guardrails ensure the AI remains a helpful tool, not a source of accidental data exposure. For more on protecting privacy during daily classroom use, see this guide on how to use AI in the classroom without violating FERPA.

Teacher Only vs. Student Facing: Risk Assessment Matters

Not all AI deployments carry the same risk, and districts should stop treating them as if they do. A teacher using an AI tool to generate a quiz on their laptop is a fundamentally different situation from a student logging into an AI powered tutoring platform with their school credentials.

Why the Distinction Changes Everything

Teacher only tools are used behind the scenes. The teacher interacts with the AI, and the output (a worksheet, a rubric, a lesson plan) is delivered to students as a static document. The student never touches the AI platform. No student account is created. No student data flows to the vendor.

Student facing tools require students to interact directly with the AI. This might mean logging in, typing responses, receiving adaptive content, or having their work analyzed in real time. These tools almost always involve some form of student data collection, even if it's just a username and session logs.

The compliance requirements diverge sharply:

	Teacher Only	Student Facing
Student accounts needed	No	Usually yes
PII collection	Minimal to none	Often significant
DPA urgency	Still recommended	Absolutely required
COPPA relevance (under 13)	Rarely	Almost always
Parental notification	Usually not required	Often required
Risk level	Lower	Higher

Districts that treat all AI tools identically end up either over-regulating harmless teacher productivity tools or under-scrutinizing student facing platforms. A tiered risk assessment is better practice.

Many educators on YouTube walkthroughs describe adopting this exact approach: using teacher only tools like content generators freely while routing student facing tools through a more formal district review. This practical split keeps innovation moving without exposing students to unnecessary risk.

TeachTools is designed as a teacher only platform, meaning students never interact with the AI directly, and no student accounts or PII are required.

Building a Secure and Accountable AI Ecosystem

Compliance goes beyond data handling. Selecting ferpa compliant ai tools also involves creating a transparent and controlled environment where every action is logged and every user has appropriate permissions.

Access Control and Role Based Permissions

Access control regulates who can see or use certain data. Role Based Access Control (RBAC) assigns permissions based on a user's role: student, teacher, or administrator. A teacher can access materials for their own class but not another teacher's. An administrator might have broader oversight, but a student has very limited permissions. This enforces the principle of "least privilege," giving everyone just enough access to do their job, which is essential for FERPA.

Record Access Logging and Audit Trails

FERPA requires schools to keep a record of who accesses student PII and for what purpose. An audit trail is a chronological log tracking these interactions. When evaluating ferpa compliant ai tools, districts look for systems that automatically log:

• Who accessed a record
• When they accessed it
• What information they viewed or changed

This trail is crucial for accountability. If there's ever a question about data misuse, the audit log provides a clear record for investigation. For a broader security checklist, see edtech security questions for district procurement.

Data Retention and Deletion Policies

Student data should not be kept forever. A data retention and deletion policy dictates how long a vendor stores information and when it gets securely erased. Good practice is to retain data only as long as it's needed and then purge it. Khan Academy, for example, automatically deletes its AI tutor chats after 365 days. Many state laws now require vendors to destroy student data upon request or after a contract ends. A clear, enforceable deletion policy is non-negotiable.

Third Party Subprocessor Disclosure and Oversight

Most AI tools rely on other services for cloud hosting or the underlying AI engine. These external services are called subprocessors. A trustworthy vendor will be transparent about who they are and provide a complete list.

More importantly, the primary vendor must ensure these subprocessors also follow FERPA's rules. This means having strong contracts in place that hold the subprocessor to the same high standards. The school's data protection agreement should extend to the entire chain of providers.

The Human Element in AI for Education

Technology alone isn't enough. True compliance and ethical AI use require human judgment, transparency, and respect for student and parent rights.

Transparency and Explainability Requirements

Teachers and parents shouldn't have to trust a mysterious "black box." Transparency means an AI provider is open about what data its system uses and what its limitations are. Explainability goes further, requiring that an AI can provide a human understandable reason for its outputs. If an AI flags an essay for plagiarism, it should explain why. This builds trust and allows educators to spot potential errors or biases.

Human Oversight for High Risk Decision Making

For decisions that could seriously impact a student (grading final exams, flagging for disciplinary action, placement decisions), a human must be in the loop. The White House AI Bill of Rights and the EU's AI Act both emphasize this principle. AI can assist and offer recommendations, but a qualified educator should always make the final call. This ensures empathy, professional ethics, and context remain part of the decision.

The Parent and Student Right to Access (Within 45 Days)

A core tenet of FERPA is the right of parents (or students 18 and older) to review and inspect education records. Schools must provide this access within 45 days of a request. If an AI tool stores data considered part of the education record, such as analytics on reading progress, parents have a right to see it. The AI platform must be able to export a specific student's data in a readable format to help the school fulfill this obligation.

How Schools Can Ensure Compliance

With these principles established, districts can build systematic processes to vet and approve technology, ensuring only the safest ferpa compliant ai tools reach teachers and students.

Conducting an AI Use Case Assessment

Before evaluating any specific vendor, districts benefit from stepping back and conducting a broader AI use case assessment. This means cataloging every way AI is being used (or proposed to be used) across the district and classifying each use case by risk level.

A use case assessment asks:

1. What is the educational purpose? Generating content, personalizing instruction, analyzing student performance, automating administrative tasks?
2. Does the use case involve student data? If yes, what type and how sensitive?
3. Is the tool teacher only or student facing? This determines the risk tier.
4. What happens if the tool fails or produces biased output? Low stakes (a bad worksheet) vs. high stakes (an incorrect grade or biased recommendation)?
5. Is there an existing approved tool that already handles this need?

This assessment prevents duplicate tool adoption, identifies the highest risk use cases that need the most scrutiny, and helps districts prioritize their vetting resources. A district with 50 pending tool requests can use this framework to fast track low risk, teacher only content generators while giving more time to student facing adaptive platforms.

Incorporating Generative AI into Your App Vetting Checklist

Traditional app vetting checklists were designed for conventional software: databases, LMS platforms, communication tools. Generative AI introduces new risks that those older checklists don't cover. Districts need to update their review process specifically for AI tools.

Beyond the standard FERPA and COPPA questions, a generative AI vetting checklist should add:

• What AI model powers the tool? Is it a proprietary model or a third party API (like OpenAI, Anthropic, or Google)?
• Does the AI model provider retain prompts or outputs? For how long?
• Can the tool generate inaccurate or biased content (hallucinations)? What safeguards exist?
• Does the tool have content filtering for age appropriate output?
• If the tool is student facing, can students input free text? Free text input to an AI creates the highest risk of PII leakage.
• Does the vendor's DPA explicitly cover AI specific data flows, including prompt processing, model inference, and output caching?

The AI in education compliance checklist provides a broader framework for integrating these questions into existing district workflows.

One IT director shared in an education technology forum that their district added a mandatory "AI addendum" to their standard vetting form after realizing their existing checklist had no questions about model training, prompt retention, or output filtering. Within six months, this addendum caught three tools that would have passed the old checklist but had problematic AI data practices.

The District Vendor Approval Process

A formal district vendor approval process puts all of this into practice. It's the official procedure for reviewing, approving, or rejecting new software. Typically, a teacher submits a request, and a district committee reviews the tool against its checklist. This involves scrutinizing the privacy policy, negotiating a DPA, and ensuring the tool meets security and instructional standards.

This process prevents unvetted "shadow IT" and ensures every tool has been cleared for safety. For practical guidance on what teachers should know before requesting a tool, see can teachers use AI without school approval.

Companies that understand K-12 needs design their products and policies to make this approval process seamless. TeachTools, for example, provides a ready-to-sign DPA, publishes its subprocessor list, and built the platform so no student PII is ever required.

Conclusion: Making Smart, Safe Choices

Navigating AI in education doesn't have to be overwhelming. The core principles are clear: understand that FERPA is your district's responsibility (not a vendor certification), minimize data collection, formalize agreements, assess each use case on its own terms, and keep humans in the loop for high stakes decisions.

Finding ferpa compliant ai tools is not about limiting possibilities. It's about building trust. The best tools prove that powerful AI assistance for creating worksheets, lesson plans, and assessments can coexist with the highest standards of data protection. Teacher only tools with zero PII requirements represent the lowest risk path to adoption.

Protecting students is what makes AI a sustainable force for good in education. To explore compliant content creation, start with TeachTools' free plan, which includes five generations per month with no student data required.

Frequently Asked Questions

What is the single biggest red flag for a non compliant AI tool?

The biggest red flag is a vague or missing privacy policy, especially one that doesn't mention FERPA or student data. Another major warning sign is if a vendor refuses to sign a district's Data Processing Agreement or states that it uses student data to train its models. If the vendor claims to be "FERPA certified," that's also a red flag, because FERPA certification does not exist.

Can schools use popular chatbots like ChatGPT and remain FERPA compliant?

Using the free, public version of a consumer chatbot with student PII would almost certainly violate FERPA. These tools were not designed for educational compliance and often use inputs for model training. However, enterprise versions or tools that use the underlying API (as many ferpa compliant ai tools do) can be compliant when governed by a strong DPA that prohibits data retention and model training.

What does PII (Personally Identifiable Information) include under FERPA?

Under FERPA, PII includes a student's name, address, parent's names, date of birth, social security number, and student ID number. It also includes other information that, alone or in combination, could identify a specific student, such as a school name combined with a grade level and demographic details.

Who is responsible if a FERPA violation occurs with an AI tool?

The school or district is ultimately responsible for protecting student data and complying with FERPA. Even if a third party vendor causes a breach, the school is held accountable. This is why having a strong DPA matters: it provides a legal framework to hold the vendor responsible to the district, even though the district bears the primary obligation.

How can a teacher quickly check if an AI tool might be safe?

Look for a dedicated privacy policy or a page for educators on the tool's website. Check for explicit mentions of FERPA, COPPA, and student data. If the tool asks you to sign in with a personal account and doesn't offer a school specific option, or if the terms of service target general consumers, it likely hasn't been designed for school use. Submit it to your district's formal vetting process before using it with any student information.

Do ferpa compliant ai tools have to be less powerful?

Not at all. Compliance is about how data is handled, not about limiting capabilities. Many of the most effective AI tools for education achieve powerful results by focusing on instructional content (a science topic, a historical event, a math concept) rather than personal student data. Building a quiz or lesson plan rarely requires any PII, so the best tools simply don't ask for it.

Is there a difference between teacher only and student facing AI tools for compliance?

Yes, and it's significant. Teacher only tools, where the educator interacts with the AI and delivers static output to students, carry much lower compliance risk because no student data typically flows to the vendor. Student facing tools, where students log in and interact directly with the AI, almost always require a signed DPA, COPPA review (for students under 13), and more rigorous data handling safeguards.

What is the SDPC National Data Privacy Agreement?

The Student Data Privacy Consortium National DPA is a standardized data privacy agreement managed by the A4L Community. It allows multiple districts within a state to join a single agreement with a vendor, reducing redundant negotiation. Districts can check the SDPC database to see if a vendor has already signed, which can significantly speed up the approval process.