IRONSTICK← Pagina iniziale

IRONSTICK — Dichiarazione GDPR sui flussi di dati
Rapporti con modelli linguistici di grandi dimensioni (LLM) esterni

Descrizione fattuale, ricavata dal codice, di ogni percorso attraverso il quale i dati escono da IRONSTICK verso un LLM esterno, di che cosa esattamente viene trasmesso, in quale forma e di dove si applica il livello di pseudonimizzazione. Edizione desktop per Windows. Il presente documento descrive esclusivamente il comportamento di IRONSTICK — ciò che il fornitore di IA fa con i dati ricevuti è disciplinato esclusivamente dalle condizioni proprie del fornitore (le condizioni e le informative sulla privacy dei fornitori configurati dall'utente — Google, Alibaba Cloud, Moonshot AI, OpenAI e/o Anthropic), che l'utente deve esaminare separatamente.

1. Ambito ed endpoint

Le chiamate IA esterne all'interno dell'app sono dirette al fornitore che la cascata automatica sta utilizzando in quel momento. L'utente può configurare fino a cinque fornitori; ogni fornitore configurato viene utilizzato automaticamente nel seguente ordine fisso, orientato al risparmio dei costi: Gemini (Google) → Qwen (Alibaba Cloud) → Kimi (Moonshot AI) → ChatGPT (OpenAI) → Claude (Anthropic). A ogni avvio del programma IRONSTICK verifica quali di essi rispondono; se nel corso della giornata una quota o un credito si esaurisce, oppure un fornitore smette di rispondere, la medesima richiesta viene ripetuta con il fornitore successivo, che viene poi utilizzato per il resto della giornata. Il contenuto trasmesso è identico per ogni fornitore (dalla sezione 3 in poi: pseudonimizzato dal router, consenso, registro di audit). Gli endpoint sono:

• Claude: POST https://api.anthropic.com/v1/messages, con la chiave API propria dell'utente.
• ChatGPT: POST https://api.openai.com/v1/chat/completions, con la chiave API propria dell'utente.
• Qwen: POST https://dashscope-intl.aliyuncs.com/compatible-mode/v1/chat/completions (Alibaba Cloud Model Studio, regione internazionale), con la chiave API propria dell'utente.
• Kimi: POST https://api.moonshot.ai/v1/chat/completions (Moonshot AI), con la chiave API propria dell'utente.
• Gemini (solo Windows): nessuna chiave API. IRONSTICK controlla il client a riga di comando proprio di Google, non modificato (Google Antigravity CLI), come processo locale nascosto; il client è autenticato con l'account Google dell'utente (finestra di accesso propria di Google — IRONSTICK non vede mai password né codice) e invia la richiesta a Google nell'ambito del piano Google AI dell'utente. Il client non ha alcun accesso agli strumenti o ai file di IRONSTICK; viene eseguito in una cartella di lavoro vuota con una cartella di profilo privata all'interno della cartella dei dati, e le sue registrazioni locali delle conversazioni e i suoi log vengono cancellati dopo ogni chiamata.

Per ciascun fornitore sono utilizzati tre livelli di modello configurabili (piccolo / medio / grande). Un canale separato e facoltativo è il ponte IA desktop (sezione 4.9): in questo caso i dati confluiscono nell'IA desktop locale propria dell'utente (Claude Desktop / Claude Code, ChatGPT Desktop, Qwen Desktop oppure Kimi Desktop), ossia al fornitore di tale IA (Anthropic, OpenAI, Alibaba Cloud/Qwen o Moonshot AI/Kimi) nell'ambito dell'abbonamento/account proprio dell'utente presso tale fornitore. I ponti possono funzionare in parallelo — lo stesso server MCP locale può essere registrato contemporaneamente presso Claude, ChatGPT, Qwen e Kimi, e questi possono lavorare simultaneamente sullo stesso caso. IRONSTICK non gestisce alcun server proprio; nessun dato confluisce mai al produttore del software. Il server LAN dello studio, facoltativo (IRONSTICK SERVER, sezione 9), non modifica tale situazione: è gestito dallo studio legale stesso, sull'hardware proprio dello studio, all'interno della rete propria dello studio — non contatta mai il produttore e non contatta mai alcun fornitore di IA.

Interamente in locale (nulla lascia la macchina): estrazione del testo e OCR, il livello di chat locale deterministico, la ricerca globale, il radar di rilevanza, l'analisi delle catene di lettere, la generazione di dossier/PDF, il passaggio locale del rilevatore di oscuramento e la creazione del pacchetto di istruzioni IA.

2. Il livello di pseudonimizzazione

Ogni esecuzione di agente all'interno dell'app può disporre di un pseudonimizzatore che tokenizza il testo in uscita, ritraduce gli argomenti degli strumenti per l'esecuzione locale, ri-tokenizza i risultati degli strumenti e de-tokenizza localmente la risposta finale. La corrispondenza risiede esclusivamente in memoria, con una nuova corrispondenza per ogni operazione; non viene mai resa persistente.

2.1 Che cosa viene sostituito

2.2 Che cosa rimane deliberatamente reale

• Date, orari e importi monetari — la loro alterazione è stata ritenuta più pericolosa della loro trasmissione.
• Denominazioni delle istituzioni (tribunali, autorità) — non figurano nel dizionario e sono enti pubblici.
• Terzi sconosciuti nel testo libero — testimoni, medici, avvocati, giudici o società che non sono memorizzati come anagrafiche di cliente/persona/caso non vengono riconosciuti ed escono in chiaro. Si tratta di un limite documentato dell'approccio.
• Indirizzi di soggetti che non sono clienti — non esiste alcuno schema per gli indirizzi; viene tokenizzato solo l'indirizzo memorizzato del cliente.
• L'intero contenuto fattuale dei documenti (allegazioni, diagnosi, narrazione) — vengono sostituiti solo gli identificativi, non la vicenda.

2.3 Eccezioni deliberate con nome in chiaro

• Ricerca web su persone (fase 1) e compilazione automatica dei moduli per persone / istituzioni: una ricerca web per $PARTEI_A$ è priva di senso, pertanto il nome reale viene inviato per scelta progettuale.
• Rilevatore IA per l'oscuramento: riceve un testo che è già stato oscurato localmente e deve rispondere con i nomi in chiaro dei terzi sconosciuti che individua — la pseudonimizzazione è disattivata per questo solo scopo.
• Pre-elaborazione per la lettura ad alta voce (TTS): si veda 4.6 — le frasi escono in chiaro.
• Ponte IA desktop: dati grezzi per scelta progettuale (sezione 4.9).

3. Momenti del consenso e registro di audit

Le chiamate instradate attraverso il router centrale sono subordinate al consenso e registrate: ogni round del modello scrive una riga nella tabella di audit locale (T0_AiExtLog) con la richiesta e la risposta complete nella forma tokenizzata che ha effettivamente lasciato la macchina; i tentativi rifiutati/bloccati vengono registrati senza contenuto utile. La finestra di dialogo del consenso indica il livello del modello e le dimensioni approssimative della richiesta, e un'unica approvazione copre la sessione corrente della schermata (per la registrazione dei documenti: l'esecuzione corrente del programma).

