Your AI Vendor Is Becoming Part of Your Architecture

AI Strategy Series | Article 9 of 20

Building the Intelligent Enterprise

For decades, enterprise technology leaders have evaluated software vendors based on functionality, cost, reliability, security, integration capabilities, and contractual terms.

Those considerations remain important.

But artificial intelligence introduces a new architectural reality.

Your AI vendor is no longer simply supplying technology. It may be participating directly in how your enterprise interprets information, makes decisions, and executes work.

That distinction changes the strategic significance of vendor selection.

A traditional enterprise software application generally operates within a defined functional boundary. An accounting platform processes financial transactions. A customer relationship management system maintains customer records. A supply chain application coordinates procurement and fulfillment.

Each may be deeply integrated into enterprise operations, but its responsibilities are relatively well understood.

AI platforms are different.

An AI service may interpret natural language, retrieve information from multiple enterprise systems, select tools, generate recommendations, coordinate workflows, and initiate actions across applications.

The vendor supplying that capability may influence not only how the system operates but also how the enterprise’s business processes are executed.

And as organizations increasingly depend on proprietary models, managed AI services, agent platforms, and vendor-controlled orchestration capabilities, the architectural consequences become substantial.

The strategic question is no longer simply:

Which AI vendor offers the best capabilities?

It is:

What part of our enterprise architecture are we allowing this vendor to become?

The Vendor Relationship Has Changed

Traditional enterprise software vendors have always influenced architecture.

ERP implementations establish data structures, integration patterns, workflow dependencies, and operational constraints that may persist for decades.

Cloud providers influence infrastructure architecture, application deployment, resilience, and operating costs.

Software-as-a-service providers shape how organizations manage customer relationships, human resources, finance, and other business functions.

AI vendors extend this influence into a new domain: the interpretation and execution of enterprise work.

Consider an organization deploying an AI assistant to support procurement.

Initially, the assistant answers questions about purchasing policies, supplier agreements, and historical transactions.

Its responsibilities appear limited.

Then the organization connects it to the procurement platform.

The assistant begins generating purchase requests, identifying suppliers, and recommending contract terms.

Eventually, it receives permission to initiate approved transactions within established financial limits.

At that point, the AI platform is no longer merely an information service.

It has become part of the enterprise’s operational architecture.

Its availability affects business continuity.

Its integration design affects transaction integrity.

Its model behavior affects decision quality.

Its access controls affect operational authority.

Its vendor-managed updates may affect how established workflows behave.

And its commercial terms may influence whether the enterprise can sustain or replace the capability.

The vendor relationship has become an architectural dependency.

That dependency should be evaluated before it becomes difficult to reverse.

AI Vendors Introduce Multiple Layers of Dependency

Enterprise leaders often discuss AI vendor dependency as though it were a single concern.

In practice, AI platforms can introduce dependencies at several architectural layers.

Understanding those layers is essential to making informed investment decisions.

1. Model Dependency

The most visible dependency involves the foundation model itself.

An enterprise may build applications around a particular model’s capabilities, context window, tool-calling behavior, structured output conventions, or performance characteristics.

Over time, developers may optimize prompts, workflows, evaluation methods, and application logic for that model.

Changing models may then require substantial testing and redesign.

Even when two providers expose similar APIs, their models may interpret instructions differently, select tools differently, or produce different outputs.

Compatibility at the interface level does not guarantee behavioral equivalence.

This creates an important distinction.

An application may be technically portable between models without being operationally portable.

The enterprise must consider both.

2. Platform Dependency

Many AI vendors offer more than model access.

They provide managed retrieval, vector storage, orchestration, agent development environments, evaluation tools, monitoring, safety controls, and workflow automation.

These capabilities can accelerate development.

They can also create architectural dependencies.

An application built around a vendor’s proprietary agent framework may become difficult to migrate if its workflows, tool definitions, state management, and execution logic are tightly coupled to that environment.

The more responsibility the platform assumes, the more consequential its design becomes.

3. Data Dependency

AI applications frequently depend on vendor-managed mechanisms for ingesting, transforming, indexing, storing, or retrieving enterprise information.

That introduces questions extending beyond traditional data hosting.

Where is enterprise information stored?

How is it transformed?

What metadata is retained?

Can the enterprise retrieve its information in a usable form?

Are embeddings, indexes, conversation histories, and execution records exportable?

What happens to those assets when the vendor relationship ends?

