Privacy Policy

1. Who we are & what this policy covers

AcademeX.AI (“AcademeX,” “the platform,” “we”) is an AI-native learning platform used by universities to deliver courses, quizzes, exams, and grades. This policy explains what personal data the platform handles, how it is used, who it is shared with, and the choices you have. It applies to students, instructors, and administrators. It does not cover your university’s own systems or third-party sites we link to. Where your institution or instructor decides what to collect and how to use it within their courses, they act as the controller of that data and AcademeX acts on their behalf (see section 12).

2. Information we collect

2.1 Account & identity

• Your name (English and, optionally, Arabic), your email address, and your password — stored by Firebase Authentication in hashed form, so we never see it.
• Your AcademeX ID (e.g. AX-7K3F9Q), and, where your university provides them, your university Student ID, institution, and account type. Whether your email has been verified.
• The date and version of the Privacy Policy and Terms of Service you accepted at signup.
• Whether you have asked us not to email you about coursework — a single on/off setting you control under Course emails on My Account. It covers the assignment notices described in section 6 and nothing else: email about your account and your sign-ins is not optional, because it is how you are told your password or your address changed.
• Your plan — whether your account has premium access to AI features, the date it expires if one was set, and who recorded it and when. A plan is set by an administrator only; you cannot change your own. It records an entitlement, not a payment: payment is arranged with your institution outside the platform, and we hold no card or bank details (see the Terms, § 8).
• The time we last emailed you a verification, password-reset or email-change message, and a pending new address while an email change awaits your confirmation — kept only to limit how often such emails can be requested.
• An account change history: when you (or an administrator acting on your request) change your name, university, email address or password through My Account, we keep a record of what changed — the field, the previous and new value (no value is kept for passwords), the time, and who made the change. It is stored with your account, visible to you on My Account and to platform administrators, and is deleted with the account. While an email change is pending, the address awaiting verification is stored alongside your current one.
• The courses you are enrolled in are also recorded as a claim inside your sign-in token (identifiers only), so course pages can check your membership without an extra lookup. It is written from your enrollment records and refreshed when they change.

2.2 Your academic work & submissions

• The full content of your answers — including the complete typed text of short-answer responses and the complete source code of coding answers — your Code-Lab drafts (saved as you type), and your lab-step answers, program output, and entered values.
• A per-question review record that pairs your answer with the correct answer and the marks awarded.
• Files you or your instructor upload that relate to your work, such as scanned exam papers (see 2.6).

2.3 Grades & evaluation

• Your grades, bonuses, and grade adjustments, and whether each is published.
• AI-generated scores and written feedback where your instructor enables AI-assisted evaluation (for example, on lab steps, on written chapter assignments, on written answers in live exams and on scanned exam papers), and the per-question record of how each answer was marked — the marks proposed, which were confirmed by your instructor, and which your instructor set.
• An audit trail of grade changes (what changed, by whom, and when), your enrollment status history (including free-text reasons for actions such as withdrawal or denial), and any warning tags recorded on your enrollment.
• Certificates of completion for self-paced courses. When you ask for one, we record its code and date on your enrollment and publish a verification record — your name (and Arabic name where given), the course, the institution and the issue date — that anyone holding the code can view on the certificate page. It is created only at your request and deleted with your account.

2.4 Activity & engagement

• Reading and course progress — which lesson sections you have visited, quiz-completion state, and your last position for resuming — timestamped and synced across your devices.
• Live game / quiz play — your answers, score, and how quickly you responded, which may convert into gradebook bonuses.
• Tool and learning activity — counts and timestamps of what you do on the platform: code runs from lessons, the Code Lab and lab handbooks (whether each run succeeded or ended in a compile or runtime error, the programming language, and how long it took), graded Code-Lab submissions, lab-step checks and live-exam submissions, and — as these features are enabled — the chapters and pages you open, the in-chapter quizzes and practice you attempt (including the score, where one is produced), game rounds you play, and how long you are active. These are kept as per-day counts, plus an individual record of each action (what, when, and in which course) kept for up to 90 days. Your source code, your answers and the text you type are not stored in these records. A separate short-lived count of your code runs — how many this minute and today — is also kept so the code runner can apply a fair-use limit; it holds counts only, never code. You can see your own counts; the records are otherwise readable only by platform administrators.

