Where the data sits, who can take it, what gets logged
Principles are cheap with education data. This page lists the actual implementation at the architecture, process and contract level, so an IT coordinator can tick it off line by line.
- 01
Inbound
What the student typed is read first — inappropriate requests, personal data and jailbreak attempts stop here, with a lower threshold in student mode.
- 02
System instruction
School policy, age band, subject context and the no-answers rule go into every call, rather than being left as a reminder to the student.
- 03
Outbound
The reply is classified again; anything questionable is masked and queued for an administrator to review.
- 04
Audit
Every call records module, model, usage and gate action; quotas are set per role and per user.
Accounts and access
- One sign-in entry, JWT with HttpOnly cookies, forced password change on first login
- Six roles (principal / admin / panel head / class teacher / subject teacher / student), then narrowed by subject and class
- Logins, exports, setting changes and account management all written to the audit log
- Optional IP range and time-window restrictions
Data protection
- Personal data fields (phone, student ID, guardian contact, SEN notes) stored with AES-256 encryption
- API keys and integration credentials encrypted; only the last four characters are shown
- Retention is configurable: conversations and AI logs are purged when they expire
- TLS 1.2 or above in transit; database and file volumes separated from other schools
AI usage policy
- Student data is not used to train any model; no-training terms are selected with every provider
- System instructions forbid the model from requesting or emitting student personal data
- Four gates: inbound detection, system instruction, outbound classification, audit and quotas
- Flagged content enters an administrator review queue; strict mode is available
The school holds the data
- Knowledge base, resources, rubrics, curriculum and student records export in bulk (JSON / CSV / original files)
- AI providers are interchangeable (OpenAI / Azure OpenAI / Anthropic / Poe / local Ollama)
- Migration assistance and a deletion certificate at contract end
- A line-by-line mapping to the six Data Protection Principles of the Hong Kong PDPO
Ownership and portability
- The data belongs to the school — on a school server or in the cloud, this does not change
- Administrators can download everything at any time (/api/school/export/all): free, unlimited, no request needed
- A school may take its data and move to another provider at any time, without giving a reason
- Your own domain is supported (e.g. ai.yourschool.edu.hk), with the school crest and name on the login page
- On-premises: installed on a school server or private cloud; data does not leave the school network
The data belongs to the school, and it is in the contract
These four are contract clauses, not marketing lines, and they apply the same on-premises and in the cloud. The exit has to be wide before a school can reasonably put its own knowledge in.
01Ownership
Plans, resources, the knowledge base, assessments, student records and school analytics — intellectual property and ownership rest with the school. Edor.ai acts as data processor on the school's instructions.
02Download
One click in the admin panel exports everything: one JSON per table, resources and the knowledge base as Markdown, original files attached as they are. Free, unlimited, no request needed.
03Leaving
A school may take its data to another provider at any time without giving a reason. At contract end we assist the migration and provide a deletion certificate.
04Front door
Reach the system on the school's own domain (e.g. ai.yourschool.edu.hk) with a single CNAME record; the login page carries the school crest and name.
ai.yourschool.edu.hk CNAME edor.aiHow A1–A5 are implemented
The Part 1 technical requirements typical of Hong Kong school AI platform tenders.
| Ref | Requirement | Edor.ai implementation |
|---|---|---|
| A(1) | Unified login and access management | Single entry, role permissions, audit logs, forced password change, session control |
| A(2) | Data security and privacy | Personal data encryption, TLS, retention, PDPO mapping, no-training terms |
| A(3) | School data governance and knowledge base | Knowledge base with RAG, bulk export (free and any time, on-premises or cloud), school ownership, free provider switching, own domain |
| A(4) | LLM compliance and safety | Provider abstraction layer, switchable, quotas, AI audit logs |
| A(5) | AI ethics and content gating | Four gates, student mode, human review of flagged content, guided tutor |
Privacy policy and terms summary
Edor.ai collects only what the service needs: staff and student account data supplied by the school, platform usage records, and content users enter. It is used to deliver and improve the service, keep it safe and fulfil the contract — never sold, never used to train AI models. The school is the data user; Edor.ai is the data processor acting on the school's instructions.
Contact-form data on this site is used only to answer the enquiry. The full privacy policy and terms come with the contract; enquiries: info@edor.ai。
See it once, then decide whether it goes in the proposal
Thirty minutes, run live on your school's subjects and grades.