监管方问 AI 团队最常见的一句话是：“这批数据你当时是怎么拿到的？”多数人能答上来“用户同意了”，却答不上“用户同意的是哪一件事”。
一句话定义：目的限制（Purpose Limitation）是一条数据处理原则——个人信息只能用于收集时明确说明的那个目的，想挪作他用，就得重新过一遍合法性。
打个比方：你把身份证复印件交给中介办租房备案，他知道这是办备案用的。如果他转头拿这份复印件去办贷款、开电话卡，哪怕他一张都没外传、全程锁在抽屉里，也越界了。同意是有边界的，边界就是目的。
这条原则通常拆成三层要求：收集时的目的要特定（specified）、明确（explicit）、合法；后续使用要与原始目的相容（compatible）；不相容的二次使用（secondary use）必须另找合法性基础、重新评估。判断“相容”不能只看字面像不像，还要看几件事：新用途和原用途的关联度、用户当初的合理预期、新用途对个人的影响大小，以及你有没有加额外的保护措施。
AI 场景里最典型的冲突就是客服对话。用户授权你把对话用来“处理本次投诉、改进服务质量”，他的合理预期是“我的问题被解决掉”。但拿这批对话去训练一个通用客服模型，尤其模型可能服务其他企业的客户，用户大概率没预料到——这在很多法域里就是典型的超出目的范围，需要重新取得同意、做充分去标识化，或者走匿名化后再利用的路径。具体口径以各地官方法律文本和监管指引为准。
和相邻概念的区别，一张表就够：
| 概念 | 管的是什么 | 大白话 |
|---|---|---|
| 目的限制 Purpose Limitation | 用途的范围 | 说好干这个，就别顺手干那个 |
| 数据最小化 Data Minimisation | 数据的多少 | 够用就行，别多收 |
| 告知同意 Informed Consent | 拿到数据那一刻的授权 | 说清楚，才同意 |
| 去标识化 De-identification | 数据的形态 | 削弱可识别性，但未必不再是个人信息 |
对从业者的实际意义：把“数据用途”当成产品需求一样管起来。三件事最实用：一是做数据流台账，写清每份数据从哪来、原始目的是什么、眼下被谁用在什么项目上；二是新模型立项先问一句“这批数据的原始目的能覆盖吗”，覆盖不了就先停下来找合法性基础，别训完再说；三是合同和界面文案别写“用于改进服务”这种大范围概括表述，看着省事，其实是把风险推到后面爆。
对普通人来说，授权时多看一眼“用途”那一栏不是多余动作。你有权知道自己的数据会被用在哪，也可以对明显超出预期的用途说不。