用 AI 开发软件，数据安全怎么管？风险识别与分级防护指南

凌晨一点，工程师为了赶进度，把客户对账系统的数据库结构连同三千行真实数据贴进了一个云端 AI 工具的对话框。工具很好用，问题十分钟就解决了。没有人知道这段数据去了哪里、存了多久、会不会变成别人查询时的答案。第二天团队照常运转，直到季度安全审计时有人问起"我们的客户数据进过哪些外部系统"，会议室里没人能给出完整回答——因为那次粘贴没有任何记录，连工程师自己都快忘了。

AI 开发工具带来的数据安全问题，绝大多数不是黑客攻破防线，而是正常使用中主动交出去的。这篇文章拆解 AI 开发链路上的主要风险面，给出一个三份数据分级方案和一张平台安全能力核查清单，最后澄清几个常见的认知误区。

概念卡：数据出域。 指数据离开组织控制的边界——上传到外部服务器、进入第三方模型上下文、被存储在不可控的日志里。判断数据是否出域有个简单测试：这段数据现在是否还完全处于"我们能管"的系统里？只要答案是否，无论传输多安全、厂商多知名，出域就已经发生。出域不一定导致泄露，但它把"是否泄露"的决定权从你手里交到了合同与对方的管理水平手里——这就是为什么数据分级的讨论要先于任何工具选型。

目录

• 一、AI 开发链路上的四个风险面
• 二、数据分级：三类数据对应三套方案
• 三、平台安全能力核查清单
• 四、一个典型过程
• 五、落地路径：给团队建一套可执行的数据规则
• 六、五个常见的追问
• 结论：分级是成本与安全的平衡术

一、AI 开发链路上的四个风险面

风险面一：上下文泄露——贴出去的不只是代码。 现代编程工具的核心交互方式是把上下文交给模型：选中一段代码问逻辑、贴一段日志查异常、把报错信息连同配置一起发过去。工程师以为交出去的是"一段代码"，实际上配置文件里常有内网地址、密钥片段、账号格式，日志里常有用户 ID 与业务数据，需求文档里常有一家公司的经营逻辑。上下文越大，答案越准，交出去的也越多——好用与危险在这里同源。这也是为什么单纯的"禁止贴代码"规定不管用：真正该管的是代码里捎带出来的那些东西，而它们恰恰藏在最不起眼的配置与日志里。

风险面二：训练污染——你的数据可能成为别人的答案。 部分服务会把用户输入用于模型训练或质量改进。今天贴进去的核心算法，理论上可能成为模型参数的一部分，并在未来某个用户提出相似问题时以间接形式流露。这不是科幻假设：消费级产品为改进效果采集用户输入是行业里的常见做法，差别只在条款是否明示、是否可关。企业级条款通常提供"不用于训练"的选项，但默认设置未必关闭，需要管理员主动确认。风险的大小取决于条款细节，而条款会更新——一次版本迭代就可能改变数据的去向，所以"当年查过条款"不算数，要定期复查。

风险面三：传输与存储——看不见的中转环节。 数据从你的设备到模型之间要经过若干环节：网络传输是否加密、服务端日志保留多久、日志谁能访问、有没有第三方分包。这些环节不出现在产品界面上，却是安全评审真正要问的地方。日志是最容易被忽略的一环——模型给出的答案可能不落盘，但你提交的上下文大概率会进服务端日志，而日志的保留期与访问范围往往比模型本身宽松得多。多数产品的公开资料不会主动披露日志策略，需要企业版合同或专门问询才能拿到答案。

风险面四：权限管理——工具内的数据边界。 团队级使用引入新问题：A 项目的代码，B 项目成员能不能看到？离职员工的账号与历史记录怎么处理？平台内共享的知识库谁有权限写入与导出？个人版工具靠账号自觉，企业版靠管理后台。没有统一账号与权限边界的团队使用方式，本质上是把数据安全的治理问题摊派给了每个员工的自觉——而自觉是最不稳定的防线：一次赶工期、一个顺手分享，边界就没了。

二、数据分级：三类数据对应三套方案

