The Right Model for AI Implementation: Rent or Own?
And the 2x2 risk-based decision making framework
When AI models first arrived on the scene, enterprises recognized their potential to transform processes, save time, and enhance productivity.
Early on, the mandate to employees inside organizations was “experiment, experiment, experiment.” Try it out. See how you could use it in your role, without much guidance.
That seemed like the right idea at the time. AI models were still underdeveloped compared to where they are today and made a lot of errors. The “play with it” approach served as some kind of warm up while the models were upgrading and proving their value.
Then the tide turned as Do-It-Yourself adoption pain and sunk costs became real. Around 95% of AI pilot projects by enterprises were left incomplete or didn’t generate ROI.
Experimentation with tokens comes at a cost. And as each subsequent AI model improved, the costs were scaling faster than the value they added.
So, more enterprises are bringing in the experts. The consulting companies. The startups. And the Forward Deployed Engineers (FDE) from offshoots of the frontier labs like OpenAI and Anthropic themselves.
All the while, there has been rising concern over sharing proprietary information with frontier labs specifically. Such information contributes to a company’s competitive advantage or moat. So, using labs’ AI models is risky if the companies are unable to effectively barricade their processes.
There are other paths to AI implementation that have also emerged, letting companies own their models instead. This is less threatening in terms of intellectual property (IP) exposure, but comes with its own set of challenges.
In this article, I cover this rent vs own option for AI implementation. ‘Rent’ is the umbrella concept that includes paying an outside party for AI implementation. ‘Own’ refers to building that capability yourself.
The 2x2 Rent vs Own Risk-based Decision-Making Framework
Closing the implementation gap requires enterprises to compare the benefits and risks of various options.
Just like ChatGPT and Claude allow individual users to adjust a setting that disallows them from using your data to train the models, that option is the default for enterprise customers too. So, this isn’t about protecting that kind of core data.
It’s about two other risks.
One is the ‘exhaust’ as Microsoft CEO Satya Nadella calls it in a recent X post or the product feedback loop. His argument is that every prompt, every tool call, and especially every correction a person makes when the model gets something wrong gets distilled into “institutional know-how”, that "leaks almost imperceptibly, trace by trace." In essence, that is your competitive knowledge becoming accessible to outsiders.
Second is the transfer of human judgement. Insiders or enterprise employees know their own processes and how things are done. When working alongside vendors for AI implementation, they are required to transfer some knowledge over about that business logic. They may or may not have a say in which AI lab’s models get employed. And they have to surrender to someone else’s method of implementation and someone else’s judgement on how to shape it, how to correct it and so on. That’s one-way transfer of human judgement from the enterprise to the lab.
How enterprises want to manage these two risks, and how much control they need over AI implementation, is what should drive the rent vs. own decision.
Here’s what that looks like mapped onto a 2x2.
The vertical axis is about who holds the judgment. The top row refers to the rent option. That means an outside party as in a lab, a consultancy, a vendor engineering team is the one making the calls, correcting the system, and accumulating the tacit knowledge of how your business runs.
The bottom row means that stays in-house (own) with whatever tools you’re using to get there.
The horizontal axis is about whether there is a product feedback loop to the vendor’s model. The left side means that the work runs through a hosted, closed frontier model, the kind where the lab providing it can see the traffic and, per Nadella’s argument, learn from it.
To be on the right means it runs on infrastructure you control such as self-hosted, open-weight so that there’s no lab on the other end absorbing the feedback.
In terms of risk, the top left is the highest risk corner with outside judgment plus a hosted frontier model underneath it, both stacked in one relationship.
The bottom right represent the low risk corner….your people, your model weights, no exposure. The other two quadrants hold one or the other risk.
The framework is based on two different types of one variable - risk to competitive advantage. There are other types of risk and other variables like financial costs for example, that should be taken into consideration but are not in this framework.
The main purpose of the framework is to organize thinking around AI implementation choices rather than to recommend any decision. So, the quadrants are more of a guide than a hard and fast rule for decision making.
Some basic terminology
Model weights are “numerical parameters that determine the importance of features in a dataset”.
Open-Weight Model is “an AI model whose core components are publicly released, allowing anyone to download it. This lets users run the model on their own computers, study how it works, and even modify it for their own specific needs”.
Rent
To rent is to buy, i.e. pay fees to an outside party to provide the required services. There are varying levels of services for which an enterprise pays rent.
For technology services, for years, companies like IBM have placed their systems integration engineers inside enterprise customers to integrate their products and solutions into the company’s operations.
Palantir then took that practice further with the Forward Deployed Engineer (FDE) model. As the story goes, in the 2010s Palantir’s intelligence agency customers couldn’t openly share data or narrowly define what they needed through a normal requirements-gathering process typical in product development.
So, Palantir embedded its engineers directly inside customer sites to learn what they needed through physical presence and build customized solutions on client premises.
Consider this the most integrated model and one that has become very popular and adopted by tech companies and startups across the board becoming almost the norm for AI implementation. Because its effectiveness has proved to be very high.
According to an MIT report on AI implementation, the high failure rate of AI implementation projects has been because most tools don’t learn, adapt to context, or integrate into how a business actually runs day to day. FDE can address these problems.
FDEs are also generalist engineers in a specific sense. An oxymoron I know! While a typical engineer builds one capability for many customers, an FDE builds “many capabilities for a single customer”.
Where it gets riskier is when that same embedding intensity is paired with a vendor that also builds and sells the underlying model. That’s the labs’ version of FDE.
The Labs’ version of the FDE model
While Palantir developed the FDE model to meet customer requirements more fully and then build and scale it, OpenAI and Anthropic have now borrowed the FDE model to shape the future of enterprise AI adoption.
Ode was launched in May 2026 as a $1.5 billion joint venture between Anthropic, Blackstone, Hellman and Friedman, and Goldman Sachs. Interesting set of corporate roommates.
Its goal is to sell directly to the key decision maker in any company, the CEO and work with them on some of their most important business processes. With Anthropic as one of its owners, naturally Ode runs on a Claude-first principle although it can use rival AI products as needed.
OpenAI has its own version called the Deployment Company. The consulting companies not to be left behind, such as Deloitte and Accenture, also have their own FDE practices but as you know, they don’t build their own AI models.
There are a few takeaways from what is turning out to be an FDE gold rush.
As models commoditize, implementation is where the returns and the durable advantage exist. FDEs make AI more applicable for customers by customizing them for client needs.
It is a vertical integration move by the frontier labs. It is almost like they are creating one more link in their supply chain from model development to model implementation and creating the army to implement it. Because whoever controls the implementation controls the customer relationship and the expansion revenue. Sweet deal!
On the note of creating an army, many of the FDEs hired by the deployment companies, are former founders. They fit the definition of generalist specialists, having developed the skills during their founding days to not only communicate effectively and sell to investors and customers but also have the technical depth to get into the weeds.
One Blackstone executive who backs Ode put it as the goal isn’t an army of forward-deployed engineers at all, but “special forces”, a small, elite unit rather than a scaled workforce.
That’s a telling take. An army can be recruited and trained at scale. Special forces, by definition, can’t. That raises a question about how far this model can actually grow, now that it has become a thing.
Where it fits in the 2x2
Mapped onto the two axes framework, Ode and the Deployment Company sit in the top left side quadrant. An enterprise using their services faces both risks of the product feedback loop and potentially outsourcing the judgement.
Meanwhile, consulting companies without labs like Deloitte and Accenture’s FDE practices sit more or less in that same quadrant, but for different reasons. They still rent out judgement to some degree. If their teams are implementing on a hosted Claude or GPT, the product feedback still flows to Anthropic or OpenAI either way. The difference is that the two risks are split across two separate companies instead of compounding inside one (like with a lab FDE). That matters.
Palantir is one that floats around in the rent model. For example, for a government engagement running on self-hosted, open-weight models, it sits in the top right quadrant with judgment risk only.
But, for a commercial deployment calling a hosted frontier model, it falls in the top left, same as Ode (as much as Alex Karp would disagree). Same company, different quadrant, depending on how a specific engagement is built.
A couple of clarification points and caveats here.
Vendors aren’t attached to specific quadrants. An FDE team can rent out exactly the same judgment, with exactly the same intensity, and still be in the lower risk quadrant if what it’s built on doesn’t create a feedback loop. Execution matters. If Ode doesn’t use Claude first, the product feedback goes elsewhere…….
Infrastructure providers like Baseten, which host open or custom models without building a competing product from what they see, are what could lower risk by offering full-service FDE without the exposure that comes from a model maker.
The Ceilings of Renting
Even without a focus on the two categories of risks, the rent model has limitations.
The first ceiling is talent and it is not unique to the labs. Any judgment based, embedded engineer business runs into this one.
For deployment companies like Ode, the challenge of getting to the trillion-dollar club that they aspire for is that they need to hire and train people for a very unique skill set which lies at the intersection of engineering, entrepreneurship, AI capability, sales and communication skills. And good judgment across all of it, at once.
If the entire model depends on a talent pool that's scarce by definition, the goal of a trillion-dollar company hits a ceiling kinda before it gets there. Do you know of any trillion dollar consulting company? There isn’t one.
Yes, yes, I know. AI is a different beast. It makes everything and everyone bigger, better, faster…….But is it really that different when you strip it down to what the job here needs - lots of people with a specialized skillset and only 24 hours in a day. And it’s also the timeline. Talent takes time to develop.
If scarcity of talent is the first limit for the FDE model, the second is what Alex Karp has been talking about on television related to ROI.
In a recent appearance on CNBC’s Squawk Box, Palantir CEO Alex Karp claimed, “They're not interested in some fake deploy co that somehow is deploying tokens that transfers the alpha to a third party. And the jig is up.” ‘They’ refers to enterprises looking to deploy AI.
Although Karp was openly promoting his own company’s application layer that helps implement AI for enterprise customers, and hence had a good dose of self-interest here, there is truth to his words.
This isn’t a new risk. It’s the product feedback loop problem from the previous section, made concrete by people close to the industry, plus financial costs added in for good measure.
If labs deployment teams spend months inside a company getting exposure and access to an enterprise’s data and operational knowledge that is a part of its intellectual property, that’s high risk even if you sign a ton of NDAs and have legal counsel at your beck and call.
Microsoft CEO Satya Nadella made a version of this argument in a post shared just a few days ago. His point was that by using closed frontier models, you “pay for intelligence twice”, once in dollars, and a second time in the proprietary data and workflow knowledge the model absorbs simply by being used inside a business.
FDE engagements are pretty much that same dynamic pushed further. Because it involves a team of people directly observing, documenting, and rebuilding your operations… and for a fee!
Like Karp, Nadella isn’t neutral. Microsoft sells AI modeling capabilities and related products. So, like Karp, he has something to promote.
Own
To own is to develop AI capabilities yourself. Like renting, it comes in more than one form, and the form matters.
One is infrastructure control, i.e. for an enterprise to control its entire AI stack; the compute, the model, and the data. Instead of having every call to a hosted frontier model through the lab’s servers, where the lab has visibility to the exchange and by Nadella’s argument is learning from it, companies could run open weight models on infrastructure that they control.
The point isn't to build something new as much as it is to stop something from leaking. Platforms like Snowflake’s Cortex Training let a company fine tune an open-weight model on its own data without it leaving their infrastructure, or Mistral’s Forge let them train a custom model from their proprietary data outright.
The second is about capturing judgement and it comes from former OpenAI CTO turned new startup Thinking Machines Lab CEO Mira Murati. Yes of course she was pitching her company’s new product. That bias aside the point she made is valid that AI should extend human judgment, not replace or centralize it.
Drawing on economists Friedrich Hayek and Michael Polanyi, she argued that the most valuable, productive knowledge is tacit and local and lives in people's heads, not a database. So a model trained once and then frozen can never really capture it. I’m going to skip the rest of her spiel where she pitches her own product since this article is not about promoting any particular company’s products.
This adds a bit of a twist to point #1 above. It's not enough to run an open-weight model on your own servers once and call it owned. The fine-tuning has to be continuous, feeding on the judgment your own people are generating in real time. Keeping the resulting weights matters here too, and for the same reason it did above…..since the base model is open-weight rather than proprietary, a company isn't locked into any one lab's roadmap for how or when that ongoing retraining happens.
There is a trade-off here for the ‘own’ approach. To ‘own’ means choosing to build this expertise in house which is its ‘own’ (pun not intended) problem. It entails identifying and hiring the right experts, training them and so on.
These individuals need the special skillset balancing expertise with the technical skills to encode the human judgment. Not an easy one. So, while the in-house approach might circumvent the IP exposure issue, it still runs into the talent scarcity problem.
There’s a third option.
As an example, Legal AI company Harvey AI has built its business around the fact that law firms don’t want to share their proprietary work with models used by the entire world. So Harvey sits on top of multiple labs’ models rather than any one and gives law firms a layer of insulation. Plus a firm running only on one lab's model could never represent a client whose adversary uses a different one.
It also solves the adoption problem differently than FDE does. Instead of sending in an army of engineers, Harvey employs roughly 200 lawyers directly. This staff trains other lawyers on how to use the product. It looks like an FDE model on the surface but the difference is that the Harvey is a reusable, AI SaaS product a company can subscribe to rather than a bespoke build.
In summary, each of the own ways that are emerging right now (and I’m sure that more will come out in the coming months) approaches ‘own’ in a different way and comes with its own barrel of costs.
Where it fits in the 2x2
All three land on the ‘own’ side of the framework where the enterprise’s own people are the ones making the calls, correcting the system, and deciding what success looks like. Where they fall on the other axis depends on architecture, same as it did for renting.
Karp’s infrastructure argument, when implemented as self hosted and open-weight, sits in the bottom right quadrant. But as with some of Palantir’s commercial work, if a company’s in-house build still calls a hosted frontier model, it lands bottom left instead.
The lowest risk quadrant is the bottom right. Projects in which the judgment stays in-house, the base model is open, and the vendor’s own stated policy keeps client data out of its training pipeline entirely fit here.
Services like Harvey land bottom left rather than bottom right. Here’s why. While it insulates against single-vendor lock-in, the underlying labs can potentially still see whatever traffic runs through their own API. Diversifying across vendors reduces dependency but it doesn’t eliminate exposure.
I want to caveat the ‘own’ decision. It is the safer choice for exposure; i.e. protecting an enterprise’s intellectual property, operational knowledge and other competencies. But there are high costs of hiring and training the right resources and significant financial costs of building the capability.
The same MIT research that flagged the industry’s broader implementation failures also found that internal builds fail roughly twice as often as externally partnered ones with deployment rates of about 33% for in-house efforts versus 67% for vendor partnered ones, across the 52 organizations it studied. So, owning it doesn’t guarantee that it will work.
What Companies Are Actually Doing
The concern with the rent model is growing with well-known folks like Karp, Nadella and others talking about it in public.
However, enterprise behavior has moved toward renting rather than building AI capability. It went from roughly half of enterprises in 2024 to about three quarters in 2025.
Some of that could be a time lag with the need for speed slowly giving way to the need to protect IP. But it’s also that most of what companies are automating isn’t the differentiated core. It’s more of the periphery where renting could actually be a safer option.
That being said, there is indeed a smaller set of enterprises that are using the ‘own’ model for a few processes that contribute to the moat. But, that’s still a minority.
What is the Right Model?
Ultimately the right model for AI implementation inside enterprises is one that does not threaten its competitive advantage. You can lose money and find ways to get it back (not simple but not impossible). But, if a company loses its moat, there is no easy way to build it back up.
As companies consider this decision, there are a few points to weigh carefully.
Not every process needs the same level of protection.
The IP exposure argument is strongest for the process that makes a company defensible. These unique competencies differ from one company to another. For more undifferentiated processes like expense reporting, scheduling, internal documentation, it matters less if someone has access to the tech stack. So, an FDE model to rebuild your customer facing pricing engine and an FDE engagement to automate meeting notes will have varying levels of risk.
A suitable question to ask to evaluate this risk is which of our processes would hurt us if a competitor understood them this well?
It’s about who owns what gets built.
This one is almost boilerplate for any consulting contract. It has been a part of the contracts I’ve signed with corporate clients I’ve consulted with. Companies, especially the larger ones with in-house legal departments are very good at including this one. But it has elevated importance in an AI world simply because of what AI can do. Some questions to ask here are
Does the resulting system, code, and process documentation belong to the company outright, or does the vendor retain rights to reuse patterns learned from the engagement elsewhere?
And of course if you want to fully own what gets built then that is something to weave into an FDE contract or then find the funds to develop the expertise in-house Murati style.
Either way it is a good idea to start building the capability now even if full independence is not realistic yet. A company using a vendor at this stage can still make sure its own teams are learning alongside the FDEs, not just supporting them on a one-way highway.
Plan for the exit, not just the engagement.
AI model competencies are changing as we speak. It’s a good idea to plan ahead for transitions that we cannot imagine right now but could happen later down the line. With respect to the end game another relevant question to ask is
what happens to it if we switch models next year?
Timing matters
The FDE might be a good fit for certain types of urgent, bounded transformations where the cost of waiting is higher than the cost of exposure (plus financial costs). Buying a product (like Harvey) might work well when the workflow is a shared industry problem. But for any proprietary process that contributes to an ongoing advantage that a company expects to defend for years, the safest solution is to suffer through the possibly slower pace to keep the results in house.
There's no single right answer here sitting in the ‘perfect’ quadrant. The right model depends on what's actually at stake in a specific process rather than on which vendor makes the best pitch.
There is only one question that truly matters viz. is this process worth the moat it could cost us? If one gets that answer right, the rest is just implementation detail.