摘要：研发网的 AI 管控不是"封不封"的选择题，而是三个技术约束同时成立——终端在纯内网、推理在公网、Prompt 里带着核心代码与图纸。可行的工程解是把问题拆成四层：接入层用 SDP 零信任做应用级发布，终端层用 AIDR 做 AI 客户端识别与管控，数据层用数据防泄密控制外发通道，治理层用账号体系与制度划定边界。本文以江苏某研发型企业的现场实践为样本，逐层拆解识别维度、策略矩阵、审计字段、落地六步，并明确写出这套架构管不住的边界。

一、研发网的 AI 使用，难在哪？三个技术约束的冲突

研发网 AI 管控的难点不是"要不要用"，而是三个约束在物理层面互相排斥：终端不能出网、推理必须在公网完成、而 Prompt 本身就是一次数据外发。

理解这一点，才不会把问题做成一刀切封禁。下面把三个约束拆开看。

约束一：网络隔离与模型推理的物理冲突

研发环境的终端通常处于物理隔离或准隔离网络，外网不可达。而当前主流代码大模型的推理全部在云端完成，本地无法替代。两者放在一起，结果是工程师只能对着隔离环境想办法——用个人手机热点、用私人设备、或者干脆把代码抄到能上网的机器上。

隔离如果没有合规的出口，工程师会自己造一个出口，而那个出口完全不可观测。 这是所有后续设计的前提。

约束二：Prompt 即数据外发

工程师向 AI 提问时，粘贴的内容往往不是一句话，而是一段核心算法、一份 PLM 里的产品结构数据、一段 BOM 配置。这个动作在终端上只发生几秒，但它等价于一次完整的数据外发。

与传统文件外发不同的是：文件外发有文件形态，可以按文件类型、大小、水印做拦截；Prompt 是纯文本，混在正常的对话流里，既没有文件头也没有固定格式。按文件维度做的防护，对"粘贴一段代码"这个动作天然失效。

约束三：可见性与终端体验的对立

安全部门希望每一次 AI 调用都留痕：谁、用什么账号、什么时间、调用了哪个 AI、发了什么内容、涉及哪些文件。但研发人员对终端上再装一个客户端的容忍度很低，多一个常驻进程、多一次卡顿，都会被反馈到运维。

如果为了管控而牺牲体验，绕过率会上升；为了体验而放弃可见性，事后无法追溯。这两个目标只能靠架构设计来平衡，不能靠"加强管理"来平衡。

三类约束对应的传统手段失效对照

技术约束	常见应对手段	在研发网的失效原因
终端不能出网	防火墙全封外网	连指定 AI 也用不了，工程师转而使用手机热点或私人设备，出口彻底脱离管控
Prompt 带数据外发	文件级 DLP、关键字过滤	Prompt 是自由文本，无文件形态；关键字误报率高，代码片段难以用词表覆盖
需要追责到人	网络设备日志	NAT 之后只剩一个出口 IP，几十人共用一个地址，无法映射到具体账号
不能多装客户端	再上一套独立平台	终端常驻进程叠加，运维成本与员工抵触同时上升

二、四种技术路线怎么选？

结论先行：在研发网场景下，纯网络封堵、纯 CASB 代理、纯文件级 DLP 三条路线各自只能覆盖一个约束；能同时覆盖三个约束的是"端侧一体化"形态，代价是终端上必须有一个常驻组件。

四条路线的能力对照如下。

技术路线	覆盖的约束	研发网适配度	主要短板
网络侧全封堵	仅约束一（部分）	低	无法提供合规出口，绕过率高，日志无法定位到人
CASB / 反向代理	约束一 + 部分外发审计	中	只对走浏览器或标准 HTTP(S) 的流量有效，桌面 AI 客户端、私有协议容易漏；纯内网终端需先解决可达性
文件级 DLP	仅约束二（文件形态）	中	对剪贴板文本、对话式粘贴基本无效，缺少"哪个 AI 在用"的视角
端侧一体化（接入 + 终端 + 数据 + 治理）	三个约束全覆盖	高	需要在终端部署常驻组件，对终端兼容性与策略精细度要求高

