成人 AI 图像的同意、年龄与合规

关于成人图像功能的每一次严肃讨论，最后都会落到同一个地方，而那不是模型。是同意与合规：图中人是否成年、是否同意，以及你能否证明这两点。支付机构会问，应用商店会问，监管机构问得越来越多。答不上来的功能会在上线后被下架，而那是代价最高的时刻。

真正重要的两个问题

第一：被描绘的人是否是同意此事的成年人？第二：正在使用你产品的人是否成年？这是两个独立的问题，需要两套独立的控制手段，把它们混为一谈是这一领域最常见的设计错误。对访问者做年龄校验，丝毫说明不了照片里那个人的情况。

同意必须被采集，而不是被假定

服务条款里的一句话不构成同意采集。真正站得住脚的，是逐次请求的明示确认：上传者拥有该图像的权利，且被描绘者是同意此事的成年人——它按具体任务记录、带时间戳，缺失时由 API 直接拒绝。

最后那一点才让它变成真实的而非装饰性的。如果没有确认的请求在 API 边界就被拒绝，那么系统里每一个被处理过的任务，从构造上就必然携带一份确认。你不必再指望自己的客户端代码问过这个问题。

面向用户的年龄核验

这方面的要求变化很快，且各法域分化明显。英国《在线安全法》、德国的青少年保护制度，以及越来越多的美国州法，都对提供成人内容的服务施加了义务，其中若干已不再接受用户自行勾选的声明。

落到实处是架构问题：把年龄核验放在一个可以随时加强、又不必重写产品的接口之后。今天是自我声明，明天如果市场要求，就换成证件核验或年龄推断服务商。把一个勾选框硬编码进十几个模板的团队，会为这个决定付两次账。

明确写出禁止用途

有两条禁令没有商量余地，必须同时写进条款、界面和执行环节：任何形式、任何借口下都不得涉及未成年人；未经本人同意不得处理真实、可识别人物的图像。第二条正是正当成人产品与骚扰工具之间的分界线，而针对非自愿私密影像的专门立法也在不断增加。

该留什么，不该留什么

这里存在真实的张力。调查滥用需要记录，而隐私与数据保护法要求最小留存。解法是把证据和内容分开：保留能证明流程的元数据——确认在何时、由哪个账号给出——而图像本身，交付所需之外一秒都不多留。

• 保留：任务 ID、账号、时间戳、同意确认、所用预设。
• 不保留：源照片和结果，除交付所需的短暂窗口之外。
• 记录对上述数据的访问日志，因为没人能查阅的审计记录不叫审计记录。

内容审核是产品决策，不是事后补丁

在上线之前就决定出事时会发生什么：举报如何送达真人、多快能封停一个账号、凌晨两点谁来拍板。一条确实存在且确实有人响应的举报通道，在实践中也正是「留得住支付机构」和「丢掉支付机构」的平台之间的区别。

把顺序排对

在 API 边界强制同意确认，把年龄核验放在可替换的接口之后，明示并执行禁止用途，图像最小留存而证明材料长期留存，再加一条能触达真人的举报通道。这些都不是什么高深工程，它就是功能能上线和被下架之间的差别。

常见问题