{"slug": "the-build-vs-buy-dilemma-at-the-heart-of-enterprise-ai", "title": "The build vs. buy dilemma at the heart of enterprise AI", "summary": "Enterprise AI adoption is forcing companies to reconsider the traditional 'buy' approach to software, as embedded AI from vendors like SAP and Oracle requires data to reside in their cloud environments, creating a strategic fork between building, buying, or adapting AI. The real choice involves three distinct approaches—embedded AI, AI platforms, and custom AI—each with different data governance and architectural implications, while many large enterprises face pressure to demonstrate AI progress amid ongoing platform modernization and migration risks.", "body_md": "For three decades, enterprise software has been a buy-it decision. Packaged software from SAP, Oracle and Salesforce covered roughly 80% of requirements at a fraction of the cost of building. The economics were obvious, and for traditional applications, they still are.\n\nAI is introducing a wrinkle that is forcing even the most committed enterprise software customers to rethink their options. AI is a layer that sits across your data, your processes, and your decisions. Where that layer runs and who controls it is an architecture question, and most of the enterprise community is still treating it as a procurement one.\n\nThe appeal of vendor-embedded AI is clear: automated operational decisions, smarter supplier and merchandising choices, and friction-free workflows built into the systems enterprises already rely on. The catch is that these capabilities almost universally depend on your data living in the vendor’s cloud environment. For most large enterprises, it sits on-premises, in hyperscale cloud infrastructure they manage themselves, or in private data centers. That gap between where your data is and where your vendor’s AI assumes it should be creates a fundamental strategic fork in the road.\n\nThe framing I keep hearing is “build vs. buy your AI strategy.” It implies that some organizations are out there training foundation models from scratch. Nobody serious is doing that. The real choice sits across three distinct approaches, and conflating them leads to poor decisions:\n\nThese are not equivalent options at different price points. They make different assumptions about where your data lives, who governs the AI, and how much architectural change you’ll absorb to get there. Vendor pitches sometimes blur the distinction on purpose. Enterprise leaders can’t afford to.\n\nEvery embedded AI capability ships with an unstated architectural prerequisite: your data must be where the AI can see it, in the shape it expects, under the governance the vendor enforces.\n\nFor organizations with clean, modern cloud estates, that is often a reasonable trade. For the long tail of large enterprises running heavily customized environments on private or hybrid infrastructure, that trade becomes a precondition, one you must meet before the AI conversation can even begin. Whether meeting it makes sense depends on your starting point, your sector’s regulatory posture, and your appetite for migration risk. None of those are uniform across organizations.\n\nThat’s the part that gets glossed over in vendor keynotes. The AI demo on stage assumes a destination architecture the audience hasn’t necessarily reached yet. Large enterprise customers are carrying an unusually heavy technology burden right now. Many are simultaneously managing platform modernization programs that have been building for over a decade, alongside pressure to migrate to vendor-managed cloud infrastructure. Sitting above both is a boardroom-level directive to demonstrate meaningful AI progress fast. The vendor path to AI and the boardroom path to AI can diverge sharply, and enterprises need to make selective, strategic decisions about where to adopt AI first to maximize value and minimize risk.\n\nThe conversation about sovereignty has been hijacked by both sides. One camp treats every SaaS adoption as a sovereignty violation. The other dismisses every sovereignty concern as Luddite resistance. Neither is useful.\n\nWhat’s happening in real customer conversations – particularly in DACH, public sector, and financial services – is more specific. Organizations are drawing a distinction between running their applications in a vendor’s cloud (which is broadly fine, well understood, decades of precedent) and enriching their data and processes inside a vendor’s AI model (which has less precedent, is harder to reverse, and carries material implications for competitive position).\n\nEnriching your data inside a vendor’s AI model is the genuinely new question, and organizations that conflate it with their existing cloud posture tend to defend the wrong perimeter.\n\nDespite spending around $100 million annually with Amazon, [Disney built its own internal AI system](https://www.uctoday.com/unified-communications/disney-openai-enterprise-strategy/) to house its corporate intelligence rather than rely on a hyperscaler’s AI offering. The decision came down to control. When your data represents decades of creative and commercial IP, you think carefully about where it lives and who can learn from it. Disney has become more open to SaaS over time. The AI sovereignty question is a separate debate from the SaaS debate and conflating the two leads organizations to the wrong conclusions.\n\nAt the other end of the spectrum, enterprises in heavily regulated environments treat data sovereignty as an absolute non-negotiable. Any AI model must run within their controlled environment, especially where sensitive data cannot touch the public internet.[ ](https://gdpr.eu/what-is-gdpr/)[GDPR obligations](https://gdpr.eu/what-is-gdpr/) reinforce this instinct across the European market, requiring organizations to maintain clear accountability for how personal data is processed inside AI systems, including vendor-managed ones.\n\nAI-enriched data, meaning models that have learned the shape of your business processes, your supplier negotiations, your customer behavior, carries a different half-life and a different strategic value than the operational data underneath it. That deserves its own architectural decision, separate from your broader cloud strategy.\n\nMost large enterprise estates will end up with a mix of all three approaches, and where you draw the lines matters more than your overall posture.\n\nEmbedded AI capabilities are the right answer for in-application productivity: the assistant inside your ERP workflows, the agent inside your procurement or HR suite. That is where vendor embedding genuinely shines, and attempting to compose your own equivalent is typically a poor use of engineering resources.\n\nCompose belongs elsewhere: in cross-application orchestration, in custom assistants over operational and observability data, and in agents that need to reach across multiple vendor systems and infrastructure layers in ways no single vendor stack will never natively support. [Research from McKinsey](https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/the-top-trends-in-tech) suggests the most significant near-term productivity gains from enterprise AI will come precisely from these cross-system workflows, rather than from within individual applications. The most interesting enterprise AI work over the next eighteen months lives here, and it doesn’t require waiting for a migration to complete first.\n\nThat compose path isn’t free, and it’s important to be honest about the costs. Governance, audit trails, and accountability for hallucinated outputs become your problem, not the vendor’s. Prompt drift and evaluation discipline are real engineering costs that never appear in the proof-of-concept. Those costs scale with the complexity of your landscape and the number of systems your agents touch. Budget for them before deployment, not after your first production incident. None of that is a reason to avoid the path. It’s a reason to staff for it, honestly.\n\nThe build-vs-buy frame survives because it gives executives a binary choice along a familiar axis. AI sits somewhere else entirely.\n\nThe question worth putting on the table at your next architecture review is simpler:\n\nWhich decisions do we want our vendors’ AI to make, and which do we want to keep on our side of the boundary?\n\nAnswer that, and the right build/buy/compose mix flows from it. Skip it, and you will end up with the architecture your vendors prefer – which may or may not be the one your business needs.\n\n**This article is published as part of the Foundry Expert Contributor Network.****Want to join?**", "url": "https://wpnews.pro/news/the-build-vs-buy-dilemma-at-the-heart-of-enterprise-ai", "canonical_source": "https://www.cio.com/article/4197957/the-build-vs-buy-dilemma-at-the-heart-of-enterprise-ai.html", "published_at": "2026-07-17 10:00:00+00:00", "updated_at": "2026-07-17 10:08:05.838462+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-policy", "ai-infrastructure", "ai-ethics"], "entities": ["SAP", "Oracle", "Salesforce"], "alternates": {"html": "https://wpnews.pro/news/the-build-vs-buy-dilemma-at-the-heart-of-enterprise-ai", "markdown": "https://wpnews.pro/news/the-build-vs-buy-dilemma-at-the-heart-of-enterprise-ai.md", "text": "https://wpnews.pro/news/the-build-vs-buy-dilemma-at-the-heart-of-enterprise-ai.txt", "jsonld": "https://wpnews.pro/news/the-build-vs-buy-dilemma-at-the-heart-of-enterprise-ai.jsonld"}}