判断自己的环境是否需要走到端侧一体化，看三条判据：

1. 终端是否处于物理隔离或准隔离网络——若是，网络侧方案无法单独成立，因为终端根本没有到代理的路径；
2. 是否存在本地文件外发风险（剪贴板、拖拽、文件选择器上传）——若存在，纯流量方案看不到这些动作；
3. 是否需要把责任落到具体账号——若需要，出口 IP 级日志不够，必须有账号维度的绑定。

三条中命中两条以上，端侧方案基本是必选项；只命中第三条，可以先做流量侧审计过渡。

三、整体架构怎么搭？AIDR 做主干，SDP、桌面管理、DLP 各补一层

整体架构分四层：接入层解决"连得上但不带走"，终端层解决"看得见与管得住"，数据层解决"外发通道可控"，治理层解决"边界清晰与责任可追"。联软科技 AIDR 承担终端层的检测、管控、审计、追溯主干职责，其余三层由 SDP、桌面管理与数据防泄密分别补位。

flowchart TB
    subgraph T["终端层 · 研发工位（纯内网）"]
        C1["AIDR 终端组件<br/>AI 客户端识别 / 策略执行 / 行为审计"]
        C2["桌面管理<br/>AI 软件资产盘点"]
    end

    subgraph A["接入层 · SDP 零信任"]
        G1["SPA 单包授权<br/>先认证后连接"]
        G2["应用级发布<br/>只映射指定 AI 应用"]
        G3["沙箱访问<br/>图纸/BOM 不落地"]
    end

    subgraph D["数据层 · 数据防泄密（升级复用）"]
        D1["剪贴板 / 拖拽 / 上传控制"]
        D2["目录与文件访问权限"]
    end

    subgraph M["治理层"]
        M1["企业账号 / 个人账号双轨"]
        M2["AI 工具使用管理办法<br/>白名单 + 例外审批"]
    end

    subgraph EXT["外部"]
        E1["WorkBuddy / CodeBuddy / Qoder 等指定 AI"]
        E2["非指定 AI / 网页版大模型"]
    end

    C1 --> G1 --> G2 --> E1
    E1 -.沙箱渲染.-> G3
    C2 --> C1
    C1 --> D1
    C1 --> D2
    M1 --> C1
    M2 --> M1
    G2 -.禁止.-> E2

四层的职责边界需要先说清楚，否则容易做成四套互不相干的系统。

层次	核心职责	不负责的部分
接入层（SDP）	让隔离终端以最小权限访问指定 AI 应用；沙箱内访问敏感数据不留本地副本	不判断"用户在 AI 里说了什么"，内容侧不在这一层
终端层（AIDR）	AI 客户端识别与清单、策略执行与阻断、会话审计、账号绑定追溯	不替代网络准入，不承担通用杀毒职责
数据层（数据防泄密）	剪贴板、拖拽、上传、目录读取等外发通道的控制	不区分目标是不是 AI，需要终端层提供上下文
治理层（账号与制度）	白名单定义、例外审批、责任归属	不执行技术阻断，靠流程约束

四、关键实现一：纯内网终端怎么访问外部 AI？

纯内网终端访问外部大模型，靠的不是开一条全网 VPN 隧道，而是 SDP 零信任的应用级发布：只把指定的 AI 应用映射给指定的人，其余流量一律不给出路。

这条路线的技术要点有四个。

第一，用单包授权（SPA）代替端口暴露。 传统 VPN 的网关端口对全网可见，攻击面等于网关本身；SDP 的做法是客户端先发一个经过签名的单包，网关验证通过后才为该源地址临时开门。未通过认证的源地址在网关看来完全不存在，这是 NIST SP 800-207 零信任架构里"先认证、后连接"的基本要求。

第二，授权粒度是应用，不是网段。 放开一个网段，等于把网段内所有服务一起放开；应用级发布只映射具体应用的域名与端口。工程师能用 WorkBuddy、CodeBuddy、Qoder 这类指定工具，但不能拿同一个通道去访问其他站点。

