AI合规自查中的数据治理实操建议

很多人一提 AI 合规自查，脑子里先蹦出来的是模型效果、禁止用途、人工监督这些“大词”。我自己做排查时却越来越清楚：真正容易在日常里翻车、又最能靠实操兜住的，往往是数据治理。功能可以先关掉，文档可以后补，但数据从哪来、怎么用、出事能不能说清楚，拖久了只会越拖越贵。

别把“有数据”当成“治理过了”

我以前也犯过同样的错：一听“训练数据够不够”，就去数体量。后来才发现，合规要问的根本不是“多不多”，而是来源清不清楚、用途明不明确、处理有没有按必要性和最小化来。里面一旦夹着个人信息或受保护内容，你还得说得出处理依据和控制措施——说不出，审查时就很难站得住。

实操上，我会逼自己先回答三件事：模型是用什么数据和流程训出来的，相关信息能不能落成可持续更新的技术文档；数据来源、授权、个人数据处理和版权风险有没有过审查；发布之后，重要变更、风险事件和处置结果有没有人记、记在哪。答不上来的，就先别急着谈“效果好不好”。

产品侧和运营侧要一起动手

光靠法务写一页说明没用。我更倾向两边同步改：产品侧尽量保留数据来源标签、模型版本标识和发布审批记录，让“用了哪一版、依据什么数据”能顺着链路找回去；运营侧则把数据问题、版权投诉、个人信息请求和安全事件收成处理台账，别散落在聊天记录里。

如果模型是外部调用的，更不能只记接口调用次数。供应商给的技术资料、使用限制和风险说明要对一遍，否则产品同学连实际跑的是哪个版本、什么配置都说不清，后面复盘会特别被动。对外提供模型能力时，也要提前划清：哪些信息由模型提供方负责，哪些义务会因为下游具体用途转到部署者或使用者身上——这层边界不写清楚，出事时最容易互相推。

日志要有用，而不是堆得越全越好

数据治理里还有一块常被误解：日志。真正有用的日志，是能支撑事件复盘、责任划分和用户申诉的那一类——谁在什么时间调用了哪项功能、用了哪个模型或版本、输入输出有没有经人工修改、最终谁拍板、异常后怎么处置。别为了“留痕”无限制收集无关个人信息，也别忽略访问权限、保存期限和安全控制；堆调用次数看起来很勤奋，审查时往往帮不上忙。

资源紧的时候，我会按风险顺序用力：先卡住可能涉及禁止用途和高风险自动决策的数据与动作，再补通用模型的文档、来源说明和透明度。数据治理不是上线前盖个章，而是让系统始终能解释“从哪来、怎么变、出了事怎么查”。把这条链路接牢，比多写一段免责声明踏实得多，后续整改压力也会小一截。