An organization may retain legal ownership of its data while losing practical access to the structures required to use it effectively.

Data ownership and data portability are not the same thing.

4. Integration Dependency

AI agents increasingly interact with enterprise applications through APIs, connectors, and tool interfaces.

Some vendors provide proprietary integration mechanisms.

Others support established protocols and open interfaces.

The architectural concern is not whether proprietary integration is inherently unacceptable.

It is whether the enterprise understands the consequences of depending on it.

A vendor-specific connector may accelerate deployment today while increasing replacement costs tomorrow.

An abstraction layer may improve portability but introduce additional complexity.

Neither approach is universally superior.

The appropriate decision depends on strategic importance, expected longevity, switching costs, and operational requirements.

5. Operational Dependency

When AI capabilities become embedded in business processes, the vendor’s operational characteristics become part of the enterprise’s own operating environment.

Availability, latency, throughput, service limits, incident response, change management, and support arrangements can directly affect business performance.

An outage affecting an experimental chatbot is inconvenient.

An outage affecting AI-driven order processing, claims handling, or supply chain coordination may interrupt revenue-generating operations.

The same vendor failure can have very different consequences depending on how deeply the AI capability has been integrated.

6. Economic Dependency

AI pricing models introduce another architectural consideration.

Costs may depend on tokens, model selection, context size, retrieval operations, storage, tool execution, agent activity, or provisioned capacity.

A workflow that appears economical during a pilot may become expensive when deployed across thousands of employees or millions of transactions.

Architecture determines consumption patterns.

Consumption patterns determine cost exposure.

The enterprise therefore needs to understand how vendor pricing interacts with application design and operational scale.

AI vendor economics cannot be separated from AI architecture.

The Hidden Problem With AI Portability

Portability is frequently presented as a solution to vendor dependency.

Organizations are encouraged to use standardized APIs, modular components, and interchangeable models.

Those practices can be valuable.

But AI portability is more complicated than replacing one technical endpoint with another.

Suppose an enterprise develops an AI agent that performs contract analysis.

The agent retrieves documents, identifies relevant clauses, evaluates contractual obligations, and recommends actions.

The application uses a particular foundation model.

Later, the organization decides to migrate to another provider.

The API changes may be manageable.

But the new model may interpret contractual language differently.

It may identify different risks.

It may apply reasoning steps differently.

It may produce different classifications.

Its tool-calling behavior may affect workflow execution.

Even when the application continues functioning, the business outcome may change.

This means portability must be evaluated across multiple dimensions.

Technical portability concerns whether the application can connect to an alternative platform.

Data portability concerns whether required information and supporting structures can move.

Operational portability concerns whether workflows can continue functioning within acceptable performance and reliability parameters.

Behavioral portability concerns whether the replacement produces sufficiently equivalent results for the intended business purpose.

Economic portability concerns whether switching remains financially practical.

An enterprise may achieve technical portability while failing the other four tests.

This is why model abstraction alone does not eliminate vendor dependency.

The enterprise must also establish evaluation mechanisms capable of determining whether a replacement model or platform remains fit for purpose.

When the Vendor Controls the Agent Framework

The architectural implications become more significant when vendors provide managed agent platforms.

An agent framework may determine how tasks are decomposed, how tools are selected, how execution state is maintained, how errors are handled, and how agents coordinate with other systems.

These are not merely implementation details.

They influence operational behavior.

Consider a customer service agent that can retrieve account information, evaluate service eligibility, issue credits, and modify customer records.

The enterprise may establish policies defining what the agent is permitted to do.

But the platform must translate those policies into executable controls.

Where are permissions enforced?

Who determines which tools are available?

Can the agent invoke tools outside its assigned workflow?

What happens when the model generates an unexpected action?

Can the enterprise interrupt execution?

Can it reconstruct what occurred?

Does the vendor control the mechanisms used to answer those questions?

These issues connect directly to the decision authority framework discussed in Article 4 of this series.

As AI moves from informing decisions to executing them, architectural boundaries become increasingly important.

A vendor-managed agent framework may provide sophisticated controls.

But the enterprise still needs to understand which controls it owns, which controls the vendor operates, and which responsibilities remain shared.

Delegating agent execution to a vendor does not eliminate the enterprise’s responsibility for the decisions those agents make within its business operations.

The Architecture Must Preserve Enterprise Authority

One of the most important design principles for enterprise AI is the separation of model capability from organizational authority.

A model may be capable of selecting and invoking a tool.

