name: pianeta-web-compliance description: Decisione meccanismo + cost/margin + roadmap compliance dei SITI CLIENTE generati dal Pianeta Web · layer distinto da Iubenda-Multiverbe-proprio last_update: 2026-06-03 owner: gregorio + claude status: meccanismo = proprietario (già canon 02-product.md r.41) · gate residuo = revisione legale CH · fondamenta in build

Pianeta Web · Compliance siti cliente

SSoT della decisione "come ogni sito pubblicato esce a norma, a nome del cliente". Correlati: sub-processors.md · skill multiverbe-ch-compliance · pianeta-web-quality-stack-spec.md · canon 02-product.md § Pianeta Web.

0. TL;DR (decisione)

Ci sono due layer di compliance distinti, spesso confusi. Tenerli separati è tutta la partita:

Layer	Chi è titolare	Chi è responsabile (processor)	Copertura
A · Multiverbe-proprio — landing `multiverbe.com` + app `multiverbe.app`	Multiverbe	i sub-processor di Multiverbe (Supabase, Anthropic, Stripe, …)	Iubenda — Essentials su landing + Advanced su app · ACQUISTATI 2026-06-03 ✅
B · Siti cliente — `*.multiverbe.app` generati dal Pianeta Web	il cliente PMI (titolare dei SUOI visitatori)	Multiverbe (hosting/generazione) + Vercel/Supabase	DA COSTRUIRE — ogni sito esce con privacy+cookie policy + banner a nome del cliente

Meccanismo Layer B — già scelto dal canon (02-product.md r.41: «il cliente non usa Iubenda a parte»), qui motivato coi numeri:

Ibrido a tendenza proprietaria. Iubenda solo per il Layer A (fatto, ~€300/anno, trascurabile). Per il Layer B: generatore proprio + Klaro/CookieBanner (già in codice) + template legali multilingua rivisti UNA VOLTA da legale CH. Motivo sotto, coi numeri. La macchina è già ~80% in codice; il costo marginale per sito ≈ €0 (vs €60-240/sito/anno di affitto Iubenda) preserva il GM ~94% e rende "incluso e a norma" una leva di vendita vera invece di una perdita margine 2-6%.

La DPA Multiverbe→cliente (Layer A→cliente) e l'endpoint /legal/subprocessors servono comunque, qualunque meccanismo si scelga per il Layer B → si possono costruire subito senza pre-decidere nulla.

1. Perché due layer (il modello mentale)

Quando una PMI pubblica un sito con Multiverbe, nascono due rapporti di data protection sovrapposti:

[Visitatore del sito del ristorante]
        │  (dati: IP, cookie, form contatti)
        ▼
[Ristorante = TITOLARE]  ──DPA──►  [Multiverbe = PROCESSOR]  ──sub-DPA──►  [Vercel, Supabase, Iubenda banner]
        │
        │ (il ristorante è anche CLIENTE di Multiverbe SaaS)
        ▼
[Multiverbe = PROCESSOR del ristorante]  ──sub-DPA──►  [Anthropic, Stripe, Brevo, Mistral, …]

Layer A copre il rapporto Multiverbe↔suoi-clienti-PMI e le superfici di Multiverbe. Iubenda 92115618 (Essentials, landing) + nuovo progetto multiverbe.app (Advanced) coprono questo. ✅
Layer B copre il rapporto cliente-PMI↔suoi-visitatori, sul sito generato. Qui Multiverbe NON può usare la propria Iubenda: il titolare è il cliente, la policy va a NOME del cliente, i sub-processor da disclosare sono quelli che toccano IL SITO (Vercel hosting, Supabase contenuti, banner consenso, + eventuali analytics che il cliente attiva), non l'intero stack AI di Multiverbe.

Conseguenza pratica: il sito generato deve uscire con la SUA privacy policy + cookie policy + banner consenso, sector-aware, multilingua IT/DE/FR/EN, intestata al cliente. Questo era già flaggato BLOCCANTE GDPR/LPD nel Business_Eye legacy.