2.5 Exam-integrity (proctoring) signals

During proctored live exams the platform records integrity events, stored with a timestamp and kept for review. These include: switching tabs or losing window focus; exiting or refusing full-screen; attempts to open developer tools; copy, paste, cut, right-click, drag, or print actions; using PrintScreen, in-browser screen capture, or the system snipping/recording shortcuts; and detection of multiple monitors. The platform also records a device fingerprint — a one-way hash of properties such as your browser user-agent, screen size, colour depth, language, platform, CPU core count, device memory, and timezone — which is stored with your submission to prevent one exam being resumed from another device. During the exam your screen shows an on-screen watermark of your email, session, and the time, so any screenshot can be traced. A similar paste-suspicion signal may be recorded on ordinary graded Code-Lab work. These signals are recorded only in connection with the relevant assessment. The platform does not capture your webcam or screen video.

The platform also records, on the same submission: the device properties behind that hash (browser user-agent, platform, language, timezone, screen and window size, touch capability, CPU core count and device memory), so your instructor can see whether two devices were used; a timeline of your sitting — when each question was shown, when you first and last answered it, how long you spent on it, and each period the exam window lost focus, was hidden or left full-screen, with its length; and, where your instructor has set a room location, your browser location when you declare yourself ready and again when you submit, with its accuracy, so the exam can tell whether you were in the room. Location is requested through the browser’s own permission prompt; declining is recorded as “not shared” and never blocks the exam. From these signals the platform computes a per-session integrity score that your instructor sees with its reasons. During a live exam your instructor may project a class-visible board showing how many students are ready, in progress or finished, the names and finish times of students who have finished, and the names of students whose timing pattern the score has flagged above a threshold the instructor sets, or who have left the exam window more often, or for longer in total, than limits the instructor sets. A flag is a prompt for the instructor to look, not a finding of misconduct.

2.6 Uploaded exam papers

Where exams are on paper, scanned answer scripts (PDF/image) are stored in the platform’s file storage. These files carry metadata including your email and your account identifier and feed AI-assisted grading.

2.7 AI processing logs

When an AI feature runs, the platform logs the request and response for cost tracking, quality, and abuse monitoring. For grading, these logs can include the answer-key text, the AI’s transcription of your answers, the marks and feedback, and the email of the account that ran the grading. If you use the AI course tutor, the logs include your questions, the lesson text they referred to, and the tutor’s answers. AI logs are readable only by platform administrators. The prompt and response text is deleted after a limited period (currently 90 days). A shorter metering record — the account, time, model, token counts and cost — is kept longer as the evidence behind billing, so a charge can still be explained or disputed after the text itself is gone.

2.8 Technical & usage data

Basic information your browser sends (such as device and browser type and IP address), and data saved on your own device to make the platform work (see Cookies & local storage). Loading our pages also sends your IP address and browser type to the content-delivery networks that serve fonts and code libraries (see section 6). We do not use advertising or cross-site tracking.

2.9 AI billing records

If your AI usage is charged for, we keep a billing record: your running usage cost, the amount charged to you, any AI credits you have bought and your remaining balance, payments an administrator has recorded against your account, and whether another account — such as your instructor or department — is paying on your behalf. Where usage is sponsored, the sponsoring account can see the amount attributable to the students it pays for, but not their prompts, questions or answers. You can see your own billing record; otherwise it is readable only by platform administrators. We keep it while your account is active and for up to 24 months after a charge is settled, or longer where accounting or legal obligations require it. AcademeX.AI does not collect or store card or bank details — payments are arranged outside the platform and only recorded here.

2.10 Lecture recordings (instructor voice)

When an instructor records a lecture in the presentation mode, we store the instructor’s microphone audio and a log of presentation actions — slide timing, on-slide annotations and pointer movement, and code-runner activity (code typed and run output shown during the lecture). Recording is started explicitly by the instructor. Recordings are attached to the course content and are accessible to the course’s enrolled students and staff, like the chapter they belong to. The instructor may optionally have the audio converted to a uniform platform voice, or transcribed for captions and a transcript, by the third-party speech services described in section 6; the original audio is retained alongside any converted version. Course staff can delete a recording at any time. Student voices are not intentionally recorded — instructors are expected to use a personal microphone, though ambient classroom sound may be captured incidentally.

