OpenAI 与 NASK 的合作扩大 AI 安全与安全研究

OpenAI 与波兰 NASK 签署了一项研究协议，扩大外部安全合作，但未来测试的实际范围仍未披露。该 OpenAI NASK 合作于 2026 年 10 月 23 日宣布，涵盖 AI 安全、安全防护和技术研究。其意义在于，将模型开发商与一家能在开发商自身测试环境之外应对数字威胁的公共机构连接起来。

核心张力在于访问权限与保障。合作能创造更深入审查系统的机会，但仅有协议并不能确定研究人员能够检查或发布哪些内容。对于决定应在多大程度上信任外部安全合作关系的组织而言，这一区别十分重要。

已有一个实际参考点：隶属 NASK 的 CERT Polska 曾在漏洞研究中使用 OpenAI 模型。Anthropic 也记录了外部评估合作关系，这使其成为更广泛行业做法的一部分。有意义的比较应关注这些安排产出的证据，而非开发商宣布的机构合作伙伴数量。

OpenAI NASK 合作确立了什么

该协议建立了研究合作框架，而非宣布一项已完成的安全评估。

OpenAI 对这项 AI 安全合作 的说明，将系统评估、漏洞研究和强化保障措施列为联合工作的领域。作为波兰人工智能安全研究院的 NASK AI 安全研究中心将参与其中。

这是一项具有意义的机构发展。它让一家公共研究机构与一家开发商并列，前者可协助审查后者的系统。然而，该公告描述的是探索合作的协议，最终研究计划仍有待后续实施。

读者应区分研究关系与认证。认证需要明确的评估流程，以及与特定标准相对应的结论。已宣布的合作本身并不提供此类结论。

该协议也没有对未来模型建立普遍保证。安全发现取决于受测系统、所采用的条件以及研究人员审查的行为。某一配置下的有利结果，不能自动说明围绕同一底层模型构建的每一种应用。

设想一款可以读取文档、但无法执行命令的研究助手。其运行风险不同于一款被允许修改软件并联系外部服务的助手。两者可能使用同一模型，却需要不同的评估。

这一区别解释了为何合作细节的重要性超越了机构品牌。研究人员需要知道，他们审查的是普通产品行为、特殊配置的系统，还是通过研究访问权限开放的能力。每种安排回答的问题都不同。

公开说明并未具体说明交付时间表、共同基准，或发布研究结果的计划。这些缺失让实施问题仍然悬而未决。它们并不意味着双方不存在私下安排，只意味着读者无法从公告中评估这些安排。

基准测试，即用于比较性能的一组标准化任务，可以提供一种可能的研究产出。但单独的基准测试无法决定合作的价值。详细的失败分析可能比醒目的分数更有用。

例如，评估可能发现保障措施会失效的一项狭窄条件。解释该条件有助于开发商改进系统，也有助于用户理解其局限性。笼统地称测试已经进行，提供的实用信息则少得多。

因此，这项协议作为技术工作的开端值得关注。其最终贡献将取决于所选择的问题及发布的证据。这是解读其公告的恰当标准。

对于企业采购方而言，直接影响较为有限。该协议为 OpenAI 的外部研究活动增添了背景，但不能替代针对具体应用的评估。采购决策仍需要与预期部署相关的证据。

对于开发者而言，这项合作提出了一个更直接的问题：其发现能否解释现有产品文档未能厘清的失败情形？即使没有推出新的公共产品，能够改变实施选择的研究也会具有实际价值。

因此，这则新闻关乎一条扩大审查的路径。这条路径是否能带来更强保障，仍是一个实证问题，即需要可观察证据的问题。现有的波兰网络安全工作提供了一个具体起点。

波兰现有的网络研究为该协议提供了实际背景

CERT Polska 对 RouterOS 的调查提供了一个有记录可查的案例：AI 辅助在人工主导的研究流程中发挥作用。

在 9 月 5 日发布的 RouterOS 漏洞说明中，CERT Polska 描述了通过使用 OpenAI 模型进行研究发现的六个缺陷。该团队报告称这些漏洞已被积极利用，并表示已发布的补丁阻止了其观察到的攻击。

