On-device AI, Apple Intelligence and the data-never-leaves advantage

Short answer: the privacy advantage of on-device AI does not rest on a vendor's promise. It is structural — the data never left the device, so there is nothing to retain or leak. The price is a capability ceiling. A school can apply the same principle at scale: Edor.ai supports on-premises deployment, keeping data inside the campus network.

It starts with a question at parents' evening

At the November parents' evening, a parent raised a hand: "My daughter's iPad has a feature that rewrites her English sentences. I would like to know whether what she writes gets sent to the United States."

The teacher taking questions could not answer. It is an excellent question, and the answer has changed in recent years: some features genuinely run entirely on the device and send not one character anywhere; others do send data out, but to a specially designed server. Parents are entitled to know which is which, and a school should be able to say.

Developing photographs at home

The closest analogy is photographic developing.

• Cloud AI is posting the film to a processing shop. The shop has better technique, more expensive machines and usually the best results. But your photographs left your hands, travelled through the post, passed a member of staff, and sat on the shop's machines for a while. You have to trust that whole chain.
• On-device AI is developing in a darkroom at home. Smaller kit, less professional chemistry, and enlargements that will not match a specialist. But from start to finish, the photographs never left the house.

Note what matters about the second: you do not have to trust anybody. It is not that the shop promised not to look at your pictures; the pictures never went out of the door. That kind of protection is structural, and it is more dependable than any privacy policy clause, because it does not rely on someone keeping a promise.

The three tiers Apple Intelligence demonstrates

Apple's approach is worth understanding, not for the brand but because it lays the trade-off out in three explicit tiers:

1. On-device processing. Rewriting text, summarising, tidying notifications and similar work is handled by a small model on the device, and the data stays on the phone or tablet.
2. Private Cloud Compute. When a task exceeds what the device can do, the request goes to servers Apple designed for the purpose. Apple's published material states that these servers do not retain user data and provides a mechanism for independent researchers to inspect the claim.
3. External models. Requests beyond that go to a third-party model, and the system asks the user first.

The useful part for a school is not Apple but the tiered way of thinking: ask first how far this task minimally requires the data to travel, keep it on the device when you can, and when it must travel, send it somewhere controlled. That is exactly the question a school data policy should be built around.

The capability ceiling, stated plainly

Do not romanticise on-device AI. It has three hard limits that are not disappearing soon:

• The model is small. Devices generally run models under a few billion parameters (lesson 13 covers small models) and heavily quantised (lesson 21). Rewriting a sentence or summarising a short passage 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 read a whole curriculum document.
• It does not know your school. A device model has none of your school-based curriculum, marking conventions or circular formats. Giving it those requires retrieval (lesson 15), and that requires a platform.

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

An example from the classroom

While reviewing its bring-your-own-device policy, a direct subsidy secondary school did a very simple sorting exercise. They put every AI feature students might touch into three columns:

The valuable part of the table is not the conclusions but the middle column. Once a school gets into the habit of asking where the data goes first, most policy arguments resolve themselves. This table was later attached to a circular for parents, and it answered the question from the opening of this lesson.

What this means for your classroom

1. "Where does the data go" is a teachable lesson. It is far more useful than reciting privacy legislation. Having students fill in the table above for the apps they actually use makes a strong information literacy period.
2. Do not assume a built-in feature is school-approved. The student handbook should say which are on, which are off and why. Without that, enforcement becomes individual teachers' guesswork.
3. On-device suits light tasks, not assessment. Rewriting a sentence or checking vocabulary is fine; writing feedback, marking or anything touching personal data belongs back on a gated, logged platform.
4. Privacy is a set of habits, not a technology. Keeping data on the device solves one link. A visible screen, a borrowed device or a shared account are risks all the same.

How this works inside Edor.ai

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

Concretely: 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 own domain. Combined with the local Ollama provider, inference for selected modules happens entirely on campus, so what students type does not need to leave the campus network. 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.

Three qualifications, so that on-premises does not sound too perfect. First, on-premises is not automatically secure: backup, updates and access control become the school's responsibility, and four-layer gating and the ai_audit_logs audit trail still need to be switched on. Second, the cloud version's protections are equally concrete: personal-data fields encrypted at rest, purging on the school's retention schedule, and APIs used under no-training terms. Third, data ownership is identical either way: the data belongs to the school, with a free one-click full export (JSON, CSV or original files) and no lock-in.

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

In summary

On-device AI hands schools a useful thinking frame: ask first how far the data minimally has to travel. When the answer is "it does not", that is the cleanest protection available. When the answer is "it does", ask where to, for how long, who can see it, and whether the school can get it back.

The next lesson takes the other half of the problem — once data stays on campus, how do you make sure what the AI says is safe for students: AI guardrails. The previous lesson is running models in school.