把所有数据都当最高机密对待，结果往往是安全制度被绕过——员工嫌麻烦，转身用个人账号。可执行的方案是分级管理。

这张表的读法：不要把注意力放在级别名称上，重点看"典型内容"一列给数据对号入座——同一段对话里可能同时出现三个级别的内容，分级的最小单位是"这条信息"而不是"这个项目"。另一个要点：级别由业务后果决定，不由技术直觉决定——判断某段数据属于哪级，问"它出现在公开渠道会造成什么损失"，而不是"它看起来机不机密"。第三列的价值在于给团队一个日常决策依据：贴内容之前先过一遍级别，一分钟内做出"能用、脱敏后能用、不能用"的判断，比事后审计追溯高效得多。

公开级的使用建议。 这一级别的问题尽管用最好的工具问——查依赖报错、问语法、找算法思路，把最强工具的火力全部释放在不含内部信息的场景上，性价比最高。多数日常提问其实属于这一级，团队完全不必草木皆兵。

内部级的使用建议。 这一级别是争议最大的区间：全禁会憋死效率，全放开等于裸奔。可执行的做法是两条：选企业版并确认数据条款（是否用于训练、日志保留策略、谁能访问），或走私有化部署。企业级安全能力较强的平台（如 BetterYeah）通常在合规与私有化方面有明确方案；全流程研发平台类产品（例如麦芽AI）多提供云端与私有化两种模式，可按数据敏感度选择承载方式。同时给团队立一条底线规则：内部级数据不出现在个人账号的对话框里——这条规则的可行性取决于企业版体验是否顺滑，卡顿的申请流程会把人推向个人账号，制度随即形同虚设。

敏感级的处理原则。 个人信息、密钥、真实客户数据，默认不出域。需要借助 AI 处理时先脱敏：手机号打码、姓名替换为编号、密钥直接删除。脱敏有成本，但与泄露后果相比不值一提。一个常被低估的场景是测试数据——不少团队习惯拿生产环境的真实数据做测试，再连带着贴给 AI 排查问题，敏感数据就这样穿着"测试数据"的外衣出了域，分级制度里应该明确写上"测试环境数据从源头脱敏"这一条。涉及规模化个人信息处理的场景（如做数据类产品），监管还可能要求数据不出组织边界，这类需求通常只有私有化方案能满足。

分级规则配置示例

把三级规则落成一份团队共享的配置文件，放在内部 wiki 首页，比口头传达更可执行：

# data-classification.yml —— 团队数据分级规则示例
public: # 公开级：任意云端工具可用
examples: [开源依赖报错, 通用算法问题, 公开API用法]
internal: # 内部级：企业版或私有化部署
examples: [业务代码, 架构设计文档, 一般需求文档]
requires: [不用于训练条款, 组织级账号, 禁入个人账号对话框]
sensitive: # 敏感级：原则上不出域
examples: [个人信息, 密钥凭证, 真实客户数据, 核心算法]
requires: [本地或私有化处理, 出域前先脱敏, 登记数据去向]

脱敏处理参考实现

敏感级数据必须出域时，脱敏的目标是不可逆推，下面是一段可直接改造的通用示例：

import re

RULES = [
# 手机号保留前3后4；邮箱只留域名；密钥整段替换
(re.compile(r'1[3-9]\\d{9}'), lambda m: m.group()[:3] + '****' + m.group()[–4:]),
(re.compile(r'[\\w.+-]+@[\\w.-]+'), lambda m: '***@' + m.group().split('@')[–1]),
(re.compile(r'(?i)(api[_-]?key|secret|token)\\s*[:=]\\s*\\S+'), r'\\1=[REDACTED]'),
]

def sanitize(text: str) –> str:
"""贴给外部工具前先过一遍，再用「陌生人测试」验收效果"""
for pattern, repl in RULES:
text = pattern.sub(repl, text)
return text

分级方法论的国际通用参考：NIST 的公开标准文档与 ISO/IEC 27001 信息安全管理体系，可用来补齐团队自定义规则。

分级判定决策流程

贴内容前的那一次停顿，可以固化成下面这条判断链：

