2025年4月10日,欧洲数据保护委员会(EDPB)发布《AI隐私风险与缓解措施-大型语言模型(LLMs)》,聚焦于大语言模型(LLMs)在数据流动过程中的隐私风险,并提出了全面的风险评估与管理框架,为保障用户数据安全提供了关键指引。
一、LLMs 基础与技术概述
1、定义与架构
大语言模型(LLMs)基于Transformer架构,通过注意力机制处理上下文关系,典型模型包括 GPT、BERT、DeepSeek-V3等。
训练流程:数据集收集(如 Common Crawl)→预处理(分词、嵌入)→模型训练(损失计算、反向传播)→微调(监督学习、RLHF)。
新兴技术:Agentic AI(自主决策代理)结合LLMs与工具调用,涉及感知、推理、记忆模块,2027 年预计 50% 企业试点。
2、应用场景
垂直领域:客户支持(Chatbot)、内容生成(Jasper AI)、医疗诊断辅助、代码生成(GitHub Copilot)。
服务模式:
即服务(SaaS):如 OpenAI GPT-4 API,用户通过API调用,数据流经提供商服务器。
现成模型(Off-the-Shelf):如Hugging Face开源模型,用户可本地部署并微调。
自研模型:企业自主开发,如DeepSeek 自研670亿参数模型。
二、隐私风险与数据流动分析
1、LLMs生命周期各阶段的隐私风险
数据收集阶段:训练、测试和验证集可能包含可识别的个人数据、敏感数据或特殊类别数据。若收集的数据未经严格筛选,可能会将个人详细信息、机密文件等敏感内容纳入其中,比如从网络爬取的数据中可能包含个人身份证号、医疗记录等。此外,数据收集过程可能存在违反隐私权利、缺乏适当同意或侵犯版权等法律问题,如在未获得用户明确授权的情况下收集其数据。
模型训练阶段:模型可能会无意中记住敏感数据,一旦这些数据在输出中暴露,就会导致潜在的隐私侵犯。例如,模型在训练过程中学习到了用户的敏感信息,当生成输出时,可能会意外地将这些信息包含在内。
推理阶段:生成的输出可能会无意中泄露私人信息或包含错误信息。比如,在回答用户问题时,可能会泄露其他用户的隐私数据,或者由于模型的局限性,生成的答案存在事实错误,误导用户。在使用RAG过程中,如果知识bases包含敏感数据且未实施适当的安全措施,可能会导致敏感数据的泄露。此外,反馈循环中用户交互可能未得到充分保护,存在隐私风险。
部署阶段:模型与实时数据输入交互,这些实时数据可能包含高度敏感的信息,需要对收集、传输和存储进行严格控制。例如,在实时聊天应用中,用户输入的信息可能涉及个人隐私,若处理不当,容易造成数据泄露。
运行和监控阶段:监控系统的日志可能会保留个人数据,如用户交互记录,这增加了数据泄露或滥用的风险。若日志管理不善,被未经授权的人员获取,就会导致用户隐私泄露。
重新评估、维护和更新阶段:使用实时用户数据进行更新时,如果没有获得适当的同意或采取安全措施,可能会违反隐私原则。例如,在模型更新过程中,未经用户同意使用其最新数据,可能会侵犯用户的隐私权。
退休阶段:与模型及其操作相关的数据在存档或删除时,如果未能正确擦除个人数据,可能会导致长期的隐私漏洞。比如,删除数据不彻底,使得个人数据在后续仍有被恢复和泄露的风险。
2、LLMs不同服务模式下的隐私风险
LLM作为服务(LLM as a Service):用户通过API与模型交互,数据流经提供商系统。可能存在的风险包括用户输入时敏感数据披露、未经授权访问、缺乏透明度和对抗攻击等;提供商接口和API可能出现数据拦截、API滥用和接口漏洞等问题;LLM处理过程中可能存在模型推理风险、意外数据记录、匿名化失败、未经授权访问日志、数据聚合风险、第三方暴露和缺乏数据保留政策等;处理后的输出可能存在不准确或敏感响应、重新识别风险和输出滥用等问题。以OpenAI GPT-4 API为例,用户依赖其隐私保障,但难以独立验证其合规性。
LLM“现成的”(LLM ‘off - the - shelf’):部署者可自定义权重和微调模型,与LLM 作为服务模式有相似之处,但也有独特风险。例如,组织在使用 “现成的” 模型时,可能因对原始训练数据集内容缺乏了解,引入偏见、不准确或未知的隐私风险;同时,依赖原始提供商进行模型更新,可能会延迟关键改进或修复。此外,在使用 RAG 时,可能存在不安全的日志记录或缓存、第三方数据处理和敏感数据暴露等风险。
自行开发的LLM(Self - developed LLM):组织自行负责模型的设计、训练和部署,虽然有更多控制权,但也面临诸多风险。在数据集收集和准备阶段,可能会包含敏感信息、存在法律合规问题、数据有偏差和受到数据投毒攻击等;模型训练阶段,训练环境可能存在安全漏洞、模型可能出现过拟合并暴露敏感信息;微调阶段,可能会暴露专有或敏感数据、存在第三方风险;部署阶段,可能出现未经授权访问和不安全的托管等问题。
基于LLM的Agentic系统(LLM-based Agentic Systems):AI Agents与其他系统和应用有更多交互,数据流动更复杂。在感知阶段,可能会收集和暴露敏感用户输入、预处理不当保留可识别信息、输入接口存在安全风险和缺乏透明度;规划阶段,敏感数据可能在传输过程中缺乏保护、第三方系统可能不符合隐私和安全标准;记忆阶段,长期存储用户数据增加风险、保留敏感数据可能违反法规;行动阶段,生成的输出可能包含敏感信息、输出共享可能被拦截或滥用、多个Agent协同可能增加幻觉概率;反馈和迭代循环阶段,用户反馈可能在未经同意的情况下被用于模型再训练、敏感反馈信息可能在日志或数据集中持续存在。
三、风险评估与管理框架
1、风险识别
风险因素考量:借助多种风险因素来识别LLMs使用中的风险,如处理敏感数据和大量数据会增加风险等级。同时,需考虑数据质量、系统安全防护措施等因素,低质量数据可能导致模型输出错误,而缺乏足够安全防护则易引发数据泄露。此外,还应关注弱势群体在数据处理中的权益保护,确保其基本权利不受侵害。
相关概念剖析:深入理解《AI法案》中引入的安全概念,如危险(潜在危害源)、危险暴露(个体或系统暴露于危害的程度)、安全(降低危害的措施)、威胁(可能利用系统漏洞的外部因素)和漏洞(系统中可被利用的弱点)等。这些概念相互关联,共同构成评估LLMs风险的基础框架,有助于全面把握风险的本质和来源。
目的与背景的关键作用:明确系统的预期用途和运行背景对风险识别至关重要。《通用数据保护条例》(GDPR)强调依据数据处理的性质、范围、背景和目的来评估风险;《AI 法案》则突出定义和评估AI系统预期运行方式的重要性。只有精准把握这些方面,才能发现系统在特定场景下的潜在风险,如系统被误用或在特定环境中产生意外漏洞等。
威胁建模的运用:威胁建模是系统识别隐私风险的有效方法,它通过利用特定的AI威胁、危害和漏洞库,对AI系统生命周期中的风险进行结构化评估。通过该方法,可识别潜在的攻击面、误用案例和漏洞,为风险评估提供有价值的参考,如发现数据访问权限设置不当可能导致的未经授权访问风险。
证据收集的重要性:为有效管理风险,需基于可靠证据进行评估。这包括收集系统运行数据(如日志和使用模式)、评估结果(来自指标测试、红队演练和外部审计)以及用户或举报人反馈等多方面信息。这些证据相互补充,能全面反映系统潜在的危害和漏洞,为风险识别提供有力支持。
2、风险评估
评估流程与利益相关者协作:在风险识别后,需对风险进行估计和评估,包括依据概率和严重程度对风险进行分类和排序。利益相关者的协作在这一过程中至关重要,由于AI的跨学科特性,需要技术、法律、伦理等多领域专业人员共同参与,从不同角度审视风险,确保评估的全面性和准确性。
概率评估标准:采用四级风险分类矩阵来确定风险概率,即非常高(事件发生可能性大)、高(有较大可能性发生)、低(发生可能性较小)、不太可能(几乎无发生迹象)。通过考虑系统使用频率、暴露于高风险场景的程度、历史先例、环境因素、系统稳健性、数据质量和完整性以及人为监督和专业知识等标准,对每个风险进行评估并打分,进而计算出综合概率得分,以确定风险的概率等级。
严重程度评估标准:同样使用四级风险分类矩阵评估风险严重程度,即非常严重(影响基本权利和公共自由,后果不可逆等)、严重(上述情况影响可逆,但存在数据主体对个人数据失控等问题)、严重但有限(对部分个人数据失去控制等较小影响)、非常有限(上述有限影响可完全逆转)。评估时考虑基本权利性质、个人数据敏感性、数据主体类别、处理目的、影响范围和数量、上下文和领域敏感性、危害的可逆性、持续时间和速度、透明度和问责机制以及连锁反应等标准,其中部分标准具有 “阻断” 作用,若达到最高级别,整体严重程度将直接判定为最高等级。
风险分类与接受标准:综合概率和严重程度评估结果,将风险分为非常高、高、中、低四个等级。通常,非常高和高等级风险应优先缓解。在风险评估阶段,还需依据组织的风险承受能力和合规要求,确定风险是否可接受,确保风险在组织可控范围内。
3、风险控制
风险处理标准:风险处理包括缓解、转移、避免和接受四种策略。选择合适的策略需综合考虑风险类型、可用缓解措施、实施成本和效果、对系统预期用途的影响以及受影响个体的合理期望等因素。例如,对于数据泄露风险,可通过实施加密技术、加强访问控制等措施来缓解;对于一些无法完全避免的风险,若在可接受范围内,组织可选择接受。
缓解措施示例:针对 LLMs 常见的隐私风险,如个人数据保护不足、训练数据匿名化错误等,提出了一系列具体的缓解措施。包括确保 API 安全实施、加密数据传输和存储、实施访问控制和匿名化措施、进行定期安全审计、培训员工安全最佳实践等。同时,不同风险的缓解措施在提供商和部署者之间可能存在不同的责任分配,双方需密切协作,共同应对风险。
四、案例分析与工具标准
1、案例分析
虚拟助手(Chatbot)用于客户查询:某厨房设备公司欲部署基于 “现成的” LLM并使用RAG技术的聊天bot。在设计与开发阶段,详细梳理了数据流程,包括用户输入、数据预处理与API交互、RAG检索、LLM处理、数据存储、个性化响应生成、数据共享和反馈收集等环节。通过分析系统架构和与利益相关者协作,识别出如个人数据保护不足、训练数据匿名化错误等风险。采用FRASP框架评估风险概率和严重程度,多数风险被评为高风险。针对这些风险,采取了如加密数据传输、限制数据收集、审核第三方数据保护实践等一系列缓解措施。实施缓解措施后,风险等级降为中等。若风险仍不可接受,可进一步强化预防控制、探索额外缓解措施或重新评估风险容忍度。同时,要持续监测聊天bot,确保风险始终处于可控范围内。
LLM系统用于监测和支持学生进步:某学校计划采用第三方基于“现成的”LLM模型的系统来监测学生学业表现。由于涉及未成年人敏感信息,存在诸多隐私风险。如数据保护措施薄弱可能导致学生敏感数据泄露,训练数据可能存在非法处理个人数据的情况,模型输出可能存在偏差影响学生等。针对这些风险,建议学校采取的措施包括实施强加密协议、进行安全审计和渗透测试、验证供应商合规性、审核训练数据、监测模型偏差、确保人类监督、保障数据主体权利、明确数据保留政策、评估数据传输风险以及严格控制数据收集等。这些措施旨在全面降低风险,保护学生的隐私和权益。
AI助手用于旅行和日程管理:该AI助手基于多种“现成的”LLMs和SLMs开发,用于管理旅行计划和日常日程。在运营和监测阶段,识别出的隐私风险包括处理特殊类别数据(如从旅行模式推断出的健康状况)、操纵或过度依赖建议、用户对系统操作不了解、缺乏人类监督、数据主体权利行使困难、数据再利用风险、数据保留过长以及跨境数据共享风险等。针对这些风险,采取的缓解措施有文档化数据匿名化方法、实施明确同意机制、监测输出偏差、确保关键决策有人工确认、提供用户友好的数据操作界面、限制数据使用目的、定义数据保留期、验证第三方服务合规性等。这些措施有助于保障用户数据安全和隐私,提升系统的可靠性和用户信任度。
2、工具和标准
评估指标:LLM评估分为内在评估和外在评估。内在评估在受控环境下测试模型性能,外在评估则在实际应用中评估模型的泛化能力和相关性。常用的评估指标包括准确率、精确率、召回率、F1分数、AUC、AUROC等传统指标,以及针对LLM的特定指标,如BLEU、ROUGE用于评估文本生成质量,MoverScore评估语义相似性。此外,还有用于评估模型效率和可用性的指标,如每分钟完成请求数、首次令牌生成时间等。同时,通过一些工具和框架,如GLUE、MMLU、ChatbotArena等基准测试来评估模型在不同任务和场景下的表现。
保障措施和工具:LLMs中的保障措施(或护栏)用于确保模型安全、符合道德和可靠运行。例如,内容过滤器可阻止或标记有害内容,提示拒绝可防止对危险提示的响应,偏差缓解可减少不公平输出,人在回路方法用于高风险应用中的人工监督,后处理解毒可去除有害内容,对抗测试可评估模型应对有害提示的能力。此外,还介绍了一些开源工具,如Anthropic Model Context Protocol用于构建安全连接,llmperf用于评估 LLM API性能,以及OWASP AI Exchange 提供的AI安全指导等。在隐私保护方面,有Clio、RAG with differential privacy guarantees等技术和工具,以及用于标记或匿名化敏感信息的工具,如Google Cloud Data Loss Prevention、Microsoft Presidio、OpenAI Moderation API 等。
方法和指导:介绍了一些用于识别数据保护和隐私风险的方法和工具,如 Practical Library of Threats (PLOT4ai) 用于 AI 系统风险识别,MITRE ATLAS 提供对抗策略知识,Assessment List for Trustworthy Artificial Intelligence (ALTAI) 指导开发者实施可信 AI 原则。同时,还列举了一些相关的指导文件和标准,如 OECD 关于 AI 语言模型的报告、NIST 的 GenAI Security 和 AI Risk Management Framework、FRIA 方法以及 AI Cyber Security Code of Practice 等,这些指导和标准为 LLM 系统的开发、部署和风险评估提供了重要的参考依据。
转载链接:https://www.tbtguide.com/c/mypt/gwxw/595823.jhtml
关注“广东技术性贸易措施”,获取更多服务。