AI and the Enterprise Risk - Part 2

Part 2 of 3: The Ownership, Control and Dependency

Once an enterprise determines that an AI capability has sufficient business value to justify adoption, the next decision is architectural.

Should the organization use a commercial model through an external provider? Should it deploy a model privately? Should it fine-tune an existing model? Should proprietary information remain outside the model through retrieval-augmented generation? Or should the enterprise attempt to train and operate its own large language model?

These options are sometimes presented as a simple progression from less control to more control.

The reality is considerably more complicated.

Owning a model does not automatically mean controlling every risk associated with AI. Conversely, using a commercial model does not necessarily mean surrendering control over enterprise information. The architecture, contractual arrangements, data flows, operational controls, and dependency structure determine the actual risk.

The central enterprise question is therefore not simply who owns the model.

It is who controls the critical components of the AI system, who can change them, and what happens if that control is lost?

The spectrum of AI ownership

Enterprise AI architecture can be viewed as a spectrum.

At one end is a commercial AI service operated almost entirely by an external provider. The enterprise supplies inputs and receives outputs.

Further along the spectrum is a commercial foundation model deployed in a controlled enterprise environment.

Beyond that are privately operated open-weight models, models fine-tuned using enterprise information, and systems that combine externally developed models with proprietary retrieval systems.

At the far end is an enterprise-developed foundation model trained and operated by the organization itself.

These arrangements produce different forms of control.

They also produce different forms of responsibility.

An organization operating its own model may have greater control over data residency, access, model configuration, deployment, and infrastructure. But it also assumes responsibility for infrastructure, security, model evaluation, updates, staffing, incident response, supply-chain management, and potentially enormous computational costs.

Ownership therefore changes the risk profile rather than eliminating risk.

Commercial models and dependency

Commercial models offer a compelling economic proposition.

Training a modern foundation model requires enormous quantities of computational resources, specialized expertise, data engineering, model research, evaluation infrastructure, and operational capacity. Few enterprises can justify reproducing the entire technology stack merely to avoid depending on an external provider.

The economic argument for using a commercial model can therefore be strong.

But dependency becomes a strategic consideration when the model becomes embedded in critical business processes.

Suppose an enterprise builds hundreds of internal applications around one provider's model. Employees become accustomed to its capabilities. Agents are configured around its APIs. Internal data pipelines are constructed around its interfaces. Business processes are redesigned around its performance.

The organization may technically retain ownership of its business data while becoming increasingly dependent upon another company for the intelligence required to operate that data.

That is a different kind of enterprise risk.

The issue is not merely vendor lock-in in the traditional software sense.

It is intelligence dependency.

If the model changes materially, pricing changes, service availability deteriorates, access policies change, a contractual relationship ends, or a provider experiences a major operational or security event, the enterprise may discover that replacing the model is substantially more difficult than initially anticipated.

Fine-tuning does not necessarily mean ownership

Fine-tuning can make an external foundation model more useful for a specialized enterprise domain.

But fine-tuning can also create conceptual confusion.

An organization may invest heavily in developing specialized behavior on top of an underlying model while still depending upon the original provider's architecture, model weights, infrastructure, terms, and update cycle.

The enterprise may own the fine-tuning data or the resulting configuration, but that does not necessarily mean it owns the underlying intelligence.

NIST recommends that organizations re-evaluate models that have been fine-tuned or enhanced on top of third-party models and re-evaluate risks when generative AI models are adapted to new domains.

This distinction matters strategically.

A company can spend substantial resources creating what appears internally to be a proprietary AI capability while retaining a critical dependency on technology it does not control.

Retrieval versus training

The decision becomes particularly interesting when proprietary information enters the architecture.

An enterprise does not necessarily need to train its proprietary information into the model.

Retrieval-augmented generation, for example, can allow a model to retrieve relevant information from enterprise-controlled repositories at inference time.

This can preserve a clearer separation between the foundation model and enterprise information.

That separation can be valuable.

If a company's confidential information remains in its own controlled systems rather than becoming part of a model's learned parameters, the organization may have greater ability to manage, modify, delete, classify, and audit the underlying information.

But RAG is not a magic isolation mechanism.

The retrieved information still enters the AI processing environment. It still has to be protected. Access controls still matter. Retrieval systems can return inappropriate information. Outputs can disclose sensitive content. And an agent with broad retrieval authority can potentially expose information through its actions.

OWASP identifies sensitive information disclosure as a major LLM risk and notes that proprietary algorithms, confidential business information, credentials, and other sensitive information can be exposed through LLM applications.

The architectural advantage of retrieval is therefore not that risk disappears.

It is that the enterprise can potentially retain a stronger separation between its information assets and the model itself.