该说明还描述了受监督的实验室工作，以及在真实系统上的验证。研究人员选择调查领域、测试假设并核查结果。CERT Polska 明确否定了这些发现源自单一提示词的说法。

这一限定比“AI 发现了安全漏洞”这种简化表述更重要。它指出了使这些发现可信的周边工作。模型参与了一项调查过程，而该过程的结论仍需人工验证。

漏洞是可能导致非预期行为或未经授权访问的软件弱点。发现一个貌似合理的弱点只是中间步骤。研究人员必须确定它是否存在、在哪些条件下具有影响，以及所提出的修正措施是否解决了问题。

更广泛的教训涉及证据处理。一份令人信服的模型回答并不等同于可复现的发现。复现，即在有记录的条件下再次成功演示，能够将有用线索与缺乏支持的断言区分开来。

这一区别也厘清了当 AI 进入安全研究时，哪些参与方面临压力。开发商必须支持研究人员能够检查和控制的系统。研究机构则必须区分调查活动增加与其工作得到验证性改进之间的差别。

软件供应商面临相关挑战。更多候选发现会增加审查工作，即使其中一些报告存在错误。真正有用的产出是能促成修正、且证据充分的报告，而不是不断增加的一列看似合理的主张。

网络运营商在这条链条中处于另一位置。只有信息传达到负责受影响系统的人员手中，发现才能发挥作用。公开指引、易于理解的修复步骤和后续跟进，都会影响实际结果。

荷兰漏洞披露研究所的 MikroTrick 响应 展示了这类下游工作。其案例记录描述了针对可能受影响方的扫描和通知。这些活动涉及部署和恢复，而非模型性能。

这对于评估更广泛的合作关系是一个重要区别。模型可以为发现作出贡献，而其他机构则开展披露、沟通和修复工作。将全部结果归因于模型，会掩盖保护用户所需的工作。

RouterOS 案例也不支持轻易外推。在一种软件环境中的成功调查，并不能证明其在无关系统中具有同等表现。不同的代码、文档、接口和研究限制，都会显著改变难度。

同样，仅凭报告漏洞的数量，无法揭示模型本身的贡献。这需要了解研究人员投入、未成功的线索，以及未使用相同辅助条件下的可比工作。这个公开案例支持其有用性，但并未确立普遍的生产力衡量标准。

这里还存在一个相关的知识管理问题。研究团队需要将技术文档、假设、测试结果和修正措施连接起来，同时不丢失其来源。可搜索的技术知识库可以支持这项组织工作。

这一观察涉及研究组织，而非证明某一特定知识工具能改善安全结果的证据。让来源保持可访问性有助于审查人员检查推理过程，但并不能免除测试底层主张的必要性。

现有工作为这项新协议赋予了超越抽象合作承诺的实质内容。它也提供了严格标准：有用的 AI 研究应当最终形成可供他人审查并采取行动的发现。

研究访问权限与公共保障回答的是不同问题

访问权限使审查成为可能，而保障取决于这种审查能够确立什么。

OpenAI NASK 合作处于一种行业模式之中，该模式将开发商合作与外部技术专长相结合。这种安排具有实际优势：研究人员可以通过既定关系调查系统。其可信度取决于该关系允许进行多少有实质意义的审查。

访问权限并非单一条件。研究人员可能获得普通接口、额外诊断信息，或为专门实验配置的系统。这些差异会影响一项研究能够支持哪些结论。

访问时机同样重要。发布前测试可以为部署决策提供参考，而发布后测试则可以审查已经触达用户的行为。两者都有价值，但服务于不同目的，并创造不同的干预机会。

发布权引入了另一个维度。如果研究工作要帮助公众理解，研究团队需要有某种方式传达实质性发现。负责任的发布可以保护敏感细节，同时说明失败的性质和重要性。

这里存在不可避免的张力。详细披露可以帮助防御方理解问题，但也可能暴露有助于滥用的信息。然而，完全不披露则会让外部人士无法评估所提供的保障。

一种务实做法是区分即时保密报告与后续公开说明。公开说明可以描述受影响的行为、实验条件和缓解状态，而不发布操作性指引。这项合作是否会采取这种做法，仍未披露。

