Realizzato in UE, e dove stanno i tuoi dati

Dove viene sviluppato Nessie, dove stanno i tuoi dati e cosa controlli quando lo ospiti da te.

Chi lo costruisce e sotto quale legge

Nessie è costruito da UnlikeOtherAI s.r.o., una società registrata nella Repubblica Ceca e operante secondo il diritto ceco.

Questa pagina descrive come è costruito il software e dove viene eseguito. Non è una dichiarazione di conformità: Nessie non possiede alcuna certificazione di sicurezza e nulla qui va letto come tale. Quali dati personali vengono trattati e su quale base è l’oggetto dell'informativa sulla privacy, che è una pagina separata.

Dove gira il prodotto in hosting

Nessie Cloud gira su fornitori di hosting europei — Scaleway, Hetzner e altri. Scegliamo il servizio migliore che ciascun fornitore offre, quindi parti diverse del prodotto possono girare con fornitori diversi, tutti in Europa.

Qualsiasi indicazione più precisa di questa — un sito, una città o un data center specifico — non viene riportata di proposito, perché diventerebbe obsoleta senza che nessuno se ne accorga.

Con il self-hosting la scelta è tua

Dove gira un’istanza self-hosted è un’impostazione di installazione, non un’impostazione del prodotto. Il percorso su una singola macchina è uno stack Docker Compose che installi sulla macchina che scegli tu. Nell’albero Terraform per un cloud gestito, la regione è un input senza alcun valore predefinito: nulla lì può essere indovinato, quindi nulla lì ha un valore predefinito, e il database, il bucket di object storage e i servizi seguono tutti la regione che indichi.

Per la stessa questione contano due dettagli strutturali. La coda e il trasporto in tempo reale sono entrambi PostgreSQL: non ci sono Redis né message broker nel percorso, quindi non c’è un terzo sistema da collocare. E l’object storage è compatibile con S3 invece di essere legato a un solo fornitore; la distribuzione di riferimento esegue MinIO in un container su una rete privata, senza alcun ingresso proprio. Le parti che devono risiedere da qualche parte sono il database, l’object store e i due servizi Node, e risiedono tutte dove le metti tu. Come metterli in piedi è spiegato nella pagina di installazione.

Che cosa conserva Nessie — e che cosa deliberatamente non conserva

L’identità non viene copiata

Con l’accesso tramite UnlikeOtherAI, il provider di identità gestisce e conserva l’identità delle persone — fattori di autenticazione, profili, appartenenza a organizzazioni e team, e inviti. Nessie è una relying party, non un secondo sistema di identità. È una scelta sui dati tanto quanto un’architettura: un’identità che Nessie non conserva è un’identità che non può perdere, far trapelare o dimenticare di cancellare.

Quello che la tabella users conserva davvero è l’identificativo utente stabile del provider — la chiave attraverso cui si risolve tutto il resto — l’indirizzo email, una copia non autorevole di nome visualizzato e avatar, e campi locali al prodotto (preferenze, pronomi, una versione del token usata per revocare le sessioni). La copia esiste solo per poter mostrare un nome e un’immagine senza una richiesta per ogni riga, e viene risincronizzata dai claim verificati del provider all’accesso, al cambio di team e al rinnovo della sessione. Nulla inventa un valore: una persona che il provider non ha nominato compare con il proprio indirizzo email finché non lo fa. Un hash della password esiste solo per il proprietario di bootstrap di un’installazione senza alcun provider di identità.

Lo stesso vale per la struttura. Un’organizzazione del provider è un’organizzazione Nessie, legata all’id di organizzazione del provider; un team senza collegamento a monte risponde 404 TEAM_NOT_LINKED invece di ripiegare su un’ipotesi locale, e una lettura dell’elenco dei membri in tempo reale va al provider di identità e non salva nulla.

Due copie non sono ancora sparite, e sarebbe disonesto lasciar intendere il contrario. I nomi di organizzazione e team sono ancora salvati in locale accanto agli id di collegamento, e le righe di appartenenza locali autorizzano ancora le richieste ordinarie tra una sincronizzazione e l’altra. Eliminarle entrambe è un lavoro aperto e tracciato nel repository, non qualcosa di già concluso.

Niente di commerciale

