Privacy

The institution does. A school, college or coaching institute enrols its own students, decides which parts of the product they use, and holds the relationship with the student and their family. Kitaabi runs the software on that institution’s behalf.

This matters practically: if you are a student or a parent and you want to see, correct or remove information, your institution is the right first contact. They can act on it directly, and we support them in doing so.

Who you are. The name, email address and role your institution entered when it created your account, the admission number it uses to match you to its own records, and which classes or groups you belong to. There is no public sign-up; accounts exist because an institution created them.

What you did while learning. Answers to questions, attempts at checkpoints, which printed pages and topics you opened, and the mastery estimates derived from them. This is the substance of the product: it is what lets it point a student back to the exact printed page they should revise.

Conversations with the tutor. Questions asked of the AI tutor and the hints it gave, so the work is not lost between sessions and a teacher can see how a student was helped.

Consent decisions and administrative records. Which policies were accepted, refused or withdrawn, and when. Withdrawing consent adds a new record rather than erasing the old one, so the history of a decision stays intact.

What it does not hold. No date of birth, no age, no phone number, no postal address, no government identifier and no payment details. The product does not ask for them and has nowhere to put them.

It does not sell data, and it carries no advertising. There are no public leaderboards and no engagement feeds; a student’s results are visible to that student, to their teachers, and to a parent where the institution has enabled it.

It carries no analytics service and no tracking pixels. Nothing you do here is used to build an advertising profile, and nothing is shared with an advertising network — there is no such connection in the product at all.

Content written by AI is never shown to a student until a teacher or an authorised content editor has approved it. That is enforced by the system, not by convention.

Every record belongs to exactly one institution, and the database refuses reads and writes across that boundary rather than relying on the interface to hide them. Access is re-checked on the server for every action; a control being invisible is never what keeps data safe.

We do not do all of this ourselves. These are the services that handle personal data on our behalf, and what each one sees:

• Supabase — the database, sign-in and file storage. It holds everything described above.
• Vercel — runs the application. Our servers for this product are in Mumbai.
• OpenAI — the AI tutor. It receives the question you ask, the lesson material the answer must come from, and, if you use Photo Help, the photograph of your working. It does not receive your name, your email address or any identifier for you.
• Resend — sends invitations, password resets and guardian consent emails. It sees a name and an email address.
• Sentry — tells us when something breaks. It receives an error category and a request reference, and is built so that messages, student content and credentials cannot be sent to it.
• Upstash — limits how often a request can be repeated, to keep the service usable. It sees a short-lived counter, not content.

Depending on how an institution is configured, the tutor may instead run on Microsoft Azure or Anthropic, which receive the same material as OpenAI and no more.

The application and the database are hosted in India. The AI tutor is not: when you ask the tutor a question, your question, the lesson material and — for Photo Help — the photograph of your working are sent to a provider that processes them outside India, currently in the United States.

What that provider does with them, as it has told us: it does not use them to train its models, and it keeps a copy for a limited period for its own abuse monitoring before deleting it. We have asked it not to store the request beyond what that monitoring requires. We are working to move this processing to India, and to reduce that retention further.

We would rather say this plainly than claim the data never leaves. If you would prefer not to use the AI tutor, it can be refused — and refusing it does not take away the rest of the product.

The camera is used only if you choose to photograph your working so the tutor can see where you got stuck. We do not save the photograph; it is passed to the AI provider to be read, and what that provider keeps is described above.

The microphone is used only if you press the microphone button to speak instead of typing. Your browser does the listening, not us — and depending on which browser you use, that can mean your voice is sent to the browser maker’s own service, Google’s or Apple’s, to be turned into text. The audio never reaches Learning OS, and we have no agreement with those companies covering it. If you would rather that did not happen, type instead; an institution can also ask us to turn the feature off for its students.

The AI tutor is designed to ask rather than answer: it offers hints in a fixed order, and the order is enforced by our servers rather than by the model. Every reference it gives back to the book is checked against the real lesson material before you see it, so it cannot invent a page number or a chapter. Where an institution requires it, AI processing is gated by its own separate consent, which can be refused or withdrawn without losing access to the rest of the product.

It can still be wrong. It is an AI, and an explanation can mislead. Your printed book and your teacher are the authority.

Students, parents and staff can raise a request about their data from inside the product, and the institution works through it with a recorded status. Requests are scoped to the institution that holds the records, and an export excludes material that is not the requester’s to receive — other people’s data, credentials, and security internals.

You can ask to see what we hold, to correct it, to have it removed, to see the history of your consent decisions, or to restrict how it is used.

Deleting an account. Signed in, ask under Me → Your account → Delete my account. Not signed in — a student who has left, or a parent — use the deletion page, which confirms the request by email before passing it on. A person at the institution checks the request and carries it out. When it is done the account can no longer be signed in to; the name, email addresses and sign-in are removed; and what the student wrote — notes, discussion posts, tutor conversations — is deleted.

What is kept, stated honestly. The record that a consent decision was made, and the institution’s administrative history, are kept with nothing left in them that names the person. The record of work done (answers and progress) is kept as the institution’s school record, for as long as its retention rules allow. Whether keeping those records in that form is the right reading of the law is a question we are taking legal advice on. Daily database backups are kept for about seven days and cannot be edited, so deleted details can remain in a backup until it ages out. A deletion is not recorded as completed until the erasure itself has recorded what it removed.

Retention is agreed with each institution per category of data, because a coaching institute preparing a student for one examination and a school holding a six-year record are not the same case. The product applies no hidden default: where a rule has not been agreed, nothing is deleted automatically and the case is put to a person instead.

Being straightforward about what that means today: because those periods have not yet been agreed, records are being kept rather than expiring on a schedule. Where a record is subject to a legal hold, it is retained regardless of any schedule.

Many students are minors. Whether a guardian’s consent is required for a given student is set on that student’s record by their institution; the product does not infer it from an age it has guessed, and it does not ask a child for their date of birth. Where guardian consent is required and has not been given, the student is not admitted to the parts of the product that need it.

A guardian responds through a single-use link sent to them, and must be signed in as themselves to answer it — a student cannot accept on their guardian’s behalf. A guardian can refuse, and can withdraw a consent they previously gave.

Connections are encrypted in transit. Records are separated by institution in the database itself. Passwords are stored only as hashes and are never readable by us. Invitation and consent links are stored only as one-way hashes, are single-use, and expire. Logs are built so that student content, questions, credentials and personal details cannot be written into them.

We are not going to tell you the product is perfectly secure, because nobody can say that truthfully. An independent security test of the product is planned and has not yet been carried out.

Write to privacy@likhithlabs.com. If your account was created by a school or college, contacting them directly is usually faster, because they hold the records.

If you have raised something with us and are not satisfied, you can complain to the Data Protection Board of India.