2.11 Access-control records

Administrators can enable or disable individual platform features for user groups (students, instructors) or for individual accounts. We keep a record of these decisions and their effects: when an administrator changes who may use a feature (which administrator, which feature, which group or account, the old and new setting, and the time), and when a signed-in account is turned away from a feature that has been disabled for it (the account, its role, the feature, the page address, and the time — recorded at most once per feature per browsing session). These records exist so access decisions are accountable and disputes can be resolved; they are readable only by platform administrators and are never used for advertising or shared with third parties.

2.12 Sign-in security records

To notice when someone other than you is using your account, we keep a short record of how your account signs in: a random identifier the platform saves in each browser you use (not a fingerprint — clearing the browser’s storage discards it), a plain label for that browser and operating system, an approximate location (country, region and city) that our hosting provider derives from your network address, a truncated form of that address (the first part of the network, never the full address), and the time of each sign-in. We remember at most the eight most recent browsers per account. For staff accounts we also count failed sign-in attempts and, after repeated failures, may lock the account for a short time; the count, the lock and the number of locks so far are kept with the account. We record whether two-step verification is turned on and when — never the authenticator secret, which is held by Firebase Authentication and by your app. A one-time code we email you to confirm a new browser is stored only as a hash and only for a few minutes.

We use these records to tell a new browser or location from a known one, to pause a sign-in until it is confirmed, to stop password guessing, and to email you about a sign-in from a new browser, an account lock, or a change to two-step verification; platform administrators are also told about locks and reversals. Sign-ins by staff, and the events above for every account, are also written to the activity records described in section 2.4. You can see the browsers your account was used from, remove one, or sign out everywhere under My Account › Security. These records are readable by you and by platform administrators, are kept while your account exists (the events for 90 days), and are never used for advertising or shared with third parties.

2.13 Email delivery records

• For each email the platform sends you (the account, sign-in, enrollment and coursework messages listed in section 6) we keep a delivery record: which kind of message it was, the address it went to, when it was sent, the message id our email provider assigned, and what the provider reported back — accepted, delivered, delayed, bounced, marked as spam, failed, or suppressed — or, if it was not sent, why (email not configured, switched off by an administrator, or held because the day’s sending allowance was nearly used up). Never the subject line or the text of the message: some of those carry a one-time code or a mark.
• From those records we keep counts per account (how many messages, of which kinds, the last one and its outcome) and per day and in total for the platform, so an administrator can answer “did my email arrive?”, notice an address that bounces, and keep the platform inside its email provider’s daily sending limit.
• Only platform administrators can see these records, through the admin dashboard. The per-message rows are kept for 12 months; the per-account counts are kept with the account and deleted when it is removed (section 8).

3. How we use your information

• Managing enrollment in courses and sections, including instructor approval of join requests (your name and email are shown to the instructor so they can recognize you), and emailing a section’s instructor when you request access to their course (that notice carries your name, email and AcademeX ID).
• Recording, evaluating, and showing your grades to you and your instructors, including AI-assisted evaluation your instructor configures.
• Delivering course content and tracking your progress through it.
• Maintaining academic integrity during live exams.
• Notifying you by email of decisions about your account and enrollment (for example, when an administrator approves an instructor request or an instructor admits or declines a section join request), and delivering verification or password-reset links an administrator sends on your behalf.
• Operating, securing, monitoring, and improving the platform, and responding to support requests.

4. Cookies & local storage

AcademeX.AI uses only first-party storage necessary to run the service — there are no advertising or cross-site tracking cookies:

• Sign-in session: Firebase Authentication keeps you signed in on your device.
• Local storage: small items in your browser — such as your reading/course progress, a cached copy of your role (academex_role_…), and your AI course-tutor chat transcripts (kept only on your device and removed at sign-out) — so pages load correctly and remember where you were. You can clear these from your browser settings.

