← AI学习中心 / 企业知识库
怎样排除不应进入通用知识库的敏感字段
文中企业场景、人物与业务数字为教学示例，不是客户成果记录。
直答：资料入库前先对照一张“默认排除字段”清单逐份检查，证件号、银行卡号、完整住址、电话、账号凭据这类字段默认不入通用库：或遮蔽、或删除、或移入单独限权分区，通用库里只留“此处原有该信息”的标记。
业务场景（合成演示）：一家40人的物流公司准备把历史工单整理进知识库。工单里夹着收件人完整地址和电话，如果整篇直接入库，等于把这些信息摊给所有能查库的人；整理同事问“哪些算敏感”，才发现公司从来没有一张成文的清单。
具体做法： 1. 由业务负责人和资料维护负责人一起起草默认排除字段清单，并经法务或信息安全岗位按个人信息保护相关法规与公司制度审核后执行；本文清单仅作演示起点。 2. 每份资料入库前对照清单过一遍，命中字段按约定处理：删除、遮蔽或移入限权分区。 3. 遮蔽用统一格式，例如写“电话：已隐去”，让后来的人知道此处曾有信息、不是漏录。 4. 确有业务需要保留完整字段的，移入单独分区并收窄可查范围，通用库不放原文。 5. 每季度抽一批已入库资料复查，看有没有漏网字段；发现漏网的按同一条清单补处理并登记。
示例表（合成演示，字段与处理均为虚构）：
| 字段类型 | 处理方式 | 入库后样式 | 原件去向 |
|---|---|---|---|
| 收件人完整地址 | 遮蔽至城市级 | “收件地：已隐至市” | 原单留档 |
| 收件人电话 | 整体删除 | “电话：已隐去” | 原单留档 |
| 常见异常件处理经验 | 保留原文 | 原文保留 | 直接入库 |
空模板：
| 字段类型 | 处理方式 | 入库后样式 | 原件去向 |
|---|---|---|---|
反例（合成演示）：另一家公司只在口头交代“注意别放敏感信息”，没有字段清单。整理同事各自理解，有人把一张含银行卡号的说明整页扫进了库，事后既说不清还有哪些资料带着类似字段，也说不清该按什么标准补查。没有清单，“注意”两个字等于没有规则。
常见问题：
问：排除清单由谁定、放哪里？ 答：由业务负责人与资料维护负责人共同起草、法务或信息安全岗位审核，清单本身也存进资料库并按变更记录留痕，改了什么、谁确认的可查。
问：历史资料太多，来不及逐份清理怎么办？ 答：按资料类型排优先级：客户原始单据先清，内部经验总结后清；未清完的类型暂不入库，不边入边清。
讨论：如果明天有人拿到你知识库的全部查询权限，哪一类字段是你最不希望他看到的？
来源与边界：本文方法为编辑设计；“把散在各处的资料统一整理并分拣归类”的思路受The Den项目文章（https://openai.com/index/the-den-family-social/）的启发，不引用其任何效果数字；本文字段清单与处理流程为原创设计，示例均为合成演示，本文不声称与任何厂商存在合作或真实成果。