AI 助力应用程序的 AI 治理

理框架 为AI助力的应用程序建立治 人工智能(AI)的发展日新月异，各行各业的企业都在以前所未有的速度部署AI助力的应用程序。例如，在PrismaCloud的2024年云原生安全现状报告1中，100%的受访者都表示自己欣然接受AI辅助的应用程序开发——对于这个几年前还被许多人视为科幻的技术来说，这确实是一个让人惊讶的结果。然而，尽管AI系统提供了巨大的优势，但也带来了全新的安全风险和治理挑战，而传统的网络安全方法并不具备应对这些风险和挑战的能力。 作为一名安全领导者，必须了解AI的现状、其潜在隐患以及给企业带来的独特风险。在本白皮书中，我们概述了AI的形势，强调了关键的安全考虑因素，并提出了一个治理框架，帮助您在这个复杂的环境中做到游刃有余。您将清楚地了解企业可能有机会探索的关键AI技术及其安全隐患，以及需要考虑哪些潜在的防护和缓解措施。我们还将帮助您了解在制定AI安全战略时需要考虑哪些因素。 1https://www.paloaltonetworks.com/state-of-cloud-native-security PrismabyPaloAltoNetworks|白皮书|AI治理1 当前的AI形势及其安全隐患 近年来，AI领域发生了翻天覆地的变化，随着企业评估和实施一系列新技术，无论是通用系统还是专用系统都取得了重大进展。 为了应对AI的相关风险和机遇，安全领导者需要时刻把握这个不断发展的生态系统的脉搏。风险可能以多种形式表现出来，正如我们最近的研究发现的一样，47%的企业都在担心与AI生成的代码相关的安全风险2。 在本文中，我们将重点关注部署AI助力的应用程序时出现的云基础设施风险。 截止到今天，以下是AI领域的基本轮廓。 传统的AI和机器学习 用例 •制造优化、供应链、欺诈检测、 营销 安全风险 •数据完整性、模型性能监控、偏见 审核、访问控制 “传统的”AI和ML 多年来，各家企业一直在利用特定于领域的AI和机器学习(ML)推理工具来提高制造、供应链优化、欺诈检测、在线营销和其他领域的效率和自动化程度。这些狭义的系统在特定的数据集基础上进行训练，用于执行明确定义的任务。虽然这些系统已经成为许多业务流程不可或缺的一部分，但每个应用程序通常都是孤立的，并且作用范围有限。 虽然这些工具已经存在了很长一段时间，并且近年来可能没有经历什么突破性的进展，但它们受到了“水涨船高”现象的影响。围绕着AI的广泛热情正在推动着人们加速投入预算来部署这些工具以及最新的LLM工具。 安全隐患 •确保用于训练和运行AI/ML模型的数据的完整性和安全性 •监控AI/ML系统是否存在异常行为、意外输出或性能下降，这些现象可能表明存在数据中毒攻击、模型规避和系统入侵等安全问题 •验证AI/ML模型没有引入无意识的偏见、公平性问题或歧视性结果，从而避免产生法律和名誉风险，这就需要定期对模型审核公平性 •提供适当的访问控制和治理，规定谁可以开发、修改或使用AI/ML 系统 2https://www.paloaltonetworks.com/state-of-cloud-native-security 大型语言模型 LLM已经发展成一种高度全能的通用AI系统，能够进行开放式的对话、生成连贯的文本，甚至还能编写代码。虽然面向消费者的聊天机器人（如ChatGPT）引起了广泛关注，但这也只是冰山一角。LLM的更大影响力在于能够以终端用户通常无法立即察觉的方式，为各种各样的企业应用程序（包括内部应用程序和面向客户的应用程序）注入动力。 在这个大背景下，有几类实现模式，每一类都依赖于一套不同的工具并带来相关的安全隐患。 预训练的基础模型 •内容生成、聊天机器人、情 用例 感分析、翻译、代码助手 •影子AI项目、数据隐私、模 安全风险 型治理、输出控制 微调和RAG •专业AI助手（支持、人力资 源、IT）、问答应用（文档、 •微调过程中敏感数据的暴 露、数据治理 LLM 代码、培训） 自定义模型训练 •高级应用（药物研发、材料 科学、自主系统） •数据中毒攻击、计算资源 隔离、模型可问责性和可 审核性 使用预训练的LLM（专属或开源） OpenAI和Anthropic等云提供商提供API来访问功能强大的LLM，并由其负责管理和保护。企业可以利用这些API将LLM功能纳入自家的应用程序，不必亲自管理底层的基础设施。 另外，一些开源的LLM（如Meta的LLaMa）也可以在企业自己的基础设施上运行。这提供了更多的控制和定制选项，但需要大量的计算资源和AI专业知识才能安全实施和维护。 LLM有多种部署模式： •基于API的SaaS：基础设施由LLM开发者（如OpenAI）提供和管理，通过公共API配置。 •由CSP管理：LLM部署在超大规模云服务商提供的基础设施上，可在Azure、OpenAI和AmazonBedrock等私有云或公有云中运行。 •自我管理：LLM部署在公司自己的基础设施上，只适用于开源或自主研发的模型。 典型用例 LLM的用例包括内容生成、聊天机器人、情感分析、语言翻译和代码助手。电子商务公司可能会使用LLM来生成产品描述，而软件开发公司可以利用LLM助力的编码助手来提高程序员的生产力。 安全隐患 方便访问的云API和开源模型的出现大大降低了向应用程序添加高级AI语言功能的门槛。开发人员现在不需要具备AI和ML方面的深厚专业知识，就可以将LLM植入自己的软件中。这在加速创新的同时，也增加了影子AI项目的风险，即缺乏适当的安全性和合规性监督。与此同时，开发团队可能会在没有充分考虑到数据隐私、模型治理和输出控制问题的情况下尝试使用LLM。 微调和检索增强生成(RAG) 云API和开源模型的可用性增加了影子AI项目的风险 为了针对特定的应用程序定制LLM，企业可以在与目标任务相关的较小数据集基础上对LLM进行微调，或者实施RAG，这就涉及将LLM与知识库整合，用于问答和内容概括。 典型用例 包括可以访问内部数据的专门AI助手（例如，用于客户支持、人力资源或IT帮助台）和问答应用程序（例如，用于文档记录、代码存储库或培训材料）。例如，电信公司的客户服务聊天机器人可以根据产品文档、常见问题解答或过往的支持互动进行微调，更好地帮助客户解决技术问题和进行客户管理。 安全隐患 微调和RAG使企业能够根据自身的特定领域和数据调整LLM，从而获得更有针对性、更准确的输出。但是，这种定制过程往往涉及到在训练过程中将模型暴露于敏感的内部信息。这就需要强有力的数据治理实践，确保只有经过授权的数据才能用于微调，并确保由此产生的模型是安全的。 模型训练 通过微调和RAG进行模型训练可能会导致模型暴露于敏感的内部信息 一些大型科技公司和研究机构正在寄希望于从头开始训练自己的LLM。这是一个高度资源密集型的过程，需要大量计算能力和数据集。不过，这样一来公司可以完全控制模型架构、训练数据和优化过程，并对由此产生的模型拥有完全的知识产权。 典型用例 专属LLM的用例包括高度专业化的应用，比如药物研发、材料科学或自主系统。例如，医疗机构可以开发一种模型，帮助根据医疗记录和影像数据诊断疾病。 安全隐患 训练自定义的LLM需要精心策划海量数据集并构建高性能的计算基础设施，这可能会带来新的安全挑战。对于模型可以获取的敏感信息和个人数据，必须彻底审查训练数据。数据中毒攻击也令人担忧，因为这是指对手故意向训练数据中注入恶意示例来操纵模型行为。 训练过程消耗大量的计算资源，因此需要对训练环境实施严格的隔离和访问控制，防止滥用或干扰。在处理复杂的黑盒模型时，如何保持模型行为的可问责性和可审核性也是一个难题。如果模型是自主研发的，这些问题可能会更加紧迫。 安全领导者应该如何理解AI风险的概念 训练自定义LLM需要对敏感信息和个人数据进行彻底审查 网络安全团队已经习惯了玩追赶游戏。更为常见的是，团队必须调整自己的战略和控制，才能跟上新技术（如云计算、容器化和无服务器架构）的采用步伐。然而，AI的兴起给网络安全带来了新的障碍，其中许多障碍与过去的障碍有着本质的不同。 变化更快，而且往往更极端 AI正在给企业带来翻天覆地的变化，而且这种变化的速度远超以往： •新模型、新技术和新应用正在以惊人的速度涌现，每月甚至每周都会出现重大突破。 •企业正感受到巨大的压力，必须快速采用和整合这些技术才能保持竞争力并推动创新。 •通过简单的API就可以使用工具，支持工具和框架的生态系统也应运而生，这些都消除了技能短缺造成的障碍，加速了技术的采用。 快速的技术变革与紧迫的业务需求相结合，可能会带来独特的安全挑战。由于时间紧迫，很难在部署AI系统之前彻底评估风险并实施适当的控制。在匆忙面市的过程中，安全问题往往被抛在脑后。最佳实践和监管指导难以跟上步伐，这意味着安全团队必须在没有行业共识或明确标准的情况下随时适应并做出判断。 不过，这也为从设计上确保AI的安全创造了机会。通过从一开始就将安全和治理考量纳入AI开发流程，企业可以积极主动地降低风险，建立更有弹性的AI系统。这就需要安全、法律和AI开发团队密切合作来遵循最佳实践，将必要的控制整合到AI生命周期中。 更广泛的影响 AI系统的潜在影响是深远的，但不一定能得到很好的理解。AI模型可以自动做出重大决策，生成具有法律意义的内容（比如使用受版权保护的材料），还可以访问大量敏感数据。与AI相关的风险，比如结果偏差、侵犯隐私、知识产权暴露和恶意使用，需要一种完全不同的风险管理模式。 要应对这些更广泛的影响，网络安全领导者需要与法律、道德和业务职能部门的利益相关者合作。需要建立合作治理结构，符合风险承受能力，制定政策和指导方针，并实施持续不断的监测和审核流程。网络安全团队必须与数据科学和工程团队密切合作，将安全和风险管理纳入AI开发生命周期。 需要新型的安全与合规监督 网络安全团队必须与数据科学和工程团队密切合作，将安全和风险管理纳入AI开发生命周期 传统的网络安全框架通常侧重于保护数据的机密性、完整性和可用性。然而，随着AI的发展，公平性、透明度和问责制等其他维度也开始发挥作用。 《欧盟人工智能法案》等新兴的监管框架对企业在AI系统的监督和治理机制方面提出了新的要求。这些法规要求公司评估并降低与AI应用相关的风险，特别是在雇佣、信用评分和执法等高风险领域。合规义务可能会根据具体的用例和涉及的风险等级而有所不同。例如，用于雇佣决策的AI系统可能会接受更严格的审核和透明度要求，确保不会延续偏见或歧视。 这意味着安全团队不能局限于一直以来对访问控制和数据保护的关注，而是必须与法律和合规团队合作，建立对AI模型的实际输出和决策进行监控和验证的机制。这可能涉及实施可解释的AI技术，定期进行偏见审核，或维护有关模型输入、输出和决策逻辑的详细文档来支持合规报告与调查。 威胁检测和补救方面的全新挑战 确保AI系统安全所面临的技术挑战既新颖又复杂，既适用于检测，也适用于补救。 新的威胁类别需要新的检测方法 前面说过，安全团队不仅需要监控底层的数据和模型工件，还需要监控AI系统在生产中的实际输出和行为。这就需要分析大量的非结构化数据并检测新型威胁，比如数据中毒攻击、模型规避技术以及可能以有害方式操纵AI输出的隐藏偏见。现有的安全工具往往不具备处理这些AI特定威胁的能力。 补救远远不是一蹴而就 传统的软件漏洞通常只要几行代码就可以修补，而AI模型的问题则不同，可能需要从头开始重新训练整个模型才能修复。AI模型从训练使用的数据中学习，这些数据会深深嵌入模型的参数中。如果发现训练数据包含敏感信息、偏见或恶意示例，就不可能仅仅是删除或纠正特定的数据点了事。相反，必须在经过净化的数据集基础上对模型进行彻底的重新训练，这可能需要几周或几个月的时间，还要花费几十万美元的计算资源和人力。 再则，重新训练模型也不是万无一失的解决方案，因为可能会降低性能