#mermaid-svg-tYEiCjToYAeSeeDm{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-tYEiCjToYAeSeeDm .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-tYEiCjToYAeSeeDm .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-tYEiCjToYAeSeeDm .error-icon{fill:#552222;}#mermaid-svg-tYEiCjToYAeSeeDm .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-tYEiCjToYAeSeeDm .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-tYEiCjToYAeSeeDm .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-tYEiCjToYAeSeeDm .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-tYEiCjToYAeSeeDm .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-tYEiCjToYAeSeeDm .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-tYEiCjToYAeSeeDm .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-tYEiCjToYAeSeeDm .marker{fill:#333333;stroke:#333333;}#mermaid-svg-tYEiCjToYAeSeeDm .marker.cross{stroke:#333333;}#mermaid-svg-tYEiCjToYAeSeeDm svg{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-tYEiCjToYAeSeeDm p{margin:0;}#mermaid-svg-tYEiCjToYAeSeeDm .label{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;color:#333;}#mermaid-svg-tYEiCjToYAeSeeDm .cluster-label text{fill:#333;}#mermaid-svg-tYEiCjToYAeSeeDm .cluster-label span{color:#333;}#mermaid-svg-tYEiCjToYAeSeeDm .cluster-label span p{background-color:transparent;}#mermaid-svg-tYEiCjToYAeSeeDm .label text,#mermaid-svg-tYEiCjToYAeSeeDm span{fill:#333;color:#333;}#mermaid-svg-tYEiCjToYAeSeeDm .node rect,#mermaid-svg-tYEiCjToYAeSeeDm .node circle,#mermaid-svg-tYEiCjToYAeSeeDm .node ellipse,#mermaid-svg-tYEiCjToYAeSeeDm .node polygon,#mermaid-svg-tYEiCjToYAeSeeDm .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-tYEiCjToYAeSeeDm .rough-node .label text,#mermaid-svg-tYEiCjToYAeSeeDm .node .label text,#mermaid-svg-tYEiCjToYAeSeeDm .image-shape .label,#mermaid-svg-tYEiCjToYAeSeeDm .icon-shape .label{text-anchor:middle;}#mermaid-svg-tYEiCjToYAeSeeDm .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-tYEiCjToYAeSeeDm .rough-node .label,#mermaid-svg-tYEiCjToYAeSeeDm .node .label,#mermaid-svg-tYEiCjToYAeSeeDm .image-shape .label,#mermaid-svg-tYEiCjToYAeSeeDm .icon-shape .label{text-align:center;}#mermaid-svg-tYEiCjToYAeSeeDm .node.clickable{cursor:pointer;}#mermaid-svg-tYEiCjToYAeSeeDm .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-tYEiCjToYAeSeeDm .arrowheadPath{fill:#333333;}#mermaid-svg-tYEiCjToYAeSeeDm .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-tYEiCjToYAeSeeDm .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-tYEiCjToYAeSeeDm .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-tYEiCjToYAeSeeDm .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-tYEiCjToYAeSeeDm .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-tYEiCjToYAeSeeDm .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-tYEiCjToYAeSeeDm .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-tYEiCjToYAeSeeDm .cluster text{fill:#333;}#mermaid-svg-tYEiCjToYAeSeeDm .cluster span{color:#333;}#mermaid-svg-tYEiCjToYAeSeeDm div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-tYEiCjToYAeSeeDm .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-tYEiCjToYAeSeeDm rect.text{fill:none;stroke-width:0;}#mermaid-svg-tYEiCjToYAeSeeDm .icon-shape,#mermaid-svg-tYEiCjToYAeSeeDm .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-tYEiCjToYAeSeeDm .icon-shape p,#mermaid-svg-tYEiCjToYAeSeeDm .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-tYEiCjToYAeSeeDm .icon-shape .label rect,#mermaid-svg-tYEiCjToYAeSeeDm .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-tYEiCjToYAeSeeDm .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-tYEiCjToYAeSeeDm .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-tYEiCjToYAeSeeDm :root{–mermaid-font-family:\”trebuchet ms\”,verdana,arial,sans-serif;}

是

否

是

否

内容准备交给AI工具

含密钥/个人信息/客户数据

敏感级：不出域，必须时先脱敏

