当越来越多的人生和业务运行在别人提供的系统上，我们真正应该担心什么？
现代数字世界建立在依赖之上。
你打开一个网站，背后可能依赖：
云服务器、DNS、CDN、数据库、对象存储、身份认证、支付系统、短信、邮箱、第三方 API、AI 模型。
一个内容创作者看起来只是发布了一条视频，实际上可能同时依赖：
手机操作系统、内容平台、账号体系、推荐系统、云存储、剪辑软件、音乐版权库、支付平台、用户私信、甚至某个 AI 服务。
现代数字系统几乎不可能做到真正意义上的“完全独立”。
所以讨论个人数字主权时，一个很容易产生的误区就是：
既然要主权，是不是就应该什么都自己做？
答案显然不是，而是：
这个依赖能不能被替换？
这可能是理解数字主权最重要的一个问题。
我们已经生活在一个高度依赖的数字世界
传统社会同样存在基础设施依赖：
电、水、道路、银行、通信、物流，这些东西一旦出现问题，大量社会活动都会受到影响。
数字世界只是把这种关系进一步放大了。
过去一家小公司可能主要依赖：办公楼、电话、银行账户，今天一家十个人的软件公司，可能同时依赖几十个在线服务。
更重要的是，这些依赖很多时候是：
嵌套的。
例如：
你的软件依赖某个 AI 接口，这个 AI 公司依赖某个云厂商，云厂商依赖 NVIDIA GPU，GPU 又依赖晶圆制造、先进封装、网络、电力和数据中心。
所以你觉得只依赖：
一个 API。
实际上背后可能是一条非常长的：
Dependency Chain / 依赖链
Cloud Security Alliance 于 2026 年 6 月发布的 AICM v1.1 实施指南要求 AI 客户盘点模型、数据源、库、SDK、API、托管服务商以及云和本地基础设施等依赖，并记录供应链实体之间如何相互连接和影响。
这意味着一个非常重要的问题：
现代数字系统真正的风险，很多时候并不发生在你直接使用的那一层。
依赖本身并不可怕
我们首先应该承认：
依赖是一种效率。
如果每一个人都自己：建数据中心、写数据库、做支付、造 GPU、运营邮件服务器、开发大模型，整个现代互联网根本不可能拥有今天这样的效率。
专业化分工本身就是现代经济运行的基础，所以使用阿里云并不是失去主权，使用微信也不是失去主权，调用 OpenAI、Claude、DeepSeek 也不意味着失去主权。
真正危险的是另一种情况：
你已经没有现实能力离开它。
这时候，依赖开始变成：
Lock-in / 锁定
“我离不开它”才是真正的问题
判断一个基础设施依赖是否危险，可以做一个非常简单的测试：
如果这个服务明天停止，我还能不能继续工作？
例如你的所有文章都写在某个平台后台，平台关闭以后：
有没有原始文件？如果没有，这是高风险依赖。
你所有客户都存在微信里，账号异常以后：还有没有第二种联系方式？
如果没有，这是高风险依赖。
软件所有核心能力都绑定某一家云厂商的专有服务，更换云厂商需要重新开发半年，这是高风险依赖。
整个 AI 产品只支持一个模型供应商，API 价格上涨、政策变化或者服务中断以后，产品直接停止工作。
这也是高风险依赖。
所以真正需要衡量的不是：有多少依赖，而应该是：
Replacement Cost / 替换成本
基础设施依赖真正危险的，是“不可替代性”
可以把数字基础设施分成两种状态。
一种是：
我使用你，因为你目前最好。
另一种是：
我使用你，因为我已经无法离开你。
表面上都叫“用户”，商业性质却完全不同。
第一种建立在：价值。
第二种建立在：锁定。
这和我们之前讨论平台用户关系完全一样，一个人用了十年某个平台，不一定意味着他高度忠诚。
可能只是：照片在那里、聊天记录在那里、用户关系在那里、历史数据在那里、迁移成本太高。
所以：
留下，不一定代表喜欢。
有时候只是离开的代价太大。
云计算是一个非常典型的例子
云计算早期解决了巨大的效率问题：
企业不需要购买服务器，不需要自己建立数据中心，可以按需使用计算、存储和数据库，这显著降低了软件创业门槛。
但云计算发展到后期，又产生了一个新的问题：
Vendor Lock-in / 供应商锁定
如果一个系统大量使用某一家云厂商的：
专有数据库、无服务器函数、消息队列、身份系统、AI 服务、监控体系、部署工具，
那么随着系统越来越复杂，更换云厂商的成本也会越来越高。
最后出现一个很有意思的现象：
云最开始帮助企业摆脱硬件依赖，最后又可能形成新的云平台依赖。
欧盟《Data Act》已经专门针对这一问题建立了云服务切换规则。
相关条款要求数据处理服务商消除妨碍客户切换或在适用时并行使用多个服务商的障碍；其中，非纯 IaaS 服务须免费提供开放接口，并在相应标准尚未发布时，应客户要求以结构化、通用、机器可读格式导出可导出数据。自 2027 年 1 月 12 日 起，服务商不得收取切换费，其中包括切换过程中产生的数据出口费。
为什么监管开始干预这一问题？
因为：
没有迁移能力，市场上的“选择”可能只是表面上的选择。
AI 正在制造新一代基础设施依赖
如果说过去十年最大的基础设施依赖之一是：
云依赖
那么未来十年很可能增加另一种：
AI Dependency / AI 依赖
越来越多产品开始把 AI 嵌入：
代码开发、客服、数据分析、营销、文档处理、内容生产、搜索、知识管理、甚至企业决策流程。
问题在于：很多系统从第一天开始，就是围绕一个模型供应商设计的。
Prompt 针对一个模型，Tool Calling 针对一个 API，上下文管理依赖特定接口，Embedding 使用特定模型，数据格式绑定某个平台，安全策略也围绕某一家供应商建立，等运行两三年以后，再想换模型，才发现：
AI 已经不是一个功能，而变成了基础设施。
IBM 商业价值研究院与 Oxford Economics在 2026 年 2 月至 4 月调查了全球 1,000 名高级管理者；71% 表示更换主要 AI 供应商或模型会很困难，91% 表示并未完全了解本组织在 AI 供应商、模型和基础设施之间的依赖。
这两个数据放在一起非常有意思：
很多企业已经高度依赖 AI，却还没有真正画清楚自己到底依赖了什么。
这就是典型的基础设施风险。
最大的风险往往不是服务停止，而是规则改变
很多人理解基础设施风险，只想到：
服务器宕机、平台倒闭、API 无法访问，这些当然是风险。
但现实里更常发生的是：
基础设施还活着，只是规则变了。
例如：
价格上涨、API 收费方式调整、调用额度变化、平台停止某个接口、内容政策变化、账号规则改变、数据出口限制、认证机制升级、某个模型停止服务、某个功能进入更高级套餐。
这时候系统并没有“坏”，但你的业务模型可能已经坏了。
所以基础设施依赖还有一个非常重要的指标：
Policy Dependency / 规则依赖
如果你的业务能不能成立，高度依赖第三方：
继续免费、继续开放接口、继续允许导出、继续提供某项能力，
那么它实际上建立在：
对别人未来政策的假设上。
这种依赖往往比技术依赖更难发现。
内容创作者其实是基础设施依赖最严重的一群人
一个普通创作者可能觉得：
我没有什么基础设施。
实际上恰恰相反，平台已经替他把所有基础设施隐藏掉了。
他的：数字身份，在平台账号里。
内容，在平台数据库里。
用户关系，在粉丝系统里。
分发，在推荐算法里。
支付，在平台商业化系统里。
数据分析，在创作者后台。
私信，在平台通信系统里。
直播，在平台系统里。
甚至商业信用，都在账号权重里。
表面上：
什么基础设施都不用管。
本质上：
几乎所有基础设施都属于别人。
这就是平台时代最极致的一种基础设施托管，
它极其方便，也极其高效，但代价就是：
退出能力很弱。
封号真正摧毁的，不只是账号
为什么一个创作者会如此害怕封号？
如果账号只是一个分发渠道，封掉一个，损失的应该只是部分流量。
但现实里很多创作者被封号以后，损失的是：
内容、粉丝、历史、用户关系、商业信用、交易入口、数据、品牌入口，
也就是说：
一个平台账号承担了过多基础设施功能。
这就是典型的：
Single Point of Failure / 单点故障
软件工程里很早就知道：
重要系统不能把所有能力压在一个节点上。
但大量创作者却把整个数字事业压在：
一个账号、一个平台、甚至一个手机号上。
从工程角度看，这其实是一种非常脆弱的架构。
真正成熟的数字系统，不追求“没有依赖”
而追求：
Replaceability / 可替代性
一个成熟系统应该允许：
服务器换、云厂商换、CMS 换、邮件服务商换、AI 模型换、支付渠道增加、发布平台换、设备换，
但与此同时：
核心资产不跟着消失。
这才是真正的数字主权。
可替代性为什么比“自托管”更重要？
自托管（Self-hosting）经常被认为是数字主权的解决方案，即：
自己搭服务器、自己维护数据、自己运行软件。它当然可以提高一部分控制能力，但自托管并不会自动带来主权。
如果你的系统只能运行在一种特殊环境，数据没有备份，代码严重依赖某个组件，只有你自己知道怎么维护，密钥丢失以后无法恢复，那么你只是把：
厂商依赖
换成了：
个人依赖。
甚至可能更加脆弱。
所以真正重要的不是：
谁在运行。
而是：
能不能替换、迁移和恢复。
判断基础设施主权，可以看三个能力
最终可以把基础设施主权压缩成三个指标。
第一：可替换性
Replaceability
如果一个组件消失，有没有替代方案？
例如：
模型 A → 模型 B。
AWS → Azure / 阿里云 / 自建。
WordPress → 其他 CMS。
Newsletter A → Newsletter B。
平台 A → 平台 B。
第二：可迁移性
Portability
能够更换，还不够。
你的东西能不能一起搬过去？
包括：数据、文件、配置、历史、用户、内容、元数据、权限。
所以：
有替代产品，不等于具有迁移能力。
第三：可恢复性
Recoverability
即使系统完全出问题，还能不能恢复？
有没有备份、版本、恢复流程、恢复测试、备用账号、备用节点、域名控制权和密钥恢复方案？这一点经常被忽略。
很多人说：
我有备份。
真正的问题应该是：
你恢复过吗？
没有验证过恢复能力的备份，只是一种心理安慰。
所以“多云”也不一定代表更安全
今天企业很喜欢讲：Multi-Cloud。
用了阿里云、用了 AWS、又用了 Azure、再用了 Google Cloud，看起来好像已经消除了依赖。
但如果这些云共用同一个身份系统、代码仓库、DNS 服务商、AI 模型 API 或核心数据库，那么真正的单点故障仍然存在。
这说明：
基础设施冗余不能只看数量。
真正应该看：
Dependency Graph / 依赖图
你需要知道：如果 A 失败，哪些东西跟着失败？
如果 B 不可用，还有没有第二条路径？
如果身份系统挂了，备用系统还能不能登录？
如果 DNS 出问题，几朵云是不是全部一起失联？
这才叫真正的基础设施设计。
个人也需要自己的 Dependency Map
这种思想过去主要用于大型企业，但 AI 时代，我认为个人也开始需要。
一位内容创作者完全可以画一张很简单的图：
身份
- 域名
- 邮箱
- 手机号
- 平台账号
资产
- 电脑
- NAS
- 云盘
- 对象存储
发布
- 个人网站
- 抖音
- 小红书
- B 站
- 公众号
用户关系
- CRM
- 微信
- 会员
AI
- 模型 A
- 模型 B
- 本地模型
交易
- 支付宝
- 微信支付
- 银行账户
- 其他渠道
然后问：
这里面有没有哪一个节点，一旦消失，我整个系统就停止运行？
这就是：
个人数字基础设施审计。
PDSI 真正反对的不是依赖，而是不可替代依赖
这也是为什么个人数字主权很容易被误解。
PDSI 并不是要求：
不用平台、不用云、不用 AI、不用微信、什么都自己造。
恰恰相反，现代个人应该充分利用：平台、AI、云计算、各种专业服务。
因为这些基础设施大幅提高了个人能力。
真正应该避免的是：
Irreplaceable Dependency / 不可替代依赖
你可以依赖别人。
但不能把自己的整个数字存在交给任何一个别人。
一个很重要的原则：工具可以失去，资产不能失去
可以把这条原则应用到几乎所有数字系统。
GitHub 可以失去，代码仓库不能失去。
WordPress 可以失去，文章不能失去。
AWS 可以失去，数据库不能失去。
OpenAI 可以失去，自己的知识库和工作流不能失去。
抖音账号可以失去，视频母本不能失去。
微信群可以失去，真正的用户关系不能全部失去。
设备可以坏，密钥和数据不能因此一起消失。
所以基础设施真正需要保护的不是：
某个工具。
而是：
工具之上的连续性。
开放标准为什么重要？
开放标准的价值，很多时候并不是“更先进”。
而是：
降低替换成本。
例如：
HTML、Markdown、RSS、SMTP、SQL、JSON、开放文件格式。
这些东西可能看起来非常普通。
但它们有一个共同特点：
很多系统都能理解。
一个 Markdown 文件今天可以用软件 A 打开，十年以后可以换软件 B，甚至用纯文本编辑器仍然可以读取。
这种长期兼容性，本身就是一种数字主权。
W3C 推动 DID 的一个核心目标，同样是让数字标识符可以脱离单一中心化身份提供商，由控制者证明自己对该标识符的控制。2026 年 3 月 5 日，W3C 将 DID 1.1 发布为 Candidate Recommendation Snapshot，这仍是候选推荐标准，而不是最终的 W3C Recommendation。
它解决的其实也是：
身份基础设施能不能降低对单一提供者的依赖？
内容来源也正在变成一种基础设施
AI 内容时代还有一种新的基础设施：
Provenance Infrastructure / 来源基础设施
如果一篇文章、图片或者视频的原创证明完全依赖：
某个平台的一枚“原创”标签，那么原创身份仍然依赖平台。
但如果内容本身存在：
哈希、签名、版本历史、来源记录、时间线、Repository Receipt，那么来源证明开始逐渐脱离单一平台。
C2PA 2.4于 2026 年 4 月新增 Repository Receipt Assertion，用于记录 C2PA Manifest Store 已被 C2PA Manifest Repository 接收的证明。它可以支持接收不可否认性、证明某个 Manifest 在特定时间存在于仓库，或由外部服务证明其已完成注册。
这其实和基础设施依赖是同一个问题：
证明我是谁、证明这个内容从哪里来，是否必须相信某一个平台？
AI 时代最大的风险之一，可能就是“基础设施单一化”
AI 看起来让软件世界更加丰富，模型越来越多，Agent 越来越多，工具越来越多，但底层却可能越来越集中。
如果大量产品最终建立在相同的少数云、GPU、模型、API、身份系统和开发框架上，那么表面上的应用繁荣可能掩盖：
底层高度集中。
当大量系统共享相同的云、模型、硬件甚至开发组件时，一个底层故障、漏洞或者供应链事件，就可能从局部事件扩散成系统性问题。
所以未来真正重要的技术能力之一可能不是：
如何接入 AI。
而是：
如何保证 AI 可以被替换。
CDSI 真正应该解决的，其实也是基础设施依赖
这样回头再看 CDSI，会发现很多功能其实都指向同一个目标。
Anchor 为什么存在？因为服务器部署不应该完全依赖某个不可迁移环境。
Beacon 为什么做本地资产索引？因为数字资产不能只存在平台数据库。
为什么需要云备份？因为本地设备也属于单点故障。
为什么需要 OpenWeb？因为公开数字身份不能完全等于平台主页。
为什么记录发布历史？因为平台不能成为唯一的内容来源证明。
为什么未来需要支持多个 LLM？因为一个 Agent 不应该被一个模型供应商永久锁定。
所以 CDSI 真正处理的问题，并不仅仅是：
备份。
而是：
降低个人数字世界里的不可替代依赖。
最成熟的系统，不是最封闭的系统
这里还可以得到一个更大的结论，很多系统把：
“别人离不开我”
理解成：
“我很强大”。
短期来看当然如此，但长期来看，过度封闭会带来一个问题：
用户和系统都失去迁移能力，内部技术越来越专用，外部接口越来越少，组织越来越依赖现有架构。
最后：
护城河开始变成围墙。
围墙可以挡住别人，但也可能把自己困在里面，
所以真正长期稳定的系统，反而往往具有：
开放接口、清晰边界、标准协议、可导出数据、替换机制、容灾方案。
这是一个很有意思的悖论：
真正的稳定，不是保证任何东西永远不变。
而是保证东西发生变化以后，系统依然能够继续运行。
这就是：
Resilience / 韧性
基础设施主权的最终目标不是独立，而是韧性
“独立”这个词很容易让人理解成：所有东西自己控制，但现实世界不可能完全独立。
你一定会依赖：电力、网络、银行、芯片、操作系统、云服务，社会基础设施。
所以真正值得追求的是：
Resilient Dependency / 有韧性的依赖
我可以依赖你。
但：
我知道自己依赖了什么，我知道失去你以后会发生什么，我有替代方案，我的数据能够迁移，系统能够恢复，核心资产不会因此归零。
这才是成熟的基础设施设计。
如何判断自己的基础设施是否健康？
其实只需要不断问六个问题：
第一：它是谁的？
域名、数据、文件、账号、密钥到底由谁控制？
第二：能不能导出？
如果今天要离开，东西能不能完整拿走？
第三：能不能替换？
市场上是否存在现实替代方案？
第四：替换要多久？
一天？一周？半年？还是根本无法替换？
第五：坏了能不能恢复？
备份是否真的能够恢复？
第六：它消失以后，我还剩下什么？
这是最重要的一问。
结语：依赖不是问题，失去选择才是问题
现代数字世界不可能没有依赖。
我们使用平台，使用云，使用 AI，使用支付系统，使用操作系统，使用网络，依赖本身恰恰创造了巨大的效率。
所以个人数字主权真正追求的从来不是：
什么都自己做。
它真正追求的是：
任何一个依赖都不能拥有摧毁你全部数字存在的能力。
云可以换，平台可以换，设备可以换，模型可以换，工具可以换，公司甚至可以倒闭。
但：
你的数据还在，内容还在，身份还在，关系还在，知识还在，业务还能继续。
所以衡量数字主权最重要的问题之一，不是：
我拥有多少基础设施？
而是：
当我失去某一个基础设施以后，我还有没有选择？
如果没有，那不是依赖。
那是：
锁定。
如果有，那才是真正健康的数字基础设施关系。
所以基础设施主权最终可以浓缩成一句话：
可以依赖，但不能无法替代。
而一个真正具有数字主权的人，并不是不依赖任何系统的人。
而是：
即使依赖发生变化，仍然能够继续存在的人。