Realizat în UE și locul unde se află datele dvs.

Unde este construit Nessie, unde se află datele dvs. și ce controlați atunci când îl găzduiți singuri.

Cine îl construiește și în baza cărei legi

Nessie este construit de UnlikeOtherAI s.r.o., o companie înregistrată în Republica Cehă și care funcționează conform legislației cehe.

Această pagină descrie cum este construit software-ul și unde rulează. Nu este o declarație de conformitate: Nessie nu deține nicio certificare de securitate și nimic din ce scrie aici nu trebuie înțeles ca atare. Ce date personale sunt prelucrate și pe ce temei face obiectul politicii de confidențialitate, care este o pagină separată.

Unde rulează produsul găzduit

Nessie Cloud rulează la furnizori europeni de găzduire — Scaleway, Hetzner și alții. Alegem cel mai bun serviciu oferit de fiecare furnizor, așa că părți diferite ale produsului pot rula la furnizori diferiți, toți din Europa.

Orice detaliu mai precis — un amplasament, un oraș sau un centru de date anume — nu este indicat aici în mod deliberat, pentru că ar deveni depășit fără ca cineva să observe.

Cu găzduirea proprie, alegerea vă aparține

Locul în care rulează o instanță găzduită de dvs. este o setare de implementare, nu o setare a produsului. Varianta pe o singură mașină este un stack Docker Compose pe care îl instalați pe o mașină aleasă de dvs. În arborele Terraform pentru un cloud gestionat, regiunea este o intrare fără nicio valoare implicită: nimic de acolo nu poate fi ghicit, deci nimic nu are valoare implicită, iar baza de date, bucket-ul de stocare de obiecte și serviciile urmează toate regiunea pe care o indicați.

Alte două detalii structurale contează pentru aceeași întrebare. Coada și transportul în timp real sunt ambele PostgreSQL — nu există Redis și niciun broker de mesaje pe traseu, deci nu mai există un al treilea sistem de amplasat. Iar stocarea de obiecte este compatibilă S3, nu legată de un singur furnizor; implementarea de referință rulează MinIO într-un container, într-o rețea privată, fără acces propriu din exterior. Componentele care trebuie să se afle undeva sunt baza de date, stocarea de obiecte și cele două servicii Node, iar toate se află acolo unde le puneți dvs. Cum se pune totul în funcțiune găsiți pe pagina de instalare.

Ce păstrează Nessie — și ce nu păstrează în mod deliberat

Identitatea nu este copiată

Cu autentificarea UnlikeOtherAI, furnizorul de identitate gestionează și stochează identitatea persoanelor — factorii de autentificare, profilurile, apartenența la organizații și echipe și invitațiile. Nessie este o parte de încredere (relying party), nu un al doilea sistem de identitate. Este o decizie despre date, la fel de mult cât una de arhitectură: o identitate pe care Nessie nu o stochează este o identitate pe care nu o poate scurge, pierde sau uita să o șteargă.

Tabelul users păstrează de fapt identificatorul stabil al utilizatorului la furnizor — cheia prin care se rezolvă tot restul —, adresa de e-mail, o copie neautoritară a numelui afișat și a avatarului, precum și câmpuri locale ale produsului (preferințe, pronume, o versiune de token folosită pentru revocarea sesiunilor). Copia există doar pentru ca un nume și o imagine să poată fi afișate fără o cerere pentru fiecare rând și este resincronizată din revendicările verificate ale furnizorului la autentificare, la schimbarea echipei și la reîmprospătarea sesiunii. Nimic nu fabrică o valoare: o persoană pe care furnizorul nu a numit-o apare cu adresa ei de e-mail până când o face. Un hash de parolă există doar pentru proprietarul inițial al unei instalări fără niciun furnizor de identitate.

Același lucru este valabil pentru structură. O organizație la furnizor este o organizație Nessie, legată prin identificatorul organizației la furnizor; o echipă fără legătură în amonte răspunde cu 404 TEAM_NOT_LINKED, în loc să recurgă la o presupunere locală, iar o citire în direct a listei de membri merge la furnizorul de identitate și nu persistă nimic.

Două copii nu au dispărut încă și ar fi necinstit să sugerăm altceva. Numele organizațiilor și ale echipelor sunt încă stocate local, alături de identificatorii de legătură, iar rândurile locale de apartenență încă autorizează cererile obișnuite între sincronizări. Eliminarea ambelor este muncă deschisă, urmărită în depozitul de cod, nu ceva deja terminat.