That does not mean the model should independently determine whether the action is authorized.

The enterprise should establish enforceable boundaries governing access to systems, data, and business transactions.

Those boundaries may include:

• Scoped service identities and access permissions.
• Tool-level authorization.
• Transaction limits and approval requirements.
• Business rule validation.
• Segregation of duties.
• Execution logging and monitoring.
• Suspension and revocation mechanisms.
• Independent verification of consequential actions.

The appropriate controls depend on the application.

The architectural principle is consistent.

Business authority should remain enforceable independently of the model’s instructions or preferences.

For example, an AI agent authorized to recommend supplier payments should not automatically possess unrestricted payment execution privileges.

A model instruction stating that payments above a particular amount require approval is not equivalent to a transaction system enforcing that limit.

The distinction becomes especially important when vendor platforms provide both the intelligence layer and the execution environment.

The enterprise should determine whether authorization can be enforced through systems it controls rather than relying exclusively on model behavior.

This preserves a meaningful separation between what AI can propose and what the enterprise permits it to execute.

Vendor Updates Are Becoming Architectural Change Events

Traditional enterprise software updates can introduce defects, alter interfaces, or change application behavior.

AI platforms introduce additional variability.

Vendors may update foundation models, modify safety mechanisms, change tool-calling behavior, revise retrieval capabilities, or adjust platform features.

Even when the application interface remains stable, model behavior may change.

A system that previously classified documents consistently may begin producing different results.

An agent may select a different sequence of tools.

A summarization workflow may change how it interprets ambiguous information.

A customer service assistant may respond differently to previously familiar situations.

Not every update will produce material changes.

But the possibility matters when AI is embedded in consequential business processes.

Enterprises should establish evaluation and release-management practices appropriate to the operational importance of each AI capability.

For critical applications, those practices may include controlled model versioning where supported, regression testing, representative evaluation datasets, staged deployment, monitoring, and rollback procedures.

The organization should also understand what change notifications and version controls its vendors provide.

A vendor model update may become an enterprise application change even when the enterprise has not modified a line of its own code.

That is a different operating assumption from treating AI as a static external service.

The Build, Buy, or Assemble Decision Has Architectural Consequences

In Article 8, Build, Buy, or Assemble? The AI Decision Has Changed, we examined why enterprise AI sourcing decisions increasingly involve combinations of commercial products, foundation models, internal applications, and reusable services.

That decision cannot be made solely on the basis of development speed or initial cost.

Each sourcing approach establishes a different relationship between the enterprise and its technology providers.

Buying an AI-Enabled Application

Purchasing a complete AI-enabled application can accelerate deployment and reduce internal development requirements.

The vendor typically controls much of the application architecture, model integration, and operational environment.

This may be appropriate when the capability supports a standardized business function and offers limited strategic differentiation.

However, the enterprise should understand the degree to which its information, workflows, and operational processes become dependent on the vendor’s implementation.

Building a Custom AI Application

Developing an internal application provides greater control over business logic, integration, user experience, and architectural boundaries.

But internal development does not necessarily eliminate vendor dependency.

The application may still rely on commercial foundation models, managed inference services, cloud infrastructure, or proprietary development frameworks.

The enterprise gains control over some architectural layers while remaining dependent on others.

Assembling AI Capabilities

An assembled architecture combines reusable internal components with external models, platforms, and services.

This approach can preserve flexibility and support enterprise-specific differentiation.

It also requires stronger architectural discipline.

The organization must determine which components should remain interchangeable, which interfaces should be standardized, and which dependencies are acceptable.

The objective should not be to eliminate every external dependency.

That would be neither realistic nor economically sensible.

The objective is to make dependencies deliberate.

The most effective AI sourcing decision is the one that aligns architectural control with strategic importance.

Not Every AI Dependency Deserves the Same Treatment

A common mistake in enterprise architecture is applying the same architectural requirements to every technology investment.

AI is no exception.

A departmental assistant used to summarize internal meeting notes does not require the same architectural controls as an AI agent authorized to execute financial transactions.

Similarly, an experimental application may tolerate vendor dependencies that would be unacceptable for a mission-critical enterprise capability.

The appropriate level of architectural independence depends on several factors.

