Where your children's data lives
This page describes where BuddyAI stores and processes school data, and where it does not. It is written to be checked against the software, not to reassure.
Not yet live
BuddyAI is not deployed. There is no hosted environment and no pupil data on any server. Everything below is the architecture the product is committed to and will be provisioned against before any school data is loaded. It is a commitment, not a description of a running system.
The planned hosting region
School data will be held in Amazon Web Services in the Asia Pacific (Mumbai) region, inside India. The application and its PostgreSQL database are planned for the same region and the same private network, so pupil records are not designed to leave India in the course of normal use. Infrastructure will be created from version-controlled templates, so the region a server runs in is a reviewable line in the repository rather than a setting someone chose by hand.
The one place data leaves India today
BuddyAI uses Google Gemini to generate worksheets, hints and summaries. The product currently reaches the model through the Google Gemini API, which processes the text of a request outside India. Moving this to a Mumbai-region service is an open decision that has not been made yet. We state it here because a residency page that omitted it would be misleading: while a school evaluates us, this is the exception to everything above.
When a pupil uses the microphone, the recording and the text that is read back to them pass through a speech service - OpenAI, or Sarvam for Hindi and Telugu where a school chooses it - which processes them outside India. The service receives the audio and the reply text only, never the pupil's name or marks, and only while the pupil is speaking to the tutor.
What is sent to the model is the material needed to answer: the question asked, and the textbook passages retrieved for it. A pupil's name, contact details and marks are not part of that request.
How one school is kept apart from another
Every school is a separate tenant. Separation is enforced by the database itself through row-level security, so a query issued for one school cannot return another school's rows even if the code asking for them is wrong. Records that point at a person carry the school identifier in the reference, so the database refuses a row that names a user belonging to a different school.
What is not in place yet
Being straightforward about the gaps is part of the commitment. Encrypted off-site backups and a rehearsed restore are designed but not yet running. An independent penetration test has not been commissioned. A self-service way for a school to export or erase a pupil's record has not been built, and until it is, such a request is handled by our team by hand. None of these will be described as complete on this page until they are.
A fuller technical description of this architecture is maintained alongside the source code for reviewers who want the detail.