Safely Using AI in Special Education: A FERPA & IDEA Guide

Artificial Intelligence (AI) can be a powerful tool for special educators and administrators — helping with progress monitoring, IEP drafting, evaluation reports, and daily workload. But because AI tools interact with sensitive student data, they live in the world of FERPA and IDEA. Missteps can expose schools to compliance risks and breaches of trust.

This guide is built for special education teachers, related service providers, and district administrators who want to use AI responsibly. It explains the laws that govern student data, the questions to ask any AI vendor, what a Data Privacy Agreement (DPA) actually does, and the practical steps to take before you put student information into any AI tool.

Who this is for:

• Special education teachers and case managers
• Related service providers (SLPs, OTs, PTs, school psychologists)
• Special education directors and coordinators
• District technology directors and IT staff
• School administrators evaluating new tools

Most consumer AI tools were not designed with student privacy in mind.

• AI tools collect everything you type. When you paste an IEP draft, evaluation summary, or a student's name into a chatbot, that information is transmitted to and stored by the AI provider.
• Without a signed DPA, they are not FERPA compliant. A free or personal-tier AI tool, even from a major company, does not become a "school official" under FERPA just because a teacher uses it.
• Free tools often train on your data. Many free or trial AI products explicitly use user inputs to train and improve their models. Once that information is in a model's training set, it is impossible to fully remove.
• Even paid tiers may not be enough. Paying for a Pro or Business plan does not automatically grant FERPA-aligned protections. The vendor still has to sign a binding agreement with the school or district.
• Inputs may be subpoenaed. Conversations with AI tools can be requested as part of a legal proceeding, including special education due process hearings.

The bottom line: a free or unverified AI tool is the legal equivalent of writing an IEP draft in a public coffee shop and leaving the laptop on the counter — it might work out fine, but you cannot say with confidence that student information stayed private.

Two federal laws form the backbone of student-data privacy in the United States, and they apply just as much to AI tools as they do to paper records.

FERPA (1974) — Family Educational Rights and Privacy Act

FERPA protects Personally Identifiable Information (PII) in education records from unauthorized disclosure.

• Schools control disclosure. Education records can only be shared with consent, or under a limited set of exceptions (school officials, directory information, studies, audits, health and safety emergencies, law enforcement, transfers).
• Vendors must qualify as "school officials." AI tools, edtech platforms, and other vendors are not automatically allowed to receive student PII. They become eligible only when they meet FERPA's "school official" criteria — typically established through a written Data Privacy Agreement (DPA) with the school or district.
• Parents have rights. Parents — or eligible students 18 and older — can inspect, review, and request corrections to records.

IDEA — Individuals with Disabilities Education Act

IDEA adds an extra layer of protection for special education records.

• Confidentiality is mandatory. All personally identifiable information in a student's special education record must be kept confidential by educators, administrators, and any vendor that touches it.
• Parent access before key meetings. Parents must have access to records before eligibility meetings, IEP meetings, resolution sessions, and due process hearings.
• Records travel with protections. Records can transfer with a student, but the protections travel with the record.

Key takeaway: FERPA + IDEA mean any AI vendor that handles student PII for a school must (1) be governed by a binding agreement, (2) keep that data confidential, and (3) support the parent and student rights baked into both laws.

PII is broader than people often realize, especially in a special education context where indirect details can identify a specific child.

Direct identifiers are obviously tied to a student:

• Full name
• Student ID number
• Date of birth
• Photograph or voice recording
• Parent or guardian name and contact info
• School and grade combination
• Email address

Indirect identifiers are details that, alone or in combination, can pinpoint a specific student even without a name:

• "The 4th-grader at Lincoln Elementary in Mr. Smith's class with autism"
• "The student in our cluster program with Down syndrome who uses an AAC device"
• A specific combination of disability category, services, and grade level in a small school

