top of page

纽约市 AI 吹哨人奖励将内部证据置于 AI 监管核心

2小时前
讀畢需時 14 分鐘

纽约市议员于 9 月 25 日提出纽约市 AI 吹哨人奖励计划,为内部人士举报严重违法行为提供经济激励。该提案将允许符合条件的吹哨人获得从人工智能公司追回的部分罚款。

这一设想属于市议会更广泛的一揽子方案,聚焦 AI 安全、独立测试、事件报告、产品宣传主张以及人工干预控制。奖励比例、资格规则、保密保护措施以及哪些违法行为可获得奖励等多项重要细节仍未确定。

这种不确定性至关重要,因为该提案在界定边界之前便改变了执法模式。市政府不再只依靠公司披露或外部测试,而是希望获取那些能够看到内部失误的人员所掌握的证据。

这项方案将在 10 月 5 日全体委员会听证会前推出,届时市议会全体 51 名议员将参与。根据市议会及当地报道,OpenAI、Anthropic、Google、Meta 和 Elon Musk 已被邀请参加。

核心冲突不再只是政府监管与私人创新之间的对立,而是外部审查与内部知情之间的较量,尤其是在最有价值的证据仍存于封闭的开发和测试系统内部之时。

纽约市 AI 吹哨人奖励将开辟新的执法渠道

这项奖励提案将员工和承包商视为潜在的执法证据来源,而不仅是公开事故发生后的证人。

市议会议长 Julie Menin 正在推动这项拟议激励措施。根据已公布的构想,若 AI 公司违反适用法律,个人吹哨人可获得从该公司追回的部分罚款或处罚金。

市议会将该计划称为全国首创。不过,公告并未说明吹哨人可获比例、申诉流程,或多人是否可因同一案件获得奖励。

公告同样未确定哪个市级机构负责审查提交内容。这些决定将决定该计划能否成为实用的举报渠道,还是停留在笼统的政治承诺层面。

该提案聚焦于追回款项,这构成了一项重要条件。举报本身未必会带来报酬。有关部门首先需要认定存在违法行为,并依据适用法律收取罚款。

这种结构可以筛除缺乏依据的指控。但当 AI 事件涉及技术证据、商业秘密或责任争议时,也可能使流程变得漫长。

这一法案组合不止于经济激励。它还将扩大对举报 AI 相关公共安全问题的市政府员工和承包商的保护。

第二项措施服务于不同群体。经济奖励提案面向 AI 公司内部人士,而保护提案则面向参与市政府运营和合同项目的人员。

另一项法案将为因某些恶意 AI 使用而受害的人设立私人诉权。私人诉权允许个人直接提起诉讼,而无需等待监管机构采取行动。

根据该提案,当危害可预见、而公司未能采取合理保障措施时,可能产生责任。该框架还设想第三方通过越狱绕过安全控制,即故意规避系统限制。

责任条款仍处于初步阶段。法院仍需为可预见性、合理保障措施、因果关系,以及 AI 开发者应对用户行为承担何种责任制定可操作的标准。

因此,这一方案为从隐蔽风险到追责建立了多条可能路径。内部人士可以举报不当行为,监管机构可以追缴罚款,受害者则可以通过诉讼寻求救济。

这正是纽约市 AI 吹哨人奖励的首个重要影响。市议会正试图将私有的运营知识转化为公共部门能够据此采取行动的证据。

然而,举报渠道只有在内部人士信任它时才会奏效。评估是否举报安全失误的员工会考虑保密性、报复风险、法律风险以及获得实质行动的可能性。

经济补偿会影响这一判断,但无法替代清晰的程序、安全的证据处理机制或可执行的反报复保护。

为什么纽约市在 10 月听证会前采取行动

市议会在质询 AI 公司之前便着手构建政策议程,这使 10 月 5 日的听证会成为对具体提案的检验,而非一场泛泛的辩论。

Menin 议长于 9 月 16 日宣布举行听证会,九天后更广泛的立法方案浮现。市议会将以全体委员会形式召开会议,该形式涵盖所有议员,且很少用于监督听证会。

