维基

健康与生活方式智能与 GDPR：法律框架

这个门户用于支持生活方式，不做诊断，也不开具治疗方案。健康数据按 GDPR 处理——基于客人的明确同意，并存放在欧盟服务器上。

Updated 2026-08-28 · Sample procedures Luxury Spa & Medical Wellness Hotel Prezident

简要说明

• 类别。 Wellness & Lifestyle Intelligence 属于生活方式支持：门户收集手表和体重秤的数据，展示给客人和医生，并保存医生的安排。它不做诊断，也不开具治疗方案。
• 谁对数据负责。 控制者是酒店：门户的政策中写明了法人主体、注册编号、地址和医生姓名。longev.eu 是处理者：负责代码和服务器。
• 每家酒店都有自己的数据库。 代码是一套，但每家酒店都有自己的进程、自己的目录和自己的数据库。不存在汇总所有酒店客人的共享表。
• 同意有两次。 一次是注册时的一般同意，另一次是在问卷前对健康数据的明确同意。两次都会连同政策版本号一起记录：目前是 17.08.2026 的 1.7 版，共 12 个章节，提供 36 种语言。
• 权利就是按钮。 可以一键导出全部数据为一个文件，也可以导出 HL7 FHIR 给诊所系统，还可以撤回同意并删除数据，或删除账户。无需给酒店写信，也无需等待。
• 哪些内容会离开欧盟。 有 3 项，而且都明确写出：通过 Google 登录、借出手表所连接的 Garmin 云，以及提供给模型的去标识化文本。
• 期限。 健康数据保留到最后一次活动后 3 年，服务器日志最多保留 90 天，重设密码链接有效期为 60 分钟。
• 这份说明写给谁。 写给正在选择平台的酒店，也写给想知道自己数据后来怎样处理的客人。更新于 23.08.2026。

Wellness & Lifestyle Intelligence 是什么意思

Wellness & Lifestyle Intelligence 是一类支持生活方式的产品：关注睡眠、活动、饮水、饮食和酒店理疗。它使用的数字与医疗领域相同，但不宣称用于医疗，也不承诺治疗效果。

门户会做这些事：接收手表里的每日状态和体重秤的称重记录，把它们与客人自己的平均值比较，在客人的「账户」里和医生的「面板」上展示整体情况，并保存和显示医生作出的安排。

它绝不会做这些事：不给疾病下结论，不开药，也不开饮食处方，不取消或替代医生的安排，也不承诺某项理疗可以治愈问题。

当算法涉及安排时，这个区别最明显。免费且属于酒店自有项目的内容——比如健康步行路线、住宿已包含的桑拿——门户会自行调整。对于收费理疗，它只会建议改期，最终由医生决定（具体机制）。

与医疗器械的界线在哪里

把一个程序归为医疗器械的，不是算法有多复杂，而是制造商赋予它的用途：诊断、预防、监测、预测、预后、治疗或减轻疾病（欧盟医疗器械法规 (EU) 2017/745，第 2 条）。这个门户不宣称这类用途——而且这不只是文件里的说法，产品本身有 3 处可以看出来：

• 问卷得出的风险等级用于选择健康路线和心率区间，不是诊断。它不会产生法律后果，医生也可以覆盖它。
• 饮泉疗程由酒店总医生在检查后安排。门户只负责保存、显示并提醒饮用时间——它自己不能安排（详解）。
• 夜间流程调整的是理疗时间，不是治疗。它依据的阈值由医生设定，并且是公开的（数字和规则）。

手表是消费级设备

酒店提供的 комплект 是普通的 Garmin Forerunner 165 Music 手表和 Garmin Index S2 体重秤，都是商店购买的常规产品。门户不会使用它们的医疗功能：Garmin 只会在获批为医疗器械的地区启用 ECG 应用，而在其他国家购买的手表甚至可能完全没有这个功能。

心率、心率变异性、睡眠阶段、呼吸和血氧饱和度，都是手腕上消费级光学传感器的读数。门户也是这样呈现它们的：把它们看作客人自身身体状态的变化，而不是检查结果（手表实际测量什么）。

这类归类靠的不是文件里的一句话，而是对外作出的承诺。如果酒店宣传说«我们能通过手表给你做诊断»或«我们一周就能治好你»，那比任何代码改动都更快打破这条界线。

谁负责什么

在 GDPR 下，各方角色是这样划分的，而且这种划分比任何关于合作关系的表述都更重要：对客人和监管机构负责的是酒店。

为什么每家酒店都有自己的数据库

