Privacy Policy

Application: Grade AI

Last updated: 12 October 2026

1. Who processes your data

The controller of personal data is:

• Name: Martin Sixta
• E-mail: [email protected]

Write to this e-mail address about anything concerning your data. The controller's full details are in section 7a.

We have no data protection officer, because under Article 37 GDPR we do not need one: we are not a public authority, and our core activity is neither large-scale monitoring of people nor processing of special categories of data. The operator answers directly, at the address above. Nor do we need an EU representative — we are established in the Czech Republic.

Pupil data works differently. There we are only a processor: the school the teacher works for decides about it, and we store it on the school's behalf. What we commit to is set out in the data processing agreement — it is an annex to the Terms of Use and the teacher enters into it on behalf of the school.

2. What data we collect

We collect only what the application needs to work.

When you create an account: your e-mail address, password (stored as a hash, we never see it), and your first and last name. Only a teacher creates an account — a pupil has none and gets in with an ID and a PIN that are tied to no e-mail address (see section 9).

When you are a teacher: the names of the classes you create, subjects, the school year, lists of pupil names in a class, tests including questions and correct answers, and the results of scanned answer sheets.

When you are a pupil: the classes you join, your answers in tests, percentages and grades.

When you go through the intro questionnaire: your answers to the twelve questions the app asks a teacher before sign-up — how long you have been teaching, what and whom you teach, how many pupils you have and how large your classes are, how many tests you set and how long they take you, what slows you down when grading, gender, and where you heard about us. We use them only to build the app around the teachers who use it; in our dashboard we see counts of answers, not individual names. Gender tells us who we are building the app for; we use it for nothing else.

The questionnaire is optional. You can skip it with one tap at the top right, and the gender question also offers "prefer not to say". Without answers the application works the same; it just does not show you an estimate of the time you will save.

The questionnaire does not ask your age. It used to, in bands, and that question was dropped on 5 September 2026 as redundant: age is already settled once, and more strictly, by the age gate before sign-up. The exact date of birth from that gate stays on the phone and never reaches the server (section 9) — moving it into the questionnaire would have turned it into one more personal datum stored against the account. So one age question remains in the whole application, and it is the stricter one.

Technical data: how much of the artificial-intelligence features you have used — this serves solely to enforce the monthly limit.

If you turn on two-step verification (it is optional): the Firebase sign-in service keeps the secret key from which the app on your phone computes the six-digit codes, and the time you turned it on. We do not see that key and send it nowhere.

If you sign up with a partner code: we record that your account was created with that code, when you registered, when you first paid, and until when the partner earns commission on your payments. The partner whose code you used sees only that — with no name and no email address: "someone registered on this day, pays, commission so much". They never learn from us who you are.

If you are one of our partners (you recommend Grade AI for a commission): your name, email address, the code assigned to you, the agreed share and how long it runs, the record of commissions and payouts, and the bank account we pay them to. Only the operator sees the bank account, in the admin panel; it is not written into the admin log.

If you write to us: the address you write from and the content of the message — so we can reply and deal with what you ask.

What is mandatory. Without an email address and a name we cannot create an account — they are necessary to conclude and perform the contract. Everything else in this section arises from what you do in the application yourself, or is expressly optional.

IP address. Like every service on the internet, we see the IP address an incoming request comes from. We use it for one purpose: it becomes a counter key, so that nobody can hammer the application from one place or run up the artificial-intelligence bill on someone else's account. What that produces in the database is a row of the form "this address, this minute, this many requests" — no account, no name, no e-mail alongside it — and it is used for nothing else. The counter is valid for two minutes and is gone at the nightly clean-up at the latest, that is within 24 hours. For IPv6 we keep only the first half of the address, so the individual device cannot be told from it; on one single path — checking a partner code, which runs before registration and has no account attached — the address is not shortened. We do not track you by it and do not link it to your account.

That is true of our own counter. By their nature, the services the application runs on see the IP address too: Firebase sign-in keeps it for security for a few weeks, Firebase website hosting for a few months, and the Cloudflare server sees it on every request that passes through it. They use it to run and protect the service, not for advertising (section 6).

Fonts are bundled into the application and the website. Loading them goes nowhere else.