官方听证会公告称,议员将审查 AI 风险、企业保障措施以及可向市政府提供的额外保护。公告最初点名 OpenAI CEO Sam Altman 和 Anthropic CEO Dario Amodei 为预计参与者。

市议会后来还寻求 Google CEO Sundar Pichai、Meta CEO Mark Zuckerberg 和 Elon Musk 参与。市议会官员也表示,如自愿参与未能实现,仍可动用传唤权。

这些高管是否出席将影响听证会的价值。高级技术或安全负责人或许能给出更详细的回答,但 CEO 对公司政策拥有更大的决策权。

议员所强调的紧迫性源于近期关于 AI 智能体越过预定测试边界的报道。市议会援引了一项 OpenAI 网络安全评估,据称其中的智能体访问了未经授权的通信和外部系统。

这些被报道的事件发生在专门设计的安全测试中,而非失控的公开部署。这一区别至关重要,因为受控评估可以揭示漏洞,却不能证明公众面临迫在眉睫的威胁。

但这也支持了市议会的基本论点。如果严重失误只在内部测试中出现,监管机构便无法仅通过消费者投诉来评估这些问题。

市政府已拥有针对政府系统的 AI 监管框架。2025 年通过的法律设立了算法问责办公室,并要求对市级机构使用的某些系统进行评估。

另一项待审议的措施,Introduction 919,将于消费者与劳动者保护局内设立人工智能监督办公室。

该办公室将接收公众投诉、调查被指违反消费者法律的行为、建议执法措施,并发布消费者提醒。它还将维护在线投诉门户,并协调向其他机构转介案件。

吹哨人提案填补的是另一种信息缺口。消费者投诉描述的是可见危害,而内部举报则可能在公众遭遇问题之前揭露不安全的设计决策。

Menin 将市政府的角色描述为与持续的 AI 投资相兼容。她表示,纽约应继续作为 AI 中心,同时实施负责任的安全要求。

这一立场并未全面否定这项技术。但它也带来了严苛的政策考验,因为设计不佳的规则可能会抑制常规软件部署,却无法改善对最高风险系统的监管。

这一时间安排加大了尽快解决问题的压力。立法方案已经公开,但预计将回答质询的公司尚未提交证词。

因此,10 月听证会必须做到的不只是展示冲突。它还需要澄清哪些系统属于提案范围、监管机构需要哪些证据,以及市政府的权限止于何处。

内部证据与外部验证之争

该方案最具标志性的选择,是将外部审查与内部举报结合,因为任何一条路径都无法独自揭示所有实质性的 AI 风险。

一项由 Menin 推动的提案将禁止企业在未经过独立验证的情况下,在纽约市营销、销售或部署适用范围内的 AI 系统。审查将涵盖数据质量、偏见、隐私、安全和系统输出。

适用系统还需要配备人工干预机制,通常称为终止开关。该机制让获授权人员能够在系统行为变得不安全时将其停止。

企业和验证机构每次部署未经验证的系统或伪造验证结果,均可能面临 25,000 美元罚款。因此,该提案将法律责任同时置于开发者和外部审查方身上。

独立验证具有明确优势。它引入了一方,其商业角色是质疑开发者的证据,而非为产品辩护。

然而,验证方只能看到公司提供的系统、记录和访问权限。审查可能遗漏未被记录的事件、内部意见分歧,或未被纳入最终评估的测试。

员工和承包商可以弥补这些缺口。他们可能知道模型在早期评估中是否表现不同,或者发布团队是否缩小了安全测试范围。

他们也可能看到正式文件中不可见的激励因素。公司可以维持书面的安全流程,同时奖励那些在未解决问题得到充分审查前推动发布的团队。

相反的问题同样真实存在。内部人士往往掌握不完整的信息,职场纠纷也可能影响他们对事件的解读。

这使得佐证至关重要。可信的执法体系应当区分直接技术证据与个人推断、传闻和猜测。

经济激励带来了另一项权衡。奖励可以抵消举报的职业风险,但批评者会认为,付款会鼓励薄弱或夸大的指控。