Il servizio di fatturazione centrale gestisce i pagamenti. Nessie non conserva alcun cliente, abbonamento, fattura, prezzo, saldo di crediti, politica di ricarica, consenso di pagamento, estratto conto o stato di disdetta del fornitore di pagamenti, e non calcola le tariffe. Legge valori già pronti per la visualizzazione e li mostra.

Segreti

Per conservare un segreto serve un vault configurato. Di proposito non esiste alcun ripiego sul database né un percorso in chiaro: senza un vault, salvare, ruotare e revocare un segreto restituiscono un errore invece di degradare verso qualcosa di meno sicuro. I registri propri di Nessie per un segreto non contengono alcun valore, testo cifrato, chiave o token del vault — solo un riferimento opaco e i suoi metadati — e i percorsi nel vault sono costruiti solo da identificativi strutturali, mai dal nome di un’organizzazione, di un team, di un progetto o di una persona.

Le credenziali che Nessie deve conservare in proprio per agire come client OAuth — credenziali di connettori e caselle di posta, segreti dei webhook, materiale di rinnovo delle sessioni, payload degli executor — sono sigillate in buste AES-256-GCM legate a uno scopo, sotto un portachiavi versionato che è una radice separata dal segreto di firma delle sessioni, con una procedura di rotazione documentata.

C’è anche una regola sui modelli: l’esistenza di un segreto può essere nota e il suo uso può essere autorizzato, ma il materiale segreto non deve entrare nel contesto del modello, nei prompt, negli argomenti degli strumenti, nei risultati degli strumenti, nella memoria, negli embedding, nella ricerca, nei log o nei messaggi. A un agente si può concedere la possibilità di usare un segreto. Non gli si può mai concedere la possibilità di rivelarlo.

Il fatto che i dischi sottostanti siano cifrati dipende dalla macchina su cui gira l’installazione. Il repository non stabilisce la cifratura a livello di volume per i volumi del database e dell’object storage, quindi questa pagina non la dichiara.

Isolamento dei tenant

Nessie è multi-tenant per progetto: un solo database, in cui ogni riga appartiene a una sola organizzazione e ogni tabella figlia ha una colonna organization_id. L’isolamento è garantito in due punti — la clausola di ambito che ogni query porta con sé e le vere chiavi esterne su quella colonna, aggiunte con quarantadue vincoli dopo che un audit interno aveva trovato la colonna presente ma priva di vincoli su decine di tabelle.

Una suite di conformità mantiene in vigore questa invariante al confine HTTP. Crea un attaccante con il massimo dei privilegi — pieno proprietario della propria organizzazione — e verifica che ogni lettura canonica delle risorse di un’altra organizzazione risponda 403, 404 o vuoto, e che ogni modifica canonica venga respinta lasciando intatta la riga dell’altra organizzazione. Copre canali, approvazioni, registro di audit, trigger, agenti e i loro collegamenti, esecuzioni, progetti, attività, thread, connessioni, installazioni di workflow, istanze MCP, la knowledge base e gli avvisi.

Per precisione sul meccanismo: si tratta di applicazione a livello di applicativo più chiavi esterne, non di row-level security di PostgreSQL. Non c’è alcuna policy RLS né una protezione lato database, e la suite di conformità gira su un archivio in memoria fedele e non su un database reale, quindi dimostra le clausole di ambito che il codice scrive, non l’SQL che un server esegue. Lo dice la documentazione stessa della suite nel repository, e lo dice anche questa pagina.

Il registro di audit

Ogni azione rilevante viene registrata: chi ha agito e in quale veste — una persona, un agente, un servizio — che cosa ha fatto, su quale risorsa, in quale organizzazione, progetto, team o canale, se è riuscita o è stata negata, perché, e l’id della richiesta, l’indirizzo e lo user agent con cui è arrivata.

Il registro è di sola aggiunta per progettazione e non c’è modo di scrivervi dall’esterno: POST /api/audit-log non esiste, ed è voluto. Le voci sono concatenate — ognuna porta un digest SHA-256 dei propri campi canonici più il digest della voce precedente di quell’organizzazione — quindi una riga modificata o rimossa spezza la catena ed è rilevabile. Un proprietario o un admin dell’organizzazione può percorrere quella catena su richiesta e gli viene indicato dove si è spezzata per la prima volta, se è accaduto.