Training a proprietary LLM

The phrase "train our own LLM" sounds straightforward.

It is not.

There are several very different concepts hidden within that phrase.

An enterprise might train a foundation model from scratch. It might start with an existing open-weight model and continue pretraining it. It might fine-tune an existing model. It might use retrieval to provide proprietary knowledge without modifying the model. Or it might construct a hybrid architecture involving multiple models and proprietary components.

These choices have dramatically different cost and risk profiles.

Training from scratch offers the greatest theoretical control but also the greatest burden.

The organization becomes responsible for data acquisition and governance, training infrastructure, model architecture, evaluation, security, model weights, deployment, updates, and operational reliability.

It also assumes responsibility for determining whether the training data itself creates intellectual-property, privacy, contractual, or regulatory problems.

The U.S. Copyright Office has been examining the legal issues surrounding AI training and copyrighted material, illustrating that training-data questions remain a significant area of legal and policy development.

For most enterprises, therefore, "build our own foundation model" should not automatically be treated as the safest alternative.

It may provide greater control.

It may also create an entirely new class of responsibilities.

What does the enterprise actually need to own?

The better question may be narrower.

Does the enterprise need to own the foundation model?

Or does it need to own and control the knowledge, data, retrieval systems, model configuration, application logic, identity, and decision processes that differentiate its business?

This distinction can materially change the economics.

A manufacturer may not need its own general-purpose foundation model. Its competitive advantage might instead reside in proprietary manufacturing data, engineering documentation, process knowledge, historical quality information, and specialized workflows.

A financial institution may derive more value from proprietary risk data and internal analytical systems than from building a general-purpose language model.

A software company may care more about protecting source code, architectural knowledge, customer information, and proprietary development processes.

In each case, the enterprise's real asset is not necessarily the model.

It is the information and organizational knowledge surrounding the model.

The hidden risk of proprietary models

There is also an important counterargument to the assumption that proprietary AI automatically improves security.

A proprietary model becomes an enterprise asset worth protecting.

Its weights may contain valuable information about the training process, specialized data, or model behavior. The model itself can become a target for theft, extraction, manipulation, or unauthorized access.

OWASP explicitly identifies model theft as a risk, noting that unauthorized access to proprietary models can compromise competitive advantage and sensitive information.

The enterprise therefore moves from one security problem to another.

With an external provider, the enterprise must evaluate the provider.

With a proprietary model, the enterprise becomes responsible for protecting the model.

Neither option is intrinsically risk-free.

Control versus complexity

There is a broader strategic principle here:

More control generally means more responsibility.

An enterprise that owns its infrastructure has greater control over infrastructure risk—but also assumes responsibility for infrastructure security.

An enterprise that operates its own model has greater control over model deployment—but also assumes responsibility for model security and performance.

An enterprise that controls its training data has greater control over its knowledge base—but also assumes responsibility for data governance and provenance.

This means that "maximum control" should not necessarily be the objective.

The objective should be sufficient control over the components that matter most to the enterprise's risk profile.

That requires identifying those components explicitly.

Dependency should be treated as an enterprise variable

AI procurement decisions traditionally emphasize price, performance, functionality, and security.

AI introduces another important variable: dependency.

If an enterprise's competitive processes increasingly depend upon an external model, then model availability, pricing, capability, policy, and contractual terms become business variables.

The organization should understand what happens if the model is unavailable for a day.

What happens if it is unavailable for a month?

What happens if a new model version changes behavior?

What happens if the provider discontinues a model?

What happens if an enterprise cannot migrate its prompts, evaluations, integrations, fine-tuning, or agent architecture to another provider without substantial redevelopment?

These questions are not hypothetical abstractions. They are ordinary components of technology concentration risk.

The difference is that AI can become deeply embedded in knowledge work unusually quickly.

The ownership decision

The enterprise therefore faces a decision that is more nuanced than "commercial versus proprietary."

The relevant dimensions include:

- Data control.
- Model control.
- Infrastructure control.
- Operational responsibility.
- Vendor dependency.
- Intellectual-property exposure.
- Cost.
- Performance.
- Portability.
- Security.
- Regulatory and contractual obligations.

No single architecture dominates across all dimensions.

The correct architecture depends on the value and sensitivity of the information, the consequences of failure, the organization's technical capabilities, the economics of the use case, and the degree of dependency the enterprise is willing to accept.

That leads directly to the final question.

Even after selecting the appropriate model architecture, the enterprise still has to determine what that system should actually be allowed to access and do.

That is where ownership becomes authorization—and where an AI capability becomes an enterprise actor.

Article published by icrunchdata
Image credit by Getty Images, Moment, Eugene Mymrin