<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0">
    <channel>
      <title>Alek&#x27;s Blog - digital-sovereignty</title>
      <link>https://blog.none.at</link>
      <description>My Blog to share my knowledge</description>
      <generator>Zola</generator>
      <language>en</language>
      <atom:link href="https://blog.none.at/tags/digital-sovereignty/rss.xml" rel="self" type="application/rss+xml"/>
      <lastBuildDate>Thu, 09 Jul 2026 00:00:00 +0000</lastBuildDate>
      <item>
          <title>Sovereign-Cloud-Washing: Five Questions</title>
          <pubDate>Thu, 09 Jul 2026 00:00:00 +0000</pubDate>
          <author>aleks</author>
          <link>https://blog.none.at/blog/2026/2026-07-09-sovereign-cloud-washing/</link>
          <guid>https://blog.none.at/blog/2026/2026-07-09-sovereign-cloud-washing/</guid>
          <description xml:base="https://blog.none.at/blog/2026/2026-07-09-sovereign-cloud-washing/">&lt;p&gt;“Sovereign cloud” is printed on marketing pages from AWS, Microsoft, Google, and a long list of
European providers alike. The label rarely comes with a definition, which makes it easy to satisfy
on paper and hard to verify in practice. I’ve put together five concrete questions, asked of the
claim itself instead of the label — enough to see, from several angles, what a provider actually
stands behind.&lt;&#x2F;p&gt;</description>
      </item>
      <item>
          <title>Who Has Access? Humans, Accounts, AI Agents</title>
          <pubDate>Thu, 09 Jul 2026 00:00:00 +0000</pubDate>
          <author>aleks</author>
          <link>https://blog.none.at/blog/2026/2026-07-09-sovereignty-access-model/</link>
          <guid>https://blog.none.at/blog/2026/2026-07-09-sovereignty-access-model/</guid>
          <description xml:base="https://blog.none.at/blog/2026/2026-07-09-sovereignty-access-model/">&lt;p&gt;&lt;a href=&quot;https:&#x2F;&#x2F;blog.none.at&#x2F;blog&#x2F;2026&#x2F;2026-07-09-sovereign-cloud-washing&#x2F;&quot;&gt;Part 1&lt;&#x2F;a&gt; split the technology-supply-chain
question into two halves: what the platform is built on, and who — or what — actually has access to
it. &lt;a href=&quot;https:&#x2F;&#x2F;blog.none.at&#x2F;blog&#x2F;2026&#x2F;2026-07-09-sovereignty-technology-stack&#x2F;&quot;&gt;Part 2&lt;&#x2F;a&gt; answered the first half. This
post answers the second, using systems already built and operated for this blog rather than new
research — human access, service-account access, and (increasingly relevant) AI-agent access, all
checked against the same bar: is it documented, is it audited, and is it technically enforced or
just expected to be followed.&lt;&#x2F;p&gt;</description>
      </item>
      <item>
          <title>Legally vs. Technically Enforced</title>
          <pubDate>Thu, 09 Jul 2026 00:00:00 +0000</pubDate>
          <author>aleks</author>
          <link>https://blog.none.at/blog/2026/2026-07-09-sovereignty-enforcement-framework/</link>
          <guid>https://blog.none.at/blog/2026/2026-07-09-sovereignty-enforcement-framework/</guid>
          <description xml:base="https://blog.none.at/blog/2026/2026-07-09-sovereignty-enforcement-framework/">&lt;p&gt;The same distinction has come up three times already in this series without being named directly:
BYOK in &lt;a href=&quot;https:&#x2F;&#x2F;blog.none.at&#x2F;blog&#x2F;2026&#x2F;2026-07-09-sovereign-cloud-washing&#x2F;&quot;&gt;Part 1&lt;&#x2F;a&gt;, two vendors’ own statements in
&lt;a href=&quot;https:&#x2F;&#x2F;blog.none.at&#x2F;blog&#x2F;2026&#x2F;2026-07-09-sovereignty-technology-stack&#x2F;&quot;&gt;Part 2&lt;&#x2F;a&gt;, and Kubernetes RBAC against a
written &lt;code&gt;CLAUDE.md&lt;&#x2F;code&gt; rule in &lt;a href=&quot;https:&#x2F;&#x2F;blog.none.at&#x2F;blog&#x2F;2026&#x2F;2026-07-09-sovereignty-access-model&#x2F;&quot;&gt;Part 3&lt;&#x2F;a&gt;. This post
makes it explicit, adds a third rung most sovereignty marketing doesn’t reach yet, and applies it
across everything the series has found so far — no new research, just naming a pattern that kept
repeating.&lt;&#x2F;p&gt;</description>
      </item>
      <item>
          <title>Can You Leave? Data Portability &amp; Egress</title>
          <pubDate>Thu, 09 Jul 2026 00:00:00 +0000</pubDate>
          <author>aleks</author>
          <link>https://blog.none.at/blog/2026/2026-07-09-sovereignty-exit-path/</link>
          <guid>https://blog.none.at/blog/2026/2026-07-09-sovereignty-exit-path/</guid>
          <description xml:base="https://blog.none.at/blog/2026/2026-07-09-sovereignty-exit-path/">&lt;p&gt;&lt;a href=&quot;https:&#x2F;&#x2F;blog.none.at&#x2F;blog&#x2F;2026&#x2F;2026-07-09-sovereign-cloud-washing&#x2F;&quot;&gt;Part 1&lt;&#x2F;a&gt; deliberately kept Question 4 — can you
