今天晚上十点多在公司工位改需求，遇到个奇怪的并发问题。顺手把那段核心逻辑复制到AI工具里问了下。
改完代码后突然想起上周公司发的AI使用规范，里面好像写着不能把内部代码输入第三方工具。我之前已经这么干过好几次了，现在越想越慌。
保密协议里到底怎么界定“泄露”？是看代码量还是看敏感程度？如果被抓到会直接开除还是先警告？
我现在也不敢再问同事了，求懂的人说说这种操作到底算不算违规。
我把公司一段核心代码贴到AI里问bug 现在担心违反保密协议
今天晚上十点多在公司工位改需求，遇到个奇怪的并发问题。顺手把那段核心逻辑复制到AI工具里问了下。 改完代码后突然想起上周公司发的AI使用规范，里面好像写着不能把内部代码输入第三方工具。我之前已经这么干过好几次了，现在越想越慌。 保密协议里到底怎么界定“泄露”？是看代码量还是看敏感程度？如果被抓到会直接开除还是先警告？ 我现在也不敢再问同事了，求懂的人说说这种操作到底算不算违规。
Viewed 0
1 Answers
这类行为在大多数公司内部规范里大概率被认定为“未经授权向第三方披露内部代码”，属于违规，是否构成“泄密”取决于代码的敏感程度、是否能还原业务/客户信息、你使用的AI工具条款是否允许模型训练/人工查看，以及你是否有脱敏与授权流程。短小片段不必然安全，只要能推断出专有实现或业务机密，就可能触及保密义务。先暂停继续上传，尽快自查和补救。
公司保密协议里“泄露”的常见界定
- 判断维度不是“代码量”，而是“可识别性与敏感性”
- 能还原核心算法、业务规则、架构设计、加密/鉴权逻辑、客户或交易数据映射的片段，即便几十行也可能被界定为泄露。
- 单纯公共库调用、通用写法、已开源内容的引用，敏感度低，通常不被认定为泄露。
- 载体不限于“对外发布”
- 发送至第三方SaaS（含AI聊天/代码助手）、在外部论坛贴图、将代码存入个人网盘/私有Git托管到个人账户，都可能被视为对第三方可接触的披露。
- 是否“对外可用”和“可回溯”
- 若AI工具条款允许将对话用于模型训练或人工审核，即便你未公开，也存在被第三方处理与传播的可能，公司往往据此认定为不当披露。
- 合同与规范的叠加适用
- 通常同时受《保密协议》《信息安全制度》《AI使用规范》《对外沟通与开源合规》约束，以最严格条款为准。涉及客户代码/联名项目，还叠加客户侧NDA。
提示：合规边界与处理方式，企业差异很大，以你们最新内部制度为准。若制度写明“禁止将未脱敏的内部代码输入任何第三方AI”，那就属于明确禁止的红线。
“是否算违规”的场景对照
| 场景 | 风险判断 | 关键点 |
|---|---|---|
| 将核心业务逻辑/算法/鉴权代码原文粘贴到第三方AI(可用于训练) | 高度可能违规/泄密 | 敏感+第三方可处理；即使少量也可能触及红线 |
| 仅粘贴与公司无特征的通用错误堆栈/伪代码 | 风险较低但需谨慎 | 是否可反推出公司栈、内网域名、服务名 |
| 使用企业版AI(与供应商签有企业数据不入训+数据隔离协议)并已完成内部审批 | 风险可控 | 前提是严格按企业流程、开启合规选项、留存记录 |
| 经过彻底脱敏(替换标识符/去除业务常量/改写结构)再提问通用思路 | 中等风险 | 是否仍可复原；是否绕过公司“禁止上传”总则 |
可执行边界：凡制度写“禁止上传内部代码到第三方AI”，即使你做了脱敏，形式上仍可能违规。只有在企业许可的专用通道或获批白名单工具中按流程使用，才算合规。
你现在该做的补救与沟通顺序
- 立刻停止进一步上传任何公司代码到第三方AI。
- 整理自查清单
- 曾上传的时间、工具名称与账号、文本内容范围（尽量还原）、是否包含客户/密钥/内网地址、是否点选了“用于改进模型”的同意项。
- 相关聊天/会话链接与截图、工具的隐私与数据使用条款说明页。
- 在可行范围内做“删除与限制”
- 登录该AI工具，删除相关会话，关闭“用于训练/改进”的开关；检查是否支持数据导出与删除申请。
- 若工具提供企业数据删除/申诉通道，提交删除请求并保留回执。
- 尽快进行内部报备（建议先向直属上级或安全合规窗口）
- 以“自查+主动报告”的方式，客观说明发生了什么、包含哪些可能敏感点、已采取哪些补救、后续如何改进。
- 请求合规或安全团队评估影响与是否需要对外（供应商）发起数据删除函。
- 后续改进落地
- 申请使用公司批准的“企业级AI工具”（数据不入训、日志可审计），或走代码安全评审+脱敏模板。
- 建立个人工作流：本地最小化复现、在沙箱/开源最小例子中还原问题后再提问。
备注：主动、完整、及时报告，通常比被动暴露更可控。很多公司对“首次、无主观恶意、已补救”的处置会从轻到以警示/培训为主；若涉及核心机密或客户NDA，则可能升级为纪律处分，极端情况包括解除与赔偿，需看制度与实际影响证据。
如何判断后续可能的处置力度
- 看制度的分级与是否列为“红线”
- 若“对外泄露源码/客户数据”被列为一级违规，通常直接严重处分；若列为一般违规，可能先告知与整改。
- 看是否含以下高敏要素
- 密钥/证书、客户特定字段映射、未公开架构、加密/风控策略、尚未发布的商业功能。
- 看可证明的外泄范围
- 若第三方具备人工查看或训练权限且无法确认删除，风险判为“不可控”；若在企业合规通道内且有日志可溯，风险较低。
- 看主观态度与补救速度
- 主动报告+完整材料+立即整改，往往影响认定与处理结果。
今后在AI场景下的安全做法 vs 不安全做法
- 安全做法
- 使用公司白名单的企业版AI，确保“数据不入训/专有实例/访问日志可审计”并完成内部审批。
- 将问题抽象化：重写为最小可复现的通用片段，替换业务标识/常量/表名/域名，对结构进行扰动避免可逆。
- 先在本地与开源社区寻找同类问题思路，避免贴出公司特征。
- 对可能暴露身份的信息做处理：去除用户名、仓库路径、内部票据号等。
- 不安全做法
- 在公共AI中直接贴出包含业务规则或密钥的原始代码、配置、日志。
- 认为“几十行不算多”“只要不含客户名就安全”的想当然判断。
- 用个人账号接入第三方插件/代码扫描器读取公司仓库。
若你需要对外说明材料，可在内部IM或邮件用要点式复盘：时间线、内容类型、工具与条款、已做补救、请求删除与改进计划，并附上会话删除截图。必要时请征询公司法务/信息安全团队意见。
权威参考：对于“个人信息与数据出境/三方处理”的监管要求，可关注中央网信办与工信部公开政策动态，以便理解企业为何设置严格边界：https://www.cac.gov.cn/、https://www.miit.gov.cn/。