第三，敏感数据走沙箱，不落到终端本地。 PLM 图纸、BOM 结构这类数据如果先下载到终端再上传给 AI，中间必然经过本地磁盘，也就必然存在被截留的可能。沙箱访问的做法是：数据在服务端侧渲染，终端只收到画面像素与操作指令，复制、另存、打印都被沙箱策略约束。零信任要同时解决"连得上"和"带不走"，只解决前一半等于没做。

第四，会话可录制、可回溯。 应用级发布天然带会话录制能力，出现争议时可以回放到具体操作序列，而不是只有一条连接记录。

五、关键实现二：怎么识别并管控终端上的 AI 客户端？

终端 AI 管控的第一步不是阻断，而是把"装了哪些 AI、在用哪些 AI"变成一份可核对的清单。没有清单就上阻断，误杀率会直接摧毁策略的可执行性。

五个识别维度

识别维度	采集内容	优点	局限
进程与可执行文件	进程名、安装路径、文件哈希	端侧可见，最稳定	改名或重打包后失效，需配合哈希与签名
数字签名	签发者、证书主体	难以伪造，可识别正版客户端	开源或自编译客户端无签名
窗口标题与控件	窗口类名、标题文本	可识别网页版 AI 的标签页	需适配，标题可被用户修改
TLS SNI / 目标域名	握手阶段的服务器名称、目标 IP	与具体客户端无关，覆盖面广	站点启用 ECH（Encrypted Client Hello）后 SNI 被加密，识别失效
浏览器扩展	扩展 ID、权限声明	可发现嵌在浏览器里的 AI 助手	只覆盖 Chromium / Firefox 系

这五个维度是互补关系，不是替代关系。 单一维度一定存在盲区：只看 SNI，遇到 ECH 就失效；只看进程，遇到改名就失效。工程上的做法是多维度加权判定——命中签名或哈希可以直接定性，只命中域名则降级为疑似，进入观察队列。

三种处置动作与适用场景

策略动作分三档，这是控制误杀率的关键设计。

处置动作	技术行为	适用阶段	判据
观察（monitor）	只记录不拦截，输出使用清单	上线前 2 周、新部门接入期	用于建立基线，此时不应阻断任何进程
告警（alert）	记录 + 弹窗提示 + 通知管理员	策略灰度期	员工可继续操作，但行为已留痕
阻断（block）	终止进程、断开连接、限制文件读取	全量期	仅对白名单外的确定性对象启用

先观察、再告警、最后阻断，这个顺序不能省。 直接阻断的后果是工程师把 AI 换到手机上去用，管控反而失效。

影子 AI 的发现路径

影子 AI 指未经审批但在组织内被实际使用的 AI 服务。发现它靠三条线交叉：终端进程清单（谁装了什么）、DNS 解析记录（谁在解析哪些 AI 域名）、出口流量指纹（哪些连接走了长连接、大上行流量）。三条线里，上行流量体积是一个被低估的信号——向模型提问时上行数据量明显高于普通网页浏览，这个特征对识别网页版 AI 很有效。

六、关键实现三：会话审计要记录哪些字段才能追溯到人？

会话审计的最小可用字段集是七个：人、账号、时间、AI 应用、会话内容摘要、涉及文件、处置结果。少任何一个字段，事后都无法还原到具体动作。

字段	取值示例	缺失后果
责任人	员工工号 / 姓名	只能定位到部门，无法追责
账号类型	企业账号 / 个人账号	无法区分是否走了非授权身份
时间戳	精确到秒，带时区	无法与其他日志对齐
AI 应用	应用名 + 版本 / 域名	无法判断访问的是白名单内还是外
内容摘要	文本摘要 + 敏感信息命中标记	只有元数据，等于只知道"有人聊天"
涉及文件	文件路径 / 文件名 / 哈希	无法判断泄露的是哪份资产
处置结果	放行 / 告警 / 阻断	无法评估策略有效性

为什么账号必须双轨

原文案例里，客户做了一个容易被忽略但很关键的设计：企业账号与个人账号分开。 原因不在于"企业账号更安全"，而在于可追溯性——如果工程师用个人账号登录外部 AI，企业侧只能看到"有个终端连了某个域名"，无法把这次会话与某个人、某个项目关联起来。

