<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
    <title>Alek&#x27;s Blog - cloud-act</title>
    <subtitle>My Blog to share my knowledge</subtitle>
    <link rel="self" type="application/atom+xml" href="https://blog.none.at/tags/cloud-act/atom.xml"/>
    <link rel="alternate" type="text/html" href="https://blog.none.at"/>
    <generator uri="https://www.getzola.org/">Zola</generator>
    <updated>2026-07-09T00:00:00+00:00</updated>
    <id>https://blog.none.at/tags/cloud-act/atom.xml</id>
    <entry xml:lang="en">
        <title>Sovereign-Cloud-Washing: Five Questions</title>
        <published>2026-07-09T00:00:00+00:00</published>
        <updated>2026-07-09T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              aleks
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://blog.none.at/blog/2026/2026-07-09-sovereign-cloud-washing/"/>
        <id>https://blog.none.at/blog/2026/2026-07-09-sovereign-cloud-washing/</id>
        
        <summary type="html">&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;</summary>
        
    </entry>
    <entry xml:lang="en">
        <title>Legally vs. Technically Enforced</title>
        <published>2026-07-09T00:00:00+00:00</published>
        <updated>2026-07-09T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              aleks
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://blog.none.at/blog/2026/2026-07-09-sovereignty-enforcement-framework/"/>
        <id>https://blog.none.at/blog/2026/2026-07-09-sovereignty-enforcement-framework/</id>
        
        <summary type="html">&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;</summary>
        
    </entry>
</feed>