4. I flussi di dati, caso d'uso per caso d'uso

4.1 Registrazione dei documenti

L'estrazione del testo e l'OCR sono locali. Se è configurata una chiave API, IRONSTICK chiede il consenso una volta per ogni esecuzione del programma; successivamente vengono eseguiti fino a quattro tipi di chiamata (tutti pseudonimizzati, tutti sottoposti ad audit):

• Rilevamento del documento principale (livello piccolo): testo OCR grezzo in blocchi di al massimo 2.000 caratteri, al massimo 8 chiamate — solo per scansioni di scarsa qualità.
• Correzione OCR (livello piccolo): testo del documento limitato a 16.000 caratteri.
• Classificazione (livello medio): testo del documento limitato a 16.000 caratteri, più elenchi di sistema: l'elenco completo dei casi (numero del caso, nome del cliente, controparte — tokenizzati), un insieme di nomi noti limitato a 2.000 caratteri (tokenizzato) e gli elenchi dei codici dei tipi di istituzione e dei tipi di documento (etichette non tokenizzate). Ripiego: livello piccolo, 8.000 caratteri, senza gli elenchi.
• Contestualizzazione al salvataggio (livello piccolo): i metadati del documento e il testo integrale limitato a 30.000 caratteri, più una riga di indice (ID, data, titolo ≤120 caratteri) di ogni elemento di prova attivo dello stesso cliente — utilizzata per fondare i riferimenti incrociati. Viene eseguita anche per i documenti contrassegnati come segreti (decisione consapevole dell'utente).

4.2 Monitor e-mail (smistamento)

L'assegnazione al caso avviene in primo luogo in modo deterministico (numero del caso o numero di ruolo noto rinvenuto nell'oggetto/estratto — nessuna chiamata IA). Altrimenti una chiamata di livello piccolo per ogni e-mail con esattamente: nome e indirizzo del mittente, oggetto e l'estratto di anteprima memorizzato (limitato rigidamente a 1.500 caratteri) — mai il corpo integrale — più l'elenco completo dei casi (tokenizzato) come contesto di abbinamento. Risposta: priorità + numero del caso. Nella schermata e-mail tale chiamata è subordinata al consenso una volta per sessione; nel funzionamento in background viene eseguita senza finestra di dialogo (l'attivazione del monitor costituisce il consenso). Pseudonimizzata e sottoposta ad audit in entrambe le modalità.

Nessun pixel di tracciamento. L'apertura di un messaggio nel monitor non contatta mai il server del mittente: le immagini richiamate tramite un indirizzo Internet (compresi i pixel di tracciamento invisibili) non vengono caricate e appaiono come segnaposto con un avviso, cosicché il mittente non può sapere quando, quante volte né da quale indirizzo un messaggio è stato letto. Vengono visualizzate solo le immagini incorporate nel messaggio stesso.

4.3 Analisi delle persone (ricerca web)

Tre fasi, dopo un consenso unico per sessione:

• Fase 1 — ricerca: i motori locali vengono interrogati direttamente; inoltre viene richiamato lo strumento di ricerca web lato server del fornitore con il nome reale della persona in chiaro (inevitabile per una ricerca; registrato in chiaro).
• Fase 2 — sintesi delle pagine (livello medio): per ciascuna pagina, il nome della persona (tokenizzato), l'URL e il contenuto della pagina limitato a 8.000 caratteri.
• Fase 3 — sintesi del profilo (livello grande): nome e città (tokenizzati) più ogni testo di pagina raccolto, limitato a 6.000 caratteri per fonte.

Il risultato viene memorizzato localmente con affidabilità "non confermata". I relativi pulsanti di compilazione automatica nei moduli persona/istituzione inviano parimenti il nome digitato in chiaro (eccezione documentata).

4.3a Verifica OSINT di una parte (osint_entity)

La verifica OSINT di una parte è una procedura fissa che l'applicazione esegue autonomamente quando un'IA collegata la richiama con nome, città, distretto, paese e indicazione di persona fisica/giuridica:

• Atti dei casi: una ricerca a testo integrale del nome nell'intera banca dati locale — puramente locale, nulla lascia la macchina.
• Internet: un elenco fisso di interrogazioni di ricerca viene inviato ai motori di ricerca pubblici Google, DuckDuckGo e Qwant. Ciascuna interrogazione è composta da un termine di ricerca nella lingua del paese della parte più il nome reale della parte in chiaro e, per alcune interrogazioni, la città o il distretto (inevitabile per una ricerca). Non viene trasmesso alcun contenuto relativo a casi, clienti o documenti. I motori vedono le interrogazioni come quelle di un qualsiasi utente di un browser.
• Gemini (solo se configurato): se l'utente ha configurato Gemini tramite l'accesso Google, viene inviato a Google esattamente un prompt — la richiesta di trovare tutto sulla parte indicata del paese indicato — contenente il nome reale e il paese in chiaro e nient'altro.

Il risultato viene restituito all'IA chiamante come profilo predisposto e non verificato. Nulla viene scritto nei dati anagrafici: ogni risultanza passa attraverso il controllo di revisione del monitor dei dati (sezione 4.5) e viene adottata solo quando l'utente la accetta. Vengono valutate esclusivamente fonti accessibili al pubblico.

4.4 Protocollo giornaliero

La schermata in sé è locale. L'importazione di testo in forma libera esegue in primo luogo un parser locale; solo quando non viene rinvenuto alcun marcatore del formato di protocollo un ripiego IA normalizza il testo grezzo: il testo incollato viene inviato integralmente (interruzione oltre 200.000 caratteri), livello piccolo, subordinato al consenso, pseudonimizzato, sottoposto ad audit. I protocolli memorizzati lasciano la macchina solo come risultati degli strumenti della chat/del ponte (estratti limitati) oppure all'interno del pacchetto di istruzioni IA (sezione 5).

4.5 Monitor dei dati

La fase 1 (e-mail ↔ dati anagrafici) è interamente deterministica. La fase 2 invia una chiamata di livello piccolo (pseudonimizzata, sottoposta ad audit, senza finestra di dialogo, limitata ai nuovi documenti in entrata) contenente: tutte le anagrafiche memorizzate di istituzioni e di persone/entità del titolare (ID, nomi, dati di contatto, CNP — tokenizzati ove presenti nel dizionario; denominazioni delle istituzioni in chiaro), tutti i nomi delle parti dei casi e estratti delle aree di contatto deduplicati (±~100 caratteri attorno a marcatori di indirizzo/telefono/codice fiscale) tratti dai testi integrali dei documenti in entrata, limitati a 130.000 caratteri in totale. La risposta diventa sempre e soltanto un suggerimento che l'utente deve accettare nel monitor.

4.6 Elaboratore di testi (assistenza IA nel testo)

• Rielaborazione della selezione: la frase/il paragrafo/la sezione selezionati (con marcatura) più i primi 6.000 caratteri dell'intero documento come contesto e l'istruzione dell'utente — livello medio, pseudonimizzato.
• Struttura/indice: di fatto l'intero documento come elenco di righe indicizzate (righe brevi per intero, righe lunghe troncate a 80 caratteri), limitato a 40.000 caratteri — livello medio, pseudonimizzato.
• Pre-elaborazione per la lettura ad alta voce: durante la lettura ad alta voce di un documento, ogni frase viene inviata singolarmente al livello piccolo in chiaro per sciogliere abbreviazioni e numeri — senza pseudonimizzazione (i numeri identificativi devono tornare invariati per essere letti correttamente). I timbri di fascicolo e i marcatori di riferimento vengono prima rimossi localmente. L'avvio della lettura ad alta voce costituisce il momento del consenso.

4.7 Revisione Red/Blue Team e sintesi del dialogo (API)

Due ulteriori flussi API riguardano la redazione. Red/Blue Team: se l'utente lo ha attivato per il fornitore attivo (interruttore accanto alla chiave API; è necessaria una chiave salvata), ogni documento formale consegnato tramite deliver_file — sia dalla chat all'interno dell'app sia dal ponte IA desktop — viene letto ancora una volta dallo stesso fornitore nel ruolo di difensore della controparte (livello medio). Viene trasmesso: il testo della bozza, la data e la giurisdizione del caso; pseudonimizzato tramite il router e sottoposto ad audit come ogni chiamata del router; nessuna finestra di dialogo separata — l'interruttore costituisce il consenso; al massimo due round per file, dopo il secondo round il file viene consegnato in ogni caso, con allegato per l'utente il rapporto del revisore. Sintesi del dialogo: nelle sessioni di chat lunghe la parte più vecchia del dialogo (solo le domande dell'utente e le risposte finali del modello, mai i risultati degli strumenti) viene condensata dal fornitore attivo (livello piccolo, in background) in una sintesi di 2.000 caratteri che sostituisce la cronologia grezza; essa viene memorizzata in forma cifrata nella memoria temporanea e sovrascritta ogni volta.