Why this matters for AI prompts. When you ask an AI tool to "rewrite this present level for a student with autism in 4th grade who is below grade level in reading," you may not have typed a name — but a colleague at your school could absolutely identify the child.

Practical rule of thumb: if a coworker reading your prompt could narrow it down to one specific student in your building, you have written PII into the prompt. The same caution that applies to talking about a student in a public place applies to typing in an AI tool that does not have a DPA.

When evaluating any AI tool that might touch student information, four essentials matter most.

1. Data handling — How is student data stored and protected? Look for clear answers about where data lives (U.S. data centers preferred for FERPA-aligned districts), how long it is retained, and who can access it inside the company.

2. Encryption — Is data encrypted in transit and at rest? The minimum bar today is TLS 1.2 or higher for transmission and AES-256 for storage. Vendors should be able to confirm both.

3. Model training — Is your data used to train AI models? 🚩 Red flag if yes. Reputable enterprise AI tools commit in writing that customer inputs and outputs are not used to train their models. If a vendor cannot make that commitment, treat them like a generic consumer tool.

4. Data Privacy Agreement (DPA) — Will the vendor sign one? This is the bedrock of FERPA-aligned vendor relationships. A vendor that refuses to sign a DPA is telling you they do not consider themselves accountable as a "school official." Walk away.

Other questions worth asking:

• Does the vendor maintain SOC 2 Type II or ISO 27001 attestation?
• What is their breach-notification timeline? (72 hours is standard; 24 hours for NYC DOE.)
• Are sub-processors disclosed, and can the district object before new ones are added?
• Will the vendor sign state-specific student-privacy addenda (NDPA, NY Ed Law 2-d, California SOPIPA, Illinois SOPPA, etc.)?

A DPA is the written contract that turns an AI vendor into a FERPA-eligible "school official." It is more than a privacy policy — it is a legally binding instrument signed by both the vendor and the school or district.

What a DPA does:

• Recognizes the vendor as a school official under FERPA. Without this status, the vendor cannot legally receive student PII.
• Confirms ownership. Student data is and remains the property of the school or district. The vendor is a custodian, not an owner.
• Locks in security commitments. Encryption requirements, U.S. data storage, employee training, access controls, and breach-notification timelines (typically within 72 hours).
• Requires transparency. The agreement spells out exactly what categories of student data the vendor receives — demographics, IEP content, assessment results, and so on.
• Customizes for state law. Many states (New York, California, Illinois, Colorado, Connecticut, Texas, and others) layer additional requirements on top of FERPA. Your DPA should reflect these.
• Supersedes the vendor's standard privacy policy. Where the DPA and the vendor's general policy conflict, the DPA wins.

The "piggyback" approach. Most districts do not negotiate a fresh DPA from scratch with every vendor. Instead, they use the Student Data Privacy Consortium (SDPC) — a national network where states publish standardized National Data Privacy Agreement (NDPA) templates. Once a vendor has signed an NDPA in your state, your district can often "piggyback" onto that signed agreement, dramatically reducing legal review time.

Two paths to a signed DPA with Playground IEP:

• Sign Playground IEP's standard DPA (NDPA-aligned), executed electronically by your district's authorized signatory.
• Submit your district's own DPA template to privacy@playgroundiep.com — we are happy to review and execute district-provided templates where the terms align.

Here is how the principles above play out in real situations special educators encounter.

"I want to use ChatGPT to help me draft an IEP goal."

The risk. A free or personal ChatGPT account does not have a DPA with your district, and OpenAI's consumer terms allow data inputs to be reviewed by humans and, depending on settings, used to train models. Pasting a student's PII into a personal chat session is a FERPA risk.

Safer approaches:

• Use a tool that has a signed DPA with your district (such as Playground IEP) for any prompt that includes student information.
• If you must use a generic AI tool to brainstorm goal language, scrub the prompt: no names, no IDs, no specific combinations of disability + grade + school that would identify a student.
• Toggle off any "improve model" or "training" settings the tool offers.

