跳到正文
AppFoyer
免费开始

指南 隐私政策

把用户数据发送给 AI API——Google Play 的要求

在应用中加入一个 LLM 调用,就是一项数据共享决定,Play 的 User Data 政策对此有明确说明。需要披露什么、在哪里披露,以及应用内披露必须是什么样子。

Google Play 的 User Data 政策适用于第三方 AI 集成,披露和征得同意的责任仍在你身上。如果你的应用把用户内容发送给 AI API,这就是与第三方共享数据:在隐私政策中写明对方,在 Data safety 表单中声明,并在发生之前显示醒目的应用内披露。

1:18
1:18 视频 · 在 YouTube 上打开

几分钟就能搞定

AppFoyer 托管本指南所讲的页面——隐私政策、服务条款、支持、账号删除和 app-ads.txt——放在它们自己的子域名上,你无需自己的域名或服务器。一个应用免费,而且商店要求的任何内容都绝不放在付费墙后面。

核查于 2026年9月19日。 商店政策会变,有时不会事先通知。下文所有内容都链接到官方文档,以那个页面为准,而不是本页。如果两者不一致,以商店为准。 本指南译自英文;引用的商店文档保留英文原文。

加一个“总结这段内容”“就你的笔记提问”或“生成配文”的功能,只需要三行网络请求代码,这恰恰是它通常完全绕过合规讨论的原因。从商店的角度看,你刚刚开始把用户的内容发送给一家他们从未听说过的公司。

Google Play 在其 User Data 政策中消除了这一模糊地带:“These requirements also apply to third-party AI integrations (such as products, services, code) and you remain responsible for ensuring compliance with this policy, including limited use, disclosure and consent.”(译:这些要求同样适用于第三方 AI 集成(例如产品、服务、代码),你仍有责任确保遵守本政策,包括有限使用、披露和征得同意。)

这里并没有什么专门针对 AI 的制度。它就是普通的数据共享规则,只是写得让谁都无法争辩说 API 调用是另一回事。

什么情况算数

只要用户数据离开设备并到达模型提供方,就算数——无论你是直接调用,还是通过某个封装库调用:

  • 包含用户输入、口述、拍摄或上传的任何内容的提示词;
  • 发送去处理的文档、图片和音频;
  • 附加在请求上的账号或设备标识符;
  • 你存储并重新发送的对话历史。

一个从不向服务器发送任何内容的端侧模型是另一种情况。如果你不确定自己用的是哪一种,请阅读 SDK 的文档,而不是凭假设——好几个“端侧”库都会回退到服务器调用。

必须出现的三个地方

1. 你的隐私政策。Play 要求隐私政策连同任何应用内披露,“comprehensively disclose how your app accesses, collects, uses, and shares user data”(译:全面披露你的应用如何访问、收集、使用和共享用户数据)。写出提供方的名称,说明发送了什么、用于什么、保留多久。“我们可能会使用第三方服务来改善你的体验”不是披露;它是一种回避披露的方式。

2. 你的 Data safety 表单。把用户内容发送给外部 API 就是与第三方共享,而这个表单问的正是这一点。Google Play 对两者之间出现差异的立场很明确:“When Google becomes aware of a discrepancy between your app behavior and your declaration, we may take appropriate action, including enforcement action.”(译:当 Google 发现你的应用行为与你的声明不一致时,我们可能会采取适当措施,包括执法措施。)流向某个你的表单没有提到的 AI 端点的流量,正是这种不一致。

3. 在发生之前显示应用内披露。这是开发者最常跳过的要求,因为它是唯一需要做 UI 的一项。Play 对它的规定很具体:披露 “must be within the app itself, not only in the app description or on a website”(译:必须在应用内部,而不能只在应用描述或网站上),并且 “must be displayed in the normal usage of the app and not require the user to navigate into a menu or settings”(译:必须在应用的正常使用过程中显示,而不能要求用户进入菜单或设置才能看到)。在需要征得同意的情况下,对话框必须 “clear and unambiguous”(译:清晰明确),并且需要 “affirmative user action (for example, tap to accept, tick a check-box)“(译:用户的主动操作(例如点按接受、勾选复选框))。

设置页面里一个指向隐私政策的链接不是应用内披露。在用户首次使用该功能的界面上、在第一次请求之前出现的一句话,才是。

上线该功能之前要回答的问题

  • 提示词里到底有什么?开发者经常惊讶于自己的代码附带了多少上下文。
  • 提供方会用它来训练吗?同一个 API 的消费者版和企业版在这一点上常常不同,而这是你的政策要作为事实陈述的内容。
  • 提供方保留多久?写出具体期限,或者说明你无法控制。
  • 用户能避开这个功能吗?一个悄悄发送所有内容的功能,比一个由用户主动开启的功能更难解释。
  • 未成年人怎么办?如果你的应用会被儿童使用,这就是该停下来寻求专业意见的时候。

在功能上线之前,把这些问题的答案写下来。每一个答案都是政策中的一句话;如果你回答不了,你就无法诚实地写出这份政策。

如果你的应用还会生成内容

与数据共享不同,Play 的政策也涉及 AI 生成的内容——为其添加标识,以及防止应用生成被禁止的内容。这是一个内容政策问题,而不是隐私问题,在上线前值得直接阅读当前的政策原文;我们没有在这里总结它,因为它经常变动。

AppFoyer 在这里做什么

我们根据你构建文件中实际存在的内容起草隐私政策,因此你依赖列表中的 AI SDK 会作为一个具名的第三方出现,而不是被悄悄漏掉。在第三方那一节还是占位符的时候,检查清单会一直标记这个页面。

我们做不了的是应用内披露——那是你应用里的一个界面,而政策明确指出网站无法替代它。和往常一样,这些模板只是起点,不是法律建议。凡是涉及未成年人或敏感数据的情况,都值得花一小时咨询律师。

权威来源