How We Limit Data, Bound AI, and Reduce Unnecessary Student Exposure
As AI becomes more common in education, privacy deserves more than a reassuring slogan. Teachers and schools need to know, in practical terms, how a platform handles student information: what it stores, what it sends, and what it deliberately chooses not to include.
Our approach is guided by a simple principle: use only the information needed to support teaching and learning, and avoid unnecessary exposure wherever possible. That principle shapes both the way accounts are managed and the way AI features are built.
At the account level, we keep subscriber records focused on essential information. A functioning classroom platform does need core account data, enrollment relationships, and activity records tied to real users. But that does not mean the student record should become a warehouse of unnecessary personal detail. We aim to keep the data footprint as limited and purposeful as possible.
Student access is also designed with flexibility and restraint in mind. In many parts of the platform, students can sign in using a standard email-and-password account. Where appropriate, teachers can also enable a class-number-plus-PIN login option. This gives teachers another controlled way to bring students into classroom activities without making email-based login the only path. PIN access is not open-ended. It is teacher-enabled, tied to classroom enrollment, and limited to active student accounts. In some workflows, it is also paired with session-token checks and lightweight challenge steps before access is granted.
Traditional account security remains part of that design. Password-based logins are supported, and passwords are stored as hashed values rather than plain text. The goal is to support real classroom conditions while keeping access bounded and appropriately controlled.
The same privacy philosophy extends into AI use. In many classroom AI workflows, the model needs the student’s work, but not the student’s identity. A writing sample may need feedback. A conversation transcript may need to be scored. A set of short responses may need to be summarized. In those cases, the instructional content matters; the personal name usually does not.
For that reason, our AI integrations are designed to scrub identifying information. When student work is sent for AI-assisted analysis, the focus is on the work itself rather than on personal identity. In discussion and transcript-based tools, prompts can preserve structure without exposing names by using neutral labels such as “Student,” “Peer 1,” “Peer 2,” “Poster 1,” or “Poster 2.” That allows the model to follow turn-taking, compare responses, and interpret interaction without requiring unnecessary identifying detail.
This is an important distinction. Privacy in educational AI is not only about preventing unauthorized access. It is also about reducing unnecessary disclosure inside authorized systems. A feature may be legitimate and still contain more identifying information than it needs. Our design goal is to keep asking that question: what does the model actually need in order to do the instructional job well?
That mindset carries across the platform. We try to limit stored data to what is functionally necessary, offer bounded and teacher-controlled access options, and structure AI prompts so they carry instructional signal rather than avoidable personal detail. In our view, privacy is not a single feature. It is a design habit.
No platform should treat privacy as finished work. Systems evolve, features grow, and safeguards need to be revisited. But the standard remains clear: keep data collection purposeful, keep access controlled, and keep AI use as privacy-conscious as possible.
That is what privacy by design means in practice.