Device identifier (only when starting a free trial): when you activate a free trial, the application sends a device identifier once. On an iPhone this is the identifier the system assigns to our apps on that phone (Apple calls it the "identifier for vendor"); it is not an advertising identifier, it does not track across other apps, and it disappears when you delete all of our apps. In a browser it is a randomly generated code stored only in that browser. The server keeps only a one-way fingerprint (HMAC) of it and uses it solely to stop one device from repeatedly creating accounts just to get another free trial. We do not store it against your account and do not link it to anything else. The fingerprint is deleted 2 years after the last free-trial activation on that device.

Why we do not ask for consent. We may read data from a device without consent only where that is strictly necessary for a service you have explicitly asked for (Section 89(3) of the Czech Electronic Communications Act). In our view that applies here: you ask for the free trial yourself, and without this check it could be taken again and again. That is our own assessment, not a regulator's ruling.

What we do not collect: location, contacts, microphone, browsing history, or any advertising identifiers. The application has no ads, and no third-party script runs inside the mobile app — the website does run one, Google reCAPTCHA against bots. It loads only in the signed-in part of the website and is described in section 11. The application never reaches into your photo library on its own — it opens only when you go there yourself for test materials (see section 4).

One caveat, so this does not read better than it is. The list above is about what the application asks the phone for — it asks for no location, no contacts, no microphone, and the system will never prompt you about them. But if you sign in with Google, you are using Google's sign-in library, and its declaration to Apple lists the collection of coarse location for Google's own purposes. It is not GPS and it never reaches us — we do not see it, do not store it, and do nothing with it. We write it here because it is why the App Store listing will carry a "Location" label, which would otherwise look like a contradiction of this page. Signing in with Google or Apple is also governed by Google's, respectively Apple's, own rules.

3. Photos of answer sheets

When you scan an answer sheet, the camera image is evaluated directly on the phone. The photo is not sent to a server, not saved to the photo library, and not transmitted anywhere. Only the result is stored on the server — that is, which answers were marked, how many of them were correct, and the grade that came out of it.

A thumbnail of the scanned sheet is kept only in the phone's memory while the scanning screen is open, so you can check that the scan was read correctly. It is never written to the database, and the application has no image storage at all.

Sheets for printing are a different matter. When you have answer sheets printed, a PDF is produced on the phone and pupils' names are in its header. The application drops it into the phone's temporary folder so it can be sent to a printer — we send it nowhere ourselves. If you then pass it on with the system share button (by e-mail, to a cloud, in a message), that is your decision as a teacher acting for the school: where the file goes and to whom, we neither see nor control. See the terms of use, section 3c.

4. Materials you upload to a test

When you have questions generated from your own materials, you can upload photos of notes, PDFs, Word documents, or text files — either from your library or by taking a photo. These files are sent to the artificial intelligence (Anthropic, USA), because it is what creates the questions from them.

We do not store them anywhere. They pass through the server and are gone; nothing about them remains in the application after the test is generated. We send them inside the request itself, not to a file store at Anthropic. Anthropic, however, deletes inputs to its interface within up to 30 days of receiving them and does not use them to train models.

You are in control. The application does not open your library on its own; it opens only when you trigger the upload yourself. When you enter questions by topic or text, no file leaves your device.

We strip metadata from photos. Before an image is sent, the application redraws it on the device — which removes the capture location, the time, and the device model and serial number. Only what is visible in the photo leaves your phone. This applies to every photo, including ones that are not resized; if the redraw fails, the file is not sent at all.

This is why the App Store listing shows a "Photos or Videos" item. That label is about these materials — the files you pick yourself and send for question generation. It is not about scanning answer sheets: that photo never leaves the phone (section 3), so it neither should nor does count towards any label.

Do not put personal data that does not belong there into the materials — in particular, not pupils' names, addresses, or health data. They are not needed to create test questions. Nobody reads or checks the content of the materials; only the file type and size are verified. Whatever you put in is what leaves — which is why the application says so right next to the upload button, and why it is also in the terms of use, section 3c.

5. Why we process data and on what basis

Legitimate interest here always means something without which the service could not be run safely or fairly — never advertising or selling data. You can object to processing based on it (section 8), and we then stop, unless we can show a compelling reason that overrides it — typically protection against misuse.

We make no automated decisions about anyone (Art. 22 GDPR). A fixed formula calculates the grade from the correct answers and the scale the teacher sets; artificial intelligence plays no part in it and decides nothing about anyone.

