At 10:15, a Grade 5 teacher pastes a paragraph from a student’s learning plan into an AI tool and asks for a reading-level adjustment. The tool produces a useful version. No name appears in the prompt, so the decision feels harmless.
It may still be the wrong decision.
COPPA, FERPA, and MFIPPA answer different legal questions. COPPA concerns online services and children under 13. FERPA governs access to and disclosure of education records in US schools. MFIPPA governs the collection, use, and disclosure of personal information by Ontario municipal institutions, including school boards. None of them is a general “AI is allowed” certificate.
The useful question is narrower: what data is moving, for what purpose, under whose authority, with what controls, and for how long? The myths below get schools into trouble because they answer only one of those questions.
Myth 1: “The school said yes, so COPPA is covered.”
Searches for “COPPA education” often produce a false shortcut: a school can click approve for students under 13 and move on.
The Federal Trade Commission does allow schools to consent on behalf of parents in some educational situations. That permission is limited. The service must be collecting information for the benefit of the school and its educational use, not for an unrelated commercial purpose. The school’s approval does not give a vendor a free pass to use children’s information for advertising, unrelated profiling, or whatever product development the vendor prefers.
COPPA applies to operators of online services directed to children under 13, as well as services with actual knowledge that they are collecting personal information from children under 13. Personal information is broader than a student’s name. It can include persistent identifiers, photos, audio, geolocation, online contact information, and other data that identifies or tracks a child.
Before approving an AI tool for primary students, ask the vendor to answer these questions in writing:
- What information does the service collect from the student or teacher prompt?
- Is the service directed to children, or does it know that children under 13 are using it?
- Is the information retained, used to train a general model, or shared with subprocessors?
- Can the school review the information and request deletion?
- Does the service use the information for anything beyond the defined school function?
The surprising part is the age cutoff. Turning 13 does not make the privacy problem disappear. COPPA may no longer be the controlling federal rule, but FERPA, state student privacy laws, contracts, and school policy can still apply. A high school tool can require more review than a primary-school tool even when COPPA is no longer in the picture.
A school that cannot get clear answers should use invented or genuinely de-identified examples while the review continues. That is not a permanent compliance strategy, and it can reduce the usefulness of the tool. It is a sensible holding pattern.
COPPA is also not a complete student privacy framework. A tool may fit the school-consent conditions under COPPA and still fail a school board’s procurement rules or FERPA requirements.
Myth 2: “FERPA means every AI use needs a signed parent consent form.”
FERPA is often treated as a blanket prohibition on sending any student information to a third party. That is not how the law works.
FERPA generally requires consent before personally identifiable information from education records is disclosed, but it contains exceptions. The most relevant one for school technology is the school official exception. A contractor may receive information when it performs an institutional service the school would otherwise use employees to perform, remains under the school’s direct control regarding use and maintenance of the records, and follows the school’s limits on use and redisclosure.
That exception can support some AI uses. It does not automatically classify an AI vendor as a school official because a contract uses those words. A FERPA AI review should examine the actual arrangement: Is the tool performing a defined school function? Does the school control the data? Can the vendor use prompts to improve a product for unrelated customers? Does the contract restrict redisclosure? Can the school satisfy a parent’s right to inspect or seek correction of the record?
The US Department of Education’s FERPA guidance emphasizes those conditions. The vendor’s privacy page is not a substitute for the school’s own determination.
Write the purpose in one sentence before sending any identifiable record:
This service receives [specific data] only to [specific school function], returns [specific output], retains it for [defined period], and may not use it for [training, advertising, profiling, or other excluded purposes].
If staff cannot complete that sentence without using phrases such as “improve the experience” or “related purposes,” the proposed use is not sufficiently defined.
There is a counterintuitive lesson here: a signed parent form can be weaker protection than a narrow contract and active school oversight. Consent may authorize a particular FERPA disclosure, but it does not fix excessive collection, weak security, an unlawful commercial use, or a conflict with state or provincial law. Nor does it transfer the school’s responsibility to the parent.
Prompts and AI-generated responses can also become education records. If a prompt is directly related to a student and the school or its agent maintains it, the fact that the text came from a chatbot does not change its status. Schools should decide what must be retained, where it belongs, and who can access it instead of allowing every chat transcript to become an accidental record.
Some schools will conclude that a particular vendor cannot meet these conditions. That is a valid outcome. “No” is better than calling a broad data-sharing arrangement an exception.
Myth 3: “We removed the student’s name, so the data is anonymous.”
Names are the easiest identifiers to remove, not the only ones that matter.
Under FERPA, de-identification requires more than deleting direct identifiers. The school must reasonably determine that a student’s identity is not personally identifiable, taking into account other information that could reasonably be available. A small class, a rare disability, a distinctive incident, and a date can identify a student when combined.
Consider this prompt:
Write feedback for Jordan, a Grade 6 student with dyslexia who missed the October 12 lab after a concussion.
Removing “Jordan” would not make the prompt anonymous in a class of 25. The combination of grade, disability, event, and date may be enough. Voice recordings, photographs, student IDs, IP addresses, behavioral descriptions, and unique writing samples create similar problems. COPPA also recognizes several of these categories as personal information, even when a student’s name is absent.
A safer workflow separates the general teaching task from the student-specific judgment. For example:
Write three neutral feedback stems for a Grade 6 learner who needs support distinguishing a main idea from supporting details.
The teacher can then apply the feedback locally. This reduces context and may produce less tailored output. That is the cost of privacy protection. If a tool needs the full learning plan, medical detail, or behavior history to be useful, the right response is to use an approved environment or escalate the request—not to rename the student and hope for the best.
De-identification is a process, not a find-and-replace operation. Ask who could identify the student, what other records they can access, whether the tool keeps the prompt, and whether the output reveals a sensitive inference. “Anonymous” should be a documented determination, not a description added after the upload.
Myth 4: “MFIPPA means all student data must stay in Ontario.”
Ontario adds a different shortcut: treating server location as the entire privacy decision.
MFIPPA applies to Ontario school boards as municipal institutions. It requires the institution to have authority for collecting personal information, to collect only what is necessary for a lawful activity, and to provide appropriate notice when information is collected directly. It also governs use, disclosure, access, and safeguards.
MFIPPA itself does not create a simple rule that every byte of personal information must remain in Ontario. That does not make location irrelevant. A vendor may store data, backups, logs, or support tickets in several countries. A foreign provider may be subject to legal demands from another jurisdiction. A board’s own policy or procurement contract may require Canadian hosting even where MFIPPA does not impose that requirement by itself.
The more useful test asks:
- What is the board’s legal authority and educational need for collecting this information?
- What data leaves the board’s systems, including prompts, logs, and backups?
- Who can access it, including subcontractors and support staff?
- How long is it retained, and can the board verify deletion?
- What happens if a student requests access or correction, or if there is a breach?
This produces a less comfortable but more accurate result: a tool hosted in Ontario can still be a poor choice if it collects broad free text, keeps it indefinitely, or permits unrelated model training. A tool hosted elsewhere might expose less information under a tightly controlled contract, but that fact alone does not establish MFIPPA compliance.
For an Ontario board, the privacy officer, records lead, or freedom-of-information coordinator should be involved before staff send identifiable student information to a new AI service. MFIPPA does not apply identically to every education provider, and schools outside Ontario need to substitute the law that governs their institution. Location is one input to the decision, not the decision itself.
The one-week test for an AI tool already in use
Do not begin with a new policy document. Choose one AI tool staff already use and make a one-page data card for it.
Record the exact inputs and outputs first. “Student work” is too vague; specify whether that means names, writing samples, IEP details, voice, images, grades, or teacher-created summaries. Then record the purpose in operational language, such as “draft three reading-feedback options for teacher review.”
Next, identify the legal and institutional route: COPPA school consent, FERPA school official exception, a documented consent process, MFIPPA authority, board approval, or some combination. Do not mark “compliant” because one law appears satisfied.
The vendor section should cover retention, model training, advertising, subprocessors, data location, deletion, breach notification, and access or correction requests. If the answers are buried in a general privacy policy, ask for the education-specific terms or pause the use.
Finally, write the staff control. A practical interim rule might be:
Until the privacy lead approves the tool, staff may use only invented or properly de-identified content. They may not enter names, student numbers, IEP or health information, discipline information, identifiable voice or images, or distinctive student work.
That rule will block some convenient uses. It also gives teachers a clear answer when a colleague asks whether a prompt is acceptable. Privacy approval remains separate from instructional review: a teacher should check AI-generated content for accuracy, bias, and appropriateness before students see it.
Start with the FTC’s COPPA guidance, the US Department of Education’s FERPA guidance on school officials and de-identification, and Ontario’s Information and Privacy Commissioner guidance for school boards. Vendor summaries can explain a service; they cannot decide a school’s legal authority.
Before Friday, complete the data card for one tool your school already uses and send the unanswered questions to the person who owns privacy decisions. Those gaps are the next work item, not a reason to fill in “yes” by default.