PDPC的指导覆盖生成式AI生命周期中的个人数据使用,包括网络抓取信息、用户为获得普通服务而提交、之后又被重新用于模型开发或改进的数据,也涉及模型部署、安全、保存期限,以及个人提出访问或更正请求时的处理方式。
核心隐私风险在于“目的发生变化”:一个人最初为完成交易、使用账户或获得客服支持而提供的信息,可能后来被大规模用于模型训练或微调。进入大型训练流程后,用户可能更难判断数据究竟如何被重新利用,也更难控制数据用途或行使访问、更正等权利。
这份指导还区分了AI供应链中不同参与者的责任:
当机构希望使用“用户数据”开发生成式AI模型,而PDPA中没有适用的同意例外时,就必须通过AI专项通知取得同意。通知不能只使用“服务优化”“个性化”或“产品改进”等宽泛说法,而应直接写明生成式AI模型开发或改进这一用途。
这一点尤其适用于这样的情形:用户最初通过既有产品或服务提交信息,目的并不是生成式AI;企业随后却希望把这些信息重新用于模型训练或微调。企业需要结合最初的收集场景、新的使用目的以及是否存在法定例外,逐项判断后再决定如何处理。
PDPA关于公开可用数据的例外,可能允许企业在开发模型时不经同意收集公开可用的个人数据。但这并不意味着所有网上可见的信息都自动符合条件。处于付费墙、登录、注册要求或类似数字障碍之后的数据,是否仍属于该用途下的“公开可用数据”,需要谨慎评估。
不过,删除姓名并不一定等于匿名化。如果结合数据中剩余的信息,或结合其他合理可获得的信息,仍有可能识别某个人,那么这份数据可能仍不能视为真正匿名。企业需要评估匿名化过程是否确实消除了识别个人的可能性。
现有材料没有确立一项专门针对呼叫中心录音的、适用于所有情形的独立例外。只要录音能够识别,或可以合理地识别来电者,就应在评估生成式AI再利用时将其视为个人数据。
因此,企业在把录音用于模型开发前,仍需确认是否有适用的PDPA依据,例如有效同意、合规通知或其他法定例外。具体结论取决于录音内容、收集方式、拟议的生成式AI用途及适用的PDPA例外;现有来源不足以支持额外的“呼叫录音专门规则”。
通知应以具体、具有实际意义的方式向个人说明拟议用途。根据现有指导,至少应包括:
通用隐私政策仍可用于提供背景信息,但如果其中没有清楚说明生成式AI训练用途,就不应成为唯一披露方式。判断标准很简单:一个合理的用户能否看懂自己的个人数据可能会被用于开发或改进生成式AI模型?
现有材料没有规定所有机构必须采用同一种格式或唯一的展示位置。实际操作中,企业可以考虑在收集相关数据或用户使用服务的场景提供通知,例如:
这些具体位置属于实施层面的合理推断,并非PDPC事实说明中列出的穷尽清单。无论采用何种形式,通知都应容易发现、内容具体,不能埋在冗长而笼统的条款中。
即使个人数据已经被用于生成式AI开发,个人仍可以提出访问或更正个人数据的请求。企业应在数据进入训练流程前后采取合理的数据管理措施,逐案评估请求,并采用适当的技术手段;不过,在大型训练数据集中追踪特定信息可能存在实际困难。
如果企业以同意作为法律依据,就必须告知用户如何拒绝或撤回同意。但这并不自动意味着用户退出后,仍能在完全不变的条件下继续使用服务的每一项功能。能否继续使用核心服务,要看生成式AI训练对该服务是否必要,以及企业的同意设计是否合规。现有来源没有确立“用户每次退出后都必须保留完整服务访问权”的一刀切规则。
IMDA的《生成式AI聊天机器人透明度指引》采取面向消费者的思路,适用于部署外部、面向公众的生成式AI聊天机器人。其目标是帮助用户作出更知情的使用决定,推动披露方式更加统一,并让企业对自己公开承诺的安全性和可靠性措施承担更清晰的责任。
信息卡应遵循三项原则:
一张有用的信息卡应覆盖以下内容:
信息卡不是对聊天机器人准确性或安全性的保证。它的价值在于,为用户提供更清楚的判断依据:什么时候可以参考工具、哪些信息不应轻易提交,以及出现问题后可以通过什么渠道寻求处理。
Google、Meta、DBS、OCBC、新加坡航空和Synapxe均表示,会把这套自愿性指引作为改进面向公众聊天机器人透明度实践的参考。这代表企业计划持续对齐和改进,并不意味着每家公司已经上线完全相同的信息卡。
对银行而言,重点可能包括解释面向客户的功能和限制,并将相关披露与既有的AI治理、风险管理流程结合起来。DBS提到了其面向客户的AI项目;OCBC则将这份指引与自身既有的AI治理和风险管理体系联系起来。
新加坡的做法,是把更具体的生成式AI数据隐私披露,与一套自愿性的公众聊天机器人透明度标准结合起来。两项措施相辅相成,但不能相互替代。企业可以按以下步骤准备: