The most important part of Siri AI shipped two years before Siri AI. Private Cloud Compute was announced in 2024, opened to outside researchers that October, and carried real Apple Intelligence traffic in the meantime. By the time the new assistant arrived, the hard parts of the cloud tier, including attestation, transparency, and the research tooling, had already been picked at by people paid to break them.
Apple spent this year doing the unfashionable version of the same job. Siri AI entered public beta on September 14, in English first, after a long and very public delay. The assistant is a stack, not a feature. Work is split between the device and the cloud, Apple brought in a partner for the one layer where it was behind, privacy is built into the servers, and much of the plumbing was laid years before the headline. You can argue about the product. The engineering choices travel well beyond consumer devices.
First, the cost of doing it this way
The same constraint applies to the people building your system. If engineers can only iterate in the cloud, they’ll test prompts, compare models, and tune fallbacks against cloud behavior, and the local path will be the least exercised code you ship. Give the team machines, on their desks or on-premises, that can run the small models you plan to deploy. Otherwise you’ll end up shipping a cloud system with a local story.
Apple designs its own chips, operating systems, and servers, and it still went to Google for Siri AI’s models, which Apple describes as built in collaboration with Google and its Gemini models. According to post-WWDC reporting, it also extended Private Cloud Compute onto Google Cloud, running the heaviest tier on NVIDIA GPUs with confidential computing.
1. Stop sending every request to a frontier model
For a company known for vertical integration, that’s an awkward admission. For a company that needed to ship, it was the obvious call. Apple rented the intelligence and part of the hardware. It kept the device integration, the routing logic, and the trust layer, which happen to be the parts customers actually experience. Most engineering teams face a smaller version of this decision every quarter, and plenty of them make it the other way around. They hand the user experience to a vendor’s widget and then spend months trying to train their own base model.
There are plain engineering reasons for this. A local call costs less, returns its first token sooner, and still works when the user is on hotel Wi-Fi. It also means the sensitive material, whether that’s the message being summarized, the calendar entry, or the half-written document, stays on a device the user already owns. Apple saves the cloud for requests that really need it, like long context or heavy reasoning.
Those costs are real. Apple lost a year of headlines to competitors and left customers in major markets waiting. I’m not arguing that Apple avoided any of that. I’m arguing that the architecture it shipped is the right one, and that most teams can build the same thing without the same delay if they do the work in the right order.
A hybrid architecture only works if the local side can run. Apple’s most capable on-device model needs an M3 Mac or later with at least 12GB of unified memory. Machines below that line still get Siri AI, but they run only the standard on-device model and lose the features tied to the larger one. The product steps down a tier rather than disappearing.
That design is also what made the Google Cloud move possible. Trust rests on attestation and software that outsiders can inspect, not on Apple owning the building, so Apple can run on someone else’s hardware and keep making the same claim. Policy is what you tell customers. Architecture is what is still true when nobody is watching.
2. Own the product. Rent the model if you have to.
After that, watch how often escalation happens. If it’s 80 percent of traffic, you’ve built an expensive way to call the frontier model. If it’s 2 percent and eval quality holds, you’ve probably found most of your inference budget.
You don’t need Apple’s hardware to hold yourself to the same standard. A design review for any AI service that touches customer or employee data should be able to answer four questions. What leaves the user’s environment, field by field? Is any of it kept, including in logs, traces, and on the vendor’s side, and for how long? Can someone independent check those answers through an audit, a published configuration, an attestation, or a contract term you could actually enforce? And do the answers still hold if you switch providers? If the honest reply to the third question is “trust us,” the system isn’t finished.
The better split is to own your data, your integrations, your eval set, and your interface, since a competitor can’t lift any of those from an API reference. Keeping the model itself swappable mostly comes down to where three things live. Prompts and templates belong in your repository, versioned like code. Tool and output schemas should be defined once on your side, with a thin adapter for each provider. And the eval suite needs to be rerun against every candidate model, because two models with identical APIs can still behave very differently on your data. A vendor you can’t leave is a migration you’ll end up doing later, with less leverage.
3. Make privacy a property of the system, not a paragraph in the FAQ
This is not a story about flawless execution. Apple promised a smarter Siri in 2024 and missed. As late as February, reports had Gemini-powered Siri features slipping past iOS 26.4. What finally shipped is labeled beta, and it did not launch on iPhone or iPad in the EU, with China on hold pending regulatory approval.
Apple did the same thing with hardware this month. It announced its first touchscreen MacBook Pro on October 28, but the software had been on Macs since June. As MacPaw’s look at the touchscreen hints in macOS Golden Gate showed, the release added finger control through Sidecar and touch-aware interface elements. Developers also found new APIs that let apps tell touch from mouse input, which Apple’s documentation says aren’t only for Sidecar. App makers could start adapting months before anyone could buy the hardware.
Most AI rollouts fail in the same boring way. A chatbot gets bolted onto the product, pointed at one cloud model, and shipped because leadership wanted something to point at. Privacy, cost, latency, and what happens when the model is wrong all get a ticket labeled “later.”
4. Ship the foundation while the headline is still a rumor
Siri AI does not treat the data center as the default. Reporting from WWDC describes three tiers. Simple requests run on the device using Apple’s own foundation models. Moderately complex ones go to Private Cloud Compute, and the heaviest work goes to a larger cloud model inside the same protected environment.
By Glenn Blake
Most internal AI systems do the opposite. Someone wires every classification, summary, and field extraction to the biggest model on the contract, and a quarter later finance wants to know why the bill tracks the latency graph so closely. What you want instead is a router, and the first version can be crude. Send everything to a small model first, local or hosted. Then write down when a request gets kicked upstairs: the output failed schema validation, the input was longer than the small model can take, a self-check score came back under a threshold you tuned against your eval set, or it’s a task you already know the small model botches.
Developer hardware is part of the stack
Most AI teams skip this step. They polish the demo and leave the APIs, data pipelines, eval harnesses, and fallbacks as cleanup. Do it the other way around. Put the unglamorous pieces behind a feature you already support and let real traffic knock them around. Then when the flagship ships, you don’t spend week one finding out that the retrieval path is wrong, the eval set measures nothing useful, and nobody decided what happens when the model declines the request.
Apple’s AI year is easy to read as a feature launch, and easy to criticize as a late one. I think it’s better read as an argument about sequencing. Make the expensive model the exception. Rent the layer that doesn’t set you apart, and keep switching cheap. Make your privacy claims something outsiders can check. Build the boring path first, then put the headline on top of something that already works.
The takeaway
Apple’s claim for Private Cloud Compute is unusually specific: personal data sent with a request is “not stored nor made accessible to Apple or anyone else.” It also doesn’t ask you to take that on faith. Since 2024, Apple has published a security guide, source code for key components, and a Virtual Research Environment. Anyone can use it to list PCC software releases, check them against a transparency log, boot them in a virtual machine, and look for flaws, with bug bounties of up to million for what they find.
Some rough, made-up numbers show why that rate matters so much. Say the small model costs one-twentieth as much per request and does an acceptable job on 85 percent of traffic. Every request pays the small-model price and 15 percent also pay the frontier price, so you end up near 20 percent of what an all-frontier setup would cost. Your ratios won’t match these. What carries over is that the escalation rate moves the total far more than the frontier model’s list price does. If you can’t say which tasks actually need a giant model, you aren’t doing model selection. You’re doing hope.
None of that requires Apple’s budget, and if you do it in the right order, none of it requires Apple’s delay either. It does require refusing to treat the demo as the architecture.
