A state-wide view of every school means a state-wide record of children: their attendance, their faces, their learning and their risk of dropping out. We think the safeguards for that record are the first design decision, not the last.
Most conversations about school monitoring begin with the screens: the minister’s delivery score, the district heat-map, the parent digest. They should begin somewhere else. Every one of those screens is built from data about children, and some of it, like faces on a camera or a dropout-risk flag, is about as sensitive as data gets. A system that is careless with it can do harm that no improvement in attendance figures will offset.
Privacy commitments often live in a policy document or a slide. Those are useful, but they rely on everyone following them every day. Our position is that the important safeguards should be properties of how the system is built, so that breaking them takes deliberate effort rather than a moment’s carelessness. They should also be written into the contract and checked from outside.
These are the safeguards EduWatch is built around. We list them because we think any buyer should expect something like them from any vendor:
| Safeguard | What it means in practice |
|---|---|
| Data stays in India | On government-empanelled servers; nothing leaves the country |
| Consent, no ads, no profiling | Parental consent is built in; learners’ data is never sold or used to target |
| Faces never leave the school | Face matching happens on site; images are blurred before anything is uploaded |
| Every access logged | Who looked at what, and when, open to external audit every year |
| The government owns the data | Open formats, export at any time, no lock-in |
| Names tokenised | Learner IDs are tokenised in logs; no personal data in plain text |
Cameras are the part of school monitoring that worries people most, and rightly. Kitchen cameras checking hygiene and weighing, or a camera scoring meal portions, look at food. Attendance by face looks at children. The difference between “a camera that recognises a child at the gate” and “a central database of children’s faces” is entirely an architecture choice. Matching on site and blurring before upload means the central system does not need to hold children’s faces to know who was present.
It is also worth noting that face is one option, not a requirement. EduWatch supports face, RFID or voice for attendance, so a department can choose what fits its policy and its community.
Data about a child can trigger consequences for that child. EduWatch’s discipline ladder needs human sign-off, and the system keeps an AI model registry. We would argue every education system should draw that line clearly: software can flag, rank and summarise, but decisions that affect an individual child should be made and owned by a person. A dropout-risk flag, for example, is a prompt for a teacher or a counsellor to talk to a family, not a label to be attached to a child’s record and forgotten.
The legal requirements that apply to your department are for your legal and data-protection advisers to confirm; these questions are about whether the system is built to meet them. For how the rest of the platform works, see our guide to a school monitoring system for education departments and the dropout early warning playbook, which uses some of the most sensitive data of all. More on the EduWatch guides page.
No. Face matching happens on site at the school, and images are blurred before anything is uploaded. Face is also optional; attendance can use RFID or voice.
The government. Data is kept in open formats, can be exported at any time and stays on government-empanelled servers in India.
The safeguards are designed to support them, but which laws and rules apply to your department should be confirmed with your legal and data-protection advisers.
See it on your own data. EduWatch — Every school on one screen. Book a 30-minute working session with an engineer.