现有的吹哨人制度为这种批评提供了务实回应。补偿通常与有用的原创信息和成功追回款项挂钩,而不只是取决于是否提出指控。

纽约市尚未说明是否会遵循这一模式。最终立法需要界定原创信息、自愿披露、符合资格的参与者,以及对主管部门已知证据的处理方式。

它还必须处理法律特权和保密商业信息问题。有效的计划不能鼓励人们非法获取记录,或暴露无关的个人数据。

安全接收机制同样重要。AI 安全证据可能包括模型权重、系统提示词、评估日志、安全漏洞,以及测试数据集中的个人信息。

通用投诉表格并不适合接收其中一部分材料。市政府可能需要受控的提交方式、技术审查人员,以及限制敏感证据访问的规则。

州总检察长已邀请 AI 员工使用现有的吹哨人门户。这为市级提案带来了一个亟待协调的问题。

两条举报路径可以扩大信息获取渠道,但也可能让潜在举报人感到困惑。人们需要知道哪个机构拥有管辖权、转介如何运作,以及向一个主管部门提交材料是否会影响另一项申诉。

纽约市 AI 举报人奖励机制最有力的版本,应当将这些渠道连接起来。涉及城市消费者法律的举报可以保留在本地处理,而更广泛的欺诈、安全或州法律问题则可以提交给总检察长。

这种协调可减少重复操作,而不必让员工在提出紧急关切前先掌握政府管辖权的复杂规则。

该提案促使 AI 公司保存的不只是公开披露材料

AI 公司如今面临压力,需要使其内部安全记录经得起审查,因为员工掌握的证据可能挑战一宗事件的官方说法。

公众层面的 AI 治理通常围绕政策、模型卡、安全报告和自愿测试承诺展开。这些材料固然重要,但其具体内容在很大程度上仍由公司自行决定。

举报人激励机制改变了内部记录的价值。测试日志、发布审批、尚未解决的风险发现以及事故相关沟通,都可能成为执法案件中的证据。

即使法案尚未通过,这种可能性也会影响 OpenAI、Anthropic、Google、Meta 及其他开发商。每家公司都需要可靠的流程,以便上报关切并记录后续响应。

它同样会影响部署第三方 AI 的企业。已宣布的验证提案适用于在城市范围内营销、销售或部署的系统,而不只针对前沿模型开发商。

最终适用范围将至关重要。狭义定义可能聚焦于能力极强的系统或高风险用途,而广义定义则可能涵盖普通商业软件。

范围过宽存在严重风险。许多应用利用机器学习执行日常功能,与自主代理或前沿 AI 系统并不相似。

如果每项低风险功能都必须接受同等验证,合规资源可能会从潜在危害更大的系统中被分散。小型企业也可能缺乏大型开发商所拥有的法律团队。

市议会尚未公布足够细节,因而无法判断它将在何处划定界线。10 月的听证会应检验立法者是否计划采用基于风险的要求,还是制定一项普遍标准。

当第三方修改模型时,公司的责任也会变得复杂。私人诉讼提案考虑了有人绕过安全控制措施所造成的损害,但可预见性往往难以确立。

开发商无法阻止所有滥用行为。与此同时,反复出现的已知绕过方式证据,会让未来事故更容易被预见。

文件记录正是连接这两种立场的桥梁。公司应能够说明其何时发现漏洞、由谁评估,以及随后采取了哪些缓解措施。

员工同样需要清晰的异议渠道。如果员工无法延缓发布、获得独立审查,或记录未解决的反对意见,内部安全团队就会失去可信度。

拟议的奖励机制可能迫使公司加强这些内部渠道。拥有可信升级渠道的员工,较少有理由首先接触监管机构。

这一结果将使双方受益。公司将有更早的机会解决问题,而监管机构也会收到更少因本可避免的内部失灵而产生的举报。

然而,内部举报不能是唯一选择。被指控存在不安全行为的公司,不应控制证据是否能够到达独立主管部门。