Statistics for the teacher. The application calculates averages, progress and the ranking of pupils in a class from the results. They are material for the teacher, not a decision — the teacher gives the grade. Only the teacher of that class sees them; a pupil sees only their own results.

6. Who we share data with

We do not sell it to anyone and do not share it for advertising. We use only these processors, without which the application would not work:

Google Firebase (Google Ireland Limited) handles sign-in, the database and website hosting, and each of those parts runs somewhere else:

• The database (Cloud Firestore) with classes, tests, grades and profiles runs in the European Union (the eur3 multi-region).
• Sign-in (Firebase Authentication) is run by Google only in the United States. It holds the teacher's e-mail address and name, the password hash, and the two-step verification key if it is on. For a pupil it holds only the assigned ID, with no name.
• Website hosting and App Check protection run on Google's global infrastructure.

Anthropic PBC (USA) provides the artificial intelligence, for one thing only — writing test questions. It receives only what you give it for that: the test topic and brief, and the materials you upload to a test yourself (photos of notes, PDFs, documents; see section 4). It is not sent your name, your e-mail, anything about pupils — no name, no answer, no result — or photos of answer sheets. Under its terms, Anthropic does not use API data to train its models and deletes it within 30 days. It keeps it longer only if its automated checks flag a request as violating its usage policy (then inputs and outputs for up to 2 years and the results of that check for up to 7 years), or where the law requires it. We send it files inside the request, not to its file store.

Cloudflare runs the server that sits between the application and the artificial intelligence. The text sent to the AI passes through it, along with the sign-in token so it can tell whose limit to count. It does not store the text and keeps nothing from it.

RevenueCat keeps a record of the subscription — whether and since when it is paid. For that it receives an account identifier, the purchase history from the App Store or Google Play, and the technical details of the request (such as the system type and IP address) — not a name or e-mail.

Apple and Google sell the subscription and take the payment for it. In doing so they are not our processors but independent controllers under their own privacy policies — in the EU the seller is Apple Distribution International Ltd., or Google Commerce Ltd, both in Ireland. Your card details go straight to them and we never gain access to them.

Google Ireland Limited (Google Workspace) runs the mailbox that receives mail sent to the address in section 1.

The partner whose code you used at sign-up sees only the data without name or email described in section 2.

Transfers outside the EU. Google and Cloudflare are certified under the EU-U.S. Data Privacy Framework, for which the European Commission has decided that it ensures adequate protection. For Google this also covers Firebase sign-in, which runs in the United States, and the Firebase contract adds the standard contractual clauses on top. Transfers to Anthropic and RevenueCat are covered by the European Commission's standard contractual clauses. We will send you a copy on request (without the commercial parts).

When the law compels us. We will also hand data over where a valid court order, a public authority acting within its powers, or another legal duty requires it — and further, to the extent necessary to protect life, health, or our rights, typically in case of fraud. We hand over only what is asked for, no more. Unless the law prevents us, we will tell you about such a request in advance; where it concerns pupils' data, we notify the school.

If the application changes hands. Student data is not treated as a transferable asset. Before any sale, merger, or wind-up we notify the school 30 days in advance, a buyer is bound by the wording the school accepted, the school may refuse and have the data deleted instead, and in insolvency student data is deleted rather than sold. A transfer to a company the operator himself controls, on unchanged terms, is also announced 30 days in advance; anyone who does not object carries on unchanged, and the school can still end the agreement and have the data deleted. See section 9a of the Terms of Use.

7. How long we keep data

Two different periods, and that is deliberate

We keep pupils' data for a shorter time than your account. After 1 year in which nobody signs in, the classes, pupil names and grades are deleted; your account, tests and folders stay for up to three years.

This is not a slip or extra strictness. The three years come from the length of parental leave, so that a teacher has something to come back to — but that is a reason about the teacher's work, not about children. Children's names and grades have no business being kept alive by a thought about the teacher's return, and the longer they sit unused, the harder they are to justify.

Anyone returning after eighteen months finds their tests and empty classes. They enter pupils again; grades from the period when the application went unused are gone. Results a school is required to archive belong in the school's own system, not here — we are a processor, not a school register.

Backups: short-lived and kept by us alone