leave — at the general level. This post is the deep-dive: concrete data-export
formats, API and query-language openness, and egress pricing already documented for AWS, GCP,
Azure, and OVH, plus new findings on how the five sovereignty offerings from
&lt;a href=&quot;https:&#x2F;&#x2F;blog.none.at&#x2F;blog&#x2F;2026&#x2F;2026-07-09-sovereignty-technology-stack&#x2F;&quot;&gt;Part 2&lt;&#x2F;a&gt; actually hold up on exit.&lt;&#x2F;p&gt;</description>
      </item>
      <item>
          <title>Digital Sovereignty: The Complete Guide</title>
          <pubDate>Thu, 09 Jul 2026 00:00:00 +0000</pubDate>
          <author>aleks</author>
          <link>https://blog.none.at/blog/2026/2026-07-09-sovereignty-guide/</link>
          <guid>https://blog.none.at/blog/2026/2026-07-09-sovereignty-guide/</guid>
          <description xml:base="https://blog.none.at/blog/2026/2026-07-09-sovereignty-guide/">&lt;p&gt;This is the index and reading guide for a six-part series built around one idea: “sovereign cloud”
is a marketing label until it’s tested against something specific. Part 1 sets out five concrete
questions to test it against instead of taking the label at face value; Parts 2 through 6 are the
deep-dives that answer each one in turn — grounded, wherever possible, in research or systems
already published elsewhere on this blog rather than written fresh for the series.&lt;&#x2F;p&gt;</description>
      </item>
      <item>
          <title>What Does It Cost to Leave — or Arrive?</title>
          <pubDate>Thu, 09 Jul 2026 00:00:00 +0000</pubDate>
          <author>aleks</author>
          <link>https://blog.none.at/blog/2026/2026-07-09-sovereignty-switching-cost/</link>
          <guid>https://blog.none.at/blog/2026/2026-07-09-sovereignty-switching-cost/</guid>
          <description xml:base="https://blog.none.at/blog/2026/2026-07-09-sovereignty-switching-cost/">&lt;p&gt;&lt;a href=&quot;https:&#x2F;&#x2F;blog.none.at&#x2F;blog&#x2F;2026&#x2F;2026-07-09-sovereign-cloud-washing&#x2F;&quot;&gt;Part 1&lt;&#x2F;a&gt; deliberately kept Question 5 at the
general level too: on-prem is largely sovereign, but “engineering time re-architecting for a
new platform’s primitives, process changes… and a skills gap no one accounted for” apply whichever
direction you’re moving. This post is that deep-dive — the last of the five, using examples already
built and published rather than new claims about any provider.&lt;&#x2F;p&gt;</description>
      </item>
      <item>
          <title>Who Builds the Platform? Ownership vs. Stack</title>
          <pubDate>Thu, 09 Jul 2026 00:00:00 +0000</pubDate>
          <author>aleks</author>
          <link>https://blog.none.at/blog/2026/2026-07-09-sovereignty-technology-stack/</link>
          <guid>https://blog.none.at/blog/2026/2026-07-09-sovereignty-technology-stack/</guid>
          <description xml:base="https://blog.none.at/blog/2026/2026-07-09-sovereignty-technology-stack/">&lt;p&gt;&lt;a href=&quot;https:&#x2F;&#x2F;blog.none.at&#x2F;blog&#x2F;2026&#x2F;2026-07-09-sovereign-cloud-washing&#x2F;&quot;&gt;Part 1&lt;&#x2F;a&gt; raised the technology-supply-chain
question with one case: Open Telekom Cloud, legally owned by Deutsche Telekom, running on a
Huawei-licensed platform. Five more prominent, more recent cases turn out to follow the same
pattern — checked here against primary sources, not just repeated from secondary coverage —
alongside three providers where ownership and technology stack come closer to aligning, each with
its own gaps left intact rather than smoothed over.&lt;&#x2F;p&gt;</description>
      </item>
    </channel>
</rss>