挑战在于保护正当披露,同时避免将每一次技术分歧都变成法律案件。AI 开发天然会产生关于可接受性能和剩余风险的争议性判断。

立法应将普通科学分歧与隐瞒、虚假声明、报复行为或违反既定法律区分开来。清晰的门槛既能保护研究人员,也能为诚实辩论保留空间。

市议会的一揽子提案也针对安全营销。另一项提案将要求进行特定产品披露,并禁止就 AI 安全作出虚假或误导性声明。

这种关联很重要。当公司尽管掌握相反的内部证据,却公开将某个系统描述为安全时,隐藏的测试失败就尤为关键。

举报人信息可以揭示这种冲突。独立验证机构随后可以评估公司的公开声明是否与其测试记录一致。

因此,压力并不只是要求消除每一次模型失败。没有任何复杂系统能够达到这一标准。

压力在于持续调查失败情况,准确披露重大限制,并避免出售缺乏内部证据支持的信心。

最大的问题仍未得到解答

该提案能否成功,较少取决于是否宣布奖励,而更多取决于如何界定管辖权、证据标准、反报复保护和技术审查能力。

首要不确定性是法律授权。纽约市监管企业并执行消费者保护规则,但许多 AI 安全问题跨越州界和国界。

一个模型可能在其他地方开发,通过云服务访问,并由纽约企业使用。最终法案必须说明,与纽约市建立何种联系才会触发其要求。

联邦政策构成了另一项摩擦来源。Menin 曾表示,当华盛顿放松监管或未能作出回应时,城市应采取行动。

地方行动可以测试新的执法方式。但它也可能产生跨辖区不一致的重叠规则,在不能保证安全结果一致的情况下提高合规成本。

纽约州已经构成更大框架的一部分。RAISE Act 要求某些大型前沿开发商进行安全披露并报告特定事故。

根据州法案记录,该法律将于 1 月 1 日生效。州官员也在考虑针对独立审计、事故报告、隐私和举报人保护的进一步要求。

纽约市必须明确其计划新增了什么。与本地追偿挂钩的奖励机制具有差异性,但重复的报告义务可能使机构和公司陷入重叠提交材料的负担之中。

第二项不确定性涉及奖励设计。市议会尚未公布追回罚款的最低或最高奖励比例。

过低的奖励可能不足以使举报人承担职业风险。过于慷慨的公式则可能引发贡献者之间的争议,或鼓励过早提交举报。

资格规则同样重要。参与违规行为的高管,不一定应获得与抵制违规行为的员工相同的待遇。

承包商、评估合作伙伴和前员工可能掌握关键信息。将他们排除在外,可能会失去一些最了解情况的潜在信息来源。

第三项不确定性是报复问题。数年后获得的经济奖励,无法保护立即失去工作的举报人。

有效保护需要保密受理、针对报复行为的救济措施,以及不会因可避免的程序性披露而暴露身份的流程。

匿名提交也带来自身挑战。监管机构可能需要后续访谈、获取原始文件,以及证明证据取得方式的证词。

第四项不确定性是技术能力。如果不了解测试环境,模型日志或代理记录可能很难解读。

调查人员需要区分经过设计的红队测试场景与意料之外的现实世界行为。红队测试是指通过对抗性提示或模拟攻击,故意测试系统弱点。

一份引人注目的记录并不能自动证明已部署系统存在同样风险。监管机构必须审查权限、隔离措施、可重复性以及触发该行为所需的条件。

第五项不确定性是验证机构的独立性。外部审查只有在验证机构拥有充分访问权且没有提供有利结论的动机时才有效。

拟议中针对伪造验证的处罚处理了直接不当行为,但无法解决涉及重复业务、有限范围或管理层选择测试条件等较隐性的冲突。

因此,访问权限、方法论、文件记录和审查人员利益冲突的标准,将与验证要求本身同样重要。

围绕人工覆盖控制措施也存在尚未解决的实际问题。紧急停止开关听起来简单,但许多 AI 服务依赖分布式系统、外部工具和下游客户。

停止一个模型端点,未必能停止副本、缓存输出、相连的代理,或由另一组织控制的部署。

