冻结的同意问题：AI照护智能体持续按照不再反映当前照护关系的授权行事时的问责困境

在AI护理部署中，同意通常在某个单一时刻被获取：注册时。护理对象或其法定代理人同意一套条款。这些条款描述了智能体可以做什么——可以激活哪些传感器、可以保留哪些数据、可以自主做出哪些决策，以及哪些决策必须上报给人类。同意文件被签署、存储，并在任何关于智能体行为是否经过授权的问题出现时被引用。

冻结的同意问题，就是从那个时刻到部署的每一个后续时刻之间所发生的事情。护理关系在演变。智能体的能力随软件更新而改变。护理对象的健康轨迹在变化——有时好转，更多时候是走向衰退。负责监督部署的人员在更替。然而，原始的同意条款却保持不变。从形式上看，它们仍然有效。从实质上看，它们可能早已不再描述实际部署的任何情况。

为何"新鲜度"并非同意的自然属性

同意框架旨在建立授权，而非维护授权。一旦获得同意，系统便拥有了继续进行的法律许可。几乎不存在任何结构性机制，能够定期检查持续中的部署是否仍然反映了原始授权所设想的内容。

在护理场景中，这一问题尤为突出，因为从注册到问题浮出水面之间的时间往往以月或年计。一个在护理对象行动自如、认知能力完好时监测其活动水平和睡眠模式的智能体，在技术层面上，当该护理对象已基本失去行动能力、认知出现损伤时，仍在有效同意下运行。同意书上写着"为优化健康状况的活动监测"。而智能体实际上正在做的事情，在实质上已大相径庭——却无人注意到，因为表格从未改变。

硬件维度

嵌入式AI护理设备使这一问题更加复杂。在注册时，设备被配置为适应特定的护理情境。该配置——包括传感范围、本地推理模型和升级阈值——被固化在固件中。随着时间推移和情况改变，固件可能会收到更新，但这些更新很少触发同意审查。原始授权保留在记录中；更新后的能力配置文件并未反映在任何新的同意中。

一台被授权监测跌倒风险的设备，在固件更新后，可能还运行着情绪推理模型。原始能力的授权已存档。新增能力可能根本没有任何在档的同意覆盖。

护理场景中没有任何自然机制来呈现这一差距。设备在运行。护理对象未被提示重新表示同意。监督人员假设：设备既然已部署，就已获得了适当的授权。那份对新增能力只字未提的授权记录，被当作全面完整的文件来对待。

时间有效性所忽略的东西

密码学证明和法律文件确立的是：同意材料是否真实，以及它在创建时是否有效。它们并不能确立同意是否在实质上仍然准确——它所描述的部署是否仍对应于实际正在进行的部署。

这一区别，恰恰在最难呈现时最为重要。一个监控自身处境能力有限、提出同意审查能力有限的护理对象，也是最不可能注意到管理其护理的授权已偏离现实的人。最需要同意"新鲜度"的人，恰恰最无力要求它。

正确的架构应该是什么样子

维护同意的新鲜度，需要将同意视为持续关系的版本化记录，而非一次性文件。在实践中，这意味着：

与部署事件挂钩的同意检查点：改变智能体功能范围的软件更新，应触发同意审查通知，而非悄然进行。

能力变更披露：当智能体的能力发生变化——无论是通过模型更新、配置变更还是新传感器激活——应将变化增量呈现给监督负责人，而非埋没在固件更新日志中。

长期部署的定期重新授权要求：在注册时获得的同意，应根据护理关系的预期时长和演变速度设置有效期，以结构化的重新授权间隔取代无限期延续。

将同意版本历史与行动历史并列的审计跟踪：以便在任何给定决策时刻，能够还原当时有效的授权，而非仅显示今日恰好存在的授权。

失败模式在紧要关头才会现形

冻结的同意问题不会自行宣告。智能体运行着。护理持续着。授权记录显示着一份签署的同意文件。系统中没有任何标记指示这一漂移。只有当问责被追究时，失败才会变得可见——当事情出了问题，有人问：这个智能体究竟被授权做什么？基于注册时准确、此后从未更新的文件重建的答案，可能已不再描述导致伤害的部署情况。

在Asaptic Labs，我们将同意视为一份活的记录，而非一次性通关的门槛。这意味着设计这样的系统：授权状态被持续地与部署状态相互核验——具备结构化机制，在差距演变为问责事件之前，将其呈现并弥合。