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 ottobre 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 analisi dei lead 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. Per redigere il report settimanale inviamo a OpenAI (USA) un estratto pseudonimizzato di questi segnali, incluso il testo dei feedback che hai scritto: le email degli account sono sostituite da alias, i nomi visualizzati che conserviamo vengono rimossi o sostituiti dallo stesso alias, gli id interni vengono rimossi, gli altri indirizzi email vengono eliminati e la richiesta non resta nel response store di OpenAI, ma la conservazione di OpenAI per il monitoraggio degli abusi si applica comunque.
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. Nei limiti dell'utilizzo incluso nel tuo piano, le conversazioni di AIDB Studio vanno a OpenAI (USA), e OpenAI conserva ogni risposta nel proprio response store, secondo i termini di conservazione dei dati della sua API. Con il piano Basic, e con qualsiasi piano dopo che l'utilizzo incluso è esaurito, AIDB Studio risponde con modelli gratuiti raggiunti tramite OpenRouter (USA): ogni richiesta arriva a OpenRouter e al provider del modello che OpenRouter sceglie, la cui ubicazione varia, e chiediamo a OpenRouter di usare soltanto provider che, nel suo elenco, non raccolgono i dati degli utenti. Ogni richiesta contiene la conversazione, i file o le immagini che alleghi, il tuo nome visualizzato e i risultati degli strumenti che AIDB Studio ha eseguito per te. Se scegli di usare AIDB Studio con la tua chiave OpenAI o OpenRouter, quelle richieste vanno a quel servizio con il tuo account e le sue impostazioni. Quando una conversazione lunga di AIDB Studio viene compattata per risparmiare spazio, con qualsiasi piano, i turni compattati vengono inviati a OpenAI (USA) per scriverne un riepilogo; quella richiesta non viene conservata nel response store di OpenAI, ma resta soggetta alla conservazione per il monitoraggio degli abusi di OpenAI. Se attivi la ricerca web in AIDB Studio, la ricerca avviene all'interno della chiamata al modello di OpenAI quando la chat usa OpenAI direttamente (il modello del tuo piano, nei limiti dell'utilizzo incluso, oppure la tua chiave OpenAI); in tutti gli altri casi, compreso un modello OpenAI usato tramite un altro provider, le query di ricerca che AIDB Studio scrive a partire dalla tua richiesta vengono inviate a Tavily, un provider di ricerca web. La deep research invia il tuo argomento a OpenAI (USA) per pianificare le sotto-domande e per leggere e riassumere le fonti, e invia le sotto-domande a Tavily.
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. Fanno eccezione i log operativi di sicurezza e di costo descritti più avanti: la cancellazione li scollega subito dal tuo account invece di eliminarli del tutto, anche se ogni riga segue comunque la scaletta di conservazione descritta lì, a prescindere dalla cancellazione.
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 che passi (valutazioni, testo opt-in, email di contatto con permesso). signals.report richiede l'accesso con un piano Pro, Pro Plus, Teams, Enterprise, beta o trial ed è collegato al tuo ID utente autenticato e piano, vengono memorizzati così come li passi i campi dell'evento (il tipo di evento, obbligatorio, e facoltativamente il contesto d'uso, una valutazione, la fase di lavoro, se consiglieresti il servizio, la dimensione del team e una nota brief_context di testo libero, che può comparire, pseudonimizzata, nel nostro estratto settimanale di analisi dei lead inviato a OpenAI), insieme al tuo piano e al client chiamante. Nessuno dei due strumenti legge i tuoi prompt, il tuo codice, i tuoi file o il tuo repository, quindi non inserire contenuti sensibili nel campo brief_context. contact_email viene memorizzata solo quando imposti permission_to_follow_up su true. In quel caso signals.feedback apre anche un ticket di supporto e invia il testo libero a OpenAI (USA) per il triage; l'indirizzo email non viene mai trasmesso a OpenAI. I moduli di supporto e partnership inviano il testo del messaggio a OpenAI (USA) per lo stesso triage; nome ed email non vengono inviati. Il form pilot invia a OpenAI (USA) ruolo, stadio del workflow e la descrizione che fornisci; il form agency invia azienda, ruolo, stadio del workflow, descrizione del workflow, tipo di supporto e sfida principale. Nome, email e, solo per l'agency, link al materiale e note non vengono mai inviati; la richiesta non resta nel response store di OpenAI, ma la conservazione di OpenAI per il monitoraggio degli abusi si applica comunque. Quando architect.validate, design.validate, spec.validate o architect.certify elabora ciò che fornisci (codice, la descrizione di un'interfaccia o una specifica scritta), quel contenuto, insieme al repository URL e ai file paths che selezioni per le scansioni di repository, viene inviato a un provider LLM esterno (OpenAI, su contratto no-training-on-API-data e soggetto ai termini di conservazione dei dati dell'API) durante l'elaborazione. Viene mantenuto nel response store di OpenAI a meno che tu non imposti private_session=true su architect.validate, design.validate o spec.validate; architect.certify conserva sempre un run. Quando un run standard risulta production_ready conserviamo il codice inviato per 24 ore, così architect.certify può verificarlo; dopo non può più essere usato e una pulizia automatica lo cancella; le sessioni private non conservano codice. NON usiamo il tuo codice proprietario, gli score di validation o i diagrammi architetturali per addestrare, fine-tunare o migliorare modelli AI di base. A parte questa conservazione di 24 ore, viene memorizzato solo il risultato strutturato: verdetti per principio, severity score, raccomandazioni, esito di certificazione, reproducibility envelope (model, seed, doctrine fingerprint, code fingerprint), un URL di review e un URL del badge e, per le scansioni di repository, un repository identifier e un commit reference (conservati per la baseline lineage e la riproducibilità, non leggibili dall'analitica interna). Per impostazione predefinita questi URL sono privati e non mostrano nulla pubblicamente; un run diventa visibile pubblicamente solo quando lo pubblichi esplicitamente dalla tua dashboard. Pubblicare un run rende pubblici il suo score, il grade e i finding strutturati; non pubblica il tuo repository identifier, il repository URL, né i file paths. 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, design.validate o spec.validate per saltare il run memorizzato per quella chiamata (nessun run_id, nessun result_json, nessun badge, e di conseguenza nessun architect.certify possibile su quel run). Una sessione privata non viene inoltre mantenuta nel response store di OpenAI, mentre un run standard sì; la conservazione di OpenAI per il monitoraggio degli abusi si applica a entrambi. Sulle chiamate non-private, il record del validation run (score, verdetti, raccomandazioni, reproducibility envelope) viene inoltre 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 dei token MCP collegati al tuo account tramite il processo di cancellazione dati descritto sopra. I feedback che hai inviato con signals.feedback vengono scollegati dal tuo account invece di essere eliminati; se ci hai lasciato un'email di contatto, scrivici e rimuoviamo anche quella.
Questi log vengono scritti a ogni chiamata, comprese le sessioni private. Registrano chi ha eseguito cosa e quando, il client chiamante, il software client e la versione che dichiara, il pacchetto di installazione da cui proviene (un identificativo fisso nel manifest del plugin, mai un dato che ti riguarda) e, sulle chiamate MCP, un digest unidirezionale calcolato con una chiave dell'indirizzo di rete da cui è arrivata la richiesta (uno pseudonimo, non l'indirizzo stesso). Registrano anche il testo o l'oggetto della ricerca (una query, il nome di un principio, cluster o esempio, oppure, per un run di validazione, il repository e l'eventuale testo di errore) e se la chiamata è andata a buon fine e quanto tempo ha richiesto, ma mai la stringa user-agent grezza: solo il client chiamante e il software e la versione che dichiara, già elencati sopra. L'handshake di connessione di un'installazione del plugin viene registrato una volta come riga a sé, anche se poi non viene chiamato alcuno strumento. Sulle chiamate di validazione conservano anche un riepilogo della richiesta: la descrizione del task o l'area di focus che hai passato, l'identificativo del repository, fino a tre dei file path che hai selezionato, il linguaggio che hai dichiarato e l'esito del run. Il riepilogo arriva fino a 4.000 caratteri su alcuni strumenti e a 500 su altri, quindi una descrizione lunga può essere conservata per intero. Il tuo codice, artefatto o specifica non viene mai scritto in questi log. Li usiamo per prevenire abusi, garantire la disponibilità della piattaforma e indagare sugli incidenti, e in forma aggregata per la reportistica operativa interna descritta sopra in Activation e lead intelligence. Possiamo inoltre usare il testo di ricerca inviato agli strumenti MCP pubblici di ricerca (principles.search, examples.search, guides.search) per scegliere gli argomenti delle guide che pubblichiamo, in base al nostro legittimo interesse a migliorare la doctrine pubblicata. Un termine conta solo quando almeno tre chiamanti distinti lo hanno cercato nella finestra letta da una pianificazione; un chiamante è un account, oppure il digest di un indirizzo di rete per le chiamate anonime, quindi una stessa persona su più reti può contare più di una volta. Un termine in shortlist viene poi inviato a OpenAI (USA) per associarlo a un principio. Un termine scelto diventa l'argomento di una guida: Tavily lo riceve come query di ricerca secondo i propri termini (la ricerca web di OpenAI lo riceve quando Tavily non risponde o non trova fonti), e OpenAI (USA) redige la guida e la sua immagine di copertina. Le richieste di testo a OpenAI non restano nel suo response store; si applica la conservazione di OpenAI per il monitoraggio degli abusi. La copia che il run della pianificazione conserva di un termine tratto dalle ricerche viene azzerata 90 giorni dopo il run, come il testo di ricerca stesso; la guida redatta a partire da quel termine e il record di generazione che la accompagna sono un nostro contenuto e vengono conservati. Contenuti come il testo di ricerca e il riepilogo delle richieste di validazione vengono azzerati dopo 90 giorni, i dati che ti identificano (ID utente, email, ID account Firebase, ID del turno di conversazione e il digest dell'indirizzo di rete) vengono rimossi dopo 12 mesi, e la riga ormai anonima viene cancellata dopo 24 mesi, in base al nostro legittimo interesse a gestire e proteggere il servizio. La cancellazione dell'account scollega queste righe di log dal tuo account invece di eliminarle: restano senza il tuo ID utente e senza il tuo indirizzo email, e da quel momento servono per sicurezza, disponibilità e la reportistica aggregata di cui sopra, nessuna delle quali ti identifica. La sezione Privacy e gestione dei dati mostra quante ne esistono collegate al tuo account, e l'esportazione dei tuoi dati include le 500 righe più recenti di ogni log, indicando il totale reale e se ha dovuto fermarsi lì. Il digest dell'indirizzo lo lasciamo fuori da quell'esportazione. Lo stesso indirizzo di rete produce sempre lo stesso digest, quindi restituirtelo ti permetterebbe di riconoscere anche le righe di altre persone che condividono il tuo indirizzo, non solo le tue.
Se sei un beta tester, puoi invitare un collega (un "counterpart") che hai indicato a unirsi alla beta. Usiamo l’indirizzo email di quella persona solo per generare un link di invito personale, che gli mandi tu; non gli inviamo noi l’email. Ci basiamo sul nostro legittimo interesse a facilitare il referral che hai richiesto. Conserviamo l’email di un counterpart non attivato per 28 giorni (la finestra beta) e poi la cancelliamo, insieme all’invito in sospeso e a eventuali identità di accesso pre-create. Il counterpart può annullare in un clic in qualsiasi momento e può chiederci di cancellare i suoi dati.
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. Per applicare limiti di frequenza alle richieste di reinvio del link di attivazione e di reimpostazione della password usiamo un registro che conserva l'indirizzo email, un digest unidirezionale calcolato con una chiave dell'indirizzo di rete e la data e l'ora della richiesta. Il registro serve solo a far rispettare questi limiti: ogni riga viene cancellata dopo 2 giorni e, con la cancellazione dell'account, le tue righe vengono cancellate subito. Nessun sistema è perfetto, quindi le protezioni evolvono con la piattaforma.