2. Decisione meccanismo Layer B · i numeri

Tre opzioni (dal brief):

(a) Iubenda agency/API per-sito

Prezzo reale verificato 2026-06-03 dal dashboard: Essentials €4,99/sito/mese (annuale, €59,88/anno) · Advanced €19,99 · Ultimate €79,99. IVA esclusa.
Un cliente PMI = tipicamente 1 sito. Quindi €59,88/sito/anno minimo (Essentials).
Impatto margine (sui tier mensili Multiverbe CHF 79/149/249 ≈ €82/155/259):

Clienti	Costo Iubenda Essentials/anno	Note
5	€300	gate 10 Giu
60	€3.593	fine 2026 plausibile
600	€35.928	scala 2027
10.000	€598.800	north-star quality-stack-spec

Su un cliente Starter: €4,99 / €82 = ~6,1% del ricavo mensile solo per il banner. Su Pro ~3,2%, su Business ~1,9%.
Anche con sconto partner/agency (stima €1,5-2/sito a volume) → a 10.000 clienti restano €180-240k/anno di affitto puro pass-through per una feature table-stakes.
Pro: Iubenda tiene i template aggiornati, offload parziale della responsabilità legale.
Contro: affitto ricorrente per-sito su una feature che il codice fa già da solo; erode il GM ~94% target.

(b) Generatore proprio + Klaro (free)

Klaro = open source (BSD), già integrato nel dashboard (src/lib/klaro-config.ts). I siti cliente hanno già un CookieBanner proprio (sites-runtime/components/Compliance/CookieBanner.tsx).
Le costituzioni di settore dichiarano già le pagine legali (legal-privacy, legal-cookies, legal-impressum) con path localizzati IT /privacy · DE /datenschutz · FR /protection-donnees + hardConstraints.legallyRequired. Manca solo la generazione del contenuto.
Costo marginale per sito ≈ €0 (compute generazione, già dentro il cost cap; consent log su Supabase, già pagato).
Costo una-tantum: revisione del template base da legale CH (skill decision-tree: privacy/cookie/ToS standard PMI = "skill + SaaS coprono 95%", lawyer ~CHF 1-3k per la base, riutilizzabile su tutti i 10k siti).
Pro: zero affitto, margine intatto, controllo pieno, "incluso e a norma" diventa leva di vendita reale.
Contro: Multiverbe possiede la responsabilità della correttezza del template (mitigata da revisione legale CH una-tantum + pattern skill multiverbe-ch-compliance).

(c) Ibrido (Klaro + testi template con base rivista da legale CH) ← RACCOMANDATO

= (b) per il Layer B + Iubenda solo per il Layer A (fatto).
Il problema "privacy policy di un sito vetrina PMI" è bounded e templatizzabile: copre hosting (Vercel), form contatti (Supabase), cookie/banner, eventuale Google Analytics/Maps. Non è l'intero stack AI di Multiverbe.
La sola spesa reale del proprietario è la revisione legale una-tantum della base; finché non atterra, si shippa la macchina dietro flag col template marcato "legal review pending" (non si pubblica testo legale vivo su siti cliente reali senza ok founder/legale).

Verdetto

(c) Ibrido a tendenza proprietaria. Il calcolo è netto: a regime, (a) costa €180-600k/anno di affitto per qualcosa che (b)/(c) fanno a costo marginale zero, su una macchina già ~80% scritta. Iubenda resta dove ha senso (le 2 superfici proprie di Multiverbe, alto valore/basso volume). Per i siti cliente, possedere il layer di compliance è la mossa big-tech: bounded, high-volume, già in codice.