We make a copy of the database ourselves, by a scheduled job on the operator's computer, roughly once a week, so that an error or an outage does not cost everything. It sits on the encrypted disk of the operator's computer in the Czech Republic, is sent nowhere else, and is deleted after 7 days. Whatever you delete is therefore gone from it within 7 days at the latest. We would restore from it only if the database were lost. Anything deleted after the copy was made could come back that way: deleted accounts and erasures a school asked for (we keep a record of those) we delete again after a restore, and we tell the teachers concerned about anything else.

Infrastructure providers delete with a delay. They remove deleted data from their own backup systems as well; for sign-in (Firebase Authentication) Google states at most 180 days. We have no access to those copies and restore nothing from them. Google also keeps the database in several copies against hardware failure — but that is not a backup against deletion.

So we say it plainly, unflattering as it is: a weekly copy protects against an outage, not against a mistake you notice a month later. Keep grades that matter to you in the school's own system as well. Grade AI marks tests; it does not replace a school register.

What is actually deleted

Deletion starts only after 30 days to reconsider, so it can be taken back — you cancel it yourself by signing in to the application. After that it is irreversible.

If you are a teacher, everything of yours disappears: classes, tests including questions and correct answers, results, folders, the record of AI consumption, the subscription, the profile, and the account in sign-in.

If you are a pupil, you do not delete your access yourself — your teacher let you into the class and also decides who is in it. A class's teacher revokes your access to that class (your other classes stay); the school or your legal guardian can ask for your data to be erased (section 9). When a teacher's pupil data is erased, your ID and your PIN hash go with it — unless you are also in a class of another teacher; then your sign-in stays for their classes.

Your name on the class roster and your grades with the teacher stay, however. They are neither our data nor yours — they are school assessment and the school decides about them. If a pupil could delete them with a click, that would be a bug, not a feature. Ask the school or your teacher to erase this data; the teacher can delete it in the application themselves — with one button, even after the subscription has expired.

The school can also ask us directly. If the head teacher or an authorised person writes to the address in point 1, we will delete every class and grade held by that teacher within 15 days and issue a record of it. The teacher's account and the tests they wrote stay — they are their data, not the school's.

What remains even after deletion: tax records (as long as tax law requires, at most 10 years), the record of consent to the terms (3 years), the record of admin-panel access (24 months), and for up to 7 days the copy in the backup. All of it is in the table above.

We delete abandoned accounts ourselves. An account nobody has signed in to for three years is flagged for deletion and, two months later, disappears along with all its data. Holding children's names and grades forever because nobody got in touch would not hold up.

Three years is not a random number: that is roughly how long parental leave commonly lasts, and a teacher who returns from it to find not a single one of her tests would be worse off than that period. Anyone who signs in during those two months clears the flag themselves.

7a. Controller details

The controller is Martin Sixta, a sole trader (a self-employed individual) registered in the Czech Trade Licensing Register.

• Business ID (IČO): 30034299
• Registered address: Zbyslavova 1674, 272 01 Kladno, Czech Republic
• Phone: +420 777 002 227
• E-mail: [email protected]

8. Your rights

Under the GDPR you have the right:

• of access to the data we hold about you
• to rectification when something is wrong
• to erasure, that is, to have everything deleted
• to restriction of processing, for example while it is checked whether the data is correct
• to portability, that is, to receive your data in a machine-readable form
• to object to processing based on legitimate interest
• not to be subject to automated decision-making — we make none (section 5)
• to lodge a complaint with the Office for Personal Data Protection (uoou.gov.cz), or with the supervisory authority in your own country — in the EU and the EEA your local one, in Switzerland the Federal Data Protection and Information Commissioner (edoeb.admin.ch)

You can do most of this yourself in the application. You delete your account with all its data in Settings, the Delete account item. For anything else, write to the e-mail given in section 1.

Before we hand data over, we have to know it is you. If a request arrives from an email address we do not hold for the account, we will ask — otherwise it would be enough to write under someone else's name and the data would go somewhere it does not belong. We do not want your ID card; writing from the address you sign in with is enough.

We answer within one month, free of charge. For a complex or extensive request we may extend that by a further two months — we will tell you within the month, with the reason. We may charge only for a request that is plainly repeated without cause, and even then we say so first.

Where processing rests on consent, you can withdraw it at any time. That does not undo the processing that already happened.

If a request concerns a pupil's data, the school decides about it (section 1). When a pupil or a parent writes to us directly, we do not brush them off: we pass the request to the school, help it deal with it, and let them know what happened. We carry out an erasure the school asks for within 15 days.

