Generative AI and Student Inputs
Generative AI and Student Inputs: what it means for a student input to an AI tool, who may use it, and the check to make before it moves.
- Record
- student input to an AI tool in ai tools and student privacy
- Data
- Generative AI and Student Inputs
- Safeguard
- a pre-adoption review and a contract term on training use
- First check
- Check that the recipient is bound to use the data only as agreed.
The short answer
In short, generative ai and student inputs comes down to one question: which student input to an AI tool is involved, who retains it, and what purpose justifies the next step with it. Get those three answers right and most of the rest of the decision follows; miss any one of them and the requirement applied shall be the wrong requirement for the facts in front of you.
The safest test for any proposed disclosing is to write it down in one sentence naming the record, the receiver, the objective and the authorization, and then to read that sentence back critically.
International students face additional exposure when files travel across borders, and that exposure ought to shape retention and disclosing determinations.
Cloud hosting does not move responsibility: the university remains answerable for a record even when another company stores it.
Copies of records given to students ought to be full enough to be useful, and redactions of third-party information ought to be explained.
What this covers
Students who are additionally employees have records in both capacities, and the capacity in which a record was created matters to its treatment.
Email may be an education file when it is maintained regarding a student, and the fact that it lives in a mailbox does not remove it from the category.
Undocumented students face serious consequences from file disclosure, and employees should be especially careful about disclosing that could reveal status.
Counselling files raise the same boundary question, and employees ought to verify the exemption before treating such a file as an ordinary file.
AI feedback tools may retain student work for training unless the contract says otherwise, and that term ought to be settled before adoption.
Financial aid systems hold income and family information, and access to them ought to be among the most tightly controlled on site.
How to work through it
Patch systems on a stated timetable, and prioritise patches for systems holding identifiable student data.
Require documented agreements for studies conducted on behalf of the university, with limits on use, de-identification where possible, and destruction on schedule.
Design age screening to collect as little as possible, since screening that collects more than it needs becomes the problem it was meant to solve.
Scrutinise monitoring in education tools for younger students, because behavioural data accumulates quietly over a school year.
Refuse parental access for independent students politely and in writing, with the reason stated, since an unexplained refusal invites repeated requests.
Limit the sharing to the minimum the objective requires, and treat extra data as extra risk rather than extra helpfulness.
Locate every copy before deciding, including the vendor copy, the backup copy and the copy in the disclosed drive.
Audit vendor adherence, and do not accept a vendor's self-assessment as a substitute for evidence where the information is sensitive.
A worked illustration
In the badly done illustration, sensitive comments were included in the export, no removal date was agreed, and the student notice still described the old system.
The cost of fixing the badly done adoption, in renegotiation, migration and lost trust, is far higher than the cost of the review that was skipped.
Consider a student who requests for a record that has already been lawfully disclosed to another department, and who is told where it went and why.
In that illustration the review finds recordings retained far beyond the exam period, and the institution deletes the backlog and shortens storage prospectively.
Consider a student who requests to see an advising note that contains a factual error, and who receives the note, the correction procedure and a written determination.
Where guides go wrong
Accepting a vendor's self-assessment as evidence, where the information is personal, is an error, since self-assessment answers the questions the vendor chose to ask.
Disclosing to a parent on the basis of family relationship alone, without establishing dependency, is a mistake that recurs every enrollment season.
Screening younger users by collecting more data than the screening needs is a mistake, since the protection then becomes the problem.
Letting group mailboxes and shared drives accumulate members without an owner is an error that turns access control into archaeology.
Disclosing on the strength of a letter alone, without a court order or subpoena procedure, is an error that can be avoided by a single phone call to the privacy officer.
Sources and evidence on the record
- Family Educational Rights and Privacy Act regulations, 34 CFR Part 99, text on eCFR.
- US Department of Education, Student Privacy Policy Office, studentprivacy.ed.gov - FERPA guidance, FAQs and model notices.
- US Department of Education, ed.gov - guidance, Dear Colleague letters and enforcement information.
Evidence basis: 34 CFR Part 99, Department of Education guidance, FTC AI guidance Applies when: When a college holds, uses or discloses a student input to an AI tool in the context of ai tools and student privacy