一家AI咨询公司在技术调研阶段发现，其软件将被用于战争中的自主致命决策，随即拒绝了一份高额合同。这次拒绝并没有为所有AI企业划定边界。它表明的是：当管理层和工程师必须决定是否接下某项具体工作时，一条既定原则可能真正发挥作用。
项目范围逐渐明朗
这位潜在客户正在开发自动化硬件系统，希望对方协助设计用于遥控设备和自主设备的软件。随着这家咨询公司深入审查技术需求，项目的预期用途逐渐清晰：该软件将在战争中对人类目标作出判断。报酬依然是这项业务的重要组成部分，但团队认为预期用途更为重要。
管理层和工程团队一致同意拒绝这项合作。这一决定出现在技术调研的后期，也就是服务型企业在承接工作前研判客户需求的阶段。这个时间点值得关注：一个项目的伦理分量，往往要在其技术目的被弄清之后才会显现。
▲ 对拟议项目的技术审查
这家咨询公司的创始人兼CEO将不伤害他人视为自己的核心原则。在这件事上，这一原则没有停留在关于负责任技术的泛泛表述上。团队把它落实到一个具体问题上：如果项目继续推进，自己的软件将作出哪些决定？
咨询流程如何影响这一决定
该公司的创始人在Amazon Web Services（AWS）工作五年后，于2022年6月创办了这家公司。公司业务涵盖云迁移、数据与分析，以及人工智能和机器学习。机器学习是指经过训练、能够从数据中发现规律的软件。该公司不提供单个外包人员，而是由自有工程师组成小组，投入以既定成果为导向的项目。
在客户调研中，该公司采用People, Process, Technology（PPT）框架，用于审视项目涉及的人员、工作的开展方式以及项目所需的工具。这种方法旨在让工程师动手实施之前，先识别客户深层的业务需求。它也为技术可行性之外的一个问题留出了空间：建成后的系统究竟会做什么？
这次拒绝说明，这个问题不能总靠“自动化”之类笼统的项目标签来回答。团队必须考虑所提议的软件在客户更大系统中扮演的角色。尽管合同具有可观的收入潜力，管理层和工程师还是得出了相同的结论。
创始人认为，一家公司体现的是其员工每天作出的选择，而不只是它对外宣称的身份。这是一种伦理主张，而不是评估每份合同的可量化规则。在这里，它揭示了声称存在一条边界与为守住这条边界承担经济代价之间的差距。
限制的是一种用途，而非所有用途
创始人主张积极引导AI的应用，而不是全盘拒绝这项技术。该公司还曾为一家紧急道路救援服务商部署AI系统。该系统对来电进行分流，使紧急情况下的救援能够更快调派，有望帮助救援人员更早抵达驾驶者身边。
▲ 集体决定拒绝合作
这两个项目的目的不同。一个利用AI协助分流求助请求；而拟议中的武器项目则会把软件用于致命决策。这一对比解释了该公司的选择，但并不能据此确立行业通用标准。其他应用可能在间接影响方面引发更棘手的问题，而仅凭良好的初衷，也未必能看清一个系统的用途最终会走向何方。
把原则转化为合同审查
这一案例为选择AI业务的组织提示了一套审查步骤。但不应把它误认为所有企业都已遵循的成文政策：
- 明确预期成果。 在把合作当作工程任务之前，先确认客户希望建成的系统实现什么。
- 审视系统的决策角色。 追问软件将决定什么、可能影响到谁，包括它在更大流程中被使用的情形。
- 结合技术判断与商业判断。 工程师可以说明自己被要求构建的是什么，管理层则必须决定公司是否应为构建它承担责任。
- 在财务压力下让边界真正有效。 即使合同能带来可观收入，也要就预期用途本身作出评估。
这种方法要求放慢节奏，把需求弄清楚。它并不要求对AI的每一项下游影响都作出确定判断，因为这些影响往往难以预测。
这次拒绝留给读者的启示
在团队确认所提议的软件将用于致命目标判定之后，这家咨询公司接受了经济上的取舍。更广泛的启示在于决策方式，而不是对AI项目的普遍裁决：当团队调查清楚预期用途，并愿意拒绝越界的工作时，伦理边界才具有实际意义。评估AI合同的组织可以从以下几点做起：追问系统将决定什么，让了解其运作方式的人参与进来，并在这些问题有了明确答案之后再决定接受还是拒绝。