School AI On-Premises or Cloud: Separate Deployment from Data Control

A direct-subsidy secondary school's IT coordinator briefs the principal on Tuesday evening: "The sponsoring body asked where our AI platform lives. I said the data always belongs to us — on-premises or Hong Kong cloud, we can export everything. The real question is whether anyone will answer the backup alert on Sunday."

Deployment answers "where the server sits". Data control answers "who decides and whether we can take it with us". Treat them separately or a school buys technology preference when it meant to fix a principle.

Two different layers

Deployment is whether the server sits in the school server room, a sponsoring body's private cloud, or the vendor's cloud (Hong Kong region available).

Data control is what the contract says about ownership, whether an administrator can export everything in one click at any time, and how deletion and migration work at termination.

A qualified platform decouples them: wherever it runs, data belongs to the school; wherever it runs, administrators should download JSON / CSV / original files in one click, no request, no fee.

The on-premises side

Who it suits

Schools with dedicated IT staff comfortable with Docker or Linux server maintenance; sponsoring bodies with an existing private cloud or data centre requiring unified hosting; data policies that state platform and school data must not leave the campus network.

Costs beyond the hardware

Upfront spend on server, network and installation; day-to-day backups, system updates, monitoring and capacity planning sit with school IT. Updates are slower — new features need scheduled installs rather than automatic cloud pushes.

Model calls remain a reality: unless you run local models through Ollama, chat still reaches cloud APIs. On-premises governs where the Edor.ai platform and school data reside, not an automatic end to all outbound inference.

Scaling is hardware-bound; compliance evidence (PDPO mapping, architecture diagrams) is largely assembled by the school. The vendor should supply a one-command update script and remote support — otherwise in two years you inherit "the old server nobody dares touch". Edor.ai supports cloud or on-premises private deployment with identical features and the school's own domain.

The cloud side

Who it suits

Limited IT staff who want "create accounts and go"; priority on continuous features and model updates; comfort with data in a Hong Kong-region cloud protected by contract, encryption and role-based access.

Upfront cost is near zero; maintenance, backups and monitoring are the vendor's job; updates are automatic and continuous. Scaling is elastic; vendors usually supply architecture notes and PDPO mapping, saving IT time on compliance packs.

Four lines the contract must nail

Cloud autonomy is not "whose server room" but whether the contract states:

• Data belongs to the school; the vendor may not repurpose it or use it for model training;
• Administrators get one-click full export, identical for cloud and on-premises;
• Termination includes assisted migration and deletion on clear timelines;
• Custom domain support: ai.school.edu.hk → CNAME → vendor server, TLS issued and renewed automatically.

With those four, cloud and on-premises are equal on whether you can take the data away.

A confident vendor writes "you can leave at any time" into the contract. Schools should stay because the product is good, not because the data is held hostage.

Five safeguards both sides need

Regardless of on-premises or cloud:

1. Personal-data fields encrypted at rest; API calls under no-training terms;
2. Role-based access and audit logs (including ai_audit_logs);
3. Retention policy — conversations and AI records purged after configured days;
4. One-click full export (JSON / CSV / original files), no request, no fee;
5. School custom domain so pupils and parents always see the school URL.

Add one practical item: four-layer gating, teacher monitoring and PII protection in student-facing use should not change with deployment — see student AI safety and security and data protection.

Three questions to decide

1. Will anyone answer the backup alert on Sunday? No → cloud is the realistic choice.
2. Does data policy forbid leaving the campus network? Yes → on-premises (or private cloud).
3. Either works? → Compare two-year total cost including IT staff time, and verify export, custom domain and termination migration clauses word-for-word for both deployment types.

Common misreadings

• The claim: On-premises means pupil conversations and model inference never leave the campus network. What actually happens: Unless you run local models such as Ollama, chat APIs may still reach the cloud. On-premises mainly governs where the platform and school data sit, not an automatic cut of every outbound connection.

• The claim: Cloud means the vendor holds the data and the school cannot get it back. What actually happens: That is a contract problem, not a deployment problem. Both options should offer one-click full export and termination migration terms.

• The claim: A custom domain is cosmetic and unrelated to security. What actually happens: A single ai.school.edu.hk address reduces phishing risk, helps parents recognise the school, and after one CNAME setup certificates renew automatically with manageable IT effort.

Three things to try on Monday

1. Ask your current or candidate vendor for the contract clauses on data ownership, one-click export and termination deletion — highlight whether JSON / CSV / original files are named, free and available without a ticket.
2. Have IT draft a CNAME worksheet: subdomain ai. + school domain → vendor host, and estimate working days from request to teachers logging in.
3. Align two sentences with the principal first: "Data belongs to the school and can leave in full at any time" before "on-premises or cloud" — then discuss IT capacity and budget.