夜雨聆风学习资料网

ARTICLE · 1111746

美战争部加速任务软件指令中AI生成代码的责任归属与制度逻辑

美战争部加速任务软件指令中AI生成代码的责任归属与制度逻辑
摘要:2026年8月31日,美国战争部首席信息官柯尔斯滕·戴维斯签署战争部指令8430.01《加速任务软件》,该指令于9月8日正式生效。指令围绕“软件定义战争”概念,构建了人工智能辅助软件开发的制度框架,其核心原则是将AI生成代码定性为“未经验证的输入”,明确开发者对AI生成代码的完全责任不因AI的介入而免除。指令同时要求对涉及安全关键功能的人工智能生成代码实施强制性人工审查,建立涵盖安全性、问责机制与风险管理的基线标准。本文从责任归属的制度设计、数据安全与供应链保障、软件复用与采办逻辑调整三个维度,分析该指令的制度逻辑及其对军事软件工程体系的影响,并探讨其在技术、组织与文化层面的实施挑战。
关键词:任务软件加速;人工智能辅助软件开发;责任归属;软件定义战争;军事软件工程
一、引言
美军近年来持续推进“软件定义战争”能力建设。联盟联合全域指挥控制(Combined Joint All-Domain Command and Control, CJADC2)、人工智能应用平台和战术边缘系统均依赖快速迭代的软件能力,而传统军用软件开发周期长、交付慢,难以适应高节奏作战需求。2025财年《国防授权法》第804条要求国防部建立软件采办的替代路径,加速能力交付。在此背景下,AI辅助软件开发被视为提升软件交付效率的关键手段。
2026年8月31日,美国战争部首席信息官柯尔斯滕·戴维斯签署战争部指令8430.01《加速任务软件》,该指令于9月8日正式生效。指令明确将“AI辅助软件开发”定位为交付速度和质量的“显著力量倍增器”,同时确立了“人类责任与问责原则”,要求开发者和开发团队对使用AI生成或修改的任何代码的安全、功能和完整性承担完全责任。该指令的出台,标志着美军在AI辅助软件开发领域从鼓励探索转向制度规范。
二、AI生成代码责任归属的制度设计
(一)“未经验证的输入”的法律定性
指令中最具制度含义的条款,是将AI生成代码明确定性为“未经验证的输入”。这一表述的实质,是在法律和工程管理层面将AI生成代码的地位等同于未经检验的第三方数据或外部输入,而非可信的软件构件。
这一定性的制度逻辑在于责任链条的完整性。传统软件开发中,代码作者对其代码的质量负责;引入AI工具后,如果AI被视为“共同作者”或“智能代理”,则可能产生责任归属的模糊地带。指令通过将AI生成代码降格为“输入”,确保了责任链条的单一指向:无论代码由谁生成,最终对其质量负责的始终是人类开发者。指令明确表述为:“开发者或政府对最终工作成果的责任不因AI的使用而免除”,该条款见于指令正文第4.2节。
(二)安全关键代码的强制人工审查
指令对涉及安全或功能关键性的AI生成代码,规定了强制性的“人工审查与批准”要求。这一规定与美军长期以来在武器系统中坚持的“人类判断”原则一脉相承。战争部指令3000.09《武器系统中的自主性》要求自主和半自主武器系统应“允许指挥官和操作员对使用武力行使适当水平的人类判断”,8430.01将这一原则从武器使用延伸至武器系统的软件开发环节。
值得注意的是,指令对“安全或功能关键性”的具体界定标准尚未完全公开。这一模糊性在实践中可能产生两种后果:一是开发者出于审慎,对所有AI生成代码都实施人工审查,降低开发效率;二是开发者通过将代码归类为“非关键”而规避审查,增加安全风险。指令的有效实施,取决于后续配套细则对“关键性”标准的明确。
(三)记录保存与可追溯性要求
指令要求软件工作保留用于生成或测试软件的模型、版本和重要数据集的记录,并将该信息作为综合软件证据包的一部分,类比于软件物料清单。这一要求的制度含义在于建立AI驱动组件的可追溯性,使审查者能够评估AI生成代码的来源、生成条件和验证历史。
在传统软件工程中,软件物料清单用于追踪软件中使用的第三方组件及其版本,以评估供应链风险。将AI模型版本和数据集的记录纳入证据包,实质上是将AI工具本身视为软件供应链的一个环节。这一制度创新回应了AI生成代码的一个核心难题:当代码质量出现问题时,如何追溯其生成过程并判断问题根源。
三、数据安全与供应链保障
(一)非公开信息的输入限制
指令对政府信息输入生成式AI工具设置了明确限制:“非公开的战争部信息,包括代码、配置脚本、基础设施定义、原理图或文档,不得输入或处理于生成式AI应用程序或服务,除非这些应用程序或服务驻留于战争部信息系统并经战争部人员批准使用”。
这一限制的出台背景是商用生成式AI工具的快速普及带来的数据泄露风险。开发者在日常工作中可能无意间将敏感代码或配置信息输入公共AI工具,导致信息泄露。指令将“批准使用”作为输入非公开信息的前提条件,实质上是将AI工具纳入现有的信息安全审查体系。
(二)经批准服务的数据保护要求
对于经批准使用的AI服务,指令要求其提供合同保证:政府数据和用户提示不会被共享或用于训练公共或战争部外部的模型,并允许指定机构审计和监控其使用。这一要求回应了企业AI服务中普遍存在的“数据用于模型训练”条款所带来的安全风险。
(三)第三方和开源组件的风险评估
指令要求对采用的每一个第三方组件评估六项风险因素,包括安全性、许可证合规性、供应链可靠性等。这一要求将AI辅助开发与软件供应链安全管理整合在同一框架内。据MeriTalk 2026年9月15日报道,Hunted Labs等安全厂商已针对该指令的合规要求发布了分析报告,表明产业界已开始响应这一制度变化。
四、软件复用与采办逻辑调整
指令的制度设计不仅限于AI生成代码的治理,还延伸至软件采办逻辑的整体调整。
(一)“默认企业复用”原则
指令将“默认企业复用”确立为七项现代软件原则之一,要求优先使用现有软件、组件、框架和平台,以及开源软件和商用现货解决方案,而非从头开发新能力。这一原则的提出,反映了美军对软件采办中重复建设和资源浪费问题的反思。
在传统采办模式下,各军种和项目办公室倾向于根据自身需求定制开发软件,导致大量功能重叠的系统并存。指令要求各部门将定制开发的代码在公共或私有代码库中共享,以促进全军范围内的复用。代码在共享前需删除个人身份信息和其他敏感数据。
(二)“以验证换取信任”的治理逻辑
指令的治理逻辑可以概括为“以验证换取信任”。在AI辅助开发中,开发速度和代码质量之间存在内在张力。指令没有选择限制AI工具的使用来保证质量,而是选择了允许广泛使用AI工具、同时建立严格的验证和审查机制来管理风险。这一逻辑的实质,是将AI视为需要管理的风险源,而非需要限制的危险因素。
从制度经济学的角度看,这一设计降低了AI工具使用的制度门槛,同时提高了验证环节的标准化要求。开发者可以自由使用AI工具提高效率,但必须为其输出承担与传统手工编写代码同等的验证义务。
五、实施挑战
(一)自动化偏见的系统性风险
指令要求对安全关键代码实施人工审查,但学术研究表明,人类审查者在面对AI建议时存在“自动化偏见”——即倾向于过度信任自动化系统的输出,忽视其中可能存在的错误。据Parasuraman和Riley 1997年发表的系统综述(涵盖航空、医疗、军事和核安全领域74项研究),自动化偏见在这些领域中普遍存在。在AI生成代码的审查中,如果人类审查者因为AI输出的流畅性和表面上的合理性而降低审查强度,则“人工审查”可能沦为形式化的“橡皮图章”。
指令本身并未包含针对自动化偏见的缓解措施。如何在制度设计中嵌入“认知韧性”要求——例如要求审查者独立验证AI生成代码的关键逻辑、引入第二独立审查者、或使用对比性测试方法——是后续实施细则需要解决的问题。
(二)AI生成代码的隐性安全缺陷
研究表明,AI生成代码可能包含人类审查者难以发现的隐性安全漏洞。据Veracode 2025年发布的GenAI代码安全评估报告,在其测试的100个AI生成应用程序中,45%的代码包含OWASP Top 10漏洞,如硬编码密码、SQL注入风险和缺失安全令牌等。
指令要求所有AI生成代码“经受与手工编写代码相同或类似的严格代码审查和安全测试”,但这一要求的前提是审查和测试方法本身能够发现AI生成代码中的特定缺陷类型。如果现有审查流程主要针对人类开发者常犯的错误设计,其对AI特有缺陷的检出能力可能不足。
(三)组织文化与技能转型
指令对开发团队提出了新的技能要求:除了传统的编码能力,还需要具备AI工具使用能力、AI生成代码的审查能力和对AI模型局限性的认知。同时,指令对非公开信息输入AI工具的限制,要求开发者在日常工作中对信息分类和工具选择保持高度警觉。
美军近年来已通过“War Force”人才招募计划和网络学徒项目等措施扩大技术人才队伍。但据GovCIO Media 2026年9月24日报道,Google Gemini AI代理已部署至约300万五角大楼用户,其中仅约2.6万人接受了正式培训。培训覆盖面与工具部署速度之间的差距,可能构成指令有效实施的人力资源制约。
六、结语
战争部指令8430.01的核心贡献,在于为AI辅助军事软件开发建立了一套“加速与问责并行”的治理框架。其制度设计的核心特征在于:不通过限制AI工具的使用来管理风险,而是通过将AI生成代码定性为“未经验证的输入”、要求人类开发者承担完全责任、建立强制审查和可追溯性要求,来确保AI的效率增益不以牺牲安全性为代价。
指令的“默认企业复用”原则和软件复用要求,则从采办逻辑层面回应了军用软件开发的效率问题,推动美军软件能力生成模式从项目周期驱动向持续迭代模式转变。这一转变与CJADC2、AI应用平台和战术边缘系统对快速迭代软件能力的依赖是一致的。
指令能否实现其制度目标,取决于三个层面的进展:技术层面,AI生成代码的审查和测试方法能否有效检出AI特有缺陷;组织层面,开发团队能否在工具部署和人员培训之间取得平衡;文化层面,开发者能否建立对AI工具输出的审慎信任而非盲目依赖。这些因素的互动结果,将决定这一制度框架是成为军事软件工程的典范还是形式化的合规程序。其后续进展的关键观察节点包括:战争部各部门实施细则的出台时间、AI生成代码审查标准的明确化、以及实施首年的合规数据。
【参考文献】
[1] Department of War. DoW Instruction 8430.01: Accelerated Mission Software[Z]. Washington D.C.: Office of the DoW Chief Information Officer, 2026-08-31.
[2] MeriTalk. Pentagon CIO Sets Rules for AI-Assisted Software Development[EB/OL]. (2026-09-15). https://www.meritalk.com.
[3] DefenseScoop. Pentagon sets procedures for AI-assisted software development[EB/OL]. (2026-09-14). https://defensescoop.com.
[4] Parasuraman R, Riley V. Humans and Automation: Use, Misuse, Disuse, Abuse[J]. Human Factors, 1997, 39(2): 230-253.
[5] Veracode. 2025 GenAI Code Security Report[R]. Burlington: Veracode, 2025.
[6] GovCIO Media. DOW Turns to Training, Access to Drive GenAI.mil Adoption[EB/OL]. (2026-09-24). https://govciomedia.com.

【本文内容信息来自国(境)外相关信息源,为开源文献,由军融国动智库研究人员编译/写,后进行了文字加工处理,文中具体技术信息和数据仅供参考,不代表本公众号观点,请自行甄别使用。】

相关学习资料