员工把机密交给公共AI前,企业需要一条密态边界
29/6/2026 · 9:19

员工把机密交给公共AI前,企业需要一条密态边界

围绕员工使用公共 AI 工具处理合同、简历、法律和科研资料的隐私风险,本文结合近 3 天 AI 隐私平台动态、Shadow AI 治理和欧盟 AI 法案透明度要求,拆解企业如何用数据分级、工具分流、密态计算、本地持钥与审计机制建立可执行的 AI 使用边界。

Nota del editor

这次不是「某个员工手滑」,而是企业 AI 边界正在被重写

过去企业谈数据泄露,常把注意力放在黑客入侵、数据库误配、供应链攻击上。但在生成式 AI 普及之后,另一条更隐蔽的泄露路径变得更常见:员工为了提高效率,把合同、简历、诉讼材料、客户名单、财务分析、科研假设直接贴进公共 AI 工具;工具看起来只是帮忙总结、润色、检索,数据却可能进入企业看不见、管不住、事后也难以追溯的系统。
本期的近 3 天触发点,是 2026 年 6 月 26 日国内 AI 隐私平台域名 www.mojingxiong.com 正式启用并招募内测体验官。报道提到,该平台覆盖法律咨询、医疗健康、心理咨询、职场事务、金融分析、科研工作六类高敏感场景,并将全密态计算、密态存储、本地持钥、阅后即焚作为主要能力描述。1
这个事件本身不应被理解为单个产品发布新闻,而应放到更大的企业治理语境里看:当公共 AI 已经进入员工日常工作流,企业真正要补的不是一句「不要乱用 AI」,而是一条能够同时覆盖数据分级、工具选择、加密计算、访问控制和审计留痕的「密态边界」。
员工使用公共 AI 工具时的敏感数据边界
AI 生成示意图:风险不是来自一个醒目的攻击入口,而是来自员工日常工作中一段看似正常的复制、上传和提问。

影子 AI 的风险,首先发生在「正常工作」里

Axiom 在 2026 年 6 月发布的法律团队提示文章中,把员工使用公共 AI 工具列为企业需要正视的隐私风险:一旦个人数据、专有业务数据或未经知情同意收集的数据进入 AI 系统,问题就不再只是「数据库有没有锁好」,而是企业能否控制信息进入 AI 后会被如何保存、训练、推断和再次使用。2
这类风险之所以棘手,是因为它常常发生在业务合理性很强的场景里:
场景员工可能输入什么隐私与合规风险
法务/合同未公开合同、争议事实、律师意见草稿商业秘密、律师-客户特权、保密义务可能被削弱
人力/招聘简历、面试评价、员工绩效、离职材料个人信息、敏感身份信息、劳动争议材料可能外泄
金融/经营分析客户资产、内部报表、未发布经营数据证券合规、客户隐私、商业秘密风险叠加
科研/产品未发表实验数据、技术路线、源代码知识产权和研发竞争优势可能提前暴露
更重要的是,很多员工并非有意违规。他们只是想更快写完邮件、总结材料、改一段代码、让模型帮忙提炼一份纪要。BRG 在 6 月 25 日关于 Shadow AI 的分析中也指出,未获批准的 AI 工具会把敏感数据带入未经监控的通道,组织往往看不见 AI 在哪里被用、什么数据进了工具、输出如何留存,以及出了问题由谁负责。3
国内已有更直观的警示案例。CSDN 4 月报道中提到,有用户称某头部 AI 助手向其返回了一份陌生人的完整简历,其中包含姓名、电话、邮箱等敏感个人信息;报道还援引《2026 全球网络安全展望报告》称,87% 受访者认为相关风险显著上升,生成式 AI 导致的数据泄露和攻击能力演化是重要担忧方向。4 这不是本期时间窗内的新事件,但它说明了一个长期问题:当输入、会话、检索、上下文和输出都在平台侧流动时,企业很难只靠员工自觉来阻断泄露链路。

法律风险不只在「泄密」,还在「保护资格被削弱」