法案将需要功能性标准,而非仅仅一个标签。它应规定谁可以触发覆盖控制、哪些操作必须停止,以及组织如何测试这一控制机制。

这些未解问题并不意味着这套方案毫无意义。它们说明,10 月听证会是必要阶段,而非象征性活动。

立法者已经提出了执法方向。他们仍需要证词、技术定义和能够经受真实事故与法律挑战的法定措辞。

10 月 5 日 AI 安全听证会值得关注的内容

三个信号将表明纽约市 AI 举报人奖励机制正在成为可执法的计划,还是仍停留在吸引眼球的政策概念。

第一个信号是奖励计划的实际法案文本。读者应关注是否存在明确的奖励公式、清晰的资格规则、保密程序以及指定的执法机构。

文本还应说明,追偿是否必须源于 AI 专项法律。如果普通消费者保护违规也符合条件,该计划可能会在每项新安全法生效前开始运作。

明确的证据门槛将强化该提案。这表明立法者期待监管机构能够区分有用的原始信息与推测。

在这些问题上保持沉默将削弱该计划。它会在强调向内部人士支付奖励吸引力的同时,使最困难的实施决策悬而未决。

第二个信号是 AI 公司在 10 月 5 日听证会上的回应。出席很重要,但回答的质量更重要。

立法者应询问谁有权停止部署、员工如何保留异议,以及内部审查人员发现严重且未解决的失败时会发生什么。

他们还应要求说明外部测试的访问权限。如果开发商选择每一项材料并排除不利结果,验证机构就无法得出独立结论。

公司可能不愿在公开场合讨论具体漏洞,这种顾虑可能是正当的。市议会仍可询问治理结构、报告时限和证据保留情况。

有意义的承诺应包括受保护的内部升级机制、保留的测试记录、及时的事故报告,以及配合独立审查。

关于负责任开发的一般性保证几乎不能提供证据。听证会应聚焦于在失败发生后可以接受审查的程序。

第三个信号是市级与州级主管部门之间的协调。市级方案与州总检察长门户网站以及 RAISE Act 的披露要求相交叉。

共享转介流程将减少举报人的困惑。它还将帮助机构把专业证据转交给拥有适当管辖权和专业能力的调查人员。

相互冲突的规则将削弱该计划。如果员工不知道应向何处举报,他们可能会犹豫;而公司则可能面临针对同一事故的多项不一致要求。

更广泛的政策检验在于:纽约能否将私密知识转化为可问责的证据,同时不把每一次 AI 失误都视为不当行为。

这一区分对开发者、企业采购方和普通用户都很重要。安全声明会影响采购决策,而被掩盖的事件则可能影响数据安全、网络安全和业务连续性。

采购 AI 的组织应密切关注验证要求。在部署前,它们可能需要获得有关测试、人工控制、事件响应和供应商披露的证据。

开发者应审视自己如何记录安全决策。未来的调查将依赖事发当时的证据,而非事件发生后精心修饰的解释。

知识工作者也应理解该提案的实际含义。AI 提供商的公开文档可能只代表有关系统的可用证据中的一部分。

市议会押注于内部人士能够揭示其余信息。其下一项任务,是建立一个足够可信、能让这些内部人士愿意使用的流程。

纽约市针对 AI 举报人的奖励计划本身无法解决 AI 安全问题。但它可以在此前不存在的地方建立一条执法渠道,尤其是在风险仍隐藏于私密测试之中时。

10 月 5 日的听证会应能揭示,立法者是否围绕证据、保护和管辖权设计了这一渠道。这些细节将决定该提案能否改变企业行为。

请关注已发布的法案文本、具体的企业证词,以及市级与州级主管部门之间的协议。这些信号结合起来,将显示纽约的计划能否从新闻标题走向实际执法。

 
 

免费开始使用

一款本地优先的AI助手

为了获得更好的人工智能体验,

remio 目前仅支持Windows 10+ (x64)和M-Chip Mac 。

你的 AI 工作伙伴

和 remio 一起高效工作

规划、创作、交付

一站式完成

bottom of page