Privacy Notice Eu

Pan-EU GDPR Privacy Notice Generator

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

Who this is for, and what kind of work this is

Operator. This skill is written for a privacy practitioner — an in-house data protection lead or DPO, or the privacy/commercial lawyer supporting them. It can be run by a non-lawyer (a founder or ops owner drafting a first notice), but then the output must be routed to qualified counsel before publication, not published on the skill's say-so. No special AI fluency is assumed beyond answering the intake questions in plain language.

Work shape. The work is bounded and document-centric: a single privacy notice assembled from a fixed template, the loaded jurisdiction reference, and the controller's intake — pattern-matched against the Art. 13/14 disclosure checklist, not open-ended advisory. The skill stays conservative inside that pattern and hands anything outside it back to counsel (see Confidence and what gets handed back below).

Status of the output. The notice itself is a client-facing document; the gap findings and assumptions this skill surfaces alongside it (e.g. "no DPA on file for processor X") are candid drafting observations — not legal advice, and not in themselves a privileged work product. Treat their storage and sharing per your firm's work-product and privilege policy.

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

Confidence and what gets handed back

A finished, formatted .docx reads as authoritative — which is the risk: a reviewing lawyer is tempted to ratify it rather than re-examine it. So the skill must make its own certainty visible and must NOT smooth contested points into confident prose. Tag every non-trivial legal position the notice relies on:

• Settled — directly supported by a cited GDPR article, the loaded jurisdiction reference, or an in-force national provision → render it normally.
• Assumed — rests on an intake answer the skill cannot verify (e.g. "marketing runs on consent") or on a default the user did not explicitly confirm → render it, but list it in the delivery summary's Assumptions block so the reviewer can check it.
• Contested / uncertain — the position is genuinely unsettled, falls outside the loaded references, or turns on facts the skill does not have → do NOT pick an authoritative-sounding answer. Leave a visible, highlighted drafting flag in the .docx ([TO CONFIRM WITH COUNSEL: …]) and call it out in the summary. Hand it back; do not bury it in fluent prose.

Confidence travels with the document: the delivery summary (Step 5) carries the Assumptions and Contested/Open-items lists explicitly, not just the chat.

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).

Covered jurisdictions = the loaded reference files only. The skill has playbooks for DE, FR, AT, IT, ES, NL, BE, IE, and UK. If the target market is any other country (e.g. PL, SE, DK, or a non-EEA jurisdiction), do NOT silently draft to generic "GDPR defaults" — that hides the national specifics (supervisory authority, employment-data rules, marketing law, age thresholds) the notice actually needs. Instead STOP and tell the user the jurisdiction is outside the loaded playbooks: draft only the EU-baseline sections you can support, mark the national-law layer as an open item, and route it to local counsel. Name the gap; do not paper over it.

Bundled legal data is point-in-time — re-verify, don't trust. The article references, adequacy / EU–US Data Privacy Framework participant lists, retention defaults, and children's-consent age thresholds in the reference files were current when written and drift over time. Treat them as a starting point to confirm against the live source, not as standing authority. Flag any reliance on a possibly-stale value in the delivery summary and tag it Assumed per Confidence and what gets handed back.

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_COMMON.md for guidance.

Present as a table for the user to confirm:

| Purpose | Legal Basis | Data Categories | |---|---|---| | Service provision / contract execution | Art. 6(1)(b) | [to fill] | | Account management | Art. 6(1)(b) | [to fill] | | Legal/tax compliance | Art. 6(1)(c) — [specific law] | [to fill] | | Analytics | Art. 6(1)(f) or consent | [to fill] | | Marketing / newsletter | Art. 6(1)(a) consent | [to fill] | | AI-based processing | [determine per use case] | [to fill] |

Group D — Recipients & Transfers

• Hosting provider + location
• Payment processor
• Analytics tools
• Email/marketing tools
• CRM / support tools
• AI/ML service providers (e.g., OpenAI, Google AI, Anthropic)
• Any other processors
• Transfers outside EU/EEA → which countries, which mechanism (adequacy, SCCs, DPF, BCRs)

DPA / Art. 28 Cross-Reference — For each processor identified:

• Verify a Data Processing Agreement (Art. 28 GDPR) is in place. If not, flag as a compliance gap requiring remediation before the notice is finalized.
• What to disclose in the notice: processor name (or category), purpose, location, transfer mechanism. Do NOT include DPA terms, sub-processor lists, or TOMs in the privacy notice — these belong in the Art. 28 agreement.
• What NOT to disclose: specific technical/organizational measures (Art. 32), sub-processor chains, pricing, SLA details.
• If the user confirms no DPA exists for a processor: note this in the summary and recommend immediate remediation. The privacy notice should still name the processor/category but add a note that the controller is in the process of formalizing the agreement.
• Joint controllership (Art. 26): if applicable, the arrangement's essence must be disclosed in the notice, including respective responsibilities and the contact point for data subjects.

Group E — Cookies & Tracking

• Cookie categories used (essential, analytics, marketing, social)
• Specific tools (Google Analytics, Meta Pixel, Matomo, HubSpot, etc.)
• CMP solution (Usercentrics, Cookiebot, Axeptio, Didomi, Borlabs, etc.)
• Server-side tracking? Fingerprinting?
• Cookie lifespans

Group F — AI & Automated Processing

If the service uses AI/ML:

• What AI systems are used and for what purpose?
• Are decisions solely automated or human-in-the-loop?
• Do decisions produce legal or similarly significant effects (Art. 22)?
• Is user data used for model training?
• AI Act classification: prohibited / high-risk / limited-risk / minimal-risk?

Group G — DPIA Indicators (Art. 35 GDPR)

Check whether a Data Protection Impact Assessment may be required. If 2 or more of the following indicators apply, inform the user and recommend a DPIA as a separate deliverable:

1. Systematic evaluation/scoring of individuals (profiling, credit scoring, performance reviews)
2. Automated decision-making with legal or similarly significant effects (Art. 22)
3. Systematic monitoring of a publicly accessible area (CCTV, Wi-Fi tracking)
4. Special category data or criminal offence data processed at scale (Art. 9/10)
5. Large-scale processing of personal data (high volume, broad geographic scope, many data subjects)
6. Matching or combining datasets from different sources in ways data subjects would not reasonably expect
7. Vulnerable data subjects (employees, children, patients, elderly)
8. Innovative use of technology (biometrics, AI/ML, IoT, blockchain for personal data)

If 2+ indicators are flagged:

• Inform the user: "Based on the processing activities described, a Data Protection Impact Assessment (DPIA) under Art. 35 GDPR appears to be required."
• Explain the notice implications: the privacy notice should reference that a DPIA has been conducted (without disclosing the DPIA content itself)
• Recommend: "A DPIA is a separate compliance exercise and should be conducted before the processing begins. This privacy notice skill can draft the notice, but the DPIA should be prepared as a standalone document."
• Check national mandatory DPIA lists (DE: DSK-Liste; FR: CNIL list of processing operations requiring DPIA)

Summary Before Drafting

After collection, produce a structured summary for user confirmation:

NOTICE TYPE: [Website / Applic

…

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [LegalQuants](https://github.com/LegalQuants)
- **Source:** [LegalQuants/lq-skills](https://github.com/LegalQuants/lq-skills)
- **License:** Apache-2.0

Install and usage instructions live in the source repository linked above.