Portability

Portability is the ability to run the same workload somewhere else without rewriting it. In BROCS it is not a hedge against vendor lock-in. It is a functional requirement, because in a lot of organizations the data is not all in one place and it is not going to be.

The runtime goes where the data is

The sequence that plays out repeatedly: a company adopts an AI platform, it works, and then a business unit says the data for their use case cannot leave their environment. Sometimes that is a regulator, sometimes a customer contract, sometimes a country, and sometimes it is simply a forty-terabyte dataset that is not moving.

At that point there are three options. Move the data, which is usually forbidden or impractical. Exclude the business unit, which means the platform is not the platform. Or run the same system in that environment, which requires that the system was built to be run in more than one place.

The third only exists if you chose it in advance. It is not a feature you add later.

What portability actually requires

It is less about avoiding every managed service and more about where the couplings are.

Package the workload, not the environment. Containers and declarative deployment, so placement is a configuration decision rather than a rewrite.

Abstract the model endpoint. The application asks for a capability; something else decides which provider or local model serves it. That is routing, and it is what lets an on-premise deployment use a local model while the hosted one uses a vendor endpoint, with the same application code.

Abstract the data plane, within reason. Object storage and SQL are portable in practice. Bet on a proprietary queue or a vendor-specific vector service and you have bought a rewrite.

Keep identity federated. The single most painful part of a second environment is usually authentication. Federating to one identity provider from the start is cheaper than reconciling two user directories later.

Keep the control plane thin and the data plane self-sufficient. If a workload in a customer’s datacentre stops serving when your central control plane is unreachable, it is not deployed there in any meaningful sense.

One system, everywhere, is a different claim

The weak version of portability is “we could migrate if we had to”. The strong version, and the one regulated enterprises actually need, is that the same platform runs in all the places at once, managed the same way, with one set of policies.

The difference matters because the weak version still leaves you operating two systems during the years it takes to move. A global organization with a data residency requirement in three jurisdictions does not want a migration path. It wants one system with three placements.

That has a design consequence: placement has to be a property of a workload rather than a property of an installation. If choosing a different region means standing up a parallel copy of your whole platform, you have built the weak version.

Sovereignty is the sharp end

For some organizations this is not a preference. Public sector bodies, healthcare providers, and financial institutions in several jurisdictions have legal constraints on where processing occurs and who can compel access to it.

A platform that can only run in one vendor’s cloud cannot serve those organizations at all, regardless of how good it is. If they are in your market, or you are one of them, portability is a gate rather than a nice-to-have, and the three sovereign paths (local models, models through your own cloud account, and contractually covered endpoints) all have to be live options rather than roadmap items.