Due precisazioni oneste. La catena rende il registro a prova di manomissione evidente, non immune alle manomissioni: dietro non ci sono né la revoca della scrittura a livello di database né uno storage write-once, quindi la garanzia è il rilevamento, non la prevenzione. E le voci vengono conservate a tempo indeterminato per impostazione predefinita — la conservazione configurabile con esportazione prima della cancellazione è progettata, non realizzata. Alle voci è inoltre vietato contenere segreti o corpi completi delle richieste, e un insieme fisso di nomi di campi di metadati sensibili viene oscurato in ingresso.

Il registro dei costi

Ogni invocazione di un modello viene registrata a carico dell’organizzazione, e dell’utente, del team, del progetto, del canale, dell’agente e dell’esecuzione da cui proviene, con i token consumati e, affiancati, sia il costo riportato dal provider sia la stima propria di Nessie. Una metrica che il provider non riporta viene salvata come null invece di essere indovinata. I report sono leggibili da un proprietario o da un admin dell’organizzazione.

Questo registro è telemetria operativa — quanto ha speso un’organizzazione e per conto di chi. Non è una fattura e non è un’autorità di fatturazione.

Terze parti, quando usi il prodotto in hosting

Un’installazione in hosting comunica con un insieme ristretto e fisso di servizi. Il traffico dei modelli e la ricerca web non vanno direttamente ai provider: escono entrambi da un unico gateway gestito da UnlikeOtherAI, dove si trovano i provider a monte dei modelli e della ricerca. L’accesso e la fatturazione vanno all’authenticator di UnlikeOtherAI. Il vault dei segreti è self-hosted accanto all’applicazione. I link per le videochiamate generati dal server usano per impostazione predefinita il servizio pubblico Jitsi.

Quasi tutto il resto è spento finché un operatore non lo configura, e lo dichiara invece di fallire in silenzio: account Google, Microsoft e Slack collegati; email degli agenti tramite Amazon SES, che un’installazione esegue nel proprio account senza intermediari; notifiche push per mobile e browser; connettori di ricerca e di fonti per le bacheche; browser nel cloud. Due dettagli meritano di essere dichiarati perché cambiano dove vanno i dati:

• Le caselle di posta collegate restano presso il tuo provider. La posta viene letta in tempo reale dal tuo provider, tramite IMAP e SMTP o l’accesso del provider stesso; Nessie conserva la credenziale sigillata e nient’altro sull’account. Una casella che colleghi all’inbox Clienti fa eccezione: chiedi che le sue conversazioni vengano conservate con ciascun cliente, quindi vengono copiate.
• Le chiamate vocali nell’app non passano da Nessie. L’API fa da intermediario per una credenziale e il client apre da sé la connessione audio. La dettatura e le chiamate telefoniche sono diverse: il loro audio passa da Nessie ai provider di voce e di modelli che lo elaborano.

Un dettaglio sull’inferenza segue lo stesso principio: gli header firmati di identità del chiamante vengono inviati solo all’host di chat configurato, quindi puntare gli embedding a un altro endpoint non consegna mai a quell’endpoint un’asserzione di delega sulla persona il cui testo viene trasformato in embedding.

Il prodotto in hosting usa diversi provider di inferenza e sceglie tra loro per costo e qualità. Un’organizzazione potrà scegliere in Admin quali provider possono usare i suoi agenti: solo occidentali, solo europei, solo cinesi, oppure nessuna preferenza — il provider più efficiente per ogni lavoro. Un’istanza self-hosted sceglie da sé.

Se lo gestisci tu, cambia tutto questo

Ogni terza parte indicata sopra è una scelta di configurazione in un’istanza self-hosted. L’inferenza può essere puntata a qualsiasi endpoint compatibile con OpenAI, anche uno sul tuo hardware. I connettori restano spenti se non li attivi. L’accesso tramite UnlikeOtherAI è il percorso supportato, e un’installazione senza alcun provider di identità gira come un’unica organizzazione non collegata, con un proprietario di bootstrap.

È proprio questo il senso dell’impostazione: il software è lo stesso, e le decisioni su dove gira e su che cosa può raggiungere spettano a chi lo gestisce. La pagina di installazione spiega come.