gdpr-privacy-notice-eu-oliver-schmidt-prietz

What this skill does

# Pan-EU GDPR Privacy Notice Generator

Generate jurisdiction-aware, GDPR-compliant privacy notices as professional .docx documents.

## Workflow Overview

```
1. SCOPE    → Notice type, jurisdiction(s), template choice
2. INTAKE   → Type-driven collection: controller info, data inventory, legal bases
3. DRAFT    → Generate notice from template + type profile + collected info
4. VERIFY   → Art. 13/14 compliance check + type-specific checks + AI Act check
5. DELIVER  → .docx output via docx skill
```

## Step 1: Scope, Notice Type & Template Selection

### Determine Notice Type (FIRST QUESTION)

Before anything else, determine what type of privacy notice is needed. Load `references/NOTICE_TYPES.md` and ask:

> "What type of privacy notice do you need?"

| Type | Description |
|---|---|
| **Website / App** | For visitors, users, subscribers of a website, web app, or mobile app |
| **Applicant / Recruiting** | For job applicants and candidates (Bewerber, candidats) |
| **Employee** | For employees, contractors, interns (Beschäftigte, salariés) |
| **Business Partner (B2B)** | For contact persons at vendors, suppliers, clients, partners |
| **B2C Customer** | For end consumers in a customer/purchase relationship |
| **Combined** | Multiple audiences in one or several linked notices |

The selected type determines:
- Which sections to include/skip in the final document
- Which data categories to probe during intake
- Which legal bases are most likely
- Which type-specific intake questions to ask
- Which retention defaults apply

Refer to `references/NOTICE_TYPES.md` for the full **section map**, **data profile**, **legal bases**, **intake questions**, and **retention defaults** for each type.

### Determine Jurisdiction

Ask which countries/markets the service targets. Load the appropriate reference:

| Target Market | Reference File |
|---|---|
| Germany / DACH | `references/DE.md` |
| France | `references/FR.md` |
| Other EU (AT, IT, ES, NL, BE, IE, UK) | `references/OTHER_EU.md` |
| Always load | `references/EU_COMMON.md` |

For multi-jurisdiction services, load all relevant files and note where requirements differ (e.g., children's age thresholds, DPO thresholds, retention rules).

### Template Selection

Ask the user:

> "I will draft the privacy notice as a professional .docx document. Do you have an existing template or privacy notice I should use as a base? If not, I will use one of our pre-built templates."

| Option | Action |
|---|---|
| User provides template | Use their .docx as base — preserve structure, wording, and formatting; only fill/adapt |
| No user template | Generate from `references/templates.md` using the docx skill |

`references/templates.md` includes: 13-section structure, Art. 21 objection box (visually highlighted), purposes/retention table, cookie table, AI/automated decision-making section, children's data section, proper header/footer with page numbers, A4 formatting, TOC, and full translations for DE, FR, and EN. Select the language matching the target jurisdiction.

**If user provides a template**: faithfully preserve its structure and validated wording. Only replace placeholders and adapt to the specific case. Do NOT rewrite validated legal language.

### Multi-Language Decision Tree

If the service targets multiple jurisdictions or language groups, determine the language approach:

| Scenario | Approach |
|---|---|
| **Single market, single language** | One notice in the market's language (e.g., DE only → German) |
| **Single market, international workforce/users** | Primary language + English version. State which version governs in case of conflict. |
| **Two markets, two languages** | Option A: Two separate notices (one per language), each self-contained. Option B: Bilingual notice with clear visual separation (e.g., side-by-side columns or sequential sections). |
| **Pan-EU / many markets** | English as primary + translations for key markets. Each translation should be a standalone notice, not a partial translation. |
| **Swiss company (nDSG + GDPR)** | Address both the Swiss nFADP (new Federal Act on Data Protection) and GDPR. Typical approach: single notice referencing both regimes, in at least German + French (+ Italian if applicable). Note: nFADP has no consent requirement for general processing but requires information duties similar to Art. 13/14 GDPR. |

**Template handling for bilingual documents**:
- Use the primary-language template as the structural base
- Ensure both language versions contain all mandatory disclosures (a translation gap = a compliance gap)
- Mark the governing language version explicitly (e.g., "In case of discrepancies, the [German/French] version shall prevail.")

**Multi-language verification checklist** (add to Step 4 if applicable):
- [ ] All mandatory Art. 13/14 disclosures present in each language version
- [ ] Governing version clearly identified
- [ ] Legal terminology correctly translated (not machine-translated without review)
- [ ] Supervisory authority information correct for each jurisdiction
- [ ] Jurisdiction-specific requirements addressed in the relevant language version

### Platform Sub-Type (Website/App type only)

If the notice type is **Website / App**, further classify the platform to anticipate data categories. See `references/NOTICE_TYPES.md` → "Website / App" → "Sub-Types & Data Profiles" for details.

| Sub-Type | Typical Additional Data |
|---|---|
| Brochure/corporate site | Contact forms, analytics, cookies only |
| E-commerce | Account, payment, order history, shipping, returns |
| SaaS / Web app | Account, usage data, feature logs, API keys, collaboration data |
| Mobile app | Device ID, push tokens, permissions (camera, location, contacts), app usage |
| Marketplace | Dual roles (buyers/sellers), ratings, messaging, payment escrow |
| Platform with AI features | Training data, AI inputs/outputs, model decisions, profiling |

## Step 2: Information Intake

Collect ALL information before drafting. Use the **type profile** from `references/NOTICE_TYPES.md` to guide the intake — each type pre-defines likely data categories, legal bases, and type-specific questions.

Ask in logical groups, not all at once. Start with Group A (always), then use the type profile to determine which categories to probe and which type-specific questions to ask.

### Group A — Controller Identity
- Company name, legal form, registration number
- Registered address
- Legal representative (name + title)
- Contact email + phone
- DPO appointed? → Contact details (use functional email)

### Group B — Data Inventory
For each collection point (forms, account creation, purchase, cookies, app usage):
- What data is collected?
- Is it mandatory or optional?
- What is the source (direct from user, third party, automated)?

Categories to probe:
- **Identity**: name, email, phone, address, date of birth, photo
- **Account**: credentials, preferences, settings, activity history
- **Technical**: IP, device ID, browser fingerprint, logs
- **Browsing**: pages visited, clicks, session duration, referrer
- **Transaction**: orders, payment method (via provider), invoices
- **Communication**: messages, support tickets, comments
- **Special categories** (Art. 9): health, biometric, political, religious, sexual orientation, ethnic origin, trade union, genetic — **If any Art. 9 data is identified**: consult `EU_COMMON.md` → "Special Category Data (Art. 9)" for the full intake protocol. Determine the Art. 9(2) exception for each category, confirm the dual legal basis (Art. 6 + Art. 9(2)), and document additional safeguards. Common triggers by notice type: Employee (church tax, disability, sick leave, union dues), Applicant (disability, health, religion), B2C (health data for pharmacy/insurance/fitness).
- **AI-related**: inputs to AI systems, AI-generated outputs, automated scores/decisions

### Group C — Purposes & Legal Bases
For each processing activity, determine the legal basis. Reference `EU_COMM