What to ask before you let AI near student records

Why school data raises the bar

A school's database is mostly information about children: names, dates of birth, guardians' phone numbers, marks, attendance, medical notes, and who owes money. Almost every category is one a school would be uncomfortable seeing outside the building.

An assistant is not inherently dangerous with that data. What is dangerous is an assistant whose access is undefined, whose outbound data flow is undocumented, and whose actions are indistinguishable from a staff member's. The questions below are the ones that surface all three, and they can be asked in a demo.

Eight questions, in the order they matter

1. What can it read, and whose permission does it use? The only good answer is: exactly what the person asking can already read, re-checked at the moment of asking. An assistant with its own service-level access is a permission bypass with a chat interface.
2. What leaves the building? Ask which text reaches the model provider, and what is removed first. Ask to see the boundary in the product, not on a slide.
3. Which data is excluded entirely? Health, infirmary, counselling and wellbeing notes about a child should not be part of an assistant's surface at any permission level. If the vendor has not thought about this, they have not thought about children's data.
4. Can it change anything on its own? A write action must be proposed and confirmed by a person. "It can update records for you" is a feature request from somebody who has not yet had to reverse one.
5. Which numbers are computed and which are written? Financial and academic figures should come from the same deterministic code that produces your reports, with the model writing only the sentence around them. If the model produces the number, the number is a guess.
6. Does it write queries? If an assistant generates database queries, its blast radius is your whole database. A safer design routes a question to a fixed catalogue of vetted, parameterised reports.
7. Can a parent see another family's child? For any parent-facing assistant, the answer must be structurally no — enforced by the child scope of the authenticated account, not by prompt instructions.
8. What does it cost, and who is metered? An assistant with unbounded usage is an unbounded bill. Ask how usage is measured, where it is visible, and what happens when a limit is reached.

Three answers that should worry you

• "It is completely private, nothing is sent anywhere." Unless the model runs on the school's own infrastructure, something is sent somewhere. The useful answer describes what is sent and what is stripped — not that the question does not apply.
• "The AI is trained on your school's data." Ask whether that means fine-tuning on your records and, if so, where those records then live and who else's assistant benefits from them. Most of the time the phrase is loose marketing for retrieval, and it should be corrected rather than repeated.
• "It is accurate." Language models produce fluent wrong answers. The right claim is narrower: the numbers are deterministic, the sources are named, and material answers are verified by the person acting on them.

Our answers, including the uncomfortable ones

The same questions, answered for Vidyapeeth360 — with the boundaries stated as boundaries.

Aira reads through the same permission checks as the person asking, re-resolved on every request, and stays inside that school's own data. Every model call goes through a single funnel that pattern-redacts common identifiers before the text leaves the process; name removal depends on the calling flow supplying the known values, and permissions and the source records — not the redactor — remain the authoritative boundary. That is a narrower claim than "everything is anonymised", and it is the accurate one.

Health, infirmary, wellbeing and counselling sources are excluded from the student-AI surface. Writes are proposed and confirmed by a person; nothing is committed on the assistant's own authority. Numbers stay deterministic — fee, attendance and result figures come from the same code paths that produce the reports, and the assistant writes the explanation around them.

For reporting questions, the model never writes or runs a query: it selects one report from a fixed catalogue, the vetted parameterised query runs scoped to the school, and the narration is generated over an aggregate summary with identifying columns dropped — so the full result, with names, reaches the administrator's browser and not the model. Parent Aira resolves only the children on the asking account. Usage is metered as credits with the consumption visible, and the whole assistant follows plan availability, off until a school enables it.

What we do not claim: that a model is accurate, that redaction is universal across every conceivable call path, or that any of this substitutes for your own review. The design principle is simply that the assistant can only reach what you can already reach — which is why the access model matters more than the assistant, and why reports and Aira share one permission story rather than two.