Dependency Is Not Dependence
Scrydon joined NVIDIA Inception this month. For a company that sells sovereign AI, that needs a sentence of explanation, and the sentence is this: a supplier you buy from is a dependency; a service you cannot operate without is dependence. Sovereignty is about the second, not the first — and most procurement checklists confuse them.
Scrydon was accepted into NVIDIA Inception this month. We also joined Microsoft for Startups. Both are programmes for early-stage companies run by the vendors whose hardware and cloud sit under most of the AI being built today, and both come with a badge that now sits on our partners page, under its own heading, next to a note that it is neither a partnership nor an endorsement.
If you have read anything we have written about sovereignty, you may reasonably ask whether a European company that sells air-gapped AI has just contradicted itself by joining two American vendor programmes. We do not think so, and the reason is a distinction that sovereignty debates keep collapsing: dependency is not dependence.
Two words that get used as one
A dependency is something you rely on someone else to supply. Once supplied, it is yours: you operate it, you decide when it runs, and nobody has to keep agreeing for it to keep working. A car is a dependency on a manufacturer. A hardback is a dependency on a publisher.
Dependence is when the thing only works for as long as someone else keeps consenting. A leased car with a remote immobiliser. An e-book you licensed and cannot open once the store closes. A model endpoint that returns an error the morning after a directive is signed in another capital.
Both involve a foreign supplier. Only one of them is a sovereignty problem. The European debate treats them as the same thing, which produces two failure modes: organisations that reject every dependency and end up with nothing that works, and organisations that accept every dependence because "we depend on America anyway".
The useful question is not who did you buy this from. It is who has to keep saying yes for it to work tomorrow.
Apply the five tests to a GPU
Earlier this autumn we published five tests that separate the adjective "sovereign" from the property: jurisdiction, keys, operating staff, disconnected mode, exit. Run them against the same accelerator bought two ways.
Owned, in your rack: the hardware sits in your building under your law. Once it has cleared customs, no foreign court has a lever on it. Rented by the hour: the hardware sits in the provider's building under the provider's law, and the provider's parent company answers to a third.
Owned: there are no keys in anyone else's hands. Your data is encrypted with your keys on your disks, decrypted in your memory. Rented: the provider holds the keys unless you bring your own, and even then you are trusting an attestation rather than a lock you can see.
Owned: your people, or a European operator you contracted, hold root. Rented: the provider's staff hold root, and the provider's support process decides who among them can reach your tenant.
Owned: unplug the uplink and the card keeps computing. Nothing in the driver stack needs to phone home for the arithmetic to happen. Rented: disconnected mode does not exist. The uplink is the product.
Owned: you already own it. Exit is a question about your next purchase, not about this one. Rented: exit is an egress bill, a re-platforming project and a contract notice period.
Same chip. Same vendor. One is a dependency, the other is dependence. That is why every deployment target the AI OS supports, from an air-gapped cluster inside a ministry to an on-premises estate at a bank, runs on NVIDIA accelerators that the customer owns, and why we have never treated that as a contradiction.
A dependency is still a dependency
None of this makes the supply side risk-free, and we would rather say so than be caught pretending otherwise.
The first three are real. They are also risks you take before the purchase, and the June episode that cut a European lab off from frontier models overnight demonstrated the difference: nobody came to collect the GPUs. Hardware that has cleared customs and sits in your building is not subject to a kill switch. The dependency is real; the dependence is not.
Two things reduce even the supply-side dependency. Buy for the horizon of the workload rather than the horizon of the budget cycle, so that a change in allocation or policy is a problem for the next procurement rather than the current one. And do not design the platform around one vendor's services: an accelerator is an accelerator, and the layer above it belongs to you.
Why we joined, and what it does not mean
Inception gives us NVIDIA's engineering resources and technical training, earlier visibility of what is coming, and preferred pricing on the hardware our customers deploy. For a company whose customers buy their own accelerators, that last item is the one that matters: it lowers the cost of the dependency without creating a dependence.
Microsoft for Startups gives us Azure credits and technical resources for building and testing the platform there. Azure is one deployment target among several, chosen by the customer when hyperscale capacity matters more than the last inch of control, and our AI on Azure page is explicit about which controls survive that choice: EU regions, keys you hold, confidential computing where the workload demands it. A programme membership does not move a single key.
What neither membership means: no vendor endorses the AI OS, no vendor is a partner in the contractual sense, and no vendor appears in your audit trail. The programmes' own brand rules say the first two, and our architecture says the third.
If you are the one signing
Take your current AI estate and sort it into the two columns. Not by supplier nationality, which tells you almost nothing, but by the question above: who has to keep saying yes?
- Dependencies you can manage with procurement: second sources, stock, longer horizons, a lifecycle plan.
- Dependences you can only manage with architecture: where the keys are, who holds root, whether the thing runs with the cable pulled, and what leaving costs.
Most organisations we meet have a long list in the first column and have never written the second one down. The second column is where sovereignty lives. On 1 October, Cornelia and Xavier take the security officer's view of AI agents inside a NIS2 essential entity, including the decision table for when air-gapped is the answer, which is the shortest way we know to work out what belongs in the second column.