Privacy policy

1. Overview

MyTA (“My Teaching Assistant”) is an AI-powered course operations platform that helps instructors manage discussion boards, grading, student communications, and course compliance. Ascent Labs builds and runs MyTA. MyTA operates as a “school official” under FERPA (34 CFR §99.31(a)(1)(i)), processing education records solely on behalf of the institution under a Data Processing Agreement (DPA).

2. Data we collect

From instructors

• Name, email address, and institutional affiliation. Instructors sign in with an email and password, with a Google account, or through a launch from their LMS.
• Course configuration preferences
• Grading rubrics and policy settings
• Draft replies and feedback composed within MyTA
• Conversations with the MyTA chat assistant and the Telegram assistant, and notes the chat assistant saves from those conversations
• Halo sign-in session details, if the instructor installs the MyTA Helper for Halo browser extension. The extension reads them from the browser’s Halo cookies so MyTA can work in Halo on the instructor’s behalf.
• The instructor’s own user ID in their LMS and the email address their LMS session reports, which MyTA reads when it syncs their courses. MyTA uses them to find the instructor on their courses’ rosters. They don’t give anyone access to a course.
• When anyone who signs in accepts the MyTA beta agreement, MyTA keeps a record as proof of acceptance: their user ID, their email address at the time, the agreement version and a fingerprint (SHA-256) of its exact text, the time they accepted, their IP address, and their browser’s user agent. Student-only accounts don’t see the agreement, so they have no acceptance record.

From students (via LMS sync)

• Name, student ID, email address, and enrollment status
• Discussion board posts and replies
• Assignment submissions, including the original files
• Thread messages sent to instructors

Most student data is synced from the institution’s Learning Management System (LMS). Students can also sign in to MyTA through a launch from their LMS, which shares their name and email address, to see their submissions, feedback, and discussion participation. Students who allow notifications get push notifications from MyTA when a grade is posted or a discussion deadline is near.

3. How we use data

• AI-assisted grading: Submission content is analyzed by AI to generate scores and feedback. Before a submission is sent to the AI provider, MyTA replaces student identifiers in its text according to the institution’s settings, with the exceptions listed in section 4.
• Discussion compliance: Posts are evaluated for word count, substantiveness, and timeliness against course policies.
• Inbox triage: Student messages are classified by urgency and draft replies are generated for instructor review.
• Engagement monitoring: Participation patterns are aggregated to identify students who may need outreach.
• Instructor assistants: The MyTA chat assistant, and the Telegram assistant if an instructor connects Telegram, answer the instructor’s questions and carry out tasks using course data.

4. Student PII protection

These features replace personally identifiable information (PII) in student text, such as a submission, a discussion post, or a message, before it is sent to the AI provider:

• Grading essays and other submissions
• Citation checks, draft comparisons, and AI detection on essays
• Grading discussion posts
• Drafting replies to student messages
• Drafting discussion posts and replies

Other parts of these requests, such as course policies and feedback from earlier grading, are sent as written. Grading a rubric criterion about formatting, such as APA or MLA style, can send the original file as written.

The replacement uses the course roster, the course’s details, and pattern matching, not AI. Each institution’s administrators choose which identifiers are replaced, in Settings under Privacy & Data:

• Student names (on by default): names on the course roster become placeholders such as “[Student A]”
• Student IDs (on by default): IDs on the course roster become placeholders such as “[ID-1]”
• Email addresses (on by default): each email address becomes its own placeholder, such as “[email kqzbtrmd]”
• Instructor names (off by default): the course instructor’s full name, and their last name after a title such as “Dr.”, become “[Instructor]”
• Course section numbers (off by default): the section number in the course name becomes “[Section]”, or “[Section A]”, “[Section B]” and so on when the name lists more than one
• Institution references (off by default): the institution’s name becomes “[Institution]”
• Custom patterns (none by default): text that matches a pattern an administrator adds becomes “[redacted]”

Placeholders are swapped back before results are shown to the instructor, except “[redacted]”, which stays in drafts and feedback. In student text, a student’s name is replaced only where it matches the full name on the roster. A first name alone, a nickname, or an identifier written another way can still reach the AI provider, and the request is not stopped when that happens.