Strategic Consideration	Lower-Dependency Concern	Higher-Dependency Concern
Business criticality	Experimental or supporting function	Mission-critical business process
Decision authority	AI provides information	AI executes consequential actions
Information sensitivity	Public or low-sensitivity information	Confidential, regulated, or strategically sensitive information
Replacement complexity	Standard interfaces and limited customization	Proprietary workflows and tightly coupled integrations
Operational resilience	Temporary interruption is tolerable	Continuous or highly available operation is required
Competitive differentiation	Standardized business capability	Proprietary capability central to competitive advantage

This framework helps leadership determine where vendor dependency deserves additional architectural attention.

For low-consequence applications, accepting greater vendor dependency may be economically sensible.

For strategically important or operationally critical capabilities, the enterprise may need stronger portability, continuity, and architectural control.

The goal is proportionality.

Architectural independence should be an intentional investment decision, not an ideological commitment to avoiding vendors.

The Enterprise Needs an AI Vendor Dependency Map

Traditional enterprise architecture repositories often document applications, technologies, integrations, infrastructure, and business capabilities.

AI introduces dependencies that may not be adequately represented in conventional application inventories.

An enterprise may know which application uses a particular AI platform.

But does it know which model versions support critical workflows?

Which applications depend on vendor-managed retrieval?

Which agents use proprietary orchestration services?

Which enterprise systems can those agents modify?

Which operational processes depend on the availability of a particular model provider?

Which vendor-controlled components would need to be replaced during an exit?

These relationships should become visible within the enterprise architecture.

An AI vendor dependency map can identify:

1. Business capability: Which enterprise function depends on the AI service?
2. AI component: Which model, platform, agent framework, or managed service is involved?
3. Information dependency: Which enterprise data and knowledge sources does it consume?
4. Execution dependency: Which systems can it access or modify?
5. Operational dependency: What happens if the service becomes unavailable or behaves unexpectedly?
6. Replacement dependency: What must change if the provider is replaced?
7. Commercial dependency: Which pricing, licensing, and contractual conditions affect continued operation?

This information supports more than vendor management.

It informs enterprise architecture, investment planning, operational resilience, and technology modernization.

It also allows leadership to identify concentration risk.

An organization may discover that several critical business processes depend on the same foundation model provider, even though those processes were developed by different teams.

That dependency may be acceptable.

But it should not be invisible.

Vendor Exit Planning Is Becoming an Architecture Discipline

Vendor exit planning has traditionally focused on contract termination, data extraction, transition services, and replacement procurement.

AI requires a broader perspective.

An organization replacing an AI provider may need to migrate or reconstruct prompts, retrieval configurations, embeddings, agent workflows, tool definitions, evaluation datasets, and execution mechanisms.

It may need to validate the behavior of a replacement model.

It may need to redesign integrations.

It may need to retrain employees.

And it may need to preserve operational records required for business continuity or accountability.

These requirements should be considered during initial architecture design.

The enterprise does not necessarily need a fully implemented alternative provider.

But it should understand the feasibility, cost, and consequences of replacement.

For critical AI capabilities, a practical exit strategy may involve maintaining portable enterprise data, separating business rules from vendor-specific orchestration, documenting integration contracts, and preserving evaluation datasets.

It may also involve contractual provisions governing data export, transition assistance, service continuity, and notification of material changes.

The objective is not to assume that a vendor relationship will fail.

It is to avoid designing an enterprise capability that cannot survive a change in that relationship.

A vendor exit strategy that exists only in the contract is incomplete if the architecture cannot support the exit.

The Economic Consequences of Architectural Dependency

AI vendor dependency also influences long-term operating economics.

An enterprise may initially select a provider because of attractive pricing.

Over time, applications become integrated with proprietary services.

Workflows are optimized for specific model behavior.

Operational teams develop specialized expertise.

Business processes become dependent on the platform.

The cost of switching increases.

That changes the enterprise’s negotiating position.

A future price increase may be economically tolerable because replacing the provider would cost even more.

A change in licensing terms may be difficult to resist.

A vendor may discontinue a feature on which critical workflows depend.

These are familiar enterprise software risks, but AI can introduce additional complexity through behavioral dependencies and model-specific application design.

The economic analysis should therefore include the cost of future change.

This does not mean selecting the cheapest or most portable provider.

A tightly integrated platform may deliver sufficient business value to justify substantial switching costs.

But those costs should be understood as part of the investment decision.

The total cost of an AI vendor relationship includes not only what the enterprise pays to use the service, but also what it may eventually cost to change it.

The CIO’s Architectural Responsibility

AI vendor selection cannot remain exclusively a procurement or application development decision.

The CIO must ensure that sourcing choices support the enterprise’s long-term architecture.