这个平台不是通常意义上的多租户：不同酒店的客人不是靠共享表中的一列来区分。每家酒店在服务器上都有自己的进程、自己的目录和自己的数据库，而代码是同一套。

这点的区别很实际。查询出错时，也不可能把另一家酒店的客人显示给本酒店看——因为这些数据根本不在它的数据库里。酒店如果停止使用，带走的是自己的完整文件，而不是从共享存储里导出的一部分。

两次同意与政策版本

健康数据属于特殊类别（GDPR 第 9 条），仅在注册时点「同意条款」在法律上还不够。因此需要两次同意：一次是注册时的一般同意，另一次是在问卷前对健康数据处理作出的明确同意。

这个顺序由服务器控制，不是由界面控制：如果政策还没有被接受，第二次同意的请求会被拒绝。

两次同意都会连同政策版本号和时间一起保存。只有内容含义发生变化时版本才会增加，不会因为错别字而增加——这时门户会在任何页面上方弹出窗口，重新询问所有人。

这种情况已经发生过 3 次：1.5 版增加了房间里的体重秤和身体成分，1.6 版写明了 AI 模型以及 3 次离开 EEA 的数据传输，1.7 版增加了饮食日记和餐盘照片。每一次都重新询问了所有客人。

门户的政策与酒店自己的政策分开，只涵盖门户本身：包括「账户」、问卷、健康路线和手表。客房预订和酒店推送则属于酒店自己的政策。

×

住客的权利靠按钮，不靠邮件

一项权利如果说是有，但实际要靠写邮件给酒店来行使，通常就等于没有。所以在「账户」里有一个「我的数据」区块，里面放了4个按钮。

• 导出——把门户保存的住客全部数据打成1个机器可读文件：问卷、带轨迹点的健康路线、夜间记录、测试、安排、个人资料（第20条——数据可携权）。
• 导出 HL7 FHIR——还是同一批数字，但用医疗系统能读的语言，格式是 FHIR R4：患者和观察记录。这个文件不只是人能看，诊所系统也能读。
• 撤回同意——默认会连同删除一起进行：同意一旦撤回，就没有依据继续保存健康数据。
• 删除账户（第17条）——需要确认：住客必须输入自己的电子邮箱地址，否则按钮不会生效。

×

这些按钮做不到什么

员工账户不能用这些按钮删除。医生的签名会出现在别人的安排和晨间记录下面，所以这类账户要由管理员移除——这样签名不会悄悄脱开。

删除的两种深度，以及删除后哪些内容会保留，见个人数据；那里也说明了为什么套件发放日志会保留，而员工写的住客备注会删除。

数据存在哪里，哪些会发出去

服务器位于欧盟；数据中心所在国家会在各酒店自己的政策里写明。数据只有在3种情况下会离开这里，这3种情况都会在政策中逐项列出：

• 通过 Google 登录——只有住客自己选了这条登录方式时才会发生，而且只涉及登录本身：电子邮箱地址、姓名和账户标识符。Google 密码绝不会到达门户。
• Garmin 云端——借出的手表会同步到一个 Garmin 账户，这个账户属于酒店，使用的是套件编号，不是住客姓名；Garmin 的服务器位于美国。依据是住客对手表作出的明确同意（第49(1)(a)条）。
• 模型提供方——去标识化的晨间记录（年龄、性别和各项数字，不含姓名、出生日期和电子邮箱地址）、需要逐字翻译的医生消息，以及住客自己按下相机时拍下的餐盘照片。

还有一项我们删不掉

门户里没有广告，也没有分析统计代码。住客的浏览器里只保存会话令牌和所选语言。

但 Garmin 账户里的每日历史无法删除：Garmin 没有提供这个功能。即使我们的副本已经删掉，这些天的数据仍会按 Garmin 自己的条款保留在它那里。门户只会从这类账户中读取住客持有该套件那次入住期间的日期——不过把这件事说清楚，比不说更诚实。

各类数据保存多久

每一类数据都有各自的保存期限，这里的删除是指从数据库中删掉记录，不是只在界面里隐藏。

有1条记录会有意在住客删除后继续保留——活跃入住的计费记录：其中指向账户的链接会被清空，这样当月还记得这次入住发生过，但不会再指向任何人（活跃住客如何计算）。

模型会做什么，不会决定什么

门户中的部分文字由人工智能模型生成：晨间摘要的表述、医生消息的翻译、步行明信片的背景文案，以及根据餐盘照片估算的卡路里。

它不计算风险等级，不选择心率区间，也不更改计划——它接收的只是门户已经算好的结果。门户中完全不存在具有法律后果的自动化决定（GDPR 第 22 条）。