8a. What emails you get from us

We send no marketing. We have no mailing service — you can see it on the Who we pass data to page, where the "mailing service" row says we have none. We do not sell or lend your email address to anyone.

You get only account-security e-mails, and only when you trigger them yourself: a password reset, an address verification (when you turn on two-step verification), and a confirmation of an e-mail change. The Firebase sign-in service sends them. Nothing else reaches your inbox from us on its own, because we have no mailing service at all — we write to you only when we reply to your message or when we must tell you something under the law or this policy (such as a statement of reasons under section 9 of the terms).

Everything else reaches you another way:

• the end of the free trial — the phone itself reminds you two days beforehand (see below); it does not go through us,
• payments and any failures of them — Apple or Google handle the payment and they write to you, not us,
• a change to the terms or to this policy — we tell you in the application.

There is no unsubscribing from that, deliberately: without those notices the terms could change under you, and the law requires us to inform you of them.

And we will say plainly what follows from it: you hear about changes and news only in the application. A security incident under section 10 is the exception — we e-mail the teachers it concerns directly, by hand from our own mailbox, because a notice in the application would miss anyone who does not happen to open it. As soon as a mailing service is added it will appear on the Who we pass data to page, we will announce it 30 days in advance, and this section will change.

If we ever start sending news about the application, it will be separate and opt-in only, with an unsubscribe link in every such email. Until a mailing service appears here and on the sub-processors page, no such emails go out.

Phone notifications do not come through a server. The application has two reminders — two days before the trial ends and on the day it ends — and the phone schedules them itself when you start the trial. It does not pass through us, we cannot send it whenever we like, and students receive no notifications at all. You can turn them off in the phone's settings.

9. Children's data

The application is meant for schools and some of its users are minors. We take this seriously and are guided by it in every decision about what the application collects.

What we know about a child: first and last name, which class they belong to, how they did in tests, the text of the questions they got wrong, and a note the teacher may write about them. That note is free text written by the teacher — which is why the terms (section 3a) forbid putting anything about a pupil's health, origin, religion, or family circumstances into it. Only the teacher sees it, it goes nowhere else, and the artificial intelligence never receives it. No image — neither the photo of the sheet nor any crop of it leaves the device. Nothing more. No e-mail address, telephone, location, contacts, photos from the library, microphone, or advertising identifiers — the application does not ask for them at all. The one technical extra is the IP address: in the request counter described in section 2 it applies to everyone alike, is linked to no account, and is gone within 24 hours; the services the application runs on see it too (same section). In Firebase sign-in (USA) a pupil is only an ID, with no name.

What we do not do with it: we do not show ads, do not sell data, do not build profiles from it for advertising or for any purpose other than teaching, do not use it to train AI models, and do not send a child's name to the artificial intelligence. Averages, progress and the class ranking are seen only by the teacher (section 5).

Only an adult, aged 18 or over, may create an account — an account meaning an email address and a password. We ask for the date of birth before registration and it stays on the phone; only the yes/no outcome reaches the server.

A pupil signs in differently: with an ID and a PIN. The teacher's class has a code and a switch that turns joining on and off again. While it is on, the pupil enters the class code, writes their own name, and chooses a six-digit PIN; they receive an ID and use the ID and the PIN from then on. Anyone who knows an active code can get into the class — which is why the terms require the teacher to issue it only to their own pupils and to switch it off once the class is in (section 3a), and why a teacher can revoke anyone's access to their class. The age gate asks a pupil nothing — they are not creating an account.

Before joining, the pupil sees the class name and the teacher's name. Whoever lets a pupil into a class can issue them a new PIN (below), so the child should be able to check that the code comes from their own teacher. The teacher's name is therefore visible to anyone who knows an active class code.

A forgotten PIN. Any teacher who has the pupil in one of their classes can issue the pupil a new single-use PIN — a class the pupil joined with its code themselves, or one the teacher moved them into from such a class of theirs; a teacher adding the pupil's account to their class on their own is not enough, and a teacher who removed the pupil from the class, or whose class the pupil left, can no longer issue one. The server makes it up, not the teacher; it lasts an hour and works once. As soon as the pupil signs in with it, the previous PIN stops working, the pupil is signed out on their other devices within an hour and must choose a new PIN; that screen shows who issued the temporary one. If someone else signed in with a temporary PIN, the pupil's own PIN would stop working and they would notice. We record who issued a temporary PIN and when (the last ten issues for each pupil), so that it can be answered who it was. A pupil can receive at most three temporary PINs a day.

