人工智能正在迅速改变医疗健康与生命科学（HCLS）领域的软件开发方式。从患者互动应用到临床试验管理平台，开发团队越来越多地借助AI编码助手来更快地编写、审查和优化软件。
对制药和生物科技企业而言，这种吸引力显而易见。支持临床研究、监管数据管理和真实世界证据（RWE）分析的数字平台正逐年变得更加复杂。AI驱动的开发工具承诺能够加快交付速度，同时帮助团队跟上数据量增长和监管要求演变的步伐。
AI也在为现代化改造支撑该行业大量基础设施的遗留系统创造新机会。企业可以利用AI重构老旧应用、转换遗留语言和架构、加速向新平台的迁移。但现代化并不能消除安全风险。用AI重构的遗留应用可能会暴露出原始代码中从未被发现的漏洞，而AI系统本身也可能在此过程中引入新的漏洞。仅仅因为用现代工具重写了代码，并不意味着代码就是安全的。
随着AI逐渐融入开发全流程，创新必须与同样成熟的软件安全方法相匹配，尤其对于负责保护受保护健康信息（PHI）和敏感研究数据的组织而言更是如此。
制药行业AI辅助开发的兴起
由大语言模型驱动的AI编码助手正越来越多地成为开发工具链的常见组成部分。这些系统能在几秒钟内生成代码、识别漏洞、提出修复方案并建议架构改进。在医疗健康与生命科学领域，它们已经影响到以下系统：
临床试验管理平台
电子数据采集系统
数字疗法应用
真实世界证据与分析平台
患者互动与远程医疗工具
对于运行大规模研究项目的组织来说，加速软件开发的能力能带来切实的好处。更快的开发周期意味着试验基础设施可以更快部署，真实世界证据的分析平台更加敏捷，面向患者的数字服务也得以改善。
但更快的代码生成并不一定意味着代码更安全。由研究员伊利亚·卡巴诺夫（Ilya Kabanov）开展、Checkmarx委托完成的同行评审研究《天气报告》（The Weather Report）发现，前沿AI模型生成功能性代码的成功率为83%至95%，但其中只有24%至36%的代码既具备功能性又安全。即使应用了AI辅助的安全技术，这一比例也仅达到47%至56%。这些发现揭示了一个根本性的挑战：AI能够生产出可运行的软件，却无法稳定地生产出安全的软件。
对制药企业而言，这一差距至关重要。支持临床研究、患者服务或敏感业务流程的软件中出现漏洞，其后果可能远远超出普通应用缺陷的范畴。
为何保护敏感数据正变得更加复杂
医疗健康与生命科学组织本就在严格的要求下运营，以保护患者和研究数据。在美国，《健康保险携带和责任法案》（HIPAA）确立了有关PHI的要求，而制药公司在处理跨司法管辖区的临床试验数据、患者登记和研究合作时还面临额外义务，而且这一监管底线正在迅速提高。
欧盟《人工智能法案》的处罚机制现已具备可执行性，最严重违规行为的罚款可达3500万欧元或全球年营业额的7%（以较高者为准），这一上限甚至超过了《通用数据保护条例》（GDPR）规定的最高罚款。加州则采取了一种范围更窄但更具针对性的做法：AB 3030法案现在要求医疗机构、诊所和医生办公室在使用生成式AI生成有关患者临床信息的沟通内容时向患者披露，除非该内容已经过持证医护人员审核。
这些规则背后的技术挑战也正变得越来越难以解决。从数据集中删除姓名等直接标识符，过去被认为是足够的去标识化手段，但如今这种做法越来越不够用。AI模型足够强大，能够将匿名化的临床或试验数据与其他公开信息进行交叉比对，从而使重新识别出具体患者身份成为一种现实风险，而非仅仅停留在理论层面——这种现象有时被称为“马赛克效应”。与AI供应商共享数据同样带有自身的合规义务：根据HIPAA，向外部AI系统提供PHI访问权限通常需要事先签署《业务伙伴协议》。如果没有这份协议，即便是部分或无意的信息披露，也可能构成实质性的合规违规。
随着AI从辅助性工具向更具自主性的开发方式转变，这一挑战将变得更加突出。这种转变正开始将传统的软件开发生命周期重塑为可以称之为“AI驱动开发生命周期”（AI-DLC）的新模式，在这种模式下，人类开发者与AI智能体在开发环境、代码仓库及其他软件构建系统中协同工作。
一个能够跨代码仓库操作、修改多个文件、运行测试、调用工具或与其他系统交互的智能体，其操作范围远比传统的代码补全助手更为广泛。因此，最小权限访问、监控和可审计性正日益成为AI开发治理中愈发重要的组成部分。对制药行业而言，这种治理不能仅着眼于保密性：支持研究和医疗流程的软件还必须保持可靠性、完整性和可追溯性。
AI带来新的软件供应链风险
安全挑战并不仅限于AI系统编写的代码本身。AI编码助手经常会推荐开源软件包，以帮助开发者更快实现功能。但大语言模型也可能“幻觉”出实际并不存在的软件包名称，而攻击者已经学会利用这些名称注册恶意软件包，并在其中植入恶意代码。
在这种情况下，漏洞不一定是写入应用程序自身代码中的，它可能是通过开发者接受的某个依赖项进入系统的，因为该依赖项看起来像是一个合理的推荐。对于处理临床试验数据或专有研究成果的机构而言，一个被攻破的依赖项可能会暴露出应用安全控制本应保护的核心信息。
这说明保障AI辅助开发安全需要超越应用程序本身的可见性。安全团队不仅需要了解AI系统生成了哪些代码，还需要了解正在使用哪些智能体和模型、它们引入了哪些组件和依赖项、能够访问哪些开发工具和服务，以及这些系统在整个软件供应链中是如何相互交互的。随着AI智能体获得自主选择软件包、调用工具和执行开发任务的能力，如果不了解周边的智能体环境而仅仅保障输出结果的安全，将留下重大盲点。
安全必须以AI的速度运行
AI辅助乃至日益智能体化的开发方式正迫使组织重新思考安全应在软件生命周期中的何处、以何种方式发挥作用。随着开发者从亲自编写每一行代码转向指导、审查和维护由AI智能体生成的代码，将安全视为下游检查点的传统模式正变得愈发难以为继。
历史上，安全测试往往在开发后期进行，例如在预发布或最终发布检查阶段。当开发者和AI智能体能够持续不断地生成和迭代代码时，这种做法正变得越来越不合时宜。在AI驱动的开发生命周期中，安全需要作为开发过程中持续存在的一部分，而不是中间或最终的关卡。
AI原生开发压缩了开发周期。更多的代码能够在更短的时间内被生成、修改和测试，这就有可能导致安全审查成为瓶颈，或者漏洞积累的速度超过团队修复的速度。
为此，组织开始采用更具智能体特性的安全模型，让AI在代码编写过程中直接参与漏洞的识别、优先级排序和修复，而不只是生成报告留待人工后续分诊。这是问题的一个方面：利用AI进行安全防护，使防御性分析能够跟上AI驱动的软件创建速度。
目标并非减缓AI辅助开发的速度，而是在软件被创建和修改的同一速度下提供安全反馈，包括在提示词被转化为代码的过程中，以及在高风险变更深入开发流程之前。
因此，安全分析应当出现在开发者和AI智能体已经在工作的地方，包括开发环境、代码仓库、拉取请求和CI/CD流水线，而不应主要被视为部署前的最终关卡。漏洞、不安全的依赖项、泄露的密钥或违反策略的情况被识别得越早，它们在日益自动化的工作流程中蔓延的可能性就越小。
这种方法同样为防御性使用AI创造了机会。安全分析和修复可以越来越多地与代码生成同步自动化，使漏洞能够在同一开发流程中被识别、解释、排序和处理。与此同时，组织还必须通过保持对参与软件构建的智能体、模型、工具、数据和权限的可见性，来确保AI系统自身的安全。
其结果是形成一个持续的安全反馈循环，而不是一系列互不相连的安全关卡。在智能体化模式下，应用安全（AppSec）本身成为开发过程的一部分，在人类与AI系统协同工作的过程中提供预防、可见性、治理和修复能力。
在采用AI开发工具的同时保持合规
制药公司无需在AI驱动开发与负责任的软件安全之间做出二选一。它们需要的是一种治理机制，能够在开发日益智能体化的过程中让二者协同运作。这意味着不仅要治理最终产出的代码，还要治理参与代码生成过程的智能体、模型、工具、数据流和权限。以下几项实践有助于建立这一基础。
制定明确的AI工具使用政策和防护措施。组织应当明确规定开发者和AI智能体可以如何使用编码系统、哪些类型的数据可以与外部模型共享、哪些工具和模型符合组织要求，以及自主系统被允许拥有何种级别的访问权限。政策还应当涵盖诸如AI驱动的开发环境和模型上下文协议（MCP）服务器等新兴组件被引入工作流程时的情况。
防止敏感数据泄露
开发者应避免在提交给外部AI系统的提示词中包含PHI、临床数据或专有研究信息。技术控制手段可以在数据到达AI服务之前进行检测和拦截，从而对开发者的政策起到补充作用。
将安全融入开发工作流程。嵌入在开发环境、代码仓库、拉取请求和CI/CD流水线中的安全能力，可以分析应用程序、开源依赖项、基础设施配置和密钥信息。这些能力还应仔细审查AI编码系统推荐的软件包及其所做的更改，而不是将智能体生成的输出默认视为可信。其目标是在风险的源头就将其防止或暴露出来，此时仍有充分的上下文可以快速纠正。
保持透明度和可审计性。随着欧盟《人工智能法案》和各州级披露法律等监管框架不断提高组织需要证明的标准，涵盖AI系统使用方式、哪些智能体和模型参与开发、它们能够访问什么、采取了哪些行动，以及其输出经过何种安全检查的审计记录，已不仅仅是良好实践，而是合规的必要条件。
对AI系统实施最小权限访问。AI智能体应仅获得完成其指定任务所需的权限，对源代码仓库、凭证、开发工具和生产系统的访问应受到适当限制和监控。随着智能体获得调用工具和跨多个系统行动的能力，控制智能体能够触碰什么，正变得与审查其产出的代码同样重要。
创新与安全必须同步推进
AI辅助开发正在成为现代软件工程中永久性的一部分。对HCLS组织而言，问题已不再是是否要采用这些工具，而是无论是用于构建新能力还是现代化改造运行多年的软件，如何才能安全地整合这些工具。
数字创新对于推动医疗健康发展至关重要，从去中心化的临床试验到为治疗决策提供依据的真实世界证据平台，无一不依赖于此。AI辅助开发有潜力显著加速这些工作的推进。但安全模型必须与开发模型同步演进。
如今的挑战已不再仅仅是防止开发者在使用AI编码助手时犯错，而是要打造这样一种软件开发环境：人类与AI智能体能够快速生产和修改代码，同时安全性、隐私性、数据完整性和治理能力始终贯穿整个过程。这正是新兴AI驱动开发生命周期的核心安全挑战：既要保障AI所创造的成果的安全，也要保障允许智能体行动的环境的安全。对制药行业而言，目标不应是减缓AI原生开发的采用步伐，而应是让安全开发成为其内在的组成部分。
随着该行业从AI辅助编码迈向日益AI原生化和智能体化的软件工程，企业需要明确地为构建者与智能体协同工作进行设计。那些将预防、可见性、最小权限访问、可审计性和持续安全融入这一转型过程的组织，将能够更好地把握更快开发带来的收益，同时不损害患者、研究合作伙伴或监管机构的信任。
Q&A
Q1：AI编码助手生成的代码安全吗？
A：研究发现，前沿AI模型生成功能性代码的成功率为83%至95%，但其中只有24%至36%的代码既具备功能性又安全，即使应用AI辅助安全技术，比例也仅达47%至56%，说明AI生成的代码能运行但不一定安全。
Q2：制药企业使用AI开发工具会面临哪些合规风险？
A：主要风险包括PHI等敏感数据意外泄露给外部AI系统、未签署业务伙伴协议导致的HIPAA违规，以及欧盟《人工智能法案》和加州AB 3030等法规带来的更高披露和处罚要求。
Q3：企业该如何保障AI智能体参与开发时的安全？
A：应制定明确的AI工具使用政策、防止敏感数据进入提示词、将安全检测嵌入开发工作流程、保持审计可追溯性，并对AI智能体实施最小权限访问控制，限制其可触及的系统和数据范围。