Il canon ha già deciso (c). canon/02-product.md r.41: «Generatore del banner cookie e della privacy policy — conformità integrata: il cliente non usa Iubenda a parte» + satellite #10 «Conformità e fiducia» (CH+EU, Impressum, privacy auto). Quindi "Iubenda anche per i siti cliente" (a) contraddirebbe il canon: questa analisi lo conferma coi numeri. Unico gate residuo: la revisione legale CH del template base (§8.2). Macchina e template li preparo identici fino al bivio di pubblicazione.

Costo per cliente + quando pagare Iubenda per-sito (risposta founder 2026-06-03)

Quanto sarebbe in più, per cliente, con Iubenda per-sito:

Iubenda Essentials = €4,99/sito/mese = ~€60/cliente/anno (CHF ~58, IVA esclusa · B2B CH→IT spesso 0% per export di servizio).
In % del ricavo mensile del tier: ~6% Starter (CHF 79) · ~3% Pro (149) · ~2% Business (249).

Alternativa proprietaria (canon): ~€0 marginale per cliente. Unico costo = revisione legale CH del template base una-tantum (CHF 1-3k), riusabile su TUTTI i siti → a 60 clienti ≈ €30/cliente una-tantum, a 600 ≈ €3, a 10k ≈ €0,20.

Break-even (anno 1): Iubenda (60 × N clienti) vs revisione legale (~CHF 2k). 60 × N = 2.000 → N ≈ 33 clienti.

Sotto ~33 clienti nel primo anno: Iubenda è perfino più economico (eviti la spesa legale one-off).
Sopra ~33, e strutturalmente a scala: vince il proprietario, e il divario esplode (600 clienti → Iubenda €36k/anno ricorrente vs ~€0).

Quando ha senso pagarlo: solo come ponte temporaneo per i primissimi clienti (es. i 5 del gate) SE devono pubblicare PRIMA che la revisione legale del template proprietario sia pronta. Ponte per 5 clienti ≈ €300/anno. Appena la revisione legale atterra — o si superano ~30 clienti — si passa al proprietario.

Regola operativa: default = proprietario (canon r.41). Iubenda per-sito = stopgap accettabile solo se (clienti < ~30) E (serve pubblicare prima della revisione legale). Oltre, è solo margine bruciato.

2.ter Decisioni founder 2026-06-03 — lifecycle cost-control + Klaro/Iubenda

(1) Provisioning compliance legato all'abbonamento attivo (paghi solo per cliente attivo, revoca su mancato pagamento). Qualunque costo di compliance per-sito (Iubenda per-site OPPURE risorse del generatore proprio) si sostiene solo finché il cliente è subscriber attivo pagante. Alla cessazione del pagamento (churn / dunning fallito): il sito cliente va de-provisionato (unpublish → sites.status ≠ published, banner/policy revocati) e ogni costo per-sito cessa.

Ancoraggio codice: stato Stripe (subscriptions / workspaces.stripe_subscription_id) → su past_due/canceled un job de-provisiona i siti del workspace (riusa dunning Stripe · skill multiverbe-stripe-checkout-edges + flusso publish/unpublish in api/site/publish.ts).
Sicurezza: la revoca dev'essere reale e idempotente (il sito smette davvero di essere servito da sites-runtime, non solo un flag), nessun residuo che continui a costare o a esporre dati dei visitatori. Grace period dunning prima dell'unpublish (no taglio brutale a chi ha un ritardo di pagamento).
Se un domani si usasse Iubenda per-site, attivazione/disattivazione del progetto Iubenda va legata allo stesso ciclo (no progetti Iubenda paganti per clienti churned). Col proprietario il costo è ~0 → il rischio residuo è solo "servire un sito di un non-pagante", chiuso dallo stesso unpublish.

(2) Ridondanza Klaro vs Iubenda → regola: prima il meglio per gli utenti, poi il più economico.