Every other feature that uses AI sends its text as written, without this replacement. Among them, these can send student names or student text:

• Discussion reminders and student outreach messages, which include the student’s name
• Building an instructor’s teaching voice profile, which sends recent student messages with the instructor’s replies. The instructor’s “Automatic PII redaction on examples” setting, on by default, applies the replacement to the message text
• Learning an instructor’s grading preferences, which sends the AI’s feedback and the instructor’s changes to it. The same setting applies the replacement to that text
• The chat assistant, whose context includes student names and recent messages
• The Telegram assistant, which can look up student names, email addresses, and message subjects
• Search indexing through Voyage AI, which receives the subject and first message of each inbox thread, and student messages with the replies sent from MyTA drafts

5. Encryption

• In transit: Connections between your browser and MyTA use HTTPS.
• At rest: MyTA encrypts LMS sign-in credentials and session tokens, the text and file names of uploaded essays, student names and email addresses on course rosters, and API keys an institution supplies (such as its own AI provider or Turnitin key) using AES-256-GCM. Other stored data, such as the text of messages and discussion posts and original uploaded files, does not have this application-level encryption. The student names stored with messages, discussion posts, engagement records, and submissions don’t have this encryption either.

6. Data retention

• Course records (rosters, message threads, discussion posts, submissions, and grades): marked deleted about one year after the course ends, then permanently deleted 30 days later
• AI-generated inbox reply drafts: marked deleted 90 days after the course ends, then permanently deleted 30 days later
• AI usage logs: deleted after 90 days
• Chat assistant conversations: deleted 90 days after they were last updated
• Error records: deleted 90 days after they are resolved, or 180 days after they occur if still unresolved
• Browser extension request records: deleted after 90 days, once the request has finished
• Audit log entries: names, email addresses, IP addresses, and browser details are removed after 365 days. The entries themselves are kept.
• Beta agreement acceptance records: kept without a time limit, as proof of acceptance
• Sign-in sessions: last up to 30 days. Each institution sets an idle timeout that ends a session sooner, 8 hours by default.

An automated purge runs once a week, so each step happens at the first weekly run after the dates above. Records for a course with no end date are not deleted automatically, and neither are submissions an instructor removes in MyTA, which are kept so they can be restored.

7. Third-party services

MyTA shares data with the following sub-processors:

• Anthropic (AI models): The default AI provider. Receives the text of AI requests, which can include student names and messages as described in section 4. The chat assistant writes its replies with Anthropic even when an institution chooses another provider.
• Hetzner (hosting): Hosts the server that runs MyTA’s application, database, and cache, and stores original submission files.
• Cloudflare (backup storage): Stores MyTA’s nightly off-site backups of the database and original submission files. Each backup is encrypted on MyTA’s server before it is uploaded, and Cloudflare does not have the key.
• Voyage AI (search indexing): Receives text that MyTA indexes for search, including the subject and first message of each inbox thread and the notes the chat assistant saves from conversations with instructors. This text is sent as written, without identifiers replaced.
• Telegram: If an instructor connects Telegram, MyTA sends that instructor notifications there, which can include a student’s name, a preview of the student’s message, and a draft reply. Conversations with the Telegram assistant also pass through Telegram.
• Sentry (error monitoring): Receives reports of errors on the server and in users’ browsers, which can include a user ID, an institution ID, and the page or route involved.
• Stripe (billing): Receives the billing email address and handles checkout, payments, and subscription changes.
• Google sign-in: If an instructor signs in with Google, Google shares that account’s name and email address with MyTA.
• Google Gemini (AI models): Receives AI requests when an institution chooses Gemini as its AI provider, using the institution’s key or MyTA’s. The Telegram assistant runs on Gemini by default, so its conversations, including the student names, email addresses, and message subjects it looks up, go to Google.
• OpenAI (AI models): Receives AI requests when an institution chooses OpenAI and supplies its own API key.
• Turnitin (similarity checking): Receives the text and file names of submissions when an institution turns on Turnitin with its own account.
• Mem0 (assistant memory): Receives the notes the chat assistant saves about an instructor, when the institution turns it on. It is off by default.

