商业秘密官司的胜负,早在辞呈递交前就已写定:一桩鸡肉公司积案的启示
苹果起诉两名跳槽OpenAI的前工程师,争议焦点其实是那些从未划清、或早已划清的边界,而不是辞职那一刻本身。英国法评判这类纠纷的标准,自1980年代一家鸡肉公司起诉自家销售经理起,几十年未变。
“员工离职时如何保护商业秘密?”这是每一位法务总监迟早都要面对的问题,但提问的时机往往错了。等到辞呈摆上桌面,这场未来官司的胜负其实早已注定,决定因素不是律师的手笔,而是多年前就做下的身份管理与账户架构决策。英国法用这套逻辑打分,已经打了将近四十年。而大多数企业的IT架构,从未按这个标准搭建过。
眼下最生动的案例,就是苹果起诉自家前工程师。苹果的诉状点名Tang Tan与Chang Liu两名前苹果员工,二人现供职于OpenAI,指控他们带走机密信息,并在离职前招揽同事跳槽。这些目前都只是指控,尚未经法院认定。OpenAI已提出动议要求驳回此案,苹果则同时申请临时禁令,要求在案件于加州联邦法院审理期间,禁止被告使用所涉机密信息。去掉品牌名与管辖地,这就是每一起人才离职纠纷的标准剧本,伦敦如此,库比蒂诺也如此:一方说“他们带走了我们的文件”,另一方说“请拿出商业秘密的证据”。
英国法在员工离职时,究竟保护什么?
答案比多数雇主想象的要窄得多,而这方面的权威判例,说来是关于卖鸡肉的。在Faccenda Chicken诉Fowler案中,英国上诉法院审理了一起案件:一名销售经理带着送货路线、客户名单和定价信息离职,自立门户参与竞争。法院裁定,雇佣关系结束后,默示的保密义务只保护严格意义上的商业秘密。已经融入员工自身技能、记忆与经验的机密信息,员工可以带走,除非存在有效的限制性竞业条款另作规定。装在脑子里的知识,属于受保护的人才流动;装进包里带走的文件,才是潜在的诉因。一家连这两者都分不清的公司,根本没有能力去执行一条法律坚持要区分的界线。
成文法后来又开辟了第二条路径,而且暗藏杀机。《2018年商业秘密(实施等)条例》将商业秘密定义为:秘密的、因秘密而具有商业价值、并且“在相应情形下已采取合理保密措施”的信息。这里有必要说清楚管辖范围,因为多数评论都说不清。美国的《保护商业秘密法》也把类似的“合理措施”要求写进了同一套联邦定义,而这正是苹果案中必须满足的标准。英国的情况更复杂:《2018年条例》与历史更久的违反保密义务之诉并行存在,后者并不含法定的合理措施要件,所以英国原告实际上有两条路可走,而非一条。但这点安慰有限:一旦未能通过合理措施测试,原告方就彻底丧失法定商业秘密的诉权,还等于把交叉盘问的台本双手奉上给对方律师。值得一提的是,这套逻辑并非英国独有:中国《反不正当竞争法》第九条同样要求权利人已对商业秘密“采取相应保密措施”,新加坡的普通法体系下,对保密信息的认定也采用近似标准。三地法律用词各异,但审判台上问的其实是同一个问题:你当初到底做了什么来保密?
个人账户与工作设备混用,为什么是致命伤?
因为“合理措施”的认定,看的是你整个IT架构里实际发生了什么,而不是政策文件上写了什么。围绕苹果案的另一项指控,理应让所有依赖“图方便”运作的企业警觉:另一宗独立的员工诉讼,据《洛杉矶时报》报道,指控员工普遍将公司配发的设备绑定个人iCloud账户。这是另一宗诉讼中的指控,未经证实。但它描述的模式几乎是普遍现象,因为这正是各大平台的机制在鼓励的行为。要在消费级生态系统里维持两套完全隔离的身份,意味着两次登录、两个相册、两种支付方式,还要不停切换。员工绑定账户,只因为绑定是阻力最小的路径,而且第一天不会有人反对。公司当下省下了麻烦,却要在多年后,用法庭唯一认可的货币偿还:一条经得起举证的边界。如果法官问,“皇冠上的明珠”当初是怎么保护的,而诚实的回答是“它存放在一个也装着员工度假照片的账户里”,那么合理措施的抗辩,在开庭披露程序开始之前就已经输了。
这个风险敞口是双向的。招聘方同样会继承这种模糊地带:如果新入职的首席工程师带来一个装满无法清晰归类材料的个人账户,那么其前雇主的疏忽管理,此刻就变成了你的诉讼风险。
如何衡量自己的风险敞口?
本周就能算出一个数字,不需要律师介入。从你所用的MDM系统里调出设备清单,数一数有多少受管设备同时登录了消费级个人身份:与工作账户并列的个人Apple ID(同步了iCloud云盘或照片)、开启了Drive同步的个人Google账户、挂在浏览器里的个人微软账户。如果你的工具查不出这个数字,就手动抽查二十台笔记本电脑,这个手动版本的结果,足以让人清醒。得出的百分比就是你的“账户混用率”,它同时也是一次预演:预演了一旦真的打官司,你在披露程序中会面对什么局面,因为每一台这样的设备,都是公司文件与私人材料共用同一个容器的地方,而你要说服法庭相信,这两者其实被清楚地分开了。
接着再问两个问题。你真正意义上的核心机密,也就是Faccenda案所保护的严格意义上的商业秘密,有多少是限定给指定名单上的人查阅,而不是“全体员工可见”?上一次有人离职时,你能否在一天之内,列出该账户所能触及的全部系统清单?只要有一个问题让你耸肩,你的商业秘密眼下就是靠运气在保护。
员工离职时,到底该如何保护商业秘密?
关键工作大多发生在入职阶段;离职本身,不过是把证据收割回来而已。四件事做到位,基本就够了。让公司身份成为阻力最小的路径,员工就不需要个人账户作为退路才能完成工作。让分类与容器绑定,因为一个到处都能找到的“秘密”,满足不了任何一种秘密的定义。让权限撤销真正对应现实:收回一个账户,只有在这个账户确实是唯一入口时才有意义。离职流程要指名具体资料,而不是笼统地挥手带过“机密信息”,因为Faccenda案与2018年条例奖励的都是具体性,而非笼统表态。这些都不是IT部门的一张工单,而是一项关乎组织系统如何体现其法律立场的战略决策,而且随着软件代理开始持有自己的凭证,这套边界逻辑只会变得更加迫切:同样的边界逻辑,也支撑着安全的智能体系统——在那里,可能带着你的数据“跳槽”的那个“员工”,是一个进程。
直白地说:英国法拦不住知识随人离开,也只有在文件被当作机密对待的前提下,才拦得住文件被带走。本周就数一数你的账户混用设备,你就会知道,在法庭真正给出判决之前,自己站在这条线的哪一侧。
常见问题
公司能否阻止离职员工使用在职期间学到的东西?
一般不能。自Faccenda Chicken诉Fowler案以来,英国法院一贯认为,员工在职期间吸收的技能、经验与一般性know-how属于员工本人,会随其离职带走;离职后仍受保护的,只有严格意义上的商业秘密,除非存在可执行的限制性竞业条款另作约定。因此,实际的争议焦点几乎总是落在具体资料(文件、档案、代码、客户数据)以及承载这些资料的系统上,而不是知识本身。
在英国,什么才算是保护商业秘密的“合理措施”?
《2018年商业秘密(实施等)条例》把“在相应情形下采取合理措施”直接写进了商业秘密的定义本身,原告如果拿不出这些措施的证据,连法定商业秘密的诉权都不成立。法院看的是日常实际发生了什么:访问权限是否只开放给确实需要的人、资料是否被标注并存放在受控位置、保密条款是否写入合同、离职时权限是否真正被彻底切断。历史更久的违反保密义务之诉虽然没有法定的“合理措施”要件,但同样的疏漏在实践中一样会削弱胜算。
应不应该允许员工在工作设备上登录个人账户?
只有在刻意加以隔离的前提下才可以。一刀切的禁令通常行不通,因为它在对抗平台本身的激励机制,人们绑定账户,正是因为彻底分离太麻烦。行得通的做法,是让公司身份本身就足以完成所有工作,用受管配置文件或容器把数据隔离开来,并且清楚认识到:任何让两种身份合流的“便利”,同时也在把你未来的证据一并合并掉。
相关阅读
- Ubuntu 26.04 LTS的coreutils依赖名没变，代码已经换了作者
- 主权溢价：企业争的不是更快的AI，而是不会被随时掐断的准入权
- 操作系统级年龄验证来了:一道账户层关卡,正把操作系统阵营劈成两半
- Security & Trust
本文由 Abyshire 专有编辑系统的 AI 编辑角色撰写，并经我们的团队审核。