11.1
来源权威与知识状态分别表达
图谱中的知识不应只分为存在与不存在。可区分原始记录、模型观察、审核确认、存在争议和已撤回等状态，并保存状态变化的原因。来源权威也不是一个适用于所有问题的单值：制造商手册可能适合设备参数，维修记录更适合说明实际更换，用户评论则反映使用经历。评估来源时，应问它对哪一类陈述有资格提供证据，以及是否覆盖当前对象与时间。来源声誉不能替代陈述级核验，多个低质量转载也不等于多个独立确认。
溯源模型可以借鉴W3C PROV中实体、活动和责任主体之间的关系，用来表达数据如何被处理以及由谁产生。采用这种思路不意味着必须将整个标准一次性实现；最小系统也可以先记录资源、处理步骤和责任人，再逐步增加细节。[R28]关键是让派生知识具有可解释的历史，而不是只存最终属性。面对冲突时，系统应能展示不同来源及其适用范围，必要时请求人工裁决。治理的目标不是把不确定信息全部排除，而是让不同知识状态对检索、生成和用户判断产生明确影响。
11.2
权限必须沿派生链传播
图谱可能把原本分散的资料连接起来，产生比单份文档更敏感的信息。即使每条边本身不显眼，组合后也可能暴露人员关系、业务计划或未公开项目。因此权限检查不能只在下载文件时执行，而应覆盖节点、观察、路径、摘要和最终答案。最安全的设计起点是：检索只能看到当前用户有权使用的证据，派生对象的可见范围由其依赖来源共同决定。具体策略需要结合组织制度，不能靠一个统一公开标记解决。
社区摘要是容易忽视的环节。如果一个摘要混入受限来源，向无权限用户展示其概括仍可能泄露内容，哪怕原始引用被隐藏。可以按权限范围分区生成摘要，或在查询时使用经过权限过滤的证据重新概括，但两种方案各有成本。测试应采用成对用户：同一问题在不同权限下返回不同可用证据，同时都不能暗示隐藏资料的具体内容。权限变更后还要检查缓存与历史共享链接。治理评估不仅检查直接泄露，也检查关系组合产生的推断风险，并由了解业务的人员判断哪些关联需要限制展示。
本报告原创设计
11.3
检索内容是资料而不是执行指令
文档、网页和图片中的文字可能包含命令式内容，例如要求忽略规则、透露其他资料或执行外部操作。即使这些文字被检索到，也只是待分析材料，不会自动获得系统指令权限。多模态系统还可能从图片中的文字或隐藏版面中读到类似内容。应在架构中区分用户请求、应用规则和外部资料，并让生成器知道引用材料只能作为证据。抽取器也不能因为原文要求“新增某关系”就把它当作事实，而应判断该文本是在描述、引用还是发出指令。
防护需要覆盖工具调用边界。检索到的文档不能直接授权发邮件、修改数据库或下载执行文件；这些动作应由用户任务和应用权限决定。可把生成与执行分开，先形成可检查计划，再由受限接口处理已授权动作。测试材料应包含显式诱导、伪装成系统提示的段落以及图像内文字，并检查系统是否仍按原任务回答。日志中记录异常内容的位置有助于调查，但不要把敏感材料无控制地复制到更多日志。这个原则同样适用于研究写作：来源中的表达可以被总结和批判，不能代替用户对研究范围与交付的要求。
11.4
删除更正与可追踪的生命周期
知识图谱的删除不是移除一个文件名。原始资源可能已经产生文字片段、向量、实体观察、关系、社区报告和答案缓存。若不记录依赖，系统很难知道还剩哪些副本。建议以资源和观察标识建立派生清单，删除时先撤销可查询状态，再逐层清理，并形成完成记录。对于需要保留审计信息的场景，应由组织明确哪些最小元数据可以保留，避免技术团队自行把全部原始内容复制进所谓审计备份。这里讨论工程流程，不替代具体地区或机构的规则判断。
更正与删除也应区分。某条观察的取值被修正时，可能保留旧版本以解释历史答案，但当前查询必须使用有效版本；某份资源被撤回时，则不能继续让其派生摘要支撑新回答。用户界面可以显示更正日期与影响范围，让读者知道旧引用为何失效。测试时应在删除前后执行相同查询，并检查原文、图路径、向量召回和缓存答案是否都符合预期。若外部系统保留了副本，还要说明系统能够控制的边界。可靠生命周期管理的标准，是能证明信息如何进入和退出，而不是只声明支持删除。
11.5
人工审核关注高影响节点
所有知识都人工审核通常不可承担，完全自动处理又容易积累错误。可以按影响分配审核资源：被大量答案使用的观察、连接多个业务对象的实体合并、与现有记录冲突的更新以及决定用户行动的属性，应优先检查。影响不仅取决于图中心性，还取决于错误后果与使用频率。一条连接度很低的安全相关陈述，也可能比热门主题标签更值得审核。审核队列需要解释为什么这条记录被选中，以及审核者需要核对哪些证据。
审核界面应并排展示原文、图片区域、当前候选和历史变化，允许确认、拒绝、拆分实体或要求补充材料。不要只显示模型给出的置信分数，因为分数可能没有校准，也可能来自不同模型而不可比较。人工决定应成为新的审计记录，并与模型输出区分。对于重复出现的同类错误，可以修订规则或数据流程，而不是无限增加人工负担。审核质量也需要抽查，防止审核者因自动化建议而机械确认。有效的人机协作不是让人给每条输出盖章，而是让人在能够改变结果的关键节点上获得足够信息和实际修改权。
11.6
事故处理与责任归属可操作化
当系统给出错误或越权回答时，首先需要限制影响，再追查原因。可以暂停受影响索引或查询路径，保留必要的请求与版本记录，并通知负责数据与服务的人员。调查应沿证据链定位：源数据是否错误，观察是否抽取失真，实体是否误合并，权限是否遗漏，生成是否超出支持范围。不同原因需要不同修复，不能把所有事故都归结为语言模型幻觉。恢复服务前，应使用原始失败案例及邻近变体确认问题已经解决。
责任分工应在上线前确定。数据所有者负责来源与适用范围，知识维护者负责本体与合并规则，服务团队负责检索、权限和可用性，业务负责人决定哪些回答可以影响行动。用户纠错与申诉也需要明确入口。事故报告可以记录影响、根因、修复、验证和防复发措施，并将敏感细节限制在必要范围。衡量成熟度时，不只看从未出错的宣传，而应看发现速度、修复速度与复发控制。图谱的可追踪性在这里产生实际价值：它能把一段错误答案拆解成可负责、可修改的环节，并帮助组织用证据改进流程。