Data Processing Agreement
Application: Grade AI
Last updated: 12 October 2026
This is an annex to the Terms of Use. It applies to you only if you use the application as a teacher and enter pupils' data into it. It does not concern a pupil themselves — a pupil is a user, not a controller.
Why this document exists
When you enter your pupils' names and grades into the application, that data is neither yours nor ours. It is children's data and the school you teach for decides about it — in GDPR terms it is the controller. We only store and process it according to what you do with it — we are the processor.
Article 28 of the GDPR says such a relationship must be governed by a contract. Without one, the processing is unlawful on both sides. This text is that contract.
You enter into it on behalf of the school you teach for. If you do not have the school's permission to do so, do not use the application with pupils and sort it out with the school first.
The school can also take it over itself at any time — by a confirmation from the school's e-mail address or a head teacher's signature, sent to [email protected]. It is not a condition of using the application, just an option for schools that want the agreement concluded directly.
1. Who is who
- Controller: the school (or other founding body) you teach for. Represented by the teacher who accepts these terms, unless the school has taken the agreement over itself (see the introduction).
- Processor: Martin Sixta, [email protected]. The processor's full details are in point 6a.
2. What this concerns
| Subject matter | Operation of the Grade AI application: storing classes, tests, scanned answers, and grades. |
| Purpose | Evaluating tests and keeping grades. Nothing else. |
| Nature of the processing | Storage, organisation, retrieval, display to the teacher and the pupil, rectification, and erasure — automated, within the application. |
| Duration | For as long as you have an account with us. Ends when the account is deleted. |
| Categories of data subjects | Pupils of the school, usually minors. |
| Types of data | Pupil's first and last name, class assignment, test answers, percentages, grades, question texts, the teacher's note about the pupil. For a pupil who signs in to the application, also the ID the application assigns and a one-way hash of the PIN they choose. No image — the photo of the sheet never leaves the device. No pupil email — only a person aged 18 or over may create an account; a pupil signs in with an ID and a PIN. Technically, in addition, the IP address: in our anti-flooding request counter it is linked to no pupil and kept for at most 24 hours (point 6); the services the application runs on see it too — Firebase sign-in keeps it for a few weeks, website hosting for a few months (point 5). |
Special categories of data (health, religion, origin, and the like) do not belong in the application and we do not process them. Do not write them into names or into questions.
3. Our obligations
We undertake that:
a) We process data only on your instructions. Ordinary use of the application is the instruction. We do nothing with pupils' data on our own initiative — we do not analyse it, sell it, use it for advertising, or use it to train artificial-intelligence models.
The only exception is what the law requires of us. Should Union or Member State law oblige us to process the data otherwise than on your instructions, we will tell you before we do so — unless that same law forbids such a notice on important grounds of public interest. We will likewise tell you if, in our view, an instruction of yours infringes data-protection law.
b) We maintain confidentiality. The application is currently operated by a single person. If another joins, they will be bound by confidentiality in writing.
c) We secure the data in accordance with Article 32 of the GDPR — see point 6.
d) We will not engage another processor without your knowledge. The ones we use today are listed in point 5 — and with that list you give us general authorisation for them. If one is added or replaced, we will announce it in the application at least 30 days in advance. You may object to the change at the address in point 1; if we cannot resolve the objection, you may end the agreement and we will hand you the pupils' data or delete it. We bind every further processor by a contract imposing data-protection obligations equivalent to this agreement, and we remain liable to you for its performance as if we had acted ourselves (Article 28(4) GDPR).
e) We will help you handle pupils' rights. If someone requests access, rectification, erasure, or portability of data, write to [email protected]. You can do most of it yourself directly in the application; with the rest we will help within 15 days, so you can meet the statutory one month.
f) We will report a security incident to you without undue delay, at the latest within 48 hours of the moment we learn of it — so you still have time to notify the supervisory authority (Art. 33 GDPR, 72 hours). We will give you everything you need for that and for informing pupils and parents, and add whatever we learn later.
g) After the end we delete the data — or return it, at your choice. Deleting a teacher's account starts a 30-day reconsideration period, after which everything belonging to it is irreversibly deleted: classes, tests including questions and correct answers, results, folders, and the account in sign-in.
If you would rather have the pupils' data than have it deleted, write to [email protected] before that period runs out. Within 15 days we will give it to you in a machine-readable form (an ordinary spreadsheet format) and only then delete it. We do this by hand from the admin panel — there is no export button in the application and we do not promise one.
Backups are short-lived and kept by us alone. A scheduled job copies the database roughly once a week, and the copy sits only on the encrypted disk of the processor's computer in the Czech Republic; it is sent nowhere else and is deleted after 7 days. Whatever we delete is therefore gone from it within 7 days at the latest. We would restore from it only if the database were lost; deleted accounts and erasures made on your instruction (we keep a record of those) we delete again after a restore, and we tell you about anything else that came back. Infrastructure providers remove deleted data from their own backup systems with a delay — for sign-in (Firebase Authentication) Google states at most 180 days; we have no access to those copies and restore nothing from them.
A weekly copy protects against an outage, not against a mistake someone notices a month later. So: keep results that matter to you in the school's own system as well. Grade AI is a tool for marking tests, not a school register.
An account nobody has signed in to for 3 years we will delete even without an instruction — holding children's data forever just because nobody got in touch would not hold up.
On your instruction we will delete pupils' data at any time — without closing the teacher's account. Write to [email protected] from a school address; the head teacher or an authorised person is enough. We will delete every class and grade held by that teacher within 15 days at the latest. The teacher's account and the tests they wrote stay — they are their data, not yours. The teacher has the same button in the application (Settings → Delete student data) and it works even after the subscription has expired: the right to erasure is not sold with a subscription.
For every such erasure we issue a record — a number, the date, who asked for it, and how many entries disappeared. We keep it for 3 years as evidence that the erasure actually happened, and it contains no pupil's name.
A pupil does not delete their access themselves — the teacher revokes it. The name on the roster and the grades are your records as the controller; you can delete them yourself in the application at any time, and the pupil's ID and PIN hash go with them.
h) We will demonstrate that this is so, and allow audits. On request we will send the information needed to demonstrate compliance with Article 28 of the GDPR — a description of the measures, the record of processing, the results of the automated permission tests. An audit, including an inspection, may be carried out at our end by you or by an auditor you mandate who is bound by confidentiality: give at least 30 days' notice, at most once a year (at any time after a security incident or on a supervisory authority's instruction), and the cost is borne by whoever requests it. The operations themselves run with cloud providers (point 5), whose data centres nobody will let us into — there the inspection is replaced by their independent audits and certifications (such as ISO 27001 and SOC 2), which we will send you.
i) We will help you with an impact assessment. If the school needs a data protection impact assessment or a consultation with the supervisory authority (Articles 35 and 36 GDPR), we will send it a description of the processing, our risk assessment, and the measures taken.
4. Your obligations as controller
- Inform pupils and their legal guardians that the school uses the application, what data it holds, and why. We have no direct relationship with pupils and cannot do it for you.
- Have a legal basis for it. For a public school this is the performance of a task in the public interest; for a private one, usually a contract or a legitimate interest. It should not be the pupil's consent.
- Do not put more into the application than is needed — in particular no data about health, origin, religion, or family circumstances.
- Guard your own access. The password is yours; do not give it to anyone.
- Guard the class code. Joining stays open for as long as the teacher leaves it switched on at the class; anyone who knows the code can get into that class. Switching it off, and revoking someone else's access, are both in the class detail. A name that already has its own PIN on the roster cannot be taken by anyone else, and the PIN locks for 15 minutes after five wrong attempts.
- Answer for what you carry out of the application. Printed sheets and the PDF bearing pupils' names are passed on by the teacher, using the phone's own share button. We do not make that transfer and cannot see it — the controller decides on it.
5. Sub-processors
The application does not work without them. They are all bound by their own contracts, which prohibit using the data for anything else.
A continuously maintained list is on its own page, Who we pass data to — including what exactly goes where and where it is held. If anyone is added, we will announce it 30 days in advance under point 3(d) above.
| Who | For what | Where |
|---|---|---|
| Google Ireland Ltd. (Firebase) | Database (Cloud Firestore) | European Union (eur3 multi-region) |
| Google Ireland Ltd. (Firebase) | Sign-in (Firebase Authentication) — for a pupil only the ID, with no name, and the IP address at sign-in | USA; Data Privacy Framework certification and standard contractual clauses |
| Google Ireland Ltd. (Firebase) | Website hosting and App Check protection | Google's global infrastructure |
| Cloudflare, Inc. | The server that sits between the application and the artificial intelligence, signs pupils in, enforces limits, and serves the admin panel | EU / worldwide; Data Privacy Framework certification and standard contractual clauses |
| Anthropic PBC | Artificial intelligence — generating test questions, nothing about pupils | USA, standard contractual clauses |
Who is deliberately absent. RevenueCat (subscription records) and Apple and Google (selling the subscription) receive only data about the teacher as a customer — no pupil data reaches them at all, so they are not further processors under this agreement. Apple and Google are, moreover, independent controllers when they sell. All of them are listed in the privacy policy, section 6.
Only what the teacher enters is sent to the artificial intelligence. The test topic and brief — and, if the teacher has questions generated from their own materials, also photos of notes, PDFs, and documents that they upload for it.
Nothing about pupils is sent. No name, no answer, no result, no photo of an answer sheet. Until 5 September 2026 the application could explain a pupil's mistakes to them and sent the question text and their answer for that; that feature has been removed.
The materials are stored neither at the controller nor at the processor and are sent inside the request, not to a file store at Anthropic. Anthropic deletes inputs to its interface within 30 days — longer only for a request its checks flag as violating its usage policy (inputs and outputs up to 2 years, the results of the check up to 7 years), or where the law requires it — and does not use them to train models.
A photo of a sheet does not leave the phone. It is evaluated directly on the device; only the parsed result goes to the server — no image and no crop of one. The application has no image storage at all.
6. Security
- Everything is transmitted encrypted (HTTPS).
- Access to the database is restricted by rules that ensure a teacher sees only their own classes and a pupil only their own grades. These are not just rules on paper — a set of automated tests guards them and runs before every deployment.
- Passwords are stored only in a form from which the original password cannot be recovered.
- The wording of tests and the correct answers sit in a separate part of the database that a pupil cannot see, even if they ask for it directly.
- The application has no ads and no third-party tracking tools. The one third-party script runs in the signed-in part of the website — Google reCAPTCHA against bots, described in the privacy policy, section 11. It does not run in the mobile application at all and never touches pupil data. The fonts are bundled into the application and are not loaded from anywhere else.
- A pupil's PIN is stored only as a one-way hash, and sign-in locks for 15 minutes after five wrong attempts.
- Only the operator's own account gets into the admin panel, and only with two-step verification; the most sensitive steps require a sign-in from the last few minutes.
- Access to the admin panel is logged — including who looked into which account. If you ask who had access to your data, it can be answered.
- 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 (point 3g).
6a. Processor details
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].
7. Transfers outside the EU
Pupils' data sits in a database in the European Union. The pupil's ID and the IP address at sign-in reach Firebase sign-in, which Google runs only in the United States; requests also pass through Cloudflare (the server), and — only if a teacher puts it there in breach of the terms — data can leave through materials sent to Anthropic. Cloudflare and Google are certified under the EU-U.S. Data Privacy Framework, for which the European Commission has decided that it ensures adequate protection (Article 45 GDPR), and the Firebase contract adds the standard contractual clauses on top; for Anthropic the transfer is covered by the European Commission's standard contractual clauses (Article 46 GDPR). For Switzerland, the Swiss extension of the same framework and clauses adapted to Swiss law apply in the same way.
This agreement is your instruction for that transfer. We will introduce no other transfer outside the EU without notice under point 3(d).
7a. If the school is outside the European Union
The agreement applies to schools outside the EU and the EEA as well. Where local law knows an equivalent role — a "service provider" or "school official" in the United States, a processor under Swiss law, and the like — we take it on and commit to everything this agreement requires. By using the application you instruct us to store the data in the European Union. For schools in the United States, the Children's Privacy Notice applies as well.
8. Liability
We are liable for damage caused by processing if we breached obligations that the GDPR imposes directly on the processor, or if we acted outside your instructions. You are responsible for having a legal basis for the processing and for having informed pupils about it.
9. Changes
We may change this agreement in the same way as the terms: we will announce material changes in the application 30 days in advance. A transfer of the agreement to a company the processor himself controls, on unchanged terms, is governed by section 9a of the terms: it is also announced 30 days in advance, and you can then end the agreement and have the data deleted. If you do not agree with a change, you can close the account and the data will be deleted. A change of purpose, or of who receives pupils' data, also needs the school's agreement (terms, section 10).
10. Precedence
If the terms and this agreement conflict, this agreement prevails for pupils' data. A separate written agreement with the school (terms, section 1) prevails over both.
Processor: Martin Sixta · [email protected]