"Our team is considering a new edtech tool that uses AI."

Questions to ask before piloting:

1. Will you sign our district's NDPA, or do you have an SDPC-listed agreement we can piggyback on?
2. Are customer prompts and outputs used to train the AI models?
3. Where is data stored (U.S.-based facilities)?
4. What is your breach-notification timeline?
5. What sub-processors do you use, and will we be notified before new ones are added?

If the vendor cannot answer these in writing, slow down.

"A vendor's DPA template doesn't match our state's required language."

What to do. Send the vendor your state's standardized DPA (often available through your state's SDPC alliance or Department of Education). Reputable EdTech vendors are familiar with state-specific addenda and will execute them. If a vendor refuses to sign your state's required language, that is a sign they may not be the right fit.

"I want to share data with a university researcher."

What to know. Research access is one of FERPA's narrow exceptions, but it requires its own written agreement that limits use to the specific study, requires data destruction at the end of the project, and prohibits re-disclosure. Do not include AI tools in the research data flow without a separate vendor DPA.

Day-to-day rules of thumb for keeping student information safe while still benefiting from AI.

Before you use any AI tool with student data:

1. Confirm there is a signed DPA. Ask your tech team or special education director which AI tools have a current DPA on file with your district.
2. Default to "no PII" until you know. If you cannot confirm DPA coverage, do not paste student names, IDs, IEP content, or any indirect identifiers.
3. Use the school's approved tools. District-procured tools have already been vetted; consumer-grade tools have not.

While using an approved AI tool:

4. Toggle OFF model-training settings. If your tool offers an option like "use my conversations to improve the model," disable it.
5. Review every output. AI drafts are starting points, not final products. Apply your professional judgment, edit liberally, and verify accuracy before saving anything to a student record.
6. Stay within the tool's intended use. A tool approved for IEP narrative drafting is not necessarily approved for, say, voice transcription of parent meetings — even if the same vendor offers both features.

At the district level:

7. Maintain a current list of approved tools. Special education leaders should know what is in use across the district, not just IT.
8. Check state-specific privacy laws. Many states layer additional requirements on top of FERPA.
9. Use the SDPC piggyback approach. Don't reinvent the wheel — leverage existing signed NDPAs whenever possible.
10. Train staff annually. AI tools change quickly, and so do the legal nuances. Annual refreshers keep everyone aligned.

• Free AI tools are not automatically FERPA compliant. Personal or consumer-tier AI products, even from major companies, do not become FERPA-eligible just because a teacher uses them at school.
• DPAs are the legal safeguard. A signed Data Privacy Agreement is what makes a vendor a "school official" under FERPA. Vendors that won't sign one are not appropriate for student data.
• PII includes indirect identifiers. A prompt with no name can still describe a specific child if it includes enough surrounding detail.
• Admins and SPED leaders must know what tools are in use. This is not solely an IT or compliance problem — it is a special-education leadership responsibility.
• Be proactive, not reactive. Vet, question, and verify before the first IEP draft goes through any tool. Compliance after a breach is far harder than compliance before one.

External resources:

• Student Data Privacy Consortium (SDPC) — national network for state-by-state NDPA templates and signed-vendor lookups
• FERPA Overview — U.S. Department of Education
• State student-data-privacy laws — search "[your state] student data privacy law" for state-specific requirements (especially NY Ed Law 2-d, California SOPIPA, Illinois SOPPA, Colorado HB 16-1423, Connecticut §10-234aa, Texas SB 820)

Playground IEP resources:

• Privacy Policy — how Playground IEP collects, uses, protects, and shares information
• Terms of Service — the agreement governing your use of Playground IEP
• Security & Privacy FAQ — detailed answers to district technology directors' questions
• Data Privacy Agreement — request a copy at privacy@playgroundiep.com, or submit your district's own DPA template for our review

Questions? We are happy to help. Email privacy@playgroundiep.com and a member of our team will respond within one business day.