Dove vive realmente la memoria della sua IA?
Uno strato di memoria è un database di tutto ciò che ha detto a un assistente. Quindi la cosa più sensibile del suo stack, e la meno documentata.
Guardi che cosa si accumula in una memoria IA dopo tre mesi di uso reale: nomi di clienti, clausole di contratto, discussioni sullo stipendio, l'architettura di sistemi di cui è responsabile, quel dettaglio medico citato una volta per spiegare un ritardo. Non è una cache. È un dossier, e lo ha costruito essendo utile a se stesso.
Ora risponda a tre domande al riguardo. In quale paese si trovano quei dati? Chi può leggerli? Che ne sarà se l'azienda chiude l'anno prossimo? La maggior parte dei prodotti di memoria non rende facili da trovare queste risposte, e qualcuno alla prima non sa proprio rispondere.
Che cosa dice davvero il GDPR (e che cosa non dice)
Il GDPR non vieta di archiviare dati fuori dall'Europa, e chi le vende «hosting UE o è illegale» sta esagerando. Ciò che richiede è una base giuridica, la limitazione della finalità, una sicurezza proporzionata al rischio e — quando dati personali lasciano lo SEE — un meccanismo di trasferimento valido con garanzie che reggano davvero.
È quest'ultimo punto a diventare scomodo. In Schrems II la Corte di giustizia ha invalidato il Privacy Shield e ha chiarito che una clausola contrattuale non serve se il diritto sulla sorveglianza del paese di destinazione le passa sopra. Le raccomandazioni successive dell'EDPB hanno spinto i titolari verso misure tecniche supplementari, il che in pratica spesso significa: lo tenga in Europa, oppure lo cifri in modo che il fornitore non possa leggerlo.
Due conseguenze che contano quando sceglie un servizio di memoria:
- Se è un'azienda che tratta dati di clienti, l'archivio di memoria è un sub-responsabile. Le serve un DPA, e le serve sapere dove gira — non per purezza, ma perché i suoi clienti lo chiederanno.
- Se è un privato, niente di tutto questo è un obbligo giuridico per lei. Resta comunque la differenza tra dati sotto giurisdizione europea e dati sotto quella di qualcun altro.
«Conforme al GDPR» è un'affermazione, non un certificato
Non esiste un organismo di certificazione GDPR che rilasci badge. Quando un fornitore scrive «conforme al GDPR» su una pagina dei prezzi, è un'autodichiarazione. Può essere del tutto vera. Non è una prova.
SOC 2 e ISO 27001 *sono* invece sottoposti ad audit, e valgono qualcosa — ma verificano che un'azienda faccia ciò che dice di fare, non dove siano i suoi byte né se quella risposta le convenga. Un rapporto SOC 2 Type 2 e un hosting esclusivamente statunitense convivono perfettamente.
Quindi ignori i badge e chieda cose concrete:
- In quale paese si trovano il database di produzione e i suoi backup? Nomini il fornitore e la regione.
- Chi ha accesso tecnico al testo in chiaro, con quale procedura, e quell'accesso è registrato?
- C'è un DPA che posso firmare, ed elenca i sub-responsabili?
- Come viene imposto l'isolamento tra clienti: dal codice applicativo o dal database?
- Cifratura a riposo: a livello di disco, oppure il fornitore non può leggere affatto le mie righe? Sono garanzie molto diverse.
- Se me ne vado: formato di export, tempi di cancellazione, e la cancellazione riguarda anche i backup?
Un fornitore che non sa rispondere a sei domande fattuali sulla propria infrastruttura le ha detto qualcosa di utile.
La domanda sull'isolamento che nessuno pone
I servizi multi-tenant tengono separati i clienti in uno di due modi. O il codice applicativo filtra per cliente a ogni query, oppure è il database stesso a rifiutarsi di restituire le righe di un altro tenant.
Il primo è normale e funziona — finché una query su diecimila non dimentica il filtro. Quella famiglia di bug sta dietro a una buona parte degli incidenti «abbiamo visto i dati di un altro utente» di cui ha letto. Il secondo costa di più da costruire e fallisce dalla parte giusta: un filtro mancante non restituisce nulla, invece dei ricordi di qualcun altro.
È una domanda legittima, e la risposta le dice come il team ragiona sulla modalità di guasto.
Zero-knowledge: utile, raro e ampiamente descritto male
La risposta più forte possibile è che il fornitore non detiene alcuna chiave e matematicamente non può leggere i suoi dati. Pochissimi prodotti di memoria lo offrono, per una ragione noiosa: la ricerca semantica deve calcolare sul contenuto. Può cifrare blob che il server non legge, ma qualcosa deve comunque calcolare l'embedding e il ranking, e quel qualcosa ha bisogno del testo in chiaro — sul suo dispositivo, o per niente.
Quindi quando vede «cifrato end-to-end» su un servizio di memoria che fa anche ricerca semantica lato server, legga con attenzione. Spesso significa TLS in transito e cifratura a riposo con una chiave detenuta dal fornitore. È un'architettura ragionevole. Non è zero-knowledge, e i due termini vengono confusi di continuo — anche, per essere schietti, nei testi di marketing di tutta questa categoria.
Che cosa facciamo, e che cosa no
Pryzm gira su Hetzner, in Germania, su un volume cifrato. Ogni cliente ha il proprio schema e il proprio ruolo PostgreSQL, quindi l'isolamento è imposto dal motore del database e non dal nostro codice. In più, i ricordi di ogni account sono cifrati con la chiave propria dell'account (AES-256-GCM), bloccata dalla password e da una frase di recupero. I backup sono cifrati e restano in Europa. La giurisdizione è europea e non c'è una capogruppo statunitense nella catena.
Ciò che non rivendichiamo: lo zero-knowledge. Mentre è connesso, il server tiene la sua chiave in memoria e decifra i suoi ricordi per rispondere alla sua IA: la ricerca semantica ha bisogno del testo in chiaro da qualche parte. L'accesso amministrativo tecnico ai server esiste, è limitato e registrato. Se le serve un fornitore che non possa mai leggere i suoi dati, la risposta onesta è l'auto-hosting.
Se preferisce non fidarsi di alcun fornitore, diversi server di memoria auto-ospitabili sono buoni e gratuiti, e li elenchiamo nel nostro confronto con le alternative. Ospitarlo da sé è la risposta più forte a tutto questo articolo.