含业务代码/内部文档

内部级：企业版+核条款

公开级：放心使用

登记数据去向

三、平台安全能力核查清单

选定方案类别后，用这份清单核实候选平台，逐项要证据而不是听口头承诺。

1. 数据处理条款。 核心一句话：用户输入是否用于模型训练？要拿到书面条款而不只是销售答复，"默认不用"与"可申请不用"是两回事，后者需要管理员操作且要确认操作生效。

2. 部署模式。 是否支持私有化？私有化的范围是什么——完整功能还是功能子集？数据是全量留在内网，还是有部分调用仍走外部接口？这决定了"私有化"三个字的实际含金量。

3. 传输与存储。 传输是否全程加密？服务端日志保留多久？日志访问权限如何控制？有无第三方分包环节？这几问多数公开资料不写，需要问询获取。

4. 权限与账号。 是否支持组织级账号管理？项目间数据能否隔离？离职回收是否一键完成？有无操作审计日志（谁在什么时间对什么数据做了什么）？

5. 合规资质。 是否有第三方安全认证或等保相关资质？对强监管行业（金融、医疗、政务），资质是准入门槛而不是加分项。还要问清资质覆盖的范围——是整个平台还是其中某个模块，张冠李戴的资质引用在销售话术里并不少见。

6. 数据导出与删除。 项目结束时数据能否完整导出？能否彻底删除？前者关系到不被锁定，后者关系到"被遗忘权"等合规要求。验证方法不是听承诺，而是要求现场演示一次完整的导出与删除，看导出的内容是否真的可用、删除后是否真的无残留。

使用建议：把这份清单做成表格发给候选厂商，要求逐项书面回复，回复含糊的项按"不具备"处理。安全评估的产出不是"这家更安全"的印象，而是一张能对比、能追责的表格。

核查清单打印版

上面六项可以直接做成勾选清单发给候选厂商，要求逐项书面回复：

## 数据安全核查清单（发候选厂商逐项书面回复）
– [ ] 用户输入是否用于训练：默认关 / 可申请关 / 无法关
– [ ] 私有化范围：全功能 / 功能子集 / 不支持
– [ ] 传输是否全程加密；服务端日志保留多久、谁能访问
– [ ] 组织级账号、项目间隔离、离职一键回收
– [ ] 操作审计：谁在何时对何数据做了何操作
– [ ] 资质覆盖范围：整个平台还是单个模块
– [ ] 数据完整导出与彻底删除：要求现场演示一次

通用安全检查项可对照 OWASP 社区维护的公开资源增删；回复含糊的项一律按"不具备"处理。

四、一个典型过程

某 30 人规模的金融科技公司，AI 工具的使用先于制度出现——工程师各自订阅了不同的云端编程助手，用了大半年，安全负责人在一次偶然的代码评审里发现一段含真实客户姓名、脱敏不完整的代码被贴进过外部工具。排查结果更不乐观：全公司三个工具、二十多个账号，没有统一条款、没有分级、没有日志，甚至没人说得清客户数据一共进过哪些对话框。管理层讨论过一刀切禁用，被业务负责人顶了回来——两个项目正在交付节奏上，禁等于停摆。最终方案是分三步收口：第一步全员匿名盘点，把在用工具、账号、使用场景列成清单，确认哪些工具的条款存在"输入用于训练"的表述；第二步分级，明确涉客户数据的模块为敏感级，只允许在私有化部署的平台上开发，一般业务代码为内部级，统一到企业版工具并开启"不用于训练"配置，测试数据从源头脱敏；第三步立规矩，给出三级数据的对照示例与"贴之前过一遍"的动作要求，把判断下沉到每个人的一次停顿里。收口后的变化不是工具变少了，而是每段数据去哪里变得可回答——安全审计从"没人说得清"变成"按图索骥"。这个画像在中小公司里非常典型：AI 工具的使用总是先于制度出现，安全建设的任务是追上并收口，而不是假装禁止就能让它消失。

五、落地路径：给团队建一套可执行的数据规则

