Build, Buy, or Blend? Choosing an Enterprise AI Operating Model?

The enterprise AI decision is becoming less about choosing a model, and more about deciding what the organization wants to control.

Disclosure: I am employed by Cloudflare. This article reflects my personal views and independent analysis through KrisperTech.com. It is not an official Cloudflare publication or product recommendation.

The question is no longer whether organizations will use AI. They already are.

The bigger question is how they plan to govern and scale AI, and how much of it they actually want to control.

For many organizations, the obvious answer is to buy. That might mean adopting a single-vendor workspace such as ChatGPT Enterprise or Claude Enterprise, or consuming commercial models through APIs and cloud platforms like Amazon Bedrock or Microsoft Foundry [1][2][3][4].

Alternatively, organizations may opt to leverage model-agnostic harnesses and frameworks, or build a custom environment using platforms such as Cloudflare. Cloudflare recently open-sourced Cloudflare OS, its AI workspace, allowing organizations to customize the agent, application, and integration layers while retaining flexibility at the model layer. Third-party models can be routed through AI Gateway, while Cloudflare-hosted models can be consumed through Workers AI [5][6].

This is usually framed as a build versus buy decision, but I’m not convinced that is the right way to think about it anymore.

The better question may be: Which parts of the AI operating model does the organization actually want to control?

Buying AI Is Not One Thing

There is an important distinction between buying an AI workspace and buying access to a model.

A provider-native workspace such as ChatGPT or Claude gives employees direct access through the provider’s own applications and interfaces. The provider owns much of the user experience and platform operation, while workspace administrators can configure available controls around identity, user access, applications, connectors, data, and administration, depending on the plan [1][2].

That can remove a significant amount of operational burden.

For general productivity use cases, this may be exactly what an organization needs. There is little value in rebuilding an entire AI experience simply so employees can summarize documents, research topics, analyze information, write content, or get help with code.

That convenience comes with a trade-off. The workspace, administration, integrations, and user experience are built around the provider. Moving from one enterprise workspace to another is not the same as changing the underlying model provider.

Another option is to consume models as a service and build applications, agents, or workflows around them.

For example, an organization can consume Claude through Amazon Bedrock, with AWS operating the surrounding inference environment [3]. Microsoft Foundry similarly provides access to models from OpenAI, Anthropic, and other providers through a common cloud platform [4].

In each case the organization is still buying AI, but it can control considerably more of what sits around the model.

That distinction matters.

Buying Does Not Remove the Architecture

Enterprise AI platforms today are very different from the consumer tools with which organizations first experimented.

OpenAI and Anthropic both provide enterprise controls around identity, user provisioning, permissions, data handling, connectors, and administration [1][2].

That means the case for building cannot simply be: “We need security and governance for our AI tooling.” Managed platforms already provide meaningful controls in both areas.

The harder questions begin when AI starts interacting with organizational systems.

• What data can it retrieve?

• Which applications can it access?

• Which tools can it invoke?

• Can it perform an action or only recommend one?

• What requires user approval?

• What gets logged?

• Who is responsible when something goes wrong?

This is where enterprise AI starts looking less like a chatbot and more like another privileged application.

The security question increasingly becomes one of authority.

What is the AI actually allowed to do?

That question exists whether the platform was bought, built, or somewhere in between.

Building Gives You Control. It Also Gives You Responsibility.

There are good reasons an organization may want to control more of its AI environment.

Maybe it wants to use multiple model providers.

Maybe a workflow needs very specific authorization rules.

Maybe an agent needs access to an internal system, but only for a tightly defined set of actions.

Maybe certain data should remain within a controlled environment.

Maybe a human must approve an action before it can be executed.

This is where building more of the AI operating layer becomes interesting. In this architecture, the organization decides how models, agents, applications, identity, integrations, and internal systems fit together.

The important part is not the product. It is that the organization is choosing to control more of the operating layer. That flexibility has value. It also has a cost.

Someone has to maintain the integrations.

Someone has to manage permissions.

Someone has to account for logging, monitoring, model changes, dependencies, authorization, failure modes, and how the platform evolves.

