When regulation becomes theater and encryption becomes window dressing
By Vektor Memory — 20 min read
It is raining here in the Southern Hemisphere again. It has been raining for three weeks now, nonstop.
I’m sitting with my chai coffee, watching out of the window, and thinking about data sovereignty. It is, genuinely, the kind of thing I think about often. The northern hemisphere is winding up for summer. Europe is getting ready for long evenings and beach holidays. I’m quietly jealous. I’ve always wanted to split the year: six months south, six months north. Endless summer. The perpetual warmth of a life lived chasing the sun.
But here I am. Chai. Rain. Data.
I’ve been turning over one question in particular: why is it that the moment you mention data sovereignty, people immediately reach for GDPR? It’s reflexive, especially among Europeans. Understandable. GDPR is loud, it’s enforced, it has teeth. French, German, and Dutch visitors make up a large disproportionate share of our site traffic at VEKTOR, and the interest in privacy and sovereignty from that audience is intense and genuine. Northern Europeans, by and large, take this seriously in a way that other markets don’t; they are working on ways to disassociate from the cloud around the world.
And yet. How many times have we clicked “Accept All” on a cookie banner in the last week? How many times have you scrolled past a privacy policy that runs to forty-two pages? How many times have you handed over your email address, your location, your device fingerprint, your behavioral patterns not because you wanted to, but because there was no meaningful alternative?
GDPR created the most sophisticated legal architecture for data rights the world has ever seen. It also created the most sophisticated ritual of consent theater the world has ever performed.
That gap, between the law and the lived reality, is what this article is about.
Ubiquitous data centre growth image
The Reflex Problem
When people think of data sovereignty, GDPR arrives first. It’s the loudest signal in the room. Europe built the world’s most formidable regulatory framework for personal data rights, backed it with multi-billion-euro fines, and positioned it as the global standard. Amazon received a €746 million penalty. Meta collected €1.2 billion. The enforcement machinery is real.
But enforcement is not the same as sovereignty.
Carissa Veliz, Oxford philosopher and author of Privacy is Power, draws a distinction most compliance departments would prefer you didn’t notice. The problem, she argues, isn’t that corporations are breaking the rules. It’s that the rules themselves were negotiated within a system that corporations largely designed.
Her central thesis, cutting through the regulatory noise with uncomfortable clarity, is that privacy is not primarily a personal concern. It is a political one. Whoever holds the data holds the power. And most organizations, compliant or not, are still handing the data to someone else.
Veliz identifies three forces that converged to erode privacy before regulators could respond. First, Google’s discovery that personal data was a money engine. Second, the post-9/11 intelligence community’s realization that surveillance could be outsourced to the private sector at zero cost to government. Third, and most insidiously: the deliberate propagation by Big Tech of the idea that privacy is outdated, a relic concern for people who have “something to hide.”
That third point is the one that should give privacy advocates pause. GDPR was built, in part, as a counter-argument to this narrative. But it arrived twenty years after the data economy had already matured. It was retrofitting regulation onto infrastructure that had been deliberately designed before those rules existed.
The result: organizations are legally compliant and practically exposed simultaneously.
A Crisis Hiding in Plain Sight
The numbers tell a story regulators have been slow to acknowledge.
In the past 18 months, 83% of organizations encountered at least one cloud security incident. Not “attempted.” Not “probed.” Encountered, meaning a breach registered, got far enough to matter. And here is the number that gives that statistic its weight: 45% of all data breaches now originate in cloud environments. Not on-premise. Not from external attackers tunneling through firewalls. Inside the cloud architecture that GDPR compliance assumes is secure by default.
The cloud keeps growing anyway.
We are not all in denial; we are stuck between convenience and corporate economics. The alternative is moving petabytes of data into on-premise data centres: staffed by certified engineers, audited quarterly, and air-gapped from vendor dependencies. It exceeds most organizations’ capital budgets by multiples. GDPR didn’t solve the infrastructure problem. It built a legal scaffold around it and called the scaffold sovereignty.
The global cloud computing market sat at roughly $853 billion in 2024 and is forecast to cross $1.6 trillion by 2030. Public cloud alone is projected to exceed $1 trillion in annual spending by 2026. In 2024, global spending on data centre hardware and software grew 34% year over year to $282 billion, with hyperscalers accounting for more than half. Google committed $85 billion in capital expenditure for 2025; AWS projected over $100 billion; Microsoft announced $80 billion in infrastructure expansion. The five largest hyperscalers have collectively planned to add roughly $2 trillion in AI-related assets to their balance sheets by 2030. Data centre construction, which represented 5% of commercial construction spending in 2014, had risen to 32% by 2024 and is projected to reach 40% by 2028. Hyperscale capacity is expected to triple by the end of the decade.
There is a counter-trend worth noting, because it complicates the narrative in useful ways. According to Flexera’s 2025 State of the Cloud Report, 86% of CIOs planned to move at least some workloads from public cloud back to private infrastructure, and 21% of workloads had already been repatriated. But the key word is “some.” IDC’s server and storage survey found that only 8–9% of organizations plan full repatriation. The dominant move is not a retreat from cloud but a redistribution within it: sensitive or cost-predictable workloads pulled back to private or on-premise infrastructure, while bursty or commodity workloads remain on public hyperscalers. The hybrid model is not a compromise. For a growing number of organizations, it is a sovereignty strategy by another name.
Which means the economics are shifting in a direction that makes the original argument sharper, not softer. Organizations are not choosing between cloud and sovereignty as binary options. They are beginning to make explicit architectural decisions about which data lives where and under which conditions. That is progress. It is also, in most cases, still happening after the fact, in response to cost shocks and compliance pressure, rather than as a design principle from the start.
What the human factor data reveals is more troubling still:
65% of cloud security breaches trace back to human error, not software vulnerabilities. 82% of misconfigurations are human decisions, not systemic bugs. 82% of cloud breaches tie to credential failures or Identity and Access Management misconfiguration. These numbers come from separate studies (SentinelOne, Exabeam, StationX) and they converge on the same conclusion: you cannot regulate away human fallibility at the scale required by modern cloud infrastructure.
GDPR assumes organizational competence. Cloud environments assume organizational fallibility. These two assumptions do not resolve.
The compliance cost compounds the irony. Organizations spend an average of $2.7 million annually on privacy compliance. 38% spend more than $5 million. That figure does not include breach remediation, legal costs, or the operational drag of maintaining audit trails. It is purely the recurring tax on compliance. And 80% of those organizations still experience a breach within a 12-month window.
You are spending millions to be compliant. We are not spending millions to be safe.
These are not hypothetical risks. They are playing out in real time, in countries that consider themselves among the world’s more privacy-conscious jurisdictions.
In February 2026, ABC News in Australia broke the story of VIQ Solutions, a Canadian AI transcription company holding Commonwealth contracts to process Australian court recordings. VIQ had subcontracted the work to e24 Technologies, an India-based firm, in direct violation of contract terms that explicitly prohibited offshoring.
The files exposed included proceedings from the Federal Circuit and Family Court, handling domestic violence and child abuse cases, and the Federal Court, which hears national security matters. VIQ staff had raised concerns internally as early as August 2025 and were told to stop spreading rumours. Australia’s privacy regulator opened a preliminary inquiry, while courts and officials said the conduct may have violated contracts requiring data to remain onshore.
By March 2026, VIQ’s Australian subsidiaries had entered voluntary administration. The breach did not happen through a sophisticated cyberattack. It happened because a vendor made a cost-driven decision to offshore sensitive data and assumed nobody would notice. A contract that said “data stays in Australia” provided zero practical sovereignty once the vendor chose to ignore it. Secure-iss + 3
Across the Pacific, a different kind of response is emerging. Vermont’s legislature passed H.727 with overwhelming tripartisan margins in May 2026, one of the strongest data centre regulatory frameworks in the United States, establishing comprehensive requirements for any large-scale data centre proposing a facility of 20 megawatts or more in the state.
The bill’s framing is notable for what it prioritises: not data rights in the European tradition, but community protection, energy impact, and environmental accountability. Vermont’s legislators are asking a question that GDPR never quite got around to: what does this infrastructure actually cost the place where it physically exists?
The answer, they concluded, required binding law rather than voluntary commitments from an industry that has consistently made voluntary commitments and then built what it wanted anyway.
What the Books Won’t Let You Forget
Two books belong on the desk of anyone serious about this problem. One is a philosophical provocation. The other is a legal framework. Together they explain why the regulatory and technical communities keep talking past each other.
Veliz’s Privacy is Power (2020, Melville House) provides the political economy argument. Personal data, she contends, should be treated as a toxic asset, regulated the way societies regulate asbestos or radioactive material. Not because data is inherently dangerous, but because its aggregation creates systemic harms that individual actors cannot see or consent to. The cookie banner you clicked this morning wasn’t about your privacy. It was about the data broker downstream who bought your behavioral profile and sold it to an insurance actuarial model you will never encounter until it quietly raises your premium.
Her argument about the data economy’s relationship to democracy is the one that deserves more attention than it gets in technical circles. When she argues that surveillance capitalism doesn’t just exploit individual users but corrodes the information commons on which democratic decision-making depends, she’s describing a structural failure that GDPR addresses at the margins, not the center. Legal rights to access and erasure don’t touch the upstream architecture that generates the power imbalance.
Daniel Solove, George Washington University law professor and author of Understanding Privacy (Harvard University Press) and the Information Privacy Law 8th edition (2024, with Paul Schwartz), takes a different angle. Privacy, he argues, is not a single concept that can be cleanly defined and then protected. It is a family of related concerns: informational autonomy, contextual integrity, freedom from surveillance, and protection from exploitation. The failure of most regulatory frameworks is their assumption that one definition can address all of them.
His concept of “contextual integrity” is particularly useful here.
Information is appropriate in one context and inappropriate in another. Medical data shared with a physician is appropriate. The same data sold to a life insurer is not, even if it was “consented to” in a privacy policy no one read. GDPR partially addresses this through purpose limitation clauses. But those clauses assume that consent, once given, is meaningful. And in an ecosystem where 55% of companies cite data privacy concerns as their primary barrier to cloud adoption while simultaneously adopting cloud at record rates, meaningful consent has become a bureaucratic fiction.
What both authors share, despite their different disciplines, is a rejection of the notion that compliance produces privacy. Solove’s framework demands contextual appropriateness. Veliz’s framework demands structural reform. Neither is satisfied by a company that ticks the regulatory boxes while running its customer data through three SaaS vendors in four jurisdictions.
The Numbers Collated
Pulling the empirical threads together produces a portrait of systemic fragility that statistics presented in isolation tend to obscure:
This is not a correlation that regulators have adequately explained.
The most striking single data point is the 21% encryption coverage figure. It means that when GDPR enforcement officers ask whether data is protected, the honest answer, for 79% of organizations holding sensitive data in cloud environments, is “partially.” Partially protected. Partially sovereign. Partially compliant in the ways that are easy to verify, and partially exposed in the ways that are difficult to audit.
The Architecture Nobody Wants to Admit
Modern SaaS and LLM infrastructure was not designed for privacy. It was designed for scale.
Hyperscalers optimized for three things: availability, cost, and developer velocity. Privacy, meaning actual data control, arrived as an afterthought, then as a compliance requirement, and now as a market differentiator for the very companies that made it a problem in the first place. GDPR then created a legal obligation to retrofit sovereignty onto infrastructure that had been deliberately architected before those rules existed.
This produced four cascading architectural failures that no compliance framework has seriously addressed.
Shared tenancy is the first. Multi-tenant cloud environments isolate applications logically but not physically. Your customer data and your competitor’s customer data may sit on the same physical server, separated by hypervisor boundaries that are probabilistically secure, not absolutely. The 65% of breaches traced to human error? A significant proportion occur because engineers misconfigured tenancy boundaries that were never intuitive in the first place.
IAM complexity is the second. Modern cloud identity systems, AWS IAM, Azure Active Directory, GCP IAM among them, are deliberately granular. Granularity creates security. Granularity also creates cognitive overload. The average enterprise cloud environment carries 173 unused IAM roles, each a potential escalation path for a credential that was never rotated. Solove’s observation that privacy duties are often carried out “in a hollow, symbolic way” applies directly to IAM governance. Organizations create the policies. They review them annually. The drift accumulates in the weeks between reviews.
Encryption theater is the third. When only 21% of organizations encrypt more than 60% of sensitive data, the question is not whether encryption works. It does. The question is why organizations that are legally required to protect data choose not to encrypt it. The answer is operational friction: encryption adds latency, key management requires expertise, and audit requirements for key access create overhead that most teams treat as optional. Encryption becomes a checkbox for data the regulator is most likely to inspect, and a gap everywhere else.
The logging paradox is the fourth and least discussed. GDPR compliance requires audit logs: evidence that data was accessed appropriately, that rights requests were fulfilled, that retention schedules were followed. Those logs must be stored, which means they must be secured. Secured logs are attack surface. The people managing that attack surface are the same talent pool responsible for the 65% error rate. The regulator requires the evidence that creates the vulnerability.
The Sovereignty Spectrum Nobody Draws
Here’s the distinction that the GDPR conversation consistently elides: sovereignty is not binary.
The compliance community treats it as though you either have rights frameworks in place or you don’t. The security community treats it as though you either have zero-trust architecture or you’re exposed. Neither framing is useful for the majority of organizations that sit somewhere in the pragmatic middle; too large to ignore the problem, too resource-constrained to solve it absolutely.
Veliz argues, correctly, that big tech’s most effective rhetorical move was framing privacy as a personal preference, a setting you can toggle in your browser, rather than a structural condition. The same move happens in the enterprise compliance space. GDPR became a toggle. A DPA signed. A checkbox checked. The structural condition got abstracted away into vendor agreements: who physically controls this data, under which jurisdiction’s law, with which encryption key.
Solove’s contextual integrity framework provides a more useful lens. The question is not whether your data is GDPR-compliant. The question is whether its use in each context matches the norms under which it was originally shared. Customer behavioral data collected to improve product UX does not, by contextual norms, belong in an LLM training dataset. A medical record shared with a primary care physician does not, by contextual norms, belong in a health insurance underwriting model. These violations happen continuously, at scale, within organizations that are simultaneously GDPR-compliant.
What true data sovereignty actually requires is a spectrum of controls:
At the minimum: encryption keys that you hold, not your cloud provider. This is achievable today with Customer-Managed Encryption Keys (CMEK) on most hyperscaler platforms. Most organizations don’t activate it because key management responsibility is operationally inconvenient.
At the intermediate level: architectural choices that limit data centralization. A causal graph that stores the relationship between events rather than the raw events themselves. A memory layer that preserves reasoning context without centralizing transcript data. Tools that enforce purpose limitation at the data layer rather than the policy layer.
At the maximum: sovereign cloud deployments. Dedicated infrastructure in a defined jurisdiction, with personnel vetting, air-gapped from shared hyperscaler resources. AWS Sovereign Cloud, Oracle Sovereign Cloud, and Microsoft’s regulated government cloud offerings exist for this use case. They cost multiples of standard cloud pricing because they’re not using efficiency gains from shared infrastructure.
Most organizations belong somewhere in the middle of this spectrum. Most compliance frameworks pretend the middle doesn’t exist.
Where Sovereignty Fits in the Architecture
This is where the argument turns practical.
The problem with most cloud-native AI memory systems is that they replicate the architectural mistake of their underlying infrastructure. They centralize. They aggregate. They store raw interaction data in shared environments and wrap it in encryption they don’t hold the keys for. They are, in the language of Veliz’s framework, toxic asset accumulation disguised as product features.
VEKTOR Memory takes the opposite approach. Rather than centralizing data and then attempting to secure it retroactively, it builds sovereignty into the memory model itself.
The architectural distinction is the causal graph. VEKTOR stores relational context, specifically the causal links between events, decisions, and outcomes, rather than raw transcripts. A graph node that records “user asked about pricing after viewing feature comparison” is contextually meaningful for AI reasoning. It is not the same as storing a verbatim conversation. The information required for intelligent memory is a fraction of the information that most AI systems centralise in the name of providing it.
This matters for four reasons that map directly to the failure modes identified above.
Encryption is native, not bolted on. The AES-256 vault operations in VEKTOR require key management decisions at deployment time, not as an afterthought. You cannot accidentally skip encryption because the architecture doesn’t have an unencrypted path.
Key management is local by default. Unlike hyperscaler deployments where encryption keys live in the provider’s key management service by default, VEKTOR’s credential vault is designed to run on-premise or in customer-controlled infrastructure. The provider cannot comply with a government disclosure order for keys they don’t hold.
Jurisdictional portability is structural. Because the memory layer runs independently of the underlying compute infrastructure, it can move between on-premise, sovereign cloud, and edge deployments without data migration. Jurisdiction follows the deployment choice, not the vendor contract.
Human error surface is reduced by design. IAM-like access decisions for memory retrieval are encoded in the causal graph structure, not delegated to runtime configuration choices made by engineers under deadline pressure. The 65% human error figure shrinks when the architecture eliminates the categories of decision where those errors occur.
This is not a claim that VEKTOR eliminates the sovereignty problem. Air-gapped, physically isolated infrastructure remains the only absolute answer, and it is incompatible with the operational requirements of most organizations. What VEKTOR offers currently is deliberate sovereignty: a system in which you know what you control, can verify that you control it, and have made architectural choices rather than compliance choices about where the boundaries are.
And in the future we'll solve the cloud problem as well, although it is much more complex, a possible solution would be Aes-256 lockers,
For organizations handling customer behavioral data, LLM interaction logs, and contextual business intelligence, which are the categories of data that accumulate in AI-native applications, this represents a practical path between the false binary of compliance theater and the unaffordable extreme of sovereign infrastructure.
Conclusion: The Question Behind the Question
GDPR is not a failure. It is a success at something more modest than its architects intended.
It gave individuals legal rights that are real and enforceable. It created organizational awareness of data practices that had previously been invisible. It produced fines large enough to make boardrooms uncomfortable. These are genuine achievements. They are also substantially less than sovereignty.
The conversation that the rain and the chai prompt, when you sit long enough with it, is not “how do we improve GDPR?” It is: what problem are we actually trying to solve?
If the problem is legal accountability for how data is used, GDPR is the answer. If the problem is actual control over data that represents power over individuals, GDPR is insufficient. Veliz’s framework says you cannot have meaningful privacy while the data economy’s incentive structure rewards aggregation. Solove’s framework says you cannot have meaningful privacy protection without asking whether each use of data matches the norms under which it was originally gathered.
Those are not compliance questions. They are architectural and economic ones.
The 83% breach encounter rate, the 65% human error attribution, the 21% encryption coverage, and the 154% surge in significant incidents: these numbers are not evidence that enterprises are careless. They are evidence that the gap between compliance and control has grown wider than organizations can bridge with policy alone.
The architecture is where the problem lives. The architecture is where the solution has to start.
Next time you click “Accept All” on a cookie banner, and you will, we all do, because the alternative is a friction wall specifically designed to wear down your resistance, remember that the consent you just provided is real in a legal sense and meaningless in an architectural one. Someone, somewhere on a server you will never see, just added a data point to a profile that will outlive your awareness of it by decades.
GDPR gave you the right to delete it.
Whether that right can be exercised depends entirely on who built the architecture it lives in.
The data is clear. The regulation is clear. The architecture is where the question actually lives.
Let's get practical.
Five things you can actually do this week
Reading about a structural problem without a practical exit ramp is its own kind of frustration. So here are five concrete actions, two for individuals and three for businesses, that move the needle from compliance theater toward real control.
The first is for any organization running on public cloud: switch from provider-managed to Customer-Managed Encryption Keys (CMEK). Your cloud vendor defaults to holding your encryption keys because it makes their operational life easier. CMEK means only you hold the keys, which means a government disclosure order served on AWS or Azure cannot unlock your data without coming to you first. This is available on all three major hyperscalers today, it does not require migrating infrastructure, and most organizations simply never activate it. Open your cloud console, search for KMS or Key Vault, and audit which services are using provider keys. The ones that are become your priority list.
The second is personal and costs nothing. Under GDPR Articles 15 through 17, any individual in the EU or UK has the right to request a full copy of every data point a company holds on them, and to demand deletion. Most companies rely on the assumption that nobody will ask. Send a Subject Access Request to the five platforms you use most regularly. The legal response deadline is 30 days. The ICO website at ico.org.uk has templates. The exercise alone is clarifying: you will find data you had no idea was being retained.
The third is also personal: audit and remove your data broker profiles. Acxiom, LexisNexis, Experian, and several hundred smaller operators hold combined profiles built from your purchase history, location data, and financial behavior, and they sell access to insurers, political campaigns, and advertisers. Tools such as DeleteMe, Optery, and Mozilla Monitor automate opt-out requests across the major brokers. A Mozilla Monitor free scan takes ten minutes and shows you exactly where your personal information is circulating.
The fourth is a business exercise that looks simple but changes everything downstream: classify your data by sensitivity before you classify it by cost. Build a two-column inventory. Column one lists every data store your organization uses. Column two assigns a sensitivity level: public, internal, confidential, or restricted. The gaps between what is classified as restricted and what is actually stored on shared public cloud infrastructure become your migration backlog. Most organizations have never done this audit. Doing it turns sovereign privacy from an abstraction into a project list.
The fifth applies specifically to any business deploying LLM-based tools. Every AI assistant, customer-facing chatbot, or internal knowledge tool your organization runs is accumulating context: user intent, session history, behavioral patterns, decision sequences. If that memory layer lives on the vendor’s shared infrastructure, you do not control it, you cannot audit it, and you cannot easily move it. The sovereign architecture decision for AI-native businesses is not which model to use. It is where the memory lives. Deploying a memory layer you control, with keys you hold, in a jurisdiction you have chosen, is the one architectural decision that compounds. Get it wrong early and every subsequent integration inherits the exposure. Get it right and you have built a foundation that scales with your data.
None of these require abandoning the cloud. Three are executable this week with no capital expenditure. The other two require planning but not extraordinary resources. The point is not perfection. The point is deliberate choice, which is the only thing that separates compliance theater from actual sovereignty.
References & Further Reading
Veliz, C. (2020). Privacy is Power: Why and How You Should Take Back Control of Your Data. Melville House.
Solove, D.J. (2024). Information Privacy Law (8th ed., with P.M. Schwartz). Aspen Publishers.
Solove, D.J. (2008). Understanding Privacy. Harvard University Press.
SentinelOne. (2025). Cloud Security Statistics. https://www.sentinelone.com/cybersecurity-101/cloud-security/cloud-security-statistics/
Exabeam. (2025). 61 Cloud Security Statistics You Must Know in 2025. https://www.exabeam.com/explainers/cloud-security/61-cloud-security-statistics-you-must-know-in-2025/
StationX. (2025). Cloud Security Statistics. https://app.stationx.net/articles/cloud-security-statistics
EFT Sure. (2025). Cloud Computing Statistics. https://www.eftsure.com/en-au/statistics/cloud-computing-statistics/
Capgemini. (2022). Cloud and GDPR Whitepaper. https://www.capgemini.com/wp-content/uploads/2022/05/cloud-and-gdpr-whitepaper.pdf
Western Sydney University. (2020). The New Privacy White Paper. https://www.westernsydney.edu.au/ics/research/publications/shared-media/the-new-privacy-white-paper.pdf
Cisco Privacy Report. (2025). Data cited in TheKnowledgeAcademy Cloud Computing Statistics.
Thales Group. (2024). Data Sovereignty, Privacy and Governance. https://cpl.thalesgroup.com/blog/encryption/data-sovereignty-privacy-governance
AWS. (2025). What is Data Sovereignty? https://aws.amazon.com/what-is/data-sovereignty/
Oracle ANZ. (2024). Sovereign Cloud: Data Sovereignty. https://www.oracle.com/anz/cloud/sovereign-cloud/data-sovereignty/
June 2026 Promo (27th of May — Ends 30th of June)
Refer a Friend — 50% Off First Month for Both of You
We just launched a referral program. If you love VEKTOR, share it with a friend, and you both get 50% off your first month:
https://vektormemory.com/product
How It Works:
Step 1 — Share your referral link: REFER50
Step 2 — Your friend checks out
The discount code: REFER50 is entered at checkout. They get 50% off their first month automatically, and you do too — no coupon hunting required.
VEKTOR Memory, including free skill files and open-source infrastructure apps Vex, Vek, Via, are available at vektormemory.com.
Data Privacy · Cloud Security · GDPR · Data Sovereignty · Cybersecurity · Artificial Intelligence · SaaS · Privacy Technology
Data Privacy
Cloud Security
Gdpr
Data Sovereignty
Top comments (0)