数据保护影响评估 (DPIA)
QR Branding API — AI 功能
| 项目 | 内容 |
|---|---|
| 日期 | 2026-03-08 |
| 数据控制者 | QR Branding (Quartzon) |
| 版本 | 1.0 |
| 状态 | 已批准 |
| 下次审查 | 2026-09-08 |
1. 处理活动描述
1.1 处理的性质
QR Branding 以两种模式提供 AI 驱动的二维码生成：
- 使用 QR Branding 自己的 LLM 提供商账户： qr-branding.com 上的 AI 设计器和市场托管端点（
POST /api/qr/ai/generate-managed）。由内部的提供商回退链（Groq、Google Gemini、OpenAI）处理每个请求。 - 使用客户自己的密钥（BYOK）： 市场端点
POST /api/qr/ai/generate。客户提供自己的 API 密钥并选择提供商（OpenAI、Anthropic、Google、Mistral、Cohere、Groq、xAI、DeepSeek 或 Qwen，或客户自己的 OpenAI 兼容端点）。
在两种模式下，用户都发送自然语言的设计提示词（例如“为科技公司设计的现代蓝色二维码”）以及二维码内容（URL、文本、vCard 等）。系统会：
- 仅将设计提示词和生成参数发送给外部 LLM 提供商：在 QR Branding 回退链中处理该请求的提供商，或用户选择的提供商（BYOK）。
- 从 LLM 接收 JSON 格式的设计配置。
- 使用提供的内容和建议的设计生成二维码。
- 将二维码图片返回给用户。
1.2 范围
- 处理的数据： 设计提示词（自由文本）、生成参数（风格预设、创意度、严格可扫描性）、二维码内容（URL、文本、vCard 联系信息、WiFi 凭据、地理位置）、客户的 API 密钥（仅限 BYOK，临时）。
- 估计量： 每个 IP 每分钟最多 15 次 AI 请求，全局每分钟 100 次生成。
- 受影响的数据主体： qr-branding.com 网站的用户、API 用户（开发者、企业），以及间接地，其数据出现在二维码内容中的人员（vCard 联系人）。
- 地理范围： 全球（RapidAPI Marketplace 上的公开 API）。
1.3 背景
- 无状态服务：没有数据库，二维码内容不会持久化。
- QR Branding 自己的账户（网站和托管端点）： QR Branding 持有自己在 Groq、Google（Gemini）和 OpenAI 处的 API 密钥，这些提供商作为其处理者，并列于子处理者页面。不会向它们发送电子邮件、账单数据、IP 地址或客户标识符。
- BYOK（Bring Your Own Key，自带密钥）模式（
POST /api/qr/ai/generate）： 客户在每次请求时提供自己的 API 密钥；对于这些请求，QR Branding 不使用自己的账户。 - 二维码内容绝不会发送给 AI 提供商，发送的只有设计提示词。
- LLM 生成的敏感字段（URL、base64）在渲染前会被置空。
- 服务运行在 Azure Functions（Consumption Plan）上。
- 在 BYOK 端点上，与 LLM 提供商的合同关系是客户与提供商之间的直接关系。
1.4 目的
让用户能够通过自然语言描述生成个性化的二维码设计，免去手动配置参数的需要。
2. 必要性与相称性
2.1 法律依据
履行合同（GDPR 第 6 条第 1 款 (b) 项）：该处理是提供用户所请求的具体服务所必需的。
2.2 数据最小化
| 原则 | 实现方式 |
|---|---|
| 仅限必要数据 | 只把提示词发送给 LLM，不发送二维码内容 |
| 不存储 | 在内存中处理；提示词文本和二维码内容在 HTTP 响应后丢弃。只有生成的设计配置可能被缓存最多 30 天，其键由提示词和参数的 SHA-256 哈希派生 |
| 不进行画像 | 不创建用户画像或请求历史 |
| 匿名化 | 日志中的 IP 地址经过匿名化（屏蔽最后一个八位组） |
| 隔离 | 在数据流中将二维码内容与 AI 提示词分开 |
2.3 相称性
该处理是相称的，因为：
- 用户主动选择使用 AI 功能（独立的端点）。
- 在 BYOK 端点上，用户自行选择 LLM 提供商；在网站和托管端点上，提供商是子处理者页面所列的处理者之一。
- 只传输设计提示词（不传输二维码内容中的个人数据）。
- 对于根据自然语言生成设计，不存在侵扰性更低的替代方案。
3. 风险识别与评估
3.1 已识别的风险
| # | 风险 | 可能性 | 影响 | 等级 | 缓解措施 |
|---|---|---|---|---|---|
| R1 | 提示词注入：用户在提示词中注入恶意指令 | 中 | 中 | 中 | <user_request> 分隔符、系统提示词中的防泄露指令、LLM 处理后将 URL/base64 字段置空 |
| R2 | 提示词中含 PII：用户在设计描述中包含个人数据 | 中 | 低 | 低 | 不存储提示词文本（缓存只保存以哈希派生的键存储的生成设计）；提示词在发送时不附带任何用户标识符；有书面的使用政策 |
| R3 | 系统提示词外泄：攻击者提取系统指令 | 低 | 低 | 低 | 系统提示词中的防泄露尾注、输出净化（移除 HTML 标签） |
| R4 | 国际传输：提示词被转发给欧洲经济区以外的提供商 | 中 | 低 | 低 | QR Branding 的账户：Groq、Google 和 OpenAI（美国）依据各提供商的数据处理条款作为处理者；只发送设计提示词和参数。BYOK：客户与提供商存在直接关系并有自己的 DPA；QR Branding 仅作为技术中介。在隐私政策和子处理者页面中披露 |
| R5 | LLM 提供商的保留：提供商根据自身政策保留数据 | 中 | 低 | 低 | QR Branding 的账户：受各提供商与 QR Branding 之间的数据处理条款约束。BYOK：依据客户与提供商之间的条款，由客户负责 |
| R6 | 含恶意内容的 LLM 响应：XSS、恶意 URL | 中 | 中 | 中 | 带超时的 HTML 净化正则、URL/base64 字段置空、反序列化时 MaxDepth=32 |
| R7 | 钱包耗尽攻击（Denial of wallet）：滥用 AI 端点推高成本 | 中 | 高 | 高 | 速率限制（每个 IP 每分钟 15 次 AI，全局每分钟 100 次）、带信号量的 RenderThrottle、functionTimeout 1:30 |
| R8 | API 密钥泄露到日志中 | 低 | 高 | 中 | SanitizeForLog() 对 API 密钥模式脱敏，错误消息不含 PII |
3.2 数据流图
User → qr-branding.com or RapidAPI Proxy → Azure Functions
↓
[Design prompt + parameters only]
↓
LLM provider (QR Branding's fallback chain,
or the user's choice on BYOK)
↓
[Design JSON config]
↓
QR Rendering (SkiaSharp)
+ QR content (never leaves the server)
↓
QR image → User
4. 缓解措施
4.1 已实施的技术措施
| 措施 | 缓解的风险 | 状态 |
|---|---|---|
提示词分隔符（<user_request>） | R1 | ✅ 已实施 |
| 系统提示词中的防泄露尾注 | R1、R3 | ✅ 已实施 |
| 将 LLM 返回的 URL/base64 字段置空 | R1、R6 | ✅ 已实施 |
| 带超时（3 秒）的 HTML 净化正则 | R6 | ✅ 已实施 |
| JsonSerializer 中 MaxDepth=32 | R6 | ✅ 已实施 |
| AI 速率限制（每个 IP 每分钟 15 次，全局每分钟 100 次） | R7 | ✅ 已实施 |
| RenderThrottle（信号量，并发 4） | R7 | ✅ 已实施 |
| functionTimeout 1:30 | R7 | ✅ 已实施 |
| SanitizeForLog()：API 密钥脱敏 | R8 | ✅ 已实施 |
| IP 匿名化（最后一个八位组） | R2 | ✅ 已实施 |
| 不含 PII 的错误消息 | R2 | ✅ 已实施 |
| 每次 LLM 调用设置输出 token 上限 | R7 | ✅ 已实施 |
| Content-Length + 读取后的大小检查（1MB） | R7 | ✅ 已实施 |
| 分离 Google 的 systemInstruction | R1 | ✅ 已实施 |
4.2 组织措施
| 措施 | 缓解的风险 | 状态 |
|---|---|---|
| 已发布的隐私政策 | R4、R5 | ✅ 已实施 |
| 在文档和子处理者页面中披露 LLM 提供商 | R4 | ✅ 已实施 |
| 与使用 QR Branding 账户的 LLM 提供商（Groq、Google、OpenAI）签订 DPA | R4、R5 | ⚠️ 待确认 |
| 与 BYOK 端点上的 LLM 提供商签订 DPA | R5 | 客户的责任 |
| 书面化的 DSR 处理程序 | 通用 | ✅ 已书面化 |
| 事件响应计划 | 通用 | ✅ 已书面化 |
5. 结论
5.1 剩余风险
在落实所有技术和组织措施后，剩余风险评估为低：
- 处理是无状态的：二维码内容和提示词文本都不会持久化（提示词缓存只保存以哈希派生的键存储的生成设计）。
- 二维码内容（可能较为敏感）绝不会离开 Azure 基础设施。
- 只有设计提示词（很少包含 PII）会传输给第三方。
- 大型审计中提出的所有技术缓解措施均已实施并验证。
5.2 决定
✅ 在现有措施下，可以开展该处理。
由于剩余风险较低，无需事先咨询监管机构（GDPR 第 36 条）。
5.3 审查
本 DPIA 将在以下情况下审查：
- 至少每 6 个月一次。
- 新增 LLM 提供商时。
- AI 端点的数据流发生变化时。
- 引入可能包含敏感数据的新型二维码内容时。
本文件生成于 2026-03-08。下次计划审查：2026-09-08。