国家级数据库，为何守不住880万人？

两件事，看似八竿子打不着：一件是丹麦国家登记数据库被打穿，880万人的姓名、地址、身份号外泄；另一件是InfoQ上一篇讲LLM平台工程的文章，作者Aditya Mulik用一套共享平台服务治理住了AI agent的幻觉。

但在我这个搭了十来年数仓和实时管道的人眼里，它们讲的是同一句话——数据一旦成为基础设施，治理就必须长在底座里，而不是装在应用层。 丹麦输就输在这一点；而LLM平台化实践，恰恰是新一代基础设施在补这一课。

🔥 一纸公告，半个国家的名字

国家级数据库最大的风险，不是被打穿，而是所有人都默认它打不穿。

事情本身并不复杂。丹麦数字事务部在周一发布公告：国家登记管理局（CPR）确认，未经授权的个人非法获取了登记库中约880万人的数据。泄露字段是三样最朴素的东西——姓名、地址、CPR号码。

朴素的字段，最致命。姓名和地址是定位，CPR号码是钥匙。在一个高度数字化运转的社会里，身份号是串联医疗、税务、金融等一切数据记录的关联主键。拿到钥匙的人，不需要马上做什么，他只需要等。

更值得玩味的是泄露对象的构成：包括在世人员、移民，甚至已故人员。丹麦全国人口约六百万级，库里有880万条登记，多出来的部分是几十年沉淀下来的历史记录。这说明这个库不是一个项目，而是一代代叠加上来的国家资产——资产越老，债务越深。

据多位长期接触欧洲公共部门数据项目的人私下讲，这类国家级登记系统的普遍现状是：接入方越接越多，权限模型却停留在十年前，'先跑起来，权限后面再说'是常态。880万人的名单，就是这句话的利息。

⚠️ 库越老，命越长，也越脆

数据的集中化程度越高，一次失误的杀伤半径就越大。

把丹麦这件事放到数据平台架构的视角下拆，能看到三个经典的老毛病。

第一，生命周期策略缺位。已故人员的登记数据还在库里以明文关联态存在，说明'该不该留存、留存多久、能不能降级脱敏'这类生命周期问题，从来没有在底座层面被认真回答过。数据治理在最该较真的地方，让位给了'万一哪天用得上'。

第二，访问边界是静态的。国家级登记系统的天然属性是'所有人都要用'——医疗要用、税务要用、统计要用。当使用者清单无限膨胀，而权限模型还是粗粒度的静态授权时，攻击者只需要找到一个接入点，就等于拿到了整栋楼的一卡通。

第三，最小化原则没有落到字段级。从公告看，泄露的是一组最基础的字段集，恰恰说明这个库对'谁能看什么'的答案是'都能看'。对一个身份底座来说，这是架构层面的设计缺陷，不是某个运维人员的一次疏忽。

顺便说一句，现在很多团队谈'数据安全'，谈的是边界防火墙和渗透测试。但丹麦这件事提醒我们：真正的安全是数据本身的状态管理——谁在库里、留了多久、谁能碰、碰了能不能查到。防火墙拦得住外面的包，拦不住库里自己松掉的螺丝。

🔧 另一边，LLM也走到了'基础设施'这一步

幻觉不是模型的病，是平台的病。

把视线从哥本哈根拉回到工程侧。Aditya Mulik在InfoQ的文章里讲了一个很典型的场景：一个库存推荐系统里，AI agent开始产生幻觉，推荐结果不可信。团队最终的解法不是换模型、不是调提示词，而是把整个LLM栈从'应用问题'重新定义为'平台基础设施问题'。

具体做法是建一个共享LLM平台，把三样东西抽出来变成公共服务：

• 提示词注册表与版本管理（prompt registry & versioning）——提示词不再散落在各个应用的代码里，而是像配置一样进注册表、有版本、有变更记录；
• Schema强制校验（schema enforcement）——模型的输出不再靠运气，而是被结构化契约硬约束；
• 按请求的Token成本归因（token cost attribution by request）——每一次调用的成本记到具体的请求、业务和人头上，而不是月底看总账时集体沉默。

熟悉的味道。这套逻辑，和十几年前数据平台从'每个业务线自己写ETL脚本'走向'统一数仓+平台服务'的演进，几乎是逐字复刻。当年我们说服业务方把ETL交出来，靠的也不是情怀，而是血缘、质量和成本分摊这些'不交出去就永远算不清账'的硬理由。今天的LLM平台，走的是同一条路。

一个耐人寻味的细节是：幻觉问题的最终解法里，没有一项是'更好的模型'。约束输出的不是智能，是架构。 这对那些把LLM能力当成'接个API就完事'的团队，应该是一记提醒。

📐 把'谁改的、谁花的、谁担责'记到人头上

不能归因的资产，最后都会变成没人负责的负债。

把平台工程的三件套翻译成数据治理的语言，对应关系一目了然：

这三件事有一个共同底色：可归因。谁改的、改了什么、花了多少、影响了谁，全部留痕、全部记账。

回头看丹麦事件，缺的恰恰也是同一个东西——只不过方向相反。LLM平台是'治理前置于底座'：平台第一天就把归因、约束、记账建进去。CPR是'治理后置于事故'：底座运转了几十年，归因和约束始终缺位，直到880万人的名单替它完成了一次最昂贵的审计。

据我了解，国内不少正在建AI中台和数据要素流通平台的团队，第一版方案里也常常只有'能力'没有'账本'——模型能力、数据目录、流通接口都齐了，但谁在用、用了多少、改了什么，没有平台级的答案。这种底座上线那一刻，就是新的CPR风险在孵化。

🛡️ 底座思维：安全左移，账目右移

应用崩了可以回滚，底座漏了没有回滚键。

两个案例摆在一起，我认为可以给所有在建数据平台和AI平台的团队三条硬性判断：

✅ 可归因：每一次数据访问、每一次模型调用、每一次配置变更，都能落到具体的人和业务。做不到归因的底座，等于把审计成本转嫁给未来的事故。

✅ 可约束：输出有Schema，访问有最小化，字段有分级。约束不是给开发添堵，是把'信任'从流程和自觉，转成架构和代码。

✅ 可撤销：权限发得出去，也要收得回来。历史上大量重大泄露的放大器，都是那些'当年为了方便开的长效权限'。

这三个词，应该写进每一份数据平台和AI平台的立项文档，而不是等监管文件来了再补课。

还有一个更深的趋势判断：随着AI大规模消费数据，'数据安全'和'AI平台治理'正在合流。今天LLM平台谈的提示词版本管理，明天就是'AI访问了哪些数据'的访问审计；今天谈的Token归因，明天就是数据要素场景下'用了谁的数据、该分多少账'的计量基础。谁先把归因和约束建进底座，谁就掌握了下一轮数据基础设施的定价权。

小结

880万人的名单和一次幻觉修复，讲的是同一件事：基础设施级的资产，需要基础设施级的治理。 丹麦CPR用几十年的数据沉淀换来一次最贵的教训；而LLM平台工程正在证明，这套课可以提前上、便宜上。对每一个还在'先跑起来再说'的团队，问题不是会不会出事，而是出事时，你的底座能不能回答'谁、在什么时候、碰了什么、花了多少'。答不上来的，账迟早要补，而且连本带息。