On-device AI, Apple Intelligence and where data goes

At the November parents' evening, a Primary 6 parent raised her hand: "That feature on my daughter's iPad that rewrites English sentences — does what she types get sent to the United States?" The English panel deputy paused for three seconds, opened Settings on her phone, and realised she was not sure either — a question schools should be ready to answer before anyone asks it in public.

The privacy advantage of on-device AI does not rest on a vendor's promise. The data never left the device. This is the foundation lesson in the local deployment module, following the campus server in lesson 22; the next lesson turns to what the AI is allowed to say.

---

The drawer, the records office and the relay

Imagine a sentence a student has written as a draft on paper.

Cloud AI is sending that draft to an off-site records office for retyping. The machines are fast, the layout is polished, and long documents usually look best — but the draft left your drawer, travelled through a link, passed someone else's system, and sat on their server for a while. You trust the whole chain.

On-device AI is editing inside your own desk drawer. Smaller equipment, weaker on long text, and struggling with complex tasks — but from first word to last, the draft never left that iPad or MacBook.

What matters is not that the records office promised not to look. It is that the draft never went out the door. That protection is structural, and it is harder than a privacy-policy clause because it does not depend on anyone keeping a promise.

Apple's three tiers

Apple Intelligence lays the trade-off out in three tiers. A school does not need to marry the brand, but it should borrow the question:

1. On-device processing. Rewriting a sentence, tidying notifications, short summaries — handled by a small model on the device, data stays on the phone or tablet.
2. Private Cloud Compute. When the task exceeds the device, the request goes to servers Apple built for the purpose. Published material states that user data is not retained and provides a mechanism for independent researchers to inspect the claim.
3. External models. Requests beyond that go to a third party, and the system asks the user first.

A school data policy can follow the same order: ask first how far this task minimally requires the data to travel — keep it on the device when you can, send it to a controlled node when you must, and beyond that require explicit consent and a stated purpose.

The capability ceiling

On-device AI has three hard limits that are not disappearing soon:

• The model is small. Devices generally run models under a few billion parameters (lesson 13) and heavily quantised (lesson 21). Rewriting one English sentence is fine; designing a full inquiry activity is a struggle.
• Memory is short. There is a hard limit on how much text it can hold at once, so it cannot swallow a whole curriculum document.
• It does not know your school. A device model has none of your marking conventions, circular formats or past papers. Giving it those requires retrieval (lesson 15), and that requires a platform.

One further limit schools care about especially: no teacher monitoring. Built-in device features do not show student conversations to a class teacher and produce no audit trail. For student-facing use, that gap is often decisive.

On-device protection answers whether data left the building, not whether the content was right or whether anyone was watching — those still need a platform and school rules.

A school sorting exercise

While reviewing its bring-your-own-device policy, a direct subsidy secondary school ran a simple sort. Every AI feature students might touch went into three columns: feature name → where the data goes → school decision.

Built-in text rewriting on the device: data stays on the device, allowed, with the handbook stating this is not ghost-writing. Built-in cloud assistant: data sent to the vendor, blocked on the campus network, reason explained to parents. The school Edor.ai tutor: inference on the campus server, allowed, with gating, teacher monitoring and a record. Chat apps students install themselves: destination unknown, blocked on campus, covered in academic integrity guidance.

The list was later attached to a circular for parents and answered the question from the opening of this lesson. The valuable part was not the conclusions but the habit of asking where the data goes first. Once that question becomes reflex, most policy arguments close themselves.

From the list to the classroom

The school turned the list into a Secondary 2 information literacy activity: each student named three apps they actually use, filled in where the data goes, and discussed in groups whether a teacher should accept AI output in assessment if the data went to an unknown server. One forty-five-minute period did more than reciting legislation.

The same principle at campus scale

The core of on-device AI is that data does not leave the device. The whole-school version is that data does not leave the campus network — and that is why Edor.ai supports on-premises deployment.

A school can deploy the whole platform on its own server or private cloud, with features identical to the cloud version and access through the school's domain. Combined with the local Ollama provider, inference for selected modules happens entirely on campus. For schools whose data policy states in writing that data must not leave the school, this is not a bonus feature but the precondition for using anything at all.

Qualifications matter too. On-premises is not automatically secure: backup, updates and access control become the school's responsibility, and four-layer gating and ai_audit_logs still need to be on. The cloud version's personal-data fields are equally encrypted at rest, purged on the school's retention schedule, and called under no-training API terms. Data ownership is identical either way: it belongs to the school, with a one-click export to JSON, CSV or original files.

Further reading: on-premises versus cloud deployment, the student AI safety net, and the platform's security and privacy page.

Where people go wrong

• Treating a built-in feature as school-approved. Without a handbook that says which are on and which are off, enforcement becomes each teacher's guess. Self-check: open your current handbook — can you find, in under two minutes, a plain sentence on whether the iPad's built-in rewrite feature may be used for assessed work?
• Assuming on-device is enough for marking and personal data. Rewriting a sentence or checking vocabulary is fine; writing feedback, marking scripts or handling SEN notes belongs back on a gated, logged platform. Self-check: will this output enter a formal student record? If yes, a device tool alone should not finish the job.
• Talking only about privacy, not visibility. Data may stay on the device, but the screen can still be seen by a classmate and the device can still be borrowed. Self-check: does your classroom teach concrete habits like covering personal details before using AI rewrite in a public space?

Try it once

What to do: Take an iPad or Mac the school actually uses (or your own Apple device), open one built-in AI feature such as sentence rewriting, and enter a test sentence with no personal data. On a second device, repeat the test in aeroplane mode and note whether the feature still works.

What to hand in: A three-column note — handwritten or in a spreadsheet: feature name, works with network, works in aeroplane mode — plus one sentence on where you think the data travels.

How you know it worked: You can explain the data path to a parent in two minutes. If it works in aeroplane mode, classify it as on-device or hybrid. If it does not, classify it as cloud-dependent and recommend checking the vendor's documentation. When unsure, write "pending IT confirmation" — that is better than pretending to know.