That requires understanding how individual vendor decisions affect shared capabilities, information access, integration, operational resilience, and future flexibility.

Different business units may independently adopt AI platforms.

Each may achieve legitimate local benefits.

But the enterprise may gradually accumulate overlapping models, incompatible agent frameworks, duplicate retrieval services, and fragmented monitoring mechanisms.

Without architectural coordination, vendor decisions can produce complexity that becomes difficult to reverse.

The CIO should establish principles governing when vendor-specific capabilities are acceptable, when shared enterprise services should be used, and when architectural independence is strategically important.

These principles should not prevent experimentation.

They should establish a path from experimentation to sustainable enterprise operation.

The CIO must also ensure that critical AI dependencies are visible to executive leadership.

A model provider supporting a mission-critical business process should not be treated as an incidental technical supplier.

Its role should be understood in the context of enterprise architecture and operational continuity.

The Boardroom Question

Imagine management presenting a proposal to expand an AI platform across several business functions.

The vendor offers advanced models, integrated agent development tools, managed retrieval, and workflow automation.

The business case projects substantial productivity improvements.

The implementation timeline appears attractive.

A director asks:

“If this vendor became unavailable, changed its platform, or substantially increased its prices, which parts of our business would be affected?”

That question requires more than a procurement response.

It requires an architectural explanation.

Management should be able to identify the business capabilities dependent on the vendor.

It should understand which information and operational processes are involved.

It should know whether alternative providers are technically and operationally viable.

And it should understand the likely cost and disruption associated with replacement.

A second question is equally important:

“Which decisions and operational controls remain under our authority, regardless of which AI provider we use?”

The answer reveals whether the enterprise has preserved meaningful control over its business operations.

Boards do not need to select AI models or design integration architectures.

They do need confidence that management understands the strategic consequences of vendor dependency.

The Executive Imperative

Artificial intelligence is changing the relationship between enterprises and their technology providers.

AI vendors increasingly supply capabilities that influence how organizations interpret information, coordinate work, make decisions, and execute business processes.

That makes vendor selection an architectural decision.

The enterprise must understand dependencies involving models, platforms, data, integration, operations, and economics.

It must distinguish technical portability from operational and behavioral portability.

It must establish enforceable boundaries between AI capability and business authority.

It must recognize that vendor updates can affect enterprise application behavior.

And it must ensure that strategically important dependencies remain visible within enterprise architecture.

The objective is not to eliminate vendor relationships.

External providers will remain essential to enterprise AI.

The objective is to ensure that those relationships support business strategy without creating dependencies the organization does not understand or cannot manage.

Enterprise leaders should evaluate AI vendors according to the business capabilities they enable, the architectural control they require, and the long-term consequences of adopting their platforms.

They should also recognize that vendor relationships become more consequential as AI systems gain operational authority.

The deeper an AI vendor becomes embedded in enterprise execution, the more important it becomes to understand exactly what the enterprise has delegated—and what it must retain.

Your AI vendor may begin as a technology supplier.

Over time, it may become part of the architecture through which your enterprise operates.

That transition should never occur accidentally.

Because when your AI vendor becomes part of your architecture, your vendor strategy becomes part of your enterprise strategy.

References

International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 42001:2023: Information Technology—Artificial Intelligence—Management System. Geneva: ISO, 2023. https://www.iso.org/standard/81230.html.

National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1. Gaithersburg, MD: U.S. Department of Commerce, January 2023. https://doi.org/10.6028/NIST.AI.100-1.

National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. NIST AI 600-1. Gaithersburg, MD: U.S. Department of Commerce, July 2024. https://doi.org/10.6028/NIST.AI.600-1.

The Open Group. The TOGAF Standard, 10th Edition. Reading, UK: The Open Group, 2022. https://www.opengroup.org/togaf.

Williamson, Oliver E. The Economic Institutions of Capitalism: Firms, Markets, Relational Contracting. New York: Free Press, 1985.

Coming Next

Article 10 — AI Does Not Automate Jobs. It Reconstructs Work.

Much of the enterprise AI conversation focuses on how many jobs artificial intelligence might automate or replace.

That framing overlooks a more important transformation.

AI is beginning to change how work is decomposed, coordinated, executed, and evaluated across the enterprise.

The next article examines why AI-driven transformation should begin with business processes and work design rather than job titles, and how organizations can rethink the division of responsibilities among employees, software applications, and autonomous agents.