对企业法务和管理层来说,公共 AI 工具的风险不止是文件被别人看到。更深一层的问题是:一旦企业把机密信息主动交给没有保密义务的第三方系统,原本可以主张的商业秘密保护、保密义务或特权保护,可能会被对方质疑。
IPWatchdog 在 2026 年 4 月的法律评论中讨论了两起与生成式 AI 相关的案件:其一,Trinidad v. OpenAI 中,法院驳回部分商业秘密请求,理由之一是原告在使用 ChatGPT 创建框架时自愿向 OpenAI 披露了相关信息;其二,United States v. Heppner 中,法院认为通过公开生成式 AI 形成的文件不满足律师-客户特权的保密要求,原因包括 AI 平台并非负有合同保密义务的律师或专业顾问。5
这些案例未必能直接移植到中国企业的每一种场景,但它们给出的治理信号很明确:企业不能把「员工只是用 AI 辅助一下」当成轻微操作。只要输入内容涉及客户资料、技术方案、融资文件、诉讼策略、员工档案或未公开经营数据,就应被纳入正式的信息安全和合规管理,而不是留在个人工具习惯层面。

监管压力正在把 AI 使用从「效率问题」推向「披露与治理问题」

6 月下旬的国际合规信号也在强化这一趋势。Sidley 在 6 月 24 日解读欧盟 AI 法案第 50 条透明度义务时指出,自 2026 年 8 月 2 日起,部分 AI 系统的提供方和部署方将适用透明度要求:直接与个人交互的 AI 系统通常需要告知用户其正在与 AI 交互;生成合成音频、图像、视频或文本的 AI 系统需要确保输出可机器读取并可被识别为人工生成或操纵;情绪识别和生物特征分类系统部署方还需告知受影响个人并遵守数据保护法。6
这说明企业 AI 治理正在从「能不能用」进入「谁在用、用在什么场景、对个人是否透明、输出是否可识别、责任如何分配」的新阶段。对于跨境业务、SaaS、金融科技、医疗健康、在线教育和人力服务企业,公共 AI 工具不再只是 IT 部门要不要封禁的网站,而可能成为数据保护、消费者告知、供应商管理和合同审计共同关注的对象。
同样在 6 月 24 日,加拿大网络安全中心在关于前沿 AI 模型影响网络安全的声明中提示,AI 正在缩短攻击者发现和利用漏洞的时间,并带来组织内部未批准使用 AI 工具、敏感数据暴露、系统依赖不准确或被操纵输出等风险;其建议包括及时打补丁、缩小攻击面、使用抗钓鱼多因素认证、集中日志、系统分段、测试应急响应计划,并建立关于负责任使用 AI 工具和处理敏感信息的清晰内部指引。7

「密态边界」要解决的,不是替员工做选择,而是让数据默认不可见

在这个背景下,荆华密算 AI 隐私平台相关公开资料中反复出现的关键词——全链路加密、密态计算、密态存储、本地持钥、服务端仅保存密文——可以被理解为一种更具体的产品化方向:让 AI 仍然可用,但让平台、模型和服务端尽量不直接接触明文数据。6 月 26 日报道中称,用户的会话记录、上传文件、知识库内容以加密密文形式存储于服务端,加密密钥由用户本地持有,服务端仅保存密文。1
需要强调的是,企业不能把任何单一技术描述理解为「风险归零」。更严谨的表述应该是:密态计算、本地加密和密态存储可以降低明文暴露面,把过去依赖平台自律、合同承诺和员工自觉的部分风险,前移到架构层面进行约束。它解决的不是「从此不用管理」,而是让管理规则有更坚实的技术边界。
密态计算与本地持钥的数据流
AI 生成示意图:企业 AI 隐私治理的关键,是把明文、密文、密钥和模型调用边界分开管理。
以职场事务为例,企业如果要允许员工用 AI 辅助处理 HR、法务、财务、研发资料,至少要区分三类工具路径:
  1. 公共 AI 工具:只允许处理公开资料、通用写作、低敏感知识问答;严禁输入个人信息、客户信息、未公开合同、内部经营数据和源代码。
  2. 企业级 AI 服务:用于中低敏业务,前提是合同明确数据不用于训练、日志保存周期可控、访问权限可审计、供应商安全义务清楚。
  3. 隐私增强型 AI 平台:用于高敏场景,如法律、医疗、心理、职场、金融、科研等,需要本地加密、密态计算、最小权限、密态存储和可追溯审计共同支撑。
这也是 AI 隐私平台自然能切入的地方。它不是为了替代企业所有 AI 工具,而是为最容易出事、又最难完全禁止的高敏工作流提供一个更受控的入口。

