> ## Content Index > Fetch the complete content index at: https://www.the-thinking-lens.com/llms.txt > Use this file to discover other available public pages before exploring further. # Rent the Compute. Protect the Context. - URL: https://www.the-thinking-lens.com/rent-the-compute-protect-the-context/ - Published: 2026-10-22T09:35:43.000Z - Updated: 2026-10-22T13:13:20.000Z - Description: Cloud sovereignty is not about owning every layer. Use the strongest available technology, preserve credible alternatives for critical dependencies, and protect the context competitors cannot recreate. - Author: Amodiovalerio Verde - Tags: #lens-product-discovery *\[Views are my own. Not legal or compliance advice.\]* *This is the first article in an exploration of technological sovereignty.* I was recently asked a question about cloud sovereignty: > How much control do you actually need? My first reaction was: probably not as much as the word “sovereignty” suggests. I do not think every European company needs European infrastructure for every workload. If a global provider can give me better compute, cheaper inference, more capacity, better tooling or access to a frontier model, there is a good reason for using it. Refusing better technology simply because it comes from somewhere else does not make a company sovereign. It may just make it slower. But I kept thinking about the question, because “how much control?” hides several different decisions inside one word. Control over what? The infrastructure? The model? The ability to keep operating? The data? Those are not the same thing. And I am increasingly convinced they should not have the same level of risk I'd accept. --- ## Sovereignty is not the same as ownership The European Commission’s Cloud Sovereignty Framework is interesting partly because it does not define sovereignty as one thing. It separates strategic, legal, data and AI, operational, supply-chain, technological, security and other dimensions. It explicitly considers questions such as dependency on non-EU technology, control over data, interoperability and the ability to migrate workloads. I think that breakdown is useful. Because there is a version of the sovereignty discussion that sounds like this: > If we want control, we need to own the stack. I am not convinced. Companies have always built on things they do not own. We rent buildings. We buy electricity. We use telecommunications networks. We run software on somebody else's infrastructure. Owning something is one way to keep control, but not the only way. I am more interested in what happens if I need to change providers. Can I leave? Can I replace it? How long would it take? What would stop working? What would I lose? That makes me think about one important dimension of sovereignty less as ownership and more as **credible optionality**. Legal, operational and data control still matter, but so does the ability to change dependencies when circumstances change. --- ## I am more comfortable renting capacity than dependency Compute, storage, memory, GPUs, CPUs and increasingly inference capacity are inputs. Important inputs, sometimes scarce inputs, but still inputs. If one provider can supply them more efficiently than another, there is a good reason to use that provider. The mistake is not using the best provider. The mistake is designing the business so that the provider becomes impossible to replace. That risk is not theoretical. In June 2026, the European Commission said in a preliminary DMA assessment that AWS and Azure benefit from lock-in effects, high switching costs and large ecosystems, and described their AI tools and partnerships as increasingly important to cloud purchasing decisions. The obvious response might be to avoid them. I think that goes too far. I would use the better global service when it gives the business an advantage. But if a critical service goes down, I want another provider we can actually switch to. That alternative might be slower or less capable. It just needs to keep the important work running. That alternative does not necessarily need to be at the frontier. This is the part I initially found counterintuitive. We often think a backup must be just as good. If the primary system can do 100, the backup must also do 100. But that depends on what the backup is for. If its job is business continuity, negotiating leverage and the ability to operate through disruption, it does not necessarily need the same performance. It needs to preserve the critical functions of the business within an acceptable recovery window. **The second source does not need to win the benchmark.** It needs to make exit credible. A theoretical second source is not a second source. If switching requires eighteen months of rewriting, new security approvals, moving data, retraining teams and rebuilding integrations, you do not have redundancy. You have a diagram. So sovereignty at the infrastructure layer becomes an architecture question: > How much performance am I willing to trade for the ability to move? That answer will be different for every workload. --- ## Then I get to data, and my risk tolerance changes I would not apply the same reasoning to data. Not because all data creates competitive advantage. Some data is essential for running a business, but that does not make it hard for competitors to recreate. Generic data is getting easier to find, copy, combine, synthesise and enrich. **A dataset does not become a moat because it contains a lot of rows.** What interests me is a narrower category. Data that is: - proprietary; - difficult for a competitor to reproduce; - continuously refreshed through the operation of the product or business; - connected to a real customer or domain problem; - capable of improving the decisions, products or models built on top of it. I have started thinking of this as **novel data**. Not novel in a legal sense. I mean hard for competitors to recreate. Information that tells you something competitors cannot easily know. - A customer interaction that exposes how a workflow really happens. - A sequence of operational decisions accumulated over years. - A proprietary relationship graph. - Domain-specific corrections made by experts. - Behavioral signals created by the use of your product. - Outcome data connecting an action to what happened afterwards. Those things are different from compute. I can potentially buy another GPU. I cannot necessarily recreate ten years of interactions. --- ## Data is not automatically a moat OECD work makes this distinction quite well. Research on AI adoption found firms often prefer specialized proprietary datasets because they can provide competitive advantage, while broader OECD work on AI competition notes that many general training datasets are non-unique or substitutable. Both can be true. I have written before about [the difference between accumulating data and accumulating knowledge](https://www.the-thinking-lens.com/from-data-informed-to-knowledge-driven/). I think the same distinction matters here. The strategic asset is not the dataset itself. It is the context and learning that become difficult for somebody else to reproduce. More recent OECD research makes a related point: proprietary data and the feedback it generates can create an advantage that competitors struggle to match. That matters more as more companies gain access to AI. If several companies can access similar frontier models, similar cloud infrastructure and increasingly similar software capabilities, differentiation has to come from somewhere else. One possible source is the information wrapped around the model. What makes the difference is often the context around the model: what you know about your customers, the feedback your product collects, and the decisions the business has learned from over time. This is where I become more cautious. There is also an important distinction between information a company owns and information it is entrusted to process on behalf of customers. Especially in enterprise software, creating a competitive advantage from context cannot come at the expense of customer ownership, confidentiality or agreed usage rights. The opportunity is to build something better with data the company has the right to use and learn from. --- ## Legal to transfer does not mean strategically sensible to transfer Europe already places significant requirements around some forms of data movement. Under GDPR, transfers of personal data outside the EEA require appropriate mechanisms and safeguards, depending on the destination and circumstances. Those controls matter. But compliance is not the question I am interested in here. **Something can be legally transferable and still be strategically unwise to transfer.** Those are different tests. Imagine I have a dataset that contains no problematic personal information and is perfectly lawful to process through an external service. That resolves one question. It does not resolve this one: > Am I comfortable giving another organization access to information that helps make my company different? Maybe the answer is yes. Contracts, isolation, encryption, retention rules and technical controls can change that risk substantially. The answer should not automatically be no. But the decision deserves a different level of scrutiny from renting another thousand GPUs. Because the downside is different. Infrastructure dependency can restrict my ability to operate. Information dependency can affect my ability to differentiate. --- ## AI makes the boundary harder to see We used to have relatively visible boundaries between infrastructure and information. I stored data somewhere. I processed it somewhere. I could draw the boxes. AI makes harder to track where data goes. An employee pastes internal material into a model. A retrieval system sends context into an inference service. An agent combines customer information, internal documents and external tools. A coding assistant sees proprietary code. An evaluation platform records prompts and outputs. A model gateway logs requests so that the company can understand usage. Suddenly “which cloud are we using?” is not a sufficient question. Neither is “where is the data stored?” The better question may be: > What information crosses which boundary, for what purpose, under whose control, and what happens to it afterwards? That is not really a cloud question anymore. It is an operating-model question. --- ## Maybe sovereignty should be selective I started with “How much control do you need?” I now think the question is too broad. I would separate at least three things. **Capacity.** Compute, storage, memory and infrastructure. Here I am relatively comfortable sourcing globally, while making sure I can switch providers where dependency would become dangerous. **Capability.** Models, APIs and specialized technology. Here I would use the best available capabilities, but avoid designing critical workflows around a single provider where there is no practical alternative. For important use cases, I want a credible second path. Not necessarily equal. Credible. **Context.** The proprietary data and knowledge that make the first two layers valuable to my business. Here my threshold becomes much higher. The more novel, difficult to reproduce and strategically useful the information is, the stronger the reason to control where it goes and what others are able to do with it. These categories overlap, and reality is messier than three boxes. But separating them changes the discussion. When making these decisions, I would ask four questions: What must remain under our control? What can we safely source externally? How quickly could we replace a dependency if necessary? And what information would be impossible to recover if we exposed it? --- ## The thing I actually want to preserve is optionality There is a tension here that I do not think Europe can avoid. If sovereignty means European companies must refuse the strongest global technology until a European equivalent exists, sovereignty can become a competitiveness tax. But the opposite creates its own problem. A company might get cheaper, better technology today but lose the ability to switch providers later. And if the same setup exposes information it cannot recreate, the consequences could be much harder to manage. Neither extreme looks particularly attractive. Perhaps that is the distinction I was missing when I first heard the phrase “cloud sovereignty.” The scarce resource may not be the cloud. It may not even be the model. As capabilities become easier to access, one of the things that remains genuinely yours is the context you have accumulated around them. > **If everyone can eventually rent similar intelligence, what information are you creating today that they cannot rent tomorrow?** --- ## Sources - European Commission (2026). [Sovereign Cloud Framework explained](https://commission.europa.eu/news-and-media/news/sovereign-cloud-framework-explained-2026-06-01%5Fen?ref=the-thinking-lens.com) - European Commission (2026). [Cloud Sovereignty Framework: Implementation Guidance](https://commission.europa.eu/document/download/2ad80a48-166f-4c77-a513-80c53ca2a128%5Fen?filename=Cloud+Sovereignty+Framework+-+Implementation+guidance.pdf&ref=the-thinking-lens.com) - European Commission (2026). [Commission reaches preliminary position that Amazon's and Microsoft's market-leading cloud services should be designated under the DMA](https://digital-markets-act.ec.europa.eu/commission-reaches-preliminary-position-amazons-and-microsofts-market-leading-cloud-services-should-2026-06-25%5Fen?ref=the-thinking-lens.com) - OECD/BCG/INSEAD (2025). [The Adoption of Artificial Intelligence in Firms: New Evidence for Policymaking](https://doi.org/10.1787/f9ef33c3-en?ref=the-thinking-lens.com) - OECD (2025). [Artificial Intelligence and Competitive Dynamics in Downstream Markets](https://doi.org/10.1787/ccf0624a-en?ref=the-thinking-lens.com) - OECD (2026). [Artificial Intelligence Markets: Recent Developments and Competition Issues](https://doi.org/10.1787/d531d73f-en?ref=the-thinking-lens.com) - European Commission. [Rules on International Data Transfers](https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/rules-international-data-transfers%5Fen?ref=the-thinking-lens.com)