Palantir and Secure Cloud Sovereignty

Sovereignty in cloud and software has become a slogan, which is unfortunate, because underneath the slogan is a precise and answerable question: if relations with the supplier’s home government deteriorated, what would you lose and how quickly. Most organisations have never worked that through, and the ones that have are usually surprised by the answer.

Data residency is the part everyone discusses and the least important. Keeping data in a domestic region addresses a legal concern about jurisdiction. It does nothing about dependency on the supplier’s engineering, update pipeline, support organisation or continued willingness to serve you.

Four distinct dependencies

It helps to separate them. Jurisdictional dependency concerns which government can legally compel access. Operational dependency concerns whether the system keeps running without the supplier. Knowledge dependency concerns whether anyone in your organisation understands what has been built. Supply dependency concerns whether you can obtain updates and support at all.

A domestic hosting region addresses only the first, and partially. The other three are addressed through contract terms, staffing decisions and architecture, and they are where the real exposure usually sits. An organisation can hold all its data domestically and still be unable to operate for six months if the supplier withdraws.

The ontology is the asset to protect

In a platform deployment the thing with the longest-lasting value is not the software and not even the raw data. It is the model: the agreed definitions, the resolved entities, the pipelines encoding years of institutional knowledge about what a record actually means. That is the genuinely expensive artefact and the one most likely to be contractually ambiguous.

Any sovereignty position worth the name therefore includes an explicit right to export the ontology and the pipeline logic in a documented, usable form, and a regular test that the export actually works. An export clause nobody has exercised is a clause that will fail when it is needed.

The sovereign foundry debate

There is a continuing argument in the UK and across Europe about whether to build a domestic equivalent of the major data platforms. The case for is obvious. The case against is that the capability took the better part of two decades to build, that the hard part is the ontology tooling and the delivery mechanism rather than the analytics, and that a half-funded national alternative is worse than a well-governed commercial dependency.

The more realistic middle position is sovereign capability in the layers that matter most: own the model, own the domain logic, retain national engineering capacity, and keep the commercial platform in the role of replaceable infrastructure. That is less satisfying than a flagship national programme and considerably more likely to work.

Supply chain and the offline case

A dependency that receives too little attention is the software supply chain itself. Modern applications assemble dozens of third-party packages from public registries, and in an accredited or disconnected environment the ability to obtain, verify and deploy those packages is a sovereignty question in miniature.

This is one reason our own PAL.NET SDK is distributed as licensed offline bundles as well as through authenticated feeds. An environment that cannot reach a package registry still needs a supported, verifiable route to its dependencies, and pretending otherwise produces unmanaged copies of libraries that nobody is patching.

A test worth running

Ask the question concretely. If this supplier stopped supporting us tomorrow, what breaks immediately, what degrades over a quarter, what could we rebuild and how long would it take. Write the answers down and circulate them. The exercise usually reveals that the dependency is in a different place from where the policy assumed, and it is considerably cheaper than discovering that during a crisis.

AIC works with customers on exactly this layer: owning the model, keeping deployments maintainable, and retaining the engineering knowledge inside the organisation rather than inside the vendor.