AI Must Be Interoperable and Reversible

The goal is enterprise capability—not model selection

Enterprise AI strategy is often framed as a selection exercise.

Which model should the organisation choose? Which provider should become strategic? Should the architecture be externally hosted, embedded in an existing productivity platform, deployed in a private cloud or operated on premises?

These are necessary decisions.

They should not become permanent bets.

The goal of enterprise AI should be to create an enduring capability that remains interoperable and reversible as models, providers, deployment patterns, economics and organisational requirements change.

The enterprise should be able to use the best available intelligence for a particular request without surrendering control of the data, systems, policies and evidence that make the request valuable.

An enterprise should invest in the capability to use AI—not in a prediction about which model or architecture will win.

This follows directly from the requirement established in The Control Plane Must Be Yours. Once the enterprise owns the enforcement point, the model and the provider can remain replaceable.

Extraordinary capability is arriving through different architectures

The market is not converging on one form of enterprise AI.

Frontier services from providers such as OpenAI, Anthropic and Google deliver extraordinary general-purpose reasoning, language, coding, multimodal and agentic capability through externally operated platforms and APIs. They improve rapidly and allow enterprises to consume advanced intelligence without operating the underlying model infrastructure.

A second pattern is ecosystem-native AI.

Microsoft 365 Copilot operates within the Microsoft 365 service boundary and grounds requests using information available through Microsoft Graph under the signed-in user’s existing permissions. Gemini Enterprise combines models, enterprise search, agents and connectors to Google and third-party information sources.

For organisations already standardised on Microsoft or Google platforms, these offerings can be especially valuable. Their usefulness comes not only from the model, but from the identity, content, permissions, applications and governance architecture surrounding it.

A third pattern gives the organisation greater control over the model runtime.

Mistral supports self-deployment of open-weight models on customer infrastructure. Cohere supports private deployment in customer-controlled cloud and on-premises environments, including network-isolated deployments. Google’s Gemma family provides open models in different sizes and specialisations that can be selected, tuned and deployed across local, edge, cloud and enterprise infrastructure.

NVIDIA is accelerating this pattern. NVIDIA AI Enterprise and NVIDIA NIM package models as optimised inference microservices that can run across cloud, data-centre, workstation and edge infrastructure. NVIDIA describes an expanding portfolio of open model families—including Nemotron for agentic AI—and an enterprise AI factory architecture through which organisations can build and deploy AI on premises. Its NIM model catalogue is intended to make thousands of open models deployable through standard APIs, while newer model releases can be packaged rapidly for NVIDIA-accelerated infrastructure.

This matters because on-premises AI is no longer limited to a small set of static models selected once and operated indefinitely. The stated direction is towards a growing, production-supported ecosystem of open and specialist models that can be introduced into enterprise-controlled infrastructure as capabilities improve.

These architectures may be preferred where sovereignty, network isolation, predictable performance, infrastructure control, domain tuning or the ability to keep prompts and outputs entirely inside the organisation is decisive.

None of these patterns invalidates the others.

They provide different combinations of capability and control.

There may be no single winner

The AI market is often discussed as though one model provider will eventually dominate every workload.

That is not a useful enterprise architecture assumption.

Models differ across tasks. They improve at different speeds. A provider that leads in coding may not lead in multilingual classification, document processing, multimodal reasoning, low-latency extraction or a specialised industry task. A smaller model may outperform a larger model when it has been tuned for a narrow domain. An internally deployed model may be less capable in general reasoning but uniquely appropriate for an isolated or sovereign environment.

The same model may also be appropriate for one request and unacceptable for another.

A request based entirely on public information may be sent safely to an externally hosted frontier model. A request containing protected health, financial, defence or citizen information may require redaction, in-country processing or an internally operated model. A high-volume classification task may justify a smaller and cheaper model. A consequential engineering or legal question may justify a more capable model, stronger evaluation and human approval.

The enterprise decision is therefore not simply:

Which model is best?

