Apple Intelligence is AI built into iPhone, iPad and Mac. Its distinguishing choice is running as much as possible on the device itself, with a privacy architecture for what cannot.
Apple Intelligence is a set of AI features woven into Apple's operating systems rather than a separate app. Writing assistance, notification summaries, image generation, and a substantially more capable Siri.
The design principle is that most processing happens on the device, so data does not leave it.
The genuinely useful features are the quiet ones: summarising long notification stacks, proofreading and rewriting text in any app, finding photos by description, and removing objects from images.
These are small time savings that occur many times a day, which is a different value proposition from a chatbot you visit deliberately.
Apple Intelligence is not a general-purpose assistant in the way ChatGPT or Claude are. It will not write you a long analysis or work through a complex problem.
For those tasks it can hand off to an external model, but the built-in capability is deliberately narrower.
Requests too large for the device go to Apple servers running on Apple silicon, under an architecture Apple calls Private Cloud Compute.
The claims are that data is used only to fulfil the request, is not stored, and that the server software is independently verifiable. Apple publishes the images for security researchers to inspect, which is unusual and meaningfully stronger than a policy promise alone.
On-device models are small by necessity — memory and battery impose hard limits. That is why capability is narrower than a frontier assistant, not a product decision that could simply be reversed.
The trade is real: privacy and latency in exchange for capability. Which matters more depends entirely on the task.
Apple exposes on-device model access to apps, meaning third-party developers can use the same local models without sending data anywhere or paying per token.
For app developers with privacy-sensitive features or high request volume, this is a genuinely different cost and compliance profile from calling an API.
Apple Intelligence is a reason to own recent Apple hardware rather than a product sold separately. That shapes what it is optimised for.
It also means feature availability depends on device generation and region, and rollout has been staged rather than simultaneous.
Apple's architecture is stronger than most on privacy, and it is still worth reading precisely what is claimed. On-device processing genuinely does not transmit data. Private Cloud Compute does transmit, under stated constraints with verification mechanisms.
Third-party handoff to an external assistant is a separate decision with separate terms, and is prompted rather than automatic.
Model choice is a routing decision rather than a ranking one, and the useful question is which part of your traffic this is right for.
Route by task, not by preference. Most requests in most applications are not hard. Classification, extraction and formatting rarely need the most capable available option, and sending everything to the top tier is the largest and most common overspend.
Test on your own evaluation set, not on published benchmarks. A benchmark measures a task that is not yours, and the ordering between models frequently reverses on specific work.
Weigh the things that are not capability. Where the data goes and under whose terms. Latency at your percentile, not the average. Whether the model can change underneath you, and whether that matters for reproducibility. Rate limits at your peak rather than your mean.
Assume you will move. Keep the provider behind an interface, keep prompts in version control, and keep an evaluation set that runs against any of them. The cost of switching is paid once at design time or repeatedly afterwards.
And re-check on a schedule. This ordering changes faster than any procurement cycle, so a decision made a year ago and never revisited is a decision that has quietly expired.
Most tool decisions are made on capability and lost on adoption. The pattern is consistent enough to plan around.
Name an owner. Not a committee and not "the team" — one person responsible for the configuration, the questions, and whether it is still earning its licence in six months. Tools without an owner decay into a subscription nobody cancels.
Start with one workflow, not the whole team. A narrow deployment that works spreads on its own; a broad one that half-works produces a reputation the tool never recovers from.
Write down what it is not for. The boundary matters more than the capability, because the damage comes from use outside the intended case — and nobody is told where that edge is unless someone writes it down.
Keep the manual path working. For at least one cycle. A team that cannot fall back is a team that cannot report a problem honestly.
Review it on a date you set in advance. Three months, against the criteria you wrote at the start. A tool nobody has reviewed is a tool nobody has decided to keep — and the review is the only thing that ever removes one.
Opens your assistant with this page as the source, and a question rather than a summary. It will ask what you are building before it answers.
Nothing is sent from here. The link carries only this page’s title and address.