企业落地时,应把「禁止清单」改造成「可执行分流规则」

很多企业的 AI 管理停留在一句话:「不得向公共 AI 工具输入敏感数据」。这句话方向正确,但执行效果通常有限。原因很简单:员工并不总能准确判断什么是敏感数据,也不一定知道可替代工具在哪里。如果企业只封堵、不提供安全路径,影子 AI 反而会转入更隐蔽的个人账号、浏览器插件、会议助手和海外工具。
更可执行的做法,是把规则拆成六个动作。
第一,建立数据分级到 AI 场景的映射。 不要只定义「秘密、敏感、公开」三个抽象等级,而要把合同、简历、病历、心理记录、客户资产、实验数据、源代码、未发布财报等具体材料放进员工能理解的清单。清单里要写明:哪些绝不能进公共 AI,哪些只能进企业级 AI,哪些必须走密态或私有化路径。
第二,把工具分流写进业务流程。 法务审合同、HR 筛简历、财务做经营分析、研发写代码时,系统应该默认给出可用工具入口,而不是让员工自己去搜索。Axiom 建议企业构建具有明确层级的 AI 使用政策,并训练员工识别哪些材料属于机密信息。2
第三,在出口处设置技术拦截。 对高敏字段、身份证号、手机号、客户名称、合同编号、源代码仓库、财务指标等内容做识别和提示;必要时通过网关、DLP、浏览器管控或端点策略阻止复制上传。BRG 对 Shadow AI 的分析也强调,单纯封禁热门工具不够,组织需要可观察、可执行、可追责的治理模型。3
第四,为高敏场景引入隐私增强计算。 当业务确实需要让模型理解敏感文档,企业应优先考虑本地加密、密态推理、密态存储、本地持钥、最小化明文接触等技术组合。其目标不是制造一个「绝对安全」的口号,而是减少平台侧、服务端、供应链和内部人员能接触明文的机会。
第五,合同和采购要同步升级。 供应商合同里应明确数据是否会被保留、是否用于训练、日志保存多久、是否支持删除、是否允许分包、发生安全事件如何通知、审计权如何行使。对于跨境业务,还要结合 GDPR、欧盟 AI 法案以及本地个人信息保护规则判断是否触发额外披露和合规义务。
第六,保留日志,但不要把日志变成新的泄露源。 企业需要知道谁在什么场景下调用了 AI、访问了哪些知识库、触发过哪些高敏提示;但日志本身也可能包含敏感内容。因此,日志应尽量结构化、脱敏化、权限隔离,并与密钥管理、留存周期、审计审批绑定。
企业 AI 使用的合规审查与审计流程
AI 生成示意图:AI 使用治理应覆盖数据分级、工具分流、权限审批、日志审计和供应商责任,而不是只靠员工口头承诺。

结论:企业要的不是「不用 AI」,而是「可用不可见」成为默认设置

公共 AI 工具不会从办公室消失。真正的问题是,企业是否愿意承认它已经进入工作流,并用正式制度和技术边界接住它。
如果继续把 AI 隐私风险理解成「员工偶尔违规」或「平台偶尔出错」,治理就会停留在事后通报和口头提醒;如果把它理解成企业数据流的一次结构性变化,管理重点就会变成:哪些数据可以进入 AI,哪些工具可以处理哪些级别的数据,哪些场景必须加密、隔离、审计,哪些供应商需要承担明确责任。
荆华密算 AI 隐私平台所代表的密态计算、本地持钥和密态存储方向,价值正在于此:它把 AI 使用从「相信平台不会看见」推进到「架构上尽量让平台看不见」。对法律、职场、金融、科研等高敏场景而言,这不是锦上添花的安全功能,而可能是企业敢不敢把 AI 从个人效率工具纳入正式生产流程的前提。
未来企业 AI 治理的分水岭,不是「谁用的模型更强」,而是谁能在提升效率的同时,把明文暴露面压到最低,把权限、合同、日志和密钥边界讲清楚。真正可持续的 AI 应用,不应建立在员工每一次复制粘贴都做出完美判断的假设上,而应建立在默认受控、默认可审计、默认可用不可见的系统设计上。

Contenido relacionado

Añade más opiniones o contexto en torno a este contenido.

  • Inicia sesión para comentar.