4.8 Chat IA (esterna, API)

Consenso una volta per sessione di chat; livello medio con passaggio automatico al livello grande (l'intero contesto viene in tal caso inviato nuovamente); pseudonimizzata; ogni round sottoposto ad audit. Ogni turno trasmette: il prompt di sistema (regole statiche), il contesto GUI in tempo reale (schermata corrente, caso/cliente aperto incl. nome del cliente — tokenizzato), fino a 10 voci della memoria IA del cliente aperto, il dialogo più recente limitato a 6.000 caratteri più una sintesi di 2.000 caratteri dei turni precedenti (4.7) e l'elenco dei file temporanei della chat. Ogni strumento richiamato dal modello restituisce il proprio risultato nella conversazione API — compresi i testi integrali dei documenti (limitati a 10.000 caratteri per elemento; i risultati più ampi vengono scritti nella memoria temporanea cifrata e letti a porzioni), i corpi delle e-mail e gli estratti del protocollo giornaliero. Da settembre 2026 la chat utilizza lo stesso livello di strumenti e gli stessi controlli di consegna del ponte IA desktop (4.9): verifica degli atti processuali, Red/Blue Team (4.7) e consegna tramite la finestra di dialogo di esportazione — ciò che lascia il sistema è un modello pronto per il deposito. Il livello di chat locale risponde alle richieste di routine senza alcuna trasmissione.

Due strumenti di utilità meritano una menzione esplicita. get_weather recupera i dati meteorologici attuali per un luogo indicato dal servizio non LLM Open-Meteo (sezione 7) — a tale servizio vengono trasmessi solo il nome del luogo / le sue coordinate, mai dati relativi a casi o persone. get_my_location risponde esclusivamente sulla base dell'ultima istantanea di sicurezza memorizzata localmente (sezione 8): la richiesta dell'IA non attiva alcuna nuova interrogazione esterna — si limita a leggere ciò che si trova già sul disco. Come per ogni strumento, ciò che questi strumenti restituiscono confluisce nuovamente nella conversazione IA, ossia al fornitore di IA.

4.9 Ponte verso un'IA desktop locale (Claude Desktop / Claude Code / ChatGPT Desktop / Qwen Desktop / Kimi Desktop) — moduli aggiuntivi FACOLTATIVI

Ciascun accesso a un'IA desktop è un modulo facoltativo, acquistato separatamente. Esiste solo laddove lo studio abbia acquistato e installato il rispettivo modulo ponte; in assenza di qualsiasi modulo, la sezione del ponte rimane bloccata nella configurazione, l'endpoint locale non viene mai avviato e nessuno dei flussi descritti nella presente sezione può verificarsi. Lo stesso server MCP STDIO locale può essere registrato presso Claude Desktop/Claude Code, ChatGPT Desktop, Qwen Desktop e/o Kimi Desktop — i meccanismi descritti di seguito sono identici per tutti; differisce solo il fornitore destinatario.

• L'IA desktop (Claude Desktop/Code, ChatGPT Desktop, Qwen Desktop o Kimi Desktop) si collega all'app in esecuzione tramite un ponte locale; l'endpoint HTTP si vincola esclusivamente a 127.0.0.1 (localhost costituisce il confine di accesso; il token memorizzato non viene ulteriormente verificato).
• Al primo accesso ai dati per ogni esecuzione del programma IRONSTICK mostra una finestra modale bloccante per il consenso; il rifiuto blocca il canale per 10 minuti. Dopo l'approvazione il canale resta aperto per il resto dell'esecuzione del programma.
• Oltre 170 strumenti — di cui oltre 100 di lettura — espongono cronologie, testi integrali, e-mail, protocolli giornalieri, scadenze, dati anagrafici, interi casi (per parti) e formati di output; i documenti contrassegnati come segreti sono esclusi. I percorsi di scrittura sono subordinati a revisione (i suggerimenti relativi a dati anagrafici/relazioni confluiscono nel monitor dei dati; le modifiche proposte dall'IA alle note di istruzione IA legate al caso vengono presentate come confronto rosso/verde all'interno di IRONSTICK e applicate solo dopo che l'utente le ha espressamente accettate — la decisione viene comunicata all'IA) oppure espliciti (consegna all'elaboratore di testi, consegna di file, navigazione solo se separatamente consentita). Lo stesso schema di controllo di revisione copre i due percorsi di scrittura più recenti: le voci della cronologia non vengono mai scritte dall'IA — questa si limita a PRECOMPILARE il modulo di registrazione, che l'utente completa e salva personalmente; e un testo integrale di un documento risanato dall'IA (nuova scansione OCR, punto successivo) sostituisce il testo integrale memorizzato solo dopo che l'utente ha visionato il testo completo in una finestra di dialogo di conferma e lo ha salvato.
• Risanamento mediante nuova scansione OCR (locale) e consegna del PDF (su iniziativa dell'utente). Quando un testo integrale memorizzato è troncato o compromesso da una precedente esecuzione OCR, l'IA può richiedere una nuova scansione: l'utente sceglie le pagine, la nuova scansione viene eseguita localmente (nessun nuovo destinatario esterno) ed entrambe le versioni del testo vengono predisposte nello spazio temporaneo locale; ciò che l'IA legge da esse confluisce al suo fornitore come qualsiasi altro risultato di uno strumento. Come estrema e ultima risorsa — solo dopo una tale nuova scansione e solo entro limiti rigidi imposti dal ponte (≤ 10 MB, ≤ 90 pagine) — l'IA può chiedere all'utente di consegnarle il file PDF originale: IRONSTICK si limita ad aprire la voce; l'utente stesso salva il PDF tramite l'icona della graffetta e lo trascina nella chat dell'IA desktop. In tal modo il documento viene trasferito come file (compresi timbri, firme e immagini) al fornitore di tale IA — ciò avviene esclusivamente per azione propria e consapevole dell'utente, mai automaticamente, e i documenti contrassegnati come segreti sono esclusi fin dall'inizio dall'intero canale di nuova scansione.
• Spazio temporaneo IA locale (minimizzazione dei dati). Qualsiasi chiamata di strumento può deviare il proprio risultato completo in un file temporaneo locale ed effimero (to_scratch); l'IA riceve allora solo il percorso del file più una breve anteprima (≈1.200 caratteri) invece del testo integrale. Gli strumenti di modifica locali (ricerca/sostituzione/inserimento/confronto/normalizzazione) rielaborano tali file sulla macchina dell'utente, e gli strumenti di consegna/aggiornamento li utilizzano tramite il percorso — contenuti di grandi dimensioni possono così essere trasportati e rielaborati senza essere affatto trasmessi al fornitore di IA. Le estrazioni complete dei casi (dump_case_to_scratch) e il protocollo di avvio della sessione in un'unica chiamata vengono parimenti scritti direttamente in quest'area locale; al suo fornitore confluiscono solo le porzioni che l'IA legge successivamente. IRONSTICK sorveglia inoltre l'attualità di tali file e li invalida quando i dati sottostanti cambiano. La cartella temporanea si trova all'interno della cartella dei dati e persiste tra le sessioni (costituisce il contesto di lavoro dell'IA); i file non utilizzati vengono eliminati dopo 180 giorni e non viene creato alcun nuovo destinatario esterno.
• La memoria temporanea è una cassaforte cifrata (da settembre 2026). Ogni file nella memoria temporanea è cifrato a riposo con AES-256, con la stessa derivazione della chiave utilizzata per la banca dati e l'archivio dei documenti. Lettura e scrittura passano esclusivamente attraverso il varco di IRONSTICK; un file in chiaro collocato nella memoria temporanea per qualsiasi altra via (uno strumento del file system dell'IA desktop, una copia manuale) viene rifiutato, rimosso e segnalato all'IA come violazione delle regole; i file lasciano la memoria temporanea solo tramite la finestra di dialogo di esportazione di IRONSTICK, mai verso una cartella di download. Insieme alla banca dati cifrata, all'archivio dei documenti e al file di configurazione, ciò colma l'ultima lacuna sulla macchina locale: nessun dato dei casi si trova non cifrato sul disco dell'utente — nemmeno i file di lavoro dell'IA. Un disco copiato, una chiavetta smarrita o un archivio di backup finito in mani sbagliate restituiscono solo testo cifrato.
• I risultati degli strumenti vengono consegnati al client di IA desktop dell'utente e da questo al relativo fornitore: Anthropic per Claude (nell'ambito dell'abbonamento Claude dell'utente e delle condizioni di Anthropic), OpenAI per ChatGPT (nell'ambito dell'abbonamento ChatGPT dell'utente e delle condizioni di OpenAI), Alibaba Cloud/Qwen per Qwen Desktop (nell'ambito dell'account Qwen dell'utente e delle condizioni di Qwen) oppure Moonshot AI per Kimi Desktop (nell'ambito dell'account Kimi dell'utente e delle condizioni di Moonshot AI). IRONSTICK non scrive righe nel registro di audit per il traffico del ponte; la barra superiore mostra un logo pulsante per ogni IA attiva (marchio Claude, marchio ChatGPT, marchio Qwen, marchio Kimi) — l'accesso simultaneo è possibile e ciascuno viene segnalato separatamente. Il ponte stesso tiene un log diagnostico puramente locale delle proprie chiamate di strumenti — data e ora, nome dello strumento, esito positivo/negativo e dimensione della risposta, mai alcun contenuto — in un file in chiaro accanto al programma del ponte. Tale log non viene trasmesso da nessuna parte e serve esclusivamente alla risoluzione dei problemi.
• La memoria IA condivisa conserva localmente conoscenze distillate (≤1.000 caratteri ciascuna, legate al cliente/caso, a scadenza automatica); il suo contenuto è visibile a ogni canale IA e viene trasmesso ogniqualvolta tali canali lo leggono.
• La revisione reciproca tra le IA desktop si svolge attraverso IRONSTICK, non direttamente tra i fornitori: un'IA deposita un prodotto del lavoro (ad es. una bozza) in una memoria di scambio locale e di breve durata (file in chiaro sulla macchina dell'utente, cancellati alla chiusura del compito e rimossi completamente a ogni riavvio dell'app) insieme a una nota di compito; l'altra IA lo legge quando l'utente glielo indica. Ciò non crea alcun nuovo destinatario esterno — ciò che l'IA revisore legge viene trasmesso al proprio fornitore esattamente come qualsiasi altro risultato di uno strumento sopra descritto, nell'ambito delle condizioni di tale fornitore. I contenuti non passano mai da un fornitore all'altro.

5. Il pacchetto di istruzioni IA (ZIP di esportazione)

La creazione del pacchetto è locale e non comporta alcuna chiamata IA. Essa produce Markdown in chiaro (senza pseudonimizzazione) destinato a essere caricato dall'utente su un LLM esterno di sua scelta. Contenuto:

I documenti contrassegnati come segreti sono esclusi dalle scadenze, dai protocolli giornalieri e dai dossier dei casi.

6. Matrice riepilogativa

7. Servizi esterni non LLM (per completezza)

Indipendentemente da qualsiasi LLM, le seguenti funzioni contattano servizi esterni con i dati minimi necessari: convalida di numeri (EU VIES, EORI, GLEIF, registri delle imprese — il numero oggetto di verifica), geocodifica degli indirizzi (OpenStreetMap Nominatim — l'indirizzo), le interrogazioni web dirette della ricerca su persone (il nome), IMAP (il Suo server di posta) e le esportazioni facoltative verso Google Drive (i file esportati). Nessuno di questi coinvolge il fornitore di IA.

Due ulteriori servizi ricevono dati parimenti minimi:

• ipwho.is (localizzazione geo-IP) — una volta per ogni avvio del programma, nell'ambito dell'istantanea di sicurezza locale (sezione 8), IRONSTICK chiede a questo servizio l'indirizzo IP pubblico della macchina e una localizzazione approssimativa (città, paese, ISP). La richiesta HTTPS in uscita non contiene alcun contenuto personale di alcun tipo — come qualsiasi server web, il servizio vede solo l'indirizzo IP da cui la richiesta proviene. La risposta viene memorizzata esclusivamente in locale e non viene trasmessa da nessun'altra parte.
• Open-Meteo (meteo) — su richiesta, lo strumento meteo dell'IA (get_weather, sezione 4.8) interroga i dati meteorologici attuali per un luogo indicato. Vengono trasmessi solo il nome del luogo / le sue coordinate — mai dati relativi a casi, clienti o persone.

Nessuno di questi servizi coinvolge il fornitore di IA.

8. Archiviazione locale, integrità e controllo da parte dell'utente

Indipendentemente dai canali IA sopra descritti, quanto segue si applica a tutti i dati detenuti da IRONSTICK:

• Archiviazione esclusivamente locale. L'intero insieme di dati — banca dati, file dei documenti, contenuti multimediali, trascrizioni, configurazione — risiede in un'unica cartella dei dati in un percorso definito dall'utente. IRONSTICK non richiede alcun account cloud e non gestisce alcun server; il produttore non detiene mai una copia di alcun dato dell'utente. Laddove uno studio utilizzi il server facoltativo IRONSTICK SERVER (sezione 9), anche tale server è un dispositivo proprio dello studio nella rete propria dello studio — nulla cambia per quanto riguarda l'accesso del produttore.
• Banca dati cifrata a riposo (AES-256). La banca dati — l'archivio di clienti, casi, cronologia, e-mail, scadenze, testi delle trascrizioni e memoria delle IA — è memorizzata in forma cifrata con AES-256, ogni pagina singolarmente e con un sigillo di integrità per ogni pagina. La chiave viene derivata dall'applicazione in fase di esecuzione e non viene mai scritta su disco né nella configurazione, cosicché un file della banca dati ottenuto dal supporto o da un archivio di backup non restituisce nulla senza IRONSTICK. Si tratta di una misura tecnica ai sensi dell'art. 32 GDPR che si applica senza alcuna configurazione da parte dell'utente e non può essere disattivata.
• Documenti cifrati a riposo (AES-256). L'archivio dei documenti — i PDF originali, le scansioni, le immagini, i file audio e di trascrizione — è cifrato allo stesso modo, file per file, con un sigillo di integrità che rileva le alterazioni. La lettura avviene attraverso un unico varco che decifra il file richiesto in una copia di lavoro temporanea e rimuove tali copie alla chiusura o all'avvio dell'applicazione. I backup e i pacchetti dei casi contengono i documenti in forma cifrata. Limiti, dichiarati apertamente: le copie di lavoro della sessione corrente sono in chiaro nella cartella temporanea (su Android tale cartella si trova nella memoria condivisa); le esportazioni e la posta in uscita sono in chiaro per scelta progettuale; e la cifratura protegge dalla lettura del supporto al di fuori di IRONSTICK, non da un utente autorizzato dell'applicazione.
• Controllo degli accessi all'avvio (TOTP). Una volta accettata la chiave di licenza, l'applicazione non mostra altro che una richiesta di codice finché l'utente non inserisce il codice monouso a sei cifre basato sul tempo corrente, generato da un'app di autenticazione (RFC 6238). Il segreto alla base dei codici viene derivato dalla chiave di licenza in fase di esecuzione e non viene mai scritto su disco; viene memorizzata solo un'impronta non segreta della configurazione confermata, affinché il codice QR venga mostrato nuovamente dopo un cambio di chiave. Codici errati ripetuti comportano un'attesa crescente. I ponti IA desktop non ricevono alcun dato dei casi mentre l'applicazione è bloccata. Il ripristino avviene mediante la chiave di licenza, il che rende la chiave di licenza la credenziale principale dell'installazione — la sua custodia è responsabilità del gestore. Il file di configurazione (chiavi API, credenziali e-mail, accesso al server) è conservato cifrato con AES-256 con lo stesso meccanismo dei documenti e viene decifrato esclusivamente in memoria.
• Percorso di archiviazione controllato dall'utente. Il percorso dei dati viene scelto durante l'installazione e può essere modificato in qualsiasi momento — anche verso un supporto rimovibile quale un'unità USB cifrata o un disco esterno cifrato. L'applicazione si limita a seguire il percorso configurato; la cifratura del supporto (ad es. con la cifratura del disco del sistema operativo) è nelle mani dell'utente ed è raccomandata per i supporti portatili. Una conseguenza da ponderare consapevolmente: se la cartella dei dati prescelta si trova all'interno di una cartella sincronizzata con il cloud (ad es. Google Drive), l'intero insieme di dati compreso il file di configurazione con la chiave di accesso IA e le credenziali e-mail viene sincronizzato con tale fornitore di cloud secondo le condizioni proprie di quest'ultimo — collocarvi la cartella dei dati è una decisione e una responsabilità dell'utente.
• Sincronizzazione dei dispositivi senza alcun cloud. La sincronizzazione facoltativa Windows ↔ tablet Android avviene tramite un collegamento diretto con cavo USB — non è coinvolto alcun servizio di terzi, i trasferimenti sono verificati mediante somma di controllo e viene eseguito un backup obbligatorio prima che la banca dati venga sostituita. I documenti contrassegnati come segreti non vengono mai trasferiti al tablet in alcun caso.
• Istantanea di sicurezza all'avvio (registro locale degli accessi). A ogni avvio del programma, IRONSTICK registra in background un'istantanea della macchina su cui è in esecuzione: nome host, sistema operativo, RAM/CPU, indirizzo IP locale, browser predefinito, strumenti di accesso remoto in esecuzione da esso rilevati e un punteggio di sicurezza derivato — più, una volta per ogni avvio, l'indirizzo IP pubblico e la localizzazione approssimativa (città, paese, ISP) ottenuti dal servizio geo-IP ipwho.is (sezione 7). L'istantanea viene memorizzata esclusivamente in locale nella banca dati (tabella T9_LoginLog) e non viene trasmessa da nessuna parte. La conservazione è limitata automaticamente a un massimo di 6 mesi e a un massimo di 1.000 voci (manutenzione giornaliera), e l'utente può consultare il registro in qualsiasi momento nel configuratore (scheda «Login log»).
• Impronte di integrità su ogni file registrato. Al momento della registrazione, ogni file memorizzato riceve un'impronta crittografica del contenuto (SHA-256 per documenti e contenuti multimediali; un'impronta MD5 preesistente per i file audio delle trascrizioni), registrata nella banca dati accanto alla voce. Qualsiasi successiva modifica di un file memorizzato è pertanto rilevabile confrontando il file con la sua impronta registrata, e le esportazioni e-discovery (EDRM) contengono tali impronte affinché i destinatari possano verificare i file in modo indipendente. Ciò rende evidente la manipolazione; come qualsiasi meccanismo di impronta, non impedisce fisicamente le modifiche ai file sul disco — le rende dimostrabili.
• Backup a discrezione dell'utente. Una funzione di backup integrata scrive una copia completa dei dati (backup completo o backup dei soli dati) come un unico archivio ZIP in qualsiasi destinazione selezionata dall'utente, ed effettua il ripristino da tale archivio su richiesta. La frequenza dei backup, il luogo in cui sono conservati, la durata della loro conservazione e l'eventuale cifratura aggiuntiva degli archivi sono interamente decisione dell'utente (la banca dati e i file dei documenti all'interno di ogni archivio sono in ogni caso cifrati con AES-256) — IRONSTICK non impone alcuna pianificazione e non trasmette i backup da nessuna parte.
• I documenti generati appartengono all'utente. L'utente può generare documenti in qualsiasi momento — atti processuali, lettere, dossier, elenchi, esportazioni — e scaricarli: essi vengono scritti nella cartella Documenti locale oppure, laddove l'utente abbia collocato la cartella dei dati in una cartella di Google Drive o selezioni espressamente Google Drive come destinazione, nell'account Google Drive proprio dell'utente. Il ruolo di IRONSTICK termina con la produzione del file. Qualunque cosa accada a un documento generato successivamente — stampa, deposito presso un tribunale, invio per e-mail, caricamento su qualsiasi servizio, condivisione con terzi — è compiuta dall'utente e rientra esclusivamente nella responsabilità dell'utente.

9. Il server LAN dello studio facoltativo (IRONSTICK SERVER)

Gli studi con più postazioni IRONSTICK possono utilizzare il server facoltativo IRONSTICK SERVER — un servizio di coordinamento eseguito sul NAS Synology proprio dello studio, all'interno della rete locale propria dello studio. Ai fini della presente dichiarazione i fatti determinanti sono:

• Non è coinvolto alcun soggetto esterno. Il server è un dispositivo proprio dello studio. Accetta connessioni solo da indirizzi di rete privati (locali) e non avvia mai alcuna connessione verso Internet — nessuna telemetria, nessuna verifica di aggiornamenti, nessun contatto con il produttore. Il produttore del software non ha alcun accesso di alcun tipo.
• Nessun coinvolgimento dell'IA. Il server non veicola traffico IA, non memorizza alcuna chiave IA e non comunica mai con alcun fornitore di modelli linguistici. Tutti i canali IA descritti nelle sezioni 1–6 restano rigorosamente riferiti alla singola postazione; il livello di pseudonimizzazione, i controlli del consenso e il registro di audit non sono influenzati dalla presenza del server.
• Che cosa memorizza il server — tutto sul NAS, sotto il controllo dello studio: (a) pacchetti di casi condivisi — solo i casi che un utente ha espressamente reso disponibili ai colleghi; i documenti contrassegnati come segreti sono esclusi per scelta progettuale e non raggiungono mai il server; (b) la biblioteca giuridica centrale — testi normativi pubblici in formato Markdown, ciascuno con il nome dell'utente che lo ha fornito, il link alla fonte e la data di revisione; (c) registrazioni dei tempi di lavoro — per utente, giorno e caso: numero del caso, nome del cliente e minuti, comunicati da ciascuna postazione in background; (d) totali di presenza per utente e giorno, derivati dai segnali periodici di sessione; (e) metadati degli eventi dei casi — condivisioni, revoche, inizi/fini di abbonamento ed esportazioni, ciascuno con data, ora e indirizzo IP LAN; (f) un registro di sicurezza con eventi amministrativi e di accesso, compresi gli indirizzi IP LAN; (g) plichi di consegna dei casi — quando un utente trasferisce la titolarità di un caso a un collega, il caso completo viaggia come un unico archivio attraverso un'area di parcheggio del server («spool»); il plico viene cancellato dal server dopo che il destinatario ha confermato l'importazione, e i documenti contrassegnati come segreti viaggiano solo dopo un'ulteriore conferma espressa del titolare (altrimenti il trasferimento viene interrotto); (h) l'acquisizione centrale delle scansioni (Central Scan App facoltativa): un registro dei numeri dei casi e del nome visualizzato di ciascun utente (comunicati dalle postazioni come materiale di abbinamento — mai contenuti dei casi) e uno spool di documenti per singolo file che conserva la posta in entrata scansionata indirizzata a un utente finché la postazione di tale utente non l'ha prelevata e confermata, dopodiché la copia sul server viene cancellata; il riconoscimento del testo e l'abbinamento del destinatario avvengono localmente sulla postazione di scansione, senza alcuna IA; (i) registrazioni degli eventi di backup — ciascuna postazione comunica i propri eventi di backup e di ripristino dei dati (tipo, nome del file, dimensione, ora, IP LAN), cosicché l'amministratore può vedere per ciascun utente quando è stato eseguito l'ultimo backup e sollecitare gli utenti in ritardo; (j) l'elenco delle parti dell'intero studio («rete delle entità») — le anagrafiche di persone e società, istituzioni, le relazioni tra di esse e le analisi delle persone tenute dalle postazioni, unitamente alla coda delle proposte di modifica scambiate tra gli utenti. Si veda il punto successivo.
• L'elenco delle parti dell'intero studio. Non appena una postazione è collegata al server, i suoi dati anagrafici delle parti (chi è chi: nomi, identificativi, dati di contatto, relazioni, analisi delle persone) vengono caricati automaticamente e replicati su ogni altra postazione dello stesso studio, cosicché ciascun avvocato vede con chi lo studio ha già a che fare e lo studio ottiene una visione dei conflitti di interesse a livello dell'intero studio. Ogni anagrafica ha esattamente un titolare — l'utente che l'ha inserita per primo; tutti gli altri utenti detengono una copia di sola lettura e possono soltanto inviare una proposta di modifica, che il titolare accetta o respinge nel monitor dei dati. Se il titolare non è raggiungibile per 48 ore, la titolarità passa all'utente proponente. I contenuti dei casi non fanno parte di questo elenco — documenti, cronologia, corrispondenza e assegnazioni ai casi restano disciplinati dalle azioni esplicite di condivisione e di consegna qui descritte. Lo scambio rimane all'interno dello studio (un unico titolare del trattamento), non lascia mai la rete locale e non coinvolge alcun fornitore di IA: il rilevamento dei duplicati e il confronto dei campi vengono eseguiti come semplice logica di programma sulla postazione mittente; il server si limita a memorizzare e inoltrare. Gli studi dovrebbero menzionare questa condivisione interna dei dati delle parti e delle analisi delle persone nel proprio registro delle attività di trattamento.
• Solo azioni consapevoli — per i contenuti dei casi. I contenuti dei casi raggiungono il server esclusivamente tramite un'azione esplicita di condivisione o di consegna confermata dall'utente; i testi della biblioteca giuridica solo dopo che l'utente ha accettato la voce nel monitor dei dati; la posta in entrata scansionata solo dopo che l'addetto di segreteria ha esaminato il documento e ha cliccato su invio a un destinatario prescelto. L'elenco delle parti sopra descritto costituisce l'unica eccezione deliberata: si sincronizza in background senza una conferma per singola anagrafica. Le registrazioni di tempi, presenze, eventi e backup sono metadati operativi generati dal funzionamento multiutente stesso e sono visibili all'amministratore dello studio nell'amministrazione web.
• Titolarità del trattamento. Lo studio che gestisce il server rimane l'unico titolare del trattamento. L'amministratore controlla l'approvazione delle registrazioni, può porre fine agli abbonamenti, cancellare voci della biblioteca giuridica e disinstallare il pacchetto — il che lascia la cartella dei dati del server sotto il controllo dell'amministratore sul NAS.
• Nomi completi dei clienti nelle registrazioni dei tempi. La panoramica dei tempi di lavoro mostra il tempo di lavoro per caso e per cliente, il che significa che i nomi dei clienti sono memorizzati sul NAS. Ciò rimane all'interno dell'infrastruttura propria dello studio e del suo regime di riservatezza esistente — ma gli studi dovrebbero includere il NAS nel proprio inventario delle misure tecniche e organizzative (controllo degli accessi su DSM, cifratura dei volumi, politica di backup), esattamente come farebbero per qualsiasi file server dello studio.

Allegato — Clausola tipo per la Sua informativa privacy ai clienti (proposta)

Il testo che segue è una proposta di redazione che uno studio legale che utilizza IRONSTICK può riprendere nella propria informativa privacy ai clienti. È redatto in modo da corrispondere fedelmente ai flussi di dati sopra descritti — non promette una protezione maggiore di quella che il software fornisce effettivamente. Evita deliberatamente citazioni di articoli di legge, affinché possa essere inserito in informative di qualsiasi struttura.

Italiano

La presente dichiarazione è stata ricavata dal codice sorgente dell'applicazione (pseudonimizzatore, router esterno, registro di audit e percorso di trasmissione di ciascuna funzione) e rispecchia il comportamento della versione descritta così come distribuita. Il trattamento da parte del fornitore di IA stesso — conservazione, utilizzo per l'addestramento, sub-responsabili del trattamento, giurisdizione — è disciplinato esclusivamente dalle condizioni del fornitore — i link alle condizioni e all'informativa sulla privacy di ciascun fornitore si trovano nella sezione corrispondente della configurazione IA (Google Antigravity: antigravity.google/terms; Alibaba Cloud: alibabacloud.com/help/en/legal; Moonshot AI: platform.kimi.ai/docs/agreement; OpenAI: openai.com/policies). Per i servizi di Anthropic si consultino, nelle rispettive versioni vigenti: i Commercial Terms of Service (anthropic.com/legal/commercial-terms), la Usage Policy (anthropic.com/legal/aup) e la Privacy Policy (anthropic.com/legal/privacy).