技能 产品商业 全球合规隐私政策生成器

全球合规隐私政策生成器

v20260804
privacy-policy-stephane-boghossian
一款零幻觉、全球合规的隐私政策生成工具。它能引导非法律背景的创始人,根据用户所在地和业务性质,生成符合GDPR、CCPA、LGPD等全球主要法规的隐私政策。核心在于准确性,确保每一条款都基于实际操作和确认的法律要求,帮助企业规避法律风险。
获取技能
249 次下载
概览

Privacy Policy Generator

Generate a bulletproof, jurisdiction-aware privacy policy for any business or product, usable by a non-lawyer founder and trusted by a lawyer. The whole point of this skill is correctness without hallucination: a fabricated statutory citation or a clause that doesn't match the user's real practices is worse than no policy at all.

⚖️ The prime directive (read this first, never break it)

  1. State ONLY what the user confirms they actually do. A privacy policy is a set of enforceable representations (FTC §5; see the OkCupid/Match 2026 and Gateway Learning cases in the reference pack). Saying more than is true is the #1 legal failure. Never default-in a flattering or risk-adding clause.
  2. Never invent law. Do not generate a statute/section number, a fine amount, an effective date, or a "the law requires X" claim unless it traces to the bundled reference pack (references/) or a live legal-data-hunter lookup. If you're unsure of a specific, name the law in plain terms ("California's CCPA/CPRA," "the EU GDPR") and describe the right functionally — or omit it. Uncertain → omit or mark [VERIFY], never guess.
  3. Confirm-don't-assume. A clause renders only if a confirming intake answer exists. Smart defaults are allowed ONLY for protective/negative clauses (no children, no selling, standard security framing, today's date, strictest-common-denominator). Anything unanswered → a visible [GAP — confirm before publishing] marker, never a guess.
  4. This is not legal advice. Always include the disclaimer; INSIST on a lawyer for high-risk cases (§ workflow step 6).

Workflow

Step 1 — Pick the mode

Ask (or infer): QUICK (non-lawyer: only the must-ask questions, batched, smart defaults pre-filled, ~10 answers) or EXPERT (lawyer/thorough: full questions, clause-level control, citations, full reconciliation). → Read references/intake-questionnaire.md for both flows.

Step 2 — Compute the applicable-law set FIRST (jurisdiction-first)

Ask intake Groups 0–2 (product type → business identity → where users are located). Location is the law-selector. If "international / unknown," apply the strictest-common-denominator (GDPR + CCPA + COPPA). This ordering is what prevents generic boilerplate.

Step 3 — Gather practices (only the questions the selected laws require)

Work Groups 3–17 of references/intake-questionnaire.md. Batch questions; offer the smart default so the user can accept with "yes." Flag every HARD-risk answer (children, health, biometric, AI-training, data broker, fintech) as you go.

Step 4 — Ground the legal content (zero-hallucination layer)

For each jurisdiction/topic in scope, pull the requirements from the matching reference file — never from memory:

  • references/jurisdictions-eu-uk.md — GDPR Art 13/14 checklist, lawful bases, rights, transfers, cookies, UK/DUAA, children ages, enforcement.
  • references/jurisdictions-us.md — CCPA/CPRA contents + the two mandatory links + Notice at Collection, ~20 state laws, COPPA, GPC, ADMT, sector overlays, FTC §5.
  • references/jurisdictions-global-mena.md — Brazil, Canada/Quebec, Australia, India, China, Japan/Korea/SA/Switzerland + UAE/DIFC/ADGM/Saudi/Bahrain/Qatar/Egypt/Turkey + cross-jurisdiction synthesis.
  • references/platform-cookies-ai.md — when a policy is contractually forced; Apple/Google app-store rules; per-tool disclosures (GA, AdSense, Meta Pixel, Stripe, PayPal, Mailchimp, Cloudflare, session-recording, A/B); cookies/CMP/TCF/GPC/Consent-Mode; AI/LLM + EU AI Act Art 50 + ADM.
  • references/sector-and-special-products.md — HIPAA/HBNR/MHMDA, GLBA, FERPA/SOPIPA, BIPA/Texas CUBI, Chrome extensions, IoT SB-327, GDPR Art 32/33/34 security/breach + US breach laws.
  • Optional live grounding: if the legal-data-hunter MCP is connected (HAQQ's 230-jurisdiction tool), use it to verify or fetch a jurisdiction-specific requirement with an inline citation — especially for a jurisdiction not fully covered in the pack, or for the latest amendment. If it's not connected, rely on the pack and clearly mark anything you couldn't verify.

Step 5 — Assemble the policy

Use the section order + modular clause library in references/structure-clauses-and-craft.md and the fill-in backbone in assets/template-privacy-policy.md. Enforce the writing craft (≈8th-grade reading level unless EXPERT/formal, ~20 words/sentence, active voice, tables for data×purpose×basis×retention, layered TL;DR). Use the DO phrasing; never the banned phrasing. Render jurisdiction-specific sections (e.g., "Your California rights" with the Do-Not-Sell-or-Share + Limit-Use-of-Sensitive-PI links) only for selected laws.

Step 6 — Self-QA gate (do NOT skip)

Run the 12-point checklist in references/edge-cases-failure-modes-qa.md §3 on your own draft. In particular:

  • Citation firewall: scan for any statute number / fine amount / effective date; each must trace to the pack or a live lookup, else remove or genericize. Zero invented citations. If cite-guard is available, run it here.
  • Practice match: every clause traces to a confirmed answer; surface any remaining [GAP].
  • Mandatory links / disclaimer / lawyer-flag present as triggered. Do not present the policy as "ready" if any check fails — present it with the failures surfaced.

Step 7 — Deliver the package

Output: the policy (in the requested language(s), RTL-aware for Arabic per structure-clauses-and-craft.md §7) · a dated version header + "changes" clause · the conditional-links status · the practices-confirmed vs clauses-generated reconciliation (the key anti-deception artifact) · the [GAP] list · the risk-tier / "get a lawyer" banner. Default output format: Markdown (offer HTML on request). Recommend human review of any machine translation.

Hard rules (guardrails)

  • Never claim the user honors GPC / DNT, encrypts data, has a DPO, or retains data for N days unless the user confirmed it — these are enforceable and false ones are deceptive.
  • Never fold employee/HR data into a consumer policy — recommend a separate notice.
  • Never present this as legal advice. INSIST on a lawyer (HARD banner) for: under-13/children, health/PHI, biometric, fintech/payments beyond a standard processor, selling data / data broker, AI training on user data, large-scale/systematic monitoring, precise geolocation at scale, or simultaneous EU+UK+US+other coverage.
  • Keep the policy in sync with reality: never output "please check this page periodically for changes" as the only update mechanism — it is "insufficient and unfair" (WP260). Use a dated change log + active material-change notice.

Companion documents

A privacy policy is necessary but not sufficient. Where relevant, tell the user they may also need: a Cookie Policy + consent banner, a DPA (Art 28) for processors, a RoPA (Art 30), a HIPAA Notice of Privacy Practices (health), a GLBA notice (finance), and a separate employee privacy notice. This skill drafts the privacy policy (and an embedded cookie section / standalone cookie policy on request); it flags the others rather than silently omitting them.


Built from primary-source research (regulator texts, statutes, and official platform terms) verified 2026-06. Sources are cited inside each references/ file. AGPL-3.0. Informational template — not legal advice.

信息
Category 产品商业
Name privacy-policy-stephane-boghossian
版本 v20260804
大小 52.53KB
更新时间 2026-09-06
语言