From a child we therefore collect two things: their name and the PIN. The application matches the name they type to the name on the roster; if it is not there, it adds it to the roster as a new pupil, and the teacher sees it. We store the PIN only as a one-way hash (it cannot be computed back) and it serves nothing except letting that pupil see their own grades. Six digits are not many, so after five wrong attempts sign-in is locked for 15 minutes and the teacher sees it for that pupil. We do not want an email address, a phone number, or anything that could be used to contact the child outside school, and nobody can reach them through the application.

We do not collect a legal guardian's consent. The name on the roster was entered by the teacher on behalf of the school — the school is the controller and the basis is its own task, not consent. Article 8 GDPR does not apply, because we do not offer the service to the child directly: their teacher lets them in.

When a teacher enrols a pupil in a class, this happens as part of the school's activity. The school, as the controller of its pupils' data, is responsible for informing pupils and their legal guardians; we are a processor and what we commit to is set out in the data processing agreement.

A pupil does not leave a class or delete their access on their own — the teacher decides who belongs in the class. The school, the teacher, and a legal guardian can all ask for a pupil's data to be erased; a legal guardian at the e-mail in section 1. So that a child's data does not go to a stranger, we confirm the relationship to the pupil through the school.

In the United States, COPPA applies as well, and we have a separate notice for it: Children's Privacy. It sets out what we hold about a student, why the school's authorization stands in place of individual parental consent, who receives the data, and how long we keep it.

10. Security

In transit and at rest. Everything between the phone and the server travels over an encrypted connection (HTTPS/TLS). Data stored with Google Firebase is encrypted on the provider's disks as well, that is, at rest.

Who can reach what. Access to the database is restricted by rules that ensure a teacher sees only their own classes and a pupil sees only their own grades. They are not rules on paper — a set of automated tests checks them before every deployment. The wording of tests and the correct answers sit in a part of the database a pupil cannot see, even when asking for it directly.

Passwords and PINs. The password is stored only in a form from which the original cannot be recovered (a salted one-way hash, handled by the Firebase sign-in service), and so is a pupil's PIN. We cannot tell you what your password is — only let you change it.

Who has access on our side. One person operates the application and is the only one who reaches the administration. Only his own account gets in, and only with two-step verification; the most sensitive steps also require a sign-in from the last few minutes. Every look into someone's account is logged — if you ask who looked into yours, that can be answered. The log is kept for 24 months (section 7).

Keys. The service keys to the database and to the artificial intelligence are not in the application or in the database. They are kept as secret variables on the server and on the operator's encrypted disk, as is the weekly copy of the database.

Review. We maintain a written security program: an assessment of risks, safeguards matched to them, and a review at least once a year. It covers the processors in section 6 as well.

No security is absolute. Should there be a breach, it depends on whose data it concerns:

• Teachers' data we hold as the controller. A breach that threatens your rights we report to the Office for Personal Data Protection within 72 hours of becoming aware of it, and we notify you.
• Pupils' data is held by the school as the controller, so the school reports it to the authority. We tell the school without undue delay, within 48 hours at the latest of becoming aware of the breach, and send it everything it needs to report it and to inform parents. We reach the school through the teacher who uses the application.

11. Cookies and local storage

We use no advertising or analytics cookies, and nothing here profiles you to sell you something. That is why there is no consent banner on the website.