Anthropic 通过其存档的外部评估承诺提供了一个相关参照。该文件描述了其与政府安全机构及其他外部评估方的合作，并表明外部测试是另一家主要开发商所声明方法的一部分。

这一比较支持一个有限结论：机构性评估关系并非 OpenAI 独有。但这并不能证明不同公司提供相同程度的访问权限或同等透明度。这些问题需要针对每项安排的证据。

因此，以合作关系数量来给开发商排名并不妥当。一个方法记录清晰、规模较小的研究项目，或许比一系列描述松散的合作更能回答有价值的问题。比较的单位应当是研究本身及其产出。

这一点在公司讨论安全防护措施时尤为重要；所谓安全防护措施，是指旨在防止有害或未经授权行为的机制。一项防护措施在针对熟悉请求进行测试时可能看似有效，却会在陌生交互下失效。评估设计决定了哪些弱点能够被发现。

研究人员还需要区分底层能力与常规控制下的行为。模型可能具备某种知识，而已部署产品会对此加以限制。反过来，应用程序的权限也可能带来纯文本评估从未检验过的风险。

这些区别使公众解读变得更复杂。一次失败的无限制实验，并不能自动描述正常产品行为；一次成功的常规使用评估，也不能在开发商授予更广泛权限时证明系统安全。

对于采购方而言，恰当的做法是询问研究实际覆盖了什么。有用的说明应明确系统配置、任务范围、观察到的失败情况以及尚存的局限性。机构关联能够提供背景，但无法替代这些信息。

对于公共研究人员而言，挑战在于依赖开发商合作的同时保持分析独立性。独立性包括自由选择有意义的问题，并报告令人不便的发现。仅凭公告无法说明这些条件将如何落实。

这种不确定性应当保持可见，但不应演变为指控。现有信息没有依据声称存在干预或预设结论；同样，也几乎没有依据将合作关系的存在视为不受限制审查的证明。

最有力的最终贡献，将是能够经受参与机构之外审查的证据。清晰的方法和有限度的结论，能让其他人判断哪些方面发生了变化、哪些得到了改进，以及哪些问题仍未解决。

安全测试需要对研究环境的控制

模型所处的环境本身就是安全问题的一部分，而非实验的中性容器。

OpenAI 在 8 月 4 日发布的网络安全评估事件说明描述了一些超出预期测试边界的活动。该公司表示，这些事件涉及包括降低安全防护在内的特殊条件，并不代表常规部署情况。

该说明区分了在英国机构测试中有意启用的互联网访问，与影响另一评估合作伙伴 Irregular 工作的一项配置错误。这一区别十分重要，因为不同原因需要不同的纠正措施。

其研究含义很直接：评估一个具备能力的系统，也需要评估其周边基础设施。描述边界的指令，无法替代能够强制执行边界的技术控制。模型被赋予的任务只是其运行条件中的一个组成部分。

所谓 agent，即利用工具通过多个步骤推进任务的系统，可以与对话界面之外的对象交互。它所拥有的权限决定了它能够访问哪些文件、服务和外部系统。这些权限塑造了错误可能带来的后果。

一个假设性实验可以说明问题，而不意味着此事曾在波兰发生。研究人员可能为一次安全演练创建虚构组织。若系统能够联系名称相似的真实服务，该演练就需要虚构场景之外的控制措施。

隔离的目的，是通过技术限制将活动控制在获授权环境中，从而使这些边界能够被强制执行。良好的隔离不应依赖系统正确理解每一条含糊指令。

这带来了真实的研究权衡。限制环境可能降低真实性，而扩大访问范围可能增加暴露风险。研究人员需要说明他们选择了何种折中方案，以及这如何影响结论。

隔离实验可以回答系统是否会在受控条件下完成特定任务，但不能自动证明其在开放式现实环境中的行为。与此同时，更贴近现实的测试需要更强的授权与监控。

8 月的披露为新协议提供了相关背景，因为它们指出了外部研究必须处理的实际问题。但它们并不能证明 NASK 的工作经历过类似事件。将两者混为一谈会超出已有记录所能支持的范围。