Nimic comercial

Plățile sunt gestionate de serviciul central de facturare. Nessie nu stochează niciun client, abonament, factură, preț, sold de credit, politică de reîncărcare, consimțământ de plată, extras sau stare de anulare de la furnizorul de plăți și nu calculează tarife. Citește valori gata de afișat și le arată.

Secrete

Pentru a stoca un secret este necesar un seif configurat. În mod deliberat nu există nicio variantă de rezervă în baza de date și nicio cale în text clar: fără seif, salvarea, rotirea și revocarea unui secret returnează o eroare, în loc să degradeze către ceva mai puțin sigur. Evidențele proprii ale Nessie despre un secret nu conțin nicio valoare, niciun text cifrat, nicio cheie și niciun token de seif — doar o referință opacă și metadatele ei —, iar căile din seif sunt construite exclusiv din identificatori structurali, niciodată din numele unei organizații, echipe, proiect sau persoane.

Credențialele pe care Nessie trebuie să le dețină el însuși pentru a acționa ca client OAuth — credențiale de conectori și de căsuțe de e-mail, secrete de webhook, material de reîmprospătare a sesiunii, conținut pentru executori — sunt sigilate în plicuri AES-256-GCM legate de scop, sub un inel de chei versionat, care este o rădăcină separată de secretul de semnare a sesiunilor, cu o procedură de rotire documentată.

Există și o regulă privind modelele: un secret poate fi cunoscut ca existent și poate fi autorizat pentru folosire, dar materialul secret nu are voie să intre în contextul modelului, în prompturi, în argumentele sau rezultatele uneltelor, în memorie, în embeddings, în căutare, în jurnale sau în mesaje. Unui agent i se poate acorda dreptul de a folosi un secret. Nu i se poate acorda niciodată dreptul de a-l dezvălui.

Dacă discurile de dedesubt sunt criptate este o proprietate a mașinii pe care rulează o implementare. Depozitul de cod nu stabilește criptarea la nivel de volum pentru volumele bazei de date și ale stocării de obiecte, așa că această pagină nu pretinde acest lucru.

Izolarea tenanților

Nessie este multi-tenant prin construcție: o singură bază de date, în care fiecare rând aparține exact unei organizații, iar fiecare tabel subordonat poartă o coloană organization_id. Izolarea este impusă în două locuri — clauza de domeniu pe care o poartă fiecare interogare și cheile străine reale pe acea coloană, adăugate prin patruzeci și două de constrângeri după ce un audit intern a constatat că, pe zeci de tabele, coloana exista, dar fără nicio constrângere.

O suită de conformitate menține această invariantă la granița HTTP. Ea creează un atacator cu privilegii maxime — proprietar deplin al propriei organizații — și verifică faptul că fiecare citire canonică a resurselor altei organizații primește răspuns 403, 404 sau gol, iar fiecare mutație canonică este respinsă, fără ca rândul celeilalte organizații să fie atins. Acoperă canalele, aprobările, jurnalul de audit, declanșatoarele, agenții și legăturile lor, rulările, proiectele, sarcinile, firele de discuție, conexiunile, instalările de fluxuri de lucru, instanțele MCP, baza de cunoștințe și alertele.

Precizând exact mecanismul: aceasta este impunere la nivel de aplicație plus chei străine, nu securitate la nivel de rând (RLS) în PostgreSQL. Nu există nicio politică RLS și nicio plasă de siguranță în baza de date, iar suita de conformitate rulează pe un depozit fidel în memorie, nu pe o bază de date reală, deci demonstrează clauzele de domeniu pe care le scrie codul, nu SQL-ul pe care îl execută un server. Depozitul de cod spune asta în documentația proprie a suitei, la fel ca această pagină.

Jurnalul de audit

Fiecare acțiune cu consecințe este înregistrată: cine a acționat și în ce calitate — persoană, agent, serviciu —, ce a făcut, asupra cărei resurse, în ce organizație, proiect, echipă sau canal, dacă a reușit sau a fost refuzată, de ce, precum și identificatorul cererii, adresa și agentul de utilizator cu care a sosit.

Jurnalul este doar pentru adăugare prin construcție și nu există nicio cale de a scrie în el din exterior: POST /api/audit-log nu există, și asta este deliberat. Intrările sunt înlănțuite — fiecare poartă un rezumat SHA-256 al propriilor câmpuri canonice plus rezumatul intrării anterioare a organizației respective — astfel încât un rând modificat sau eliminat rupe lanțul și poate fi detectat. Un proprietar sau un administrator al organizației poate parcurge acest lanț la cerere și află unde s-a rupt prima dată, dacă s-a rupt.

