GDPR Data Protection Impact Assessment (DPIA) guidance under Article 35 GDPR, EDPB Guidelines WP 248 rev.01, EDPB Opinion 28/2024 (AI), and national SA blacklists/whitelists. Triggers: "DPIA", "DSFA", "Datenschutz-Folgenabschätzung", "impact assessment", "Art. 35", "do I need a DPIA", descriptions of new high-risk processing (profiling, AI, biometrics, large-scale monitoring, special category data), Art. 36 prior consultation questions, national blacklist/whitelist queries.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Important: This skill provides structured GDPR Article 35 guidance based on EDPB Guidelines and national SA requirements. It is not legal advice. Involve your DPO (Art. 35(2)) and qualified counsel for final decisions.
Determine what the user needs and load references accordingly:
| User Need | Load These References | Action |
|---|---|---|
| "Do I need a DPIA?" / threshold question | references/edpb-criteria.md + relevant jurisdiction file(s) | Run threshold assessment |
| Full DPIA | edpb-criteria.md + jurisdiction(s) + references/risk-catalog.md + scoring.md | Walk through assessment phases |
| Document generation (.docx) — custom format | references/dpia-custom-population.md + references/templates.md + docx skill | Populate custom template .docx (unpack → fill tables → repack) |
| Document generation (.docx) — EDPB 2026 format | references/edpb-2026-population.md + references/edpb-2026-template.md + docx skill | Populate official EDPB template .docx (unpack → fill tables → repack) |
| Specific legal question | Load relevant reference only | Answer directly |
Jurisdiction selection: Ask two questions: (1) Where is the controller's main establishment? (2) Where are the data subjects located? Load all jurisdiction files that are relevant — this may be multiple files for multi-jurisdictional processing. See references/edpb-criteria.md → "Multi-Jurisdictional DPIA Analysis" for the full decision framework.
Available jurisdiction files:
references/jurisdictions/de-dsk.md — Germanyreferences/jurisdictions/fr-cnil.md — Francereferences/jurisdictions/ie-dpc.md — Irelandreferences/jurisdictions/be-apd.md — Belgiumreferences/jurisdictions/nl-ap.md — Netherlandsreferences/jurisdictions/it-garante.md — Italyreferences/jurisdictions/pl-uodo.md — Polandreferences/jurisdictions/whitelists.md — France, Czech Republic, Spain, AustriaFor jurisdictions not covered by a dedicated file, rely on the EDPB nine-criteria analysis in references/edpb-criteria.md and note that the user should check their national SA's Art. 35(4) list directly.
Threshold → Description → Asset Inventory → Necessity → Proportionality → Inherent Risks (Track A+B) → Mitigations → Residual Risk → Art. 36 Check → Documentation
This is the logical sequence, not a rigid script. Adapt to the user: if they provide rich context upfront, skip intake questions. If they're experienced, move faster. If they're new to DPIAs, explain more.
Asset Inventory (per EDPB Template 2026, Section 1.3): Collect risk-relevant assets — hardware, software, APIs/models, personnel, sites/premises, organisational assets. Group by logical module or technical layer. Include only assets whose compromise would plausibly impact data subjects' rights and freedoms.
Necessity and Proportionality are separate upstream gates (EDPB Template 2026, Section 3). Necessity: is the processing effective and least intrusive? Proportionality: do the benefits justify the impacts? These must be assessed before the risk mitigation phase.
Two risk tracks (per EDPB Template 2026): Track A identifies inherent-by-design risks (from processing working as intended). Track B identifies operational risks (from accidental/unlawful/abnormal events). Both are scored using the same L×S + modulating factors methodology in references/scoring.md.
The assessment is iterative: if mitigations in later stages change the processing design, revisit earlier analysis and flag this to the user.
These are areas where Claude's training knowledge may be imprecise. Always apply these rules:
Art. 35(3) triggers are absolute. If any of the three mandatory cases apply (systematic extensive automated evaluation with legal/significant effect; large-scale special category/criminal data; systematic monitoring of publicly accessible areas on large scale), a DPIA is required — no balancing, no judgment call.
The two-criteria rule is a presumption, not a mandate. Meeting 2+ of the 9 EDPB criteria creates a strong presumption a DPIA is needed. But a DPIA may be needed with only 1 criterion, and may be justified as unnecessary with 2 — if thoroughly documented. See WP 248 rev.01, p. 11.
Art. 9 is cumulative with Art. 6. Special category data always needs BOTH a legal basis under Art. 6 AND an exception under Art. 9(2). These are separate legal hurdles.
"Large scale" has no fixed number. The EDPB uses four factors: number of subjects, data volume, duration, geographic extent. An individual doctor is not large scale; a regional hospital is. Never cite a specific numerical threshold.
National blacklists are additive, not exhaustive. Processing not on a blacklist may still require a DPIA. A blacklist entry in the relevant jurisdiction overrides whitelist exemptions from other jurisdictions.
Multi-jurisdictional processing requires checking ALL relevant blacklists. Art. 35(4) lists are territorial — the DPIA obligation is triggered if the processing matches a blacklist in ANY jurisdiction where the controller is established OR where data subjects are located. The one-stop-shop mechanism (Art. 56) governs enforcement jurisdiction, but it does NOT limit which Art. 35(4) lists apply to the DPIA obligation itself. A single DPIA can address multiple jurisdictions, but the threshold analysis must run against each applicable national list. See references/edpb-criteria.md → "Multi-Jurisdictional DPIA Analysis" for details.
DPIA must happen before processing begins (Art. 35(1)). It is a pre-processing obligation, not a retroactive compliance exercise. If processing has already started, the DPIA should still be done but note this as a compliance gap.
AI requires dual-phase analysis (EDPB Opinion 28/2024). Training and deployment are separate processing activities with distinct risk profiles. A deployer cannot simply rely on the model provider's DPIA.
Art. 36 prior consultation is sequential to the DPIA, not part of it. The DPIA identifies residual risk; if that risk remains high after all feasible mitigations, Art. 36 requires consulting the SA before processing begins. The SA has 8 weeks (extendable by 6).
Pseudonymization as risk reducer (EDPB Guidelines 01/2025 on Pseudonymisation, adopted 17 January 2025): Effective pseudonymization with technically separated additional information can meaningfully reduce likelihood scores in risk assessment. But it must be genuine — if re-identification is trivial, it doesn't reduce risk.
Risk assessment is from the data subject's perspective. A DPIA assesses risks to rights and freedoms of natural persons (Recital 75), not corporate/business risks. Identity theft risk to the individual, not reputational risk to the company.
AI Act FRIA is distinct from DPIA. For high-risk AI systems under the AI Act, a Fundamental Rights Impact Assessment (FRIA) may also be required. DPIA (data protection risks) and FRIA (broader fundamental rights) are complementary — one does not replace the other.
EDPB DPIA Template (v1.0, March 2026) provides a harmonised EU-wide DPIA structure but does not mandate a specific risk scoring methodology. Controllers may use any established methodology (CNIL PIA, DSK SDM, etc.); the template records the minimum required information in a standardised format. National SA requirements and methodologies remain valid complements. Note: the template was adopted for public consultation — check for final version updates.
Threshold result: Present a clear verdict (DPIA Required / Recommended / Not Required) with the reasoning showing Art. 35(3) check, criteria analysis, and national list check.
Risk register: Table with Risk ID, Track (A/B), Description, Rights Category, Likelihood (1-5), Severity (1-5), Score, Modulating Factors, Adjusted Level. Use the scoring methodology in references/scoring.md.
Residual risk overview: Summary showing total risks by level before and after additional mitigation, plus overall verdict (APPROVED / CONDITIONALLY APPROVED / CONSULT SA / REJECTED).
Documents: Both formats use template population (unpack → fill → repack) for consistent styling. Read the docx skill first, then the relevant population guide:
references/edpb-2026-template-v1.docx using references/edpb-2026-population.md. Official format recognized by all EU SAs.references/dpia-custom-template-v1.docx using references/dpia-custom-population.md. Includes threshold analysis, jurisdictional blacklist detail, risk heat maps, and annexes.If the
.docxtemplate files are not present (some hosts, including lawve.ai, store text files only): build the Word document from scratch with the docx skill following the matching population guide — the population guides above fully specify every section, table, and field. The pre-styled.docxtemplates are available in the GitHub repo linked at the top of this skill if you want the exact corporate styling.
Ask the user which format they prefer.
This skill works standalone, but pairs well with my other EU data-protection skills — install any on its own or combine them:
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Creates an Agent Authority Charter for enterprise or regulated AI agents before deployment. Use this Skill when a user needs to define what an AI agent is allowed to do, who delegated authority to it, what actions are permitted or prohibited, when human approval is required, what evidence must be preserved, and how the agent can be suspended, revoked, or escalated.
日本語の概要は準備中です。原文の説明を表示しています。
EU AI Act Knowledge Engine — authoritative regulatory Q&A grounded in 70 official EU source documents (including the 2026 Commission draft guidelines on Art. 6 high-risk classification — general principles, Annex I, Annex III). Answers any question about the AI Act with article-level citations from the full regulation text, Commission guidelines, EDPB/EDPS opinions, codes of practice, harmonised standards, FRIA guides, incident templates, and sector-specific guidance. This skill should be used when the user asks about the "EU AI Act", "AI Act regulation", "Regulation 2024/1689", "KI-Verordnung", asks to "explain an AI Act article", "what does Article X say", "AI Act requirements", "AI Act penalties", "AI Act timeline", "GPAI obligations", "high-risk AI", "prohibited AI practices", "AI Act and GDPR", "fundamental rights impact assessment", "AI Act standards", "AI Act national implementation", "AI literacy", "serious incident reporting", "Digital Omnibus", "AI regulatory sandbox", or any question about EU artificial intelligence regulation. Also triggers on German terms: "KI-Gesetz", "KI-Verordnung", "Hochrisiko-KI", "KI-Kompetenz", "Grundrechte-Folgenabschaetzung", "GPAI-Verhaltenskodex". For assessment workflows that produce a classification decision rather than a knowledge answer, offer to run a structured risk-tier classification in-session.
日本語の概要は準備中です。原文の説明を表示しています。
This skill builds a structured audit trail of an AI-assisted task: what the tool was asked to do, what materials it was given, what it produced, how the output was verified, and what was ultimately relied upon. It documents the workflow for supervision and later review without ruling on privilege or disclosure, so the record stays accurate rather than self-serving.
日本語の概要は準備中です。原文の説明を表示しています。
Use this skill when the user wants an AI governance, legal-risk, privacy, compliance, procurement, or vendor-risk review of an internal AI use case, an AI product feature, an LLM workflow, or a third-party AI vendor. The skill asks intake and clarifying questions first when facts or evidence are missing, identifies required documentation and missing evidence, maps the use case to AI governance frameworks and applicable legal domains, and produces a preliminary or final governance review with scorecards, findings, owners, remediation actions, and follow-up questions.
日本語の概要は準備中です。原文の説明を表示しています。
Turn an interpretive-ambiguity audit of a legal text — contract, statute, regulation, or judicial opinion — into a polished deliverable. Produces a multi-page website (default), a single-page interactive site, a Microsoft Word document, a PowerPoint deck, or a LaTeX/PDF. Use whenever a user has a stress-test result, ambiguity audit, or "where will this be litigated" scenarios and wants to publish, present, or share them. Triggers on "publish the audit," "make a report from this," "turn this into a website / deck / brief / Word doc," "make a Netlify site," "build slides of these ambiguities," "render the scenarios," "package this stress test," "produce a LaTeX version," and similar. Pairs with the ambiguity-stress-test skill (the underlying analysis) but works on any structured or semi-structured ambiguity analysis. Visual design is opinionated but the user can override colors, fonts, and brand label. Most formats need Python and a writable filesystem; single-file HTML works where the host has neither.
日本語の概要は準備中です。原文の説明を表示しています。
Adversarially stress-tests a legal text — a contract, statute, regulation, or judicial opinion — for interpretive ambiguity: it finds the seams where the people governed by it will later disagree about what it means and turns each into a concrete dispute scenario with both sides' arguments, the likely outcome, and a fix. Use it whenever someone wants to pressure-test, red-team, audit, or find weak spots, loopholes, gaps, ambiguities, or drafting problems in a legal document; whenever a drafter wants to tighten a contract, statute, regulation, or opinion before it issues; whenever a litigator wants to mine an opinion or contract for arguments; or whenever someone hands over a legal text and asks where it will be fought over or for issue-spotting. Trigger it for contract review, statutory-ambiguity analysis, judicial-opinion scope analysis, and drafting QA — even if the user never says "stress-test" or "ambiguity."
日本語の概要は準備中です。原文の説明を表示しています。