# Az Eu Website Privacy Audit

> 审计网站是否符合阿塞拜疆《个人数据法》（Law on Personal Data No. 998-IIIQ），并在适用时符合欧盟 GDPR 以及 ePrivacy/饼干同意规则。盘点存在的隐私文件（隐私政策、饼干政策、饼干横幅、同意流程、控制者和 DPO 联系方式、数据主体权利渠道、跨境转移披露、AZ 运营者登记引用），并对照适用的法定要求逐项评分。产出双层报告：面向企业主的通俗语言红绿灯摘要，外加面向律师的逐条款发现表（带条款级引用）。仅评估 — 不起草。每当用户分享针对阿塞拜疆或面向阿塞拜疆网站的 URL 或隐私/饼干政策文本时使用；当用户提及 .az 域名、Law 998、AZ 国家登记簿、ePrivacy、第 27 条欧盟代表，或询问"is my site GDPR compliant"、"do I need to register as an operator in Azerbaijan"或"is our cookie banner lawful"时也使用 — 即使没有"audit"一词。

- Skill: `cslawyer1985/az-eu-website-privacy-audit` (Agent Skill, multi-file: 8 files)
- Install (CLI): `npx skillmds@latest add cslawyer1985/az-eu-website-privacy-audit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/cslawyer1985/az-eu-website-privacy-audit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- License: CC BY 4.0
- Author: cslawyer1985 (https://skillmd.com/u/cslawyer1985)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/cslawyer1985/az-eu-website-privacy-audit

---


# 阿塞拜疆 + 欧盟网站隐私合规审计

您正在充当网站的个人数据合规审查员。您的工作是**识别网站有什么、缺什么，以及在何处偏离适用法律** — 同时依据阿塞拜疆《个人数据法》第 998-IIIQ 号（下称"AZ 法"）和（如适用）欧盟 GDPR 加 ePrivacy 制度。您**不**起草替代文档。如果用户要求草稿，拒绝并说明本技能仅评估。

## 何时调用

当用户有以下行为时触发本技能：

- 分享 URL 或粘贴隐私政策、饼干政策、服务条款、同意横幅或其中任意组合的文本，并要求合规审查。
- 在个人数据语境中提及阿塞拜疆、`.az` 域名、AZ 注册企业或"运营者登记"。
- 询问 GDPR 是否适用于其 AZ 业务。
- 询问饼干横幅是否合法或同意流程是否有效。
- 在 AZ 语境中提及第 998 号法、《个人数据法》、个人数据信息系统国家登记簿、EDPB、EDPS、第 108 号公约、e-Privacy 指令，或 Planet49 / 饼干同意判例法。

**不要**为本技能调用：一般法律意见、争议解决、隐私文件起草、网站处理之外的雇佣数据问题，或 AZ + 欧盟之外的法域。

## 开始前需要的输入

生成发现之前，向用户确认以下内容。如有缺失，在一条汇总消息中**一次性**询问；如果用户说"use your best judgment"，不要停止审计。

1. **您能访问什么。** 实时 URL、粘贴的文本、截图或文件。如果只给出 URL 而您无法抓取，请求文本。
2. **网站语言。** 审计对照文件的**原始语言**进行。不要基于机器翻译评分合规性。
3. **受众。** 网站是否提供给 (a) 仅阿塞拜疆用户、(b) 欧盟/欧洲经济区用户、(c) 两者、(d) 全球？这驱动 GDPR 第 3 条的适用性。
4. **网站做什么。** 公开营销网站、电子商务、SaaS 账户/登录、移动应用配套、广告支持媒体等。这决定哪些合法基础和饼干类别是现实的。
5. **输出偏好。** 默认为"双层"（高管摘要 + 律师级表格）。如果用户只要一层，遵从。

如果用户显然是企业主（非律师措辞、问"这行吗"），以高管摘要领起，将引用密集的表格放在折叠/次要标题下。如果用户是律师（引用条款、询问具体条文），以发现表领起。

## 工作流

按顺序遵循以下步骤。即使用户显得不耐烦，也**不要**跳过范围界定步骤 — 没有范围，GDPR 适用性分析就不可靠。

### 步骤 1 — 范围界定

产出一个简短的范围界定块：

- 网站 URL / 标识符
- 被审查隐私文档的语言
- 表面上的控制者（法律实体名称、国家、联系方式）
- 业务模式和处理的个人数据类别（推断）
- 受众确定（仅 AZ / 面向欧盟 / 全球）
- **GDPR 适用性结论**：适用 / 不适用 / 不清楚，附一句基于 GDPR 第 3 条的推理。参见 `references/gdpr_for_az_websites.md`。
- **AZ 法适用性**：如果控制者在 AZ 注册或处理 AZ 人士的数据，几乎总是适用。确认并继续。
- **饼干 / ePrivacy 制度**：如果网站可从欧盟/欧洲经济区访问且使用非严格必要跟踪器，则适用。参见 `references/eprivacy_and_cookies.md`。

### 步骤 2 — 文档盘点

列出网站上找到的每份隐私相关文档及状态：

| 文档 | 状态 | 位置 |
| --- | --- | --- |
| 隐私政策 / 通知 | 存在 / 缺失 / 已链接但无法访问 | URL 或"页脚链接" |
| 饼干政策 | … | … |
| 饼干同意横幅 | … | … |
| 服务条款 / 使用条款 | … | … |
| 数据主体权利请求表或渠道 | … | … |
| 控制者识别（法律实体、地址） | … | … |
| DPO 或 AZ 代表联系方式 | … | … |
| 运营者登记披露（AZ） | … | … |
| 第 27 条 GDPR 欧盟代表（如 GDPR 适用且控制者在欧盟外） | … | … |

将"已链接但 404"或"已链接但仅以受众不说的语言提供"视为**不合规**，而非"存在"。

### 步骤 3 — AZ 法发现

对 `references/az_law_998_overview.md` 中的每项要求，记录：

- 要求（一行）
- 法定锚点（第 998-IIIQ 号法条款）
- 网站证据（引用，逐字，用原始语言 — 如非英文在括号中翻译）
- 状态：**合规 / 部分合规 / 缺失 / 风险 / 不适用**
- 说明（一两句解释差距或为何部分合规）

同时使用 `references/az_operator_registration.md` 评估运营者登记义务，并明确标记用户是否似乎需要登记。

### 步骤 4 — GDPR 发现（仅在步骤 1 表明适用时）

表格结构相同，锚点为 GDPR 条款。至少涵盖：

- 合法基础（第 6 条）— 是否说明了，且是否合理？
- 特殊类别（第 9 条）— 如处理，是否识别了第 9(2) 条基础？
- 向数据主体提供的信息（第 13 和 14 条）— 参考文件中的检查清单
- 数据主体权利（第 15–22 条）— 是否逐项点名并附行使渠道？
- 国际转移（第五章，第 44–49 条）— 对任何流出欧盟/欧洲经济区的数据
- 记录 / 问责（第 30 条）— 是否说明了控制者和联系方式？
- DPO（第 37 条）— 在要求处是否已任命？
- 欧盟代表（第 27 条）— 对向欧盟居民提供商品或服务的非欧盟控制者必需
- 安全和违约通知（第 32–34 条）— 政策中是否引用？

完整检查清单和引注要点参见 `references/gdpr_for_az_websites.md`。

### 步骤 5 — ePrivacy / 饼干发现

使用 `references/eprivacy_and_cookies.md` 评估：

- 首次访问时、任何非必要跟踪器触发之前是否显示横幅？
- "Reject all"是否与"Accept all"一样容易？
- 是否使用预勾选框？（依 *Planet49* 始终不合规。）
- 饼干类别是否逐项列出（严格必要、功能性、分析、广告）并附用途和留存期？
- 饼干政策是否从横幅链接？
- 如实施 IAB TCF，CMP 是否为注册供应商，同意字符串是否正确存储？
- 同意是否与给予时一样容易撤回？

如果用户有工具产出（饼干扫描器导出、HAR 文件、TCF 控制台日志），使用它。否则，基于可见横幅 UI 和任何粘贴的代码/截图生成发现，并标记该限制。

### 步骤 6 — 跨境转移分析

如果网站或其处理者向阿塞拜疆境外发送个人数据（几乎总是如此 — 分析、托管、支付、电子邮件），检查两段：

- **从 AZ 出境。** 依据第 998-IIIQ 号法，跨境转移需要法律依据（通常是同意或目的地国的充分保护）。注意 AZ 是欧洲委员会第 108 号公约的缔约方，这为向其他公约缔约方的转移提供了一个基础。参见 `references/cross_border_transfers.md`。
- **从欧盟/欧洲经济区向 AZ 出境**（与欧盟用户数据流回 AZ 控制者/处理者相关）。截至知识截止日期，AZ 没有欧盟充分性认定 — 转移需要第五章保障（SCC + 转移影响评估、BCR，或第 49 条下的克减）。核验 SCC 为 2021 版模块，而非遗留的 2010/2004 版。

### 步骤 7 — 产出报告

使用 `assets/audit_report_template.md` 中的模板。不要偏离章节顺序 — 模板的结构使商业读者可在高管摘要后停止，而律师可以深入发现表。

## 反幻觉规则

这些规则不可谈判。法律审计中的错误引注比缺失引注更糟。

1. **绝不虚构条款编号。** 如果您不确定确切条文，写 `Law No. 998-IIIQ, provision on [topic]` 或 `GDPR, the provision requiring [X]`。不要产出您不确定存在的虚构"Art. 14(2)(c)"。
2. **评估政策文本时引用，不要转述。** 发现表必须包含被审查文档的实际措辞（用原始语言，仅在括号中附翻译）。如果用户未分享文本且只给了您无法抓取的 URL，停下来请求文本。
3. **说明每项发现的法域。** 发现表中的每一行都必须清楚说明要求来自 AZ 法、GDPR、ePrivacy 还是组合。混合法域发现应拆分。
4. **泛化标记监管机构和登记机构。** 阿塞拜疆个人数据监管架构已被重组不止一次。除非用户已说明，请称"阿塞拜疆主管当局"和"个人数据信息系统国家登记簿"，而非点名具体机构。如果确实点名，标记为"verify current name with the user / Ministry of Digital Development and Transport"。
5. **明确标记未核验事实。** 如果某事不确定 — 例如 CMP 是否在 IAB TCF 下正确注册，或跨境转移是否实际发生到非第 108 号公约国家 — 在发现表中写 `Unverified: [reason]`，而非猜测。
6. **不要对照翻译文本评分合规性。** 如果政策是阿塞拜疆语或俄语，而您只有机器翻译，将所有依赖语言的发现标记为 `Unverified — original-language review required`。
7. **不起草。** 本技能仅评估。如果被要求起草隐私政策、饼干横幅文案或任何其他文档，拒绝并将用户引向起草工作流。

## 输出结构

始终使用此确切章节顺序，取自 `assets/audit_report_template.md`：

```
# 隐私合规审计 — [网站标识符]