There is sometimes an assumption in cybersecurity that more control is automatically better. I do not think that is true.

A well-configured managed platform can be considerably safer than an internally built AI environment with poorly scoped permissions and weak governance.

Owning more of the stack does not automatically mean securing it better.

This Is Why I Think Most Enterprises Will Blend

This is where the traditional build versus buy argument starts to fall apart.

An organization may provide ChatGPT or Claude to employees for broad productivity while still building specialized AI workflows in areas where it needs greater control.

A security team may want an agent that can interact with security telemetry.

Engineering may want an agent capable of performing specific operational tasks.

A regulated workflow may require human authorization before an AI system can take an action.

Those use cases do not necessarily justify replacing the enterprise AI workspace used by the rest of the organization.

They can exist alongside it.

There is another reason the distinction is becoming less useful.

An organization that builds its own AI environment will often still consume a commercial model underneath it.

So if an organization builds an agent but uses Claude through Amazon Bedrock, did it build or buy? Both.

If it buys an enterprise AI workspace and then connects that workspace to internally developed tools and data? Again, both.

The same applies to model choice. When the organization controls more of the application and orchestration layer, changing the underlying model can become a very different decision from replacing an entire employee workspace.

Cloudflare OS itself now provides another example of how these boundaries are beginning to blur. Cloudflare released the platform as open source in August and has since opened a waitlist for a fully managed deployment option [5][7].

The boundaries are getting harder to draw.

The Real Decision Is Where Control Lives

I think this is the more useful way to approach enterprise AI.

Who owns the user experience?

Who manages identity?

Who defines which tools can be used?

Who determines what data the AI can access?

Who controls model selection?

Who monitors activity?

Who authorizes actions?

Who responds when something goes wrong?

Those responsibility boundaries ultimately determine the operating model.

For some organizations, the right answer may be to purchase almost everything.

Others will build considerably more.

Most, I suspect, will land somewhere in the middle.

That does not mean every organization needs a complex internal AI platform.

It means the architecture should follow the use case.

Use managed workspaces where the speed, user experience, and reduced operational burden make sense. Build where the organization genuinely needs additional control.

Consume models as infrastructure where the organization wants to control more of what sits around them.

Blend those approaches where forcing everything into a single platform or operating model creates more problems than it solves.

The enterprise AI conversation started with a fairly simple question: Which AI should we use?

I think the next phase has a bigger one: Which parts of AI are we prepared to control?

For many organizations, the answer will not simply be build or buy. It will be blend.

References

[1] OpenAI. ChatGPT Enterprise Admin Quickstart. OpenAI Help Center. OpenAI documents enterprise workspace controls including SSO, SCIM, RBAC, apps, connectors, security controls, and monitoring. OpenAI Help Center

[2] Anthropic. Configuring Claude: Guidance for Enterprise Admins. Anthropic. Anthropic documents SSO, SCIM, roles and permissions, connectors, model access, retention, and other enterprise controls. Anthropic

[3] Amazon Web Services. Claude Platform on AWS vs Amazon Bedrock. AWS documents that Amazon Bedrock operates the inference stack for Claude and exposes it through the Bedrock environment. AWS Documentation

[4] Microsoft. Model Router for Microsoft Foundry. Microsoft documents access to and routing across models from OpenAI, Anthropic, Meta, xAI, DeepSeek, and others through Foundry. Microsoft Learn

[5] Cloudflare. Cloudflare OS: an open platform for agents, apps, and work. August 2026. Cloudflare describes Cloudflare OS as an open-source platform organizations can deploy and customize around their own systems and ways of working. Cloudflare Blog

[6] Cloudflare. Cloudflare AI. Cloudflare documents a unified AI platform supporting models hosted on Cloudflare infrastructure through Workers AI and external providers through AI Gateway. Cloudflare Docs

[7] Cloudflare. Cloudflare OS: your company’s agent workspace, managed for you. October 2026. Cloudflare announced a waitlist for fully managed Cloudflare OS deployments. Cloudflare Blog