Două rezerve cinstite. Lanțul face jurnalul vizibil la manipulare, nu imun la manipulare: în spatele lui nu există nicio revocare a dreptului de scriere la nivel de bază de date și nicio stocare write-once, deci garanția este detectarea, nu prevenirea. Iar intrările sunt păstrate implicit pe termen nelimitat — retenția configurabilă, cu export înainte de ștergere, este proiectată, nu construită. De asemenea, intrările nu au voie să conțină secrete sau corpuri complete de cereri, iar un set fix de nume sensibile de câmpuri din metadate este mascat la intrare.

Registrul de costuri

Fiecare invocare a unui model este înregistrată pe organizație, precum și pe utilizatorul, echipa, proiectul, canalul, agentul și rularea din care provine, cu tokenii consumați și cu costul raportat de furnizor alături de estimarea proprie a Nessie. O metrică pe care furnizorul nu o raportează este stocată ca null, nu ghicită. Rapoartele pot fi citite de un proprietar sau un administrator al organizației.

Acest registru este telemetrie operațională — cât a cheltuit o organizație și în numele cui. Nu este o factură și nu este o autoritate de facturare.

Terți, când folosiți produsul găzduit

O implementare găzduită comunică cu un set mic și fix de servicii. Traficul către modele și căutarea web nu merg direct la furnizori: ambele ies printr-un singur gateway operat de UnlikeOtherAI, unde se află furnizorii din amonte de modele și de căutare. Autentificarea și facturarea merg la autentificatorul UnlikeOtherAI. Seiful de secrete este găzduit propriu, alături de aplicație. Linkurile de apel video generate de server folosesc implicit serviciul public Jitsi.

Aproape tot restul este dezactivat până când un operator îl configurează și spune asta, în loc să eșueze în tăcere: conturile conectate Google, Microsoft și Slack; e-mailul agenților prin Amazon SES, pe care o implementare îl rulează în propriul cont, fără intermediar; notificările push mobile și din browser; conectorii de cercetare și de surse pentru tablă; browserele din cloud. Două detalii merită menționate, pentru că schimbă destinația datelor:

• Căsuțele de e-mail conectate rămân la furnizorul dvs. E-mailul este citit direct de la furnizorul dvs., prin IMAP și SMTP sau prin propria autentificare a furnizorului; Nessie stochează credențiala sigilată și nimic altceva despre cont. O căsuță pe care o conectați la inboxul Clients este excepția: cereți ca conversațiile ei să fie păstrate la fiecare client, așa că sunt copiate.
• Apelurile vocale din aplicație nu trec prin Nessie. API-ul furnizează o credențială, iar clientul deschide singur conexiunea audio. Dictarea și apelurile telefonice sunt diferite: sunetul lor trece prin Nessie către furnizorii de recunoaștere vocală și de modele care îl prelucrează.

Un detaliu de inferență urmează același principiu: antetele semnate de identitate a apelantului sunt trimise doar către gazda de chat configurată, așa că indicarea embeddings-urilor către alt endpoint nu îi dă acelui endpoint o aserțiune de delegare despre persoana al cărei text este transformat în embedding.

Produsul găzduit folosește mai mulți furnizori de inferență și alege între ei după cost și calitate. O organizație va putea alege în Admin ce furnizori au voie să folosească agenții ei: doar occidentali, doar europeni, doar chinezi sau fără preferință — cel mai eficient furnizor pentru fiecare sarcină. O instanță găzduită de dvs. și-i alege singură.

Dacă îl rulați singur, toate acestea se schimbă

Fiecare terț de mai sus este o alegere de configurare pe o instanță găzduită de dvs. Inferența poate fi îndreptată către orice endpoint compatibil OpenAI, inclusiv unul de pe hardware-ul dvs. Conectorii sunt dezactivați dacă nu îi activați. Autentificarea UnlikeOtherAI este calea acceptată, iar o implementare fără niciun furnizor de identitate rulează ca o singură organizație nelegată, cu un proprietar inițial.

Acesta este tot rostul aranjamentului: software-ul este același, iar deciziile despre unde rulează și la ce are acces aparțin celui care îl rulează. Pagina de instalare explică cum.