It is:

Which model, deployment and control pattern is best for this request, under these requirements, at this moment?

Every request has functional and non-functional requirements

Model selection is usually evaluated through functional capability: can the model perform the task?

Enterprise architecture must ask a second set of questions.

Can the task be performed under the conditions the organisation requires?

TomorrowX treats these conditions as part of the system boundary. As described in Components, boundaries and non-functional requirements, a functionally correct result may still be unacceptable if it is too slow, insufficiently resilient, processed in the wrong location or impossible to audit.

The best model is not necessarily the model with the highest benchmark score.

It is the model that produces the required outcome while satisfying the complete set of functional and non-functional requirements.

Model choice becomes a routing decision

In a model-diverse enterprise, the request should not be permanently wired to one provider.

It should be evaluated and routed.

1. Request and purpose
2. Identity, data classification and policy
3. Functional and non-functional requirements
4. Eligible models and deployment patterns
5. Selected model, controls and fallback
6. Evaluation, action and evidence

This does not imply that every request requires a complex auction between every available model. Many requests will follow stable, pre-approved routes. Some workloads will remain dedicated to one model because their tuning, economics or operating requirements justify it.

The architectural principle is that the route remains explicit and changeable.

When a better model becomes available, a provider changes its terms, a jurisdictional requirement changes or an internal model reaches the required capability, the enterprise can revise the route without redesigning every consuming application.

Model selection should become champion–challenger operation

Interoperability should not be used only when a provider fails or a contract changes.

It should create a continuous method for improving value.

In model management, the current production model can be treated as the champion. One or more alternative models, model versions, prompts, routes or deployment patterns become challengers. Each challenger is evaluated against the same representative requests, expected outcomes and non-functional requirements.

For some processes, this may be a controlled A/B test. For others, it may be A/B/C or multi-model testing conducted in shadow mode before any output is allowed to influence the live process. The number of challengers is less important than the discipline: all candidates must be measured against the same definition of value.

This is consistent with the logic of Six Sigma and continuous improvement: define the required outcome, measure current performance, analyse variation, improve the process and retain control over the resulting standard. Champion–challenger testing applies that discipline to intelligence itself.

The champion should therefore not be the model that won a benchmark or procurement process months earlier.

It should be the currently approved route that produces the optimum enterprise value under observed operating conditions.

Interoperability is more than API compatibility

A common API shape can make models easier to call.

It does not by itself make enterprise AI interoperable.

Models differ in prompt structure, context limits, tool use, output formats, safety behaviour, latency, pricing, data controls and supported deployment locations. Enterprise applications also differ in the data they may expose and the actions they may permit.

True interoperability therefore requires a stable enterprise contract above the models.

That contract should define:

• the business purpose of the request;
• the identity and authority of the requester;
• the information required and its classification;
• the expected result and validation criteria;
• the actions that may follow;
• the acceptable security, privacy, sovereignty, performance and price envelope; and
• the evidence needed to reconstruct the decision.

Provider-specific invocation can then sit beneath that contract.

The enterprise application asks for a capability. The control architecture determines how that capability is fulfilled.

Reversibility is the practical test of control

Interoperability creates choice.

Reversibility proves that the choice remains real.

An AI architecture is not meaningfully reversible if changing models requires every application to be rewritten, every security review to restart, every data connection to be rebuilt and every operating team to learn a new control framework.

Reversibility means that a model, agent or provider can be introduced, compared, constrained, replaced or removed without transferring unnecessary disruption into the systems around it.

This is not only an exit strategy.

It is a normal operating capability.

The enterprise may use reversibility to:

• move a workload from an external model to an internally hosted model;
• use a frontier model temporarily while an internal model is trained or validated;
• replace a model whose performance has regressed;
• route around a provider outage or capacity constraint;
• compare a new model against the current production model in shadow mode;
• respond to a change in price, retention, location or contractual terms; or
• retire an AI capability without changing the underlying enterprise system.