App multiverbe.app: banner = Klaro (già in codice, free/open-source, consent log su Supabase, un solo banner coerente col design system). Iubenda Advanced app = solo policy/cookie-policy/ToS/ROPA/DSR (testi + tool), NON la Cookie Solution/banner → evita il doppio banner in conflitto. Klaro vince su entrambi i criteri (meglio per utenti: un banner solo; più economico: free).
Landing multiverbe.com: verificare se ha già un banner nel codice; in assenza lean Klaro per coerenza. La Cookie Solution Iubenda è inclusa in Essentials ma un doppio stack non è "meglio per gli utenti". Decidere a verifica codice landing.
Siti cliente (Layer B): già proprietario (CookieBanner/Klaro) → coerente con questa regola.

3. Stato attuale in codice (ground truth verificato 2026-06-03)

Due app, due stack (vedi pianeta-web-quality-stack-spec.md § Stack reale):

frontend/multiverbe-app/ — Vite 5 + React 19, serverless api/ flat (Vercel ESM NodeNext, import relativi con .js).
sites-runtime/ — Next.js 16, siti generati *.multiverbe.app.

Pezzo	Dove	Stato
Klaro (consenso dashboard Multiverbe)	`multiverbe-app/src/lib/klaro-config.ts`	✅ completo · 5 lingue · 9 app · sync `legal_acceptances`
CookieBanner siti cliente	`sites-runtime/components/Compliance/CookieBanner.tsx`	⚠️ MVP IT-only · localStorage `mv-site-consent` · essential+analytics · montato in `app/layout.tsx`
Pagine legali siti cliente	costituzioni `src/lib/site-design/constitutions/*.ts` (`legal-privacy/cookies/impressum`, path IT/DE/FR/EN)	⚠️ dichiarate, contenuto non generato
Rotte `/legal/{privacy,cookie,tos,dpa,subprocessors}`	env `VITE_LEGAL_*_URL` in `klaro-config.ts`	❌ referenziate, non implementate (placeholder)
Tabella consenso versionato	DB `legal_acceptances` (`document_type IN privacy_policy	tos
Audit append-only	DB `audit_log_gdpr_art9`	✅ esiste
Seam di publish	`multiverbe-app/api/site/publish.ts` (POST, verifica ownership, set status=published, hook non-bloccanti)	✅ hook-point per iniezione legale
CSP	`vercel.json` già autorizza `cdn.iubenda.com` + `*.iubenda.com`	✅
`compliance.ts` sync consenso	`multiverbe-app/src/lib/compliance.ts`	⚠️ Klaro→DB ok · `recordLegalAcceptance` non ancora agganciato al signup

Gap che restano (Layer B): generazione contenuto pagine legali per-locale + wiring privacyPolicyUrl per-tenant nel CookieBanner + endpoint /legal/* + DPA click-wrap agganciata a legal_acceptances + sub-processor disclosure.

4. Roadmap implementativa (PR atomiche, CI verde)

Ordine per rischio crescente. DB-touch → approvazione founder (regola standing).

#	PR	Tocca	Rischio	DB?	Stato
P1	Sub-processor SSoT in codice + endpoint `/legal/subprocessors` versionato (JSON + HTML minimale)	`api/legal/` + `api/_lib/legal/`	basso · additivo	no (serve da modulo git-versionato)	✅ MERGED (#163)
P2	Notifica 30gg cambio sub-processor (revFADP art. 9) — cron diff versione + email Brevo a owner workspace attivi	`api/cron/` + Brevo	basso	no	✅ PR #178 · changelog versionato nel SSoT + cron daily · idempotenza+audit via `audit_log_gdpr_art9` (niente tabella nuova) · email IT/DE/FR/EN · CI verde
P3	Motore template legali multilingua (privacy + cookie + impressum, sector-aware, IT/DE/FR/EN) — modulo + render, flag OFF, watermark "BOZZA in revisione legale"	`multiverbe-app/api/_lib/legal/site-legal.ts` (spostato qui da `sites-runtime/lib/legal/`: CI-covered + importabile da publish.ts)	medio	no	✅ PR #181 · `generateLegalPages()` + `layerBSubprocessors()` + `isLegalTextPublishable()` (false) · 12 doc 3×4 lingue · CI verde
P4	Generazione pagine legali a publish (crea `site_pages`/`site_blocks` legali da template P3, `show_in_footer=true`) + wiring `CookieBanner.privacyPolicyUrl` per-tenant	`api/site/publish.ts` + `sites-runtime`	medio-alto · pubblica contenuto legale vivo	scrive righe site_* (tabelle esistenti)	🟡 GATE: revisione legale CH + `LEGAL_TEMPLATES_REVIEWED=true` · motore (P3) pronto, manca solo il wiring al seam publish (hook fire-and-forget, vedi `publish.ts`)
P5	DPA outbound click-wrap onboarding (riusa `legal_acceptances` `document_type='dpa'`) + template versionato	`api/_lib/legal/outbound-legal.ts` + `api/legal/accept-agreements.ts` + `compliance.ts`	medio	no (riusa tabella)	✅ PR #182 · template DPA (7 clausole) + endpoint accept server-side (IP/UA hash) + helper `acceptClientAgreements` · manca solo il wiring UI in SetupWizardV2
P6	ToS + clausola AI-liability per siti generati (template + accettazione)	`api/_lib/legal/outbound-legal.ts` `document_type='tos'`	medio	no	✅ PR #182 · ToS as-is + clausola contenuti-AI + cap 12 mesi + foro Lugano · servito su `/legal/tos`
+	Hardening CookieBanner siti cliente (granulare necessari/statistiche/marketing · no pre-tick · revoca one-click · IT/DE/FR/EN · ricevuta consenso)	`sites-runtime/components/Compliance/CookieBanner.tsx`	medio	no	✅ PR #186 · build Vercel sites + Semgrep verdi · wiring per-tenant locale = follow-up B5

Nessuna nuova migration prevista: si riusa legal_acceptances (DPA/ToS) e si serve la sub-processor list da modulo codice git-versionato (la storia versioni È git, deploy = pubblicazione). Eventuali tabelle (es. dsar_requests dalla skill) restano follow-up post-gate con SQL pronto e approvazione founder.

5. Sub-processor disclosure (due liste, 30 giorni)

revFADP art. 9 + GDPR art. 28(2): notifica 30 giorni PRIMA di attivare un nuovo sub-processor, a tutti gli owner workspace.

Lista 1 · Multiverbe→clienti-PMI (Layer A→cliente, DPA outbound): tutti gli 11 di sub-processors.md. Servita a /legal/subprocessors su multiverbe.app. Linkata dalla DPA + privacy policy app.

Lista 2 · cliente-PMI→visitatori (Layer B, nella privacy policy del SITO generato): sottoinsieme che tocca il sito vivo:

Vercel (hosting/CDN, log richiesta) · Supabase (contenuti sito, eventuale form contatti) · Iubenda/Klaro (banner consenso) · + solo se il cliente li attiva: Google Analytics, Google Maps, Meta Pixel, ecc.
NON includere Anthropic/Mistral/Stripe/Brevo nello stack del SITO: toccano generazione/billing/email di Multiverbe, non i visitatori del sito cliente.

L'endpoint P1 espone la Lista 1 versionata; il template P3 inietta la Lista 2 (per-sito, condizionata agli analytics attivati) nella privacy policy del cliente.

6. DPA outbound click-wrap (Multiverbe = processor)

Click-wrap in onboarding, pre-go-live. Clausole chiave (skill § DPA outbound, base Genie AI Swiss + iubenda):

Istruzioni del titolare: trattamento solo workspace_id-scoped.
Riferimento sub-processor list versionata /legal/subprocessors.
Notifica cambio sub-processor: min 30 giorni (revFADP art. 9).
Misure di sicurezza: RLS, encryption at rest (Supabase), TLS in transito, audit log, MFA opzionale.
Diritto di audit: self-assessment documentato (SOC2/ISO 27001 se disponibili).
Restituzione/cancellazione a fine rapporto: soft-delete 90gg + hard-delete + purge sub-processor.
Cap di responsabilità: 12 mesi di fee (standard SaaS).

Implementazione (P5): riusa legal_acceptances (document_type='dpa', document_version bump quando la sub-processor list cambia) + ip_hash/user_agent_hash già presenti. Niente tabella nuova. Per verticali regolati (sanità/finanza/legale, post-MVP) → addendum + lawyer CH (skill decision-tree).

7. ToS / liability siti generati da AI (P6)

Rischio reale: bug del generatore → form rotto → lead persi → cliente imputa il danno a Multiverbe.

ToS del servizio Pianeta Web (Multiverbe→cliente): sito fornito "as-is" con best-effort, cap responsabilità 12 mesi fee (allineato DPA §7), SLA di disponibilità dichiarato, responsabilità del cliente sui contenuti che fornisce e sull'attivazione di analytics terzi.
Clausola AI-content: i contenuti generati (copy, immagini) sono assistiti da AI; il cliente è invitato a verificarli prima del publish; Multiverbe non garantisce accuratezza fattuale del testo generato.
Accettazione tracciata in legal_acceptances (document_type='tos').

8. Aperti per il founder

Meccanismo Layer B: già canon (02-product.md r.41, proprietario). Niente da decidere salvo tua conferma esplicita di rotta; procedo su (c).
Revisione legale CH del template base privacy+cookie+ToS (una-tantum, CHF 1-3k, riusabile su tutti i siti) → gate per accendere P4 in produzione.
Eventuali tabelle DSAR (dsar_requests) e cron overdue → post-gate, SQL pronto nella skill.

9. Fatto oggi 2026-06-03

✅ Iubenda Essentials su multiverbe.com (landing, annuale €59,88/anno) — pagato.
✅ Iubenda Advanced su multiverbe.app (app, mensile €21,99 · passare ad annuale quando ci sono fondi, -16%) — pagato.
✅ Decisione two-layer + meccanismo Layer B raccomandato, coi numeri.
✅ Design doc (questo file) + P1 = PR #163 (endpoint /legal/subprocessors versionato) · CI verde + verificato live (HTTP 200 JSON). Non-merged (legal surface → merge founder).
✅ PR #169 (fuori-scope ma big-tech): estesa la SAST Semgrep ai path di codice (api//src//sites-runtime/); ha scovato + soppresso 1 FP pre-esistente. Gate 0 finding.
✅ Risposta costo per-cliente Iubenda (§2.bis sopra) + decisioni lifecycle/Klaro-Iubenda (§2.ter).
✅ Punto A (2026-06-04): inseriti 6 sub-processor nella policy Iubenda app (Stripe, Supabase, Vercel, Brevo email, Anthropic, Mistral — tutti i flussi PII cliente). I restanti (no-PII + Upstash/Datatrans) coperti dalla lista canonica /legal/subprocessors (live). Dettaglio + follow-up (Titolare/entità, integrazione, landing) in iubenda-subprocessors-turnkey-2026-06-03.md.
✅ Merge: PR #163 (endpoint) + #169 (SAST) mergiati in master (prod), #163 verificato dalla SAST estesa (0 finding) prima del merge.
🟡 Iubenda Advanced (app): deciso tenere come ponte (Klaro resta il banner, no doppio-pagamento); disdetta pulita quando proprietario + revisione legale CH pronti.

10. Stato implementazione · 2026-06-04 (sessione Pianeta Web compliance · COMPLETA)

Macchina di compliance interamente costruita e mergiata in master. 10 PR atomiche, tutte CI-verdi. Tutto il testo legale è draft-gated: niente va vincolante/vivo finché non c'è la revisione legale CH e i flag non passano a true.

PR	Cosa	Stato
#163 P1	endpoint `/legal/subprocessors` versionato	✅ merged
#178 P2	notifica 30gg cambio sub-processor (changelog + cron Brevo IT/DE/FR/EN · idempotenza+audit `audit_log_gdpr_art9` · niente migration)	✅ merged
#181 P3	motore template legali siti (privacy+cookie+impressum IT/DE/FR/EN, sector/feature-aware, `layerBSubprocessors`, draft-gated) in `multiverbe-app/api/_lib/legal/site-legal.ts`	✅ merged
#182 P5+P6	DPA + ToS outbound + endpoint accept server-side (IP/UA HMAC, idempotente) + pagine `/legal/dpa`·`/legal/tos` + helper `acceptClientAgreements`	✅ merged
#186	CookieBanner siti cliente: granulare (necessari/statistiche/marketing, no pre-tick), multilingua IT/DE/FR/EN, ricevuta consenso versionata	✅ merged
#191	cleanup: svuotato `KNOWN_PENDING` nel guard ESM (#155 in master)	✅ merged
#192	gate `OUTBOUND_LEGAL_REVIEWED` + watermark + suffisso versione `-draft` su DPA/ToS	✅ merged
#194 P4-live	genera+persiste pagine legali al publish (gated `isLegalTextPublishable`) `site_pages`/`site_blocks` (upsert idempotente, niente migration) + renderer `Legal` in sites-runtime	✅ merged
#196	click-wrap DPA+ToS in onboarding (checkbox Step 3 + `acceptClientAgreements` best-effort in `handleFinalComplete`)	✅ merged
#197	revoca consenso cookie sui siti (pill discreta post-consenso → `openCookiePreferences`)	✅ merged
#201	DPA + ToS multilingua IT/DE/FR/EN + `?locale=` su `/legal/dpa`·`/legal/tos`	✅ merged
#207	compliance senza avvocato: modello owner-responsibility (ToS) + carve-out settori regolati (`isRegulatedSector`) + DPA allineata alle SCC UE 2021/915 + gate riformulato	✅ merged
#208	footer per-tenant sui siti (link legali da `show_in_footer` + revoca cookie + ©) → Impressum raggiungibile (UWG art. 3)	✅ merged

🟢 Niente più avvocato a pagamento (decisione founder 2026-06-04)

Il gate "revisione legale CH a pagamento (CHF 1-3k)" è superato dal modello #207 (doc dedicato legal-templates-no-lawyer-strategy-2026-06-04.md): template da fonti ufficiali gratuite (SCC UE 2021/915 · trasparenza nDSG/GDPR · UWG) + "titolare responsabile, non consulenza legale" nei ToS + carve-out settori regolati + due diligence documentata. È lo standard Wix/Squarespace. Le PMI <250 dip. a basso rischio sono parzialmente esentate dall'OPDa.

Cosa resta per andare LIVE (solo azione founder, niente più codice core né avvocato)

Accendere i due flag (auto-attestazione informata, reversibile, 2 costanti):
- LEGAL_TEMPLATES_REVIEWED = true in site-legal.ts
- OUTBOUND_LEGAL_REVIEWED = true in outbound-legal.ts → tolgono i watermark "bozza", bumpano le versioni (re-prompt clienti che hanno accettato la bozza), accendono P4-live al primo re-publish. Consigliato: scorrere una volta i testi generati per un sito demo prima di accendere.
Solo per i settori regolati (sanità/finanza/legale, ~5%): isRegulatedSector li segnala già; lì conviene una verifica professionale a carico del cliente (non nostra), e NON li vendiamo come "a norma chiavi in mano".
Polish minore (post-gate, opzionale): campo email-titolare dedicato in onboarding (oggi fallback brand_dna/billing_email) per la privacy policy.