You wouldn't outsource accountability for your safety culture. You wouldn't let a third party decide which equipment gets maintained and which doesn't. You wouldn't hand over your process safety decisions to a vendor.
In industrial settings, AI increasingly influences maintenance prioritization, inspection findings, and operator decision support. So why are you outsourcing the capability that powers those decisions?
Zapier's 2026 Enterprise AI Survey found that 81% of enterprise leaders are concerned about AI vendor dependency - and only 6% believe they could switch providers without material disruption. Unlike cloud infrastructure lock-in, which is primarily a migration problem, AI lock-in is a capability risk. When you fine-tune a closed-weight proprietary model through a vendor's API, that investment in model behavior often doesn't transfer - the weights stay in their environment. Some vendors offer adapter export (LoRA weights), but many don't. When your workflows are built around specific API behavior and prompt structures, those workflows break when the underlying model changes.
The build-vs-buy decision for AI is fundamentally different from software. And most organizations are applying the wrong framework.
Why the Software Playbook Doesn't Work
When you buy software, deployment is never trivial - but the product fundamentally works the same for you as it does for your competitor. The value is in the tool itself.
When you buy AI, you're buying a starting point - and the value is in what you do with it after deployment. The fine-tuning, the feedback loops, the expert corrections, the domain-specific data curation. That's where the competitive advantage lives. None of it transfers if you switch vendors.
This is the lesson from every article in this series:
- The model is 20% of the work (Article 3). The organizational infrastructure is 80%.
- For many industrial use cases, the foundation model isn't the differentiator - 42% of successful deployments used commodity models (Stanford). Data is the differentiator (Article 4).
- The feedback loop that compounds improvement requires domain experts in the loop (Article 5) - and that loop is yours to own or lose.
If everything in your AI investment sits in a vendor's platform - training data, fine-tuned weights, feedback history, evaluation metrics - you don't have a capability. You have a dependency. And unmanaged dependencies don't compound. They expire when the contract does.
The AI Build-vs-Buy Matrix
Stop treating the model as the decision. Start deciding which layers to own.
Foundation models - Rent. Stanford found nearly half of successful deployments used commodity models. Use APIs or open-weight models. Switch when better options emerge.
Compute / GPU - Rent training, own inference at scale. Rent GPU for one-off training jobs. Own inference when workloads are predictable and data residency matters.
Fine-tuning data and weights - Own. Your data plus your domain equals your moat. Own the training dataset, the annotation guidelines, and the resulting model weights - even if you hire a partner to run the pipeline.
Review and feedback tooling - Own. This is where organizational capability lives - the interfaces your experts use to correct the AI.
Domain expert workflows - Own. Nobody sells your institutional knowledge. This is the 80% from Article 3.
Data curation infrastructure - Own. The compound advantage. Every correction makes the next project better.
MLOps and monitoring - Hybrid. Buy the platform. Build the domain-specific monitors, drift detectors, and quality gates.
The pattern is clear: rent the commodity layers, own the differentiation layers. The commodity layers are where models, compute, and platforms live - and they're getting cheaper every quarter. The differentiation layers are where your domain data, expert corrections, and feedback loops live - and they're getting more valuable with every project.
This isn't anti-vendor. If the workflow isn't differentiating, the data isn't sensitive, and the volume doesn't justify in-house investment - buy the product and move on. Customer service automation, marketing content generation, non-safety-critical internal search - these are commodity AI problems where speed-to-market matters more than ownership. The framework matters most when AI touches your core operations, your proprietary data, or your competitive advantage.
Three Things You Should Think Very Hard Before Outsourcing
1. The Feedback Loop
Every expert correction is training data. Every edge case caught is a test case. Every round of human review makes the next deployment better. This is the compounding mechanism described in Articles 3, 4, and 5.
If a vendor owns that feedback loop - if your expert corrections are trapped in a proprietary database schema you can't export - then you can't use those corrections to train your own models, switch providers, or even reproduce a training run. The risk isn't that the vendor shares your data with competitors. Modern enterprise contracts prevent that. The risk is that your most valuable asset - accumulated expert feedback - is locked in a format only one vendor can use.
Own the loop. Own the improvement curve.
2. Domain Data Curation
Article 4 established that data quality is the single highest-leverage investment in AI. The contaminated reference standard problem means generic data teams can't do this work. Your domain experts must be in the loop - reviewing labels, updating annotation guidelines, flagging edge cases that only someone with 20 years of experience would catch.
If your annotation process is outsourced to a vendor who uses generic annotators, your training data inherits their lack of domain knowledge. The model learns from people who don't understand what they're labeling.
3. Success Metrics
MIT's Project NANDA found that 61% of AI projects were approved on projected value that was never formally measured after deployment. Organizations buy AI, skip the measurement, and then buy more AI.
If you outsource measurement to the vendor - if the only metric you track is "the vendor says it's working" - you'll never know whether your AI investment is compounding or stalling. Define your own capability metrics: cost per reviewed entity, error rate trending down across deployments, human review time decreasing per batch, edge cases handled autonomously this quarter versus last.
These metrics tell you whether you're building a capability or renting a product. Nobody will track them for you.
Own Inference, Rent Training
From the first article in this series: local AI for spatial precision and data sovereignty, frontier AI for reasoning - with an anonymization layer in between.
That wasn't ideology. It was risk management.
When you send a P&ID to a cloud API, you're sending facility blueprints to a third-party server. On more than one project, legal blocked cloud API usage before engineering even evaluated accuracy. Their concern was valid. The result was months of delay.
The economics now support the architecture. Deloitte estimated that inference workloads will account for two-thirds of all AI compute by 2026 - up from roughly half in 2025. For predictable, high-volume inference workloads with high GPU utilization, on-premises deployment can break even within months - Lenovo's TCO analysis showed as fast as four months under favorable conditions. You rent training compute for expensive, one-off GPU jobs. You own inference for production workloads that run every day.
Owning inference isn't free - it requires IT partnership for reliability, patching, and capacity planning. The business case isn't just compute cost. It's data sovereignty: keeping facility blueprints and proprietary engineering data off third-party servers, and keeping your competitive advantage non-exportable.
This is the hybrid model emerging across industrial AI: use frontier APIs for development and experimentation, deploy fine-tuned local models - often open-weight (like Llama or Mistral) - for production. The open-weight distinction matters: when you fine-tune an open model, you own the resulting weights. When you fine-tune through a proprietary API, the vendor controls the artifact.
Five Questions to Ask About Your Current AI Investments
If you're an Engineering Director or VP evaluating your organization's AI portfolio, run it through this filter Monday morning:
1. If your primary AI vendor shut down tomorrow, what would break? If the answer is "everything," you don't have a capability - you have a single point of failure. Identify what's portable and what's locked in.
2. Who owns the feedback loop? When your domain experts correct the AI's mistakes, where do those corrections go? Into your training pipeline - or into the vendor's platform? If the vendor owns the corrections, they're compounding their product on your expertise.
3. Where does your training data live? If it's in the vendor's environment, can you export it? In what format? With what latency? If you can't reproduce a training run from your own data, you don't own your AI.
4. What are your capability metrics? Not "is the AI deployed" - is it getting better? Is error rate trending down? Is human review time decreasing? Is the model that processes your next facility better than the one that processed the last? If you can't answer, you're not building a capability.
5. Is your AI budget co-owned with operations? If the budget sits entirely in IT, procurement will apply software rules. For AI that touches engineering or operations workflows, the domain leader needs to co-own budget, success metrics, and governance. IT brings infrastructure. Operations brings the context that determines whether the system actually works.
If all five answers point to the "buy" column, you're building a dependency, not a capability. And dependencies don't survive the next contract cycle.
The Decision That Compounds
This series started with a model that went from 39% to 93% accuracy - not from a better algorithm, but from domain data, expert corrections, and organizational discipline. It moved through the organizational infrastructure that makes AI usable, the data quality practice that makes it defensible, and the workforce urgency that makes it time-sensitive.
It all converges here: the decision about what to own.
The organizations that own their feedback loops, their domain data, and their expert workflows will compound their AI advantage for years. Each project makes the next one faster. Each correction makes the model better. Each expert who teaches the AI embeds institutional knowledge that no competitor can replicate.
The organizations that rent everything will keep buying the next platform, the next model, the next vendor - wondering why AI still isn't delivering value, while the capability they needed was never in the software. It was in the decision about what to build.
This is Part 6 of a 6-part series on AI in industrial operations:
- I've Trained AI on Engineering Drawings. The Model Was Never the Hard Part.
- You're Buying AI Like Software. That's Why It's Failing.
- Your AI Model Works. Your Organization Doesn't.
- Your Data Is the Model. Everything Else Is a Commodity.
- The $31.5 Billion Walk-Out: Why Your Best AI Training Data Is About to Retire
- Build, Buy, or Die: The AI Decision That Will Define Your Next Five Years
This is the last article in this series, and it comes down to one question: are you building a capability or buying a product?
If you've read this far, you already know the answer. The harder question is what to do about it - which layers to own, where to start, and how to make the case internally.
Which of the five questions above is the hardest for your organization to answer right now? Comment and I'll share how others are tackling it - or DM me "AUDIT" for the full build-vs-buy framework I use with industrial AI teams.