3、数据源识别与分类：企业内部数据源、外部数据源、数据分类分级标准
做AI审计，第一步不是看模型，而是看数据从哪来。
我见过太多团队，模型调得漂漂亮亮，一查数据源全是坑。数据源搞不清楚，后面所有审计工作都是空中楼阁。说白了，你得先知道你的数据是亲生的还是领养的，才能决定怎么管它。
3.1 企业内部数据源
企业内部数据，就是你自己家产的数据。我习惯把它们分成三类：数据库、日志、API。这三类数据，审计重点完全不同。
3.1.1 数据库
这是最传统的数据源。关系型数据库（MySQL、PostgreSQL）、NoSQL（MongoDB、Redis）、数据仓库（ClickHouse、Snowflake），都在这个范畴。
审计数据库时，我重点关注三个问题：
- 数据血缘：这张表的数据从哪来？ETL过程有没有丢失？
- 权限控制：谁有读权限？谁有写权限？有没有幽灵账号？
- 数据质量：空值率、异常值、重复记录，这些指标必须跑一遍。
3.1.2 日志
日志数据，很多人不把它当回事。其实日志是AI审计的宝藏。
为什么？因为日志记录了真实行为。用户点击、系统报错、接口调用，全在日志里。这些数据没法造假，是审计交叉验证的最佳材料。
我建议审计日志时，重点看这几类：
- 访问日志：谁在什么时候调用了什么接口？频率是否异常？
- 操作日志：管理员有没有批量导出数据？有没有非工作时间操作？
- 错误日志：模型推理失败率是多少？失败原因分布如何？
3.1.3 API
现在很多系统都是微服务架构，数据通过API流转。API数据源审计，核心是接口契约和调用链路。
我个人习惯用这几种方式审计API数据源：
- 抓取API文档（Swagger/OpenAPI），比对实际返回字段是否一致
- 检查API鉴权方式，是不是所有接口都加了认证
- 看限流策略，有没有防止数据爬取的机制
举个例子，我之前审计一个推荐系统，发现他们的用户画像API返回了手机号字段。但API文档里根本没写这个字段。一问才知道，是开发为了方便调试加上的，上线后忘了删。你想想看，这要是被爬了，后果多严重。
3.2 外部数据源
外部数据源，说白了就是别人的数据。你用别人的数据训练模型，合规风险比内部数据高得多。
3.2.1 第三方API
很多AI系统会调用第三方API获取数据，比如天气数据、地图数据、征信数据。审计这类数据源，我重点关注：
- 数据授权范围：你买的API套餐，允许你用这些数据训练模型吗？很多合同里写明了「仅限查询，不得存储和训练」。
- 数据时效性：第三方API的数据更新频率是多少？你拿到的数据是不是已经过时了？
- 数据脱敏责任：如果你把用户数据传给第三方API做处理，谁负责脱敏？
关键问题： 调用第三方API时，你的数据会不会被对方留存？我见过一个案例，某公司用第三方API做人脸识别，结果对方把上传的人脸照片都存下来了，用于训练自己的模型。这算不算数据泄露？算。
3.2.2 公开数据集
公开数据集，比如ImageNet、COCO、Wikipedia dump，看起来人畜无害。但审计时你会发现，问题也不少。
我总结了几条公开数据集的审计要点：
| 审计项 | 常见问题 | 我的建议 |
|---|---|---|
| 许可证合规 | 用了CC BY-NC的数据集做商业模型 | 先看License，别想当然 |
| 数据偏见 | 人脸数据集以白人为主 | 统计分布，确认代表性 |
| 隐私泄露 | 数据集中包含可识别个人信息 | 做一轮PII扫描 |
| 数据时效 | 2015年的数据集用在2024年的场景 | 确认数据采集时间 |
3.3 数据分类分级标准
数据源识别完了，下一步就是分类分级。为什么？因为不同级别的数据，审计要求和管控措施完全不同。
我常用的分类分级框架是这样的：
3.3.1 数据分类
按业务属性分，比如：
- 用户数据：姓名、手机号、地址、设备ID
- 业务数据：订单、交易记录、库存
- 技术数据：日志、监控指标、配置信息
- 衍生数据：模型特征、用户画像、推荐结果
3.3.2 数据分级
按敏感程度分，我建议至少分四级：
| 级别 | 定义 | 示例 | 审计要求 |
|---|---|---|---|
| L1 公开 | 可对外公开 | 产品名称、公开报告 | 无特殊要求 |
| L2 内部 | 仅限内部使用 | 内部文档、非敏感报表 | 访问控制、操作审计 |
| L3 敏感 | 泄露有负面影响 | 用户手机号、交易记录 | 加密存储、脱敏展示、严格权限 |
| L4 高度敏感 | 泄露后果严重 | 身份证、银行卡、医疗记录 | 加密传输、审计日志、专人管理 |
3.3.3 分类分级的落地方法
我个人习惯用标签化的方式来做。每张表、每个字段都打上分类和分级的标签。比如：
-- 字段级别标签示例
字段：user_phone
分类：用户数据
分级：L3 敏感
脱敏规则：中间4位掩码
保留期限：业务结束后90天
字段：order_amount
分类：业务数据
分级：L2 内部
脱敏规则：无需脱敏
保留期限：7年（财务要求）这样做的好处是，审计时可以直接扫描元数据，快速定位高风险字段。我之前的项目里，就是用这套标签体系，自动生成了数据资产地图，审计效率提升了至少一倍。
3.4 小结
数据源识别与分类，是AI审计的基石。你想想看，如果连数据从哪来、是什么级别都搞不清楚，后面的数据质量审计、模型公平性审计，根本无从谈起。
我的建议是：
- 先盘点所有数据源，内部外部都要覆盖
- 对每个数据源做合规检查，特别是外部数据源
- 建立分类分级标准，并且落地到元数据管理
- 定期复查，数据源和分级不是一成不变的
嗯，这一章就到这里。下一章我们聊聊数据质量审计，那才是真正考验功夫的地方。