A reversible architecture allows the organisation to adopt strong capability earlier because the decision is not irreversible.

The control plane must not become another lock-in point

A model router operated entirely by one provider may simplify access to that provider’s preferred ecosystem.

It does not necessarily create enterprise independence.

The control plane responsible for model selection, data access and action authority should remain customer-controlled and vendor-independent. It should be able to evaluate external frontier models, ecosystem-native assistants, private deployments and internally operated models without making any one of them the enforcement authority for the others.

This is why placement matters.

The control plane must sit in the interaction path between the request, the selected intelligence and the enterprise resources involved. It must be capable of acting before protected data is disclosed and before a consequential action reaches the underlying system.

The provider may supply intelligence.

The enterprise must retain the decision.

The role of Data Mediation

Data Mediation creates a stable enterprise layer between AI capability and the systems, data and actions that capability seeks to use.

A Programmable Data Agent can terminate an interaction, establish context and apply policy before re-originating only what is permitted. It can transform a provider-specific request, redact or encrypt sensitive fields, select a model, enforce cost or token limits, validate a response, invoke an alternative route and retain evidence of what occurred.

Importantly, this capability is not embedded inside the model or the application being protected.

The model can change while the enterprise contract remains.

The provider can change while the access policy remains.

The deployment location can change while the consuming application remains.

The functional logic and the non-functional requirements can be governed as one solution without becoming properties of a single AI vendor.

Value is not the same as lowest inference price

Price must be part of the routing decision.

But the cheapest token is not necessarily the cheapest outcome.

A lower-cost model may require more retries, more human review or a larger prompt to produce an acceptable result. A higher-capability model may complete the task in one pass. An internally hosted model may have attractive marginal economics at sustained volume but introduce infrastructure, energy, support and capacity costs. A platform-native assistant may reduce integration effort because it already operates within the enterprise’s content and identity architecture.

The relevant measure is the total value of the completed request:

Required outcome quality, achieved within the permitted risk, performance and cost envelope.

A customer-controlled control plane can make that value decision explicit rather than allowing model choice to follow whichever provider an application happened to integrate first.

Model change should become routine

Enterprise architectures have historically treated major platform substitution as a transformation programme.

AI changes too quickly for that operating model.

Models will improve, regress, specialise, become unavailable, change price and appear in new deployment forms. Organisations will also learn more about where particular models perform well and where they do not.

Model evaluation, comparison and replacement should therefore become part of normal operations.

The approved route becomes the champion. New models, model versions, prompts and deployment patterns enter as challengers. They can be tested against retained enterprise scenarios, run in shadow mode and compared using the same quality, risk, performance and cost measures. Traffic can then be shifted progressively when a challenger demonstrates superior value.

The result is a controlled improvement cycle: define, measure, analyse, improve and control. A challenger is not promoted because it is newer. It is promoted because evidence shows that it produces a better enterprise outcome within the required boundaries.

A failed change can be reversed without changing the underlying system. The previous champion remains available as a fallback, while the evidence from the test becomes part of the next evaluation cycle.

This moves enterprise AI away from provider selection as an occasional procurement event and towards intelligence management as a continuous quality discipline.

Conclusion

OpenAI, Anthropic, Gemini and Microsoft Copilot are delivering extraordinary capability through externally operated and ecosystem-native architectures.

Mistral, Cohere, Gemma, NVIDIA’s expanding open-model ecosystem and other open-weight models create different opportunities for private, sovereign, tuned and on-premises deployment.

The enterprise should be able to use all of these patterns where they create value.

It should not have to make one of them permanent.

The durable enterprise asset is the customer-controlled architecture that understands each request, applies its functional and non-functional requirements, selects an eligible model, governs the data exchange, constrains the resulting action and retains the evidence.

That architecture makes intelligence interoperable.

Its ability to change the route makes intelligence reversible.

Together, those properties allow the organisation to invest confidently in AI capability without betting which model, provider or architecture will win.