Loading our pages also makes functional requests to third-party content-delivery networks (section 6), which necessarily receive your IP address. A chapter’s embedded video player (section 6) is loaded only when you scroll to it, and any storage it sets when you press play is YouTube’s, not ours.

5. Who can see your data

• You — your own grades, submissions, and progress, and the browsers your account was used from.
• Your instructors — the roster, grades, submissions, and integrity events for the sections they teach. An instructor of a course who tries to add you to one of their sections may also learn one fact about another section of that course: whether you already hold a place in it in the same term (a student may hold one section of a course per term; see the Terms of Service, § 2) — the section is named only if they teach it too, and never your grades or work there.
• Platform administrators — for support, migrations, and monitoring.
• Anyone holding a certificate code — the verification record of a self-paced certificate you chose to issue (name, course, institution, date).

6. Service providers & third parties

Your data is never sold and never shared for advertising. It is shared only with the providers that make the platform work, acting on our or your institution’s behalf:

• Google Firebase — authentication, database, and file storage.
• Vercel — hosting of the site and its serverless functions (through which requests pass).
• AI provider(s) configured by your institution — one or more of Google Gemini, Anthropic, or OpenAI. Depending on the feature, the provider receives the relevant content: for grading, this includes images of scanned answer pages, the typed text of written answers (on lab steps, on written chapter assignments and on written answers in live exams), the answer key, and course details — where your instructor asks for AI marking, a second AI model may independently mark the same answer, and a third may settle a disagreement between the two; each receives the same answer, key and course details, and none receives your name; for matching a paper to a student, a class list of names and emails; for AI-assisted content generation, the instructor material involved; and if you chat with the AI course tutor, your questions, any lesson text you select, and recent messages of that conversation. We ask providers not to train on this content; whether that holds depends on the provider’s API terms for the account in use. Your institution may instead run a self-hosted model (keeping data on its own server) or use a manual path where a staff member supplies the AI themselves. The tutor also offers a “my own AI” option: the platform only prepares a prompt for you to copy — anything you then paste into an outside AI service is governed by that service’s own terms, not ours.
• Speech services for recorded lectures — when an instructor uses the optional voice tools on a lecture recording (section 2.10), the recording’s audio is sent to ElevenLabs (conversion to the uniform platform voice) and/or to the configured transcription provider — OpenAI (Whisper) or ElevenLabs (Scribe) — to produce captions and a transcript. Both are initiated by the instructor per recording; the audio processed is the instructor’s voice, not student submissions.
• Transactional email — every email the platform sends about your account is delivered through Resend, which receives your name, your email address, and the content of that message: sign-up verification, password-reset links (requested by you or by an administrator), the confirmation sent to a new address when you change your email and the notice — with an undo link valid for 7 days — sent to your previous address, and decisions about your account or enrollment (instructor-access approval, section join requests), and the notice sent to a section’s instructor when you request access to their course, and the sign-in security notices described in section 2.12 (a sign-in from a new browser, the one-time code that confirms it, an account lock and its unlock link, changes to two-step verification and the link that recovers a lost authenticator). Since 8 September 2026 it also carries coursework notices about your chapter assignments: that one has opened, that one closes within a day and we have no submission from you, that a deadline has been extended, and — where you have submitted but not reached full marks and attempts remain — that you may attempt it again. That last message names your current mark on that assignment and the number of attempts you have left, so it tells the mailbox something about your academic performance; each message also names the course, the chapter and the deadline. They go to the address on your account, and you can switch all of them off under Course emails on My Account — your instructor can also switch a notice off for a whole course. Resend also reports back whether each message was delivered, delayed, bounced or marked as spam, and we record that outcome per message (section 2.13); we do not track whether a message is opened or a link in it clicked. Google Firebase sends only its own notice when two-step verification is added to your account, and no other email on our behalf. We do not send marketing email.
• Code-execution server — when you run or submit code, your source code and any input you type with it are sent to a code-execution server AcademeX operates, hosted for us by Hetzner in Germany. It compiles and runs the program in an isolated sandbox with no access to the internet, returns the output, and the submission is deleted within one hour (section 8). Your code is no longer sent to a third-party compiler service.
• Content-delivery networks — Google Fonts, Google’s SDK CDN, and Cloudflare serve fonts and code libraries and receive your IP address and browser type when pages load.
• Video (YouTube) — some chapters include a video player from YouTube (Google). The player is embedded in privacy-enhanced mode (youtube-nocookie.com) and is loaded only when you scroll it into view — open a chapter and never reach the player, and nothing is sent to YouTube at all. When it does load, YouTube receives your IP address, browser type and the address of the page. If you press play, YouTube may store information on your device and, if you are signed in to a Google account in the same browser, associate the view with that account under Google’s own terms. We do not receive, request or store anything about what you watch (section 8). Videos are chosen by teaching staff, and no player ever starts on its own.