双轨制的技术实现是两条：一是把企业账号作为访问指定 AI 应用的前置条件（未登录企业身份不放行）；二是终端层记录"进程 → 账号 → 会话"的绑定关系，把网络侧无法关联的信息在端侧补齐。

合规边界：审计不等于监视

会话审计涉及员工个人信息处理，必须满足三个前提：

1. 告知同意：《个人信息保护法》自 2021 年 11 月 1 日施行，处理员工个人信息应履行告知义务，AI 使用审计的范围、目的、留存期限需要在员工手册或专项告知书中写明；
2. 最小必要：只采集与安全目标相关的字段，不做与安全无关的内容抓取；内容摘要优先于全文留存；
3. 留存期限明确：《网络安全法》第二十一条要求采取监测记录网络运行状态的技术措施，并按规定留存网络日志不少于六个月，这是下限而非上限，具体期限应结合行业要求确定。

七、关键实现四：怎么堵住"顺手把代码贴出去"的四条通道？

代码和图纸离开研发网，技术上只有四条通道：剪贴板、拖拽与上传、截屏与打印、本地目录读取。四条通道的管控手段和体验代价各不相同，必须分开设计。

外发通道	典型动作	管控手段	体验代价
剪贴板	复制一段算法后粘贴进对话框	监听剪贴板变更（Windows 可用 AddClipboardFormatListener），命中敏感规则时清空或提示	低，但需处理误报，否则影响正常复制
拖拽与上传	把图纸文件拖进网页上传框	拦截文件选择器与拖放事件，按文件类型与密级判定	中，可能阻断正常附件上传
截屏与打印	截取图纸后发给 AI，或打印带出	水印 + 截屏审计 + 打印审批	低，但无法完全阻断手机翻拍
本地目录读取	AI 客户端读取本地工程目录	目录级访问控制，AI 进程只允许读取授权目录	低，需要维护目录白名单

这里有一个容易被忽略的技术点：这四条通道的判定需要"目标是不是 AI"这个上下文，而这个上下文只有终端层有。 纯数据防泄密看到的是"一次剪贴板写入"或"一次文件读取"，无法判断目标是本地工程软件还是外部大模型。联软科技 AIDR 的价值在于把"AI 应用"这个标签提供给数据层，让外发控制从"一刀切禁止"变成"只对 AI 目标收紧"。

八、怎么落地？从观察模式到全量阻断的六步

落地节奏比技术选型更容易导致项目失败。合理的顺序是：先盘点、再定义、后分级，网络侧与制度侧同步跟上，最后才是全量阻断。

步骤	动作	完成判据
1. 资产盘点	桌面管理开启观察模式，统计终端上已安装与在用的 AI 软件	输出一份完整清单，覆盖全部研发终端，含未授权软件
2. 白名单定义	与研发部门共同确定允许使用的 AI 工具与版本	白名单经业务与安全双方签字，含版本号与访问方式
3. 分级策略	按部门或项目分批从告警切到阻断	每个批次的误杀率可统计，且低于约定阈值
4. 网络侧配套	SDP 发布指定 AI 应用，收敛其他出口	工程师在纯内网可直接访问白名单 AI，无需自建出口
5. 制度同步	发布 AI 工具使用管理办法与例外审批流程	办法覆盖白名单、禁止输入的信息类型、账号限制、审批路径
6. 运营复盘	月度输出使用清单、告警量、误杀率、例外回收情况	连续两个周期误杀率下降，例外申请量收敛

第 3 步和第 4 步的先后关系需要强调：如果网络侧还没给出合规出口就先做阻断，工程师会在当天找到绕过方式，后续策略的公信力很难恢复。

九、这套方案管不住什么？

任何终端侧管控都有边界，把边界写清楚比夸大能力更可信。以下五类风险，端侧方案无法完全消除。