One third-party script does run, and we would rather name it than hide it. The website loads Google reCAPTCHA to tell a real person from an automated script, so that nobody can hammer our server or run up the artificial- intelligence bill on someone else's account. To score that, reCAPTCHA reads signals from your browser and stores a cookie of its own. It loads only in the signed-in part of the website — the first time the web application talks to our server (when it checks the subscription or generates questions, for instance). Neither the home page nor these texts load it. We use it solely to secure the site, not for advertising or analytics, and in that use we consider it technically necessary for a service you have asked for yourself — which is why it runs without a consent banner. That is our own assessment, not a regulator's ruling; if a supervisory authority saw it differently, we would add the banner or replace reCAPTCHA. It does not run in the mobile app at all — and nothing replaces it there. Device attestation through App Check is deliberately not switched on in the mobile app (the web SDK cannot reach Apple's attestation from inside a WebView), so what protects the application there is the server-side limits alone, not any proof that a request comes from the genuine app. It is a known gap and our security programme says so too.

The application and the website store on your device only what they need to function:

• your sign-in — so you do not have to enter your password every time (Firebase),
• your language choice and the read state of a few screens,
• the random device code described in section 2, if you activate a free trial.

This storage is strictly necessary for the service to work. If you clear it in your browser, you will simply have to sign in again and set your language.

12. Where we offer the application

We offer Grade AI worldwide, except in the countries listed below, and it is built on European data-protection rules. Those rules apply to every user, including outside Europe — we do not apply a lower standard anywhere.

Where we do not offer the application — and where it must not be used with pupils:

• The United Kingdom — its code for services likely to be accessed by children (the Age Appropriate Design Code) requires a separate assessment, and the law a representative in the country; we have neither yet.
• Brazil — its law on protecting children in digital environments (the ECA Digital) requires services likely to be accessed by minors to verify age and provide parental tools, which we do not have.
• India, Indonesia, South Korea, Vietnam, Kenya, and Uganda — their law requires consent from a legal guardian for a minor's data, which we do not collect.
• Algeria and Tunisia — children's data there requires a legal guardian's consent together with a judge's authorisation, and in Algeria also the authority's permission to transfer data abroad.
• Turkey, Egypt, Saudi Arabia, Serbia, Thailand, Tanzania, and Zimbabwe — a foreign operator needs a registration or licence with the authority there, or a representative in the country.
• Russia, Kazakhstan, Rwanda, and Zambia — data must be stored in the country; in Russia payments do not work either.
• Belarus — because of the European Union's and the United States' sanctions against its regime, and unreliable payments, we have chosen not to offer the application there.
• Mainland China — the application would need a registration with the authority there (ICP), which we do not have. This does not concern Hong Kong, Macao, or Taiwan.
• Syria, Iran, North Korea, and Cuba — the App Store cannot offer the application there, and we do not offer it there on Google Play.

In the United States we offer the application to schools and teachers under COPPA: student data is collected on the school's authorization for a school-authorized educational purpose, never for a commercial one. The details are in a separate notice, Children's Privacy. We also maintain a written security program for children's data, with a named person responsible for it and an annual review.

In Switzerland the Swiss Federal Act on Data Protection applies; the rights it gives you match section 8, and you complain to the Federal Data Protection and Information Commissioner (edoeb.admin.ch).

Outside Europe we store your data in the database in the European Union (section 6; sign-in runs in the United States) and protect it under European rules. If the law of your country gives you more than this page describes, write to us at the address in section 1 — we will honour it.

If you live in California

We do not sell personal information, and we never have. We do not share it for cross-context behavioural advertising, we do not track users over time or across other websites, and there is no advertising in the application — so there is nothing here for a "Do Not Sell" request to switch off, and we do not act on Do Not Track signals because we do not track in the first place.

Beyond that, everything the CCPA grants you, we already give every user under European rules and section 8 of this policy: to know what we hold, to get a copy, to have it corrected, and to have it deleted. We will never charge you more, or give you a worse service, for asking.

Student data is a special case: where it is an education record under FERPA it falls outside the CCPA, and we handle it under the school's instructions and the Children's Privacy Notice. Write to the address in section 1 and we answer within 30 days; we may first need to establish that you are who you say you are.

If you live in another US state

Several states have their own consumer privacy laws (Virginia, Colorado, Connecticut, Texas, and others). Whether or not one of them reaches a service of our size, we give their residents what they grant: to know what we hold, to get a copy, to have it corrected or deleted, and to appeal our answer — write to the address in section 1 and, if you disagree with our reply, write again with "Appeal" in the subject. We do not sell data, do no targeted advertising, and do no profiling that leads to decisions about anyone, so there is nothing to opt out of. Student data is covered by the Children's Privacy Notice.

If you live in Nevada

Nevada law lets you tell a business not to sell your personal information for money. We do not sell it — to anyone, for anything. There is no sale to opt out of, but you are welcome to write and we will confirm that in writing.

13. Changes

When we change this policy, we will update the date at the top. We announce significant changes in the application at least 30 days in advance, as with the terms. Changes to how pupils' data is handled also need the school's agreement (terms, section 10). We will send you any earlier version on request.

Controller: Martin Sixta · [email protected]