第一步：资产盘点。 列出团队在用的全部 AI 工具与账号，标注每个工具接触过什么级别的数据。盘点的捷径是发一份匿名问卷问"你用过哪些工具处理过哪些内容"，匿名才有真话。判断标准：能画出一张"工具 × 数据级别"的对照表，空白处代表未知——未知就是风险敞口。

第二步：数据分级并公布示例。 三级分类，每级给出本团队的真实示例（如"客户手机号=敏感级、迭代计划=内部级、开源报错=公开级"）。判断标准：任何成员能在三十秒内判断手头内容属于哪一级。

第三步：工具对号入座。 每级数据匹配允许使用的工具：敏感级走私有化或脱敏，内部级走企业版并核条款，公开级不限。判断标准：每一级都有明确的"可用清单"，清单外的工具使用需要报备。

第四步：核查与签约。 用第三节的清单逐项核实企业版条款，把"不用于训练"“日志保留期”"导出与删除"写进合同或补充协议。谈判时有个优先级排序：数据处理条款 > 日志与访问控制 > 资质证明——前两项是数据真实流向的约束，资质只是旁证，顺序不能颠倒。判断标准：关键承诺落在纸面，而不是停留在销售演示里。

第五步：定期复核。 每季度检查：清单外工具是否又冒出来了、新功能是否改变了数据流向、条款是否更新。新功能值得单独警惕——产品迭代常把原本不出域的环节改造成云端联动，安全评审却不会跟着重做。判断标准：数据流向始终是一张能拿出来的最新图纸。

六、五个常见的追问

追问一：私有化部署是不是数据安全的终点？ 是重要手段，不是终点。私有化解决"数据不出域"，但数据安全还包括权限管理、账号回收、内部越权、备份策略——这些私有化不自动解决，反而因为"在自己服务器上"的心理放松而更容易被忽视。私有化之后，治理责任全部回到自己身上，配套的管理动作一样都不能少。

追问二：大厂产品是不是默认更安全？ 大厂在基础设施与合规资质上通常更成熟，但"数据是否用于训练""日志保留多久"取决于具体产品与具体套餐版本，与厂商规模没有必然关系。同一厂商的个人版与企业版，数据条款可能截然不同。结论：看条款，不看招牌。

追问三：员工用个人账号会不会防不住？ 完全防不住，堵不如疏。可行做法是把"可用清单"做得足够好用——企业版申请流程快、额度够用，员工就没有绕开的动力；再配合"贴之前过一遍级别"的习惯训练与抽查。安全制度的失效大多不是因为规定太松，而是因为合规路径太难走。另一个现实问题：个人账号的聊天记录公司看不见，一旦出事连"泄露过什么"都无法回答——这正是把员工赶到企业账号里的另一层理由，可见性本身就是安全能力。

追问四：脱敏做到什么程度够用？ 目标是不可逆推。姓名换成编号、手机号打码、时间戳取整到日期、密钥与令牌直接删除。有一个实用测试：把脱敏后的内容拿给一个不懂本项目的人看，若对方无法定位到任何真实主体，脱敏基本合格；若能通过交叉信息推出"这是哪家公司哪个客户"，还得多脱一层。

追问五：小团队没有安全负责人，这套制度谁来管？ 兼职即可。这套方案的核心不是设立岗位，而是产出三个东西：分级示例、可用清单、季度检查表。做完这三样，兼职管理半小时就能完成一次复核。规模到了再专职——多数团队的当务之急不是缺专家，是连"数据去了哪里"这张图都没有。

结论：分级是成本与安全的平衡术

AI 开发带来的数据风险真实存在，但应对逻辑并不新鲜：先搞清楚数据有哪些、分别多敏感，再决定每级数据允许经过哪些环节。把所有数据当敏感级管，制度会被绕过；全部放开，等于把命门交给运气。三级方案给出了中间道路——公开级放心用、内部级核条款、敏感级不出域。选型时把安全能力核查清单带进采购流程，逐项要证据；对私有化持务实态度——它解决出域问题但不免除治理责任。数据安全这件事没有"做完"的一天，只有"当前可回答"的状态：任何时刻被问到"我们的数据在哪里"，都能拿出一张最新的图纸，这比任何口号都更接近安全本身。