We may also disclose data where required by law or to protect the rights and safety of users.

7. International data transfers

Our providers may process and store data on servers outside your country (for example, in the United States or Europe). Where that happens, the transfer relies on the providers’ own safeguards and applicable data-protection terms. By using the platform you understand that your data may be processed in these locations.

8. How long we keep your data

We keep your account and academic records while your account is active and for as long as your institution needs them to meet its academic record-keeping obligations. Uploaded exam papers, integrity signals, and AI logs are kept only as long as needed for their purpose and then deleted. Because your email is copied onto related records (such as enrollments, grades, and submissions) so the platform can function, full erasure may take time and may be limited by records your institution is required to retain. On a valid removal request (section 9), data is deleted subject to those obligations. Sign-in security records (section 2.12) are kept while your account exists; the sign-in events among them are kept for 90 days. Email delivery records (section 2.13) are kept for 12 months; the per-account counts among them are deleted with the account. Code you run or submit is deleted from the code-execution server (section 6) within one hour; what remains of a run is the count described in section 2.4, never the code itself. We keep nothing about embedded-video playback (section 6) — no view, no position, no duration; any record of what you watched is Google’s, held under its own retention.

9. Your rights & choices

• You may cancel a pending course join request at any time before it is approved.
• You can view the identity data we hold and correct your name, email address and password yourself at any time on My Account (/account.html). Changing your email is verify-first: the new address must confirm a link we send it before it takes effect, and your previous address is notified and can undo the change. Name changes are applied to the copies kept on your course records so instructors see the corrected name.
• For anything else, you may ask your instructor or a platform administrator to access, correct, or delete your account and associated personal data. Deletion is handled through the platform’s account-removal tool and is subject to your institution’s record-keeping obligations for academic results.
• You can clear locally stored data from your browser at any time.

10. How we protect your data

Passwords are hashed by Firebase Authentication and never visible to us. Access is restricted by server-side security rules so students, instructors, and administrators reach only the records they are entitled to, and administrator access is limited to support and operations. No system can be guaranteed perfectly secure, but we work to protect your information using industry-standard measures. Repeated failed sign-ins lock a staff account for a short time, a sign-in from a new browser or location may have to be confirmed by email, and staff can — and, where the platform is configured so, administrators must — protect their account with two-step verification. Account security is shared: we hash and gate, but the credentials themselves are yours to protect — see the Terms of Service, § 2 and § 7.

11. Children & minors

AcademeX.AI is intended for university students and staff and is not directed at children. If you are below the age of digital consent in your country, please use the platform only with the involvement of your institution or a parent or guardian. If you believe a minor has provided personal data without appropriate consent, contact us and we will address it.

12. Roles & responsibilities

Your institution and instructors decide which courses, assessments, and AI features to use, what data those collect, and how grades and records are handled — for that data they are the controller. AcademeX provides the platform and processes data on their instructions and to operate and secure the service. Requests about how your academic data is used in a specific course are best directed to your instructor or institution; requests about the platform itself can come to us.

13. Changes to this policy

If this policy changes materially, the version date at the top changes and you may be asked to accept the new version at your next sign-in. The version you accepted is stored with your account.

14. Contact

Questions about this policy or a request about your data? Contact your instructor or a platform administrator, or email privacy@academex.net. See also our Terms of Service.

AcademeX.AI — the AI-native learning platform for universities.