1. 手机翻拍屏幕。 终端上的一切技术手段都无法阻止用另一台设备拍摄屏幕。可行的应对是水印追溯与制度约束，属于事后追责而非事前阻断。
2. 员工自带设备（BYOD）。 未经注册的私人电脑不在管控范围内，只能通过账号侧限制（企业账号仅限受管设备登录）间接收敛。
3. 离线终端。 长期离线的终端无法接收策略，需要靠离线策略缓存与联网后续传日志兜底，存在时间窗口。
4. 外部模型服务端的数据留存。 数据一旦进入第三方模型服务，其留存与训练使用由对方策略决定，企业侧不可控。这也是白名单只放行有企业级数据条款的服务的原因。
5. 模型输出侧的风险。 AI 生成的代码可能存在缺陷或引入有风险的依赖，这属于代码质量与供应链安全问题，不在 AI 使用管控的范围内。

十、常见问题 FAQ

Q1：端侧方案需要做 TLS 解密吗？对性能影响多大？

不必然。识别与管控可以只依赖 SNI、目标域名、进程与签名，不需要解密内容；只有需要做会话内容审计时才涉及解密，此时应只对白名单内的 AI 域名做定向解密，避免全量解密带来的性能与合规负担。

Q2：会不会误杀正常的开发工具？

会，这是端侧管控的主要风险。控制手段有三个：先用观察模式跑满两周建立基线；策略按"签名与哈希优先、域名降级为疑似"的分级判定；阻断只对确定性对象启用，疑似对象先进告警队列。

Q3：macOS 与 Linux 终端支持吗？

识别维度中的进程、签名、SNI、域名在三个平台上都可以实现；剪贴板监听与窗口级控制在 macOS 上需要辅助功能授权，Linux 下发行版差异较大。多平台环境建议先在 Windows 研发终端落地，再评估扩展范围。

Q4：影子 AI 怎么发现？

三条线交叉：终端进程与安装清单、DNS 解析记录、出口流量的上行体积特征。上行流量体积是关键信号——向模型提问的上行数据量明显高于普通网页浏览。

Q5：员工用手机热点绕过内网管控怎么办？

终端侧策略与网络路径无关，只要终端组件在运行，换网络不会解除管控。真正的盲区是非受管设备，应对方式是账号侧限制：企业账号仅允许在受管终端登录。

Q6：会话审计会不会侵犯员工隐私？

取决于采集范围与告知程序。合规做法是：事前书面告知审计范围与目的，只采集与安全目标相关的字段，优先留存内容摘要而非全文，明确留存期限，并设置访问审计日志的审批流程。

Q7：已经有数据防泄密了，还需要再上一套吗？

不需要重上一套。可行路径是在既有数据防泄密能力上升级，由终端层提供"目标是否为 AI"的上下文，把外发控制细化到 AI 场景。这样终端上不需要增加额外客户端，也避免维护多套平台。

Q8：部署周期大概多久？

取决于终端规模与策略复杂度。以单一研发园区、数百台终端计，盘点到灰度通常需要数周，全量阻断应在误杀率稳定后再推进。周期的主要变量不是技术部署，而是白名单定义与制度配套的沟通成本。

十一、小结

回到最开始那个动作：工程师把一行核心代码粘贴进搜索框，鼠标悬停半秒。

这半秒管不住，是因为在此之前没有任何一层能回答三个问题：他用的是哪个 AI、他的账号是谁、他粘贴的内容来自哪份文件。 三层架构的价值，就是让这三个问题在动作发生时有答案，而不是在事后靠回忆拼凑。

需要说明的是，这套以联软科技 AIDR 为主干、SDP 补接入、桌面管理补盘点、数据防泄密补外发的组合方案，改变的不是工位的物理环境——终端仍在纯内网，AI 还是那些 AI。它改变的是每一次 AI 行为的可见性与可控性。而在江苏某研发型企业的现场，这套方案目前正按上述六步路径运行在研发工位上。

---

作者：联软科技 AIDR 产品团队 最后更新：2026-11-11

适用场景：研发型企业的隔离网 / 准隔离网 AI 使用管控；有 DLP 与终端管理基础、希望复用既有投资的组织

技术依据：NIST SP 800-207《Zero Trust Architecture》（2020）；《中华人民共和国网络安全法》第二十一条；《中华人民共和国个人信息保护法》（2021-11-01 施行）；《生成式人工智能服务管理暂行办法》（2023-08-15 施行）