Apple Stopped Building Its Own AI and Took It from Google. The Build vs Buy Lesson Most CTOs Would Rather Not Hear
For years Apple built its story around a simple idea: we control everything. The chip, the operating system, the screen, the store, even the way the product reaches the customer. Then, at yesterday's WWDC keynote, the most integrated company in the industry confirmed a choice that would have sounded almost out of character not long ago: for a central part of its artificial intelligence, it will use models built by someone else.
This is not hearsay and it is not a reading between the lines. The new generation of Apple Foundation Models, the one powering the new Apple Intelligence and the new assistant, is based on Google's Gemini models. Apple also evaluated OpenAI and Anthropic, then decided to integrate external technology instead of building everything internally. And it did so while having more money, talent and infrastructure than almost anyone else in the market.
If you are a CTO or a founder and you have a "do we build our own model or integrate an existing one?" decision on the table, this is not just tech news. It is a huge, very public case study, and a useful one to bring into your next budget meeting.
What actually happened, no speculation
Let's start with the facts, because some people are still talking about this as if it were only a hypothesis. The Apple-Google partnership was announced earlier this year; yesterday it became a product. The new Apple Foundation Models are based on Gemini, they run partly on-device and partly on Apple's servers through Private Cloud Compute, and Apple has adapted them so deeply that the Gemini name does not appear in the interface. At the centre there is also an orchestration system that understands which app you are using and decides which tool should be involved.
The interesting part is not only technical. It is strategic. The company that can afford almost any investment concluded, after what it called a "careful evaluation", that the most sensible choice was to use technology from a direct competitor. The official explanation is restrained: Google offered the best foundation for their models. Put less diplomatically, building a frontier model alone, on an acceptable timeline, was a fight even Apple chose not to take.
The paradox you should care about
This is where the useful part begins. For fifteen years Apple's message was: total control is a competitive advantage. Yesterday the same brand showed, at the largest possible scale, that you can control the experience without necessarily owning the model that powers it.
This is a distinction we often try to help clients see, and it is not always pleasant to hear. A founder once asked us to build "his own proprietary AI". Our first question was: proprietary in what sense, the model or the problem you want to solve? Those are two very different things, and confusing them makes you spend a fortune on the wrong piece.
When someone tells us "I want to control everything", the first question should not be "which model do we use?". It should be: which piece would really hurt if you lost it tomorrow? The answer is almost never the model. More often it is the data, the workflows, the business rules and the point where you decide what enters the system and what comes out. Apple effectively answered the same question and concluded that the model was not the piece to own at any cost.
Where control actually lives
We once spent an entire afternoon convincing a CTO not to train a model from scratch. He wanted independence, and for him independence meant owning the network's weights. The point is that, in many projects, independence does not live there. It lives in the orchestration layer that decides what goes in and what comes out, handles alternatives when a service does not respond, cleans inputs and holds the system together. That is the part you truly govern. That is the part nobody can change under your feet.
We do not believe that "built in-house" automatically means "under control", and we prefer to say that before a project starts. The code that matters is often the code connecting your domain to the model: rules, data, checks, permissions, formats and exceptions. Confusing that layer with the model underneath is the most expensive way we know to feel safe. You spend months training something that will age in a quarter, and meanwhile you leave the surrounding integration fragile. That is a bad trade.
Apple put an orchestrator at the centre of its architecture for this exact reason. The defensible value is not the model itself, since the foundation comes from Google. The value is the layer that routes requests, decides what to use, protects privacy and keeps the experience coherent across every device.
This is the same reason why, when we build AI agents for a company, we design them to be model-agnostic. An agent should not depend forever on a single provider, nor should it use the same model for every task just because that is the one already integrated. In a real workflow, it can make sense to use different models: one better suited to reasoning over long documents, one faster for classifying simple requests, one more precise when generating code or analysing structured data. The value is not in picking a name and staying loyal to it. The value is in building a system that can use the right tool at the right point.
The integration is the part that breaks
We saw a project fail because the client was focused almost entirely on owning the model and had neglected the weakest point: the data coming in. The data was messy, inconsistent and full of unmanaged exceptions. The model was good, but the architecture around it could not hold. The project failed anyway, not because the model was weak, but because the most important work had been done in the wrong place.
That is the risk you run when the pride of "we built it ourselves" comes before system engineering. A model, however good, is not enough on its own. It is only as useful as the layer that decides which information it receives and what happens after the response. Apple understood this and invested its work there: in orchestration and Private Cloud Compute, not in training a direct rival to Gemini.
The question that changes the decision
The question we ask before any AI integration is not "on-device or cloud?". It is: what happens the day the provider changes pricing, licence or terms? If you do not have an answer designed in advance, you do not really have an architecture. You have a dependency with a nice interface on top.
Apple moved very carefully on this exact point. It structured the deal as non-exclusive. In practice, it kept open the option to switch or add providers, and it also keeps the OpenAI integration available for certain requests. This is not just a legal detail. It is a way to design the dependency instead of suffering it later. The question "what if Google raises the price or changes the terms tomorrow?" was asked before signing, not after.
This is the difference between buying technology while knowing what you are doing and buying it while hoping everything works out. We often tell clients something uncomfortable: integrating a model can be a reversible choice, but only if you design it that way from the start. The difference is an abstraction layer nobody wants to pay for while everything works, and that suddenly becomes essential the night the provider changes the API half your product depends on. That usually happens at three in the morning.
What this means for you, in practice
If you are weighing a build vs buy decision on an AI component, Apple's story gives you three very concrete questions to take into the room.
First: is the model really your competitive advantage, or is it the problem you solve with the model? If the answer is not "the model is the product", it almost always makes more sense to integrate external technology and put your money elsewhere.
Second: if you integrate an external provider, can you replace it without rewriting everything? This is where an abstraction layer, a multi-model strategy and agreements that don't box you into one direction matter. If the answer is no, you are not buying a component: you are getting married, and without a prenup.
Third: where is the truly defensible part of your architecture? If the answer is "in the model's weights", you are looking in the wrong place. Almost always the value is in orchestration, data, business rules and workflows that no vendor can hand you ready-made.
Apple answered these questions in public, accepting that it might look a little less "Apple" in order to be more effective. For anyone building enterprise software the signal is clear: stopping the confusion between possession and control is not a shortcut, it is the more grown-up choice.
Conclusion
The company most obsessed with control has just shown that you can govern the experience without owning every piece of the technology underneath. This is not a surrender. It is engineering done by grown-ups. The control that matters does not live in the weights of a neural network that may age in a few months. It lives in the layer you govern: the one that decides what goes in, what comes out and what happens when the provider changes its mind.
If your next big technical decision is "do we build it or buy it?", start there. The model is a component. The architecture around it is your product.
Related Services
If you're weighing a build vs buy decision around AI components, explore our approach to AI development in Turin. When AI needs to become part of a scalable product, the work moves into SaaS product engineering and requires a software company in Turin that can design architecture, integrations and governance.