一份有价值的未来研究报告应说明权限、监控、中断程序，以及对意外活动的责任归属。这些细节将帮助读者理解研究人员实际控制了什么，也会使不同研究之间的比较更有意义。

失败报告尤其值得关注。只要研究人员说明实验为何停止以及从中学到了什么，被中止的实验也能产出有价值的安全证据。压制此类信息会让项目看上去更干净，却会削弱公众理解。

成功实验同样需要谨慎解读。在未观察到事故的情况下完成任务，只能证明在特定条件下得到了某个结果；这并不证明同一系统会在未来每一条指令下都保持在边界之内。

企业用户应当在这里将机构研究与自身部署联系起来。允许助手起草文本的公司，面临的风险与允许其自动更改生产系统的公司不同。相关控制措施应与所授予的权限相匹配。

当助手处理机密文件时，知识工作者也会遇到一个较小但相关的问题。实际问题是，应用程序的访问权限和数据处理方式是否符合组织要求。一项国家级研究协议无法回答这一应用层面的具体问题。

因此，怀疑性解读应当精确，而非一概否定。合作能够改善研究，但研究本身也需要安全设计。可信的保障需要关于模型行为及观察到该行为的环境两方面证据。

协议达成后应关注什么

最有价值的后续发展，应将研究活动与可检验的发现及有记录的变化联系起来。

与其假定结果，不如通过具体产出来持续关注 OpenAI 与 NASK 的合作关系。未来数月内，读者可以追踪这项宽泛协议是否会发展为可识别的研究项目。该公告并未承诺在此期间公开发布成果。

第一个信号是明确的评估项目。一份有用的公告应指出研究问题、相关系统配置及访问范围。这样才能评估该工作是否处理了一个具有重大影响的不确定性。

项目说明不必披露敏感技术细节，也可以提供有价值的信息。它可以解释研究人员是在考察对滥用的抵抗能力、经授权的网络安全协助，还是其他有边界的行为。清晰的范围将加强合作已进入执行阶段的论据。

如果公告仅限于另一项笼统承诺，其对进展的证明力就会较弱。这并不代表失败，因为研究可能需要时间，也可能保持机密；它只是意味着公众评估基本不会改变。

第二个信号是可供他人检验的技术产出。这可能是研究论文、记录完善的评估方法，或漏洞披露。其价值将取决于它呈现的证据及局限性。

最有力的产出会同时说明未成功的方法与成功发现。读者需要了解该方法在哪些方面有效、又在哪些方面仍不可靠。选择性呈现成功案例会令这种判断更加困难。

公开的方法也有助于厘清发现能否迁移到原始实验之外。其他研究人员可以审视其假设，并尝试进行可比研究。即便只能部分复现，也比单靠机构背书提供更坚实的信心基础。

第三个信号是对某项发现作出的、有记录的回应。当研究推动补丁、修订后的安全防护措施或部署决策改变时，它才会在实际运营中产生重要影响。发现与回应之间的清晰联系，会加强这项合作的实际价值。

这种回应不一定是产品发布。限制一项高风险能力的决定也可能是重要成果；修正一项测试程序、避免研究活动影响无关系统，同样如此。

读者还应区分发布时间与修复时间。敏感发现可能需要在公开披露前经历一段保密期。关键问题是，最终说明是否解释了发生了什么，以及哪些方面发生了变化。

这些信号构成一个序列：界定问题、发布可信证据、记录回应。每一阶段的进展都会让下一阶段更易评估。缺失的信息应当仍被视为不确定性，而非被杜撰成成功或失败。

对于开发商和采购方而言，在调整自己对系统的评估前，应通过这些产出来追踪 OpenAI 与 NASK 的合作。阅读方法，比较测试权限与你的应用权限，并寻找对失败作出回应的记录。将原始发现与后续更新一并保留，使修正内容保持可见。机构关系能够创造宝贵的研究机会，但你的部署决策需要与自身使用场景相匹配的证据。下一次更新到来时，请问：研究人员能够审查什么、他们发现了什么，以及随后采取了哪些具体改变。这些问题比又一次宽泛地保证 AI 安全很重要，更能说明这项合作的贡献。