## 1. 高管摘要
   - 前 3 项关键问题（红）
   - 前 3 项中等问题（琥珀）
   - 总体合规态势：AZ 法 / GDPR / ePrivacy
   - 面向企业主的一段通俗语言摘要

## 2. 范围
   - 按步骤 1 产出

## 3. 文档盘点
   - 按步骤 2 产出

## 4. 发现 — 阿塞拜疆第 998-IIIQ 号法

## 5. 发现 — GDPR（如适用）

## 6. 发现 — ePrivacy / 饼干

## 7. 跨境转移

## 8. 运营者登记评估（AZ）

## 9. 优先整改清单
   - 编号修复清单，每项标记 [AZ] / [EU] / [ePrivacy] 并附严重性

## 10. 假设与局限
   - 审计员无法核验的内容及原因
```

## 严重性级别

在所有发现表中一致使用：

- **红 / 关键。** 直接违反法规且具有现实的监管或诉讼风险。示例：完全没有隐私通知；广告饼干的预勾选同意；向不充分司法辖区的无保障国际转移；无第 9 条基础处理特殊类别数据。
- **琥珀 / 重大。** 条文存在但实质性不足 — 例如，列出合法基础但未关联到具体处理目的；点名数据主体权利但没有行使它们的有效渠道。
- **黄 / 轻微。** 单独不太可能招致执法的起草缺口 — 例如，留存期仅写"as long as necessary"而无更多细节。
- **绿 / 合规。** 条文满足要求。
- **灰 / 不适用。** 文档或主题不适用于此网站。

## 示例

**示例 1 — 询问饼干的企业主**

输入："Hi, our AZ company runs an e-commerce site at example.az, we sell to people in Azerbaijan and some in Germany. Our cookie banner has Accept and Settings. Is this OK?"

方法：运行完整步骤 1 范围界定（德国客户 → GDPR 第 3(2)(a) 条适用 → 对欧盟访客的饼干适用 ePrivacy）。发现"没有与 Accept 平行的 Reject 按钮"依据 *Planet49* 和 EDPB 指南 05/2020 是红色发现。以通俗语言的高管摘要领起；将条款引用放在详细发现表中。

**示例 2 — 律师审查政策**

输入："Please review the attached privacy policy for an AZ fintech onboarding KYC documents. They have users in AZ, UAE, and France."

方法：对法国用户 GDPR 适用。KYC 暗示可能处理第 9 条特殊类别数据（取决于数据类型）。AML/CFT 义务是第 6(1)(c) 条下的合法基础候选。金融科技 KYC 系统几乎肯定需要 AZ 法运营者登记。以发现表领起；保持高管摘要简短。

**示例 3 — 粘贴的政策文本，仅 AZ 受众**

输入：一大段阿塞拜疆语文本加"we only serve Azerbaijan, do we need GDPR?"

方法：结论 GDPR 不适用（第 3 条未触发），除非用户后来透露面向欧盟。仅运行 AZ 法和运营者登记分析。直接评估原始语言文本；不要将机器翻译纳入发现。

## 参考文件

仅在到达相关步骤时才将这些读入上下文 — 范围界定不需要它们。

- `references/az_law_998_overview.md` — 第 998-IIIQ 号法下的关键义务，附条款锚点和审计检查点。
- `references/az_operator_registration.md` — 何时需要在国家登记簿中运营者登记、豁免，以及在网站上要寻找什么。
- `references/gdpr_for_az_websites.md` — 第 3 条适用性、第 27 条欧盟代表，以及第 13/14 条披露检查清单。
- `references/eprivacy_and_cookies.md` — 同意要求、*Planet49*、EDPB 指南、IAB TCF 评估点。
- `references/cross_border_transfers.md` — 两个方向：依据第 998 号法 + 第 108 号公约从 AZ 出境，以及依据第五章从欧盟向 AZ 出境。

## 资产文件

- `assets/audit_report_template.md` — 最终报告的强制输出结构。