Questa policy spiega quali dati personali AI Design Blueprint tratta tra pagine pubbliche di scoperta, activation dei membri, validation run, waitlist, pilot intake e operazioni admin, perché il trattamento avviene e quali controlli sono disponibili.
Ultimo aggiornamento: 10 aprile 2026
A seconda di come usi la piattaforma, possiamo trattare identificativi dell'account, dati del provider di accesso, informazioni di profilo, preferenze di comunicazione, risposte di activation, riepiloghi del percorso consigliato, stato di apprendimento, validation run, iscrizioni in waitlist, pilot application, record di invito beta, token di accesso OAuth MCP e log operativi di sicurezza.
Usiamo questi dati per autenticare i membri, creare e mantenere workspace, preservare l'accesso ai corsi, tracciare i progressi, supportare validation e workflow pilot, generare raccomandazioni di activation, valutare salute del prodotto e dei lead, gestire waitlist e pilot intake e migliorare affidabilità, supporto e qualità del prodotto.
Risposte di activation, strumenti selezionati, stato dell'artefatto, raccomandazioni di percorso, attività di apprendimento, stato waitlist, stato pilot e segnali operativi correlati possono essere combinati in riepiloghi interni di lead intelligence per revisione admin e report operativi settimanali. Questi riepiloghi servono a prioritizzare supporto, comprendere la domanda e individuare attriti nella piattaforma. Non vendiamo questi dati a terzi.
I cookie necessari sono usati per far funzionare il servizio e mantenere la funzionalità di base. I controlli opzionali coprono attualmente analytics storage e research contact. Puoi concedere o revocare questi consensi dal cookie banner e, se autenticato, dalla sezione Privacy e gestione dei dati nell'app.
L'autenticazione si basa attualmente su Firebase Authentication, incluso Google sign-in quando scelto dall'utente. La misurazione analitica si basa su Google Analytics 4 (GA4), caricato solo quando concedi il consenso analytics tramite il cookie banner; GA4 opera ai sensi dei termini di trattamento dati di Google e della consent mode v2. Invio email e sincronizzazione preferenze possono usare Resend. Provider infrastrutturali possono trattare dati operativi necessari per ospitare, proteggere e monitorare il servizio. Provider AI e model possono trattare prompt e output necessari per contenuti localizzati, activation routing, valutazione o reporting.
Conserviamo i dati personali solo per il tempo necessario al servizio, alla sicurezza, agli obblighi legali o alla continuità operativa legittima. Se richiedi la cancellazione dell'account, l'account live e i record in-product collegati vengono rimossi e può essere mantenuto un backup limitato nel tempo per il numero di giorni scelto nella sezione Privacy e gestione dei dati, prima della sua eliminazione.
Quando sei autenticato puoi usare la sezione Privacy e gestione dei dati per rivedere i consensi opzionali, ispezionare un inventario dei dati, generare un export portabile dei dati collegati all'account e richiedere la cancellazione dell'account. Puoi anche aggiornare le preferenze di comunicazione e interrompere l'uso di un metodo di accesso in qualsiasi momento, salvo vincoli di recupero account.
I file di istruzioni statici (AGENTS.md, regole .mdc, copilot-instructions.md) sono file locali, non inviano nulla. Gli strumenti MCP di recupero (principles.list, examples.search, ecc.) recuperano doctrine ed esempi dai nostri server. signals.feedback è aperto a tutti i chiamanti ma deve essere usato solo su richiesta esplicita dell'utente; vengono memorizzati solo i campi strutturati che passi (valutazioni, testo opt-in, email di contatto con permesso). signals.report richiede un token Bearer Pro o Teams attivo ed è collegato al tuo ID utente autenticato e piano, vengono memorizzati solo i campi strutturati dell'evento (tipo, superficie, valore percepito, breve nota). Prompt grezzi, codice proprietario, contenuti di file e dettagli del repository non vengono mai memorizzati. contact_email viene memorizzata solo quando imposti permission_to_follow_up su true. Quando architect.validate o architect.certify elabora il codice, viene inviato a un provider LLM esterno (OpenAI, su contratto no-training-on-API-data) in modo transitorio e non viene conservato da AI Design Blueprint come contesto grezzo. NON usiamo il tuo codice proprietario, gli score di validation o i diagrammi architetturali per addestrare, fine-tunare o migliorare modelli AI di base. Viene memorizzato solo il risultato strutturato: verdetti per principio, severity score, raccomandazioni, esito di certificazione, reproducibility envelope (model, seed, doctrine fingerprint, code fingerprint), URL di review pubblico e URL del badge. Il code_fingerprint SHA-256 a 16 caratteri che persistiamo è una primitiva di binding tra architect.validate e architect.certify (perché il cert non possa essere emesso su codice diverso da quello revisionato) e non è reversibile al codice originale. Imposta private_session=true su architect.validate per saltare tutta la registrazione server-side per quella chiamata (nessun run_id, nessun result_json, nessun badge — e di conseguenza nessun architect.certify possibile su quel run). Sulle chiamate non-private, il record del validation run (score, verdetti, raccomandazioni, reproducibility envelope) viene memorizzato nella tua workspace history privata e puoi cancellarlo in qualsiasi momento dalla dashboard. Questo design riflette l'impegno del Blueprint: gli agenti eseguono il workflow, gli umani lo governano. Il tuo codice resta tuo a meno che tu non scelga esplicitamente di condividerlo. L'autenticazione OAuth 2.1 MCP (usata da client come Claude Code) crea un codice di autorizzazione a breve scadenza e un token di accesso opaco a lunga durata collegato al tuo ID utente; questi record vengono usati solo per autenticare le successive chiamate MCP e possono essere revocati cancellando l'account. Puoi richiedere la cancellazione di tutti i record di segnale e token collegati al tuo account tramite il processo di cancellazione dati descritto sopra.
Usiamo autenticazione gestita, controlli di sessione server-side, restrizioni di accesso admin, chiavi interne tra servizi e secret management per ridurre l'esposizione dei dati personali. Manteniamo inoltre log operativi limitati per rilevare abusi, proteggere la disponibilità della piattaforma e investigare incidenti. Nessun sistema è perfetto, quindi le protezioni evolvono con la piattaforma.
