常见问题
这些问题来自客户现场、公众号后台和我们自己的项目复盘。每条都直接回答，不绕。
分类分级
技术路线、准确率与选型
数据分类分级不就是给文件打标签吗？
打标签是结果，不是方法。真正的难点在于判断「这份数据服务于什么业务、对应哪条法规、在什么组合下会升级为高敏感」。只按字段名匹配的工具，在拼音缩写、同名异义、历史遗留命名面前会大幅失效——而这恰恰是企业最需要工具帮忙的区域。
展开阅读：数据分类分级的三代范式 →厂商说准确率 95%，这个数字可信吗？
要看测试方法。常见的做法是：测试集由厂商提供、未识别字段不计入分母、只测常见字段、把非结构化排除在外、不公布混淆矩阵、测试集与训练集同源。任何一条成立，这个数字都不能直接采信。合理的做法是测试集由客户从生产系统抽取，且必须包含拼音缩写、行内特殊命名与历史遗留字段。
展开阅读：分类分级准确率 95% 是怎么算出来的 →怎么分辨真 AI 分类分级和包装过的旧工具？
问三个问题。第一，请解释这个字段为什么被判定为敏感——如果答案是「触发了某条规则」，那就是规则引擎。第二，如果有五千个行内特殊命名字段怎么处理——如果要一条条加进规则库，AI 没有减少配置工作。第三，新监管文件发布后多久能适配——如果周期是三到六个月，说明底层仍要人工改规则、发版本。
展开阅读：如何分辨真假 AI 数据分类分级 →我们已经有 DLP 了，还需要分类分级吗？
需要，两者解决的是不同问题。DLP 解决「拦不拦」，分类分级解决「该拦什么」。传统 DLP 靠正则和关键词，规则脆弱：调严了挡住正常业务，调松了形同虚设。它的病根不在拦截能力，而在不知道该拦什么。分类分级提供带业务语义的判断依据，是 DLP 的大脑而不是替代品。
展开阅读：Cyera 两年五次收购：DSPM 为什么必须吃下 DLP →非结构化数据怎么做分类分级？
关键是把非结构化形态还原为可识别的数据项，再按与结构化字段相同的方法分级。这不是 OCR，也不是关键字匹配，而是基于业务上下文的识别。人行令 3 号对此有明确要求：非结构化数据项应当优先按照可拆分的各结构化数据项所对应的最高层级标识其层级。
展开阅读：数据离开数据库之后怎么管 →AI 数据安全
AI 应用中的数据治理与权限
把企业文档喂给 AI 之前，需要做什么？
至少四件事：去重与版本识别，避免旧版污染知识库；来源确认，保证可追溯；分类分级，判断哪些数据允许进入；权限映射，把原始 ACL 同步进来。这四件事必须在入库前完成——权限关系一旦在切片环节丢失，后面补不回来。
展开阅读：数据进 AI 之前的四道关卡 →给知识库配了角色权限，为什么还会越权？
常见做法是用提示词约束 AI「如果用户是客服，不要回答核保内容」。提示词约束是软约束，AI 不一定严格遵守，攻击者可以通过 Prompt Injection 绕过，普通用户也可能在不知情的情况下命中越权内容。可靠的做法是让越权内容在检索的候选阶段就被排除，压根不进入模型上下文。
展开阅读：AI Agent 安全的六层防御栈 →AI Agent 用服务账号跑有什么问题？
服务账号通常权限过大且长期有效。当 Agent 代表不同用户执行任务时，它能访问的数据范围会超出用户本人的权限；而审计日志里只看得到服务账号，追不到真实委托人。出了事既说不清责任，也还原不了过程。
展开阅读：Agent 时代正在失效的十二个安全假设 →每次使用都判一遍权限，性能扛得住吗？
扛得住，因为理解是提前做完的，运行时只做「查身份证」这个动作。存量数据的标签在入库时离线算好；增量数据靠事件触发秒级补办，补办完成前一律按最高敏感对待；衍生数据直接继承源头标签。真正需要现场判断的只有用户现敲的问题和 AI 现生成的回答，这部分走规则、小模型、大模型三级漏斗。
展开阅读：AI 时代的数据安全怎么建 →合规监管
法规标准的落地问题
JR/T 0358—2026 和 DSMM 是什么关系？
JR/T 0358 引用了 GB/T 37988（DSMM），沿用其五级成熟度与四个能力维度，但做了四处金融化改造：顶层骨架从 30 个过程域重构为 4 能力域 × 19 能力子域；生命周期从 6 阶段细到 10 环节；分类分级与运营保障从过程项提升为独立能力域；等级语义从「非正式执行到持续优化」换成「随机被动到智能化闭环」。
展开阅读：JR/T 0358—2026 解读 →金发〔2026〕8 号对训练数据有什么硬性要求？
第二十四条明确：姓名、身份证号、手机号、银行卡号等个人信息和隐私数据，不得用于生成式人工智能模型的训练和优化。条文用的是「不得」，前面没有「审慎」「原则上」这类缓冲词。配套要求还包括第九条的高质量数据集标准与第二十一条的留痕要求（日志保存期限不低于业务存续期）。
展开阅读：金发〔2026〕8 号解读 →分类分级只是金融行业的要求吗？
不是。法律源头是《数据安全法》第 21 条，适用于所有行业、所有数据处理者。金融、医疗、电信、工业、能源、交通、教育、水利、政务、汽车等行业都有各自的实施细则，只是节奏不同——金融业已进入执法阶段，其他行业多处于制度建立期。
展开阅读：数据分类分级不只是金融的题 →监管检查时到底在查什么？
从公开罚单看，火力集中在三段：采集质量（数据不真实、信用信息违规采集查询）、处理与报送（查询权限失控、报送不准确）、对外共享（第三方合作数据安全管控不到位）。再叠加一个横跨全周期的制度治理层——事由写「违反数据安全管理规定」这类笼统表述的，往往是顶层制度缺位。
展开阅读：2026 金融数据安全罚单分析 →产品与服务
我们提供什么、边界在哪
你们的产品和 RAG、Agent 平台是什么关系？
对外销售的软件产品只有模界·知源 AiDClass，负责数据分类分级，可独立服务于 DLP、数据治理、迁移与审计系统。RAG 知识库平台和 Agent 平台不是我们的产品，而是做落地服务时使用的平台层：基座按客户环境选择开源软件或客户现有平台，知源输出的标签与权限依据接在上面。三者松耦合，可以只买软件、只做服务，也可以组合。
展开阅读：AI 数据安全：哪些能买到，哪些必须自建 →支持私有化部署吗？数据会出域吗？
支持私有化部署，并可使用客户本地模型。重要数据尽量不离开客户环境是产品的默认设计前提，不是可选项。
你们和通用 Agent 平台厂商有什么不同？
我们不重新发明通用 Agent 框架。底层模型、Agent 框架与工具生态保持可兼容，不以模型数量和插件市场作为竞争点。我们真正掌握的是身份传递、权限模型、策略服务、执行控制、活动图谱与审计解释——也就是「让 Agent 在企业权限内工作」这一层。
RAG 和 Agent 项目一定要用你们的平台吗？
不一定。我们不自研通用知识库或 Agent 框架，项目里用的是开源基座或客户已有的平台，我们负责的是权限继承、标签接入、执行控制与审计这一层的设计与实施。客户已有知识库或 Agent 平台的，直接在其上改造；没有的，我们按客户环境选型开源基座。
FDE
角色定义与转型
什么是 FDE？
FDE 是 Forward Deployed Engineer，前线部署工程师。国际标准下有五条硬性特征：对生产结果负责（以采用率与业务影响计，不以验收完成计）；拥有从发现、范围界定、系统设计、构建到生产上线的全流程所有权；以评估数据驱动；把交付经验沉淀为可复用资产；没有销售指标。
展开阅读：FDE 是什么 →领域型 FDE 是通用型 FDE 的低配版吗？
不是，它们是两种能力结构，不存在层级关系。通用型跨领域作战，靠问题发现、组织协调与系统工程能力；领域型在一个专业域里作战，靠领域知识、产品能力与专业方法。在金融数据安全、工业生产网变更这类高风险高专业场景中，领域型 FDE 承担的结果责任可能比通用型更重。
展开阅读：什么是领域型 FDE →不会写代码，能做 FDE 吗？
在边界清楚、结果可验证、风险可控的任务里可以。AI 已经能承担大量工程实现工作，但有三件事不会外包：问题由谁定义、边界由谁裁定、结果由谁认可。不写代码的人换了个位置——不再亲手砌每一块砖，而是负责图纸、边界、验收和最后的签字。
展开阅读：把 AI 当员工管 →