文本由模型生成这一点，会在告知内容中直接告诉客人：这是欧盟人工智能法规第 50 条的要求。

还有最重要的一道保险：只要超级管理员还没有确认已与服务提供方签订数据处理协议，任何带有个人文本的请求都不会发出。开关默认关闭——沉默不等于同意。免费套餐不适合用于这里：按提供方自己的条款，它会从收到的内容中学习。

根据照片得出的卡路里，门户会以区间显示，并允许修改：这是基于图片的估算，不是测量值。

哪些限制是服务器执行的，不是界面做的

• 以客人视角查看时只能读取。 医生可以打开客人的账户，看到和客人完全一样的内容。在这种会话里，任何修改请求都会在进入应用时就被拦下，早于任何处理程序：如果只靠每条路线分别遵守这个承诺，它只能维持到第一条新路线出现为止。
• 每一次进入都会记录。 哪位员工在什么时候打开过客人的账户，日志里都会有一行。管理员在这种会话中可以修改，代价也说得很明白：修改会以客人的名义发出，而日志会记住该去看谁的窗口。
• 客人只能访问自己的记录。 角色隔离是在服务器端完成的，不是藏在菜单里。
• 密码不会被存储。 数据库里保存的是 PBKDF2 哈希，重设密码链接保存的只是代码的 SHA-256。即使数据库泄露，也拿不到这两样东西。
• 修改密码会使已发出的密钥失效。 每个令牌里都写有会话代次：修改密码、在所有设备上退出，或更改角色，都会让已经发出的密钥立即失效，而不是等它们自己过期。

酒店上线前要做什么

• 填好控制者信息。 只要还有任何一个字段仍是尖括号占位内容，门户就会把这份政策视为不可发布，并在管理员面板中提示。
• 说明数据请求的联系渠道——如果已指定数据保护官（第 37 条），还要写明其联系方式。法规不要求公开这位负责人的姓名，但要求提供联系办法。
• 写明医生姓名。 客人既然交出了健康数据，就有权知道是谁在查看，而不只是看到「疗养地医生」这样的说法。
• 签订数据处理协议——要和平台签，如果启用了模型，还要和模型提供方签。在确认之前，开关保持关闭，个人文本不会发出。
• 核对营销表述是否符合分类。 如果酒店网站承诺治疗效果，就会直接推翻「生活方式支持」这一定义。
• 记住年龄门槛。 门户是为成年人设计的；未满 16 岁的人不会创建账户。
• 明确你的监管机构。 政策中会写明它的地址和网站；在捷克，这个机构是 Úřad pro ochranu osobních údajů。

常见问题

• 门户属于医疗器械吗？ 不属于。它不宣称具有医疗用途：不做诊断，不开治疗方案，也不承诺治疗结果。它负责收集并展示数据，决定由医生来做。
• 对客人负责的是酒店还是平台？ 是酒店：它是数据控制者。平台是处理者，按合同和酒店的指示工作。
• 如果客人只是佩戴手表，也需要同意吗？ 需要。每日状态属于健康数据，是 GDPR 第 9 条规定的特殊类别。门户会为此单独取得明确同意，而且可以一键撤回。
• 数据会离开欧盟吗？ 服务器在欧盟内。会离开的有 3 项，而且都写在隐私说明里：通过 Google 登录、借出手表使用的 Garmin 云端，以及交给模型的去身份化文本。
• 模型会用客人的数据学习吗？ 不会。在与服务商的数据处理协议确认之前，任何个人文本都不会传出；而协议本身也禁止再利用和训练。
• 如果客人把所有内容都删除，还会剩下什么？ 数据库里会删除住宿夜数、健康路线、安排项目、饮食日记和员工关于他的备注。留下的是酒店自身的记录：套件交接日志，以及一条已经不再指向任何人的账单记录。

来源

欧盟条例 (EU) 2016/679 — GDPR · 欧盟医疗器械条例 (EU) 2017/745 · 欧盟人工智能条例 (EU) 2024/1689 · Úřad pro ochranu osobních údajů

相关内容

个人数据：两项同意、导出和删除 — 从客人的一侧看同样这些权利，按按钮一步一步说明。

平台如何安排理疗 — 算法在哪里停止，医生从哪里开始。

价格：Setup、Base 和 Active Guest — 启动包含什么，以及活跃客人是怎么计算的。

手表测量什么 — 具体有哪些数字会从手腕传过来。

前台：应用操作 — 为什么套件在交给下一位客人前要先清除。

门户的完整隐私说明无需登录即可查看，就在隐私页面。