No student data is sold, shared for advertising, or used for purposes outside the institution’s educational mission. A sub-processor register with data handling details is available upon request and included in our Data Processing Agreement (DPA).

8. AI-specific data practices

• No model training by MyTA: Ascent Labs does not build, train, or fine-tune its own AI models, and does not use student data to train AI models. How long an AI provider keeps request data, and whether it uses that data, is set by that provider’s terms.
• Student identifiers in AI requests: Some features replace student names, IDs, and other identifiers in student text, according to the institution’s settings, before it reaches the AI provider. Section 4 lists them, their exceptions, and the features that send student names and text as written.
• Human oversight: All AI-generated content (grades, feedback, draft replies) is presented to the instructor as a draft requiring review and approval. No AI output reaches students without explicit instructor action.
• AI usage tracking: MyTA logs each request it makes to its AI provider (Anthropic, Gemini, or OpenAI) with the action type, model used, and token counts. Requests to Voyage AI and Mem0, and the Telegram assistant’s requests, are not in this log. Usage data is available to institutional administrators.

For more detail, see our AI governance page.

9. Access control

MyTA gives access to course data as follows:

• An instructor can open the courses they teach: the courses they added to MyTA, and the courses their own LMS sync or LTI launch shows them teaching. Access that came from a sync or a launch ends when 3 days pass without another one.
• A teaching assistant can open a course their own LMS sync or LTI launch shows them in, under the same 3-day rule. They can view it and write drafts, but cannot approve, send, or publish anything, or change the course’s settings. If a course’s Halo roster lists you as a teaching assistant, MyTA gives you the teaching assistant role on that course, even if you added the course yourself. Your role follows the LMS role until an instructor or administrator adds you to the course by hand.
• Chairs and administrators can open every course in their departments. Administrators can also export a student’s records from every course in the institution, and process deletion requests as described in section 10.
• An instructor of a course, or a chair or administrator of its department, can also add a staff member of the institution to the course by hand, as an instructor or a teaching assistant. That access lasts until one of them removes it.
• The chat assistant, the Telegram assistant, and the daily digest use these same rules to decide who can see a course.
• Students see only their own records: their submissions and feedback after the grade is published, and their discussion status.

An institution that signs up through MyTA starts with a single department, so there a chair or administrator can open every course in the institution. Row-level security in the database keeps each institution’s data separate from every other institution’s.

Work MyTA prepares in a course, such as a drafted reply waiting for approval, is shared with the course. Everyone on the course’s staff sees it in their own lists, and the course’s pages show it to anyone who can open the course. Anyone who teaches the course, or is a chair or administrator of its department, can approve or reject it. The first decision counts, and the others see who made it. A teaching assistant sees the course’s tasks but cannot decide them, though whoever prepared a task can withdraw it. What a person approves or publishes goes out to the LMS under their own LMS account. The one exception is a chair or administrator who isn’t on the course’s staff: an announcement or an essay grade they approve or publish goes out under the instructor of record’s account.

Notifications about a course go to the people who teach or assist in it. Requests to approve something in the course, such as a drafted reply, go to everyone who teaches it, and updates on its scans go to its instructor of record. Alerts about the course’s students go to everyone who teaches or assists in it, including a flag that a student’s message mentions self-harm or a threat. A confirmation that a reply was sent or a grade was published goes only to the person who sent or published it, or to the instructor of record when MyTA sent it on its own. Each person can turn a course’s notifications off for themselves in the Course Hub, though a self-harm or threat flag still reaches everyone who teaches the course. Chairs and administrators get a course’s notifications only if they teach or assist in it, apart from confirmations of what they did themselves.

10. Student rights

Under FERPA, students (or parents of minors) have the right to:

• Request access to their education records processed by MyTA
• Request correction of inaccurate records
• Request deletion of their data. The institution’s administrator sends the request to MyTA support at support@courseops.ai, and MyTA tells the administrator when the student’s records have been deleted.

To exercise these rights, contact your institution’s administration. Data subject access requests are processed within 30 days.

11. Contact

For privacy-related questions or concerns, contact your institution’s MyTA administrator or reach out to Ascent Labs at privacy@courseops.ai.